DICOM compliance of OBSERVATION.imaging_exam_result

Clinical
1

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
2

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.

4 Likes
3

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.

2 Likes
4

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.

5

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.

DICOM_Series_Metadata
DICOM_Series_Metadata1221Ɨ714 50.9 KB

1 Like
6

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

7

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
8

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
9

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?

2020-07-09_DICOM_Imaging_Draft_2
2020-07-09_DICOM_Imaging_Draft_23346Ɨ1222 252 KB

2 Likes
10

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.

11

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

12

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
13

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!

14

Thank you, Ian!

15

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

16

@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.

17

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.

18

Hi all, late to the DICOM imaging party but letting you all know that Iā€™ve been working on updating the imaging archetype family over a period of time.

The project is here: Imaging examinations project

Iā€™ve just uploaded the latest version of the OBSERVATION.imaging_exam_result. In fact, you will note that it is still on a branch (so you can have a sneak preview while it waits for a NO translation to be added. We intend to send it out for review very soon. The design may appear a little different to the discussion in this thread and Iā€™d like to explain why and then encourage everyone to join the review by adopting the archetype.

The focus of the Imaging exam result archetype is to record the findings and interpretation as part of a published result report. The current design is a (hopefully relevant and meaningful) mashup of:

  • Clinical reporting standards/recommendations for imaging reports
  • FHIR Diagnostic Report and Imaging Study resources
  • DICOM attributes relevant to a report
  • Alignment with the OBS for lab test result where relevant.

So Iā€™ve designed the OBSERVATION to be for a single Study, potentially including multiple series which is modelled by a CLUSTER.imaging_series that can be used within SLOTS for the study report and to represent other series that may be used for Comparison purposes.

I had previously modelled a CLUSTER that carried both DICOM study and DICOM series level attributes but it ended up duplicating many data fields that were required in the result for including non-DICOM reporting. So we needed a different approach - today Iā€™ve done a major redesign to include the Study level attributes within the OBSERVATION and the Series level attributes are kept in the optional CLUSTER.imaging_series which can be nested within the OBS at ā€˜Series detailsā€™ SLOT and ā€˜Comparison series detailsā€™ SLOT as required. You can see the changes if you view previous revisions in the same CKM branch.

In my investigation Iā€™ve not come up with evidence that we need to document down to instance level for reporting purposes, but happy to be corrected. I very deliberately want to avoid replicate an RIS level of DICOM detail within an imaging report, only what is required for our purposes.

This is the art of archetyping in action, determining how far we need to incorporate DICOM and FHIR attributes but keep the archetype focused on the reporting purpose. That doesnā€™t mean that they are not required in other contexts and so we need to understand the other opportunities before we go much further.

You will also note a growing family of specialised CLUSTER archetypes that record the specifics of imaging exams of a growing number of body regions and associated metrics such as fetal biometry. It is anticipated that these will grow in number and level of detail over time. This imaging exam detail pattern is closely aligned with the way we are modelling physical examination.

@christian.haux et al - Iā€™m curious to get your feedback and how these archetypes meet or miss your modelling requirements. I referenced the specialisations you pointed us to further up in the thread, and included most of them in my newest iteration but didnā€™t have a use case for a number of your attributes at present. So if you have use cases for the others that we need to add, please let me know

Regards

Heather

4 Likes
19

Oh you open up a barrel here, I try to take a look on the weekend.

4 Likes
20

Please do!