Thursday, 16 September 2021

Looping over repeating OBX values and updating the segment

I regularly need to update HL7 messages as the data flows between systems. Often, it's significantly cheaper to take the feed designed for another integration and massage the HL7 message before passing it onto your integration.  

With Integration Host you generally just remap using the Transformers and it's all very simple. But the other day I got a wee bit tangled when trying to update OBX values.

I wanted to loop over each OBX segment, look at the value in the OBX-3.4, then use some conditions and lookup tables (note: loving lookup tables right now) to alter the value before inserting it back into the OBX-3.2.

So I used a FOREACH transformer to loop over the OBX values, then put the OBX-3.4 into a variable that I then updated to the value I needed.  This was all easy, but the trick came when I tried to write the value back into the same OBX line the FOREACH was on.  My mapping just wrote each value into the first segment, overwriting it each time, leaving the last in place. This stumped me for a bit and I contacted HL7 Soup support.

It turns out that the loop is only looping over the incoming OBX values, not the outgoing ones, so you can’t use it to set the value in the destination message.  Rather you need to create a different HL7 path for each iteration and set that value.  Apparently, they looked at creating a feature in the UI to allow this several times, but it turns out that code is by far the easiest way:

//Update the OBX-3.2 on the same index as the for each loop.
IHL7Message destinationMessage = (IHL7Message)activityInstance.Message;
string path = $"OBX[{workflowInstance.GetVariable("ForEachIterator")}]-3.2";
destinationMessage.SetValueAtPath(path,  workflowInstance.GetVariable("UpdatedValueVariable"));

Above, you can see that you just construct the path we wish to write to using the forEachIterator variable (which is automatically populated by the FOREACH Transformer), then set the path in the destination message with the needed value - the variable "UpdatedValueVariable" in my case.

Extracting HL7 Fields out of File Names with HL7 Soup

Sometimes when generating an HL7 message, the trigger or source of the message is a file that doesn't contain parsable data such as a PDF.  It's a fairly common practice to use the 255 filename characters to include some additional metadata.  This post shows how to access the filename and then how to extract the values.

Integration Host makes accessing the filename very easy.  If you have a Directory scanner the filename is automatically put into a variable for you to use "DirectoryScannerFileName". The value includes the filename and extension, so it's pretty convenient to use if you just want to update the same file, but as we want to use the values, we need to remove the extension and split that metadata out.

To do this I used a Code Transformer with the following code:

//Get the destination message
IHL7Message destinationMessage = (IHL7Message)activityInstance.Message; 

//Get the filename
string fileName = workflowInstance.GetVariable("DirectoryScannerFileName");

//Remove the extension
fileName = System.IO.Path.GetFileNameWithoutExtension(fileName);

//split it by the _ character
string[] values = fileName.Split('_');

//Write the values to their HL7 location.  I've just put them in dummy locations for now, as you can change them
//Note, that to use this the filename must have the correct number of values or you will get an error.
destinationMessage.SetValueAtPath("PV1-19", values[0]);
destinationMessage.SetValueAtPath("PV1-20", values[1]);
destinationMessage.SetValueAtPath("PV1-21", values[2]);

It's pretty straightforward.  You can see that I get the variable with the filename, then remove the extension, followed by splitting it by the "_" character.

Then it's just a matter of placing each value where I want it.  I've put it into the PV1-19 to 21, but you can use whichever location you need.

The one thing to note is that I've written this to error if the number of fields required isn't provided.  I prefer this outcome rather than proceeding even if the filename doesn't have all the values, but others may wish to put an IF condition around it to only add the values if the right number of fields exist.

Saturday, 3 October 2020

I'm back

Sorry about the missing me...

