Comment by sachinag | Hacker News Reader

Comment by sachinag | Hacker News Reader

This article understates the issues delivering software solutions to patients, providers, or payers. The lack of data standards has completely crippled the ability for new companies/products to innovate and break through. When I worked at a healthcare VC, we deemphasized IT in favor of medical devices because the path for success is much clearer and easier to trod.

The reason I can be so confident that it's the data standards, BTW, is because the DICOM data standard exists for medical imaging. IIRC, the founder of Heartlab invented the format, it somehow escaped a proprietary home, and dozens of companies innovated on top of it. The existing EMR vendors - GE, Cerner, Epic, etc - all have proprietary data standards for storage and interchange. My due diligence on this revealed that the companies would each have to spend three years re-writing their software against a common data standard. Of course, they should have to. It would help patients immensely and all sorts of innovations would spring forth, just like after DICOM.

I agree that the lack of data standards and interconnectivity is on of several big problems that have traditionally crippled health IT innovation. But, advanced technology is becoming so cheap, and the pain points have become so large, that companies are changing.

Technologies that can compensate for inconsistencies between existing systems (like my company's product, http://comprehend.com) are enabling health IT to do things previously unthinkable.

I would argue that it is the crippling lack of appetite for change and innovation that stifles breakthrough technology that would create a data standard and a thriving interoperable service ecosystem.

The success of an innovative idea will attract the other members of a data ecosystem. ( Your example proves that!) So you need to have innovation first - not standardization. Standardization may follow.

You were right to abandon IT as a VC --- this is an industry that is not about ROI. The only reason I do it is I can afford to subsidize it, fueled by the letters we get from patients thanking us for making their lives better, or saving them a tremendous amount of pain and suffering.

The MDs at the hospitals I know don't do it for the money. Despite the outrageous prices in US healthcare, they get paid pennies on the dollar for 24X7X366 work (they take it home!) and little thanks (and lots of lawsuits). Often their own institutions don't support them. I would never recommend my child be an MD in the US, at least not for profit. (Advice a family friend and physician once told me when contemplating med school, which I took to heart.)

What about HL7?

it's delimited by pipes... i mean, it is a standard, but it's far from ideal.

Technically it's delimited by whatever character is decided to be the delimiter, which is even better :)

Having said that, it still seems to get data between all sorts of systems in the hospital.

In my experience with HL7 it's a standard, but every single system you talk to you need to write custom code to handle them, because everyone talks the "standard" a bit differently.

[edit] and as for the XML v3, nobody uses it. Nobody.

Absolutely (for both points). I found HL7v2 to be more of a 'standard of communication of data' as opposed to a 'standard of data'. A lot of the work I did in my last job was dealing with these differences... I think the best investment of my time was the code I wrote to more easily interact with the messages, just to help alleviate those differences.

All in all, very fun times :)

That I think is the key distinction: HL7 works okay for a group of tightly coupled systems, usually internal to a single organization. The biggest problems today are with data interchange between providers, networks of providers, 3rd party vendors (cloud based or whatever) and the like. The finance and insurance industry have, I think, figured this out. Healthcare has not.

That's a good point and to be honest, I didn't deal much with things outside of the hospital itself (I mainly worked in the ADT 'sphere') but I could see how the 3rd party stuff could get hairy... especially if they're trying to deal with different message formats within the same facility.

lol, yeah, im sure it works. it isn't json tho...

you could also say Cache (it's a post-relational database... whatever that means) is a standard database used in medical systems, but it sure isn't a postgres.

It is an object database which was all the rage back in 1996-ish. I had to use it outside of the medical market once and the sales manager was shocked!

HL7 v3 is xml: https://en.wikipedia.org/wiki/Health_Level_7#HL7_version_3

HL7 V2 actually defines two standard encodings: ER7 and XML. They are both logically equivalent. The ER7 encoding is similar to old EDI standards and typically uses the '|' character as the field delimiter (although certain other characters can be used instead). Unfortunately the XML encoding is poorly supported and most applications use the ER7 encoding.

HL7 is a data interchange format, not a data storage format. You can't code to that spec the way you can to DICOM. EHRcon and CDA are jokes.

And, of course, the vendors who stitch together siloed datasets from proprietary vendors make a killing. So that's yet another group who loves the status quo.

HL7 CDA R2 works pretty well as a data storage format for certain types of medical records.

HL7 is often characterized as a "70% standard," meaning that instead of getting complete agreement from vendors, they decided to standardize most of it. (HL7 3.0 is an 80% standard, but no one really uses HL7 3.0, at least not in the U.S.)

Think of HL7 as a language with many dialects. As a result there are whole industries for translating feeds both within hospitals (integration engines) and between institutions (RHIO/HIEs).

As the saying goes:

"Once you've seen one HL7 message, you've seen one HL7 message".

Reply on news.ycombinator.com