Echocardiography - Change of "Imaging result" CLUSTER archetype? Reuse lab analyte design pattern for nested/repeated clusters?

erik.sundvall · 18 June 2021 17:22

HI!

We are developing a template for echocardiography in Sweden and have had a close look at a template from the German HiGHmed project, see: https://ckm.highmed.org/ckm/templates/1246.169.85 (Ping @birger.haarbrandt)

In HiGHmed’s template the archetype openEHR-EHR-CLUSTER.imaging_result.v0 is repeated in a nested fashion with an instance for each measurement type. All these are wrapped inside an openEHR-EHR-OBSERVATION.imaging_exam_result.v0 archetype.

We find most of the datapoints needed for our very similar Swedish use case, but to us it looks like the meaning/semantics of each nested measurement in HiGHmed’s template is only carried in the (native language specific) renaming name of the CLUSTER.imaging_result.v0 archetype in the surrounding template. (Or have we misunderstood something???)

See snippet from https://ckm.highmed.org/ckm/templates/1246.169.85 (click to enlarge)

Potential problems:

It is hard (impossible with current archetype?) to, at the template level, encode each of the measurements with e.g. SNOMED CT or LOINC codes…
…which in turn only leaves the language dependent labels as an option to discern between the values in AQL queries etc.

One (bad) solution would of course be to create a specialized CLUSTER archetype for each of the measurements within an echocardiography. But (just as with lab values) I suspect this would lead to very many little archetypes to maintain. AQL paths for each speacilized archetype would be easy to discern using the archetype name.

Another (somewhat bad) solution would be to create a larger completely new CLUSTER archetype containing many measurements at once. That would be less of a maintenance nightmare and easy to translate between languages etc. AQL paths for each branch within that big CLUSTER would be easy to discern (using the at/id-codes).

A third (probably better) solution/question:

Can we reuse the design pattern from e.g. openEHR-EHR-CLUSTER.laboratory_test_analyte.v1 where the field “Analyte name” allows e.g. a coded text that can be used for including e.g. SNOMED CT or LOINC codes at the template level and thus also in the AQL-queryable stored EHR data. See e.g. the glucose example by @siljelb in https://ckm.openehr.org/ckm/templates/1013.26.383

Something along the third alternative seems to have been discussed by @pablo. @heather.leslie and @ian.mcnicoll in https://ckm.openehr.org/ckm/archetypes/1013.1.2764/discussion (requires logging in to the CKM) - see relevant snippet as image below (click to enlarge)

By adding something like “Result name” (similar to the “Analyte name” pattern in labs) the archetype could become something like below

Image above: Screenshot of our local test modification with “Result Name” added to the CKM version

Text to cut&paste for the editor that wants to add the field in the archetype in the CKM follows…

Label: Result name
Description: Name of the result.
Comment: The value for this element is normally supplied in a template, in a specialisation, or at run-time to reflect the actual result. Coding with an external terminology is strongly recommended, such as LOINC, SNOMED CT, or local terminologies.

heather.leslie · 22 June 2021 02:08

Hi Erik,

I think the simple answer is it is too hard to tell, yet. It is a reasonable thought, especially trialling a pattern that has worked in a similar domain.

Smart modelling to create a coherent family of archetypes covering the breadth, depth and complexity of the imaging domain requires us to have good insight into the requirements. We don’t need to model all at the same time, but we do need an agreed strategy before we start to put these archetypes through review.

The archetypes currently in CKM were best guesses at the time of their development, but I suspect that we’ll find that they are not quite ready for prime time. The main barrier to progress is gathering enough high-quality examples to identify implementable patterns.

As best as I can tell with my investigations to date, a good pattern will be somewhat similar to the Lab test - an OBSERVATION for the framework of every Imaging exam and then CLUSTER archetypes that will support the detailed content. IMO the OBSERVATION.imaging exam is reasonably sound and carries most of the critical crossover data to DICOM in the protocol.

The future intent for the Lab test family is to have a CLUSTER framework for common cytology data elements, another for microbiology, and another for anatomical pathology etc.

I haven’t had access to enough good quality example reports to determine if we might also identify a similar CLUSTER framework pattern - for example, one for the basics of all ultrasounds and another for all plain Xrays and another for all CTs etc.

Or if we need to do it differently.

Progress so far is disappointing and frustrating. I know there are many who are wanting to progress this work.

To help break the impasse, I’d certainly welcome if anyone can share example reports or point to online resources, so we can progress modelling this domain.

To date, I’ve been using some rather variable quality examples in the Rad Report library - https://radreport.org/ but they don’t give me confidence to develop potential patterns. I also have access to a dataset for CT coronary angiography but it’s very specialised and I’d like to see more examples of CT reports in varying levels of detail.

Creating a good-quality family of models across this domain will be a significant challenge.

Any and all radiology domain expert advice welcome

Regards

Heather

erik.sundvall · 23 June 2021 15:02

Hi!

Echocardiography is of course only one of many ultrasound examinations that we want an imaging pattern to work for, but it is a suitably complex example involving many methods and several calculated values that can be reached in more than one way. In addition to ultrasound other modalities (e.g. MR-imaging) can also be used to measure the same heart dimensions, blood flow etc.

General examples:
The page Riktlinjer - Ekokardiografi links to many references regarding Echocardiography that may be useful for this modeling work.

openEHR-specific examples:
The German Echocardiography template https://ckm.highmed.org/ckm/templates/1246.169.85 from HiGHmed is a pretty good example report regarding interesting data points (although I suggest some modeling/terminology improvements in the original post above)

The corresponding Swedish experiment is slowly being built up at https://github.com/modellbibliotek/klinfys-register. Right now, when writing this, the most recent half-way template attempt is in the file klinfys-register/Echo.t.json at master · modellbibliotek/klinfys-register · GitHub
It extends and modifies the HiGHmed template a bit and using a modified openEHR-EHR-CLUSTER.imaging_result.v0 archetype with "Result name " added as described above.