Hi, I am quite new at OpenEHR and am trying to design a template for a focus echocardiogram. I would like to know if there is an existing template for echocardiography, as I cannot seem to find one.
Thank you
2 Likes
Hi Maria,
You probably want to base your template on
The Result Report Composition archetype
and Imaging exam result Observation archetype
This might be sufficient for your needs if focus echo findings reporting is still mostly textual.
e.g. Focus cardiac ultrasound: the European Association of Cardiovascular Imaging viewpoint | European Heart Journal - Cardiovascular Imaging | Oxford Academic
If Focus reports need to be more structured , the usual policy is to create a specific Cluster archetype for each modality, as reporting styles are often very different for each.
As an example of a more complex Echo report, which uses different cluster archetypes for different types of Echo see the HighMed Echocardiogram template though bear in mind that the Highmed project is a primarily about analytics so may not be a perfect fit for your purpose
Thank you very much
This is very helpful
Kind regards
Maria
Hi Maria,
I’m the original author/designer of the Imaging archetypes in the international CKM. You can find the work to date in the Imaging project.
I agree with Ian re:
However, we diverge on the approach to structured details. In the Imaging result OBS use it strategically says:
“Detailed findings observed during an imaging examination and targeting a specified structure or region can be recorded by nesting the CLUSTER.imaging_exam and/or its family of specialised archetypes within the ‘Structured imaging findings’ SLOT in this archetype. It is intended that the specific detail in each specialisation will grow over time to include findings using all imaging modalities.”
In the Imaging project, you can see all the archetypes developed so far to record structured detail per body structure or region. The intended design approach is to record all details about the examination of a body structure or region in that archetype, irrespective of the modality. This deliberately caters for the many situations where you want to record or measure the same thing, and it can be done in more than one modality - otherwise, we’d be repeating those same data points in ‘per modality’ archetypes & we’d have an explosion of structured imaging archetypes. Note that the intended modality for echocardiography is set in the parent OBSERVATION using the ‘Modality’ data element.
The HiGHmed example was built independently and predates the design pattern I’ve described above by reusing a generic result CLUSTER for many results, which worked for their use case but is probably not semantically sustainable way to create a radiology reporting data ecosystem - but this was all we had at the time so their approach is understandable in context. We’ve intentionally moved away from that approach in these newer Project archetypes.
That said, echocardiography is not something I’ve investigated extensively. There is currently no specialisation of CLUSTER.imaging_exam (Imaging exam of a body structure. I would recommend starting by creating of a specialisation of this archetype for CLUSTER.imaging_exam-heart (Imaging exam of the heart).
You can also see in the use of CLUSTER.imaging_exam (Imaging exam of a body structure) that “The intended scope for the CLUSTER.imaging_exam family of archetypes to be used to record all detailed findings on radiological examination. The family of specialised archetypes are derived from this generic parent archetype, CLUSTER.imaging_exam, designed as a universal pattern for recording any findings in any specified body structure or region and using any modality.”
So, theoretically the CLUSTER.imaging_exam-heart archetype will carry all the data elements that can be measured by echo or CT or MRI etc. Clinical requirements will provide more insight into whether this will be adequate or if the complexity of 2D/3D echocardiography will require some other additional patterns. It is possible that unique and specific heart echo-only data point may warrant their own archetypes and nest them within CLUSTER.imaging_exam-heart for echo-only purposes eg functional assessments. You can see a couple of examples of these kind of non-patterned archetypes in the Imaging project - for example Vascular findings on ultrasound, which could be reused across ultrasound reports for many structures or regions, or Cobb angle which needs to be reused in any or all imaging exams of cervical, thoracic or lumbar spine.
I’ll be very interested to hear your thoughts in return.
If you are willing, you have an opportunity to kickstart the authoring and development of the heart imaging archetype for others in the community to use. All archetypes developed so far are driven on a use-case-by-use-case basis, just like yours, and they are then contributed for community reuse.
Kind regards,
Heather
1 Like
Thanks Heather,
Very helpful to understand the intended direction of travel.
It has always been difficult to model detailed front-line imaging reporting as there is a surprising lack of standardisation in that community, compared to say Anatomic pathology, This effort by RSNA seems to have been discontinued https://radreport.org/
And completely agree that we need examples like Focus Echo to drive our understanding and knowledge.
1 Like
Hello everyone,
I’m new to openEHR, and I’d like to join this discussion. We recently started creating a form for saving echocardiography data at the UKSH, which is part of HighMed.
Initially, we intended to use the HighMed template, but it doesn’t have all the information we require, and the architecture seems a bit odd. (As Heather mentioned, it doesn’t adhere to the design principles.)
After some consideration, we also assumed that we would need a CLUSTER.imaging_exam-heart archetype. My coworker and I are interested in kickstarting the development of such an archetype. While we’re not clinicians, we could get support from cardiologists for refinement.
However, we assume that an image archetype for the heart would be quite extensive, and I’m not sure whether we could cover everything needed for every use case. Would it still make sense to at least start the development and submit the archetype to the CKM? Or would you suggest another approach, like creating a specialized echo-heart archetype?
Any input will be greatly appreciated.
Kind regards,
Henrik
3 Likes
Hi Henrik,
I welcome your question and willingness to kickstart this conversation. In the context of an evolving pattern, the aim is a coherent ecosystem of fractal archetypes related to imaging that can be nested and arranged to support any use case.
With the general intention to create CLUSTERs of archetypes per body location/region and agnostic of any single modality, I totally support your suggestion of CLUSTER.imaging_exam-heart. I also agree that an imaging examination could be very extensive.
Without a full investigation of what the heart imaging requirements are, it is not yet possible to advise how best to proceed. In your position, my first step would be to create a mind map, perhaps firstly aiming to identify the major parts of the heart that may need to be modelled separately ie a ‘core’ heart archetype that would be required for most modelling scenarios and others that might be used effectively as ‘extensions’ in less frequent scenarios. As part of the mind mapping exercise it may even become apparent that there is a plethora of data elements that are only relevant to one modality and in that situation it may be prudent to break our previously stated ‘principles’ and group these particular data elements together in a single archetype eg for an echo of a single valve. I’m not sure of the outcome, just thinking out loud here. However, I am sure that the only way to determine the way forward is to understand the domain requirements clearly.
If you are able to carefully document the requirements from your cardiologists, even as a mindmap to begin with, we can collaborate on how to optimise ‘chunking’ and reuse. And if we can collaborate with @Maria_Sol_Andres & her team and their requirements, our resulting model/s can become even more refined.
Regards
Heather
2 Likes