8 ms·

HL7 is a joke as are most acronyms in the healthcare tech space. It's like reading through a framework devised by lawyers and policy makers. I cant wrap my hea

• droobles 8y ago
  I used to sit next to a guy at a healthcare startup that wrote some huge HL7 parser, I wonder if they still use it. They were considering open sourcing it.
  • eclipxe 8y ago
    I built an HL7 parser at a startup that was open source. Mirth.
    • CalumSult 8y ago
      I use Mirth, thanks for open sourcing it!
      • eclipxe 8y ago
        Awesome to hear that people are using it - I've long since moved on, but the days debugging my MLLP code were some of my favorite times!
        • nwhatt 8y ago
          Here's Google's MLLP code: https://github.com/GoogleCloudPlatform/mllp https://github.com/GoogleCloudPlatform/mllp
    • markolschesky 8y ago
      I love Mirth and the community that's built around it. Thank you very much for all the work you did on the project.
      • eclipxe 8y ago
        Great to hear! I've been off the project for years, but great to hear the community is going strong! I was the first community manager!
    • deleted 8y ago
      [deleted]
    • scruple 8y ago
      We still use Mirth in a few legacy systems at work. I have fond memories of writing some custom JavaScript modules that were manipulating HL7 data at the time, was some fun work. I believe that they're still in use today, too.
• allyant 8y ago
  Ha! This brings back memories - trying to figure out exactly what HL7 FHIR resource your data belongs to, and how the relationships are setup can take a long time.
• nradov 8y ago
  HL7 is an independent, worldwide standards development organization. Which specific framework are you referring to? I have personally participated in quite a bit of HL7 standards development and I can guarantee you that regulators have only minor influence over the process. HL7 work groups have multiple types of participants including providers, payers, vendors, and regulators. The older HL7 V2 and V3 standards can take a while to learn. FHIR (which is essentially HL7 V4) is a bit easier to understand. But the health IT domain is inherently complex and can never be made simple.
  • fjabre 8y ago
    I was referring to all frameworks/standards that the HL7 org has developed for handling of patient/clinical data. Patient data is not special other than its security requirements. There does not need to be a layer of standards in this space dedicated to handling/transfer of clinical/hospital data between organizations. Private industry & hospitals can solve this without the need for a standards board or HL7 standards. We have enough standards for handling/transfer of sensitive data. Engineers have already solved that with interoperable data systems dedicated to managing and sorting through large sets of data. Healthcare data is simply data. There are plenty of other types of highly sensitive data that don't need an entire organization dictating bloated standards implementations that are already highly fragmented themselves. HL7 is an unnecessary abstraction.
    • nradov 8y ago
      It's always disappointing to see comments like this on HN. We sometimes get engineers on here who wrongly believe that just because they're good at coding (or whatever) they must be experts on anything, even when they have minimal knowledge of the actual problem domain. You obviously haven't read through all the HL7 standards. The core HL7 standards only touch on security tangentially. The primary focus is on message and document formats for clinical and administrative interoperability. The whole reason that HL7 exists as a standards development organization is precisely because private industry and hospitals (plus other stakeholders) formed it to have a governance body for working on this stuff. It's literally impossible to figure out data formats on an ad-hoc basis with more than a few participants. Never mind the legal antitrust and IP issues. Engineers have certainly not already solved data systems interoperability in the general case. Every major industry has its own standards bodies. In health IT especially the engineers usually lack the domain knowledge to make good decisions on their own; the administrators and clinicians have to be involved on an equal footing. Instead of just complaining, if you have actual good ideas to suggest then create a formal change request for the applicable standard. The process is completely open and contributions are welcome.
• Insanity 8y ago
  Yeah, healthcare standards are peculiar.. Not just HL7 though, I find that a lot of the communication formats (with government services etc) are either badly documented or badly designed. Usually, both.
  • nradov 8y ago
    Have you taken the time to enter formal change requests for problems you have found in HL7 standards? Implementers are encouraged to do so, and the HL7 work groups do take those requests seriously. Sometimes you have to take active steps to improve the situation.
    • Insanity 8y ago
      For HL7 I have not done so because I don't actively work with it(apart from helping a colleague every now and then). For other formats provided by the (Belgian) government I have. And even made some PRs to their services :) Which they did merge and overal they do seem open to improvements of their systems and standards.
