Difference between revisions of "PCC TF-1/Overview"

From IHE Wiki
Jump to navigation Jump to search
m
 
 
(2 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
* The IHE actors involved
 
* The IHE actors involved
 
* The specific set of IHE transactions exchanged by each IHE actor.
 
* 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.
 
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.
  
−
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.
+
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/ http://www.ihe.net/Technical_Framework/].
  
−
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.
+
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.
  
−
====Cross-Enterprise Sharing of Medical Summaries (XDS-MS)====
+
[[Image:XDSMSUseCaseProcessFlow.png|center|frame|Use Case Process Flow Diagram]]
−
This profiles provides a mechanism to automate the sharing process between care providers of Medical Summaries.  Medical summaries are a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings.  Medical Summaries are commonly created and consumed by electronic medical record systems at points in time of transfers of care such as referrals or discharge.
 
  
−
Note that this Cross-Enterprise Sharing of Medical Summaries Integration Profile is specialized for regions or countries in term of detailed content of sections and information elements by a set of Document Content Profiles.  This Integration profile has been structured to facilitate the inclusion of national extensions in the form of country or "realm" specific Content Profiles.  When developed by the national IHE Chapters these will be included in the PCC TF-3.
+
These steps are:
  
−
====Exchange of Personal Health Record Content (XPHR)====
+
# 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).
−
This integration profile describes the content and format of summary information extracted from a PHR system used by a patient for import into healthcare provider information systems, and visa versa. The purpose of this profile is to support interoperability between PHR systems used by patients and the information systems used by healthcare providers.
+
# 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).
 +
# 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.
 +
# The e-mail notification that contains no patient identified information is received by the specialist EMR system.
 +
# The receiving provider can then utilize existing query transactions from the XDS profile to find the URL of the Documents.
 +
# Finally, the receiving provider may choose to display the document, or import relevant information from these records into their own EMR system.
  
−
This profile does not address all the data exchange requirements of PHR systems.  A PHR system may leverage other IHE Integration and Content Profiles for interoperability in addition to the XPHR Content Profile.  For example, a PHR Systems may implement XDS-MS to import medical summaries produced by EHR systems, XDS-I to import imaging information, XDS-Lab to import laboratory reports, et cetera.
+
====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.
  
−
====Basic Patient Privacy Consents (BPPC)====
+
[[Image:XDSMSUnplannedAccessUseCaseProcessFlow.png|center|frame|Unplanned Access Process Flow Diagram]]
−
This profile provides a mechanism to record the patient privacy consent(s), a method to mark documents published to XDS with the patient privacy consent that was used to authorize the publication, and a method for XDS Consumers to use to enforce the privacy consent appropriate to the use.
 
−
The XDS profile provides little guidance on supporting privacy policies within an affinity Domain.  Documents can be marked with a confidentialityCode, but no information has been provided on how to use this information to support patient privacy concerns.  This profile corrects that deficiency by describing a mechanism whereby an Affinity Domain can develop and implement multiple privacy policies, and describes how that mechanism can be integrated with the access control mechanisms supported by the XDS Actors (e.g. EHR systems).
 
−
There are three key parts of the profile:
 
−
# It provides a content module for capturing a patient consent to a privacy policy or policies.
 
−
# It describes how the XDS metadata is used to support the consent policies.
 
−
# Finally it describes the method by which XDS Actors can enforce the privacy policies determined by the document confidentialityCode and the patient privacy consents.
 
  
−
====Preprocedure History and Physical (PPHP)====
+
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.
−
This purpose of this content profile is to provide a mechanism to record a pre-procedure assessment, and to communicate that assessment and other relevant documentation, such as laboratory and imaging reports to relevant parties prior to surgery.
 
  
−
====Emergency Department Referral====
+
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.
−
This profile provides a means to communicate medical summary data from an EHR System to an EDIS System during a referral from a provider to an emergency department.
 

Latest revision as of 00:31, 24 July 2007

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.

Retrieved from "http://wiki.ihe.net/index.php?title=PCC_TF-1/Overview&oldid=8152"