Stream: implementers
Topic: CodeableConcept describing DICOM images
Parnesh Raniga (Oct 17 2018 at 12:33):
Just trying to create an Endpoint resource for a DICOM PACS. What would the correct payloadType be?
Lloyd McKenzie (Oct 17 2018 at 14:45):
@Elliot Silver ?
Elliot Silver (Oct 17 2018 at 16:43):
Hmm, good question. Imaging WG hasn't looked at endpoint recently, so I'm not sure I can give an "official" answer. I didn't recall that payloadType is a required field. (@Brian Postlethwaite -- what's the logic in making it required?). The closest equivalent to the example valueset would be to list all of the supported SOP classes as codes (urn:oid: format, system of urn:ietf:rfc:3986). This would also be consistent with the IHE format code examples, since XDS-I KOS use the SOP class as the format code value. (Although IHE suggests 1.2.840.10008.2.6.1 -- the DICOM UID Registry-- as the system; I could be convinced to use that instead of RFC3986.)
I don't like explicitly listing the SOP classes though, since an image archive may add support for new SOP classes at any time, often through a configuration change, and there is the question of supported SOP classes vs. available SOP classes ("yes, I could give you a dose plan...if I had one"). And in some ways, I'd rather say push this off to the PACS, rather than keep it in FHIR; this is something the new work on DICOM part 18 conformance and the OPTIONS header should include.
SOP class also makes some sense for WADO-RS and STOW-RS, but not for QIDO-RS. The returned content isn't a DICOM composite SOP instance. You could use the C-FIND SOP classes, but since QIDO doesn't map exactly to C-FIND, I'm not sure that's the right answer either.
You could also use a code that means generic DICOM payloads. I can't think of an existing code value/system for that off the top of my head, so you may need to create your own, and make sure your partners know it.
(By the way, I'm assuming you're interested in DICOMweb -- the Imaging workgroup is ignoring DIMSE connectivity since we expect users will want to use RESTful DICOM with RESTful FHIR. If you're trying to describe a DIMSE endpoint (AE title, port, etc.), you'll need to invent your own approach.)
There are a whole bunch of issues here that need looking at. I've filed a tracker item (GF#19427) to make sure it gets some attention.
Parnesh Raniga (Oct 17 2018 at 22:17):
@Elliot Silver Thanks for the very comprehensive answer. I agree that this should be a code saying that this is a DICOM PACS (implying support for DICOMWeb) that can receive DICOM payload without specifying SOPs. I would have assumed that this would exist in the IHE format codes.
Will follow the tracker item.
Elliot Silver (Oct 17 2018 at 22:21):
For clarity, you already can indicate that the endpoint supports DICOMweb via connectionType. What is missing is guidance, or an appropriate vocabulary for payloadType.
Parnesh Raniga (Oct 17 2018 at 22:59):
@Elliot Silver Indeed.
Parnesh Raniga (Oct 18 2018 at 07:19):
Currently using @Elliot Silver suggestion for urn:oid:1.2.840.10008.2.6.1 which is enough to pass the validation tests. :thumbs_up:
Lloyd McKenzie (Oct 18 2018 at 13:30):
I would strongly encourage transitioning to a human-readable URL. If you lock into an OID-based code system, you'll be stuck with it forever more and a meaningful (and ideally resolvable) URL is much easier for software developers to understand and is less likely for implementers to get wrong.
Elliot Silver (Oct 18 2018 at 15:57):
@Lloyd McKenzie, although I generally would agree with that, here we're trying to connect to a DICOM server that uses DICOM-assigned OIDs to identify DICOM file content. If my suggestion of using payloadType to identify the file content (SOP classes) -- and I'm not sure that's the right answer -- then most systems that use those endpoint will need to know the DICOM SOP class OIDs anyhow. I'd rather not have systems have to maintain two lists, and possibly a mapping between them.
Further, DICOM isn't likely to define those URLs, as DICOM is more than happy to continue to use OID. So, to do this in a standard way becomes a FHIR responsibility. We have already seen the reluctance to add a single code value to support DICOM identifiers; I'm not sure FHIR wants to add 100 codes value for all DICOM SOP classes, and to take on the responsibility of maintaining it in sync with changes to the DICOM standard (which publishes 5 times per year).
Parnesh Raniga (Oct 19 2018 at 00:46):
I can see pro's and con's to both ways. Agree with @Elliot Silver in that you will need to connect to the system anyway to figure out what it will support and what it won't. The fact that this is a DICOM endpoint is already defined in the connectiontype as a code means that the payload type does not give you any more info if you use a single generic URL in this instance.
Last updated: Apr 12 2022 at 19:14 UTC
