9 ms·

This article understates the issues delivering software solutions to patients, providers, or payers. The lack of data standards has completely crippled the abi

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.

drstewart 14y ago
What about HL7?
- lucidrains 14y ago
  it's delimited by pipes... i mean, it is a standard, but it's far from ideal.
  - narcissus 14y ago
    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.
    - markmark 14y ago
      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.
      - narcissus 14y ago
        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 :)
    - daigoba66 14y ago
      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.
      - narcissus 14y ago
        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.
    - deleted 14y ago
      [deleted]
    - lucidrains 14y ago
      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.
      - rficcaglia 14y ago
        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!
  - pgr0ss 14y ago
    HL7 v3 is xml: https://en.wikipedia.org/wiki/Health_Level_7#HL7_version_3 https://en.wikipedia.org/wiki/Health_Level_7#HL7_version_3
    - deleted 14y ago
      [deleted]
  - nradov 14y ago
    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.
- sachinag 14y ago
  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.
  - nradov 14y ago
    HL7 CDA R2 works pretty well as a data storage format for certain types of medical records.
- skue 14y ago
  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).
- louthy 14y ago
  As the saying goes: "Once you've seen one HL7 message, you've seen one HL7 message".
rmorrison 14y ago
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 http://comprehend.com) are enabling health IT to do things previously unthinkable.
rficcaglia 14y ago
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.)

drstewart 14y ago

What about HL7?

lucidrains 14y ago
it's delimited by pipes... i mean, it is a standard, but it's far from ideal.
- narcissus 14y ago
  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.
  - markmark 14y ago
    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.
    - narcissus 14y ago
      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 :)
  - daigoba66 14y ago
    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.
    - narcissus 14y ago
      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.
  - deleted 14y ago
    [deleted]
  - lucidrains 14y ago
    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.
    - rficcaglia 14y ago
      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!
- pgr0ss 14y ago
  HL7 v3 is xml: https://en.wikipedia.org/wiki/Health_Level_7#HL7_version_3 https://en.wikipedia.org/wiki/Health_Level_7#HL7_version_3
  - deleted 14y ago
    [deleted]
- nradov 14y ago
  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.
sachinag 14y ago
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.
- nradov 14y ago
  HL7 CDA R2 works pretty well as a data storage format for certain types of medical records.
skue 14y ago
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).
louthy 14y ago
As the saying goes: "Once you've seen one HL7 message, you've seen one HL7 message".

rmorrison 14y ago

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 http://comprehend.com) are enabling health IT to do things previously unthinkable.

rficcaglia 14y ago

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.)