Difference between revisions of "Cross-Community Patient Discovery"
JohnMoehrke (talk | contribs) |
JohnMoehrke (talk | contribs) |
||
| Line 13: | Line 13: | ||
The Cross-Community Patient Discovery (XCPD) profile supports the means to locate communities which hold patient relevant health data and the translation of patient identifiers across communities holding the same patient’s data. A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information within the community via an established mechanism. Facilities/enterprises may host any type of healthcare application such as EHR, PHR, etc. A community is identifiable by a globally unique id called the homeCommunityId. Membership of a facility/enterprise in one community does not preclude it from being a member in another community. Such communities may be XDS Affinity Domains which define document sharing using the XDS profile or any other communities, no matter what their internal sharing structure. | The Cross-Community Patient Discovery (XCPD) profile supports the means to locate communities which hold patient relevant health data and the translation of patient identifiers across communities holding the same patient’s data. A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information within the community via an established mechanism. Facilities/enterprises may host any type of healthcare application such as EHR, PHR, etc. A community is identifiable by a globally unique id called the homeCommunityId. Membership of a facility/enterprise in one community does not preclude it from being a member in another community. Such communities may be XDS Affinity Domains which define document sharing using the XDS profile or any other communities, no matter what their internal sharing structure. | ||
| + | ===Options=== | ||
| + | |||
| + | The following modes are supported and are intended | ||
| + | |||
| + | *Normal (synchronous) | ||
| + | **the SOAP request and response are carried in one TCP/IP connection | ||
| + | ***Response is expected in very short timeframe, e.g. less than 60 seconds | ||
| + | *Asynchronous | ||
| + | **where the WS-Addressing support for “replyTo” is used to return the response through a separate TCP/IP connection | ||
| + | ***Response is expected in short timeframe, e.g. less than 60 minutes | ||
| + | *Deferred | ||
| + | **where the request is decoupled from the reply so each are a separate SOAP interaction (Section 3.55.6.2) | ||
| + | ***Response is expected to have lengthy delay, e.g. more than 60 minutes | ||
==Systems Affected== | ==Systems Affected== | ||
Revision as of 09:12, 4 January 2017
Summary
Cross-Community Patient Discovery (XCPD) - supports the means to locate communities which hold patient relevant health data and the translation of patient identifiers across communities holding the same patient’s data.
Benefits
- supports the means to locate communities which hold patient relevant health data
- translation of patient identifiers across communities holding the same patient’s data.
Details
The Cross-Community Patient Discovery (XCPD) profile supports the means to locate communities which hold patient relevant health data and the translation of patient identifiers across communities holding the same patient’s data. A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information within the community via an established mechanism. Facilities/enterprises may host any type of healthcare application such as EHR, PHR, etc. A community is identifiable by a globally unique id called the homeCommunityId. Membership of a facility/enterprise in one community does not preclude it from being a member in another community. Such communities may be XDS Affinity Domains which define document sharing using the XDS profile or any other communities, no matter what their internal sharing structure.
Options
The following modes are supported and are intended
- Normal (synchronous)
- the SOAP request and response are carried in one TCP/IP connection
- Response is expected in very short timeframe, e.g. less than 60 seconds
- the SOAP request and response are carried in one TCP/IP connection
- Asynchronous
- where the WS-Addressing support for “replyTo” is used to return the response through a separate TCP/IP connection
- Response is expected in short timeframe, e.g. less than 60 minutes
- where the WS-Addressing support for “replyTo” is used to return the response through a separate TCP/IP connection
- Deferred
- where the request is decoupled from the reply so each are a separate SOAP interaction (Section 3.55.6.2)
- Response is expected to have lengthy delay, e.g. more than 60 minutes
- where the request is decoupled from the reply so each are a separate SOAP interaction (Section 3.55.6.2)
Systems Affected
Systems involved in this profile are:
- HIS
Actors & Transactions:
Specification
Profile Status: Final Text
Documents:
- [1] Technical Framework
- Vol. 1 - Section 27
- Vol. 2b - Sections 3.55 & 3.56
- Vol. 2x - Appendix O HL7 v3 Transmission and Trigger Event Control Act Wrappers
- Vol. 2x - Appendix E IHE Requirements for Patient Identifier Data Types in HL7 Messages
- Vol. 2x - Appendix O HL7 v3 Transmission and Trigger Event Control Act Wrappers
- Vol. 2x - Appendix Q HL7 V3 Sample Payload XML Schemas
Underlying Standards:
- HL7 Version 3 Edition 2008, Patient Administration DSTU, Patient Topic
- HL7 V3 Datatypes 2008 Normative Edition
See Also
Guest blog articles by Karen Witting, co-chair of the IHE ITI Planning Committee and prime on the XCPD profile
Related Profiles
This page is based on the Profile Template
Current: IT Infrastructure Technical Framework.