Systems and methods for identifying healthcare assets

Abstract

A system for identifying healthcare assets includes a set of tags configured to communicate with each other, the set of tags including a root tag configured to transmit an asset identifier identifying the healthcare asset and multiple component tags, each configured to transmit a component identifier identifying a part of the healthcare asset. A receiver system is configured to receive the asset identifier and the multiple component identifiers from the set of tags and to automatically generate a bill of materials (BOM) for the healthcare asset based on the asset identifier and the multiple component identifiers.

Description

Background Technology

[0001] This disclosure generally relates to systems and methods for identifying healthcare assets, and more specifically to systems and methods for automatically generating a bill of materials for healthcare assets and / or monitoring healthcare assets throughout their lifespan.

[0002] Healthcare assets such as computed tomography (CT) imagers, magnetic resonance (MR) imagers, positron emission tomography (PET) imagers, ultrasound imagers, C-arms, or other X-ray imagers are widely used for patient diagnosis, treatment, and monitoring. Healthcare institutions such as hospitals and clinics rely heavily on the availability, efficiency, and performance of these assets. Failure to these healthcare assets is unacceptable, therefore many healthcare assets undergo monitoring and preventative maintenance, which involves periodic maintenance and repair or replacement of critical components of such assets. These assets are complex systems in which many parts can be repaired or replaced throughout the asset's lifespan. Summary of the Invention

[0003] This summary is provided to introduce a series of concepts that will be further described in the detailed embodiments below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to help limit the scope of the claimed subject matter.

[0004] In one embodiment, a system for identifying healthcare assets includes a set of tags configured to communicate with each other, the set of tags including a root tag configured to transmit an asset identifier identifying the healthcare asset and multiple component tags, each configured to transmit a component identifier identifying a part of the healthcare asset. A receiver system is configured to receive the asset identifier and the multiple component identifiers from the set of tags and to automatically generate a bill of materials (BOM) for the healthcare asset based on the asset identifier and the multiple component identifiers.

[0005] One implementation of a method for identifying healthcare assets includes providing a set of tags configured to communicate with each other, and configuring this set of tags into a hierarchical structure based on the component structure of the healthcare asset. The tags are then manipulated to transmit an asset identifier identifying the healthcare asset and multiple component identifiers identifying the components of the healthcare asset. The asset identifier and multiple component identifiers are received at a receiver system, and a Bill of Materials (BOM) for the healthcare asset is then generated based on the asset identifier and multiple component identifiers.

[0006] Various other features, objects, and advantages of the invention will become apparent from the following description taken in conjunction with the accompanying drawings. Attached Figure Description

[0007] This disclosure is described with reference to the following figures.

[0008] Figure 1 An exemplary system for identifying healthcare assets is illustrated schematically.

[0009] Figure 2 A set of tags in a system for identifying healthcare assets according to one embodiment of this disclosure is shown.

[0010] Figure 3 An exemplary label is shown schematically according to one embodiment of this disclosure.

[0011] Figure 4 It is a flowchart depicting an implementation scheme generated based on the Bill of Materials (BOM) of an exemplary implementation scheme.

[0012] Figures 5 to 8 An exemplary method for identifying healthcare assets according to an embodiment of this disclosure is described. Detailed Implementation

[0013] The inventors have recognized the need to model each specific healthcare asset in the field, such as large imaging devices (e.g., CT imagers, MR imagers, PET imagers) and portable imagers (e.g., ultrasound imagers, C-arm imagers, or other portable X-ray imagers), as well as other types of high-value and complex healthcare assets. These complex assets have hundreds or even thousands of parts that may be maintained or replaced throughout the asset's lifespan. The inventors have also recognized the need for a system and method that can automatically generate and manage an asset's Bill of Materials (BOM) that can track the asset and all its components throughout its lifespan. A comprehensive and up-to-date BOM provides a digital model of the asset that can be used for many engineering, service, and commercial purposes. For example, a BOM can be used to predict the asset's required maintenance based on specific parts, materials, origins, etc., of all its components. Furthermore, a BOM across a range of assets can be used to monitor trends and trace the source of problems, such as tracing a problem back to a set of assets or the point of manufacture or other origin of an asset component. Additionally, a BOM can be used to monitor asset maintenance throughout its lifespan and / or ensure that accurate parts and correct maintenance are performed according to a predefined schedule.

