Difference between revisions of "Cross-Community Access - Images (XCA-I) - Detailed Proposal"

Latest revision as of 11:10, 27 October 2010

1. Proposed Workitem:Cross Community Access - Images (XCA-I)

Proposal Editor: Chris Lindop'
Editor: Chris Lindop / Alexis Tzannes
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: Radiology

2. Summary

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

XDS.b

XDS-I.b

XCA

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.

Existing actors

Initiating Gateway
Responding Gateway
Document Consumer
Document source
Image Document Consumer
Image Document source

New actors

None.

Existing transactions

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.

Assitance by members from:

IHE-USA
IHE-Canada
IHE-UK
IHE-Europe
IHE ASIA Pacific

would be solicited in addition to IHE Radiology and IHE ITI.

7. Risks

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? (scope of use, end-to-end vs middle-to-end)

How are "legal"/permission/access issues addressed between sites that do not share the common legal environment of an affinity domain?

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

Candidate Editor:

Lindop /Tzannes

@@ Line 2: / Line 2: @@
 * Proposal Editor: ''Chris Lindop'
-* Editor: Chris Lindop
+* Editor: Chris Lindop / Alexis Tzannes
 * Date:    N/A (Wiki keeps history)
 * Version: N/A (Wiki keeps history)
@@ Line 9: / Line 9: @@
 [[Category:RAD]]
-==2. The Problem==
+==2. Summary ==
-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/
+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==
-Use Case (how it should work)
+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.
@@ Line 29: / Line 29: @@
 Image Exchange Systems, PACS, EMRs, RISs
-==5. Discussion==
-===Summary===
-''<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==
@@ Line 63: / Line 48: @@
 *Initiating Gateway
 *Responding Gateway
+*Document Consumer
+*Document source
 *Image Document Consumer
 *Image Document source
@@ Line 72: / Line 59: @@
 ===Existing transactions===
-Reuse tranactions from XDS-I
+Reuse tranSactions from XDS-I
 ===New transactions (standards used)===
-*New transaction between Responding Gateway and Initiating Gateway for Image transfer.  Possibly based on RAD-69.
+*New transaction between Responding Gateway and Initiating Gateway for Image transfer.  Reccomend based on RAD-69.
 ===Impact on existing integration profiles===
@@ Line 87: / Line 74: @@
 ===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.
+Assitance by members from:
+*IHE-USA
+*IHE-Canada
+*IHE-UK
+*IHE-Europe
+*IHE ASIA Pacific
+would be solicited in addition to IHE Radiology and IHE ITI.
 ==7. Risks==
-''<List technical or political risks that will need to be considered to successfully field the profile.>''
+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==
@@ Line 102: / Line 106: @@
 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?
+How will JPIP be managed? (scope of use, end-to-end vs middle-to-end)
+How are "legal"/permission/access issues addressed between sites that do not share the common legal environment of an affinity domain?
 ==9. Tech Cmte Evaluation==
 Effort Evaluation (as a % of Tech Cmte Bandwidth):
-:* 15% for Supplement Development
+:* 30% for Supplement Development
 Responses to Issues:
@@ Line 113: / Line 119: @@
 Candidate Editor:
-: TBA
+: Lindop /Tzannes