Integration is Language for Robots

HL7 is nothing but a conversation over a cup of coffee

Integration is a technical topic. At Redox (and at most healthcare technology companies), we’re surrounded by acronym soup, wading through HTTPS, JSON, REST, SAML, and HCOs. We’re knee-deep in architectural decision-making, espousing the benefits of webhooks over queries, defining workflows only to map them to technical exchange methods, calling out data elements necessary for mission success.

This is not easy stuff. Healthcare is hard enough with the myriad workflows and scenarios that are seen across the spectrum of care. Anyone who endeavors to learn just that (a.k.a doctors) spends about a decade of their time and hundreds of thousands of dollars to do so. Overlay 40 years of technology and it’s enough learning for a lifetime.

So for this blog, let’s make it simple and just use a metaphor. We may also see some simile, highlight with some hyperbole, amplify with analogy, and magnify with metonymy, but those are accidental byproducts (as I strive more for education than entertainment) of the main goal here, which is a single metaphor:

Integration is Language for Robots

When I think of what we work on, I think of a conversation between you and me, perhaps via Slack, sometimes via Zoom, often in person. The methods and means of human communication are varied, just as they are in healthcare integration, but the component parts are truly analogous and can help you understand those acronyms much more deeply as you see the parallels.

Components of Language

In order to ground our metaphor, let’s first make sure we understand exactly what language is (at least in the context of human to human interaction). Note: People spend their whole lives diving into this stuff and defining it in terms of philosophy, sociology, and math, so the rabbit hole goes deep. Some other day, I’ll take that red pill with you over some beers, but for the purposes of this metaphor (and our goal in simplifying what is already complicated), we’ll keep things blue pill-level.

Language is defined as the method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way. To break that out further, Wikipedia gets into these steps of communication:

1. The formation of communicative motivation or reason.
2. Message composition (further internal or technical elaboration on what exactly to express).
3. Message encoding (for example, into digital data, written text, speech, pictures, gestures and so on).
4. Transmission of the encoded message as a sequence of signals using a specific channel or medium).
5. Noise sources such as natural forces and in some cases human activity (both intentional and accidental) begin influencing the quality of signals propagating from the sender to one or more receivers.
6. Reception of signals and reassembling of the encoded message from a sequence of received signals.
7. Decoding of the reassembled encoded message.
8. Interpretation and making sense of the presumed original message.

For our purposes, I think it’s worthwhile to add two additional concepts:

1. Identity verification is important as a step in communication so that each party understands who they are communicating with, especially when dealing with secure information.

Take a second to think about the above paradigm in regards to various ways you communicate daily. For instance, this morning I asked my fiancée to grab me a cup of coffee by saying “Bailey, can you grab me a cup?”:

1. Motivation/reason: Caffeine is life and I just woke up.
2. Message composition: I realized that Bailey was near the coffee machine and that if I played my cards right, I might be able to get that caffeine without moving.
3. Message encoding: I encoded all that into “Bailey, can you grab me a cup?”.
4. Identity verification: I can see Bailey in the kitchen and recognize her
5. Transmission: I spoke those words over the medium of sound.
6. Noise quality: It’s early, so high quality as there’s none of the typical background noise of SF, such as honking cars or people on nearby Haight-Ashbury trying to relive the 1960s.
7. Reception: Bailey hears the noises.
8. Decoding: Bailey knows English and therefore is able to decode the noises to meaning.
9. Identity verification 2: Bailey recognizes my voice
10. Interpretation: Bailey understands my noises as an ask for coffee and decides whether she wants to bring me a cup. ¹

Okay, that was simple. Let’s do another example to make sure we understand communication. For instance, I just Whatsapped my twin brother to ask him about New Year’s:

1. Motivation/reason: New Year’s is a conflicted holiday for me.² To reduce that conflict, I want to figure out a plan early.
2. Message composition: My brother is pretty cool (he’s a clone of me, so judge that as you will), so I thought I’d hit him up.
3. Identity verification: I use my fingerprint to get into my phone and have an ongoing Whatsapp conversation with my brother.
4. Message encoding: I typed in “What it do for NYE, bro?”.
5. Message encoding (actual): Just kidding. I don’t speak that way. I typed “Hey, how’s it going? You have any plans for New Year’s yet?”.

• Reason to have this joke/duplicate step: The way information is encoded (according to rules of language, social norms, set agreements, etc) matters a ton. These standards help influence understanding on the recipient’s end.
• Note that I encoded it into writing, which follows different encoding rules than speech.

4. Transmission: I transmitted it via Whatsapp communication method.

