Abstract:
A health care provider tracking system and method are disclosed. Such a method may include customizing a healthcare device user interface by presenting a first user interface on the healthcare device; receiving tag data having a healthcare provider identifier; sending the tag data to an authentication server; receiving an access token; and presenting a second user interface on the healthcare device different from the first user interface. The second user interface is configured based on the access token and the healthcare provider identifier. A healthcare tracking system may include a plurality of user tags and a plurality of healthcare devices configured to present a first user interface; obtain the tag data from user tags; communicate tag data; receive an access token; and present a second user interface on the healthcare device different from the first user interface.

Description:
[0001]    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. 
     
    
       [0002]    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. 
     
    
     TECHNICAL FIELD 
       [0003]    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. 
       BACKGROUND 
       [0004]    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. 
         [0005]    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. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    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. 
           [0007]      FIG. 1  is an exemplary top-level drawing illustrating a healthcare provider tracking system. 
           [0008]      FIG. 2  is an exemplary data flow diagram illustrating an embodiment of a data flow path between the user tag, patient device and server of  FIG. 1 . 
           [0009]      FIG. 3  is an exemplary block diagram illustrating an embodiment of a method for healthcare provider tracking in accordance with an embodiment. 
           [0010]      FIG. 4  is an exemplary block diagram illustrating an embodiment of a method for healthcare provider tracking in accordance with an embodiment. 
       
    
    
       [0011]    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. 
       DETAILED DESCRIPTION 
       [0012]    Turning to  FIG. 1 , the healthcare provider tracking system  100  is shown as including a station device  120 , a patient device  130  and a server  140  that are operably connected via a network  150 . A user tag  110  may also be operably connected with or communicate with the station device  120  or patient device  130 . 
         [0013]    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. 
         [0014]    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 . 
         [0015]    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. 
         [0016]    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&#39;s access credentials defined by the server  140 . 
         [0017]    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,  FIG. 1  depicts the user tag  110  in communication with both the station device  120  and patient device  130 . Although embodiments may allow for simultaneous communication between a user tag  110  and a plurality of devices  120 ,  130 , in various embodiments, the user tag  110  and user tag readers associated with a given device  120 ,  130  are only operable at relatively short distances (e.g., within about 0.1 cm, 0.5 cm, 1 cm, 2 cm, 5 cm, 10 cm, 50 cm, 100 cm, or the like). Accordingly, where devices  120 ,  130  are spaced apart at distances greater than this operable distance, the user tag  110  may therefore only communicate with only one device  120 ,  130  at a time. 
         [0018]      FIG. 2  is an exemplary data flow diagram illustrating an embodiment of a data flow path between the user tag  110 , patient device  130  and server  140  of  FIG. 1 . The data flow begins where the user tag  110  sends tag data to the patient device, at  205 . The patient device  130  stores tag data, at  210 , and generates and stores a timestamp associated with the tag data, at  215 . For example, in some embodiments, tag data may be used to login and configure the patient device  130 , and tag data may comprise a tag ID, a user ID, a user password, a user token, user session data, user settings, profile data, or the like. Additionally, as described herein, it may be desirable to track when a user log into, or attempts to log into the patent device  130  for tracking purposes, and therefore a timestamp may be associated with the received tag data. In some embodiments, timestamps may be generated in relation to any suitable step in the processes or a user session as described herein. 
         [0019]    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. 
         [0020]    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. 
         [0021]    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. 
         [0022]    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. 
         [0023]    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. 
         [0024]    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. 
         [0025]    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. 
         [0026]    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. 
         [0027]    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. 
         [0028]      FIG. 3  is an exemplary block diagram illustrating an embodiment of a method  300  for healthcare provider tracking in accordance with an embodiment. The method  300  begins in decision block  305  where a determination is made whether tag data is received. If tag data is not received, the method  300  loops at block  305  until tag data is received. If tag data is received, the tag data is stored in block  310  and timestamp data is generated and stored in association with the tag data in block  315 . In block  320 , timestamp and tag data are sent to the server  140 . 
         [0029]    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 ( FIG. 4 ), the server may send an error indicating that the tag data does not meet authentication criteria. 
         [0030]    Returning to  FIG. 3 , if an access token is received, then in block  340  the device is configured based on the received access token and a user session is initiated in block  345 . For example, as discussed herein, a user interface on a patient device  130  may be customized, configured or reconfigured based on the received access token. The user interface may provide access to, obscure, or deactivate various functionalities of the patient device  130  or interface on the patient device  130 . The user may perform functions on the device  130  with the modified or configured user interface during a user session, and then logout of the user session. 
         [0031]    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. 
         [0032]    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. 
         [0033]      FIG. 4  is an exemplary block diagram illustrating an embodiment of a method  400  for healthcare provider tracking in accordance with an embodiment. The method  400  begins in decision block  410  where a determination is made whether tag data is received, and if not, the method  400  loops back to block  410 . However, if tag data is received, then in block  420 , received tag data is compared to user authentication data, and in decision block  430 , a determination is made whether the received tag data meets authentication criteria. 
         [0034]    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. 
         [0035]    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 . 
         [0036]    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.