Building an HL7 reference with variables

Hi folks

We have some clients that use non-standard locations for some information.
We are trying to keep out parsing as generic as possible, so I am passing in some values using JSON.
So far, that works great. But as we set up new clients, there is potential for many variations on where the data resides.
So I thought about passing the segment/field information, and building the parse information on the other side.
Example:
function MapDFT(DFTMessages, MsgIn)
local ftseg = ‘PID’ — Would be passed into the function
local ftfield = 18 — Would be passed into the function
local ftsub = 1 — Would be passed into the function

DFTMessages.VistitNumber = MsgIn.ftseg[ftfield][ftsub]:sub(1,20)

But I am not sure how to properly interpret the final result so the code understands it.
‘ftseg’ member does not exist.

I believe this approach will allow for maximum flexibility. I can pass the customized values in JSON and build my database insert on the fly.

Thanks!
Steve

Steve Ela
Macro Helix / McKesson
Software Developer / Integration Lead / Scrum Master

The syntax you are probably looking for is:

DFTMessages.VistitNumber = MsgIn[tosting(ftseg)][tonumber(ftfield)][tonumber(ftsub)]:sub(1,20)

However, I am unsure what the advantage of this approach versus just mapping the field from MsgIn directly.

It sounds like you want your processing logic to have static code rather than code that accommodates unique mapping across clients. In that case, you want to pass into that processing component a standardized message where those varying visit number locations have been mapped to the same field. Like perhaps you should only be passing through a normalized JSON message rather than the source HL7.

Sorry if I didn’t understand your objectives correctly.

Casey Trauer,
Director, Client Education
iNTERFACEWARE

The syntax you are probably looking for is:

DFTMessages.VistitNumber = MsgIn[tosting(ftseg)][tonumber(ftfield)][tonumber(ftsub)]:sub(1,20)

However, I am unsure what the advantage of this approach versus just mapping the field from MsgIn directly.

It sounds like you want your processing logic to have static code rather than code that accommodates unique mapping across clients. In that case, you want to pass into that processing component a standardized message where those varying visit number locations have been mapped to the same field. Like perhaps you should only be passing through a normalized JSON message rather than the source HL7.

Sorry if I didn’t understand your objectives correctly.

Casey Trauer,
Director, Client Education
iNTERFACEWARE

Correction:

tostring(ftseg)

not

tosting(ftseg)

Casey Trauer,
Director, Client Education
iNTERFACEWARE

90% of the original message is good. Its that 10% that I want some flexibility with.
We want the inbound channel to accept the message, and pass client specific information into the queue, then have the processing channel to the heavy lifting.
Passing seg/field locations is one way of doing that.
Not idea yet if it is the best way or not 🙂

Steve Ela
Macro Helix / McKesson
Software Developer / Integration Lead / Scrum Master

This is what I ended up with. Someone not familiar with the code could easily change what fields are being pulled.

Local channel module with client values

local cV = {}
cV.adtEnc1,cV.adtEnc2,cV.adtEnc3 = ‘PID’,18,1
cV.adtPt1,cV.adtPt2,cV.adtPt3 = ‘PV1’,18,1
return cV

Dynamically extracting the message values

OutADT.PatientType = MsgIn[cV.adtPt1][cV.adtPt2]:sub(1,20)
OutADT.VistitNumber = MsgIn[cV.adtEnc1][cV.adtEnc2][cV.adtEnc3]:sub(1,20)

Steve Ela
Macro Helix / McKesson
Software Developer / Integration Lead / Scrum Master