• Darkstack 8y ago
  I wrote a HL7 ADT parser (version 1/2 with the horrible MSH header) with some fields removed/obfuscated to meet legislation in my country, yes HL7 is a mess, it looks awful, but it works.
• cabaalis 8y ago
  I wouldn't call it a joke because it is functional, but HL7 is terribly unwieldy and IMO is contributing to the lack of innovation in the space.
• jimbokun 8y ago
  I don't disagree with your assessment of HL7 historically, but FHIR documentation is outstanding: https://www.hl7.org/fhir/resourcelist.html https://www.hl7.org/fhir/resourcelist.html Documents both the REST API and JSON and XML formats for every type of resource, with lots of examples, and sufficient detail for anyone to create a compliant implementation. Documentation for all of the datatypes like dates and times, terminologies, identifiers, references, numeric values, and how to serialize and parse them. Cross links everywhere. It's legitimately one of the best documented and well thought out APIs I have worked with. I think they took all the mistakes made and legacy baggage of the old HL7 specs to heart, and did a great job of replacing them with something much better with very high quality documentation.
  • nathas 8y ago
    I disagree. The data format is well defined, but how those documents interact with each other is still a jumbled mess. There's also so much extensibility that someone implementing it could just throw away all of the default fields in a patient's record and create their own, and we're right back to a mess of records that are useless across systems without having custom handlers.
    • nradov 8y ago
      FHIR only provides a baseline starting point which covers the most common data elements. That's why for any particular use case the implementers need to get together and write a detailed Implementation Guide. The IG may include extensions for necessary data elements not covered in the standard. The health IT domain is simply so large and complex that including every use case in a single comprehensive standard would be totally impractical.
  • legulere 8y ago
    FHIR is a bit big of ad-hoc mess: Most specification pages have more shoulds than shalls. Foundational types are a huge mess. For instance there are countless types of references that look very similar but work differently: absolute references, relative references, contained references and references that are replaced as part of a transaction all use the same field. Literal references suddenly lack the type that is referenced which can be not clear from the context. Then there are references that are just free text. Nothing you would expect to be mandatory actually is: code and system are both 0..1 in Coding for instance. A lot of things are not specified how they work at all but just have examples, for instance slicing or how the serialization actually works. Adhering to profiles from someone else is a huge pain in the ass, xml schemas are easier to understand and work with, you gain nothing from using FHIR. If a FHIR rest server does not understand your conditional requests it might just execute them when the condition would evaluate to false. Types that somehow look similar are shoehorned into one type, like transaction requests and search results. FHIR sits in a sweet spot of modeling Health data: not detailed enough to be useful interoperable on its own, detailed enough to not be compatible with other models without a pain in the ass. It’s like the semantic web again where people tried modeling the world. FHIR is a bit like JavaScript easy to get something to work at the start but hard to actually get it right.
• markolschesky 8y ago
  HL7v2 was invented in 1989. It was invented to meet the needs of then intra-operability between existing HIS systems. HL7 itself is a open organization comprised of a variety of members from vendors to health systems to life sciences/pharma. HL7v2's problem is that it is 30 years old and probably should have been replaced by something earlier. Then again, so should most X12, mainframes, COBOL, etc. etc. FHIR is good, but the challenge is that the incentives for interoperability are much lower than those for intra-operability.
  • snuxoll 8y ago
    People love to bitch about HL7, but it gets far too much vitriol compared to X12. You want to talk about an antiquated format that should be taken out back and shot, here is your target. The annoying part is the QACH CORE Connectivity Rule has finally made interacting with health care partners for X12 transactions suck less by providing standard REST and SOAP interfaces for transaction exchange, but we couldn’t be bothered to implement a less shitty transaction format. HL7 is a work of art in comparison.
• bryanrasmussen 8y ago
  Rule: Frameworks focused on heavily regulated domains will read as though they were devised by lawyers and policy makers.