Stream: implementers
Topic: DICOM Metadata Extension
Jan Maluche (May 03 2021 at 06:49):
Hello, i am working on a process extracting dicom Metadata to a FHIR Server for further processing. Besides the elements of ImagingStudy I am interested to store different types like T1/T2 Time of MRI, Sequence description, some device codes, ... which can be part of the dicomheader.
I thought about creating an own extension to fulfill that, but was wondering if there is already something i can extend or use?
Lloyd McKenzie (May 03 2021 at 14:31):
@Elliot Silver
Elliot Silver (May 03 2021 at 16:12):
There are a couple of existing efforts that might be relevant. One is around dose reporting (https://confluence.hl7.org/display/IMIN/Radiation+Dose+Summary+for+Diagnostic+Procedures+on+FHIR) and the other is DICOM SR to FHIR (via CDA mappings) (https://confluence.hl7.org/display/IMIN/Mapping+of+DICOM+SR+to+FHIR). Neither is what you are looking for, but they might give some insight into community approaches.
Depending on what you are modelling, I'd either make sequence information a subtask or subprocedure within the parent procedure (I'd need to review the procedure and task resources to figure out which), or add it as extensions on the ImagingStudy.
One thing the joint DICOM/HL7 workgroup has tried hard to understand is the boundary between DICOM and FHIR. Generally they have come down on leaving the actual imaging data in DICOM, while the procedure and other "management" type attributes stay in FHIR. Clinical observations are moving towards dual representation or a combined representation. I'd ask, what is the information that you want in FHIR that isn't available currently? Is this something the workgroup needs to consider? If your goal is just to have the DICOM metadata in a format that is more easily consumable for non-DICOM systems, you may want to consider one the DICOM XML or traditional DICOM JSON formats, or the new simplified JSON format (supplement 219).
Finally, if I had to create extensions to ImagingStudy, to record additional DICOM metadata, I'd use the DICOM attribute keyword in the extension name. This may be something that the WG wants to standardize on, and because they are within DICOM could use something like http://www.dicomstandard.org/element/someAttributeName as the style. If they adopt this, the extensions would be commonly understood across systems. However, since they haven't taken this on, your extensions will have to use a domain you control, and you'll have to educate your partners on the extension meanings.
Current Imaging Integration co-chairs are @Jonathan Whitby and @Christopher Lindop if they want to chime in, or bring these issues to the workgroup.
Jan Maluche (May 04 2021 at 08:40):
Thank you verry much @Elliot Silver for this summary.
I thought about modelling the additional information to the Series element of ImagingStudy. Currently it is not clear by requierement, which additional in formation should be included, as this is still in negotiation process. But at least some additional information about the technical details of the imaging process should be implemented in near future.
From my point of view the attribute specific extensions as your last point explained seems to be most operable.
Elliot Silver (May 04 2021 at 18:01):
@Jan Maluche , we discussed your issue on the Imaging Integration work group call today. The consensus favored use of the metadata-only WADO retrieve to access additional DICOM attributes. This is more flexible, as it doesn't depend on all ImagingStudy publishers having to know about the extensions, or consumers being limited to the attributes you've chosen to publish. Obviously, you're free to do as you wish in your implementation, but if this isn't a good solution for you, the WG would be interested in understanding the problem more. Feel free to join a WG call, or comment on the ticket I filed to help clarify this (FHIR#32077).
Jan Maluche (May 05 2021 at 07:53):
Thank you. I will discuss this point with my colleagues and may join with a very specfic example.
I understand the part, why the wado attempt is more interoperable. I will check, if this would make sense for our planned infrastructure. At the moment every datasource is put into a fhir server, which is the basis of different etl processes. Currently we planned to have some additional information available for the secondary process usage to filter more specific. Afterwards we also planned to make more specific dicom tags available.
Last updated: Apr 12 2022 at 19:14 UTC