5. Noise quality: No lossiness due to latency, packet loss, etc.

6. Reception: Colin’s Whatsapp receives the message and notifies him. He sees the notification.

7. Decoding: He reads the message, as he is literate in English

8. Identity Verification 2: Colin safely assumes that the Whatsapp line has not been compromised and that it’s me.

9. Interpretation: Colin understands the message as a request about New Year’s Eve plans. He thinks about what he is doing for NYE.³

The US trade deficit to China this year for single-use NYE related garbage will exceed $500 million this year.⁴

You know it’s fun because they’re wearing sunglasses inside at midnight

You can take the format above and play around with it. Think of a few examples of communication via different methods (speech, written, gestures, sign language, body language, etc) and try to do the same exercise I just did.

Same thing, but now for robots

Okay, so we’ve explained how all this works for humans. But what if instead of humans, it was robots?

Couldn’t decide between a caption of “Oh shit, no no no this is my nightmare.” and “Just your normal on Market St in SF”

What do I mean by robots? I’m actually referring to communication between two programmable systems, such as an EHR and a lab system, but robots is a cooler/more exciting word (better message encoding!) so I chose to use that to start. We’ll pivot now to “systems”.

Anyhow, we can use the same communication-defining techniques for systems that we did for humans.

1. Motivation/reason: We’d call this the “trigger point” or “initiation point” when detailing the communication between systems. Systems typically have set trigger points as parts of their workflow (i.e. they say something every time a certain event happens) or can be triggered manually by a user (i.e. a human user can ask the system to communicate on-demand, like a query).

2. Message composition: The system gathers up all relevant information from their database necessary to create a message.

3. Message encoding: We’d call this the “data format” or “content format” (if you’re interested in these, the history of healthcare standards). This is the encoding of all the stuff from part 2 into a set format (which could be a “standard”, such as HL7, or could be proprietary/specific to the system, such as a vendor-specific JSON API). Here’s a wiki talking about content formats. Examples of data formats include:

• JSON
• XML
• HL7v2
• FHIR data format

4. Identity Verification: We’d call this authentication when detailing how applications secure their communication channels and prove identity. Asserting user identity or system-level identity is important in communications. Confirming your own identity (authentication) and ensuring you are allowed access to the system (authorization). Overall, this step encompasses security, credentials, authentication, and authorization, but we’ll focus on just authentication for now:

• Basic Authentication
• SAML (Security Assertion Markup Language)
• API Keys
• OAuth2 (at least the OpenID authentication piece that’s generally layered in there)
• JWT

5. Transmission: We’d call this the communication protocol/method or transport method. This is the medium by which the encoded content is moved from system A to system B. Whereas with humans we had speech, writing, etc, with systems we have electronic transmission methods, like these examples:

• TCP/IP
• HTTPS
• SFTP
• SOAP XDS/XDR

6. Noise quality: We have the concept of noise in electronic communication, such as lost packets, software bugs that cause dropped messages, or latency. We also have external actors that can affect the quality of your communication through malicious intent. We protect against these actors just as you might use different mechanisms to protect against noise. Example technologies used for this part:

• IPsec VPN
• HTTPS
• SSH

6. Reception: This is the reverse of the capabilities in point 4. In order for communication to be successful, the recipient has to be able to understand the communication method.

• In the examples of our humans, Bailey was not deaf, so she could hear. Colin was literate and not blind, so he could read.
• The analogous situation for systems is that they can receive HTTP traffic, MLLP traffic, etc.

7. Decoding: This is the reverse of the capabilities in point 3. In order for received communication to be processed, it first needs to be decoded (i.e. moved from the encoded format into the local format).

• In the example of our humans, Bailey took the spoken words and reconciled it using her knowledge of spoken English grammar and pronunciation rules into thought. Colin took the written words and reconciled it against his knowledge of written English spelling and grammar rules into thought.
• Likewise, systems take the encoded format (such as HL7 message) and reconcile it against their knowledge of that format’s rules.

8. Identity Verification 2: As in the first Identity Verification, authentication needs to be handled in some fashion. It could be as part of the same method as in step 1.

9. Interpretation: The receiving system can then use the new information as it sees fit, perhaps to update a database or to perform a new action.

Okay, let’s get down into the specifics and apply it to one of the most basic communication situations we see in healthcare: the exchange of patient demographics.

