Hacker News new | ask | show | jobs
by mcphilip 3385 days ago
>Rather than trying to find a system that could be universalized, the (idiotic) plan has been to give millions of dollars to multiple corporations to develop systems, then subsidize the purchase cost to providers to encourage adoption. Then, only once everyone has invested in their own proprietary system will they begin trying to universalize the system by developing cross compatibility.

This is misinformation. Interoperability via HL7 messages has roots in the 80s. The subsidies encouraging provider adoption of EMRs during Obama's administration set constraints on qualifying EMRs including a certain level of support for interoperability. The government sensibly leveraged existing standards produced by those free market forces you decry.

2 comments

I don't think we will ever see HL7 messages exchanged between organizations. Each product has it's own list of message types that they support, and even then they will vary in terms of which segments have data and in some cases, even what that data will be. Patient identifiers also vary between organizations, making it hard to know which patient goes with which piece of data.

Alternative methods for passing data between organizations have been proposed, but the vendors as well as the hospitals have been fighting this tooth and nail. The big EMR vendors are dragging their feet (and cashing government checks) but hospitals aren't pushing for this functionality either. IMHO, hospitals also would prefer to keep patient data to themselves.

I work at a top 10 EMR on the interface engine team. Messages between products require a lot of custom work to align message types and IDs, establishing a compendium of identifiers for external labs and identifiers, but it's not uncommon.
Yeah, but I can't take my data from Epic and move it all into Cerner via HL7, no matter what.

What we need are government standards for data at rest, similar to DICOM, for other data - and tied to Medicare reimbursement. Literally some functionary at CMS could write that rule and patients would be better off.

Or machine learning to mechanized the matching.
You haven't been paying attention. I've been working on products which exchange HL7 messages between organizations for 20 years. It's very common now. Some configuration work is usually needed on each interface but that's mostly a solved problem.
I think he likely meant "I don't think we will ever see HL7 messages exchanged between organizations [routinely and with little effort]."

"some configuration work is usually needed on each interface" is the key phrase in your response. Just because many organizations have poured cash into yours and your competitors' solutions when the economic stars align does not mean that message passing between organizations is a solved problem.

My experience has been closer to that of mcphilip, every time we bring in a new system we end up with consultants from both sides (the new product and the hospital information system) and the cost is quite high. Where I work, exchanging HL7 messages directly with another organization has never been on the table and we have done a couple interop projects with other area hospitals.

That said, in my opinion the two organizations looking to exchange messages would need to have a pretty good relationship and a real business need in order to pursue this strategy. They may also have to compromise on dictionary values, etc., in order to have comprehensible data on both sides. For organizations with even a modest amount of rivalry, I can't see them spending this kind of time, effort and money.

My understanding was that "meaningful use" would make interop much easier, perhaps on a higher level than HL7 messages. In my experience this has not been the case.

My experience is that "some configuration" translates to 6 months and 50k$. Especially when the really big vendors are involved and when those vendors have competing products.
HL7 interop is a joke.
To elaborate for the uninformed:

HL7 is literally just a syntax, and one that isn't reliably followed at that. It makes no solid guarantees about the semantic structure of the messages, and so is next to worthless.

For a simple analogy, consider that two companies have agreed to write contracts in English--and little else.