Introduction

This is a draft of the Query for Existing Data Profile (QED) supplement to the Patient Care Coordination Technical Framework. This draft is a work in progress, not the official supplement or profile.

Profile Abstract

The Query for Existing Data Profile (QED) supports dynamic queries for Clinical Data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems within and across enterprises to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.

Glossary

Clinical Data Repository: A Clinical Data Repository (CDR) is a database of clinical information on patients, often optimized for access by individual patients.

Volume I

Add the following bullet to the list of profiles

Query for Existing Data - This profile (QED) supports dynamic queries for Clinical Data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems within and across enterprises to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.

Dependencies

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

Integration Profile	Dependency	Dependency Type	Purpose
Query for Existing Data	Audit Trail and Node Authentication	Each actor in this profile shall be grouped with the ATNA Secure Node or Secure Application actor.	Required to manage audit trail of exported PHI, node authentication, and transport encryption.
Query for Existing Data	Consistent Time	Each actor in this profile shall be grouped with the Time Client Actor	Required to manage and resolve conflicts in multiple updates.

Query for Existing Data Profile (QED)

The Query for Existing Data Profile (QED) supports dynamic queries for clinical data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems within and across enterprises to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.

Classification of Information

The QED profile classifies information into six different categories for the purpose of determining where it might be found.

Common Observations: These are a collection of simple measurements or reported values that can be determined using simple measuring devices (e.g., Height, Weight), or which can be reported by the patient (date of last menstrual period). These measurements do NOT include anything that might be recorded as a problem, allergy, risk, or which requires interpretation, clinical decision making, or diagnostic quality equipment or procedures for performing the measurement.

Diagnostic Results: These are a collection of observations made or performed using laboratory testing equipment, imaging procedures, vision examinations, et cetera.

Problems and Allergies: These are a collection of diagnoses, clinical findings, allergies, or other risk factors that are recorded for the patient. The information may be obtained from patient reports, or through clinical decision making. It includes such information as would be found in social and family history sections of clinical reports. This classfication can be further subdivided into three groups.

Conditions: This is a collection of disease conditions for the patient.
Intolerances: This is a collection of the patient's allergies and other intolerances.
Risk Factors: This is a collection of the patients significant risk factors, as might be established based on a review of family history, social history, occupational exposures, et cetera. By themselves, they may not be indicitave of a disease condition, but could contribute to one.

Medications: This is a collection of the medications that a patient is or has been taking for treatment of one or more conditions.

Immunizations: This is a collection of immunizations that have been given, or which are planned to be given to the patient.

Professional Services: This is a collection of procedures and/or encounters which the patient has participated in, or is expected to participate in.

Each of these major classifications of information can often be found in distinct repositories of information. For example, patient vital signs, problems and allergies may be recorded in simple EHR sytem; diagnostic results in a laboratory or radiology information system; medications in a pharmacy information system, immunizations in an immunization registry, and professional services in a practice management system.

Actors/Transaction

There are six actors in this profile, the Clinical Data Consumer, and five different repositories of clinical data, including vitals, problems and allergies, diagnostic results, medications, and immunizations.

Query for Existing Data Actor Diagram

For Public Comment

The Vital Signs Data Repository should probably become the Common Observations Data Repository, because it should be able to contain more than just vital signs measurements.

The table below lists the transactions for each actor directly involved in the Query for Existing Data Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled 'R'). Transactions labeled 'O' are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed below under Options.

Query for Existing Data Actors and Transactions
Actor	Name	Optionality	Transaction
Clinical Data Consumer	Query Vital Signs	O¹	PCC-1
	Query Problems and Allergies	O¹	PCC-2
	Query Diagnostic Data	O¹	PCC-3
	Query Medications	O¹	PCC-4
	Query Immunizations	O¹	PCC-5
Vital Signs Data Repository	Query Vital Signs	R	PCC-1
Problems and Allergies Repository	Query Problems and Allergies	R	PCC-2
Diagnostic Data Repository	Query Diagnosic Data	R	PCC-3
Medications Repository	Query Medications	R	PCC-4
Immunizations Repository	Query Immunizations	R	PCC-5

Note ¹: The Actor shall support at least one of these transactions.

Options

Query for Existing Data Options
Actor	Option
Clinical Data Source	None Defined
Clinical Data Consumer	Vital Signs Option
	Problems and Allergies Option
	Diagnostic Data Option
	Medications Option
	Immunizations Option

Vital Signs Option

A Clinical Data Consumer that implements the Vital Signs Option implements the Query Vital Signs transaction.

Problems and Allergies Option

A Clinical Data Consumer that implements the Problems and Allergies Option implements the Query Problems and Allergies transaction.

Diagnostic Data Option

A Clinical Data Consumer that implements the Diagnostic Data Option implements the Query Diagnostic Data transaction.

Medications Option

A Clinical Data Consumer that implements the Medications Option implements the Query Medications transaction.

