Clinical information systems provide tremendous benefits to healthcare by improving quality, workflow, and efficiency of care. But the accelerating digitization of healthcare has created complex information architectures composed of large enterprise systems such as the electronic health/medical record (EHR/EMR) and a multitude of specialty clinical systems. It is not unusual for large healthcare provider organizations to have 400 or more different clinical IT systems and with the trends of continued specialization and digitization this is only going to increase this complexity.
Interoperability is both a prerequisite for continued innovation in digital models of care and a major challenge facing healthcare providers today. This is not a new problem, and it has been addressed since the 1980s with HL7 v2 messaging based integrations that have become the lifeblood of electronic health communication. HL7 v2 integrations are still ubiquitous for patient admissions, discharges, transfers, orders and results. However, as the complexity of digital health systems has increased, so has the need for integration – pushing the limits of a 30-year-old integration approach.
Fast Healthcare Interoperability Resources (FHIR) is now the latest interoperability standard from HL7 and is being widely adopted across the industry. FHIR is best known for bringing a standardized RESTful API specification for interoperability to healthcare. However, FHIR also specifies a messaging framework to satisfy asynchronous use cases and with it the potential to modernize and dramatically improve upon the current state of HL7 v2 messaging-based integrations.
Challenges with current HL7 v2 messaging
One of the biggest challenges of HL7 v2 is the variation of implementations and its extensibility mechanism. This means every HL7 interface has to be adapted and comprehensively documented, making new integrations and maintenance complex and labor intensive. The specialist skill set required to navigate HL7 v2 and the complexity of existing integrations that often only few people in an organization can navigate also create bottlenecks that slow down innovation.
Next generation healthcare interoperability with FHIR messaging
The philosophy behind FHIR is to build a base set of resources that satisfy the majority of common use cases for exchanging electronic health records, either by themselves or combined. FHIR has proven particularly popular for RESTful integrations enabling standards based synchronous integrations in healthcare. However, FHIR also defines an event based integration pattern using resource bundles as FHIR messages much like HL7 v2.
Early examples of FHIR messaging implementations have focused on cross-organizational event communications. Cedar-Sinai, a large healthcare provider network in the U.S., has implemented FHIR Messaging to support Event Notification for Payer – Provider Communication following the HL7 Da Vinci specification for unsolicited notifications.
Numerous FHIR Messaging initiatives are also underway at the National Health Service in the U.K. under its National Events Management Service. It specifies FHIR messaging based event publish/subscribe services for programs such as child health, vaccinations, pathology messaging, and more.
FHIR event-driven APIs with AsyncAPI and MuleSoft
FHIR Messaging is focused on defining a standardized representation of the message payload, message events and acknowledgement patterns. However, the delivery mechanism, protocol and architectures to enable FHIR Messaging are explicitly out of scope for the standard. This is where the AsyncAPI open source initiative becomes interesting as it seeks to make working with Event Driven Architectures as easy as it is to work with REST APIs today. It starts with standardized documentation much like OpenAPI or RAML does for REST APIs but also includes code generation, discovery and event management.
MuleSoft is an active contributor to the open source AsyncAPI initiative and we implement it as part of the Anypoint Platform. We are extending our existing messaging capabilities, which is used by many customers including large scale HL7 v2 implementations, with new innovative functions for event-driven APIs.
MuleSoft features for FHIR event-driven APIs in healthcare
In the first release of MuleSoft’s event-driven API functions, we are extending API Designer with the ability to create and publish AsyncAPI specifications. This is now generally available to all customers without extra costs. Subsequent, upcoming releases will complete our vision with functions that support governance and monitoring providing a fully integrated platform to manage the entire lifecycle of both RESTful and event-driven APIs
Event-driven API specifications
RESTful FHIR implementations already benefit from state of the art tooling to define implementation guides and describe APIs through widely adopted tools like OpenAPI or RAML. In the HL7 v2 messaging world this doesn’t exist and relies on proprietary interface engines, paper documentation and highly sought after HL7 integration specialists. This makes HL7 integrations very time consuming, expensive, and therefore a significant hurdle to improve interoperability between clinical systems.
The Async API specification, as for example implemented in MuleSoft’s API Designer, allows developers to easily describe event-driven APIs for FHIR Messaging in the same way as they would for RESTful APIs with RAML. Existing FHIR resource specifications, e.g. that which is provided in MuleSoft’s Accelerator for Healthcare, can be reused to structure the event payload.
Channels define the medium of event transportation. Publish and subscribe are the key verbs (similar to GET or POST) that define the supported operations. Channels are then bound to a server and the specific protocol implemented by the server such as JMS, MQTT or Kafka.
The event schema defines the structure of the payload, the format a publishing system is expected to deliver event messages in as well as the payload a subscribing system can expect. For a FHIR messaging implementation the schema will consist of a FHIR resource bundle.
The AsyncAPI specification also supports automated documentation of the API and MuleSoft implements this with the ability to publish the API to Anypoint Exchange, our developer portal.
Discoverability
Large healthcare organizations often have hundreds of systems and integrations between these systems which creates a significant amount of complexity. Today, documentation of these HL7 integrations generally relies on hundreds of pages of separate documents that have to be manually created and kept up to date. Often only a handful of people in the organization can traverse this complexity, creating a significant bottleneck for new integration initiatives.
API catalogs and developer portals have successfully addressed this challenge for RESTful APIs and the same benefits can now be leveraged for event-driven architectures. MuleSoft’s Anypoint Exchange allows developers to easily navigate an organization’s event-driven APIs, the channels through which to publish and consume events and the schema of payloads. It also allows brokers to be associated with these APIs, such as for example a specific topic on a Kafka cluster, making it much easier for developers to navigate existing message streams.
Bridging the gap between HL7 v2 and FHIR messaging
It will take years, if not decades, for existing healthcare integrations to fully migrate from current HL7 v2 based integrations to FHIR messaging. Designing a future-proof architecture that allows for coexistence of legacy and modern integration standards is essential.
MuleSoft offers powerful tools for HL7 v2 messaging with its HL7 MLLP connector, HL7 schemas, and parser. This has already allowed multiple large healthcare organizations to orchestrate their HL7 v2 messaging with MuleSoft as its integration engine.
MuleSoft customers also have access to the Accelerator for Healthcare, which includes a HL7 v2 to FHIR transformation template. It supports the most common HL7 message formats with mappings to FHIR bundles according to best practices provided by HL7 with the ability to extend it to support custom fields and segments.
The transformations use MuleSoft’s DataWeave engine and are highly performant at scale. This will allow organizations to adopt a modern event-driven API architecture using MuleSoft to perform data transformations between different HL7 versions at the publisher or subscriber level.
A vision for event-driven APIs in healthcare
The continuing digitization of healthcare demands a high level or integration capability from healthcare provider organizations to deliver tangible operational and clinical benefits.
Today’s healthcare integrations are still dominated by HL7 v2 messaging, a 30+ year old standard. While specialized HL7 integration engines have emerged over time, they have only marginally improved the situation, and interoperability remains one of the biggest challenges for healthcare providers to reap the benefits of digitization.
Three converging trends are now giving healthcare providers the opportunity to transform interoperability within and beyond their organizations.
- Widespread adoption of FHIR: The undisputed canonical data model for healthcare interoperability. FHIR provides all the necessary building blocks to modernize event-driven messaging in healthcare.
- AsyncAPI initiative: Paving the way for an industry agnostic framework for event-driven APIs, this initiative is similar to what REST has delivered for synchronous integrations.
- Modern integration platforms for RESTful and event-driven integrations: Like MuleSoft’s Anypoint platform, this allows developers to design, develop, and operate REST and event-driven APIs and connect them to both modern and legacy HL7 v2 data formats.
FHIR provides a comprehensive canonical data model for healthcare and has been adopted by all major clinical IT and technology companies. Event-driven APIs can be modeled based on FHIR messaging and resource bundles that represent common clinical events such as admission, discharge, or patient transfer and laboratory orders and results, for example. A common semantic model is implemented in topics that are hosted on modern messaging infrastructure such as Kafka or Anypoint MQ, allowing systems to publish and subscribe to events.
The AsyncAPI specification provides a framework to manage these event-driven APIs consistently across the enterprise which is essential given the scale that healthcare providers have to manage with a large number of clinical systems and event types.
Given the prevalence of HL7 v2, it will take many years for all clinical systems to natively publish or subscribe to event-driven APIs with FHIR messaging. This is where MuleSoft provides a fully integrated platform to connect any system and protocol to an event-driven architecture and perform the necessary transformation.
MuleSoft’s fully integrated platform to design, build, and manage both RESTful and event-driven APIs reimages interoperability in healthcare. It provides healthcare providers with the capabilities to reap the benefits of digitization in healthcare.
