It shoud be possible for endpoint to describe various endpoints used in Diagnostic Imaging.

Currently, the ImagingManifest resource has its own set of elements and coding used to provide a similar (although way more limited) functionality to Endpoint, which could be switched over to Endpoint. To do so, Endpoint needs to be able to express the following services: DICOM WADO-URI (HTTP GET), DICOM WADO-RS (RESTful retrieve), and IHE IID (Invoke Image Display, HTTP GET).

For the various WADO services, the payloadType/payloadFormat would vary depending on the Accept headers, query parameters (equivalent to the FHIR _format query parameter) or query payload. For IID, the result is to launch a web-based image viewer. Thus, for these uses, I think that no payloadFormat or Type should be specified.

In the future, the list of supported services could be extended to include: DICOM QIDO-RS, STOW-RS, and UPS-RS (all RESTful).

Other protocols that have been discussed but are less likely to be needed, include:

• DICOM WADO-WS (and the related IHE RAD-69), which is similar to XDS document retrieval, and might need a retrieveLocationUid attribute. For that matter, should enpoint be able to support XDS?

• DICOM DIMSE, which identifies endpoints by an AE Title (a short string) that is typically used to look up the corresponding hostname/IP and port, and a list of capabilities (supported SOP classes) for that endpoint. However, in many ways, DIMSE is the DICOM equivalent of HL7 v2, so it is unclear if support for DIMSE will ever be needed in an FHIR environment.