[killjoywashere]

This is why DICOM is a thing: because hospitals cannot be tied to a vendor for radiology studies. They have to be able to cancel contracts, novate, etc.

Sounds like someone is trying to wrap this up, godspeed: https://spectrum.ieee.org/wearable-health-data-standards

Also, IMHO, I think healthcare is where protobuf could really win over JSON: a protobuf comes with the schema and any datatype can ride the message. Everything you need is there.

Is protobuf a heavier lift to get started? Yeah. So? Healthcare is too heavily regulated (and for good reasons) for this to be a significant issue. The barrier to entry is so much higher than the effort to handle protobuf, that it's lost in the wash.

[legulere]

Apple is already offering to export your health data and they use the HL7 FHIR standard.

It's just sad that FHIR has lots of issues as a standard. On one hand it suffers from trying to model the whole world, similar to the problems of the semantic web in the 90s. Even with the cop-out of extensions for things it doesn't support all the objects are very bloated.

A lot of things feel like ad-hoc solutions and there are tons of pitfalls. A primitive value can be there by the primitive value being missing, but an extension being there. FHIR XML cannot be translated to FHIR JSON without access to the resources' definitions, because elements that have a higher maximum cardinality than 1 are serialized as lists in JSON, but the same way in XML. Yet when you read a FHIR XML or JSON you do not know which resource definition applies because there is no way to know the FHIR version. Variant elements that can be different types do not have the element name als the XML element name, but the element name with the type name added to the end after capitalizing the first letter. Profiling the resources is absolutely necessary to ensure interoperability but it's extremely hard to get right.

In the end FHIR brings a whole lot of complexity, while it doesn't bring much of a benefit.

[nradov]

None of those are really valid objections. HL7 FHIR does not even attempt to model the whole world. It only attempts to model the most common healthcare use cases. Most resource elements are optional and you can just ignore those that are irrelevant to your needs. Resource metadata can specify profile conformance, which implies the standard version. There are a variety of tools available now to assist with profiling. The resource definitions are free open source and available to everyone.

If FHIR doesn't bring much benefit then why is it so widely used? If you need to exchange healthcare data with other organizations then what's the alternative? The older HL7 standards weren't any better.

[legulere]

If you think my arguments are not valid, then why don't you reply to them?

FHIR tries to model the whole world in the sense, that addresses are abstracted so much that all kinds of addresses could be represented with it.

Optional elements are one of the biggest problem of FHIR. You cannot just ignore them. If you show a physician just part of the data they might misjudge the situation. If you are writing profiles it is best to set cardinality of not needed elements to 0..0, so nobody gets the bad idea of writing that data or relying on it.

FHIR does not even commit to its own way it works. The system and value elements of Identifier and Coding are also optional. That is just madness, and exactly what I mean, when I say that it's trying to be abstract enough for anything.

To read resource metadata you need to already know which FHIR version the resource is. Even if you can, going through the profile information seems like a huge detour and complexity for such a simple thing. I don't know why there's not simply a different namespace in XML for the different versions. Also widely used JSON formats like OpenAPI include the version.

Profiling is an extreme mess. If you write profiles it's extremely difficult to get everything right. If you need to work with profiled resources it is hard as well, as working on FHIR resources directly is too complicated with extensions and everything. So you need to create Models that represent the profiled resources and need to write converters. You need to do all of this by hand, trying to understand the profiles from a technical perspective and trying to understand what the other human that wrote the profile actually meant.

Why is FHIR used? In my experience there's a push to use international standards and FHIR best fits that. It's not a technology selected by the people that actually have to work with it.

The alternative is to have a schema of your data (for instance with OpenAPI) that exactly matches your data model and is optimized for generating code from it. No need to understand the extreme complexities of FHIR and far less work.

[nradov]

Custom schemas for your data won't work for large scale interoperability across organizations. I've done FHIR profiling before and it's not a serious problem.

[nradov]

Most of the data generated by consumer health devices would be better suited to HL7 standards rather than DICOM.

[killjoywashere]

Agreed. The point of that example was simple vendor lockin

[leovander]

Healthcare companies following a schema? Ha. Maybe the closest thing to there being any consistency is companies making sure they can be listed in Apple's Health app.

[dragonwriter]

The closest thing is probably companies assuring they can interact with the transaction formats mandated for electronic transactions under the HIPAA transactions and code sets rule, or EHR standards also mandated/incentivized by the federal government.

[nradov]

Most EHRs and other related healthcare applications now have reasonably correct support of various HL7 interoperability formats. Not perfect, but good enough. Much of this has been driven by federal government regulatory mandates.