Immunizations Option

A Clinical Data Consumer that implements the Immunizations Option implements the Query Immunizations transaction.

Grouping

Clinical Data Repositories

Any of the repository actors of this profile can be grouped with other repository actors. For example, an EMR might implement all of the repository actors of this profile, while a pharmacy system might implement only the Immunizations and Medications Repository actors.

When actors are grouped in this fashion, it is expected that they will provide appropriate join fields to show relationships between different records. For example, when a EMR groups together the Medication Data Repository and Problems and Allergies Data Repository, and recieves a request for Medications, it should also return the Problems, and internal references to those problems that are the reason for prescribing the medication.

Audit Trail and Node Authentication and Consistent Time

All actors of this profile shall be grouped with either the Secure Node or the Secure Application actor, to ensure the security of the information being exchanged. These actors shall also implement Time Client to ensure that consistent time is maintained across systems.

TBD -- what specifically are the logging requirements under this profile

Login/Logout
Actor Start/Stop
Query
Import (if the reciever imports the queried data)
Export

Retrieve Form for Data Capture

A Clinical Data Consumer actor may be grouped with an Form Filler or Form Manager actor to appropriately populate forms with recently gathered clinical data.

Cross Enterprise Document Sharing

A Repository actor may be grouped with a Cross Enterprise Document Repository actor. Data gathered from clinical documents submitted to the Document Repository can be a source of information returned by the Repository actor. Information returned by the Repository shall include references to all documents used in generating the results.

Content Integration Profiles

A Content Creator may be grouped with a Clinical Data Consumer to obtain some or all of the information necessary to create a Medical Summary based on information found in a Repository.

Patient Identity Cross Referencing and Patient Demographics Query

A clinical data consumer may be grouped with a Patient Identifier Cross-reference Consumer or a Patient Demographics Consumer actor to resolve patient identifiers prior to submitting queries to a Repository.

Within an enterprise, the need to cross-reference patient identifiers may not be necessary. However, once enterprise boundaries are crossed, these identifiers will need to be resolved. In that case either PIX or PDQ shall be used.

Process Flow

Query for Existing Data Process Flow

Clinical Trials

A patient participating in a clinical trial arrives for a trial-related visit to a physician office. The physician completes a report in his/her EMR gathering information relevant to the trial. Upon completion of the visit, a research assistant gathers the data relevant to the trial and submits it to the clinical trial information system. Among the data needed to gather are the patient's current medications.

The research assistant logs into the clinical trial information system, and enters data about the patient visit pertinent to the trial. The clinical trial information system performs a query of the EMR using [PCC-4] where the patient data is stored, and obtains the list of the patient's current medications.

Claims

A claims administrator begins a claim for treatment of a patient who is pregnant. They log into their practice management system to begin processing the claim. Since this claim is for services provided during pregnancy, a patient measurement is needed to complete the claim. The practice management / billing system queries the EMR for the date of last menstruation for the patient using [PCC-1], and completes the claim.

Drug Safety

Medication is about to be administered at a modality. Prior to administration, the modality queries the EMR for current problems and allergies and medications using PCC-3 and PCC-4 to enable display of this information to the operator, or to send to a decision support system to determine if this medication is OK to administer.

A CPOE system needs to generate a medication order for a patient for a medication whose dosage is based on weight. Prior to generating the order, the system will query the EMR for the most recent weight measurements of the patient to determine the correct dose using [PCC-1]. The system also request information about the patient's current problems and allergies using [PCC-3], and medications using [PCC-4] to perform drug interaction checking before completing the order.

Public Health, Biosurveillance, and Disease Registries

During a routine pediatric visit, an EMR queries an immunization registry for the immunization history for the patient using [PCC-5]. Upon review of the information, it appears that on a recent visit, the patient was scheduled for immunization, but the immunization was not given due to a current fever. The fever ius not longer present, so the immunization is given to the patient.

Upon completion of the visit, a reporting application is notified. The reporting application queries the EMR visit data to see if any immunizations were given during the just completed visit using [PCC-5]. If an immunization was given during the visit, the reporting application collects the appropriate data and submits it to an immunization registry.

Identifying Qualifying Patients

Decision support systems can query the EMR to obtain specific data elements for a patient, and use that information to determine if the patient qualifies for a clinical trial, or if the visit is one that requires additional reporting.

Upon completion of a visit, the EMR activates a decision support system. The decision support system queries the EMR for patient diagnoses using PCC-3. Upon determining that the patient has been diagnosed with Diabetes, the decision support system notifies the EMR that it needs to activate protocols for diabetic care. This use case could be continued as described in the section below.

Quality Reports and Disease Management

Upon completion of a visit, certain quality measures need to be gathered in order to produce an aggregate measure. A quality system can query the EMR to determine for each patient the values that need to be measured.

