XML embedded in OBX;5.5 of MDM message

Did anyone reply to you…I need to do the same thing…Can you share your findings with me? Wilson Wat 267 479 1312 wilsonwat@ccpdocs.com

We just set up Interqual’s ADT side but have not touched the outbound side yet.  I had planned on using the tcllib base64 package to decode the xml data.  Based on the CERMe HL7 quide this should be all we need to decode the data so that we can work with it. We are still about 3 months away before we plan on starting to working on the outbound side.

Good luck.

No reason to use the Base64 package.  Cloverlead has built-in commands for base64

     encode      Encodes to Base64

     decode    Decodes from Base64

Anyone get this done for the outbound CareEnhance Review Manager?  I tried using the tcl package (per thread https://usspvlclovertch2.infor.com/viewtopic.php?t=3948&highlight=base64) by requiring base64 package in my proc.  When I pull out OBX-5 and try to decode using the method described in the other thread, all I get is junk.  It’s not readable at all.

Here’s my code:

set obx5 [hl7_get_field $data OBX 5]

echo “Encoded OBX-5:n$obx5”

set obx5 [base64::$type $obx5]

echo “Decoded OBX-5:n$obx5”

What is the value of type?  What do you get with the first echo?

Not enough here to provide help.

FWIW, I think the hl7 package (hl7_get_field, etc.) is one of the worse packages that was ever written.  Unless it is a different one than I ma thinking of, it goes through a complete parse of the message everytime you request a field. – A LOT OF OVERHEAD.

I am sorry to say that library of procs was written by one of our ex-employees and even sorrier to know it is still in use within the user community.

Just my opinion  😀   Which is worth less than the usual $0.02.

Sandy,

 I have not gone any further but I remember when looking at the data that the actual data was in subfield 5 so after getting field 5 you will have to split the field on the ^ and do and lindex 4 to get the actual encoded data.

John – Thanks for pointing out that the actual data is in subfield 5.  The code I posted works on the subfield.

Charlie – Sorry for not giving enought info.  Type  is encode or decode.  

The “hl7 package” we are using IS the old one.  Is there a new package available?  Or what would you suggest using instead?  We are moving to 5.7 on Red Hat by December and this is where we’re developing this interface.

Thanks for the help!

Assuming you are on .7 you have tcllib1.8 which is pretty well up to date.  The base-64 package there is pretty good.  There is a later version of tcllib. 1.11 I think, but I do not beleive the base64 package changed.

If you feel you need the latest you can always download tcllib from SourceForge

Hi Charlie – The base64 TCL library on 5.7 appears to work great (when you use it on the proper field  😳 ).  

For the hl7 package (i.e. hl7_get_field, etc.), what do you suggest replacing that with?  Is there an updated package available or is there a preferred method using TCL code to extract a specific field (or replace a field, etc.)?

Thanks for your contribution to this list!

The splits you have to do to replace the package is less than the time to use the package.

set fldSep [string index $msg 3]

set subSep [string index $msg 4]

set segList [split $msg r]

set PID [split [lsearch -inline -regexp $segList {^PID}] $fldSep]

set PID3 [lindex $PID 3]

If you need to later replace PID segment:

set pidLoc [lsearch -regexp $segList {^PID}]

set PID [split [lindex $segList $pidLoc] $fldSep]

set PID3 [lindex $PID 3]

How easy can it be?

Sandy,

 No problem, we are just waiting for them to understand that they need to store the visit information with the case from the hl7 message so they can send it out again otherwise we can’t file the message.  At least for us we need the account and visit info which they don’t provide.

 The sad thing is this is a McKesson product and we are trying to file back into a McKesson product and they can’t talk 😡

I hope your having more luck,