Making sense of 'Severity'

'Severity' is a pretty simple clinical concept, isn't it? I thought so too until I first sat down to create a single, re-usable archetype to represent 'Severity'. I soon discovered that I had significantly underestimated it - the challenge was greater than appeared at first glance.

The archetype development process is usually relatively straight forward - a brain dump of all related information into a mind map, followed by rearranging the mind map until sensible patterns emerge. They usually do, but not this time.

However, the more I investigated and researched, the more I could see that clinicians express severity in a variety of ways, sometimes mixing and 'munging' various concepts together in such a way that humans can easily make sense of it, but it is much harder to represent in a way that is both clinically sensible and computable.

The simple trio of 'Mild', 'Moderate' and 'Severe' is commonly used as a gradation to express the severity of a condition, injury or adverse event. Occasionally these are defined for a given condition or injury, however most often these are subjective and there should be concern that one clinician's mild might be another's moderate. Some also include intermediate terms, such as 'Mild-to-moderate' and 'Moderate-to-severe', but one has to begin to be concerned if these more subtle differences make the judgement even more unreliable, especially if we need to exchange information between systems.

Others add 'Trivial' – is this less than 'Mild'? By how much? Is there a true gradation here? And what of 'Extreme'? Still others add 'Life-threatening' and 'Death' – but are these really expressing severity? Or are they expressing clinical impact or even an outcome?

When exploring severity I found examples of severity expressed by clinicians in many ways. This list is by no means exhaustive:

• Pain – expressed as intensity, often including a visual analogue scale as a means to record it ie rate from 0-10
• Burns – describing percentage of body involved e.g. >80% burns
• Burns – describing the depth of burn by degree e.g. first degree
• Perineal tears – describe the extent and damage by degree – e.g. second degree tear
• Facial tic – expressed in using frequency e.g. occasional through to unrelenting
• Cancer – expressed as a grade, clinical or pathological
• Rash – extent or percentage of a limb or torso covered.
• Minor or major
• Mild, disabling life-threatening
• Relative severity – better, worse etc
• Functional impact – ordinary activity, slight limitation, marked limitation, inability to perform any physical activity
• Short or long term persistence
• Acute or chronic

In practice, clinicians can work interchangeably with any of these expressions and make reasonable clinical sense of it. The challenge when creating archetypes, and other computable models, is to ensure that clinicians can express what they need in a health record, exchange that information safely with other clinicians, allow for knowledge-based activities such as decision support.

In addition, there also needs to be a clear distinction between 'severity' and other, related qualifiers that provide additional context about 'seriousness' of the condition, injury or adverse reaction. These sometimes get thrown into the mix as well, including:

• Clinical impact (or significance);
• Clinical treatment required; and
• Outcomes.

Clinical impact/significance might include:

• None - No clinical effect observed
• Insignificant - Little noticeable clinical effect observed.
• Significant - Obvious clinical effect observed
• Life-threatening - Life-threatening effect observed
• Death – Individual died.

Immediate clinical treatment required might include:

• No treatment
• Required clinician consultation
• Required hospitalisation
• Required Intensive Care Unit

Outcomes might include:

• Recovered/resolved
• Recovering/resolving
• Not recovered/resolved
• Fatal

Then there are those that recovered or the condition resolved but there were other sequelae such as congenital anomalies in an unborn child...

Severity ain't simple.

Over time, and repeatedly returning to it when modelling it in various archetypes including Adverse Reaction and Problem/Diagnosis, I've come to the conclusion that I don't think it is useful or helpful for us to model 'severity' in a single, re-usable archetype. It seems to work better as a single qualifier element within archetypes – then we can bind it in to terminology value sets that are useful for that specific archetype concept and for the use-case context.

When a clinical knowledge pattern is easily identified, creating an archetype is easy - the archetype almost writes itself! So over time I've learned not to try to force the modelling. Some archetypes 'work'; some, like this one, just don't.

Anatomy of an archetype

With this blog I want to establish a simple baseline statement or overview about openEHR archetypes, aggregated from other posts and publications – a reference point if you like – from which we can journey further and in more detail into the issues around clinical modelling using specific archetypes. Archetypes are a strong basis for data liquidity. Create the archetype once, agree through peer-review, re-use when and where required – the foundation for a 'universal health record'.

Definition:

Formal Definition

An archetype is a computable expression of a domain content model in the form of structured constraint statements, based on a reference (information) model. openEHR archetypes are based on the openEHR reference model. Archetypes are all expressed in the same formalism. In general, they are defined for wide re-use, however, they can be specialized to include local particularities. They can accommodate any number of natural languages and terminologies. [Archetype Definitions and Principles]

Clinician's 'lay' definition:

An archetype is a structured, computable specification for one single, discrete clinical concept. - much simpler!

Each archetype is a rich health data specification, defined and agreed by the clinicians themselves to ensure that each model is 'fit for clinical purpose'. Collectively these archetypes together can create an electronic health record 'lingua franca', or an example of PCAST report's 'Universal Exchange Language (although archetypes are not limited only to exchange of health information).

