Question
Marykutty George · Dec 3, 2020

HL7 message from JSON Input file

What is the best way to create an HL7 message from JSON input file?

We have JSON file available with data required for building the HL7 message . I am trying to use a standard file/FTP Business service to pick up the file and convert the input %FileCharacterStream into a dynamic Object and use the stand JSON features to read /process the data and build the HL7 message. 

Is there any other better way to do this? or any standard built-in functionality available in HealthShare? 

Thanks you for your help

Mary

Product version:
IRIS 2019.1
00
1 0 2 132
Log in or sign up to continue

Replies

Hi Mary,

I just went through a similar exercise, although in my case, I was importing JSON Data directly into SDA.

I can think of two ways of going about this:

The first one is what you are doing - that is, extracting JSON data using %Get(), %GetNext(), etc... and save the data to the Properties of the correct EnsLib.HL7.Message object (based on the message type). This is the most straightforward way but I found that it has drawbacks. The biggest one is that you have to initialize every variable that is being saved to the object Property. The reason is, you usually wouldn't know whether a certain field that you expect is populated or not (unless you have a way to check this by running the JSON files through some kind of schema first). So if you try to store something that you expect but does not exist in this particular JSON snippet, your processing would stop. Everything that is being set to a Property should be initialized (usually to ""). 

Because you are on IRIS, you have another option. IRIS now supports JSON Adaptors (not sure if your particular version supports it). You could create a Data Model: a separate Object for each HL7 message, which would all extend %JSON.Adaptor. This is rather like working with %XML.Adaptor: you should be able to read JSON messages directly without using Dynamic Objects. The advantage would be that before storing the data in the HL7 Message Object, you would store it in an intermediate object. I see the following advantages:

1) If you need to make a change because message structure changes, you would make a change only to the particular object, not the whole Business Process/Operation that would be extracting all of your JSON files.

2) It is easier to troubleshoot and maintain for the same reason.

3) It is easier to scale for different Participants (if they have differing JSON objects)

4) These objects would be %Persistent so you could pass them to Methods and in Ensemble messages.

Because you are dealing with JSON objects that mimic HL7 messages, this method may not give you more advantages. HL7 messages are discrete so if you create a Business Service for each message you could create a business process for each one as well, making it easier to troubleshoot. 

I hope this helps.

Thank you @Vitaly Furman  for explaining it.  

We are only handling one message type (ORU_R01) and the data items are fixed so I think it I will go with the first approach.