IHE ITI Technical Framework
The Final Text ITI Technical Framework is published here in HTML format and is no longer published as PDF. Trial Implementation supplements are available from the Volume 1 Table of Contents.

3.21 Patient Demographics Query [ITI-21]

This section corresponds to transaction [ITI-21] of the IHE IT Infrastructure Technical Framework. Transaction [ITI-21] is used by the Patient Demographics Consumer and Patient Demographics Supplier Actors.

3.21.1 Scope

This transaction involves a request by the Patient Demographics Consumer for information about patients whose demographic data match data provided in the query message. The request is received by the Patient Demographics Supplier Actor. The Patient Demographics Supplier immediately processes the request and returns a response in the form of demographic information for matching patients.

3.21.2 Use Case Roles

Actor: Patient Demographics Consumer

Role: Requests a list of patients matching the supplied set of demographics criteria (example: ID or Name) from the Patient Demographics Supplier.

Actor: Patient Demographics Supplier

Role: Returns demographic information for all patients matching the demographic criteria provided by the Patient Demographics Consumer.

3.21.3 Referenced Standards

HL7

Version 2.5, Chapter 2 – Control

Version 2.5, Chapter 3 – Patient Administration

Version 2.5, Chapter 5 – Query

3.21.4 Messages

Figure 3.21.4-1: Interaction Diagram

3.21.4.1 Patient Demographics Query

3.21.4.1.1 Trigger Events

A Patient Demographics Consumer’s need to select a patient based on demographic information about patients whose information matches a minimal set of known data will trigger the Patient Demographics Query based on the following HL7 trigger event:

Q22 – Find Candidates

3.21.4.1.2 Message Semantics

The Patient Demographics Query is conducted by the HL7 QBP^Q22 message. The Patient Demographics Consumer shall generate the query message whenever it needs to select from a list of patients whose information matches a minimal set of demographic data. The segments of the message listed below are required, and their detailed descriptions are provided in the following subsections.

Table 3.21-1: QBP Query by Parameter

QBP Query by Parameter Chapter in HL7 2.5
MSH Message Header 2
QPD Query Parameter Definition 5
RCP Response Control Parameter 5
[DSC] Continuation Pointer 2

The receiver shall respond to the query by sending the RSP^K22 message. This satisfies the requirements of original mode acknowledgment; no intermediate ACK message is to be sent.

Each Patient Demographics Query request specifies two distinct concepts. The Patient Demographics Query is always targeted at a single source of patient demographic information (referred to in this transaction as the patient information source ). A Patient Demographics Supplier may have knowledge of more than one source of demographics. A Patient Demographics Supplier shall support at least one source of patient demographics and may support multiple sources of demographics. Section 3.21.4.1.2.1 describes how the Patient Demographics Consumer specifies which source of demographics is requested by the query. Each query response shall return demographics from a single patient information source.

The second concept present in the query is the set of patient identifier domains referenced by the query. These patient identifier domains may or may not be associated with the patient information source. A Patient Demographics Supplier shall support at least one patient identifier domain and may support multiple identifier domains. Section 3.21.4.1.2.2 describes how the Patient Demographics Consumer requests identifiers from one or more patient identifier domains. Query responses may return patient identifiers from 0, 1 or multiple patient identifier domains.

3.21.4.1.2.1 MSH Segment

The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2: C.2.2).

The Patient Demographics Supplier is able to obtain demographics from at least one and possibly multiple patient information sources. When more than one patient information source is available, Field MSH-5-Receiving Application specifies the patient information source that this query is targeting. The Patient Demographics Supplier shall return this value in MSH-3-Sending Application of the RSP^K22 response. The value specified in MSH-5 is not related to the value requested in QPD-8 What Domains Returned.

A list shall be published of all Receiving Applications that the Patient Demographics Supplier supports, for the Patient Demographics Consumer to choose from. Each query is processed against one and only one source of patient demographic information.

Field MSH-9-Message Type shall have all three components populated with a value. The first component shall have a value of QBP ; the second component shall have a value of Q22 . The third component it shall have a value of QBP_Q21 .

3.21.4.1.2.2 QPD Segment

The Patient Demographics Consumer shall send attributes within the QPD segment as described in Table 3.21-2.

