PCC-1

Query Vital Signs

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 Vital Signs Data Repository Actors.

Transaction PCC-1 is uses the same pattern as other transactions in the PCC Technical Framework: PCC-2, PCC-3, PCC-4 and PCC-5. The sections below first describe the general requirements of all of these transactions. Information specific to this transaction is described in futher detail below in the section on Domain Content.

Use Case Roles

Clinical Data Consumer		Vitals Signs Data Repository
Query Vital Signs

Actor

Clinical Data Consumer

Role

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

Actor

Vitals Signs Data Repository

Role

Returns vital signs measurements matching the selection criteria supplied by the Clinical Data Consumer.

Referenced Standards

CareRecord	HL7 Care Provision Care Record (DSTU)
CareQuery	HL7 Care Provision Care Record Query (DSTU)
HL7WS	HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release
WSDL	Web Services Description Language (WSDL 1.1)
SOAP	Simple Object Access Protocol (SOAP 1.1)

Interaction Diagrams

Get Care Record Profile Query

Trigger Events

The Clinical Data Consumer's need to obtain information about a patient will trigger the query, based on the following HL7 trigger event: QUPC_TE043100UV

Message Semantics

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

This interaction uses the message element QUPC_IN043100UV as defined in QUPC_IN043100UV.xsd. The message infrastructure content shall be filled out as described in the Message Infrastructure section of the appendix on Sending HL7 Version 3 Messages. The control act process content shall be filled out as described in the Control Act Process section in that same appendix. Addition restrictions are found in the section below describing the Domain Content for the Get Care Record Profile Query.

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 send this parameter. The Repository column indicates whether the Data Repository 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 Data Repository in its response.

Query Parameters

Parameter Name	Cardinality	Data Type	Vocabulary Domain	Consumer	Repository
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

Each of the parameters is described in more detail below.

<queryByParameter>
  <statusCode code='new'/>
  <initialQuantity value=''/>
  <initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'>
  <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>
</queryByParameter>

<queryByParameter>

The <queryByParameter> element shall be present, and contains all of the query parameters that are being requested by the Clinical Data Consumer.

<statusCode code='new'/>

The <statusCode> element is required, and shall have the value new as shown above to indicate that this is a new query.

<initialQuantity value=/>

The <initialQuantity> element may be sent to indicate the number of care statements returned. A Data Repository shall return no more than the requested number of initial values.

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

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). For these queries, what is being counted is clinical statements, so the code to use shall be REPC_RM000100UV.

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

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 [fnord].

Specific results or categories of results may be requested using the codes listed in the domain content section below.

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

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.

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

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>

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>

This element is set to either true or false depending upon whether care plans should be returned or not. A Data Repository 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).

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

<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 Repository will raise a detected issue alert.

Expected Actions -- Clinical Data Consumer

The clinical data consumer shall send a query as specified in the QUPC_MT040300UV message type.

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 cooresponds to the HL7 Interaction QUPC_IN043200UV.

This interaction uses the message element QUPC_IN043200UV as defined in QUPC_IN043200UV.xsd. The message infrastructure content shall be filled out as described in Message Infrastructure in the appendix on Sending HL7 Version 3 Messages. The Control Act Process content shall be filled out as described in Control Act Process in that same appendix.

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 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 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 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 varies depending upon the specific transaction, and is futher defined in the section on Domain Content

<parameterList>

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

Expected Actions -- Data Repository

Response to a New Query

The Data Repository, shall:

