Return to detail page at www.hitsp.org	HITSP/TP13
	Prev  TOC  Next

---

2.0Transaction Package Definition

2.1 Context Overview

To support this HITSP Manage Sharing of Documents Transaction Package, HITSP has selected the Integrating the Healthcare Enterprise (IHE) Cross-Enterprise Document Sharing (XDS) and the Cross Community Access (XCA) Integration Profiles, which facilitate the registration, distribution and access of patient electronic health records across healthcare enterprises and across communities of such enterprises. Cross-Enterprise Document Sharing is focused on providing a standards-based specification for managing the sharing of documents between healthcare enterprises, ranging from a private physician office, to a clinic, to an acute care inpatient facility and other healthcare IT systems. Cross Community Access is focused on creating a network of networks or communities by providing the means for a community to access consumers health records managed by other communities. Additional source material from the IHE IT Infrastructure (ITI) Technical Framework (TF) Cross-Enterprise Document Sharing (XDS) Integration Profile and associated supplements on Registry Stored Query, XDS.b and XCA are quoted in this document to further clarify the actions and interactions.

The IHE XDS and XCA Integration Profiles, which are reproduced in part in this specification, with specific written permission from IHE, provide sample scenarios depicting how specific interfaces should comply with the proposed standards for interoperability. Key concepts from the IHE XDS and XCA Integration Profiles are introduced in this document to help the reader understand the context of the Profile.

Overview of IHE XDS Integration Profile

This section provides an overview of the IHE XDS Integration Profile. Its intent is to provide the reader with an introductory context to the XDS Profile. XDS provides the ability to register, store and query/retrieve documents containing consumer or patient-centric healthcare information.

The previous IHE XDS Integration Profile [1] is now referred to as XDS.a but remains technically without change. The current XDS Integration Profile referred to as XDS.b employs different versions of ebXML Registry (versions 2.0 and 3.0) and specifications that have been superseded (like SOAP with Attachments or SwA). The IHE XDS.b Integration Profile accomplishes the following:

Updates XDS Web Services implementation to allow for use of SOAP 1.2 and optionally SOAP1.1

Updates the XDS transactions to use ebXML Registry 3.0 metadata

Updates Provide and Register Document Set "on-line" mode transaction to use MTOM instead of the legacy SOAP with Attachments (SwA) mechanism

Defines a new transaction which provides a SOAP binding for the XDS Retrieve Document transaction that uses MTOM (new transaction now named "Retrieve Document Set")

Updates IHE XDS Registry Stored Query transaction to be consistent with other XDS.b transactions. The Registry Stored Query transaction is the same in XDS.a and XDS.b

Provides informative Web Services Description Language (WSDL) contracts for all required IHE XDS.b Transactions and WSDL fragments for options

XDS.b introduces the new Patient Identity Feed HL7v3 transaction in addition to the existing Patient Identity Feed [ITI-8] transaction based on HL7v2. For more detailed explanations, examples and the complete specification see the IHE XDS Integration Profile specification at www.ihe.net.

Text from the IHE XDS Integration Profile begins here:

IHE Cross-Enterprise Document Sharing (XDS) is focused on providing a standards-based specification for managing the sharing of patient electronic health records or documents between any healthcare entity, ranging from a private physician office, to a clinic, to an acute care in-patient facility or other health information system.

The IHE XDS Integration Profile assumes that these enterprises belong to one or more XDS Affinity Domains. An XDS Affinity Domain is a group of healthcare enterprises that have agreed to share health information together using a common set of policies and share a common infrastructure.

Examples of XDS Affinity Domains include:

Community of Care supported by a Health Information Exchange in order to serve all patients in a given region

Nationwide EHR

Specialized or Disease-Oriented Care

- Cardiology Specialists and an Acute Cardiology Center

- Oncology Network

- Diabetes Network

Federation of Enterprises

- A regional federation made up of several local hospitals and healthcare providers

Government Sponsored Facilities (e.g.,, VA or Military)

