PCC TF-1/CM

Volume 1

HIMSS and RSNA
Integrating the Healthcare Enterprise

IHE Patient Care Coordination

Care Management (CM)
Technical Framework Supplement
Volume I

Revision 3.0
2008-2009

Public Comment

• (PCC TF-1/Preface)Preface to Volume I of the PCC Technical Framework

• (PCC TF-1/Introduction)Introduction to the PCC Technical Framework

• (PCC TF-1/About)About the Patient Care Coordination Integration Profiles

• (PCC TF-1/Dependencies)Dependencies of the PCC Integration Profiles

• (PCC TF-1/Overview)PCC Integration Profiles Overview

• (PCC TF-1/History)History of Annual Changes

• (PCC TF-1/Product Implementations)Product Implementations

Care Management (CM)

This is a draft of the Care Management Profile (CM) supplement to the PCC Technical Framework. This draft is a work in progress, not the official supplement or profile.

Profile Abstract

The Care Management Profile (CM) provides a mechanism for EHR and other HIT systems to communicate information to Care Management systems in support of specialized care programs through the use of evidence based guidelines.

Issue Log

Open Issues

1. In the case of HL7 V2 transactions, how does one indicate where the response goes, since it is not a normal HL7 V3 response?
2. How well does volumne I explain the concept of the guideline based care orientation of this profile? Is there more it could do?
3. Should the the guideline or parts of it be folded into the TF as individual "content" components referenced by the transaction, or kept in-line in the transaction as is done now?
4. How does the Clinical Data Source check for consent to share data as part of its responsibilities? How is this reflected in the actor groupings in Volume I, and in the transaction details in volume II.
5. We will need an example or two for PCC-7. I propose developing one using SNOMED, LOINC, RxNORM, and CPT codes to show how a diabetes chronic disease implementation would work, using an international guideline. Are there others more appropriate that would have "more" impact?

Closed Issues

1. Is PCC-9 really a "query" transaction with a delayed response, or a notification transaction? The former has the advantage that it has an actor to respond to built in, whereas the latter does not. In the latter case, how would one indicate where to send the response to?
   • PCC-9 is uses the HL7 V3 Query transactions.

Volume I

Add the following bullet to the list of profiles

• Care Management - The Care Management Profile provides a mechanism for EHR and other HIT systems to communicate information to Care Management systems in support of specialized care programs through the use of evidence based guidelines.

Dependencies

Add the following row(s) to the list of dependencies

Integration Profile	Dependency	Dependency Type	Purpose
Care Management	CT	Implementors of the Care Management profile must implement the Time Client Actor of the CT profile.	Ensures that messages sent to the Care Management use concistent time reporting.
Care Management	ATNA	Implementors of the Care Management profile must implement the Secure Node or Secure Application actor of the ATNA profile.	Ensures that transmissions and changes to patient health information are logged in an audit repository, and that communication is secured between nodes.

Overview

The Care Management Profile (CM) supports the exchange of information between HIT systems and applications used to manage care for specific conditions. Examples of these systems include Cancer Registries, Chronic Disease Management Systems, Disease Registries and Immunization Information Systems.

The collection of this data from health care IT applications can improve outcomes by supporting health management, substantially reducing health care costs. More and more, special purpose care management systems are used to support wellness programs, public health monitoring including tracking immunizations and infectious diseases, and to manage the care of patients with chronic diseases such as diabetes and cancer.

These systems often include decision support capabilities, using evidence-based guidelines for the treatment and care of patients. They often use ad-hoc data gathering to collect information from many different sources to populate data repositories, which are then used to support and manage care for different patient populations. Information is provided to these systems from a number of sources, including:

• Physician Offices
• Imaging Centers
• Laboratories
• Surgery Centers
• Inpatient Settings
• Insurance Providers

In order to manage patient care using these systems, numerous data points are routinely gathered. The data gathered varies based upon the condition being managed and may include:

• Current and Past Medical History
• Family History and other Risk Factors (commonly called Social History)
• Medications (Current and prior)
• Allergies and Adverse Reactions
• Vital Signs and other common observations
• Laboratory and Diagnostic Study Results
• Immunizations
• Health Visits (planned and prior)
• Procedures
• Surgical History

Current practice involves the creation of ad hoc interfaces to pass this information from each health care application to the care management system. Given the large number of applications and conditions which are managed in this fashion, it is not practical or cost effective to design one-off interfaces for each combination that needs to communicate with care management systems. Thus, there is a need for a method to easily and automatically configure health care IT systems to transmit this data, either on an ad hoc or a scheduled basis, and to automate the transmission of this information to these systems.

One goal of this profile is to systematically define the data gathering requirements of these systems in a way that supports existing and future deployments. If the data requirements are specified in sufficient detail, and presented to the receiving applications in an electronic format, then the receiving applications can automatically determine what information to report and when.

Scope

A guideline based approach to Care Management can address the overall coordination of patient care as described below.

1. Care providers define a protocol for disease management.
   • Specialist groups, using an evidence based approach, define a current “best practice” protocol for management of the disease, including all of the assessments, treatments and medications that define high quality care.
2. Patients are identified for potential enrollment in a disease management program.
   • Patients are seen by a clinician during a routine visit. The clinician may order tests to be performed to evaluate the patient for enrollment in the program.
   • Alternative: Patient consent is obtained for evaluation. Said consent may include consent to participate in an electronic health record, consent for use of personal health information for clinical care, consent for disclosure of information for clinical care, and consent for disclosure of data for secondary use (eg. registries, research, public health tracking)
3. Patient demographics and clinical data is collected for evaluation.
   • Patient data necessary to make a decision on patient suitability for enrollment, as defined by the disease management protocol, is gathered for consideration.
   • Alternative: Patient demographics and a sub-set of initial data may be transferred from the patient’s Personal Health Record.
4. Patients are identified for enrollment.
   • Patients fitting the requirements for enrollment in the care management program are identified, either through manual study or automatically through clinical decision support tools
5. Patients are enrolled in a disease management program.
   • Clinician may recommend remote monitoring, which is discussed with the patient. This may involve notifying a care coordinator within the clinicians office or elsewhere to initiate the remote monitoring process with the patient or caregiver.
   • Alternative: Patient consent is obtained for enrollment. Consent is as described above.
   • Alternative: Patient may enroll themselves in a disease management program, possibly including self monitoring. The disease monitoring program notifies the clinician that the patient has been enrolled in the care program. The patient may acquire a monitoring device with the ability to send the data to a PHR, or other method of information exchange. This may include a mechanism to send self monitoring data to clinician EHRs.
6. Disease management data for the patient is gathered from health care IT systems during routine patient care.
   • Clinician performs set-up required to accept remote monitoring information transferred to the EHR, including necessary establishment of authentication and authorization.
   • Alternative: Patient uses self monitoring device to obtain data. Some devices may be set up to take measurements on a predefined schedule and may require no action by the patient. Clinician receives notification of patient request to send self monitoring information to the EHR. The clinician may accept or deny transmission of self monitoring data, depending upon whether said information is relevant to the care plan.
7. Additional data is gathered on patients based on information in the disease management protocol.
   • The remote monitoring information may be displayed in the clinician’s EHR for review. The clinician is able to determine the source of the measurement data (e.g. clinic, lab or home monitoring), the date/time of the measurement, any supporting data.
   • Alternative:The information communicated to the clinician’s EHR may include all measurements, or a sub-set of measurements (eg. a medical summary).
   • Alternative: The information may be an excerpted set of measurements identified for review by a care coordinator. If the remote monitoring information was reviewed by a care coordinator, the information received in the EHR may contain assessment information such as a summary of the care coordinator’s findings/recommendations, summary of interactions with the patient, or specific items for the clinician to consider, etc.
   • Alternative: The remote monitoring information communicated to the EHR includes data that may or may not be utilized by decision support to alert the clinician. Alert information may be generated by the device, data intermediary or information exchange and may be communicated to the clinician’s EHR.
8. Decision support systems can monitor changes to information provided during health care activities, and recommend actions to support the care of the patient.
   • The clinician or decision support system may recommend a follow-up office visit, urgent care, or a discussion with the patient about following the recommended care plan (e.g. medications, diet, activity). The clinician may order tests if appropriate.
   • The clinician may need to modify the patient’s care plan based upon information received and evaluation of the patient.
   • The modified care plan and recommendations may be electronically accessed by the patient. The patient implements the updated treatment plan. Remote monitoring may continue as directed by care providers. The modified plan may also need to be communicated to other providers or care coordinators.
   • Changes to care plan and patient data are fed back to the organization defining disease protocol for continuing research and refinement of protocols.

Figure 1. Process Flow for Guideling Notification and Care Data Query

The complete use case for Care Management is extensive and very complex. It has been necessary to limit the scope for this years development to a small subset of the desired functionality. The focus for this year is:

1. The definition and communication of the data variables needed to support guideline oriented care.
2. The exchange of this information to and from health care IT systems.
3. Association of guidelines used for care with patients needing care under those guidelines, through a query mechanism.
4. Communication of information from the patient record meeting the guideline criteria to the system used to manage the care for a specific condition or conditions
5. Support for communications using traditional HL7 Version 2 messaging, and HL7 Version 3 messages over web services.

It is hoped that future work by IHE Patient Care Coordination will expand this functionality to provide further transactions covering:

1. Use of decision support to locate patients that qualify for care management programs.
2. Administrative activities involving the enrollment of patients in care management programs.
3. Use of decision support to activate workflow in care management programs and support clinical decision making.
4. Communication of guidelines in electronic format to support clinical decision support.
5. Use of aggregated data collected by the care management programs to inform the revision of care guidelines.

The present level of support for guideline definition in this profile is sufficient to identify the variables needed for decision support to the care management system and its sources of clinical data, but is not intended to convey the complete guideline definition.

IHE Patient Care Coordination will continue to work with relevant standards organizations with respect to the development of appropriate standards in the areas of guideline definition and clinical decision support to enable these future activities.

Diabetes Patient Care Management Example

The story begins when Mabel Jones visits her Primary Care Practitioner (PCP) , Dr. Martin, and is diagnosed as having Type II Diabetes mellitus. He counsels her about lifestyle changes, and refers her to the diabetes clinic in the local hospital.

A week later, Mabel is seen at the diabetes clinic. The diabetes clinic that she is referred to has a Care Management System, which provides a care plan for the patient and monitors their progress, both through home monitoring and through continuing routine visits with the clinic and her PCP. The clinic has a working relationship with a National Diabetes Association, which publishes updated treatment guidelines twice yearly, and makes them available electronically, ensuring that their subscribers are always providing care in accordance with the latest recommendations. (Step 1 and 2 in Figure 1. above)

She is assessed by an internist and meets with a registered nurse, dietician and pharmacist, who enroll her in their program, and a care plan is created for her, using the association's guidelines, which specifies all of the medical tests, medications and recommended follow-up appointments recommended for care of her condition. Her care plan includes blood glucose measurements four times daily, as well as a regimen of oral drugs, so Mabel is supplied with a home monitoring system with a blood glucose monitor, and a prescription for glipizide. When her enrollment is completed, a query for relevant results is sent from the Care Management System to the EMR at her PCPs office, the HIS at the hospital, and the LIS at the local lab, and her home monitoring system. (Step 3 and 4 in Figure 1. above)

Six months pass and Mabel is fairly compliant with her diabetes management. Mabel checks her sugars daily and puts the results in her home monitoring system. She has purchased additional equipment and is now able to do the same for her blood pressure and weight. These measurements, as well as the results from the followup appointments she has had with her PCP, have been sent to the Care Management System (Step 5 in Figure 1. above), which has been monitoring her status. The Care Management Systems clinical decision support software initially detected the fact that her blood glucose levels were not being optimally controlled and suggested adjustments to her medications, which were accepted by the specialist and Mabel’s prescription changed. Soon her measurements were within the acceptable range.

At her next appointment with her PCP, Mabel’s standard physical exam reveals that she is pregnant. The results of this test are also sent to the Care Management System (Step 6 in Figure 1. above) and the clinical decision support rules indicate the need for an appointment with a perinatologist and an opthamologist, a change in medication from oral to insulin injections, and bi-weekly urine ketone tests, which she arranges to have done at her local lab. The Care Management System sends out an updated query, requesting the results of these tests. The test results are returned to the Care Management System as they are completed and, with continual monitoring keeping her diabetes under control, Mabel has an uneventful and healthy pregnancy.

Figure 2. Care Management Architecture Overview

Several existing IHE Profiles support the communication of information collected and produced by a care management system. Rather than reproduce these actors and transactions in this profile, we have simply referenced the uses of these profiles in the Grouping section below. }}

Use Cases

In the uses cases below, we describe the before and after effects of implementing the Care Management profile.

Before Care Management

Preconditions

A Care Management protocol is defined.

Use Case

1. Using the defined care management protocol, a set of data variables are collected in report form.
2. A Clinical Analyst reviews the data variables with the protocol designers, to establish criteria and mappings from health care information sources.
3. An interface engineer creates appropriate interface messages and integrates them with the HIT application.
4. Patients are somehow enrolled in the program
5. When a health care application updates information from a patient, and that patient is determined to be enrolled with the appropriate care management program, one or more messages are sent to the care management system from the HIT application containing information specific to that program.

Postconditions

The Care management system is supported by one HIT system.

Repeat at step 2 above for the next HIT system.

When you've done one interface, you've done one interface.

After Care Management

Precondition

A care management protocol is defined by clinical experts.

Use Case

1. Using the defined care management guideline, a set of data variables are defined in an electronic format using established vocabularies and defined units and measures, in conjunction with clinical analysts and informatics experts. This electronic format is stored in a Guideline management system, and reported to the care management system.
2. Data variables used for care management are allocated automatically by care management systems reading the electronic specification.
3. Care management systems enable reporting for enrolled patients by issuing queries to the clinical data sources reporting the guideline being used.
   • [Option] Reporting is enabled for a patient by an "out-of-band" communication not specified in this profile.
4. Clinical Data Sources configure the outbound interfaces for reporting the data variables by locating the guideline definition, and reading the electronic specification of the data variables needed from it.
   • [Option] The Clinical Data Source is configured to handle the reporting of data using traditional interfacing methods, and uses the query to simply indicate which preconfigured interface to use.
5. When a health care application updates information from a patient, and that patient is determined to be enrolled with the appropriate care management program, one or more messages are sent to the care management system from the HIT application containing information specific to that program.

Postcondition

The care mangement system is updated with patient data from multiple clinical data sources.

Note:

While enrollment is out of scope for this profile, the "enrollment" of a patient in a program can be enabled in the Clinical Data Source by reciept of the query specified in step 3 above.

Actors/Transaction

The diagram below shows the actors of the Care Management profile.

The Guideline Manager keeps track of guidelines and responds to requests for information about guidelines using PCC-8. When new guidelines are received, or existing guidelines are updated, it notifies the Care Manager actor using PCC-7.

The Care Manager is responsible for receiving notifications of new or updated guidelines using PCC-8. Upon receipt of these guidelines, it can analyze them in detail, and then, using PCC-9, issues queries to various Clinical Data Sources.

The Clinical Data Sources will then pass back information to the Care Manager, using either PCC-10 or PCC-11, enabling the Care Manager to evaluate next steps for the management of the patients' condition(s).

Care Management Actor Diagram

Care Management Actors and Transactions

Actor	Transaction	Opt.	Section
Guideline Manager	Guideline Notification	R	PCC-7
	Request Guideline Data	R	PCC-8
Care Manager	Guideline Notification	O	PCC-7
	Request Guideline Data	O	PCC-8
	Care Management Data Query	R	PCC-9
	V3 Care Management Update	R	PCC-10
	V2 Care Management Update	R	PCC-11
Clinical Data Source	Request Guideline Data	O	PCC-8
	Care Management Data Query	CSee note 2	PCC-9
	V3 Care Management Update	C See note 1	PCC-10
	V2 Care Management Update	C See note 1	PCC-11

Note 1

At least one of these transactions must be supported.

Note 2

A Clinical Data source that implements the Care Record option shall implement this transaction.

Options

Care Management Options

Actor	Option
Clinical Data Source	Care Record Option
	HL7 Version 2 Option
Care Manager	Guideline Management Option

Care Record Option

A Clinical Data Source Actor that implements the Care Record Option sends updates to the Clinical Data Manager using PCC-10, and must also support receipt of PCC-9.

HL7 Version 2 Option

A Clinical Data Source Actor that implements the HL7 Version 2 option sends updates to the Clinical Data Manager using PCC-11.

Guideline Management Option

A Care Manager that implements the Care Manager Option supports the receipt of PCC-7 transaction.

Grouping

ATNA and CT

The actors of this profile must implement the ATNA Secure Node or Secure Application Actor, and the CT Time Client Actor. Specific details on the logging requirements are given for each transaction in volume II.

QED

The Care Manager may be grouped with the Clinical Data Source actors of the QED profile to facilitate communication of care management trends or other information to PHR or EHR systems.

XDS

The Care Manager may be grouped with the Document Source actor of the XDS profile to facilitate communication of care summaries from the Care Management system to an XDS Repository, for subsequent access by a Care Provider or the patient.

Analyzer / Aggregator

The the Care Manager actor may be grouped with Analyzer / Aggregator actor of the PEQD profile to support aggregation of quality reporting data to measure conformance to evidence-based guidelines.

BPPC

The Clinical Data Source actor may be grouped with the Content Consumer Actor of the BPPC profile to obtain information about consents to share data.

Coded Terminologies

This profile supports the capability to record entries beyond the IHE required coding associated with structured data. Actors from this profile may choose to utilize coded data, but interoperability at this level requires an agreement between the communicating parties that is beyond the scope of this Profile.

To facilitate this level of interoperability, the applications that implement actors within this profile shall provide a link to their HL7 conformance profile within their IHE Integration statement. The conformance profile describes the structure of the information which they are capable of creating or consuming. The conformance profile shall state which templates are supported by the application implementing the profile Actors, and which vocabularies and/or data types are used within those templates. It should also indicate the optional components of the entry that are supported.

An Example HL7 Conformance Profile is available to show how to construct such a statement. See the HL7 Refinement Constraint and Localization for more details on HL7 conformance profiles.

Process Flow

Care Management Process Flow

1. A guideline is defined and activated in the Guideline Manager. The set of data variables are communicated in electronic format to the Care Management System.
2. The Care Manager sends a query for the clinical data identified by the guideline to Clinical Data Source 1 and Clinical Data Source 2.
3. Clinical Data Source 1 is configured out of band to respond appropriately to the query identified by the guideline manager.
4. Clinical Data Source 2 queries the Care Manager for the Guideline identified in the query, and configures itself to respond appropriately based on the data variables identified in the guideline.
5. Upon updating applicable patient data, Clinical Data Source 1 sends an HL7 Version 2 message specified by the guideline to the Care Manager.
6. Upon updating applicable patient data, Clinical Data Source 2 sends an HL7 Version 3 Care Record Update to the Care Manager, based on the configuration computed in step 4.

Resources and References

[1] American College of Physicians Diabetes Portal, 2000-2008, American College of Physicians

[2] Priority Areas for National Action, Transforming Healthcare Quality, 2003, Institute of Medicine

[3] Using Computerised Registries in Chronic Disease Care, February 2004, California HealthCare Foundation

[4] Global Guideline for Type 2 Diabetes, 2005, International Diabetes Federation, ISBN 2-930229-43-8

Actor Definitions

Guideline Manager

The guideline manager actor is responsible for managing the guidelines used to create care plans, and for communicating those guidelines to other systems.

Care Manager

The care manager actor is responsible for supporting the management of the care of patients with respect to a specific health condition. It gathers information about the care provided and current health status of the patient. A Care Manager actor may be designed for management of a single condition, such as management of Diabetes, or may be a general purpose system supporting management of multiple conditions.

Clinical Data Source

The clinical data source actor is responsible for gathering and supplying information about the care provided and current health status of patient.

Transaction Definitions

Guideline Notification

The Guideline Notification transaction reports a the content of new and/or updated guidelines to interested parties. The purpose of this transaction is to alert systems that need to act on clinical guidelines of the availability of new guidelines.

Request Guideline Data

The Request Guideline Data transaction supports the capability of systems to query for the contents of an identified guideline.

Care Management Data Query

The Care Management Data Query transaction supports the capability for systems responsible for monitoring the health status and care provided to one or more patients to request that information from systems that may have it.

V3 Care Management Update

The V3 Care Management Update transaction supports the capability for systems that have information about the health status and care provided to one or more patients to share that information with external systems that need to monitor that information using profiles of HL7 V3 Care Record standard messages.

