Cheap... Flexible... Interoperable... choose 2. YIKES!!

i sure do agree with your last points, Lloyd. Leadership is everything!

Thanks, Lloyd, for the very thoughtful and thorough reply. There's a lot to think about, as we continue to progress Canada's digital health agenda. I genuinely appreciate these ideas and suggestions and clarifications. All very helpful!

Hi Derek,

The risk in proliferation of extensions really comes from two places:
1. Systems that choose to stick their data into extensions rather than conveying it in standard elements. For example, "I use a SNOMED code for gender, so I'll send that as an extension and won't bother to populate Patient.gender" when best practice is to send both the extension *and* to map their SNOMED code to the Patient.gender value set and send that too. Or "I need to capture the patient's blood type, so I'll stick that as an extension on Patient" when best practice would be to capture blood type as a separate Observation.

2. Systems that define new extensions for concepts that already have extensions and create multiple ways of communicating the same thing.

FHIR provides a few different mechanisms to help mitigate these issues:

• The standard is quite understandable and approachable and has lots of examples, so it's harder (though never impossible) for implementers to misinterpret the spec and decide to stick stuff in extensions rather than where it belongs
• Registries allow implementers and implementation guide/profile developers to see what extensions already exist and leverage those rather than creating their own duplicate extensions
• FHIR's profiling (and associated validation, IG publication and testing) mechanisms make it easier to enforce consistent use of extensions within a particular jurisdiction or other implementation space (and to enforce the use of core elements where that's appropriate too).
• Most importantly, FHIR has an extremely active and responsive community (at chat.fhir.org) that helps guide implementers to appropriately and consistently using existing resource structures and/or 'standard' extensions rather than creating inappropriate or duplicate extensions.

