New post
Question
· Nov 8, 2017

Maximum Size of HL7 Record

#Ensemble #DTL #HL7

So this may sound trivial, but I'm seeing conflicting information on this topic and hoping to get clarification.

 

According to Enslib.HL7.Message class definition, the maxlength of RawContent is 10,000 characters. So when using encoding like UTF-8, that is 10KB. When using Unicode, that should then be 20KB.

But then also coming across some forums and documents where 32KB is maximum size before HL7 fields are truncated.

 

What is the sure way to determine and modify an interface's maximum supported message size?

Discussion (6)1
Log in or sign up to continue
Sean Connelly · Nov 8, 2017

RawContent is a calculated property that is truncated to 10,000 characters. Something to do with playing nice with result-sets.

Perhaps RawContent was not the best name for this property, maybe PotentiallyTruncatedRawContentSoBeCarefull would have been better.

The actual raw content is stored as a string in a global, so presumably it is limited to either 32k or around 3.6GB depending if long string support is enabled or not.

1 0
Anthony Filaski · Nov 8, 2017

Thanks, Marc. This sounds similar to post https://community.intersystems.com/post/how-avoid-truncation-hl7-message...

So if I'm understanding this correctly, streams theoretically have no max size, and even with large strings enabled we would still need to look into building custom classes that access the raw untruncated stream via OutputTo* and possibly also need to use the [Get/Store]FieldStreamRaw methods for processing large messages. Correct?

0 0
Marc Mundt · Nov 8, 2017

The content of an EnsLib.HL7.Message is actually stored in streams, which don't have a fixed size, so theoretically there is no maximum size for an HL7 message.

The RawContent property is a bit misleading. This is a convenience for accessing the content of the message, but it's not where the content is actually stored. RawContent is generated dynamically from the underlying streams but only returns the first 10000 characters.

If you want to access the full, raw, untruncated message you can use one of the OutputTo* methods such as OutputToLibraryStream.

1 0
Marc Mundt · Nov 8, 2017

Brendan's post is a related issue, but it's important to note that what he describes only applies if you want to update the value of a specific field when that field contains > 32K of data.  The total size of the message isn't an issue.

As an example: if you have an ORU message with a 10 MB PDF stored in OBX:5, you will still be able to update fields in the PID segment using standard DTL functions. But if you want to update OBX:5 you will need to use the functions that Brendan mentioned.

1 0