1. Recieve and validate the query message.
2. Create the response message.
3. Add an ILLEGAL detected issue alert to the response message if the content is invalid (e.g., does not pass schema validation or is otherwise malformed), and immediately return a response indicating the error, and that the query was aborted. Set the text of the alert to the name of the first data element that is not valid. The Data Repository may send more than one ILLEGAL detected issue alert if it is able to determine that multiple data elements in the query are not valid.
4. Add a NAT detected issue alert to the response message if the requesting party is not authorized to perform the query, and immediately return a response indicating the error, and that the query was aborted.
5. Add a 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 Repository Actor. The text value on the alert shall be set to the name of the parameter that does not match (patientName, patientGenderCode or patientBirthTime).
6. Add a BUS detected issue alert to the 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.
7. Add a BUS detected issue alert to the response message if a careProvisionReason value is specified, but the Data Repository cannot query by this field. The text value on the alert shall be set to careProvisionReason.
8. Add a KEY204 detected issue alert to the response message if any of the vocabulary domains are not recognized by the Data Repository. The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
9. Add a CODE_INVALID detected issue alert to the response message if any of the codes specified are not recognized by the Data Repository. The text value on the alert shall be set to the name of the query parameter that used the unrecognized vocabulary domain.
10. Add a FORMAT detected issue alert to the 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.
11. 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 patient. Set the text value on the alert to patientId.
12. Add a KEY204 detected issue alert to the response message if the the data repository does not know about the patient. Set the text value on the alert to patientId. This is distinct from having nothing to report. If the patient is recognized but there is no data to report, the result returned should simply have no data. However, if information is requested for a patient that isn't known, then the KEY204 alert shall be raised.
13. Add an appropriate detected issue alert if any parameters otherwise not specified by this profile have been provided, but are not supported by the Data Repository.
14. If any issues were detected, Set queryAck/statusCode/@code to aborted, and queryAct/queryResponse/@code to QE, and return the response.
15. 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.
16. Query for the data requested by the query.
17. If results are found, set queryAct/queryResponse/@code to OK, otherwise set it to NF.
18. Set queryAck/statusCode/@code to deliveredResponse.
19. Add any results to the response up to the maximum number of history statements requested.
20. If all results have been returned, release the query results.

A conforming Data Repository 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 Repository, shall:

1. Recieve and validate the query continuation message.
2. 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 Repository 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.
3. Create the response message.
4. Add a KEY204 detected issue alert to the response message if the the data repository does not recognize the queryId.
5. Add a VALIDAT detected issue alert to the response message if the query was previously aborted or otherwise terminated.
6. 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 Repository.
7. If any issues were detected, Set queryAck/statusCode/@code to aborted, and queryAct/queryResponse/@code to QE, and return the response.
8. 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.
9. Scroll to the result requested in queryContinuation/startResultNumber, querying additional data if necessary.
10. If more results are found, set queryAct/queryResponse/@code to OK, otherwise set it to NF.
11. If no more results are found, ensure that the queryAck/resultTotalQuantity indicates the toal number of results found.
12. Set queryAck/statusCode/@code to deliveredResponse.
13. Add any results to the response up to the maximum number of history statements requested.
14. Return the response message.
15. 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 Repository, shall:

1. Recieve and validate the query cancelation message.
2. Create the response message.
3. Add an ILLEGAL detected issue alert to the response message if the content is invalid (e.g., does not pass schema validation or is otherwise malformed), and immediately return a response indicating the error, and that the query was aborted. Set the text of the alert to the name of the first data element that is not valid. The Data Repository 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.
4. Add a KEY204 detected issue alert to the response message if the the data repository does not recognize the queryId.
5. 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 Repository.
6. 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).
7. Set queryAck/statusCode/@code to aborted,
8. 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.
9. Return the response message.
10. 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 applaction error occured, the <text> element shall contain diagnostic information (e.g., stack trace or exception message).

<mitigatedBy>

If the reason for the alert was an incorrect code (CODE_INVALID), the alert may contain one or more <mitigatedBy> elements that supply legal codes from specified vocabulary. Of the reason for the alert was an incorrect vocabulary (KEY204), the alert may contain one or more <mitigatedBy> elements that supply legal vocabularies to use in the request.

<detectedIssueManagement moodCode="DEF">

The <detectedIssueManagement> element shall be present as shown above.

<code code= displayName= codeSystem= codeSystemName=>

The <code> element shall contain the value ??? from codeSystem ??? to indicate that code or vocabulary subsitution is required.

For Public Comment

Ideally, there should be a way for the Clinical Data Consumer to determine what vocabularies are supported by a Data Repository, to allow for vocabulary negotiation. The detectedIssue element could return the list of vocabularies supported in some way.

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

The Clinical Data Consumer's need to obtain more information about a patient 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 cooresponds to the HL7 Interaction QUPC_IN043100UV.

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.

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 cooresponds to the HL7 Interaction QUPC_IN043100UV.

Domain Content

Get Care Record Profile Query

careProvisionCode

A Clinical Data Consumer 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 Clinical Data Consumer 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 Clinical Data Consumer 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 Clinical Data Consumer 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 Vital Signs 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 Vital Signs 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 Vital Signs 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.