OpenEMPI vs OpenDJ/OpenAM for providers’ authorization and ActiveDirectory
How to Host other Vendor’s SMART on FHIR App within your System?
As the industry is moving rapidly towards SMART on FHIR adoption. Some healthcare vendors are not only writing host SMART on FHIR applications but also developing host environments to allow hosting of other vendor’s SMART app. It’s no more only Epics and Cerners who are providing SMART on FHIR App integration options to other vendors.
At Technosoft, we help our customers with their SMART on FHIR presence on both ends. This article provides info about some basic building blocks needed to allow hosting another vendor’s SMART on FHIR Apps.
First some background about OpenEMPI vs OpenDJ/OpenAM
For OpenEMPI, in order to collect and manage clinical records of the patient, it is of most importance that the organization is able to identify each patient accurately whose data is collected from multiple sources. Open Enterprise Master Patient Index (OpenEMPI) is a repository used by healthcare organizations that maintains a registry of all patients and their demographics across an enterprise by assigning a unique identifier to each patient. It is intended to ensure that patient data is correct and consistent throughout the system. It can also resolve duplicate records in the system.
OpenEMPI as ActiveDirectory
Active Directory provides authentication and authorization mechanisms as well as a framework within which other related services can be deployed (AD Certificate Services, AD Federated Services, etc). It is an LDAP compliant database that contains objects. The most commonly used objects are users, computers, and groups. These objects can be organized into organizational units (OUs) by any number of logical or business needs. Group Policy Objects (GPOs) can then be linked to OUs to centralize the settings for various users or computers across an organization.
Technosoft analyzed the requirement of using OpenEMPI as an active directory for patients within our platform and concluded that it is not feasible to do so because there is no REST API available in OpenEMPI that authenticates the patients who reside in the registry. However, it does offer an API that authenticates administrators only(users of the OpenEMPI web portal).
Therefore, Technosoft would recommend using OpenDJ(an open-source project building LDAP and REST base directory services) to store both patients and providers. OpenDJ also has the added advantage of seamless integration with OpenAM which would provide a fine-grained authentication layer. Technosoft can define custom attributes within the directory in order to differentiate between patients and providers.
Providers’ Authorization with OpenDJ/OpenAM
When a user wants to access an application protected by AM/OpenAM, they supply credentials (such as user name and password) to log in. These credentials are then validated against the ones held in the Credential store (authentication); if they match, the user successfully authenticates to AM/OpenAM and the user profile is retrieved if an Identity data store is configured.
Technosoft configured an instance of OpenDJ, seeded it with a few providers and was able to integrate the instance with OpenAM by providing the relevant configuration parameters as well.
Technosoft also tested a couple of authentication flows and they worked as they were expected.
SMART Integration with our platform
SMART on FHIR is a set of open specifications to integrate apps with Electronic Health Records, portals, Health Information Exchanges, and other Health IT systems. In order to enable SMART on FHIR capabilities for the platform, we can make some changes in specific modules of the platform.
Integration with OpenAM
1. Changes to /authorize endpoint
To make the host environment, We need to change the behavior of the authorize endpoint by including the following changes:
For simulating the EHR launch SMART on FHIR App
- We design a webpage for developers in order to create a launch context for them (the concept is quite similar to what other EHRs provide in their sandboxes). This launch context and its associated data would be stored in our FHIR server. The launch context would get a unique identifier.
- When a request would be sent to the authorize endpoint with a launch query parameter containing the unique identifier, our OpenAM server would communicate it with the FHIR server. It would retrieve the context’s associated data and pass this information to the token endpoint.
- The “aud” query parameter can only point to our FHIR server. Other values would be rejected. This is done so that developers are not able to leak a genuine token to a counterfeit server.
For standalone launch
- Handle the scopes passed in the request.
- Rename the scope “profile” to “fhirUser” as “fhirUser” is regarded as more appropriate by the standard.
- When a practitioner logs in, show a patient picker so as to make a patient available in the current context.
- When a patient logs in and there is an encounter requested, just randomly choose one and make it available in the current context.
2. Changes to /token endpoint
We need to modify the response that results from the token endpoint. The following changes are required:
- Add the context parameters alongside with other nodes inside the response body.
- Modify the access token to include context parameters.
- Modify the id_token to include the FHIR mapping of the authenticated user. We would need to use the script that is available inside OpenAM out-of-the-box.
Integration with OpenDJ
Add a custom attribute
Add a custom attribute named “fhirUser” to store the FHIR resource mapping for provider/patient in our OpenDJ instance.
Integration with an FHIR server
1. Write a custom interceptor
We need to develop an interceptor to capture every request passed to an FHIR server. It would perform the following functions:
- Verify the JWT passed in our request header by invoking the /introspect endpoint in our OpenAM server.
- Make sure that the request doesn’t intend to perform anything outside of its token’s scope.
2. Develop Create/Read endpoints for launch contexts’
We need to store the launch context in our database in case developers want to simulate the EHR launch. Whenever the OpenAM server would require a launch context, the FHIR server must be able to return it.
With this demo level set up, you can see the basic building blocks of a SMART on FHIR hosted environment and some of the technologies available that can be used to set this up.
If you are looking to develop a SMART on FHIR App to be hosted in Epic, Cerner, Allscripts or any other vendor’s environment, please see our other blogs on SMART on FHIR or contact us.