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

Hi Derek,

Some thoughts on your post

1. FHIR extensions have several important differences from v2 Z-segments:

• FHIR extensions are named in a globally unique way by a URI, so you don't have to wonder whether my ZPA.2.5 means the same as your ZPA.2.5
• FHIR extensions are discoverable. If you receive an instance that contains an extension, you MUST have access to the formal definition of the extension. (If not, the sender is non-conformant.) In v2, the only way to find out what the elements in a Z-segment mean is to phone the interface analyst at the hospital that sent the message (and sometimes not even then )
• FHIR extensions do, in fact, have formal definitions, which means there's a formal description of what the extension means, what the allowed values are, what other constraints exist, etc.
• FHIR extensions can appear where they need to, not only at the segment level. That makes it possible to extend names, identifiers and other complex structures that v2 provided no easy way to manage other than by trying to link equivalent repetitions
• FHIR has a solid registry infrastructure that makes it much easier to discover extensions that already exist and consolidate on the use of existing extensions rather than always inventing new ones
• FHIR has a robust profiling infrastructure (and starting to be decent tooling) to allow authoring of profiles that dictate what extensions are expected to be supported in particular context and where and when they must appear, which makes the process of governing the use of extensions much better than it was in v2.

Extensions are not a panacea. They can be (and in places, are being) abused. They certainly allow for undesirable divergence. However, they're also essential. Without extensions, it becomes necessary to include everything in the core model. This results in a huge amount of bloat. Canadian developers don't want to wade through address parts designating "house boat across the street from" nor to have to google what a "hijri" date is. Extensions allow the core specification to be limited to those elements that most systems need and, through a profiling framework, to also standardize the more region-specific/discipline-specific/organization-specific requirements in a way that doesn't impose a cost on everyone else.

2. There is a place for governance, but there is also a place for flexibility. One of the nice things about FHIR is that it's much more amenable to agile development approaches. You can easily start sharing new data elements that not necessarily everyone in the interoperability community supports yet. And you can do that without breaking existing receivers. The narrative view ensures that any 'key' information is available to the consuming clinicians, while permitting participating systems to migrate to supporting the new discrete element in a time-frame that works for them. This elimination of the need for single "big bang" migrations (and the corresponding difficulty that results in supporting new features or diversity of use-cases) is one of the biggest benefits to FHIR's single-schema with extensions approach.

3. We've seen, through the v3 experiment, that standardization that's solely driven by top-down governance doesn't fly well. There's a need for a mixture. Yes, we need projects like US-Core, CA-Core, as well as more specific projects in areas like registries, diabetes, etc. to increase consistency and agree on requirements for interoperability in a specific space. But those won't always start at the pan-Canadian level. And there needs to be room for innovation at the jurisdictional and individual software product level because if that room isn't present, it'll be forced in - generally at the price of interoperability.

4. One of the design points for FHIR is that, as much as possible, it should be possible for systems to expose a *single* FHIR interface that meets the needs of multiple consumers. Systems consume the data they require and ignore the data they do not. This reduces maintenance costs because rather than having a separate API for each jurisdiction/use-case/etc., the software only needs to write code to expose its internal data store once. This reduces overall implementation costs, increases uptake and increases responsiveness of implementers to new requirements (because new requirements no longer come with the baggage of creating, testing and forever maintaining another separate interface). This design point does, however, reflect a significant change for specifiers. Specifiers are often used to locking down interfaces to exactly what they want - and only what they want. It means baking in the flexibility of allowing additional data to be present and defining the mechanisms to extract the data needed from within a broader collection.

5. I do agree that there's a need for governance. FHIR allows the same problem to be solved in multiple ways. It carries with it the benefit that even if solutions have different architectural approaches (e.g. REST vs. documents) the underlying data is typically at least easily portable. However, true interoperability does require a governance process that allows the community to say, "This is the architecture and the set of minimum data elements we agree to exchange to solve this problem". Good governance is hard.

One of the other 'laws' Grahame has talked about in his past posts is that interoperability isn't a technical problem, it's a people problem. There's a need for people to agree and, even harder, there's a need for people to agree to change and to incur costs for the broader benefit of interoperability. One of the things FHIR did from the outset was to try to improve governance processes within HL7 to help ensure that the principles underlying FHIR were adequately reflected in the work coming out of the different HL7 work groups. The result hasn't been perfect, but it's certainly been significantly better than what HL7 has been able to produce with past standards. In terms of implementation guides, the governance and quality processes are still very much a work in progress.

A significant challenge for us in Canada is figuring out how to ensure that there's similar good governance in place for the standardization work that needs to happen in the Canadian space. Infoway isn't as strong as it once was from a leadership capacity. We've lost several of the governance structures that would allow us to formally declare something is a "Canadian standard". More importantly, we don't have a deep and broad set of the implementer community engaged and paying attention and providing feedback in a way that would allow us to feel confident in both the implementability and the probability of uptake of any specification that we were to declare a "standard".

In the U.S. they have a mixture of Argonaut (bottom-up, vendor led) and ONC (top-down, government imposed, though vendor influenced) that addresses this governance need to some extent - though in a far from perfect manner. In Canada, we don't really have anything that's national in scope with the same investment, influence or degree of involvement. The U.S. is actually doing a pretty good job of not abusing extensions and ensuring consistency of approach across implementation guides. If we don't figure out how to do the same in the Canadian space, we're not going to get nearly the same benefit out of the capabilities FHIR offers.

