Hacker News new | ask | show | jobs
by ape4 1124 days ago
When they say "Most EHRs use a message format called HL7v2, which is ugly and tedious to type." they aren't kidding, here's an example of it:

MSH|^~\&|FROM_APP|FROM_FACILITY|TO_APP|TO_FACILITY|20180101000000||ADT^A01|20180101000000|P|2.5| EVN|A01|20110613083617| PID|1|843125^^^^MRN|21004053^^^^MRN~2269030303^^^^ORGNMBR||SULLY^BRIAN||19611209|M|||123 MAIN ST^^CITY^STATE^12345| PV1||I|H73 RM1^1^^HIGHWAY 01 CLINIC||||5148^MARY QUINN|||||||||Y||||||||||||||||||||||||||||20180101000000|

9 comments

I designed HL7v2 and v3 (xml based) parsers in Mirth. It was horrible, but boy did I learn a ton. Subtle bugs could lead to scary outcomes like drug doses being way off. Seeing the string “PID” still causes nightmares.
Pelvis Inflammatory Disease as a data format - a perfect description for HL7.
Mirth is so useful for debugging, though.
Don't forget the most ridiculous part of EDI-style protocols (X12, HL7, etc.), which is that they don't have an explicit looping construct; you have to look at each implementation spec and your trading partner's specific companion guide and determine where repeated or looped sequences area through context. Makes for some exciting issues in implementing parsers.
Agreed.

On the positive side, being domain specific and well known, Hl7v2 "interface" specs are more simple and predictable than other IDLs I've used. (Just vibes. I haven't done a formal comparison.)

We had a stock human-readable "interface" template to use. It's basically literate programming. Paragraphs of descriptive text and well-formed tables.

I wrote a simple parser which turned those well-formed tables into actual code. Our HL7 tools made it trivial to subclass generated classes whenever a special case (difficult to describe in the spec's tables) had to be hard-coded.

Our HL7 tool stack allowed our "business analysts" (domain experts talking with customers) to do most of the implementation themselves, with speedy deploys, low cost of change, and super easy to verify. For instance, our team could make changes and deploy and verify while on the phone with customers / partners.

What could be easier?

Our customers loved us.

So of course the mega-corp which acquired our startup had to strangle our effort in the crib, dumping our corpse in a land fill. Mostly out of spite.

The wire format is a bit messy and hard to read. But developers mostly work through libraries like HAPI which have a decent API.

https://hapifhir.github.io/hapi-hl7v2/

HAPI is amazing.
Last Published: 2017-06-23...is it still active?
HL7 has different lifetime to JS-framework-of-the-week. It doesn't really change since the software itself is updated at most every year. (not including small patches)
This message object seems to be missing the HIPAA^ENCRYPTED field (pun intended)...I am assuming the encryption is implemented above this layer? Is there a standard for HL7v2 encryption?
HL7v2 is just the schema - the mechanism for sending these messages is normally something called MLLP which is just a simple framing protocol and has no built in security. It is possible to send/receive HL7v2 over other protocols, MLLP is the most common.

Its normal to secure the endpoints via network level security - ipsec etc. HL7v3 transformed into FHIR which is done over HTTPS instead.

or, hear me out, you also blast it unencrypted to the flex pagers your employees don't even use anymore
It's normal to not encrypt it, in my experience.
It's really not normal to not encrypt HL7 V2 messages. Every interface that I've seen uses a VPN.
I'm in the UK in the NHS. Perhaps that's the difference. They just do network lockdowns inside the hospital.
oh neat. i was aware of hl7, but didn't realize i'd seen it in the wild til today.

you can often find these messages flying unencrypted over flex pager channels in the us

Typically these messages are not encrypted. This is a late 80's spec based on a 70's era EDI spec.

IMHO, when these messages are transmitted outside the hospital typically a VPN used. There is a spec for posting these messages to an web service over HTTPS but I haven't seen it in use.

Usually encrypted via a TLS connection right into an HL7 channel/listener. Or the entire connection is encrypted via a VPN connection between healthcare systems.
If there's encryption, it's generally further up the stack (eg. wrapping in a TLS connection or IPSec tunnel).
no shot anyone actually types this out, right? surely this must be generated by machines for machine ingestion.
No, not any more than anyone types out XML anyway.
They probably do, and if NOTAMs are any indication, it's probably also read by people too.
Not comparable. HL7 is a machine interchange format - virtually no docs or healthcare personnel except those involved in informatics (and then generally only superficially) are familiar with HL7.

These NOTAMs were designed for human consumption and brevity, they date back to the 40s (debate about their ergonomics nonwithstanding).

Generally, it's machine generated. I've only ever typed it out manually if I needed something specific for a unit test and that only for small messages. It's tedious to do by hand.
yeah
I've worked a lot with DICOM which has plenty of warts (as expected with a 30 year old living standard), but HL7 is a bit much for me. At least FHIR and DICOMweb are considerably saner.
You haven't lived until you've tried to debug it. The array isn't zero based. The line breaks have different characters for breaking the lines, and you get to guess which ones are doing it.

Certain characters are ok (ASKII) but when a Mac gets a nice ' into the field, all hell breaks loose. Things like "lesion at 9 o'clock" then break the system, as does Mr O'Leary. The hours spent chasing down how some failure happened are countless. Pity those working with HL7.

Healthcare is the perfect storm of layered, ossified systems created across decades + input data that's normal just often enough... that everyone thinks bounds are actually handled.

And then Mr. O'Leary checks in.

Fuzz testing tools would be great, but I haven't seen many institutions that have functional 1:1 lower environments (i.e. including all system-system integrations working in test).

Add to that the fun bits like "let's attach a whole base64 encoded PDF as a field of the hl7 message". Which honestly is not a terrible solution given you want to keep it all together, but still... It would be nice if you could attach binaries after the ASCII content.
It is possible to include multiple binary attachments and text content in certain HL7 V2 message structures. Just use multiple OBX segments.
You can ask GPT to expand it for you without any context and it will fill in the headers and explain each field.
Good learning tool if you use it on generated data.

Don't paste actual patient data.

Why not? Can you articulate what could go wrong?
You're sharing someone's sensitive data without permission. On top of that, patient data has additional protections in many countries. You can get into legal troubles because of that.

Major providers like Azure or AWS have programs in place to handle sensitive patient data. I'm not sure if OpenAI has one too. Either way, you would have to enter into a special agreement to do so.

Bonus point: ask ChatGPT if it's ok to paste private patient data there.

What does HL7v3 look like?
The HL7 V3 standard is mostly dead. Only the Clinical Document Architecture (CDA) offshoot of V3 still survives in widespread use. You can find examples here.

https://hl7-c-cda-examples.herokuapp.com/

Most new HL7 work has moved on to FHIR which is essentially "HL7 V4".

R4 is where things get a bit kinder and gentler.

https://www.hl7.org/fhir/us/core/Condition-condition-duodena...

I think you're kind of mixing up version or release numbers there. HL7 has several major standards: V2 Messaging, V3 (including CDA), and FHIR. And each of those has gone through multiple releases. FHIR was on R4 for a couple years and R5 was recently published.
Yeah, I’m doing that thing where I speak sloppily. HL7 is the standards organization, so talking about “HL7 messages” is like talking about “ISO messages”. It’s a misnomer.

But as someone at the sharp end of the stick wrt integrations? If I hear someone talk to me about HL7 I’m thinking HL7v2, and if someone says FHIR I’m thinking US Core v2 + FHIR R4. That just seems to be lingua franca.

Ah that makes more sense.
Seems readable to me