Archetypes can be used to model a range of clinical concepts:

• Simple and straightforward - such as 'Blood Pressure'; 'Body Weight'; or 'Symptom'; or
• Complex, compound concepts - such as 'Medication order', or recording how a 'Procedure' has been carried out.

Purpose

Archetypes are:

• Potential 'agents for change' – allowing knowledge-driven EHRs as an orthogonal approach to EHR development.
• The basis for a coherent and consistent approach for the whole continuum of clinical care and related activities:
  • Recording, storing and querying health information in electronic health information;
  • Exchanging health information - the broader the agreement & governance, the greater the potential for interoperability;
  • Data aggregation;
  • Knowledge-based activities; and
  • Comparative data analysis.

Using archetypes requires:

• A change of mindset – no longer silos of data; no longer message and document driven.
• Upfront planning & coordination in development of archetypes, but not necessarily more time
• CLINICIAN LEADERSHIP & ENGAGEMENT
  • To ensure the quality of clinical data in our EHRs
  • To warrant the clinical data is safe & 'fit for purpose'

Design

Each archetype is designed:

• As a maximal data set effectively everything one can think of about a clinical concept in all situations by the consumer and any and all providers. This design intent is pragmatically constrained to be sensible in some situations, however good archetype design will always ensure that the full model can be achieved through nesting of additional archetypes to create the maximal dataset/universal use-case ideal.
• For the 'universal use-case' – for re-use in any and all scenarios, from use at home, to primary care, community care, hospital care, secondary use and for research.

Each archetype needs to represent the variety of data that is required to represent the information required for all aspects of clinical care and related activities, including:

• The ability to capture both free-text vs structured data;
• Normal statements such as "Nil significant" or "NAD";
• Graphable data;
• Images – eg a homunculus, or a surgical diagram;
• Multimedia including photos, video and audio or an ECG wave format;
• Questionnaires, checklists etc

Think about how the clinician may record the data: different clinicians will need differing approaches to recording their health information and the models need to allow for this clinical diversity. Some will prefer to use more free text and others more structure; some need more detail than others; we need to capture current requirements for recording and exchange while keeping in mind what might be best practice in the near and distant future.

The best designers, without a doubt, have a clinical background. I have seen clinicians and non-clinicians given identical clinical content, but the archetypes produces are surprisingly different. Clinician modellers definitely model their domain better than those who are not familiar with clinical practice. They are perhaps better able to envision the fractal nature of medicine and take that in to account in creating archetypes, especially the complex areas which require nesting of archetypes within each other to capture the depth and richness required in the models.

Integration with terminologies such as SNOMED, ICD or LOINC are strategic and important – the structure of an archetype is not enough to represent clinical information adequately, and similarly terminology alone is inadequate. However the combination of terminology within an archetype structure, by naming elements or provision of value sets, is semantically very powerful. There is still considerable work to be done to determine how to represent the information overlap – that which can be expressed either in the archetype structure itself or via terminology. This remains a 'grey zone' and is a pressing area for collaboration or research.

Archetype classes – support clinician's processes

There are four main categories of archetypes that are useful to understand – each corresponding to classes in the openEHR Reference Model.

1.  Compositions – which correspond to commonly used clinical documents, such as 'antenatal visit' or 'care plan'. 2.  Sections – these are effectively used to assist with human navigation within EHRs and correspond to document headings, for example 'antenatal examination' or 'summary'.

3.  Entries – these are the most common and are fundamental building blocks of EHRs. There are four main types of Entry archetypes:

• Observations – recording measurable or observable data e.g. blood pressure, symptoms or weight;
• Evaluations – recording clinically interpreted findings e.g. adverse event, diagnosis or assessment of risk;
• Instructions – recording the initiation of a workflow process, such as a medication order or referral;
• Actions – recording clinical activities e.g. procedure or medication administration. Actions complement the instruction and can record the ensuing state of the instruction, such as 'completed' or 'cancelled'.

4. Clusters

Lifecycle & Governance

The Clinical Knowledge Manager (CKM) – www.openEHR.org/knowledge - is an international, online clinical knowledge repository under the auspice of the openEHR Foundation that provides:

• Access to a library of cohesive archetypes and related knowledge artefacts;
• Peer review, life cycle management & publication process via a Web 2.0 approach for clinical content, terminology binding, terminology reference set binding and translations;
• Clinical Knowledge governance underpinned by a digital asset management system and providing:
  • Provenance, audit trails, validation checking
  • Release sets for implementation

Archetypes are freely available under a Creative Commons license.

Use

The need for EHRs to be able to represent clinical diversity is absolutely underrated. Existing EHR systems corral clinicians into certain types of recording etc, but for safety we need more diverse ways for clinicians to record what they need for patient care, and also to ensure that what is exchanged is appropriate for the patient and their individual circumstances. A 'one size fits all' document approach to emergency summaries or messages can be potentially unsafe. Elderly, pregnancy, chronic disease, paediatrics are extremely common examples where there are specific additional requirements needed to summary data sets

