Patent Description:
Real-time location systems (RTLS) monitor asset distribution and usage, providing actionable information to help control costs and improve the quality and efficiency of care. Systems that have been developed to track and analyze activities in clinical settings have included installing Radio Frequency Identification (RFID) or infrared (IR) reader infrastructures into buildings to capture position information. RFID sensors may be placed on the people and/or assets that need to be tracked.

However, this is an expensive and time-consuming solution because it requires pulling power and data cabling to all the required locations. Location accuracy can also vary depending on technology. Typical RFID systems have a tolerance of approximately plus-or-minus ten feet, further limiting their range. RFID and IR-based sensors, though, are highly susceptible to drift due to interference in the environment (e.g., a patient room) and cross talk between locations that are physically separated, but have a line of sight between them (e.g., two patient rooms across the hall from each other).

Therefore, it would be desirable to design a system and method for tracking locations and interactions between people and assets in an environment with minimal infrastructure requirements and standardized technologies. <CIT> discloses an asset tag device including a housing, a battery disposed within the housing, a circuit board disposed within the housing and in electrical communication with the battery. The circuit board includes a local memory, a transceiver to detect local signals and transmit a response packet, and a processor. The processor to identify the detected local signals, determine whether the detected local signals include at least one beacon signal, store, to the local memory, the at least one beacon signal, sort, in the local memory, the stored at least one beacon signal by proximity to the asset tag device, parse the sorted at least one beacon signal, and append tag information to the parsed at least one beacon signal to generate the response packet. <CIT> Al describes, according to its abstract, methods and systems relating to location-based services such as social networking, providing demographic information, tracking mobile devices, providing business information, providing an adaptable user interface, remotely effecting a change on a portable electronic device, providing a geofence, outputting location-based information on a mobile device, varying transmissions to and from a mobile device, providing location-based alerts, verifying transactions and tailoring information to the behavior of a user. <CIT> discloses an electronic device configured to attach to a human-powered vehicle.

The features and technical aspects of the system and method disclosed herein will become apparent in the following Detailed Description set forth below when taken in conjunction with the drawings in which like reference numerals indicate identical or functionally similar elements.

In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific examples that may be practiced. These examples are described in sufficient detail to enable one skilled in the art to practice the subject matter, and it is to be understood that other examples may be utilized and that logical, mechanical, electrical and other changes may be made without departing from the scope of the subject matter of this disclosure. The following detailed description is, therefore, provided to describe an exemplary implementation and not to be taken as limiting on the scope of the subject matter described in this disclosure. Certain features from different aspects of the following description may be combined to form yet new aspects of the subject matter discussed below.

Certain examples of the presently disclosed technology improve proximity detection and location tracking of resources in an environment such as a hospital. An example system disclosed herein includes one or more beacon tags affixed to assets within the environment and that transmit (e.g., periodically, aperiodically and/or as a one-time event) beacon messages. The beacon messages are received by a mobile reader badge that listens for beacon messages transmitted in the environment. For example, disclosed example reader badges (sometimes referred to herein as "readers," "badges" or "mobile wireless bridges") may include a network interface to receive beacon messages transmitted via low power Bluetooth Low Energy (BLE). In some disclosed examples, the reader badges process the received beacon messages and communicate information obtained from the beacon messages to one or more real-time location services (RTLS) servers via a communication infrastructure. For example, disclosed example reader badges may aggregate and communicate a batch of beacon messages (e.g., a threshold number of beacon messages, a threshold interval of time (e.g., a window of interest), etc.) to an RTLS server via a Wi-Fi infrastructure (e.g., a wireless network). In some disclosed examples, the RTLS server processes the received batch of beacon messages to facilitate real-time location tracking of the resources in the environment. In some disclosed examples, the RTLS server may report the location of resources via charts, graphs, tables, etc..

Real-time location services enable improved patient workflow via proximity detection and location tracking in a healthcare environment, such as a hospital. Location tracking can be used to locate resources such as mobile assets (e.g., patients, intravenous (IV) pumps, telemetry units, wheelchairs, etc.) within the hospital. For example, location tracking can be used to locate a "lost" or "missing" IV pump within a patient's room. Proximity detection facilitates an improved understanding of how interactions occur during the patient workflow. For example, based on the proximity to a soap dispenser, a user (e.g., a system administrator) can determine whether a caretaker washed their hands prior to interacting with a patient.

Examples systems and methods disclosed herein facilitate improved proximity detection and location tracking by creating a hospital tracking network within the hospital using the communication infrastructure already installed in the hospital. Beacon tags are installed throughout a location or building. For example, beacon tags can be affixed to stationary assets (e.g., patient room entry ways, sinks, water fountains, hallways, etc.) and mobile assets such as hospital beds, IV pumps, soap dispensers, etc. In some disclosed examples, the beacon tags are also included in disposable patient tags provided to the patient upon admission of a hospital stay. Beacon tags are low-cost, low-power transmitters of beacon messages. A beacon message (sometimes referred to herein as a "beacon") includes information about the beacon tag such as a unique identifier (e.g., a tag identifier such as a media access control (MAC) address) and a tag type identifier (e.g., whether the beacon tag is affixed to a fixed-location asset or to a mobile asset). In some disclosed examples, the beacon tags broadcast (e.g., advertise, communicate, transmit, etc.) beacon messages at preset frequencies (e.g., ten times a second, once a second, once a minute, etc.). For example, a beacon tag affixed to a fixed-location asset (e.g., a sink) may broadcast beacon messages ten times a second, while a beacon tag affixed to a mobile asset (e.g., a wheelchair) may broadcast beacon messages at relatively shorter intervals (e.g., once a second).

A reader badge is a mobile wireless bridge that facilitates mobile tracking by "listening" and receiving beacon messages broadcast by beacon tags. The reader badge includes a BLE controller to receive connection-less beacon messages broadcast by beacon tags. The reader badge also includes a Wi-Fi controller to establish a connection with an RTLS server. The reader badge may be worn or transported by hospital caregivers. For example, a reader badge may be worn as a lanyard or clipped to the caregiver's clothing. As the caregiver moves about the hospital, the reader badge passively collects beacon messages and communicates reader messages to an RTLS server at the backend of the system. In some examples, the reader badge collects a number (e.g., a predetermined number) of beacon messages or waits a period (e.g., a predetermined period of time) prior to communicating the reader messages. In some examples, the reader badge generates and communicates a reader message as a beacon message from a beacon tag is received. A reader message includes information received from the beacon message such as a unique identifier of the source beacon tag and a spatial location of the source beacon tag. In some examples, the reader badge includes a timestamp identifying when the beacon message was received by the reader badge in the reader message. In some examples, the reader badge includes a received signal strength indication (RSSI) value (e.g., a power ratio in decibels of the measured power to one milli-watt (dBm)).

Example reader badges disclosed herein include a proximity engine to process the beacon messages and determine distance from the source (e.g., the beacon tag that broadcast the corresponding beacon message). For example, a hospital room may include a first beacon tag affixed to a door, a second beacon tag affixed to an infusion pump, a third beacon tag affixed to a bed, and a fourth beacon tag included in a patient tag (e.g., a disposable bracelet including patient identification information such as name, sex, date of birth information). As the caregiver moves about the hospital room, the reader badge may receive beacon messages from each of the beacon tags. The proximity engine can determine the RSSI strength for each of the beacon messages and associate RSSI strength with a respective beacon tag.

In some examples, the proximity engine determines which beacon tags are proximate (e.g., near or closely located) to the reader badge. For example, the proximity engine can compare the RSSI strength of a beacon message to a threshold and if the RSSI strength satisfies the threshold (e.g., the RSSI strength is greater than a threshold), the proximity engine identifies the source beacon tag as proximate to the reader badge. In some examples, the proximity engine discards beacon messages that are not proximate to the reader badge.

Example systems and methods disclosed herein include an RTLS server that monitors and/or reports tracking location and interactions between people and assets in an environment. For example, the RTLS server can aggregate reader messages from the one or more reader badges included in an environment (e.g., the hospital). The RTLS server may be in connection with the reader badges via a wireless Intranet network (e.g., a wireless local area network, etc.) and/or a wireless Internet connection.

As healthcare assets continue to become smaller and more ergonomic, RTLS tracking with a small footprint becomes increasingly important. Additionally, as a hospital's inventory of healthcare equipment gets leaner, the equipment is likely to be cleaned more often. Therefore, an asset tracking beacon should withstand frequent, repeated cleaning with harsh disinfecting chemicals.

Certain examples provide an improved housing that can be applied with BLE and/or other location tracking technology to healthcare assets (e.g., scanner, IV pumps, monitors, etc.). In certain examples, a computerized maintenance management system (CMMS) and/or source system can organize and monitor assets and can remove and reassociate beacons from one asset to another asset on demand. Beacons can be installed on ergonomic items that do not have flat surfaces. Beacons can be developed with housings to withstand rigorous healthcare cleaning protocols while maintaining a small footprint to not disturb normal usage of equipment to which the beacon is applied.

A quality of location data provided by a real time location platform can depend on health of devices deployed to receive sensory and/or location events. If deployed devices are not functioning as intended, the location data produced by the system may be inaccurate/unreliable. To help ensure accurate location data, support teams can monitor system health, isolate problematic devices and correct the problems through reconfiguration/replacement/upgrades/etc..

Certain examples provide receiver health methods and systems for real time location platforms. Certain examples define a mechanism and associated application programming interface (API) specification by which location receivers deployed as part of a real time location platform can transmit system health information using an event-based messaging framework. The data/events provided can be captured and utilized to maintain the system and help ensure improved or optimal performance.

Devices used to implement a real time location platform may have numerous dependencies, including a reliable power supply (e.g., battery, outlet, etc.), network connectivity and acceptable environmental conditions (e.g. min/max operating temperature, etc.). With a large number of devices deployed, it is not feasible or cost effective to manually inspect each device in the field on a regular basis. Certain examples facilitate device self-reporting of health status and associated system events to help maintain a functioning system.