[0014] In view of the aforementioned needs in the relevant art recognized by the inventors, the disclosed system and method are developed for identifying healthcare assets. The system includes a set of tags and a receiver system configured to communicate with each other. The receiver system is configured to receive information from the tags to automatically generate a Bill of Materials (BOM) for the tagged healthcare asset or any of its subsystems. In one embodiment, the set of tags may be configured in a hierarchical structure based on the component structure of the healthcare asset. The tags are operated to transmit an asset identifier identifying the healthcare asset and multiple component identifiers identifying components of the healthcare asset to the receiver system. In one embodiment, the hierarchical structure includes a root tag and multiple component tags. The root tag is configured to transmit the asset identifier identifying the healthcare asset. Each of the multiple component tags is configured to transmit a component identifier identifying a component, which may be a separate part of a subsystem of the healthcare asset. In one embodiment, the component tags are further hierarchically differentiated into parent-child relationships following the component structure of the healthcare asset.

[0015] In one implementation, tags are configured to communicate with a mesh network and thus route data in a non-hierarchical manner, although their identities can still be defined hierarchically based on the component structure of the healthcare asset. In other implementations, tags may be configured to communicate hierarchically, such as initiating messaging at the lowest node level and propagating messages upwards through the hierarchical structure. In such implementations, the root tag at the top of the hierarchical structure and / or a subset of tags may be configured to communicate with a receiver system. In view of this disclosure, as will be appreciated by those skilled in the art, various communication protocols and wireless or wired communication devices can be implemented to perform the disclosed systems and methods, including for communication between the group of tags on the healthcare asset and for communication between the group of tags and the receiver system.

[0016] Figure 1 An embodiment of System 2 for identifying healthcare asset 4 is schematically depicted. A set of tags 10 includes a root tag 12 and multiple component tags 14. Each component tag 14 is configured to be associated with and identify a component of healthcare asset 4. For example, each component tag 14 may store a component identifier that identifies a component of healthcare asset 4. In one embodiment, the multiple component tags may be hierarchically structured into a parent / child relationship, including one or more levels of parent / child tags 14a, 14b (see also...). Figure 2) and leaf tag 14c. In the hierarchical structure, each parent / child tag has a parent tag above it, which can be another parent / child tag 14a, 14b, or it can be the root tag 12. In the hierarchical structure, each parent / child tag has one or more child tags below it, which can be another parent / child tag 14a, 14b, or it can be a leaf tag 14c. One or more leaf tags 14c are located at the end of the hierarchical structure, where each leaf tag 14c has a parent tag but no child tags.

[0017] The set of tags 10 is configured to communicate with the receiver system 20, and is specifically configured to transmit the asset identifier of the healthcare asset 4 and multiple component identifiers identifying its parts. The receiver system 20 includes software such as a BOM module 22, an asset tracking module 24, and / or a tamper detection module 26, which is configured to perform various asset identification and tracking functions based on information received from the set of tags 10. The receiver system 20 includes a processing system 21 that executes the software 22, 24, 26 stored within the receiver system 20. In various embodiments, the receiver system 20 can be any computing system (which can be any object from a server to a mobile device) or a network of computing systems. For example, the receiver system 20 can be implemented on a cloud computing system.

[0018] The healthcare asset 4 identified by this set of tags 10 can be any type of healthcare asset with multiple component parts, and BOM generation and tracking are valuable for these component parts. Figure 2 This represents one embodiment of healthcare asset 4, which is an MR imager. A root tag 12 is configured to identify MR asset 4 and stores an asset identification number that identifies the MR asset. Multiple component tags 14 are each associated with a component of MR asset 4. MR imagers are complex systems, therefore the set of tags 10 may include hundreds or even thousands of tags marking various components of the MR system. Multiple component tags can be associated with each of the multiple subsystems within MR asset 4, such as gradient coils, RF coils, magnets, gantry, cold heads, patient examination tables, etc. Figure 2 Several examples are provided for the purpose of illustrating component labeling structures; however, given this disclosure, those skilled in the art will understand that any one of the many components in a given MR system can be labeled.

[0019] For gradient coil 100, parent component tag 14a is configured to transmit an identifier 100' of the gradient coil, which identifies a specific gradient coil incorporated into MR asset 4 for BOM purposes. Similarly, parent component tag 14a' is associated with RF coil 102 by being configured to and storing an asset identifier 102' of the RF coil. Similarly, parent component tag 14a' is associated with a magnet by storing and transmitting a component identifier 104' of a specific magnet 104 incorporated into a specific MR asset 4. In various embodiments, the component identifier stored on each tag 14a, 14b, 14c is configured to identify the type of component (e.g., gradient coil, X / Y / Z coil, RF coil, transmitter / receiver / RF shield, etc.) and the exact instance of the component (e.g., by a serial number or some other unique identifier). In some embodiments, the component identifier identifying a specific hardware component may be traceable to specify a particular manufacturing start point, product and / or material batch, software version, assembly line, etc., to identify the source of the component.