Insurance Provider Supported Communities

Within an XDS Affinity Domain, certain common policies and business rules must be defined. They include how patients are identified, consent is obtained and access is controlled, as well as the format, content, structure, organization and representation of health information. This Integration Profile does not define specific policies and business rules; however, it has been designed to accommodate a wide range of such policies to facilitate the deployment of standards-based infrastructures for sharing patient health documents. This is managed through federated Document Repositories and a Document Registry to create a longitudinal record of information about a patient within a given XDS Affinity Domain. These are distinct entities with separate responsibilities:

A Document Repository is responsible for storing documents in a transparent, secure, reliable and persistent manner and responding to document retrieval requests

A Document Registry is responsible for storing information about documents of interest, for the care of a patient may be easily found, selected and retrieved irrespective of the repository where they are actually stored

The concept of a document in XDS is not limited to textual information, a XDS is document content neutral. Any type of health information without regard to content and representation is supported. This makes the IHE XDS Integration Profile equally able to handle documents containing simple text, formatted text (e.g., HL7 CDA Release 1), images (e.g., DICOM) or structured and vocabulary coded clinical information (e.g., CDA Release 2, DICOM SR). In order to ensure the necessary interoperability between the Document Sources and the Document Consumers, the XDS Affinity Domain must adopt policies concerning document format, structure and content.

Text from the IHE XDS Integration Profile ends here.

Overview of the IHE XCA Integration profile

Figure 2-1 shows the interfaces directly involved in the XCA Integration Profile and the relevant transactions between them.

Figure 2-1 XCA Interface Diagram

Figure 2-2 Initiating Gateway grouped with Document Consumer

When a Responding Gateway is supporting an XDS Affinity Domain, it may resolve Cross Gateway Query and Cross Gateway Retrieve Transactions by grouping with a Document Consumer Interface and using the Registry Stored Query and Retrieve Document Set transactions. For details see IHE IT Infrastructure TF Section 18.2.2.2

Figure 2-3 Responding Gateway grouped with Document Consumer

Text from the IHE XCA Integration Profile ends here.

2.1.1 Interfaces

Options that may be selected for this Construct are listed below:

For the XDS.a Option, in IHE-ITI-TF-1, Section 10.2, Table 10.2-1 (in the IHE XDS Integration Profile) along with the Interfaces to which they apply

For the XDS.b Option, in the supplement IHE IT Infrastructure Technical Framework Supplement 2007-2008 Cross-Enterprise Document Sharing-b (XDS.b), Section 10.2, Table 10.2-1b XDS.b - Interfaces and Options

For the XCA Option, In IHE-ITI-XCA Supplement, Section 18.2, Table 18.2-1 (in the IHE XCA Integration Profile) along with the Interfaces to which they apply

Table 2-1 Interfaces for XDS.a Option

Table 2-2 List of Transactions for XDS.b Option

Table 2-3 Interfaces for XCA Option

2.1.2 Interface Interactions

Specifically, the following sections provide further detail about the interactions that are addressed by this Transaction Package.

2.1.2.1 Cross-Enterprise Document Sharing XDS.a Option

The relationship between the interfaces and the transactions of this Transaction Package are shown in IHE-ITI-TF-1, Section 10.1 (in the IHE Technical Framework, XDS Integration Profile Chapter). The process flows supported by this Transaction Package are shown in IHE-ITI-TF-1 Section 10.4.1 (in the IHE XDS Integration Profile).

Figure 2-4 Cross-Enterprise Document Sharing XDS.a Diagram

2.1.2.2 Cross-Enterprise Document Sharing XDS.b

The relationship between the interfaces and the transactions of this Transaction Package are shown in IHE-ITI-TF-1, Section 10.1 (in the IHE Technical Framework, XDS Integration Profile Chapter). The process flows supported by this Transaction Package are shown in IHE-ITI-TF-1 Section 10.4.1 (in the IHE XDS Integration Profile).