Table 3.21-2: IHE Profile - QPD segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 250 CE R 0471 01375 Message Query Name
2 32 ST R+ 00696 Query Tag
3 QIP R Demographics Fields
8 CX O What Domains Returned

Adapted from the HL7 standard, version 2.5

The Consumer shall specify “IHE PDQ Query” for QPD-1.1 Message Query Name. All other components of Message Query Name shall not be populated.

3.21.4.1.2.3 Populating QPD-3-Demographics Fields

Field QPD-3-Demographics Fields consists of one or more repetitions, each of which contains two components that together contain the name and value of a distinct parameter to the query. Acceptable segments are PID and PD1. Requirements stated in Appendix E apply to parameters of the datatype CX. In particular, specifying @PID.3.1 without @PID.3.4 is not allowed.

Note:   The Patient Demographics Consumer may need to provide an Assigning Authority if the human operator has not provided one.

The first component of each parameter contains the name of an HL7 element in the form

  @<seg>.<field no>.<component no>.<subcomponent no>

The above format is populated according to common HL7 usage for specifying elements used in query parameters, as follows:

<seg> represents a 3-character segment ID from the HL7 Standard.

<field no> is the number of a field within the segment as shown in the SEQ column of the segment attribute table for the segment selected.

<component no>, for fields whose data types contain multiple components, shall contain the cardinal number of the component being valued. For fields whose data types do not contain multiple components, <component no> shall not be valued and its preceding period shall not appear.

<subcomponent no>, for components whose data types contain multiple subcomponents, shall contain the cardinal number of the subcomponent being valued. For components whose data types do not contain multiple subcomponents, <subcomponent no> shall not be valued and its preceding period shall not appear.

The second subcomponent of each parameter contains the value that is to be matched. If it is desired to constrain the quality of a match within the bounds of an algorithm known to the Supplier, the algorithm and constraint values may be specified in Fields QPD-4 through QPD-7.

The Patient Demographics Consumer may specify, and the Patient Demographics Supplier shall support, the fields in Table 3.21-3. If the Pediatric Demographics Option is supported, then additionally, the Patient Demographics Consumer may specify, and the Patient Demographics Supplier shall support, the fields in Table 3.21-4.

The Patient Demographics Supplier shall return demographic records that reflect the best fit to all of the search criteria.

Table 3.21-3: IHE Profile – QPD-3 fields required to be supported

FLD ELEMENT NAME
PID.3 Patient Identifier List
PID.5 Patient Name
PID.7 Date/Time of Birth
PID.8 Administrative Sex
PID.11 Patient Address
PID.18 Patient Account Number

Table 3.21-4: IHE Profile – Additional QPD-3 fields required to be supported if the Pediatric Demographic Option is supported

FLD ELEMENT NAME
PID.6 Mother’s Maiden Name
PID.13 Phone Number - Home

An example of parameter expressions in QPD-3:

@PID.5.1.1^SMITH~@PID.8^F

requests all patients whose family name (first subcomponent (data type ST) of the first component (data type FN) of PID-5-Patient Name (data type XPN)) matches the value ‘SMITH’ and whose sex (PID-8-Sex (data type IS)) matches the value ‘female’.

3.21.4.1.2.4 Populating QPD-8-What Domains Returned

As is specified in the discussion of the Find Candidates (Q22) Query in Chapter 3 of the HL7 Standard, field QPD-8 restricts the set of domains for which identifiers are returned in PID-3:

  1. In a multiple-domain environment, QPD-8 may be used to identify one or more domains of interest to the Patient Demographics Consumer and from which the Consumer wishes to obtain a value for PID-3-Patient Identifier . Note that the patient information source designated by MSH-5 may or may not be associated with any of the Patient ID Domains listed in QPD-8-What Domains Returned .
  2. If QPD-8 is empty, the Patient Demographics Supplier shall return all Patient IDs known by the Patient Demographics Supplier for each patient that matches the search criteria. See Case 1 in Section 3.21.4.2.2.8 for details on how this information is returned.
  3. If QPD-8 is specified and the domains are recognized, the Patient Demographics Supplier shall return the Patient IDs for each patient that matches the search criteria. See Case 2 in Section 3.21.4.2.2.8 for details on how this information is returned.
  4. Any domain not recognized by the Patient Demographics Supplier is an error condition. See Case 3 in Section 3.21.4.2.2.8 how to handle this condition.
  5. In a single-domain environment, QPD-8 may be ignored by the Patient Demographics Supplier. The Supplier shall always return the identifier from the Patient ID Domain known by the Patient Demographics Supplier.