In certain examples, location devices are designed to submit event data (e.g., as JavaScript Object Notation (JSON) documents, etc.) to a service interface (e.g., a representational state transfer (REST) or RESTful service interface, etc.). There are numerous events defined, and these events can be sent in response to a condition (e.g., device regaining network connectivity, device placed on charger, device removed from charger, etc.) or on a time schedule that is configurable as part of the device profile. Events include a set of base (e.g., header, etc.) attributes that are used for ongoing system health management. In addition, each event includes a details section where attributes/data specific to an event type can be included.

In certain examples, receiver health includes a set of events defined for receiver devices (e.g., Bluetooth receiver devices, BLE receiver devices, etc.). The set of events can be defined according to an API, for example. In certain examples, a gateway client API includes a service interface specification or API for the RESTful service used by the device to post receiver health events, etc..

Certain examples provide a centralized health and monitoring capability for large scale systems that include a plurality of devices deployed in a wide range of environments. Without such monitoring, deployed systems may fall into disrepair over time and/or the costs of monitoring/maintaining such systems may threaten the commercial viability of the dependent products, for example.

Certain examples, when utilized, result in improved system performance, higher customer satisfaction, higher return on investment for the customer, lower cost of ownership for the customer, lower support costs for the supplier and increased profit margin for the supplier, etc..

Types and details of health events reported by devices can be extended/modified in a variety of ways to propose a "unique" set of health events. The mechanisms/protocols by which the events are delivered (e.g. JSON/XML/CSV or HTTP/JMS/SMTP, etc.) and/or captured can also be varied to propose a "unique" solution, for example.

Certain examples provide a custom beacon protocol (e.g., a custom BLE beacon protocol, etc.) that provides all involved fields for message processing and location determination, as well as system health status including low battery indication (e.g., in days remaining, hours remaining, percent remaining, battery value, etc.), custom fields for additional installation specific data (e.g., profile identifier (ID), floor designation, department ID, etc.), beacon security, and/or other item(s). While no single existing protocol fulfills these needs, certain examples provide a new protocol that enable location systems to provide customers with system health and security information/messaging and also enable additional device level functionality by allowing custom data within the protocol.

Health information, also referred to as healthcare information and/or healthcare data, relates to information generated and/or used by a healthcare entity. Health information can include reader messages and RTLS server information, for example. Health information can be information associated with health of one or more patients, for example. Health information may include protected health information (PHI), as outlined in the Health Insurance Portability and Accountability Act (HIPAA), which is identifiable as associated with a particular patient and is protected from unauthorized disclosure. Health information can be organized as internal information and external information. Internal information includes patient encounter information (e.g., patient-specific data, aggregate data, comparative data, etc.) and general healthcare operations information, etc. External information includes comparative data, expert and/or knowledge-based data, etc. Information can have both a clinical (e.g., diagnosis, treatment, prevention, etc.) purpose and an administrative (e.g., scheduling, billing, management, etc.) purpose.

Institutions, such as healthcare institutions, having complex network support environments and sometimes chaotically driven process flows utilize secure handling and safeguarding of the flow of sensitive information (e.g., personal privacy). A need for secure handling and safeguarding of information increases as a demand for flexibility, volume, and speed of exchange of such information grows. For example, healthcare institutions provide enhanced control and safeguarding of the exchange and storage of sensitive patient PHI and employee information between diverse locations to improve hospital operational efficiency in an operational environment typically having a chaotic-driven demand by patients for hospital services. In certain examples, patient identifying information can be masked or even stripped from certain data depending upon where the data is stored and who has access to that data. In some examples, PHI that has been "de-identified" can be re-identified based on a key and/or other encoder/decoder.

A healthcare information technology infrastructure can be adapted to service multiple business interests while providing clinical information and services. Such an infrastructure may include a centralized capability including, for example, a data repository, reporting, discreet data exchange/connectivity, "smart" algorithms, personalization/consumer decision support, etc. This centralized capability provides information and functionality to a plurality of users including medical devices, electronic records, access portals, pay for performance (P4P), chronic disease models, and clinical health information exchange/regional health information organization (HIE/RHIO), and/or enterprise pharmaceutical studies, home health, for example.

Interconnection of multiple data sources helps enable an engagement of all relevant members of a patient's care team and helps improve an administrative and management burden on the patient for managing his or her care. Particularly, interconnecting the patient's electronic medical record and/or other medical data can help improve patient care and management of patient information. Furthermore, patient care compliance is facilitated by providing tools that automatically adapt to the specific and changing health conditions of the patient and provide comprehensive education and compliance tools to drive positive health outcomes.

In certain examples, healthcare information can be distributed among multiple applications using a variety of database and storage technologies and data formats. To provide a common interface and access to data residing across these applications, a connectivity framework (CF) can be provided which leverages common data models (CDM) and common service models (CSM) and service oriented technologies, such as an enterprise service bus (ESB) to provide access to the data.

In certain examples, a variety of user interface frameworks and technologies can be used to build applications for health information systems including, but not limited to, MICROSOFT® ASP. NET, AJAX®, MICROSOFT® Windows Presentation Foundation, GOOGLE® Web Toolkit, MICROSOFT® Silverlight, ADOBE®, and others. Applications can be composed from libraries of information widgets to display multi-content and multimedia information, for example. In addition, the framework enables users to tailor layout of applications and interact with underlying data.

In certain examples, an advanced Service-Oriented Architecture (SOA) with a modern technology stack helps provide robust interoperability, reliability, and performance. Example SOA includes a three-fold interoperability strategy including a central repository (e.g., a central repository built from Health Level Seven (HL7) transactions), services for working in federated environments, and visual integration with third-party applications. Certain examples provide portable content enabling plug 'n play content exchange among healthcare organizations. A standardized vocabulary using common standards (e.g., LOINC, SNOMED CT, RxNorm, FDB, ICD-<NUM>, ICD-<NUM>, etc.) is used for interoperability, for example. Certain examples provide an intuitive user interface to help minimize end-user training. Certain examples facilitate user-initiated launching of third-party applications directly from a desktop interface to help provide a seamless workflow by sharing user, patient, and/or other contexts. Certain examples provide real-time (or at least substantially real time assuming some system delay) patient data from one or more information technology (IT) systems and facilitate comparison(s) against evidence-based best practices. Certain examples provide one or more dashboards for specific sets of patients. Dashboard(s) can be based on condition, role, and/or other criteria to indicate variation(s) from a desired practice, for example.

An information system can be defined as an arrangement of information/data, processes, and information technology that interact to collect, process, store, and provide informational output to support delivery of healthcare to one or more patients. Information technology includes computer technology (e.g., hardware and software) along with data and telecommunications technology (e.g., data, image, and/or voice network, etc.).

