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.

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.Over 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 n^th 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...

Fractal Electronic Health Records?

Clinicians record their findings and conclusions remarkably efficiently on paper, recording the contextual variations succinctly and in a way that other clinicians can understand. Getting computers to do the same thing – to enable clinicians to record simply in the normal circumstances, but be able to cope with the complex and detailed where it is critically needed - is not a trivial task. Ensuring that a user interface reflects a clinician's work flow and captures the evolving requirements in a clinical consultation is extremely complex. Obviously computers are not as flexible as a human brain; they can only record what is pre-ordained in their programming. We clinicians should expect our electronic health record (EHR) applications to do be able to support our recording requirements and work flow however, in reality, there are very few clinical systems that do this well.

Identifying recurring patterns in clinical practice help to ensure our EHRs can record health information effectively. When we look closely, clinical medicine is fractal in nature.

What do we have to record, display, query and exchange in our EHRs? Lots of measurements such as Pulse, Temperature, Blood gases, Apgar Score, Height, and Weight are pretty straightforward. Those screens are a breeze - type in a couple of numbers and hit 'Save'. Evaluations, diagnoses and assessments are also pretty uncomplicated.

However it starts to get much more complicated when we start to explore history-taking and examination findings - where the bulk of the 'art of medicine' takes place.

Let's think of the evolving nature of a typical clinical consultation. It would be so nice if each patient walked into my consulting room with a single, neatly packaged problem for me to solve, but this is not the norm. In fact the majority arrive with the dreaded 'shopping list or, worse still, with multiple problems that are gradually revealed one by one throughout the consultation. So while computers will capture a linear work flow really well, the typical patient consultation is anything but linear.

But each of these problems will likely be recorded in a common pattern - reason for encounter, history of presenting complaint, systematic questioning, examination, differential diagnosis, investigations, diagnosis, management plan and follow-up.

Consider a simple skin examination. The clinician inspects the patient's back and finds an abnormality - a dark, warty lesion. They record its location, dimensions, shape, regularity, surrounding skin etc, and - oh oh - that there is an area within it with increased pigmentation. Then they focus on the hyperpigmented area - recording location, dimensions, shape, surrounding tissue etc. Then they take a photo for future reference and pull out the dermatoscope - recording yet again the location, dimensions, shape, surrounding tissue etc. There are repeating patterns identified here at increasing levels of granularity.

Recently I've been modeling the examination of the hand. Easy, I thought... at first. OK, we’ll use the general clinical principles to record inspection and palpation of the hand as a whole, including specific hand-related items such as presence of Duypuytren’s contracture, wasting of lumbricals plus circulation, sensation (pinprick, temperature, vibration etc), and strength. Then we need to potentially be able to examine in detail:

• per named finger – again inspection and palpation per digit, plus circulation, sensation, movement of each joint on that finger
• per named nerve eg median nerve distribution
• per named tendon
• per named joint – inspection, palpation and movement of each joint
• per named bone - palpation

And if we found something on inspection of the finger such as a nodule, we need to be able to inspect and palpate the nodule. And if there was a pigmented part of the nodule we'd be documenting it in a similar way to the wart on the back - inspect the pigmentation in detail, including an image of it for future reference. These are incredibly complex recording requirements.

Which way we view or prioritize these requirements will depend on the patient context and the expertise of the examiner. For example, recording needs for a hand examination by a General Practitioner will differ from that of a Rheumatologist or an Orthopaedic Surgeon. Consider also the plastic surgeon about to take a patient to surgery to repair a severed finger will absolutely need to be able to record a detailed breadth and depth of not only the hand and the finger but the digital vessels and nerves that will need their expert attention.

Do you get a sense of the fractal nature of medicine? Repeating patterns in the way we record health information:

• revealed as we repeat the work flow of a typical history and examination process; and
• revealed as we record our findings in more and more detail.

Content modeling for EHRs needs to reflect the fractal nature of clinical medicine accurately, both coarse and fine levels of granularity, and ensuring that the data capture is ‘fit for clinical purpose’.

Inspired by @samheard, as usual;-)