[0020] In the hierarchical structure, parent labels 14a, 14a', and 14a'" identify root label 12 as their parent label. Each parent label 14a, 14a', and 14a'" has multiple child labels 14b, which represent components within the corresponding subsystems 100, 102, and 104 represented by those parent component labels. In the depicted example, the parent component label 14a configured to identify gradient coil 100 has three child labels 14b1, 14b2, and 14b3. Child label 14b1 identifies X coil 100x, child label 14b2 identifies Y coil 100y, and Z coil 100z is identified by child label 14b3. Similarly, each sub-component of RF coil 102 is associated with a child label that reports to the parent component label 14a of RF coil 102. For example, receiver 102a is identified by sub-tag 14b4, RF shield 102b by sub-tag 14b5, transmitter 102c by sub-tag 14b6, and so on. Similarly, magnet 104 identified by parent tag 14a” has multiple sub-tags associated with it representing each of the external shield, internal shield, main winding, cryostat, etc. Each sub-tag 14b2 stores and is configured to transmit a component identifier identifying the corresponding component 100x, 100y, 100z, 102a, 102b, 102c, etc., including component type and specific component instance (e.g., serial number or other unique identifier). This information is then transmitted from this set of tags 10 to receiver system 20, as described herein with respect to various embodiments.

[0021] Each component label 14 is configured to store information relating to its position within the hierarchical structure, in addition to a component identifier. In one embodiment, configuring multiple component labels 14 includes storing a parent ID on each component label that identifies its parent. Therefore, Figure 2 In the example, each parent component label 14a stores the parent ID of the root label 12, which in the depicted example is MR asset identifier 4'. Each child label 14b stores the parent ID of its parent component label 14a for the subsystem to which it belongs. Thus, child labels 14b1, 14b2, and 14b3 each store the parent ID of their parent component label 14a, which in one example could be gradient coil identifier 100'. Given this disclosure, as will be understood by those skilled in the art, each child label described in this example can be the parent of another child label, and such additional child labels will similarly store... Figure 2 The parent ID of the sub-labels shown (e.g., 14b1, 14b2, 14b3). Furthermore, an additional level of hierarchical structure is provided down to the smallest sub-component being tracked, which is identified by leaf label 14c.

[0022] With each tag initially configured with a component identifier and a parent ID, the group of tags 10 can be configured to automatically map a hierarchical structure based on communication between parent and child tags. Each parent component tag 14a can be configured to identify and store its child component tags as those tags that transmit the corresponding parent ID that identifies the parent tag. Therefore, each tag 12, 14 is also configured to store and identify itself—that is, to store its own identifier. Thus, each component tag 14 is configured to identify the transmission of its own identifier through the child tags, and subsequently track and listen for messages from child tag 14b that transmit that identifier as a parent ID.

[0023] Each label 12, 14 can be configured as an external label, which is a unit attached (such as physically adhered) to each component of asset 4, or each label can be an integrated label manufactured as part of the asset and / or otherwise integrated into the asset. Figure 3 This represents one implementation of labels 12 and 14. Various label configurations can include... Figure 3A subset of the elements depicted herein, such as those depending on the tag's hierarchical location and / or system configuration. Each tag 12, 14 includes one or more functional modules 42-52 that can cooperate with CPU 56 and / or wireless communication modules 61-64 to function as described herein. In various embodiments, one or more tags of tags 12, 14 may be externally powered passive tags, or they may be active tags containing internal power supplies. Each tag 12, 14 may have a power module 54, which may be battery powered or may include a battery as a DC power source. The power module 54 may also include power control functions that allow tags 12, 14 to enter various power states, such as no power or low power passive modes, which can be engaged when tags 12, 14 are not transmitting and / or in a low battery or no-power state.

[0024] Each tag 12, 14 may have a messaging module 42 that facilitates communication with other tags and / or receiver systems 20. The messaging module 42 may be configured to support events, i.e., event generation upon detection of anomalies, notifications, payloads, etc., of tags 12, 14, or their associated child or parent tags. The messaging module 42 may be configured to manage multicast and / or broadcast messaging, depending on the system 2 configuration.