V2 Care Management Update

The Care Management Updagte transaction supports the capability for systems that have information about the health status and care provided to one or more patients to share that information with external systems that need to monitor that information using specific profiles of HL7 V2 standard messages.

Appendix A - Actor Descriptions

Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise.

Content Creator

The Content Creator Actor is responsible for the creation of content and transmission to a Content Consumer.

Content Consumer

A Content Consumer Actor is responsible for viewing, import, or other processing of content created by a Content Creator Actor.

Clinical Data Consumer

A clinical data consumer makes use of clinical patient data.

Clinical Data Source

A Clinical Data Sources maintains patient information about vital signs, problem and allergies, results from diagnostic tests (e.g., Lab, Imaging, or other test results), medications, immunizations or historical or planned visits and procedures.

Appendix B - Transaction Descriptions

Transactions are interactions between actors that transfer the required information through standards-based messages. The PCC Technical Framework does not define any specific transactions, as these are assumed to be carried out through the use of transactions defined in other IHE Profiles.

Query Existing Data

Request information about recent patient information, used to obtain vital signs measurements, problems and allergies, diagnostic results, medications, immunizations, or procedures or visits relevant for a patient. The query may request information about some or all of the above topics, or may request information on a specific topic, or one entered for a specific encounter or date range.

Appendix C - How to Prepare an IHE Integration Statement

IHE Integration Statements are documents prepared and published by vendors to describe the conformance of their products with the IHE Technical Framework. They identify the specific IHE capabilities a given product supports in terms of IHE actors and integration profiles described in the technical frameworks of each domain.

Users familiar with these concepts can use Integration Statements to determine what level of integration a vendor asserts a product supports with complementary systems and what clinical and operational benefits such integration might provide. Integration Statements are intended to be used in conjunction with statements of conformance to specific standards (e.g., HL7, IETF, DICOM, W3C, etc.).

IHE provides a process for vendors to test their implementations of IHE actors and integration profiles. The IHE testing process, culminating in a multi-party interactive testing event called the Connectathon, provides vendors with valuable feedback and provides a baseline indication of the conformance of their implementations. The process is not intended to independently evaluate, or ensure, product compliance. In publishing the results of the Connectathon and facilitating access to vendors' IHE Integration Statements, IHE and its sponsoring organizations are in no way attesting to the accuracy or validity of any vendor's IHE Integration Statements or any other claims by vendors regarding their products.

IMPORTANT -- PLEASE NOTE: Vendors have sole responsibility for the accuracy and validity of their IHE Integration Statements. Vendors' Integration Statements are made available through IHE simply for consideration by parties seeking information about the integration capabilities of particular products. IHE and its sponsoring organizations have not evaluated or approved any IHE Integration Statement or any related product, and IHE and its sponsoring organizations shall have no liability or responsibility to any party for any claims or damages, whether direct, indirect, incidental or consequential, including but not limited to business interruption and loss of revenue, arising from any use of, or reliance upon, any IHE Integration Statement.

Structure and Content of an IHE Integration Statement

An IHE Integration Statement for a product shall include:

1. The Vendor Name
2. The Product Name (as used in the commercial context) to which the IHE Integration Statement applies.
3. The Product Version to which the IHE Integration Statement applies.
4. A publication date and optionally a revision designation for the IHE Integration Statement.
5. The following statement: "This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles, Actors and Options listed below:"
6. A list of IHE Integration Profiles supported by the product and, for each Integration Profile, a list of IHE Actors supported. For each integration profile/actor combination, one or more of the options defined in the IHE Technical Framework may also be stated. Profiles, Actors and Options shall use the names defined by the IHE Technical Framework Volume I. (Note: The vendor may also elect to indicate the version number of the Technical Framework referenced for each Integration Profile.)

Note that implementation of the integration profile implies implementation of all required transactions for an actor as well as selected options.

The statement shall also include references and/or internet links to the following information:

1. Specific internet address (or universal resource locator [URL]) where the vendor's Integration Statements are posted
2. URL where the vendor's standards conformance statements (e.g., HL7, DICOM, etc.) relevant to the IHE transactions implemented by the product are posted.
3. URL of the IHE Initiative's web page for general IHE information www.himss.org/ihe.

An IHE Integration Statement is not intended to promote or advertise aspects of a product not directly related to its implementation of IHE capabilities.

Format of an IHE Integration Statement

Each Integration Statement shall follow the format shown below. Vendors may add a cover page and any necessary additional information in accordance with their product documentation policies.

IHE Integration Statement	Date	12 Oct 2005
Vendor	Product Name	Version
Any Medical Systems Co.	IntegrateRecord	V2.3
This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles, Actors and Options listed below:
Integration Profiles Implemented	Actors Implemented	Options Implemented
Cross-Enterprise Sharing of Medical Summaries	Document Consumer	View Option
Audit Trail and Node Authentication	Secure Node	none
Patient Identity Cross-referencing	Patient Identifier Cross-reference Consumer	PIX Update Notification
Internet address for vendor's IHE information:www.anymedicalsystemsco.com/ihe
Links to Standards Conformance Statements for the Implementation
HL7	www.anymedicalsystemsco.com/hl7
Links to general information on IHE
In North America: www.ihe.het	In Europe: www.ihe-europe.org	In Japan: www.jira-net.or.jp/ihe-j

IHE Integration Statement template

An IHE Integration Statement template (MS Word version) is available here.

The IHE Product Registry

The assumption of an integration statement is that all actors listed are functionally grouped and conform to any profile specifications for such groupings. In case of exceptions the vendor must explicitly describe the functional groupings.

IHE has developed a new Web-based database of Integration Statements. The IHE Product Registry enables developers to create, manage and publish Integration Statements for their commercial and open source healthcare IT systems. It allows users to browse for these systems based on their conformance with specific IHE Actors and Profiles. The system is open for use by developers and users now!

Appendix D - Braden Scale for Predicting Pressure Sore Risk

See File:Braden.pdf

Glossary

The following terms are used in various places within this technical framework, and are defined below. The complete IHE Glossary is available on the IHE Wiki at http://wiki.ihe.net/index.php/IHE_Glossary .

Actor

An entity within a use case diagram that can perform an action within a use case diagram. Possible actions are creation or consumption of a message

Acuity Assessment

Also known as triage category, this is the acuity of the patient assigned during the process of ED triage. A number of evidenced based triage scales exist, including the Emergency Severity Index (ESI), Canadian Triage and Acuity Scale (CTAS), the Australasian Triage Scale (ATS), and the Manchester Triage System. In many emergency departments, patients may simply be classified as emergent, urgent or non-urgent.

ADT

Admit, Discharge & Transfer.

Affinity Domain Policy

Affinity Domain Policy that clearly defines the appropriate uses of the XDS Affinity Domain. Within this policy is a defined set of acceptable use Privacy Consent Policies that are published and understood.

ASTM

Formerly the American Society of Testing and Materials, now ASTM International. An SDO that develops a number of standards across a wide variety of industries, including healthcare.

ATNA

Audit Trail and Node Authentication. An IHE ITI profile.

Care Context

The participations surrounding the care provision act, and the attributes of that act. Everything in the document header. Data history, links to clinical reasoning.

Continuity of Care Document(CCD)

An HL7 Clinical Document Architecture (CDA) implementation alternative to ASTM ADJE2369 for institutions or organizations committed to HL7 standards. This specification was developed as a collaborative effort between ASTM and HL7. More information is available from http://www.hl7.org.

Continuity of Care Record (CCR)

A core data set of the most relevant administrative, demographic, and clinical information facts about a patient’s healthcare, covering one or more encounters. The CCR is Designation E2369-05 of the ASTM (American Society for Testing and Materials, International). More information is available from http://www.astm.org.

Clinical Document Architecture (CDA)

An HL7 standard for the exchange for clinical documents. It specifies the structure and semantics of clinical documents. More information is available from http://www.hl7.org.

Content Binding

A content binding describes how the payload used in an IHE transaction is related to and/or constrained by the data elements contained within the content sent or received in those transactions.

CRS

Care Record Summary. An implementation guide that constrains CDA Release 2 for Care Record Summary documents.

CT

Consistent Time Integration Profile.

DICOM

Digital Imaging and Communication in Medicine

DSG

Digital Signatures. An IHE ITI Profile.

EDIS

An Emergency Department Information System (EDIS) is an extended EHR system used to manage data in support of Emergency Department patient care and operations. The functions of an EDIS may be provided by a single application or multiple applications.

eMPI

Enterprise Master Patient Index.

EMR

Electronic Medical Record, an Electronic Health Record system used within an enterprise to deliver care (also called EHR-CR by IHE-XDS).

Estimated Time of Arrival

the time the patient being referred can be expected to arrive in the emergency department.

EUA

Enterprise User Authentication Integration Profile.

Expected Actions

Actions which should occur as the result of a trigger event.

HIMSS

Healthcare Information and Management Systems Society.

HL7

Health Level Seven

HIS

Hospital Information System.

IHE

Integrating the Healthcare Enterprise.

Interaction Diagram

A diagram that depicts data flow and sequencing of events.

IT

Information Technology.

Logical Observation Identifiers Names and Codes (LOINC®)

A vocabulary developed by the Regenstrief Institute aimed at standardizing laboratory and clinical codes for use in clinical care, outcomes management, and research. Additional information found at http://www.regenstrief.org/medinformatics/loinc/.

Mode of Arrival

The method of transportation used to transport the patient to the Emergency Department.

MPI

Master Patient Index.

MRN

Medical Record Number.

NAV

Notification of Document Availability

OID

Object Identifier. (See also 'Globally Unique Identifier').

Patient Identifier Cross-reference Domain

Consists of a set of Patient Identifier Domains known and managed by a Patient Identifier Cross-reference Manager Actor. The Patient Identifier Cross-reference Manager Actor is responsible for providing lists of "alias" identifiers from different Patient Identifier Domains.

Patient Identifier Domain

A single system or a set of interconnected systems that all share a common identification scheme for patients. Such a scheme includes: (1) a single identifier-issuing authority, (2) an assignment process of an identifier to a patient, (3) a permanent record of issued patient identifiers with associated traits, and (4) a maintenance process over time. The goal of Patient Identification is to reduce errors.

PDF

Portable Document Format.

PIX

Patient Identifier Cross Referencing. An IHE ITI Profile.

PDQ

Patient Demographics Query. An IHE ITI Profile.

PHR

Personal Health Record

Procedure

In the context of a "Pre-procedure History and Physical," the "procedure" is a surgery or an invasive examination of a patient that is required by quality review organizations to be preceded by a pre-procedure assessment of procedure risk and anesthesia risk. This assessment is typically referred to as a "Pre-operative" or "Pre-procedure History and Physical."

Process Flow Diagram

A graphical illustration of the flow of processes and interactions among the actors involved in a particular example.

Proposed disposition

the intended disposition (i.e. admission to ICU, discharge to home, transfer to psychiatric hospital), if known, that the referring provider expects the patient will end up after the emergency department intervention.

Referral Source

An individual, group, or agency that determined the patient should seek care at the ED. Referral source may be used to determine appropriate discharge referrals and services, or to provide surveillance data for program and service planning, or to examine referral patterns.

Role

The actions of an actor in a use case.

RSNA

Radiological Society of North America.

sig.

A Latin abbreviation for signetur used to represent the instruction following the medication name.

Scope

A brief description of the transaction.

SNOMED-CT® A comprehensive clinical terminology, originally created by the College of American Pathologists (CAP) and, as of April 2007, owned, maintained, and distributed by the International Health Terminology Standards Development Organisation (IHTSDO), a non-for-profit association in Denmark. The CAP continues to support SNOMED CT operations under contract to the IHTSDO and provides SNOMED-related products and services as a licensee of the terminology. More information available from http://www.ihtsdo.org/ or the United States National Library of Medicine at http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html

Transport Mode

the method the patient employs, or is provided to get to the emergency department.

Trigger Event

An event such as the reception of a message or completion of a process, which causes another action to occur.

UID

Unique Identifier (See also Globally Unique Identifier).

Universal ID

Unique identifier over time within the UID type. Each UID must belong to one of specifically enumerated species. Universal ID must follow syntactic rules of its scheme.

Use Case

A graphical depiction of the actors and operation of a system.

XUA

Cross Enterprise User Authentication

XDS

Cross Enterprise Document Sharing

Volume 2

HIMSS and RSNA
Integrating the Healthcare Enterprise

IHE Patient Care Coordination

Care Management (CM)
Technical Framework Supplement
Volume II

Revision 3.0
2008-2009

Public Comment

• (PCC TF-2/Preface)Preface

• (PCC TF-2/Introduction)Introduction

IHE Transactions

This section defines each IHE transaction in detail, specifying the standards used, and the information transferred.

Guideline Notification

This section corresponds to Transaction PCC-7 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-7 is used by the Guideline Manager and Care Manager Actors.

Use Case Roles

Guideline Manager		Care Manager
Guideline Notification

Actor

Guideline Manager

Role

Notifies the Care Manager of new and/or updated guidelines for care

Cooresponding HL7 Version 3 Application Roles

Care Provision Informer (REPC_AR004010UV)

Actor

Care Manager

Role

Recieves notification of new and/or updated guidelines for care

Cooresponding HL7 Version 3 Application Roles

Care Provision Tracker (REPC_AR004020UV)

Note:

Implementors of a Guideline Manager Actor, or a Clinical Data Source Actor shall publish an HL7 Conformance Profile that indicates the vocabularies and code sets that they support for this transaction.

Referenced Standards

CareRecord	HL7 Care Provision Care Record (DSTU)
HL7QI	HL7 Version 3 Standard: Infrastructure Management – Query Infrastrucure
HL7WS	HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release
SOAP	Simple Object Access Protocol Version 1.1 (SOAP 1.1)
SOAP12	Simple Object Access Protocol Version 1.2 (SOAP 1.2)

Interaction Diagrams

Guideline Notification

Trigger Events

When a new or updated guideline is released, the Guideline Manager uses this transaction to notify the Care Manager of the new and/or updated guideline. This cooresponds to the HL7 trigger events:

• Activate Care Provision (REPC_TE004110UV)
• Replace Care Provision (REPC_TE004913UV)

Message Semantics

This interaction cooresponds to the HL7 Interactions:

• Activate Care Provision (REPC_IN004110UV) {Schema: [5]}
• Replace Care Provision (REPC_IN004913UV) {Schema: [6]}

The schema for these interactions can be found at the links above, and include:

• the transmission wrapper MCCI_MT000100UV01,
• the control act wrapper MCAI_MT700201UV01, and
• the message payload REPC_MT004000UV.

These components of the interaction are specified in the HL7 standards described above.

Transmission Wrapper

The transmission wrapper MCCI_MT000100UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<REPC_IN004110UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='REPC_IN004110UV|REPC_IN004913UV' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='AL'/>
 <receiver typeCode="RCV">
   <device classCode="DEV" determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device classCode="DEV" determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess classCode="CACT" moodCode="EVN">
  See Control Act Wrapper below
 </controlActProcess>
</REPC_IN004110UV>

<REPC_IN004110UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

To indicate that this interaction is notification of activation of a guideline, the element shall be named: REPC_IN004110UV To indicate that this interaction is notification of replacement of a guideline, the element shall be named: REPC_IN004913UV

 <rule context='/'>
   <assert test='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
     The root element of a PCC-7 transaction shall be REPC_IN004110UV or REPC_IN004913UV from the HL7 namespace (urn:hl7-org:v3).
   </assert>
 </rule>

<interactionId extension='REPC_IN004110UV|REPC_IN004913UV' root='2.16.840.1.113883.5'/>

The identifer for the interaction shall be sent using either the value REPC_IN004110UV or REPC_IN004913UV depending upon whether this interaction describes activation or replacement respectively. This value must be the same as the name of the interaction element being sent.

 <rule context='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
   <assert test='hl7:interactionId/@extension = local-name()'>
     The interaction of a PCC-7 transaction shall be REPC_IN004110UV or REPC_IN004913UV and shall coorespond to the interaction being used in the message.
   </assert>
 </rule>

<processingModeCode code='T'/>

The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.

 <rule context='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
   <assert test='hl7:processingModeCode/@code = "T"'>
     The processingModeCode shall use the code value "T" for this message.
   </assert>
 </rule>

<acceptAckCode code='AL'/>

The acceptAckCode indicates whether the sender wants to recieve an acknowledgement, and shall be sent as shown above.

 <rule context='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
   <assert test='hl7:acceptAckCode/@code = "AL"'>
     The acceptAckCode shall use the code "AL" to indicate that the reciever must always acknowledge the message. 
   </assert>
 </rule>

Control Act Wrapper

The control act wrapper MCAI_MT700201UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O.

An example control act wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<controlActProcess classCode="CACT" moodCode="EVN">
  <id root=' ' extension=' '/>
  
  <effectiveTime><low value=' '/><high value=' '/></effectiveTime>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  <subject typeCode='SUBJ' contextConductionInd='false'>
  </subject>
</controlActProcess>

<controlActProcess classCode="CACT" moodCode="EVN">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "EVN" by the sender to indicate notification of a guideline activation or change event.

 <rule context='//hl7:controlActProcess'>
   <assert test='@classCode="CACT"'>
     The controlActProcess of a PCC-7 transaction shall have classCode="CACT".
   </assert>
   <assert test='@moodCode="EVN"'>
     The controlActProcess of a PCC-7 transaction shall have moodCode="EVN".
   </assert>
 </rule>

The trigger event which caused the act to be transmitted is recorded in the code element is recorded. The value of the code attribute shall be REPC_TE004110UV to record an activation event, or REPC_TE004913UV to record a replacement. The code attribute shall coorespond to the correct interaction.

 <rule context='//hl7:controlActProcess'>
   <assert test='hl7:code'>
     The code element shall be present in a PCC-7 transaction.
   </assert>
 </rule>
 <rule context='//hl7:controlActProcess/hl7:code'>
   <assert test='(@code="REPC_TE004110UV" or @code="REPC_TE004913UV) and substring(@code,8,8) = substring(local-name(/),8,8)"'>
     The trigger event in a PCC-7 transaction shall be REPC_TE004110UV or REPC_TE004913UV, and shall coorespond to the interaction.
   </assert>
 </rule>

<effectiveTime><low value=' '/><high value=' '/></effectiveTime>

The effectiveTime element shall be present. The low component shall be present and indicates the effective start date for the set of guidelines described in the subject element. The high component may be present, and if present, indicates the stop date for the guidelines. If not present, the guidelines are effective for an indefinate time period until explicitely changed or removed from the system.

 <rule context='//hl7:controlActProcess'>
   <assert test='hl7:effectiveTime'>
     The effectiveTime element shall be present in a PCC-7 transaction.
   </assert>
 </rule>
 <rule context='//hl7:controlActProcess/hl7:effectiveTime'>
   <assert test='hl7:low and hl7:low/@value'>
     A low element shall be present in the effectiveTime and the value attribute shall indicate the date upon which the guidelines become effective.
   </assert>
 </rule>

<subject typeCode='SUBJ' contextConductionInd='false'>

The subject element shall be present and shall be recorded as shown above. The subject element shall contain a <careProvisionEvent> element describing the guideline being activated.

Message Body

<careProvisionEvent classCode='PCPR' moodCode='EVN'>

An example <careProvisionEvent> element is shown below.

 <careProvisionEvent classCode='PCPR' moodCode='EVN'>
   <replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
     <careProvisionEvent classCode='PCPR' moodCode='EVN'>
       <id root=' ' extension=' '/>  
     </careProvisionEvent>
   </replacementOf>
   <component typeCode='COMP'>
     <carePlan classCode='PCPR' moodCode='INT'>
       <definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
         <guideline classCode='PCPR' moodCode='DEF'>
           <id root=' ' extension=' '/>
           <title></title>
           <text></text>
           <statusCode code='active|obsolete'/>
           <effectiveTime>
             <low value=' '/>
             <high value=' '/>
           </effectiveTime>
           <!-- zero or more components containing acts of care to be monitored -->
           <component2 typeCode='COMP'>
             <!-- One of the following elements -->
             <observationDefinition classCode='OBS' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </observationDefinition>
             <substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </substanceAdministrationDefinition>
             <procedureDefinition classCode='PROC' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </procedureDefinition>
             <encounterDefinition classCode='ENC' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </encounterDefinition>
             <actDefinition classCode='ACT' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </actDefinition>
           </component2>
           <!-- zero or more components containing "sub-guidelines" that make up this guideline -->
           <component3 typeCode='COMP'>
             <!-- The content model for "sub-guidelines" is as for a guideline, with the exception
             that it need not contain an id, title, text, statusCode, or effectiveTime element.  -->
           </component3>
         </guideline>
       </definition>
     </carePlan>
   </component>
 </careProvisionEvent>

