COVID-19 has brought unprecedented challenges across all industries, but its impact on healthcare is unparalleled. Without access to testing centers or vaccines, patients and citizens are left with many unanswered questions.
These unanswered questions have a sizable impact on healthcare — a significant being the contact centers. Hospitals across the globe are hit with higher call volumes than ever before by patients who rightfully want to know if they should come into the hospital to be tested, if their test results are available or not, or if they can be rescheduled for elective surgery.
This rise in call center volumes have resurfaced an issue that has existed in healthcare for a long time — the lack of real-time access to patient data. Luckily, there have been advancements in this area. Doctors and nurses were provided access to EHRs which serve as the source of truth for patient data. However, not everyone who needs patient data has access to an EHR — a great example of this is the contact center agents. While it makes perfect sense why agents would not have access to all records related to a patient, they do need limited information to help patients requesting support. So how do we provide them with the right access to the information agents need, while staying compliant with regulations that protect patient data, like HIPAA?
Introducing MuleSoft Accelerator for Healthcare
Knowing this was an urgent issue with COVID-19, MuleSoft partnered with Salesforce Health Cloud to build an accelerator that helps providers unlock critical patient data and COVID-19 test results from their EHR and make them available in Salesforce Health Cloud. By helping providers build a patient 360 within Health Cloud, we can enable contact center agents to have access to the critical info they need to quickly address rising call volumes.
MuleSoft Accelerators enable businesses to implement critical integration use cases, faster and easier than ever. Accelerators include production-ready APIs, connectors, and integration templates that unlock critical data from external systems such as Epic and Cerner; all the while guiding you to adopt best practices synthesized from thousands of customer implementations. These assets can be used as is or extended to meet your company’s unique needs.
Building a patient 360 in Health Cloud
To help organizations build a patient 360 in Salesforce Health Cloud, we are providing the following assets:
- HL7 V2 ADT Implementation Template
- HL7 V2 ORU Implementation Template
- FHIR R4 US Core Patient API – RAML and Implementation Template
- FHIR R4 US Core AllergyIntolerance API – RAML and Implementation Template
- FHIR R4 US Core Condition API – RAML and Implementation Template
- FHIR R4 US Core Observation API – RAML and Implementation Template
Functionally, the solution provides the ability to perform a unidirectional sync from any EHR into Health Cloud. Rather than to model after a specific EHR, we kept our APIs and templates compliant with industry standards so that you can apply it to any EHR. To continue to keep your source system (EHR) as the system of record, we used a push-based mechanism to trigger the push into Health Cloud.
Also, knowing that many of our customers are currently using HL7 V2, but rapidly adopting FHIR R4, we wanted to provide examples of accomplishing this use case using both HL7 V2 and FHIR R4.
Best practices embedded
Regardless of the approach taken (HL7 V2 or FHIR R4), we embed MuleSoft best practices into our accelerator assets. For example, Mule coding best practices such as reconnection strategies, ensuring reliable delivery of messages by using Anypoint MQ, and ensuring transaction integrity using Salesforce Composite Connector are embedded within the accelerator. We also provide MUnit tests as part of our accelerators so that you can run unit and integrated tests for your Mule applications.
Using HL7 V2:
Using our accelerator, use your existing HL7 V2 feed to trigger messages, such as patient data in the form of Admissions, Discharge, and Transfer (ADT), or Observation Results (ORU) for lab results. This applies whether you are using an interface engine or not. In addition, for HL7 V2, we show you how to use protocols such as HTTP and MLLP to exchange data from the source system.
FHIR R4:
For FHIR, knowing FHIR can be quite complex, our goal was to provide customers with the building blocks for designing FHIR APIs using RAML. These building blocks come in the form of data types, libraries, and API specifications.
To complement these APIs, we have also built implementation templates for the Patient, Allergy, Observation, and Condition resources. By reviewing these templates, you can see a great example of how to implement the RAML specifications we are providing to stay compliant with FHIR standards. This will give you the guidance needed to implement against the 20+ API specs we are providing for the US Core Profile, which you can scaffold and connect to any backend system.
Excited to learn more?
Check out Accelerator for Healthcare on Anypoint Exchange, and sign up for our upcoming webinar on the Accelerator for Healthcare:
