Environment Setup For ReactJS

We the the following things to setup the reactJS environment in the system

I’m using Windows version 8.1. 64bit computer system to perform this. Follow the below procedures and have happy coding.

Setup NodeJS & NPM:

Go to https://nodejs.org/en/ website and download the LTS version.



Install Visual Code:

Visual code seems to be “the” best editor for JS code and it manages the packages and routes fairly than the rest of the others.

Download from this site https://code.visualstudio.com/Download And I’m using the configuration mentioned  in the screenshot



Create React-App:

Open the command prompt for NodeJS.

provide the following commands

node –version

Should give you the version number

npm –version

should give a version number

Now run command to install react-app:

npm install -g create-react-app

you see the following after the installation is done


create-react-app –version 

Should display 3.0.0 version (any other shouldnt be expected here)

Run React Project:
Navigate to the project folder
cd <projectname>

npm start

Happy coding!!!!!!!!!!!


Continuous Integration & Deployment with Mirth Using Jenkins

This blog post is to provide a view on developing a continuous integration  and deployment using Mirth tool.

You can follow the below  provided steps to  do the same.


  • Often the codes have to be moved from one environment to another. From Staging to Testing and to Production  environment.
  • Manually moving the channels can be cumbersome and prone to human error. It is always advisable to automate this entire integration and deployment feature.

Steps to perform the Continuous Integration (CI):

  1. The source of truth here is repository be it Git Hub/Lab/Bitbucket or SVN. We need to create a webhook from the git repositories.
  2. Install Jenkins in the local system. You can follow a number of procedures online.
  3. Once jenkins is installed, we need to create  job in the jekins to perform this.

Follow the below steps to create job in jenkins:

  1. select New Item and click on freestyle project and click ok.
  2. In the General tab select Git Hub project and provide the git URL of your repository.
  3. In the source code management select Git
  4. In the Build Trigger area select “GitHub hook trigger for GITScm polling”.
  5. Click Save now and the changes will be saved.

If the above steps are completed then if any new code is pushed to your repository then it will be pulled by jenkins and the pulled code will appear on your folder location.

Continuous Integration Issues:

  • If you are using a public Git Hub repository then there will be a challenge involved in Git recognizing your local IP.
  • To overcome this issue, I made my local jenkins public by using Ngrok tool. you can download the tool from here
  • Once you download the tool, open the application and type ngrok.exe http “jenkinsportnumber” in the shell. This will make your  IP+jenkins port go public.
  • After the command is entered you can see that it gives a http url in the console. You can use that URL in the github webhook instead of mentioning localhost in it.


Push any new code in the repository and check the jenkins Job and you can see the data is pulled and completed.

Happy Integrations!!!!!!!

Why PDF is complicated in Mirth

Visit www.hl7engine.com to know more

This blog is about why PDF is complicated in Mirth? and How we can Split PDF in Mirth?.

Splitting of PDF, PDF parsing is complicated in Mirth because of the libraries used to perform few actions in it.

Basically, in JAVA if you want to split a PDF or parse a PDF content or manipulate data of a PDF content you would use couple of famous Libraries such as

  1. PDF BOX from Apache
  2. iText library (Licensed from 7.1 Version)

If you are going to use the unlicensed stable version on iText Library then the best version is 5.5.1

Problem of using PDF library in Mirth:

By Default, Mirth already uses these two libraries by default for its other functionality.

For Example: Mirth uses PDF BOX v.1.8.4 for the pdf viewer extension. If you are using a new version of PDF BOX library and provide it in anywhere in custom library or other locations it wont work.

Because Mirth do not identify which version of the library it has to select. You can see these two libraries in the following location shown in the screenshot below:

How to use PDF Box Library:

The Best library you can use to perform multiple functionality of PDF is using Apache PDF BOX library.

First, Mirth wants to read the font of the PDF that is suppose to manipulate. To, do that we need to add another library called fontbox-1.8.4 inside C:\Program Files\Mirth Connect\extensions\doc\lib location.

Then add this library path  in destination.xml in C:\Program Files\Mirth Connect\extensions\doc as <library type=”SERVER” path=”lib/fontbox-1.8.4.jar” />

Another approach:

If you really do not want to use the PDF Viewer functionality in mirth.

You can disable that extension and provide later version (v2.5) of PDF BOX library in the same way mentioned above.

