Correct Arity

"FHIR is a standard for health care data exchange"

Welcome to FHIR®

If you're like me, when you go to hl7.org/fhir and read "FHIR is a standard for health care data exchange" your eyes kind of glaze over, you need to look at a bunch of examples to get a feel for it eg AllergyIntolerance:

But that original description covers some interesting stuff...

data

The least controversial part is "data"...yep it's data. Also the operations you can do on the data, for example you can Create an AllergyIntolerance, Read an AllergyIntolerance, etc.

health care

Imo "health care" as a domain is quite bloated. Some resources are clearly medical: AllergyIntolerance, ImagingStudy, Medication, etc. Others health care systems need to manage despite being more administrative: Organization, Claim, Appointment. Btw here is the Claim resource:

standard

"standard" does not mean everyone uses the same data structure. Rather, FHIR is a platform, meaning

this specification usually requires further adaptation to particular contexts of use. Typically, these adaptations specify:

Rules about which resource elements are or are not used, and what additional elements are added that are not part of the base specification

Rules about which API features are used, and how

Rules about which terminologies are used in particular elements

Descriptions of how the Resource elements and API features map to local requirements and/or implementations

Systems do this by profiling fhir, which restricts resources in ways that keep the restricted resource valid for the original. For instance the default Patient may have zero names (0..*), whereas a US Core Patient must have at least one name (1..*). So any US Core Patient is a valid base Patient. But the reverse isn't true: a Patient with no names would not be a valid US core patient. Because FHIR is a platform for profiling, resources can have a lot of elements or very generic elements such as Observation.component, which profiles can then restrict to a smaller useful subset.

"terminologies" means defining the set of strings a value can come from, which can be very complex.

There are also implementation guides (IGs), tbh I do not fully understand everything that can go into these, but it seems like what you publish online with all your resources, rules, documentation, yada yada...

A "standard" with this much complexity is probably necessary as there is no technical solution to the social problem of, for instance, patient names being defined differently in different places. Still it does make the spec a lot more complicated for the sake of extensibility. You want to say ugh, couldn't you all just choose something and stick to it...

exchange

FHIR is for data exchange as opposed to data storage. JSON/XML are nice for sending data from one system to another, but don't map perfectly onto a relational database. Not having a schema might make it harder to guarantee all the data is valid over the years of an application. hl7.org/fhir/storage goes into a bit more depth on this. For instance a FHIR Reference is not exactly a SQL foreign key; under managing joins they say

All the flexibility is required in various exchange scenarios, but it can present challenges for application design when building a coherent data store with resources.

Which again the point of FHIR is exchange not storage, this is fair and probably good design for an exchange format to focus on exchange. At the same time, there's a strong urge to say "well if we're already using FHIR for exchange, why convert it into another format for storage, wouldn't it be so much simpler to store data in a FHIR server". Maybe you have to try just storing resource JSONs and stub your toe enough to not want to, or maybe it's a good idea, idk.

Also on the list of things FHIR maybe should not be responsible for, but it's ohh so tempting to try FHIR for it, is data presentation. A thread on chat.fhir.org asks

Do folks have any examples of FHIR IGs that:

Define conformance statements unrelated to data exchange (such as user interface requirements, logging requirements, etc.)

Are successfully deployed in production

We are having a discussion about whether it is appropriate for a FHIR IG to impose conformance requirements that are unrelated to data exchange. I'd like to identify an examples where that was done successfully (where success = actual deployment, not just drafting a spec that gathered dust).

For context, the guy asking this is from Epic, the big US EMR company that is, if not good, at least not nearly as bad as the alternatives, and probably meets a lot of constraints that most of us don't even know exist. The Epic guy is sceptical FHIR IGs can require elements in the UI rather than stick to the exchange layer, and asks if this has ever actually worked. The strongest example of a FHIR IG poking out into the UI layer is probably Structured Data Capture which defines forms in FHIR, including rendering considerations, enhanced behavior, and automatic population, and is tempting if you want to do everything in FHIR.

Sounds like fun?

This is the part where I plug a little ad for my thing :) if you read all this and didn't run away screaming, try fhir in gleam! Is it good? Uh, other projects such as firely and hapi are probably better, they definitely cover more and have more real use...still, gleam is a nice little language that is (imo) suited for a nice approach to FHIR. Rather than make you check if data has a valid structure right before using it, the approach in gleam is to check if it's valid when first parsing it into a type. Plus nice composable error messages. But yeah, it's a health care standard for data exchange, thrilling stuff!