Cardiology templates and archetypes

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

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

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

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

4 Likes

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

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:

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

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

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

This the real culprit

4 Likes

Hmm…I’d start with these :rofl:

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

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

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