Patent Application
20180295466
This disclosure relates generally to tracking beacons, and, more particularly, to healthcare asset beacons and beacon housings.
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.
Certain examples provide beacon housings. An example low-power, short-range radio frequency wireless beacon apparatus includes a primary housing formed from at least a first portion and a second portion fused together around beacon electronics, the beacon electronics to communicate with second electronics via low-power, short-range radio frequency wireless communication. The example beacon apparatus includes a mounting surface on the primary housing to affix the primary housing to an object to be tracked using the beacon electronics.
Another example apparatus includes a primary housing means formed from at least a first portion and a second portion fused together around beacon electronics, the beacon electronics to communicate with second electronics via low-power, short-range radio frequency wireless communication. The example apparatus includes a mounting means on the primary housing to affix the primary housing to an object to be tracked using the beacon electronics.
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.
When introducing elements of various embodiments of the present disclosure, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
I. Overview
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) and/or other low-power, short-range radio frequency wireless communication. 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 pre-set 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 (and/or other low-power, short-range radio frequency wireless 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 low-power, short-range radio frequency wireless 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 re-associate 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.
II. Example Operating Environment
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 multi-media 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-9, ICD-10, 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.
A. Example Healthcare Information System
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,
As illustrated in
The example input 110 of
The example output 120 of
The example processor 130 of
The example memory 140 of
In certain examples, the memory 140 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 140 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 140. The memory 140 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 140 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 150 of
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.
B. Example Healthcare Infrastructure
In the illustrated example of
In the illustrated example of
In the illustrated example of
In the illustrated example, the interface unit 210 receives images, medical reports, administrative information, exam workload distribution information, and/or other clinical information from the information systems 204, 206, 208 via the corresponding interface connections 216, 218, 220. If necessary (e.g., when different formats of the received information are incompatible), the interface unit 210 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 212. 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 210 transmits the medical information to the data center 212 via the data center interface connection 222. Finally, medical information is stored in the data center 212 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 214 (e.g., by their common identification element, such as a patient name or record number). The workstation 214 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 214 of
The example data center 212 of
In the illustrated example, the example data center 212 of
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 200 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 200 can also be provided via platform as a service (PaaS), infrastructure as a service (IaaS), etc. For example, the healthcare information system 200 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.
C. Industrial Internet Examples
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.
As shown in the example of
Thus, the example health-related assets 310-312 within the industrial internet configuration 300 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 320, the health-related assets 310-312 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 310. 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 310-312.
D. Data Mining Examples
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.
E. Example Methods of Use
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.
III. Example Hospital Tracking Network
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
In the illustrated example of
In the illustrated example of
In the illustrated example, the beacon messages 410 include tag identifying information 415 and tag-type identifying information 420. For example, tag identifying information 415 may be a unique identifier of the beacon tag 405 such as a MAC address, a serial number, an alphanumeric signature, etc. The example tag-type identifying information 420 identifies whether the beacon tag 405 broadcasting the beacon message 410 is affixed to a fixed-location asset or affixed to a mobile-location asset. However, the beacon messages 410 may include additional or alternative information. For example, the beacon messages 410 may include information identifying the software version being executed by the beacon tags 405, may include information identifying a power level of the beacon tag 405, etc.
In the illustrated example of
In the illustrated example of
In the illustrated example of
In the illustrated example of
In the illustrated example, the RTLS server 455 is in communication with the reader badge 425 via one or more wireless networks represented by example network 460. Example network 460 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
In the illustrated example of
In the illustrated example of
In the illustrated of
In the illustrated example, when a mobile-location asset is classified as relatively-far, the example RTLS server 455 of
When a mobile-location asset is classified as a relatively-immediate asset, high signal strength (e.g., an RSSI value greater than (−40) decibels, etc.) may be indicative of a mobile-location asset that is in-front of the hospital worker 426, is being used by the hospital worker 426 and/or is being moved by the hospital worker 426. 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 425. In the illustrated example, the example RTLS server 455 of
In the illustrated example of
In the illustrated example of
In the illustrated example of
The hub module 506 may be leveraged to identify particular locations. As an example, the beacon badge 504 may be coupled, via a badge connection 534, to a hub module 506 placed on an entrance to a restricted area to identify when a person wearing a beacon tag 502 enters (or approaches) the restricted area. In one embodiment, the hub module 506 includes a system-on-a-chip (SOC) 528 to manage components of the hub module 506, one or more power sources 530 (e.g., one or more batteries and an external power source (e.g., an AC/DC connection), etc.) to extend the battery life and capabilities of the beacon badge 504, one or more sensors 532 communicatively coupled to the SOC 528, and a badge connection 534 for connecting the beacon badge 504 to the hub module 506.
In the illustrated example, the beacon badge 504 may be connectable (e.g., mechanically coupled, electronically coupled, etc.) to the example dock module 508. In the illustrated example, the dock module 508 may be used to charge one or more beacon badges 504. Accordingly, and in one embodiment, the dock module 508 includes an external power connector 536 (e.g., an alternating current (AC) connector, etc.), a charging indicator 538 to indicate whether the beacon badge 504 is charged or charging, and a badge connection 540 for connecting the beacon badge 504 to the dock module 508. In one embodiment, the dock module 508 is portable. For example, the dock module 508 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 504 to the dock module 508, via a badge connection 540, when they are off-duty.
The example beacon 600 of
The example beacon 600 of
The one or more network interfaces 640 of the example beacon 600 of
The example beacon 600 of
The example beacon 600 of
For example, transmit power has an impact on battery life. Transmit power is defined by several factors which include range/coverage and antenna design, for example. The transmit power can be adjusted to address antenna gain and coverage for a given beacon usage. The example beacon 600 may be designed to cover a 4 to 8 feet wide aisle with a distance between beacons 4 to 8 feet. In certain examples, the antenna 630 is configured to work well when the beacon 600 is mounted against a wall or asset with a smooth surface (e.g., in a half sphere pattern, etc.) and/or (2) when the beacon 600 is hanging (e.g., via a tombstone bracket, etc.) with respect to a surface, etc.
The chirp rate indicates a number of times per second that an advertisement packet is send out by the beacon 600 (e.g., 1 beacon every two seconds, 9.5 beacons per second, 2000 millisecond (ms) chirp time, etc.). However, each additional chirp per second decreases battery life. Chirp rate is also defined by a number of channels on which the beacon 600 advertises (e.g., 2 channels, etc.). Transmitting on two channels instead of three can save power, for example.
The example beacon 600 of
The example beacon 600 of
The example CPU 710 executes instructions stored in the memory 720 to facilitate programming, testing, and operation of the BLE chip 610. For example, the chip 610 implements one or more BLE profiles and/or other low-power, short-range radio frequency wireless profiles and operates the radio (e.g., RF, etc.) with the RF core 730, clock 670, antenna tuner 620, and antenna 630. The memory 720 stores information and instructions such as a BLE protocol stack, for example, for execution by the CPU 710.
The example RF core 730 controls an RF portion of the beacon 600 radio. For example, the RF core 730 includes a phase locked loop and/or other circuit to provide carrier and modulation frequencies to generate radio signals (e.g., 2.4 GHz, 5.2 GHz, etc.). In some examples, the clock(s) 670 operate with the RF core 730 to support RF operation (e.g., to generate a beacon signal, etc.).
The example sensor controller 740 includes and/or interfaces with one or more sensors such as a low power sensor/battery monitor, a temperature sensor, etc. The example peripheral interface(s) 750 facilitate interaction with interface(s) such as the network interface(s) 640, user input control(s) 650, temperature and/or battery monitor(s), timer(s) (e.g., watchdog timer, etc.), real time clock and/or other clock 670, security module, analog comparator, etc.
In certain examples, the primary housing portion 810 includes an opening or access port 815 through which air can flow, a push button can be inserted, an LED can be positioned, etc. In certain examples, the port or opening 815 is covered in a mesh to keep particles out of the interior of the housing 810, etc.
In certain examples, an LED and/or other light/visual indicator positioned in the opening 815 can indicate whether the beacon 600 is turned on/off, in a particular mode, etc. For example, the beacon 600 can operate in one of a plurality of modes including a shipping mode, a sleep mode, a configuration mode, an operating or normal mode, etc. The indicator and/or the beacon 600 can act differently depending on in which mode the beacon 600 is operating. For example, the indicator can be a different color, different pattern, flashing, etc., based on the mode. Thus, the indicator reacts different depending upon the mode of the beacon device 600. In certain examples, the indicator can be selected through the opening 815 to change the mode of the beacon 600. The beacon 600 can be in a shipping or sleep mode in transit, a sleep mode when idle, an operating mode to emit a signal, a configuration mode to change beacon rate, etc.
In certain examples, the primary housing 810 is attached to a secondary housing 820. The secondary housing portion 820 provides a mounting surface to attach the beacon 600 to another device, surface, etc. In certain examples, the secondary portion 820 provides a plurality of mounting options including a flat surface mounting option including an adhesive such as sticky back adhesive tape located on the outward facing surface of the secondary housing 820 to be exposed by a user to attach the beacon 600 directly to a flat surface on an asset. The secondary portion 820 can provide another option for mounting using an opening 825 near and end of the secondary portion 820 which facilitates tying or wrapping of the beacon 600 to a circular structure such as a pole, cord, knob, etc., via the opening 825 of the secondary portion 820 (e.g., a tombstone shaped plastic piece, etc.).
In certain examples, at least one of the primary housing 810 and secondary housing 820 is transparent and/or translucent to allow the LED(s) 680 (e.g., indicating mode, error, activity, etc.) and/or labeling of the beacon 600 to be visible through the housing 800. In certain examples, the primary 810 and/or secondary 820 portions of the housing 800 are cleanable without degradation or damage using one or more surface cleaners, germicidal wipes, alcohol, bleach, disinfectant cleaner, glass cleaner, hydrogen peroxide, soap, etc.
In operation, one or more way point beacons are distributed over an area in which locationing and asset tracking is desired. Asset beacons are attached to assets such as carts, products, heart pumps, scanners, etc. A hand held device with WiFi and BLE capability such as a smart phone, mobile badge, BLE/WiFi client bridge, access point with BLE sniffing, etc., can be used to detect beacons within range.
An example way point beacon sends an advertisement packet out every chirp period (e.g., 600 ms intervals, etc.). This rate can be changed such as based on a number of chirps per second needed to resolve the location with a certain accuracy and time period. Transmit power can be a variable in the operation of the beacon 600. For example, way point beacons are placed at fixed locations and the location is recorded in a locationing server in a map of the area. When the way point beacon is heard by a hand held device or one of the BLE/WiFi client bridges, the locationing server knows that the handheld device is near or in the same room as the way point beacon it is reporting. The handheld device or one of the many BLE/WiFi client bridges might also receive beacons at the same time from asset beacons. The locationing server, knowing that the mobile device has also heard a way point beacon, determines that the asset beacon(s) it is receiving are located on or near assets near or in the same room as the way point beacon. Similarly, as an asset moves around in an area, wall mount BLE/WiFi clients hear the asset's beacon come into range and out of range, allowing the locationing server to track movement of the asset. Thus, a beacon can be placed on a mobile asset and used to track that asset within a user's location, for example.
Upon power up, the asset beacon enters a connect mode. The connect mode allows the asset beacon to momentarily connect to a master BLE device, such as an Ipad™, Android™ device, etc., that, if running a toolbox application, can modify certain beacon parameters such as transmit power, chirp time, number of channels in an advertisement chirp, beacon mode and/or will also allow certain parts of the beacon's firmware to be upgraded, for example. After a time period (e.g., 20 seconds), if the beacon has not connected to a valid toolbox application, the beacon transitions to a beaconing mode. In the beaconing mode, the beacon continually chirps at a fixed rate over, for example, 1, 2 or 3 advertisement channels at the selected transmit power setting. The beacon includes a RESET switch which allows the user to change from the beaconing mode back to the connect mode, for example. This switch can also be used to put the beacon in a deep sleep where it is no longer beaconing or take the beacon out of a deep sleep, for example.
In certain examples, the asset beacon tag can be mounted in several ways. The beacon tag can be taped to equipment from the top or side, for example. The tag can also be hung on a bed, IV pole, and/or other equipment with a tie wrap or hook, for example.
Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.
