IHE Profile – ITI 9 (PIX Query)
ITI-9 is the HL7v2 format of ITI-45. Both ITI-9 and ITI-45 performs PIX Query. Based on the requirement of HIE, the EHR’s are expected to send the corresponding data. Some HIE expects ITI-9 (HL7v2 format) format and some HIE expects ITI-45 (HL7v3 format).
While communicating this message from an EHR entity to HIE, sometimes the HIE expects data to be sent in a VPN tunnel as IP/PORT socket connection. At times, the data communication happens through webservices interaction where the HIE will expect the HL7 data to be bind inside a soap envelope and then communicate to them.
This message is a transaction between EHR to HIE, EHR is described here as Patient Identifier Cross-Reference Consumer and HIE is described as Patient Identifier Cross-Reference Manager
Actions:
- The EHR will send patient ID’s (Medical Record Numbers)* of the patient to the HIE
- The HIE will search the patient (across domains)* and provide the list of corresponding details for the provided ID.
Message Type:
- The ITI-9 uses HL7V2.5 as a reference model
Message communication :
The Identifier QBP^Q23 is the Message ID/Identifier (MSH.9) of the Request sent from the EHR to the HIE. Similarly, RSP^K23 is the response sent from the HIE back to EHR (MSH.9).
The PIX Query ITI-9 shall contain the following segments with it, the same HL7v3 of <queryByParameter> is represented as QBP here in HL7v2.
MSH|^~\&|NIST_SENDER^^|NIST^^|NIST_RECEIVER^^|NIST^^|20101101160655||QBP^Q23^QBP_Q21|NIST-101101160655565|P|2.5
- MSH.3.1 – SENDER ID (Any Mnemonic from the sending Facility (clinic/hospital/healthcare organization) – Facility Identifier)
- MSH.4.1 – SENDER APPLICATION (Mnemonic used by the sending (EMR) of the facility)
- MSH.5.1 – RECEIVER APPLICATION (EMR/Interface Engine/ used at HIE end)
- MSH.6.1 – RECEIVING FACILITY (Facility ID of the HIE)
- MSH.7.1 – Date and Time at which the message is sent (System generated current date/time of format YYYYMMddHHmmss)
- MSH.9.1– Says the type of the message, QueryByParamter is referred here as QBP
- MSH.9.2 – Says the subtype (Event) action of this message. Here Q23 is a request for getting identifiers.
Q23 – Get Corresponding Identifiers - MSH.9.3 – It implies that the message with the event type Q23 and Q21 are similar in structure.
- MSH.10 – Control ID (Generated By EHR can be anything unique from the sending application)
- MSH.11 – This component is similar to the <processingCode> in HL7v3 message which implies the environment upon which this message is communicating with HIE. Either Testing (T) or Production environment (P) correspondingly
- MSH.12 – Version Number (2.5) hard-coded
/*Optional Entry*/ - MSH.8 – Implies a security field which is optional.
QPD|IHE PIX Query|QRY124518648946312|14583058^^^NIST2010&2.16.840.1.113883.3 .72.5.9.1&ISO|^^^&2.16.840.1.113883.3.72.5.9.2&ISO
- QPD.1 – Is of Length to a maximum of 250 characters and this defines the Message Query Name. This can be as literal as IHE PIX Query or anything that the EHR would like to send. (Required)
But By 2.5 standards QPD.1 can have multiple sub-components which can be used by the EHR as they need (on demand). Although all the below mentioned sub-components are the fields described by HL7v2.5 standards, but IHE standards does not expect all the values to be occupied while communicating to HIE - QPD.2 – Is of Length to a maximum of 32 characters and this defines the Query Tag, this is a unique query number tag, just like the control Id sent in the MSH segment. This is a alpha-numeric field. The purpose this field is to keep track of the queries been sent to the HIE and to uniquely identify the query messages. (Required)
By 2.5 standards the QPD.2 segment contains only one field. That is String value. - QPD.3.1 – This is the patient identifier (can be numeric/alpha-numeric) which will uniquely identify the patient within the given patient domain*.
Patient Domain : Is the hospital/clinic/healthcare organization upon which given particular patient has to be searched. - QPD3.4 – This specifies the Assigning authority of the patient. You may have a doubt why QPD3.2,3.3 where not specified. Basically QPD3.1, QPD3.2 & QPD3.3 all refers to the patient ID segment. The sender EHR will have to provide definitely the patient Identifier value in any of these fields.For Example: The EHR can send the Patient ID value in either 3.1,3.2 or 3.3. The Assigning authority mentioned in 3.4 will just have to be specific to patient id sent in any of these three fields.If the EHR believes that more than one patient specific details has to be sent, in that case they can send the basic patient Id in the 3.1 segment and send other information like SSN or patient account number in 3.2 and 3.3In the above case, when all the three segments are filled with value. The first component will be taken as a reference for determining the 3.4 value. Which means the Assigning Authority has to define authority of the assigned patient Id. On the Example it is provided with the NIST&OID&ISO this is also a way of representing the assigning authority but for clear example refer this site here
|112234^^^GOOD HEALTH HOSPITAL|The above provided segment is an example of QPD.3 segment. As per the specification you must have the QPD 3.1 and QPD3.4 is required entity which means your PID and assigning authority is required field
- QPD4 : This specifies the domain at which the patient has to be searched. Note: this is an optional segment. This means that if this value is not provided then the HIE software will search for this patient ID across domain* (use this link to know what is across domain)
The responding system shall return the Patient ID value for each requested domain if a value is known.
RCP Segment:
RCP|I |
This segment is abbreviated as Response Control Parameter. This segment has 7 meaningful segments according to the HL7v2.5 standards. All the available segments are shown below:According to HL7 standards RCP is a required segment for a QBP message. But, IHE does not require PIX query to be sent to HIE with all the values specified by the HL7 standards.
IHE standards requires the value to be sent on the first segment of RCP segment. This segment stands for Query Priority. This can have only two value I for immediate and D for Deferred as shown in the picture below:
The RCP segment will always be set to the value I indicating that the response to the request should be sent immediately.
Recent Comments