What do an Enterprise Architect and an Integrations Manager at Nebraska Medicine have in common? At first not very much.
We both worked at Nebraska Medicine and UNMC for years without interacting with each other. Audrey became an IT architect and was looking at integrations from a previous project at Nebraska Medicine that would create our digital front door. Meanwhile, Sophia worked in integrations and had been a part of the interface team for several years. Our paths crossed for the first time when we kicked off this project and we set out to learn more about integrations using web services.
A year later, we both attended the same training offered by our EMR vendor that focused on API integrations. This began our obsession with APIs and led to numerous evening “nerd sessions” where we discussed the possibilities with API-led integrations over a period of a year. APIs appealed to us because of the ease of integration compared to our current methods at the time. Ultimately, this knowledge and expertise landed us a role on this exciting project.
Nebraska Medicine implemented MuleSoft to further its digital transformation strategy. One of the goals of this strategy was to have our contact center agents use Salesforce Health Cloud for inbound call handling. Prior to this initiative, the contact center agents toggled between five different applications during a single call.
We aimed to improve call response times and ultimately improve patient satisfaction, with the main goal of streamlining the call center workflow and providing a “one-stop shop” for agents. MuleSoft was selected as the integration platform for this project because of its ease of use, ability to perform secure data transfers, and reusable APIs for Healthcare providers included in the MuleSoft Accelerator for Healthcare. This project required a number of new integrations one of which was to create a new patient from Salesforce — this is the flow that we’ll be describing below:
Making our patient-create flow in Salesforce
Salesforce has a concept called a path which is a set of guided steps that represent a user workflow. The five steps in this diagram represent the workflow our agents go through when their caller is a new patient looking to schedule an appointment or another care service. The problem was that our backend system requires a patient identifier for the four steps following patient creation shown here.
We went through a discovery process with our registration team to understand how they created a new patient in each system and any policies around patient creation that we needed to consider. We ended up with a list of organizational guidelines and policies that we had to adhere to. After researching potential methods to create the patient in our EMR, we found a solution that worked best for this use case.
It was relatively quick to add the flow above to an existing MuleSoft system API because the application existed and all the policies were already in place. We started off by adding a patient-create flow. This flow can be broken down into five main areas:
- The inbound payload contained the fields needed to create the patient. This was a combination of the organizational requirements and the API requirements.
- To prevent creating duplicates, we created an EMR for the patient using a national identifier.
- In cases where this identifier was not provided, we created the patient and used the existing policies that the registration team provided to avoid creating duplicate patients.
- After the patient was created, we returned the patient’s medical record number to Salesforce.
- When the default path from step 2 is executed, it’s possible for a duplicate would have been created — but this would be caught by step 4, so we want to return that response.
Aligned with MuleSoft recommended best practices, we created a process API for FHIR patient resource. This reusable API design is included in the Accelerator for Healthcare. That architecture shown here represents our finished service. The Salesforce experience API sends the new patient to be mapped to the FHIR patient data model and finally passed to the source systems API to create the patient. The result is that the new patient’s identifier is returned to the UI in Salesforce.
Benefits
By implementing this solution, we successfully gave our contact center agents the ability to create a patient in Salesforce. This implementation saves them time as they no longer have to go to the EMR system to complete this step which was one of their “must-haves.” From a technology standpoint, we added an asset that can be reused for other use cases which will save us time and resources for future projects as we won’t have to build this asset from scratch.
Lastly, on a personal note, we gained valuable experience towards our quest to develop in-house Mule developers and growing our integration portfolio. Recently, Audrey even passed her MCD- Mule 4 certification!
To learn more about how to unlock the EHR with APIs, watch our SMART on FHIR webinar. To learn more about how the MuleSoft Accelerator for Healthcare can support digital health projects such as this, watch our Solving Interoperability with MuleSoft Accelerator for Healthcare webinar.
Authors
Audrey Honeycutt
Enterprise Architect
Nebraska Medicine
Sophia Chege
Integrated Tech Solutions Manager
Nebraska Medicine