The <careProvisionEvent> elements sent by a Guideline Notification transaction, or returned in a Request Guideline Data transaction represent activations or replacements of guidelines. As such these elements shall not contain any of the following participants:

• The <careProvisionEvent> element SHALL NOT contain a <recordTarget>, as guidelines are not specific to a single patient record.
• The <careProvisionEvent> element SHALL NOT contain a <subject> element, as guidelines are not specific to a device being maintained.

The <careProvisionEvent> may contain other participants not otherwise prohibited above.

Furthermore, these elements shall not contain any of the following relationships which would be only relevant to a single patient:

• The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation2> element.
• The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation3> element.

Furthermore, the <careProvisionEvent> element SHOULD NOT contain a <pertinentInformation1> element, as this information is not directly relevant to the guideline being retrieved.

The <careProvisionEvent> may contain other relationships not otherwise prohibited above, but the use of these elements is not described in this profile.

<rule context='hl7:careProvisionEvent[not(../hl7:replacementOf)]'>
  <assert test='count(hl7:component) = 1'>
    A careProvisionEvent shall have only one component containing the guideline.
  </assert>
  <assert test='not(hl7:recordTarget)'>
    The careProvisionEvent shall not contain a recordTarget element.
  </assert>
  <assert test='not(hl7:subject)'>
    The careProvisionEvent shall not contain a subject element.
  </assert>
  <assert test='not(hl7:pertinentInformation1)'>
    Warning: The careProvisionEvent should not contain a pertinentInformation1 element.
  </assert>
  <assert test='not(hl7:pertinentInformation2)'>
    The careProvisionEvent shall not contain a pertinentInformation2 element.
  </assert>
  <assert test='not(hl7:pertinentInformation3)'>
    The careProvisionEvent shall not contain a pertinentInformation3 element.
  </assert>
</rule>

<replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<id root=' ' extension=' '/>

When a Guideline Notification transaction sends a replacement notification, the <careProvisionEvent> that references the guideline being replaced shall be identified in the <replacementOf> element. The <replacementOf> element shall contain a single <careProvisionEvent> element that shall contain the an <id> element giving the unique identifier of the <careProvisionElement> that was replaced, and which should not contain any other elements.

<rule context='/hl7:REPC_IN004913UV'>
  <assert test='hl7:careProvisionEvent/hl7:replacementOf'>
    A replacement transaction shall contain a replacementOf element identifying 
    the careProvisionEvent being replaced.
  </assert>
</rule>

<rule context='hl7:replacementOf/hl7:careProvisionEvent'>
  <assert test='hl7:id'>
    The careProvisionEvent that is being replaced shall contain an id element.
  </assert>
  <assert test='not(hl7:*[local-name() != "id"])'>
    Warning: The careProvisionEvent that is being replaced should not contain anything other than an id element.
  </assert>
</rule>

<component typeCode='COMP'>
<carePlan classCode='PCPR' moodCode='INT'>

A <careProvisionEvent> shall have only one <component> element, containing only one <carePlan>, represented exactly as shown above.

<rule context='hl7:careProvisionEvent/hl7:component'>
  <assert test='count(hl7:carePlan) = 1'>
    The component of the careProvisionEven shall have one and only one carePlan element.
  </assert>
</rule>

<definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
<guideline classCode='PCPR' moodCode='DEF'>

The <carePlan> element shall be empty of all participants and relations with the exception of the <definition> of the <carePlan>. The <definition> element contains one and only one <guideline>.

<rule context='hl7:carePlan'>
  <assert test='not(*[local-name() != "definition"])'>
    The carePlan element shall be empty of all participants and relations with the exception of the definition element.
  </assert>
  <assert test='count(hl7:definition) = 1'>
    The carePlan element shall have one and only one definition element.
  </assert>
</rule>
<rule context='hl7:definition'>
  <assert test='count(hl7:guideline) = 1'>
    The definition element shall have one and only one guideline element.
  </assert>
</rule>

<id root=' ' extension=' '/>

Top level guidelines shall have a unique identifier.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:id'>
    A top level guideline shall have an id element.
  </assert>
</rule>

<title></title>

Top level guidelines shall have a title.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:title'>
    A top level guideline shall have a title element.
  </assert>
</rule>

<text></text>

All guidelines may contain narrative text describing the guideline.

<statusCode code='active|obsolete'/>

Top level guidelines shall have a statusCode value that is either "active" or "obsolete".

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:statusCode'>
    A top level guideline shall have a statusCode element.
  </assert>
</rule>
<rule context='hl7:guideline/hl7:statusCode'>
  <assert test='@code="active" or @code="obsolete"'>
    The statusCode/@code attribute shall be either "active" or "obsolete".
  </assert>
<rule>

<effectiveTime><low value=' '/><high value=' '/></effectiveTime>

Top level guidelines shall contain an <effectiveTime> element that records the time period over which the guideline is effective. It shall contain a <low> element recording at the very least the date upon which the guideline was activated. An obsolete guideline shall contain a <high> element recording the last date upon which the guideline was effective. An active guideline may record the date upon which the guideline is expected to be revised.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:effectiveTime'>
    A top level guideline shall have a effectiveTime element.
  </assert>
</rule>
<rule context='hl7:guideline/hl7:effectiveTime'>
  <assert test='hl7:low and hl7:low/@value'>
    The effectiveTime element shall contain a low element containing a value attribute indicating the time at which
    the guideline became effective.
  </assert>
<rule>
<rule context='hl7:guideline[hl7:statusCode/@code="obsolete"]/hl7:effectiveTime'>
  <assert test='hl7:high and hl7:high/@value'>
    The effectiveTime element in an obsolete guideline shall contain a high element containing a value attribute 
    indicating the time at which the guideline became ineffective.
  </assert>
<rule>

<component2 typeCode='COMP'>

All guidelines are composed (at some level) of one or more definitions for acts of care which are to be monitored by a Care Manager and reported upon by a Clinical Data Source during the provision of care. These may include various observations performed (e.g., Hemoglobin A1C tests), medications or immunizations given or prescribed, procedures performed (e.g., foot care), encounters performed (e.g., eye exam), or other acts of care not elsewhere described above.

<rule context='hl7:guideline'>
  <assert test='count(.//hl7:component2/hl7:*[@moodCode='DEF']) > 0'>
    At least one act of care must be defined at some level beneath a guideline element.
  </assert>
</rule>

<observationDefinition classCode='OBS' moodCode='DEF'>

<substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>

<procedureDefinition classCode='PROC' moodCode='DEF'>

<encounterDefinition classCode='ENC' moodCode='DEF'>

<actDefinition classCode='ACT' moodCode='DEF'>

One of the above definitions of an act of care shall be present in a <component2> element.

<templateId root=' ' extension=' '/>

Each act of care to be monitored shall indicate the identifier of the template used to report information on that act.

<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
  <assert test='hl7:templateId'>
    A templateId element must appear in the definition.
  </assert>
</rule>

A Guideline Manager actor shall use one the IHE Template identifiers specified for PCC-1 under careProvisionCode to request information profiled in an IHE template to be returned in a PCC-10 transaction. A Clincial Data Source implementing the Care Record option shall report activites to the Care Manager using the Care Record Query Response message using the template identified.

A Guideline Manager actor may include an ActDefinition in the <guideline> to identify the HL7 Version 2 Message Profile to describe the data to be monitored by a Care Manager. A Clinical Data Source implementing the HL7 Version 2 option shall report activities to the Care Manager using the HL7 Version 2 message identified by those ActDefinition elements.

<id root=' ' extension=' '/>

Each act of care to be monitored shall contain an identifier for the definition of the act. It shall also contain a code element describing the specific act of care to be monitored. Other features of the specific act allowed by the standard may be provided by the Guideline Manager to further identify the specific acts of care that a Care Manager wants to recieve (e.g., routeCode, targetSiteCode). A Clinical Data Source may use these additional features to limit the number of items it reports, but is not required to review any feature other than the "code" element when making its reports. The Care Manager is expected to use its decision support capabilities to ignore reports that are not relevant to its decision making processes.

<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
  <assert test='hl7:id'>
    An id element must appear in the definition.
  </assert>
  <assert test='hl7:code'>
    An code element must appear in the definition.
  </assert>
</rule>

A Clinical Data Source implementing the Care Record Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-10.

A Clinical Data Source implementing the HL7 Version 2 Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-11.

<component3 typeCode='COMP'>

Guidelines may cover different phases (e.g., pre-operative, post-operative) or perspectives of care (e.g., patient education, diet, medications). A guideline can therefore be constructed of other guideline components, which follow the same pattern as for the top level guideline in the careProvisionEvent, except that these subcomponents need not have a unique identity, a title, a status, or effective time.

Expected Actions -- Guideline Manager

The Guideline Manager shall send notifications as specified in the REPC_IN004110UV and REPC_IN004913UV interactions. The message shall be sent using web services as specified in the ITI-TF: Appendix V.

The name of the messages in the WSDL shall be REPC_IN004110UV_Message for activitation notifications, and REPC_IN004913UV_Message for replacement notifications. The following WSDL snippet defines the types for these messages:

Guideline Notification Message Type Definition

<types> <xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3"> <!-- Include the message schema --> <xsd:import namespace="urn:hl7-org:v3" schemaLocation="REPC_IN004110UV.xsd"/> <xsd:element name="REPC_IN004110UV"/> <xsd:import namespace="urn:hl7-org:v3" schemaLocation="REPC_IN004913UV.xsd"/> <xsd:element name="REPC_IN004913UV"/> </xsd:schema> </types>

The message types are declared to be of the appropriate type by the following WSDL snippet:

Guideline Notification Message WSDL Declarations

<message name='REPC_IN004110UV_Message'> <part element='hl7:REPC_IN004110UV' name="Body"/> </message> <message name='REPC_IN004913UV_Message'> <part element='hl7:REPC_IN004913UV' name="Body"/> </message>

Expected Actions -- Care Manager

The Care Manager shall send an acknowledgement response as specified in the MCCI_IN000002UV01 interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V. An acknowledgement response is structured almost identically to a transmission wrapper, but includes an acknowledgement element in the response. The example structure below uses the same values as the transmission wrapper, with the exceptions noted in bold black text below.

<MCCI_IN000002UV01 xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='MCCI_IN000002UV01' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='NE'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <acknowledgement>
  <typeCode code='AA|AE|AR'/>
  <acknowledgementDetail>
    <typeCode='E|I|W'/>
    
    <text></text>
    <location></location>
  </acknowledgementDetail>
 </acknowledgement>
</MCCI_IN000002UV01>

<MCCI_IN000002UV01 xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The name of the acknowledgement message element shall be MCCI_IN000002UV01 from the HL7 namespace.

<rule context='/'>
 <assert test='/hl7:MCCI_IN000002UV01'>
  The name of the acknowledgement message element shall be MCCI_IN000002UV01 from the HL7 namespace.
 </assert>
<rule>

<interactionId extension='MCCI_IN000002UV01' root='2.16.840.1.113883.5'/>

The interactionId element shall be recorded exactly as specified above.

<rule context='/hl7:MCCI_IN000002UV01'>
 <assert test='hl7:interactionId/@extension = "MCCI_IN000002UV01" and interactionId/@root = "2.16.840.1.113883.5"'>
  The extension attribute of the interaction Id element shall be MCCI_IN000002UV01.
 </assert>
<rule>

<processingModeCode code='T'/>

The code attribute of the processingModeCode element shall be T to indicate current processing.

<rule context='/hl7:MCCI_IN000002UV01'>
 <assert test='hl7:processingModeCode/@code = "T"'>
   The code attribute of the processingModeCode element shall be T to indicate current processing.
 </assert>
<rule>

<acceptAckCode code='NE'/>

The code attribute of the acceptAckCode element shall be NE to indicate that acknowledgments are never acknowledged by the reciever.

<rule context='/hl7:MCCI_IN000002UV01'>
 <assert test='hl7:acceptAckCode/@code = "NE"'>
   The code attribute of the acceptAckCode element shall be NE.
 </assert>
<rule>

<acknowledgement>

One and only one acknowledgement element shall be present.

<rule context='/hl7:MCCI_IN000002UV01'>
 <assert test='count(hl7:acknowledgement) = 1'>
   One and only one acknowledgement element shall be present.
 </assert>
<rule>

<typeCode code='AA|AE|AR'/>

The typeCode element shall be present. It shall use only the values AA, AE, or AR to describe whether the application accepted it (AA), found an error in it (AE), or rejected it (AR).

<rule context='/hl7:MCCI_IN000002UV01/hl7:acknowledgement'>
 <assert test='hl7:typeCode/@code = "AA" or hl7:typeCode/@code = "AE" or hl7:typeCode/@code = "AR"'>
   Only the values AA, AE and AR are acceptable.
 </assert>
<rule>

<acknowledgementDetail>

The acknowledgementDetail element shall be present when a message is rejected, or when an error is found. It may be present even when an application has accepted the message to convey information and warnings.

<rule context='/hl7:MCCI_IN000002UV01/hl7:acknowledgement'>
 <assert test='hl7:typeCode/@code = "AA" or hl7:acknowledgementDetail'>
   The acknowledgementDetail element is required when the acknowedgement reports an error (AE) or rejects a message (AR).
 </assert>
<rule>

<typeCode code='E|I|W'/>

The typeCode element shll be present in the acknowledgementDetail element. It shall have a value of E, I or W to indicate errors, information or warnings. A detail message sent with the acknowledgement type of AA shall not contain a value of E in the detailed type code.

<rule context='/hl7:MCCI_IN000002UV01/hl7:acknowledgement/hl7:acknowledgementDetail'>
 <assert test='hl7:typeCode/@code = "E" or hl7:typeCode/@code = "I" or hl7:typeCode/@code = "W"'>
   Only the values E, I or W are acceptable.
 </assert>
 <assert test='hl7:typeCode/@code != "E" or ../../hl7:typeCode != "AA"'>
   Acknowledgement details cannot indicate an error when the acknowledgment is of type AA.
 </assert>

<rule>

The code element may be present in the acknowledgementDetail element to further describe the error.

<text></text>

The text element may be present in the acknowledgementDetail element to further describe the error in human readable form.

<location></location>

The location element may be present in the acknowledgementDetail element to indicate the location of the error. The location shall be reported as an XPath expression indicating the position of the error in the source message content.

The name of the acknowledgement response message shall be MCCI_IN000002UV01_Message in the WSDL. The following WSDL snippet defines the type for this message:

Accept Acknowledgement Message Type Definition

<types> <xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3"> <xsd:import namespace="urn:hl7-org:v3" schemaLocation="MCCI_IN000002UV01.xsd"/> <xsd:element name="MCCI_IN000002UV01"/> </xsd:schema> </types>

The message type is declared to be of the appropriate type by the following WSDL snippet:

Accept Acknowledgement Message WSDL Declaration

<message name='MCCI_IN000002UV01_Message'> <part element='hl7:MCCI_IN000002UV01' name="Body"/> </message>

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:

WSDL Definitions for PCC-7

WSDL Item	Value
wsdl:definitions/@name	GuidelineManger
Activate Care Provision	REPC_IN004110UV_Message
Replace Care Provision	REPC_IN004913UV_Message
Acknowlegement	MCCI_IN000002UV01_Message
portType	GuidelineManger_PortType
Activate Guideline Operation	GuidelineManger_REPC_IN004110UV
Activate Guideline Operation	GuidelineManger_REPC_IN004913UV
SOAP 1.1 binding	GuidelineManger_Binding_Soap11
SOAP 1.1 port	GuidelineManger_Port_Soap11
SOAP 1.2 binding	GuidelineManger_Binding_Soap12
SOAP 1.2 port	GuidelineManger_Port_Soap12

The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Guideline Manger Data Repository actor implementing the QED profile can be found at ftp://ftp.ihe.net/Patient_Care_Coordination/yr3_2008-2009/resources/cm.zip. For a general description of the WSDLs for Care Management see the Appendix of the same name in this volume.

Port Type

Port Types for PCC-7

<portType name="GuidelineManger_PortType"> <operation name="GuidelineManger_REPC_IN004110UV"> <input message="tns:REPC_IN004110UV_Message" wsaw:Action="urn:hl7-org:v3:REPC_IN004110UV"/> <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/> </operation> <operation name="GuidelineManger_REPC_IN004913UV"> <input message="tns:REPC_IN004913UV_Message" wsaw:Action="urn:hl7-org:v3:REPC_IN004913UV"/> <output message="tns:MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/> </operation> </portType>

Bindings

SOAP 1.2 Binding for PCC-7

<binding name="GuidelineManger_Binding_Soap12" type="GuidelineManger_PortType"> <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GuidelineManger_REPC_IN004110UV"> <wsoap12:operation soapAction="urn:hl7-org:v3:REPC_IN004110UV"/> <input> <wsoap12:body use="literal"/> </input> <output> <wsoap12:body use="literal"/> </output> </operation> <operation name="GuidelineManger_REPC_IN004913UV"> <wsoap12:operation soapAction="urn:hl7-org:v3:REPC_IN004913UV"/> <input> <wsoap12:body use="literal"/> </input> <output> <wsoap12:body use="literal"/> </output> </operation> </binding>

SOAP 1.1 Binding for PCC-7

<binding name="GuidelineManger_Binding_Soap11" type="GuidelineManger_PortType"> <wsoap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GuidelineManger_REPC_IN004110UV"> <wsoap11:operation soapAction="urn:hl7-org:v3:REPC_IN004110UV"/> <input> <wsoap11:body use="literal"/> </input> <output> <wsoap11:body use="literal"/> </output> </operation> <operation name="GuidelineManger_REPC_IN004913UV"> <wsoap11:operation soapAction="urn:hl7-org:v3:REPC_IN004913UV"/> <input> <wsoap11:body use="literal"/> </input> <output> <wsoap11:body use="literal"/> </output> </operation> </binding>

Request Guideline Data

This section corresponds to Transaction PCC-8 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-8 is used by the Care Manager and/or Clinical Data Source Actors to request Guideline Data from a Guideline Manager Actor. Transaction PCC-8 is similar in structure to Transaction PCC-1. The difference between PCC-8 and PCC-1 is that where PCC-1 requests clinical information matching the query parameters for a specific patient, the PCC-8 transaction requests a specific care record activating a clinical guideline identified in the query parameters.

Use Case Roles

Care Manager or Clinical Data Source		Guideline Manager
Request Guideline Data

Actor

Care Manager or Clinical Data Source

Role

Requests the data required to implement a guideline.

Cooresponding HL7 Version 3 Application Roles

Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)

Actor

Guideline Manager

Role

Returns the guideline data required to implement a guideline.

Cooresponding HL7 Version 3 Application Roles

Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)

Note:

Implementors of a Guideline Manager Actor, Care Manager Actor or a Clinical Data Source Actor shall publish an HL7 Conformance Profile that indicates the vocabularies and code sets that they support for this transaction.

Referenced Standards

CareRecord	HL7 Care Provision Care Record (DSTU)
CareQuery	HL7 Care Provision Care Record Query (DSTU)
HL7QI	HL7 Version 3 Standard: Infrastructure Management – Query Infrastrucure
HL7WS	HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release
SOAP	Simple Object Access Protocol Version 1.1 (SOAP 1.1)
SOAP12	Simple Object Access Protocol Version 1.2 (SOAP 1.2)

Interaction Diagrams

Get Care Record Query

Trigger Events

When a Clinical Data Source actor needs to understand the data needed to respond to a query from a Care Manager, or a Care Manager actor needs to refresh its knowledge about a guideline (e.g., to determine how to update a query for a replaced guideline) it will trigger a Get Care Record Query event. This cooresponds to the HL7 trigger event: QUPC_TE040100UV

Message Semantics

The Query Care Record Event Get Query corresponds to the HL7 Interaction QUPC_IN040100UV.

A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN040100UV.xsd. This schema includes:

• the transmission wrapper MCCI_MT000100UV01,
• the control act wrapper QUQI_MT020001UV01, and
• the message payload QUPC_MT040100UV.

These components of the interaction are specified in the HL7 standards described above.

Transmission Wrapper

The transmission wrapper MCCI_MT000100UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<QUPC_IN040100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='QUPC_IN040100UV' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='AL'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess>
  See Control Act Wrapper below
 </controlActProcess>
</QUPC_IN040100UV>

<QUPC_IN040100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

<interactionId extension='QUPC_IN040100UV' root='2.16.840.1.113883.5'/>