1. Motivation/reason (trigger point): An EHR user marks that a patient has been admitted into the hospital. This is a set trigger to send information.
2. Message composition: The system gathers up all relevant information from their database necessary regarding the patient (the demographics, the admitted location, the providers, etc).
3. Message encoding (data format): The EHR system is set up to send HL7v2 ADT messages, so it encodes the data into that format.
4. Identity Verification: An EHR will include a sort of system identifier on the message (in the MSH segment). Not a whole lot of authentication with these basic communications.
5. Transmission (comm method/transport protocol): The connection to the ancillary system is via TCP/IP (specifically MLLP).
6. Noise quality (security/credentials/auth): The connection is secured by an IPsec VPN.
7. Reception: The receiving system is a lab system (LIS) that has the capability to receive via TCP/IP (that is to say, it’s literate in TCP/IP). Note: in most cases, the LIS would receive this message after it passes through the interface engine if the HCO has one. For the purposes of our metaphor, the interface engine is really a middleman playing somewhat of a telephone game with us.
8. Decoding: The lab system has learned the requisite language (HL7v2) and understand the topic of conversation (ADT), so it decodes it to its internal format.
9. Identity Verification: The lab system recognizes the identifier for the sender in the MSH segment
10. Interpretation: The lab system interprets the ADT information and updates the necessary internal database tables.

See the parallels? Pretty rad, right? Healthcare systems are just like us. And so are robots, but anyone who’s seen I, Robot knows that.

Pictured: Us and the EHR systems of the future. NBD, just hanging, talking about communication, HBU?

So how’s a company like Redox fit into this picture? Great question, you smart reader, you. Simply put, Redox acts as a translator in the communication, reducing the burden on one (or more) sides of the conversation. Here’s our conversation from before, but in an alternate reality where my brother is illiterate and can only understand spoken Spanish.

1. Motivation/reason: I’m still wondering about New Year’s. The clock is ticking.
2. Message composition: I think about the words to ask him again.
3. Identity verification: I again use my fingerprint to get into my phone and have an ongoing Whatsapp conversation with my brother
4. Message encoding: I type in another message like, “Hellllooooo. Earth to Colin. What are you thinking?”
5. Transmission: I transmitted it via Whatsapp communication method.
6. Noise quality: Not really applicable here. No lossiness.
7. Reception: Colin’s Whatsapp receives the message and notifies him. He sees the notification and hands this to his translator friend, Amigo, who is bi-lingual and literate.
8. Decoding and re-encoding: Amigo reads the message and translates mentally to Spanish.
9. Transmission: Amigo speaks the message over the medium of sound.
10. Noise quality: The subtle melodies of Maroon Five’s “Memories” wafts in the background, but the spoken sounds make it to him with minimal disruption.
11. Reception: Colin is not deaf, so he hears the spoken words.
12. Decoding: He understands the message, as he understands spoken Spanish.
13. Interpretation: Colin understands my message and thinks about what he is doing for NYE. He still does not respond.

With that in mind, here’s our previous electronic exchange with a translator (Redox!) involved:

1. Motivation/reason (trigger point): An EHR user marks that a patient has been admitted into the hospital. This is a set trigger to send information.
2. Message composition: The system gathers up all relevant information from their database necessary regarding the patient (the demographics, the admitted location, the providers, etc).
3. Message encoding (data format): The EHR system is set up to send HL7v2 ADT messages, so it encodes the data into that format.
4. Transmission (comm method/transport protocol): The connection to the ancillary system is via TCP/IP (specifically MLLP).
5. Noise quality (security/credentials/auth): The connection is secured by an IPsec VPN.
6. Reception by Redox: Redox has the capability to receive via TCP/IP (that is to say, it’s literate in TCP/IP).
7. Decoding and re-encoding: Redox has learned the requisite language (HL7v2) and understand the topic of conversation (ADT), so we decode it to our native Data Model (PatientAdmin).
8. Transmission 2 (comm method/transport protocol): The connection to the ancillary system is via HTTPS.
9. Noise quality (security/credentials/auth): The connection is secured by Redox authentication and authorization.
10. Reception by Redox: The lab system is cutting edge and has developed to the Redox API transmission method (that is to say, they are literate in Redox’s HTTPS).
11. Decoding: The lab system has developed to the Redox API data format (that is to say, they have learned the requisite language — the Redox Data Model).
12. Interpretation: The lab system interprets the PatientAdmin information and updates the necessary internal database tables.

Without knowledge of the requisite language, Bill the Billing app is stuck smiling awkwardly at his fellow systems

Trust

Pretty simple, right? We’ll add one layer before we wrap up. Sometimes it’s important when you communicate sensitive information to keep it private. In healthcare, the conversation topics are always sensitive due to the government saying so, so you want to make sure you trust the person you talk to. There are several ways we can do this.

