Contact Our Experts
We’ve been seeing lots of questions on social media and in personal conversations about how to build and integrate third-party user-facing applications into Epic’s ecosystem and other EHRs. There are many options and flavors of such integrations, leading to a lot of confusion. We’ve been developing and integrating applications with EHRs for many years soI thought I’d try to demystify and summarise the topic and discuss available options.
I include a number of topics that are general and are not specific to integration with EHRs, but are frequently asked about and discussed as they significantly affect application workflows, and available integration options.
This document is using Epic as a basis. Many of the topics discussed here are EHR-agnostic.
Depending who is the target audience for the application, the workflow and the integration options are somewhat different.
We generally classify these users in three groups - patients, providers, and everybody else (hospital administration, researchers, etc.). We will review and discuss the workflows and differences for each of these groups further in this document.
This topic is ubiquitous but very relevant here as it is deeply connected to integration options.
Depending on the specific goals of the application and organizational needs, there are two hosting options to consider: on-prem, or external - in the cloud.
“On-prem” means hosting internally, within organizational firewalls. This may be in a private data center, or in the private cloud, which many organizations now have.
External application hosting usually means deploying the application with a cloud provider, typically with one of the big three providers - AWS, Azure or Google Cloud. Of course there are other hosting options - like Oracle and many others.
There are a number of significant differences between the above two options from an organizational and logistical perspective.
Hosting an application externally has its own opportunities and challenges, among them:
Organizations must agree to expose their data and interfaces to an external application
There are basically two types of applications we are dealing with today - Web applications and native mobile applications. We rarely see a strong interest in desktop applications (e.g. Windows, MacOS) nowadays.
Both types of applications typically have a server side (also referred as the back-end) and a client side. When we separate applications into two above types, we really are mostly talking about the client side as either types may have the same back end.
The client side of a Web allocation is running in the browser, also known as a “thin client". There is nothing to install for the user, as long as there is a browser available. Users just need a URL to enter into the browser and launch the application.
Mobile applications run on mobile devices. Mobile applications can also be Web applications with look-and-feel tailored to a specific mobile form factor. In the context of integration with Epic, they are just Web applications, the integration is largely the same for all form factors.
Unlike for a Web allocation that runs in the browser that is usually present on the device, the client side of a “native” mobile application has to be installed on the device. The native clients are also operating system-specific, which means that we need two versions of a native mobile client implemented - for iOS and and for Android (ignoring fringe OSs here). Native clients are also known as “fat clients” as an alternative to “thin clients”.
Summarising differences between two type of applications:
Looking forward, in the majority of use cases a thin client (Web) application is much more attractive than a fat-client application. We see very few reasons to develop native mobile applications.
There are two distinct and different types of integrations that we need to think about - data-level integration and user-interface level integration. The data-level integration is where the external application shares data with Epic via (mostly) standard interoperability APIs and protocols - like HL7 V2 or FHIR. I say “mostly” because Epic used to have a proprietary API, now largely deprecated, except for a few Epic-specific interfaces, such as for in-basket messaging - Epic’s internal email equivalent.
The back-end data-level integration from a technology perspective is largely identical regardless of the options and very well addressed. We are not spending much time discussing it here.
Let’s separate the topic of UI-integeration into two topics - ability to invoke (launch) an application from Epic and Single Sign On (SSO) - in the discussed context, logging into Epic and having access to the external applications without a separate login in. This also includes sharing patient and user context between Epic and the external applications.
The differences and options for the UI-level integration largely depend on who the user is - a patient or a provider. The integration options and the workflow for these two classes of applications are substantially different. There are of course “anybody else” users, but the focus are usually on providers and patients and the variability of workflows and options for “anybody else” users are so wide that we are leaving these users out of this conversation for now.
For patient-facing applications, SSO means that patients can log in into the external application with their MyChart (Epic’s patient portal) credentials - if they have a MyChart account of course, which is not always the case.
Patients who have a MyChart account can access an external application in one of two ways - as a standalone, or from MyChart portal. For the later case, they will see a corresponding icon for the external application in MyChart. These two different forms of access affect the authentication workflow for the patient. With the application exposed within the MyChart portal, the patient is already logged in and authenticated, no extra steps are required to open an application other than just clicking on the application icon. I am simplifying a bit here, one thing to consider is that MyChart portal is a Web application, there are no additional steps required only if the external application is also a Web application itself.
The authentication/authorization workflow for standalone applications is different. First, patients need to get access to the application. Depending if this is a Web application or a native (e.g. iOS or Android) application, they need to get the application URL, or install it on their device respectively. Once they have access to the application, they need to authenticate into it using MyChart credentials.
Epic supports multiple authentication methods, most notably SAML and SMART-on-FHIR. SAML is primarily concerned with user authentication and authorization by transferring identity information between systems, while SMART on FHIR focuses on enabling healthcare applications to securely access and exchange patient data with Epic using the FHIR standard. The user experience while using these methods is similar to logging into an application via Facebook or Google. The external application does not have access to the user credentials, the handshake is taking place via the Epic-provided login screen, after which the application obtains an authentication token with limited lifespan.
Note that the same application may be accessed as a standalone as well as invoked from MyChart portal.
When we talk about provider-facing applications, we mostly assume that these applications are invoked from Epic Hyperspace as Hyperspace is where providers spend most of their day - when they are looking at the computer screen, of course. This dictates how to implement the SSO and how to configure Hyperspace to invoke the application.
The provider applications however, may be used standalone as well without invocation from Hyperspace, in which case the SSO could be implemented with provider organizational credentials via integration with the organization’s identity management system, like Active Directory. The back-end data-level integration with Epic can still exist with standalone applications; it is mostly independent from how the application is invoked.
Mobile applications obviously can’t be invoked from Hyperspace, they can utilize Smart-on-FHIR or SAML protocols from the mobile devices - much like patient mobile applications, except we assume that providers always have an Epic account, unlike with a patient who may or may not have a MyChart account.
Since we rarely see the need for native desktop applications (e.g. Windows or Mac applications) to be integrated into Hyperspace, we will talk about integration of Web applications into Hyperspace.
Epic Hyperspace can host a browser control which can run third party applications. There is a legacy way to invoke and provide SSO with Epic and a “modern”, standard way to do it. In both cases the external Web application will live in the browser control.
The legacy way still works, it is simple and does not require Epic involvement or additional payments, not a lot of people know about it since it is not promoted by Epic anymore. It entails capturing the URL of the external application and the context to share (e.g. user, patient MRN, and more) within Epic Activity.
The Epic-promoted “standard” SSO and context sharing with Epic using SMART-on-FHIR or SAML, requires registering an application with Epic vendor program, obtaining corresponding client ids and keys and (in some cases) paying Epic. The application will be available in Epic Showroom, which is similar to Google and Apple App stores.
There is a frequent and obvious need to build an application once and make it available to users at multiple institutions and sites. Here are the options and considerations for multi-site integration.
Applications most likely need to be hosted outside of any of the target institutions in an external cloud. There is a slim chance that one institution will agree to host an application that serves other institutions and deals with data for other institutions.
Multitenancy
An application is multitenant if it serves multiple different sites allowing for some limited differences in appearance, workflow and features. Typically, a multi-tenant application has a single code base serving all sites. Running multiple retail stores within Shopify is a good example of multitenancy.
Multiplicity
When sites have significantly different requirements, workflows, data models, deployment and security requirements it is difficult to combine it all within a single multi-tenant instance of an application. In such cases we can just deploy multiple instances of an application, one for each site, and customize them independently for each site. Note that having a single codebase with multiple different instances is virtually impossible.
The stakeholders have to make a decision if there will be a single multitenant application that serves multiple sites or multiple independent applications dedicated to each site.
Multitenant applications must deal with multiple user identities at different institutions, but more importantly - with storing and operating on patient data from multiple institutions securely and independently. It would be very unfortunate if patient data would accidentally be mixed up between different institutions.
Other important considerations are:
Multiplicity is easier and safer, but usually more costly and laborious. For example, every common new feature and upgrade must be implemented and deployed separately for every application instance. With modern containerised and automated deployments and source control frameworks this is not such a significant challenge anymore.
There are a lot more details related to integration of third-party applications into Epic and other EHRs. We tried to address this topic at a high level in this document, hope it has been helpful to resolve lots of confusion about the topic. Let us know if you see anything missing, have questions, and what else you wish to cover - happy to assist!