The identifer for the interaction shall be sent as shown above.

<processingModeCode code='T'/>

The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.

<acceptAckCode code='AL'/>

The acceptAckCode indicates whether the sender wants to recieve an acknowledgement, and shall be sent as shown above.

Control Act Wrapper

The control act wrapper QUQI_MT020001UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<controlActProcess moodCode="RQO">
  <id root=' ' extension=' '/>
  
  <effectiveTime value=' '/>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  
  <queryByParameter>
    <id root=' ' extension=' '/>
    <statusCode code='new'/>
    <responseModalityCode code='R'/>
    <responsePriorityCode code='I'/>
    <initialQuantity value=/>
    <initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'>
    <parameterList>
      see Query Parameter List below
    </parameterList>
  </queryByParameter>
</controlActProcess>

<controlActProcess moodCode="RQO">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "RQO" by the sender to indicate a request to perform an action, in this case, a query.

The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.

<queryByParameter>

HL7 Version 3 messages that perform a query specify the details of it in the <queryByParameter> element.

<id root=' ' extension=' '/>

The sending system shall specify the identifier of the query. This is the identifier that is used in subsequent continuation or cancel messages.

<statusCode code='new'/>

When passing the parameter list, the <statusCode> element shall be recorded as above to indicate that this is a new query.

<responseModalityCode code='R'/>

The query response shall always be in real-time.

<responsePriorityCode code='I'/>

The query response shall always be immediate.

<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883.5'>

The <initialQuantityCode> shall be sent when <initialQuantity> is sent. The code shall be the identifier of the HL7 artifact that is to be counted (e.g., R-MIM or C-MET identifer). In this profile what is being counted is clinical statements, so the code to use shall be REPC_RM000100UV.

Parameter List

The message supports specification of the data items listed in the table below as query parameters. The first column of this table provides the name of the parameter. The next column indicates the number of times it may occur in the query. The next column indicates the type of data expected for the query parameter. The next column indicates the vocabulary domain used for coded values. The Sender column indicates whether the message sender (a Care Manager or Clinical Data Source actor) must send this parameter. The Reciever column indicates whether the reciever (a Guideline Manager Actor) must support this parameter. If these last two columns contain the value R, then this parameter SHALL be send by actor, and if it is X, then this parameter SHALL NOT be sent by the actor. In this profile, all parameters not explicitly required are prohibited.

Query Parameters

Parameter Name	Cardinality	Data Type	Vocabulary Domain	Sender	Reciever
careRecordId	1..1	II		R	R
patientId	0..0	CD		X	X
versionTimeStamp	0..0	TS		X	X
includeCarePlanAttachment	1..1	BL		R	R
maxHistoryClincialStatements	0..0	INT		X	X

An example of the query specification is described in the figure below.

  <parameterList>
    <careRecordId>
      <value code='' displayName='' codeSystem='' codeSystemName=''/>
    </careRecordId>
    <includeCarePlanAttachment><value value='true'/></includeCarePlanAttachment>
  </parameterList>

<parameterList>

The <parameterList> element shall be present, and contains the set of query parameters being used in this query.

<careRecordId><value root=' ' extension=' '/></careRecordId>

The identifier of the care record event that activated the guideline shall be specified in this element. The root and extension attributes shall be present.

<includeCarePlanAttachment><value value='true'/></includeCarePlanAttachment>

The <includeCarePlanAttachment> element shall be sent and the value shall be true. As guidelines always appear in a Care Record message under the Care Plan, the Care Plan must be present in the response.

Expected Actions -- Care Manager or Clinical Data Source

The clinical data consumer shall send a query as specified in the QUPC_IN040100UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.

The name of the query response message shall be QUPC_IN040100UV_Message in the WSDL. The following WSDL snippet defines the type for this message:

Query Message Type Definition

<types> <xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3"> <!-- Include the message schema --> <xsd:include namespace="urn:hl7-org:v3" schemaLocation="QUPC_IN040100UV.xsd"/> </xsd:schema> </types>

The message type is declared to be of the appropriate type by the following WSDL snippet:

Query Message WSDL Declaration

<message name='QUPC_IN040100UV_Message'> <part element='hl7:QUPC_IN040100UV' name="Body"/> </message>

Other WSDL declarations required for this transaction are defined under the Domain Content section.

Get Care Record Profile Response

Trigger Events

This message is triggered upon reciept of a Query Care Record Event Get Query. This corresponds to HL7 trigger event: QUPC_TE043200UV

Message Semantics

The Query Care Record Event Get Query Response corresponds to the HL7 Interaction QUPC_IN040200UV. A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN040200UV.xsd. This schema includes:

• the transmission wrapper MCCI_MT000300UV01,
• the control act wrapper MFMI_MT700712UV01, and
• the message payload REPC_MT004000UV.

These components of the interaction are specified in the HL7 standards described above.

Transmission Wrapper

The transmission wrapper MCCI_MT000300UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.

An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<QUPC_IN040200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='QUPC_IN040200UV' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='NE'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE"> 
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess>
  See Control Act Wrapper below
 </controlActProcess>
</QUPC_IN040200UV>

<QUPC_IN040200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

<interactionId extension='QUPC_IN040200UV' root='2.16.840.1.113883.5'/>

The identifer for the interaction shall be sent as shown above.

<processingModeCode code='T'/>

The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.

<acceptAckCode code='NE'/>

The acceptAckCode indicates whether the reciever wants to recieve an acknowledgement, and shall be sent as shown above. Query responses shall not require acknowledgements.

Control Act Wrapper

The control act wrapper MFMI_MT700712UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<controlActProcess moodCode="EVN">=
  <id root=' ' extension=' '/>
  
  <effectiveTime value=' '/>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  <subject>
     See Query Response below
  </subject>
  <queryAck>
    <queryId root=' ' extension=' '/>
    <statusCode code=' '/>
    <queryResponseCode code=' '/>
    <resultTotalQuantity value=' '/>
    <resultCurrentQuantity value=' '/>
    <resultRemainingQuantity value=' '/>
  </queryAck>
</controlActProcess>

<controlActProcess moodCode="EVN">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "EVN" by the sender to indicate a response to a query.

The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.

<subject>

The <subject> element shall be present to record the responses in a query request.

<queryAck>

The queryAck element is transmitted in any message that is a response to a query, query continuation or query cancellation message.

<queryId root=' ' extension=' '/>

The <queryId> element shall be transmitted in a queryAck element. It shall contain an identifier that was used in the original query message.

<statusCode code=' '/>

The statusCode element in the queryAck element indicates the status of the query. It may contain the value 'deliveredResponse' or 'aborted'.

<queryResponseCode code=' '/>

The queryResponseCode element indicates at a high level the results of performing the query. It may have the value 'OK' to indicate that the query was performed and has results. It may have the value 'NF' to indicate that the query was performed, but no record was found. It may have the value 'QE' to indicate that an error was detected in the incoming query message, or 'AE' to indicate some other application error occurred.

<resultTotalQuantity value=' '/>

The resultTotalQuantity element shall be present and enumerates the number of results found (1). This element gives the count of the total number of results located by the query.

Note:

For this use of the query, the resultTotalQuantity value should always be 1

<resultCurrentQuantity value=' '/>

The resultCurrentQuantity element shall be present, and shall enumerate number of results returned in the current response.

Note:

For this use of the query, the resultCurrentQuantity value should always be 1

<resultRemainingQuantity value=' '/>

This resultRemainingQuantity element shall be present. It shall enumerate the number of results that follow the results currently returned (0).

Note:

For this use of the query, the resultRemainingQuantity value should always be 0

Registration Event Details

The <subject> element of the <controlActProcess> element shall appear as shown in the example below, and provides details on the event that registered the the guideline with the Guideline Manager.

<subject>
  <registrationEvent>
    <statusCode code='active|obsolete'/>
    <custodian>
      <assignedEntity>
        <id root='' extension=''/>
        <addr></addr>
        <telecom></telecom>
        <assignedOrganization>
          <name></name>
        </assignedOrganization>
      </assignedEntity>
    </custodian>
    <subject2>
      <careProvisionEvent classCode='PCPR' moodCode='EVN'>
        <!-- Message Body -->
      </careProvisionEvent>
      <parameterList>
      </parameterList>
    </subject2>
  </registrationEvent>
</subject>

<subject>

The <subject> element shall be present, and is where the results are returned.

<registrationEvent>

Only one <registrationEvent> element shall be be present.

The <registrationEvent> is used to record the information about how the <careProvisionEvent> being returned was recorded or "registered" in the custodial system (the Guideline Manager actor) .

<statusCode code='active|obsolete'/>

The <statusCode> element records the status of the data records. Queries return active and obsolete (replaced) records.

<custodian>

The <custodian> element records the custodian, or "owner", of the guideline. A Guideline Manager actor may return records from multiple custodians.

<assignedEntity>

The <assignedEntity> element shall be present, and provides contact and identification information about the <custodian>.

<id root=' ' extension=' '/>

The <id> element shall be present, and shall uniquely identify the custodian of the guideline.

<addr></addr>

The <addr> element shall be present, and shall provide a postal address for the custodian of the guideline.

<telecom></telecom>

At least one <telecom> element shall be present that provides a telephone number to contact the custodian of the guideline. A <telecom> element may be present that provides the web service end-point address of the custodian of the guideline.

For Public Comment

How might the web service end-point address be used? Is it a good idea to include it, or should we omit this from the profile?

<assignedOrganization>
 <name></name>
</assignedOrganization>

The name of the organization that is the custodian of the guideline shall be provided.

<subject2>

The <subject2> element provides the data content requested from the query.

Query Response Content

Note:

The following content for careProvisionEvent is identical to that found in PCC-7.

<careProvisionEvent classCode='PCPR' moodCode='EVN'>

An example <careProvisionEvent> element is shown below.

 <careProvisionEvent classCode='PCPR' moodCode='EVN'>
   <replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
     <careProvisionEvent classCode='PCPR' moodCode='EVN'>
       <id root=' ' extension=' '/>  
     </careProvisionEvent>
   </replacementOf>
   <component typeCode='COMP'>
     <carePlan classCode='PCPR' moodCode='INT'>
       <definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
         <guideline classCode='PCPR' moodCode='DEF'>
           <id root=' ' extension=' '/>
           <title></title>
           <text></text>
           <statusCode code='active|obsolete'/>
           <effectiveTime>
             <low value=' '/>
             <high value=' '/>
           </effectiveTime>
           <!-- zero or more components containing acts of care to be monitored -->
           <component2 typeCode='COMP'>
             <!-- One of the following elements -->
             <observationDefinition classCode='OBS' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </observationDefinition>
             <substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </substanceAdministrationDefinition>
             <procedureDefinition classCode='PROC' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </procedureDefinition>
             <encounterDefinition classCode='ENC' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </encounterDefinition>
             <actDefinition classCode='ACT' moodCode='DEF'>
               <templateId root=' ' extension=' '/>
               <id root=' ' extension=' '/>
               
             </actDefinition>
           </component2>
           <!-- zero or more components containing "sub-guidelines" that make up this guideline -->
           <component3 typeCode='COMP'>
             <!-- The content model for "sub-guidelines" is as for a guideline, with the exception
             that it need not contain an id, title, text, statusCode, or effectiveTime element.  -->
           </component3>
         </guideline>
       </definition>
     </carePlan>
   </component>
 </careProvisionEvent>

The <careProvisionEvent> elements sent by a Guideline Notification transaction, or returned in a Request Guideline Data transaction represent activations or replacements of guidelines. As such these elements shall not contain any of the following participants:

• The <careProvisionEvent> element SHALL NOT contain a <recordTarget>, as guidelines are not specific to a single patient record.
• The <careProvisionEvent> element SHALL NOT contain a <subject> element, as guidelines are not specific to a device being maintained.

The <careProvisionEvent> may contain other participants not otherwise prohibited above.

Furthermore, these elements shall not contain any of the following relationships which would be only relevant to a single patient:

• The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation2> element.
• The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation3> element.

Furthermore, the <careProvisionEvent> element SHOULD NOT contain a <pertinentInformation1> element, as this information is not directly relevant to the guideline being retrieved.

The <careProvisionEvent> may contain other relationships not otherwise prohibited above, but the use of these elements is not described in this profile.

<rule context='hl7:careProvisionEvent[not(../hl7:replacementOf)]'>
  <assert test='count(hl7:component) = 1'>
    A careProvisionEvent shall have only one component containing the guideline.
  </assert>
  <assert test='not(hl7:recordTarget)'>
    The careProvisionEvent shall not contain a recordTarget element.
  </assert>
  <assert test='not(hl7:subject)'>
    The careProvisionEvent shall not contain a subject element.
  </assert>
  <assert test='not(hl7:pertinentInformation1)'>
    Warning: The careProvisionEvent should not contain a pertinentInformation1 element.
  </assert>
  <assert test='not(hl7:pertinentInformation2)'>
    The careProvisionEvent shall not contain a pertinentInformation2 element.
  </assert>
  <assert test='not(hl7:pertinentInformation3)'>
    The careProvisionEvent shall not contain a pertinentInformation3 element.
  </assert>
</rule>

<replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<id root=' ' extension=' '/>

When a Guideline Notification transaction sends a replacement notification, the <careProvisionEvent> that references the guideline being replaced shall be identified in the <replacementOf> element. The <replacementOf> element shall contain a single <careProvisionEvent> element that shall contain the an <id> element giving the unique identifier of the <careProvisionElement> that was replaced, and which should not contain any other elements.

<rule context='/hl7:REPC_IN004913UV'>
  <assert test='hl7:careProvisionEvent/hl7:replacementOf'>
    A replacement transaction shall contain a replacementOf element identifying 
    the careProvisionEvent being replaced.
  </assert>
</rule>

<rule context='hl7:replacementOf/hl7:careProvisionEvent'>
  <assert test='hl7:id'>
    The careProvisionEvent that is being replaced shall contain an id element.
  </assert>
  <assert test='not(hl7:*[local-name() != "id"])'>
    Warning: The careProvisionEvent that is being replaced should not contain anything other than an id element.
  </assert>
</rule>

<component typeCode='COMP'>
<carePlan classCode='PCPR' moodCode='INT'>

A <careProvisionEvent> shall have only one <component> element, containing only one <carePlan>, represented exactly as shown above.

<rule context='hl7:careProvisionEvent/hl7:component'>
  <assert test='count(hl7:carePlan) = 1'>
    The component of the careProvisionEven shall have one and only one carePlan element.
  </assert>
</rule>

<definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
<guideline classCode='PCPR' moodCode='DEF'>

The <carePlan> element shall be empty of all participants and relations with the exception of the <definition> of the <carePlan>. The <definition> element contains one and only one <guideline>.

<rule context='hl7:carePlan'>
  <assert test='not(*[local-name() != "definition"])'>
    The carePlan element shall be empty of all participants and relations with the exception of the definition element.
  </assert>
  <assert test='count(hl7:definition) = 1'>
    The carePlan element shall have one and only one definition element.
  </assert>
</rule>
<rule context='hl7:definition'>
  <assert test='count(hl7:guideline) = 1'>
    The definition element shall have one and only one guideline element.
  </assert>
</rule>

<id root=' ' extension=' '/>

Top level guidelines shall have a unique identifier.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:id'>
    A top level guideline shall have an id element.
  </assert>
</rule>

<title></title>

Top level guidelines shall have a title.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:title'>
    A top level guideline shall have a title element.
  </assert>
</rule>

<text></text>

All guidelines may contain narrative text describing the guideline.

<statusCode code='active|obsolete'/>

Top level guidelines shall have a statusCode value that is either "active" or "obsolete".

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:statusCode'>
    A top level guideline shall have a statusCode element.
  </assert>
</rule>
<rule context='hl7:guideline/hl7:statusCode'>
  <assert test='@code="active" or @code="obsolete"'>
    The statusCode/@code attribute shall be either "active" or "obsolete".
  </assert>
<rule>

<effectiveTime><low value=' '/><high value=' '/></effectiveTime>

Top level guidelines shall contain an <effectiveTime> element that records the time period over which the guideline is effective. It shall contain a <low> element recording at the very least the date upon which the guideline was activated. An obsolete guideline shall contain a <high> element recording the last date upon which the guideline was effective. An active guideline may record the date upon which the guideline is expected to be revised.

<rule context='hl7:definition/hl7:guideline'>
  <assert test='hl7:effectiveTime'>
    A top level guideline shall have a effectiveTime element.
  </assert>
</rule>
<rule context='hl7:guideline/hl7:effectiveTime'>
  <assert test='hl7:low and hl7:low/@value'>
    The effectiveTime element shall contain a low element containing a value attribute indicating the time at which
    the guideline became effective.
  </assert>
<rule>
<rule context='hl7:guideline[hl7:statusCode/@code="obsolete"]/hl7:effectiveTime'>
  <assert test='hl7:high and hl7:high/@value'>
    The effectiveTime element in an obsolete guideline shall contain a high element containing a value attribute 
    indicating the time at which the guideline became ineffective.
  </assert>
<rule>

<component2 typeCode='COMP'>

All guidelines are composed (at some level) of one or more definitions for acts of care which are to be monitored by a Care Manager and reported upon by a Clinical Data Source during the provision of care. These may include various observations performed (e.g., Hemoglobin A1C tests), medications or immunizations given or prescribed, procedures performed (e.g., foot care), encounters performed (e.g., eye exam), or other acts of care not elsewhere described above.

<rule context='hl7:guideline'>
  <assert test='count(.//hl7:component2/hl7:*[@moodCode='DEF']) > 0'>
    At least one act of care must be defined at some level beneath a guideline element.
  </assert>
</rule>

<observationDefinition classCode='OBS' moodCode='DEF'>

<substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>

<procedureDefinition classCode='PROC' moodCode='DEF'>

<encounterDefinition classCode='ENC' moodCode='DEF'>

<actDefinition classCode='ACT' moodCode='DEF'>

One of the above definitions of an act of care shall be present in a <component2> element.

<templateId root=' ' extension=' '/>

Each act of care to be monitored shall indicate the identifier of the template used to report information on that act.

<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
  <assert test='hl7:templateId'>
    A templateId element must appear in the definition.
  </assert>
</rule>

A Guideline Manager actor shall use one the IHE Template identifiers specified for PCC-1 under careProvisionCode to request information profiled in an IHE template to be returned in a PCC-10 transaction. A Clincial Data Source implementing the Care Record option shall report activites to the Care Manager using the Care Record Query Response message using the template identified.

A Guideline Manager actor may include an ActDefinition in the <guideline> to identify the HL7 Version 2 Message Profile to describe the data to be monitored by a Care Manager. A Clinical Data Source implementing the HL7 Version 2 option shall report activities to the Care Manager using the HL7 Version 2 message identified by those ActDefinition elements.

<id root=' ' extension=' '/>

Each act of care to be monitored shall contain an identifier for the definition of the act. It shall also contain a code element describing the specific act of care to be monitored. Other features of the specific act allowed by the standard may be provided by the Guideline Manager to further identify the specific acts of care that a Care Manager wants to recieve (e.g., routeCode, targetSiteCode). A Clinical Data Source may use these additional features to limit the number of items it reports, but is not required to review any feature other than the "code" element when making its reports. The Care Manager is expected to use its decision support capabilities to ignore reports that are not relevant to its decision making processes.

<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
  <assert test='hl7:id'>
    An id element must appear in the definition.
  </assert>
  <assert test='hl7:code'>
    An code element must appear in the definition.
  </assert>
</rule>

A Clinical Data Source implementing the Care Record Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-10.

A Clinical Data Source implementing the HL7 Version 2 Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-11.

<component3 typeCode='COMP'>

Guidelines may cover different phases (e.g., pre-operative, post-operative) or perspectives of care (e.g., patient education, diet, medications). A guideline can therefore be constructed of other guideline components, which follow the same pattern as for the top level guideline in the careProvisionEvent, except that these subcomponents need not have a unique identity, a title, a status, or effective time.

<parameterList>

The <parameterList> shall be present, and shall contain content that is identical to the <parameterList> passed in the query.

Expected Actions -- Data Repository

The Data Repository shall send a response as specified in the QUPC_IN043200UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V. The name of the query response message shall be QUPC_IN043200UV_Message in the WSDL. The following WSDL snippet defines the type for this message:

Query Response Message Type Definition

<types> <xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3"> <xsd:import namespace="urn:hl7-org:v3" schemaLocation="QUPC_IN043200UV.xsd"/> <xsd:element name="QUPC_IN043200UV"/> </xsd:schema> </types>