[0025] Each tag 12, 14 may have a connectivity module 44 configured to manage communication connections between a particular tag 12, 14 and its family members and / or with the receiver system 20. In various embodiments, tags 12, 14 may include a variety of different wireless communication receivers / transmitters configured to communicate via various wired or wireless protocols, including a Wi-Fi module 61 configured to communicate over a Wi-Fi network, a Near Field Communication (NFC) chip 62 configured to enable NFC communication, such as using a portable receiver system, and a Bluetooth Low Energy (BLE) module 64, such as a Bluetooth transceiver configured for mesh networking to enable many-to-many communication via Bluetooth radio.

[0026] Some tags 12, 14 may also include a radio frequency identification (RFID) chip 63 capable of RFID communication, such as for location tracking purposes. For example, the root tag 12 or high-level component tag 14 on a portable healthcare device (such as a portable ultrasound device) may include an RFID chip 63 capable of tracking the location of asset 4, such as via a real-time location system (RTLS) or other RFID-based tracking systems. Alternatively, other types of tracking systems, such as Wi-Fi-based tracking, may be used instead of RFID. For fixed assets 4 that do not require asset tracking, such as MR scanners and CT scanners, the RFID chip 63 and asset tracking functionality may be eliminated.

[0027] Each tag 12, 14 may have a clock module 46 configured to track time for purposes such as synchronizing message passing, timestamp events, and tracking time for periodic message passing purposes (e.g., "heartbeat" status message passing for asset monitoring purposes, as described below). Each tag 12, 14 may include various software instruction sets that provide logic for handling various connectivity and messaging needs, including communication between tags within set 10 and / or with receiver system 20, for tags that enable such communication. Software 48 may also be provided for detecting and managing events and related notifications, etc.

[0028] Each tag may include one or more configuration files 50, which contain configuration profiles for tags 12 and 14. Configuration files 50 include, for example, component identifiers or asset identifiers for the relevant tags, hierarchical categories or locations (e.g., root, parent, child, leaf), subsystem classifications (e.g., scanner, generator, tube, rack, gradient coil, etc.) or component descriptions (Z-coil, RF shield, etc.), series descriptors (the location of the component tag in the hierarchical structure), and parent IDs (all tags except the root tag) that associate a specific tag 14 with its parent in the hierarchical structure.

[0029] Each tag 12, 14 may include a storage system 52 that provides temporary storage for the payload before transmission, as well as available storage to accommodate various on-demand storage needs, such as for failures of the wireless transmitter and / or wireless communication system, low battery scenarios, etc. That is, the storage device 52 can be configured to store information generated by various other modules 42-50 when such information has not yet been transmitted or cannot be transmitted for some reason.

[0030] Each tag is configured for its specific role in the hierarchical structure, and therefore different hardware and software configurations can be provided for the various tags 12, 14a, 14b, 14c in System 2. In cases where the tag is an external tag configured to be attached to a component of Asset 4, hardware configurations oriented towards specific tag roles can be provided for different tag types—i.e., root, parent / child, leaf, etc. For example, root tag 12 may include more data communication modules 61-64 to support multiple communication options for various communication needs, such as communication between tags, communication with one or more receiver systems 20, communication with location tracking systems (e.g., RFID), etc. In some embodiments, System 2 may include multiple receiver systems 20, such as server systems and portable receiver systems, so root tag 12 can be configured to communicate with each receiver system 20 via various protocols (such as TCP / IP, UDP, NFC, NDEF, GATT, etc.).

[0031] Similarly, each tag type may have certain software functions configured to perform the tag's function within the hierarchy. In some embodiments, System 2 may be sold or provided as a set of tags 10 and receiver systems, wherein the set of tags 10 includes a root tag 12 pre-configured to perform desired functions and one or more component tags of different types, such as parent / child tags, system-level parent tags configured for higher-level functions in the hierarchy, leaf tags, etc. In some embodiments, each tag type may include a visual identifier that visually distinguishes tag types within set 10. For example, a root tag may have a root tag visual identifier that distinguishes it from root tag 12. Multiple component tags may have component tag visual identifiers, which may be different visual identifiers to identify the type of component tag (e.g., system-level parent, intermediate parent / child, leaf, etc.). For example, the visual identifier may be a color, text, and / or number tag that identifies the tag type.

[0032] Figure 4 It is shown Figure 2 The flowchart illustrates the tag communication and BOM creation functionality for MR assets. In the depicted example, each tag 12, 14 transmits its component identifier (or asset identifier in the case of a root tag) as well as the component identifiers of its children and their parent IDs. Therefore, the group of tags 10 in the depicted embodiment has been configured such that each tag knows its parent (in one embodiment, the parent is established as an initial configuration step) and its children (which can be established as subsequent configuration steps). Additionally, each tag may transmit other configuration information, such as its category (root, parent, child), its system or component description (“MR Rio2”, “gradient coil”, etc.), hierarchical level identifiers (level 1, level 2, level 3), etc.

