6 votes

Open standards may finally give patients control of their data and care via Electronic Health Records

4 comments

  1. [4]
    Gaywallet
    Link
    As someone who works in healthcare IT, I practically don't even know where to start with this article. For one, he starts off by claiming that most data is in the cloud. This is absolutely not the...

    As someone who works in healthcare IT, I practically don't even know where to start with this article.

    For one, he starts off by claiming that most data is in the cloud. This is absolutely not the case in the United States. I can't speak for other countries because I do not know their healthcare law, but in the US, HIPAA makes it so rigorous standards need to be obeyed in terms of security of how the data is stored and accessed, and because of it the healthcare executives are deathly afraid of cloud storage. They are afraid because it opens them up to the possibility of being sued by the US government for a very nontrivial amount of money. Realistically, cloud storage is much safer than what we end up with, but good luck convincing a CIO at a healthcare company that it's a good idea.

    Next, he jumps into talking about how he devised the idea that EHRs need to talk to each other and standardized EHRs "around 1989 or 1990". Has he never heard of HL7? This is precisely how EHRs currently do talk to each other, and it has a standardized format for transmitting data. HL7 was invented in the late 70s on the back of precursors that existed for the same reason. News flash - HL7 engines are primarily what drives the data exchanges that we currently do have and if your record is sent from one hospital to another nowadays, it's almost guaranteed it was done through an HL7 message (or, unfortunately, as a PDF).

    The rest of the article basically jumps into what seemed like a sale point to me - pushing his idea that he showed off at HIMSS. I've seen plenty of these proposed solutions for interoperability over the years, and there's a great XKCD article on this. We don't need another standard, we need people to do a better job using the one that has existed since the beginning. Quite frankly that's not going to happen until they add more incentive to do so. Meaningful Use (see the HITECH act of the 2009 ARRA) has already provided several requirements in terms of sending and receiving records and was probably the single biggest incentive to EHR vendors to start implementing HL7 engines and other means of sending and receiving data. More aggressive legislation requiring the ability to send and receive and for patients to view their own records is how we're going to get to this promised land the author wants to see.

    3 votes
    1. [3]
      patience_limited
      Link Parent
      Hello, fellow slave to EHR interoperability! I've seen every god-awful, jacked-up method of exchanging data among EHRs (mostly because our EHRs are either badly home-grown and/or sinkholes of...

      Hello, fellow slave to EHR interoperability!

      I've seen every god-awful, jacked-up method of exchanging data among EHRs (mostly because our EHRs are either badly home-grown and/or sinkholes of technical debt), and I'm sad to admit that I came up with one myself (basically, scan-to-PDF e-mail attachment with some back-end automation). We're still manually filing PDF's that aren't OCR-indexed.

      I've had the joy of trying to push adoption of a promising interoperability product for edge cases, in an institution that's currently supporting somewhere upwards of 1,000 HL7 interfaces with MIRTH (though we're slowly migrating to Corepoint). It takes stupid amounts of time to set up HL7 interfaces among institutions - navigating more-or-less paranoid security, specifying data types, creating VPNs and firewall rules, maintaining interface engines, and documenting the whole mess.

      You can negotiate sexual consent with more uniformity and efficiency, and with less peril.

      It's hard to call HL7 a worthwhile standard for posterity when it's privately maintained (supposedly not-for- profit). It takes months and years of expensive study to properly formulate a message that's barely distinguishable from an ASCII text file, and has 2,000+ named data types. It's not that damned hard to map fields from one database to another. HL7 also charges licensing fees...

      There is absolutely a need for interoperability based on open standards, which is why big players like Amazon and Google are interested, and more and more EHRs support APIs. HL7 FHIR is finally trying to behave like an API, so time will tell.

      3 votes
      1. [2]
        Gaywallet
        Link Parent
        Ain't that the truth. Agree to disagree here. There's an unlimited number of ways to store data and even among major players (Cerner, EPIC, VISTA, Allscripts, Athena, etc.) some very basic...

        It takes stupid amounts of time to set up HL7 interfaces among institutions - navigating more-or-less paranoid security, specifying data types, creating VPNs and firewall rules, maintaining interface engines, and documenting the whole mess.

        Ain't that the truth.

        It's not that damned hard to map fields from one database to another.

        Agree to disagree here. There's an unlimited number of ways to store data and even among major players (Cerner, EPIC, VISTA, Allscripts, Athena, etc.) some very basic information is stored in vastly different ways. Having worked extensively with the back-end of a few different major EHRs, I can confirm it's a fucking mess.

        As fucked up and complicated as HL7 is, that's really it's purpose. Maybe another standard that does something similar would work fine, but the reality is that most of the major players have already started on HL7 integration engines (if they don't already offer them) so we might as well start with the devil we know...

        big players are interested

        They sure are, they just aren't willing to drop the money to fix the problem 😂

        2 votes
        1. patience_limited
          Link Parent
          You're right, and I was wrong to be so dismissive of the mess; I'm just angry about the vendor lock-in. Medical records represent a complicated(!) data set, and every EHR is a Galapagos island of...

          Agree to disagree here. There's an unlimited number of ways to store data and even among major players (Cerner, EPIC, VISTA, Allscripts, Athena, etc.) some very basic information is stored in vastly different ways. Having worked extensively with the back-end of a few different major EHRs, I can confirm it's a fucking mess.

          You're right, and I was wrong to be so dismissive of the mess; I'm just angry about the vendor lock-in.

          Medical records represent a complicated(!) data set, and every EHR is a Galapagos island of evolved ways to slice and dice this data. Then layer in all of the coding, insurance/billing requirements (if you're not in the U.S., you have no idea), and institution-specific modifications.

          EPIC carved out dominant market share through its ability to customize its EHR. That's how you wind up with proprietary interfaces to other systems that cost 5 figures/year, and take months or years to roll out. They've gotten better, mostly because of the changes in legal requirements and competition.

          HL7 was at least an attempt to classify the data types so that you could have roughly standardized mappings for items that aren't as discrete and well-defined as date of birth or blood type. I'm still not convinced it can be called a reliable standard.

          It's been a few years since I've worked on interfaces; at least the message formatting, data definitions, and secure network communication components are now converging on common standards with FHIR refinements, competitive pressure from Apple's adoption of FHIR for Health Records, and a hefty amount of regulatory pressure.

          1 vote