Note: Using the PDF BOX library outside without following the above approach will not work. It will always throw error.

Is Splitting PDF possible inside Mirth?

Yes, certainly possible.

There is a Java program already written using Apache PDF Box library function https://gist.github.com/actsasflinn/4516ae1c322447bdc2634fab9240d70c 

I used the same function and converted to Javascript. Here is a sample of that code which is converted to EX4JS

Code converted from Java to Javascript – Splitting PDF

var AnyValueOfYyourChoice = ”;


var pdPage = org.apache.pdfbox.pdmodel.PDPage();
var inputDocument = org.apache.pdfbox.pdmodel.PDDocument.loadNonSeq(new java.io.File(globalMap.get(‘pdfReaderFilePath’)+$(‘originalFilename’)),null);
var stripper = new org.apache.pdfbox.util.PDFTextStripper();
var outputDocument = new org.apache.pdfbox.pdmodel.PDDocument();
var uuid = UUIDGenerator.getUUID();
var page;

for (page = 1; page <= inputDocument.getNumberOfPages(); ++page) {

var text = stripper.getText(inputDocument);
var p = new java.util.regex.Pattern.compile(DataNeedToBeCheckedFor);
var m = p.matcher(text);
var pdPage = inputDocument.getDocumentCatalog().getAllPages().get(page – 1);
var output_file = new java.io.File(globalMap.get(‘newPdfReaderPath’) +$(‘fileNameDocType’)+’_’+AnyValueOfYyourChoice+”.pdf”);

What is Meaningful Use? (MU)

Read more about this on http://hl7engine.com/meaningful-use/

Let us try to understand Meaningful Use (MU) as easy as possible. If any in-depth standards information is needed, regarding Meaningful Use, I suggest this blog.

Imagine there exist a physician named Dr.John Doe.

Dr.John Doe is practicing medicine in some part of USA. Dr.John Doe has a clinic (only outpatient involved) where the information about recurring and critical patients were stored in large paper files.

Imagine that Dr. John Doe is consulting in his clinic for 10 years and data of his patients piling up. Day-by-day the  time required to search the recurring patient is increasing.  Last month, there was a bad water-leak on top floor of his clinic damaging at least 5 years of patient information. Oops that’s a serious problem now which puts his job in jeopardy.

Dr.John Doe & Meaningful Use

Dr.John Doe now takes a wise decision. By converting all his paper works to digitized or electronically transformed health record in a computer system. But, what’s stopping him is the cost involved in getting these things done.

Because to get this transition done Dr.John Doe has to purchase an EMR first. Implement it in his clinic and setup infrastructure for it. Train his receptionist or nurses to use it. And all these comes with a cost. But, Dr.John Doe was happy when he came to know that government provides incentives for this adoption. But Dr.John can’t just buy any EHR and leave it, instead he has to show a meaningful use with this EHR.

So, to sum up all Meaningful Use is the adoption of Certified EHR technology.

Which means Dr.John Doe cannot buy any EHR, but an EHR that is certified by appropriate authority.  The authority that certifies should check for basic eligibility criteria of the EHR. This is in fact forms the 1st stage out of the three stages of meaningful use.


Now Dr.John Doe is still not clear and expects a clear cut answer for the following questions as shown in the picture

Answer for First Question:

Answers for the first question is somewhat clear to John Doe but to provide a clear cut explanation, the physician has to do two things to qualify for the money.

  1. Get a government certified EHR
  2. Demonstrate a meaningful use with the EHR. This means to show proof to the government authority that EHR is properly implemented according to their expected criteria.

The list of criteria is provided in a list of 25 aspects provided by the depart of health & human services and it is broken into two major parts.

  1. Core Set
  2. Menu Set

Core Set: This is the list of basic requirement list of 15 aspects that all the EHR must follow. Whenever the EHR is subjected for the certification aspect, the certification bodies will test for all the core set objectives to be available in the EHR.

Menu Set: The Menu Set is the list of 10 requirements out of which the EHR’s have the liberty to choose any 5 aspect. In other not all the 10 aspects are required to pass the certification.

So basically there are a minimum of 20 aspects that are required to eligible for the incentive criteria. If Dr. John Doe is going to purchase a EHR he must make sure it is certified with all the minimum 20 aspects. Obviously now Dr.John Doe has the answer for his first question.

Answer for the Second question:

To answer the second question, it heavily depends on which incentive program the physician depends on. There are two incentive programs

  1. Medicare
  2. Medicaid.

With Medicare the physicians can get up to 75% of the incentives up to $44,000 over four years and with medicaid, on the other hand if the physician handles or sees more than 30% of medicaid patients then he can get up to $64,000 over six years.

Which means sooner the healthcare providers adopt the system the more the money they will receive as incentives. Now to proceed further for this answer, the medicare and medicaid are basically insurance policies adopted by the US government.

Medicare applies to the patient who are more than 65 years of age irrespective of the gender while medicaid applies to  the underprivileged people. These incentive scheme are brought to implementation by HITECH abbreviated as Health Information Technology for Economic and Clinical Health act.

HITECH is one of the act passed along with the stimulus package (a.k.a) ARRA act abbreviated as American Recovery and Reinvestment Act signed by President Obama in 2009 as a part of meaningful use development process.


This blog is migrated to a website based solution.

This will be a complete website where all this blog posts will be available. Also there will be new changes in design. Some  interesting health care related products are also in place to bring inter-operability to new dimension.

Visit www.hl7engine.com for more

Unzip .zip files in mirth

Create a source as File Reader. put the zip file directory to read and make sure you enable read as binary radio button. as shown below

unzip files

Now, the logic is that the .zip file will be read via mirth engine and the data inside the zip file will be consumed as base 64 based content and written in to the output folder.

Provide the below code in the transformer editor.

// path at which the ZIP files has to be unzipped
var destinationPath = “C:\\Projects\\NON-EAI-PROJECTS\\tmp”;
var buffer_value = 1024;

// Convert incoming data to a base64 encoded data
var strBase64Data = connectorMessage.getRawData();
var decodedBytes = FileUtil.decode(strBase64Data);

// process all zipped files
var is = new java.io.ByteArrayInputStream(decodedBytes);
var zis = new java.util.zip.ZipInputStream(is);

var entry;
while((entry = zis.getNextEntry()) != null) {

// save file
var count;
var buffer = java.lang.reflect.Array.newInstance(java.lang.Byte .TYPE, buffer_value);

var fileOut = new java.io.File(destinationPath + “\\” + entry.getName());
var fos = new java.io.FileOutputStream(fileOut);

// read byte content from zipped file
while ((count = zis.read(buffer, 0, buffer_value)) != -1) {
fos.write(buffer, 0, count);


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?



IHE Profile – ITI 18 (Registry Stored Query)

ITI – 18 is used by Document Registry and Document Consumer actors. Both of these actors may use Synchronous or Asynchronous web service exchange.

Definition : IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21 (Pg: 91)

When two actors referred as Requester and Provider want to exchange information in a request-response pattern, then this communication can happen in two ways as Synchronous and Asynchronous web service exchange pattern.

Synchronous web service exchange:

In Synchronous web service exchange the requester (system which send the request) will send a request and wait for the provider (system which will respond for the request) to respond in the same connection (socket connection) which the requester initially established.

In Synchronous web service exchange a provider will always be available to respond whenever the requester send their message. Here response sender is a HIE (i.e) provider is a HIE and Requester is a EHR Middleware

Asynchronous web service exchange:

In Asynchronous web service exchange the requester will send a request knowing that provider will eventually send the response. The provider may not be available by the time the request is sent.

When the provider receives the message it will send the acknowledgement back to the requester In simple words, Asynchronous is only concerned about sending a request. EMR  will send only the request and whenever the HIE is available, it will receive it.


Definition : IHE_ITI_TF_Vol2x (Pg : 135) 

The Document Consumer will send a request query by passing parameters to it. The Document Registry services the query based on the defined definition it has. In this scenario the Document consumer will be a EHR and the Document Registry is a HIE.


Registry Stored Query is the request query from the EHR to the HIE. It contains two elements:

  1. A reference to a predefined query
  2. parameters to a query

Message Breakdown:

The ITI 18 message follows ebXML Registry Information Mode Version (RIM) 3.0 . This ITI 18 ebXML stored query takes three forms of parameters

a) returnType
b) QueryID (an UUID) and
c)Query Parameters

