Invented by Bhavesh S. Padmani, Matthew A. Valentine, Robert Bossio, Baxter Corp Englewood
In recent years, the healthcare industry has witnessed a significant shift towards digitization and the adoption of electronic health records (EHRs). This transformation has led to the creation of vast amounts of patient data, which needs to be securely managed and accessed by authorized healthcare professionals. As a result, there has been a growing demand for robust and efficient health information management systems (HIMS).
One crucial aspect of any HIMS is the central user administration, which involves managing user accounts, access rights, and permissions across the entire system. In a distributed health information management system, where patient data is stored and accessed from multiple locations, central user administration becomes even more critical.
The market for central user administration in a distributed HIMS is witnessing significant growth due to several factors. Firstly, healthcare organizations are increasingly recognizing the need for a centralized approach to user administration to ensure data security and privacy. By centralizing user administration, organizations can implement consistent access controls and enforce strong authentication measures, reducing the risk of unauthorized access to sensitive patient information.
Secondly, the complexity of managing user accounts and access rights in a distributed environment necessitates the adoption of specialized solutions. Central user administration systems offer features such as role-based access control, single sign-on, and user provisioning, which streamline the process of managing user accounts and permissions across multiple systems and locations. These solutions not only enhance security but also improve operational efficiency by reducing administrative overhead.
Furthermore, regulatory requirements and standards, such as the Health Insurance Portability and Accountability Act (HIPAA) in the United States, mandate the implementation of robust user administration controls in healthcare organizations. Failure to comply with these regulations can result in severe penalties and reputational damage. Central user administration systems help healthcare organizations meet these compliance requirements by providing audit trails, access logs, and user activity monitoring capabilities.
The market for central user administration in a distributed HIMS is also driven by the increasing adoption of cloud-based solutions in the healthcare industry. Cloud-based HIMS offer scalability, flexibility, and cost-effectiveness, making them an attractive option for healthcare organizations of all sizes. Central user administration systems designed specifically for cloud environments enable seamless management of user accounts and access rights across multiple cloud-based applications and services.
As the demand for central user administration in distributed HIMS grows, several vendors have emerged in the market, offering a range of solutions tailored to the unique needs of the healthcare industry. These solutions vary in terms of features, scalability, integration capabilities, and pricing models. Healthcare organizations must carefully evaluate their requirements and select a central user administration system that aligns with their specific needs and budget.
In conclusion, the market for central user administration in a distributed health information management system is witnessing significant growth due to the increasing digitization of healthcare records, regulatory requirements, and the adoption of cloud-based solutions. Central user administration systems offer healthcare organizations the ability to manage user accounts, access rights, and permissions in a centralized and secure manner, ensuring data privacy and compliance with regulations. As the healthcare industry continues to evolve, the demand for robust and efficient central user administration solutions is expected to rise further.
The Baxter Corp Englewood invention works as follows
Centralized user support management in a distributed health information management system.” Support user management can include the generation of permissions data which may be distributed by a central system to one or several local systems. Local systems can execute healthcare information management applications, such as a pharmacy workflow application. Central support users on the central server will need to access the local systems periodically to perform technical support and troubleshooting for the application that is executed by the local system. The central server may provide permission data to the local systems to allow support users access to the local systems with the specific permission identification provided by the support users. The local system can then track support users and establish specific permissions for them.
Background for Central user administration in a distributed health information management system
Distributed Healthcare Information Management Systems” may include multiple local instances of Healthcare Information Management applications that operate remotely on remote nodes in active communication with a server. U.S. 61/975,519 entitled?MANAGEMENT OF MEDICATION DOSE ORDERS? The Provisional Patent Application No. 61/975,519, entitled “MANAGEMENT of Medication Dose Orders”, was filed on Apr. Filed on Apr. The application was filed on Apr.
In such a distributed network, remote nodes can communicate with the central server. Remote nodes can communicate with a central server to perform a variety of functions. Remote nodes may also perform administrative functions. Users of the central node can access the local node in order to perform administrative functions. Remote users can also access the local server to perform administrative tasks. Administrative functions can be related to management, upgrading, development, troubleshooting or technical support.
A distributed healthcare information system (e.g. a host such as a server central, client device or a combination of these) can also use a role-based model. Role-based security models can assign access rights or privileges for individual users. Individual users can access resources on a distributed health information management system by using a username-password combination that is associated with a set of permissions.
For example, in one specific example of a Healthcare Information Management System, local nodes can each execute a client app comprising a healthcare management system to manage healthcare information (e.g. a pharmacy workflow application for preparing dose orders), related to the facility where the local notice is executed (e.g. a hospital or pharmacy). Local users may use username and password combinations to access the system, allowing them to grant specific permissions to the appropriate users. A remote user may require additional access (e.g. a central support at a server central). The support user might not have the local username and password for local client applications.
In the traditional approach, to provide support users with access to a device local, a generic ‘administrator’ is used. All central support users may receive a login to access a local node to perform various functions. It may be impossible to track specific users who are taking actions on the local node, or to manage the role-based model of security for a particular support user. Security may also be compromised if a user with access to a generic administrator login was no longer allowed to access local systems. “In turn, it is necessary to continue developing the role-based model of security for the distributed healthcare management system.
As a result of the above, the present disclosure comprises management of central user permissions on a plurality local nodes which are operative for executing client applications in a healthcare information management distributed system. A central server may establish permission data regarding the access, privileges, rights or other relevant permissions for a support user. Permission data can define a support user’s access level, permissions for specific activities, or other authorizations. The support user can then access the local node’s client application to perform the functions defined by the permission data.
Support users can access remote local nodes that are executing client applications (e.g. the support users could be located with a central node which is distant from a local one). Support users may need to access multiple local nodes in order to perform administrative functions or tasks. The central server can distribute permission data about support users to all or some of the local nodes that are executing client applications in communication with the central server. In the centralized management of users, the permission data for each support user can be sent to every client application running at a local server. This allows a support person to have access to any or all client applications at any local node according to the permissions established at the central node. Modifications to the permissions data for support users can be distributed across a system of local nodes efficiently to allow rapid modification of the permissions data.
The centralized management of users described in this document may offer a number advantages over the traditional methods of facilitating access to users at local nodes. As described above, for example, a generic admin login can be created at a local node to provide access rights that correspond with tasks typically performed by central users. Support users may be required to use the generic administrator login in order to gain access to a local node and make administrative changes. This approach has many drawbacks. The identity of the support user may not be known, as multiple support users can share the same generic administrator login on the local node. Each local system can also have its own general administrator login. Especially for systems that have many local nodes it can be difficult to remember each local administrator login. In addition, because multiple support users might know the login of a local system’s administrator, it may be necessary to change the login if the role of any of those support users who have access to that login changes. It can be difficult to manage, and it may lead to security lapses where unauthorized users have access to valid administrator logins.
However with the centralized administration described herein, a support user can access a node local utilizing unique credentials (e.g. a specific user name and password) so that permissions for the support users may be tailored and/or track the support users performing administrative tasks at a node local (e.g. by logging the activities of the specific user at the node local). The granularity of permissions can be increased in order to give support users more access rights to local nodes. This will also increase visibility about the actions that support users take at the local node. Moreover, as permissions are changed for support users, the local system can be updated efficiently and easily.
In this regard, one aspect of the disclosure is a centralized user management system that can be used in a health information management system. The system can include a remote host device in communication with multiple local devices that each execute a client application that includes a healthcare management application. The system can also include a module for managing support users that is executed on the host device. The support user module can be a memory device with a nontransitory data structure that is computer-readable and stores permission data for at least one support users. The permission data can include an identification of the at least one user in relation to the permitted activities at the healthcare management system. The system can also include a device for network communication located on the host device and in operative communications with the support user module, to transmit permission data to the plurality local devices via the interface network.
A number feature refinements and added features are applicable to the initial aspect.” These features can be used in any combination or individually. Each of the features discussed below may be used in conjunction with other features or combinations of features from the first aspect, but this is not mandatory. In one embodiment, the support module for user management may be configured to receive confirmation from the respective local devices of receiving the permission data sent by the network communication device. The confirmation of receiving the permission data transmitted from the network communication device can include a checksum that is calculated by each of the plurality local devices. Permission data may be transmitted to a local device, which includes a subset that has been modified since the previous transmission. The support user management module, for example, may be operative in determining the subset that has been modified since the last transmission of permission to the given device based at least partially on the confirmation received from the device. The support user module can also maintain a timestamp based on a modification time for the permissions data. This module is then able to determine a subset of permissions data that has been modified since a previous transmission to a given local device, based at least in part on the timestamp. The support user module can also or alternatively maintain a hash in relation to permission data. It is then operative to determine a subset of permission data that has been modified since the last transmission of permission data to a given local device, at least partially based on this hash. The network communication device can also be configured to receive an error message from at least one device local regarding the permission data that was transmitted to this device.
In one embodiment, the network device can transmit permission data at periodic intervals to a plurality of devices local. Transmission of permission data can be at the request of local devices or initiated by the host device. When initiated by the host system, it may provide permission data periodically to a plurality of local devices. The host device can also transmit the permission data from the local devices when the permission data changes.
The support user management module can also include a log that records activity for at least one user. This log is in a format that can be read by humans. The log module can log various activities or data. The log module, for example, may log any changes made to a non-transitory data structure computer-readable in relation to the permission data. The log module can also or alternatively be in operative communications with the network communication device, and log data pertaining to the transmission of permission data via the network interface. The log module can also or alternatively log data about the access of the at least support user to the Healthcare Information Management System. The access data can include the identity of at least one user who is accessing the resource, and the resource that was accessed. The user’s identity may be a user name.
Furthermore if the resource is logged by an individual, then the indication that the user accessed the resource may include a flag indicating whether it contains protected health information. In the following discussion, PHI can include all or some information that identifies a patient. A resource flag that indicates whether the resource contains PHI can be used to determine whether it is PHI. A report may be included in the resource that an individual has accessed. The report could include information about one or more patients. The resource flag indicating whether a resource contains PHI can be generated dynamically based on the data class in the report that is defined to contain PHI. For some resources, such as all resources in a particular location, like a local device, resources can be assumed to include PHI. The resource flag can indicate that some resources contain PHI depending on where they are provided.
In one embodiment, the support users management module can also include a module for editing permission data that is operative to edit the permission data stored on the non-transitory data structure. The permission editing module can be used to modify permission data for one support user or support user group. Access to the permission-editing module can be controlled by a permission ID, so that only specific support users have access.
In one embodiment, permission data can be linked to a username of the at least support user. The user name is then associated with a passcode. In this way, the correct combination of user name and password may be required to access a resource on the local device or host device. Access to a resource on the local device or host device can be determined by the permission ID associated with the username. Access to a resource can only be granted to a user if they have the correct combination of user name and password associated with a Support User that has sufficient permission identification for accessing the requested resource. The user name can be linked to a specific individual user. The disadvantages of sharing administrator login information described above can be reduced.
In one embodiment, the nontransitory computer-readable structure can store at least a support user group. Permission data may be associated with a support user group. Permission data may apply to all members of the support group. The at least one user of support may be a part of the group, so that their user name is linked to the group. The support user group can be given task-specific permission identifications.
One possible permission definition may define a class of data that is accessible to at least one support users. The data class could be defined, for example, as data that contains PHI or does not contain PHI. A permission identification can be chosen to identify that at least one user of support is only authorized to access data classes that do not contain PHI. The support user could be prohibited from accessing PHI-containing data. A permission identification can be used to identify that at least one support users is authorized to have access to the data class containing PHI. Then, the support user can access PHI-containing data by providing this permission identification.
In one embodiment, permission data can include at least a permission identification for accessing a local device resource and a permission identification for accessing a host device resource. Permission data can include identifications of both the host device and local device within the healthcare information system. Permission identifications can be unique to a node of the system that a support user has accessed.
In one application, a host device can be a central server for a healthcare management system. The plurality of local devices could each have a pharmacy workflow application to prepare doses that will be administered to patients. Permission identifications may be related to tasks that are associated with the preparation of a dosage and/or tasks in relation to the management of dose orders records within the pharmacy workflow application.
In the application the central support user-management to a Healthcare Information Management System that includes pharmacy workflow applications, the central servers and the plurality pharmacy workflow applications may not be affiliated. The central server, for example, may be managed or executed by the provider of the healthcare management application that is executed on the local device. The central server can have multiple support users who may be able to access the local device in order to provide technical assistance for the application. The at least one user of support may therefore be located remotely from the plurality local devices.
Click here to view the patent on Google Patents.
Leave a Reply