PCC TF-1/Overview

PCC Integration Profiles Overview

In this document, each IHE Integration Profile is defined by:

• The IHE actors involved
• The specific set of IHE transactions exchanged by each IHE actor.
• The content of the IHE transactions

These requirements are presented in the form of a table of transactions required for each actor supporting the Integration Profile. Actors supporting multiple Integration Profiles are required to support all the required transactions of each Integration Profile supported. When an Integration Profile depends upon another Integration Profile, the transactions required for the dependent Integration Profile have not been included in the table.

The content of the transactions are presented as Content Integration Profiles. These are specification of the content to be exchange, along with explanations (called bindings) of how the content affects the transactions in which it is exchanged. It is expected that Content Integration Profiles will be used environments where the physician offices and hospitals have a coordinated infrastructure that serves the information sharing needs of this community of care. Several mechanisms are supported by IHE profiles:

• A registry/repository-based infrastructure is defined by the IHE Cross-Enterprise Document Sharing (XDS) and other IHE Integration Profiles such as patient identification (PIX & PDQ), and notification of availability of documents (NAV).
• A media-based infrastructure is defined by the IHE Cross-Enterprise Document Media Interchange (XDM) profile.
• A reliable messaging-based infrastructure is defined by the IHE Cross-Enterprise Document Reliable Interchange (XDR) profile.
• All of these infrastructures support Security and privacy through the use of the Consistent Time (CT) and Audit Trail and Node Authentication (ATNA) profiles.

For more details on these profiles, see the IHE IT Infrastructure Technical Framework, found here: http://www.ihe.net/Technical_Framework/.

Such an infrastructure is assumed by the use cases that focus on the context for defining the specific clinical information content for this profile. These content integration profiles use similar transactions and differ only in the content exchanged. A process flow for these use cases using Cross Enterprise Document Sharing (XDS) and Notification of Document Availability (NAV) is shown in the figure below. Other process flows are possible using XDM and/or XDR.

Use Case Process Flow Diagram

These steps are:

1. Extract/capture a collection of records into a set of documents packaged as an XDS Submission Set. This submission contains at least one clinical document, and may contain a number of other related clinical documents. For example, Medical Summaries are clinical documents (already known in the paper world), which often serve the dual purpose of documenting an encounter and providing the rationale for sending the information to another provider. This step utilizes the transactions provided by the ITI XDS profile to place the records in an XDS Repository (local or shared).
2. The Repository ensures that the documents of the submission set are registered with the XDS Registry of the Affinity Domain (set of cooperating care delivery institutions).
3. Notify the other provider that documents are now available for review. This step utilizes the transactions provided by the ITI NAV profile to perform the e-mail notification.
4. The e-mail notification that contains no patient identified information is received by the specialist EMR system.
5. The receiving provider can then utilize existing query transactions from the XDS profile to find the URL of the Documents.
6. Finally, the receiving provider may choose to display the document, or import relevant information from these records into their own EMR system.

Unplanned Access to past Content

In many cases, a provider may need to assess information from the patient care history, and patients may have content in the XDS repository from prior visits to other providers. For example, Medical Summaries, as well as other documents such as laboratory and radiology reports are critical for emergency physicians and nurses to provide the best care to patient in acute conditions. The figure below shows the transactions required for this use case, again, using XDS. Other process flows are possible using XDM and/or XDR.

Unplanned Access Process Flow Diagram

Note that IHE Integration Profiles are not statements of conformance to standards, and IHE is not a certifying body. Users should continue to request that vendors provide statements of their conformance to standards issued by relevant standards bodies, such as HL7 and DICOM. Standards conformance is a prerequisite for vendors adopting IHE Integration Profiles.

Also note that there are critical requirements for any successful integration project that IHE cannot address. Successfully integrating systems still requires a project plan that minimizes disruptions and describes fail-safe strategies, specific and mutually understood performance expectations, well-defined user interface requirements, clearly identified systems limitations, detailed cost objectives, plans for maintenance and support, etc.