Electronic Health Record systems (EHR) are the digital version of a patient’s paper charts that get shared among care providers. They’ve become the standard in the healthcare industry for recording and managing a patient’s medical history, laboratory results, and medications. Also, EHR systems allow healthcare providers to access those patient records securely and automate and streamline their workflows. As these systems become more widely-adopted, the healthcare software company, Epic has risen as an industry leader in EHR solutions. According to John Hopkins, Epic is the preferred system in the U.S.—over 45 percent of the population has their medical records in an Epic system.
Healthcare companies now have an opportunity to leverage Epic’s widespread success to streamline and standardize care across the entire health system. However, Epic integrations for healthcare systems aren’t always straightforward, as two hospitals may configure and use their EHR systems entirely different from each other. Moreover, due to your enterprise application’s sheer size, many events, activities, and messages are available to leverage one-way or two-way integration points.
The complexity of your Epic integration ultimately depends on what information other systems need to send or receive. As such, we always start with three critical considerations when guiding Epic integration projects for our healthcare clients.
Identifying key events and messages
Epic usage among hospitals or healthcare providers can differ based on what functionalities and data fields are used, and the values entered into those fields. For instance, a user may populate a data field intended to store and reflect a unique identifier for a doctor with a National Provider Identifier (NPI) managed by the National Plan & Provider Enumeration System in one hospital. Another hospital may opt to use an Epic Identifier managed by Epic. Both identifiers can be used to pinpoint a doctor or medical of the medical staff. However, the choice of what data goes into which fields depends on the hospital and their standard operating procedures.
As a result, coordinating with a hospital to identify key events and messages. The goal is to understand what information is provided or resides in Epic, what information needs to be sent or other systems, and what data need to be received or processed by Epic.
Understanding the flow of data between the systems paves the way to identifying what system events will trigger sending a message in either system and map the data within a message to the destination system.
Depending on the system integrating with Epic, patient data may need to be updated or changed. Agreeing on what changes need to occur within the Epic system or how the other system handles the message data’s contents is the first step to establishing the big picture. Moreover, this type of analysis can build the foundation for establishing an integration guild for integrating Epic with other systems in the future.
Understanding message specification
Once the events and related messages have been identified, it’s essential to understand the message type and its contents. Like many other EHR systems, Epic uses Health Level Seven International (HL7) specification to format its messages. HL7 is currently the international standard for transferring clinical and administrative data between software applications.
Although Epic uses the HL7 standard, it uses the specification differently. For instance, a field referring to “Placer Order Number” can be a string or integer in the base HL7 message. However, Epic will require that field to be an integer since Epic order numbers are numeric under a medication ordering event. Several other data fields have similar restrictions than the base HL7 format, which doesn’t enforce value types.
In the same fashion, not all data fields in the HL7 specification are used by Epic; this goes back to the initial data-mapping point mentioned earlier. As a result, it’s important to be aware of the data fields Epic uses to generate a message and the data fields that Epic uses upon receiving a message, ahead of implementation. The Epic documentation highlights those specifications.
Getting a grip on message handling
Now that we understand the subtle differences in message standards, we begin to uncover the challenges in sending messages between systems. Epic already had endpoints for sending and receiving messages in HL7. Notwithstanding this fact, error handling is required to account for message failures. Message failure may relate to, but is not limited to, the infrastructure and the medium in which messages are sent. Consequently, a system receiving an HL7 based message from Epic will need to parse the incoming message to extract the associated fields’ data. Handling the data parsing and error handling is achievable programmatically. However, existing tools address and manage the cases mentioned above.
NextGen Connect (formerly Mirth Connect) is an open-source, cross-platform HL7 interface engine that enables bi-directional sending of HL7 messages between systems and applications over multiple transport types. NextGen Connect facilitates defining rules for where a specific message from one system goes to another system. In light of possible message failures, NextGen Connect can also handle retries and duplicate messages.
In the distributed system domain, messages from a system can be fire-and-forget while other systems will need a response or confirmation that a message was delivered successfully. Both scenarios are taken into account and handled by NextGen Connect.
Other tools contend with NextGen to cover the scenarios presented. Still, the main takeaway here is that you don’t need to venture to recreate functionality or address a problem that has already been solved.
Epic integration as a milestone in healthcare modernization
Successful Epic integrations are primarily based on identifying the system’s event that will trigger the sending of messages to other systems. Determining what messages the Epic system will be receiving from other systems and how Epic processes those messages is also necessary. The message’s contents must be understood to ensure the mapping of data fields between systems is accurate and transformed if necessary. Coupled with message sending and receiving is the notion of using other tools to take advantage of file parsing, error handling, and retries.
Overall, system integration leads toward modernization. In the healthcare arena, that could mean adding another layer of accountability and ensuring data correctness by limiting the manual entry of data from one system to another. Data entries of that manner can be critical when lives are on the line. Not to mention, there is the added benefit of creating better reporting and reconciliation procedures. If you do decide to integrate your medical systems with Epic, addressing the considerations above can make the entire process less complicated. Carefully reviewing your data and messaging specs upfront can set a team up for success and make this major step towards healthcare modernization attainable.