Find the sample HL7v3 request from Document Consumer to Document Registry.


  1. The message that starts with <query:AdhocQueryRequest> is a root element or the header tag, this provides all the necessary namespaces for the document standards, this is a static data.
  2. <query:ResponseOption> contains two attributes returnComposedObjects and returnType. the default value of returnComposedObjects will be set to “true”, which literally means the request is expecting a response back

returnType: The returnType can have two values 1. LeafClass 2. ObjectRef,
The LeafClass returns a list of XML elements of fully specified ebXML objects. This type of query result is self-contained, everything known about the object(s) is returned.
The ObjectRef returns a list of UUID which references to the registry object that matches the query. This type query is recommended when the returned object list could be large.
In real time an information has to be provided from the EHR to determine what kind of returnType is expected either LeafClass or ObjectRef
3.  <rim:AdhocQuery> contains only one attribute called id this is referred as QueryID. This is most important and required field. These are IDs (a list predefined) that are used in the AdhocQueryRequest to reference certain actions to be performed. For Example: EHR will request the HIE to Find Documents or Get Related Documents. Based on this request ID, the corresponding query parameters will change.

Query IDs are in UUID format (RFC4122). An error will be returned to the requester whenever unsupported query id is provided. The below provided are the list of actions and their corresponding Query ID