The message type is declared to be of the appropriate type by the following WSDL snippet:

Query Respone Message WSDL Declaration

<message name='QUPC_IN040200UV_Message'> <part element='hl7:QUPC_IN040200UV' name="Body"/> </message>

Other WSDL declarations required for this transaction are defined under the Domain Content section.

Response to a New Query

The Guideline Manager, shall:

1. Recieve and validate the query message.
2. Create the response message.
3. Add an ILLEGAL detected issue alert to the response message if the content is invalid (e.g., does not pass schema validation or is otherwise malformed), and immediately return a response indicating the error, and that the query was aborted. Set the text of the alert to the name of the first data element that is not valid. The Guideline Manager may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the query are not valid.
4. Add a NAT detected issue alert to the response message if the requesting party is not authorized to perform the query, and immediately return a response indicating the error, and that the query was aborted.
5. Add a ILLEGAL detected issue alert to the response message if the the data repository does not recognize the identity domain used to identify the guideline. Set the text value on the alert to careRecordId.
6. If any issues were detected, Set queryAck/statusCode/@code to aborted, and queryAct/queryResponse/@code to QE, and return the response.
7. Add an ISSUE alert to the response message if at any time during response generation, an application error occurs that prevents further processing. Set the text of the alert to the reason for the application error (e.g., a stack trace or exception message). Set queryAct/statusCode/@code to aborted, and queryAct/responseCode/@code to AE, and return the response.
8. Query for the guideline requested by the query.
9. If results are found, set queryAct/queryResponse/@code to OK, otherwise set it to NF.
10. Set queryAck/statusCode/@code to deliveredResponse.
11. Add the result to the response.

Raising Alerts

If the content of the request is not valid (e.g., according to the Schema or the rules of this profile), at least on ILLEGAL alert shall be raised indicating the data element that was invalid. A response will be sent indicating that the request was invalid, and no further processing shall be performed.

If the requesting party is not authorized to perform the query, the minimum response shall be sent indicating only that the requested is not authorized to perform the query.

In other cases, all possible alerts shall be accumulated before returning a response to the caller.

This enables Clinical Data Consumer actors to send a test query that will enable them to verify the vocabulary and other request parameters that are desired.

An alert is raised by sending a response containing one or more <reasonOf> elements, coded as shown below.

<reasonOf>
  <detectedIssueEvent>
    <code code='' displayName='' codeSystem='' codeSystemName=''/>
    <text></text>
    <mitigatedBy>
      <detectedIssueManagement moodCode="RQO">
        <code code='' displayName='' codeSystem='' codeSystemName=''/>
        <text></text>
      </detectedIssueManagement>
    </mitigatedBy>
  </detectedIssueEvent>>
</reasonOf>

<reasonOf>

The <reasonOf> element is required to indicate that an alert has occured.

<detectedIssueEvent>

The details of the alert shall be present in the <detectedIssueEvent> element.

<code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.5.4' codeSystemName='ActCode'/>

The <code> element shall contain ISSUE or one of its descendants from the HL7 ActCode vocabulary.

<text></text>

If a validation or other business rule error occurred, the erroneous parameter shall be identified in <text> element using the element name, and nothing else should be present.

If an application error occured, the <text> element shall contain diagnostic information (e.g., stack trace or exception message).

If the reason for the alert was an unrecognized code (CODE_INVALID), the text element shall contain the name of the erroneous parameter, and may contain a space separated list of OIDs identifying value sets which would be valid.

If the reason for the alert was an unrecognized identifier (KEY204) for the vocabulary used in the careProvisionCode or careProvisionReason element, the text element shall contain the name of the erroneous paramater, and may contain a space separated list of the OIDs for code systems which would be valid.

Expected Actions -- Clinical Data Consumer

The Care Manager or Clinical Data Source processes the query response data. No additional data other than the single requested guideline will be returned, so no provision is made in this profile for continuations or canceling the query.

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:

WSDL Definitions for PCC-8

WSDL Item	Value
wsdl:definitions/@name	GuidelineManger
Get Care Record Query	QUPC_IN040100UV_Message
Get Care Record Query Response	QUPC_IN040200UV_Message
portType	GuidelineManger_PortType
Query Operation	GuidelineManger_QUPC_IN043100UV
SOAP 1.1 binding	GuidelineManger_Binding_Soap11
SOAP 1.1 port	GuidelineManger_Port_Soap11
SOAP 1.2 binding	GuidelineManger_Binding_Soap12
SOAP 1.2 port	GuidelineManger_Port_Soap12

The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Guideline Manger Data Repository actor implementing the QED profile can be found at ftp://ftp.ihe.net/Patient_Care_Coordination/yr3_2008-2009/resources/cm.zip. For a general description of the WSDLs for Care Management see the Appendix of the same name in this volume.

Port Type

Port Types for PCC-8

<portType name="GuidelineManger_PortType"> <operation name="GuidelineManger_QUPC_IN040100UV"> <input message="tns:QUPC_IN040100UV_Message" wsaw:Action="urn:hl7-org:v3:QUPC_IN040100UV"/> <output message="tns:QUPC_IN040200UV_Message" wsaw:Action="urn:hl7-org:v3:QUPC_IN040200UV "/> </operation> </portType>

Bindings

SOAP 1.2 Binding for PCC-8

<binding name="GuidelineManger_Binding_Soap12" type="GuidelineManger_PortType"> <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GuidelineManger_QUPC_IN043100UV"> <wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN040100UV"/> <input> <wsoap12:body use="literal"/> </input> <output> <wsoap12:body use="literal"/> </output> </operation> </binding>

SOAP 1.1 Binding for PCC-8

<binding name="GuidelineManger_Binding_Soap11" type="GuidelineManger_PortType"> <wsoap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GuidelineManger_QUPC_IN040100UV"> <wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN040100UV"/> <input> <wsoap11:body use="literal"/> </input> <output> <wsoap11:body use="literal"/> </output> </operation> </binding>

Care Management Data Query

This section corresponds to Transaction PCC-9 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-9 is used by the Care Manager and Clinical Data Repository Actors.

Transaction PCC-9 is a variation of the pattern used in transaction PCC-1 of the PCC Technical Framework. Information specific to this transaction is described in futher detail below in the section on Domain Content.

Use Case Roles

Care Manager		Clinical Data Repository
Care Management Data Query

Actor

Care Manager

Role

Requests a collection of clinical data matching the selection criteria from the Clinical Data Repository.

Cooresponding HL7 Version 3 Application Roles

Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)

Actor

Clinical Data Repository

Role

Returns clinical data matching the selection criteria supplied by the Care Manager.

Cooresponding HL7 Version 3 Application Roles

Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)

Referenced Standards

CareRecord	HL7 Care Provision Care Record (DSTU)
CareQuery	HL7 Care Provision Care Record Query (DSTU)
HL7QI	HL7 Version 3 Standard: Infrastructure Management – Query Infrastrucure
HL7WS	HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release
SOAP	Simple Object Access Protocol Version 1.1 (SOAP 1.1)
SOAP12	Simple Object Access Protocol Version 1.2 (SOAP 1.2)

Interaction Diagrams

Get Care Record Profile Query

Trigger Events

When the Care Manager needs to obtain information about a patient or population it will trigger a Get Care Record Care Profile event. This cooresponds to the HL7 trigger event: QUPC_TE043100UV

Message Semantics

The Query Care Record Event Profile Query corresponds to the HL7 Interaction QUPC_IN043100UV.

A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN043100UV.xsd. This schema includes:

• the transmission wrapper MCCI_MT000100UV01,
• the control act wrapper QUQI_MT020001UV01, and
• the message payload QUPC_MT040100UV.

These components of the interaction are specified in the HL7 standards described above.

Transmission Wrapper

The transmission wrapper for PCC-9 is nearly identical to the transmission wrapper used in PCC-1, and appears below.

The transmission wrapper MCCI_MT000100UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<QUPC_IN043100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='QUPC_IN043100UV' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='AL'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <respondTo typeCode="RSP">
   <entityRsp determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' '/>
   </entityRsp>
 </respondTo><controlActProcess>
  See Control Act Wrapper below
 </controlActProcess>
</QUPC_IN043100UV>

<QUPC_IN043100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

<interactionId extension='QUPC_IN043100UV' root='2.16.840.1.113883.5'/>

The identifer for the interaction shall be sent as shown above.

<processingModeCode code='T'/>

The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.

<acceptAckCode code='AL'/>

The acceptAckCode indicates whether the sender wants to recieve an acknowledgement, and shall be sent as shown above.

<respondTo typeCode="RSP">
<entityRsp determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' '/>

This element may be used to indicate the destination of the response when it is other than the sender of the query. The server and port address where the response is being sent shall appear in a URI in the value attribute of the <telecom> element. This element shall only be used in queries that are requesting a response in HL7 Version 2 format.

Control Act Wrapper

The control act wrapper QUQI_MT020001UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction. The controlActProcess element defined for this transaction nearly identical to the same element defined in PCC-1, with variations in the responsePriorityCode, responseModalityCode, and executionAndDeliveryTime elements.

<controlActProcess moodCode="RQO">
  <id root=' ' extension=' '/>
  
  <effectiveTime value=' '/>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  
  <queryByParameter>
    <id root=' ' extension=' '/>
    <statusCode code='new'/>
    <responseModalityCode code='R|B'/>
    <responsePriorityCode code='D'/>
    <initialQuantity value=/>
    <initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'/>
    <executionAndDeliveryTime xsi:type="PIVL_TS">
      <phase value="20080601000000"/>
      <period value='24' unit='h|d|wk|mo|a'/>
    </executionAndDeliveryTime>
    <parameterList>
      see Query Parameter List below
    </parameterList>
  </queryByParameter>
</controlActProcess>

<controlActProcess moodCode="RQO">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "RQO" by the sender to indicate a request to perform an action, in this case, a query.

The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.

<queryByParameter>

HL7 Version 3 messages that perform a query specify the details of it in the <queryByParameter> element.

<id root=' ' extension=' '/>

The sending system shall specify the identifier of the query. This is the identifierr that is used in subsequent continuation or cancel messages.

<statusCode code='new'/>

When passing the parameter list, the <statusCode> element shall be recorded as above to indicate that this is a new query.

<responseModalityCode code='R|B'/>

The query response may be in real-time (R) or batch (B). When the responseModalityCode is set to batch, an executionAndDeliveryTime element shall be sent to identify the schedule for the responses.

<responsePriorityCode code='D'/>

The query response shall always be deferred.

<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883.5'>

The <initialQuantityCode> shall be sent when <initialQuantity> is sent. The code shall be the identifier of the HL7 artifact that is to be counted (e.g., R-MIM or C-MET identifer). In this profile what is being counted is clinical statements, so the code to use shall be REPC_RM000100UV.

Please note, the initial response to this query may include a large number of clinical statements providing historical data for the patients selected by the query. The use of initialQuantityCode allows the Care Manager to control the amount of historical data that the Clinical Data Source sends.

For Public Comment

There is some question here about what to do with the acknowledgement, should it be delayed until the Care Manager has processed or stored the information. What happens with the remaining data? Is a continuation required to be sent to alert the Clinical Data Source that it can send more data?

<executionAndDeliveryTime xsi:type="PIVL_TS">
<phase value="20080601000000"/>
<period value=' ' unit='h|d|wk|mo|a'/>

The <executionAndDeliveryTime> element shall be sent when the responseModalityCode is batch (B). It shall not be sent when the responseModalityCode is real-time (R). The data type for this element shall be set to PIVL_TS to indicate that the batches are to be returned periodically. The period between batches shall be specified in the <period> element, using the unit values described above. The <phase> element may be sent to indicate the time window in which the batch response is expected, either as a single value to indicate the time at which it is scheduled, or as an interval (using <high> and <low> elements) marking the time window in which the response can be sent. Responders will make their best efforts to respond according to the schedule specified, but this profile does not guarantee that they must respond in the specified time frame.

The phase of the schedules is aligned to the appropriate calendar component matching the units specified. To request a batch message to be sent on the first of each month, set the phase to indicate the first day of any month, and the units to "mo".

For Public Comment

How critical is it to address time zone shifts during daylight savings time vs. standard time? If so, how would you recommend dealing with this issue? Is is necessary for the reciever to always be able to expect a message at 1am local time, or is it OK for the reciever to get the message at 1am at some times of the year, and at 2am at others?

Parameter List

The message supports specification of the data items listed in the table below as query parameters. The first column of this table provides the name of the parameter. The next column indicates the number of times it may occur in the query. The next column indicates the type of data expected for the query parameter. The next column indicates the vocabulary domain used for coded values. The Consumer column indicates whether the Care Manager must supply this parameter. The Source column indicates whether the Clinical Data Source must support this parameter.

A Care Manager may supply parameters other than those required by this profile, but must appropriately handle any detected issue alert raised by the Clinical Data Source in its response.

Query Parameters

Parameter Name	Cardinality	Data Type	Vocabulary Domain	Consumer	Source
careProvisionCode	0..1	CD		O	R
careProvisionReason	0..*	CD		O	O
careRecordTimePeriod	0..1	IVL<TS>		O	R
clinicalStatementTimePeriod	0..1	IVL<TS>		O	R
includeCarePlanAttachment	0..1	BL		R	R
maximumHistoryStatements	0..1	INT		O	R
patientAdministrativeGender	0..1	CE	AdministrativeGender	O	R
patientBirthTime	0..1	TS		O	R
patientId	1..1	II		R	R
patientName	0..1	PN		O	R

An example of the query specification is described in the figure below.

 <parameterList>
   <careProvisionCode>
     <value code=' ' displayName=' ' codeSystem=' ' codeSystemName=/>
   </careProvisionCode>
   <careProvisionReason>
     <value code=' ' displayName=' ' codeSystem=' ' codeSystemName=/>
   </careProvisionReason>
   <careRecordTimePeriod>
     <value><low value=' '/><high value=' '/></value>
   </careRecordTimePeriod>
   <clinicalStatementTimePeriod>
     <value><low value=' '/><high value=' '/></value>
   </clinicalStatementTimePeriod>
   <includeCarePlanAttachment><value value='true|false'/></includeCarePlanAttachment>
   <maximumHistoryStatements><value value=' '/></maximumHistoryStatements>
   <patientAdministrativeGender>
     <value code=' ' displayName=' ' 
       codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
   </patientAdministrativeGender>
   <patientBirthTime><value value=' '/></patientBirthTime>
   <patientId><value root=' ' extension=' '/></patientId>
   <patientName><value></value></patientName>
 </parameterList>

<parameterList>

The <parameterList> element shall be present, and contains the set of query parameters being used in this query.

<careProvisionCode><value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/></careProvisionCode>

This <careProvisionCode> may be present. This element describes the information that is being looked for in the <value> element. When the <careProvisionCode> element is not present, it indicates that all relevant results are to be reported up to the maximum number specified in maximumHistoryStatements for each result. To obtain results that have not been coded, the <value> element may be specified with a nullFlavor attribute. There are various flavors of NULL defined in the HL7 NullFlavor vocabulary. A query for results coded using a specific flavor of null shall return all flavors of null that are equal to, or subordinate to that flavor of null within the HL7 hierarchy of null flavors.

A Care Manager can restrict the results returned in the query by setting the value attribute of <value> element in the <careProvisionCode> element to a code identifying the clinical data to be returned. A Clinical Data Source can use the codes specified in the sections below to obtain different kinds of clinical data.

A Care Manager implementing one of the options for that actor shall be able to issue a query using at least one of the codes listed for that information category as specified in the table below. A Clinical Data Source implementing one of these options must support all codes listed in the table below for that information category.

Information Category	Code	Returns	Template Id
Vital Signs	COBSCAT	All Vital Signs	Vital Signs Observation
	Any Code from the Vital Signs Table in the Vital Signs Observation	The vital sign identified by the code	Vital Signs Observation
Problems and Allergies	MEDCCAT	All problem entries	Problem Entry
	CONDLIST	All Concern Entries	Concern Entry
	PROBLIST	All Problem Concerns	Problem Concern
	INTOLIST	All Allergy Concerns	Allergy and Intolerance Concern
	RISKLIST	All Risks1	Concern Entry
Diagnostic Results	LABCAT	All Lab Results	Simple Observations
	DICAT	All Imaging Results	Simple Observations
Medications	RXCAT	All Medications	Medications
	MEDLIST	All Medications	Medications
	CURMEDLIST	All active medications	Medications
	DISCHMEDLIST	Discharge Medications	Medications
	HISTMEDLIST	All Historical Medications	Medications
Immunizations	IMMUCAT	All Immunizations	Immunizations
Professional Services	PSVCCAT	All professional service entries	Encounters Procedures Entry

A Care Manager Actor may make requests using other codes not specified above to obtain other clinical data, but these are not guaranteed to be supported by the Clinical Data Source actor.

Note:

Clinical Data Sources that are grouped with Content Creators are required to support the vocabulary used within the templates defining the content being created!

Querying for Substances

Often, a query needs to identify a particular substance, such as in the case for a query about the use of a specific medication, immunization, or allergy to a given substance. To support these queries, IHE requires that Clinical Data Sources that can respond to queries using appropriate vocabularies for substances use the following form:

<value code='DRUG|IMMUNIZE|INTOL' displayName=' ' codeSystem='1.3.5.1.4.1.19376.1.5.3.2' codeSystemName='IHEActCode'>
  <qualifier>
    <name code='SUBSTANCE|SUBSTCLASS'/>
    <value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>
  </qualifier>
</value>

<value code='DRUG|IMMUNIZE|INTOL' displayName=' ' codeSystem='1.3.5.1.4.1.19376.1.5.3.2' codeSystemName='IHEActCode'>

The <value> element expresses in the code attribute whether the act being queried for is:

Code	Definition
DRUG	Treatment with a specific drug
IMMUNIZ	Immunization of a patient
INTOL	A record of an allergy or intolerance to a substance

One of the values listed above shall be used in the code attribute. The codeSystem shall be recorded as listed above.

<qualifier><name code='SUBSTANCE|SUBSTCLASS'/>

The <qualifier> element further qualifies the concept being requested. The <name> element indicates whether the substance is being described, or the class of substances is being described.

Code	Definition
SUBSTANCE	The substance used
SUBSTCLASS	A class of substances used

<value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>

The <value> element inside the <qualifier> describes the substance or class of substances of interest in the query.

<careProvisionReason><value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/></careProvisionReason>

This element identifies the reason why the result was recorded. If specified, only those results which are recorded for the specified reason will be returned.

The <value> element of the <careProvisionReason> element may contain a value identifying a specific condition that was the reason for obtaining the result or prescribing the medication or immunization. A Clinical Data Source actor that chooses to honor this query parameter shall return only those results that were for the indicated reason. Should the Clinical Data Source Actor not support the use of the <careProvisionReason> element, it shall indicate this by raising the appropriate alert as decribed in the expected actions recorded in PCC-1.

For Public Comment

For immunizations, there is a desire to identify a specific immunization program that was the reason for the immunization, how might an immunization program be referenced? A code might identify the specific pathogen against which the patient is being immunized, but for public health use, a more discrete question is being asked: What program caused the patient to come in for immunization? This seems to require the ability to query for an identifier.

<careRecordTimePeriod><value><low value=' '/><high value=' '/></value></careRecordTimePeriod>

This element describes the time period over which the results were recorded. A query could for example, request new entries that have been processed for this patient since the last query request. If specified, only those results that were authored within the specified time period will be returned.

<clinicalStatementTimePeriod><value><low value=' '/><high value=' '/></value></clinicalStatementTimePeriod>

This element describes the effective time for the clinical statement. If specified, only those results that were effective within the clinical statement effective time will be returned.

The effectiveTime range of the returned clinical statements shall overlap or be wholely contained within the time range described by the <clinicalStatementTimePeriod> element. In the example below, the clinical statements with the effectiveTime values represented by time ranges B, C and D would be returned, while those with effectiveTime values represented by time ranges A and E would not, because they fall outside of the specified <clinicalStatementTimePeriod> value.

Effective Time and Clinical Statement Time Period

<includeCarePlanAttachment><value value='true|false'/></includeCarePlanAttachment>

The <includeCarePlanAttachment> element shall be sent, and must be set to either true or false depending upon whether care plans should be returned or not. A Data Source may choose not to honor this request when the value is set to true, but must then raise a BUS detected issue alert to indicate that this capability is not supported. Note that many data repositories will not associate a care plan attachment with a specific result.

<maximumHistoryStatements><value value=' '/></maximumHistoryStatements>

