Lately, I’ve been describing the standards process that we’re engaged in – making a difference to people’s health through defining healthcare IT standards – as a process that has 3 legs. Kind of like this:
Well, not really. It’s actually 3 legs of a journey. The 3 legs are:
- Developing the base standards
- Profiling the standard for particular communities
- Driving Solutions into production in the market
#1 Developing the Base Standards
The first leg is developing the base standards the define the capabilities for describing and exchanging healthcare. These base standards enable all sorts of communities to form around exchanging healthcare data.
But given the breadth of healthcare, and the variety of processes, jurisdictions and business rules – along with the fact that there’s no single authority of these things (in as much as there’s any authority at all), these are platform standards: they create platforms that are used in all sorts of different ways. They define how things can work.
Example Standards:
- FHIR + v2 (from HL7)
- Snomed CT
- LOINC
- DICOM (from NEMA)
- etc (there’s 100+ organizations creating platform standards)
They’re also limited in that they can only make hard rules that everyone in the world agrees to – which is a lot less than an particular set of rules that a single solution needs. So they don’t define particular solutions, except in the rare case that everyone in the world agrees to the solution (we actually might have a couple of those things: consumer healthcare repository, and terminology service).
#2 Profiling the Standard for Particular Communities
Once the international platform specification(s) exist, particular communities find common use cases for which they need to determine and record their business rules, and converge on a common approach for using the platform standards. These are called various things – profiles, templates, value sets, reference sets, implementation guides. But in all cases the basic steps are the same:
- identify the need for a particular solution
- form a smaller community around it
- support the community to converge and agree on a particular approach
- publish the approach and help the community test it’s validity
- iterate the process
The principle is simple: a smaller communities can get more agreement amongst themselves because they have more in common (and are sometimes empowered by hard rules/regulations/laws – when they are useful)
There’s lots of organizations working in this space. Some relevant in the FHIR eco-system:
- IHE (this is the classical space owned and brought into focus by IHE, from RSNA and HIMSS)
- Argonaut + Da Vinci
- CarinHealth Alliance / the Sequoia Project
- National Standards Organizations profiling FHIR / v2 / CDA
- National Snomed Release centers (among other things they do)
- etc (lots)
Aside: Platform vs Usage
Note that the demarcation line between leg #1 (platform) and leg #2 (usage) is grey. I think of XDS as a platform standard, even though it’s technically profiling other standards. Thing is, that’s what FHIR does too, and it’s very definitely a platform standard. The question is far more about community and process than technology, and XDS has played out more like a platform standard (though it’s not that important which it is)
At first encounter with the standards process, many people challenge the value of the platform/usage split – why not just get it right in the first place? We’d love to – but the trade-off between community size and level of agreement is a hard external fact we can’t wish away. Given that, if you don’t create the platform/application split, the result will be a shattered standards system with myriads of incompatible standards, one for each variation of the use case and all incompatible. Which is (unfortunately) too much like what we have now. 😒 It’s really nice the first time you solve a problem, but the next time you solve a related problem…. then you start to feel the pain. After the Nth time… you really want a platform standard.
#3 Driving Solutions into production in the market
Once you’ve formed a community, got your agreements, published them, and tested that it’s possible… you’re still not done. You created capability, and expectation. But at that point, nothing is actually working (except for limited demonstrations at hotels and exhibitions, typically).
Driving the solutions home – the last leg of the journey – that’s actually the hardest part of the journey. IT solution providers (vendors, usually though not exclusively) are often happy to collaborate in a community process, and demonstrate cool stuff to sell, but bringing stuff to market involves messy processes like certification, sales, deployment, contracts, and many people have to sign off on the process and someone has to fund the deployment/testing/maintenance.
This is the primary source of the Gartner Trough of Despair, and we’re certainly hearing that this the case with FHIR:
- The platform standard is doing well – 4th release, normative, lots of energy and adoption spreading like wild fire (sorry)
- There’s plenty of projects around profiling / usage agreements from IHE and others. In particular, the Argonaut project has created a huge potential in USA with access to EHR data
- But – case in point – actual argonaut end-points are not widely available, and getting access to them, even when in production, can be very difficult
HL7 has pretty much no leverage over the 3rd leg of the process. IHE has more, but not as much as everyone would like. Argonaut, in their smaller community, has more again – but still not enough. Classically, the agents that have influence/leverage over the 3rd leg are the regulators (hello CMS, ONC and the NPRM), but professional societies such as HIMSS and HISA also have influence, since their membership is much more provider based.
HL7 and the FHIR community are starting to pay much more attention to the whole 3 legs, and looking to work much more pro-actively with critical partners like IHE, HIMSS etc to see what we can do to make as much as possible real.