Figure 2-5 Cross-Enterprise Document Sharing XDS.b Diagram

Note that e ach XDS option addresses the same set of interfaces and transactions, but reference different transactions from the IHE Technical Framework for Retrieve Document set, Provide and Register Document Set, Register Document Set.

2.1.2.3 Document Integrity Option

The following diagram further illustrates where the optional verification of Document Integrity is performed within an XDS Affinity Domain. This option applies both on the XDS.a and the XDS.b options.

Figure 2-6 Optional Document Integrity Sequence Diagram

The diagram above outlines several interactions that are integral to the establishment of Document Integrity. The storage and querying of documents, as occurs in the Provide Document to Repository transaction is the trigger by which the Document Integrity activity is invoked. Once a document is provided to the Document Repository by the Document Source, the document is also registered in a Registry, so that it can be located.

Once a document is stored into a Document Repository, it can be located through a registry query and then retrieved by the Document Consumer.

The Verify Integrity of Document interaction is an optional activity that occurs in order to ensure that Document Integrity is validated. This represents the validation of the SHA-1 hash attribute by the Document Consumer.

2.1.2.4 XCA Cross Community Access

The relationship between the interfaces and the transactions of this Transaction Package are shown in IHE-ITI-XCA Supplement. The process flows supported by this Transaction Package are shown in IHE-ITI-XCA Supplement Section 18.1 (in the IHE XCA Integration Profile). This is described in Section 2.1 Context Overview of this document.

2.1.2.5 Gaps

The following gaps have been identified for this Transaction Package.

2.1.2.5.1 Terminology

Document Registration Terminology is a gap. This Component will include the set of vocabularies used in the XDS Document Registry to populate the metadata associated with each document. There is no ready terminology to reference, but we will leverage subsets of existing terminology structures such as those used by LOINC Document dimensions.

2.1.2.5.2 Cross-Affinity Domain Document Sharing

The HITSP Manage Sharing of Documents Transaction Package is based on the IHE-XDS and the IHE XCA Integration Profiles referenced by HITSP from the IHE IT Infrastructure Technical Framework. This section discusses the pre-conditions associated with document sharing environments across multiple independent domains.

The Integrating the Healthcare Enterprise has defined an Integration Profile called Cross-Enterprise Document Sharing (XDS), which defines document sharing among a number of entities or organizations forming an XDS Affinity Domain using the IHE XDS terminology. This construct also includes the means for Communities (XDS based or not) to access remote Communities (XDS based or not), leveraging the IHE Cross-Community Access (XCA) Integration Profile.

For Cross-Community Access, a number of additional interoperability requirements need to be addressed beyond XCA. Some of these are addressed by existing HITSP Constructs, while others remain to be addressed:

Cross-Community patient identification linkage. In two common environments, this is addressed by the use of the existing HITSP/TP22 Patient Identity Cross-Referencing Transaction Package and HITSP/T23 Patient Demographics Query. This is discussed in detail in the IHE XCA supplement. Some specific issues may need further work for which HITSP should leverage lessons learned by the NHIN contractors, Connecting for Health, Federal Agencies, IHE and otherimplementation experiences

Community Discovery: In this domain there are numerous strategies, some patient-centric such as use of a Patient Community Locator, consumer carried smart tokens conveying community addresses, etc. This may be handled by manual configurations which may be the most practical especially when the Cross-Community consent sharing remains a complex issue

Cross-Community policy matching: This area requires much work and analysis. In the short to mid-term this may be handled by manual configuration among peer communities that have performed a matching of their document sharing policies

HITSP will contribute to and review the white paper being developed by IHE in 2008 along with other input such as lessons learned by the NHIN contractors, Connecting for Health, Federal Agencies, IHE and otherimplementation experiences.

Figure 2-7 XDS Affinity Domain