[0033] In the depicted example, each system-level parent component label 14a, 14a', 14a'" transmits information about its parent ID used to identify the root label and information about its children 14b. For example, parent component label 14a of gradient coil 100 transmits component identifier 100' that identifies the gradient coil, a system description of the gradient coil, its label category (or label type), its parent ID 4', a description of its parent asset 4, and component identifiers 14b1-14b3 of its children and their hierarchical levels (level 2). System-level parent component labels 14a' and 14a'" transmit similarly structured messages for their system components. Each child 14b1-14b3 first transmits its component identifier, component description, etc., which is received at system-level parent component label 14a, which then relays the information transmitted by its children in its own transmission.

[0034] Root tag 12 listens for transmissions from its child, which is system-level parent tag 14a, and the root tag includes some or all of the information transmitted from parent tag 14a in root tag transmissions. In the depicted example, system-level parent tag 14a and root tag 12 are configured to transmit information to receiver system 20. Child tags 14b (and any leaf tags 14c) are not transmitted via a communication protocol established for receiver system 20, and therefore communicate only on tag networks, such as multicast or broadcast networks established for inter-tag communication. In other embodiments, only root tag 12 may be configured to communicate with receiver system 20, and therefore system-level parent tag 14a may communicate only within the tag network, and all messages and information from all tags in set 10 are transmitted from root tag 12. In other embodiments, child tag 14b may be configured to communicate with receiver system 20 such that receiver system 20 receives transmissions from multiple levels in the tag hierarchy.

[0035] Receiver system 20 receives transmissions from tags, including asset identifiers and identifiers of all components currently operating in system 2. Receiver system 20 is configured to generate one or more Bills of Materials (BOMs) based on the information transmitted by the tags. In one embodiment, receiver system 20 includes a BOM module 22, which is a set of software instructions configured to compile the transmitted information into a current BOM of healthcare asset 4 or a subsystem BOM of any subsystem within asset 4 (e.g., subsystems 100, 102, 104 of the MR asset). Figure 4 Exemplary steps for BOM creation, which can be performed, for example, by BOM module 22, are described. First, transmitter information can be queued and aggregated. In one embodiment, transmitted messages are queued based on transmission time. In some embodiments, the system can be configured with priority messaging capabilities, where certain critical components, such as those related to patient safety and / or those essential to the safe operation of healthcare asset 4, can transmit messages with priority codes. The queuing and message aggregation step 123 will accordingly prioritize those messages, such as placing them before earlier-occurring messages.

[0036] The aggregated messages are then clustered at step 124, such as based on their parent / child relationships. This is based on the assets coherently organizing messages for configuration and is used to group messages that may contain redundant information together. The various messages are then verified, such as by comparing messages from various devices to each other and / or comparing messages to previous transmissions from the same tag. An updated BOM is then generated at step 126 based on the transmitted messages. At step 127, BOM module 22 examines the updated BOM to determine if any event alerts should be generated to identify missing parts or other issues with asset 4.

[0037] In the event of one or more missing tags, such as due to component removal (where the component containing the tag is removed from the asset 4 system) or tag invalidation, a missing component event can be created at the tag level and transmitted to receiver system 20. For example, a parent tag can be configured to detect when it has not received a component identifier from one of its child component tags—i.e., a non-transmitted tag—and then generate a missing component event. The missing component event can propagate upwards through the hierarchical structure of the group of tags 10 and be transmitted to receiver system 20. Alternatively, each parent tag can be configured to transmit only information received from its children, and any missing components will be detected at the receiver system 20 level by a BOM module 22, which can be configured to detect missing component tags by recognizing any missing component identifiers from the transmission. In such embodiments, BOM module 22 can compare an updated BOM with a previously generated BOM of healthcare asset 4 to identify any missing component identifiers and generate a missing component alert accordingly. Such alerts can be provided to a user, for example, through a user interface for receiver system 20.

[0038] Various systems and methods can be provided for users to access information aggregated and generated by receiver system 20. Additionally, multiple receiver systems 20 can be combined within asset identification system 2. In one embodiment, master receiver system 20 can be combined within a host network associated with a healthcare institution, such as a hospital or other environment utilizing healthcare asset 4. Receiver system 20 can be housed within a server on the host network, which can be a field network or a cloud system. Alternatively or additionally, portable receiver systems can include portable readers configured to wirelessly communicate with one or more of tags 12, 14, such as via relatively short-range wireless communication devices. For example, one or more tags in set 10 (such as root tag 12 and / or system-level parent tag 14a) can be configured to communicate NFC with an adjacent portable reader to retrieve information from it. Alternatively or additionally, tag 14 can be configured for BLE communication for the same purpose. Thus, system 2 enables on-demand and on-site information collection from specific healthcare assets 4.

