Cardiology templates and archetypes

Clinical
,
1

Hi everyone,

At the University Hospital Basel, we’re excited to announce the start of a major cardiology project. This initiative involves developing templates and modeling cardiology-specific archetypes to address gaps in the openEHR ecosystem.

The first archetypes currently in development are:

  • Duke ISCVID Infective Endocarditis Criteria and
  • European System for Cardiac Operative Risk Evaluation (EuroSCORE) II.

Together with @jannisp and @amanda.herbrand, we are committed to creating detailed, reusable models aligned with openEHR principles and international standards. Transparency and collaboration are key to our work, so we’d love to hear community feedback, ideas, or insights.

Stay tuned for updates, and feel free to reach out if you’re interested in contributing or learning more.

Looking forward to your thoughts,
Olha

9 Likes
2

Awesome :slight_smile:
we did some cardiology stuff, most of it needs some love (different quality) and some of it have had no flow back yet (resources missing) .
I hope you can find smt of use here.

For CAEHR (connecting GP and Hospitals tracking patients etc.), please check the incubator CAEHR on the HiGHmed CKM, here all the models labeled with CAEHR_C where designed for the cardiology use-case.
These contain more up-to-date templates as the HiGHmed UCC ones and some new archetypes for questionnaires (here its not so easy with the IP of these some of them we had to take down from the CKM).

4 Likes
3

Thank you so much for sharing this and pointing me in the right direction! :slight_smile:
I’ll definitely take a closer look at the HiGHmed CKM and the CAEHR_C models.

3 Likes
4

Hi Olha,

Great to see you advertising your work in the community to promote reuse rather than reinvention. Thank you.

It may be helpful if you can post what you think the gaps are in the CKM library or a mind map of the domain scope for your project. IMO many archetypes that may be useful within a cardiology context may not be cardiac-specific. For example, I have many years worth of archetypes uploaded to incubators or early drafts local on my machine that may be of interest even though I have not worked on cardiac-specific projects.

Kind regards

Heather

7 Likes
5

Hi Heather,

I absolutely agree! We already found the Cluster for imaging of the heart and also the ones for Physical examination of heart and lung each, amongst others. We had planned to get in touch with you about how to best further develop those and maybe achieve a stable version when our roadmap has become a bit clearer.
Currently, we are still in a project planning phase. Our high-level gap analysis has shown that many archetypes are already available, however, some (not many) are a .v0 and few missing. Happy to share our gap analysis if of interest.
We are tackling the easier, missing ones first (such as Duke and EUROII) and then moving on to the existing unstable ones. Regarding echocardiography, we are also in touch with Åsa (@Asa_Skagerhult) and colleagues from the ASHA project in Sweden to collaborate.

Let’s stay in touch!
Best,
Amanda

3 Likes
6

Hi everyone,

I have recently joined the clinical data modeling team in Basel and am taking my first steps with the archetype designer. As Olha has outlined above, we are at the beginning of a cardiology project with the long-term aim to model the cardiology documentation (i.e., clinical examination, imaging, interventions etc.).

Currently, I am working on the clinical examination of the heart and cardiovascular system. The idea is to model it with the complete physical examination of all organ systems in mind. So far, I have found the following resources:

• Proposal for the physical examination pattern from Heather:

• CKM project on physical examination findings:

Based on these resources, I have tried to model the examination of the heart, starting from CLUSTER.exam-heart.v0:

Draft-examination-of-the-heart-250402
Draft-examination-of-the-heart-250402719×1121 42.5 KB

The data elements are based on the textbook “Macleod’s Clinical Examination” and the physical examination standard on internal medicine wards at the University Hospital of Basel. It is a first draft and not at all meant to be final. I’m a clinician who has mostly worked in internal medicine and have little experience in data modeling, so the archetype probably looks very crude to experienced modelers. I find it quite difficult to get my head around how to model the complexity of the physical examination. I’m looking for other people in the openEHR community working on this who could provide some guidance, especially regarding the general structure.

At the moment, I’m mostly thinking about the following questions:

  1. Is building specific CLUSTER archetypes for each exam finding, specialized from the generic exam archetype still the recommended way to model specific examination content?
  2. Are there other approaches?
  3. What would be the recommended way to model findings such as cyanosis or oedema (a v0 CLUSTER for oedema exists already)?

Would be great to find other people working on the physical exam of the heart and beyond :blush:

Kind regards,
Simon

2 Likes
7

Hi Simon,

and welcome to the community.

I must confess that you have induced some PTSD in me!!

First the mention of “Macleod’s Clinical Examination” which I clearly remember from my medical student days in the 1970s!! I used to use it to send myself to sleep.

The second is the whole issue of how to do detailed physical examination, which is really, really fraught. @heather.leslie is undoubtedly the expert here having grappled with the problem over many years.