A diabetic patient completes a routine visit. The EMR queries a Lab Result Repository using PCC-2 to determine if a recent HgA1C result is available from the last six months using [PCC-2]. Upon failing to find one the EMR system notifies the physician that an updated HgA1C test is required.

Disease Management

A physician wants to monitor a patient's blood sugar levels and body mass index. She requests a graph of the patient's blood sugar lab results (lab) and BMI (vital signs) for the past 9 months from a desktop application. The desktop application queries the EMR for the selected vital signs for the indicated time period using PCC-1, and graphs the data appropriately.

Actor Definitions

Clinical Data Consumer: A clinical data consumer makes use of clinical patient data.
Vital Signs Data Repository: A Vital Signs Data Repository maintains patient vital signs data.
Problems and Allergies Repository: A Problems and Allergies Repository maintains patient problem and allergy data.
Diagnostic Data Repository: A Diagnostic Data Repository Repository maintains results from diagnostic tests (e.g., Lab, Imaging, or other test results).
Medications Data Repository: A Medications Data Repository maintains patient medication data.
Immunizations Data Repository: An Immunizations Data Repository maintains patient immunization data.

Transaction Definitions

Query Vital Signs: Request information about recent patient measurements, usually used to obtain vital signs measurements. The query may request all measurements, or those taken for a specific encounter, or date range, or may be for a specific set of measurements.
Query Problems and Allergies: Request information about problems or allergies known for a patient, usually to determine the patients current problems and allergies. The query may request information about all problems, all allergies, or may request information on a specific problem or allergy entry, entered during a specific encounter or date range.
Query Diagnostic Data: Request information about diagnostic results known for a patient. The query may request information about all diagnostic results, or may request information on a specific diagnostic result entry, or one entered for a specific encounter or date range.
Query Medications: Request information about medications given to, or being taken by a patient. The query may request information about all medications or may request information on a specific kind of medication or immunization, or one entered for a specific encounter or date range.
Query Immunizations: Request information about immunizations given to a patient. The query may request information about all immunizations, all immunizations or may request information on a specific kind of medication or immunization, or one entered for a specific encounter or date range.

Volume II

Document Sharing

This section corresponds to Transaction PCC-1 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-1 is used by the Clinical Data Consumer and Clinical Data Source Actors.

Use Case Roles

Clinical Data Consumer		Clinical Data Source
Document Sharing

Actor

Clinical Data Consumer

Role

Requests a list of vital signs matching a minimal set of selection criteria from the Vitals Signs Repository.

Cooresponding HL7 Version 3 Application Roles: Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)

Actor

Clinical Data Source

Role

Returns clinical data matching the selection criteria supplied by the Clinical Data Consumer.

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 Clinical Data Consumer needs to obtain information about a patient 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 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>
 <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.

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 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'/>

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 Consumer column indicates whether the Clinical Data Consumer must supply this parameter.  The Source column indicates whether the Clinical Data Source must support this parameter.  
A Clinical Data Consumer 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.




Parameter Name
Cardinality
Data Type
Vocabulary Domain
Consumer
Source

Query Parameters


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 Clinical Data Consumer 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 Clinical Data Consumer 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 Risks¹
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 Clinical Data Consumer 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.

<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 -- Clinical Data Consumer

The clinical data consumer 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 name of the query response message shall be QUPC_IN043100UV_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:import namespace="urn:hl7-org:v3"
      schemaLocation="QUPC_IN043100UV.xsd"/>
    <xsd:element name="QUPC_IN043100UV"/>
  </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>

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

Get Care Record Profile ResponseTrigger Events

This message is triggered upon reciept of a Query Care Record Event Profile Query, or General Query Activate Query Continue or General Query Query Cancel 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.

<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='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_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='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 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 Source 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.

<resultTotalQuantity value=' '/>

The resultTotalQuantity element should be present, and if so, enumerates the number of results found. It shall be present once the last result has been located by the Data Source. This element gives the count of the total number of results located by the query. When present, the resultRemainingQuantity element shall also be present.

<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, and shall be present if resultTotalQuantity is present. It shall enumerate the number of results that follow the results currently returned.

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>
      <parameterList>
      </parameterList>
    </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.  
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 Source 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 shall only return active records, not replaced records, so the value of this element shall always be returned as 'active'.

<custodian>

The <custodian> element records the Data Source that is the custodian, or "owner", of the data record.  A Data Source 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.

<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 Source.

<recordTarget>

The <recordTarget> element records information about the patient for whom the Data Source 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 Source that matches the specified query parameters. The content of this data element is a care statement that varies depending upon the specific query.  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 on Authors and Informants for more information on how this information should be recorded.

<parameterList>

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

Expected Actions -- Data Source

The 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 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_IN043200UV_Message'>
   <part element='hl7:QUPC_IN043200UV' name="Body"/>
 </message>

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

Response to a New Query

The Data Source, shall:

