Bridging the interop chasms

The dilemma for implementers is: how to standardise clinical content yet use it in different clinical scenarios? How to lock down clinical content yet express variation in clinician requirements. How to create clinical content standards when every day the scope, depth and detail of the content is dynamically evolving? And then if we somehow manage to specify the content enough to successfully implement our own system, how to make that solution interoperable with others?

Everyone is running around (often in circles) trying to find the holy grail of health IT, the ‘one ring to bind them all’ of standards and, more recently, the ‘Uber of healthcare’. The sheer number of approaches reflects that there is no clear single approach at this point, no clear winning strategy.

My proposal: if we want to achieve any degree of semantic interoperability in our clinical systems we need to standardise the clinical content, keeping it open and independent of any single implementation or messaging formalism.

I noticed that John Halamka, CIO at Harvard & Beth Israel Deaconess Medical Center, was quoted in a rather unappetising Forbes article yesterday – worth reading for the interesting content but please leave the title and analogy at the door. His quote:

“FHIR is the “HTML” of healthcare. It’s based on clinical modeling by experts but does not require implementer’s to understand those details. Historically healthcare standard were easy for designers and hard for implementor’s. FHIR has focused on ease of implementation.” 

Totally agree: FHIR is the newest technology on the block and indeed many are considering it the HTML of healthcare. It has created a massive buzz of excitement around the world. But remember that HTML itself is a content free zone. Without addition of content, HTML is essentially just a technical paradigm. Similarly, without high quality clinical content, FHIR runs the risk of just being a marvellous new technical approach, elegantly solving our current implementer nightmares. We need more…

I have blogged previously about my experience participating in a FHIR clinical connectathon this time last year: The challenge for FHIR: meeting real world clinician requirements. My opinion about FHIR is neutral. I am not a software engineer. However as a clinician it was not offering enough to meet my recording needs a year ago. Little of my world has been FHIRified since. No doubt the FHIR team have a strategy for that, it will evolve, sometime.

My potentially controversial position is that it does not necessarily follow logically that the clever minds who devised FHIR are best placed to develop the clinical content that will ensure FHIR’s success. The great majority of FHIR models created to date are related to the US domain and within a rather limited scope that are largely focused on supporting existing messaging requirements and simple document exchange.

This is not a FHIR-specific problem – it is ubiquitous across the healthIT ecosystem. We need to transition away from the traditional business approach where the technicians/vendors dictate what clinicians would have in their EHR, and the data structure is determined by software engineers who have to investigate, interpret and then attempt to represent the world and work of the clinician in every EHR. With the best of intentions from both sides there is still a massive semantic chasm between the two professions.

What most technical modellers haven’t yet grappled with is the huge scope of clinical content – the sheer breadth and depth is astounding and as new knowledge is discovered it is also dynamic and evolving, which only compounds an almost impossible task. Most clinical recording in systems to date is relatively simple – usually focused on the ‘one size fits all’ minimal data set approach to enable some information to be shared broadly. It certainly has had some limited success but how long will it be before we realise that we need to standardise more than the minimum data sets.

Minimum data sets are woefully inadequate when we need to represent the detail that clinicians record as part of day-to-day patient care, for patient-specific data exchange with other clinicians, to drive complex decision support, for data querying, aggregation, analysis. Patients vary, so that no one approach will suit all – the needs for a surgical patient, a neonate, a pregnant woman vary hugely. Clinicians vary, so that no one approach will suit all – generalist vs specialist; medical and nursing notes may focus on the same things but from a completely different point of view. Clinical contexts vary, so no one approach will suit all. Many aspects of clinical recording needs recurring, fractal patterns. There are homunculi, questionnaires, normal statements, graphs, video, audio. The ‘one size fits all’ approach to health data standards is an absolute myth – in fact, the truth is actually that one size fits none.

Take the timing of medications as an example. Just this one seemingly simple data element raises a huge number of challenges for EHRs. I challenge you to show me one system in the world that enables prescribing today at the following level of detail:

This is the level of detail that clinicians need today in their clinical work. Yet most clinical systems only cater for the ability to prescribe to the level of complexity where someone can take one tablet, three times a day, after meals. Even if you try to prescribe a skin cream, many systems are unable to do anything but represent it in the most rudimentary way.

Below is the mind map of the current Medication Order archetype:


