PCC TF-1/QED
Volume 1
HIMSS and RSNA
Integrating the Healthcare Enterprise
IHE Patient Care Coordination
Query for Existing Data (QED)
Technical Framework Supplement
Volume I
Revision 3.0
2008-2009
Public Comment
- (PCC TF-1/Preface)Preface to Volume I of the PCC Technical Framework
- (PCC TF-1/Introduction)Introduction to the PCC Technical Framework
- (PCC TF-1/About)About the Patient Care Coordination Integration Profiles
- (PCC TF-1/Dependencies)Dependencies of the PCC Integration Profiles
- (PCC TF-1/Overview)PCC Integration Profiles Overview
- (PCC TF-1/History)History of Annual Changes
- (PCC TF-1/Product Implementations)Product Implementations
Query for Existing Data Integration Profile (QED)
The Query for Existing Data Profile (QED) supports dynamic queries for clinical data, , including vital signs, problems, medications, immunizations, diagnostic results, procedures and visit history. 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.
Technical Approach
The QED profile leverages the existing content modeling defined previously in other IHE document profiles and the HL7 CCD implementation guide to deliver information that is semantically equivalent as a web service using the IHE ITI web services and HL7 web services guidelines.
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 two actors in this profile, the Clinical Data Consumer and the Clinical Data Source.
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.
| Actor | Name | Optionality | Transaction |
|---|---|---|---|
| Clinical Data Consumer | Query Existing Data | R | PCC-1 |
| Clinical Data Source | Query Existing Data | R | PCC-1 |
Note 1: The Actor shall support at least one of these transactions.
Options
| Actor | Option |
|---|---|
| Clinical Data Source | Vital Signs Option (1) |
| Problems and Allergies Option (1) | |
| Diagnostic Data Option (1) | |
| Medications Option (1) | |
| Immunizations Option (1) | |
| Professional Services Option (1) | |
| Clinical Data Consumer | Vital Signs Option (1) |
| Problems and Allergies Option (1) | |
| Diagnostic Data Option (1) | |
| Medications Option (1) | |
| Immunizations Option (1) | |
| Professional Services Option (1) |
(1) At least one of these options shall be supported by the Actor
Vital Signs Option
A Clinical Data Consumer that implements the Vital Signs Option implements the Query Existing Data transaction using the specified vocabulary to query for vital signs. A Clinical Data Source that implements the Vital Signs Option responds to all vocabulary specified in PCC-1 for vital signs.
Problems and Allergies Option
A Clinical Data Consumer that implements the Problems and Allergies Option implements the Query Existing Data transaction using the specified vocabulary to query for problems or allergies or both. A Clinical Data Source that implements the Problems and Allergies Option responds to all vocabulary specified in PCC-1 for problems and allergies.
Diagnostic Data Option
A Clinical Data Consumer that implements the Diagnostic Data Option implements implements the Query Existing Data transaction using the specified vocabulary to query for diagnostic data. A Clinical Data Source that implements the Diagnostic Data Option responds to all vocabulary specified in PCC-1 for Diagnostic Data.
Medications Option
A Clinical Data Consumer that implements the Medications Option implements the Query Existing Data transaction using the specified vocabulary to query for medications. A Clinical Data Source that implements the Medications Option responds to all vocabulary specified in PCC-1 for medications.
Immunizations Option
A Clinical Data Consumer that implements the Immunizations Option implements the Query Existing Data transaction using the specified vocabulary to query for immunizations. A Clinical Data Source that implements the Immunizations Option responds to all vocabulary specified in PCC-1 for immunizations.
Professional Services Option
A Clinical Data Consumer that implements the Professional Services Option implements the Query Existing Data transaction using the specified vocabulary to query for professional services or both. A Clinical Data Source that implements the Professional Services Option responds to all vocabulary specified in PCC-1 for professional services.
Grouping
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.
Retrieve Form for Data Capture
When grouped with an Form Filler or Form Manager actor, a Clinical Data Consumer Actor shall appropriately populate forms with recently gathered clinical data.
Cross Enterprise Document Sharing
A Clincial Data Source 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 Clinical Data Source actor. Information returned by the Clinical Data Source 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 Clinical Data Source.
A Content Creator may be grouped with a Clinical Data Source. When grouped with a Content Creator, the Clinical Data Source Actor shall respond to queries containing the relevant vocabulary codes used by the Content Creator.
| Note: | This may create additional vocabulary requirements on applications implementing the Clinical Data Source profile and another IHE content profile! |
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
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. During the information gathering process, forms are populated with the list of the patient's current medications viaby a query of the EMR where the patient data is stored using [PCC-1]. Information gathered by these forms in then stored in the clinical trial information system.
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. It may also query the EMR for details of the procedures performed using [PCC-1].
Drug Safety
Medication to be administered for a radiology procedure may cause an allergic reaction in some patients. The RIS can query the EMR for current problems and allergies and medications using [PCC-1] 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 and medications 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-1]. 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-1]. 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-1]. 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-1] to determine if a recent HgA1C result is available from the last six months. 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.
- Clinical Data Source
- A Clinical Data Sources maintains patient information about vital signs, problem and allergies, results from diagnostic tests (e.g., Lab, Imaging, or other test results), medications, immunizations or historical or planned visits and procedures.
Transaction Definitions
- Query Existing Data
- Request information about recent patient information, used to obtain vital signs measurements, problems and allergies, diagnostic results, medications, immunizations, or procedures or visits relevant for a patient. The query may request information about some or all of the above topics, or may request information on a specific topic, or one entered for a specific encounter or date range.
Volume II
HIMSS and RSNA
Integrating the Healthcare Enterprise
IHE Patient Care Coordination
Query for Existing Data (QED)
Technical Framework Supplement
Volume II
Revision 3.0
2008-2009
Public Comment
- (PCC TF-2/Preface)Preface
- (PCC TF-2/Introduction)Introduction
IHE Transactions
This section defines each IHE transaction in detail, specifying the standards used, and the information transferred.
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
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 Risks1
Concern Entry
Diagnostic Results
LABCAT
All Lab Results
Simple Observations
DICAT
All Imaging Results
Simple Observations
Medications
RXCAT
All Medications
Medications
MEDLIST
All Medications
Medications
CURMEDLIST
All active medications
Medications
DISCHMEDLIST
Discharge Medications
Medications
HISTMEDLIST
All Historical Medications
Medications
Immunizations
IMMUCAT
All Immunizations
Immunizations
Professional Services
PSVCCAT
All professional service entries
Encounters
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 Response
Trigger 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 Continue
Trigger 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 Cancel
Trigger 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.
PCC-6
The functionality of this transaction was incorporated into PCC-1 as a result of a Change Proposal. This transaction is now reserved.
Namespaces and Vocabularies
This section lists the namespaces and identifiers defined or referenced by the IHE PCC Technical Framework, and the vocabularies defined or referenced herein.
The following vocabularies are referenced in this document. An extensive list of registered vocabularies can be found at http://www.hl7.org/oid/.
Vocabularies Used
codeSystem
codeSystemName
Description
1.3.6.1.4.1.19376.1.5.3.1
IHE PCC Template Identifiers
This is the root OID for all IHE PCC Templates. A list of PCC templates can be found below in CDA Release 2.0 Content Modules.
1.3.6.1.4.1.19376.1.5.3.2
IHEActCode
See IHEActCode Vocabulary below
1.3.6.1.4.1.19376.1.5.3.3
IHE PCC RoleCode
See IHERoleCode Vocabulary below
1.3.6.1.4.1.19376.1.5.3.4
Namespace OID used for IHE Extensions to CDA Release 2.0
2.16.840.1.113883.10.20.1
CCD Root OID
Root OID used for by ASTM/HL7 Continuity of Care Document
2.16.840.1.113883.5.112
RouteOfAdministration
See the HL7 RouteOfAdministration Vocabulary
2.16.840.1.113883.5.1063
SeverityObservation
See the HL7 SeverityObservation Vocabulary
2.16.840.1.113883.5.7
ActPriority
See the HL7 ActPriority Vocabulary
2.16.840.1.113883.6.1
LOINC
Logical Observation Identifier Names and Codes
2.16.840.1.113883.6.96
SNOMED-CT
SNOMED Controlled Terminology
2.16.840.1.113883.6.103
ICD-9CM (diagnosis codes)
International Classification of Diseases, Clinical Modifiers, Version 9
2.16.840.1.113883.6.104
ICD-9CM (procedure codes)
International Classification of Diseases, Clinical Modifiers, Version 9
2.16.840.1.113883.6.26
MEDCIN
A classification system from MEDICOMP Systems.
2.16.840.1.113883.6.88
RxNorm
RxNorm
2.16.840.1.113883.6.63
FDDC
First DataBank Drug Codes
2.16.840.1.113883.6.12
C4
Current Procedure Terminology 4 (CPT-4) codes.
2.16.840.1.113883.6.257
Minimum Data Set for Long Term Care
The root OID for Minimum Data Set Answer Lists
1.2.840.10008.2.16.4
DCM
DICOM Controlled Terminology; PS 3.16 Content Mapping Resource, Annex D
2.16.840.1.113883.6.24
MDC
ISO/IEEE 11073 Medical Device Nomenclature
2.16.840.1.113883.3.26.1.5
NDF-RT
National Drug File Reference Terminology (NCI version)
2.16.840.1.113883.11.19465
nuccProviderCodes
National Uniform Codes Council Healthcare Provider Terminology
2.16.840.1.113883.6.255.1336
X12DE1336
Insurance Type Code (ASC X12 Data Element 1336)
2.16.840.1.113883.6.256
RadLex
RadLex (Radiological Society of North America)
The IHE FormatCode vocabulary is now managed in an Implementation Guide published using FHIR.
- formal canonical URI https://profiles.ihe.net/fhir/ihe.formatcode.fhir/ValueSet-formatcode.html
- formal publication URL https://profiles.ihe.net/fhir/ihe.formatcode.fhir/
- FormatCode gitHub repository for source of the Implementation Guide can be used to register issues, or create pull requests for modifications. Formal governance is managed by ITI Technical Committee.
This FormatCode vocabulary represents:
- Code System 1.3.6.1.4.1.19376.1.2.3
- Value Set 1.3.6.1.4.1.19376.1.2.7.1
IHEActCode Vocabulary
CCD
ASTM/HL7 Continuity of Care Document
CCR
ASTM CCR Implementation Guide
The IHEActCode vocabulary is a small vocabulary of clinical acts that are not presently supported by the HL7 ActCode vocabulary. The root namespace (OID) for this vocabulary is 1.3.6.1.4.1.19376.1.5.3.2. These vocabulary terms are based on the vocabulary and concepts used in the CCR and CCD standards listed above.
Code
Description
COMMENT
This is the act of commenting on another act.
PINSTRUCT
This is the act of providing instructions to a patient regarding the use of medication.
FINSTRUCT
This is the act of providing instructions to the supplier regarding the fulfillment of the medication order.
IMMUNIZ
The act of immunization of a patient using a particular substance or class of substances identified using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
DRUG
The act of treating a patient with a particular substance or class of substances identified using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
INTOL
An observation that a patient is somehow intollerant of (e.g., allergic to) a particular substance or class of substances using a specified vocabulary. Use of this vocabulary term requires the use of either the SUBSTANCE or SUBSTCLASS qualifier described below, along with an identified substance or class of substances.
SUBSTANCE
A qualifier that identifies the substance used to treat a patient in an immunization or drug treatment act. The substance is expected to be identified using a vocabulary such as RxNORM, SNOMED CT or other similar vocabulary and should be specific enough to identify the ingredients of the substance used.
SUBSTCLASS
A qualifier that identifies the class of substance used to treat a patient in an immunization or drug treatment act. The class of substances is expected to be identified using a vocabulary such as NDF-RT, SNOMED CT or other similar vocabulary, and should be broad enough to classify substances by mechanism of action (e.g., Beta Blocker), intended effect (Dieuretic, antibiotic) or ...
For Public Comment
What else needs to appear above for SUBSTCLASS?
IHERoleCode Vocabulary
The IHERoleCode vocabulary is a small vocabulary of role codes that are not presently supported by the HL7 Role Code vocabulary. The root namespace (OID) for this vocabulary is 1.3.6.1.4.1.19376.1.5.3.3.
IHERoleCode Vocabulary
Code
Description
EMPLOYER
The employer of a person.
SCHOOL
The school in which a person is enrolled.
AFFILIATED
An organization with which a person is affiliated (e.g., a volunteer organization).
PHARMACY
The pharmacy a person uses.
HL7 Version 3.0 Content Modules
This section contains content modules based upon the HL7 CDA Release 2.0 Standard, and related standards and/or implementation guides.
CDA Document Content Modules
- (1.3.6.1.4.1.19376.1.5.3.1.1.1)Medical Documents Specification
CDA Header Content Modules
- (1.3.6.1.4.1.19376.1.5.3.1.2.5)PCC CDA Supplement 2:6.3.2.7 Authorization
CDA Section Content Modules
This list defines the sections that may appear in a medical document. It is intended to be a comprehensive list of all document sections that are used by any content profile defined in the Patient Care Coordination Technical Framework. All sections shall have a narrative component that may be freely formatted into normal text, lists, tables, or other appropriate human-readable presentations. Additional subsections or entry content modules may be required.
Impressions
- (1.3.6.1.4.1.19376.1.5.3.1.1.13.2.4)PCC CDA Supplement 2:6.3.3.9.7 Assessments
CDA and HL7 Version 3 Entry Content Modules
- (1.3.6.1.4.1.19376.1.5.3.1.4.1)PCC TF 2:6.3.4.3 Severity
- (1.3.6.1.4.1.19376.1.5.3.1.4.1.1)PCC TF 2:6.3.4.4 Problem Status Observation
- (1.3.6.1.4.1.19376.1.5.3.1.4.1.2)PCC TF 2:6.3.4.5 Health Status
- (1.3.6.1.4.1.19376.1.5.3.1.4.2)PCC TF 2:6.3.4.6 Comments
- (1.3.6.1.4.1.19376.1.5.3.1.4.3)PCC TF 2:6.3.4.7 Patient Medication Instructions
- (1.3.6.1.4.1.19376.1.5.3.1.4.3.1)PCC TF 2:6.3.4.8 Medication Fulfillment Instructions
- (1.3.6.1.4.1.19376.1.5.3.1.4.4)PCC TF 2:6.3.4.9 External References
- (1.3.6.1.4.1.19376.1.5.3.1.4.4.1)PCC TF 2:6.3.4.10 Internal References
- (1.3.6.1.4.1.19376.1.5.3.1.4.5.1)PCC TF 2:6.3.4.11 Concern Entry
- (1.3.6.1.4.1.19376.1.5.3.1.4.5.2)PCC TF 2:6.3.4.12 Problem Concern Entry
- (1.3.6.1.4.1.19376.1.5.3.1.4.5.3)PCC TF 2:6.3.4.13 Allergy and Intolerance Concern
- (1.3.6.1.4.1.19376.1.5.3.1.4.5)PCC TF 2:6.3.4.14 Problem Entry
- (1.3.6.1.4.1.19376.1.5.3.1.4.6)PCC TF 2:6.3.4.15 Allergies and Intolerances
- (1.3.6.1.4.1.19376.1.5.3.1.4.7)PCC TF 2:6.3.4.16 Medications
- (1.3.6.1.4.1.19376.1.5.3.1.4.12)PCC TF 2:6.3.4.17 Immunizations
- (1.3.6.1.4.1.19376.1.5.3.1.4.7.3)PCC TF 2:6.3.4.18 Supply Entry
- (1.3.6.1.4.1.19376.1.5.3.1.4.7.2)PCC TF 2:6.3.4.19 Product Entry
- (1.3.6.1.4.1.19376.1.5.3.1.4.13)PCC TF 2:6.3.4.20 Simple Observations
- (1.3.6.1.4.1.19376.1.5.3.1.4.13.1)PCC TF 2:6.3.4.21 Vital Signs Organizer
- (1.3.6.1.4.1.19376.1.5.3.1.4.13.2)PCC TF 2:6.3.4.22 Vital Signs Observation
- (1.3.6.1.4.1.19376.1.5.3.1.4.15)PCC TF 2:6.3.4.23 Family History Organizer
- (1.3.6.1.4.1.19376.1.5.3.1.4.13.4)PCC TF 2:6.3.4.24 Social History Observation
- (1.3.6.1.4.1.19376.1.5.3.1.4.13.3)PCC CDA Supplement 2:6.3.4.25 Family History Observation
- (1.3.6.1.4.1.19376.1.5.3.1.4.13.5)PCC CDA Supplement 2:6.3.4.26 Pregnancy Observation
- (1.3.6.1.4.1.19376.1.5.3.1.4.13.7)PCC CDA Supplement 2:6.3.4.29 Advance Directive Observation
- (1.3.6.1.4.1.19376.1.5.3.1.4.14)PCC CDA Supplement 2:6.3.4.31 Encounters
- (1.3.6.1.4.1.19376.1.5.3.1.4.19)PCC CDA Supplement 2:6.3.4.33 Procedure Entry
- (1.3.6.1.4.1.19376.1.5.3.1.1.12.3.1)PCC CDA Supplement 2:6.3.4.38 Pain Score Observation
Appendix A - Examples Using PCC Content Profiles
Example documents conforming to each profile can be found on the IHE wiki at the following URLs.
Profile and Content
URL
XDS-MS
Referral Summary
XDSMS Example1
Discharge Summary
XDSMS Example1
XPHR
XPHR Content
XPHR Example1
XPHR Update
XPHR Example2
(EDR) ED Referral
EDR Example
(APS) Antepartum Summary
APS Example
(EDES)
Triage Note
EDES Example1
ED Nursing Note
EDES Example2
Composite Triage and Nursing Note
EDES Example3
ED Physician Note
EDES Example4
(FSA) Functional Status Section
FSA Example
Appendix B - Validating CDA Documents using the Framework
Many of the constraints specified by the content modules defined in the PCC Technical Framework can be validated automatically by software. Automated validation is a very desirable capability, as it makes it easier for implementers to test the correctness of their implementations. With regard to validation of the content module, the PCC Technical Framework narrative is the authoritative specification, not any automated software tool. Having said that, it is still very easy to create a validation framework for the IHE PCC Technical Framework using a XML validation tool such as Schematron.
Since each content module has a name (the template identifier), any XML instance that reports itself to be of that "class" can be validated by creating assertions that must be true for each constraint indicated for the content module. In the XML representation, the <templateId> element is a child of the element that is claiming conformance to the template named. Thus the general pattern of a Schematron that validates a specific template is shown below:
<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
<ns prefix="cda" uri="urn:hl7-org:v3" />
<pattern name='ReferralSummary'>
<rule context='*[cda:templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.3]"'>
<!-- one or more assertions made by the content module -->
</rule>
</pattern>
</schema>
Validating Documents
For document content modules, the pattern can be extended to support common document content module constraints as shown below:
<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
<ns prefix="cda" uri="urn:hl7-org:v3" />
<pattern name='ReferralSummary'>
<rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.1.3]"'>
<!-- Verify that the template id is used on the appropriate type of object -->
<assert test='../ClinicalDocument'>
Error: The referral content module can only be used on Clinical Documents.
</assert>
<!-- Verify that the parent templateId is also present. -->
<assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.1.2"]'>
Error: The parent template identifier for medical summary is not present.
</assert>
<!-- Verify the document type code -->
<assert test='code[@code = "34133-9"]'>
Error: The document type code of a referral summary must be
34133-9 SUMMARIZATION OF EPISODE NOTE.
</assert>
<assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
Error: The document type code must come from the LOINC code
system (2.16.840.1.113883.6.1).
</assert>
<!-- Verify that all required data elements are present -->
<assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
Error: A referral summary must contain a reason for referral.
</assert>
<!-- Alert on any missing required if known elements -->
<assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.8"]'>
Warning: A referral summary should contain a list of history of past illnesses.
</assert>
<!-- Note any missing optional elements -->
<assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.3.18"]'>
Note: This referral summary does not contain the pertinent review of systems.
</assert>
</rule>
</pattern>
</schema>
Validating Sections
The same pattern can be also applied to sections with just a few minor alterations.
<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
<ns prefix="cda" uri="urn:hl7-org:v3" />
<pattern name='ReasonForReferralUncoded'>
<rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
<!-- Verify that the template id is used on the appropriate type of object -->
<assert test='section'>
Error: The coded reason for referral module can only be used on a section.
</assert>
<assert test='false'>
Manual: Manually verify that this section contains narrative providing the
reason for referral.
</assert>
<!-- Verify that the parent templateId is also present. -->
<assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
Error: The parent template identifier for the reason for referral
module is not present.
</assert>
<!-- Verify the section type code -->
<assert test='code[@code = "42349-1"]'>
Error: The section type code of the reason for referral section must be 42349-1
REASON FOR REFERRAL.
</assert>
<assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
Error: The section type code must come from the LOINC code
system (2.16.840.1.113883.6.1).
</assert>
</pattern>
<pattern name='ReasonForReferralCoded'>
<rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.2"]'>
<!-- The parent template will have already verified the type of object -->
<!-- Verify that the parent templateId is also present. -->
<assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
Error: The parent template identifier for the reason for referral
module is not present.
</assert>
<!-- Don't bother with the section type code, as the parent template caught it -->
<!-- Verify that all required data elements are present -->
<assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.13"]'>
Error: A coded reason for referral section must contain an simple observation.
</assert>
<!-- Alert on any missing required if known elements -->
<!-- Note any missing optional elements -->
</rule>
</pattern>
</schema>
A similar pattern can also be followed for Entry and Header content modules, and these are left as an exercise for the reader.
Phases of Validation and Types of Errors
Note that each message in the Schematrons shown above start with a simple text string that indicates whether the message indicates one of the following conditions:
- An error, e.g., the failure to transmit a required element,
- A warning, e.g., the failure to transmit a required if known element,
- A note, e.g., the failure to transmit an optional element.
- A manual test, e.g., a reminder to manually verify some piece of content.
Schematron supports the capability to group sets of rules into phases by the pattern name, and to specify which phases of validation should be run during processing.
To take advantage of this capability, one simply breaks each <pattern> element above up into separate patterns depending upon whether the assertion indicates an error, warning, note or manual test, and then associate each pattern with a different phase. This is shown in the figure below.
<schema xmlns="http://www.ascc.net/xml/schematron" xmlns:cda="urn:hl7-org:v3">
<ns prefix="cda" uri="urn:hl7-org:v3" />
<phase id="errors">
<active pattern="ReasonForReferralUncoded_Errors"/>
<active pattern="ReasonForReferralCoded_Errors"/>
</phase>
<phase id="manual">
<active pattern="ReasonForReferralUncoded_Manual"/>
</phase>
<pattern name='ReasonForReferralUncoded_Errors'>
<rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
<assert test='section'>
Error: The coded reason for referral module can only be used on a section.
</assert>
<assert test='code[@code = "42349-1"]'>
Error: The section type code of the reason for referral section must be 42349-1
REASON FOR REFERRAL.
</assert>
<assert test='code[@codeSystem = "2.16.840.1.113883.6.1"]'>
Error: The section type code must come from the LOINC code
system (2.16.840.1.113883.6.1).
</assert>
</rule>
</pattern>
<pattern name='ReasonForReferralUncoded_Manual'>
<rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
<assert test='false'>
Manual: Manually verify that this section contains narrative providing the
reason for referral.
</assert>
</pattern>
<pattern name='ReasonForReferralCoded_Errors'>
<rule context='*[templateId/@root="1.3.6.1.4.1.19376.1.5.3.1.3.2"]'>
<assert test='templateId[@root="1.3.6.1.4.1.19376.1.5.3.1.3.1"]'>
Error: The parent template identifier for the reason for referral not present.
</assert>
<assert test='.//templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.13"]'>
Error: A coded reason for referral section must contain an simple observation.
</assert>
</rule>
</pattern>
</schema>
Using these simple "templates" for template validation one can simply create a collection of Schematron patterns that can be used to validate the content modules in the PCC Technical Framework. Such Schematrons are expected to be made available as part of the MESA test tools that are provided to IHE Connectathon participants, and which will also be made available to the general public after connectathon.
Appendix C - Extensions to CDA Release 2.0
This section describes extensions to CDA Release 2.0 that are used by the IHE Patient Care Coordination Technical Framework.
IHE PCC Extensions
All Extensions to CDA Release 2.0 created by the IHE PCC Technical Committee are in the namespace urn:ihe:pcc:hl7v3.
The approach used to create extension elements created for the PCC Technical Framework is the same as was used for the HL7 Care Record Summary (see Appendix E) and the ASTM/HL7 Continuity of Care Document (see secion 7.2).
replacementOf
The <replacementOf> extension element is applied to a section appearing in a PHR Update Document to indicate that that section's content should replace that of a previously existing section. The identifier of the previously existing section is given so that the PHR Manager receiving the Update content will know which section to replace. The model for this extension is shown below.
Model for replacementOf
Use of this extension is shown below. The <replacementOf> element appears after all other elements within the <section> element. The <id> element appearing in the <externalDocumentSection> element shall provide the identifier of the section being replaced in the parent document.
Example use of the replacementOf extension
<section>
<id root=' ' extension=' '/>
<title>Name of the Section</title>
<text>Text of the section</text>
<entry></entry>
<component></component>
<pcc:replacementOf xmlns:pcc='urn:ihe:pcc:hl7v3'>
<pcc:externalDocumentSection>
<pcc:id root='58FCBE50-D4F2-4bda-BC1C-2105B284BBE3'/>
<pcc:externalDocumentSection/>
</pcc:replacementOf>
</section>
Extensions Defined Elsewhere used by IHE PCC
Entity Identifiers
There is often a need to record an identifer for an entity so that it can be subsequently referenced. This extension provides a mechnism to store that identifier. The element appears after any <realm>, <typeId> or <templateId> elements, but before all others in the entity where it is used:
<playingEntity classCode='ENT' determinerCode='INSTANCE'>
<sdtc:id root='1.3.6.4.1.4.1.2835.2' extension='EntityID'/>
:
.
</playingEntity>
Patient Identifier
There is a need to record the identifer by which a patient is known to another healthcare provider. This extension provides a role link between the assigned, related or associated entity, and the patient role.
Use of this extension to record the identifier under which the patient is known to a provider is shown below.
Example use of the Patient Identifier Extension
<assignedEntity>
<id extension='1' root='1.3.6.4.1.4.1.2835.1'/>
<addr>
<streetAddressLine>21 North Ave</streetAddressLine>
<city>Burlington</city>
<state>MA</state>
<postalCode>01803</postalCode>
<country>USA</country>
</addr>
<telecom value='tel:(999)555-1212' use='WP'/>
<assignedPerson>
<name>
<prefix>Dr.</prefix><given>Bernard</given><family>Wiseman</family><suffix>Sr.</suffix>
</name>
</assignedPerson>
<sdtc:patient xmlns:sdtc='urn:hl7-org:sdtc' >
<sdtc:id root='1.3.6.4.1.4.1.2835.2' extension='PatientMRN'/>
</sdtc:patient>
</assignedEntity>
The <patient> element records the link between the related, assigned or associated entity and the patient. The <id> element provides the identifier for the patient. The root attribute of the <id> should be the namespace used for patient identifiers by the entity. The extension attribute of the <id> element shall be the patient's medical record number or other identifier used by the entity to identify the patient.
Appendix E - WSDLs for QED
The WSDL for the QED transaction PCC-1 represents the interface contract for the QED profile. Conformance to this contract is a requirement of the profile. However, the WSDL representing the this contract is not necessarily the best WSDLs to use when generating application proxies.
There is a general guideline for generating proxies make application development much easier for complex WSDL/schemas such as the ones included for QED. Use a generic, non-strongly typed WSDL that is for the purpose of generating the proxy. Use of a strongly typed WSDL forces the generation infrastructure to go through all the XML type definitions. It will then generate classes for each of them, which can result in thousands of generated classes and megabytes of generated code. In addition, the mapping between the schema and object oriented constructs is not straightforward. Because of both the size, and complexity of the schema, proxy generators often run into problems with valid instances of strongy typed WSDLs.
A commonly used method for creating non-strongly typed WDSL for HL7 Messages used for generating proxies substitutes the ANY data type for the payload of either the message infrastructure or the control act. This results in much smaller proxies. Applications receiving messages using these proxies may want to validate inputs since they are no longer validated by the proxy. A discussion of this method of proxy generation can be found in this article: http://msdn2.microsoft.com/en-us/library/ms954603.aspx. See the section on Web Services Code Generation.
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="ClinicalDataSource" targetNamespace="urn:ihe:pcc:qed:2007"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:hl7="urn:hl7-org:v3"
xmlns:tns="urn:ihe:pcc:qed:2007"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:wsoap11="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsaw="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<types>
<xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3">
<!-- Query Care Record Event Profile Query -->
<xsd:include schemaLocation="QUPC_IN043100UV.xsd"/>
</xsd:schema>
<xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3">
<!-- Query Care Record Event Profile Query Response -->
<xsd:include schemaLocation="QUPC_IN043200UV.xsd"/>
</xsd:schema>
<xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3">
<!-- General Query Activate Query Continue / Cancel -->
<xsd:include schemaLocation="QUQI_IN000003UV01.xsd"/>
</xsd:schema>
</types>
<message name="QUPC_IN043100UV_Message">
<part element="hl7:QUPC_IN043100UV" name="Body"/>
</message>
<message name="QUPC_IN043200UV_Message">
<part element="hl7:QUPC_IN043200UV" name="Body"/>
</message>
<message name="QUQI_IN000003UV01_Message">
<part element="hl7:QUQI_IN000003UV01" name="Body"/>
</message>
<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_Continue"/>
<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_Cancel"/>
<output message="tns:QUPC_IN043200UV_Message"
wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV"/>
</operation>
</portType>
<binding name="ClinicalDataSource_Binding_Soap12" type="tns: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>
<operation name="ClinicalDataSource_QUQI_IN000003UV01_Continue">
<wsoap12:operation soapAction="urn:hl7-org:v3:QUQI_IN000003UV01"/>
<input><wsoap12:body use="literal"/></input>
<output><wsoap12:body use="literal"/></output>
</operation>
<operation name="ClinicalDataSource_QUQI_IN000003UV01_Cancel">
<wsoap12:operation soapAction="urn:hl7-org:v3:QUQI_IN000003UV01"/>
<input><wsoap12:body use="literal"/></input>
<output><wsoap12:body use="literal"/></output>
</operation>
</binding>
<binding name="ClinicalDataSource_Binding_Soap11" type="tns: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><wsoap12:body use="literal"/></input>
<output><wsoap12:body use="literal"/></output>
</operation>
<operation name="ClinicalDataSource_QUQI_IN000003UV01_Continue">
<wsoap11:operation soapAction="urn:hl7-org:v3:QUQI_IN000003UV01"/>
<input><wsoap11:body use="literal"/></input>
<output><wsoap11:body use="literal"/></output>
</operation>
<operation name="ClinicalDataSource_QUQI_IN000003UV01_Cancel">
<wsoap11:operation soapAction="urn:hl7-org:v3:QUQI_IN000003UV01"/>
<input><wsoap11:body use="literal"/></input>
<output><wsoap11:body use="literal"/></output>
</operation>
</binding>
<service name="ClinicalDataSource_Service">
<port binding="tns:ClinicalDataSource_Binding_Soap11" name="ClinicalDataSource_Port_Soap11">
<wsoap11:address location="http://servicelocation/"/>
</port>
<port binding="tns:ClinicalDataSource_Binding_Soap12" name="ClinicalDataSource_Port_Soap12">
<wsoap12:address location="http://servicelocation/"/>
</port>
</service>
</definitions>
This file, along with the necessary HL7 Schemas, and some skelatal examples can all be found on the Patient Care Coordination FTP site: [1]