Having just participated in the Melbourne FHIR Clinical Connect-a-thon, I've come away with lots of food for thought. My impression is that the ability for clinicians to influence the FHIR process will be limited to those in the Connect-a-thon room and additional engagement via email lists and teleconferences, technical artefact review, and a rigid balloting process - this will be challenging. Ultimately, the interoperability problem that we (including FHIR) need to solve is no longer primarily a technical one, but one that is socio-technical: with the imperative that it is driven by the clinicians from now on, rather than the techies/engineers.
A couple of the major points here, others will no doubt come later:
- there is a big gap between the mostly generic FHIR resources currently under development and the full scope of clinical data needed by us clinicians, even if only for FHIR's messaging priority. This can be considered in terms of
- the sheer number of resources required to cover detailed and specific content for broad clinical coverage of general medicine and specialties cf generic resources such as Observation and Condition;
- granularity and level of detail of resources;
- re-use of resources; and
- the focus on data that is currently in use in existing systems, rather than establishing the data specifications that clinicians want and need in state-of-the-art clinical systems - in effect a roadmap for the existing systems to work towards.
- the design of the current FHIR resources for use in messages vs the possibly/maybe increasing expectations of the FHIR community to use FHIR as the basis for electronic health records and data persistence; and
- the reliance on extensions will produce huge pockets of non-interoperability unless these are governed in the same way as formal FHIR resources, which rather defeats the purpose of local extensions.
The rather extensive image below is a real life example of an openEHR archetype/template specification, based for clinician-identified requirements, that is currently undergoing implementation in a new clinical information system. Some components of this template will also be used for reporting and in messages, so this level of detailed content will need to be considered for real world FHIR implementations as well.
Others may disagree, but I think that FHIR will eventually need to be able to recreate this kind of real world content as specified and agreed by the clinicians themselves...
In this image, keep in mind that the black data elements are active; the greyed out data elements are inactive, ie not required by the clinician for this clinical scenario. But still the sheer number of archetypes that are required to cover the number of clinical concepts that need to be used for a teleotology assessment by a remote ENT surgeon are surprisingly large.
To try to represent the range and level of detail for this clinical purpose by assembling current FHIR resources such as Condition or Observation and making them fit for the clinical purpose will render modellers into a world of pain. And, of course, the risk is that each assembly of the name/value pairs in Observation will be done differently by each modeller, resulting in non-interoperability after all. The resources will need to be governed, including local extensions.
With the increasing burden of technical engagement resulting from the incredible expectations generated by FHIR globally, perhaps the clinical content specification should be outsourced to... the clinicians first of all, ensuring that the clinical content can be represented in a technical format for implementation.
It makes good sense to explore how we can leverage the existing openEHR archetypes and the clinician engagement/asset governance processes in CKM as seamlessly as possible to streamline the FHIR resource development and provide a forward path to interoperability. The potential value of transformations from archetypes directly to FHIR resources could solve a number of the issues I raise above...