You can see and download the corresponding archetype that is currently undergoing review here. This clinical content specification is the result of years of research, investigation of existing clinical systems, engagement with vendors and standards organisations and direct clinical informatician experience. The amount of work involved in specifying this common clinical order should not be underestimated, nor should it need to be undertaken ever again if we can get appropriate levels of agreement through international domain expert review! (Please register in CKM and adopt the archetype to participate in the international review.) It is massive. It is hugely complex.

Via a similar process, we have just achieved a consensus view on our Adverse Reaction Risk archetype: 12 review rounds completed; 91 participants from 16 countries; 182 total reviews; 0 face-to-face meetings! A core concept in any clinical system, with every system implementing it slightly differently. Now we have a line drawn in the sand, a starting point for being able to share adverse reaction data that has been designed and verified by clinicians, yet immediately computable. This work was done in collaboration with the FHIR/HL7 patient care community – note the joint copyright!

Archetypes bridge the semantic chasm between clinicians and software engineers.

Using archetypes as the means to represent clinical knowledge in an open, non-proprietary way is major breakthrough in our quest to “help kill the “golden goose” of proprietary EHR data”, as the Forbes article phrases it.

One does not have to be a rocket scientist to recognise that if we leverage the 400+ existing archetypes already in the international CKM, which already incorporates a huge breadth of clinician knowledge and expertise, we can kickstart any serious development of implementable resources for any technical paradigm willing to join in.

There is a powerful logic in actively separating out development of clinical content from the implementation formalism. In that way we can develop, agree and verify the clinical content specifications once. The resulting archetypes become the free, open standard representing the clinician’s knowledge in an implementation agnostic way. Subsequently technical transformations will be able to deliver the content to the implementer in any formalism that they choose. No longer just one archetype for openEHR implementation alone, but leverage the content to develop FHIR, CIMI, CDA, v2, UML resources… Now there is a vision!

Archetypes bridge the semantic chasm between implementation formalisms.

IMO this is probably the greatest benefit : the archetyped clinical content is created once, verified as fit for use by our clinicians, and remains as a governed infostructure resource for the next years, decades and beyond. Governance processes ensure that the archetypes are maintained and can evolve within a robust versioning framework. Different implementations will have the same, standardised clinical content.

One solid truth that we can rely on in the world of technology is that FHIR, HL7v2, HL7v3, CIMI, UML, AML, openEHR and other implementation formalisms will likely be overtaken at some time in the future. As sure as death and taxes. We really don’t want to start the process of building content for the each and every new technical invention that comes along.

Archetypes bridge the chasms created by the volatile fads and fashions in IT: our resulting ehealth INFOstructure will be a non-proprietary representation of clinical knowledge that can withstand and outlast the inevitable waves of technology as they come and go. 

Archetypes are a pragmatic and sustainable approach to interoperability: between professions; between implementations; beyond our current technologies!







Therapeutic Precautions are the ‘new black’!

Clinical modelling around the concepts of warnings, alerts and notifications is incredibly complex and each of the terms are loaded with confusion. It is not going to be easy to navigate this area and achieve a common understanding that will underpin information models for sensible and cross paradigm decision support.

I’ve talked extensively with Rikard Lovstrom (@rikardlovstrom) and I like his ideas about standardising alert notifications in clinical systems but he hasn’t been able to get traction in ISO to take this further.

Sam Heard (@samheardoi) and I also had some robust discussions about this area back in 2012 and I wrote up an early version of our conversation at that time. I’ve just been sharing it with Lloyd McKenzie, relating to potentially aligning some of the openEHR archetypes and FHIR resources, so decided to tidy it up a little and post it, below, for others to comment.

This document is not attempting to be a final solution by any means – consider it an work in progress – but could be a pragmatic basis for standardising the decision support needs around alerts, precautions, contraindications, notifications etc in clinical systems.

You will also note that I have deliberately avoided naming models as ‘warnings’ or ‘alerts’ because the widespread use within the community causes significant confusion. We need a neutral term that embraces these terms, hence the proposal for Therapeutic Precautions – this is a term that clinicians will understand! However systems could potentially implement these models and call them by whatever name they need.