Definition: IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21 (Pg: 113)

You can notice that in the XML provided as sample the Query ID specified is <rim:AdhocQuery id=”urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d”> which refers to the QueryName Find Documents.

4.  In the sample XML you can also see <rim:slot> beginning sections, and the number of parameters were passed. All these parameters depends on the Query ID provided, For Example if the QueryID provided is for the action of Find Documents, then the query parameters will have the following data with it.


Definition: IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21 (Pg: 99)

For the QueryID with the name of Find Document the table provides parameters that needed to be passed. The <rim:Slot name=””> must be filled with the Parameter Name column of the table <rim:Value></rim:Value> must contain the corresponding value of the parameter. Note: Not all parameters are required for this, only highlighted ones which are those mentioned as Required (R) in Opt column is needed.

Now comes another question.. in the provided XML sample you can notice that a patient ID is provided in this format  <rim:Value>’st3498702^^^&amp;;ISO’</rim:Value> How will the EHR know what elements are these?

For this refer IHE_ITI_TF_Rev14.0_Vol2a_FT_2017-07-21.pdf document (pg number 95), these are nothing but the coding standards of ebXML specification. The general Syntax of this will be <value> (‘code1^^coding-scheme1’) </value> and it can have multiple values <Value>(‘code1^^coding-scheme1′,’code2^^coding-scheme2’)</Value>

For the Query ID with the name of Find Submission Sets the below are the expected parameters:


Create Mirth Environment in AWS (Amazon AMI)

Setup Java:

Check if the Java JDK is installed in the system. use the below command to confirm

java -version

if it returns java: command not found then you have to install java in the machine.

yum -y install java-1.8.0-openjdk

you will need a (sudo) in front to perform that action as a root user. sudo yum -y install java-1.8.0-openjdk. This will install the complete Java 1.8.0 package for you.

perform java -version again. this will give you the below resultjdk install success

Install Mirth connect:

Download Mirth connect by using the below command, the below link is for the version 3.6.0

sudo wget http://downloads.mirthcorp.com/connect/3.6.0.b2287/mirthconnect-3.6.0.b2287-unix.tar.gz

unzip the downloaded file by using the following command

sudo tar xvfz mirthconnect-3.6.0.b2287-unix.tar.gz

once you unzip you can see a new mirth connect folder available (with a space between Mirth and Connect). you will not use the tar.gz file anymore, you can delete it by using the below command

sudo rm -r mirthconnect-3.6.0.b2287-unix.tar.gz

It’s always better to move the spaced folder to space-less folder and keep it inside the opt directory. Perform the following command for it

sudo mv Mirth\ Connect/ /opt/mirthconnect

Mirth will need two ports one is 8080 and another is 8443, you need to enable these two ports in the security group of the AWS  console.


Navigate to security groups and select launch-wizard-1 group name. The click on Inbound tab and click Edit button. Add the ports as shown in the picture below


Now we need to start the Mirth Service to run on the remote system. Navigate to opt/mirthconnect/ and type the below command

./mcservice start

Getting AWS remote mirth in local:

Type the IP address and the webstart port of the mirth connect in your browser URL




Blog at WordPress.com.

Up ↑