Embedded PDF content in OBX:5 more than 32K

[Sheetal Kairawala]

Hi Everyone,

We're usung ensemble 2011 and ran into an issue where we get more than 32K characters in embedded PDF into OBX:5. Healthshare only allows 32K characters per OBX segments.

Has anyone encounters this problem? We need to break up into multiple OBX segments.

Any suggestions would be very helpful.

Thanks
Sheetal

[Ted Peck]

The problem is not that you can't get an OBX of that size, only that DTL
won't manage it for you. You need to use the methods in EnsLib.HL7.Segment:
GetFieldStream...()
StoreFieldStream...()
and then operate on these streams.

If you simply wanted to pass this sort of message through Ensemble
without operating on it, that would be no problem.

[Lawrence Harris]

The #1 issue is that both ends of the message agree on how you are encoding the document in the OBX segment (specifically OBX-5).  Once you have agreement on that then if it must be sent in one OBX containing the whole document then Ted's suggestion is probably the way.  Some versions of HL7 have limits of 64k for OBX-5 but the implementation many not adhere to them.

If it can be broken up or there limits in other aspects of the communication path that mean you can't send it in very large segments then you could also to break it up into say 30k chunks to be reassembled at the other end by using OBX-1 the Set ID to indicate the continuation segments.  Again both sides need to agree.

OBX|1|ED|DOC^Document^L||^application^pdf^Base64^…first 30k chunk

OBX|2|ED|DOC^Document^L||^application^pdf^Base64^…second 30k chunk

  :

OBX|n|ED|DOC^Document^L||^application^pdf^Base64^…last chunk

If the issue is just 'how' then these links might help with some background.

http://www.hl7standards.com/blog/2007/11/27/pdf-attachment-in-hl7-message/

http://books.google.ca/books?id=EVjOolUJNGUC&pg=PA298&lpg=PA298&dq=hl7+obx+Encapsulated+Data&source=bl&ots=VlHkmCkBls&sig=L-QGZTSMkBJxCyyN1jeCVhp4ZMI&hl=en&sa=X&ei=2jp9UumVBcTmiwLArYH4DQ&ved=0CDIQ6AEwAQ#v=onepage&q=hl7%20obx%20Encapsulated%20Data&f=false

The first link is fairly basic, it suggests sending it as an ED data type using base64 encoding.  The second is talking about DICOM images but extrapolates to PDF and other document types.

Lawrence Harris

activEHR

by EMRlogic Systems

1-866-367-2899 x 641

lha...@EMRLogic.com

--
You received this message because you are subscribed to the Google Groups "InterSystems: Ensemble in Healthcare Community" group.
To post to this group, send email to Ensemble-in...@googlegroups.com
To unsubscribe from this group, send email to Ensemble-in-Healt...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Ensemble-in-Healthcare?hl=en
--- You received this message because you are subscribed to the Google Groups "InterSystems:  Ensemble in Healthcare" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Ensemble-in-Healt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sheetal Kairawala]

Thank you Lawrence and Ted.

Sent from my iPhone 4S

[Ryan]

Ted - Almost :-)

If passing through from Service to operation and never touching it with a DTL? Sure. But as soon as you have a DTL mess with it - either a copy or a new - it actually truncates the data for the OBX:5 in the outbound message object. A nice little code block in the DTL that messed with OBX:5 like what you described works perfectly. Here's a snippet:

<assign value='source.{OBX(1):4}' property='target.{OBX(1):4}' action='set' />

<code>

<![CDATA[  

  // -- Since the data from an Epic MDM can exceed 32K on a single field, process the RTF encoded field as a stream.

  // -- Be advised - doing this marks the message "Immutable", so if you have to edit it even further, do 

  // -- it in a custom business process, or send it out and back in to the engine as a whole new message.

  //

  Set tSize=0

  Set tLargeField=##class(%Stream.TmpCharacter).%New()

Set tStatus=source.GetFieldStreamRaw(.tLargeField,"OBX(1):5(1)",.tRemainder)

Do tLargeField.Rewind()

Set tSize=tLargeField.Size

Set tStatus=target.StoreFieldStreamRaw(.tLargeField,"OBX(1):5(1)",.tRemainder)

Kill tLargeField

  //

]]></code>

<assign value='tSize' property='target.{MSH:8}' action='set' />

(I just parked the stream size in MSH:8 - Epic doesn't use it (or at least didn't when I wrote this) so MSH:8 sometimes makes a great debugging field. 

Ryan 

[Ted Peck]

Ryan, you are quite right that if you mess with it in DTL then truncation will occur, unless you use a code block as described.

One hopeful development: in the upcoming 2014.1 release the truncation will occur at 3.6Mb instead of 32k, due to implementation of "long string support" by Dale:  DDP879 - Support long strings in Ensemble HL7 framework.

This change will allow manipulation of much larger field values but if you need to handle fields of any possible size then you still should use a code block as described.  In general PDFs and GIFs that might be encoded into an OBX could easily be larger than 3.6 M.

Ted