Mirth: Making sure that dev/test code doesn’t get into LIVE (Is this lazy, or just accommodating reality?)

In a perfect world database connections and other things that must be changed when you migrate code between environments are neatly stored in one place where they can be easily changed.

With Mirth you can do this using global maps,  however when you do that,  they are exposed to anyone who has appropriate access to Connect.

I get around this by declaring variables at the top of the filters or transformers where I make database calls.

One of the things with my position is that I wear many hats and am the organization’s ‘go to’ for a great many things.  This means that interruptions are frequent.

This means that I when I’m doing something like preparing an interface to move from TEST to PRODUCTION that I can miss things.

Some of you might scoff,  but that is the reality of my world,  and almost 50 years on this planet has taught me that reality is often very far from ideal,   so you plan for reality.

I’m working on a project where I reach out to a couple of databases to pull data that isn’t included in the HL7 message.

Some of the transformations are complex,  and things were complicated by very tight deadlines,  and a situation where the spec “needed clarification”.  (as in I built my end to spec but they wanted a change).

Those of you familiar with this reality thing will know that this often leads to kludged together solutions.

After spending several hours making sure that our iPeople Echo downloads were moving the correct data from our test environment and copying/altering stored procedures and SQL functions I finally got to combing through my Mirth interface to make the changes there.

To give you an idea of the complexity,  I have 13 transformers in my source connector.

I realized that when I moved this to Live that there were too many potential failure points and wanted to prevent them.

So I added this code to my source filter:


var channelName = ChannelUtil.getDeployedChannelName(channelId);

if (channelName.indexOf('LIVE') > -1) {

logger.error('******************** CHECK ' + channelName + ' FOR DEV/TEST SETTINGS! ****************');
 return false;
 
}

return true;

/* Changes for Live
-remove anonymizer
-change db settings in source PID, PV1, OBR and ZDR
-change db settings in destination MR PID transformer

*/

Hey look…a checklist of sorts!

My thinking is that if I forgot to make this very basic change that I’ll look and wonder why all my messages are being filtered!

But then I got to thinking of how many times I’ve been interrupted today and what would happen if I missed a single change…

So I wrote this:

function envcheck(sql,strTest,strLive) {

 var channelName = ChannelUtil.getDeployedChannelName(channelId);

 if (channelName.indexOf('LIVE') > -1) {

 logger.error(channelName + ' **** CHANGE SQL STATEMENT FOR LIVE ' + sql);

 sql = sql.replace(strTest,strLive);
 
 }

 return sql;
 
 
}



Mirth Integration: Iterate through specific HL7 segments

Many of us in the healthcare integration community use the Mirth Integration Engine for HL7 and other integration needs.

In the past I’ve been active on the Mirth Community Forums as Bostad,  both asking and answering questions.  I haven’t been that active lately as my duties don’t leave me much time.

I do sometime receive direct requests,  and it was one of those that prompted me to start posting some of my Mirth programming tips here.

If you’re curious about healthcare integration and/or HL7 messaging, you can read about it here.

When required to iterate through repeating segments of an HL7 message,  here’s my method:


var i = 0;   //iteration variable
for each (seg in msg..ROL) {   //iterates through each ROL segment of an incoming HL7 message

i++;

if (seg['ROL.3']['ROL.3.1'].toString() != 'FAMILY DOCTOR')  {

   channelMap.put('ROL ' + i,'Not Family Doc');

}
}

In the code above,  you’ll note that the variable seg holds the current iteration of the target segment.

You’ll also note that the code above doesn’t do anything useful…I don’t want to flood you with a bunch of lines of code that aren’t helpful.

To reference specific fields within the segment,  unlike when referencing msg or tmp objects,  you do not use the initial segment name as an index!


//referencing msg and tmp

var strM = msg['ROL']['ROL.3']['ROL.3.1'].toString();
var strT = tmp['ROL']['ROL.3]['ROL.3.1'].toString();

//referencing seg (from within implied loop)

var strS = seg['ROL.3]['ROL.3.1']..toString();

If anything is unclear,  or you have further questions, feel free to ask in comments.

JQUERY: Handle a click event on an HTML element within another clickable element

Confusing title?

Let me explain:

I’m working on a project that will allow my employer’s senior team a patient census board. (I work for a hospital if the “patient” thing didn’t give it away).

As this project spans 4 different hospitals,  I present the initial data in collapsed tables,  populated by JQuery from an XML document passed from a PHP script.

In order to expand a table,  I allow the user to click the appropriate row.

Yesterday I was asked to add some new functionality that would allow the user to call up a list of patients by clicking on a column within that row.

The information in this column is wrapped in a span for display purposes,  so I hooked onto that.

Of course,  when I click on it,  both the span click event, AND the row click event fire!

I prevent this,  by placing the span click event handler above the row click event handler in the js file AND ending the span click even with return false;

This is how the table structure is set up


<table>
<tr>
<th>header row</th>
</tr>
<tr class="exoccclick">
<td>Something</td>
<td>Another Thing</td>
<td><span class="pdcold">53</span></td>
</tr>
</table>

And this is the click handling code for both the tr class (exocclick) and the span class (pdcold)


$(document).on('click','.pdcold',function(e){

var tbid = $(this).closest('table').attr('id');

console.log('pdcclick ' + tbid);

return false;  //<--don't forget this bit!
});

$(document).on('click','.exoccclick',function(e){

//some stuff

});

As this is internal I can’t link the actual page,  but here’s a screen shot of what the row looks like:

The Pend DC Old column is the span class where I added the click handler

The Pend DC Old column is the span class where I added the click handler (click to enlarge)