A Pattern for Cardiovascular Assessment

As part of my work helping to build the Welsh Diabetes record, I have started modelling this with OpenEHR. We have around 3,500 data points of various shapes and sizes and some of these are found in individual assessments. At seemingly random¹ I picked the Cardiology assessment out of nine that we have built and wondered how generic this actually was?

This post will detail the concept of clinical modelling patterns and how these may define an additional dimension to standardisation of data.

But don’t get me wrong: I’m not inventing anything new here. The Slack Group for Clinical Modelling had a channel long before I turned up, but I do not believe that applying patterns to a clinical model is something widely talked about. Within the domain of computer engineering it is very common (see the Larman bible for details) so why not health informatics too?

The Data Set

The context of this data set is of a cardiology assessment carried out by the diabetologist in an outpatient clinic. It is not a specialist assessment as recorded by a cardiologist and the individual observations are at a fairly high level as evidenced by the Normal|Abnormal or Absent|Present options. These questions have accompanying free text fields for further detail to be recorded if needed. As we will see, the parent archetypes from which we can draw the data are more complex as per the OpenEHR mantra of developing the maximal data set.

Everybody Loves Blood Pressure

As this is a clinical composition, the high level archetype used is openEHR-EHR-COMPOSITION.encounter.v1. As detailed in the Clinical Knowledge Manager, its purpose is;

To record the document level details of a single interaction, contact or care event between a subject of care and healthcare provider(s) for the provision of healthcare service(s). This can be either a face-to-face or remote interaction.

The important point here is that is represents a point-in-time assessment and is not designed to be edited over time. Next is the Official Number 1 archetype is Blood Pressure². Everyone I meet loves it. It’s a thing of beauty… It is a go-to archetype for those new to OpenEHR because most people understand the basic concept of blood pressure. At its’ most basic it can be described as systolic pressure over diastolic pressure (e.g. 120/80) but as shown in the archetype diagram, it can get a lot more complicated. Elsewhere in the diabetes assessment we are making use of this basic version for nursing assistants to record (not shown in the wireframe). For the consultant assessment we are recording 24 Hour Blood Pressure. But the good news is that one archetype can be used twice.

Option to Extend

The next question, 'Conduct extended cardiovascular assessment' depicts one of the principle differences between the modeller viewpoint and that of an implementer. The question is framed to assist the user in reducing the amount of options visible to them unless they wish to record an extended assessment. However, from the perspective of the clinical model this tick box is not required as this is primarily a design choice. If the data exists for one or many of the extended questions then it can be assumed that this box was ticked.

The next data items are where things get interesting.

Finger on the Pulse

Two data points concern pulse; Pulse character and Carotid pulse character. When you delve into the archetype you can see that both the general 'pulse' and more specialised Carotid pulse can be represented by assigning a body site of Carotid Artery - Left or Right, which can of course be forced as the only options within the template, constraining out the other elements which are not needed.

So far so good. The OpenEHR approach to tha maximal data model is holding up with one archetype being used for two data points.

Thrills!

The remaining six data points follow a pattern of a positive/present value or negative/absent value dependant on the focus of the question. Of them, only one individual archetype exists for Jugular venous pressure (JVP). The remaining data points can be completed by utilising the Examination findings archetype:

In the above mind map, only the highlighted data points are needed for this assessment with the flexibility of using Clinical interpretation to embed a coded term set. In this case the values for Heart sounds normal or Heart sounds abnormal.

This looks great but there is a pitfall if we rely on Snomed: not all the terms match up (or at least in the same position of the Snomed CT hierarchy). For example there is no direct term for Palpation for heaves\thrills which (presumably) is some form of expression involving 113011001 | Palpation (procedure) but of course we could opt for a local/internal code.

Discussion with Heather Leslie on Slack suggested two sage approaches...

I have two thoughts, depending on the context of your assessment. One is that if this is more of a questionnaire then you may just consider modelling it as a local standardised instrument. Or to use the simplicity of CLUSTER.exam, using SNOMED to identify the structure examined (Carotid artery) and 'Conclusion' to be renamed in the template to your questions e.g. Carotid bruit and add the values Present/Absent - https://ckm.openehr.org/ckm/#showArchetype_1013.1.218. Similarly examine the Heart using this archetype and your Conclusions could be named to 'Apex beat', 'Heart sounds' etc.

The JVP archetype needed tweaking to be fit for purpose by adding 'Conclusion' data point. However, for my purposes it could just as easily be modelled using the Clinical Interpretation archetype.

Things get more complicated when we consider that there are a series of draft archetypes such as Examination of heart which could be used as follows:

This made perfect sense to me but Heather made an interesting point;

By using the Exam of heart archetype, you are modelling with one pattern. And by using the generic Exam archetype for the rest you are using another pattern. Ideally, we'd either do one or the other. But this hybrid is being practical with what you have and there is no choice until some of the other archetypes are developed or this possible newer pattern of specialisations that I alluded to are agreed and developed³.

So, it comes back to the pattern which I find an exciting concept. When we consider "data standards", OpenEHR already adds a governance wrap to the archetype including how it should be used or not used. The template is the clinical use case, and the application of those archetypes. However, there is no hard and fast rule to how those templates should be constructed outside of the core reference model that binds OpenEHR together. So in this case, I am very strongly swayed to remove the JVP archetype and apply the same pattern used elsewhere. But there is a but…

There’s Always A “But”

The debate on how far to specialise or model granular attributes of clinical data will rage eternal. I am fairly sure that it can be a double-edged sword to consider and focus on the fullest extent of the maximal data model. But where there is a reason for an individual archetype then its use must be considered.

JVP has a purpose and a use (albeit vague since this is a draft archetype). It could be that it needs a bit more work to become a V1 archetype, but it stands to reason that where single, definable observations need to be recorded there is a need to define these to a greater or lesser degree. Otherwise we would just follow the FHIR approach of a very generic resource defined by the coded contents which is not too dissimilar to the Examination findings archetype.

I would not advise this as the FHIR Observation resource is just too damned generic to the point of being nearly meaningless in a semantic context. It’s perfectly suitable for the message but not for semantically coherent clinical data storage. The Examination findings archetype has definition and meaning at that level substantiate that data within a clinical context;

For recording a narrative description and clinical interpretation of the findings observed during the physical examination of a body system or anatomical structure.

And that description perfectly matches the use case that I am focussing on.

So…

Patterns. Patterns. Patterns. I’m wearing some informaticist geek credentials on my sleeve when I say I find this concept very interesting. It raises the obvious questions on how these should be defined/implemented/standardised. One of the benefits of utilising OpenEHR for this purpose is that a template could constrain this pattern, only suggesting certain archetypes to be used for an assessment such as this. If this template is adopted as a clinical standard pattern, it could be reused for similar assessments in future and streamline the modelling process. The next step for me is to assess if this works for a more detailed specialist cardiology assessment such as the Acute Coronary Syndrome pathway. More on that soon!

If you are interested in contributing to this template in an editorial review, please get in touch via the Apperta CKM where it is published.

---