[0039] Figures 5 to 8 Exemplary implementations of a method 200 for identifying healthcare assets are described, including methods for various implementations of configuration and operating system 2. Figure 5 An implementation of a system configuration process for configuring a set of tags 10 into a hierarchical structure based on a component structure of healthcare assets is described. A set of tags is provided at step 202. A root tag is configured at step 204, such as by storing asset identifiers of the healthcare assets. As described above, additional configuration information may be stored in configuration file 50, such as information describing the assets, tag types, etc. Additionally, software 48 may be configured to enable root tag 12 functionality, as well as the messaging and connectivity configurations required to communicate with receiver system 20 and to communicate on the tag network.

[0040] Then, multiple component labels 14 are configured according to the hierarchical structure representing the components of healthcare asset 4. At step 206, one or more parent labels are configured, including by storing the associated component ID and storing the parent ID. For a system-level parent component label 14a representing the first level below the root label 12, the parent ID will identify the root label 12. Each subsequent label level is then configured, where each sub-label is configured to identify its parent at step 208. Finally, at step 210, one or more leaf labels 14c are configured, including storing their associated component identifier and identifying the parent ID of the sub-label 14b immediately above the leaf label.

[0041] Then, a system configuration exercise is initiated at step 212. For example, system configuration can be initiated by the root tag 12 of receiver system 20. In one embodiment, the configuration exercise begins at the leaf tag level, where each leaf tag transmits its component identifier and its parent ID at step 214. Then, each child tag stores information about any leaf tags associated with it at step 216. That is, each child tag 14b identifies a message containing its identifier in the parent ID position, and then the child tag identifies each such leaf tag as its child and stores the information transmitted from it. Then, the child tag performs its own transmission at step 218, where it transmits its component identifier and its parent ID, as well as leaf information transmitted from its child / leaf tags.

[0042] This process is repeated upwards in the hierarchical tag structure, where each parent tag receives and identifies its associated child tags at step 220, stores the information transmitted from the child tags, and then includes its child information in the transmission of its own tree structure at step 222. Therefore, in addition to its own component identifier and parent ID, the parent tag also transmits leaf information and all information from the child tags, allowing the transmitted information to be aggregated as it progresses upwards along the hierarchical structure. At each level, the parent tag is able to identify its child tags based on the transmission of its corresponding parent ID.

[0043] At the top, the root tag identifies its children, such as the system-level parent tag 14a, and stores the information transmitted from it at step 224. The root tag then transmits all tag information to the receiver at step 226. After receiving the transmissions from all tags, the receiver system 20 generates a BOM at step 228, such as the one described above. Figure 4 The steps described in the document.

[0044] Where the set of labels 10 includes external label elements that are adhesively or otherwise attached to the components of asset 4, it may be necessary to remove and replace such external label elements 12, 14. For example, a single label may be detached and replaced with a new label after it becomes invalid. Alternatively, components of asset 4 may be replaced and may include or have been attached new labels that need to be integrated into the BOM. Figure 6 The method steps for removing an old tag and replacing it with a new tag are described, such that the new tag is integrated into and replaces the hierarchical position in the structured group of tags 10 occupied by the old tag. The old tag is identified by a technician at step 230 and deactivated at step 232. At step 234, the deactivated tag is separated from the component (in the case of tag removal and replacement), or the entire component to which the tag is attached is removed from asset 4. Then, at step 236, a communication sequence is executed to verify tag removal, such that the group of tags 10 and the receiver system 20 identify the missing tag. Thereafter, the tag has been successfully removed, and the system identifies the missing tag.

[0045] Then, a new tag is attached at step 240 and configured at step 242, such as to store its part ID and / or parent ID, as described above. The new tag can be an external tag attached to a part or an integrated tag in which the tag element is integrated into the part system. In the case of replacing only the tag, the new tag is then attached to the part at step 244. Alternatively, in the case of providing a new part, the new part may contain a new tag that needs to be configured in the system when the new part is installed in asset 4. The tag is activated at step 246, such as by powering the tag, and connected to the network at step 248. The verification procedure is then repeated at step 250 to generate a new BOM showing the new tag in the appropriate hierarchical location. Once the new tag has been verified, the set of tags 10 and asset 4 can operate normally at step 252.

