FHIR Extensions

Sep 11, 2012

HL7 faces a fundamental challenge in formulating it’s standards: the business of providing clinical care is wildly variable around the world. The process flows, and even the ways people think about the problems they are trying to solve and describe vary wildly. Further, there’s no central standards body that sets standards for the provision of healthcare process around the world - indeed, for cultural and political reasons, the different countries solve the problems of healthcare radically differently. Even within countries, standards, regulations and funding policies with regard to forcing common practices have dubious success. That’s the context within which HL7 makes standards for exchanging healthcare information. And so, not surprisingly, HL7 can’t write really tight, easy to use specifications.They are full of flexibility to support variable business practices and different ways of understanding and describing the same things. The idea is that countries and projects etc will then take the specification and add their own rules about how it’s used based on whatever agreement they are able to get from the eco-system in which the exchange is going to occur. This means layers, and complexity. There’s no way around this.

The question is, how do you manage this? Generally, you could try one of two different ways:

Define every data element that anyone is ever going to use, and then let the particular implementations exclude things that they don’t use
Define a basic set of data, and let particular implementations add extra stuff when they need it.

Either approach has it’s problems. The first is going to produce a huge, comprehensive specification, and it will take lots of time (and $$$) to produce and use it. Many people will prefer not to use it at all due to it’s unwieldy size. The second approach will mean that every implementation will just add their own extra stuff, and none of them will be able to talk to each other using the extra stuff - and it’s going to matter.

In v2, HL7 took the second approach, and implementers or projects (and even jurisdictions) are allowed to define Z-segments, which allow them to add any additional data to messages, or even to define Z-events that have entirely custom messages. Without the flexibility offered by Z-Segments, v2 wouldn’t really be a workable standard (that’s not to say that every message includes a z-segment. Not at all - just that if this mechanism wasn’t available, it would be very difficult to commit to it).

But Z-segments are a notorious problem as well - use of Z-segments is very often ill-disciplined, and poorly documented, so that you often work with messages where you are guessing what the content is - not a good place to be in healthcare. Also, it’s hard to get vendors to exchange content because they’ve used z-segments differently. Note that you can produce this problem without using Z-segments - that’s easy, but it is very often associated with Z-segments.

Having had a good look at the way option #2 works, in v3, HL7 decided to go with option #1 - model everything known in the base resources. This would avoid the very well-known problems of Z-segments in v2. Only… it turned out to have the predictable problems I described above: lots of time and $$$ to produce and implement the specifications. Note that this is not the only reason for that, but it is a key contributor. And even then, there was still the option to include content in other namespaces - even worse than Z-segments in some ways. In fact, the worst aspect of this is that many schema-driven implementations simply can’t handle these alternative namespace extensions at all.

So when we started working on FHIR, this was a central question: what are we going to do about this problem? The one thing we knew for sure was that whatever we did would be controversial.

To start with, we knew that we needed to allow implementers to use extensions in the message. Further, we wanted it to be ok to use them -unlike Z-segments, which attract fierce criticism whenever they are use. What we have done is:

Defined a stable method for representing extensions in the instance, so that any generated code - whether from schema or something else, and including the reference implementations - is able to read and write all valid instances, including ones that include any kind of extensions
identified extensions by a URI reference, which needs to resolve to a definition of the extension (so unlike v2, you can find out what an extension means)
decreed by policy, that implementers are expected to accept extensions (not that all extensions are acceptable, but that the concept of extensions is ok)

Here, we are trying to strike a balance, a midway path between options #1 and #2. Extensions are allowed, but they must follow a set of rules that ensure that everyone can read and understand them (though of course it’s unlikely to be something you can do with a machine).

So far, so good. But this creates a governance problem: just who is allowed to define extensions? Anyone? HL7 only? Maybe HL7 affiliates? Any of those answers have different pros and cons, and no obvious answer. Even more difficult is the question about who is allowed to change the definitions later, and what kind of changes are you allowed to make?

The initial RFH proposal was that only HL7 would be allowed to define extensions, but it rapidly became clear that it didn’t matter what HL7 could say, implementers wouldn’t believe that HL7 would provide timely support for doing this - and really, I don’t see how it could. And nor would it always be appropriate - why should two developers exchanging content within a strictly controlled environment need to consult HL7 to add an extension? Also, we hope that usage of FHIR scales up to a very high volume….

So in practice, we allow implementers to define their own extensions. We encourage them to register them with HL7 through their local affiliate (if outside USA) or HL7 itself, or even to ask HL7 to define them. But they don’t have to.

This allows implementers to choose how much governance they want to opt-in to. This position doesn’t please everyone - and it’s not perfect because while the price of choosing not to be interoperable is partly born by the implementers, it’s only partly borne by them. Other implementers, system purchasers, national programs - they bear part of the price too.

So how can we handle this - to discourage misuse of the extensions facility?

Make it easy to register extensions (this is a technical problem - tooling and registries)
Make it easy to find existing extensions (this is largely a informatics problem - search in appropriate terms)
Create expectations around acceptable user behaviour (this is largely a social problem)

Other ideas are welcome in the comments.