Patent Application
20140330575
The present disclosure relates generally to healthcare systems and more particularly, but not exclusively, to systems and methods for providing a healthcare provider tracking system.
In a healthcare environment, the ability for staff to quickly access information resources may be important for patient care and efficiency. With the proliferation of computerized systems, staff members are increasingly burdened by the need to remember multiple logins to access these systems. In addition to remembering logins, typing usernames and passwords slows down daily workflow and introduces unnecessary delay and frustration into the work process.
The introduction of more advanced nurse call systems, where logins are desirable to track who responds to patient requests, and where a high number of logins are required every day, means having a fast login method is desirable. Additionally, typing usernames and passwords requires physical contact with keyboard interfaces or touch-screens, which may act as vectors for infectious diseases in a healthcare environment.
The accompanying drawings, which are included as part of the present specification, illustrate one embodiment of the present invention and together with the general description given above and the detailed description of the preferred embodiment given below, serve to explain and teach the principles of the present invention.
It should be noted that the figures are not necessarily drawn to scale and that elements of similar structures or functions are generally represented by like reference numerals for illustrative purposes throughout the figures. It also should be noted that the figures are only intended to facilitate the description of the various embodiments.
Turning to
The user tag 110 can be various types of devices that are operable to store and communicate data. For example, the user tag 110 can comprise a Near Field Communication (“NFC”) device, a Radio Frequency Identification Device (“RFID”), a Bluetooth enabled device, a WiFi enabled device, or the like without limitation.
The devices 120 and 130 are depicted as desktop computer and tablet devices respectively, but in various embodiments, the devices 120 and 130 may be any suitable device including a smart phone, laptop computer, gaming device, server, or the like without limitation. In various embodiments, the user tag 110 can be a device operable to be wirelessly read, interrogated, and/or modified by a suitable device in close proximity to the user tag 110.
Additionally, the server 140 may be any suitable device or may comprise a plurality of devices, or may be a cloud-based system. In various embodiments, the network 150 may comprise one or more suitable wireless or wired network, including the Internet, a local-area network (“LAN”), a wide-area network (“WAN”), or the like.
In various embodiments, there may be a plurality of the devices 120, 130 and a plurality of user tags 110. For example, in an embodiment where the system 100 is implemented in a hospital, there may be a plurality of healthcare providers such as doctors, nurses and other healthcare staff that can carry a user tag 110. As described in more detail herein, these providers may use their user tag 110 to login and configure devices such as the station device 120 and patient device 130. A given device 120, 130 may be in a locked or limited functionality configuration, and when service providers approach a given device 120, 130, they can position their user tag 110 proximate to the device 120, 130 such that the device 120, 130 reads or obtains user data from the user tag 110, which allows the device 120, 130 to authenticate the service provider via the server 140, and configure the device 120, 130 for use by the authenticated service provider based on the given provider's access credentials defined by the server 140.
Station and patient devices 120, 130 are described herein for purposes of example only, and in some embodiments, various suitable devices in various suitable locations may be employed in a healthcare provider tracking system 100. Additionally,
Returning to the communications, tag data and timestamp data are sent to the server 140, at 220, and tag data and associated timestamp data are stored at the server 140, at 225. In an embodiment comprising a plurality of tags 110 and devices 120, 130 in a hospital, storing this timestamp data associated with the tag data may be desirable because it allows a system administrator to track healthcare providers performing services in and around the hospital. Such tracking may provide for provider accountability and promote increased efficiency and faster response time to patient requests and needs.
Returning again to the communications, the server 140 authenticates the user data based on the tag data, at 230, and sends an access token to the patient device 130, at 235. The patient device 130 is configured based on the access token, at 240. For example, authentication of a user may comprise comparing received tag data to authentication data stored at the server 140. In some embodiments, received tag data comprises a user ID and a tag ID, and both must correspond to an authentication entry on the server 140 for user authentication to occur. Each user tag 110 may have a unique serial number or identification number associated with the tag 110, and by requiring both a matching user ID and tag ID, fraudulent access attempts can be prevented where a malicious party attempts to re-program a user tag 110 with different user credentials or where an unauthorized user tag 110 is programmed with valid user credentials.
In various embodiments, it may be desirable to configure or reconfigure the patient device 130 when in use by different health care providers, health care staff, or others such as patients. For example, the patient device 130 may be configured for use by a patient (e.g., as described in U.S. patent application Ser. No. 13/460,175), which provides a defined set of device functionalities via an interface. Such functionalities may include a patient scheduling orders or indicating various needs.
A nurse that is providing care or services to a patient may also use the patient device 130, but may configure the patient device interface to provide different functionalities by logging in with a user tag 110. Once authenticated, the patient device interface may be customized for the nurse user associated with the user tag 110. For example, the nurse user may have a user profile that includes favorites, user history, an access level, or other configuration settings.
Additionally, the interface may be configured to provide functionalities based on allowable user duties, user seniority, user status, or the like. For example, some health care staff may only be able to perform basic patient tasks such as providing comfort to and repositioning of a patient, providing food and drink, or attending to bathroom or hygiene needs. Such a staff member would therefore have a customized interface that provides functionalities related to these tasks but not others (e.g., as described in U.S. patent application Ser. No. 13/460,175). In contrast, a doctor may be authorized to change medication settings, provide a patient diagnosis, and perform certain medical procedures. Accordingly, a doctor may have a customized interface that provides functionalities related to these advanced tasks, whereas other users would not have access to such functionalities in their customized user interface.
Returning again to the communications, the patient device 130 receives a user logout, at 245, and stores session data at 250. Session data is sent to the server 140, at 255, and stored at 260. In various embodiments, it may be desirable to track and record actions performed by a user while the user is logged onto the patient device 140 (i.e., during a user session). While session data is depicted as being stored and sent to the server 140 after a user session, in some embodiments, session data may be communicated and stored in real-time or periodically during a user session.
In various embodiments, access to a customized user interface (via a patient device 130, station device 120, or the like) may provide a health care provider access to a task list, or may allow a health care provider to generate such a task list. A task list may allow the provider to respond to a patient, forward a patient request to another provider, send a message to another provider or send alert to the provider if a lapse in time has occurred that would warrant sending an alert to the provider, or send an alert at various programmed time intervals or at a programmed time, depending on the context of the patient request or task list item or provider preferences. Additionally, a task list may allow the provider to add, remove, edit, change the priority of, change the display order of, change the assignment of, or change an access setting of a task listed on a task list.
In further embodiments, a task list may be transferable. For example, if a given provider has a plurality of active tasks assigned to them on a task list, these active tasks may need to be re-assigned when the assigned provider goes on break, ends a shift, or otherwise is unavailable to perform the assigned task items according to defined criteria. In some embodiments, tasks may be re-assigned to a single provider or distributed among a plurality of providers. Such re-assignment may occur automatically without user interaction, or may be selectively performed by a healthcare provider, administrator, or the like.
In some embodiments, a customized user interface may allow for communication between and among a plurality of health care providers, patients or the like. For example, users may communicate via audio, text message, video, or the like.
The method 300 continues to decision block 325 where a determination is made whether an access token is received. If an access token is not received, then in decision block 330, a determination is made whether an error message is received. If an error message is not received, the method 300 cycles back to decision block 325; however, if an error is received, then in block 335 a user authentication error is indicated, and the method 300 cycles back to decision block 305. For example, a nurse can tap his user tag 110 at a tag reader associated with a station or patient device 120, 130, and the obtained tag data can be sent to the server 140 for authentication. If the server 140 determines that the tag data does not meet authentication criteria (
Returning to
In decision block 350 a determination is made whether a user logout is received, and if not, the user session is continued in block 355 and the method 300 cycles back to decision block 350. If a user logout is received, then session data is sent to the server 140 in block 360, and the device 130 is reconfigured in block 365. The method 300 then cycles back to decision block 305. For example, as discussed herein, a device 120, 130 may comprise a user interface that is configured based on a received access token. When the user logs out of a user session, the user interface may then be reconfigured, which may be a configuration that the interface was in before the user session began. In some embodiments, a patient device 130 may be configured for patient use, and then configured for used by a nurse, doctor or other user when such a user logs onto the device 130 with a user tag 110. When the user logs out of a user session, the device may return to the patient configuration for patient use.
Similarly, a station device 120 may be a general-use device that can be accessed by medical providers and the station device 120 may be in a locked configuration or other default configuration. When such a user logs onto the station device 120 with a user tag 110, the station device 120 may be configured as discussed herein and then return to the default or locked configuration when the user logs out of a user session.
For example, as discussed herein, tag data can comprise a tag identifier associated with the user tag 110 and can comprise an identifier associated with a user. The server 140 or other device may store data corresponding to user identifiers, tag identifiers, and relations therebetween. A determination whether received tag data meets authentication criteria may include a determination of whether a received user ID is valid and has required permissions; a determination whether a received tag ID is valid and has required permissions; and a determination whether the received user ID and tag ID are linked or associated.
Returning to the method 400, if tag data meets authentication criteria, then in block 450, an access token is generated and sent to the device that sent the tag data. The method 400 then cycles back to block 410. However, if received tag data does not meet authentication criteria, then in block 440 an access error message is generated and sent to the device that sent the tag data. The method 400 then cycles back to block 410.
It is understood that the embodiments described herein are for the purpose of elucidation and should not be considered limiting the subject matter of the present disclosure. Various modifications, uses, substitutions, combinations, and improvements, without departing from the scope or spirit of the present invention, would be evident to a person skilled in the art.
The present application is a non-provisional application of and claims benefit of provisional application 61/818,850 filed May 2, 2013. The present application is also related to U.S. patent application Ser. No. 13/460,175 filed on Apr. 30, 2012, which is a continuation-in-part of U.S. patent application Ser. No. 11/778,974 filed on Jul. 17, 2007, which claims the benefit of and priority to U.S. Provisional Patent Application No. 60/831,235 entitled “Advanced Patient Communication System (APaCS)” filed on Jul. 17, 2006, and U.S. Provisional Patent Application 61/568,073 entitled “Advanced Patient Nurse Call Device” filed on Dec. 7, 2011. These applications are hereby, incorporated by reference in their entirety for all purposes.
This invention was made with government support under Federal Grant Number 2R41MD006149-02 awarded by the National Institutes of Health, Institute for Minorities and Health Disparities. The government has certain rights in the invention.
| Number | Date | Country | |
|---|---|---|---|
| 61818850 | May 2013 | US |