Within field QPD-8, only component 4 (Assigning Authority) shall be valued.

The Patient Demographics Supplier may or may not be able to supply additional identifiers from the domains specified in QPD-8. A discussion of how QPD-8 is processed is included in the architectural discussion in the “Using Patient Data Query (PDQ) in a Multi-Domain Environment” section ( ITI TF-2: Appendix M ).

The Patient Demographics Consumer shall be able to support at least one of the following mechanisms for specifying QPD-8:

  1. Transmit an empty value and receive all identifiers in all domains known by the Patient Demographics Supplier (one or more domains), or
  2. Transmit a single value and receive zero or more identifiers in a single domain, or
  3. Transmit multiple values and receive multiple identifiers in those multiple domains.
3.21.4.1.2.5 RCP Segment

The Patient Demographics Consumer shall send attributes within the RCP segment as described in Table 3.21-5. Fields not listed are optional and may be ignored.

Table 3.21-5: IHE Profile - RCP segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 1 ID R 0091 00027 Query Priority
2 10 CQ O 0126 00031 Quantity Limited Request

Adapted from the HL7 standard, version 2.5

3.21.4.1.2.5.1 Populating RCP-1-Query Priority

Field RCP-1-Query Priority shall always contain I , signifying that the response to the query is to be returned in Immediate mode.

3.21.4.1.2.5.2 Populating RCP-2-Quantity Limited Request

The Patient Demographics Consumer may request that responses to the query be sent, using the HL7 Continuation Protocol, in increments of a specified number of patient records. (In the context of the HL7 query, a patient record is defined as the PID segment and any segments accompanying it for each patient.) It is desirable to request an incremental response if the query could result in hundreds or thousands of matches or “hits.”

The Patient Demographics Supplier shall support the HL7 Continuation Protocol.

Field RCP-2 is of data type CQ, which contains two components. The first component contains the number of increments, always expressed as an integer greater than 0, while the second component contains the kind of increment, always RD to signify that incremental replies are specified in terms of records.

For example, 50^RD requests 50 records at a time.

See the “Incremental Response Processing” (Section 3.21.4.1.3.3) and the “Expected Actions” section of the Patient Demographics Query Response message (Section 3.21.4.2.3) for more information on the implementation of the continuation protocol.

3.21.4.1.2.6 DSC Segment

The Patient Demographics Consumer may request additional increments of data by specifying this segment on the query request. This segment should be omitted on the initial query request. Its purpose is to request additional increments of the data from the Patient Demographic Supplier.

Table 3.21-9: IHE Profile - DSC segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 180 ST O 00014 Continuation Pointer
2 1 ID O 0398 01354 Continuation Style

3.21.4.1.2.6.1                         Populating DSC-1 Continuation Pointer

To request additional increments of data, DSC-1 (Continuation Pointer) shall echo the value from RSP^K22 DSC-1.

3.21.4.1.2.6.2                         Populating DSC-2 Continuation Style

DSC-2 (Continuation Style) shall always contain I, signifying that this is part of an interactive continuation message.

3.21.4.1.3 Expected Actions
3.21.4.1.3.1 Immediate Acknowledgement

The Patient Demographics Supplier shall immediately return an RSP^K22 response message as specified below in Section 3.21.4.2, “Patient Demographics Response.”  The RSP^K22 response message incorporates original mode application acknowledgment as specified in the “Acknowledgment Modes” section (ITI TF-2: C.2.3). The Supplier shall use MSH-3 - Sending Application of the RSP^K22 to return the value it received from the Patient Demographics Consumer in Field MSH-5-Receiving Application of the QBP^Q22 message.

3.21.4.1.3.2 Query Parameter Processing

The Patient Demographics Supplier shall be capable of accepting, searching on, and responding with attributes in the QPD segment as specified in Table 3.21-2.

The Patient Demographics Supplier must be capable of receiving all possible representations of an Assigning Authority (patient identifier domain) in QPD.8.4 (What Domain Returned): 1) namespace, 2) universal id (OID) and 3) both namespace and universal id (OID).

