DICOM compliance of OBSERVATION.imaging_exam_result

Hi all,

Let me please introduce myself. My name is Christian, I am working at the German Cancer Research Center in the HiGHmed project. We are working on Radiomcis image analyses and use the archetype OBSERVATION.imaging_exam_result.
We had the requirement to represent certain DICOM tags with the archetype, which are not covered by the current one. We have found that the existing archetype is difficult to extend. Therefore, we created a specialization of the archetype.
(please see https://ckm.highmed.org/ckm/archetypes/1246.145.1284) However, I wanted to ask if there is a general interest in making the archetype more DICOM compliant?

Best wishes,

Christian

3 Likes

Hi Christian,

I’m sure there would be considerable interest in this area. My preference might have been to add most of the extra DICOM information as CLUSTER archetype that could be plugged in at template level, rather than as a specialisation. We should also consider whether there are some key DICOM attributes that should just be in the parent imaging Observation.

3 Likes

I should say this is great time to get the international Imaging archetypes into review and publication and having your practical experience/input will be very welcome.

1 Like

I agree with Ian, some DICOM tags are groups and some represent individual values, which is the same pattern we have for CLUSTER/ELEMENT in openEHR. Maybe the current archetype can be extended with such structures in a generic way, and have the specific structures specified at the template level.

@christian.haux do you have the set of DICOM tags you need to use? That would be a great input!

Also consider some DICOM tags like parient or study level tags might be mapped to a patient or to a composition, not to the observation.

Hi Ian,
hi Pablo,

Thanks for your reply! Making a COMPOSITION Archetype with the required DICOM Tags was also my first thought and I also created a prototype. Please see the image attached. These are also the DICOM Tags that are necessary for us. However, I had the problem that there is only a Extension slot on the Protocol level. But for DICOM tags that are specific for the DICOM series or the image, an extension in the “image details” cluster would be necessary in my opinion. But please correct me if there is another way to add an extension to the image details cluster.

1 Like

Thanks Christian,

The obvious solution to your issue, would be to add a slot to carry that extra metadata at the appropriate level. The Imaging archetype is still in draft, so this is our chance to get it right!

I’m not familiar enough with DICOM metadata to understand how it might fit into a typical ‘clinical’ imaging report.

If a rough outline is

Imaging Report (Composition)

   Imaging Result (Observation 0..*)
  
       Imaging finding (Cluster)

Could you organise the mindmap to see how the various items would fit into that hierarchy?

Ian

That’s interesting and made me think about mapping for series.

Not considering current archetypes, I think the COMPOSITION level is a good mapping for DICOM Study, the OBSERVATION level might be a good mapping for DICOM Series and EVENT a mapping for DICOM Objects. But you could also map one series to a COMPO, in this case a set of COMPOs will be the study, or even map one DICOM object to a COMPO. If you consider DICOM files, each file contains the full metadata of the study, series and object(s) that file belongs to. I would prefer the first: one COMPO ~ one DICOM study (it’s easier to manage).

So you might have one COMPOSITION per study, with many OBSERVATIONs (one per series), then inside each OBSERVATION many EVENTs (one per object).

BTW, is this just for DICOM SR or do you want to store the imaging/video/waveform study metadata also in openEHR?

Because one alternative to store everything in openEHR is to store the WADO/DICOMweb information in openEHR then do the queries over the PACS using those services, since all the tags will be there. Of course I don’t know your integration requirements, but both are a totally valid approaches.

1 Like

Hi to all,
I am a colleague of Christian.

BTW, is this just for DICOM SR or do you want to store the imaging/video/waveform study metadata also in openEHR?

No, it is not just for DICOM SR. It is also supposed to cover other IODs, most prominently different DICOM * Image IODs (* like CT, MR, US …), but it would also cover most of the fundamental infomation for other IODs like DICOM Seg or DICOM RT* IODs (e.g. RTStruct).

Because one alternative to store everything in openEHR is to store the WADO/DICOMweb information in openEHR

This is in a lot of cases a valid approach and we also will store the link to the primary source (PACS), but for our use cases it is not enough. The key idea is to offer a minimal (from our point of view) set of information about the imaging directly in OpenEHR. This would offer us the possibility to directly use the imaging information e.g. for sub cohort definition. For example one could query for patients with certain clinical properties who also got a certain imaging protocol after intervention, or have a certain set acquesitions of different modalities for a certain bodypart…
I hope I could convey the idea.

Thanks for the first impulses and vivid discussion! We will use it to (re)organize the mindmap as @ian.mcnicoll proposed. Looking forward to the comments.

3 Likes

Dear all,

thank you for your great input! I quickly drafted a mindmap that represents the idea of Ian having a slot for extra DICOM metadata on each level. I also renamed the DICOM IODs as they were in my previous mindmap to DIOCOM modules to be compliant with the DICOM standard. For the individual images per series I would use the CLUSTER.imaging_result.v0 archetype and added the DICOM module image to the Imaging result detail slot.
@pablo could you please elaborate more on using EVENTs for that?

2 Likes

Hi, OBSERVATIONS are containers of time series data, so basically: OBSERVATION ->* EVENT

Each EVENT has an archetypable (generic) data structure inside, and the EVENT contains the “timestamp” for that data. What I was thinking is: since DICOM objects are obtained in series, maybe the EVENT data could represent a DICOM object, and the OBSERVATION’s EVENTs could represent a DICOM series.

But all depends on the level in which you want to do the mappings, for instance if you want to represent a complete DICOM study with just one COMPOSITION. If that is the case, which makes perfect sense, this is a possible mapping:

Study -> COMPOSITION
Series -> OBSERVATION
Object -> EVENT

For instance, to map the Study tags in a COMPO, I would use COMPOSITION.context.other_context rather than adding a custom OBSERVATION for that data. But as everything in the modeling area, this is arguable.

Everything that I mentioned here is not considering existing archetypes, I’m just thinking about options.

Hi,

Not directly relevant for the Modelling but:
I would even try to cover more attributes than the above ones, DICOM itself provides only very basic search capabilties and covering more Attributes, if wanted, does not harm.
Especially since AQL allows quite complex queries.
The Sequences shown in the query attribute tables of C.6 from DICOM PS3.4 for study, series and composite object could also be covered.
Most of the attributes listed in the figure above are contained in this tables, covering the rest of them may provide some advantage for querying in the future ( excluding the “All other Attributes of level X” that would be too much).

Regards,
Severin

Hi all,

@pablo: Thanks for your explanation. I have developed a structure for a template. As basis I would use openEHR-EHR-COMPOSITION.report and integrate a cluster with the required DICOM study tags via the slot “Extension”.
For the observation, I would use openEHR-EHR-OBSERVATION.imaging_exam_result and include a cluster with the DICOM series tags via the slot “protocol -> Extension”.
For the event, I use openEHR-EHR-CLUSTER.imaging_result and include a cluster with the DICOM image tags (Patient module) via the slot “Other detail”.

openEHR-EHR-COMPOSITION.report
context
	other context
		(Extension) openEHR-EHR-CLUSTER.dicom_module_study_metadata
			DICOM SOP class UID
			DICOM SOP instance UID
			DICOM study instance UID
			DICOM study description
			DICOM modality in study
			DICOM study date and time
			DICOM images in study
	content
		openEHR-EHR-OBSERVATION.imaging_exam_result
			data
				Any event
					Data
						openEHR-EHR-CLUSTER.imaging_result
							(Other detail) openEHR-EHR-CLUSTER.dicom_module_image_metadata
								DICOM image instance UID
								DICOM image description
								DICOM image date and time
								DICOM image modality
			protocol
				(Extension) openEHR-EHR-CLUSTER.dicom_module_series_metadata
					DICOM series instance UID
					DICOM series description
					DICOM modality in series
					DICOM series date and time
					DICOM images in series

@SevKohler: Thanks for your suggestion. I am open to add additional tags if we get benefits from that.

Regards,
Christian

1 Like

Hi @christian.haux - that looks pretty identical to how I would have done it, based on my more limited understanding of DICOM - so go for it!!

The other value of modelling it this way is that it allows folks who do not need or want that level of DICOM detail to be included, to work on the same base archetype.

Great job!

Thank you, Ian!

and please submit the resulting archetypes to the international CKM so we can publish and share widely.

@christian.haux looks good me for too. I think putting the series at the entry level in the protocol is a smart move to have one series associated with many objects, one per event. Wonderful!

I would also leave room for extra extensions at those 3 levels, just in case you need extra tags, you can associated extra cluster or element archetypes.

That is good advice Pablo but we actually have those slots already, pretty well as standard - one at composition level, one in protocol and an image details slot within observation/event/data. These are all open so can be used for the extra Dicom info as well as e.g detailed cardiac ultrasound findings via a cluster slot.