Templates are computable specifications for a specific clinical scenario or use-case. The openEHR paradigm takes the governed and agreed archetypes from CKM and creates clinically useful specifications that can be implemented in systems by:

• Aggregating the necessary archetypes together; and
• Constraining the maximal dataset archetypes so that only relevant data elements are active.

Examples include all clinical content required for a specific Message, Document, Clinical consultation or Report e.g. a histopathology report, a referral, an antenatal visit or a discharge summary.

In this way we can, in colloquial terms, 'have our cake and eat it too'. At the same time, CKM ensures tight clinical knowledge governance, yet templates allow for expression of clinician diversity.

Benefits

Archetypes provide a 'glide path' to knowledge-level interoperability of health information. They can:

• Bootstrap new application development – a source of agreed clinical content, avoid re-inventing the wheel for each vendor, organisation or project;
• Provide a forward 'roadmap' for existing applications – supporting gradual transition from proprietary silos to common data representations, perhaps via mapping to common messages as an interim step;
• Support data integration – the means to migrate valuable silos of legacy data to a common, re-usable representation
• Enable data aggregation & comparative analysis – the basis for ensuring 'apples' are 'apples', not 'oranges';
• Simplify messaging – keep message content consistent with EHR content;
• Enable knowledge-based activities eg Clinical Decision Support Systems – consistent & coherent; create once, re-use in all systems.

Can clinicians agree?

There have been a number of robust discussions in recent weeks around the claim that clinicians achieve consensus around computable definitions for clinical content. All discussions have been with MDs, some with substantial experience in various international standards organisations. All have been extremely sceptical...

The first challenge: "—What is a heart attack?” - and the response, —“5 clinicians, 6 answers” – and they are probably very accurate!

The second: —“What is an issue vs problem vs diagnosis?” - I'm told that this has been an unresolved issue in HL7 for 5 years+!

—And the third, from an obstetrician: “The midwives want all this rubbish that we don’t” - perhaps an unfortunate way of expressing the absolutely correct need for different clinicians to have screens presented that are relevant to the patient and the immediate clinical task at hand. —Different clinicians have different needs.

—However these are all essentially HUMAN PROBLEMS! Issues about communications, synonyms, value sets, screen display/layout. IT will not solve these issues - as always, the clinicians need to work out the issues amongst themselves. So where CAN we achieve consensus?

Within the openEHR Clinical Knowledge Manager environment we are gaining some traction in achieving clinician agreement to the structure required to define clinical concepts as archetypes – the ‘first principles’ of clinical concepts, if you like. The approach is inclusive of everyone's needs and requirements, rather than requiring an arbitrary decision on the minimum data set or a priority data set - so we aim, as best we can, for a maximum data set.

For example, the framework to express a Diagnosis is largely not contentious:

• Diagnosis name
• Status
• Date of initial onset
• Age at initial onset
• Severity
• Clinical description
• Anatomical location
• Aetiology
• Occurrences
• Exacerbations
• Related problems
• Date of Resolution
• Age at resolution
• Diagnostic criteria

And for a Symptom:

• Symptom name
• Description
• Character
• Duration
• Variation
• Severity
• Current intensity
• Precipitating factors
• Modifying factors
• Course
• Aetiology
• Occurrences
• Previous episodes
• Associated symptoms

This notion of achieving clinician (and other domain expert) consensus and standardisation of clinical concepts is a major focus of the openEHR archetype work.

Bear in mind that while agreement can be achieved on the clinical content structure, this is only the first step in ensuring that clinicians are able to enter, retrieve and exchange meaningful clinical data.

So if we can achieve consensus around these archetypes, do clinicians then have to agree on a standard Discharge Summary or Antenatal Record or Report? The answer: only if is useful to do so. Clinical diversity can be allowed if the archetype pool is stable & governed/managed. By tightly governing the archetypes at international or national level, these are effectively the common 'lingua franca' that enables sharing of health information.

Template creation is the next openEHR layer - these aggregate the archetypes together to represent the requirements for a specific clinical activity and then constrain them down from their fully inclusive state to something that is 'fit for use' for a given clinician in a given clinical situation. Terminology subsets are also integrated in appropriate places into the archetypes (sometimes) and templates (usually) to round out the expressiveness needed by computable clinical models in clinical care - neither the structure nor the terminology can do this in isolation.

Once a critical mass of these archetypes are published we will be able to support a breadth clinical diversity across eHealth projects - the need for rigid, inflexible messages and documents to support any health information exchange has been largely overcome. Clinicians will only need to agree these types of messages or documents where there is a measurable benefit for doing so, and at all other times they can focus on ensuring that they express their archetype-based clinical records as flexibly as they need to for patient care. Sure, the human factors remain unresolved - but not even the most perfect EHR will solve these issues!

So can clinicians agree? Yes! It is happening in many areas related to data structure, creating a solid framework for our electronic health records. Archetypes are the tightly managed building blocks; templates enable safe and flexible expression of clinical and patient records - allowing the best of both worlds, both governance AND clinical diversity to flourish... and the clinicians are finally able to actively participate in shaping their EHRs.