Recieve and validate the query message.
Create the response message.
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 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.
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.
Add a VALIDAT detected issue alert to the response message for each of the patientName, patientGenderCode or patientBirthTime fields specified in the query that do not match the values known by the Vital Signs 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).
Add a BUS detected issue alert to the response 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.
Add a BUS detected issue alert to the response message if a careProvisionReason value is specified, but the Data Source cannot query by this field.  The text value on the alert shall be set to careProvisionReason.
Add a KEY204 detected issue alert to the response message if any of the vocabulary domains are not recognized by the Data Source.  The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
Add a CODE_INVALID detected issue alert to the response message if any of the codes specified are not recognized by the Data Source.  The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
Add a FORMAT detected issue alert to the response 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.
Add a ILLEGAL detected issue alert to the response message if the the Data Source does not recognize the identity domain used to identify the patient.  Set the text value on the alert to patientId.
Add a KEY204 detected issue alert to the response message if the the 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.
Add an appropriate detected issue alert if any parameters otherwise not specified by this profile have been provided, but are not supported by the Data Source.
If any issues were detected, Set queryAck/statusCode/@code to aborted, and queryAct/queryResponse/@code to QE, and return the response.
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.
Query for the data requested by the query.
If results are found, set queryAct/queryResponse/@code to OK, otherwise set it to NF.
Set queryAck/statusCode/@code to deliveredResponse.
Add any results to the response up to the maximum number of history statements requested.
If all results have been returned, release the query results.

A conforming Data Source shall support those parameters that have an R in the Repository column from the table above, and need not support those query parameters that have an O in this column.

Response to a Query Continuation

The Data Source, shall:

Recieve and validate the query continuation message.
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 Data Source may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the continuation are not valid.
Create the response message.
Add a KEY204 detected issue alert to the response message if the the Data Source does not recognize the queryId.
Add a VALIDAT detected issue alert to the response message if the query was previously aborted or otherwise terminated.
Add an appropriate detected issue alert if any parameters otherwise not specified by this profile have been provided, but are not supported by the Data Source.
If any issues were detected, Set queryAck/statusCode/@code to aborted, and queryAct/queryResponse/@code to QE, and return the response.
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.
Scroll to the result requested in queryContinuation/startResultNumber, querying additional data if necessary.
If more results are found, set queryAct/queryResponse/@code to OK, otherwise set it to NF.
If no more results are found, ensure that the queryAck/resultTotalQuantity indicates the toal number of results found.
Set queryAck/statusCode/@code to deliveredResponse.
Add any results to the response up to the maximum number of history statements requested.
Return the response message.
Release query results if no additional messages on the query are recieved within an application configurable timeout value.

Response to a Query Cancel

The Data Source, shall:

Recieve and validate the query cancelation message.
Create the response message.
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 Data Source may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the cancellation are not valid.
Add a KEY204 detected issue alert to the response message if the the Data Source does not recognize the queryId.
Add an appropriate detected issue alert if any parameters otherwise not specified by this profile have been provided, but are not supported by the Data Source.
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 queryAck/statusCode/@code to aborted,
If any application errors were detected, set the queryAct/queryResponse/@code to AE, otherwise, if any other issues were detected, set the value to QE, otherwise set it to NF.
Return the response message.
Release query results.

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 clinical data consumer processes the query response data.  If the response indicates that more data is available, the clinical data consumer can request additional data using the General Query Activate Query Continue message, indicating which data is being requested.

General Query Activate Query ContinueTrigger Events

When a Clinical Data Consumer needs to obtain more results from a query, it will trigger the continuation of the query. This cooresponds the the HL7 trigger event: QUQI_TE000003UV01

Message Semantics

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

the transmission wrapper MCCI_MT000300UV01, and
the control act wrapper  QUQI_MT000001UV01.

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.

<QUQI_IN000003UV01 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='QUQI_IN000003UV01' 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>
</QUQI_IN000003UV01>

<QUQI_IN000003UV01 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='QUQI_IN000003UV01' 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 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>
  <queryContinuation>
    <queryId root=' ' extension=' '/>
    <statusCode code='waitContinuedQueryResponse'/>
    <startResultNumber value=' '/>
    <continuationQuantity value=' '/>
  </queryContinuation>
</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 continuation of a query.

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

Continuation Request<queryContinuation>

The queryContinuation element shall be sent in messages that are used to obtain more query results or cancel a current query.

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

The identifier of the query to continue or cancel shall be reported in the queryId element.

<statusCode code='waitContinuedQueryResponse'/>

The statusCode element shall be sent, and indicates that this is a continuation of the query.

<startResultNumber value=' '/>

The startResultNumber element may be sent to indicate the query result to start returning from. If this element is sent, it shall be honored by the Data Source. If this element is omitted, results will be sent that follow the last set of results sent. Results are numbered from 1, so setting this value to 1 will start with the first result returned. Setting this value to a number less than 1 will result in undefined application behavior.

