PCC-10

From IHE Wiki
Jump to navigation Jump to search

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
Usecase.png
Care Management Data Query
Actor
Care Manager
Role
Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction from the Clinical Data Repository.
Cooresponding HL7 Version 3 Application Roles
Care Record Query Placer (QUPC_AR004030UV)
Query by Parameter Placer (QUQI_AR000001UV01)
Actor
Clinical Data Repository
Role
Recieves a collection of clinical data matching the selection criteria in a prior PCC-9 transaction from the Clinical Data Repository.
Cooresponding HL7 Version 3 Application Roles
Care Record Query Fulfiller (QUPC_AR004040UV)
Query by Parameter Fulfiller (QUQI_AR000002UV01)


Referenced Standards

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

Interaction Diagrams

Cmpcc10id.gif


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 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>
Expected Actions -- Care Manager

The Care Manager processes the query response data. If the response indicates that more data is available, the Care Manager can request additional data using the General Query Activate Query Continue message, indicating which data is being requested.

General Query Activate Query Continue

Note: Do we need this? If not, how will the Care Manager handle "flow control"? Control-S and Control-Q just doesn't seem to cut it


Trigger Events

When a Care Manager 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 is recorded as shown above. incoming query message, or 'AE' to indicate some other application error occurred.

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 repository. If this element is omitted, results will be sent that follow the last set of results sent. Results are numbered from 1, so setting this value to 1 will start with the first result returned. Setting this value to a number less than 1 will result in undefined application behavior.

<continuationQuantity value=' '/>

The continuationQuantity element 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 repository may send fewer results than requested, but shall send no more than this value.

Expected Actions -- Care Manager

Upon completion of all result processing, the Care Manager shall send a General Query Query Activate Continue message to obtain additional results.

The Data Repository 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 Care Manager 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 -- Care Manager

When finished with all query results, the Care Manager 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.

Expected Actions -- Clinical Data Source

The Clinical Data Source shall respond to the Cancellation message with an acknowledgement.

Domain Content

This section lists the requirements specific to the Query Vital Signs transaction.


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

Get Care Record Profile Query

careProvisionCode

A Care Manager may specify the value COBSCAT from the from the HL7 ActCode vocabulary (2.16.840.1.113883.5.4) domain to obtain all matching observations that coorespond to the LOINC code values from the table in Vital Signs Observation reproduced below. A Care Manager may use any of the LOINC code values from this table to obtain any specific vital sign result.

Vital Signs Codes
LOINC Description Units Type
9279-1 RESPIRATION RATE /min PQ
8867-4 HEART BEAT
2710-2 OXYGEN SATURATION %
8480-6 INTRAVASCULAR SYSTOLIC mm[Hg]
8462-4 INTRAVASCULAR DIASTOLIC
8310-5 BODY TEMPERATURE Cel or [degF]
8302-2 BODY HEIGHT (MEASURED) m, cm,[in_us] or [in_uk]
8306-3 BODY HEIGHT^LYING
8287-5 CIRCUMFRENCE.OCCIPITAL-FRONTAL (TAPE MEASURE)
3141-9 BODY WEIGHT (MEASURED) kg, g, [lb_av] or [oz_av]

A Care Manager Actor may make requests using other codes to obtain other common observations, but these are not guaranteed to be available in all cases. For example, a Care Manager might use values from the table in Pregnancy Observations.

As a rule of thumb, if it is a measurement that does not require special diagnosic equipment to be performed, or a value that may be reported by a patient that is not indicitive on its own as a medical condition, then it can be considered to be a common observation. Other common observations that may be included are measures such as glucometer readings, date of last menstruation (e.g., as would be used to estimate date of delivery during perinatal care), et cetera. A specific lab result would not be obtained using this transaction, nor would patient risk factors (e.g. ETOH (Alcohol) use), or the presence of any specific problems.

Get Care Record Profile Response

A Clinical Data Repository Actor shall respond to a query request by returning clinical statements that are returned within <pertinentInformation3> data elements.

When careProvisionCode is set to COBSCAT from the HL7 ActCode vocabulary domain, the Vital Signs Repository 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 Repository 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.

A Clinical Data Repository Actor may respond to requests using other LOINC codes to return other common observations. These observations shall conform to the Simple Obervations entry template.

All observations returned shall specify the author or authors of the observation in an <author> element, and may indicate the informants in <informant> elements.

WSDL Declarations

The following WSDL naming conventions SHALL apply for this transaction:

WSDL Definitions for PCC-1
WSDL Item Value
wsdl:definitions/@name VitalSigns
Get Care Record Query QUPC_IN043100UV_Message
Message Acknowledgement MCCI_IN000002UV01_Message
portType VitalSigns_PortType
Query Operation VitalSigns_QUPC_IN043100UV
SOAP 1.1 binding VitalSigns_Binding_Soap11
SOAP 1.1 port VitalSigns_Port_Soap11
SOAP 1.2 binding VitalSigns_Binding_Soap12
SOAP 1.2 port VitalSigns_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 Vital Signs actor can be found at ftp://ftp.ihe.net/TF_Implementation_Material/PCC/VitalSigns.wsdl. For a general description of the WSDLs for PCC see the Appendix of the same name in this volume.

Port Type
<portType name="VitalSigns_PortType">
 <operation name="VitalSigns_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-1
Bindings
<binding name="VitalSigns_Binding_Soap12" 
   type="VitalSigns_PortType">
 <wsoap12:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="VitalSigns_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="VitalSigns_Binding_Soap11" 
   type="VitalSigns_PortType">
 <wsoap11:binding style="document"
   transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="VitalSigns_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
Retrieved from "http://wiki.ihe.net/index.php?title=PCC-10&oldid=20262"