# DICOM compliance of OBSERVATION.imaging_exam_result **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2020-07-07 12:47 UTC **Views:** 2074 **Replies:** 26 **URL:** https://discourse.openehr.org/t/dicom-compliance-of-observation-imaging-exam-result/857 --- ## Post #1 by @christian.haux 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 --- ## Post #2 by @ian.mcnicoll 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. --- ## Post #3 by @ian.mcnicoll 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. --- ## Post #4 by @pablo 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. --- ## Post #5 by @christian.haux 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|690x403](upload://4gCl8RYFjSCpXjQIG8vtK68izM5.png) --- ## Post #6 by @ian.mcnicoll 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 --- ## Post #7 by @pablo 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. --- ## Post #8 by @rfloca 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. --- ## Post #9 by @christian.haux 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|690x251](upload://wNTlZsej3NT0aUQLeEUaS6HhsDA.png) --- ## Post #10 by @pablo 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. --- ## Post #11 by @SevKohler 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 --- ## Post #12 by @christian.haux 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 --- ## Post #13 by @ian.mcnicoll 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! --- ## Post #14 by @christian.haux Thank you, Ian! --- ## Post #15 by @ian.mcnicoll and please submit the resulting archetypes to the international CKM so we can publish and share widely. --- ## Post #16 by @pablo @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. --- ## Post #17 by @ian.mcnicoll [quote="pablo, post:16, topic:857"] 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. [/quote] 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. --- ## Post #18 by @heather.leslie 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](https://ckm.openehr.org/ckm/projects/1013.30.41) I've just uploaded the latest version of the [OBSERVATION.imaging_exam_result](https://ckm.openehr.org/ckm/archetypes/1013.1.6018). 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](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949159/Adopt+an+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](https://ckm.openehr.org/ckm/archetypes/1013.1.6012) 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 --- ## Post #19 by @SevKohler Oh you open up a barrel here, I try to take a look on the weekend. --- ## Post #20 by @heather.leslie Please do! --- ## Post #21 by @SevKohler 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](https://ckm.openehr.org/ckm/archetypes/1013.1.1494) 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. --- ## Post #22 by @varntzen 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. --- ## Post #23 by @heather.leslie Thanks+++ Severin - will send out for review tomorrow. If anyone in this thread wants to participate in the review, please [adopt](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949159/Adopt+an+Archetype) the OBS.imaging_exam_result and we'll be able to invite you. Regards Heather --- ## Post #24 by @rfloca 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 --- ## Post #25 by @heather.leslie 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 - https://ckm.openehr.org/ckm/archetypes/1013.1.6012. Would that work for your use case? ![image|414x500](upload://4qaNO8SgkEK6uNkoWqUjSWtHHUQ.png) Please [adopt](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949159/Adopt+an+Archetype) the OBS.imaging_exam_result so we can invite you to the review. Regards Heather --- ## Post #26 by @heather.leslie 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 --- ## Post #27 by @heather.leslie ICYMI - https://discourse.openehr.org/t/observation-imaging-examination-result-and-cluster-imaging-exam-ready-to-be-published/2594?u=heather.leslie --- **Canonical:** https://discourse.openehr.org/t/dicom-compliance-of-observation-imaging-exam-result/857 **Original content:** https://discourse.openehr.org/t/dicom-compliance-of-observation-imaging-exam-result/857