This is part three in a three part series. Read part one | Read part two
***
Build for Flexibility
As you approach your first integration project with a healthcare organization, you’ve got to take what we call the Mick Jagger approach: you can’t always get what you want, but you better make sure you get what you need.
To be sure you get what you need before you kick off an integration project, you need to design with flexibility in mind. Yes, the buzz word is still FLEXIBILITY!
Let’s look at the considerations for Field Reliability, Data Requirements, Patient IDs, Coded Value Management, Error Handling and Code Completion. Plan ahead and you’ll have the greatest chances for success.
Understand Field Reliability
Field reliability is the reliability of specific data elements within a message that are exchanged between the health care organization and your product.
Every organization will have different data sets that are set up to be exchanged by default, regardless of the connection method. For example, one ADT message from one site won’t have the same data populated as another organization’s ADT message. This is something to prepare for as you look to integrate.
Look at this example from the Redox API documentation:
The green tags next to each field represent field reliability when looking across the 100s of connections we have across the US. It helps us see how often we receive a given data element from a source.
Determine Your Minimum Data Requirements
You need a clear understanding of your actual data requirements before kicking off an integration project. A healthcare organization may need to modify their existing interfaces or exchange infrastructure. They’ll need to plan for the extra time this could take in addition to the typical implementation timeline.
Make it easy for organizations to get on board with your project by critically thinking through your data requirements ahead of time.
Determine:
- What is actually required for your integrated product?
- What is the minimum data set that will still provide value?
Just as you looked for the easy wins when iterating on your integration scope, look for easy wins in data requirements. Start with a minimum data set, exchange it, and then iterate over time. You can always add new interfaces to your connection.
Beginning this way will get your integration up and running much faster. We’ve seen countless others have success when they use this approach. Health care organizations are used to iterating on projects this way, too.
Perform Data Content Checks
Problem: You’re receiving incoming messages from your connection partners but some of your critical requirements aren’t populated.
Solution: As long as you’ve received the message and can process it, send a success response before you initiate a data validation or content check, whether that’s an HTTP code or an HL7 hack as shown here. Once you’ve sent the success response, internally log issues with the data content so you can continue receiving the data.
It may seem counterintuitive to send a success response when you haven’t received the data you need. Here’s why it’s important: If you error against an incoming message, your integration vendor or connection partner may start queueing up subsequent messages. Because you want to continue receiving data, send a success response and internally log issues with the data content as errors on your end. This way, you’ll continue receiving data while investigating what happened with that specific message.
Designate a Primary Patient Identifier Within Your Product
A patient’s primary identifier is commonly (but not always) referred to as an MRN or MR. In this image, you can see a few Patient ID types that Redox comes across: MR, EHRID, and NIST. The ID type can be any value. Think of it as a customized string and be prepared to persist any and all identifiers and their ID types that are sent to you.
When you’re connecting to a large multi-hospital system or an organization that uses Epic for Clinicals and Cerner for Billing, it’s common for both entities to have their own patient identifiers. The organization may still send data through the same interface engine, sending multiple IDs on outbound messages. Typically, one of these IDs will be used as the patient’s primary ID to identify the patient anywhere within their network.
If your product is writing back data, or you’re making subsequent queries against that organization, include all of the same identifiers and their ID types. Designate the appropriate ID as the patient’s primary identifier. This will ensure that you maintain that organization’s patient identity within your product.
Consume & Map Diverse Coded Values
Within healthcare and healthcare IT, clinical data like diagnoses, conditions, allergies, and vitals are often coded. While there are some common code sets — like ICD-10 codes to represent diagnoses or SNOMED codes to represent patient conditions — organizations also use their own internal, site-specific codes. We see this more often with order and procedure codes.
For example, Kaiser Permanente Northwest may use one code set for representing types of orders on their outbound order messages, and Kaiser Permanente Mid-Atlantic may use a different code set for the same types of orders.
However your product represents diagnoses, allergies, or vitals, make sure your product can consume any external code set and can map it appropriately.
Be Prepared for Error Handling
Manage any errors you receive on outbound messages. To do this, you need to be familiar with hacks and knacks on HL7 connections and know what the different HTTP status codes represent. When you receive an error message, your product must notify the appropriate people on your support team so the problem can be addressed.
Keep in mind that just as your connection partners queue subsequent messages when you respond with an error, they will want you to do the same for them. For example, if you receive a 401 error on an outbound message, have a queueing infrastructure in place so you can queue up subsequent outbound messages until the issue is resolved.
Code Completion
Make sure your core integration development is as complete as it can be before you kick off your project. Working with HL7 connections? You better make sure you can receive and produce HL7 messages as appropriate. Going the route of an API connection? Then build against the API ahead of time for the events you’ll need.
I know — it’s so much more fun to get out there and get things moving along as soon as possible. But here’s the thing — when a health care organization signs on with you, they’ll assign you a resource from their IT and network teams for a limited time. Make the most of their time by already having your core integrations in place. Be ready at the same time the health care organization is ready or else your resource may get reassigned.
As long as your core development is ready, all you’ll need to focus on will be site-specific idiosyncrasies and mapping that organizations data to your product.
Now You Know Our Healthcare Product Scalability Secrets
Your healthcare product can make a fantastic impact. The better prepared you are for the way EHRs handle data and workflows, the more good it can do.
- Remember you need to scope your project from the user flow, paying attention to enrollment, supplementation, and write back.
- Then you need to design your architecture to support your workflow. Know when to choose Query vs Event push and how to handle historical data.
- Last, determine your minimum data requirements and have a plan in place to handle the EHR’s data (no matter how it’s presented).
Stay in the know! Subscribe to our newsletter.
Related Posts
Are we there yet? How payers can accelerate the journey to value-based care.
In the early 1940’s less than 9% of the US population had health insurance. A quick adoption began…
