3 ms·

HL7. Well-structured. Pick one. The HL7 spec might be a standard, with a specification, but it is not a thing for well-structured data. For example, FHIR allow

by shakna 5y ago

HL7. Well-structured. Pick one. The HL7 spec might be a standard, with a specification, but it is not a thing for well-structured data. For example, FHIR allows you to use a standardised shorthand, with a formal grammar. [0] That grammar is well defined... It also happens not be a regular grammar, and it is entirely possible to construct something that will be both valid and undecidable, ala Perl. Infinite parsing and expansion on finite data. [0] https://hl7.org/fhir/uv/shorthand/STU1/reference.html#appendix-formal-grammar https://hl7.org/fhir/uv/shorthand/STU1/reference.html#append...

specialist 5y ago
Yup. After a few years of trying to follow the rules, I just decided to use data scrapping techniques.
paulmd 5y ago
Yes, think of HL7 like XML or JSON. It's a grammar/syntax, it does provide some domain-specific conceptual mapping but you can code the same thing lots of different ways. Emitting a well-formed HL7 message doesn't mean that anybody can actually ingest them. There's also a fair amount of instance-specific coding and going to/from that is always a pain.
- nradov 5y ago
  I wouldn't think of HL7 like XML or JSON, it's higher level than that. HL7 is a standards development organization which publishes multiple separate major standards. Those standards define data models which can be encoded in various different wire formats. V2 Messaging can be encoded as ER7 or (rarely) XML. CDA can only be encoded as XML. FHIR can be encoded as JSON or XML. If you want recipients to be able to ingest your messages or documents then it's crucial for the sender and recipient to mutually agree to conform to a specific versioned Implementation Guide. If both parties actually follow the IG then it eliminates the need for instance specific coding, but of course some organizations still have quality problems.
nradov 5y ago
That isn't an accurate description of HL7 standards. Everyone in the industry understands that the baseline standards (V2 Messaging, CDA, FHIR) are just construction kits. In order to achieve real world interoperability you need an Implementation Guide which profiles and constrains the baseline standard to clearly document the exact interactions and data structures (required data elements, cardinality, code system bindings, extensions). There are dozens of published IGs so find one that fits your use case, or get involved with an HL7 Work Group or FHIR Accelerator and help write a new IG. Anyone can participate and as ANSI accredited organization the process is completely open. I don't understand your concern with the possibility of a FHIR Shorthand expression being undecidable. This just isn't a problem in any real world system. But if you know a better approach then formal proposals to improve the standard are always welcome and will be seriously considered.
- shakna 5y ago
  > I don't understand your concern with the possibility of a FHIR Shorthand expression being undecidable. This just isn't a problem in any real world system. My discovery of the format being undecidable came with the experience of building a system designed to ingest and interop data for an entire state (Victoria) during the construction of Australia's MyHealthRecord [0], which I would classify as a "real world system". It was just one of the many edge cases I found with the standards, and led me to believe that no, it isn't possible to normalize the data that these standards are supposed to encode. And no, there is no way in hell that you can get many thousands of practitioners all to follow a single IG. It's such a lovely set of standards that MHR developed the HIPS Middleware Standard [1] to sit between all HL7 documents and the developer interfaces of MHR. [0] https://www.myhealthrecord.gov.au/ https://www.myhealthrecord.gov.au/ [1] https://developer.digitalhealth.gov.au/specifications/implementation-and-adoption/ep-3456-2021 https://developer.digitalhealth.gov.au/specifications/implem...
  - nradov 5y ago
    Just because it's possible in theory to construct an undecidable FHIR Shorthand expression doesn't mean that's a real problem in practice. Could you give us some specific details about how that issue impacted MyHealthRecord? Have you created a Jira issue and brought it up to the FHIR Infrastructure Work Group, or registered a negative on the latest IG ballot? I'm sure they'd like to know and would try to find a solution. http://hl7.org/fhir/uv/shorthand/history.html http://hl7.org/fhir/uv/shorthand/history.html http://www.hl7.org/Special/committees/fiwg/index.cfm http://www.hl7.org/Special/committees/fiwg/index.cfm A few edge cases are really not a serious concern. There are many organizations using these standards. In fact in the USA we're getting thousands of practitioners to follow a single IG right now because they're mandated to by federal regulation. Of course there will be some technical challenges and defects but those will be gradually resolved over time. And in practice there won't be thousands of independent implementations; instead a few vendors will implement the specifications and then the provider organizations will use that software. HIPS appears to be a tool for doing patient index matching, and for converting between legacy HL7 V2 Messaging and CDA formats. That's useful functionality, but doesn't indicate any sort of problem with FHIR. Instead of complaining about the standards I would encourage you to get actively involved in improving them. The standards development process is totally open and transparent, and the work groups welcome new members who want to contribute in a positive way.

