IHE Profile – ITI 8 (Patient Identity Feed)

ITI-8 is the HL7v2 format of ITI-44. Both ITI-8 and ITI-44 performs same action (i.e) Sending Patient Identity Feed. Based on the requirement of HIE, the EHR’s are expected to send the corresponding data. Some HIE expects ITI-8 (HL7v2 format) format and some HIE expects ITI-44 (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 as well as Document Registry. Even though the working of  Patient Identifier Cross-Reference and Document Registry are not the same.


What exactly is Document Registry?

The Document Registry is an Actor that (actually a software/Database) maintains metadata about each registered document in a document entry or each patient records. Note that it maintains only meta-data (index of main data). The Document Registry responds to queries asked to it regarding documents meeting specific criteria.

What is Patient Identifier Cross Referencing (PIX) ?

The concept of transmitting the patient identifier information (patient id) from patient identifier source (EHR in our scenario) to the patient identifier cross reference manager is called Patient identifier cross referencing (so called PIX)

The Patient Identifier Cross Reference Manager is basically a software that receives data from any patient identity source and provides the data to document registry for performing query operations as shown in the picture below:


Actions performed in ITI – 8 :

The EHR will send the HL7 ADT messages to the HIE to do the following activities:

  1. ADT^A01 – Patient Admit Message
  2. ADT^A04 – Patient Registration Message
  3. ADT^A05 – Patient Pre-Admission Message
  4. ADT^A08 – Patient Update Message


But note that, in real-time an HIE might or might not adhere to this IHE profile standards.

Let’s logically discuss the above statement.

A04 : A “register patient” message (A04 event) signals that the patient has arrived or checked in as an outpatient, recurring outpatient, or emergency room patient. This message contains the information of patient as well as other information like next of kin, insurance or guarantor information as well.

A08 : Whenever any important information related to the patient is updated then this will be communicated as A08 message (for eg: visit information of patient, name, date of birth, or any information related to the patient).

Scenario :1
consider a scenario, Where a patient named zzzz is registered in a hospital and his details are sent to the HIE in the form of ADT A04 message.
Now, no demographics information of a patient zzzz is changed except his physical location upon which he was admitted. Like he is moved from Bed Number 305 to 405. In this case, it does not make sense to send this message as patient update because all the demographics fields are intact and same. And it is good to send an A02 message a Patient Transfer Message instead of Patient Update Message.

When A02 is sent, then it makes more sense because this message will contain change in assigned patient location in PV1-3 segment, while the old patient location appears in PV1-6-(prior patient location) and other demographic changes will be same.

According to HL7, if only the patient location change happens then EHR is expected to send an A02, but if the location change and demographic change both happened, then EHR should send an A08, But never both the messages i.e both A08 and A02 shouldn’t be sent.

Reference : http://www.hl7.eu/refactored/ch03.html

Similarly, If the patient is going to a temporary location (such as the O/R, XRAY, LIMBO, the HALLWAY) it is recommended that the A09 (patient departing tracking) and A10 (patient arriving tracking) events be used instead of A02.

But in the diagram provided above is IHE profiles suggested as per the document Vol2a there is no ADT A02 specified. Which makes this topic even more debatable.

Scenario 2:

Consider a scenario, where patient’s mother name is updated here patient’s mother is a Next of Kin, basically NK1 segment is changed. According to the above diagram, we have to send this as ADT^A31 message.

But, by the definition of ADT^A31 it is shown that it is “An update of any person information & the person need not be patient”. Which means it can be a patient as well. Now, to send the change of mother name, the EHR have the license to send either A31 or A08.

Reference : http://www.hl7.eu/refactored/ch03.html

An A08 (update patient information) event should be sent and/or negotiated as necessary to provide for implementation and application specific needs.

The right way to proceed this ITI-8 transaction is to get the details clarified from the HIE or the EHR person to determine what message to be sent based on the HIE acceptance.

A01 : The ADT A01 message will be used only for Inpatients. In other words this message is for ‘admitted patients only’. Not for clinic visits or outpatients.

A05 : The ADT A05 is a pre-register message, if the patient is scheduled for an operation, then the operation theater, setup and post-operation bed setup all information will be sent in this message.



HIE – Terminology definitions


The word “Enterprise” is used in IHE / HIE manuals to mean a separate hospital or separate medical clinic. If HIE is receiving patient data form 7 different medical clinics, 4 different lab facilities and 3 different hospitals.

In this scenario, we will refer that this HIE has 14 enterprises inside it. So, basically the term “Enterprise” is used to refer the entities (labs, hospitals or clinics) registered with a HIE, regardless of them being an enterprise hospital group or not.


MPI is simply abbreviated as Master Patient Index. It’s basically provided by a software/database used by hospitals/organization to maintain single source of medical record across multiple departments for a patient.

Imagine a patient named patient-x entering to the hospital where each department of the hospital is using different software of their ease. The patient visits an outpatient clinic inside the hospital where the physician provides a unique patient id (MM565465) for the patient-x. Then patient-x enters to the radiology area where a different software is used and the radiology people assigns a different id for the patient (1234), the same patient-x goes to the lab to take some more tests and lab uses another lab software and provides him with the patient id (4567).

Now the single patient-x is assigned with multiple patient Id’s based on different software used in different department of the same hospital. As shown in the picture below


The hospital with multiple departments are expected to have single software or the master Database where the patient-x’s different Id’s from different departments will be provided with one unique id, this ID is called Master Patient Index (MPI) and the software used for this is called PIX manager.

Community & Cross-Community:

we come across terminology “Community” in HIE/ IHE manuals. The word “Community” is an alias name for single HIE.

The communication across the HIE entities are represented in the below picture.hie_communication
when HIE B has to communicate with HIE F for patient data, it is referred as “Cross Community Access”. Here the cross-community gateway is basically a software that connects, transfers the data from one HIE to another HIE.


The abbreviation of this simple three letter word is “Cross Enterprise Document Sharing” and one can notice that this terminology is used across multiple places of any HIE document.

Imagine  if an HIE has 7 (Eg: 3 hospital, 3 clinics & 1 lab) enterprises bound with it. This HIE is storing the patient named X from all these 7 hospital or clinics or labs (i.e) 7 different enterprises, then it is referred as XDS.

If suppose as referred in the picture above, if the HIE A wants to send a patient information with HIE F, this cannot be called “Cross Enterprise Access”. This  is called as “Cross Community Gateway” as mentioned above. Since, each HIE has multiple enterprises and one HIE is considered as one community when one HIE communicates with another it is termed as cross community access. But within one HIE when communication takes place the term Enterprise comes to picture.

Data Source:

It is one of the common terminology used in the definition document of several IHE profile ITI messages. Consider the QPD segment of the QBP^Q23 message, this is bound to the ITI version 9

QPD | IHE PIX Query | QRY124518648946312 | 14583058^^^NIST2010&2.16.840.1.113883.3 . | ^^^&2.16.840.1.113883. |

Here QPD 3.4 refers the Assigning Authority and QPD 4 refers to the Data source. Imagine if 14583058 is a  Medical Record Number used by EHR named EHR-x by the clinic “Good Health Medical Clinic”.

The OID for “Good Health Medical Clinic” is 2.16.840.1.113883.3 . The physician from the Good Health Medical Clinic wants to search for the patient in St.Joseph hospital.

The OID provided for the St.Joseph Hospital is 2.16.840.1.113883., so basically the Data Source here specifies the St.Joseph Hospital that is the location of the hospital upon which the patient has to be searched for. This target search location is often termed as Data source.


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



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.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 .|^^^&2.16.840.1.113883.

  • 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 HIEQPD.1 segments
  • 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.3

    In 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 

    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:RCP segmentsAccording 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:

RCP first segmentThe RCP segment will always be set to the value I indicating that the response to the request should be sent immediately.


IHE Profile – ITI 45 (PIX V3 Query)

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?



Blog at WordPress.com.

Up ↑