Handling of phonetic issues, alternate spellings, upper and lower case, wildcards, accented characters, etc., if deemed appropriate, is to be supported by the Patient Demographics Supplier rather than by the Patient Demographics Consumer. The Supplier shall return at least all exact matches to the query parameters sent by the Consumer; IHE does not further specify matching requirements.

3.21.4.1.3.3 Incremental Response Processing

The Patient Demographics Supplier shall be capable of accepting and processing attributes in the RCP segment as listed in Table 3.21-5. In particular, the Patient Demographics Supplier shall respond in immediate mode (as specified by a RCP-1-Query Priority value of I ).

Also, the Patient Demographics Supplier shall be able to interpret RCP-2-Quantity Limited Request to return successive responses of partial lists of records according to the HL7 Continuation Protocol, as described in Section 3.21.4.2 below and in the HL7 Standard.

3.21.4.2 Patient Demographics Response

3.21.4.2.1 Trigger Events

The Patient Demographics Supplier’s response to the Find Candidates message shall be the following message:

K22 – Find Candidates response

3.21.4.2.2 Message Semantics

The Patient Demographics Response is conducted by the RSP^K22 message. The Patient Demographics Supplier shall generate this message in direct response to the QBP^Q22 message previously received. This message satisfies the Application Level, Original Mode Acknowledgement for the HL7 QBP^Q22 message.

The segments of the message listed without enclosing square brackets in the table below are required. Detailed descriptions of all segments listed in the table below are provided in the following subsections. Other segments of the message are optional.

Table 3.21-6: RSP Segment Pattern Response

RSP Segment Pattern Response Chapter in HL7 2.5
MSH Message Header 2
MSA Message Acknowledgement 2
[ {ERR} ] Error 2
QAK Query Acknowledgement 5
QPD Query Parameter Definition 5
[ { PID Patient Identification 3
  [ PD1 ]
  [ QRI ] } ] Query Response Instance 5
[ DSC ] Continuation Pointer 2
3.21.4.2.2.1 MSH Segment

The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2: C.2.2).

Field MSH-3-Sending Application specifies the patient information source that processed the query. The Patient Demographics Supplier shall use Field MSH-3-Sending Application of the RSP^K22 message to return the value it received from the Patient Demographics Consumer in Field MSH-5-Receiving Application of the QBP^Q22 message.

Field MSH-9-Message Type shall have all three components populated with a value. The first component shall have a value of RSP ; the second component shall have a value of K22 . The third component shall have a value of RSP_K21 .

3.21.4.2.2.2 MSA Segment

The Patient Demographics Supplier is not required to send any attributes within the MSA segment beyond what is specified in the HL7 standard. See the “Acknowledgment Modes” section (ITI TF-2: C.2.3) for the list of all required and optional fields within the MSA segment.

3.21.4.2.2.3 QAK Segment

The Patient Demographics Supplier shall send attributes within the QAK segment as defined in Table 3.21-7. For the details on filling in QAK-2 (Query Response Status) refer to the “Patient Demographics Supplier Actor Query Response Behavior” in Section 3.21.4.2.2.8.

QAK-1 (Query Tag) shall echo the same value of QPD-2 (Query Tag) of the QBP^Q22 message, to allow the Patient Demographics Query Consumer to match the response to the corresponding query request.

Table 3.21-7: IHE Profile - QAK segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 32 ST R 00696 Query Tag
2 2 ID R+ 0208 00708 Query Response Status

Adapted from the HL7 standard, version 2.5

3.21.4.2.2.4 QPD Segment

The Patient Demographics Supplier shall echo the QPD Segment value that was sent in the QBP^Q22 message.

3.21.4.2.2.5 PID Segment

The Patient Demographics Supplier shall return one PID segment group (i.e., one PID segment plus any segments associated with it in the message syntax shown in Table 3.21-6) for each matching patient record found. The Supplier shall return the attributes within the PID segment as specified in Table 3.21-8. In addition, the Patient Demographics Supplier shall return all other attributes within the PID segment for which it is able to supply values.

Table 3.21-8: IHE Profile - PID segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
3 250 CX R 00106 Patient Identifier List
5 250 XPN R 00108 Patient Name
7 26 TS R2 00110 Date/Time of Birth
8 1 IS R2 0001 00111 Administrative Sex
11 250 XAD R2 00114 Patient Address
18 250 CX R2 00121 Patient Account Number