<continuationQuantity value=' '/>

The continuationQuantity element may be sent on continuation requests to indicate the number of addition records to return.  If sent it shall have a value greater than 0. The Data Source may send fewer results than requested, but shall send no more than this value.

Expected Actions -- Clinical Data Consumer

Upon completion of all result processing, the clinical data consumer shall send a General Query Query Activate Continue message to obtain additional results.
The Data Source shall send a response as specified in the QUQI_IN000003UV01 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 QUQI_IN000003UV01_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="QUQI_IN000003UV01.xsd"/>
     <xsd:element name="QUQI_IN000003UV01"/>
   </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='QUQI_IN000003UV01_Message'>
   <part element='hl7:QUQI_IN000003UV01' name="Body"/>
 </message>

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

General Query Query CancelTrigger Events

When the Clinical Data Consumer is finished with the query, it shall cancel the query.  This cooresponds the the HL7 trigger event:QUQI_TE000003UV01 -- General Query Activate Query Continue

Message Semantics

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

the transmission wrapper MCCI_MT000300UV01, and
the control act wrapper  QUQI_MT000001UV01.

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.  The transmission wrapper used in the Query Cancel message is the same as the transmission wrapper used in the Query Continuation message described in the previous section.

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 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>
  <queryContinuation>
    <queryId root=' ' extension=' '/>
    <statusCode code='aborted'/>
    <startResultNumber value=' '/>
    <continuationQuantity value='0'/>
  </queryContinuation>
</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 continuation of a query.

The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.
incoming query message, or 'AE' to indicate some other application error occurred.

Cancellation Request<queryContinuation>

The queryContinuation element shall be sent in messages that are used to obtain more query results or cancel a current query.

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

The identifier of the query to continue or cancel shall be reported in the <queryId> element.

<statusCode code='aborted'/>

The statusCode element shall be sent as shown above, and indicates that this is a continuation of the query.

<startResultNumber value=' '/>

The startResultNumber element shall not be sent in a cancellation request.

<continuationQuantity value=' 0'/>

The continuationQuantity element shall be sent and shall have a value 0 to indicate a cancellation.

Expected Actions -- Clinical Data Consumer

When finished with all query results, the clinical data consumer shall send a General Query Query Cancel message to cancel the query. 
The name of the query response message shall be QUQI_IN000003UV01_Message in the WSDL, and this is declared as shown above for the Query Continue message. Other WSDL declarations required for this transaction are defined under the Domain Content section.

Get Care Record Profile Response

A Clinical Data Source Actor shall respond to a query request by returning matching clinical statements within <pertinentInformation3> elements.
All information returned shall specify the author or authors of the returned information in a subordinate <author> element, and may indicate the informants in <informant> elements.

Common Observations and Vital Signs

The following rules applied to a Clincial Data Source supporting the Vital Signs option.
When careProvisionCode is set to COBSCAT from the HL7 ActCode vocabulary domain, a Clinical Data Source supporting shall respond by returning all matching observations that coorespond to the LOINC code values from the table in Vital Signs Observation.  It shall also respond to any of the individual LOINC codes found in that table to return specific kinds of vital signs measurements.  The observations returned shall conform the the PCC Vital Signs Observation entry template.
A Clinical Data Source Actor may respond to requests using other LOINC codes to return other common observations.  These observations shall conform to the Simple Obervations entry template.  For example, a Clinical Data Source Actor may respond to a query request where the LOINC code matches any individual LOINC code found in the table in the Pregnancy Observations with clinical statements conforming to that entry template.

Problems and Allergies

The following rules applied to a Clincial Data Source supporting the Problems and Allergies option.
The clinical statements that are returned for codes specified in the table above in the section on careProvisionCode shall conform to the template identifiers shown therein.
A Clinical Data Source actor may respond to query requests using other codes to return information about specific problem, allergy or risk observations.  These observations shall conform to the Problem Entry or Allergy and Intolerance Entry

Medications

The following rules applied to a Clincial Data Source supporting the Medications option.
Clinical statements representing medications that are returned by this transaction shall conform to the Medications template.

Immunizations

The following rules applied to a Clincial Data Source supporting the Immunizations option.
Clinical statements representing medications that are returned by this transaction shall conform to the Immunizations template.

Professional Services

A Clincia Data Source Actor shall respond to a query request for Professional Services by returning clinical statements matching the query parameter returned within <pertinentInformation3> data elements. 
The clinical statements containing Professional Services shall shall conform to the templates shown above.

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:


WSDL Definitions for PCC-1


WSDL Item
Value


wsdl:definitions/@name
ClinicalDataSource


Get Care Record Profile Query
QUPC_IN043100UV_Message


Get Care Record Profile Response
QUPC_IN043200UV_Message


General Query Activate Continue / Cancel
QUQI_IN000003UV01_Messsage


portType
ClinicalDataSource_PortType