The way we ensure trust with just one other individual is a Business Associate Agreement. It’s a contract that the other person (system) signs to say “Hey, I’m trustworthy. Tell me about patients and I won’t misuse that information”.

Another way to ensure trust is by having the person you’re talking about say it’s okay to have that conversation. That’s patient authorization! Before the EHR system discusses anything about hypothetical patient Steve with patient portal application, the EHR system checks with Steve in a secure way that he says it’s okay.

Lastly, sometimes you just want to have a big party and talk freely. That’s enterprise interoperability! You put a bouncer out front who checks IDs and makes sure no one is packing heat. Once each individual is checked (certified) by the bouncers (HIE, HISP, or network certification/accreditation staff), for instance, they’re allowed into Club Commonwell or Direct Danceclub and able to chat with whoever they want. Still, it’s not the type of place you’d want really in-depth conversations, so the topics you can talk about currently are limited (just ClinicalSummary, really).

If you’re interested in more content about trust frameworks (that is rich in detail, but decidedly less fun than the metaphor version), check out this post here.

Check out this live feed into the healthcare technology community. Grahame Grieve is in there somewhere

Conclusion

The intent of this post was to give you deeper insight into components of electronic exchange by comparing and contrasting with traditional communication. There’s a lot more we could do with the metaphor (regional dialects and accents of a language are roughly equatable to different implementation of a data format, such as Epic’s HL7v2 ADT, Cerner’s HL7v2 ADT, etc; how queries/responses and messaging correlate to questions/answers and statements) but we can save that for an in-person discussion if you’re interested (or a future blog post if there’s popular demand).

Takeaways

If you remember nothing else, here is another keyphrase to hold onto:

Not all systems can be Pete Buttigieg.

Definitely not a robot.

We can expound upon that with some key takeaways for you that I hope will provide value in your healthcare, integration and (hopefully) Redox journey:

1. Data formats like HL7v2, X12, FHIR, JSON, and XML are just like languages. A system can be really smart and learn a bunch of different languages, but realistically, most systems shouldn’t be Mayor Buttigieg (and know seven languages).⁵ It’s definitely cool and respectable, but it’s just not an efficient use of time for everyone to learn seven languages. Some (like me) struggle mightily to learn languages, like me in my ongoing quest to learn French as an adult. Rather, a translator like Redox can be very valuable in allowing a system to only learn one language (our JSON formats) and focus on their core competencies and unique skills (like playing basketball or helping surgeons manage their cases).
2. Comm methods like TCP/IP (MLLP), HTTPS, and SFTP are akin to ways of conveying language like speech, writing, gestures, and body language. While humans use and understand many of these, it’s just additional overhead for our computer system friends, so Redox provides value in that a system only has to use one (our Redox HTTPS-based comm method).
3. There’s a lot of potential for abuse in healthcare, in that the data is valuable and people would like inappropriate access. Authentication methods like OAuth, Basic, and JWT help protect that. Again, there are many possible variations, so Redox provides another layer of value.

Footnotes

¹ For those riveted on the above narrative, she did bring me the cup of coffee, because she is wonderful.

² Generally on NYE, bars are overpriced and not really that fun. Additionally, the highlight of the whole holiday is just a 10-second countdown and millions of voices suddenly crying out together in terror for no particular reason. Aside from that, it’s just another party, just with those blower things and tacky hats, and this particular year, it’s on a Wednesday, which limits the ability to extend a weekend. In summary, NYE is trash. Don’t @ me. I’ll make a future blog post that ranks holidays and you don’t want to see where it lands.

³ No response yet. I will assume it is because he is also struggling with the moral dilemma that NYE represents.

⁴ Not a real stat

⁵ It’s an interesting thought exercise to try to figure out which 2020 presidential candidate we do want our systems to be like. A Yang system that only speaks tech? A Romney system (with a secret diet French/FHIR version)? A Trump version with a super limited set of communication skills? A Gabbard system with nebulous X12 (Russian) capabilities? A Beto version running low on system resources and with an incomplete product launch of its Spanish/XML implementation? A lot of potential here.

⁶ I apologize if I offended by above jokes about your potential candidate of choice. It’s just fun to think of them as EHRs. Or a PHR, in Trump’s case.

If you found this post interesting, it would mean a lot to me if you could click on the “claps” icon below to let me know or let me know through the comments your general thoughts. For more in-depth discussions, feel free to reach out via email at brendan@redoxengine.com or brendanjkeeler@gmail.com.