[0046] In some implementations, the asset tracking module can be configured to periodically receive "heartbeat" transmissions from the group of tags 10. For example, communications from the hierarchically configured group of tags 10 can be periodically generated, such as... Figure 4 The examples shown are pre-configured cycles suitable for a specific asset 4. To provide an example, periodic transmissions or "heartbeat" cycles can be generated daily or weekly. In other examples, heartbeat transmissions may be more frequent, such as several times per hour or per day. Other cycles for transmissions may be provided and are within the scope of this disclosure.

[0047] Asset tracking module 24 can be configured to set the heartbeat transmission period and receive and evaluate periodically transmitted information from the group of tags 10. In one such implementation, the heartbeat transmission process is initiated at step 260, which can be initiated at the lowest level of the hierarchical structure and propagate upwards. Thus, leaf tags 14c can each transmit their respective component identifiers and parent IDs, and messaging can propagate upwards through the hierarchical structure of the group of tags 10, as described above. An event may be generated when a tag in the system fails to receive a transmission from a child tag as expected. Figure 7In the example, a sub-tag only receives part IDs from a subset of the expected leaf tags. Therefore, if one or more leaf tags fail to transmit, it's either because the tag is not functioning or because the part to which the tag is attached has been removed. Of particular concern is the scenario where a part of Healthcare Asset 4 is removed and replaced with an unapproved part (such as an aftermarket part not approved by the manufacturer of Healthcare Asset 4). This can be problematic because untested and unapproved replacement parts may be of poor quality or may not function optimally within Healthcare Asset 4. Asset tracking module 24 and / or tamper detection module 26 can be configured to identify this scenario based on transmissions (or missing transmissions) from that set of tags 10. Similarly, in the event that one or more tags fail and therefore do not transmit as expected, asset tracking module 24 can be configured to alert the system operator to the tag failure.

[0048] return Figure 7 At step 264, a sub-tag that detects a missing leaf tag transmits a missing component event. For example, the sub-tag may transmit information received from a subset of leaf tags, along with a missing component event specifying one or more inactive leaf tags. The sub-tag also transmits its component ID and parent ID, causing the message to propagate up the system, along with the information it normally transmits as indicated at step 266. The message propagates up to root tag 12, which relays the missing component event along with its normal transmission information at step 268. Receiver system 20, specifically asset tracking module 24 and / or tamper detection module 26, receives and processes the information to generate a missing component alert at step 270, specifying the missing component and any situational awareness that can be derived from the missing tag information. For example, if several tags identify sub-components of a larger component system, such information can be provided in the event alert, allowing monitoring personnel to understand any potential problems with asset 4.

[0049] Figure 8Another embodiment for providing tamper detection steps is described, such as that which can be performed by the tamper detection module 26 of the set of tags 10 in conjunction with the receiver system 20. An event-driven transmission is generated at step 272. For example, a tag may generate a transmission when it is removed from the system, such as when a component is removed from the system, a tag is disconnected, or in other circumstances. For example, a parent tag may detect a warning transmission from a child tag that can only be generated before the child tag goes offline. The event-driven transmission propagates upwards through the hierarchically structured set of tags 10, and at step 274, all tag information is received from the root tag 12 at the receiver system 20. As described above, a new BOM is generated at step 276. At step 278, the new BOM is compared with one or more previously generated BOMs. In one embodiment, the tamper detection module 26 may be configured to identify missing or altered components based on the comparison at step 280. Alternatively or additionally, in the case of events transmitted from the tags, the tamper detection module 26 may identify missing components based on them. A missing component alarm is generated at step 282.

[0050] This written description uses examples to disclose the invention, including the best mode, and also enables those skilled in the art to perform and use the invention. Certain terms are used for the purpose of brevity, clarity, and ease of understanding. Unnecessary limitations should not be inferred from this description beyond the requirements of the prior art, as such terms are used for descriptive purposes only and are intended to be understood broadly. The patent scope of this invention is defined by the claims and may include other examples that would occur to those skilled in the art. These other examples are intended to be within the scope of the claims if they have features or structural elements that are not different from the literal language of the claims, or if they include equivalent features or structural elements that are not substantially different from the literal language of the claims.

Claims