Query Operation
ClinicalDataSource_QUPC_IN043100UV


Continue Operation
ClinicalDataSource_QUQI_IN000003UV01_Continue


Cancel Operation
ClinicalDataSource_QUQI_IN000003UV01_Cancel


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 implementing the QED profile can be found at ftp://ftp.ihe.net/Patient_Care_Coordination/yr3_2007-2008/resources/Query.zip.  For a general description of the WSDLs for QED see the Appendix of the same name in this volume.

Port Type





<portType name="ClinicalDataSource_PortType">
 <operation name="ClinicalDataSource_QUPC_IN043100UV">
   <input message="tns:QUPC_IN043100UV_Message"
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043100UV"/>
   <output message="tns:QUPC_IN043200UV_Message" 
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV "/>
 </operation>
 <operation name="ClinicalDataSource_QUQI_IN000003UV01_Continue">
   <input message="tns:QUQI_IN000003UV01_Message"
     wsaw:Action="urn:hl7-org:v3:QUQI_IN000003UV01"/>
   <output message="tns:QUPC_IN043200UV_Message" 
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV "/>
 </operation>
 <operation name="ClinicalDataSource_QUQI_IN000003UV01_Cancel">
   <input message="tns:QUQI_IN000003UV01_Message"
     wsaw:Action="urn:hl7-org:v3:QUQI_IN000003UV01"/>
   <output message="tns:QUPC_IN043200UV_Message" 
     wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV "/>
 </operation>
</portType>


Port Types for PCC-1

Bindings





<binding name="ClinicalDataSource_Binding_Soap12" 
   type="ClinicalDataSource_PortType">
 <wsoap12:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="ClinicalDataSource_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.2 Binding for PCC-1





<binding name="ClinicalDataSource_Binding_Soap11" 
   type="ClinicalDataSource_PortType">
 <wsoap11:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="ClinicalDataSource_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>


SOAP 1.1 Binding for PCC-1

PCC-2

The functionality of this transaction was incorporated into PCC-1 as a result of a Change Proposal.  This transaction is now reserved.

PCC-3

The functionality of this transaction was incorporated into PCC-1 as a result of a Change Proposal.  This transaction is now reserved.

PCC-4

The functionality of this transaction was incorporated into PCC-1 as a result of a Change Proposal.  This transaction is now reserved.

PCC-5

The functionality of this transaction was incorporated into PCC-1 as a result of a Change Proposal.  This transaction is now reserved.

Appendix D - Sending HL7 Version 3 Messages



For Public Comment

This appendix and Appendix O of the ITI Technical Framework overlap in content.  If you are reviewing this profile, we would like your feedback on the content of this appendix and of the ITI Appendix.  Appendix O of the ITI Technical Framework can be found in the PIX/PDQ Version 3 Profile



HL7 Version 3 messages are sent in XML.  Each message has information related to:

Messaging Infrastructure
Control Act
Domain Content

The first two components are described in greater detail below.  Domain content is decribed in further detail within the IHE Profiles.

Message Infrastructure

This section of the message conveys information about the message itself, including:

The message identity
Creation time of the message
The message type
Processing controls on the message
Identity of the sending and recieving systems
The control act which is being conveyed in the message

An example message illustrating the message infrastructure elements is shown below.

<HL7Interaction 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='HL7Interaction' root='2.16.840.1.113883'/>
 <processingCode code='D|P|T'/>
 <processingModeCode code='A|T|I|R'/>
 <acceptAckCode code='AL|ER|NE'/>
 <receiver typeCode="RCV">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <desc/>
     <existenceTime><low value=' '/></existenceTime>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </receiver>
 <sender typeCode="SND">
   <device determinerCode="INSTANCE">
     <id/>
     <name/>
     <desc/>
     <existenceTime><low value=' '/></existenceTime>
     <telecom value=' ' />
     <manufacturerModelName/>
     <softwareName/>
   </device>
 </sender>
 <controlActProcess>
  See Control Act Process below
 </controlActProcess>
</HL7Interaction>

<HL7Interaction 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".

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

Each message shall be uniquely identified.  The root attribute is required, the extension attribute may be used if the root attribute is insufficient to uniquely identify the message instance.

<creationTime value=' '/>

The creationTime indicates when the message was created, and shall be sent with a timestamp that is precise to at least 1/100th of a second.

<interactionId extension='HL7Interaction' root='2.16.840.1.113883'/>

The identifer for the interaction shall be sent.  The extension value shall be valued with the HL7 Interaction identifier specified within the standard.  The root attribute shall be set to the value 2.16.840.1.113883 to identify this as an HL7 interaction.

<processingCode code='D|P|T'/>

The processingCode element identifiers whether this message is being sent for debugging, production or training respectively.  It shall be present and have one of the values D, P or T, as shown above.

<processingModeCode code='A|T|I|R'/>

