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.
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.
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.
‘Requester’ at at0030 and indicated a possible mapping to the narrower concept of DICOM’s ‘Referring Physician’s Name’.
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?
