DICOM compliance of OBSERVATION.imaging_exam_result

Clinical
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!

21

From my side i can see all the fields i myself would see as required to be contained in order to represent rudimentary DICOM information correctly. The imaging result archetype contains all the meta information in the protocol. Finding and series contain exactly what they should. The Cluster use is exactly what i would do too.

I think it would be also important if someone from the more practical field like @rfloca and @christian.haux also took a look and see if all the fields that are important for your use are represented.
I for myself do not know how much granularity is required and the exact use case this will be used for.

I support the decision not to model too much of the CIOD level since its super granular and specific information that is not required in most cases for direct the clinical use case.

3 Likes
22

Great, and thanks Severin!
We’re really keen on sending for review soon, as there will be need for imaging exam result archetypes in the ongoing project dealing with Artificial Reproductive Technology (a.k.a. IVF) in Norway. If please @rfloca and @christian.haux can have a look before sending on review, it would be super. Otherwise, it’s always possible to make comments in the review.

Regards, Vebjørn Arntzen, co-ed.

2 Likes
23

Thanks+++ Severin - will send out for review tomorrow.

If anyone in this thread wants to participate in the review, please adopt the OBS.imaging_exam_result and we’ll be able to invite you.

Regards

Heather

1 Like
24

Hi all, sorry for the late and brief respond. Currently there are a lot of to-dos. I shortly skimmed offer the proposal.

*Disclaimer: *
1. I am quite an openEHR novice and my expertise is in the DICOM domain.
2. We have also quite data science / AI driven Use Cases in mind. That might explain some diverging priorities.

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.

It happens from time to time that vendors encode different image volumes in the same series (e.g. whole body images that are acquired in multiple bed positions; multiple frames of a time resolved acquisition…). In most current clinical scenario it might be irrelevant to really pin point the correct volume. But in our cases (e.g. for Radiomics, reporting of results that are done by AI) it is important to us to have provenance information that also can guarantee to indicated which data was really used. And therefore (at least for us) series UID is sometimes just not enough.

Looking for missing things, at first glance, I found the following:

  • In our internal (HiGHmed) designs we are discussing about adding referring physician (0008,0090); but may that is already covered on a higher level already
  • We would like to be able to also report Source Images (0008,2112) and Source Instances (0042,0013). To also model data provenance and make it query able on that level. Because in cases of derived images (e.g. computed SUV maps, or perfusion maps) it might be of relevance which input was used.

Sorry to have not more time. I hope that helps. And I hope we manage to converge things.

Best,
Ralf

2 Likes
25

Hi Ralf,

Thanks for your response.

In the Protocol we have modelled

  1. ‘Requester’ at at0030 and indicated a possible mapping to the narrower concept of DICOM’s ‘Referring Physician’s Name’.
  2. If further details re instances and images are required we have anticipated extending the CLUSTER for Imaging Series - Clinical Knowledge Manager. Would that work for your use case?

image
image692×834 94.1 KB

Please adopt the OBS.imaging_exam_result so we can invite you to the review.

Regards

Heather

1 Like
26

3 reviews were sent out yesterday, with a 3 week review period, ending March 9:

  • OBSERVATION.imaging_test_result
  • CLUSTER.imaging_finding
  • CLUSTER.imaging_exam

Reviews are starting to trickle in… :face_with_monocle:

H

1 Like
27

ICYMI - OBSERVATION.Imaging examination result and CLUSTER.imaging.exam ready to be published

2 Likes