Adding Subfield Definitions

[Daniel DeLoach]

Forgive me, I am sure this is a question that will seem simple to most of you but at this stage of my Cloverleaf experience there are still many things I am trying to figure out!

Here’s my problem:

v5.5 on Windows

We have a laboratory application that sends out results. For the most part, everything works ok. However recently they noticed that “part” of their micro reports were not coming across, specifically the ‘organism name’. I’ve tracked down the problem to the format of OBX-5. Here’s an example of what they will send out:

OBX|1|CE|STREPA^THROAT, STREP A CULTURE^|1|STRGRG^Group G beta-streptococcus||||||F

Now since the map is set up to send OBX.#5 to OBX.#5 (no subfields are defined in the message definition), what we get outbound is

OBX|1|TX|STREPA^THROAT, STREP A CULTURE||STRGRG||||||F||||BDH

Because its only getting that first subfield in OBX-5, I presume since the transaction definitions have no “OBX-5.2” defined.

So the question is:

Is there a way I can ADD a definition for an OBX-5.2 to the transaction variant, so I could then CONCAT instead of COPY? I don’t see a way to do this…at least it’s not obvious.

I have tried juggling this with some tcl to lindex the incoming OBX-5 values and concat them back out, which “works” but causes undesireable charactes to appear in the rest of the OBX lines of the report that only have one value (no OBX-5.2). So maybe there is more tcl code that could do this to….but I’d rather not have to go through all that for what seems like a straightforward problem.

Topic

[Tom Rioux]

Try just using the Pathcopy instead of Copy and see if that works for you first.

Hope this helps…

Tom Rioux

[Max Drown (Infor)]

And you could copy OBX.#5.[0], OBX.#5.[1], OBX.#5.[2] etc. without making any changes to the variant.

-- Max Drown (Infor)

[Daniel DeLoach]

Awesome, thanks Max – that’s the trick (hardcode the OBX.#5.[1] in the CONCAT even if it doesn’t “exist” in the variant def to select from the GUI). This seems to solve my problem, and is something I’m sure I’ll use again soon.

Pathcopy wasn’t really an option in this case, as there is too much other manipulation in the message going on….thanks for the thought though.

[Jim Kosloskey]

Daniel,

The OBX segment is rather unusual.

Normally each field has its own Data Type. However for the OBX segment the OBX-5 field’s Data Type is governed by the Data Type value expressed in OBX-2.

Note in the segment you cite for the example that OBX-2 has the value CE which is a valid HL/7 Data Type that means Coded Entry.

Thus the variant has a generic field Data Type for OBX-5 and it is at segment evaluation that the Xlate needs to determine how to handle the OBX-5 field based on the content of OBX-2.

So you need to make sure that the set of OBX segments you can receive all will be CE types (in OBX-2) or else your use of the component notation may not function as you want.

Just a caution to make sure you thoroughly analyze.

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

[Daniel DeLoach]

Thanks Jim,

Yes that was a consideration and I do think I may go and clamp this down a bit with some additional logic (eg, if OBX-2 =CE then CONCAT else COPY)…but since the CONCAT seems to work regardless (since OBX-5.2 is not generally valued otherwise) it seems ok for now. I do need to further test all the scenarios but I think the way the consultant originally set this up (questionable in many ways) these particular results are going through their own xlate and so are the only ones so affected.

Great point about the OBX-2 though and something to keep in mind for sure.

[Jim Kosloskey]

Dan,

It sound like you have a handle on it.

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

[Daniel DeLoach]

It only looks that way!

[Author]

Replies