Adapted from the HL7 standard, version 2.5

The Patient Demographics Supplier may or may not be able to supply additional identifiers from the domains specified in QPD-8. Inability to supply an identifier in a particular domain is not an error, provided that the domain is recognized.

The PID segment and its associated PD1 and QRI segments are returned only when the Patient Demographics Supplier is able to associate the search information in QPD-3 with one or more patient records in the patient information source associated with MSH-5-Receiving Application . See the “Patient Demographics Supplier Actor Query Response Behavior” Section 3.21.4.2.2.8 for a detailed description of how the Patient Demographics Supplier responds to the query request under various circumstances.

3.21.4.2.2.6 QRI Segment

For each patient for which the Patient Demographics Supplier returns a PID Segment, it may optionally return the QRI (Query Response Instance) segment, but is not required to do so. Refer to the HL7 Standard, Version 2.5, Chapter 5, Section 5.5.5, for more information.

3.21.4.2.2.7 DSC Segment

If the number of records is specified in RCP-2-Quantity Limited Request , the Patient Demographics Supplier shall return an incremental response of that number of records when the number of matching records it finds exceeds the number of records specified in RCP-2.

As long as the Patient Demographics Supplier has records to return in addition to those returned in the incremental response, the Supplier shall return a DSC Segment. The single field of the DSC Segment shall contain a unique alphanumeric value (the Continuation Pointer) that the Patient Demographics Consumer may return in the DSC of the QBP^Q22 message to request the next increment of responses. The Supplier shall return increments as many times as the Consumer requests them (and there are increments to return), and shall stop when the Consumer sends a cancel query (QCN^J01) message (or when there are no more increments to return).

3.21.4.2.2.8 Patient Demographics Supplier Actor Query Response Behavior

The Patient Demographics Supplier shall perform the matching of patient data based on the query parameter values it receives. The information provided by the Patient Demographics Supplier to Patient Demographics Consumer Actors is a list of possible matching patients from the patient information source associated with the value that the Consumer sent in MSH-5-Receiving Application of the query message.

If domains are specified in QPD-8-What Domains Returned and are recognized by the Patient Demographics Supplier, the response will also, for each patient, contain any Patient ID values found in the specified domains.

The mechanics of the matching algorithms used are internal to the Patient Demographics Supplier and are outside of the scope of this framework.

The Patient Demographics Supplier shall respond to the query request as described by the following 3 cases:

Case 1 : The Patient Demographics Supplier finds (in the patient information source associated with MSH-5-Receiving Application ) at least one patient record matching the criteria sent in QPD-3-Demographics Fields . No patient identifier domains are requested in QPD-8-What Domains Returned .

AA (application accept) is returned in MSA-1.

OK (data found, no errors) is returned in QAK-2.

One PID segment group (i.e., one PID segment plus any segments associated with it in the message syntax shown in Table 3.21-6) is returned from the patient information source for each patient record found. If the Patient Demographics Supplier returns data for multiple patients, it shall return these data in successive occurrences of the PID segment group.

Within each PID segment, field PID-3-Patient Identifier List contains one or more identifiers from the set of Patient ID Domains known by the Patient Demographics Supplier.

If an incremental number of records are specified in RCP-2 - Quantity Limited Request , and the number of records to be sent exceeds that incremental number, the Supplier returns only the incremental number of records, followed by a DSC segment containing a uniquely valued Continuation Pointer.

The consumer will specify the value of the continuation pointer in the DSC segment on the subsequent query request to request the next increment of responses.

Case 2 : The Patient Demographics Supplier finds (in the patient information source associated with MSH-5-Receiving Application ) at least one patient record matching the criteria sent in QPD-3-Demographics Fields . One or more patient identifier domains are requested in QPD-8-What Domains Returned ; the Supplier recognizes all the requested domains.

AA (application accept) is returned in MSA-1.

OK (data found, no errors) is returned in QAK-2.

One PID segment group (i.e., one PID segment plus any segments associated with it in the message syntax shown in Table 3.21-6) is returned for each matching patient record found. If the Patient Demographics Supplier returns data for multiple patients, it shall return these data in successive occurrences of the PID segment group.

