This topic contains 4 replies, has 2 voices, and was last updated by  steve.ela@macrohelix.com 4 weeks, 1 day ago.

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

    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

You must be logged in to reply to this topic.