3 ms·

>However, it seems like this is still not happening, and the convoluted nature of many HL7 standards is certainly not helping. I actually think HL7 (as an orga

by dqv 8y ago

>However, it seems like this is still not happening, and the convoluted nature of many HL7 standards is certainly not helping. I actually think HL7 (as an organization) is beginning to get us to a point where it's not as convoluted. >So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents, and focus on optimizing the accessibility of the data through good full-text document search that can assemble an overview by showing document snippets (i.e., allowing to get a broad cross-document overview through document previews, rather than requiring opening each document individually). I think that's what is intended with FHIR (fast healthcare interoperability resources)[0]: >A domain resource is [a] resource that [...] has a human-readable XHTML representation of the content of the resource IIRC all the other FHIR extend the DomainResource class. So you have the narrative and then the resources (supporting data) that makes up that narrative. [0]: https://www.hl7.org/fhir/domainresource.html https://www.hl7.org/fhir/domainresource.html

cmiles74 8y ago
I would disagree that the HL7 organization is looking to make these standards less convoluted. On the contrary, the large and established vendors help write these standards. In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I have worked on several integration projects, we always had to customize the interface on both sides of the system (the hospital information system on one side, perhaps a radiology system on the other). Moving one step up and exchanging data between hospital information systems and all of the smaller vendor systems is just that much more complex.
- dqv 8y ago
  Did you use something like Mirth Connect? I was going to ask what HL7 you were using, but it looks like you were using v2. > In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I get your point. When I read about FHIR extensions, my immediate assumption was that a vendor would use it to throw a wrench. But FHIR does have an idea of conformance that I think better addresses the issues with earlier standards.
  - cmiles74 8y ago
    Yes, the "interface engine" I worked with was Quovodx Cloverleaf. :-)
- nradov 8y ago
  HL7 standards are developed on a consensus basis by providers, payers, vendors, governments, and academics. The established vendors certainly help, but I deal with their HL7 representatives on a daily basis and I can clearly see that they're working in good faith. The main reason there is flexibility (and convolutions) in the standards is that healthcare is highly complex. Integration projects are thus labor intensive; software is usually a relatively minor slice of the total cost. If you have a specific suggestion for simplifying or otherwise improving any HL7 standard then please submit a formal change request. The process is very open and accessible. I've done it many times myself.

by dqv 8y ago

cmiles74 8y ago

I would disagree that the HL7 organization is looking to make these standards less convoluted. On the contrary, the large and established vendors help write these standards. In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I have worked on several integration projects, we always had to customize the interface on both sides of the system (the hospital information system on one side, perhaps a radiology system on the other). Moving one step up and exchanging data between hospital information systems and all of the smaller vendor systems is just that much more complex.

dqv 8y ago
Did you use something like Mirth Connect? I was going to ask what HL7 you were using, but it looks like you were using v2. > In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I get your point. When I read about FHIR extensions, my immediate assumption was that a vendor would use it to throw a wrench. But FHIR does have an idea of conformance that I think better addresses the issues with earlier standards.
- cmiles74 8y ago
  Yes, the "interface engine" I worked with was Quovodx Cloverleaf. :-)
nradov 8y ago
HL7 standards are developed on a consensus basis by providers, payers, vendors, governments, and academics. The established vendors certainly help, but I deal with their HL7 representatives on a daily basis and I can clearly see that they're working in good faith. The main reason there is flexibility (and convolutions) in the standards is that healthcare is highly complex. Integration projects are thus labor intensive; software is usually a relatively minor slice of the total cost. If you have a specific suggestion for simplifying or otherwise improving any HL7 standard then please submit a formal change request. The process is very open and accessible. I've done it many times myself.