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.