The processingModeCode distinguishes the type of processing being performed, using the values A, T, I or R for Archive, current processing, Initial load, or Restore from archive respectively.  This element shall be present and have one of the values shown above.

<acceptAckCode code='AL|ER|NE'/>

The acceptAckCode indicates whether the reciever wants to recieve an acknowledgement Always (AL), only on errors (ER), or never (NE).  Unless reliable message transport has been established through some other mechanism, any message that would result in the potential alteration of clinical data shall be sent with the acceptAckCode set to AL, and any message that performs queries or is otherwise non-destructive should be set the value to 'ER' or 'AL'.

<receiver typeCode="RCV">
<sender typeCode='SND'/>

The reciever and sender elements shall be used to identify the systems responsible for recieving and sending the messages.

<id/>

The id element is required and identifies the sender or reciever of the message.

<name/>

The name element may be sent to provide a human readable name for the sender or reciever.

<existenceTime><low value=' '/></existenceTime>

The existenceTime element may be set by the sender on the sender element, or by the reciever on the reciever element to indicate the time at which the sending or recieving process was last started.  The sender should not set this value for the reviever, and visa-versa.

<telecom value=' ' />

The telecommunications address for the sender and/or reciever may be sent.  This address is the URL at which the sender or reciever is originating or recieving messages.  The URL shall be the URL of the appropriate web service end-point.

<manufacturerModelName/>

The manufacturer model name may be set by the sender or reciever to indicate a human readable description of the manufacturer model name of the sending or recieving device.  Once again, the senders and recievers should only set these values for themselves.

<softwareName/>

The software name may be set by the sender or reciever to indicate a human readable description of the software being used to send or recieve the message.  Once again, the senders and recievers should only set these values for themselves.

Control Act Process

This section of the message identifies the action and provides information the business actors related to the transaction.  This includes:

