Engineering

A Method to the Data: Plurality of Concerns part II

Posted March 28, 2018
By Nick Hatt
At Redox, we have embarked on tackling a huge problem: interoperability. I’m stealing the title of one my favorite blog posts of all time – Dharma’s great Why Interoperability is Hard: The Plurality of Concerns. It’s a deep dive into how you start building an interoperability stack from the ground up. I want to focus on a different angle: in addition to the concerns Dharma has, I also need to scale across multiple EHRs.
The original concerns:
  • Being functional
  • Being usable/maintainable
  • Being performant
  • Being scalable
  • Being secure
  • Being available
We need to add some concerns about the data we’re getting and the methods by which we get that data.
  • Be parseable
  • Be consistent
  • Be stable
  • Be normalized to my internal data structures

 

Scenario: Receive HL7v2 over MLLP

If you read Dharma’s article, you’ll understand that a lot of work goes into just building a connection with which to receive the data. Once you have that data, you still need to understand it.
You might start out with some kind of pipeline that looks like this. You read the data in, parse the HL7, translate fields to something your database understands (M -> Male, F -> Female, for example) and then store it.

Parse the HL7

You might look at a sample HL7v2 message and say “Pipes, carets, yeah I got this”. In reality, the simple syntax of HL7v2 hides a much more complex model. In a recent stack overflow answer I broke down why off the shelf tools like Mirth don’t do a good job of this. Further, most people don’t bother to read chapter 2 of the HL7v2 specification which outlines all the edge cases like escape sequences, continuation pointers, batch messages, and my favorite: Everything You Wanted to Know About Character Encoding in HL7.
The best open-source option for parsing is probably HAPI, and even that has you doing most of the work when it comes to things like character encoding.
Even if you nail your parsing, you still have to deal with changing data from other systems. An upgrade might switch where data is sent, or new segments will be added without you realizing it.
Let’s say that you’re successful with this, and your team is on board with the HL7v2 model and can adapt to change. Next, you need to tackle the consistency problem.

Normalize the data

Take a look at the PID segment specification from chapter 3 of the HL7v2 specs.
If you were to guess where to find the patient identifiers, where would you look?
If you guessed either PID-2, PID-3, or PID-4 you wouldn’t be wrong. At one point in time all three were valid. Now, PID-3 is recommended for all identifiers. That doesn’t stop people from using multiple fields, with repetitions.
You can see where we can solve this consistency problem on a case-by-case basis. But how do we solve it more broadly, in a configurable way that doesn’t slow down your implementations? Redox has its own DSL that we just call “Configurations” that solves this for us, but it still involves a lot of communication when we’re bringing new health systems online.

Fill your database

Once you’ve established a pattern and tools for making the data coming into your system consistent – you still need to file it away.
How do you represent clinical concepts internally? Do you use HL7’s models for how things like orders and observations fit together? What kind of process does your team follow when adding new fields to say, the Patient table? Who decides what set of codes should be used to store allergies, medications, and problems?
HL7 makes recommendations for some of these things – for example see Medication in FHIR. But is that list of SNOMED codes going to be the best for your end users to work with? How do you represent the need to do one-to-many types of mapping between codesets?
How are you going to manage when codesets change, like the ICD-9 to ICD-10 transition. Are you going to have to migrate massive amounts of data to the new format?

The Redox Plurality of Concerns

From the very beginning we’ve had a vision of a healthcare network where many of these concerns were tackled by a central hub. It’s been very exciting to build tools around solving these problems, and I’ll be the first to admit we’re only scratching the surface.
I’m just going to end this with Dharma’s conclusion:
This is the work we do at Redox. The good news is that we are thinking about the plurality of our concerns, and we do that as upfront in the design as possible. Meeting all of these expectations is both daunting and thrilling. It’s the nature of our space, and it’s why we do what we do.