Assumption: the fundamental data representations that will underpin any decision support ecosystem in an Electronic Health Record system will include:

  • Existing Templates:
    • Adverse Reaction List (curated; persistent; versioned) – containing EVALUATION.adverse_reaction archetypes
    • Current Medication List (curated and/or automatic; persistent; versioned) – containing INSTRUCTION.medication, and potentially some ACTION.medication, archetypes
    • Current Problem List (curated and/or automatic; persistent;versioned)
      • Problems/Diagnoses – containing EVALUATION.problem_diagnosis archetypes
      • Past Procedures performed – containing ACTION.procedure archetypes
  • New Templates:
    • Therapeutic Precautions (curated; persistent; versioned)
    • Nota Bene (curated and/or automatic; persistent; versioned)
    • ?Preferences/Directives (curated and/or automatic; persistent; versioned)

Therapeutic Precautions Template

A persistent Therapeutic Precautions COMPOSITION will contain archetypes that are deemed by the clinicians to warrant highlighted representation in the EHR and will provide the basis for visually informing clinicians of issues of therapeutic importance for consideration when providing direct clinical care and to support automated clinical decision support, especially when initiating clinical management such as ordering medication, vaccinations, or diagnostic tests. The contents of this COMPOSITION will be unique for every individual and their purpose is to flag personalised health-related issues for each individual patient. Archetypes within the Therapeutic Precautions COMPOSITIONS are effectively a type of personalised “clinical or therapeutic alert”.

Potential ENTRY archetypes are allowed to be included in a Therapeutic Precautions COMPOSITION might include, but are not limited to:

  • EVALUATION for Pregnancy and Breastfeeding status
  • EVALUATION.precaution – these archetypes identify conditions or states of the patient that are clinically significant and unique or idiosyncratic for this patient. (Precautions such as administration of a live vaccine in a woman who is pregnant is not appropriate for recording as a Precaution as this is a general rule applicable for all pregnant women.)
    Precautions are evaluative/summary statements; not a diagnosis or a test result. Each precaution can be optionally linked to a diagnosis, test result or medication order that is evidence/rationale for the precaution. Precautions such as administration of a live vaccine in a woman who is pregnant is not appropriate for recording as a Precaution as this is a general rule applicable for all pregnant women and should be flagged by a generic knowledge base if the pregnancy status is known. For example:

    • ?Immunosuppressed/On immunosuppressive therapy – linked to medication order for chemo or steroids; or diagnosis of leukaemia
    • Renal insufficiency – linked to renal function tests and/or diagnosis of Renal Failure.
    • Failed procedure – where the clinician deems it inappropriate to repeat it
    • ?Family member is immunosuppressed – so might reconsider administration of a live vaccine to the subject.
  • EVALUATION.contraindication – these archetypes represent absolute contraindications for management and have been identified by a clinician. The name of the contraindication is the name of a medication or a treatment or procedure, which is not represented in the Adverse Reaction list, Problem List or Medication List. For example:
    • Medication administration – identified by means other than adverse reactions, such as genetic testing eg never administer Drug X because they have gene sequence Y.
    • Procedure – such as performing a MRI in the presence of a pacemaker. Rather than relying on the coding of a Pacemaker insertion being recognized in a Problem List, this explicit contraindication can be an explicit expression of what a clinician has recognized should not be performed. Decision Support systems would need to know to look for this kind of information within this model.
    • Live vaccine – if on immunosuppressant medication. Note: need to set a review date for this contraindication when the patient is no longer likely to be on immunosuppressant medication
  • Archetypes for Patient Preferences/Directives – Directives are formally attested; Preferences are not formally attested. Most of these are clinical; but some, like preferred place of care are not andaremorelikelyto be recorded as ‘nota bene’ – consider whether Preference/Directives may need its own COMPOSITION.
    • Blood transfusion
    • Tube feeding
    • CPR Status
    • Intubation Status
    • Antibiotic Status
    • Near death preferences
    • Natural death preference
    • Palliative care preferences

Nota Bene Template

A persistent Nota Bene Template contains archetypes that are deemed important for consideration when making administrative and other non-direct care-related decisions about a patient. Archetypes within the Nota Bene COMPOSITION are effectively a type of personalised “administration alert” or precaution.

  • Legal Constraints. For example, custodial orders or mental health orders.
  • ADMIN_ENTRY.nota_bene – these archetypes represent data that is of use to the clinicians and healthcare providers but does not include information that might inform direct care decision-making. NotaBene are effectively “administrative alerts”. For example:
    • Patient requires infection precautions (eg if MRSA/VRE/HepC positive or in isolation for infectious/outbreak reasons)
    • Patient has a vicious dog in the front yard – beware for home visits
    • Patient has violent partner
    • Patient has been violent in past
    • Patient requires chaperone
  • Patient Preferences/Directives – Directives are formally attested; Preferences are not formally attested.
    • Preferred place of care

