IHE Profile – ITI 45 (PIX V3 Query)

Scenario:
The explanation of this IHE profile is done under the assumption that any EHR who would like to communicate to HIE will adhere to IHE standards. The following ITI – 45 specifications are explained in such a way what an EHR would need to send to HIE to get the communication going further.

What is ITI – 45:

ITI – 45 is a PIX Query established in HL7V3 format. An ITI – 45 message profile is used between Patient Identifier Cross Reference Consumer and Patient Identifier Cross Reference Manager actors

In our scenario, the Patient Identifier Cross-reference Consumer is a EHR and Patient Identifier Cross-reference Manager is HIE.

Actions Performed:

1. The EHR will send queries as request for HIE to fetch a list of corresponding (patient identifiers)*.
2. The HIE would accept the request from EHR and references the patient identifier (across domains)* and returns a list of patient identifiers back to EHR assuming the HIE finds the patient identifier match.

* patient identifier:
Suppose patient A is admitted to XYZ hospital  on /1/2016.
XYZ Hopsital assigned medical record Number 12345
Patient again admitted, but at a different hospital called LMN
LMN hospital assigned medical record number D8

This medical Record Number is called Patient Identifier

* across domains: 
Imagine a Patient AAA exists
Patient AAA is admitted to XYZ hospital on 2015
Patient AAA is admitted to LMN hospital on 2015
Patient AAA admitted to QQQ hospital on 2015
Patient AAA treated by DDD clinic on 2015
XYZ, hospital, LMN hospital, QQQ hospital, DD Clinic are all called Domains. Other name for each one of the is “Enterprise”
If PIX manager search for patient “Medical Record numbers” in multiple domains (in response to PIX query), then the language is “across domains” or “cross domains” search X = across or across

The first action performed by the first actor is called Patient Registry Query Placer (Application Role : PRPA_AR201303UV02) and the second action performed by the second actor is called Patient Registry Query Fulfiller (Application Role: PRPA_AR201304UV02)
(Application Role * will be explained in a separate blog post, for understanding: An application Role can be any device or software who send/Receive message)

Note: PRPA_AR201303UV02 is not a message ID
PRPA_AR201303UV02 is a software component ID
The software that performed PIX placing action and software that performs PIX fulfilling action are assigned Application Role Identifiers.

Note:  PRPA_IN201309UV02 is called message Identifier/ID ( Not application Role identifier/ID)
PRPA_IN201310UV02 is called message Identifier/ID ( Not application Role identifier/ID)
Do not confuse between message ID vs application Role ID terminology used by HIE

It is clear from above diagram that the EHR will send a request message and this message is called Patient Registry Get Identifiers Query also referred as PRPA_IN201309UV02 meaning it is a request from EHR to HIE.

The response from the HIE to the EHR (a.k.a response message) is called Patient Registry Get Identifiers Query Response also referred as PRPA_IN201310UV02 meaning it is a response from the HIE to EHR.

Sample HL7V3 PRPA_IN201309UV02 Request from EHR to HIE is provided below

The schema document of this message ITI-45 can be found in Pg number: 98 of this document. Here is the direct link for schema document.

The sample message provided here is taken from OpenEMPI confluence link. The examples provided by the IHE schema in document volume 2b does not contain ITI-45 message type but all other ITI PIX Query message were available, you can find the actual examples provided by IHE specification here examples in this link

Message Breakdown:
This message contains two parts
a) Transmission Wrapper (a.k.a) HL7V3 Transmission Wrappers
b) Control Act Wrapper

a) Transmission Wrapper:

The first half of the entire XML is called Transmission Wrapper, which includes sender and receiver information as shown below

1. <PRPA_IN201309UV02> is the message identification/ID tag, this denotes this message is Get Identifiers Query message. The ITI-45 profile contains only two messages PRPA_IN201309UV02 (request) and PRPA_IN201310UV02 (response). This tag will be different for different ITI messages, for Example: ITI-44 has types of message PRPA_IN201301UV02, PRPA_IN201303UV02 and PRPA_IN201304UV02
2. <id root=””> provides a GUID value, This is a GUID value of the sender EHR, when the response message comes, it will also contain the same GUID, representing that the data is sent to this specific EHR. This GUID will be sent by the EHR dynamically from their system.
3. <creationTime value=””/> Represents the time at which this request is triggered, this will be sent by EHR from their system generated time in the format of YYYYMMddHHmmss
4. <interactionId root=”” extension=””>The Interaction root ID will be provided by the EHR to the HIE, although the extension will be same as that of the header tag. (Question: Who will provide this OID to the EHR?)
5. <processingCode code=””> This can have only two values either P or T, meaning it can be either Production Environment or Testing Environment. This can be taken as static value depending on environments by the EHR.
6. <processingModeCode code=””> This value will be sent dynamically by EHR as it might have 4 possible values A (Archive),T (Current  processing),I (Initial Load), R (Restore from archive). (Question: How does an EMR know what has to be sent in here?)
7. <acceptAckCode code=””> Valid values are AL (Always), ER (Error/reject Valid values are AL (Always), ER (Error/reject  only), NE (Never) Ideally EHR will always expect the HIE to send a response back, it should be set to AL by default.

Receiver Information:

1. <receiver typeCode> This will be a static value and it will be set to RCV meaning its a Receiver.
2. <device classCode=”” determinerCode=””> The value of classCode will be set to DEV by default, but determinerCode can have two values either INSTANCE or KIND. Where, INSTANCE means particular id, person, device KIND is a literal meaning for KIND OF, kind of Id’s, people, devices, software’s etc.
3. <id root=””> This id root will be provided by the HIE to the EHR. HR will be communicating with HIE to get their HR will be communicating with HIE to get their  respective OID. This id tag SHALL not require extension.

Sender Information:

1. <sender typeCode=””> This will be a static value and it will be set to RCV meaning its a Receiver.
2. <device classCode=”” determinerCode=””>The value of classCode will be set to DEV by default, but determinerCode can have two values either INSTANCE or KIND. Where, INSTANCE means particular id, person, device KIND is a literal meaning for KIND OF, kind of Id’s, people, devices, software’s etc.
3. <id root=””> This should be one of the Baby OID that the EHR purchases and assigns for the device. Its a device OID from which the message will be sent to the HIE.

b) Control Act Wrapper:

The second half of the entire XML is called Control Act Wrapper, which includes Query parameters, which means the actual items needed for querying as shown below

1. <controlActProcess classCode=”” moodCode=””> This is a static value and represents the starting of the control act transmission wrapper. This is a static data.
2. <code code=”” codeSystem=””> The code PRPA_TE201309UV02 means that the queryByParameter message to request that HIE device/application to return all patient information. Also notice that a message with PRPA_IN201309UV02 will always have PRPA_TE201309UV02 by default. HIE will supply the coding system id to the EHR
3. <author> is a optional segment/section which means the author of message request
4. <queryByParameter> contains one root id and extension. EHR will provide this OID and the HIE will send a acknowledgement back with the same OID, Extension will also be provided by the EHR in the form of any unique combination so the each request sent by the EHR will have a unique id combining the OID and the extension value.
5.  What is Data source?

6. What is Patient Identifier?