Muse vendor sending ORU with embedded pdf

Donna,

OK to begin with the vendor did not do this according to the standard (big surprise huh).

What should have happened is this should have been in an OBX segment with OBX-2 having the value of ‘ED’ (Encapsulated Data) indicating the OBX-5 field has binary data in it.

Then the OBX-5 would have the stucture of the ED Data Type. One of the components in that structure indicates the type of file (PDF in this case) and another indicates the encoding technique used. Finally one component houses the actual encoded data.This way the receiving system can know what kind of data/file is in the payload of OBX-5 and how to decode it. You can find the exact format in the HL/7 standard documentation (I believe Chapter 6 or 7)

So the vendor (rather typically) is too lazy or uninformed to utilize the standard so the vendor makes up a Z segment (worse thing the HL/7 committee ever allowed in the standard in my opinion).

What you don’t know is what encoding technique they used (at least they encoded the report). Ask them. My guess would be base-64 (pretty common). If they don’t know or you don’t hear from them for a while then try base-64 (hopefully you can find out what the report is supposed to look like so you can verify it decodes properly).

Base-64 is supported in Tcl by the encode/decode command.

So you can set up a VRL with one field and use an xltp type proc to decode the field into the VRL then use a Fileset protocol to deliver to a file – or use a Tps proc to parse the HL/7 and create your decoded output – or – maybe other ways but using the Tcl decode command.

Donna,

We are receiving these PDF’s from MUSE, and have some tcl code to do the necessary manipulation to make these into true base-64 encoded pdf’s which we send outbound to our EMR.  I also have some additional code (for another interface) that extracts an encoded .pdf, decodes it, and writes the binary file as a PDF file.  I will put together the information and post it, but it may take me a day or two….

Jim Cobane

Henry Ford Health

Here’s what we’ve used for our MUSE PDF output.  We send to McKesson HPF (Patient Folder), which requires the PDF and XML indexing file;  Thanks to others who posted a lot of this already on Clovertech, I just expanded on it for our site.

Basic overview:

1) HL7 ORU message from MUSE with embeded PDF

2) Tcl muse_pdfdecode_file.tcl, run as PreProc on the xlate since this ORU goes to multiple routes at our site.

3) xlate file muse_oruxml_hpf.xlt (attached as muse_oruxml_hpf.txt)

The xlate creates XML index file that corresponds to the PDF created by the Tcl in step #2 based on the HPF xml requirements.  Xlates are written in Tcl so it just gives a basic idea of HL7 to XML that we did.

I did some directory hardcoding in the Tcl, which wasn’t the most elegant, but was quick to get this working.   I also removed our logon credentials, etc… and put servername username password text in it’s place.  Hopefully it’ll help you out some.  Good luck, this wasn’t exactly a fun one here either, but once implemented it’s worked near flawlessly for us.

Hi Chad,

Funny, I’m curious from where you got that tcl

Using “string map” or “regsub” to convert encoding characters has the potential to fail. For example, the string FSF could be mistranslated depending on which sequence is replaced first. Here’s some code that I use for converting escape sequences.

Dave,

As I understand it the proper escape you describe would be F\S\F  not FSF  and when I use map:

string map

$stuff

Where $stuff contains F\S\F  I get the proper result:

~^~

No, FSF is correctly translated as |S| unless you replace the S before the F. In that case it is mistranslated as F^F.

It looks like “string map” will work in this case regardless of the order that you specify your mapping string. This is because it processes in order of the input string parameter and not the mapping string. The “regsub” solution that someone posted earlier in the thread could still fail.

The proc that I use can also handle hexadecimal escape sequences. I think the Muse interface only uses X0D and X0A, so those would be easy enough to add to a string map, but if you need the full set, it would be harder.

Dave,

OK I misinterpreted what was being escaped. I have seen vendors do this when they wanted to represent &&& – TTT – and of course that is not correct.

Why not simply Base-64 encode it?

Better late than never.

James, A few questions about your post re the embedded pdf from Muse.

Rich,

You don’t need to use the ampersand_fixer proc; that’s specific to one of our downstream systems.  Have you tried to display the temporary decoded .pdf file (that’s created with ‘exec uudecode -o ${path}${pdf_file} ${path}${encoded_file}’ statement) with Adobe?  You will need to tweak the proc so it doesn’t delete the file, then you should be able to grab the file (pull it down locally via FTP as binary) and open it in Adobe.

Jim Cobane

Henry Ford Health

Jim,

Thanks for the info.  Good idea to display the temporary decoded .pdf file.  I tried it and the document looks fine.  I also went as far as decoding the Base64 encoded file and writing that to a file just before the script exits.  That also looks fine.  Pursuing possible issues on the Cerner side.  

Appreciate the help.

Just a follow up on my prior post.   The pdf string that comes from Muse in the ZPD.3 converts fine in the tps_muse_pdf proc.  Although, I ran into a truncation problem in my xlate.  The 100k string length limit in my ZPD.3 and OBX.5 fields was not enough to handle this pdf string.    I edited the fields file and set the lengths of both fields to -1 and it worked fine.  The EKG Waveform opened perfectly in Cerner.

Hello Rich,

Did you validate, that the HL7 message is  complete after the translation? I found, that the translation cuts off the last part of a message, if it is to big. I never did determin the limit for cutting off.

Yes, we have verfied we are now getting the complete HL7 message.  At least so far.  Not in production yet.  The only truncation problem I have had so far is with the pdf string copying it from the ZPD segment to the OBX segment.  This was resolved by making the field lengths -1.

One and All,

The unlimited field length specification is available in the 5.8.5 Integrator Release.   We have found that with 5.7 once you edit the field length to be -1 and then open it up in the IDE and close the HL7 configuration it reverts back to 0 (zero).

Just a caveat here.

Enjoy.

Bob,

Thanks for the heads up on the field length in 5.7.  I will pass it on to the team.  We are in the process of preparing to upgrade to 5.8.5 before the end of the year.

How did you “wizards” arrive at what needed “scrubbed” in the inbound result from MUSE……?….is there a spec or understanding of PDF’s out there that would convey wjhat to change…or was it….a continual trial and error inefficient process ? to determine until ADOBE could load the file?

How did you guys determine what to edit in these files before decoding?

ie. changing the  T..R…F…E’s to other delimiter values…..?….is there a spec somewhere?

Sorry, I don’t understand the question.

You have to substitute the strings, that’s it. No trial and error. Here is my version. If its unclear just drop me a line.

regsub -all {\X0D\\X0A\} $msg [format %c 10] msg

set map

set n_msg “”

set n_msg [string map $map $msg]

# decode string

set sUUData [uuencode::uudecode $n_msg]

set sUUData [subst $sUUData]

set sUUData [crange $sUUData [string first “%PDF” $sUUData] end]

…and those are documented in Chapter 2 of the HL/7 standard for whatever version of HL/7 2.x is being used.

Hello Rich,

    I’ve been following this post as I am attempting to send a PDF from Xcelera into Cerner.  I have been able to create the message and encode the PDF in BASE64 in the OBX 5 field and tested decoding to make sure that I have the complete code in the field.

    While testing I have been writing the output to a file and now I am trying to send this into Cerner via a tcpip connection.  Once I do this when I replay the message my ORU from Cerner shows Pending and the PDF into Cerner shows no activity.  I checked logs in both Cloverleaf and Cerner and have not found any errors.

    Any suggestions on what to look at?  Anyone feel free to respond all suggestions are welcome.  We are currently on 5.7 ver 2.

thank you,

Mike