The Archetype Journey…

I’m surprised to realise I’ve been building archetypes for over 7 years. It honestly doesn’t feel that long. It still feels like we are in the relatively early days of understanding how to model clinical archetypes, to validate them and to govern them. I am learning more with each archetype I build. They are definitely getting better and the process more refined. But we aren’t there yet. We have a ways to go!

Let me try to share some idea of the challenges and complexities I see…

We can build all kinds of archetypes for different purposes.

There are the ones we just want to use for our own project or purpose, to be used in splendid isolation. Yes, anyone can build an archetype for any reason. Easy as. No design constraints, no collaboration, just whatever you want to model and as large or complex as you like.

But if you want to build them so that they will be re-used and shared, then a whole different approach is required. Each archetype needs to fit with the others around it, to complement but not duplicate or overlap; to be of the same granularity; to be consistent with the way similar concepts are modelled; to have the same principles regarding the level of detail modelled; the same approach to defining scope; and of course the same approach to defining a clinical concept versus a data element or group of data elements… The list goes on.

Some archetypes are straightforward to design and build, for example all the very prescriptive and well recognised scales like the Braden Scale or Glasgow Coma Scale. These are the ‘no brainers’ of clinical modelling.

Some are harder and more abstract, such as those underpinning a clinical decision support system of orders and activities to ensure that care plans are carried out, clinical outcomes achieved and patients don’t ‘fall through the cracks’ from transitions of care.

Then there are the repositories of archetypes that are intended to work as single, cohesive pool of models – each archetype for a single clinical concept that all sits closely aligned to the next one, but minimising any duplication or overlap.Archetype ecosystem

That is a massive coordination task, and one that I underestimated hugely when we embarked on the development of the openEHR Clinical Knowledge Manager, and especially more recently, the really active development and coordination required to manage the model development, collaboration and management process within the Australian CKM – where the national eHealth program and jurisdictions are working within the same domain of models, developing new ones for specific purposes and re-using common, shared models for different use cases and clinical contexts.

The archetype ecosystems are hard, numbers of archetypes that need to work together intimately and precisely to enable the accurate and safe modelling of clinical data. Physical examination is the perfect example that has been weighing on my mind now for some time. I’ve dabbled with small parts of this over the years, as specific projects needed to model a small part of the physical exam here and there. My initial focus was on modelling generic patterns for inspection, palpation, auscultation and percussion – four well identified pillars of the art of clinical examination. If you take a look at the Inspection archetype clinicians will recognise the kind of pattern that we were taught in First Year of our Medical or Nursing degrees. And I built huge mind maps to try to anticipate how the basic generic pattern could be specialised or adapted for use in all aspects of recording the inspection component of clinical examination.mindmapOver time, I have convinced myself that this would not work, and so the ongoing dilemma was how to approach it to create a standardised, yet extraordinarily flexible solution.

Consider the dilemma of modelling physical examination. How can we capture the fractal nature of physical examination? How can we represent the art of every clinician’s practice in standardised archetypes? We need models that can be standardised, yet we also need to be able to respond to the massive variability in the requirements and approach of each and every clinician. Each profession will record the same concept in different levels of detail, and often in a slightly different context. Each specialty will record different combinations of details. Specialists need all the detail; generalists only want to record the bare basics, unless they find something significant in which case they want to drill down to the nth degree. And don’t forget the ability to just quickly note ‘NAD’ as you fly past to the next part of the examination; for rheumatologists to record a homunculus; for the requirement for addition of photos or annotated diagrams! Ha – modelling physical examination IS NOT SIMPLE!

I think I might have finally broken the back of the physical examination modelling dilemma just this week. Seven years after starting this journey, with all this modelling experience behind me! The one sure thing I have learned – a realisation of how much we don’t know. Don’t let anyone tell you it is easy or we know enough. IMO we aren’t ready to publish standards or even specifications about this work, yet. But we are making good, sound, robust progress. We can start to document our experience and sound principles.

This new domain of clinical knowledge management is complex; nobody should be saying we have it sorted…