Within an XDS Affinity Domain, for the purpose of information exchange among the member organizations, certain common policies and business rules must be defined. Neither HITSP, nor IHE define these policies or what is the appropriate implementation of XDS Affinity Domains for the NHIN, RHIOs/HIEs, Sub-network Organizations or large enterprises such as Federal Agencies. HITSP does not rule on the number of organizations that partake. These choices are considered to be implementation, configuration or architecture decisions, not within the purview of HITSP.

Conclusion

The HITSP Manage Sharing of Documents Transaction Package addresses a number of environments while others are beyond its current scope:

Single Organization Stand-alone XDS Affinity Domain: An organization/enterprise implements IHE-XDS internally and chooses to be a single XDS Affinity Domain, where its internal systems are Document Sources and Document Consumers. There is a Document Registry and one or more Document Repositories in the XDS Affinity Domain.

Multi-Organization Stand-alone Affinity Domain: A number of independent organizations choose to share documents by joining in an XDS Affinity Domain. Each organization chooses to be a Document Source and/or Document Consumer. Each organizationmay also choose to be itsown Document Repository or to use one or more shared Document Repository. There is a Document Registry in the XDS Affinity Domain (possibly hosted by one of the member organizations).

Multi-Affinity Domains Hierarchical Federation: A number of XDS Affinity Domains, each independently managed, choose to establish a federation. With a federation level PIX Manager (e.g., an RLS as defined by Connecting for Health) and the use of Cross-Community Access (XCA) as defined by this construct, Cross-Affinity Domain access is possible.

Multi-Affinity Domains Lateral Cross-Community: A number of XDS Affinity Domains, each independently managed, wish to establish peer-to-peer communication without establishing a federation. With the use of Cross-Community Access (XCA) as defined by this construct, Cross-Affinity Domain access is possible.

Approach 3 and 4require further work in the area of community discovery, privacy and Cross-Community policy matching. The HITSP will leverage lessons learned by the NHIN contractors, Connecting for Health, Federal Agencies, IHE and otherimplementation activities as they become available.

2.1.3 Pre-conditions

Table 2-4 lists the pre-conditions when implementing the XDS.a and XDS.b Options for this Transaction Package.

Table 2-4 Pre-conditions for XDS.a and XDS.b Options

Table 2-5 lists the pre-conditions when implementing the XCA Option for this Transaction Package.

Table 2-5 Pre-conditions for XCA Option

2.1.3.1 Process Triggers

Table 2-6 lists the triggers for the XDS.a and XDS.b Options for this Transaction Package.

Table 2-6 Process Triggers for XDS.a and XDS.b Options

Table 2-7 lists the triggers for the XCA Option for this Transaction Package.

Table 2-7 Process Triggers for XCA Option

2.1.4 Post-conditions

Table 2-8 lists the post-conditions for the XDS.a and XDS.b Options for this Transaction Package, as well as the post-conditions if the Document Integrity constraint is applied.

Table 2-8 Post-conditions for XDS.a and XDS.b Options

Table 2-9 lists the post-conditions for the XCA Option for this Transaction Package.

Table 2-9 Post-conditions for XCA Option

2.1.4.1 Required Outputs

There were no identified outputs from the processes supported for the XDS.a and XDS.b options in this Transaction Package other than the integration of the documents into the clinicians EHR system and Biosurveillance database. If the optional Document Integrity constraint applied, then the following outputs are identified:

Table 2-10 Required Outputs

2.1.5 Data Flows

See IHE Infrastructure IT Technical Framework specifications for clinical examples.

2.2 List of HITSP Constructs

Table 2-11 List of Constructs

2.2.1 Construct Dependencies

Table 2-12 Construct Dependencies

2.2.2 Additional Constraints on Required Constructs

Table 2-13 Additional Constraints on Required Constructs

2.3 Standards

2.3.1 Regulatory Guidance

Table 2-14 Regulatory Guidance

2.3.2 Selected Standards

Table 2-15 Selected Standards [11]

2.3.3 Informative Reference Standards

Table 2-16 Informative Reference Standards

---

	Return to detail page at www.hitsp.org	HITSP/TP13
	Prev  TOC  Next