Embracing Digital Disruption with HealthTech Interoperability Solutions ✏️
The world is undergoing a profound digital transformation, and healthcare is not absent from this revolution. The health sector is an active participant, leveraging technology to enhance patient care. Technological advancements and evolving patient needs are forcing healthcare organizations to strive for improvement and adaptation, offering more personalized experiences and cost reductions through the adoption of digital solutions.
Fragmented care is one of the most challenging problems to face, with many different systems all trying to exist in the same ecosystem. This is where the role of Electronic Health Records (EHRs) becomes crucial in modern healthcare. EHRs centralize patient information, enabling healthcare providers to access comprehensive records quickly and securely. They provide the capacity to make more informed decisions, reduce medical errors, and improve care coordination.
Technology also democratizes healthcare by introducing telemedicine, remote patient monitoring using IoT devices, AI to assist providers, or even detecting diseases early, as well as medication interactions. The new paradigm of Healthcare IT is characterized by the multitude of systems trying to intercommunicate in a world where creating protocols is as easy as pie. This is why organizations like HL7 promote standardization in the US and around the globe.
In the following sections, we will delve deeper into Epic's EHR, one of the most popular in the United States, and we will explore the most common standards for intercommunicating with it.
Epic EHR & Integrations 🧙
“Founded in a basement in 1979 with three half-time employees, Epic develops software to help people get well, help people stay well, and help future generations be healthier.” - Epic "Our Story" section.
An Electronic Health Record (EHR) serves as a digital repository for a patient's medical history, enhancing not only patient safety through real-time access to critical information like allergies and current medications but also improving providers' overall efficiency and experience. Tasks such as scheduling appointments, ordering labs, and sending prescriptions can be time-consuming, which is why EHRs automate many of these processes, allowing prescribers to dedicate more time to patient care.
Additionally, EHRs facilitate seamless sharing of patient information among different healthcare providers, enabling easy access to patients' medical histories. This not only enhances the quality of care but also drives the development of more sophisticated technologies to enhance these benefits further.
Curious fact: Epic's name reflects its commitment to the comprehensive and evolving narrative of a patient's healthcare journey over time. According to Epic's documentation, an 'epic' is a glorious recounting of a nation's events. Similarly, Epic's electronic health records chronicle the story of a patient's healthcare over time, much like the epic tales of the Iliad or the Odyssey. This concept is detailed further on Epic's website.
Epic is a widely recognized electronic health record (EHR) system utilized in diverse healthcare settings such as hospitals, independent practices, mental health facilities, urgent care centers, retail clinics, payers, and rehabilitation centers, among others. With over 305 million patients having a current electronic record in Epic Systems EHR, it has emerged as a key player in the health tech industry. Its features cater to a variety of needs in day-to-day healthcare operations. A valuable resource for exploring these features is the API documentation, which provides a detailed description of many of Epic's functionalities.
Additionally, Epic's commitment to data security and compliance with healthcare regulations ensures that patient data is protected and privacy is maintained. Epic also continually enhances its capabilities over time. Therefore, it's advisable to consult Epic or their documentation for the most up-to-date information on what is available.
Interoperability 🌐
Security and interoperability are two of the most critical challenges in health tech. While we won't delve deeply into security in this article, please let us know if you're interested in learning about the key aspects to consider when developing a healthcare system in a future blog post.
Interoperability in software can be considered a quality attribute. According to the book "Software Architecture in Practice" by Len Bass, Paul Clements, and Rick Kazman, interoperability is defined as "the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context."
In the case of Electronic Health Records (EHRs), they don't know in advance with whom they will be exchanging information, but they do know that at some point, another system will need to interoperate. This challenge could result in numerous API designs and exponentially increasing implementations trying to communicate with those APIs. This complexity is why standards are crucial in the healthcare scenario. The need for interoperability is clear, but how can we elevate the maturity level of these systems in those terms?
Before diving into the topic, it's essential to introduce HL7 to the conversation. Health Level Seven (HL7) standardizes the exchange, integration, sharing, and retrieval of electronic health information. It comprises a set of global standards widely used for transmitting patient data, including demographics, diagnoses, treatments, laboratory results, and medical images, among healthcare providers, payers, patients, and public health agencies.
These standards are developed by Health Level Seven International, a nonprofit ANSI-accredited organization dedicated to promoting global health interoperability. The organization boasts over 5,000 members from more than 50 countries, highlighting its widespread adoption and impact on healthcare data exchange.
Understanding the necessity for standardization, let's explore the specific protocols that can be used to communicate with Epic.
HL7 v2️⃣
This standard has been the backbone of health data exchange for decades. It is widely used, as it serves the function of allowing data interchange within and across systems. It defines a series of messages and data formats. These messages can range from ADT (Admission, Discharge, and Transfer process) to laboratory results. While HL7 v2 has successfully enabled interoperability, its structure can be complex, and implementations can vary, leading to challenges in integration.
AI-generated example of an HL7 v2 message for patient admission:
MSH|^~\&|SendingApp|SendingFacility|ReceivingApp|ReceivingFacility|20220321120000||ADT^A04|MSGID001|P|2.3|
EVN|A04|20220321120000|||
PID|1|123456789|123456789||Doe^John^^^MR||19800101|M|||123 Main St^^Springfield^IL^12345^USA||(555)555-5555|||S||
PV1|1|O|Consulting|^Physician^|||MED|||||||||1234567890^Last^First^Dr.|||ADM|A0|20220321120000|||
- MSH (Message Header) segment contains information about the message format and structure.
- EVN (Event Type) segment indicates that this is an admission event.
- PID (Patient Identification) segment contains patient demographic information.
- PV1 (Patient Visit) segment contains information about the patient's visit, including the admitting physician and admission date/time.
Here's another example, and you can check out other resources here.
HL7 v3️⃣
HL7 v3 was designed to address some of the limitations of HL7 v2 by providing a more robust and semantically precise standard. However, HL7 v3 adoption has been limited due to its complexity and the significant effort required for implementation. As a result, HL7 v3 has not seen widespread adoption in the healthcare industry.
The main differences between v3 and v2 are, for example, the usage of RIM, the Reference Information Model, which is an object-oriented approach using classes and relationships, and the usage of XML as message encoding syntax.
A common usage for v3 is, for example, HL7 CDA (Clinical Document Architecture). It’s a standard for encoding clinical documents such as discharge summaries, notes, or any clinical report in a structured format (XML).
AI-generated example of an HL7 v3 message for patient admission:
<?xml version="1.0"?>
<PRPA_IN201302UV02 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 ../schemas/HL7V3/NE2013/multicacheschemas/PRPA_IN201302UV02.xsd">
<!-- Message Header -->
<id root="1.2.3.4.56789" extension="EFGH5678"/>
<creationTime value="2024-04-15T14:45:00"/>
<interactionId root="2.16.840.1.113883.1.6" extension="PRPA_IN201302UV02"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="AL"/>
<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="1.2.3.4.56789" extension="EFGH5678"/>
<telecom value="tel:+1-234-567-8901"/>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="1.2.3.4.56789" extension="EFGH1234"/>
<telecom value="tel:+1-234-567-8901"/>
</device>
</sender>
<!-- Message Body -->
<controlActProcess classCode="CACT" moodCode="EVN">
<code code="PRPA_TE201302UV02" codeSystem="2.16.840.1.113883.1.6"/>
<subject typeCode="SBJ">
<registrationEvent classCode="REG" moodCode="EVN">
<statusCode code="active"/>
<subject1 typeCode="SBJ">
<patient classCode="PAT">
<id root="1.2.3.4.56789" extension="123456789"/>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<given>John</given>
<family>Doe</family>
</name>
<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
<birthTime value="19800101"/>
</patientPerson>
</patient>
</subject1>
</registrationEvent>
</subject>
</controlActProcess>
</PRPA_IN201302UV02>
- This HL7 v3 message represents a patient admission event (PRPA_IN201302UV02).
- The message header includes metadata such as message ID, creation time, interaction ID, and processing information.
- The message body contains the control act process for the admission, including the patient's identification, name, gender, and birthdate.
- The <code> element within the <controlActProcess> specifies the type of control act (admission event).
- The <subject> element contains the subject of the control act (the patient being admitted).
FHIR in Healthcare 🔥
Fast Healthcare Interoperability Resources (FHIR) is a standard designed for exchanging healthcare information electronically, with the goal of facilitating interoperability among different healthcare systems and applications. FHIR provides a set of resources and APIs that are easy to implement and use, leveraging modern web technologies such as RESTful interfaces and JSON or XML formats, which make it lightweight and flexible.
This standard supports a wide range of use cases, including mobile health apps, clinical decision support, and population health management, among others. As FHIR gains popularity in the healthcare industry, it is being widely adopted by EHR vendors and other healthcare software developers.
Despite being a standard, FHIR continues to evolve through various releases aimed at improvement. Different FHIR resources have different standard levels, with some being highly developed and unlikely to change in future releases. Some of the FHIR versions you may have heard of include DSTU1 (the first FHIR standard introduced in 2014), DSTU2, STU3, R4, and R5.
As an example, here is an example of an emergency patient admission message using FHIR R5: "NPM hl7.fhir.r5.examples".
{
"resourceType": "Encounter",
"id": "emerg",
"text": {
"status": "generated",
"div": "\u003cdiv xmlns\u003d\"http://www.w3.org/1999/xhtml\"\u003eEmergency visit that escalated into inpatient patient @example\u003c/div\u003e"
},
"status": "in-progress",
"class": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "IMP",
"display": "inpatient encounter"
}
]
}
],
"subject": {
"reference": "Patient/example"
},
"actualPeriod": {
"start": "2017-02-01T07:15:00+10:00"
},
"admission": {
"admitSource": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/admit-source",
"code": "emd",
"display": "From accident/emergency department"
}
]
}
},
"location": [
{
"location": {
"display": "Emergency Waiting Room"
},
"status": "active",
"period": {
"start": "2017-02-01T07:15:00+10:00",
"end": "2017-02-01T08:45:00+10:00"
}
},
{
"location": {
"display": "Emergency"
},
"status": "active",
"period": {
"start": "2017-02-01T08:45:00+10:00",
"end": "2017-02-01T09:27:00+10:00"
}
},
{
"location": {
"display": "Ward 1, Room 42, Bed 1"
},
"status": "active",
"period": {
"start": "2017-02-01T09:27:00+10:00",
"end": "2017-02-01T12:15:00+10:00"
}
},
{
"location": {
"display": "Ward 1, Room 42, Bed 1"
},
"status": "reserved",
"period": {
"start": "2017-02-01T12:15:00+10:00",
"end": "2017-02-01T12:45:00+10:00"
}
},
{
"location": {
"display": "Ward 1, Room 42, Bed 1"
},
"status": "active",
"period": {
"start": "2017-02-01T12:45:00+10:00"
}
}
],
"meta": {
"tag": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
"code": "HTEST",
"display": "test health data"
}
]
}
}
To dive even deeper, here's FHIR's API specification for Epic, the complete FHIR specification, FHIR implementation tools, and its standard levels.
Who is Leading?
Each version of the FHIR standard is carefully crafted and tested to meet the evolving needs of the healthcare industry. This commitment to refinement has made FHIR one of the most widely adopted health data standards worldwide, embraced by healthcare organizations, EHR vendors, and industry stakeholders.
While transitioning to FHIR may initially seem challenging, it offers significant long-term benefits. Its modular approach allows developers to use only the relevant parts of the standard, making it easier to adopt incrementally and integrate with existing systems. FHIR's support for modern formats like JSON and XML, combined with its RESTful architecture, enhances its adaptability and usability without adding unnecessary complexity.
Other than HL7 specifications, Epic offers over 30,000 live interfaces that are worth exploring to find the one that suits your needs the most.
For more information on Epic interfaces go here, and to learn more about Epic Open APIs go here.
Conclusions
In the tale of the Tower of Babel, the diversity of languages led to confusion and division. Similarly, in healthcare, the lack of interoperability creates barriers that hinder communication and collaboration. However, just as the Babel Tower sought to unite people through a common language, interoperability aims to unify healthcare systems through shared standards.
Interoperability is the key to building the modern Babel Tower of healthcare. It requires understanding and working with standards like Fast Healthcare Interoperability Resources (FHIR) to ensure data flow seamlessly between systems. Just as the builders of the original Babel Tower needed to cooperate and communicate effectively, healthcare stakeholders must come together to implement interoperable solutions.
By promoting the understanding and adoption of interoperability standards, we are laying the foundation for a healthcare system where information flows freely, leading to better patient outcomes and improved healthcare delivery. In this way, interoperability is not just a technical requirement but a means to bridge the language barriers in healthcare and build a more connected, efficient, and patient-centric healthcare ecosystem.
Want even more?
Check out our Light-it Integratehr showcase for examples of EHRs and data tools like Redox and Health Gorilla. These examples demonstrate what can be achieved using different APIs to create UIs based on patient data.
If you're interested in exploring other topics such as security, using Sandbox resources as more concrete examples, or learning how to create an Epic app or a SMART on FHIR app, please let us know! We're here to help you delve deeper into these areas.
