PCC TF-2/Transactions
IHE Transactions
This section defines each IHE transaction in detail, specifying the standards used, and the information transferred.
Cross Enterprise Document Content Transactions
At present, all transactions used by the PCC Content Profiles appear in ITI TF-2. General Options defined in content profiles for a Content Consumer are described below.
View Option
A Content Consumer that supports the View Option shall be able to:
- Use the appropriate XD* transactions to obtain the document along with associated necessary metadata.
- Render the document for viewing. This rendering shall meet the requirements defined for CDA Release 2 content presentation semantics (See Section 1.2.4 of the CDA Specification: Human readability and rendering CDA Documents). CDA Header information providing context critical information shall also be rendered in a human readable manner. This includes at a minimum the ability to render the document with the stylesheet specifications provided by the document source, if the document source provides a stylesheet. Content Consumers may optionally view the document with their own stylesheet, but must provide a mechanism to view using the source stylesheet.
- Support traversal of links for documents that contain links to other documents managed within the sharing framework.
- Print the document to paper.
Document Import Option
This Option requires that the View Option be supported. In addition, the Content Consumer that supports the Document Import Option shall be able to support the storage of the entire document (as provided by the sharing framework, along with sufficient metadata to ensure its later viewing) both for discharge summary or referral documents. This Option requires the proper tracking of the document origin. Once a document has been imported, the Content Consumer shall offer a means to view the document without the need to retrieve it again from the sharing framework. When viewed after it was imported, a Content Consumer may chose to access the sharing framework to find out if the related Document viewed has been deprecated, replaced or addended.
| Note: | For example, when using XDS, a Content Consumer may choose to query the Document Registry about a document previously imported in order to find out if this previously imported document may have been replaced or has received an addendum. This capability is offered to Content Consumers by this Integration Profile, but not required, as the events that may justify such a query are extremely implementation specific. |
Section Import Option
This Option requires that the View Option be supported. In addition, the Content Consumer that supports the Section Import Option shall be able to support the import of one or more sections of the document (along with sufficient metadata to link the data to its source) both for discharge summary or referral. This Option requires the proper tracking of the document section origin. Once sections have been selected, a Content Consumer shall offer a means to copy the imported section(s) into local data structures as free text. This is to support the display of section level information for comparison or editing in workflows such as medication reconciliation while discrete data import is not possible. When viewed again after it is imported, a Content Consumer may chose to access the sharing framework to find out if the related information has been updated.
| Note: | For example, when using XDS, a Content Consumer may choose to query the Document Registry about a document whose sections were previously imported in order to find out if this previously imported document may have been replaced or has received an addendum. This capability is offered to Content Consumers by this Integration Profile, but not required, as the events that may justify such a query are extremely implementation specific. |
This Option does not require, but does not exclude the Content Consumer from offering a means to select and import specific subsets of the narrative text of a section.
Discrete Data Import Option
This Option does not require that the View, Import Document or Section Import Options be supported. The Content Consumer that supports the Discrete Data Import Option shall be able to support the storage of the structured content of one or more sections of the document. This Option requires that the user be offered the possibility to select among the specific sections that include structured content a set of clinically relevant record entries (e.g. a problem or an allergy in a list) for import as part of the local patient record with the proper tracking of its origin.
| Note: | The Discrete Data Import Option does not require the support of the View, Import Document or Import Sections Options so that it could be used alone to support implementations of Content Consumers such as Public Health Data or Clinical Research systems that might aggregate and anonymize specific population healthcare information data as Document Consumer Actors, but one where no care provider actually views the medical summaries. |
When discrete data is accessed after it was imported, a Content Consumer may choose to check if the document related to the discrete data viewed has been deprecated, replaced or addended.
A Content Consumer Actor grouped with the XDS Document Source Actor may query the Document Registry about a document from which discrete data was previously imported in order to find out if this previously imported document may have been replaced or has received an addendum. This capability is offered to Content Consumers by this Integration Profile, but not required, as the events that may justify such a query are extremely implementation specific.
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.
Guideline Notification
This section corresponds to Transaction PCC-7 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-7 is used by the Guideline Manager and Care Manager Actors.
Use Case Roles
Guideline Manager
Care Manager
Guideline Notification
- Actor
- Guideline Manager
- Role
- Notifies the Care Manager of new and/or updated guidelines for care
- Cooresponding HL7 Version 3 Application Roles
- Care Provision Informer (REPC_AR004010UV)
- Actor
- Care Manager
- Role
- Recieves notification of new and/or updated guidelines for care
- Cooresponding HL7 Version 3 Application Roles
- Care Provision Tracker (REPC_AR004020UV)
Note:
Implementors of a Guideline Manager Actor, or a Clinical Data Source Actor shall publish an HL7 Conformance Profile that indicates the vocabularies and code sets that they support for this transaction.
Referenced Standards
Interaction Diagrams
Guideline Notification
Trigger Events
When a new or updated guideline is released, the Guideline Manager uses this transaction to notify
the Care Manager of the new and/or updated guideline. This cooresponds to the HL7 trigger events:
- Activate Care Provision (REPC_TE004110UV)
- Replace Care Provision (REPC_TE004913UV)
Message Semantics
This interaction cooresponds to the HL7 Interactions:
- Activate Care Provision (REPC_IN004110UV) {Schema: [1]}
- Replace Care Provision (REPC_IN004913UV) {Schema: [2]}
The schema for these interactions can be found at the links above, and include:
- the transmission wrapper MCCI_MT000100UV01,
- the control act wrapper MCAI_MT700201UV01, and
- the message payload REPC_MT004000UV.
These components of the interaction are specified in the HL7 standards described above.
Transmission Wrapper
The transmission wrapper MCCI_MT000100UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<REPC_IN004110UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id root=' ' extension=' '/>
<creationTime value=' '/>
<interactionId extension='REPC_IN004110UV|REPC_IN004913UV' root='2.16.840.1.113883.5'/>
<processingCode code='D|P|T'/>
<processingModeCode code='T'/>
<acceptAckCode code='AL'/>
<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</sender>
<controlActProcess classCode="CACT" moodCode="EVN">
See Control Act Wrapper below
</controlActProcess>
</REPC_IN004110UV>
<REPC_IN004110UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".
To indicate that this interaction is notification of activation of a guideline, the element shall be named: REPC_IN004110UV
To indicate that this interaction is notification of replacement of a guideline, the element shall be named: REPC_IN004913UV
<rule context='/'>
<assert test='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
The root element of a PCC-7 transaction shall be REPC_IN004110UV or REPC_IN004913UV from the HL7 namespace (urn:hl7-org:v3).
</assert>
</rule>
<interactionId extension='REPC_IN004110UV|REPC_IN004913UV' root='2.16.840.1.113883.5'/>
The identifer for the interaction shall be sent using either the value REPC_IN004110UV or REPC_IN004913UV depending upon whether this interaction describes activation or replacement respectively. This value must be the same as the name of the interaction element being sent.
<rule context='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
<assert test='hl7:interactionId/@extension = local-name()'>
The interaction of a PCC-7 transaction shall be REPC_IN004110UV or REPC_IN004913UV and shall coorespond to the interaction being used in the message.
</assert>
</rule>
<processingModeCode code='T'/>
The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.
<rule context='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
<assert test='hl7:processingModeCode/@code = "T"'>
The processingModeCode shall use the code value "T" for this message.
</assert>
</rule>
<acceptAckCode code='AL'/>
The acceptAckCode indicates whether the sender wants to recieve an acknowledgement, and shall be sent as shown above.
<rule context='/hl7:REPC_IN004110UV|/hl7:REPC_IN004913UV'>
<assert test='hl7:acceptAckCode/@code = "AL"'>
The acceptAckCode shall use the code "AL" to indicate that the reciever must always acknowledge the message.
</assert>
</rule>
Control Act Wrapper
The control act wrapper MCAI_MT700201UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O.
An example control act wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<controlActProcess classCode="CACT" moodCode="EVN">
<id root=' ' extension=' '/>
<effectiveTime><low value=' '/><high value=' '/></effectiveTime>
<languageCode code=' '/>
<authorOrPerformer typeCode=' '></authorOrPerformer>
<subject typeCode='SUBJ' contextConductionInd='false'>
</subject>
</controlActProcess>
<controlActProcess classCode="CACT" moodCode="EVN">
The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "EVN" by the sender to indicate notification of a guideline activation or change event.
<rule context='//hl7:controlActProcess'>
<assert test='@classCode="CACT"'>
The controlActProcess of a PCC-7 transaction shall have classCode="CACT".
</assert>
<assert test='@moodCode="EVN"'>
The controlActProcess of a PCC-7 transaction shall have moodCode="EVN".
</assert>
</rule>
The trigger event which caused the act to be transmitted is recorded in the code element is recorded. The value of the code attribute shall be REPC_TE004110UV to record an activation event, or REPC_TE004913UV to record a replacement. The code attribute shall coorespond to the correct interaction.
<rule context='//hl7:controlActProcess'>
<assert test='hl7:code'>
The code element shall be present in a PCC-7 transaction.
</assert>
</rule>
<rule context='//hl7:controlActProcess/hl7:code'>
<assert test='(@code="REPC_TE004110UV" or @code="REPC_TE004913UV) and substring(@code,8,8) = substring(local-name(/),8,8)"'>
The trigger event in a PCC-7 transaction shall be REPC_TE004110UV or REPC_TE004913UV, and shall coorespond to the interaction.
</assert>
</rule>
<effectiveTime><low value=' '/><high value=' '/></effectiveTime>
The effectiveTime element shall be present. The low component shall be present and indicates the effective start date for the set of guidelines described in the subject element. The high component may be present, and if present, indicates the stop date for the guidelines. If not present, the guidelines are effective for an indefinate time period until explicitely changed or removed from the system.
<rule context='//hl7:controlActProcess'>
<assert test='hl7:effectiveTime'>
The effectiveTime element shall be present in a PCC-7 transaction.
</assert>
</rule>
<rule context='//hl7:controlActProcess/hl7:effectiveTime'>
<assert test='hl7:low and hl7:low/@value'>
A low element shall be present in the effectiveTime and the value attribute shall indicate the date upon which the guidelines become effective.
</assert>
</rule>
<subject typeCode='SUBJ' contextConductionInd='false'>
The subject element shall be present and shall be recorded as shown above. The subject element shall contain a <careProvisionEvent> element describing the guideline being activated.
Message Body
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
An example <careProvisionEvent> element is shown below.
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<id root=' ' extension=' '/>
</careProvisionEvent>
</replacementOf>
<component typeCode='COMP'>
<carePlan classCode='PCPR' moodCode='INT'>
<definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
<guideline classCode='PCPR' moodCode='DEF'>
<id root=' ' extension=' '/>
<title></title>
<text></text>
<statusCode code='active|obsolete'/>
<effectiveTime>
<low value=' '/>
<high value=' '/>
</effectiveTime>
<!-- zero or more components containing acts of care to be monitored -->
<component2 typeCode='COMP'>
<!-- One of the following elements -->
<observationDefinition classCode='OBS' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</observationDefinition>
<substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</substanceAdministrationDefinition>
<procedureDefinition classCode='PROC' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</procedureDefinition>
<encounterDefinition classCode='ENC' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</encounterDefinition>
<actDefinition classCode='ACT' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</actDefinition>
</component2>
<!-- zero or more components containing "sub-guidelines" that make up this guideline -->
<component3 typeCode='COMP'>
<!-- The content model for "sub-guidelines" is as for a guideline, with the exception
that it need not contain an id, title, text, statusCode, or effectiveTime element. -->
</component3>
</guideline>
</definition>
</carePlan>
</component>
</careProvisionEvent>
The <careProvisionEvent> elements sent by a Guideline Notification transaction, or returned in a Request Guideline Data transaction represent activations or replacements of guidelines. As such these elements shall not contain any of the following participants:
- The <careProvisionEvent> element SHALL NOT contain a <recordTarget>, as guidelines are not specific to a single patient record.
- The <careProvisionEvent> element SHALL NOT contain a <subject> element, as guidelines are not specific to a device being maintained.
The <careProvisionEvent> may contain other participants not otherwise prohibited above.
Furthermore, these elements shall not contain any of the following relationships which would be only relevant to a single patient:
- The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation2> element.
- The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation3> element.
Furthermore, the <careProvisionEvent> element SHOULD NOT contain a <pertinentInformation1> element, as this information is not directly relevant to the guideline being retrieved.
The <careProvisionEvent> may contain other relationships not otherwise prohibited above, but the use of these elements is not described in this profile.
<rule context='hl7:careProvisionEvent[not(../hl7:replacementOf)]'>
<assert test='count(hl7:component) = 1'>
A careProvisionEvent shall have only one component containing the guideline.
</assert>
<assert test='not(hl7:recordTarget)'>
The careProvisionEvent shall not contain a recordTarget element.
</assert>
<assert test='not(hl7:subject)'>
The careProvisionEvent shall not contain a subject element.
</assert>
<assert test='not(hl7:pertinentInformation1)'>
Warning: The careProvisionEvent should not contain a pertinentInformation1 element.
</assert>
<assert test='not(hl7:pertinentInformation2)'>
The careProvisionEvent shall not contain a pertinentInformation2 element.
</assert>
<assert test='not(hl7:pertinentInformation3)'>
The careProvisionEvent shall not contain a pertinentInformation3 element.
</assert>
</rule>
<replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<id root=' ' extension=' '/>
When a Guideline Notification transaction sends a replacement notification, the <careProvisionEvent> that references the guideline being replaced shall be identified in the <replacementOf> element. The <replacementOf> element shall contain a single <careProvisionEvent> element that shall contain the an <id> element giving the unique identifier of the <careProvisionElement> that was replaced, and which should not contain any other elements.
<rule context='/hl7:REPC_IN004913UV'>
<assert test='hl7:careProvisionEvent/hl7:replacementOf'>
A replacement transaction shall contain a replacementOf element identifying
the careProvisionEvent being replaced.
</assert>
</rule>
<rule context='hl7:replacementOf/hl7:careProvisionEvent'>
<assert test='hl7:id'>
The careProvisionEvent that is being replaced shall contain an id element.
</assert>
<assert test='not(hl7:*[local-name() != "id"])'>
Warning: The careProvisionEvent that is being replaced should not contain anything other than an id element.
</assert>
</rule>
<component typeCode='COMP'>
<carePlan classCode='PCPR' moodCode='INT'>
A <careProvisionEvent> shall have only one <component> element, containing only one <carePlan>, represented exactly as shown above.
<rule context='hl7:careProvisionEvent/hl7:component'>
<assert test='count(hl7:carePlan) = 1'>
The component of the careProvisionEven shall have one and only one carePlan element.
</assert>
</rule>
<definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
<guideline classCode='PCPR' moodCode='DEF'>
The <carePlan> element shall be empty of all participants and relations with the exception of the <definition> of the <carePlan>. The <definition> element contains one and only one <guideline>.
<rule context='hl7:carePlan'>
<assert test='not(*[local-name() != "definition"])'>
The carePlan element shall be empty of all participants and relations with the exception of the definition element.
</assert>
<assert test='count(hl7:definition) = 1'>
The carePlan element shall have one and only one definition element.
</assert>
</rule>
<rule context='hl7:definition'>
<assert test='count(hl7:guideline) = 1'>
The definition element shall have one and only one guideline element.
</assert>
</rule>
<id root=' ' extension=' '/>
Top level guidelines shall have a unique identifier.
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:id'>
A top level guideline shall have an id element.
</assert>
</rule>
<title></title>
Top level guidelines shall have a title.
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:title'>
A top level guideline shall have a title element.
</assert>
</rule>
<text></text>
All guidelines may contain narrative text describing the guideline.
<statusCode code='active|obsolete'/>
Top level guidelines shall have a statusCode value that is either "active" or "obsolete".
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:statusCode'>
A top level guideline shall have a statusCode element.
</assert>
</rule>
<rule context='hl7:guideline/hl7:statusCode'>
<assert test='@code="active" or @code="obsolete"'>
The statusCode/@code attribute shall be either "active" or "obsolete".
</assert>
<rule>
<effectiveTime><low value=' '/><high value=' '/></effectiveTime>
Top level guidelines shall contain an <effectiveTime> element that records the time period over which the guideline is effective. It shall contain a <low> element recording at the very least the date upon which the guideline was activated. An obsolete guideline shall contain a <high> element recording the last date upon which the guideline was effective. An active guideline may record the date upon which the guideline is expected to be revised.
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:effectiveTime'>
A top level guideline shall have a effectiveTime element.
</assert>
</rule>
<rule context='hl7:guideline/hl7:effectiveTime'>
<assert test='hl7:low and hl7:low/@value'>
The effectiveTime element shall contain a low element containing a value attribute indicating the time at which
the guideline became effective.
</assert>
<rule>
<rule context='hl7:guideline[hl7:statusCode/@code="obsolete"]/hl7:effectiveTime'>
<assert test='hl7:high and hl7:high/@value'>
The effectiveTime element in an obsolete guideline shall contain a high element containing a value attribute
indicating the time at which the guideline became ineffective.
</assert>
<rule>
<component2 typeCode='COMP'>
All guidelines are composed (at some level) of one or more definitions for acts of care which are to be monitored by a Care Manager and reported upon by a Clinical Data Source during the provision of care. These may include various observations performed (e.g., Hemoglobin A1C tests), medications or immunizations given or prescribed, procedures performed (e.g., foot care), encounters performed (e.g., eye exam), or other acts of care not elsewhere described above.
<rule context='hl7:guideline'>
<assert test='count(.//hl7:component2/hl7:*[@moodCode='DEF']) > 0'>
At least one act of care must be defined at some level beneath a guideline element.
</assert>
</rule>
<observationDefinition classCode='OBS' moodCode='DEF'>
<substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
<procedureDefinition classCode='PROC' moodCode='DEF'>
<encounterDefinition classCode='ENC' moodCode='DEF'>
<actDefinition classCode='ACT' moodCode='DEF'>
One of the above definitions of an act of care shall be present in a <component2> element.
<templateId root=' ' extension=' '/>
Each act of care to be monitored shall indicate the identifier of the template used to report information on that act.
<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
<assert test='hl7:templateId'>
A templateId element must appear in the definition.
</assert>
</rule>
A Guideline Manager actor shall use one the IHE Template identifiers specified for PCC-1 under careProvisionCode to request information profiled in an IHE template to be returned in a PCC-10 transaction. A Clincial Data Source implementing the Care Record option shall report activites to the Care Manager using the Care Record Query Response message using the template identified.
A Guideline Manager actor may include an ActDefinition in the <guideline> to identify the HL7 Version 2 Message Profile to describe the data to be monitored by a Care Manager. A Clinical Data Source implementing the HL7 Version 2 option shall report activities to the Care Manager using the HL7 Version 2 message identified by those ActDefinition elements.
<id root=' ' extension=' '/>
Each act of care to be monitored shall contain an identifier for the definition of the act. It shall also contain a code element describing the specific act of care to be monitored. Other features of the specific act allowed by the standard may be provided by the Guideline Manager to further identify the specific acts of care that a Care Manager wants to recieve (e.g., routeCode, targetSiteCode). A Clinical Data Source may use these additional features to limit the number of items it reports, but is not required to review any feature other than the "code" element when making its reports. The Care Manager is expected to use its decision support capabilities to ignore reports that are not relevant to its decision making processes.
<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
<assert test='hl7:id'>
An id element must appear in the definition.
</assert>
<assert test='hl7:code'>
An code element must appear in the definition.
</assert>
</rule>
A Clinical Data Source implementing the Care Record Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-10.
A Clinical Data Source implementing the HL7 Version 2 Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-11.
<component3 typeCode='COMP'>
Guidelines may cover different phases (e.g., pre-operative, post-operative) or perspectives of care (e.g., patient education, diet, medications). A guideline can therefore be constructed of other guideline components, which follow the same pattern as for the top level guideline in the careProvisionEvent, except that these subcomponents need not have a unique identity, a title, a status, or effective time.
Expected Actions -- Guideline Manager
The Guideline Manager shall send notifications as specified in the REPC_IN004110UV and REPC_IN004913UV interactions. The message shall be sent using web services as specified in the ITI-TF: Appendix V.
The name of the messages in the WSDL shall be REPC_IN004110UV_Message for activitation notifications, and
REPC_IN004913UV_Message for replacement notifications.
The following WSDL snippet defines the types for these messages:
Guideline Notification Message Type Definition
<types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:import namespace="urn:hl7-org:v3"
schemaLocation="REPC_IN004110UV.xsd"/>
<xsd:element name="REPC_IN004110UV"/>
<xsd:import namespace="urn:hl7-org:v3"
schemaLocation="REPC_IN004913UV.xsd"/>
<xsd:element name="REPC_IN004913UV"/>
</xsd:schema>
</types>
The message types are declared to be of the appropriate type by the following WSDL snippet:
Guideline Notification Message WSDL Declarations
<message name='REPC_IN004110UV_Message'>
<part element='hl7:REPC_IN004110UV' name="Body"/>
</message>
<message name='REPC_IN004913UV_Message'>
<part element='hl7:REPC_IN004913UV' name="Body"/>
</message>
Expected Actions -- Care Manager
The Care Manager shall send an acknowledgement response as specified in the MCCI_IN000002UV01 interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V. An acknowledgement response is structured almost identically to a transmission wrapper, but includes an acknowledgement element in the response. The example structure below uses the same values as the transmission wrapper, with the exceptions noted in bold black text below.
<MCCI_IN000002UV01 xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id root=' ' extension=' '/>
<creationTime value=' '/>
<interactionId extension='MCCI_IN000002UV01' root='2.16.840.1.113883.5'/>
<processingCode code='D|P|T'/>
<processingModeCode code='T'/>
<acceptAckCode code='NE'/>
<receiver typeCode="RCV">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</receiver>
<sender typeCode="SND">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</sender>
<acknowledgement>
<typeCode code='AA|AE|AR'/>
<acknowledgementDetail>
<typeCode='E|I|W'/>
<text></text>
<location></location>
</acknowledgementDetail>
</acknowledgement>
</MCCI_IN000002UV01>
<MCCI_IN000002UV01 xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
The name of the acknowledgement message element shall be MCCI_IN000002UV01 from the HL7 namespace.
<rule context='/'>
<assert test='/hl7:MCCI_IN000002UV01'>
The name of the acknowledgement message element shall be MCCI_IN000002UV01 from the HL7 namespace.
</assert>
<rule>
<interactionId extension='MCCI_IN000002UV01' root='2.16.840.1.113883.5'/>
The interactionId element shall be recorded exactly as specified above.
<rule context='/hl7:MCCI_IN000002UV01'>
<assert test='hl7:interactionId/@extension = "MCCI_IN000002UV01" and interactionId/@root = "2.16.840.1.113883.5"'>
The extension attribute of the interaction Id element shall be MCCI_IN000002UV01.
</assert>
<rule>
<processingModeCode code='T'/>
The code attribute of the processingModeCode element shall be T to indicate current processing.
<rule context='/hl7:MCCI_IN000002UV01'>
<assert test='hl7:processingModeCode/@code = "T"'>
The code attribute of the processingModeCode element shall be T to indicate current processing.
</assert>
<rule>
<acceptAckCode code='NE'/>
The code attribute of the acceptAckCode element shall be NE to indicate that acknowledgments are never acknowledged by the reciever.
<rule context='/hl7:MCCI_IN000002UV01'>
<assert test='hl7:acceptAckCode/@code = "NE"'>
The code attribute of the acceptAckCode element shall be NE.
</assert>
<rule>
<acknowledgement>
One and only one acknowledgement element shall be present.
<rule context='/hl7:MCCI_IN000002UV01'>
<assert test='count(hl7:acknowledgement) = 1'>
One and only one acknowledgement element shall be present.
</assert>
<rule>
<typeCode code='AA|AE|AR'/>
The typeCode element shall be present. It shall use only the values AA, AE, or AR to describe whether the application accepted it (AA), found an error in it (AE), or rejected it (AR).
<rule context='/hl7:MCCI_IN000002UV01/hl7:acknowledgement'>
<assert test='hl7:typeCode/@code = "AA" or hl7:typeCode/@code = "AE" or hl7:typeCode/@code = "AR"'>
Only the values AA, AE and AR are acceptable.
</assert>
<rule>
<acknowledgementDetail>
The acknowledgementDetail element shall be present when a message is rejected, or when an error is found. It may be present even when an application has accepted the message to convey information and warnings.
<rule context='/hl7:MCCI_IN000002UV01/hl7:acknowledgement'>
<assert test='hl7:typeCode/@code = "AA" or hl7:acknowledgementDetail'>
The acknowledgementDetail element is required when the acknowedgement reports an error (AE) or rejects a message (AR).
</assert>
<rule>
<typeCode code='E|I|W'/>
The typeCode element shll be present in the acknowledgementDetail element. It shall have a value of E, I or W to indicate errors, information or warnings. A detail message sent with the acknowledgement type of AA shall not contain a value of E in the detailed type code.
<rule context='/hl7:MCCI_IN000002UV01/hl7:acknowledgement/hl7:acknowledgementDetail'>
<assert test='hl7:typeCode/@code = "E" or hl7:typeCode/@code = "I" or hl7:typeCode/@code = "W"'>
Only the values E, I or W are acceptable.
</assert>
<assert test='hl7:typeCode/@code != "E" or ../../hl7:typeCode != "AA"'>
Acknowledgement details cannot indicate an error when the acknowledgment is of type AA.
</assert>
<rule>
The code element may be present in the acknowledgementDetail element to further describe the error.
<text></text>
The text element may be present in the acknowledgementDetail element to further describe the error in human readable form.
<location></location>
The location element may be present in the acknowledgementDetail element to indicate the location of the error. The location shall be reported as an XPath expression indicating the position of the error in the source message content.
The name of the acknowledgement response message shall be MCCI_IN000002UV01_Message in the WSDL.
The following WSDL snippet defines the type for this message:
Accept Acknowledgement Message Type Definition
<types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<xsd:import namespace="urn:hl7-org:v3"
schemaLocation="MCCI_IN000002UV01.xsd"/>
<xsd:element name="MCCI_IN000002UV01"/>
</xsd:schema>
</types>
The message type is declared to be of the appropriate type by the following WSDL snippet:
Accept Acknowledgement Message WSDL Declaration
<message name='MCCI_IN000002UV01_Message'>
<part element='hl7:MCCI_IN000002UV01' name="Body"/>
</message>
WSDL Declarations
The following WSDL naming conventions SHALL apply for this transaction:
WSDL Definitions for PCC-7
WSDL Item
Value
wsdl:definitions/@name
GuidelineManger
Activate Care Provision
REPC_IN004110UV_Message
Replace Care Provision
REPC_IN004913UV_Message
Acknowlegement
MCCI_IN000002UV01_Message
portType
GuidelineManger_PortType
Activate Guideline Operation
GuidelineManger_REPC_IN004110UV
Activate Guideline Operation
GuidelineManger_REPC_IN004913UV
SOAP 1.1 binding
GuidelineManger_Binding_Soap11
SOAP 1.1 port
GuidelineManger_Port_Soap11
SOAP 1.2 binding
GuidelineManger_Binding_Soap12
SOAP 1.2 port
GuidelineManger_Port_Soap12
The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Guideline Manger Data Repository actor implementing the QED profile can be found at ftp://ftp.ihe.net/Patient_Care_Coordination/yr3_2008-2009/resources/cm.zip. For a general description of the WSDLs for Care Management see the Appendix of the same name in this volume.
Port Type
<portType name="GuidelineManger_PortType">
<operation name="GuidelineManger_REPC_IN004110UV">
<input message="tns:REPC_IN004110UV_Message"
wsaw:Action="urn:hl7-org:v3:REPC_IN004110UV"/>
<output message="tns:MCCI_IN000002UV01_Message"
wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
</operation>
<operation name="GuidelineManger_REPC_IN004913UV">
<input message="tns:REPC_IN004913UV_Message"
wsaw:Action="urn:hl7-org:v3:REPC_IN004913UV"/>
<output message="tns:MCCI_IN000002UV01_Message"
wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
</operation>
</portType>
Port Types for PCC-7
Bindings
<binding name="GuidelineManger_Binding_Soap12"
type="GuidelineManger_PortType">
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GuidelineManger_REPC_IN004110UV">
<wsoap12:operation soapAction="urn:hl7-org:v3:REPC_IN004110UV"/>
<input>
<wsoap12:body use="literal"/>
</input>
<output>
<wsoap12:body use="literal"/>
</output>
</operation>
<operation name="GuidelineManger_REPC_IN004913UV">
<wsoap12:operation soapAction="urn:hl7-org:v3:REPC_IN004913UV"/>
<input>
<wsoap12:body use="literal"/>
</input>
<output>
<wsoap12:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.2 Binding for PCC-7
<binding name="GuidelineManger_Binding_Soap11"
type="GuidelineManger_PortType">
<wsoap11:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GuidelineManger_REPC_IN004110UV">
<wsoap11:operation soapAction="urn:hl7-org:v3:REPC_IN004110UV"/>
<input>
<wsoap11:body use="literal"/>
</input>
<output>
<wsoap11:body use="literal"/>
</output>
</operation>
<operation name="GuidelineManger_REPC_IN004913UV">
<wsoap11:operation soapAction="urn:hl7-org:v3:REPC_IN004913UV"/>
<input>
<wsoap11:body use="literal"/>
</input>
<output>
<wsoap11:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.1 Binding for PCC-7
Request Guideline Data
This section corresponds to Transaction PCC-8 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-8 is used by the Care Manager and/or Clinical Data Source Actors to request Guideline Data from a Guideline Manager Actor. Transaction PCC-8 is similar in structure to Transaction PCC-1. The difference between PCC-8 and PCC-1 is that where PCC-1 requests clinical information matching the query parameters for a specific patient, the PCC-8 transaction requests a specific care record activating a clinical guideline identified in the query parameters.
Use Case Roles
Care Manager or Clinical Data Source
Guideline Manager
Request Guideline Data
- Actor
- Care Manager or Clinical Data Source
- Role
- Requests the data required to implement a guideline.
- Cooresponding HL7 Version 3 Application Roles
- Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)
- Actor
- Guideline Manager
- Role
- Returns the guideline data required to implement a guideline.
- Cooresponding HL7 Version 3 Application Roles
- Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)
Note:
Implementors of a Guideline Manager Actor, Care Manager Actor or a Clinical Data Source Actor shall publish an HL7 Conformance Profile that indicates the vocabularies and code sets that they support for this transaction.
Referenced Standards
Interaction Diagrams
Get Care Record Query
Trigger Events
When a Clinical Data Source actor needs to understand the data needed to respond to a query from a Care Manager, or a Care Manager actor needs to refresh its knowledge about a guideline (e.g., to determine how to update a query for a replaced guideline) it will trigger a Get Care Record Query event. This cooresponds to the HL7 trigger event: QUPC_TE040100UV
Message Semantics
The Query Care Record Event Get Query corresponds to the HL7 Interaction
QUPC_IN040100UV.
A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN040100UV.xsd. This schema includes:
- the transmission wrapper MCCI_MT000100UV01,
- the control act wrapper QUQI_MT020001UV01, and
- the message payload QUPC_MT040100UV.
These components of the interaction are specified in the HL7 standards described above.
Transmission Wrapper
The transmission wrapper MCCI_MT000100UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<QUPC_IN040100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id root=' ' extension=' '/>
<creationTime value=' '/>
<interactionId extension='QUPC_IN040100UV' root='2.16.840.1.113883.5'/>
<processingCode code='D|P|T'/>
<processingModeCode code='T'/>
<acceptAckCode code='AL'/>
<receiver typeCode="RCV">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</receiver>
<sender typeCode="SND">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</sender>
<controlActProcess>
See Control Act Wrapper below
</controlActProcess>
</QUPC_IN040100UV>
<QUPC_IN040100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".
<interactionId extension='QUPC_IN040100UV' root='2.16.840.1.113883.5'/>
The identifer for the interaction shall be sent as shown above.
<processingModeCode code='T'/>
The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.
<acceptAckCode code='AL'/>
The acceptAckCode indicates whether the sender wants to recieve an acknowledgement, and shall be sent as shown above.
Control Act Wrapper
The control act wrapper QUQI_MT020001UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<controlActProcess moodCode="RQO">
<id root=' ' extension=' '/>
<effectiveTime value=' '/>
<languageCode code=' '/>
<authorOrPerformer typeCode=' '></authorOrPerformer>
<queryByParameter>
<id root=' ' extension=' '/>
<statusCode code='new'/>
<responseModalityCode code='R'/>
<responsePriorityCode code='I'/>
<initialQuantity value=/>
<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'>
<parameterList>
see Query Parameter List below
</parameterList>
</queryByParameter>
</controlActProcess>
<controlActProcess moodCode="RQO">
The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "RQO" by the sender to indicate a request to perform an action, in this case, a query.
The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.
<queryByParameter>
HL7 Version 3 messages that perform a query specify the details of it in the <queryByParameter> element.
<id root=' ' extension=' '/>
The sending system shall specify the identifier of the query. This is the identifier that is used in subsequent continuation or cancel messages.
<statusCode code='new'/>
When passing the parameter list, the <statusCode> element shall be recorded as above to indicate that this is a new query.
<responseModalityCode code='R'/>
The query response shall always be in real-time.
<responsePriorityCode code='I'/>
The query response shall always be immediate.
<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883.5'>
The <initialQuantityCode> shall be sent when <initialQuantity> is sent. The code shall be the identifier of the HL7 artifact that is to be counted (e.g., R-MIM or C-MET identifer). In this profile what is being counted is clinical statements, so the code to use shall be REPC_RM000100UV.
Parameter List
The message supports specification of the data items listed in the table below as query
parameters. The first column of this table provides the name of the parameter. The next column indicates the number of times it may occur in the query. The next column indicates the type of data expected for the query parameter. The next column indicates the vocabulary domain used for coded values. The Sender column indicates whether the message sender (a Care Manager or Clinical Data Source actor) must send this parameter. The Reciever column indicates whether the reciever (a Guideline Manager Actor) must support this parameter. If these last two columns contain the value R, then this parameter SHALL be send by actor, and if it is X, then this parameter SHALL NOT be sent by the actor. In this profile, all parameters not explicitly required are prohibited.
Parameter Name
Cardinality
Data Type
Vocabulary Domain
Sender
Reciever
Query Parameters
careRecordId
1..1
II
R
R
patientId
0..0
CD
X
X
versionTimeStamp
0..0
TS
X
X
includeCarePlanAttachment
1..1
BL
R
R
maxHistoryClincialStatements
0..0
INT
X
X
An example of the query specification is described in the figure below.
<parameterList>
<careRecordId>
<value code='' displayName='' codeSystem='' codeSystemName=''/>
</careRecordId>
<includeCarePlanAttachment><value value='true'/></includeCarePlanAttachment>
</parameterList>
<parameterList>
The <parameterList> element shall be present, and contains the set of query parameters being used in this query.
<careRecordId><value root=' ' extension=' '/></careRecordId>
The identifier of the care record event that activated the guideline shall be specified in this element. The root and extension attributes shall be present.
<includeCarePlanAttachment><value value='true'/></includeCarePlanAttachment>
The <includeCarePlanAttachment> element shall be sent and the value shall be true. As guidelines always appear in a Care Record message under the Care Plan, the Care Plan must be present in the response.
Expected Actions -- Care Manager or Clinical Data Source
The clinical data consumer shall send a query as specified in the QUPC_IN040100UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.
The name of the query response message shall be QUPC_IN040100UV_Message in the WSDL.
The following WSDL snippet defines the type for this message:
Query Message Type Definition
<types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include namespace="urn:hl7-org:v3" schemaLocation="QUPC_IN040100UV.xsd"/>
</xsd:schema>
</types>
The message type is declared to be of the appropriate type by the following WSDL snippet:
Query Message WSDL Declaration
<message name='QUPC_IN040100UV_Message'>
<part element='hl7:QUPC_IN040100UV' name="Body"/>
</message>
Other WSDL declarations required for this transaction are defined under the Domain Content section.
Get Care Record Profile Response
Trigger Events
This message is triggered upon reciept of a Query Care Record Event Get Query. This corresponds to HL7 trigger event: QUPC_TE043200UV
Message Semantics
The Query Care Record Event Get Query Response corresponds to the HL7 Interaction QUPC_IN040200UV. A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN040200UV.xsd. This schema includes:
- the transmission wrapper MCCI_MT000300UV01,
- the control act wrapper MFMI_MT700712UV01, and
- the message payload REPC_MT004000UV.
These components of the interaction are specified in the HL7 standards described above.
Transmission Wrapper
The transmission wrapper MCCI_MT000300UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<QUPC_IN040200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id root=' ' extension=' '/>
<creationTime value=' '/>
<interactionId extension='QUPC_IN040200UV' root='2.16.840.1.113883.5'/>
<processingCode code='D|P|T'/>
<processingModeCode code='T'/>
<acceptAckCode code='NE'/>
<receiver typeCode="RCV">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</receiver>
<sender typeCode="SND">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</sender>
<controlActProcess>
See Control Act Wrapper below
</controlActProcess>
</QUPC_IN040200UV>
<QUPC_IN040200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".
<interactionId extension='QUPC_IN040200UV' root='2.16.840.1.113883.5'/>
The identifer for the interaction shall be sent as shown above.
<processingModeCode code='T'/>
The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.
<acceptAckCode code='NE'/>
The acceptAckCode indicates whether the reciever wants to recieve an acknowledgement, and shall be sent as shown above. Query responses shall not require acknowledgements.
Control Act Wrapper
The control act wrapper MFMI_MT700712UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<controlActProcess moodCode="EVN">=
<id root=' ' extension=' '/>
<effectiveTime value=' '/>
<languageCode code=' '/>
<authorOrPerformer typeCode=' '></authorOrPerformer>
<subject>
See Query Response below
</subject>
<queryAck>
<queryId root=' ' extension=' '/>
<statusCode code=' '/>
<queryResponseCode code=' '/>
<resultTotalQuantity value=' '/>
<resultCurrentQuantity value=' '/>
<resultRemainingQuantity value=' '/>
</queryAck>
</controlActProcess>
<controlActProcess moodCode="EVN">
The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "EVN" by the sender to indicate a response to a query.
The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.
<subject>
The <subject> element shall be present to record the responses in a query request.
<queryAck>
The queryAck element is transmitted in any message that is a response to a query, query continuation or query cancellation message.
<queryId root=' ' extension=' '/>
The <queryId> element shall be transmitted in a queryAck element. It shall contain an identifier that was used in the original query message.
<statusCode code=' '/>
The statusCode element in the queryAck element indicates the status of the query. It may contain the value 'deliveredResponse' or 'aborted'.
<queryResponseCode code=' '/>
The queryResponseCode element indicates at a high level the results of performing the query. It may have the value 'OK' to indicate that the query was performed and has results. It may have the value 'NF' to indicate that the query was performed, but no record was found. It may have the value 'QE' to indicate that an error was detected in the incoming query message, or 'AE' to indicate some other application error occurred.
<resultTotalQuantity value=' '/>
The resultTotalQuantity element shall be present and enumerates the number of results found (1). This element gives the count of the total number of results located by the query.
Note:
For this use of the query, the resultTotalQuantity value should always be 1
<resultCurrentQuantity value=' '/>
The resultCurrentQuantity element shall be present, and shall enumerate number of results returned in the current response.
Note:
For this use of the query, the resultCurrentQuantity value should always be 1
<resultRemainingQuantity value=' '/>
This resultRemainingQuantity element shall be present. It shall enumerate the number of results that follow the results currently returned (0).
Note:
For this use of the query, the resultRemainingQuantity value should always be 0
Registration Event Details
The <subject> element of the <controlActProcess> element shall appear as shown in the example below, and provides details on the event that registered the the guideline with the Guideline Manager.
<subject>
<registrationEvent>
<statusCode code='active|obsolete'/>
<custodian>
<assignedEntity>
<id root='' extension=''/>
<addr></addr>
<telecom></telecom>
<assignedOrganization>
<name></name>
</assignedOrganization>
</assignedEntity>
</custodian>
<subject2>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<!-- Message Body -->
</careProvisionEvent>
<parameterList>
</parameterList>
</subject2>
</registrationEvent>
</subject>
<subject>
The <subject> element shall be present, and is where the results are returned.
<registrationEvent>
Only one <registrationEvent> element shall be be present.
The <registrationEvent> is used to record the information about how the <careProvisionEvent> being returned was recorded or "registered" in the custodial system (the Guideline Manager actor) .
<statusCode code='active|obsolete'/>
The <statusCode> element records the status of the data records. Queries return active and obsolete (replaced) records.
<custodian>
The <custodian> element records the custodian, or "owner", of the guideline. A Guideline Manager actor may return records from multiple custodians.
<assignedEntity>
The <assignedEntity> element shall be present, and provides contact and identification information about the <custodian>.
<id root=' ' extension=' '/>
The <id> element shall be present, and shall uniquely identify the custodian of the guideline.
<addr></addr>
The <addr> element shall be present, and shall provide a postal address for the custodian of the guideline.
<telecom></telecom>
At least one <telecom> element shall be present that provides a telephone number to contact the custodian of the guideline.
A <telecom> element may be present that provides the web service end-point address of the custodian of the guideline.
For Public Comment
How might the web service end-point address be used? Is it a good idea to include it, or should we omit this from the profile?
<assignedOrganization>
<name></name>
</assignedOrganization>
The name of the organization that is the custodian of the guideline shall be provided.
<subject2>
The <subject2> element provides the data content requested from the query.
Query Response Content
Note:
The following content for careProvisionEvent is identical to that found in PCC-7.
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
An example <careProvisionEvent> element is shown below.
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<id root=' ' extension=' '/>
</careProvisionEvent>
</replacementOf>
<component typeCode='COMP'>
<carePlan classCode='PCPR' moodCode='INT'>
<definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
<guideline classCode='PCPR' moodCode='DEF'>
<id root=' ' extension=' '/>
<title></title>
<text></text>
<statusCode code='active|obsolete'/>
<effectiveTime>
<low value=' '/>
<high value=' '/>
</effectiveTime>
<!-- zero or more components containing acts of care to be monitored -->
<component2 typeCode='COMP'>
<!-- One of the following elements -->
<observationDefinition classCode='OBS' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</observationDefinition>
<substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</substanceAdministrationDefinition>
<procedureDefinition classCode='PROC' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</procedureDefinition>
<encounterDefinition classCode='ENC' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</encounterDefinition>
<actDefinition classCode='ACT' moodCode='DEF'>
<templateId root=' ' extension=' '/>
<id root=' ' extension=' '/>
</actDefinition>
</component2>
<!-- zero or more components containing "sub-guidelines" that make up this guideline -->
<component3 typeCode='COMP'>
<!-- The content model for "sub-guidelines" is as for a guideline, with the exception
that it need not contain an id, title, text, statusCode, or effectiveTime element. -->
</component3>
</guideline>
</definition>
</carePlan>
</component>
</careProvisionEvent>
The <careProvisionEvent> elements sent by a Guideline Notification transaction, or returned in a Request Guideline Data transaction represent activations or replacements of guidelines. As such these elements shall not contain any of the following participants:
- The <careProvisionEvent> element SHALL NOT contain a <recordTarget>, as guidelines are not specific to a single patient record.
- The <careProvisionEvent> element SHALL NOT contain a <subject> element, as guidelines are not specific to a device being maintained.
The <careProvisionEvent> may contain other participants not otherwise prohibited above.
Furthermore, these elements shall not contain any of the following relationships which would be only relevant to a single patient:
- The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation2> element.
- The <careProvisionEvent> element SHALL NOT contain a <pertinentInformation3> element.
Furthermore, the <careProvisionEvent> element SHOULD NOT contain a <pertinentInformation1> element, as this information is not directly relevant to the guideline being retrieved.
The <careProvisionEvent> may contain other relationships not otherwise prohibited above, but the use of these elements is not described in this profile.
<rule context='hl7:careProvisionEvent[not(../hl7:replacementOf)]'>
<assert test='count(hl7:component) = 1'>
A careProvisionEvent shall have only one component containing the guideline.
</assert>
<assert test='not(hl7:recordTarget)'>
The careProvisionEvent shall not contain a recordTarget element.
</assert>
<assert test='not(hl7:subject)'>
The careProvisionEvent shall not contain a subject element.
</assert>
<assert test='not(hl7:pertinentInformation1)'>
Warning: The careProvisionEvent should not contain a pertinentInformation1 element.
</assert>
<assert test='not(hl7:pertinentInformation2)'>
The careProvisionEvent shall not contain a pertinentInformation2 element.
</assert>
<assert test='not(hl7:pertinentInformation3)'>
The careProvisionEvent shall not contain a pertinentInformation3 element.
</assert>
</rule>
<replacementOf typeCode='RPLC' contextControlCode='OP' contextConductionInd='false'>
<careProvisionEvent classCode='PCPR' moodCode='EVN'>
<id root=' ' extension=' '/>
When a Guideline Notification transaction sends a replacement notification, the <careProvisionEvent> that references the guideline being replaced shall be identified in the <replacementOf> element. The <replacementOf> element shall contain a single <careProvisionEvent> element that shall contain the an <id> element giving the unique identifier of the <careProvisionElement> that was replaced, and which should not contain any other elements.
<rule context='/hl7:REPC_IN004913UV'>
<assert test='hl7:careProvisionEvent/hl7:replacementOf'>
A replacement transaction shall contain a replacementOf element identifying
the careProvisionEvent being replaced.
</assert>
</rule>
<rule context='hl7:replacementOf/hl7:careProvisionEvent'>
<assert test='hl7:id'>
The careProvisionEvent that is being replaced shall contain an id element.
</assert>
<assert test='not(hl7:*[local-name() != "id"])'>
Warning: The careProvisionEvent that is being replaced should not contain anything other than an id element.
</assert>
</rule>
<component typeCode='COMP'>
<carePlan classCode='PCPR' moodCode='INT'>
A <careProvisionEvent> shall have only one <component> element, containing only one <carePlan>, represented exactly as shown above.
<rule context='hl7:careProvisionEvent/hl7:component'>
<assert test='count(hl7:carePlan) = 1'>
The component of the careProvisionEven shall have one and only one carePlan element.
</assert>
</rule>
<definition typeCode='INST' contextControlCode='OP' contextConductionInd='false'>
<guideline classCode='PCPR' moodCode='DEF'>
The <carePlan> element shall be empty of all participants and relations with the exception of the <definition> of the <carePlan>. The <definition> element contains one and only one <guideline>.
<rule context='hl7:carePlan'>
<assert test='not(*[local-name() != "definition"])'>
The carePlan element shall be empty of all participants and relations with the exception of the definition element.
</assert>
<assert test='count(hl7:definition) = 1'>
The carePlan element shall have one and only one definition element.
</assert>
</rule>
<rule context='hl7:definition'>
<assert test='count(hl7:guideline) = 1'>
The definition element shall have one and only one guideline element.
</assert>
</rule>
<id root=' ' extension=' '/>
Top level guidelines shall have a unique identifier.
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:id'>
A top level guideline shall have an id element.
</assert>
</rule>
<title></title>
Top level guidelines shall have a title.
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:title'>
A top level guideline shall have a title element.
</assert>
</rule>
<text></text>
All guidelines may contain narrative text describing the guideline.
<statusCode code='active|obsolete'/>
Top level guidelines shall have a statusCode value that is either "active" or "obsolete".
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:statusCode'>
A top level guideline shall have a statusCode element.
</assert>
</rule>
<rule context='hl7:guideline/hl7:statusCode'>
<assert test='@code="active" or @code="obsolete"'>
The statusCode/@code attribute shall be either "active" or "obsolete".
</assert>
<rule>
<effectiveTime><low value=' '/><high value=' '/></effectiveTime>
Top level guidelines shall contain an <effectiveTime> element that records the time period over which the guideline is effective. It shall contain a <low> element recording at the very least the date upon which the guideline was activated. An obsolete guideline shall contain a <high> element recording the last date upon which the guideline was effective. An active guideline may record the date upon which the guideline is expected to be revised.
<rule context='hl7:definition/hl7:guideline'>
<assert test='hl7:effectiveTime'>
A top level guideline shall have a effectiveTime element.
</assert>
</rule>
<rule context='hl7:guideline/hl7:effectiveTime'>
<assert test='hl7:low and hl7:low/@value'>
The effectiveTime element shall contain a low element containing a value attribute indicating the time at which
the guideline became effective.
</assert>
<rule>
<rule context='hl7:guideline[hl7:statusCode/@code="obsolete"]/hl7:effectiveTime'>
<assert test='hl7:high and hl7:high/@value'>
The effectiveTime element in an obsolete guideline shall contain a high element containing a value attribute
indicating the time at which the guideline became ineffective.
</assert>
<rule>
<component2 typeCode='COMP'>
All guidelines are composed (at some level) of one or more definitions for acts of care which are to be monitored by a Care Manager and reported upon by a Clinical Data Source during the provision of care. These may include various observations performed (e.g., Hemoglobin A1C tests), medications or immunizations given or prescribed, procedures performed (e.g., foot care), encounters performed (e.g., eye exam), or other acts of care not elsewhere described above.
<rule context='hl7:guideline'>
<assert test='count(.//hl7:component2/hl7:*[@moodCode='DEF']) > 0'>
At least one act of care must be defined at some level beneath a guideline element.
</assert>
</rule>
<observationDefinition classCode='OBS' moodCode='DEF'>
<substanceAdministrationDefinition classCode='SBADM' moodCode='DEF'>
<procedureDefinition classCode='PROC' moodCode='DEF'>
<encounterDefinition classCode='ENC' moodCode='DEF'>
<actDefinition classCode='ACT' moodCode='DEF'>
One of the above definitions of an act of care shall be present in a <component2> element.
<templateId root=' ' extension=' '/>
Each act of care to be monitored shall indicate the identifier of the template used to report information on that act.
<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
<assert test='hl7:templateId'>
A templateId element must appear in the definition.
</assert>
</rule>
A Guideline Manager actor shall use one the IHE Template identifiers specified for PCC-1 under careProvisionCode to request information profiled in an IHE template to be returned in a PCC-10 transaction. A Clincial Data Source implementing the Care Record option shall report activites to the Care Manager using the Care Record Query Response message using the template identified.
A Guideline Manager actor may include an ActDefinition in the <guideline> to identify the HL7 Version 2 Message Profile to describe the data to be monitored by a Care Manager. A Clinical Data Source implementing the HL7 Version 2 option shall report activities to the Care Manager using the HL7 Version 2 message identified by those ActDefinition elements.
<id root=' ' extension=' '/>
Each act of care to be monitored shall contain an identifier for the definition of the act. It shall also contain a code element describing the specific act of care to be monitored. Other features of the specific act allowed by the standard may be provided by the Guideline Manager to further identify the specific acts of care that a Care Manager wants to recieve (e.g., routeCode, targetSiteCode). A Clinical Data Source may use these additional features to limit the number of items it reports, but is not required to review any feature other than the "code" element when making its reports. The Care Manager is expected to use its decision support capabilities to ignore reports that are not relevant to its decision making processes.
<rule context='hl7:component2/hl7:*[@moodCode='DEF']'>
<assert test='hl7:id'>
An id element must appear in the definition.
</assert>
<assert test='hl7:code'>
An code element must appear in the definition.
</assert>
</rule>
A Clinical Data Source implementing the Care Record Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-10.
A Clinical Data Source implementing the HL7 Version 2 Option shall report care activities that meet the definitions in the guideline to the Care Manager using the clinical statement templates specified in PCC-11.
<component3 typeCode='COMP'>
Guidelines may cover different phases (e.g., pre-operative, post-operative) or perspectives of care (e.g., patient education, diet, medications). A guideline can therefore be constructed of other guideline components, which follow the same pattern as for the top level guideline in the careProvisionEvent, except that these subcomponents need not have a unique identity, a title, a status, or effective time.
<parameterList>
The <parameterList> shall be present, and shall contain content that is identical to the <parameterList> passed in the query.
Expected Actions -- Data Repository
The Data Repository shall send a response as specified in the QUPC_IN043200UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.
The name of the query response message shall be QUPC_IN043200UV_Message in the WSDL.
The following WSDL snippet defines the type for this message:
Query Response Message Type Definition
<types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<xsd:import namespace="urn:hl7-org:v3"
schemaLocation="QUPC_IN043200UV.xsd"/>
<xsd:element name="QUPC_IN043200UV"/>
</xsd:schema>
</types>
The message type is declared to be of the appropriate type by the following WSDL snippet:
Query Respone Message WSDL Declaration
<message name='QUPC_IN040200UV_Message'>
<part element='hl7:QUPC_IN040200UV' name="Body"/>
</message>
Other WSDL declarations required for this transaction are defined under the Domain Content section.
Response to a New Query
The Guideline Manager, shall:
- 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 Guideline Manager may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the query are not valid.
- 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 ILLEGAL detected issue alert to the response message if the the data repository does not recognize the identity domain used to identify the guideline. Set the text value on the alert to careRecordId.
- 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 guideline 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 the result to the response.
Raising Alerts
If the content of the request is not valid (e.g., according to the Schema or the rules of this profile), at least on ILLEGAL alert shall be raised indicating the data element that was invalid. A response will be sent indicating that the request was invalid, and no further processing shall be performed.
If the requesting party is not authorized to perform the query, the minimum response shall be sent indicating only that the requested is not authorized to perform the query.
In other cases, all possible alerts shall be accumulated before returning a response to the caller.
This enables Clinical Data Consumer actors to send a test query that will enable them to verify the vocabulary and other request parameters that are desired.
An alert is raised by sending a response containing one or more <reasonOf> elements, coded as shown below.
<reasonOf>
<detectedIssueEvent>
<code code='' displayName='' codeSystem='' codeSystemName=''/>
<text></text>
<mitigatedBy>
<detectedIssueManagement moodCode="RQO">
<code code='' displayName='' codeSystem='' codeSystemName=''/>
<text></text>
</detectedIssueManagement>
</mitigatedBy>
</detectedIssueEvent>>
</reasonOf>
<reasonOf>
The <reasonOf> element is required to indicate that an alert has occured.
<detectedIssueEvent>
The details of the alert shall be present in the <detectedIssueEvent> element.
<code code=' ' displayName=' ' codeSystem='2.16.840.1.113883.5.4' codeSystemName='ActCode'/>
The <code> element shall contain ISSUE or one of its descendants from the HL7 ActCode vocabulary.
<text></text>
If a validation or other business rule error occurred, the erroneous parameter shall be identified in <text> element using the element name, and nothing else should be present.
If an application error occured, the <text> element shall contain diagnostic information (e.g., stack trace or exception message).
If the reason for the alert was an unrecognized code (CODE_INVALID), the text element shall contain the name of the erroneous parameter, and may contain a space separated list of OIDs identifying value sets which would be valid.
If the reason for the alert was an unrecognized identifier (KEY204) for the vocabulary used in the careProvisionCode or careProvisionReason element, the text element shall contain the name of the erroneous paramater, and may contain a space separated list of the OIDs for code systems which would be valid.
Expected Actions -- Clinical Data Consumer
The Care Manager or Clinical Data Source processes the query response data. No additional data other than the single requested guideline will be returned, so no provision is made in this profile for continuations or canceling the query.
WSDL Declarations
The following WSDL naming conventions SHALL apply for this transaction:
WSDL Definitions for PCC-8
WSDL Item
Value
wsdl:definitions/@name
GuidelineManger
Get Care Record Query
QUPC_IN040100UV_Message
Get Care Record Query Response
QUPC_IN040200UV_Message
portType
GuidelineManger_PortType
Query Operation
GuidelineManger_QUPC_IN043100UV
SOAP 1.1 binding
GuidelineManger_Binding_Soap11
SOAP 1.1 port
GuidelineManger_Port_Soap11
SOAP 1.2 binding
GuidelineManger_Binding_Soap12
SOAP 1.2 port
GuidelineManger_Port_Soap12
The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Guideline Manger Data Repository actor implementing the QED profile can be found at ftp://ftp.ihe.net/Patient_Care_Coordination/yr3_2008-2009/resources/cm.zip. For a general description of the WSDLs for Care Management see the Appendix of the same name in this volume.
Port Type
<portType name="GuidelineManger_PortType">
<operation name="GuidelineManger_QUPC_IN040100UV">
<input message="tns:QUPC_IN040100UV_Message"
wsaw:Action="urn:hl7-org:v3:QUPC_IN040100UV"/>
<output message="tns:QUPC_IN040200UV_Message"
wsaw:Action="urn:hl7-org:v3:QUPC_IN040200UV "/>
</operation>
</portType>
Port Types for PCC-8
Bindings
<binding name="GuidelineManger_Binding_Soap12"
type="GuidelineManger_PortType">
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GuidelineManger_QUPC_IN043100UV">
<wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN040100UV"/>
<input>
<wsoap12:body use="literal"/>
</input>
<output>
<wsoap12:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.2 Binding for PCC-8
<binding name="GuidelineManger_Binding_Soap11"
type="GuidelineManger_PortType">
<wsoap11:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GuidelineManger_QUPC_IN040100UV">
<wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN040100UV"/>
<input>
<wsoap11:body use="literal"/>
</input>
<output>
<wsoap11:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.1 Binding for PCC-8
Care Management Data Query
This section corresponds to Transaction PCC-9 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-9 is used by the Care Manager and Clinical Data Repository Actors.
Transaction PCC-9 is a variation of the pattern used in transaction PCC-1 of the PCC Technical Framework. Information specific to this transaction is described in futher detail below in the section on Domain Content.
Use Case Roles
Care Manager
Clinical Data Repository
Care Management Data Query
- Actor
- Care Manager
- Role
- Requests a collection of clinical data matching the selection criteria from the Clinical Data Repository.
- Cooresponding HL7 Version 3 Application Roles
- Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)
- Actor
- Clinical Data Repository
- Role
- Returns clinical data matching the selection criteria supplied by the Care Manager.
- Cooresponding HL7 Version 3 Application Roles
- Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)
Referenced Standards
Interaction Diagrams
Get Care Record Profile Query
Trigger Events
When the Care Manager needs to obtain information about a patient or population it will trigger a Get Care Record Care Profile event. This cooresponds to the HL7 trigger event: QUPC_TE043100UV
Message Semantics
The Query Care Record Event Profile Query corresponds to the HL7 Interaction
QUPC_IN043100UV.
A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN043100UV.xsd. This schema includes:
- the transmission wrapper MCCI_MT000100UV01,
- the control act wrapper QUQI_MT020001UV01, and
- the message payload QUPC_MT040100UV.
These components of the interaction are specified in the HL7 standards described above.
Transmission Wrapper
The transmission wrapper for PCC-9 is nearly identical to the transmission wrapper used in PCC-1, and appears below.
The transmission wrapper MCCI_MT000100UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<QUPC_IN043100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id root=' ' extension=' '/>
<creationTime value=' '/>
<interactionId extension='QUPC_IN043100UV' root='2.16.840.1.113883.5'/>
<processingCode code='D|P|T'/>
<processingModeCode code='T'/>
<acceptAckCode code='AL'/>
<receiver typeCode="RCV">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</receiver>
<sender typeCode="SND">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</sender>
<respondTo typeCode="RSP">
<entityRsp determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' '/>
</entityRsp>
</respondTo><controlActProcess>
See Control Act Wrapper below
</controlActProcess>
</QUPC_IN043100UV>
<QUPC_IN043100UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".
<interactionId extension='QUPC_IN043100UV' root='2.16.840.1.113883.5'/>
The identifer for the interaction shall be sent as shown above.
<processingModeCode code='T'/>
The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.
<acceptAckCode code='AL'/>
The acceptAckCode indicates whether the sender wants to recieve an acknowledgement, and shall be sent as shown above.
<respondTo typeCode="RSP">
<entityRsp determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' '/>
This element may be used to indicate the destination of the response when it is other than the sender of the query. The server and port address where the response is being sent shall appear in a URI in the value attribute of the <telecom> element. This element shall only be used in queries that are requesting a response in HL7 Version 2 format.
Control Act Wrapper
The control act wrapper QUQI_MT020001UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
The controlActProcess element defined for this transaction nearly identical to the same element defined in PCC-1, with variations in the responsePriorityCode, responseModalityCode, and executionAndDeliveryTime elements.
<controlActProcess moodCode="RQO">
<id root=' ' extension=' '/>
<effectiveTime value=' '/>
<languageCode code=' '/>
<authorOrPerformer typeCode=' '></authorOrPerformer>
<queryByParameter>
<id root=' ' extension=' '/>
<statusCode code='new'/>
<responseModalityCode code='R|B'/>
<responsePriorityCode code='D'/>
<initialQuantity value=/>
<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'/>
<executionAndDeliveryTime xsi:type="PIVL_TS">
<phase value="20080601000000"/>
<period value='24' unit='h|d|wk|mo|a'/>
</executionAndDeliveryTime>
<parameterList>
see Query Parameter List below
</parameterList>
</queryByParameter>
</controlActProcess>
<controlActProcess moodCode="RQO">
The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "RQO" by the sender to indicate a request to perform an action, in this case, a query.
The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.
<queryByParameter>
HL7 Version 3 messages that perform a query specify the details of it in the <queryByParameter> element.
<id root=' ' extension=' '/>
The sending system shall specify the identifier of the query. This is the identifierr that is used in subsequent continuation or cancel messages.
<statusCode code='new'/>
When passing the parameter list, the <statusCode> element shall be recorded as above to indicate that this is a new query.
<responseModalityCode code='R|B'/>
The query response may be in real-time (R) or batch (B). When the responseModalityCode is set to batch, an executionAndDeliveryTime element shall be sent to identify the schedule for the responses.
<responsePriorityCode code='D'/>
The query response shall always be deferred.
<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883.5'>
The <initialQuantityCode> shall be sent when <initialQuantity> is sent. The code shall be the identifier of the HL7 artifact that is to be counted (e.g., R-MIM or C-MET identifer). In this profile what is being counted is clinical statements, so the code to use shall be REPC_RM000100UV.
Please note, the initial response to this query may include a large number of clinical statements providing historical data for the patients selected by the query. The use of initialQuantityCode allows the Care Manager to control the amount of historical data that the Clinical Data Source sends.
For Public Comment
There is some question here about what to do with the acknowledgement, should it be delayed until the Care Manager has processed or stored the information. What happens with the remaining data? Is a continuation required to be sent to alert the Clinical Data Source that it can send more data?
<executionAndDeliveryTime xsi:type="PIVL_TS">
<phase value="20080601000000"/>
<period value=' ' unit='h|d|wk|mo|a'/>
The <executionAndDeliveryTime> element shall be sent when the responseModalityCode is batch (B). It shall not be sent when the responseModalityCode is real-time (R). The data type for this element shall be set to PIVL_TS to indicate that the batches are to be returned periodically. The period between batches shall be specified in the <period> element, using the unit values described above.
The <phase> element may be sent to indicate the time window in which the batch response is expected, either as a single value to indicate the time at which it is scheduled, or as an interval (using <high> and <low> elements) marking the time window in which the response can be sent. Responders will make their best efforts to respond according to the schedule specified, but this profile does not guarantee that they must respond in the specified time frame.
The phase of the schedules is aligned to the appropriate calendar component matching the units specified. To request a batch message to be sent on the first of each month, set the phase to indicate the first day of any month, and the units to "mo".
For Public Comment
How critical is it to address time zone shifts during daylight savings time vs. standard time? If so, how would you recommend dealing with this issue? Is is necessary for the reciever to always be able to expect a message at 1am local time, or is it OK for the reciever to get the message at 1am at some times of the year, and at 2am at others?
Parameter List
The message supports specification of the data items listed in the table below as query
parameters. The first column of this table provides the name of the parameter. The next column indicates the number of times it may occur in the query. The next column indicates the type of data expected for the query parameter. The next column indicates the vocabulary domain used for coded values. The Consumer column indicates whether the Care Manager must supply this parameter. The Source column indicates whether the Clinical Data Source must support this parameter.
A Care Manager may supply parameters other than those required by this profile, but must appropriately handle any detected issue alert raised by the Clinical Data Source in its response.
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 Care Manager can restrict the results returned in the query by setting the value attribute of <value> element in the <careProvisionCode> element to a code identifying the clinical data to be returned. A Clinical Data Source can use the codes specified in the sections below to obtain different kinds of clinical data.
A Care Manager implementing one of the options for that actor shall be able to issue a query using at least one of the codes listed for that information category as specified in the table below. A Clinical Data Source implementing one of these options must support all codes listed in the table below for that information category.
Information Category
Code
Returns
Template Id
Vital Signs
COBSCAT
All Vital Signs
Vital Signs Observation
Any Code from the Vital Signs Table in the Vital Signs Observation
The vital sign identified by the code
Vital Signs Observation
Problems and Allergies
MEDCCAT
All problem entries
Problem Entry
CONDLIST
All Concern Entries
Concern Entry
PROBLIST
All Problem Concerns
Problem Concern
INTOLIST
All Allergy Concerns
Allergy and Intolerance Concern
RISKLIST
All Risks1
Concern Entry
Diagnostic Results
LABCAT
All Lab Results
Simple Observations
DICAT
All Imaging Results
Simple Observations
Medications
RXCAT
All Medications
Medications
MEDLIST
All Medications
Medications
CURMEDLIST
All active medications
Medications
DISCHMEDLIST
Discharge Medications
Medications
HISTMEDLIST
All Historical Medications
Medications
Immunizations
IMMUCAT
All Immunizations
Immunizations
Professional Services
PSVCCAT
All professional service entries
Encounters
A Care Manager Actor may make requests using other codes not specified above to obtain other clinical data, but these are not guaranteed to be supported by the Clinical Data Source actor.
Note:
Clinical Data Sources that are grouped with Content Creators are required to support the vocabulary used within the templates defining the content being created!
- Querying for Substances
- Often, a query needs to identify a particular substance, such as in the case for a query about the use of a specific medication, immunization, or allergy to a given substance. To support these queries, IHE requires that Clinical Data Sources that can respond to queries using appropriate vocabularies for substances use the following form:
<value code='DRUG|IMMUNIZE|INTOL' displayName=' ' codeSystem='1.3.5.1.4.1.19376.1.5.3.2' codeSystemName='IHEActCode'>
<qualifier>
<name code='SUBSTANCE|SUBSTCLASS'/>
<value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>
</qualifier>
</value>
<value code='DRUG|IMMUNIZE|INTOL' displayName=' ' codeSystem='1.3.5.1.4.1.19376.1.5.3.2' codeSystemName='IHEActCode'>
The <value> element expresses in the code attribute whether the act being queried for is:
Code
Definition
DRUG
Treatment with a specific drug
IMMUNIZ
Immunization of a patient
INTOL
A record of an allergy or intolerance to a substance
One of the values listed above shall be used in the code attribute. The codeSystem shall be recorded as listed above.
<qualifier><name code='SUBSTANCE|SUBSTCLASS'/>
The <qualifier> element further qualifies the concept being requested. The <name> element indicates whether the substance is being described, or the class of substances is being described.
Code
Definition
SUBSTANCE
The substance used
SUBSTCLASS
A class of substances used
<value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/>
The <value> element inside the <qualifier> describes the substance or class of substances of interest in the query.
<careProvisionReason><value code=' ' displayName=' ' codeSystem=' ' codeSystemName=' '/></careProvisionReason>
This element identifies the reason why the result was recorded. If specified, only those results which are recorded for the specified reason will be returned.
The <value> element of the <careProvisionReason> element may contain a value identifying a specific condition that was the reason for obtaining the result or prescribing the medication or immunization. A Clinical Data Source actor that chooses to honor this query parameter shall return only those results that were for the indicated reason. Should the Clinical Data Source Actor not support the use of the <careProvisionReason> element, it shall indicate this by raising the appropriate alert as decribed in the expected actions recorded in PCC-1.
For Public Comment
For immunizations, there is a desire to identify a specific immunization program that was the reason for the immunization, how might an immunization program be referenced? A code might identify the specific pathogen against which the patient is being immunized, but for public health use, a more discrete question is being asked: What program caused the patient to come in for immunization? This seems to require the ability to query for an identifier.
<careRecordTimePeriod><value><low value=' '/><high value=' '/></value></careRecordTimePeriod>
This element describes the time period over which the results were recorded. A query could for example, request new entries that have been processed for this patient since the last query request. If specified, only those results that were authored within the specified time period
will be returned.
<clinicalStatementTimePeriod><value><low value=' '/><high value=' '/></value></clinicalStatementTimePeriod>
This element describes the effective time for the clinical statement. If specified, only those results that were effective within the clinical statement effective time will be returned.
The effectiveTime range of the returned clinical statements shall overlap or be wholely contained within the time range described by the <clinicalStatementTimePeriod> element. In the example below, the clinical statements with the effectiveTime values represented by time ranges B, C and D would be returned, while those with effectiveTime values represented by time ranges A and E would not, because they fall outside of the specified <clinicalStatementTimePeriod> value.
Effective Time and Clinical Statement Time Period<includeCarePlanAttachment><value value='true|false'/></includeCarePlanAttachment>
The <includeCarePlanAttachment> element shall be sent, and must be set to either true or false depending upon whether care plans should be returned or not. A Data Source may choose not to honor this request when the value is set to true, but must then raise a BUS detected issue alert to indicate that this capability is not supported. Note that many data repositories will not associate a care plan attachment with a specific result.
<maximumHistoryStatements><value value=' '/></maximumHistoryStatements>
This value indicates the maximum number of each type of result that will be returned by the query. No more than the maximum number will be returned. This value is NOT the maximum number of clinical statements returned, rather it is the maximum number of clinical statements returned for individual type of clinical statement specified in the careProvisionCode. Thus, if all results are requested (e.g., all Vital Signs), and maximumHistoryStatements/value/@value = 1, you will receive the most current value for each kind of result requested (e.g., one each of the most recent value for height, weight, blood pressure, tempurature, et cetera).
For Public Comment
Does this parameter have any relevance for the Care Manager Actor?
<patientAdministrativeGender>
<value code=' ' displayName=' ' codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
The patient gender may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient gender of the patient specified in patientId. If the two values do not match, the Vital Signs Data Source will raise a detected issue alert.
<patientBirthTime><value value=' '/></patientBirthTime>
The patient birth time may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient birth time of the patient specified in patientId. If the two values do not match, the Vital Signs Data Source will raise a detected issue alert.
<patientId><value root=' ' extension=' '/></patientId>
The patient identifier shall be specified in this element. The root and extension attributes shall be present. When used in cross enterprise settings, the root attribute shall the affinity domain identity OID.
Sending a query with a known invalid patientId element can be used to ping a Data Source. For example, setting the root attribute to "0" and omitting the extension attribute should result in a response that raises an ILLEGAL detected issue alert on the patientId field, since the value "0" will never be used as the OID of a patient identity domain. This capability can be used by a Clinical Data Consumer to verify that it can connect to a Data Source when configuration parameters are modified.
The Care Manager may specify a value of * in the extension attribute of the value element to issue the query against the population of patients.
<patientName><value></value></patientName>
The patient name may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient name of the patient specified in patientId. If the two values do not match, the Data Source will raise a detected issue alert.
Expected Actions -- Care Manager
The Care Manager shall send a query as specified in the QUPC_IN043100UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.
The Care Manager shall send an audit message to the audit log repository indicating that a query was initiated, and the parameters of query that were supplied (see the queryByParameter element above).
Expected Actions -- Clinical Data Source
The Clinical Data Source shall send an acknowledgement of the query as specified in the HL7 MCCI_IN000002UV01 interaction in the response to the query message, and shall trigger a QUPC_TE043200UV event to initiate the sending of historical data for all matching patients (see below).
In generating the acknowledgement, the Clinical Data Source shall:
- Recieve and validate the query message.
- Create the acknowledgement message.
- Add an ILLEGAL detected issue alert to the acknowledgement message if the content is invalid (e.g., does not pass schema validation or is otherwise malformed), and immediately return a response indicating the error, and that the query was aborted. Set the text of the alert to the name of the first data element that is not valid. The Clincial Data Source may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the query are not valid.
- Add a NAT detected issue alert to the acknowledgement message if the requesting party is not authorized to perform the query, and immediately return a response indicating the error, and that the query was aborted.
- Add a VALIDAT detected issue alert to the acknowledgement message for each of the patientName, patientGenderCode or patientBirthTime fields specified in the query that do not match the values known by the Clinical Data Source Actor. The text value on the alert shall be set to the name of the parameter that does not match (patientName, patientGenderCode or patientBirthTime).
- Add a BUS detected issue alert to the acknowledgement message if includeCarePlanAttachment is true, but care plans are not associated with observation values. The text value on the alert shall be set to includeCarePlanAttachment.
- Add a BUS detected issue alert to the acknowledgement message if a careProvisionReason value is specified, but the Clinical Data Source cannot query by this field. The text value on the alert shall be set to careProvisionReason.
- Add a KEY204 detected issue alert to the acknowledgement message if any of the vocabulary domains are not recognized by the Clinical Data Source. The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
- Add a CODE_INVALID detected issue alert to the acknowledgement message if any of the codes specified are not recognized by the Clinical Data Source. The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
- Add a FORMAT detected issue alert to the acknowledgement message if any date ranges are incorrectly formed (low > high). The text value on the alert shall be set to the name of the query parameter that has the error.
- Add a ILLEGAL detected issue alert to the acknowledgement message if the the Clinical Data Source does not recognize the identity domain used to identify the patient. Set the text value on the alert to patientId.
- Add a KEY204 detected issue alert to the acknowledgement message if the the Clinical Data Source does not know about the patient. Set the text value on the alert to patientId. This is distinct from having nothing to report. If the patient is recognized but there is no data to report, the result returned should simply have no data. However, if information is requested for a patient that isn't known, then the KEY204 alert shall be raised.
- Add an appropriate detected issue alert if any parameters otherwise not specified by this profile have been provided, but are not supported by the Clinical Data Source.
- Add an ISSUE alert to the acknowledgement message if at any time during response generation, an application error occurs that prevents further processing. Set the text of the alert to the reason for the application error (e.g., a stack trace or exception message).
The Clinical Data Source shall send an audit message to the audit log repository indicating that a query was recieved, and the parameters of query that were supplied (see the queryByParameter element above).
The name of the query message shall be QUPC_IN043100UV_Message in the WSDL. The name of the acknowledgement response message shall be MCCI_IN000002UV01 in the WSDL.
The following WSDL snippet defines the types used for this transaction:
Query Message Type Definition
<types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include namespace="urn:hl7-org:v3" schemaLocation="QUPC_IN043100UV.xsd"/>
<xsd:include namespace="urn:hl7-org:v3" schemaLocation="MCCI_IN000002UV01.xsd"/>
</xsd:schema>
</types>
The message type is declared to be of the appropriate type by the following WSDL snippet:
Query Message WSDL Declaration
<message name='QUPC_IN043100UV_Message'>
<part element='hl7:QUPC_IN043100UV' name="Body"/>
</message>
<message name='MCCI_IN000002UV01_Message'>
<part element='hl7:MCCI_IN000002UV01' name="Body"/>
</message>
WSDL Declarations
The following WSDL naming conventions SHALL apply for this transaction:
WSDL Definitions for PCC-9
WSDL Item
Value
wsdl:definitions/@name
CareManager
Get Care Record Query
QUPC_IN043100UV_Message
Message Acknowledgement
MCCI_IN000002UV01_Message
portType
CareManager_PortType
Query Operation
CareManager_QUPC_IN043100UV
SOAP 1.1 binding
CareManager_Binding_Soap11
SOAP 1.1 port
CareManager_Port_Soap11
SOAP 1.2 binding
CareManager_Binding_Soap12
SOAP 1.2 port
CareManager_Port_Soap12
The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Care Manager actor can be found at ftp://ftp.ihe.net/TF_Implementation_Material/PCC/CareManager.wsdl. For a general description of the WSDLs for PCC see the Appendix of the same name in this volume.
Port Type
<portType name="CareManager_PortType">
<operation name="CareManager_QUPC_IN043100UV">
<input message="tns:QUPC_IN043100UV_Message"
wsaw:Action="urn:hl7-org:v3:QUPC_IN043100UV"/>
<output message="MCCI_IN000002UV01_Message"
wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
</operation>
</portType>
Port Types for PCC-9
Bindings
<binding name="CareManager_Binding_Soap12"
type="CareManager_PortType">
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="CareManager_QUPC_IN043100UV">
<wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN043100UV"/>
<input>
<wsoap12:body use="literal"/>
</input>
<output>
<wsoap12:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.2 Binding for PCC-9
<binding name="CareManager_Binding_Soap11"
type="CareManager_PortType">
<wsoap11:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="CareManager_QUPC_IN043100UV">
<wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN043100UV"/>
<input>
<wsoap11:body use="literal"/>
</input>
<output>
<wsoap11:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.1 Binding for PCC-9
V3 Care Management Update
This section corresponds to Transaction PCC-10 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-10 is used by the Care Manager and Clinical Data Repository Actors.
Transaction PCC-10 is a variation of the pattern used in transaction PCC-1 of the PCC Technical Framework. Information specific to this transaction is described in futher detail below in the section on Domain Content.
Use Case Roles
Care Manager
Clinical Data Repository
V3 Care Management Update
- Actor
- Care Manager
- Role
- Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction from the Clinical Data Repository.
- Cooresponding HL7 Version 3 Application Roles
- Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)
- Actor
- Clinical Data Repository
- Role
- Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction from the Clinical Data Repository.
- Cooresponding HL7 Version 3 Application Roles
- Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)
Referenced Standards
Interaction Diagrams
Get Care Record Profile Response
Trigger Events
This message is triggered upon reciept of a Query Care Record Event Profile Query Message. This corresponds to HL7 trigger event: QUPC_TE043200UV
Message Semantics
The Get Care Record Profile Response corresponds to the HL7 Interaction QUPC_IN043200UV. A schema for this interaction can be found at: http://www.hl7.org/v3ballot2007may/html/processable/multicacheschemas/QUPC_IN043200UV.xsd. This schema includes:
- the transmission wrapper MCCI_MT000300UV01,
- the control act wrapper MFMI_MT700712UV01, and
- the message payload REPC_MT004000UV.
These components of the interaction are specified in the HL7 standards described above.
Transmission Wrapper
The transmission wrapper MCCI_MT000300UV01 provides information about the message transmission and routing. Transmission wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction. This message wrapper is similar to the transmission wrapper used for the same interaction in PCC-1, save that the acceptAckCode is different.
<QUPC_IN043200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<id root=' ' extension=' '/>
<creationTime value=' '/>
<interactionId extension='QUPC_IN043200UV' root='2.16.840.1.113883.5'/>
<processingCode code='D|P|T'/>
<processingModeCode code='T'/>
<acceptAckCode code='AL'/>
<receiver typeCode="RCV">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</receiver>
<sender typeCode="SND">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</sender>
<controlActProcess>
See Control Act Wrapper below
</controlActProcess>
</QUPC_IN043200UV>
<QUPC_IN043200UV xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
The HL7 Interaction being sent will control the name of the root element in the message. The namespace of this message shall be urn:hl7-org:v3, and the ITSVersion attribute shall be "XML_1.0".
<interactionId extension='QUPC_IN043200UV' root='2.16.840.1.113883.5'/>
The identifer for the interaction shall be sent as shown above.
<processingModeCode code='T'/>
The processingModeCode distinguishes the type of processing being performed. This element shall be present and have the value shown above to indicate that this message is for current processing.
<acceptAckCode code='AL'/>
The acceptAckCode indicates whether the reciever wants to recieve an acknowledgement, and shall be sent as shown above. Query responses in this transaction shall require an acknowledgement.
Control Act Wrapper
The control act wrapper MFMI_MT700712UV01 provides information about the business actors related to the transaction, including the author or performer of the act. Control act wrappers are further described in ITI TF-2: Appendix O.
An example transmission wrapper is given below for this interaction. Items marked in dark gray are transmitted as specified in ITI TF-2: Appendix O. Items in bold black text are further constrained by this profile in this interaction.
<controlActProcess moodCode="EVN">=
<id root=' ' extension=' '/>
<effectiveTime value=' '/>
<languageCode code=' '/>
<authorOrPerformer typeCode=' '></authorOrPerformer>
<subject>
See Query Response below
</subject>
<queryAck>
<queryId root=' ' extension=' '/>
<statusCode code=' '/>
<queryResponseCode code=' '/>
<resultCurrentQuantity value=' '/>
<resultRemainingQuantity value=' '/>
</queryAck>
</controlActProcess>
<controlActProcess moodCode="EVN">
The controlActProcess element is where information about the business act being performed is recorded. The moodCode is set to "EVN" by the sender to indicate a response to a query.
The trigger event which caused the act to be transmitted is recorded in the code element is recorded as shown above.
<subject>
The <subject> element shall be present to record the responses in a query request or continuation response.
<queryAck>
The queryAck element is transmitted in any message that is a response to a query, query continuation or query cancellation message.
<queryId root=' ' extension=' '/>
The <queryId> element shall be transmitted in a queryAck element. It shall contain an identifier that was used in the original query message.
<statusCode code=' '/>
The statusCode element in the queryAck element indicates the status of the query. It may contain the value 'deliveredResponse' or 'aborted'. If the value is 'aborted', no additional messages should be sent to the data repository for the specified query.
<queryResponseCode code=' '/>
The queryResponseCode element indicates at a high level the results of performing the query. It may have the value 'OK' to indicate that the query was performed and has results. It may have the value 'NF' to indicate that the query was performed, but no results were located. It may have the value 'QE' to indicate that an error was detected in the incoming query message, or 'AE' to indicate some other application error occurred.
<resultCurrentQuantity value=' '/>
The resultCurrentQuantity element shall be present, and shall enumerate number of results returned in the current response.
<resultRemainingQuantity value=' '/>
This resultRemainingQuantity element may be present. It shall enumerate the number of additional results known to follow the results currently returned. Because these queries have long lifetimes, additional results may be added at any time.
Query Response
The <subject> element of the <controlActProcess> element shall appear as shown in the example below.
<subject>
<registrationEvent>
<statusCode code='active'/>
<custodian>
<assignedEntity>
<id root='' extension=''/>
<addr></addr>
<telecom></telecom>
<assignedOrganization>
<name></name>
</assignedOrganization>
</assignedEntity>
</custodian>
<subject2>
<careProvisionEvent>
<recordTarget>
<patient>
<id root='' extension=''/>
<addr></addr>
<telecom value='' use=''/>
<statusCode code='active'/>
<patientPerson>
<name></name>
<administrativeGenderCode code='' displayName=''
codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
<birthTime value=''/>
</patientPerson>
</patient>
</recordTarget>
<pertinentInformation3>
<!-- Domain Content -->
</pertinentInformation3>
</careProvisionEvent>
</subject2>
</registrationEvent>
</subject>
<subject>
The <subject> element shall be present, and is where the results are returned.
<registrationEvent>
At least one <registrationEvent> element shall be be present for each set of records returned from a different custodial source or patient (in the case of population queries).
The <registrationEvent> is used to record the information about how the <careProvisionEvent> being returned was recorded or "registered" in the custodial system. The response to a Care Profile query is a CareProvisionEvent that is constructed in response to the query. This <careProvisionEvent> is transitory in nature, and is has limited "registration" information content.
A Data Repository that aggregates information from two or more other data repositories shall separate the information into multiple <registrationEvent> elements so as to record the different custodians of the information.
<statusCode code='active'/>
The <statusCode> element records the status of the data records. Queries always return active records, not replaced records, so the value of this element shall always be returned as 'active'. Note that an active record may reference the record that it replaces in the result. The replaced record so referenced does not count towards the number of results returned.
<custodian>
The <custodian> element records the data repository that is the custodian, or "owner", of the data record. A Data Repository actor may return records from multiple custodians, but shall separate the data records from each custodian into different <registrationEvent> elements.
<assignedEntity>
The <assignedEntity> element shall be present, and provides contact and identification information about the <custodian>.
<id root=' ' extension=' '/>
The <id> element shall be present, and shall uniquely identify the custodian of the data records.
<addr></addr>
The <addr> element shall be present, and shall provide a postal address for the custodian of the data records.
<telecom></telecom>
At least one <telecom> element shall be present that provides a telephone number to contact the custodian of the data records.
A <telecom> element may be present that provides the web service end-point address of the custodian of the data records.
For Public Comment
How might the web service end-point address be used? Is it a good idea to include it, or should we omit this from the profile?
<assignedOrganization>
<name></name>
</assignedOrganization>
The name of the organization that is the custodian of the data records shall be provided.
<subject2>
The <subject2> element provides the data content requested from the query.
<careProvisionEvent>
The <careProvisionEvent> elements returned by the Care Record Profile Query are compositions based upon the information requested in the query. It is transitory in nature, and does not necessarily coorespond to a single care provision activity stored within the data repository.
<recordTarget>
The <recordTarget> element records information about the patient for whom the Data Repository is returning results.
<patient>
The <patient> element contains information identifying the patient and providing contact information.
<id root=' ' extension=' '/>
At least one <id> element shall be present that identifies the patient. This <id> element shall be the same as the value of the <patientId> passed in the query. Other <id> elements may be present.
<addr></addr>
At least one <addr> element shall be present to provide a postal address for the patient. It may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<telecom value=' ' use=' '/>
At least one <telecom> element shall be present to provide a telephone number to contact the patient. It may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera). Other <telecom> elements may be present to contain other contact methods, e.g., e-mail. One cannot determine from a <telecom> element with the nullFlavor attribute whether it is supposed to contain a telephone number, e-mail address, URL, or other sort of telecommunciations address. Due to this limitation, the assumption will be made that a <telecom> element with a nullFlavor attribute represents a telephone number that is unavailable.
<statusCode code='normal'/>
The <statusCode> element shall be present, and shall be represented exactly as shown above. This indicates that the role of patient is in one of the normal states, e.g., has not been explicitly removed or "nullified".
<patientPerson>
The <patientPerson> element shall be present, and provides further identification information about the patient.
<name></name>
The <name> element shall be present, and normally provides the patient's name. The <name> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<administrativeGenderCode code=' ' displayName=' '
codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>
The <administrativeGenderCode> element shall be present, and normally provides the patient's gender using the HL7 AdministrativeGender vocabulary. The <administrativeGender> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<birthTime value=' '/>
The <birthTime> element shall be present, and normally provides the patient's birthTime. The <birthTime> element may have the nullFlavor attribute set to UNK if unknown (e.g., for a repository that contains pseudonomized information), or set to MSK for repositories that may contain the information, but which do not choose to divulge the information (e.g., due to access permissions, et cetera).
<pertinentInformation3>
<!-- Domain Content>
<pertinentInformation3>
This data element shall be present. It shall contain one of the data elements found in the Data Repository that matches the specified query parameters. The content of this data element is a care statement that varies depending upon the specific transaction, and is futher defined in the section on Domain Content. Each care statement shall have at least one <author> element that indicates to whom the care statement is attributed. Each care statement may have zero or more <informant> elements that indicates who provided information related to the care statement. See the section below on Authors and Informants for more information on how this information should be recorded.
Expected Actions -- Clinical Data Source
The Clinical Data Source shall send a response as specified in the QUPC_IN043200UV interaction. The message shall be sent using web services as specified in the ITI-TF: Appendix V.
The Clinical Data Source shall populate the message with the appropriate responses using the appropriate templates specified in Care Management Data Query under the <careProvisionCode> query parameter.
Expected Actions -- Care Manager
The Care Manager processes the query response data. The Care Manager shall respond with an acknowledgement as specified in the QUPC_IN043200UV interaction.
The name of the query response message shall be QUPC_IN043200UV_Message in the WSDL.
The following WSDL snippet defines the type for this message:
Query Response Message Type Definition
<types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<xsd:import namespace="urn:hl7-org:v3"
schemaLocation="QUPC_IN043200UV.xsd"/>
<xsd:include namespace="urn:hl7-org:v3"
schemaLocation="MCCI_IN000002UV01.xsd"/>
<xsd:element name="QUPC_IN043200UV"/>
</xsd:schema>
</types>
The message type is declared to be of the appropriate type by the following WSDL snippet:
Query Respone Message WSDL Declaration
<message name='QUPC_IN043200UV_Message'>
<part element='hl7:QUPC_IN043200UV' name="Body"/>
</message>
<message name='MCCI_IN000002UV01_Message'>
<part element='hl7:MCCI_IN000002UV01' name="Body"/>
</message>
WSDL Declarations
The following WSDL naming conventions SHALL apply for this transaction:
WSDL Definitions for PCC-10
WSDL Item
Value
wsdl:definitions/@name
ClinicalDataSource
Get Care Record Query Response
QUPC_IN043200UV_Message
Message Acknowledgement
MCCI_IN000002UV01_Message
portType
ClinicalDataSource_PortType
Query Response Operation
ClinicalDataSource_QUPC_IN043200UV
SOAP 1.1 binding
ClinicalDataSource_Binding_Soap11
SOAP 1.1 port
ClinicalDataSource_Port_Soap11
SOAP 1.2 binding
ClinicalDataSource_Binding_Soap12
SOAP 1.2 port
ClinicalDataSource_Port_Soap12
The following WSDL snippets specify the Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V. A full WSDL example for the Clinical Data Source actor can be found at ftp://ftp.ihe.net/TF_Implementation_Material/PCC/ClinicalDataSource.wsdl. For a general description of the WSDLs for PCC see the Appendix of the same name in this volume.
Port Type
<portType name="ClinicalDataSource_PortType">
<operation name="ClinicalDataSource_QUPC_IN043200UV">
<input message="tns:QUPC_IN043200UV_Message"
wsaw:Action="urn:hl7-org:v3:QUPC_IN043200UV"/>
<output message="MCCI_IN000002UV01_Message"
wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01"/>
</operation>
</portType>
Port Types for PCC-10
Bindings
<binding name="ClinicalDataSource_Binding_Soap12"
type="ClinicalDataSource_PortType">
<wsoap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="ClinicalDataSource_QUPC_IN043200UV">
<wsoap12:operation soapAction="urn:hl7-org:v3:QUPC_IN043200UV"/>
<input>
<wsoap12:body use="literal"/>
</input>
<output>
<wsoap12:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.2 Binding for PCC-10
<binding name="ClinicalDataSource_Binding_Soap11"
type="ClinicalDataSource_PortType">
<wsoap11:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="ClinicalDataSource_QUPC_IN043200UV">
<wsoap11:operation soapAction="urn:hl7-org:v3:QUPC_IN043200UV"/>
<input>
<wsoap11:body use="literal"/>
</input>
<output>
<wsoap11:body use="literal"/>
</output>
</operation>
</binding>
SOAP 1.1 Binding for PCC-10
V2 Care Management Update
This section corresponds to Transaction PCC-11 of the IHE Patient Care Coordination Technical Framework. Transaction PCC-11 is used by the Care Manager and Clinical Data Repository Actors.
Transaction PCC-11 sends the appropriate HL7 Version 2 message defined by the guideline in the Guideline Notification transaction and that was requested in the Care Management Data Query.
The Clinical Data Source actor must be able to understand what kind of HL7 Version 2 message is being requested when interpreting the Care Management Data Query transaction issued by the Care Manager actor. How HL7 messages are described using the HL7 Version 3 act structure is now described below.
To fully describe an HL7 Version 2 message, this profile makes use of two infrastructure attributes specified on all RIM classes, and the <code> element of the act:
The XML fragment below is an act, in definition mood, that describes the definition of acts of interest to a Care Manager. These acts are represented in a <guideline> element as described in the Guideline Notification transaction. An example appears below:
<actDefinition classCode='ACT' moodCode='DEF'>
<typeId root='2.16.840.1.113883.12.354' extension='ADT_A01'/>
<templateId root='2.16.840.1.113883.9.2.2'/>
:
</actDefinition>
- typeId
- Describes the constraints imposed by a message type definition. In HL7 Version 2, Table 354 identifies the message structures (or types of messages) that can be sent using the HL7 Version 2 standard. This table can be found in Chapter 2 (Control/Query) of the HL7 Version 2 standard. The example above describes the message of interest as using message structure ADT_A01, which is used to convey that a patient has arrived at a facility.
- templateId
- Describes the constraints imposed by a template definition. Conformance profiles introduced in HL7 Version 2 are templates which further constrain a specific message structure. HL7 makes available a registry of conformance profiles that have been registered with HL7 to its members at http://www.hl7.org/memonly/conformance/. In the example given above, the profile identifer is given in the <templateId> element, and identifies the specific HL7 Conformance profile that further constrains the message.
- code
- Describes the specific event (or act) which is of interest in the code attribute. The value for the code attribute comes from table 3 of the HL7 Version 2 standard, which is identified using the codeSystem value 2.16.840.1.113883.12.3. In the example above, the act is the trigger event, A01 (Admit/Visit Notification). We further specify that the code (A01) used to identify that act comes from version 2.4 of the specified codeSystem.
Having demonstrated how to represent a kind of HL7 message in a guideline, we next demonstrate how it appears in a query, as shown in the example below.
<parameterList>
:
<careProvisionCode>
<value code='A01' codeSystem='2.16.840.1.113883.12.3' codeSystemVersion='2.4'/>
</careProvisionCode>
</parameterList>
For Public Comment
As you can see, the <parameterList> element above does not completely identify the act that is of interest (the message to be returned by the Clinical Data Source). There are several approaches we have considered to address this:
- Create a code system whose values are the template identifiers (or Conformance profile identifiers in this example), an use those template identifiers in the code attribute of the <value> element. This is a hack that will work.
- Allow the meaning of templateId to be context sensitive, so that in the context of a query parameter, a templateId might simply assert that the expected response to the query would be an item matching that templateId, also a hack that will work.
- Leave the query for an HL7 V2 response as shown above, with the expectation that the specific conformance profile used to respond to the query will be provided out of band.
Our expectation is that the V2 Care Mnaagement Update message will initially require out of band configuration in any case, as the Clinical Data Sources using the HL7 Version 2 Option are not be required to support reciept of the Care Management Data Query transaction.
Use Case Roles
Care Manager
Clinical Data Source
V2 Care Management Update
- Actor
- Care Manager
- Role
- Recieves the HL7 Version 2 message matching the selection criteria in a prior PCC-9 transaction, or otherwise configured out of band with the Clinical Data Source.
- Actor
- Clinical Data Source
- Role
- Sends the HL7 Version 2 message matching the selection criteria found in a prior PCC-9 transaction from the Clinical Data Repository, or preconfigured.
Referenced Standards
Interaction Diagrams
Send Message
Trigger Events
When the indicated trigger event occurs, or at the times scheduled in the Care Management Data Query transaction, the Clinical Data Source shall send an HL7 Version 2 message, or if requested in the query transaction, the next batch of HL7 Version 2 messages to the recipient indicated in the <respondTo> element of the query.
Message Semantics
The semantics of the message are determined by the HL7 Version 2 Conformance Profile that has been specified for use in the guidelines being applied to the specific use of the Care Management profile (see http://www.hl7.org/memonly/conformance/index.cfm).
The message shall be sent using the HL7 Minimum Lower Layer Protocol (MLLP), as described in ITI TF-2:Appendix C.2 HL7 Implementation Notes
Expected Actions -- Clinical Data Source
Real-Time Mode
- Upon detection of a qualifying event, the clinical data source shall produce and send the appropriate HL7 Version 2 message for the event to the recipient indicated in the <respondTo> element of the Care Management Data Query) transaction triggering the notification.
- The Clinical Data Source shall await an acknowledgement of the message.
- If errors are noted in any of the messages sent in the batch, an operator will be alterted.
Batch Mode
- The Clinical Data Source shall take note of qualifying events.
- At the scheduled time (see <executionAndDeliveryTime> in Care Management Data Query), the clinical data source shall produce the appropriate HL7 Version 2 message for each event noted above identified by the query (and guideline).
- The Clinical Data Source shall send an HL7 Version 2 Batch message to the recipient indicated in the <respondTo> element of the Care Management Data Query) transaction. This message shall contain all of the HL7 Version 2 messages it produced in the previous step. If no messages are produced, it shall produce an empty HL7 Version 2 batch.
- The Clinical Data Source shall await an acknowledgement of the batch.
- If errors are noted in any of the messages sent in the batch, an operator will be alterted.
Message Acknowledgement
The Care Manager shall send an acknowledgement indicating that it has recieved the messages.
Trigger Events
The trigger event for the response is the reciept of a new real-time or batch response from the sender.
Message Semantics
Expected Actions -- Care Manager
Real-Time Mode
The Care Manager will validate the message content, and return an acknowledgement to the sender.
Batch Mode
The Care Manager will validate the message content for each message in the batch, and return batch acknowledgement to the sender. The batch acknowledgement shall contain only negative responses.
Expected Actions -- Clinical Data Source
The Clinical Data Source will correct any errors reported by the Care Manager and will resend the corrected messages at the next opportunity.