The fractal and complex nature of the clinician's physical examination is an obvious benchmark test for the capability of any modelling paradigm. If you can't model the clinical requirement for something as fundamental, yet complex and diverse as physical examination, then you need to revisit the approach entirely. In a number of previous blog posts I've used the phrase 'fractal examination findings'. Others identified the concept and it describes the dilemma that @ianmcnicoll and I have faced in trying to solve how to represent it in archetypes. In fact it has taken over 5 years of experimentation to arrive at our latest solution, together with collaboration from our Norwegian colleagues, @siljelb and @jtvaland. It it has withstood our own collective testing to date, and worth sharing more broadly at this point.

Whilst the solution appears mind-numbingly simple to me now, the journey of discovery has been considerably longer and more painful than anticipated. Because of this, I'd like to share the patterns as we have them now - it is preferable to try to prevent others making the same mistakes and to build further on these learnings.

Let’s first identify the high level principles that frame the complexity surrounding structured representation of data for physical examination findings:

Different health professionals record the same clinical concepts to different levels of detail or granularity;
Different clinical purposes or contexts require recording of the same clinical concepts to different levels of detail or granularity
Each of the above statements is further compounded by the individual, clinician-to-clinician variation within the same profession, clinical context or purpose.

There will never be only one, single way to record any clinical record, but clinical examination seems to be an extreme example where we require a robust semantic foundation with strong governance, that can then be expressed in a flexible, mix’n’match approach to be able to cater for each of the differing requirements identified above.

This is where the dual level modelling paradigm simply shines:

archetypes provide the solid, foundational building blocks as source of ‘clinical truth’; and
templates express the variation in the patterns of archetype aggregation and constraint for any given clinical scenario.

Using this approach we can represent the clinical data requirements for representation of physical examination findings in all professional, contextual, purpose-driven scenarios.

A single, foundation archetype

Underpinning it is a single 'Physical Examination findings archetype' - OBSERVATION.exam - which is effectively a very simple framework with minimal clinical content. The primary purpose of the OBSERVATION archetype is to anchor all the other CLUSTER archetypes which carry the detailed clinical data elements. The interchangeability and nesting capability from using the CLUSTER archetypes in different configuration is the key to representing the fractal detail for exam findings.

In the example above, the ‘Physical Examination Findings’ archetype (OBSERVATION.exam) is the default root level archetype that provides the following data nodes:

‘Description’ – to allow a simple text description of all examination findings, or to provide a single place for unstructured data from existing systems to be captured;
‘Examination detail’ SLOT – this is where the 'magic' happens! Into this SLOT any and all clinically relevant CLUSTERs archetypes can be added, or even nested within each other to enable representation of the level of granularity and relationships between each of the examination archetypes. In the example below, three CLUSTER archetypes representing components of an ear examination have been inserted into this SLOT.
‘Interpretation’ – allows for one or more evaluative statements to be made about all examination findings. For example – ‘normal exam’ or other specific summary statements.
‘Confounding factors’ – allows for statements to be made about any factors that contributed to the findings and subsequent interpretation. For example, the child was crying throughout the examination or the patient was uncooperative.
‘Device details’ SLOT – allows representation of any devices that were used as part of the examination. For example, the dermatoscope used to visualise a mole on the skin or the otoscope used to take a video image of the ear drum.

The detailed exam CLUSTER pattern

We have also identified a simple pattern that is applicable to nearly all models representing the detail of the physical examination domain:

‘XYZ examined’ - Clear identification of the specific XYZ examination being done or the XYZ body part being examined;
‘No abnormality detected’ – to enable an ability to record common shortcuts used by clinicians when recording exam findings – for example, ‘no abnormality detected’ or ‘PERLA’ as an acronym for ‘pupils equal and reactive to light and accommodation’;
‘Clinical description’ – to allow for recording a textual description of all findings for this specific examination as the simplest type of structured data collection or, alternatively, as a placeholder for the non-structured findings for this specific examination that might be found in existing legacy data systems;
Positive statements about detailed findings for each specific examination – findings that were observed as ‘present’ as well as where it is clinically important to record things as ‘not present’; plus
‘Examination findings’ Slot – allows for nesting of other CLUSTER archetypes for Physical examination to be nested within the context of this CLUSTER archetype. This is the key to the fractal representation;
‘Multimedia representation’ SLOT – allows for insertion of a purpose-specific CLUSTER to enable the ability to add digital representations of the findings, including annotated diagrams, photos, videos, audio or device data;
‘Clinical interpretation’ - allows for one or more evaluative statements to be made about all examination findings. For example – ‘normal exam’ or other specific summary statements.
‘Comment’ – the ‘get out of jail free’ data node that will allow for recording any additional data that does not fit the current structured data elements.
‘Examination not done’ SLOT – allows for insertion of a purpose-specific CLUSTER to enable a clear statement that a specified examination was not performed

This has become the default pattern on which all recent examination CLUSTER archetypes were built, with the ability to adapt for specific use cases - CLUSTER.exam_XYZ:

And in the real world this can be used to represent the ear examination as per the template below, where the details for Examination of the tympanic membrane (or ear drum) are displayed within the Physical examination findings OBSERVATION.: