[John Perks]

That was it.

Since the thread was UPOC protocol, not fileset-local, the PROTOCOL.IBDIR was not available and I had done a cd to a different directory in one of the tcl procs.  That changed it immediately for the process’ command thread, and the rest is academic.

Thanks.

[John Perks]

Jim’s methods are not mutually exclusive, by the way.

They all could be utilized to some degree, depending on the needs of your situation.

#2 is probably the easiest to implement in terms of coding changes.  You can easily put the duplicated code into a called proc and just remember to globalize the necessary variables.

But that called proc probably no longer fits the profile of a tps procedure in terms of args it gets from the engine.  So use #3 and put those called procs in a package. then they would no longer be indexed in the current tclindex and consequently would no longer clutter up the gui proc selection windows in the IDE.  If they are no longer tps procedures you would not want them there anyway.

And using namespaces and packages obviates the need to keep all your proc names unique, which become a hassle as your collection of procs grows

You can combine both (user defined) passed arguments (#1) and global variables (#2) in the same procedure to further enahance the versatility of the procs you design.  After all, some variables you may want to share amongst all procs called from a main proc, such the $msg.  Other variables you may want only local, yet at the same time you need to pass their value back to the calling procedure.  It really depends on your needs; if you intend to make your called procs available to other main procedures developed later, now is the time to design them with that versatility and re-usability.

[John Perks]

Echo your $client_list before the foreach loop, I suspect it is not initialized.

If it is a valid scenario that client_list is not initialized, then do a catch {set client_list} catch_return and on error initialize client_list to null before hand.  Your loop list can be null, it just has to exist to prevent the tcl error.

[John Perks]

Or rather

Regards

John

[John Perks]

Jim,

I am doing that now; I think I would have had to do that regardless in order to do a XML-HL7 xlate.  I was just trying to get the odbc call to build the tagged message for me, instead of coding the TCL procedure to do so.

Regards,

Jim

[John Perks]

This can be done with tcl string and list manipulation.  Don’t forget, starting out, that your source value is really a list, and you want the first element of that list.  Depending on your tcl programming style, you can do it a couple of ways.

You need to split the string (the first element of the xlateInVals list) on the . character, and get the last element of the resulting list.

The following code will do it, and will work even if there are multiple or 0 occurences of the . character in the string.

lindex [split [lindex $xlateInVals 0] .] [expr [llength [split [lindex $xlateInVals 0] .]] -1]

Copy this code to your Pre TCL dialog box on the source side of the COPY action.

To simplify your code, you could set a TCL variable to [lindex $xlateInVals 0] and reference that variable in your command string.  You can have multiple TCL command strings in your dialog box if they are separated by a semi-colon.

[John Perks]

Yes, in order for your HRL segment to be considered repeating, like a repeating segment in an HL7 message, you must check off one of the “Repeat Options” in the “Segment Properties” of the HRL configuration.

I had a fixed record length input file, with multiple record types, with the record type identified by three characters in a fixed position.

I checked off the “Repeat While” option in the “Segment Properties”, and set the “Field” to the FRL field corresponding to the record type, and the “Value” to what is expected in that field.

Until I set it up this way, the HRL worked fine until it hit a “segment” or record type that was not expected; i.e. if I set up the HRL with Z00, Z01, Z02, Z03 records, all non-repeating, and the Z02 repeated, the Xlate quit processing when it encountered the 2nd Z02 record.  Once I set it up as repeating, it processed all of them and continued.

And Jim is right, just use the ITERATE action in your Xlate on the repeating segment (FRL).

If this explanation was all too concise and you need further help, you may email me.

[John Perks]

You can remove the dashes in an xlate COPY with minimal tcl code in the pre Input/Output panel:

regsub -all {-} [lindex $xlateInVals 0] {} xlateOutVals

It’s still tcl, but at least it is not an entire proc.

John Perks

jjp1576@bjc.org

[John Perks]

Although the regsub command is “quick and dirty”, I have a few cautions that only you can answer, since you know the data and your downstream application.

Obviously the NTE and OBX segment layouts are different, but the corresponding field sizes are different in the standard HL7 definitions; so watch for truncations.

Also, by changing one segment type to another, the message may no longer match the variant.

If you are already using an xlate, the safest way would be to build new OBXs from the NTEs.  It might not be simple, depending on the inbound segments, you may have to manually manipulate an index variable to get your segments in a specific order in your outbound message.

[John Perks]

Alter your regular expression to include the preceding segment delimiter, e.g.

regsub -all “x0dNTE” $msg “x0dOBX” $msg

If you look for the field delimiter (|} following the segment identifier (NTE), ignoring the preceding segment delimiter (x0d), you could alter fields which end in “NTE”.

Try it at the TCL command line to test it.

[John Perks]

Globalize myfileID, and make sure the “Run Translation Procs in start-mode” is enabled for the process’ option.

[John Perks]

Use the CONCAT action, select the input fields in their correct order, specify your separator, and select OBX.5 for the destination.

If you really want to use OBX.5 subfields, since there are not usually subfields in OBX.5, just do a normal COPY from each of your source to OBX.5, which is essentially subfield 0, and manually change the subfield index on the 2nd and subsequent COPY lines to 1, 2, etc.

[Author]

Replies