Adding X12 envelope

[Jim Kosloskey]

Cloverleaf(R) 5.2 AIX 5.2.

I am building an X12 message from an FRL.

The last time I did X12 with Cloverleaf(R) was on release 3.3.1.

In that release, we could specify the ISA, etc. in the Variant and reference it in the Xlate.

With this release I understand that is not possible. The new way is to use Tcl.

So OK I looked at the tclproc and at first blush it appears that hciX12buildinterchange should do the trick – but wait – it needs to have the ISA, etc. in the message metadata. Well of course, since the source was an FRL and there is no way to build the ISA, etc. anymore in the Xlate – there is no ISA in the metadata.

Well I am guessing that the hciX12splitinterchange stores the ISA, etc. from the message coming in in each transcation set’s message so it is there for later.

Is there a proc which builds the ISA, etc. when there is no X12 message inbound from which to get an ISA?

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

Topic

[Mark Thompson]

Jim,

Check out hciX12buildinterchange in root/tclprocs/edi.tcl

- Mark Thompson
HealthPartners

[Jim Kosloskey]

Mark,

I did try using hciX12buildinterchange and that proc is failing because it cannot find an ISA in the metadata.

I suspect the hciX12buildinterchange proc is intended to be used in conjunction with the hciX12split interchange or some other proc which captures the ISA from an inbound 12 message.

In my case there is no inbound X12 message to get an ISA from. The X12 is being created from another message type and since we no longer can reliably define an ISA in the variant for use in an Xlate there is a need for the ISA to be added post Xlate (or perhaps inside the Xlate to the metadata).

So my question stands – does anyone know if there is a provided proc which creates an ISA from thin air (or hopefully provided arguments) or am I going to have to write one myself?

I don’t mind writing one – but why reinvent the wheel if one already exists?

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jim Kosloskey]

OK – I wrote a Tcl proc to build the ISA in the Metadata and that is working fine.

Now hciX12buildinterchange  (through the joinX12 event of the X12lib package) is complaining because Message Metadata USERDATA field does not contain GS.

I have looked at the joinX12 event and the comments would lead one to believe that the action is determined by the first two bytes of the message. If the first two bytes are ST then no GS is needed.

My messages do not have a GS they indeed start with the ST segment.

However, the code (joinX12) as I look at it seems to not follow the comments as it still looks for the GS even if the action is ST (first 2 bytes are ST). Upon not locating the GS in the metadata, it errors.

So does anyone know which is correct the comments or the code?

I really cannot see why a GS in USERDATA is necessary if the message begins with an ST segment and has not GS segments at all.

Anybody??

Thanks,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Bob Richardson]

Greetings,

Jim,

We have built one X12 270/271 Eligibility interface running under CIS5.4.1 Rev2 on AIX5.2.  Per our X12 expert who used to teach this stuff X12 is a standard that is enforced (!) unlike HL7 where (in my opinion) the only standard is how you spell HL7.  Ok… opinion aside…

As far as I know you need the ISA/GS/…GE/IEA envelope which the canned Cloverleaf package X12lib expects.  The ISA and GS segments are placed in Metadata field USERDATA so that you may perform routing/translation work on the ST sets.  Later on there is a join step which wraps the ST with the envelope and creates the GE and IEA using the values from the ISA and GS (not much in these segments).

So… your envelope hits a pre xlate tcl proc; you translate each ST; then the whole kit and kaboodle is put back together again at post xlate.

Sample pre-xlate logic:

       # load X12lib package

          package require X12lib

                 #

        # X12lib returns one msg handle per transaction (ST/SE)

        # we should only get one ST/SE per inbound msg, but

        # this can handle many, just in case

        # The ISA, IEA, GS, GE segments are saved in USERDATA.

        #

           foreach STmh [X12lib::splitX12 $mh ST] {

               lappend dispList “CONTINUE $STmh”

           } ;# end of foreach STmh

        #

        # since this is the last transaction, add a SEQ key

        # in USERDATA that will indicate this is the last

        # transaction in the batch

         set userdata [msgmetaget $STmh USERDATA]

         keylset userdata SEQ END

         msgmetaset $STmh USERDATA $userdata

         # kill the original inbound message

         lappend dispList “KILL $mh”

Sample post X12 xlate logic:

       # load the X12lib package

         package require X12lib

       run {

        # ‘run’ mode always has a MSGID; fetch and process it

           keylget args MSGID mh

       # get sepchars from metadata

           set sepchars [msgmetaget $mh SEPCHARS]

        keylget sepchars SEGMENT segsep

       # append transaction to tmp buffer

        lappend buffer [msgget $mh]

       #

       # extract USERDATA metadata and look for the SEQ key

    # if it exists, this is the last transaction in the set

    # so rebuild it with X12lib::joinX12

    # this is just in case a provider sends more then one

    # transaction per batch

       #

        set seq “”

        set userdata [msgmetaget $mh USERDATA]

        keylget userdata SEQ seq

        if {[string equal $seq END]} {

           msgset $mh [join $buffer $segsep]

           X12lib::joinX12 $mh

           set buffer “”

        } else {

           return “{KILL $mh}”

        }

           lappend dispList “CONTINUE $mh”

       }

Sample metadata:

   msgSepChars       : {FIELD “x2a”} {COMPONENT “x5e”} {SEGMENT “x7e”}

   msgNumRetries     : 0

   msgGroupId        : 0

   msgDriverControl  :

   msgRecordFormat   :

   msgRoutes         :

   msgUserData       : {ISA {ISA 00 {          } 00 {          } ZZ {999999         } ZZ {999999         } 080109 0805 U 00401 000938820 0 P ^}} {GS {GS HS 999999 999999 20080109 0805 938820 X 004010X092A1}} {SEQ END} {SENTFORPOST 1199887553}

Note: key=SENTFORPOST is my doing; not X12 split/join.

Note: values all 9s to mask our entity code and that of payer.

    I hope that this helps you out as I am also much of a novice myself in the X12 universe.  We did contract help from Quovadx to get this sucker up and running.

Enjoy.

[Jim Kosloskey]

Bob,

Thanks for the input.

I was fairly sure there would need to be a GS/GE segment set in the outbound message but the X12lib package seems to indicate the message used to produce the outbound message does not need any GS information it would be provided.

I am now guessing that if the mesage does not have the GS segment the package is expecting to get what it needs from the GS keyed list in the USERDATA Metadata field.

Thanks again,

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Author]

Replies