Interoperability needs to be priority #1. Flexible is a nice to have. Cheap is a reality. That being said, we need to look at the balancing of interoperability and flexibility. We may have higher flexibility and lower interoperability if we can show a valid use case (this coming from an HL7 co-chair). You can only pick two of those if you have limits and you see things in black and white.

I would happily see some interoperability reduced if it allows for the flexibility needed for Postel's Law: Be strict when sending and tolerant when receiving. We have challenges that strict adherence to the realm of interoperability will cause issues. Interoperability still needs to be #1, but not so far about flexibility that we loose the ability to communicate what is needed in a SHR for clinicians to do their work effectively

So, choosing two is a terrible way to look at the world of healthcare systems.

This is meant as a spark-a-conversation piece... please, let's DISCUSS this very important topic.

Recently, I heard a presenter cite, with some reverence, Grahame Grieve's " 3rd Law of Healthcare Software " which basically posits that there is a trade-off between having digital health software which is: cheap, or flexible, or interoperable... and that we can only choose 2 of these options.

If you haven't already, I highly recommend reading (or re-reading) Grahame's very thoughtful piece. It is from 2011... the very early days of FHIR. I must admit that it does not, for me, quite rise the level of being an immutable law. But it is a useful and memorably pithy statement that helps clarify what are some of the nontrivial choices that face policymakers and digital health advocates in Canada, and elsewhere.

A lot has happened since 2011, when Grahame penned this ditty, so let's revisit an analysis of these trade-offs in light of our present efforts in Canada to go to scale with digital health solutions based on the HL7 FHIR specification.

Flexible & Interoperable -- This represents, in my view, the heart of some of the most unhelpful hype regarding FHIR. I'm leading with this one because I've been hearing a narrative, lately, around FHIR-with-extensions being interoperable. The reason I'm calling out the "hype" aspect is that, in practice, FHIR-with-extensions is not functionally different from HL7v2-with-Z-segments. The most worrying angle to this hype is that there seems to be an implied "FHIR-with-extensions is cheap" message sneaking into the narrative, too. This is fueled by the elation felt by software developers after an afternoon at a hackathon... but has little relationship to the total-cost-of-ownership borne by a care delivery network groaning under the weight of thousands of incompatible Z-segments. We've been there... we've done that.

Cheap & Flexible -- There is absolutely no doubt that FHIR interfaces can be quickly and easily built to operationalize a point-to-point connection between system 1 and system 2. Here is where FHIR-with-extensions shines; it demonstrably is cheap and flexible. Whatever are the message idiosyncrasies of the systems participating in the exchange -- they can be readily accommodated. I believe that's why our American cousins are so enamored with FHIR-with-extensions... it is well-suited to the relative lack of governance in their care delivery network. Of course -- message idiosyncrasies may belie underlying workflow idiosyncrasies... and these can cause genuine incompatibilities that impede interoperability. But interoperability is the constraint being intentionally sacrificed in such situations -- so there it is.

Cheap & Interoperable -- I am willing to admit it... this is (by far) my favourite option. Under this scenario, FHIR's flexibility is constrained by governance. FHIR resources are profiled to meet the requirements of our Canadian context -- and then we exert governance on the broad adoption of a family of national Profiles that represent the CA Core. Moreover, these Profiles describe how FHIR resources operate within defined use cases with conformance-testable pre- and post- conditions and companion specifications that operationalize authentication, authorization, privacy and security. These are Profiles with a capital P (and yes, IHE is very much in the conformance-testable Profile-with-a-capital-P business).

But what about flexibility, you ask? On this point I find myself sometimes nursing a crabbiness that comes with 35+ years of implementation scar tissue. In my view, we need to be grown-up about something, here... flexibility is only worth it when it adds value. If there is a particularly valuable extension, then I expect it to make its way into the CA Core. We can't let a well meaning desire-to-please cause us to lose our focus on an important imperative: interoperability serves care continuity and patient safety -- and these are, for Canadians, the trump cards. Idiosyncratic care practices are, in my experience, more often fueled by not-invented-here syndrome than they are by innovation.

That said -- we have the option to move flexibility (and its associated complexity) to the edges of our digital health data sharing network. Data needed to feed clinical research or to support complicated treatment regimes in hospital does not need to be posted up to our shared health record (SHR) repositories. If we focus on the SHR as a tool to support care continuity and patient safety then we usefully simplify the data exchange requirements and, in so doing, we reduce our need for a proliferation of FHIR extensions. Basically -- not everything in a hospital patient records system needs to be conveyed to the SHR. This kind of thinking is being well progressed by, for example, the smart folks working on the International Patient Summary initiative (IPS). In my view, reliably exchanging an IPS every time we did a care hand-off would have a huge and beneficial impact on healthcare outcomes for Canadians. There's some low-hanging fruit, here.

I'm deeply sorry for how long a blog post this turned out to be. Thanks for reading this far. We have important decisions to make, in Canada, regarding what kind of digital health infrastructure we want to build. PLEASE -- add your thoughts to this thread.