Patent Application
20210265047
In a workplace, such as an office or a hospital, it is common for one or more software packages or online services to be provided by the employer to facilitate the work done by workers.
In many cases, these software packages or online services maintain per-user accounts or profiles. For example, an email client maintains an account for each email user that stores email messages received and sent by the user, address book information for the user, and credentials needed by the user to use the email client and access his or her account.
As another example, a particular employer may use payroll software to manage payroll payments to workers. The payroll software has a profile for each user containing information such as name, social security number, salary level, number of income tax exemptions claimed, and a history of payments made and taxes withheld.
As a third example, a hospital or group of hospitals may use an electronic medical record or electronic health record system (“EMR”) in its operations. The EMR maintains a provider profile for the medical providers (e.g., doctors, nurses, nursing assistants, physical and occupational therapists, and radiographers) who are employed by or otherwise operate in the hospital(s). Information stored in such a provider profile can include demographic, licensure, scheduling, billing, ordering, admitting, and attending information about each provider.
When a new worker is hired, it is typical for information technology and/or human resources workers to manually create accounts and profiles for the new worker for any software package or online service that's needed to facilitate the worker's work and effectively manage the worker. This process is sometimes called “provisioning.”
The inventors have identified disadvantages with conventional approaches to performing worker provisioning. In particular, establishing worker profiles and accounts manually, such as by typing or copying-and-pasting information about a new worker into a new profile or new account form displayed by the software package or online service is error-prone, and is often experienced as unrewarding work. Further, manual provisioning can take an unreasonably long time—such as weeks—during which a new worker must find a way to do his or her job without access to resources generally deemed to be important tools. This is particularly true in workplaces where: the flow of new workers is significant; the number of profiles and accounts that must be created for each worker is large; and/or too few people are assigned to create profiles and accounts, or the people assigned to create profiles and accounts are assigned additional responsibilities that compete with this task.
In the case of hospitals and other healthcare organizations, the inventors have discerned that having a new provider for whom an EMR provider profile has not been created interferes with the provider being scheduled to serve patients; the healthcare organization billing for the provider's services; the provider supervising others; etc. Thus, despite having hired, begun paying, and otherwise initiated a new provider, the healthcare organization is largely deprived of their assistance, which may affect the quality and volume of care provided to patients overall by the healthcare organization, provider cost-efficiency, etc.
In response to the inventors' recognition of these disadvantages, they have conceived and reduced to practice a software and/or hardware facility for automatically provisioning new providers in an EMR or other system (“the facility”). For example, in some embodiments, the facility automatically adds Schedulable Epic Resources (“SERs”) to the EPIC EMR system from Epic Systems Corporation. In various embodiments, the facility provides similar functionality for a variety of other EMR systems, including, for example, CERNER ELECTRONIC HEALTH RECORD from Cerner Corporation, ECLINICALWORKS EMR from eClinicalWorks, OPENEMR from OpenEMR Foundation, Inc., and PRACTICE FUSION EHR from Practice Fusion, Inc.
In some embodiments, the facility accesses information about every worker stored in a worker identity management system, such as THE SAILPOINT IDENTITYIQ system from Sailpoint Technologies Holdings, Inc. (Identity management systems are sometimes referred to herein as “IM systems,” “IMSs,” or “IMs.”) In various embodiments, the facility uses a variety of other IM systems, including, for example, MICROSOFT AZURE ACTIVE DIRECTORY from Microsoft Corporation, ORACLE IDENTITY CLOUD MANAGEMENT from Oracle Corporation, WORKFORCE IDENTITY from Okta, Inc., and INTELLIGENT IDENTITY PLATFORM from Ping Identity Holding Corporation. In various embodiments, populating the IMS is already a business process of the organization employing the workers and/or is performed automatically or semi-automatically; some or all of the information stored in the IMS that is used by the facility is used in the IMS for other purposes; etc.
In particular, for each worker, the facility uses business rules to determine from information about the worker's role stored in the IM system whether a provider profile should be created for the worker in the EMR system. In cases where the facility determines that the a provider profile should be created for the worker in the EMR system, the facility uses business rules to identify, again based on information about the worker's role, which fields of the provider profile should be populated for the worker. The facility then uses mappings from IMS fields to the identified EMRS fields to generate field/value pairs for the identified EMRS fields for the worker from information stored about the worker in the IMS, and calls the EMRS to create a new provider profile having the generated field/value pairs. The EMRS returns a provider profile identifier for the created provider profile. The facility uses this provider profile identifier to retrieve the created provider profile from the EMRS. The facility verifies the correctness of the retrieved provider profile, and causes it to be stored in the IMS, where it and its contents becomes available for retrieval along with other identity information stored for the worker by the IMS.
By performing in some or all of the ways discussed above, the facility shifts significantly earlier the time at which new providers are active in an EMRS, and thus the time when these providers can fulfill their work responsibilities. The facility also reduces the level of manual effort needed to create EMR provider profiles, and reduces the erroneous information contained by these provider profiles.
Also, the facility improves the functioning of computer or other hardware, such as by reducing the dynamic display area, processing, storage, and/or data transmission resources needed to perform a certain task, thereby enabling the task to be permitted by less capable, capacious, and/or expensive hardware devices, and/or be performed with less latency, and/or preserving more of the conserved resources for use in performing other tasks or additional instances of the same task. As one example, by automating the process of creating provider profiles, the facility reduces the level of processing resources and network bandwidth required to create provider profiles in a way that is more manual.
Next, the intermediary system 202 reads the created provider profile 214 from the electronic medical record system, such as by using the provider profile identifier returned by the electronic medical record system. The intermediary system then stores information 215 from the created provider profile in the identity management system. At any subsequent time, a user can review the information 216 from the created provider profile as stored in the identity management system.
In some embodiments, the facility uses provider profile creation business logic to perform acts 303-305.
While
Returning to
Returning to
/2018/Core/DataUtility/ImportData/ImportData?ImportSpecificationID passing the mapped EMRS field/value pairs. In some embodiments, the facility includes a user identifier already associated with the user in the identity management system among the field/value pairs passed by the facility in the provider profile creation call in order to connect the new provider profile to the user in the identity management system. In some embodiments, the facility instructs that this IMS user identifier be stored in a Text Grouper Two field 2901 of the EMRS.
In act 308, in response to the call of act 307, the facility receives from the EMRS a provider profile identifier that identities the provider profile created by the EMRS. In act 309, the facility uses the provider profile identifier received in act 308 to retrieve from the EMRS—from the EMR database, through the EMR interconnect server—the created provider profile. In some embodiments, the facility performs act 309 using a RunQuery API of the EMRS, a SOAP endpoint having the URI:
In act 310, the facility verifies the accuracy of the provider profile retrieved in act 309. In act 311, the facility populates the provider profile and its identifier to the EMS for the new user, such as by using the identity management system's user identifier for the new user. In some embodiments, the facility performs act 311 by calling an API on an IMS server in order to write the data to an IMS database. After act 311, the steps conclude.
Those skilled in the art will appreciate that the acts shown in
In some embodiments, the facility performs a bulk read of provider profiles from the EMRS, and reformats this data into a common format for loading into the IMS. In some embodiments, the facility does so by using a script executing on a script server to read the data from the EMRS data store, transform the data as appropriate, and write it to a custom table within the IMS DB with the following columns:
The various embodiments described above can be combined to provide further embodiments. All of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet are incorporated herein by reference, in their entirety. Aspects of the embodiments can be modified, if necessary to employ concepts of the various patents, applications and publications to provide yet further embodiments.
These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.