Here is an earlier ‘rejected’ attempt https://ckm.openehr.org/ckm/archetypes/1013.1.111

I would definitely not use that, but I think it helps to see where we have gone in the past and found it problematic

I think the default pattern, is as you say, to specialise an examination around a part of the body or system but how to handle further complexity like heart sounds etc , is I suspect still bit unclear. A large part of the issue is the sheer disparity in the granularity of the exam needed by different clinicians and the context in which the examination is performed. My gut instinct , though(@heather.leslie @siljelb @varntzen might disagree!, is to split out things like heart sounds into a separate cluster archetype to be slotted in.

Expect debate, and good luck. this is real ‘dragon’ territory. I also do sometimes wonder if this is still a valuable area to be recording as structured data, or at least to attempt to standardise, given the increasing use of more definitive examination through imaging etc.

5 Likes
8

Hi Ian,

Thanks a lot for your answer and advice, I’m very sorry for inducing some PTSD in you!

I must admit that I find modelling the physical examination quite mind-boggling and thinking about it too much makes me feel a bit dizzy. So, it’s a relief to hear that it’s tricky even for the most experienced in the community.

Thanks a lot for the link to the rejected archetype, it’s very interesting to see how much thought has already been put into this.

I’ve also been thinking about how much detail in structured documentation of the physical examination is both feasible and helpful in clinical practice. For now, it is definitely a good exercise. Thanks again and have a nice weekend!

Kind regards,
Simon

9

This the real culprit

image
image1049×1500 109 KB

6 Likes
10

Hmm…I’d start with these :rofl:

ChatGPT Image Apr 5, 2025, 12_12_43 AM
ChatGPT Image Apr 5, 2025, 12_12_43 AM1536×1024 303 KB

11

Hi Simon,

Welcome to the community. You’ve not started with an easy task.

Yes, the pattern is still the basis for creating physical exam archetypes.

I would start as simple as you can, especially if this is a new experience for you. Also to keep it aligned with what current systems are recording, knowing that we can grown it and extend it in the future.
More specifically, I would advise you to begin with investing time in developing a mind map outlining your proposed pattern, including links to related archetypes. This is a way of testing whether the pattern will work before you commit to building an archetypes Just adding the data elements that you know you need and are pretty sure will be ubiquitous. While we are aiming for inclusivity of all information about the heart it doesn’t all have to happen at once. That said, the mind map will help identify the road map for other possible data elements or related archetypes as well - effectively an ecosystem of the heart/chest related archetypes.
Only once the mind map is agreed by your peers, would I start to use the Archetype Designer tool. This advice is one of the best kept secrets, in terms of not wasting time. Mind mapping is a much more effective tool to test a modelling pattern.

The oedema archetype originally designed to be nested in any higher level Exam CLUSTER, for example, the theory was to nest it in an archetype related to the lower leg, to record pitting oedema of the calf. But again, looking at this very old archetype, it also needs some more work to make this clearer. OR We need someone to do the investigation (via mind mapping) to work out if it is more efficient to just add relevant data elements in the ankle/leg/sacrum archetypes and if there are other use cases for oedema that would make this archetype inappropriate.
Cyanosis may be best modelled directly and explicitly in the Exam archetypes where cyanosis is examined eg face, fingers or create a reusable one for broader reuse. Again, we need further modelling and investigation before we can make that decision.

There are some heart-related archetypes that have been rejected (and the underlying reason for Ian’s PTSD) and the ‘Auscultation’ CLUSTER that @ian.mcnicoll pointed you to has some good possible content related to heart sounds even though the concept is not correct. Heart sounds could be modelled as an internal grouping/cluster in the Exam of the heart archetype, although I wonder if there is ever a use case where we might record heart sounds outside of a formal heart examination? For example, if there is a rupture of the diaphragm, you can hear breath sounds in the abdomen. Is it also possible to need to record heart sounds within an ‘Exam of the abdomen’ archetype context?

I have certainly used my dusty old version of Macleod to assist in designing these archetypes, but I’d also just caution you to remember that we are not designing them for academic purity but to reflect actually clinical practice, which may be somewhat messy and we need to be able to capture recording for the least untrained or remote health workers who may only be able to document that a murmur is present, through to the most experienced cardiologists who want to document every diagnostic ‘click’.

This is our ‘art’ and calling in designing high quality archetypes and, simultaneously, our collective world of pain! You are not alone, it is challenging but also very satisfying when you ‘nail’ an archetype and it gets published. :smiling_face_with_sunglasses:

6 Likes
12

Hi Heather,

Thank you for the warm welcome and your helpful insights. I’ll definitely take the mind map approach to explore the pattern and connections, and to identify the road map. The examples around oedema and cyanosis really helped clarify the kinds of questions I should be thinking about.

If there are any additional resources from previous attempts to model the physical examination—such as older archetypes not available in the CKM, or documentation of the thought process—I’d be very interested in having a look.

Thanks again for your help!

Kind regards,
Simon

1 Like
13

Hi,

I’m happy to announce that the two scores (Duke ISCVID Infective Endocarditis and EuroSCORE II) are now ready and have been uploaded today to the proposed archetypes on CKM. I highly welcome any feedback and comments.

“EuroSCORE II” is a registered trademark, and we have received permission from the IP holders to use the name in our openEHR model. I have added this information accordingly to the licensing section. Could you please check if it was done appropriately? Should any additional steps be taken regarding this matter? @varntzen @siljelb @heather.leslie

Would it be possible to move these two scores to the Team Switzerland Reviews project so we can manage the review process there?

The next step will be to develop the Heart Echocardiography archetype. We have completed the requirement analysis on our side and compared it with the requirements received from @Asa_Skagerhult. It is a massive dataset (around 320 data items), and I’m a bit puzzled about how to translate it into the openEHR model. I’ll start a new thread to describe the full scope of the issue :sweat_smile:

Cheers,
Olha

3 Likes
14

Hi,

In Region Östergötland, Sweden, we have resumed work on modeling echocardiography measurements. We have been in contact with Basel but sadly their work is on hold for the time being. But their work has inspired us a lot.

We have some questions that we hope to get answers or guidance on here.

Regarding anatomical localization, how deep should we go with specialization archetypes? That a measurement concerns the left ventricle, where is this best expressed? With a new specialized cluster archetype for the left ventricle or in an attribute in a more general imaging examination of the heart cluster archetype or with precoordinated concepts?

Then regarding different modes/views/methods for each measurement. Each measurement can be done in different ways, in different modes such as 2D, from a specific view such as PLAX and with a special method such as biplane. Where should this be expressed? In the observation archetype one level up from the cluster archetype? This is specific information for each individual measurement parameter, not to the examination as a whole. Can it be expressed as a separate cluster under each measurement parameter? Or should we stop trying to model it and use pre-coordinated codes to express this more detailed information.

A related question concerns how to specify which phase the heart is in during the specific measurement? Or if this also is better handled by a specific attributes tied to precoordinated concepts.

Another avenue we have considered is whether we can take inspiration from the spirometry archetype that uses runtime name constraint. But maybe this is outside of the current design pattern of imaging archetypes?

Measurement example:

IVSd - Interventricular septum thickness at end-diastole, measured with M-mode, PLAX

IVSd - Interventricular septum thickness at end-diastole, measured with 2D, PLAX

A standard examination in Sweden might contain about 20-30 measurements and there are about 80 measurements that are could be of interest for our clinicians.

Kind regards,
David

15

I think this depends on the information requirements at each level. If the left ventricle is ever examined in isolation and has its own set of unique attributes that need to be recorded, I might choose to make a separate specialisation. Otherwise I think keeping it all in one “Imaging examination of the heart” archetype is likely a better choice.

Are the measurements expressed using the same set of parameters in other modalities relevant for an imaging examination of the heart? If so, could they be modelled as one element per relevant permutation of the parameters, so that they’re easily comparable across instances without having to align a full set of parameters in a query? So in your example, each of the two would be a separate element?

2 Likes
16

I’m not a cardiologist, and I would trust @siljelb ‘ s judgement over my own, but I think will face similar challenges in eye care (we do ultrasound, too!). So I thought I might share my thoughts.

If anyone is free to share a list of cardiac ultrasound parameters in question that may be helpful!

  • The Archetypes families seems to draw a line between imaging- Vs. nom-imaging based measurements, but in ultrasound that line can be blurry. Not sure how strict we should be about it?
    Blood velocity measurements based on Doppler curves are still sort of image based, but A-scan scan ocular ultrasound is a one-dimensional measurement. You can display that in a graph, but not an image. Also, the same concept may be measured by either imaging or non-imaging methods. Ocular axial length could be measured by CT (Image-based), A-scan ultrasound (non-image based), B-scan ultrasound (image-based, not precise), optical biometry (non-image based). From what I understand cardiac output could similarly be calculated based on imaging and nom-imaging based methods.
    Am I wrong or would the current CLUSTER pattern force a duplication of these parameters, once within the imaging CLUSTER Family and once outside of it? I seems to me such variables may be best situated in CLUSTERs that can be used across imaging and nom-imaging Observation Archetypes? Maybe sometimes it may be helpful to draw a line between morphometric (like axial length) and functional (like cardiac output), parameters? Would seem less method-dependent to me.

  • The probe would not be oriented different ways at the same time, and the special modes are (I expect) mutually exclusive. This is reminds me of similar to the distance at which a Visual acuity chart is shown, it is never 35cm and 5m at the same time. We could argue that the state of the examination is changing and each instance of that being a different event? When drafting the visual acuity Archetype we found it helpful to move such parameters to the “state”, so that they may change over time from event to event. perhaps adding an element or slot for “Mode type” or “ultrasound probe position” in the state of the imaging examination result archetype may be helpful? It does overlap with the “technique” element in protocol though. And it may not work with regard to the DICOM/imaging study structure.

  • I initially thought precoordinating pulse-related timing (end-diastolic etc) would be unproblematic, but I’m not sure if there are edge cases where the pressure cycle works differently. Have you considered how this would work in patients with an LVAD? Are there exceptions to the end-diastolic/end-systolic pattern? Having the pulse related timing in a separate element may be the “safer” option..

Apologies if this is not making things any simpler, feel free to ignore if it is not helpful. I’m just trying to wrap my head around how these patterns can work across different specialties…

2 Likes
17

Hi David,

It is hard to answer such specific questions without understanding all the requirements. You are modelling a very complex domain.

As @siljelb noted, it depends. Not to be difficult but the principles she outlines are a very useful starting point.

The current Imaging of the heart CLUSTER is intended to be used for all modalities, a single source of consistent data, not just for echo, so any changes to this need to keep this in mind. It is conceivable that after investigation there are data elements that are only echo-specific and if this blows out the size of the archetype or creates confusion within this single archetype or there is a need for reuse in other contexts, it may be useful to create an ‘echo-specific’ CLUSTER. This will require analysis of all heart imaging and the detail of the echocardiography domain before we can make any recommendations as to the best approach.

The phase of the heart during recording is complex. In general this is necessary for correct interpretation, so should be recorded as part of the state of the patient. This indicates to me that it may be necessary to consider specialising the Imaging OBSERVATION to support specific heart phase in State, unless the ‘Confounding factors’ in the current archetype can represent it well enough. Then you can reuse the data/state event group combo (0..*) if the protocol is consistent.

If anything in the Protocol differs between the measurements, then a new instance of the archetype should be recorded. I’m guessing this might be necessary to document the difference between measurements taken using a different technique or procedure such as 2D PLAX or M-mode. If multiple modality imaging exams are done in a single session, then they can all be recorded as part of a single report.

The use of Run-time name constraint in Spirometry works because they are measurements made using the same device, the same state, and the same protocol. But it appears echocardiography, is more complex.

Hope this helps,

Heather

3 Likes
18

Hi Heather,

Currently neither the Physical Examination nor the Imaging Result OBSERVATION Archetypes have a SLOT in state that allows for CLUSTERed reuse of state parameters.
Would that maybe be quite a versatile solution?

Then there could be a “cardiac ultrasound probe position” CLUSTER, and a “ophthalmic ultrasound probe position CLUSTER”, “pulse Phase CLUSTER” each of which would be reasonably concise and have it’s own review/publishing cycle.

This would get especially interesting when we consider that some of these state parameters may be required both for imaging and for simple examination findings family.

Sorry to pick another eye care example, but “gaze position” (patient looking up, down etc) could be a relevant state for photos documenting the eye motility (in the imaging family) but also for some simple observations such as Lid aperture height (in examination family). Lid aperture height in relation to gaze position is pretty important in Duane Syndrome.

It is also probably worth considering Stress Echocardiography as a not-so-rare special case, so exertion level also seems relevant, and it already has a cluster…

19

Hi Lars,

This is another pattern to investigate and solve - is it best to specialise or add CLUSTERs. There are pros and cons.

The level of exertion is a valid use case as you rightly point out, but it was modelled as a group of reusable data points and has reusability utility in many ENTRY level archetypes, so the decision to make it into a CLUSTER made sense.

If there is an echo specialisation it could include a SLOT for exertion and the cycle phase and potentially for the other parameters you suggest. The alternative is to develop CLUSTERs for these ‘extensions’ in state, data and protocol. Then assembling a template with all of these components might be quite difficult, especially for new modellers.

For ophthalmology we could add ‘gaze position’ and others directly to a single Physical exam specialisation OR add a variety of CLUSTERs.

This is what we need to balance - utility from reuse is paramount but there are many factors that need to be considered including modeller confusion or increased (?unwarranted) variation in modelling. Reuse for reuse’s sake is not ideal either.

Historically, we tend not to create an archetype for a single data element, although technically it is possible to create an ELEMENT class. So far we discovered that if we built an archetype with one data element, someone inevitably asks for a ‘Comment’ etc, so it all breaks.

Regards

Heather

2 Likes
20

Thank you @siljelb, @Lars_Fuhrmann and @heather.leslie for your answers and informative discussion! Thats a lot to process and we will get back to you. Hopefully we will have a mindmap over the parameters we want to capture to share with you later this week. We will also bring your questions and thoughts to the clinicians we are working with next week.

1 Like