1. A system for identifying healthcare assets, the system comprising: A set of tags, configured to communicate with each other in a hierarchical structure, the set of tags including: A root tag, which is configured to transmit an asset identifier that identifies the healthcare asset; Multiple component tags, each configured to transmit a component identifier that identifies a component of the healthcare asset; and A receiver system configured to receive the asset identifier and multiple component identifiers from the set of tags, and to automatically generate a bill of materials (BOM) for the healthcare asset based on the asset identifier and the multiple component identifiers; The plurality of component tags are configured in a hierarchical structure, such that each component tag stores a parent ID that identifies its parent component tag, and each component tag is further configured to transmit its parent ID in conjunction with its component identifier; and Each parent component label is configured to identify one or more component labels corresponding to its parent ID as child component labels. The hierarchical structure also includes a parent component label having at least one associated child component label and at least one leaf component label not having an associated child component label, wherein: The heartbeat transmission process is initiated at the at least one leaf component label; The at least one sub-component label only receives the component ID of a subset of the expected leaf component labels; The child label that detects a missing leaf component label transmits its parent ID, component ID, and missing component event until the missing component event is transmitted to the root label; A missing component alert is generated based on the missing component event.

2. The system of claim 1, wherein each parent component label is configured to transmit the component identifier from each of its child component labels in combination with its component identifier and its parent ID.

3. The system of claim 2, wherein each parent component label is configured to detect a missing component identifier of a non-transmitting child component label in its child component labels and transmit a missing component event.

4. The system of claim 2, wherein the root tag is configured to transmit a component identifier from all component tags transmitted in the hierarchical structure.

5. The system of claim 4, wherein the root tag is further configured to detect a missing component identifier of a non-transmitting sub-component tag in its sub-component tags and transmit a missing component event, and wherein the receiver system is configured to generate a missing component alarm identifying the missing component based on the missing component event.

6. The system of claim 4, wherein the root tag is configured to transmit the component identifier from all transmission component tags in the set of tags.

7. The system of claim 1, wherein the receiver system is further configured to: Compare the multiple component identifiers from the set of tags with the previously generated BOM of the healthcare asset; and Based on the comparison, the missing component label is identified and a missing component alert is generated that identifies the missing component.

8. The system of claim 1, wherein the receiver system is further configured to generate a subsystem BOM within one or more subsystems of the healthcare asset.

9. The system of claim 1, further comprising a portable reader configured to wirelessly communicate with the root tag, wherein the root tag is configured to wirelessly communicate with the portable reader.

10. The system of claim 1, wherein each of the plurality of component tags is configured to be attached to a corresponding component thus identified, and the root tag is configured to be attached to or near the healthcare asset.

11. The system of claim 10, wherein the root label has a root label visual identifier thereon, and each of the plurality of component labels has a component label visual identifier thereon.

12. The system of claim 11, wherein each parent component label has a parent label visual identifier thereon, and each leaf component label has a leaf label visual identifier thereon.

13. A method for identifying healthcare assets, the method comprising: Provides a set of tags configured to communicate with each other; Based on the component structure of the healthcare asset, the set of tags is configured into a hierarchical structure, and the tags are operated to transmit an asset identifier that identifies the healthcare asset and multiple component identifiers that identify the components of the healthcare asset. Receive the asset identifier and the plurality of component identifiers at the receiver system; as well as Based on the asset identifier and the plurality of component identifiers, a bill of materials (BOM) for the healthcare asset is generated at the receiver system; including: The asset identifier is stored on one of the tags in the set of tags. In order to configure the root tag associated with the healthcare asset; and A different component identifier from the plurality of component identifiers is stored on each of the remaining tags in the set of tags in order to configure a plurality of component tags, the plurality of component tags being further configured into a hierarchical structure; For each component label in the component labels, a parent ID is stored thereon and each component label is configured to transmit its parent ID in conjunction with its component identifier; and The transmission of one or more component tags corresponding to the parent ID is identified as child component tags; and Receive the component identifier from each of its associated sub-component labels; The hierarchical structure further includes a parent component label having at least one associated child component label and at least one leaf component label not having an associated child component label; and wherein: The heartbeat transmission process is initiated at at least one leaf component label; The at least one sub-component label only receives the component ID of a subset of the expected leaf component labels; The child label that detects a missing leaf component label transmits its parent ID, component ID, and missing component event until the missing component event is transmitted to the root label; A missing component alert is generated based on the missing component event.

14. The method of claim 13, further comprising operating each parent component tag to transmit the component identifier received from each child component tag in conjunction with its component identifier and its parent ID, and operating the root tag to transmit the component identifier from all component tags in the hierarchy.

15. The method of claim 13, wherein each parent component label is configured to detect a missing component identifier of one of its child component labels, and to transmit a missing component event in combination with its component identifier and its parent ID.

Images