Those mechanisms won't prevent the inappropriate creation or use of extensions, but it's certainly helping. Where it does happen, it's generally where specifications/implementations are created outside the public view by individuals/projects that aren't engaged in the FHIR community. (Which is why it's super-important to encourage involvement in or at least awareness of the community by any one who is or might be implementing or creating specifications.)


The other consideration is that, even where extensions do proliferate, their impact on interoperability isn't as negative as you might initially think:

First, extensions fit within the standard schema. That means that I can receive, validate, pass on and even potentially store instances that contain extensions I don't recognize. As a result, the extensibility mechanism doesn't negatively impact the ability to process the instance as it does with other standards. In v3/CDA, extensions mean pre-processing prior to validation which adds complexity. And neither v2 nor v3 are amenable as generic persistence of extensions.

Second, extensions are safely ignorable. If my system doesn't recognize them, I'm free to throw them away and be confident that if any of them contain essential information, it'll be present in the narrative for the end recipient to read. While some of the data might have better informed my decision support, filtering and other logic, ignoring them won't cause any of that logic to fail or produce incorrect results. (This is true because the non-safe-to-ignore extensions are separately flagged as "modifierExtensions".) Having a human readable representation as a fallback is hugely useful - whether the data is encoded in custom extensions, 'standard' extensions or even core elements.

Third, the most important data to consistently exchange and understand is present in core. Even if there are a lot of extensions present, if I understand the core elements, I know the most important part of the story and I'm far further ahead than I would have been in most prior standards (and, even better, that story is shareable in a consistent way across provincial/territorial/national boundaries because FHIR instances uses a single schema everywhere). Extensions are, by definition, for stuff around the edge, so the fact that there's a risk of reduced interoperability there is mitigated by the fact that it's edge-case data anyhow. And governance allows it to be standardized and made consistent through profiles and implementation guides where clinical/business importance justifies.


I don't think that governance can "ensure interoperability". It can improve it and increase the likelihood of it, but there are many nuances of interoperability driven by differences in culture, legacy, business process, perception of best practice, training, regulation, etc. that make "ensuring" full interoperability pretty much impossible. Governance can (and should) create improvements on the status quo and minimize unnecessary divergence.

I also don't think the purpose of governance is necessarily to curtail the proliferation of extensions. Rather, the purpose of governance is to improve consistency of implementation in the spaces where consistency matters.

For something like "patient health card version", "hijiri date of birth" or "boat across the street from", extensions are the appropriate solution and so long as there's a standard extension that's used consistently throughout Canada/Saudi Arabia/Netherlands respectively, that's fine. And it's also fine if some hospital embeds an extension that says "compliant against super-awesome-project-xyz" in a bunch of their instances that everyone ignores except one hospital-specific recipient. There could be thousands of hyper-local extensions like that in use and it wouldn't get in the way of interoperability. Attempting to impose strong governance on such extensions would be hurtful rather than helpful to healthcare interoperability - because if we make it too hard for implementers to introduce extensions for hyper-local requirements, they'll instead abuse core elements or 'standard' extensions to meet their business need and thereby reduce data quality.


In terms of what we need to do here in Canada:
One of the key lessons that went into building FHIR is that implementation (and thus correspondingly implementers) needs to be the primary focus. Design for the theoretical/best-practice/pet favorite doesn't get us anywhere because it doesn't actually get rolled out at the scale needed to make a difference. We need to be tuned into what implementers can do and are willing to do and focus on implementability (through proof-of-concept, reference implementations, connectathons, etc.) at each stage.

A challenge that we have in Canada is that there are often two sides to the implementer space - the commercial software vendors and the jurisdictional implementations of bespoke province/territory-specific solutions. The latter has typically had more say than the former and the latter have also not done a great job of even pretending to want to be consistent with each other. (There are some exceptions, but they're still the exceptions, not the rule.)

I'm not sure how we fix the politics of that, but if we want to take advantage of technologies like SMART and CDS Hooks, Apple's phone-based data repository and other truly revolutionary technologies (i.e. technologies that have the potential to, and in some places are, really reshaping how healthcare gets delivered), we're going to need to fix that "people" problem. The Apples of the world (because they can't be bothered) and app and decision support service developers of the world (because they don't have capacity) won't really engage in Canada if we can't agree on some basics like "what codes will we use for drugs and health conditions".

I wish I knew how to get the needed governance in place. In the EMR space, a lot of our vendors are the same as the US vendors. And they're running flat out to keep up with the demands of the ONC, their commitments through argonaut and new payor/regulatory demands through Da Vinci. Given the size of the Canadian market, they're not going to pay attention to anything that demands significant variation from the direction they're already running and it's unlikely they're going to step up to take a leadership role here like they have in the U.S. On the smaller side of things, I think the community EMR vendors are wary of being asked to do more than they're already doing and certainly aren't positioned to lead something like a Canadian Argonaut. (I'd be super happy to hear disagreement from vendors on either of the preceding points...)

The governance structures we once had through HL7 Canada and then through the Standards Collaborative are now gone. And Infoway is super gun-shy about standards of any sort, let-alone the notion of pan-Canadian standards. What we have left are grass-roots projects like the Canadian FHIR Baseline Profiles work and efforts to drive consistency around identifier URIs and things like that. That's good work, but I don't know if it will be enough to nudge jurisdictions or vendors to actually align. I think we need some assertive leadership, community building and formal governance. Just not sure how to get there from here

Lloyd -- thank you for these thoughtful responses! And yes, I'm happy to see that we separately teased out some nearly identical points regarding governance.

I wonder if you could clarify a few of your points, please. I'm especially unclear regarding your assertions related to FHIR extensions. I do not dispute that there are technical differences between FHIR extensions and HL7v2 Z-segments -- and that these are important improvements. We agree, too, on the fact that they are essential; that's how we will develop a CA-Core, for example. What isn't clear is whether, in your view, a proliferation of FHIR extensions will undermine interoperability... and in this way, create the same "functional" challenge that Z-segments did.

We agree -- "There is a place for governance, but there is also a place for flexibility." I think, however, that the role of governance is to ensure interoperability... and that this will likely include curtailing the proliferation of extensions that might otherwise occur in the absence of governance. Do we agree on this point, too... or not so much?

Lloyd, you make excellent points about the technical value of a base+extensions approach vs. a maximal+restrictions approach. I like that approach, too, and for the same reasons you do. I also think I deserved to be called out for focusing on only one of Grahame's 3 laws -- especially when he bluntly stated that it's all about people, not technology. That's probably at the heart of my concern. Our problem in Canada wasn't (only) that we had the wrong wire protocol -- so how can a new one be the (only) solution? I'm curious to know what you think needs to be done so that FHIR... or anything else, for that matter... can go to scale and operationalize broad digital health interoperability across our Canadian care delivery network?

It's good that we're aligned on some key aspects of the governance piece.

FHIR isn't trying to diverge from a model-based approach. What it is diverging from is two parts of the v3 methodology:
1. Having the modeling be part of the learning curve for the developers. (We want to keep the learning curve for those who need to build interfaces as low as possible.) In v3, the schemas and element names were directly driven by the RIM, which resulted in complex structures and non-intuitive names which acted as a barrier to uptake. We want a specification that a healthcare implementer with no HL7-specific training can look at and say "Yeah, that makes sense, I can do that". Neither v3 messaging nor CDA met that objective - and thus there was minimal uptake except where there was a top-down push.

2. Design-by-constraint doesn't work. V3 took an approach where the core specification tried to include everything that anyone might need with the notion that the specification would be tightened down as it got closer to the implementation space. The result was that design took way too long (it's hard to get consensus on 'everything' when new use-cases keep coming to the table) and the resulting artifacts were inevitably both too restrictive (causing different jurisdictions to introduce variations the broke compliance) and too abstract/flexible (resulting in different implementers solving the same problem by different mechanisms.

FHIR certainly has a lot of flexibility built in, but not around the 'common' stuff. If you tell 3 different implementers to share allergy information and give them the v3 RIM (or the base CDA spec), you'll get wide divergence and minimal interoperability. (And they probably won't like you very much after trying to wade through and understand the spec.) On the other hand, if you give them the same task with the FHIR specification, they'll be a lot happier, a lot faster, and what they produce will interoperate a lot better. They might not all have exactly the same capabilities (some might capture reactions and severity, others might not) or use the same code systems, but at least when they're sharing the same information it'll be in the same data element. That's a huge step forward.

