Cardiology templates and archetypes

Our preliminary understanding is that one might examine only a specific part of the heart in an examination in some cases. But the standard examination is much broader. Some of the attributes are unique and some are not. For example, the attribute list for left ventricle differs from the list for the right ventricle. If this is because of clinical relevancy or structural differences, we will have to ask the clinicians.

Concerning the question about measurements in other modalities one can in at least some cases measure the same thing using MR for example, but the measured result will vary. I’m not sure which if any parameters that concerns state and protocol corresponds across the modalities. We will have to ask the clinicians here as well.

Thanks @heather.leslie , good to know that those options are on the table :wink:

I think because ultrasound probe position is relevant across nearly the whole body it is really interesting to think about how it will work in general..

Not only does the probe position use 4-6 degrees of mechanical freedom depending on the organ , but the terms used to describe the positions (or views) mix references to general anatomical planes (saggital plane view…), clock hours (eye), anatomical structures (apical 4 chamber view).

Plus where one “area examined” starts and another begins may be a bit unclear, say looking at a bit of the diaphragm/pleural space/lung as part of a liver ultrasound would be expected, i think finding a bit of pleural effusion would not be super rare in abdominal ultrasound exams.

SNOMED CT does have specific qualifier values for specific cardiac imaging views which may be useful inspiration for @davwet and i guess often onse such value to describe probe position may suffice?

In DICOM the “View Name Attribute” (0008,2127) seems to basically be a short string if I understand it correctly.
However, the DICOM controlled terminology contains lots and lots of (precoordinated) cardiac ultrasound terms including some view descriptions, not sure how much they are used in practice but I am sure a lot of thought has gone into them.
A pearl here is that the apical 4-chamber view acutally gets split up further into into “RV focused” (130681) and “modified” (130682), based on a consensus statement.
What a rabbit hole, I need to get out, now! :wink:

2 Likes

We would like to invite you to a workshop to discuss the modeling of the archetype(s) for imaging examination of the heart. Would any of you be interested in participating? We think it would be easier and make us arrive at our goal faster than only continuing the discussion in this thread. Just throwing out a date, how about 9 October sometime around 08-12 CEST?

In the meantime we have some additional questions:

General modeling question
When modeling an archetype, should you constrain the modeling in a way that makes it difficult or impossible to implement it in a way that does not correspond to an actual state in reality or do you leave it open for the person implementing the archetype to make a judgement about what permutations are acceptable? For example, leaving the possibility to set attribute A to X and attribute B to Z even though that specific combination is practically impossible.

The combination of the imaging observation archetype and the cluster archetype
How do we best handle the combinatorial explosion (with reservation that we have misunderstood the discussion above) when we then configure the template based on the pattern discussed above, i.e. handling cardiac cycle phase in state and view and mode in protocol. As we understand it, we would need many observation archetypes in our template with different combinations of values ​​for attributes for mode, view, method, exertion and cardiac phase. Instinctively, the resulting template feels counterintuitive with one observation with all the measurement done on 2D images in biplane view at the end systolic point in time and another observation for all measurement done on 2D images in single plane view at the end diastolic point in time etc. etc. The structure will probably allow for powerful yet easily understood queries but the templating would probably need a complementing implementation guide.

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?

There seems to be some overlap, e.g. regarding views even though the value set for the parameter may differ. We have to continue study the possibility of precoordinated elements that work across all modalities.

We think that we should build clusters per structure. Partly because of previous reasoning that you might only examine specific parts or a few parts of the heart and that the selection of measurements differs between these. But also because when analyzing the results, you most likely look at each part separately.

We attach an excerpt from our work in progress, the variable list, a mind map of all variables and a picture of the observation and the new cluster archetype(s).

This looks interesting.

There is colleague I recently met doing heart scans in Wales (UK).

Her name is Emma Rees:

https://www.linkedin.com/in/emma-rees-b38566368/

Her email is: e.rees@swansea.ac.uk

Emma would be interested to join this Cardiology archetype/template group. Could you send her an invite explaining the aims of this collaboration.

Emma doesn’t know anything about openEHR apart from my elevator pitch (actually a transfer bus from terminal to plane pitch) a few days ago.

Thanks @Kanthan_Theivendran ! We will contact Emma.

