Cross-Community Access - Images (XCA-I) - Detailed Proposal
1. Proposed Workitem:Cross Community Access - Images (XCA-I)
- Proposal Editor: Chris Lindop'
- Editor: Chris Lindop
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: Radiology
The XDS.b and XDS-I.b profiles support the means for a community to query and retrieve relevant medical data within a community. It does not support access to relevant clinical information that may be in other communities. The Cross-Community Access profile supports the means to query and retrieve patient relevant medical data held by other communities for non-imaging data. Missing from the Cross-Community Access profile, is the support necessary for exchanging medical imaging data. The proposal is an extension to XCA for imaging. The proposal is constrained to support XDS-I.b with other communities.
3. Key Use Case
A typical Use Case
Assume within a region, such as the State of Wisconsin, we have several healthcare communities (or XDS Affinity Domains or RHIOs). One in Madison is also based on XDS.b and XDS-I.b for images. One in Whitewater is also based on XDS.b and XDS-I.b for images. Patient Abigail has a serious accident and is scanned with a CT in a local hospital emergency room. The local ED doctor immedeatly determines she needs care from a level 1 trauma center in Madison. An ED Referral is dispatched to the trauma center. Abigail is now in transit by a medical helicopter transport. While in route, the attending ED physician in Madison accepts the referral and uses her hospital information system to query across multiple domains for healthcare information about this patient. She finds the images recently acquired in Whitewater. She also notes Abigail had an MRI scan fairly recently in Milwaukee. She retrieves the CT scan and the MRI, reviews the images with other relevant clinical data, and develops a treatment plan prior to Abigail’s arrival.
4. Standards and Systems
Image Exchange Systems, PACS, EMRs, RISs
5. Technical Approach
The technical approach proposed is an extension to the existing Cross-Community Access (XCA) protocol defined in ITI.
XCA currently has the initiating gateway grouped with a document consumer. The proposal for XCA-I would require the grouping to include XDS-I.b Image Document Consumer and an XDS-I.b Image Document Source. The responding gateway would require the grouping to include XDS-I.b Image Document Consumer and an XDS-I.b Image Document Source.
When an Initiating Gateway receives a stored query by a Document Consumer which includes requests for imaging documents, it will in kind provide a stored query to the domain registry and responding gateways from other domains. The behavior will be identical to the currently specified behavior for XCA Initiating and Responding Gateways.
If the Initiating gateway receives a request to get an image manifest, it will retrieve the Image Manifest from either the responding gateway or local repository. It will re-purpose the image Document source location described in the Manifest to direct image queries to the image document source grouped with the Initiating Gateway.
If the image document source grouped with the Initiating gateway receives a request for images, it must first retrieve the images from either the XCA-I.b responding Gateway or local Image Document source, then provide the images to the requesting Image Document Consumer.
The responding gateway would also need to be grouped with an Image Document Consumer for collecting the image documents to be transferred back to the intiating gateway. There would be a new transaction for image transfer between the responding and initating gateway based on RAD-69.
- Initiating Gateway
- Responding Gateway
- Document Consumer
- Document source
- Image Document Consumer
- Image Document source
Reuse tranSactions from XDS-I
New transactions (standards used)
- New transaction between Responding Gateway and Initiating Gateway for Image transfer. Reccomend based on RAD-69.
Impact on existing integration profiles
For XCA-I, as with XCA, Document Consumers will need to manage community ID in queries. An XDS-I Image Document Consumer will need to manage this attribute similar to the XDS Document Consumer.
When an Image Document Consumer or an Image Document Source is grouped with an Initiating or responding Gateway, the interfacing is not specified.
New integration profiles needed
New profile XCA-I is being proposed.
Breakdown of tasks that need to be accomplished
Develop the Technical Supplement leveraging XCA as the parent profile.
- Group Image Document Consumer Actor to Initiating Gateway
- Group Image Document Source Actor to Initiating Gateway
- Add RAD-69 to Responding Gateway as an Image Document Consumer
- Add RAD-69 functionality between Responding Gateway and Initiating Gateway for cross Community Image access
- Add functionality to Initiating Gateway to translate KOS retrieval information to grouped Image Document Source
- Possible option to pre-fetch and/or cache images at Gatewy for
- Allow for Image Document souce to include JPIP server or JPIP proxy as Image Document Source to requesting Consumer
6. Support & Resources
There is global interest by vendors and regions for this capability.
Query Latency may be percieved as limiting factor for sucessful deployment. Pre-fetching and JPIP are two methods which could help mitigate.
With Pre-fetching, Storage limitiations may be an issue.
8. Open Issues
How will the Query latency be handled due to the caching of images locally in the affinity domain impact workflow?
How will JPIP be managed?
9. Tech Cmte Evaluation
Effort Evaluation (as a % of Tech Cmte Bandwidth):
- 30% for Supplement Development
Responses to Issues:
- See italics in Risk and Open Issue sections