I'm still doing this HL7 and FHIR Integrations but have been really busy with it.  Also, I'm now using Integration Host as my Integration Engine, so don't really have the pain anymore that required this blog.  However, I know it's helped a few of your out there, so I'll try and make sure I add in some of the steps I perform.  I've updated a couple of my old posts too as Mirth Connect is now called NextGen Connect.  I still use "Connect" at a number of sites, but avoid it when possible.  HL7 Soup's much cheaper when you add in your time, it's a no brainer (heck, even Lyniate's cheaper than "Mirth" when you include your time).


Double double-quotes in HL7

Firstly, what does it mean?

PID||""|564346^^^MRN^MR

The simple answer is that the value represents blank.  But that raises the next question:  Isn't that the same as just leaving it blank?

No.  In HL7, if nothing is between the pipes it means that the value wasn't provided, or that it isn't known by the sending system.  That means that if you receive an update patient message, for example, where the patient's surname name is not provided in the PID-5.1, you should leave your records as they are. It would be wrong to update your database to nothing in this instance.

However, if you receive an "" then the sending system is telling you to update your database value to nothing, even if you have a value.  Yep, it's a way to blank out your value.

To me it feels like an awkward extension to HL7, I can picture when some tech in the early '90s pointed out this need and it got fudged into the HL7 structure.  However, it is what it is...

But then the important question is how to deal with it?

Well, now that I do my integrations in HL7 Soup's Integration Host, things have become simpler (yeah, like everything else).

Any binding between messages or variables supports a right-click option to "HL7 Encode with Quotes" that will automatically add the quotes into any value if it's omitted. Great if you're converting data in your system or another file to HL7 and want to put in the "" when it's blank to update the other system (without having to write code all the time!)

And the reverse is there too.  Say you receive an HL7 message and don't have the capacity in your web services to handle the "" value, well, you can right-click and "HL7 Decode with Quotes" and any "" value will be converted to an empty string of text.  

Even better, these functions will also handle the & and pipes that may occur to. 



Thursday, 8 November 2018

Writing Base64 encoded HL7 data to a Binary file

It is common to have Base64 encode data in an OBX-5 field. The most common I've come across are PDF documents, but also .Doc, Docx and other Document formats are common, as are the many image formats - TIFF, PNG, JPG, and BMP.

HL7 Soup is now my go-to HL7 integration engine for binary formats as it's just so simple, while at the same time it's totally flexible.  Let me show you. 

Create a receiver workflow that receives an HL7 message and then writes it out to a file.

In the transformers of the “File Writer” activity, drag the OBX-5 into the transformers list to create a new variable.


Then back in the “File Writer” change the message template to write out the variable (delete the default message template, the right click in message template and insert variable).


Now Just change the message type of the file you want to write to binary and you’ll have a binary file.


And that is it done.  Writing out a binary file automatically decodes the value from base64.  No mucking about with code or anything fiddly like that.  

OK, but what if it wasn’t actually binary data, you just had base64 encoded text for instance?  Well, you also have the option to right click on the variable and tell it to base64 decode the value like so. 




There are lots of different types of encoding available too.  Depending on the Message Type you select, you get different options.  E.g. if I had written out an XML document then right-clicking on the variable would allow me to "XML Encode" the data which replaces the &'s & etc.

Sunday, 12 August 2018

Get Patient Email Address from HL7 repeat Fields

The HL7 inbound messages I was receiving were a bit inconsistent on where to find the patient emails.  Basically, I need to look at the PID-14 and all repeating instances of this, one at a time until I find an email address.
It sounded to me like a good opportunity to try out HL7 Soups custom parameters, where I can code up my logic in c#.

Firstly I went through there introduction video on custom transformers, and then grabbed the sample code to base mine transformer on. 

I must say that I love the API, it makes coding with HL7 super easy.  The trick I found is to make sure you typecast the messages to IHL7Message right at the beginning.  It gives you heaps more methods and properties than the basic IMessage type (which is generic because it also works with JSON, CSV, etc).

The only thing I tripped up on was finding the repeat fields themselves.  I thought they may have been accessible on the GetFields() method, so I mucked around there for a bit.  But actually, they are a property of IField.  I just needed to call GetRelatedRepeatFields(), and it gave me an iterator that included the original field and its siblings.

The deployment was easy, and I loved the debugging right in Visual Studio.  So much easier than having to log out each line like in Mirth.

Anyway, here is the code I created, hope it helps.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using HL7Soup.Integrations;

namespace CustomTransformersSample
{
    [Variable("Patient Email", "sample@sample.com")]
    [DisplayName("Find Patient Email")]
    public class FindPatientEmail : CustomTransformer
    {
        public override void Transform(IWorkflowInstance workflowInstance, IMessage message, Dictionary<string, string> parameters)
        {
            string email = "";
            //Get the incoming message
            IHL7Message hl7 = workflowInstance.Activities[0].Message as IHL7Message;

            //Find the PID-14
            IHL7Field pid14 = (IHL7Field)hl7.GetPart("PID-14");
            if (pid14 != null)
            {
                //Look at all the PID 14s
                foreach (var repeatField in pid14.GetRelatedRepeatFields())
                {
                    //Get the 4th component (which is email)
                    IHL7Component component = repeatField.GetComponent("4");
                    if (component != null && component.Text != "")
                    {
                        //Found the email.  Return it.
                        email = component.Text;
                        break;
                    }
                }
            }

            workflowInstance.SetVariable("Patient Email", email);
        }
    }

}

Thursday, 10 August 2017

Update HL7 Soup Example messages

When you load up HL7 Soup you are presented with a selection of example HL7 messages.  They are great to get you going, but won't necessarily be what you normally need at start-up.
You may want your own message samples, or maybe you just want a blank page.  The great thing is that you can change these by simply making your changes and clicking save.
You can add your own HL7 messages, delete the ones you don't like, or edit the defaults to your hearts content.  Just click save when you are done, and you'll be confronted with your changes when you next load HL7 Soup.

So where is this stored? Well, I did a bit of hunting and found the file is stored at

%appdata%\hl7soup\Sample HL7 Messages.txt

You can just put your own file in its place too and it will be picked up as the HL7 Soup default.

One last thing, you might want to revert to the HL7 Soup default messages again.  I found a simple workaround that recovers these.  Just delete the file I mentioned above and when you reload HL7 Soup it will add it back in with the original sample HL7 messages.  Very handy.