The author or performer of the act
The information recipients to who the information will be conveyed
The domain content related to the act

 <controlActProcess moodCode="RQO|EVN">
   <id root=' ' extension=' '/>
   <code code='QUPC_TE043100UV'/>
   <effectiveTime value=' '/>
   <languageCode code=' '/>
   <authorOrPerformer typeCode=' '></authorOrPerformer>
   <informationRecipient typeCode=' '></informationRecipient>
   <!-- Performing a Query -->
   <queryByParameter>
     <statusCode code='new'/>
     <initialQuantity value=' '/>
     <initialQuantityCode code=' ' codeSystem='2.16.840.1.113883'>
     <parameterList>
       :
       Domain Content
     </parameterList>
   </queryByParameter>
   <!-- Returning Results -->
   <subject>
      :
      Domain Content
   </subject>
   <!-- Any response to a query (returning results, acknowledging a cancelation, or returning an error -->
   <queryAck>
     <queryId root=' ' extension=' '/>
     <statusCode code=' '/>
     <queryResponseCode code=' '/>
     <resultTotalQuantity value=' '/>
     <resultCurrentQuantity value=' '/>
     <resultRemainingQuantity value=' '/>
   </queryAck>
   <!-- Requesting more results or cancelling a query -->
   <queryContinuation>
     <queryId root=' ' extension=' '/>
     <statusCode code='waitContinuedQueryResponse|aborted'/>
     <startResultNumber value=' '/>
     <continuationQuantity value=' '/>
   </queryContinuation>
   </queryContinuation>
 </controlActProcess>

<controlActProcess moodCode="RQO|EVN">

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.  The reciever will often return a new controlActProcess element in moodCode "EVN" to indicate that the act has been performed.

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

Each control act may have a unique identifier, recorded in the id element.  The root attribute must be present.  The extension attribute may be present to further distinguish the identifier.

<code code='QUPC_TE043100UV'/>

The trigger event which caused the act to be transmitted shall be recorded in the code element.

<effectiveTime value=' '/>

The date and time of the trigger event shall be recorded in the effectiveTime of the control act.  This is timestamp is distinct from the time of message transmission in the transmission wrapper.

<languageCode code=' '/>

The primary language used within the message content is identified in the languageCode element.  This element shall be present.

<authorOrPerformer typeCode=' '></authorOrPerformer>

This element may be present to identify the business actors responsible for the message transmission.

<informationRecipient typeCode=' '></informationRecipient>

This element may be present to identify the business actors expected to recieve the result of the message.

Performing a Query<queryByParameter>

For HL7 Version 3 messages that perform a query, the query is specified in the <queryByParameter> element.

<statusCode code='new'/>

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

<initialQuantity value=' '/>

The <initialQuantity> element may be present to specify the initial number of data elements to be returned.  The responder must send no more than the specified number of data elements in the response, but may send fewer than requested.

<initialQuantityCode code=' ' codeSystem='2.16.840.1.113883'>

The <initialQuantityCode> element indicates hoow responses are counted.  This element must be specified when the <initialQuantity> element is present.  It indicates the HL7 structures to count when determining the total number of data elements to return.  The code is the identifier of the HL7 artifact to count (i.e., the R-MIM or C-MET identifier).  Each query should indicate what structures are counted within the detail of the transaction.  The rationale for counting based on HL7 structures is that each query is expected to return one or more "rows", and each row is expected to coorespond to an HL7 structure that is being returned.

<parameterList>

The <parameterList> data element shall be provided.  This data element contains a domain specific set of parameters.  These parameters will be described in the transaction detail.

Returning Results

<subject>
 Domain Content
</subject>

For typical HL7 version 3 messages, the domain content is accessible through the subject element, as is the domain content that is generated in response to a query.

<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 may be used in subsquent messages to obtain more results, or to cancel the query.

<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.  Finally, it may have the value 'QE' to indicate that an error was detected in the incoming query message.

<resultTotalQuantity value=' '/>

The resultTotalQuantity element should be present, and if so, enumerates the number of results found.  It shall be present once the last result has been located by the data repository.
This element gives the count of the total number of results located by the query.  When present, the resultRemainingQuantity element shall also be present.

<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, and shall be present if resultTotalQuantity is present.  It shall enumerate the number of results that follow the results currently returned.

Continuation or Cancellation of a Query<queryContinuation>

The queryContinuation element shall be sent in messages that are used to obtain more query results or cancel a current query.

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

The identifier of the query to continue or cancel shall be reported in the queryId element.

<statusCode code='waitContinuedQueryResponse|aborted'/>

The statusCode element shall be sent, and indicates whether this is a continuation or cancellation of the query.  If the query is to be continued, the code attribute shall be set to waitContinuedQueryResponse.  If the query is to be canceled, it shall be set to aborted.

<startResultNumber value=' '/>

The startResultNumber element may be sent to indicate the query result to start returning from.  If this element is sent, it shall be honored by the data repository.  If this element is omitted, results will be sent that follow the last set of results sent.  Results are numbered from 1, so setting this value to 1 will start with the first result returned.  Setting this value to a number less than 1 will result in undefined application behavior.

<continuationQuantity value=' '/>

The continuationQuantity element shall be sent on cancelation requests, and shall have a value of 0.  For continuation requests, this element may be sent to indicate the number of results that should be returned.  The data repository may send fewer results than requested, but shall send no more than this value.

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

Information Category	Code	Returns	Template Id
Vital Signs	COBSCAT	All Vital Signs	Vital Signs Observation
Vital Signs	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 Risks¹	Concern Entry
Diagnostic Results	LABCAT	All Lab Results	Simple Observations
Diagnostic Results	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

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

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

WSDL Item	Value
wsdl:definitions/@name	ClinicalDataSource
Get Care Record Profile Query	QUPC_IN043100UV_Message
Get Care Record Profile Response	QUPC_IN043200UV_Message
General Query Activate Continue / Cancel	QUQI_IN000003UV01_Messsage
portType	ClinicalDataSource_PortType
Query Operation	ClinicalDataSource_QUPC_IN043100UV
Continue Operation	ClinicalDataSource_QUQI_IN000003UV01_Continue
Cancel Operation	ClinicalDataSource_QUQI_IN000003UV01_Cancel
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

Query for Existing Data

Introduction

Profile Abstract

Glossary

Volume I

Dependencies

Query for Existing Data Profile (QED)

Classification of Information

Actors/Transaction

Options

Vital Signs Option

Problems and Allergies Option

Diagnostic Data Option

Medications Option

Immunizations Option

Grouping

Clinical Data Repositories

Audit Trail and Node Authentication and Consistent Time

Retrieve Form for Data Capture

Cross Enterprise Document Sharing

Content Integration Profiles

Patient Identity Cross Referencing and Patient Demographics Query

Process Flow

Clinical Trials

Claims

Drug Safety

Public Health, Biosurveillance, and Disease Registries

Identifying Qualifying Patients

Quality Reports and Disease Management

Disease Management

Actor Definitions

Transaction Definitions

Volume II

Document Sharing

Use Case Roles

Referenced Standards

Interaction Diagrams

Get Care Record Profile Query

Trigger Events

Message Semantics

Transmission Wrapper

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

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

<processingModeCode code='T'/>

<acceptAckCode code='AL'/>

Control Act Wrapper

<controlActProcess moodCode="RQO">

<queryByParameter>

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

<statusCode code='new'/>

<responseModalityCode code='R'/>

<responsePriorityCode code='I'/>

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

Parameter List

<parameterList>

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

<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=' '/>

<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'/>

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

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

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

Expected Actions -- Clinical Data Consumer

Get Care Record Profile Response

Trigger Events

Message Semantics

Transmission Wrapper

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

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

<processingModeCode code='T'/>

<acceptAckCode code='NE'/>

Control Act Wrapper

<controlActProcess moodCode="EVN">

<subject>

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

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

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

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