Hi David,

It’s difficult to provide a definitive response to such a complex modelling question via this forum. You’re working in a space that, while we’ve tried to anticipate it in the design of existing archetype patterns, remains relatively unexplored in practice. I don’t yet have direct modelling experience with this level of anatomical and physiological detail, and I can’t know what I don’t yet know.

To provide a thoughtful and appropriate response really requires a deep understanding of the context and specific requirements. Ideally, that would be through a face-to-face workshop over the course of a day, where domain experts are directly interacting with modellers. Translating language adds another layer of complexity that makes it even harder to give immediate or accurate feedback.

From first principles, I can say that we don’t typically create specialisations for left and right sides of a structure separately. So, if we need an archetype for imaging examination of a ventricle, I’d expect only one archetype, with the laterality (left or right) represented using the ‘Body structure’ element. This is consistent with how we approach other paired anatomical regions.

To do complex modelling justice, even with a solid understanding of the clinical background, it is common to enter a significant phase of exploration. There is usually a period of trial, error and iteration before the optimal approach becomes clear. In Australia, I often describe this as “going down a deep rabbit hole” and hoping to eventually find my way out. I’m not sure if that analogy translates well, but it feels apt. This is a normal part of my process, even with extensive experience. Each new clinical use case presents its own conundrums and we rely on existing patterns to support solving the next one. But your situation has little existing for us to leverage at this point in time.

At this stage, I do think it would be valuable to have guidance from senior modellers or CKAs to ensure your work aligns with CKM modelling patterns and has the potential to contribute meaningfully to the shared archetype library. Unfortunately, we don’t yet have the resources in place to fully support that kind of mentoring or review. I wish it were different.

As a first step, perhaps consider collaborating around and sharing a mind map or structured outline that captures what data you would expect to record for each specialisation or structure. This might help clarify why a separate archetype may be justified, or whether your needs can be addressed through templating or compositional approaches. The complexity of phases of the heart is another layer on top of the basic identification of CLUSTERs required to correctly represent the structures that need to be imaged.

I hope this helps you make some progress. The more collaborative your approach, the more likely it is that the modelling requirements will become clearer. From there, we can hopefully work out a way to support translation into the correct scope for each of the archetypes that follow the established patterns.

This is important work, and thank you for your efforts.

Kind regards,
Heather

Hi David, thank you for suggesting a workshop, I would be generally interested but can’t make it this Thursday i’m afraid and will be too busy in the next month. If you are in Barcelona next week please do reach out.

I think part of this is just the nature of the beast that we are grappling with, we just can’t change the fact that us clinicians are controlling 3-10 distinct variables at the same time, and may change 5 of them from one measurement to the next.
It reminds me of my visual acuity work, where , within seconds, we like to change the chart used, distance tested and type of correction/glasses, all of it in ways that are hard to predict when writing a template.

Not sure if precoordination in the archetypes would be a good idea, I think it is necessary to avoid a cartesian explosion and to maintain reusability across different modes of measurement/imaging.

Maybe it may be sensible to question whether you really need to predict all variable combinations at the template level?
To make the rather complicated visual acuity archetype implementeable I have been considering if the templates could be kept quite liberal, both in terms of the number of events/observations and combinations of variables they contain. Because I have no Idea how many VA tests the next patient will need and with which combination of variables.

In order to ensure the right variables are used in combination with one another precoordination may still be useful, but what if that is only performed at the front end/application level and neither the Archetypes nor the template?
I am imagining a UI where all those variable have been precoordinated, so there is just a single field for something like “right ventrical volume in 4 chamber view at the end systolic point”, but after being entered and before the composition is written this gets mapped out into like 3 elements.

  • Body site: right Ventricle,
  • View: 4-chamber,
  • Pulse Cycle timing: end systolic.

All of which on the complicated different paths that suit the rather liberal template.

So in a way this would be having both the precoordination and the rules just in the front end, not the template. My hope is this could both make templating relatively easy and keep clinicians from having to fill in 5 drop down menus for a single observation.
This may or may not be problematic as the data is not saved exactly as seen by the user, but maybe it is an option somewhere?

Again, I’m just sharing my thoughts as because we have similar issues in eye care, not because I think that I have the perfect solution for them..