The v3 RIM still underlies most of the FHIR resources. (Some resources such as StructureDefinition and ValueSet don't live in "RIM-space", so the modeling is still there. But it no longer gets in the way of providing a specification that's intuitive to implementers and the resources are tighter in ways that drive more consistency.

Of course, "some consistency" isn't necessarily "enough consistency". FHIR dictates pretty strict expectations around some things (e.g. vital signs) but is a long way from trying to standardize every CBC, care plan or protocol. Realistically, we'll never standardize everything because we don't have consensus and/or the space evolves too quickly. We can, however, increase the standardization of the highest value pieces - and we can often standardize those in a use-case independent way. We can come to agreement that we're going to use CCDD for drug codes and SNOMED CT for condition and allergy codes and define where "health card version" should be sent without necessarily limiting the scope of those decisions to just "shareable health record" or "decision support" or "disease registries" or anything else. There will of course be additional expectations driven by those use-cases, but hopefully we can get sufficient alignment that an EHR could expose a single interface that meets the SHR, CDS and registry requirements.

David -- thank you for this! You're right, of course... ideally we would all love to be able to get all 3 at once and it does feel, a bit, like we're being asked to make a false choice.

I fear there is a bit of persistent naivete, though, around how difficult it is to get both flexibility and interoperability. To get that, we need to be able to leverage an underlying information model (e.g. HL7 RIM... or OpenEHR's RM) to develop our data exchange models. We tried this approach. It proved not to be "cheap"... software developers needed to traverse a non-trivial learning curve before they could understand how (for example) the HL7 RIM works. Of course... software tooling can help address this (as it has with FHIR). But we bailed on the whole model-based notion once the Americans had decided it was "too hard". They were (largely) our software providers, after all.

My gut instinct is that we'd need to embrace an underlying information model before we could operationalize Postel's law. If we were strict about being model-adherent... then any model-adherent message (even if I'd never seen the exact message schema before) could be ingested by a receiving system. In terms of being flexible enough for clinicians to get value out of the SHR, I think we may disagree. I think that we need to develop CA Core so that clinicians get value out of the SHR. This should, in my view, be the most scope-defining engineering constraint on the whole of that effort.

Frankly, my biggest fear is that we'll back away from a Canadian vision based on broad interoperability. This is totally doable from a technical standpoint. Our challenge is sociotechnical, not technical. Our biggest challenge is governance... and governance is hard. We may find we've disassembled some of the "collaboration-supporting" infrastructure we will need to achieve consensus and go to scale with it.