Within each PID segment, field PID-3-Patient Identifier List contains, in successive occurrences delimited by the repetition separator, the identifiers from all the Patient ID Domains requested in QPD-8. In each occurrence of PID-3, component 4 contains the assigning authority value for one Patient ID Domain, and component 1 contains the Patient ID value in that domain. If an identifier does not exist for a domain that was specified on QPD-8, that identifier is not returned in the list. If all entries in the list of patient identifiers are eliminated, which would leave PID-3 empty, then the corresponding PID segment group shall not be present in the response at all.

If an incremental number of records is specified in RCP-2 - Quantity Limited Request , and the number of records to be sent exceeds that incremental number, the Supplier returns only the incremental number of records, followed by a DSC segment containing a uniquely valued Continuation Pointer.

The consumer will specify the value of the continuation pointer in the DSC segment on the subsequent query request to request the next increment of responses.

Case 3 : The Patient Demographics Supplier does not recognize one or more of the domains in QPD-8-What Domains Returned .

AE (application error) is returned in MSA-1 and in QAK-2.

For each domain that was not recognized, an ERR segment is returned in which the components of ERR-2-Error Location are valued as follows.

COMP # COMPONENT NAME VALUE
1 Segment ID QPD
2 Sequence 1
3 Field Position 8
4 Field Repetition (see below)
5 Component Number (empty)
6 Subcomponent Number (empty)

ERR-2.4-Field Repetition identifies the ordinal occurrence of QPD-8 that contained the unrecognized domain. As specified by HL7, ERR-2.5-Component Number and ERR-2.6-Subcomponent Number are not valued because we are referring to the entire field QPD-8.

ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier). Together with the values in ERR-2, this signifies that the Patient Demographics Supplier did not recognize the domain for QPD-8-What Domains Returned .

3.21.4.2.3 Expected Actions

The Patient Demographics Consumer will use the demographic information provided by the Patient Demographics Supplier to perform the functions for which it requested the information, e.g., providing a pick list to the user.

If the Supplier has sent a DSC segment containing a continuation pointer value, additional increments of data are available upon request by the Consumer. After receiving each increment of data that includes a DSC segment containing a continuation pointer value, the Consumer should take one of the following actions.

  • If the Consumer wishes to receive another increment of the data, the Consumer reissues the query message using a new unique value in MSH-10-message control ID and adding the DSC segment after the RCP segment. DSC-1 shall echo the continuation pointer returned in RSP^K22 DSC-1 segment.
  • If the Consumer does not wish to receive another increment of the data, the Consumer issues a cancel query (QCN^J01) message. The consumer shall echo the query tag from QAK-1 in QID-1 and the query message name from QPD-1 in QID-2.
  • If the Consumer does not reissue the query or send a cancel query message, the query will eventually terminate.

If the Supplier has not sent a DSC segment containing a continuation pointer value, no more increments of data are available and no further action by the Consumer is required.

3.21.4.3 Canceling a query

The Patient Demographic Consumer can send a cancel trigger to notify the Patient Demographic Supplier that no more incremental responses will be requested, and the interactive query can be terminated. This cancellation trigger is optional. How long the Patient Demographic Supplier retains query results (for incremental response) is an implementation decision and therefore beyond the scope of IHE.

3.21.4.3.1 Trigger Events

The Patient Demographic Consumer which received a RSP^K22 response message indicating there are more incremental responses data available, can terminate the interactive query with the following HL7 trigger event:

J01 – Cancel query status

3.21.4.3.2 Message Semantics

Canceling a query is conducted by the QCN^J01 message. The Patient Demographic Consumer can generate this message to notify the Patient Demographic Supplier that no more data is desired. The segments of the message listed below are required, and their details descriptions are provided in the following subsections.

Table 3.21-10: QCN Cancel query

QCN Cancel query Chapter in HL7 2.5
MSH Message Header 2
QID Query identification Segment 5

The receiver shall acknowledge this cancel by the HL7 ACK message. See ITI TF-2: C.2.3, “Acknowledgement Modes”, for definition and discussion of the ACK message.

3.21.4.3.2.1 MSH Segment

The MSH segment shall be constructed as defined in the “Message Control” section (ITI TF-2: C.2.2).

MSH-9 (Message Type) shall have three components. The first component shall have the value of QCN; the second component shall have a value of J01. The third component shall have the value of QCN_J01.

3.21.4.3.2.2 QID Segment