Turning now to the figures, <FIG> shows a block diagram of an example healthcare-focused information system <NUM>. The example healthcare-focused information system <NUM> can be configured to implement a variety of systems and processes including image storage (e.g., picture archiving and communication system (PACS), etc.), image processing and/or analysis, radiology reporting and/or review (e.g., radiology information system (RIS), etc.), computerized provider order entry (CPOE) system, clinical decision support, patient monitoring, population health management (e.g., population health management system (PHMS), health information exchange (HIE), etc.), healthcare data analytics, cloud-based image sharing, electronic medical record (e.g., electronic medical record system (EMR), electronic health record system (EHR), electronic patient record (EPR), personal health record system (PHR), etc.), RTLS server, and/or other health information system (e.g., clinical information system (CIS), hospital information system (HIS), patient data management system (PDMS), laboratory information system (LIS), cardiovascular information system (CVIS), etc..

As illustrated in <FIG>, the example healthcare-focused information system <NUM> includes an input <NUM>, an output <NUM>, a processor <NUM>, a memory <NUM>, and a communication interface <NUM>. The components of the example healthcare-focused information system <NUM> can be integrated in one device or distributed over two or more devices.

The example input <NUM> of <FIG> may include a keyboard, a touch-screen, a mouse, a trackball, a track pad, optical barcode recognition, voice command, etc. or combination thereof used to communicate an instruction or data to the example healthcare-focused information system <NUM>. The example input <NUM> may include an interface between systems, between user(s) and the healthcare-focused information system <NUM>, etc..

The example output <NUM> of <FIG> can provide a display generated by the processor <NUM> for visual illustration on a monitor or the like. The display can be in the form of a network interface or graphic user interface (GUI) to exchange data, instructions, or illustrations on a computing device via the communication interface <NUM>, for example. The example output <NUM> may include a monitor (e.g., liquid crystal display (LCD), plasma display, cathode ray tube (CRT), etc.), light emitting diodes (LEDs), a touch-screen, a printer, a speaker, or other conventional display device or combination thereof.

The example processor <NUM> of <FIG> includes hardware and/or software configuring the hardware to execute one or more tasks and/or implement a particular system configuration. The example processor <NUM> processes data received at the input <NUM> and generates a result that can be provided to one or more of the output <NUM>, the memory <NUM>, and the communication interface <NUM>. For example, the example processor <NUM> can take user annotation provided via the input <NUM> with respect to an image displayed via the output <NUM> and can generate a report associated with the image based on the annotation. As another example, the example processor <NUM> can process updated patient information obtained via the input <NUM> to provide an updated patient record to an EMR via the communication interface <NUM>.

The example memory <NUM> of <FIG> may include a relational database, an object-oriented database, a data dictionary, a clinical data repository, a data warehouse, a data mart, a vendor neutral archive, an enterprise archive, etc. The example memory <NUM> stores images, patient data, best practices, clinical knowledge, analytics, reports, etc. The example memory <NUM> can store data and/or instructions for access by the processor <NUM>. In certain examples, the memory <NUM> can be accessible by an external system via the communication interface <NUM>.

In certain examples, the memory <NUM> stores and controls access to encrypted information, such as patient records, encrypted update-transactions for patient medical records, including usage history, etc. In an example, medical records can be stored without using logic structures specific to medical records. In such a manner, the memory <NUM> is not searchable. For example, a patient's data can be encrypted with a unique patient-owned key at the source of the data. The data is then uploaded to the memory <NUM>. The memory <NUM> does not process or store unencrypted data thus minimizing privacy concerns. The patient's data can be downloaded and decrypted locally with the encryption key.

For example, the memory <NUM> can be structured according to provider, patient, patient/provider association, and document. Provider information may include, for example, an identifier, a name, and address, a public key, and one or more security categories. Patient information may include, for example, an identifier, a password hash, and an encrypted email address. Patient/provider association information may include a provider identifier, a patient identifier, an encrypted key, and one or more override security categories. Document information may include an identifier, a patient identifier, a clinic identifier, a security category, and encrypted data, for example.

The example communication interface <NUM> of <FIG> facilitates transmission of electronic data within and/or among one or more systems. Communication via the communication interface <NUM> can be implemented using one or more protocols. In some examples, communication via the communication interface <NUM> occurs according to one or more standards (e.g., Digital Imaging and Communications in Medicine (DICOM), Health Level Seven (HL7), ANSI X12N, etc.). The example communication interface <NUM> can be a wired interface (e.g., a data bus, a Universal Serial Bus (USB) connection, etc.) and/or a wireless interface (e.g., radio frequency, infrared, near field communication (NFC), etc.). For example, the communication interface <NUM> may communicate via wired local area network (LAN), wireless LAN, wide area network (WAN), etc. using any past, present, or future communication protocol (e.g., BLUETOOTH™, USB <NUM>, USB <NUM>, etc.).

In certain examples, a Web-based portal may be used to facilitate access to information, patient care and/or practice management, etc. Information and/or functionality available via the Web-based portal may include one or more of order entry, laboratory test results review system, patient information, clinical decision support, medication management, scheduling, electronic mail and/or messaging, medical resources, etc. In certain examples, a browser-based interface can serve as a zero footprint, zero download, and/or other universal viewer for a client device.

In certain examples, the Web-based portal serves as a central interface to access information and applications, for example. Data may be viewed through the Web-based portal or viewer, for example. Additionally, data may be manipulated and propagated using the Web-based portal, for example. Data may be generated, modified, stored and/or used and then communicated to another application or system to be modified, stored and/or used, for example, via the Web-based portal, for example.

The Web-based portal may be accessible locally (e.g., in an office) and/or remotely (e.g., via the Internet and/or other private network or connection), for example. The Web-based portal may be configured to help or guide a user in accessing data and/or functions to facilitate patient care and practice management, for example. In certain examples, the Web-based portal may be configured according to certain rules, preferences and/or functions, for example. For example, a user may customize the Web portal according to particular desires, preferences and/or requirements.

<FIG> shows a block diagram of an example healthcare information system (e.g., an infrastructure) <NUM> including one or more subsystems such as the example healthcare-related information system <NUM> illustrated in <FIG>. The example healthcare information system <NUM> of <FIG> includes a HIS <NUM>, a RIS <NUM>, a PACS <NUM>, an interface unit <NUM>, a data center <NUM>, and a workstation <NUM>. In the illustrated example, the HIS <NUM>, the RIS <NUM>, and the PACS <NUM> are housed in a healthcare facility and locally archived. However, in other implementations, the HIS <NUM>, the RIS <NUM>, and/or the PACS <NUM> may be housed within one or more other suitable locations. In certain implementations, one or more of the HIS <NUM>, the RIS <NUM>, the PACS <NUM>, etc., may be implemented remotely via a thin client and/or downloadable software solution. Furthermore, one or more components of the healthcare information system <NUM> can be combined and/or implemented together. For example, the RIS <NUM> and/or the PACS <NUM> can be integrated with the HIS <NUM>, the PACS <NUM> can be integrated with the RIS <NUM>, and/or the three example information systems <NUM>, <NUM>, and/or <NUM> can be integrated together. In other example implementations, the healthcare information system <NUM> includes a subset of the illustrated information systems <NUM>, <NUM>, and/or <NUM>. For example, the healthcare information system <NUM> may include only one or two of the HIS <NUM>, the RIS <NUM>, and/or the PACS <NUM>. Information (e.g., scheduling, test results, exam image data, observations, diagnosis, etc.) can be entered into the HIS <NUM>, the RIS <NUM>, and/or the PACS <NUM> by healthcare practitioners (e.g., radiologists, physicians, and/or technicians) and/or administrators before and/or after patient examination. One or more of the HIS <NUM>, the RIS <NUM>, and/or the PACS <NUM> can include and/or communicate with an RTLS server and can communicate with equipment and system(s) in an operating room, patient room, etc., to track activity, correlate information, generate reports and/or next actions, and the like.

In the illustrated example of <FIG>, the HIS <NUM> stores medical information such as clinical reports, patient information, and/or administrative information received from, for example, personnel at a hospital, clinic, and/or a physician's office (e.g., an EMR, EHR, PHR, etc.). The example RIS <NUM> of the illustrated example of <FIG> stores information such as, for example, radiology reports, radiology exam image data, messages, warnings, alerts, patient scheduling information, patient demographic data, patient tracking information, and/or physician and patient status monitors. Additionally, the RIS <NUM> enables exam order entry (e.g., ordering an x-ray of a patient) and image and film tracking (e.g., tracking identities of one or more people that have checked out a film). In some examples, information in the RIS <NUM> is formatted according to the HL-<NUM> (Health Level Seven) clinical communication protocol. In certain examples, a medical exam distributor is located in the RIS <NUM> to facilitate distribution of radiology exams to a radiologist workload for review and management of the exam distribution by, for example, an administrator.

In the illustrated example of <FIG>, the PACS <NUM> stores medical images (e.g., x-rays, scans, three-dimensional renderings, etc.) as, for example, digital images in a database or registry. In some examples, the medical images are stored in the PACS <NUM> using the Digital Imaging and Communications in Medicine (DICOM) format. Images are stored in the PACS <NUM> by healthcare practitioners (e.g., imaging technicians, physicians, radiologists) after a medical imaging of a patient and/or are automatically transmitted from medical imaging devices to the PACS <NUM> for storage. In some examples, the PACS <NUM> can also include a display device and/or viewing workstation to enable a healthcare practitioner or provider to communicate with the PACS <NUM>.

In the illustrated example of <FIG>, the interface unit <NUM> includes a HIS interface connection <NUM>, a RIS interface connection <NUM>, a PACS interface connection <NUM>, and a data center interface connection <NUM>. The example interface unit <NUM> facilities communication among the HIS <NUM>, the RIS <NUM>, the PACS <NUM>, and/or data center <NUM>. In the illustrated example, the interface connections <NUM>, <NUM>, <NUM>, <NUM> are implemented by a Wide Area Network (WAN) such as a private network or the Internet. Accordingly, the interface unit <NUM> includes one or more communication components such as, for example, an Ethernet device, an asynchronous transfer mode (ATM) device, an <NUM> device, a DSL modem, a cable modem, a cellular modem, etc. In turn, the data center <NUM> communicates with the workstation <NUM>, via a network <NUM>, implemented at a plurality of locations (e.g., a hospital, clinic, doctor's office, other medical office, or terminal, etc.). The network <NUM> is implemented by, for example, the Internet, an intranet, a private network, a wired or wireless Local Area Network, and/or a wired or wireless Wide Area Network. In some examples, the interface unit <NUM> also includes a broker (e.g., a Mitra Imaging's PACS Broker) to allow medical information and medical images to be transmitted together and stored together.

In the illustrated example, the interface unit <NUM> receives images, medical reports, administrative information, exam workload distribution information, and/or other clinical information from the information systems <NUM>, <NUM>, <NUM> via the corresponding interface connections <NUM>, <NUM>, <NUM>. If necessary (e.g., when different formats of the received information are incompatible), the interface unit <NUM> translates or reformats (e.g., into Structured Query Language ("SQL") or standard text) the medical information, such as medical reports, to be properly stored at the data center <NUM>. The reformatted medical information can be transmitted using a transmission protocol to enable different medical information to share common identification elements, such as a patient name or social security number. Next, the interface unit <NUM> transmits the medical information to the data center <NUM> via the data center interface connection <NUM>. Finally, medical information is stored in the data center <NUM> in, for example, the DICOM format, which enables medical images and corresponding medical information to be transmitted and stored together.

The medical information is later viewable and easily retrievable at the workstation <NUM> (e.g., by their common identification element, such as a patient name or record number). The workstation <NUM> can be any equipment (e.g., a personal computer) capable of executing software that permits electronic data (e.g., medical reports) and/or electronic medical images (e.g., x-rays, ultrasounds, MRI scans, etc.) to be acquired, stored, or transmitted for viewing and operation. The example workstation <NUM> of <FIG> receives commands and/or other input from a user via, for example, a keyboard, mouse, track ball, microphone, etc. The workstation <NUM> is capable of implementing a user interface <NUM> to enable a healthcare practitioner and/or administrator to interact with the healthcare information system <NUM>. For example, in response to a request from a physician, the user interface <NUM> presents a patient medical history. In other examples, a radiologist is able to retrieve and manage a workload of exams distributed for review to the radiologist via the user interface <NUM>. In further examples, an administrator reviews radiologist workloads, exam allocation, and/or operational statistics associated with the distribution of exams via the user interface <NUM>. In some examples, the administrator adjusts one or more settings or outcomes via the user interface <NUM>.

The example data center <NUM> of <FIG> is an archive to store information such as images, data, medical reports, and/or, more generally, patient medical records. In addition, the data center <NUM> can also serve as a central conduit to information located at other sources such as, for example, local archives, hospital information systems/radiology information systems (e.g., the HIS <NUM> and/or the RIS <NUM>), or medical imaging/storage systems (e.g., the PACS <NUM> and/or connected imaging modalities). That is, the data center <NUM> can store links or indicators (e.g., identification numbers, patient names, or record numbers) to information. In the illustrated example, the data center <NUM> is managed by an application server provider (ASP) and is located in a centralized location that can be accessed by a plurality of systems and facilities (e.g., hospitals, clinics, doctor's offices, other medical offices, and/or terminals). In some examples, the data center <NUM> can be spatially distant from the HIS <NUM>, the RIS <NUM>, and/or the PACS <NUM>.

In the illustrated example, the example data center <NUM> of <FIG> includes a server <NUM>, a database <NUM>, and a record organizer <NUM>. The server <NUM> receives, processes, and conveys information to and from the components of the healthcare information system <NUM>. The database <NUM> stores the medical information described herein and provides access thereto. The example record organizer <NUM> of <FIG> manages patient medical histories, for example. The record organizer <NUM> can also assist in procedure scheduling, for example.

Certain examples can be implemented as cloud-based clinical information systems and associated methods of use. An example cloud-based clinical information system enables healthcare entities (e.g., patients, clinicians, sites, groups, communities, and/or other entities) to share information via web-based applications, cloud storage and cloud services. For example, the cloud-based clinical information system may enable a first clinician to securely upload information into the cloud-based clinical information system to allow a second clinician to view and/or download the information via a web application. Thus, for example, the first clinician may upload an x-ray image into the cloud-based clinical information system, and the second clinician may view the x-ray image via a web browser and/or download the x-ray image onto a local information system employed by the second clinician.

In certain examples, users (e.g., a patient and/or care provider) can access functionality provided by the healthcare information system <NUM> via a software-as-a-service (SaaS) implementation over a cloud or other computer network, for example. In certain examples, all or part of the healthcare information system <NUM> can also be provided via platform as a service (PaaS), infrastructure as a service (IaaS), etc. For example, the healthcare information system <NUM> can be implemented as a cloud-delivered Mobile Computing Integration Platform as a Service. A set of consumer-facing Web-based, mobile, and/or other applications enable users to interact with the PaaS, for example.

The Internet of things (also referred to as the "Industrial Internet") relates to an interconnection between a device that can use an Internet connection to talk (e.g., communicate) with other devices on the network. Using the connection, devices can communicate to trigger events/actions (e.g., changing temperature, turning on/off, providing a status, etc.). In certain examples, machines can be merged with "big data" to improve efficiency and operations, providing improved data mining, facilitate better operation, etc..

Big data can refer to a collection of data so large and complex that it becomes difficult to process using traditional data processing tools/methods. Challenges associated with a large data set include data capture, sorting, storage, search, transfer, analysis, and visualization. A trend toward larger data sets is due at least in part to additional information derivable from analysis of a single large set of data, rather than analysis of a plurality of separate, smaller data sets. By analyzing a single large data set, correlations can be found in the data, and data quality can be evaluated.

<FIG> illustrates an example industrial internet configuration <NUM>. The example industrial internet configuration <NUM> includes a plurality of health-related assets <NUM>-<NUM> (sometimes referred to herein as health-focused systems or infrastructures) (e.g., information systems, imaging modalities, etc.), such as a plurality of health information systems <NUM> (e.g., PACS, RIS, EMR, etc.) communicating via the industrial internet configuration <NUM>. The example industrial internet configuration <NUM> of <FIG> includes a plurality of health-related assets <NUM>-<NUM> communicating with a server <NUM> and an associated data store <NUM> via a cloud <NUM>.

As shown in the example of <FIG>, a plurality of health-related assets <NUM>-<NUM> can access the cloud <NUM>, which connects the assets <NUM>-<NUM> with the server <NUM> and the associated data store <NUM>. Information systems, for example, include communication interfaces to exchange information with the server <NUM> and the data store <NUM> via the cloud <NUM>. Other assets, such as medical imaging scanners, patient monitors, etc., can be outfitted with sensors and communication interfaces to enable them to communicate with each other and with the server <NUM> via the cloud <NUM>.

Thus, the example health-related assets <NUM>-<NUM> within the industrial internet configuration <NUM> become "intelligent" as a network with advanced sensors, controls, analytical-based decision support and hosting software applications. Using such an infrastructure, advanced analytics can be provided to associated data. The analytics combines physics-based analytics, predictive algorithms, automation, and deep domain expertise. Via the example cloud <NUM>, the health-related assets <NUM>-<NUM> and associated people can be connected to support more intelligent design, operations, maintenance, and higher server quality and safety, for example.

Using the industrial internet infrastructure, for example, a proprietary machine data stream can be extracted from the asset <NUM>. Machine-based algorithms and data analysis are applied to the extracted data. Data visualization can be remote, centralized, etc. Data is then shared with authorized users, and any gathered and/or gleaned intelligence is fed back into the assets <NUM>-<NUM>.

Imaging informatics includes determining how to tag and index a large amount of data acquired in diagnostic imaging in a logical, structured, and machine-readable format. By structuring data logically, information can be discovered and utilized by algorithms that represent clinical pathways and decision support systems. Data mining can be used to help ensure patient safety, reduce disparity in treatment, provide clinical decision support, etc. Mining both structured and unstructured data from radiology reports, as well as actual image pixel data, can be used to tag and index both imaging reports and the associated images themselves.

Clinical workflows are typically defined to include one or more steps or actions to be taken in response to one or more events and/or according to a schedule. Events may include receiving a healthcare message associated with one or more aspects of a clinical record, opening a record(s) for new patient(s), receiving a transferred patient, reviewing and reporting on an image, and/or any other instance and/or situation that requires or dictates responsive action or processing. The actions or steps of a clinical workflow may include placing an order for one or more clinical tests, scheduling a procedure, requesting certain information to supplement a received healthcare record, retrieving additional information associated with a patient, providing instructions to a patient and/or a healthcare practitioner associated with the treatment of the patient, radiology image reading, and/or any other action useful in processing healthcare information. The defined clinical workflows may include manual actions or steps to be taken by, for example, an administrator or practitioner, electronic actions or steps to be taken by a system or device, and/or a combination of manual and electronic action(s) or step(s). While one entity of a healthcare enterprise may define a clinical workflow for a certain event in a first manner, a second entity of the healthcare enterprise may define a clinical workflow of that event in a second, different manner. In some examples, different healthcare entities may treat or respond to the same event or circumstance in different fashions. Differences in workflow approaches may arise from varying preferences, capabilities, requirements or obligations, standards, protocols, etc. among the different healthcare entities.

In certain examples, a medical exam conducted on a patient can involve review by a healthcare practitioner, such as a radiologist, to obtain, for example, diagnostic information from the exam. In a hospital setting, medical exams can be ordered for a plurality of patients, all of which require review by an examining practitioner. Each exam has associated attributes, such as a modality, a part of the human body under exam, and/or an exam priority level related to a patient criticality level. Hospital administrators, in managing distribution of exams for review by practitioners, can consider the exam attributes as well as staff availability, staff credentials, and/or institutional factors such as service level agreements and/or overhead costs.

Additional workflows can be facilitated such as bill processing, revenue cycle management, population health management, patient identity, consent management, etc..

The foregoing systems and methods can be deployed to provide real-time location services. Real-time location services (RTLS) facilitate tracking people and assets in an industrial setting, such as a hospital. The example RTLS system described herein is designed to create location awareness of assets by capturing location and proximity information from beacon tags installed throughout the hospital. Examples disclosed herein utilize reader badges worn by healthcare workers (e.g., doctors, nurses, administrators, janitors, etc.) that receive beacon messages from beacon tags that are installed in and/or affixed to assets such as hallways, rooms, equipment, patients, etc. for which location and/or proximity information is to be collected between the beacon tags and the tagged asset. For example, the beacon tags may broadcast beacon messages including a unique identifier (e.g., a signature, a MAC address, a serial number, etc.) associated with the corresponding beacon tags. As the healthcare workers walk around the hospital, their reader badges collect beacon messages transmitted from beacon tags throughout the hospital. In some disclosed examples, the reader badges aggregate the beacon messages and transmit a batch of beacon messages to an RTLS server for processing. The example RTLS server disclosed herein processes the beacon messages to create location awareness through proximity and probability.

In some disclosed examples, beacon tags are installed in and/or attached to fixed-location (e.g., placed on stationary (or near stationary)) assets. For example, some "known location" beacon tags may be affixed to hallways, doors, windows, sinks, etc. As disclosed below, in some examples, the RTLS server utilizes the beacon messages received from "known location" beacon tags to determine a location for the reader badge.

In some disclosed examples, beacon tags are affixed to mobile assets such as equipment. For example, some "mobile location" beacon tags may be affixed to beds, wheelchairs, patients, etc. As disclosed below, in some examples, the RTLS server utilizes the beacon messages received from the "mobile location" beacon tags to determine what assets are near the corresponding reader badges (e.g., the reader badge that aggregated and transmitted a batch of beacon messages).

In addition, comparing the asset locations during different timestamp intervals may be useful in determining how the assets were moved and/or when caregivers interacted with the assets. For example, consider an example in which a wheelchair (e.g., a mobile-location asset) is located in a first patient room. In the illustrated example, assume that the wheelchair is affixed with a mobile-location asset beacon tag and that the first patient room is affixed with a fixed-location asset beacon tag. In the illustrated example, when a caregiver wearing a reader badge walks into the first patient room, their reader badge collects beacon messages broadcast by the wheelchair beacon tag and the first patient room beacon tag. In the illustrated example, the caregiver location is assigned to the first patient room based on the beacon messages broadcast by the first patient room beacon tag. In addition, since the wheelchair is "seen" in the same location, the wheelchair location may also be updated to the first patient room.

In the illustrated example, while the caregiver is in the first patient room, their reader badge collects beacon messages broadcast by the wheelchair beacon tag and the first patient room beacon tag. If the caregiver begins moving the wheelchair (e.g., from the first patient room to a second patient room), their reader badge will continue to collect beacon tags broadcast by the first patient room badge tag, but will also begin collecting beacon messages broadcast by a second patient room beacon tag. In the illustrated example, once the caregiver enters the second patient room, the caregiver location is updated to the second patient room. Additionally, in the illustrated example, since the wheelchair is still "seen" by the caregiver (e.g., the wheelchair location is determined to be proximate to the caregiver), the location of the wheelchair is also updated to the second patient room.

In the illustrated example, after the wheelchair is moved from the first patient room to the second patient room, confidence that the wheelchair is located in the second patient room rather than the first patient room may be low. However, in the illustrated example, each time a caregiver walks into the first patient room and does not "see" the wheelchair, confidence that the wheelchair is located in the first patient room decreases. Additionally, in the illustrated example, each time a caregiver walks into the second patient room and does "see" the wheelchair, confidence that the wheelchair is located in the second patient room increases. In the illustrated example, the "crowd" (e.g., the caregivers) provides different snapshots of what is "seen" at different locations and at different times. As disclosed herein, an RTLS server may analyze the different snapshots to facilitate proximity detection and location tracking of assets in an environment.

Referring to <FIG>, an example environment <NUM> in which examples disclosed herein may be implemented to facilitate proximity detection and location tracking using a mobile wireless bridge is illustrated. The example environment <NUM> of <FIG> includes example beacon tags <NUM>, an example reader badge <NUM> and an example real-time locations services (RTLS) server <NUM>.

In the illustrated example of <FIG>, the beacon tags <NUM> are implemented using low-power BLE transmitters and include a single coin-cell battery. In some examples, the single coin-cell battery provides power to the corresponding beacon tag <NUM> for two or more years. In the illustrated example, beacon tags <NUM> are installed throughout the environment <NUM> on two types of assets. For example, one or more beacon tag(s) <NUM> may be located on (e.g., affixed to) fixed-location assets such as doors, rooms, hallways, water fountains, etc. In addition, one or more beacon tag(s) <NUM> may be located on (e.g., affixed to) mobile-location assets such as patients (e.g., inserted within a patient tag), beds, IV pumps, wheelchairs, etc. Although the illustrated example of <FIG> includes only two beacon tags <NUM>, other environments are likely to include additional beacon tags. For example, different environments may include tens, hundreds and/or thousands of beacon tags affixed to assets. In general, accuracy of the proximity detection and location tracking of assets in an environment is increased and/or decreased based on adding or reducing the number of beacon tags placed in the environment.

In the illustrated example of <FIG>, the example beacon tags <NUM> periodically advertise their presence in the environment <NUM>. For example, the beacon tags <NUM> may broadcast example beacon messages <NUM> every one second. In other examples, the beacon tags <NUM> may broadcast beacon messages <NUM> aperiodically and/or as a one-time event. In some examples, the beacon tags <NUM> may broadcast beacon messages <NUM> at different time intervals. For example, beacon tags <NUM> located on fixed-location assets may broadcast beacon messages <NUM> every two seconds, while beacon tags <NUM> located on mobile-location assets may broadcast beacon messages <NUM> every second. In some examples, beacon tags located on mobile-locations assets may broadcast beacon messages <NUM> at a first frequency (e.g., once every second) while the mobile-location asset is stationary and may broadcast beacon messages <NUM> at a second frequency (e.g., once every half-second) while the mobile-location asset is moving. However, other time intervals may additionally or alternatively be used.

In the illustrated example, the beacon messages <NUM> include tag identifying information <NUM> and tag-type identifying information <NUM>. For example, tag identifying information <NUM> may be a unique identifier of the beacon tag <NUM> such as a MAC address, a serial number, an alphanumeric signature, etc. The example tag-type identifying information <NUM> identifies whether the beacon tag <NUM> broadcasting the beacon message <NUM> is affixed to a fixed-location asset or affixed to a mobile-location asset. However, the beacon messages <NUM> may include additional or alternative information. For example, the beacon messages <NUM> may include information identifying the software version being executed by the beacon tags <NUM>, may include information identifying a power level of the beacon tag <NUM>, etc..

In the illustrated example of <FIG>, the beacon messages <NUM> are received by the reader badge <NUM>. In the illustrated example, the reader badge <NUM> is worn by a hospital caregiver <NUM> such as a doctor, a nurse, etc. As the hospital caregiver moves through the hospital, the reader badge <NUM> collects beacon messages <NUM> broadcast by the beacon tags <NUM>. For example, while the hospital worker <NUM> is visiting a patient in an example patient room #<NUM>, the example reader badge <NUM> may collect one or more beacon message(s) from a fixed-location asset beacon tag located on a door of the patient room #<NUM>, one or more beacon message(s) from a fixed-location asset beacon tag located on a sink in the patient room #<NUM>, one or more beacon message(s) from a mobile-location asset beacon tag located on the patient's identification tag, one or more beacon message(s) from a mobile-location asset beacon tag located on a bed in the patient room #<NUM>, etc..

In the illustrated example of <FIG>, the reader badge <NUM> generates example reader messages <NUM> in response to receiving the beacon messages <NUM>. For example, the reader badge <NUM> may create a reader message <NUM> including the tag identifying information <NUM> and the tag-type identifying information <NUM> included in the beacon message <NUM> and append example badge identifying information <NUM>, an example timestamp <NUM>, example signal strength information <NUM>, and example channel identifying information <NUM>. In the illustrated example, the badge identifying information <NUM> is a string of alphanumeric characters that uniquely identifies the reader badge <NUM> (e.g., a MAC address, a serial number, an alphanumeric signature, etc.). The example timestamp <NUM> identifies a date and/or time (e.g., January <NUM>, <NUM>, <NUM>:<NUM>:<NUM> pm) when the beacon message <NUM> was received by the reader badge <NUM>. The example signal strength information <NUM> identifies signal strength of the beacon message <NUM> when it was received by the reader badge <NUM> (e.g., a received signal strength indication (RSSI) value). The example channel identifying information <NUM> identifies a channel on which the beacon message <NUM> was received (e.g., a Bluetooth frequency channel such as channel <NUM>, channel <NUM> or channel <NUM>).

In the illustrated example of <FIG>, the reader badge <NUM> periodically communicates a group (e.g., a batch) of reader messages <NUM> to the RTLS server <NUM>. For example, the reader badge <NUM> may transmit one or more reader messages <NUM> that were collected over a period of time (e.g., thirty seconds). Additionally or alternatively, the reader badge <NUM> may communicate one or more reader message(s) <NUM> aperiodically and/or as a one-time event. For example, the reader badge <NUM> may collect a threshold number of reader messages <NUM> prior to transmitting the collected reader messages <NUM> to the RTLS server <NUM>. In some examples, the reader badge <NUM> transmits the reader messages <NUM> as they are created by the reader badge <NUM>.

In the illustrated example of <FIG>, the RTLS server <NUM> is a server and/or database that facilitates proximity detection and location tracking. In some examples, the RTLS server <NUM> is implemented using multiple devices. For example, the RTLS server <NUM> may include disk arrays or multiple workstations (e.g., desktop computers, workstation servers, laptops, etc.) in communication with one another.

In the illustrated example, the RTLS server <NUM> is in communication with the reader badge <NUM> via one or more wireless networks represented by example network <NUM>. Example network <NUM> may be implemented using any suitable wireless network(s) including, for example, one or more data busses, one or more wireless Local Area Networks (LANs), one or more cellular networks, the Internet, etc. As used herein, the phrase "in communication," including variances thereof (e.g., communicates, in communication with, etc.), encompasses direct communication and/or indirect communication through one or more intermediary components and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes communication at periodic or aperiodic intervals, as well as one-time events.

In the illustrated example of <FIG>, the RTLS server <NUM> utilizes the reader messages <NUM> to facilitate proximity detection and location tracking of assets in the environment <NUM>. In the illustrated example, the RTLS server <NUM> selects a portion of reader messages <NUM> received from the reader badge <NUM> to determine a location of the reader badge <NUM>. For example, the RTLS server <NUM> may process the reader messages <NUM> to identify a first subset of reader messages <NUM> (e.g., one or more reader messages) that were received by the reader badge <NUM> during a first window of interest (e.g., a five second window) and that were fixed-location asset tag type (e.g., based on the tag-type information <NUM> included in the first subset of reader messages). In the illustrated example of <FIG>, the RTLS server <NUM> utilizes the signal strength information <NUM> included in the first subset of reader messages <NUM> to determine a nearest fixed-location asset. For example, a relatively stronger RSSI value may indicate that the broadcasting beacon tag <NUM> is closer in proximity to the reader badge <NUM> than a beacon tag <NUM> associated with a relatively weaker RSSI value. In the illustrated example of <FIG>, the RTLS server <NUM> updates the location of the reader badge <NUM> based on the nearest fixed-location asset.

In the illustrated example of <FIG>, once the RTLS server <NUM> associates the reader badge <NUM> with a location (e.g., the location of the nearest fixed-location asset), the RTLS server <NUM> identifies a second subset of reader messages <NUM> (e.g., one or more reader messages) that were received by the reader badge <NUM> during the first window of interest (e.g., a five second window) and that were mobile-location asset tag type (e.g., based on the tag-type information <NUM> included in the second subset of reader messages <NUM>). For example, the RTLS server <NUM> may update the location of a mobile-location asset based on its proximity to the reader badge <NUM>.

In the illustrated example of <FIG>, the RTLS server <NUM> selects a reader message of the second subset of reader messages <NUM> and classifies the corresponding mobile-location assets relative location to the reader badge <NUM> based on the RSSI value <NUM> included in the selected reader badge <NUM>. For example, the RTLS server <NUM> classifies mobile-location asset as relatively-far assets when the signal strength information <NUM> satisfies a first threshold (e.g., the RSSI value is less than (-<NUM>) decibels). The example RTLS server <NUM> of <FIG> classifies mobile-location assets as relatively-immediate assets when the signal strength information <NUM> satisfies a second threshold (e.g., the RSSI value is greater than (-<NUM>) decibels). In the illustrated example of <FIG>, the RTLS server <NUM> classifies mobile-location assets as relatively-near assets when the signal strength information <NUM> does not satisfy the first threshold and the second threshold. For example, the RTLS server <NUM> may classify mobile-location assets as relatively-near assets when the RSSI value is less than (-<NUM>) decibels and greater than (-<NUM>) decibels.

In the illustrated of <FIG>, depending on the relative location classifications, the RTLS server <NUM> updates the location of the mobile-location asset and/or updates an asset-location confidence score associated with the mobile-location asset. In the illustrated example, the asset-location confidence score represents a probability (or likelihood) that a mobile-location asset may be found at the currently assigned asset-location. For example, when a mobile-location asset is "seen" in the same location, the RTLS server <NUM> increases the asset-location confidence score of the mobile-location asset. When the mobile-location asset is "seen" in a different location, the RTLS server <NUM> decreases the asset-location confidence score of the mobile-location asset. Additionally, when the asset-location confidence score fails to satisfy a location threshold (e.g., is less than a location threshold), the asset-location of the mobile-location asset may be updated based on, for example, the location of the reader badge <NUM> that collected the beacon message <NUM> emitted from the mobile-location asset (e.g., by the beacon tag <NUM> affixed to the mobile-location asset).

In the illustrated example, when a mobile-location asset is classified as relatively-far, the example RTLS server <NUM> of <FIG> discards the reader message <NUM> and the RTLS server <NUM> makes not change to the location of the mobile-location asset and/or the asset-location confidence score associated with the mobile-location asset. For example, the reader badge <NUM> may have collected a relatively weak beacon message emitted from a mobile-location asset passing through the hallway outside of the patient room #<NUM>. In some examples, the reader badge <NUM> may filter such beacon messages (e.g., beacon messages <NUM> that are associated with weak (e.g., low) RSSI values) rather than communicate the weak beacon messages to the RTLS server <NUM>.

When a mobile-location asset is classified as a relatively-immediate asset, high signal strength (e.g., an RSSI value greater than (-<NUM>) decibels) may be indicative of a mobile-location asset that is in-front of the hospital worker <NUM>, is being used by the hospital worker <NUM> and/or is being moved by the hospital worker <NUM>. In some such instances, the location of the mobile-location asset may be assumed to be the same as the location of the reader badge <NUM>. In the illustrated example, the example RTLS server <NUM> of <FIG> updates the location of the mobile-location asset to the location of the reader badge <NUM>. In addition, the example RTLS server <NUM> increments the asset-location confidence score of the mobile-location asset (e.g., the probability of the mobile-location asset being located at the updated asset-location is increased). In some examples, if the beacon tag <NUM> is relatively-immediate to the reader badge <NUM>, an assumption may be made that the caregiver is interacting with the corresponding assets. For example, the caregiver may be pushing a patient in a wheelchair.

In the illustrated example of <FIG>, when a mobile-location asset is classified as a relatively-near asset (e.g., is associated with a medium signal strength), the example RTLS server <NUM> of <FIG> compares the current location associated with the mobile-location asset to the location of the reader badge <NUM>. In the illustrated example, the RTLS server <NUM> increases the asset-location confidence score of the mobile-location asset when the current asset-location is the same as the location of the reader badge <NUM>. For example, the mobile-location asset is "seen" in the same location as it is currently assigned. In some examples when the current asset-location is not the same as the location of the reader badge <NUM>, the example RTLS server <NUM> decreases the asset-location confidence score of the mobile-location asset. In addition, the example RTLS server <NUM> compares the asset-location confidence score of the mobile-location asset to a location threshold and, when the asset-location confidence score fails to satisfy the location threshold (e.g., is less than the location threshold), the RTLS server <NUM> updates the asset-location of the mobile-location asset to the location of the reader badge <NUM> that received the corresponding beacon message <NUM>.

In the illustrated example of <FIG>, the example environment <NUM> includes an example dock module <NUM>. The example dock module <NUM> may be used to charge one or more reader badges <NUM>. In some examples, the dock module <NUM> receives beacon messages <NUM> from beacon tags <NUM> and/or transmits reader messages <NUM> to the RTLS server <NUM>.

<FIG> illustrates various components included in an example beacon tag <NUM>, an example beacon badge <NUM>, an example hub module <NUM> and example dock module <NUM>. For example, the beacon tag <NUM> includes one or more BLE chips (labeled "Beacon") <NUM> to transmit beacon messages <NUM>, one or more power sources <NUM> (e.g., one or more coin-cell batteries) and a system-on-a-chip (SOC) <NUM> to manage the one or more BLE chips <NUM> and the one or more power sources <NUM>. The example beacon badge <NUM> includes one or more BLE chips <NUM> (labeled "transceiver") to receive beacon messages 406a -409a, one or more Wi-Fi chips <NUM> to communicate with a wireless network (e.g., the example network <NUM>), one or more power sources (e.g., one or more batteries) <NUM>, one or more sensors <NUM> (e.g., a motion sensor, an accelerometer, a gyroscope, etc.) and a system-on-a-chip (SOC) <NUM> to manage the one or more BLE chips <NUM>, the one or more Wi-Fi chips <NUM>, the one or more power sources <NUM> and the one or more sensors <NUM>. The example beacon badge <NUM> also includes an example module connector <NUM> to connect the beacon badge <NUM> to the example hub module <NUM> and/or the dock module <NUM>.

In the illustrated example of <FIG>, the beacon badge <NUM> is connectable to the example hub module <NUM>. The connection between the beacon badge <NUM> and the hub module <NUM> may include a mechanical connection, an electrical connection, or combinations thereof. In the illustrated example, the hub module <NUM> may be used to track asset interactions with fixed locations. In a healthcare environment, examples of fixed locations include soap dispensers, beds, walls, equipment, etc. In other environments, such as a retail environment, fixed locations may include wall sconces, light fixtures, mirrors, shelving, and other such fixed locations.

The hub module <NUM> may be leveraged to identify particular locations. As an example, the beacon badge <NUM> may be coupled, via a badge connection <NUM>, to a hub module <NUM> placed on an entrance to a restricted area to identify when a person wearing a beacon tag <NUM> enters (or approaches) the restricted area. In one embodiment, the hub module <NUM> includes a system-on-a-chip (SOC) <NUM> to manage components of the hub module <NUM>, one or more power sources <NUM> (e.g., one or more batteries and an external power source (e.g., an AC/DC connection)) to extend the battery life and capabilities of the beacon badge <NUM>, one or more sensors <NUM> communicatively coupled to the SOC <NUM>, and a badge connection <NUM> for connecting the beacon badge <NUM> to the hub module <NUM>.

In the illustrated example, the beacon badge <NUM> may be connectable (e.g., mechanically coupled, electronically coupled, etc.) to the example dock module <NUM>. In the illustrated example, the dock module <NUM> may be used to charge one or more beacon badges <NUM>. Accordingly, and in one embodiment, the dock module <NUM> includes an external power connector <NUM> (e.g., an AC connector), a charging indicator <NUM> to indicate whether the beacon badge <NUM> is charged or charging, and a badge connection <NUM> for connecting the beacon badge <NUM> to the dock module <NUM>. In one embodiment, the dock module <NUM> is portable. For example, the dock module <NUM> may be placed throughout one or more environments, such as at cash registers, podiums, counters, nursing stations, break rooms, hallways, etc., and a caregiver may couple their beacon badge <NUM> to the dock module <NUM>, via a badge connection <NUM>, when they are off-duty.

<FIG> illustrates an example environment <NUM> illustrating interaction between premises <NUM>, <NUM> via a cloud <NUM>. In the example of <FIG>, one or more fixed beacons <NUM> and one or more mobile beacons <NUM> are positioned in a facility <NUM> (e.g., a hospital, clinic, etc.). The beacons <NUM>, <NUM> are affixed (e.g., permanently affixed, removably affixed, etc.) to locations, assets, etc. For example, the fixed beacon <NUM> can be mounted on a wall at a location in the facility <NUM> at which asset(s) may be located to provide a location to a receiver. The mobile beacon <NUM> can be affixed (e.g., permanently, removably, etc.) to an item to be located and tracked (e.g., an intravenous (IV) pump, imaging scanner (e.g., x-ray, CT, ultrasound, etc.), crash cart, lab cart, etc.), for example.

The beacons <NUM>, <NUM> are detected and read (e.g., via Bluetooth™, Bluetooth Low Energy (BLE), near field communication (NFC), etc.) by one or more mobile receivers <NUM> and/or fixed receivers <NUM>, for example. For example, the mobile receiver <NUM> includes logic to process its location (e.g., with respect to the fixed beacon <NUM>, etc.). The mobile receiver <NUM> can be worn by a person and/or mobile asset to create a crowdsourced environment in which the mobile receiver <NUM> interacts with beacons <NUM>, <NUM> and informs the system <NUM> of the receiver <NUM> location and presence of beacon(s) <NUM>, <NUM> within range of the location, for example. The fixed receiver <NUM> is configured with its location in the facility <NUM>. The fixed receiver <NUM> can be mounted on a wall in a location where crowdsourcing is reduced (e.g., storage locations, enclosed locations, etc.) to interact with beacons <NUM>, <NUM> and inform the system <NUM> of the receiver <NUM> location and presence of beacon(s) <NUM>, <NUM> within range of the location, for example. The mobile receiver(s) <NUM> and fixed receiver(s) <NUM> process which asset(s) are located within range (e.g., as indicated mobile beacon(s) <NUM> and/or fixed beacon(s) <NUM>, etc.) and notify other component(s) of the system <NUM>.

The receiver(s) <NUM>, <NUM> communicate over a channel <NUM>, such as Wi-Fi, etc., with a middleware gateway <NUM> to transmit information regarding beacon <NUM>, <NUM> location to a middleware engine <NUM>. The middleware gateway <NUM> can be an edge device, gateway device, hub, and/or other electronic device to interface between the premises <NUM> and the cloud <NUM>, for example. The middleware engine <NUM> can reside on the cloud <NUM> to process received beacon <NUM>, <NUM> and receiver <NUM>, <NUM> data and calculate location information. The middleware engine <NUM> can also publish location events to one or more receiving/subscribing recipients, for example.

For example, one or more consuming applications <NUM> access location data from the middleware engine <NUM> via the cloud <NUM> to leverage the location data for scheduling, tracking, (re)ordering, maintenance, billing, protocol compliance, treatment evaluation, employee evaluation, resource evaluation, and/or other resource management application(s), etc. Alternatively or in addition, an application programming interface (API) <NUM> provides location awareness data for consumption by one or more hospital applications <NUM>-<NUM> at a second facility (e.g., hospital, clinic, etc.) <NUM>. For example, a hospital computerized maintenance management system (CMMS) <NUM>, a hospital bed management system <NUM>, and/or other hospital system <NUM>, hospital application <NUM>, etc., can receive and process asset location information via the API <NUM>.

<FIG> illustrates an example architecture <NUM> of the hospital network <NUM> and the cloud <NUM> of <FIG>. As shown in the example of <FIG>, the hospital network <NUM> communicates with the cloud <NUM> via the middleware or location gateway <NUM>, which can be divided (as shown in the example of <FIG>) into a client location gateway 618a and a server location gateway 618b. The example hospital network <NUM> includes a badge configuration tool <NUM> used to configure a badge <NUM> (e.g., a hospital staff badge, smart phone, etc.) for one or more parameters such as WiFi network, gateway connectivity, gateway security credential/certificate, etc. The tool <NUM> can communicate with the badge <NUM> via WiFi, Bluetooth, NFC, etc. Further, the badge <NUM> communicates with the client location gateway 618a to provide location information to the cloud <NUM>.

Additionally, firmware <NUM> can communicate with the badge <NUM> to update firmware, settings, etc., on the badge <NUM>. The example firmware <NUM> can provide and/or be associated with a software development kit (SDK) to enable integration of application(s) into the badge <NUM>, for example. Using the SDK, the firmware <NUM> can provide notifications, offers, and/or other customizations to the badge <NUM> and/or a user/wearer of the badge <NUM>, for example.

The example hospital network <NUM> of <FIG> also includes a location toolbox application <NUM>, which communicates with a beacon <NUM> (e.g., a Bluetooth beacon, BLE beacon, etc.) and/or a hub <NUM> (e.g., via Bluetooth, BLE, etc.). The beacon <NUM> and/or hub <NUM> can also communicate with the badge <NUM> and/or the client location gateway 618a, for example. The toolbox <NUM> provides configuration and/or authorization application(s), setting(s), configuration(s), etc., for the hub <NUM>, badge <NUM>, and/or beacon <NUM>, etc. For example, the toolbox <NUM> can be used to set beaconing frequency, beacon range, beacon transmission mode, etc. The toolbox <NUM>, beacon <NUM>, and/or badge <NUM> can communicate via the hub <NUM> with the client location gateway 618a, etc..

The example hospital network <NUM> of <FIG> can also include a passive reader <NUM>, access point <NUM>, and passive tag <NUM>. The WiFi access point <NUM> helps relay locating information by presence (e.g., in the facility <NUM>), zone (e.g., in a particular area of the facility <NUM>), location (e.g., actual location), etc. The passive tag <NUM> and passive reader <NUM> can interact to provide location information in the hospital network <NUM> to the client location gateway 618a, for example.

The client location gateway 618a communicates with the server location gateway 618b at the cloud <NUM>. The client location gateway 618a also communicates with a middleware engine <NUM> such as a locationing server <NUM>. The example server <NUM> provides a plurality of features including a management user interface (UI), a system health monitor, configuration information, insights/analytics, etc. The example server <NUM> communicates with beacon/site management services <NUM> and a site builder <NUM>, which helps to map out a location (e.g., the hospital network <NUM>, etc.) and beacons found at the location.

Using a service bus <NUM>, the server location gateway 618b, beacon/site management services <NUM>, and/or the site builder <NUM> can communicate with a geographic information system (GIS) <NUM> to create map(s) of the facility <NUM> to be stored using georeferenced location coordinates, for example. Fixed receivers placed in the facility <NUM> can be identified and added to the map using the site builder <NUM> and GIS <NUM>. A location engine <NUM> can be used to leverage the map(s) and geographic information to associate location(s) with detected beacon events to derive a location for a particular asset, for example. Using the GIS <NUM> and site builder <NUM>, maps can be modified/updated in real time (or substantially real time given some data processing, transmission, and/or storage latency, etc.) to make fast, fluid changes based on incoming data, for example. The GIS <NUM> provides spatial context to the inside of the facility <NUM> mapped by the site builder <NUM>, for example. Using the GIS <NUM> platform, distance(s) between objects can be derived and georeferenced coordinates can be included. Information generated by the location engine <NUM> can be consumed by one or more products <NUM> including asset management <NUM>, hospital information system (HIS) <NUM>, and/or other third party system <NUM>, etc. Badge configuration services <NUM> can also help with badge configuration on the server/cloud side, helping to update the badge configuration tool <NUM> at the hospital <NUM>, for example.

Thus, certain examples provide systems and methods to monitor and manage badge(s), beacon(s), and receiver(s) and provide health statistics for such devices. Certain examples provide APIs that allow devices installed at a location to communicate status information to the cloud <NUM> infrastructure to be processed to display reports, analytics, facilitate interaction for repair/update, etc., to drive notifications, alerts, maintenance, etc., for system health and ongoing system operation. Certain examples facilitate monitoring and evaluation of network and system performance and retuning/reconfiguring/redefining desired network and/or system operation.

More generally, <FIG> illustrates a basic real time location platform <NUM> including a number of monitored devices <NUM>-<NUM> and an edge device <NUM> in a facility <NUM>, along with a cloud health processor <NUM> and management service(s) <NUM> in a cloud <NUM>. The monitored devices <NUM>-<NUM> can include one or more beacons, badges, and/or receivers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc. The edge device <NUM> can include the location gateway <NUM>, etc. The cloud health processor <NUM> can include the location server <NUM>, etc. The management services <NUM> can include beacon/site management services <NUM>, badge configuration services <NUM>, etc..

The cloud health processor <NUM> defines a mechanism and associated API specification by which location receivers <NUM>, <NUM>, <NUM> deployed as part of a real time location platform <NUM>, <NUM> can transmit system health information using an event-based messaging framework. The data/events provided can be captured and utilized to maintain the system <NUM>, <NUM> and help ensure optimal and/or otherwise improved performance.

In certain examples, given numerous dependencies, connectivity issues, and power concerns, the system <NUM> is configured such that the devices <NUM>-<NUM> self-report their health status and associated system events to the health processor <NUM> via the edge device <NUM> to help maintain a functional system <NUM>, <NUM>, <NUM>. For example, location devices <NUM>-<NUM> are designed to submit event data (e.g., JSON documents, and/or other format/protocol such as XML, CSV, HTTP, JMS, SMTP, etc.) via the edge device <NUM> to an interface (e.g., a RESTful service interface, etc.) at the health processor <NUM>.

A plurality of events can be defined. An event includes a set of base (e.g., header, etc.) attributes that are used for ongoing system health management. In addition, each event includes a details section in which attributes/data specific to an event type can be included. For example, numerous events can be defined, and these events can be sent in response to a specified condition (e.g., device regaining network connectivity, e.g., device placed on charger, e.g., device removed from charger, etc.) and/or on a time schedule that is configurable as part of the device profile. The following table provides some examples of receiver health-related events:.

Thus, each receiver transmits health/operating details to the processor <NUM> via the API (e.g., API <NUM>, etc.) when associated events are executed. In certain examples, a WiFi reconnect does not include a roaming and/or access point transition for a mobile receiver. In certain examples, a heartbeat timer restarts on device reboot. In certain examples, a heartbeat interval is set to be frequent enough to monitor temperature changes, eliminating a need for temperature threshold events, for example.

In certain examples, a service interface (e.g., API) specification can be provided, such as for a RESTful service, etc., used by device(s) <NUM>-<NUM> to post health events. The service interface can define a health API and/or a reference API that provides definition for location events, time, firmware updates, system health, receiver configuration, etc. For example, a location event request can be formatted as a JSON object to include a beacon MAC address, UUID, RSSI, battery life (e.g., percentage of battery life remaining, battery value, etc.), timestamp (e.g., a time at which the beacon event was received, etc.), receiver MAC address, etc. A get time request can be implemented as a JSON formatted object including a time, such as a UNIX time, POSIX time, Epoch time, UTC time, etc., for example. A firmware update can be implemented as a binary file providing an application/octet stream to a target device <NUM>-<NUM>, for example. A system health request can be implemented, for example, as a JSON formatted object including an event type, device MAC address, timestamp, firmware version, depth of discharge (e.g., percent of battery life remaining, etc.), temperature (e.g., device temperature in Fahrenheit, Celsius, etc.), details (e.g., any additional details provided for the event), etc. A receiver configuration request can be implemented, for example, as a JSON formatted object including a scan interval (e.g., a period of time for which received beacons are being evaluated to determine which beacons should be transmitted, etc.), a scan channel (e.g., BLE channel(s) on which the device should listen, etc.), heartbeat interval, WiFi transmission frequency, profile name/ID, beacon type, proximity range, RSSI low (e.g., weakest RSSI signal strength considered within the range that a beacon should be processed, etc.), RSSI high (e.g., strongest RSSI signal strength considered within the range that a beacon should be processed, etc.), beacon hit count (e.g., a number of beacon hits required to be received within a scan interval, etc.), scan retention interval (e.g., a number of scans that occur before results of a scan are stored for transmission, etc.), send closest only (e.g., if true, all beacons received within the given range will be transmitted by the device, else only the closest (e.g., highest RSSI value) beacon is to be transmitted, etc.), suppress repeats (e.g., if true, transmissions from the device will be suppressed if they are the same as the previous scan interval, etc.), time service URL (e.g., uniform resource locator exposing the time service, etc.), event service URL (e.g., uniform resource locator exposing the event service, etc.), firmware service URL (e.g., uniform resource locator exposing the firmware service, etc.), firmware filename, etc..

The quality of location data provided by the real time location platform <NUM>, <NUM> is dependent on the health of the devices deployed to receive sensory/location events. If the deployed devices are not functioning as intended, the location data produced by the system has the potential to be inaccurate/unreliable. To help ensure accurate location data, support system(s) and/or team(s) (e.g., health processor <NUM> and management service <NUM>) must be able to monitor system health, isolate problematic devices and correct the problems through reconfiguration, replacement, upgrade, etc. Thus, certain examples provide a centralized health and monitoring capability for large scale systems that include many thousands of devices deployed in a wide range of environments. Without this system, deployed systems would fall into disrepair over time and/or the costs of monitoring/maintaining such systems would threaten the commercial viability of the dependent products. Certain examples monitor system health and provide maintenance/solutions to enable improved system performance, higher customer satisfaction, higher return on investment for a customer, lower cost of ownership for the customer, lower support costs for a supplier, increased profit margin for the supplier, etc..

<FIG> illustrates an example implementation of the cloud health processor <NUM>. In the example of <FIG>, the processor <NUM> includes a message receiver <NUM>, a message evaluator <NUM>, an event processor <NUM>, a health analyzer <NUM>, a health alert notifier <NUM>, and an output generator <NUM>.

The example message receiver <NUM> monitors for a message from a receiver (e.g., from one or more devices <NUM>-<NUM> including one or more beacons, badges, and/or receivers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.). When a message is received, the example message evaluator <NUM> evaluates the received message to determine a message type associated with the message (e.g., location message, firmware message, time message, receiver configuration message, health message, etc.). If the message is not a receiver health message, then, the message evaluator <NUM> sends the message to another processor, such as the location engine <NUM>, site builder <NUM>, consuming product(s) <NUM>, etc..

If the message is a health message, then the message evaluator <NUM> sends the message to the event processor <NUM>. The example event processor <NUM> processes the health message to identify an event type indicated by the message. For example, the message may indicate an on charge event, off charge event, forced reboot event, unforced reboot/system error event, WiFi reconnect event, heartbeat event, etc. Based on the event type, the event processor <NUM> processes the details of the event.

The event processor <NUM> provides the message details and event type to the health analyzer. Based on the event type, the example health analyzer <NUM> compares the details of the event to a threshold, range, standard, norm, etc. If the event is within normal or expected behavior, the event can be logged via the output generator <NUM>. If the event is outside the prescribed bound(s), the health alert notifier <NUM> can be triggered in response to the event. In some examples, the health alert notifier <NUM> can generate a response message or instruction to the device via the output generator <NUM> to adjust a level, setting, mode, etc., in response to the event (e.g., not charging enough, not charging properly, irregular heartbeat, reboot needed, etc.) such as to send a message to a user, automatically adjust a device setting, trigger a maintenance request, alert hospital staff to a failing device, change in setting/configuration warranted, etc. Thus, the output generator <NUM> can provide an update and/or other message to the device and/or a third party (e.g., beacon/site management services <NUM>, badge configuration services <NUM>, consuming product(s) <NUM>, etc.) to repair, replace, and/or adjust the affected device(s). An alert, update, and/or other message can be generated to help ensure reliable operation and uptime of the RTLS system <NUM>, <NUM>, for example.

While example implementations of the systems <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> are illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example components of <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example components of <FIG> can be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example components of <FIG> is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory (e.g., a read only memory (ROM), hard drive, flash memory, other volatile and/or non-volatile memory, etc.), a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware. Further still, the example systems of <FIG> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices.

A flowchart representative of example machine readable instructions for implementing the systems of <FIG> is shown in <FIG>. In these examples, the machine readable instructions comprise a program for execution by a processor such as the processor <NUM> shown in the example processor platform <NUM> discussed below in connection with <FIG>. The program may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor <NUM>, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example programs are described with reference to the flowchart illustrated in <FIG>, many other methods of implementing the example systems may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

As mentioned above, the example process(es) of <FIG> may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a ROM, a CD, a DVD, a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, "tangible computer readable storage medium" and "tangible machine readable storage medium" are used interchangeably. Additionally or alternatively, the example process(es) of <FIG> may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term "comprising" is open ended.

<FIG> illustrates a flow diagram of an example method <NUM> to monitor receiver and/or other device health in a real time location system. At block <NUM>, messages are monitored to detect a message from a receiver. For example, the example message receiver <NUM> monitors for a message from a receiver (e.g., from one or more devices <NUM>-<NUM> including one or more beacons, badges, and/or receivers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.). At block <NUM>, when a message is received, the message is evaluated to determine a message type. For example, the example message evaluator <NUM> evaluates the received message to determine a message type associated with the message (e.g., location message, firmware message, time message, receiver configuration message, health message, etc.). At block <NUM>, the message type is compared to a health message type. If the message is not a health message, then, at block <NUM>, the message is redirected for further processing. For example, the message is not a receiver health message, the message evaluator <NUM> sends the message to another processor, such as the location engine <NUM>, site builder <NUM>, consuming product(s) <NUM>, etc..

If the message is a health message, then, at block <NUM>, the health message is processed to identify an event type indicated by the health message. For example, the message evaluator <NUM> sends the message to the event processor <NUM>. The example event processor <NUM> processes the health message to identify an event type indicated by the message. For example, the message may indicate an on charge event, off charge event, forced reboot event, unforced reboot/system error event, WiFi reconnect event, heartbeat event, etc. At block <NUM>, based on the event type, the event processor <NUM> processes the details of the event. For example, the event processor <NUM> digests information associated with the event type and additional details if provided in the message.

At block <NUM>, the event is compared to prescribed bound(s) for the event. For example, the event processor <NUM> provides the message details and event type to the health analyzer. Based on the event type, the example health analyzer <NUM> compares the details of the event to a threshold, range, standard, norm, etc. At block <NUM>, if the event is within normal or expected behavior, the event is logged. For example, the event can be logged via the output generator <NUM>. At block <NUM>, if the event is outside the prescribed bound(s), a response to the event is triggered. For example, the health alert notifier <NUM> can be triggered in response to the event. In some examples, the health alert notifier <NUM> can generate a response message or instruction to the device via the output generator <NUM> to adjust a level, setting, mode, etc., in response to the event (e.g., not charging enough, not charging properly, irregular heartbeat, reboot needed, etc.) such as to send a message to a user, automatically adjust a device setting, trigger a maintenance request, alert hospital staff to a failing device, change in setting/configuration warranted, etc. At block <NUM>, an output is provided. For example, the output generator <NUM> can provide an update and/or other message to the device and/or a third party (e.g., beacon/site management services <NUM>, badge configuration services <NUM>, consuming product(s) <NUM>, etc.) to repair, replace, and/or adjust the affected device(s). An alert, update, and/or other message can be generated to help ensure reliable operation and uptime of the RTLS system <NUM>, <NUM>, for example.

<FIG> is a block diagram of an example processor platform <NUM> capable of executing the instructions of <FIG> to implement the example systems and components disclosed and described herein with respect to <FIG>. The processor platform <NUM> can be, for example, a server, a personal computer, or any other type of computing device.

The processor <NUM> of the illustrated example executes the instructions to implement the example message receiver <NUM>, the example message evaluator <NUM>, the example event processor <NUM>, the example health analyzer <NUM>, the example health alert notifier <NUM>, the example output generator <NUM>, and/or, more generally, the example health processor of <FIG>.

The input device(s) <NUM> permit(s) a user to enter data and commands into the processor <NUM>.

The output devices <NUM> can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer and/or speakers). The interface circuit <NUM> of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The coded instructions <NUM> of <FIG> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

Thus, certain examples communicate via messages or beacon communications to provide status information, location information, firmware upgrade, etc. Certain examples provide a custom beacon protocol (e.g., a custom BLE beacon protocol, etc.) that provides all involved fields for message processing and location determination, as well as system health status including low battery indication (e.g., in days remaining, hours remaining, percent remaining, battery value, etc.), custom fields for additional installation specific data (e.g., profile identifier (ID), floor designation, department ID, etc.), beacon security, and/or other item(s). While no single existing protocol fulfills these needs, certain examples provide a new protocol that enable location systems to provide customers with system health and security information/messaging and also enable additional device level functionality by allowing custom data within the protocol. Certain examples provide a protocol including data encryption as well as battery life information, system health information, location information, and/or other custom information. Using this protocol, the health processor <NUM>, management services <NUM>, edge device <NUM>, location gateway <NUM>, location server <NUM>, badge configuration tool <NUM>, firmware <NUM>, location toolbox app <NUM>, beacon/site management services <NUM>, site builder <NUM>, GIS <NUM>, location engine <NUM>, badge configuration services <NUM>, consuming products <NUM>, etc., can communicate and use the protocol to transmit and/or receive a plurality of information.

For example, a BLE proximity-sensing protocol can transmit a UUID along with several additional bytes to determine a device's physical location, track device movement, trigger a location-based action on the device, gauge device health, update device firmware, etc., via push and/or pull communication. Certain examples provide a protocol with a plurality of frame types that can be used individually and/or in various combinations to communication information from a beacon to a receiver. For example, a frame can include an identifier, a type, a flag, a length, a data value, an encrypted value, etc. A frame can include a variable data value and an indication of how the receiver is to interpret that value.

Certain examples can specify a security type (e.g., WPA-Enterprise, etc.), an encryption type (e.g., TKIP, etc.), an authentication method (e.g., Cisco: PEAP, etc.), authentication credentials (e.g., username/password, certificate, etc.), gateway host, gateway port, etc. Profile and proximity range can also be defined, for example. Configuration setting and corresponding BLE channel(s) can also be defined, for example. Other parameters such as location beacon broadcast, badge scan profile indicator, proximity range identifier, transmit interval, transmit window, hit count, suppress repetitive, etc., can be defined according to the protocol, for example.

From the foregoing, it will appreciate that the above disclosed methods, apparatus and articles of manufacture facilitate proximity detection and location tracking of assets in an industrial setting. As described above, example disclosures uniquely eliminate the expensive and difficult-to-maintain infrastructure. An example benefit of the disclosed techniques includes determining location awareness of assets in the industrial setting without constructing a new infrastructure. In some disclosed examples, the location awareness of assets is determined by "crowd-sourcing" probability proximity locations of the assets.

Claim 1:
A cloud based processing system (<NUM>) configured to:
receive location information and health status information of a plurality of beacon devices, wherein the location information indicates real-time locations of the plurality of beacon devices, and the health status information indicates real-time conditions of the plurality of beacon devices, the health status information including an event associated with at least one of the real-time conditions occurring at the respective beacon device, wherein the event comprises operation error information including one of: an unforced reboot event, a system error event, a forced reboot event, a wi-fi reconnect event and a heartbeat event, and wherein transmission of the health status information is in response to occurrence of the condition at the respective device;
track movements of at least some of the plurality of beacon devices based on the location information; and characterized in that the system is configured to compare details of the event to a prescribed bound (<NUM>), and, if the event is outside the prescribed bound, trigger a response (<NUM>) to the event, wherein the response comprises outputting an update or other message to repair, replace, and/or adjust the device.