Source: https://patents.google.com/patent/US20160301691A1/en
Timestamp: 2019-09-23 21:15:21
Document Index: 139480788

Matched Legal Cases: ['art 300', 'art 400', 'art 500', 'art 600', 'art 700', 'art 800', 'art 900', 'art 1000', 'art 1100', 'art 1200']

US20160301691A1 - Layering in user authentication - Google Patents
Layering in user authentication Download PDF
US20160301691A1
US20160301691A1 US14/961,743 US201514961743A US2016301691A1 US 20160301691 A1 US20160301691 A1 US 20160301691A1 US 201514961743 A US201514961743 A US 201514961743A US 2016301691 A1 US2016301691 A1 US 2016301691A1
US14/961,743
2015-12-07 Priority to US14/961,743 priority patent/US20160301691A1/en
2016-10-13 Publication of US20160301691A1 publication Critical patent/US20160301691A1/en
An asset is disclosed having a processing device and hardware with which to capture a biometric. The asset, with optional input from a remote server, may authenticate an identity of a medical staff member (MSM) with biometric recognition (and/or with other second factor authentication) upon the MSM attempting to access a medical database via the asset. The asset may receive a first location of the MSM from a real-time location system (RTLS) and retrieve a second location of a patient from the RTLS. The asset may further correlate the first location and the second location as being co-located, and thus grant the MSM access to identified data records of the patient within the medical database according to a security access level authorized the MSM. The correlation may include a location of the asset, which correlates to the location of the MSM before access is granted.
FIG. 1 illustrates a communication flow of asset and management information in a medical management system (MMS) according to various embodiments.
FIG. 2 is a diagram of an authentication system to authenticate access to the MMS according to one embodiment.
FIG. 3 is a flowchart of an exemplary method for validating credentials through the authentication system according to one embodiment.
FIG. 4 is a flowchart of an exemplary method for creating of a biometric for use in the authentication system according to one embodiment.
FIG. 5 is a flowchart of an exemplary method for updating a biometric being used in the authentication system according to one embodiment.
FIG. 6 is a flowchart of an exemplary method for deleting a biometric being used in the authentication system according to one embodiment.
FIG. 7 is a flowchart of an exemplary method for validating a biometric captured for use in the authentication system according to one embodiment.
FIG. 8 is a flowchart of an exemplary method for validating a biometric captured for use in the authentication system, according to another embodiment.
FIG. 9 is a flowchart of an exemplary method for validating a biometric and for handling a stored biometric that has become stale, according to one embodiment.
FIG. 10 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to one embodiment.
FIG. 11 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to another embodiment.
FIG. 12 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to yet another embodiment.
FIG. 13 illustrates a block diagram of one implementation of a computer system.
A medical asset may include equipment such as a medical cart, ventilators, an IV pole, a tablet computer, a battery pack, all in one (AIO) personal computer, and so forth. A military asset may include a mobile or stationary computer, a radio system, a workstation and a weapons system and the like. A government asset may include a mobile or stationary computer, a workstation, an authentication pad and the like. Because some assets involve computing devices (such as a medical cart, a tablet or personal computer), these assets may provide access to confidential or sensitive patient information records in a medical setting, a military setting, a government setting and in a business setting. Securing access to the assets becomes a challenge when the assets may be distributed throughout a medical facility such as a hospital, nursing home or medical clinic (or a military or government facility) and are generally difficult to keep under constant observation at all times.
Accordingly, the asset may function in conjunction with a server or remote computing device to authenticate access of a medical staff member (MSM) (or other user) to an asset and to a medical server or database that stores patient or medical information. The MSM may be a physician, a physician's assistant, a nurse, a medical technician, or a specimen collector, for example. In one embodiment, the medical asset may validate the identification of the MSM for access to the medical database through one or more authentication methods.
In another embodiment, other users may be military or government personnel such as, for example, officers of certain rank, soldiers, sailors, airmen or marines of certain rank, and government employees of certain general schedule (GS) rank. Additionally, or alternatively, personnel may be categorized by position. For example, in the military, personnel may be assigned to positions such as S1, personnel staff, commander, captain, executive officer (XO), S2, S3, S4, S6 and other command or staff members. In the government, personnel may similarly be assigned to a position, which could be a position of leadership, management, committee head or chair, and the like. These personnel may be authenticated through a computing system integrated within an asset or as a stand-alone workstation or the like for access to personnel records, or mission or planning documents, and/or to other confidential, sensitive records or information that may carry varying levels of security levels for authorized access. Accordingly, the “MSM” referred to herein may also be understood to refer to military or government personnel or other business or organization personnel as would be apparent to one of ordinary skill in the art having the benefit of this disclosure.
In one embodiment, an asset includes a processing device and hardware with which to capture a biometric. The asset, with optional input from a remote server, may authenticate an identity of a MSM with biometric recognition upon the MSM attempting to access the medical database via the asset. The asset may also receive a first location of the MSM from a real-time location system (RTLS) and retrieve a second location of a patient from the RTLS. The asset may further correlate the first location and the second location as being co-located, e.g., within a threshold distance of each other or in a same room or designated location. Based on a combination of the biometric authentication and the location correlation of the MSM and the patient, the asset may grant access, by the MSM, to identified data records of the patient within the medical database according to a security access level authorized to the MSM. Alternatively, or additionally, the correlation may further include a location of the asset that correlates to the location of the MSM before access is granted, which may allow the MSM to access a patient's information even when not co-located with the patient.
In another embodiment, the asset, with optional input from a remote server, may validate credentials received from a user through an input source to provide access to an authentication system used to authenticate access to a medical database server. Once past the credentials authentication, the asset may perform second factor authentication to increase security. In one example, the asset may capture a biometric of the user through a biometric capturing device as directed by the processing device. The asset may send the biometric captured of the user to an authentication server over a network in which is stored one or more biometrics for the user. The asset may then receive a validation from the authentication server authenticating the user based on the biometric meeting a threshold match with a stored biometric, and grant a level of access to records of the medical database server according to a security access level associated with the user.
FIG. 1 illustrates a communication flow of asset and management information in a medical management system (MMS) 100 according to various embodiments, in addition to aspects of a real-time location system (RTLS) that works with the MMS 100 for authentication as will be explained with reference to FIG. 2.
The communication flow may originate in a location such as a room 110, and may include beacon devices 102 and data sent from an asset 104 (e.g., a medical cart is shown). The asset 104 may be coupled with an asset tag device 105A or may include an asset tag manager 105B that runs on the asset 104 to determine a location of the asset 104. The data (including the location) may flow through a communication hub 106 (or other network device) and arrive at a server 108 (such as a medical database and/or an authentication server). In some embodiments, the data also, or alternatively, flows through a communications network 115, where the communications network 115 may include the communication hub 106. The data flow may also flow in the reverse direction from the server 108 and/or the communication hub 106 to the asset 104, e.g., in response to a request for medical information or records on a patient. The data may include asset and/or management data, medical information, patient information, authentication data, and other personal and security-related information and the like.
The MMS 100 may include a plurality of assets 104 as shown in FIG. 2. The beacon devices 102 may be fixed locations and may provide a location identifier (ID) for assets 104 to detect, such that the assets 104 may determine a current location, which the assets may transmit through the communication hub 106 to the server 108. The beacon device 102 may identify or be associated with any type of location, including a room, a hallway, a common or conference room, and/or a grid location.
The asset tag device 105A (e.g., a non-integrated asset tag device) may be implemented in hardware and include a circuit board within a housing, the circuit board containing a processor, memory (potentially non-volatile and/or volatile memory), a battery, and a transceiver. The transceiver may be a third-party integrated circuit, such as an RF module, e.g., a Bluetooth® chip, an RFID interrogator and/or receiver or the like. The asset tag device may be performed by processing logic comprising hardware, software, firmware or any combination thereof.
The asset tag manager 105B (e.g., an integrated asset tag device) may be a software program (including instructions) that may utilize a processor, memory, transceiver and the like of a host machine of the asset 104, such as the medical cart (all-in-one (AOI)), any medical device in which the asset tag is integrated, or any device when used in non-medical applications.
One advantage of the asset 104 determining its location and sending the asset management information to the communication hub 106 may be to enable the beacon device 102 to be small and low energy. For example, because the beacon device 102 broadcasts the location ID, the beacon device 102 may consume a small amount of power (such as a 1-2 Ah per day) and may be powered by a small battery for an extended period of time. The asset 104 may have a separate power supply that may be recharged more easily than the beacon device 102. Another advantage of the asset 104 communicating the asset information may be that the asset 104 may select the information of the asset 104 to be communicated to the communication hub 106 and communicate the information in real-time and directly to the communication hub 106 to reduce communication interference from a plurality of devices.
In yet another example, the beacon devices 102 may have a predefined number or identifier (ID). When a layout of the building is compiled, the user may use a graphical user interface (GUI) to select which beacon device is located in each room, hallway, conference room and the like.
FIG. 2 is a diagram of an authentication system 200 to authenticate access to the MMS 100 of FIG. 1, including a medical database, according to one embodiment. In this example, the authentication system 200 may include a plurality of assets 104, a medical database server 250, a real-time location system (RTLS) 220 and an authentication server 230. The medical database server 250 may include a medical database 254 including patient records 255 and other personal and confidential information needing authenticated, or secured, access by medical staff members (MSMs).
The RTLS 220 may include a plurality of beacons and/or tags with which are associated location identifier (IDs) as discussed with reference to FIG. 1, which may be stored in the location IDs database 222. The RTLS 220 may further include a staff locations database 224 to store and track locations of the MSMs based on tags (or other locater) positioned in badges, bracelets and the like worn by the MSMs. The RTLS may further include a patient locations database 226 to store and track locations of patients within a medical facility, such as with tags (or other locator) positioned in badges, bracelets (or other device that is attached to the patient), or attached to a bed or other equipment of the patient, such as an IV tower.
The correlator 206 may perform correlations between these locations, e.g., between the locations of the MSM requesting access to the asset and medical database, a patient for which the MSM requests information and/or the asset 104 located in a room or the proximity of the patient. For example, the correlator 216 may determine whether the MSM is co-located with the patient (e.g., within the same room) and/or whether the asset 104 itself is co-located in the same room with the patient. Given a location, the asset 104 (with optional input from the RTLS 220), may determine in what room of the medical facility that location resides. In this way, the asset 104 may correlate, at least at a room or area level, the locations of the MSM, a patient and the asset 104.
The authenticator 216 may run the general authentication process at the asset level as will be explained in more detail, which may include second factor authentication of the MSM (or user) wanting to access the asset, and the medical database 254 including the patient records 255. The authentication may also include results of the location correlation performed by the correlator 206, and thus improve the accuracy and security of the authentication of the user. In one embodiment, at least one form of authentication includes validation of a biometric captured by the biometric capturer 214 and biometric hardware 213 of the asset. The authenticator 216 may run any series of authentications, which may be driven by an algorithm or group of algorithms. After successful validation of an identity of the MSM, and passing the required authentication, the authenticator 216 may grant access by the MSM to the medical database server 250 (e.g., via an application or program).
In one embodiment, the authentication server 230 may include, but is not to be limited to, the processing device 202, an account manager 234, a staff accounts database 238, an access codes database 242, a biometrics database 244, and a security access level database 246. In one example, the authentication server 230 and the medical database server 208 may be located on different servers or may be two separate databases on a single server. In another example, the authentication server 230 and the medical database server 208 may be integrated as a single server, and so reference to one or the other may be more for the benefit to ease explanation than to require that certain processes be executed by one, or that certain data be stored by one, as compared to the other. For example, even if separate, the authentication server 230 may still act as a gatekeeper to access by MSMs to the medical database 254 located on the medical database server 208.
In one example, the processing device 202 of the authentication server 230 may be substantially the same as the processing device 202 of the asset 104. In other words, the authentication server 230 may perform substantially the same locating, correlating and/or authenticating functions across the network 115 on behalf of the asset 104, e.g., such that processes requiring more processing power and/or access to the above-listed databases may be performed all in the same location. In another example, one or more process may be performed by the processing device 202 at the asset 104 and one or more other process may be performed by the processing device of the authentication server 230. When authentication is completed, the authentication server 230 may send a positive validation indication to the asset 104, which may then grant access to the MSM that has been authenticated.
In one embodiment, the account manager 234 may create a security access account for each new medical staff member (MSM) (such as a doctor, nurse, aide and the like) wanting access to the medical database 254. The account manager 234 may then set up access codes for each MSM such as a username, password, PIN and swipe card ID, secret shape, gesture, badge tap and the like which may be stored in the access codes database 242. The account manager 234 may further coordinate the capture of a biometric of the new MSM by the asset (or other computer within the medical facility) to begin a baseline against which to compare future biometrics. If set up with facial or iris recognition or the like, the account manager may request to obtain more than one image, such as from different angles or in differing lighting conditions, on which to build a set of baseline images against which to compare future biometric validations. The authentication server 230 may store the captured and updated biometrics in the biometrics database 244.
The account manager 234 may further be directed to set a certain security access level for each MSM and store the security access levels in the security access level database 246 in relation to the corresponding staff account 238. Each security access level may dictate a certain level of access to patient records 255 and personal information permitted by corresponding MSMs (or officers, enlisted, government personnel of differing positions). For example, different individuals may have different security access levels, which may mean access to less or more information or access to information of a different quality, e.g., less or more confidential or sensitive.
In one example, a doctor may access complete patient information, including treatment information, medication charts, personal information, and so forth. In this example, a nurse's aide may have limited access to the patient information and be limited to accessing treatment information and medical carts. Furthermore, a specimen collector or medical technician may have still further limited information as may be dictated on a need to know basis according to their respective job descriptions.
In another example, a commander in the military, the Si and personnel staff may access entire records of military personnel within their unit, while other personnel within the unit may only access their own personal record(s). In a further example, a leader of a government agency may access all data records of personnel within their stewardship but those personnel may only be able to access their own data record(s). Similarly, personnel with certain positions or clearance levels may be provided access to differing levels of confidential or sensitive strategy and planning documents based on security level granted to those personnel.
In yet another example, the device can also use facial recognition to determine the identity of the patient. For example, when the doctor enters the patient's room, the device may determine what patient is assigned to that room and then use facial recognition to verify that an individual in that room is the assigned person.
Authentication in video mode may be used together with a liveness detector, which may be integrated within the authenticator 216, and which checks that the image for which a biometric is captured is a live person (not a photo, for example). This prevents granting access to an asset with an image of the subject. Detection of “liveness” may include, but not be limited to, detecting blinking of eyes, moving the head around, tilting the head, moving the head closer to or further from the camera, and/or slightly changing facial expression. Liveliness may also be detected using other sensors such as a microphone where the user speaks a given phrase or using voiceprint identification.
When layering in authentication as discussed above, greater or fewer layers of authentication may be used depending on the level of accuracy (or strength) with which the user is identified at each subsequent layer and/or a level of confidentiality of the information attempting to be accessed. When some doubt exists or authentication is performed with a weaker method, a next layer may increase the difficulty of spoofing or hacking the authentication. For example, a first layer may be a username and password, a second layer may be a PIN number, a third layer may be a random security code (like an RSA token), a fourth layer may be a biometric, and a fifth layer may include further second factor authentication, where these layers may have their orders changed in various embodiments. By way of further example, when the first layer provides 50% accuracy, then the MSM may add a second layer of authentication. When the second layer increases the accuracy to 75%, the MSM may add additional layers until accuracy reaches a predetermined level, such as 85% or 90% or the like.
In one example, the authentication system may enable a user to access a device or a database using a single sign-on (SSO), such as with use of facial recognition authentication. FIG. 3 is a flowchart 300 of an exemplary method for validating credentials through the authentication system 200 according to one embodiment.
The authenticator 216 may then determine whether a valid response is received from the authentication server for the credential validation and the biometric validation (318). The asset 104 may then retrieve an operating system credential and send the operating system credential to a third party single sign-on (SSO) server 330. An operating system credential (e.g., an SSO credential) may include a username and password, a PIN or other authentication identifier obtained by the operation system. In some embodiments, a positive validation by the authentication server 130 may act as SSO credential for access to all applications and software of the asset.
In one example, the authentication system 200 may automatically log a user out after a period of inactivity or when the user may not be adjacent the asset 104 for a threshold period of time. When the user may be logged out, the authentication system may retain a previous state of the system for a threshold period of time. For example, when a user may be logged out, the authentication system 200 may maintain the last known system configuration for 10 minutes. When the same user logs back into the system within 10 minutes, the authentication system 200 may bring back up the last known system configuration. When the user logs back in after the 10 minutes have expired, the system 200 may be reset to a default configuration.
FIG. 4 is a flowchart 400 of an exemplary method for creating of a biometric for use in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (410). The asset 104 may then select an account appropriate for the user (420), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (430) and continue to attempt capture until successful (430). Upon successful capture, the asset may create the biometric and send the captured biometric for storage in the biometrics database 144, e.g., in conjunction with user's staff account (440).
FIG. 5 is a flowchart 500 of an exemplary method for updating a biometric being used in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (510). The asset 104 may then select an account appropriate for the user (520), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (530) and continue to attempt capture until successful (530). Upon successful capture, the asset may update the biometric (e.g., a previously captured or stored biometric) and send the updated biometric for storage in the biometrics database 144, e.g., in conjunction with user's staff account (540). Updating a biometric recognizes that a biometric may change over time, such as facial features may change with fluctuating weight or age in the example of facial recognition.
The updating the biometric process may also involve authenticating an identity of the user associated with the stored (or stale) biometric before updating or replacing the stored biometric with an updated biometric. The authentication as disclosed elsewhere herein may include a primary authentication, and alternatively, a primary authentication and a second factor authentication such as layered authentication approaches to increase the accuracy and the security of making updates to the biometrics. (See FIG. 9 for more details and an alternative embodiment.)
FIG. 6 is a flowchart 600 of an exemplary method for deleting a biometric being used in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (610). The asset 104 may then select an account appropriate for the user (620), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether to delete a biometric and continue to operate until successful deletion (630). The asset 104 may then direct the authentication server to delete the biometric from the biometrics database 144 (640). Deletion of a biometric may occur such as based on an account of a user being removed, deleted or changed, or in the case a staff account needs to be recreated from scratch, including creation of access codes and biometrics. The biometric may also be removed when an active database changes, which may include a different list of authorized users.
FIG. 7 is a flowchart 700 of an exemplary method for validating a biometric captured for use in the authentication system 200 according to one embodiment. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (710). The asset 104 may then select an account appropriate for the user (720), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (730) and continue to attempt capture until successful (730). The asset 104 may then request the authentication server 230 to validate the captured biometric with one or more biometrics stored in the biometrics database 144 (740). The asset 104 may then determine whether the biometric is valid (750), e.g., based on receipt of a valid or invalid response from the authentication server 230. When valid, the asset 104 may alert or inform the user of successful validation (760), and thus grant access to the user. When invalid, the asset 104 may alert or inform the user of the failure (770), and optionally prompt the user for a different biometric or other form of authentication.
FIG. 8 is a flowchart 800 of an exemplary method for validating a biometric captured for use in the authentication system 200, according to another embodiment. After a user (e.g., a medical staff member) logs in with a keyboard (or the like) (810), the asset 104 may determine whether biometric validation is available (820). If not, the asset 104 may prompt the user for other authentication (830) and validate the other form of authentication (840), which may be another biometric, a username/password, PIN, access card or the like. If yes, the asset 104 may attempt to capture a biometric of the user until successful (850). The asset 104 may then request the authentication server 230 to validate the biometric as done in the method of FIG. 7 (860). When the authentication server returns a response that the biometric is valid, the asset may alert or inform the user that the biometric is valid (870). When the authentication server returns a response that the biometric is invalid, the asset 104 may prompt the use to create another biometric (or try again to capture the same biometric again) that may be used for comparison for later authentications of the user (880).
FIG. 9 is a flowchart 900 of an exemplary method for validating a biometric and for handling a stored biometric that has become stale, according to one embodiment. The asset 104 may determine whether a biometric has been captured (910), until successfully capturing the biometric (910). The asset 104 may then direct the authenticator 216 (at the asset or at the authentication server 230) to validate the biometric based on comparison with one or more biometrics stored in the biometrics database 244 in relation to the user's staff account (920).
In one example, the facial recognition system may malfunction or be unable to authenticate the user. For example, the facial recognition system may not be able to communicate with the authentication server 230 to access facial recognition information. In one example, when an asset 104 is at a location where the network 115 is not available, then a login or badge tap may be used for authentication. In one example, when the login or badge tap may be used for authentication, the user may be granted limited access to the asset 104 or information available through the asset. For example, the user may not be able to login to patient records but could generally access the authentication system 200 for diagnostics, troubleshooting and the like. In another example, the user may be restricted to only accessing power assistance systems to move the cart to a location where the network 115 is available. In another example, an asset 104 may backup facial recognition information on the asset 104 and may use the backup facial recognition information to authenticate a user. One advantage of the asset 104 using the facial recognition system may be to provide a standalone authentication system. Another advantage of the asset 104 using the facial recognition system may be to save time by eliminating a manual login for authentication.
FIG. 10 is a flowchart 1000 of an exemplary method for authenticating a medical staff member for access to the MMS according to one embodiment. An asset may detect that a medical staff member (MSM) has entered a patient room (1004) and update a location of the MSM based on method disclosed above (1008). The MSM may attempt to access the asset (e.g., an all-in-one PC, a tablet, a medical cart or the like) (1012). To authenticate the MSM's access, the asset may capture a biometric (1016) and receive second factor authentication (1020). The asset (and/or the authentication server) may then determine whether the biometric and the second factor authentication are valid (1024). If the authentication is not valid, the asset denies access by the MSM (1028). If the authentication is valid, the asset grants access by the MSM to the asset (1032).
The asset may continue to detect the MSM attempting to access patient health record software (1036). In response to the detection, a single sign-on (SSO) server may retrieve the MSM's credential for the health record software on behalf of the asset (1040). The asset may determine whether the MSM's credentials are valid (1044). If not valid, the asset may deny access to the health record software (1028). If valid, the asset may grant access by the MSM to the health record software with a proper security access level corresponding to the MSM's security access rights. The asset may then request patient data from a medical database (e.g., as stored in a medical database) (1052). The asset may, in one embodiment, then determine whether the patient corresponding to the requested patient data is located at the MSM's location (1056). If the MSM is not co-located with the patient, no records are returned, e.g., access may be denied (1060). If the MSM is co-located with the patient, the MSM may provide access to the patient health data according to the MSM's security access level.
FIG. 11 is a flowchart 1100 of an exemplary method for authenticating a medical staff member for access to the MMS 100 of FIG. 1 according to another embodiment. An asset may authenticate the identification (ID) of a medical staff member (MSM) with biometric recognition (1110). The asset may then receive a first location of the MSM from a real-time location system (RTLS) or from data provided by the RTLS (1120). The asset may also receive a second location of a patient from the RTLS (1130). The asset may then correlate the first location with the second location to generate a first correlation, in determining whether the MSM is co-located with the patient (1140). The asset may also correlate the second location with a location of the asset to generate a second correlation (1150). The asset may then determine whether a positive correlation has been provided for the first correlation, and alternatively, for both the first and second correlations (1160). If not, the method may loop back to block 1120. If yes, the asset may grant access to medical records of the patient in accordance with the security access level of the authenticated MSM (1170).
FIG. 12 is a flowchart 1200 of an exemplary method for authenticating a medical staff member for access to the MMS 100 of FIG. 1 according to yet another embodiment. An asset may validate credentials received from a user (such as a medical staff member) through the asset (1210). The asset may capture a biometric of the user through a biometric capturing device (1220). The asset may then send the captured biometric to an authentication server (1230). The asset may then receive a validation of the captured biometric from the authentication server (1240). The asset may then grant a level of access to records of the medical database server according to a security access level associated with the user (1250). The method of FIG. 12 may be combined with the method of FIG. 11 in alternative embodiments.
FIG. 13 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 1300 within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative implementations, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” may also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed in the present disclosure.
Processing device 1302 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 1302 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 1302 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 1302 is configured to execute instructions 1326 for performing the operations and steps discussed herein.
The computer system 1300 may further include a network interface device 1334. The computer system 1300 also may include a video display unit 1308 (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT), or a touch screen), an alphanumeric input device 1310 (e.g., a keyboard), a cursor control device 1314 (e.g., a mouse), and a signal generation device 1316 (e.g., a speaker).
The data storage device 1318 may include a machine-readable storage medium 1324 on which is stored one or more sets of instructions 1326 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 1326 may also reside, completely or at least partially, within the main memory 1304 and/or within the processing device 1302 during execution thereof by the computer system 1300, the main memory 1304 and the processing device 1302 also constituting computer-readable storage media. The instructions 1326 may further be transmitted or received over a network 115 via the network interface device 1334.
While the machine-readable storage medium 1324 is shown in an exemplary implementation to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” may also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “computer-readable storage medium” may accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.
The disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.
a processing device to run a medical cart;
computer-readable memory storing data and instructions for access to a medical database server, wherein the instructions are executable by the processing device to perform biometric recognition on medical staff members;
wherein the processing device is to execute the instructions to:
authenticate an identity of a medical staff member with biometric recognition;
receive a location of the medical staff member from a real-time location system (RTLS);
correlate the location of the medical staff member with a location of a patient; and
grant access to data records of the patient on the medical database server according to a security access level authorized the medical staff member, as authenticated, in response to co-location of the medical staff member and the patient.
2. The system of claim 1, wherein the processing device is further to execute the instructions to receive a location of the medical cart, and wherein to correlate the location further includes to correlate the location of the medical cart with the location of the patient.
3. The system of claim 1, wherein the biometric recognition comprises facial recognition, further comprising:
a camera to capture a first image of the medical staff member;
a database storing second images against which to match the first image using facial recognition software; and
wherein the processing device is further to deny access to the data records of the patient when the first image does not sufficiently match any of the second images.
4. The system of claim 3, further comprising a networked device accessible over a network in which is stored the database and on which is executed the facial recognition software.
5. The system of claim 1, wherein the security access level authorized the medical staff member depends on a role of the medical staff member, and wherein a first role is granted access to more confidential data records than a second role.
6. The system of claim 1, wherein the location of the medical staff member or the patient is received as an indicator from a tracking device, wherein the indicator is at least one of a personal area network (PAN) indicator, a received signal strength indicator (RSSID), or a radio frequency identification (RFID) indicator.
7. The system of claim 1, wherein the processing device is further to execute the instructions to, in response to a failure to correlate the location of the medical staff member with the location of the patient, deny access to records of the patient by the medical staff member.
8. The system of claim 1, wherein the processing device is further to execute the instructions to require second factor authentication of the identity of the medical staff member comprising at least one of: a swipe card; a personal identification number or password; a biometric other than facial recognition; or a decryption key of a public-key cryptosystem.
authenticating, by a processing device incorporated within an asset, an identity of a medical staff member with biometric recognition upon the medical staff member attempting to access a medical database via the asset;
receiving a first location of the medical staff member from a real-time location system;
retrieving a second location of a patient from the real-time location system;
correlating, using the processing device, the first location and the second location as being co-located; and
granting the medical staff member memory access, by the processing device, to identified data records of the patient within the medical database according to a security access level authorized the medical staff member.
10. The method of claim 9, wherein the medical database is stored at a medical database server with which the asset communicates over a network, the method further comprising retrieving the security access level of the medical staff member from the medical database server before granting access.
11. The method of claim 9, wherein the security access level of a physician is higher than the security access level of a nurse, and wherein the security access level of a nurse is higher than the security access level of a specimen collector.
12. The method of claim 9, further comprising denying the medical staff member access to the medical database in response to failure to authenticate the identity of the medical staff member or failure to correlate the first location and the second location as being co-located.
13. The method of claim 9, wherein, to authenticate the identity of the medical staff member, the method further comprising requiring second factor authentication of the identity of the medical staff member comprising any or a combination of: a swipe card; a gesture; a secret shape; a personal identification number; a second biometric; and a decryption key of a public-key cryptosystem.
14. The method of claim 9, further comprising determining the first location from a location tracking device located on the medical staff member.
15. The method of claim 9, further comprising determining the second location from a location tracking device on the patient, on a bed of the patient, or based on a location of the asset.
16. The method of claim 9, wherein the correlation comprises a first correlation, the method further comprising:
determining a third location of the asset;
correlating the first location with the third location to generate a second correlation; and
wherein granting access by the medical staff member to the identified data records of the patient is dependent on the first correlation and the second correlation.
17. A processing device to execute instructions stored in non-transitory computer readable storage medium to:
validate credentials received from a user through an asset to provide access to an authentication system used to authenticate access to a medical database comprising medical information;
authenticate an identity of the user through a first type of user authentication;
determine a level of accuracy of the first type of user authentication;
perform additional authentication of the identity of the user through at least a second type of user authentication until an accuracy level of a combination of the first type and the at least the second type of user authentication exceeds a predetermined threshold level of accuracy; and
grant a level of access to records of the medical database according to a security access level associated with the user responsive to reaching the predetermined threshold level of accuracy of user authentication.
18. The processing device of claim 17, wherein the first type or the at least the second type of user authentication comprises biometric recognition, and further to execute the instructions to:
capture a biometric of the user through a biometric capturing device;
send, over a network, the biometric captured of the user to an authentication server in which is stored one or more biometrics for the user; and
receive a validation from the authentication server authenticating the user based on the biometric meeting a threshold match with a stored biometric.
19. The processing device of claim 18, wherein, upon receipt of the validation from the authentication server, further to execute the instructions to provide the user single sign-on access to applications that access the medical database according to the security access level of the user.
20. The processing device of claim 17, wherein the user is a medical staff member, and further to execute the instructions to:
receive a first location of the medical staff member from a real-time location system;
receive a second location of a patient from the real-time location system;
determine a third location of the asset;
correlate the first location with the second location and with the third location; and
deny the user access to the records of the medical database when the first location fails to sufficiently correlate with the second location or with the third location.
21. The processing device of claim 20, further to execute the instructions to determine the location of the patient from a location tracking device on the patient or based on a location of the asset.
US14/961,743 2015-04-10 2015-12-07 Layering in user authentication Abandoned US20160301691A1 (en)
US14/961,743 US20160301691A1 (en) 2015-04-10 2015-12-07 Layering in user authentication
US20160301691A1 true US20160301691A1 (en) 2016-10-13
US14/961,730 Abandoned US20160301690A1 (en) 2015-04-10 2015-12-07 Access control for a hard asset
US20090226048A1 (en) * 2008-03-05 2009-09-10 Fujitsu Limited Biometric authentication apparatus
US20100153752A1 (en) * 2008-12-16 2010-06-17 Yasumichi Tsukamoto Computers Having a Biometric Authentication Device
US20130283350A1 (en) * 2012-04-18 2013-10-24 Ifat Afek Access authorization
US20140372147A1 (en) * 2013-06-13 2014-12-18 NaviNet, Inc. Systems, methods, and environment for identification and processing of medical events
US20160019889A1 (en) * 2014-07-18 2016-01-21 Google Inc. Speaker verification using co-location information
US9363324B2 (en) * 2004-12-17 2016-06-07 Vid Scale, Inc. Methods and apparatus for geo-collaboration
2015-12-07 US US14/961,730 patent/US20160301690A1/en not_active Abandoned
US20160301690A1 (en) 2016-10-13