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:
- 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 .
- 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.
- 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.
- 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.
- 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:
- Transmit an empty value and receive all identifiers in all domains known by the Patient Demographics Supplier (one or more domains), or
- Transmit a single value and receive zero or more identifiers in a single domain, or
- 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
Field RCP-1-Query Priority shall always contain I , signifying that the response to the query is to be returned in Immediate mode.
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 |
QID-1 (Query Tag) uniquely identifies the query to be canceled. This field shall contain the same value specified in QPD-2.
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/
|
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/
|
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/
|
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/
|
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/
|
AuditSourceID | U | not specialized. |
AuditEnterpriseSiteID | U | not specialized | |
AuditSourceTypeCode | U | not specialized |
Patient
(AuditMessage/
|
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/
|
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/
|
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/
|
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/
|
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/
|
AuditSourceID | U | not specialized |
AuditEnterpriseSiteID | U | not specialized | |
AuditSourceTypeCode | U | not specialized |
Patient
(AuditMessage/
|
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/
|
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) |