The QID segment contains the information necessary to uniquely identify the query being cancelled.

Table 3.21-11: IHE Profile - QID segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 32 ST R 00696 Query Tag
2 250 CE R 0471 01375 Message Query Name
3.21.4.3.2.2.1 Populating QID-1 Query Tag

QID-1 (Query Tag) uniquely identifies the query to be canceled. This field shall contain the same value specified in QPD-2.

3.21.4.3.2.2.2 Message Query Name

QID-2 (Message Query Name) identifies the name of the query. It is an identifier of the conformance statement for this query. This field shall contain the same value specified in QPD-1.

3.21.5 Security Considerations

3.21.5.1 Audit Record Considerations

The Patient Demographics Query Transaction is a Query Information event as defined in Table 3.20.4.1.1.1-1. The Actors involved shall record audit events according to the following:

3.21.5.1.1 Patient Demographics Consumer audit message:
Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110112, DCM, “Query”)
EventActionCode M “E” (Execute)
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-21”, “IHE Transactions”, “Patient Demographics Query”)
Source (Patient Demographics Consumer) (1)
Human Requestor (0..n)
Destination (Patient Demographics Supplier) (1)
Audit Source (Patient Demographics Consumer) (1)
Patient (0..n)
Query Parameters (1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Demographics Consumer facility and sending application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID M The process ID as used within the local operating system in the local system logs.
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode M EV(110153, DCM, "Source Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

Human Requestor (if known)

AuditMessage/
ActiveParticipant

UserID M Identity of the human that initiated the transaction.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode U Access Control role(s) the user holds that allows this transaction.
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Destination

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Demographics Source facility and receiving application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID U not specialized
UserName U not specialized

UserIsRequesto r

U not specialized
RoleIDCode M EV(110152, DCM, "Destination Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

Audit Source

AuditMessage/
AuditSourceIdentification

AuditSourceID U not specialized.
AuditEnterpriseSiteID U not specialized
AuditSourceTypeCode U not specialized

Patient

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “1” (Person)
ParticipantObjectTypeCodeRole M “1” (Patient)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M not specialized
ParticipantObjectSensitivity U not specialized
ParticipantObjectID The patient ID in HL7 CX format (see ITI TF-2: Appendix E ) from the @PID.3. M The patient ID in HL7 CX format.
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized

Query Parameters

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “2” (system object)
ParticipantObjectTypeCodeRole M “24” (query)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV(“ITI-21”, “IHE Transactions”, “Patient Demographics Query”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID U not specialized
ParticipantObjectName U not specialized
ParticipantObjectQuery M The complete query message (including MSH and QPD segments), base64 encoded.
ParticipantObjectDetail M Type=MSH-10 (the literal string), Value=the value of MSH-10 (from the message content, base64 encoded)
3.21.5.1.2 Patient Demographics Source audit message:
Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110112, DCM, “Query”)
EventActionCode M “E” (Execute)
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-21”, “IHE Transactions”, “Patient Demographics Query”)
Source (Patient Demographics Consumer) (1)
Destination (Patient Demographics Supplier) (1)
Audit Source (Patient Demographics Supplier) (1)
Patient (0..n)
Query Parameters (1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Demographics Consumer facility and sending application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode M EV(110153, DCM, "Source Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

Destination

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Demographics Supplier facility and receiving application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID M The process ID as used within the local operating system in the local system logs.
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode M EV(110152, DCM, "Destination Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

Audit Source

AuditMessage/
AuditSourceIdentification

AuditSourceID U not specialized
AuditEnterpriseSiteID U not specialized
AuditSourceTypeCode U not specialized

Patient

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “1” (Person)
ParticipantObjectTypeCodeRole M “1” (Patient)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M not specialized
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID in HL7 CX format (see ITI TF-2: Appendix E ) from the @PID.3.
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized

Query Parameters

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “2” (system object)
ParticipantObjectTypeCodeRole M “24” (query)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV(“ITI-21”, “IHE Transactions”, “Patient Demographics Query”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID U not specialized
ParticipantObjectName U not specialized
ParticipantObjectQuery M The complete query message (including MSH and QPD segments), base64 encoded.
ParticipantObjectDetail M Type=MSH-10 (the literal string), Value=the value of MSH-10 (from the message content, base64 encoded)