20 Questions #6: Optionality vs Extensiblity

Sep 9, 2014

In the 6th question of the 20 Questions series,  Greg Meyer, asks:

Optionality vs Extensibility: What effect is the large selection of standards and technology in the health IT domain having on interoperability? Do we need to eliminate optionality and focus more on extensibility?

There’s a bit more context with the question:

In my view, optionality is the death sentence of interoperability. That statement deserves a bit a context starting with the definition of optionality. Simply stated, optionality is the ability to choose one or more entities with complete disregard to supporting alternate entities. Applying that to interoperability, it means you can choose a single option (or multiple) from an enumerated set of options to perform a task without the requirement of supporting the rest of the options in that set. The result is a multitude of systems supporting different option sets where there may be no intersection of compatible options. The end game: no universal interoperability.

The real problem here is lack of alignment of use cases. Why aren’t the use cases aligned? Maybe the options truly are irrelevant - for instance, there’s no point expecting a physiotherapist package to supporting prescribing medications, for instance. On the other hand, two applications that both are a core EHR, why don’t their use cases match? There’s a number of reasons for that, including that there’s no consensus in medicine as to what the core use cases are. Also application history/legacy, different marketing/product strategies, and the personal choices of the key clinical and technical people as the application was taking shape.

If 2 applications don’t share the same set of use cases, then there won’t be any interoperability between them, or it will be fitful - like pasting content between word and a browser and vice versa - it kind of sorta works. Most of the time, but you’ll often have to manually fix it for things that didn’t work how you wanted it to. In these cases, the choice of optionality vs extensibility is moving deck chairs around on the titanic, and there’s not much you can do. Following this thought experiment, it means that resolving optionality is the same as resolving the use cases, and the problem is that IT people can’t do it, and clinical people don’t yet see the need to do it.

Given that we can’t resolve the problem, which is the best way to do it? In HL7, we generally call this the minimal vs maximal approach. We have a set of use cases that create overlapping wire format requirements - should we express the super set of all of them, or the subset of only what they all share? Put like this, it’s obvious: the minimal set that all use cases share is not (generally) capable of supporting any of the individual use cases, and a specification that is minimal doesn’t work for any of them. So in practice, we produce standards that are half way in-between - not minimal or maximal - and in FHIR, we’re trying to be explicit about that.

Does that mean we don’t care about the minimal problem? No - the full HL7 methodologies for the various standards are capable of expressing the idea of minimum conformance - this is the minimum capability that you must have to be conformant. There’s a few problems with this though:

  • The capability for this is mostly lost in the overall complexity, and the tools to support it are poor
  • It’s not usually HL7’s business to force people to comply, so there’s often not a lot of point trying to capture this
  • It’s extremely difficult to capture this information

The consequence of this is that the minimal set is hardly ever expressed.

On that last point - it is extremely difficult to capture the information about the minimal set of shared requirements/use cases. It’s easy for an open community to capture use cases that aren’t handled - this can be expressed as “your standard doesn’t work for this use case” - a fault with the community product. But to capture the set of minimal agreement requires the members of the community to say something like “we don’t do this” - making it sound as if the fault is with the member. Very hard for a community to get it’s members to do, and vendors- and even providers - are extremely reluctant to do that (in fact, in practice, the decision to release that kind of information often has to be approved at the C-level). In FHIR, we’re setting up a special system to cater for gathering this kind of information through a trusted proxy so that there’s no possibility that observers will be able to trace information about the minimal set to any particular source, but it remains to be seen how well that will work.

Interoperability remains a tough problem.