Exchanging Images Outside a Specific Health Information Exchange Domain

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
Standard	Digital Imaging and Communication in Medicine (DICOM)	Final	Production	Feedback Requested	No	Free	No
Implementation Specification	IHE Cross Community Access for Imaging (XCA-I)	Final	Pilot		No	Free	Yes
Implementation Specification	The combination of IHE-XCPD (Cross-Community Patient Discovery) and IHE-PIX (Patient Identifier Cross-Reference)	Final	Production		No	Free	Yes
Implementation Specification	IHE Portable Data for Imaging (PDI)	Final	Production		No	Free	No

Limitations, Dependencies, and Preconditions for Consideration	Applicable Value Set(s) and Starter Set(s)
The IHE XCA-I profile can be found in Section 2.1.27 of the IHE Radiology (RAD) linked above. IHE-PIX and IHE-XCPD are used for the purposes of patient matching and to support this interoperability need. For IHE-PDI, network transfers are preferable to digital media transfers, though the latter may be used when network solutions are not in place See IHE projects in the Interoperability Proving Ground.	Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery. Authentication Enforcer – centralized authentication processes. Authorization Enforcer – specifies access control policies. Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).

Limitations, Dependencies, and Preconditions for Consideration

Applicable Value Set(s) and Starter Set(s)

The IHE XCA-I profile can be found in Section 2.1.27 of the IHE Radiology (RAD) linked above.
IHE-PIX and IHE-XCPD are used for the purposes of patient matching and to support this interoperability need.
For IHE-PDI, network transfers are preferable to digital media transfers, though the latter may be used when network solutions are not in place
See IHE projects in the Interoperability Proving Ground.

Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.
Authentication Enforcer – centralized authentication processes.
Authorization Enforcer – specifies access control policies.
Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).

Comment

Submitted by bschreiber on 2017-11-17

Using the Direct Protocol for Image Exchange

As a member of the Direct Project Workgroup, I would like to highlight work in progress to make the Direct Protocol feasible for image exchange and DICOM study exchange. The workgroup is testing the concept of message fragmentation (defined in RFC2046 section 5.2.2). This technique when combined with the Trust, Encryption, and Delivery notification standards of the Direct Protocol create an opportunity to eliminate the SMTP limit of 10 MB for message size and also eliminate the need for expensive persistent connections between parties. With Direct, any party with a Direct Address can immediately inter-operate with any other party with a Direct Address. This cost reduction should lead to more widespread Image Exchange.

Bruce Schreiber

CTO MaxMD

Submitted by andries.hamster on 2019-09-21

Uptake of XCA-I (and XDS-I) profile

The XCA-I and XDS-I profiles are both beyond the pilot phase and have been generally adopted by the diagnostic imaging industry. Both profiles are in "production" globally.

Submitted by lisaspellman on 2019-09-24

Suggestions for Section III

Section III: Standards and Implementation Specifications for Services/Transport/Exchange. Recommendations:

Change the title of the first block to be: Interoperability Need: Exchanging Images Outside of a Specific Health Information Exchange Domain
For this block, the standard is DICOM (not DICOMweb – DICOMweb is an implementation within the DICOM standard, and the XCA-I implementation does not rely on DICOMweb).
For now I would leave the next two rows (IHE XCA-I and IHE-XCPD/IHE-PIX) the same. But I think we will want to revisit this and consider if/how WIA fits for exchange outside of a HIE.
Change the title of the second block to be: Interoperability Need: Exchanging Images Within a Specific Health Information Exchange Domain

Given the way the document is structured, the “Implementation Specification” rows should reference the implementation documentation that utilizes the “Standard” defined in the first row. So once again, the “Standard” is DICOM. If a Health Information Exchange is built on a VNA, or dedicated PACS acting as a VNA, then DICOM or DICOMweb provides the standard, and we can reference Part 4, or Part 18 for the Implementation Specification.

Recommendations for Section III_DICOM.docx

Submitted by lisaspellman on 2019-09-24

Exchanging Imaging Documents Outside a Specific HIE Domain

Exchanging Imaging Documents Outside a Specific Health Information Exchange Domain Recommend addition of IHE PDI (Portable Data for Imaging) with an adoption of 5. Add a corresponding note to acknowledge that network transfers are clearly preferable to digital media, but when network solutions are not yet in place, transfer using digital media is preferable to no transfer at all. PDI does work and is successfully used widely. https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf

Exchanging Imaging Documents Outside a Specific HIE Domain_ODonnell_DICOM.docx