This value indicates the maximum number of each type of result that will be returned by the query. No more than the maximum number will be returned. This value is NOT the maximum number of clinical statements returned, rather it is the maximum number of clinical statements returned for individual type of clinical statement specified in the careProvisionCode. Thus, if all results are requested (e.g., all Vital Signs), and maximumHistoryStatements/value/@value = 1, you will receive the most current value for each kind of result requested (e.g., one each of the most recent value for height, weight, blood pressure, tempurature, et cetera).

For Public Comment

Does this parameter have any relevance for the Care Manager Actor?

<patientAdministrativeGender>
 <value code=' ' displayName=' ' codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>

The patient gender may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient gender of the patient specified in patientId. If the two values do not match, the Vital Signs Data Source will raise a detected issue alert.

<patientBirthTime><value value=' '/></patientBirthTime>

The patient birth time may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient birth time of the patient specified in patientId. If the two values do not match, the Vital Signs Data Source will raise a detected issue alert.

<patientId><value root=' ' extension=' '/></patientId>

The patient identifier shall be specified in this element. The root and extension attributes shall be present. When used in cross enterprise settings, the root attribute shall the affinity domain identity OID.

Sending a query with a known invalid patientId element can be used to ping a Data Source. For example, setting the root attribute to "0" and omitting the extension attribute should result in a response that raises an ILLEGAL detected issue alert on the patientId field, since the value "0" will never be used as the OID of a patient identity domain. This capability can be used by a Clinical Data Consumer to verify that it can connect to a Data Source when configuration parameters are modified.

The Care Manager may specify a value of * in the extension attribute of the value element to issue the query against the population of patients.

<patientName><value></value></patientName>

The patient name may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient name of the patient specified in patientId. If the two values do not match, the Data Source will raise a detected issue alert.

Expected Actions -- Care Manager

The Care Manager shall send a query as specified in the QUPC_IN043100UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.

The Care Manager shall send an audit message to the audit log repository indicating that a query was initiated, and the parameters of query that were supplied (see the queryByParameter element above).

Expected Actions -- Clinical Data Source

The Clinical Data Source shall send an acknowledgement of the query as specified in the HL7 MCCI_IN000002UV01 interaction in the response to the query message, and shall trigger a QUPC_TE043200UV event to initiate the sending of historical data for all matching patients (see below).

In generating the acknowledgement, the Clinical Data Source shall:

1. Recieve and validate the query message.
2. Create the acknowledgement message.
3. Add an ILLEGAL detected issue alert to the acknowledgement message if the content is invalid (e.g., does not pass schema validation or is otherwise malformed), and immediately return a response indicating the error, and that the query was aborted. Set the text of the alert to the name of the first data element that is not valid. The Clincial Data Source may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the query are not valid.
4. Add a NAT detected issue alert to the acknowledgement message if the requesting party is not authorized to perform the query, and immediately return a response indicating the error, and that the query was aborted.
5. Add a VALIDAT detected issue alert to the acknowledgement message for each of the patientName, patientGenderCode or patientBirthTime fields specified in the query that do not match the values known by the Clinical Data Source Actor. The text value on the alert shall be set to the name of the parameter that does not match (patientName, patientGenderCode or patientBirthTime).
6. Add a BUS detected issue alert to the acknowledgement message if includeCarePlanAttachment is true, but care plans are not associated with observation values. The text value on the alert shall be set to includeCarePlanAttachment.
7. Add a BUS detected issue alert to the acknowledgement message if a careProvisionReason value is specified, but the Clinical Data Source cannot query by this field. The text value on the alert shall be set to careProvisionReason.
8. Add a KEY204 detected issue alert to the acknowledgement message if any of the vocabulary domains are not recognized by the Clinical Data Source. The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
9. Add a CODE_INVALID detected issue alert to the acknowledgement message if any of the codes specified are not recognized by the Clinical Data Source. The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
10. Add a FORMAT detected issue alert to the acknowledgement message if any date ranges are incorrectly formed (low > high). The text value on the alert shall be set to the name of the query parameter that has the error.
11. Add a ILLEGAL detected issue alert to the acknowledgement message if the the Clinical Data Source does not recognize the identity domain used to identify the patient. Set the text value on the alert to patientId.
12. Add a KEY204 detected issue alert to the acknowledgement message if the the Clinical Data Source does not know about the patient. Set the text value on the alert to patientId. This is distinct from having nothing to report. If the patient is recognized but there is no data to report, the result returned should simply have no data. However, if information is requested for a patient that isn't known, then the KEY204 alert shall be raised.
13. Add an appropriate detected issue alert if any parameters otherwise not specified by this profile have been provided, but are not supported by the Clinical Data Source.
14. Add an ISSUE alert to the acknowledgement message if at any time during response generation, an application error occurs that prevents further processing. Set the text of the alert to the reason for the application error (e.g., a stack trace or exception message).

The Clinical Data Source shall send an audit message to the audit log repository indicating that a query was recieved, and the parameters of query that were supplied (see the queryByParameter element above).

The name of the query message shall be QUPC_IN043100UV_Message in the WSDL. The name of the acknowledgement response message shall be MCCI_IN000002UV01 in the WSDL.

The following WSDL snippet defines the types used for this transaction:

Query Message Type Definition

<types> <xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3"> <!-- Include the message schema --> <xsd:include namespace="urn:hl7-org:v3" schemaLocation="QUPC_IN043100UV.xsd"/> <xsd:include namespace="urn:hl7-org:v3" schemaLocation="MCCI_IN000002UV01.xsd"/> </xsd:schema> </types>

The message type is declared to be of the appropriate type by the following WSDL snippet:

Query Message WSDL Declaration

<message name='QUPC_IN043100UV_Message'> <part element='hl7:QUPC_IN043100UV' name="Body"/> </message> <message name='MCCI_IN000002UV01_Message'> <part element='hl7:MCCI_IN000002UV01' name="Body"/> </message>

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:

WSDL Definitions for PCC-9

WSDL Item	Value
wsdl:definitions/@name	CareManager
Get Care Record Query	QUPC_IN043100UV_Message
Message Acknowledgement	MCCI_IN000002UV01_Message
portType	CareManager_PortType
Query Operation	CareManager_QUPC_IN043100UV
SOAP 1.1 binding	CareManager_Binding_Soap11
SOAP 1.1 port	CareManager_Port_Soap11
SOAP 1.2 binding	CareManager_Binding_Soap12
SOAP 1.2 port	CareManager_Port_Soap12

The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Care Manager actor can be found at ftp://ftp.ihe.net/TF_Implementation_Material/PCC/CareManager.wsdl. For a general description of the WSDLs for PCC see the Appendix of the same name in this volume.

Port Type

Port Types for PCC-9

<portType name="CareManager_PortType"> <operation name="CareManager_QUPC_IN043100UV"> <input message="tns:QUPC_IN043100UV_Message" wsaw:Action="urn:hl7-org:v3:QUPC_IN043100UV"/> <output message="MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/> </operation> </portType>

Bindings

SOAP 1.2 Binding for PCC-9

<binding name="CareManager_Binding_Soap12" type="CareManager_PortType"> <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="CareManager_QUPC_IN043100UV"> <wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN043100UV"/> <input> <wsoap12:body use="literal"/> </input> <output> <wsoap12:body use="literal"/> </output> </operation> </binding>

SOAP 1.1 Binding for PCC-9

<binding name="CareManager_Binding_Soap11" type="CareManager_PortType"> <wsoap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="CareManager_QUPC_IN043100UV"> <wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN043100UV"/> <input> <wsoap11:body use="literal"/> </input> <output> <wsoap11:body use="literal"/> </output> </operation> </binding>

V3 Care Management Update

This section corresponds to Transaction PCC-10 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-10 is used by the Care Manager and Clinical Data Repository Actors.

Transaction PCC-10 is a variation of the pattern used in transaction PCC-1 of the PCC Technical Framework. Information specific to this transaction is described in futher detail below in the section on Domain Content.

Use Case Roles

Care Manager		Clinical Data Repository
V3 Care Management Update

Actor

Care Manager

Role

Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction from the Clinical Data Repository.

Cooresponding HL7 Version 3 Application Roles

Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)

Actor

Clinical Data Repository

Role

Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction from the Clinical Data Repository.

Cooresponding HL7 Version 3 Application Roles

Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)

Referenced Standards

CareRecord	HL7 Care Provision Care Record (DSTU)
CareQuery	HL7 Care Provision Care Record Query (DSTU)
HL7QI	HL7 Version 3 Standard: Infrastructure Management – Query Infrastrucure
HL7WS	HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release
SOAP	Simple Object Access Protocol Version 1.1 (SOAP 1.1)
SOAP12	Simple Object Access Protocol Version 1.2 (SOAP 1.2)

Interaction Diagrams

Get Care Record Profile Response

Trigger Events

This message is triggered upon reciept of a Query Care Record Event Profile Query Message. This corresponds to HL7 trigger event: QUPC_TE043200UV

Message Semantics

The Get Care Record Profile Response corresponds to the HL7 Interaction QUPC_IN043200UV. A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN043200UV.xsd. This schema includes:

• the transmission wrapper MCCI_MT000300UV01,
• the control act wrapper MFMI_MT700712UV01, and
• the message payload REPC_MT004000UV.

These components of the interaction are specified in the HL7 standards described above.

Transmission Wrapper

The transmission wrapper MCCI_MT000300UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.

An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction. This message wrapper is similar to the transmission wrapper used for the same interaction in PCC-1, save that the acceptAckCode is different.

<QUPC_IN043200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <id root=' ' extension=' '/>
 <creationTime value=' '/>
 <interactionId extension='QUPC_IN043200UV' root='2.16.840.1.113883.5'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='T'/>
 <acceptAckCode code='AL'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE"> 
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess>
  See Control Act Wrapper below
 </controlActProcess>
</QUPC_IN043200UV>

<QUPC_IN043200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".

<interactionId extension='QUPC_IN043200UV' root='2.16.840.1.113883.5'/>

The identifer for the interaction shall be sent as shown above.

<processingModeCode code='T'/>

The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.

<acceptAckCode code='AL'/>

The acceptAckCode indicates whether the reciever wants to recieve an acknowledgement, and shall be sent as shown above. Query responses in this transaction shall require an acknowledgement.

Control Act Wrapper

The control act wrapper MFMI_MT700712UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O. An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.

<controlActProcess moodCode="EVN">=
  <id root=' ' extension=' '/>
  
  <effectiveTime value=' '/>
  <languageCode code=' '/>
  <authorOrPerformer typeCode=' '></authorOrPerformer>
  <subject>
     See Query Response below
  </subject>
  <queryAck>
    <queryId root=' ' extension=' '/>
    <statusCode code=' '/>
    <queryResponseCode code=' '/>
    <resultCurrentQuantity value=' '/>
    <resultRemainingQuantity value=' '/>
  </queryAck>
</controlActProcess>

<controlActProcess moodCode="EVN">

The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "EVN" by the sender to indicate a response to a query.

The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.

<subject>

The <subject> element shall be present to record the responses in a query request or continuation response.

<queryAck>

The queryAck element is transmitted in any message that is a response to a query, query continuation or query cancellation message.

<queryId root=' ' extension=' '/>

The <queryId> element shall be transmitted in a queryAck element. It shall contain an identifier that was used in the original query message.

<statusCode code=' '/>

The statusCode element in the queryAck element indicates the status of the query. It may contain the value 'deliveredResponse' or 'aborted'. If the value is 'aborted', no additional messages should be sent to the data repository for the specified query.

<queryResponseCode code=' '/>

The queryResponseCode element indicates at a high level the results of performing the query. It may have the value 'OK' to indicate that the query was performed and has results. It may have the value 'NF' to indicate that the query was performed, but no results were located. It may have the value 'QE' to indicate that an error was detected in the incoming query message, or 'AE' to indicate some other application error occurred.

<resultCurrentQuantity value=' '/>

The resultCurrentQuantity element shall be present, and shall enumerate number of results returned in the current response.

<resultRemainingQuantity value=' '/>

This resultRemainingQuantity element may be present. It shall enumerate the number of additional results known to follow the results currently returned. Because these queries have long lifetimes, additional results may be added at any time.

Query Response

The <subject> element of the <controlActProcess> element shall appear as shown in the example below.

<subject>
  <registrationEvent>
    <statusCode code='active'/>
    <custodian>
      <assignedEntity>
        <id root='' extension=''/>
        <addr></addr>
        <telecom></telecom>
        <assignedOrganization>
          <name></name>
        </assignedOrganization>
      </assignedEntity>
    </custodian>
    <subject2>
      <careProvisionEvent>
        <recordTarget>
          <patient>
            <id root='' extension=''/>
            <addr></addr>
            <telecom value='' use=''/>
            <statusCode code='active'/>
            <patientPerson>
              <name></name>
              <administrativeGenderCode code='' displayName='' 
                 codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
              <birthTime value=''/>
            </patientPerson>
          </patient>
        </recordTarget>
        <pertinentInformation3>
           <!-- Domain Content -->
        </pertinentInformation3>
      </careProvisionEvent>
    </subject2>
  </registrationEvent>
</subject>

<subject>

The <subject> element shall be present, and is where the results are returned.

<registrationEvent>

At least one <registrationEvent> element shall be be present for each set of records returned from a different custodial source or patient (in the case of population queries).

The <registrationEvent> is used to record the information about how the <careProvisionEvent> being returned was recorded or "registered" in the custodial system. The response to a Care Profile query is a CareProvisionEvent that is constructed in response to the query. This <careProvisionEvent> is transitory in nature, and is has limited "registration" information content.

A Data Repository that aggregates information from two or more other data repositories shall separate the information into multiple <registrationEvent> elements so as to record the different custodians of the information.

<statusCode code='active'/>

The <statusCode> element records the status of the data records. Queries always return active records, not replaced records, so the value of this element shall always be returned as 'active'. Note that an active record may reference the record that it replaces in the result. The replaced record so referenced does not count towards the number of results returned.

<custodian>

The <custodian> element records the data repository that is the custodian, or "owner", of the data record. A Data Repository actor may return records from multiple custodians, but shall separate the data records from each custodian into different <registrationEvent> elements.

<assignedEntity>

The <assignedEntity> element shall be present, and provides contact and identification information about the <custodian>.

<id root=' ' extension=' '/>

The <id> element shall be present, and shall uniquely identify the custodian of the data records.

<addr></addr>

The <addr> element shall be present, and shall provide a postal address for the custodian of the data records.

<telecom></telecom>

At least one <telecom> element shall be present that provides a telephone number to contact the custodian of the data records. A <telecom> element may be present that provides the web service end-point address of the custodian of the data records.

For Public Comment

How might the web service end-point address be used? Is it a good idea to include it, or should we omit this from the profile?

<assignedOrganization>
 <name></name>
</assignedOrganization>

The name of the organization that is the custodian of the data records shall be provided.

<subject2>

The <subject2> element provides the data content requested from the query.

<careProvisionEvent>

The <careProvisionEvent> elements returned by the Care Record Profile Query are compositions based upon the information requested in the query. It is transitory in nature, and does not necessarily coorespond to a single care provision activity stored within the data repository.

<recordTarget>

The <recordTarget> element records information about the patient for whom the Data Repository is returning results.

<patient>

The <patient> element contains information identifying the patient and providing contact information.

<id root=' ' extension=' '/>

At least one <id> element shall be present that identifies the patient. This <id> element shall be the same as the value of the <patientId> passed in the query. Other <id> elements may be present.

<addr></addr>

At least one <addr> element shall be present to provide a postal address for the patient. It may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).

<telecom value=' ' use=' '/>

At least one <telecom> element shall be present to provide a telephone number to contact the patient. It may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera). Other <telecom> elements may be present to contain other contact methods, e.g., e-mail. One cannot determine from a <telecom> element with the nullFlavor attribute whether it is supposed to contain a telephone number, e-mail address, URL, or other sort of telecommunciations address. Due to this limitation, the assumption will be made that a <telecom> element with a nullFlavor attribute represents a telephone number that is unavailable.

<statusCode code='normal'/>

The <statusCode> element shall be present, and shall be represented exactly as shown above. This indicates that the role of patient is in one of the normal states, e.g., has not been explicitly removed or "nullified".

<patientPerson>

The <patientPerson> element shall be present, and provides further identification information about the patient.

<name></name>

The <name> element shall be present, and normally provides the patient's name. The <name> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).

<administrativeGenderCode code=' ' displayName=' '
 codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>

The <administrativeGenderCode> element shall be present, and normally provides the patient's gender using the HL7 AdministrativeGender vocabulary. The <administrativeGender> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).

<birthTime value=' '/>

The <birthTime> element shall be present, and normally provides the patient's birthTime. The <birthTime> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).

<pertinentInformation3>
 <!-- Domain Content>
<pertinentInformation3>

This data element shall be present. It shall contain one of the data elements found in the Data Repository that matches the specified query parameters. The content of this data element is a care statement that varies depending upon the specific transaction, and is futher defined in the section on Domain Content. Each care statement shall have at least one <author> element that indicates to whom the care statement is attributed. Each care statement may have zero or more <informant> elements that indicates who provided information related to the care statement. See the section below on Authors and Informants for more information on how this information should be recorded.

Expected Actions -- Clinical Data Source

The Clinical Data Source shall send a response as specified in the QUPC_IN043200UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.

The Clinical Data Source shall populate the message with the appropriate responses using the appropriate templates specified in Care Management Data Query under the <careProvisionCode> query parameter.

Expected Actions -- Care Manager

The Care Manager processes the query response data. The Care Manager shall respond with an acknowledgement as specified in the QUPC_IN043200UV interaction.

The name of the query response message shall be QUPC_IN043200UV_Message in the WSDL. The following WSDL snippet defines the type for this message:

Query Response Message Type Definition

<types> <xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3"> <xsd:import namespace="urn:hl7-org:v3" schemaLocation="QUPC_IN043200UV.xsd"/> <xsd:include namespace="urn:hl7-org:v3" schemaLocation="MCCI_IN000002UV01.xsd"/> <xsd:element name="QUPC_IN043200UV"/> </xsd:schema> </types>

The message type is declared to be of the appropriate type by the following WSDL snippet:

Query Respone Message WSDL Declaration

<message name='QUPC_IN043200UV_Message'> <part element='hl7:QUPC_IN043200UV' name="Body"/> </message> <message name='MCCI_IN000002UV01_Message'> <part element='hl7:MCCI_IN000002UV01' name="Body"/> </message>

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:

WSDL Definitions for PCC-10

WSDL Item	Value
wsdl:definitions/@name	ClinicalDataSource
Get Care Record Query Response	QUPC_IN043200UV_Message
Message Acknowledgement	MCCI_IN000002UV01_Message
portType	ClinicalDataSource_PortType
Query Response Operation	ClinicalDataSource_QUPC_IN043200UV
SOAP 1.1 binding	ClinicalDataSource_Binding_Soap11
SOAP 1.1 port	ClinicalDataSource_Port_Soap11
SOAP 1.2 binding	ClinicalDataSource_Binding_Soap12
SOAP 1.2 port	ClinicalDataSource_Port_Soap12

The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Clinical Data Source actor can be found at ftp://ftp.ihe.net/TF_Implementation_Material/PCC/ClinicalDataSource.wsdl. For a general description of the WSDLs for PCC see the Appendix of the same name in this volume.

Port Type

Port Types for PCC-10

<portType name="ClinicalDataSource_PortType"> <operation name="ClinicalDataSource_QUPC_IN043200UV"> <input message="tns:QUPC_IN043200UV_Message" wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV"/> <output message="MCCI_IN000002UV01_Message" wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/> </operation> </portType>

Bindings

SOAP 1.2 Binding for PCC-10

<binding name="ClinicalDataSource_Binding_Soap12" type="ClinicalDataSource_PortType"> <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="ClinicalDataSource_QUPC_IN043200UV"> <wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN043200UV"/> <input> <wsoap12:body use="literal"/> </input> <output> <wsoap12:body use="literal"/> </output> </operation> </binding>

SOAP 1.1 Binding for PCC-10

<binding name="ClinicalDataSource_Binding_Soap11" type="ClinicalDataSource_PortType"> <wsoap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="ClinicalDataSource_QUPC_IN043200UV"> <wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN043200UV"/> <input> <wsoap11:body use="literal"/> </input> <output> <wsoap11:body use="literal"/> </output> </operation> </binding>

V2 Care Management Update

This section corresponds to Transaction PCC-11 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-11 is used by the Care Manager and Clinical Data Repository Actors.

Transaction PCC-11 sends the appropriate HL7 Version 2 message defined by the guideline in the Guideline Notification transaction and that was requested in the Care Management Data Query.

