How are images (like x-rays) stored and retrieved for FHIR servers

1

Hello,

I am very new to FHIR schema, and I am working on a server that hosts FHIR data and an application that represent the data.

I was wondering how to represent images associated with FHIR data. For example, if I have x-ray images from an Observation, can I upload the images to the FHIR server and have them retrieved, or should they be uploaded to a different storage and only their urls are given to the FHIR data?

I would also like to know which resourceType to use with the images. I’ve found Media, ImagingStudy, and ImagingManifest on stu3, but it’s difficult for me understand them fully. Am I correct that images themselves need to be Media and ImagingStudy ties them to the Patient?

Thank you,

2 Likes
2

ImagingManifest is being removed in R4. Your real choice is between Media and ImagingStudy. Media is a simple wrapper around something jpg/png; it provides some simple metadata and links directly to patient. ImagingStudy is an alternative that, instead of containing the pixels in some format, refers to the images as available on a DICOM-WS server. The second option brings to bear to the awesome power of the DICOM stack, but also brings the price and complexity of that.

Which is a better choice is not one the FHIR standard can make for you; it just defines these 2 different paths so that you can choose. In terms of your question, I think it depends where and how you get the images.

2 Likes
3

I am happy to have finally found this forum and hope I will also find some answers to my beginner’s questions.

The question raised by Efreeto is more or less also mine. To be clear: our developers’ group is considering
to become part of a project the gist of which should be interoperability between DICOM applications and FHIR servers.

We all come from the DICOM world, with no experience, little knowledge about, and great interest in FHIR.
In first approximation, our use case is as follows: a DICOM application should send scalar data
(patient, study, series, instance, measurements and some specific metadata) as well as the images themselves to a FHIR server using a service that has to perform all the necessary mappings.

As far as I understand Grahame’s answer, there exists no direct possibility to store a DICOM object
(such as instance or image) as a value within a ImagingStudy, but only an URL to a WADO-enabled PACS
(something very similar we implemented ad hoc years ago in a HL7 V2-flavored project).

Anyway, there remain many knowledge gaps and technical questions, how can one get more information?
Are there some examples of similar projects to follow?

TIA, Stan

4

It is possible to store the actual DICOM images within FHIR, but I wouldn’t recommend it. And before pursuing it, I’d want to understand your use case better.

In many cases FHIR servers are designed around for smaller data objects with a moderate update rate. On the other hand, DICOM images are usually large (and can be huge), and seldom change. The infrastructure requirements are often different, and you probably won’t be happy with the performance of using the wrong one.

That said, if you do want to go down that route…

Theoretically, you could use the valueAttachment of an extension to add the image content to the instance element of an ImagingStudy resource. However, that would mean pulling back the image each time the ImagingStudy was retrieved; there would be no way to get the “metadata” separately. Worse, if the study had 100 images (or 1000), the image data for each would all be attached to the ImagingStudy resource; retrievals would likely time out as a FHIR get isn’t expected to take 5 minutes.

So, direct image storage within the ImagingStudy is unlikely to work. However, FHIR does have the Binary resource which is used for storing arbitrary blobs of data, and could be used to store the DICOM images. You could use ImagingStudy.enpoint with a fhir-rest endpoint type (you aren’t restricted to WADO/QIDO) to indicate that the images are stored on the FHIR server; but since the endpoint is specified for the study, not each instance, unless you can compute a mapping for a specific instance to a specific binary, that won’t get you much further.

If you are determined to go down this route, you could define an extension on ImagingStudy.series.instance with a valueUri set to the Binary resource for instance. This wouldn’t bloat the ImagingStudy resource too unreasonably.

As for examples to follow, I think some of the open source DICOM projects now have query-able FHIR APIs, but I’m not sure. The Microsoft Azure DICOM offering has an integration with their FHIR server to publish ImagingStudy resource for DICOM studies, and to sync the content.

If you feel the inability to store and reference DICOM images in FHIR is a problem, consider submitting an issue against the spec (at the bottom of each page of the FHIR standard) and getting involved in HL7 Imaging Integration/DICOM WG-20. At this point, I’m not sure they’ll make large changes to the spec, but a standard extension is not unreasonable.

1 Like