Hacker News Reader

Comment by raxxorrax | Hacker News Reader

I wonder how much security issues relate to the data formats that are often used to exchange medical information. I believe northern American nations mostly use HL7, while European countries tend to prefer Dicom.

HL7 was around since 1987, while Dicom is older than TCP/IP I believe. I think requirements for data exchange fundamentally changed in the last 30 years and at least Dicom is just horrible to handle.

True, you could upgrade it with putting everything in a crypt container, but that is just a quick fix.

This is a case where I fully support software engineers that say that we need to fully reimplement these formats. It is good to have standards here, but many manufacturers of medical devices have their own proprietary adaptations anyway. It shouldn't mean to throw everything learned from these formats away. Just maybe it should all be reevaluated.

View on HN

HL7 is just a text format. It doesn’t say anything about how the data is transmitted (which should always be encrypted these days)

Yes, there are newer standards, specifically FHIR (OAuth authenticated API). But why switch over to FHIR when HL7v2 works really well? Everybody in the medical industry supports this standard, and it’s super easy to work with once you know what you’re doing. It’s also arguably more interoperable than FHIR, because the sending and receiving parties don’t need to fully agree on the spec (like they must for an API). For HL7 messages, there’s a layer that sits in between called an “interface engine” that can modify messages, which opens up more capability with less development and coordination.

I don't really think any replacement standard could be fundamentally much better. Sure, you could resolve the fact that DICOM is so old that it predates widespread adoption of IEEE 754 and so does its own thing there, or minor oversights in the standard. But the fact remains that the standard is a ~5000 page monstrosity designed to cover virtually anything and there's no regulatory certifying body so nothing prevents vendors from failing to properly implement the standard (which is virtually impossible to do given that it's so damn huge and also not always entirely clear). Any standard that aims to be similar in scope and lacks enforcement will, I think, inevitably lead to a horrendously inconsistent ecosystem.

HL7 is just text, if you're not sending it over SSL then it's arguably easier to decipher than a simple webpage when looking through the packets!

The current thing is called FHIR though and instead of sending text HL7v2 messages directly to a port over SSL now we can use a web service, HTTPS, and exchange JSON messages.

Oh really? I always thought it would mainly be an image container like Dicom, which is in practice abused to exchange text just as well. Haven't had the pleasure to work with HL7, I was just tormented by Dicom and have always been told that HL7 is just the American version of it.

All of my legacy interfaces for an EHR vendor are HL7v2 based. It's pretty simple to work with but our lack of external libraries leaves me tinkering with opening ports and reading data manually too much.

The beginning of a HL7 (2.4) message with the header and patient ID node might look like this (this example looks like an ORU^R01 inbound lab result)

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4

PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520

Just a list of offsets using |^~\& seperators sent directly over a port.

The JSON/FHIR versions are nicer even if they are more verbose.

HL7 is so awful. My introduction was is seared into my memory as I hadn’t realised the various line break methods allowed/used.

I have dealt with a vendor who’s existence began is still heavily propped up by their HL7 broker service. It seems rather lucrative.

HL7 is the manifestation of all that is unholy and wrong.

DICOM is commonly used for medical imaging binary data (ultrasounds, xrays, MRIs, CTs). However, some metadata is often put into the DICOMs also.

Reply on news.ycombinator.com