The Clinical Data Source actor must be able to understand what kind of HL7 Version 2 message is being requested when interpreting the Care Management Data Query transaction issued by the Care Manager actor. How HL7 messages are described using the HL7 Version 3 act structure is now described below.

To fully describe an HL7 Version 2 message, this profile makes use of two infrastructure attributes specified on all RIM classes, and the <code> element of the act:

The XML fragment below is an act, in definition mood, that describes the definition of acts of interest to a Care Manager. These acts are represented in a <guideline> element as described in the Guideline Notification transaction. An example appears below:

<actDefinition classCode='ACT' moodCode='DEF'>
  <typeId root='2.16.840.1.113883.12.354' extension='ADT_A01'/>
  <templateId root='2.16.840.1.113883.9.2.2'/>
     :
  
</actDefinition>

typeId

Describes the constraints imposed by a message type definition. In HL7 Version 2, Table 354 identifies the message structures (or types of messages) that can be sent using the HL7 Version 2 standard. This table can be found in Chapter 2 (Control/Query) of the HL7 Version 2 standard. The example above describes the message of interest as using message structure ADT_A01, which is used to convey that a patient has arrived at a facility.

templateId

Describes the constraints imposed by a template definition. Conformance profiles introduced in HL7 Version 2 are templates which further constrain a specific message structure. HL7 makes available a registry of conformance profiles that have been registered with HL7 to its members at http://www.hl7.org/memonly/conformance/. In the example given above, the profile identifer is given in the <templateId> element, and identifies the specific HL7 Conformance profile that further constrains the message.

code

Describes the specific event (or act) which is of interest in the code attribute. The value for the code attribute comes from table 3 of the HL7 Version 2 standard, which is identified using the codeSystem value 2.16.840.1.113883.12.3. In the example above, the act is the trigger event, A01 (Admit/Visit Notification). We further specify that the code (A01) used to identify that act comes from version 2.4 of the specified codeSystem.

Having demonstrated how to represent a kind of HL7 message in a guideline, we next demonstrate how it appears in a query, as shown in the example below.

<parameterList>
   :
  <careProvisionCode>
    <value code='A01' codeSystem='2.16.840.1.113883.12.3' codeSystemVersion='2.4'/>
  </careProvisionCode>
</parameterList>

For Public Comment

As you can see, the <parameterList> element above does not completely identify the act that is of interest (the message to be returned by the Clinical Data Source). There are several approaches we have considered to address this: Create a code system whose values are the template identifiers (or Conformance profile identifiers in this example), an use those template identifiers in the code attribute of the <value> element. This is a hack that will work. Allow the meaning of templateId to be context sensitive, so that in the context of a query parameter, a templateId might simply assert that the expected response to the query would be an item matching that templateId, also a hack that will work. Leave the query for an HL7 V2 response as shown above, with the expectation that the specific conformance profile used to respond to the query will be provided out of band. Our expectation is that the V2 Care Mnaagement Update message will initially require out of band configuration in any case, as the Clinical Data Sources using the HL7 Version 2 Option are not be required to support reciept of the Care Management Data Query transaction.

Use Case Roles

Care Manager		Clinical Data Source
V2 Care Management Update

Actor

Care Manager

Role

Recieves the HL7 Version 2 message matching the selection criteria in a prior PCC-9 transaction, or otherwise configured out of band with the Clinical Data Source.

Actor

Clinical Data Source

Role

Sends the HL7 Version 2 message matching the selection criteria found in a prior PCC-9 transaction from the Clinical Data Repository, or preconfigured.

Referenced Standards

HL7V2.3	HL7 Version 2.3 Messaging Standard
HL7V2.3.1	HL7 Version 2.3.1 Messaging Standard
HL7V2.4	HL7 Version 2.4 Messaging Standard
HL7V2.5	HL7 Version 2.5 Messaging Standard
HL7V2.5.1	HL7 Version 2.5.1 Messaging Standard
CareQuery	HL7 Care Provision Care Record Query (DSTU)
MLLP	Minimal Lower Layer Message Protocol, Release 2

Interaction Diagrams

Send Message

Trigger Events

When the indicated trigger event occurs, or at the times scheduled in the Care Management Data Query transaction, the Clinical Data Source shall send an HL7 Version 2 message, or if requested in the query transaction, the next batch of HL7 Version 2 messages to the recipient indicated in the <respondTo> element of the query.

Message Semantics

The semantics of the message are determined by the HL7 Version 2 Conformance Profile that has been specified for use in the guidelines being applied to the specific use of the Care Management profile (see http://www.hl7.org/memonly/conformance/index.cfm).

The message shall be sent using the HL7 Minimum Lower Layer Protocol (MLLP), as described in ITI TF-2:Appendix C.2 HL7 Implementation Notes

Expected Actions -- Clinical Data Source

Real-Time Mode

1. Upon detection of a qualifying event, the clinical data source shall produce and send the appropriate HL7 Version 2 message for the event to the recipient indicated in the <respondTo> element of the Care Management Data Query) transaction triggering the notification.
2. The Clinical Data Source shall await an acknowledgement of the message.
3. If errors are noted in any of the messages sent in the batch, an operator will be alterted.

Batch Mode

1. The Clinical Data Source shall take note of qualifying events.
2. At the scheduled time (see <executionAndDeliveryTime> in Care Management Data Query), the clinical data source shall produce the appropriate HL7 Version 2 message for each event noted above identified by the query (and guideline).
3. The Clinical Data Source shall send an HL7 Version 2 Batch message to the recipient indicated in the <respondTo> element of the Care Management Data Query) transaction. This message shall contain all of the HL7 Version 2 messages it produced in the previous step. If no messages are produced, it shall produce an empty HL7 Version 2 batch.
4. The Clinical Data Source shall await an acknowledgement of the batch.
5. If errors are noted in any of the messages sent in the batch, an operator will be alterted.

Message Acknowledgement

The Care Manager shall send an acknowledgement indicating that it has recieved the messages.

Trigger Events

The trigger event for the response is the reciept of a new real-time or batch response from the sender.

Message Semantics

Expected Actions -- Care Manager

Real-Time Mode

The Care Manager will validate the message content, and return an acknowledgement to the sender.

Batch Mode

The Care Manager will validate the message content for each message in the batch, and return batch acknowledgement to the sender. The batch acknowledgement shall contain only negative responses.

Expected Actions -- Clinical Data Source

The Clinical Data Source will correct any errors reported by the Care Manager and will resend the corrected messages at the next opportunity.

IHE Patient Care Coordination Bindings

This section describes how the payload used in a transaction of an IHE profile is related to and/or constrains the data elements sent or received in those transactions. This section is where any specific dependencies between the content and transaction are defined.

A content integration profile can define multiple bindings. Each binding should identify the transactions and content to which it applies.

The source for all required and optional attributes have been defined in the bindings below. Three tables describe the three main XDS object types: XDSDocumentEntry, XDSSubmissionSet, and XDSFolder. XDSSubmissionSet and XDSDocumentEntry are required. Use of XDSFolder is optional. These concepts are universal to XDS, XDR and XDM.

The columns of the following tables are:

• <XXX> attribute – name of an XDS attribute, followed by any discussion of the binding detail.
• Optional? - Indicates the required status of the XDS attribute, and is one of R, R2, or O (optional). This column is filled with the values specified in the XDS Profile as a convenience.
• Source Type – Will contain one of the following values:

Source Type	Description
SA	Source document Attribute – value is copied directly from source document. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible.
SAT	Source document Attribute with Transformation – value is copied from source document and transformed. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible. Extended Discussion column must not be empty and the transform must be defined in the extended discussion
FM	Fixed (constant) by Mapping - for all source documents. Source/Value column contains the value to be used in all documents.
FAD	Fixed by Affinity Domain – value configured into Affinity Domain, all documents will use this value.
CAD	Coded in Affinity Domain – a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
CADT	Coded in Affinity Domain with Transform - a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list.
n/a	Not Applicable – may be used with an optionality R2 or O attribute to indicate it is not to be used.
DS	Document Source – value comes from the Document Source actor. Use Source/Value column or Extended Discussion to give details.
O	Other – Extended Discussion must be 'yes' and details given in an Extended Discussion.

• Source/Value – This column indicates the source or the value used.

The following tables are intended to be summaries of the mapping and transforms. The accompanying sections labeled 'Extended Discussion' are to contain the details as necessary.

Medical Document Binding to XDS, XDM and XDR

This binding defines a transformation that generates metadata for the XDSDocumentEntry element of appropriate transactions from the XDS, XDM and XDR profiles given a medical document and information from other sources. The medical document refers to the document being stored in a repository that will be referenced in the registry. The other sources of information include the configuration of the Document Source actor, the Affinity Domain, the site or facility, local agreements, other documents in the registry/repository, and this Content Profile.

In many cases, the CDA document is created for the purposes of sharing within an affinity domain. In these cases the context of the CDA and the context of the affinity domain are the same, in which case the following mappings shall apply.

In other cases, the CDA document may have been created for internal use, and are subsequentyly being shared. In these cases the context of the CDA document would not neccessarily coincide with that of the affinity domain, and the mappings below would not necessarily apply.

Please note the specifics given in the table below.

XDSDocumentEntry Metadata

XDSDocumentEntry Attribute	Optional?	Source Type	Source/ Value
availabilityStatus	R	DS
authorInstitution	R2	SAT	$inst <= /ClinicalDocument/author /assignedAuthor /representedOrganization The authorInstitution can be formated using the following XPath expression, where $inst in the expression below represents the representedOrganization. concat($inst/name)
authorPerson	R2	SAT	$person <= /ClinicalDocument/author The author can be formatted using the following XPath expression, where $person in the expression below represents the author. concat( $person/id/@extension,"^", $person/assignedPerson/name/family,"^", $person/assignedPerson/name/given[1],"^", $person/assignedPerson/name/given[2],"^", $person/assignedPerson/name/suffix,"^", $person/assignedPerson/name/prefix,"^", "^^^&", $person/id/@root,"&ISO")
authorRole	R2	SAT	This metadata element should be based on a mapping of the participation function defined in the CDA document to the set of author roles configured for the affinity domain. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: /ClincicalDocument/author/ participationFunction
authorSpecialty	R2	SAT	This metadata element should be based on a mapping of the code associated with the assignedAuthor to detailed defined classification system for healthcare providers such configured in the affinitity domain. Possible classifications include those found in SNOMED-CT, or the HIPAA Healthcare Provider Taxonomy. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: /ClinicalDocument/author/ assignedAuthor/code
classCode	R	CADT	Derived from a mapping of /ClinicalDocument/code/@code to an Affinity Domain specified coded value to use and coding system. Affinity Domains are encouraged to use the appropriate value for Type of Service, based on the LOINC Type of Service (see Page 53 of the LOINC User's Manual). Must be consistent with /ClinicalDocument/code/@code
classCodeDisplayName	R	CADT	DisplayName of the classCode derived. Derived from a mapping of /ClinicalDocument/code/@code to the appropriate Display Name based on the Type of Service. Must be Consitent with /ClinicalDocument/code/@code
confidentialityCode	R	CADT	Derived from a mapping of /ClinicalDocument/confidentialityCode/@code to an Affinity Domain specified coded value and coding system. When using the BPPC profile, the confidentialyCode may also be obtained from the <authorization> element. /ClinicalDocument/ confidentialityCode/@code -AND/OR- /ClinicalDocument/authorization/ consent[ templateId/@root= '1.3.6.1.4.1.19376.1.5.3.1.2.5' ] /code/@code
comments	O	DS
creationTime	R	SAT	/ClinicalDocument/effectiveTime Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time.
entryUUID	R	DS
eventCodeList	O	CADT	These values express a collection of keywords that may be relevant to the consumer of the documents in the registry. They may come from anywhere in the CDA document, according to its purpose.
eventCodeDisplayNameList	R (if event Code is valued)	CADT	These are the display names for the collection of keywords described above.
formatCode	R	FM	The format code for each PCC Document content profile is provided within the document specifications.
healthcareFacilityTypeCode	R	CAD	A fixed value assigned to the Document Source and configured form a set of Affinity Domain defined values. Must be concistent with /clinicalDocument/code
healthcareFacility TypeCodeDisplay Name	R	CAD	Must be concistent with /clinicalDocument/code
intendedRecipient (for XDR, XDM)	O	SAT	$person <= /ClinicalDocument/intendedRecipient and/or $inst <= /ClinicalDocument/intendedRecipient/receivedOrganization The intendedRecipient can be formated using the following XPath expression, where $inst in the expression below represents the receivedOrganization and where $person in the expression below represents the intendedRecipient. concat( $person/id/@extension,"^", $person/informationRecipient/name/family,"^", $person/informationRecipient/name/given[1],"^", $person/informationRecipient/name/given[2],"^", $person/informationRecipient/name/suffix,"^", $person/informationRecipient/name/prefix,"^", "^^^&", $person/id/@root,"&ISO", "|" $inst/name) "^^^^^&", $inst/id/@root, "&ISO", "^^^^", $inst/id/@extension) -->
languageCode	R	SA	/ClinicalDocument/languageCode
legalAuthenticator	O	SAT	$person <= /ClinicalDocument/ legalAuthenticator The legalAuthenticator can be formatted using the following XPath expression, where $person in the expression below represents the legalAuthenticator. concat( $person/id/@extension,"^", $person/assignedPerson/name/family,"^", $person/assignedPerson/name/given[1],"^", $person/assignedPerson/name/given[2],"^", $person/assignedPerson/name/suffix,"^", $person/assignedPerson/name/prefix,"^", "^^^&", $person/id/@root,"&ISO")
mimeType	R	FM	text/xml
parentDocumentRelationship	R (when applicable)	DS	Local document versions need not always be published, and so no exact mapping can be determined from the content of the CDA document. The parentDocumentRelationship may be determined in some configurations from the relatedDocument element present in the CDA dsocument. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: /ClinicalDocument/relatedDocument/@typeCode
parentDocumentId	R (when parent Document Relationship is present)	DS	Local document versions need not always be published, and so no exact mapping can be determined from the content of the CDA document. The parentDocumentId may be determined in some configurations from the relatedDocument element present in the CDA dsocument. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: $docID <= /ClinicalDocument/ relatedDocument/parentDocument/id The parentDocumentId can be formatted using the following XPath expression, where $docID in the expression below represents the identifier. concat($docID/@root,"^", $docID/@extension)
patientId	R	DS	The XDS Affinity Domain patient ID can be mapped from the patientRole/id element using transactions from the ITI PIX or PDQ profiles. See sourcePatientId below. If the context of the CDA coincides with that of the affinity domain, then the following x-path may be appropriate: $patID <= /ClinicalDocument/recordTarget/ patientRole/id
practiceSettingCode	R	CAD	This elements should be based on a coarse classification system for the class of specialty practice. Recommend the use of the classification system for Practice Setting, such as that described by the Subject Matter Domain in LOINC.
practiceSettingCodeDisplayName	R	CAD	This element shall contain the display names associated with the codes described above.
serviceStartTime	R2	SAT	/ClinicalDocument/documentationOf/ serviceEvent/effectiveTime/low/ @value Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time.
serviceStopTime	R2	SAT	/ClinicalDocument/documentationOf/ serviceEvent/effectiveTime/high/ @value Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time.
sourcePatientId	R	SAT	$patID <= /ClinicalDocument/recordTarget/ patientRole/id The patientId can be formatted using the following XPath expression, where $patID in the expression below represents the appropriate identifier. concat($patID/@extension,"^^^&", $patID/@root, "&ISO")
sourcePatientInfo	R	SAT	/ClinicalDocument/recordTarget/ patientRole The sourcePatientInfo metadata element can be assembled from various components of the patientRole element in the clinical document.
title	O	SA	/ClinicalDocument/title
typeCode	R	CADT	/ClinicalDocument/code/@code The typeCode should be mapped from the ClinicalDocument/code element to a set of document type codes configured in the affinity domain. One suggested coding system to use for typeCode is LOINC, in which case the mapping step can be omitted.
typeCodeDisplay Name	R	CADT	/ClinicalDocument/code/@displayName
uniqueId	R	SAT	$docID <= /ClinicalDocument/id The uniqueId can be formatted using the following XPath expression, where $docID in the expression below represents the identifier. concat($docID/@root,"^", $docID/@extension)

XDSSubmissionSet Metadata

The submission set metadata is as defined for XDS, and is not necessarily affected by the content of the clinical document. Metadata values in an XDSSubmissionSet with names identical to those in the XDSDocumentEntry may be inherited from XDSDocumentEntry metadata, but this is left to affinity domain policy and/or application configuration.

Use of XDS Submission Set

This content format uses the XDS Submission Set to create a package of information to send from one provider to another. All documents referenced by the Medical Summary in this Package must be in the submission set.

Use of XDS Folders

No specific requirements identified.

Configuration

IHE Content Profiles using this binding require that Content Creators and Content Consumers be configurable with institution and other specific attributes or parameters. Implementers should be aware of these requirements to make such attributes easily configurable. There shall be a mechanism for the publishing and distribution of style sheets used to view clinical documents.

Extensions from other Domains

Scanned Documents (XDS-SD)

XDS-SD is a CDA R2 document and thus conforms to the XDS Metadata requirements in the PCC-TF, volume 2, Section 5 unless otherwise specified below.

XDSDocumentEntry

XDS-SD leverages the XDS DocumentEntry Metadata requirements in the PCC-TF, volume 2, Section 5.1.1.1.1 and in PCC_TF-2/Bindings unless otherwise specified below

XDSDocumentEntry.formatCode

The XDSDocumentEntry.formatCode shall be urn:ihe:iti:xds-sd:pdf:2008 when the document is scanned pdf and urn:ihe:iti:xds-sd:text:2008 when the document is scanned text. The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.

XDSDocumentEntry.uniqueId

This value shall be the ClinicalDocument/id in the HL7 CDA R2 header. The root attribute is required, and the extension attribute is optional. In accordance with the XDS.a profile, total length is limited to 128 characters; for XDS.b the limit is 256 characters. Additionally see PCC-TF, volume 2, Section 5.1.1.1.1 or PCC_TF-2/Bindings for further content specification.

Relating instances of XDS-SD documents

In general, most instances of XDS-SD will not have parent documents. It is possible, however, in some specific use cases that instances of XDS-SD documents are related. For example, for a particular document it may be the case that both the PDF scanned content and somewhat equivalent plaintext need to be wrapped and submitted. Each document would correspond to separate XDSDocumentEntries linked via an XFRM Association that indicates one document is a transform of the other. These can be submitted in a single submission set, or in separate ones. Other specific examples may exist and this profile does not preclude the notion of a parent document for these cases.

XDSSubmissionSet

No additional constraints. Particular to this profile, a legitimate use of submission sets would be to maintain a logical grouping of multiple XDS-SD documents. We encourage such usage. For more information, see PCC-TF-2 Section 5.1.1.1.2 or PCC_TF-2/Bindings.

XDSFolder

No additional requirements. For more information, see PCC-TF-2 Section 5.1.1.1.3 or PCC_TF-2/Bindings.

Basic Patient Privacy Consents (BPPC)

Laboratory Reports (XD-LAB)

XD-Lab is a CDA R2 document and thus conforms to the XDS Metadata requirements in the PCC-TF, volume 2, Section 5 unless otherwise specified below.

XDSDocumentEntry

XD-Lab leverages the XDS DocumentEntry Metadata requirements in the PCC-TF, volume 2, Section 5.1.1.1.1 and in PCC_TF-2/Bindings unless otherwise specified below

XDSDocumentEntry.eventCodeList

XD-Lab documents further constrain the the XDSDocumentEntry.eventCodeList to the following.

XDSDocumentEntry

Attribute	Optional?	Source Type	Source/ Value
eventCodeList	R2	SAT	ClinicalDocument / component / structuredBody / component / section / entry / act / entryRelationship / organizer (templateId="1.3.6.1.4.1.19376.1.3.1.1")/ component / observation(templateId="1.3.6.1.4.1.19376.1.3.1.1.1")/code AND ClinicalDocument / component / structuredBody / component / section / entry / act / subject / code If the document has Reportable Condition, then this code shall be among those listed in the eventCodeList. Additionally, if the document contains information about a Non-Human Subject, then the code that indicates what this subject is shall be among those listed in the eventCodeList. Thus, this attribute has been enhanced from the XDS profile from O to R2.

XDSDocumentEntry.formatCode

The XDSDocumentEntry.formatCode shall be urn:ihe:lab:xd-lab:2008 The formatCode codeSystem shall be 1.3.6.1.4.1.19376.1.2.3.

XDSSubmissionSet

