Inbound PDF to base64-encoded HL7

Jim,

I didn’t have the Style set to “Single” so I have changed that and bounced the process.

For the Directory Parse, I’m simply saying “PDF only” and then I have a tps on TPS Inbound Data (code snippet below) to encode the PDF:

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

keylget args MSGID mh
package require base64

set msg [msgget $mh]
fconfigure $msg -translation binary
set encodedPDF [base64::encode [read -nonewline $msg]]
lappend new_msg $encodedPDF

msgset $mh $new_msg
lappend dispList “continue $mh”

}

Now I’m getting this ERR: can not find channel named “%PDF-1.7 so I’m not sure what I should be writing for this TPS Inbound Data tcl in order to pass the appropriate data along to the xlate.

-Timothy

Jim,

I removed that unnecessary read but the value being passed to me, instead of the actual PDF data, is just the string “%PDF-1.7” instead of the actual PDF that I’m feeding it as a test.

This is the relevant code snippet for my dirParse:

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

keylget args MSGID mh

# add double quotes around filename with spaces
#set files [string map {“\x0d\x0a” “\x01”} [msgget $mh]]

set files [msgget $mh]
set newlist {}
foreach f $files {
if ![regexp — {.*\.pdf} $f] {
echo Skip $f
continue
}
lappend newlist $f
}
msgset $mh $newlist
lappend dispList “CONTINUE $mh”
}

And this is the relevant code snippet for my TPS Inbound Data tcl:

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

keylget args MSGID mh
package require base64

set msg [msgget $mh]
echo “This is the Message: $msg”
fconfigure $msg -translation binary
set encodedPDF [base64::encode $msg]
echo “The encoded PDF is $encodedPDF”
lappend new_msg $encodedPDF

msgset $mh $new_msg
lappend dispList “CONTINUE $mh”

}

Jim,

I removed that fconfigure as well. I’m still getting just the string “%PDF-1.7” so I’m wondering if you know what would cause that to be passed from the Directory Parse tcl.

-Timothy

UPDATE: After being delayed for a few months, we finally went live with this project only to find out that the process I outlined above didn’t work exactly as planned. The overall concept worked but the PDF was blank – correct title and number of pages, but no content. We didn’t run into this when first testing but we also tested with smaller-sized PDFs and I relied on the vendor to confirm the PDFs were valid. Lessons learned.

I decided to reassess how I set this up and came up with a solution that actually worked. The setup is roughly the same as before but on my fileset-local inbound thread, on the Inbound tab > TPS Inbound Data, I changed the tcl to only pull the filename of the PDF (which is a patient identifier in this case) and pass that along to the xlate. The VRL I changed to have one field – the filename – instead of before where it had two – one for filename and one for the base64-encoded PDF string.

I also updated the Archive tcl on the fileset-local inbound thread copying the PDF to a “staging” folder on the CL server.

The xlate builds the HL7, SQL-querying with the filename to build the patient demographics out as required by the vendor. This is the same as it was before. The difference is I now have a tcl snippet taking in the filename value, which lets me open the PDF that I put in the “staging” folder from the Archive tcl and then I do the base64 encoding here, using fconfigure to translate the PDF to binary first. Outbound variable now was the base64 string and then I delete the copied file that I put in the “staging” folder as it’s no longer needed. I’ve put the relevant tcl snippet below.

package require base64
set visitNumber $xlateInVals
set filePath “$HciRoot/data/UTF/Staging/$visitNumber.PDF”
set fileHandle [open $filePath r]
fconfigure $fileHandle -translation binary
set encodedPDF [string map {\n “”} [base64::encode [read $fileHandle [file size $filePath]]]]
close $fileHandle
set xlateOutVals $encodedPDF
file delete -force “$HciRoot/data/UTF/Staging/$visitNumber.PDF”

This may not be the most elegant or efficient way to do this, but given the size and scope of this interface – 20-30 600KB PDFs dropped overnight during non-peak hours for an interface that doesn’t require a huge amount of patient demographics in the HL7 – it works swimmingly. I also found a base64 encode/decode site is a huge help for quickly identifying if my base64-encoded PDF string was correct or not. Definitely recommend for speedy confirmation.

-Timothy

The PDF filename will always be the Patient Visit Number from our EMR and then I have an Advanced Database Lookup to our EMR SQL server in the XLATE to pull the minimum necessary demographics like Name, DOB, Gender, Department, etc. based on that Visit Number to fill in the gaps in the HL7. The volume for this interface is likely to be relatively small and controlled – files will always be dropped at a specified time and not in large quantities – so the combination of PDF file sizes and SQL queries shouldn’t be too taxing. If the overall volume was larger, I’d probably want the patient demographics in file metadata or in the file name as well.

-Timothy