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
2. The Problem
The Cross-Community Access profile supports the means to query and retrieve patient relevant medical data held by other communities. 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
Use Case (how it should work)
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
<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">
<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">
<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">
<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">
<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">
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
- Image Document Consumer
- Image Document source
Reuse tranactions from XDS-I
New transactions (standards used)
- New transaction between Responding Gateway and Initiating Gateway for Image transfer. Possibly 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.
6. Support & Resources
There is global interest by vendors and regions for this capability.
<List technical or political risks that will need to be considered to successfully field the profile.>
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):
- 15% for Supplement Development
Responses to Issues:
- See italics in Risk and Open Issue sections