No additional constraints. For more information, see PCC-TF-2 Section 5.1.1.1.2 or PCC_TF-2/Bindings.

XDSFolder

No additional requirements. For more information, see PCC-TF-2 Section 5.1.1.1.3 or PCC_TF-2/Bindings.

Namespaces and Vocabularies

This section lists the namespaces and identifiers defined or referenced by the IHE PCC Technical Framework, and the vocabularies defined or referenced herein.

The following vocabularies are referenced in this document. An extensive list of registered vocabularies can be found at http://www.hl7.org/oid/.

Vocabularies Used

codeSystem	codeSystemName	Description
1.3.6.1.4.1.19376.1.5.3.1	IHE PCC Template Identifiers	This is the root OID for all IHE PCC Templates. A list of PCC templates can be found below in CDA Release 2.0 Content Modules.
1.3.6.1.4.1.19376.1.5.3.2	IHEActCode	See IHEActCode Vocabulary below
1.3.6.1.4.1.19376.1.5.3.3	IHE PCC RoleCode	See IHERoleCode Vocabulary below
1.3.6.1.4.1.19376.1.5.3.4		Namespace OID used for IHE Extensions to CDA Release 2.0
2.16.840.1.113883.10.20.1	CCD Root OID	Root OID used for by ASTM/HL7 Continuity of Care Document
2.16.840.1.113883.5.112	RouteOfAdministration	See the HL7 RouteOfAdministration Vocabulary
2.16.840.1.113883.5.1063	SeverityObservation	See the HL7 SeverityObservation Vocabulary
2.16.840.1.113883.5.7	ActPriority	See the HL7 ActPriority Vocabulary
2.16.840.1.113883.6.1	LOINC	Logical Observation Identifier Names and Codes
2.16.840.1.113883.6.96	SNOMED-CT	SNOMED Controlled Terminology
2.16.840.1.113883.6.103	ICD-9CM (diagnosis codes)	International Classification of Diseases, Clinical Modifiers, Version 9
2.16.840.1.113883.6.104	ICD-9CM (procedure codes)	International Classification of Diseases, Clinical Modifiers, Version 9
2.16.840.1.113883.6.26	MEDCIN	A classification system from MEDICOMP Systems.
2.16.840.1.113883.6.88	RxNorm	RxNorm
2.16.840.1.113883.6.63	FDDC	First DataBank Drug Codes
2.16.840.1.113883.6.12	C4	Current Procedure Terminology 4 (CPT-4) codes.
2.16.840.1.113883.6.257	Minimum Data Set for Long Term Care	The root OID for Minimum Data Set Answer Lists
1.2.840.10008.2.16.4	DCM	DICOM Controlled Terminology; PS 3.16 Content Mapping Resource, Annex D
2.16.840.1.113883.6.24	MDC	ISO/IEEE 11073 Medical Device Nomenclature
2.16.840.1.113883.3.26.1.5	NDF-RT	National Drug File Reference Terminology (NCI version)
2.16.840.1.113883.11.19465	nuccProviderCodes	National Uniform Codes Council Healthcare Provider Terminology
2.16.840.1.113883.6.255.1336	X12DE1336	Insurance Type Code (ASC X12 Data Element 1336)
2.16.840.1.113883.6.256	RadLex	RadLex (Radiological Society of North America)

The IHE FormatCode vocabulary is now managed in an Implementation Guide published using FHIR.

• formal canonical URI https://profiles.ihe.net/fhir/ihe.formatcode.fhir/ValueSet-formatcode.html
• formal publication URL https://profiles.ihe.net/fhir/ihe.formatcode.fhir/
• FormatCode gitHub repository for source of the Implementation Guide can be used to register issues, or create pull requests for modifications. Formal governance is managed by ITI Technical Committee.

This FormatCode vocabulary represents:

• Code System 1.3.6.1.4.1.19376.1.2.3
• Value Set 1.3.6.1.4.1.19376.1.2.7.1

IHEActCode Vocabulary

CCD		ASTM/HL7 Continuity of Care Document
CCR		ASTM CCR Implementation Guide

The IHEActCode vocabulary is a small vocabulary of clinical acts that are not presently supported by the HL7 ActCode vocabulary. The root namespace (OID) for this vocabulary is 1.3.6.1.4.1.19376.1.5.3.2. These vocabulary terms are based on the vocabulary and concepts used in the CCR and CCD standards listed above.

Code	Description
COMMENT	This is the act of commenting on another act.
PINSTRUCT	This is the act of providing instructions to a patient regarding the use of medication.
FINSTRUCT	This is the act of providing instructions to the supplier regarding the fulfillment of the medication order.
IMMUNIZ	The act of immunization of a patient using a particular substance or class of substances identified using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
DRUG	The act of treating a patient with a particular substance or class of substances identified using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
INTOL	An observation that a patient is somehow intollerant of (e.g., allergic to) a particular substance or class of substances using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
SUBSTANCE	A qualifier that identifies the substance used to treat a patient in an immunization or drug treatment act. The substance is expected to be identified using a vocabulary such as RxNORM, SNOMED CT or other similar vocabulary and should be specific enough to identify the ingredients of the substance used.
SUBSTCLASS	A qualifier that identifies the class of substance used to treat a patient in an immunization or drug treatment act. The class of substances is expected to be identified using a vocabulary such as NDF-RT, SNOMED CT or other similar vocabulary, and should be broad enough to classify substances by mechanism of action (e.g., Beta Blocker), intended effect (Dieuretic, antibiotic) or ...

For Public Comment

What else needs to appear above for SUBSTCLASS?

IHERoleCode Vocabulary

The IHERoleCode vocabulary is a small vocabulary of role codes that are not presently supported by the HL7 Role Code vocabulary. The root namespace (OID) for this vocabulary is 1.3.6.1.4.1.19376.1.5.3.3.

IHERoleCode Vocabulary

Code	Description
EMPLOYER	The employer of a person.
SCHOOL	The school in which a person is enrolled.
AFFILIATED	An organization with which a person is affiliated (e.g., a volunteer organization).
PHARMACY	The pharmacy a person uses.

HL7 Version 3.0 Content Modules

This section contains content modules based upon the HL7 CDA Release 2.0 Standard, and related standards and/or implementation guides.

CDA Document Content Modules

• (1.3.6.1.4.1.19376.1.5.3.1.1.1)Medical Documents Specification

CDA Header Content Modules

• (1.3.6.1.4.1.19376.1.5.3.1.2.5)PCC CDA Supplement 2:6.3.2.7 Authorization

CDA Section Content Modules

This list defines the sections that may appear in a medical document. It is intended to be a comprehensive list of all document sections that are used by any content profile defined in the Patient Care Coordination Technical Framework. All sections shall have a narrative component that may be freely formatted into normal text, lists, tables, or other appropriate human-readable presentations. Additional subsections or entry content modules may be required.

Impressions

• (1.3.6.1.4.1.19376.1.5.3.1.1.13.2.4)PCC CDA Supplement 2:6.3.3.9.7 Assessments

CDA and HL7 Version 3 Entry Content Modules

•  PCC TF 2:6.3.4.1 Authors and Informants

•  PCC TF 2:6.3.4.2 Linking Narrative and Coded Entries

• (1.3.6.1.4.1.19376.1.5.3.1.4.1)PCC TF 2:6.3.4.3 Severity

• (1.3.6.1.4.1.19376.1.5.3.1.4.1.1)PCC TF 2:6.3.4.4 Problem Status Observation

• (1.3.6.1.4.1.19376.1.5.3.1.4.1.2)PCC TF 2:6.3.4.5 Health Status

• (1.3.6.1.4.1.19376.1.5.3.1.4.2)PCC TF 2:6.3.4.6 Comments

• (1.3.6.1.4.1.19376.1.5.3.1.4.3)PCC TF 2:6.3.4.7 Patient Medication Instructions

• (1.3.6.1.4.1.19376.1.5.3.1.4.3.1)PCC TF 2:6.3.4.8 Medication Fulfillment Instructions

• (1.3.6.1.4.1.19376.1.5.3.1.4.4)PCC TF 2:6.3.4.9 External References

• (1.3.6.1.4.1.19376.1.5.3.1.4.4.1)PCC TF 2:6.3.4.10 Internal References

• (1.3.6.1.4.1.19376.1.5.3.1.4.5.1)PCC TF 2:6.3.4.11 Concern Entry

• (1.3.6.1.4.1.19376.1.5.3.1.4.5.2)PCC TF 2:6.3.4.12 Problem Concern Entry

• (1.3.6.1.4.1.19376.1.5.3.1.4.5.3)PCC TF 2:6.3.4.13 Allergy and Intolerance Concern

• (1.3.6.1.4.1.19376.1.5.3.1.4.5)PCC TF 2:6.3.4.14 Problem Entry

• (1.3.6.1.4.1.19376.1.5.3.1.4.6)PCC TF 2:6.3.4.15 Allergies and Intolerances

• (1.3.6.1.4.1.19376.1.5.3.1.4.7)PCC TF 2:6.3.4.16 Medications

• (1.3.6.1.4.1.19376.1.5.3.1.4.12)PCC TF 2:6.3.4.17 Immunizations

• (1.3.6.1.4.1.19376.1.5.3.1.4.7.3)PCC TF 2:6.3.4.18 Supply Entry

• (1.3.6.1.4.1.19376.1.5.3.1.4.7.2)PCC TF 2:6.3.4.19 Product Entry

• (1.3.6.1.4.1.19376.1.5.3.1.4.13)PCC TF 2:6.3.4.20 Simple Observations

• (1.3.6.1.4.1.19376.1.5.3.1.4.13.1)PCC TF 2:6.3.4.21 Vital Signs Organizer

• (1.3.6.1.4.1.19376.1.5.3.1.4.13.2)PCC TF 2:6.3.4.22 Vital Signs Observation

• (1.3.6.1.4.1.19376.1.5.3.1.4.15)PCC TF 2:6.3.4.23 Family History Organizer

• (1.3.6.1.4.1.19376.1.5.3.1.4.13.4)PCC TF 2:6.3.4.24 Social History Observation

• (1.3.6.1.4.1.19376.1.5.3.1.4.13.3)PCC CDA Supplement 2:6.3.4.25 Family History Observation

• (1.3.6.1.4.1.19376.1.5.3.1.4.13.5)PCC CDA Supplement 2:6.3.4.26 Pregnancy Observation

• (1.3.6.1.4.1.19376.1.5.3.1.4.13.7)PCC CDA Supplement 2:6.3.4.29 Advance Directive Observation

• (1.3.6.1.4.1.19376.1.5.3.1.4.14)PCC CDA Supplement 2:6.3.4.31 Encounters

• (1.3.6.1.4.1.19376.1.5.3.1.4.19)PCC CDA Supplement 2:6.3.4.33 Procedure Entry

• (1.3.6.1.4.1.19376.1.5.3.1.1.12.3.1)PCC CDA Supplement 2:6.3.4.38 Pain Score Observation

Appendix A - Examples Using PCC Content Profiles

Example documents conforming to each profile can be found on the IHE wiki at the following URLs.

Profile and Content	URL
XDS-MS
Referral Summary	XDSMS Example1
Discharge Summary	XDSMS Example1
XPHR
XPHR Content	XPHR Example1
XPHR Update	XPHR Example2
(EDR) ED Referral	EDR Example
(APS) Antepartum Summary	APS Example
(EDES)
Triage Note	EDES Example1
ED Nursing Note	EDES Example2
Composite Triage and Nursing Note	EDES Example3
ED Physician Note	EDES Example4
(FSA) Functional Status Section	FSA Example

Appendix B - Validating CDA Documents using the Framework

Many of the constraints specified by the content modules defined in the PCC Technical Framework can be validated automatically by software. Automated validation is a very desirable capability, as it makes it easier for implementers to test the correctness of their implementations. With regard to validation of the content module, the PCC Technical Framework narrative is the authoritative specification, not any automated software tool. Having said that, it is still very easy to create a validation framework for the IHE PCC Technical Framework using a XML validation tool such as Schematron. Since each content module has a name (the template identifier), any XML instance that reports itself to be of that "class" can be validated by creating assertions that must be true for each constraint indicated for the content module. In the XML representation, the <templateId> element is a child of the element that is claiming conformance to the template named. Thus the general pattern of a Schematron that validates a specific template is shown below:

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <pattern name='ReferralSummary'>
    <rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.3]"'>
      <!-- one or more assertions made by the content module -->
    </rule>
  </pattern>
</schema>

Validating Documents

For document content modules, the pattern can be extended to support common document content module constraints as shown below:

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <pattern name='ReferralSummary'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.3]"'>
      <!-- Verify that the template id is used on the appropriate type of object -->
      <assert test='../ClinicalDocument'>
        Error: The referral content module can only be used on Clinical Documents.
      </assert>
      <!-- Verify that the parent templateId is also present. -->
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.2"]'>
        Error: The parent template identifier for medical summary is not present.
      </assert>
      <!-- Verify the document type code -->
      <assert test='code[@code = "34133-9"]'>
        Error: The document type code of a referral summary must be
        34133-9 SUMMARIZATION OF EPISODE NOTE.
      </assert>
      <assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
        Error: The document type code must come from the LOINC code 
        system (2.16.840.1.113883.6.1).
      </assert>
      <!-- Verify that all required data elements are present -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: A referral summary must contain a reason for referral.
      </assert>
      <!-- Alert on any missing required if known elements -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.8"]'>
        Warning: A referral summary should contain a list of history of past illnesses.
      </assert>
      <!-- Note any missing optional elements -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.18"]'>
        Note: This referral summary does not contain the pertinent review of systems.
      </assert>
    </rule>
  </pattern>
</schema>

Validating Sections

The same pattern can be also applied to sections with just a few minor alterations.

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <pattern name='ReasonForReferralUncoded'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
      <!-- Verify that the template id is used on the appropriate type of object -->
      <assert test='section'>
        Error: The coded reason for referral module can only be used on a section.
      </assert>
      <assert test='false'>
        Manual: Manually verify that this section contains narrative providing the
        reason for referral.
      </assert>
      <!-- Verify that the parent templateId is also present. -->
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: The parent template identifier for the reason for referral 
        module is not present.
      </assert>
      <!-- Verify the section type code -->
      <assert test='code[@code = "42349-1"]'>
        Error: The section type code of the reason for referral section must be 42349-1
        REASON FOR REFERRAL.
      </assert>
      <assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
        Error: The section type code must come from the LOINC code 
        system (2.16.840.1.113883.6.1).
      </assert>
  </pattern>
  <pattern name='ReasonForReferralCoded'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.2"]'>
      <!-- The parent template will have already verified the type of object -->
      <!-- Verify that the parent templateId is also present. -->
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: The parent template identifier for the reason for referral 
        module is not present.
      </assert>
      <!-- Don't bother with the section type code, as the parent template caught it -->
      <!-- Verify that all required data elements are present -->
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.13"]'>
        Error: A coded reason for referral section must contain an simple observation.
      </assert>
      <!-- Alert on any missing required if known elements -->
      <!-- Note any missing optional elements -->
    </rule>
  </pattern>
</schema>

A similar pattern can also be followed for Entry and Header content modules, and these are left as an exercise for the reader.

Phases of Validation and Types of Errors

Note that each message in the Schematrons shown above start with a simple text string that indicates whether the message indicates one of the following conditions:

• An error, e.g., the failure to transmit a required element,
• A warning, e.g., the failure to transmit a required if known element,
• A note, e.g., the failure to transmit an optional element.
• A manual test, e.g., a reminder to manually verify some piece of content.

Schematron supports the capability to group sets of rules into phases by the pattern name, and to specify which phases of validation should be run during processing. To take advantage of this capability, one simply breaks each <pattern> element above up into separate patterns depending upon whether the assertion indicates an error, warning, note or manual test, and then associate each pattern with a different phase. This is shown in the figure below.

<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
  <ns prefix="cda" uri="urn:hl7-org:v3" />
  <phase id="errors">
    <active pattern="ReasonForReferralUncoded_Errors"/>
    <active pattern="ReasonForReferralCoded_Errors"/>
  </phase>
  <phase id="manual">
    <active pattern="ReasonForReferralUncoded_Manual"/>
  </phase>
  <pattern name='ReasonForReferralUncoded_Errors'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
      <assert test='section'>
        Error: The coded reason for referral module can only be used on a section.
      </assert>
      <assert test='code[@code = "42349-1"]'>
        Error: The section type code of the reason for referral section must be 42349-1
        REASON FOR REFERRAL.
      </assert>
      <assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
        Error: The section type code must come from the LOINC code 
        system (2.16.840.1.113883.6.1).
      </assert>
    </rule>
  </pattern>
  <pattern name='ReasonForReferralUncoded_Manual'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
      <assert test='false'>
        Manual: Manually verify that this section contains narrative providing the
        reason for referral.
      </assert>
  </pattern>
  <pattern name='ReasonForReferralCoded_Errors'>
    <rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.2"]'>
      <assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
        Error: The parent template identifier for the reason for referral not present.
      </assert>
      <assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.13"]'>
        Error: A coded reason for referral section must contain an simple observation.
      </assert>
    </rule>
  </pattern>
</schema>

Using these simple "templates" for template validation one can simply create a collection of Schematron patterns that can be used to validate the content modules in the PCC Technical Framework. Such Schematrons are expected to be made available as part of the MESA test tools that are provided to IHE Connectathon participants, and which will also be made available to the general public after connectathon.

Appendix C - Extensions to CDA Release 2.0

This section describes extensions to CDA Release 2.0 that are used by the IHE Patient Care Coordination Technical Framework.

IHE PCC Extensions

All Extensions to CDA Release 2.0 created by the IHE PCC Technical Committee are in the namespace urn:ihe:pcc:hl7v3.

The approach used to create extension elements created for the PCC Technical Framework is the same as was used for the HL7 Care Record Summary (see Appendix E) and the ASTM/HL7 Continuity of Care Document (see secion 7.2).

replacementOf

The <replacementOf> extension element is applied to a section appearing in a PHR Update Document to indicate that that section's content should replace that of a previously existing section. The identifier of the previously existing section is given so that the PHR Manager receiving the Update content will know which section to replace. The model for this extension is shown below.

Model for replacementOf

Use of this extension is shown below. The <replacementOf> element appears after all other elements within the <section> element. The <id> element appearing in the <externalDocumentSection> element shall provide the identifier of the section being replaced in the parent document.

Example use of the replacementOf extension

<section> <id root=' ' extension=' '/> <title>Name of the Section</title> <text>Text of the section</text> <entry></entry> <component></component> <pcc:replacementOf xmlns:pcc='urn:ihe:pcc:hl7v3'> <pcc:externalDocumentSection> <pcc:id root='58FCBE50-D4F2-4bda-BC1C-2105B284BBE3'/> <pcc:externalDocumentSection/> </pcc:replacementOf> </section>

Extensions Defined Elsewhere used by IHE PCC

Entity Identifiers

There is often a need to record an identifer for an entity so that it can be subsequently referenced. This extension provides a mechnism to store that identifier. The element appears after any <realm>, <typeId> or <templateId> elements, but before all others in the entity where it is used:

<playingEntity classCode='ENT' determinerCode='INSTANCE'>
 <sdtc:id root='1.3.6.4.1.4.1.2835.2' extension='EntityID'/>
   :
   .
</playingEntity>

Patient Identifier

There is a need to record the identifer by which a patient is known to another healthcare provider. This extension provides a role link between the assigned, related or associated entity, and the patient role.

Use of this extension to record the identifier under which the patient is known to a provider is shown below.

Example use of the Patient Identifier Extension

<assignedEntity> <id extension='1' root='1.3.6.4.1.4.1.2835.1'/> <addr> <streetAddressLine>21 North Ave</streetAddressLine> <city>Burlington</city> <state>MA</state> <postalCode>01803</postalCode> <country>USA</country> </addr> <telecom value='tel:(999)555-1212' use='WP'/> <assignedPerson> <name> <prefix>Dr.</prefix><given>Bernard</given><family>Wiseman</family><suffix>Sr.</suffix> </name> </assignedPerson> <sdtc:patient xmlns:sdtc='urn:hl7-org:sdtc' > <sdtc:id root='1.3.6.4.1.4.1.2835.2' extension='PatientMRN'/> </sdtc:patient> </assignedEntity>

The <patient> element records the link between the related, assigned or associated entity and the patient. The <id> element provides the identifier for the patient. The root attribute of the <id> should be the namespace used for patient identifiers by the entity. The extension attribute of the <id> element shall be the patient's medical record number or other identifier used by the entity to identify the patient.