by shakna 5y ago

specialist 5y ago

Yup. After a few years of trying to follow the rules, I just decided to use data scrapping techniques.

paulmd 5y ago

Yes, think of HL7 like XML or JSON. It's a grammar/syntax, it does provide some domain-specific conceptual mapping but you can code the same thing lots of different ways. Emitting a well-formed HL7 message doesn't mean that anybody can actually ingest them. There's also a fair amount of instance-specific coding and going to/from that is always a pain.

nradov 5y ago
I wouldn't think of HL7 like XML or JSON, it's higher level than that. HL7 is a standards development organization which publishes multiple separate major standards. Those standards define data models which can be encoded in various different wire formats. V2 Messaging can be encoded as ER7 or (rarely) XML. CDA can only be encoded as XML. FHIR can be encoded as JSON or XML. If you want recipients to be able to ingest your messages or documents then it's crucial for the sender and recipient to mutually agree to conform to a specific versioned Implementation Guide. If both parties actually follow the IG then it eliminates the need for instance specific coding, but of course some organizations still have quality problems.

nradov 5y ago

That isn't an accurate description of HL7 standards. Everyone in the industry understands that the baseline standards (V2 Messaging, CDA, FHIR) are just construction kits. In order to achieve real world interoperability you need an Implementation Guide which profiles and constrains the baseline standard to clearly document the exact interactions and data structures (required data elements, cardinality, code system bindings, extensions). There are dozens of published IGs so find one that fits your use case, or get involved with an HL7 Work Group or FHIR Accelerator and help write a new IG. Anyone can participate and as ANSI accredited organization the process is completely open. I don't understand your concern with the possibility of a FHIR Shorthand expression being undecidable. This just isn't a problem in any real world system. But if you know a better approach then formal proposals to improve the standard are always welcome and will be seriously considered.

shakna 5y ago
> I don't understand your concern with the possibility of a FHIR Shorthand expression being undecidable. This just isn't a problem in any real world system. My discovery of the format being undecidable came with the experience of building a system designed to ingest and interop data for an entire state (Victoria) during the construction of Australia's MyHealthRecord [0], which I would classify as a "real world system". It was just one of the many edge cases I found with the standards, and led me to believe that no, it isn't possible to normalize the data that these standards are supposed to encode. And no, there is no way in hell that you can get many thousands of practitioners all to follow a single IG. It's such a lovely set of standards that MHR developed the HIPS Middleware Standard [1] to sit between all HL7 documents and the developer interfaces of MHR. [0] https://www.myhealthrecord.gov.au/ https://www.myhealthrecord.gov.au/ [1] https://developer.digitalhealth.gov.au/specifications/implementation-and-adoption/ep-3456-2021 https://developer.digitalhealth.gov.au/specifications/implem...
- nradov 5y ago
  Just because it's possible in theory to construct an undecidable FHIR Shorthand expression doesn't mean that's a real problem in practice. Could you give us some specific details about how that issue impacted MyHealthRecord? Have you created a Jira issue and brought it up to the FHIR Infrastructure Work Group, or registered a negative on the latest IG ballot? I'm sure they'd like to know and would try to find a solution. http://hl7.org/fhir/uv/shorthand/history.html http://hl7.org/fhir/uv/shorthand/history.html http://www.hl7.org/Special/committees/fiwg/index.cfm http://www.hl7.org/Special/committees/fiwg/index.cfm A few edge cases are really not a serious concern. There are many organizations using these standards. In fact in the USA we're getting thousands of practitioners to follow a single IG right now because they're mandated to by federal regulation. Of course there will be some technical challenges and defects but those will be gradually resolved over time. And in practice there won't be thousands of independent implementations; instead a few vendors will implement the specifications and then the provider organizations will use that software. HIPS appears to be a tool for doing patient index matching, and for converting between legacy HL7 V2 Messaging and CDA formats. That's useful functionality, but doesn't indicate any sort of problem with FHIR. Instead of complaining about the standards I would encourage you to get actively involved in improving them. The standards development process is totally open and transparent, and the work groups welcome new members who want to contribute in a positive way.