Stream: implementers
Topic: HL7 v2 formatted text
David Hay (Jul 28 2016 at 01:45):
Suppose I have an HL7 v2 message with formatted text as the value. What is the best way to represent that in the value[x] element of an Observation? Markdown would seem the best option, but it isn't a supported datatype. We could use a string and put markdown in there, but the end user won't know that's markdown (unless we use an extension to indicate this of course)...
David Hay (Jul 28 2016 at 01:49):
Of maybe the unformatted data in the value, and formatted as markdown in the extension?
Eric Haas (Jul 28 2016 at 02:46):
Have you considered ValueAttachment?
David Hay (Jul 28 2016 at 02:53):
How does that value over string? Or are you thinking that the markdown/html whatever is b64 encoded with an appropriate mime type?
Stephen Royce (Jul 28 2016 at 03:03):
One of the advantages of Markdown is that the bare text is very readable as is. I'm not sure if this would be frowned upon, but you could put the Markdown text in the string and people "in the know" would decode it while others would get the bare text. As I said, though, that might be considered bad form because of it's esoteric nature.
Stephen Royce (Jul 28 2016 at 03:05):
Or are you saying no-one would be "in the know"?
Stephen Royce (Jul 28 2016 at 03:35):
In which case my suggestion is a bad idea and you SHOULD just ignore me! 
David Hay (Jul 28 2016 at 07:49):
That was where we started :) I'll likely propose that markdown is a valid observation.value datatype, but - as you say - the MD is quite readable, even as plain text...
Eric Haas (Jul 28 2016 at 16:29):
after looking at section 2.7.7 in the V2 spec ver 2.8.2 re FT formatiing. I don't see why you would need to use markdown here. if you want to reproduce it exactly as in the V2 message it will be text. If you want to have it all pretty and formatted at the end I'm still partial to valueAttachment so you can identify the Markup (html, markdown flavor)
James Butler (Jul 28 2016 at 21:48):
I feel a bit queasy about base64-encoding something which is *pretty much* human-readable text. One of the reasons for suggesting Markdown is that if a client can't interpret the markup it can still show the user something useful, the remaining problem being there's no way to tell clients that Markdown is what is there. If we present it as some kind of binary then a client is more likely to reject it outright imho.
Jeffrey Chen (Jul 28 2016 at 22:31):
I think it because HL7 v2 OBX has multipe types of text value. So, you have to provide additional information to that. In that case, ValueAttachment is the only place to hold those information.
Simone Heckmann (Aug 15 2016 at 10:01):
@David Hay What did you end up doing? I am currently facing the same issue: It mostly boils down to the question of what to do with the "\.br\" in OBX.#5. I have hardly ever seen systems using more sophisticated markup that that...
Simone Heckmann (Aug 15 2016 at 10:37):
oh wait. CR LF are allowed in datatype string! duh.
David Hay (Aug 15 2016 at 23:06):
From our notes:
Textual laboratory results might enter the system in an OBX message with a value of type FT (Formatted Text), an HL7v2-specific markup language. We currently expose this in FHIR as an Observation with a string value, where the string is the raw FT text complete with formatting. This isn't very useful for clients who don't know how to interpret FT formatting (which is a vague legacy standard used only in v2 messaging); and even clients which do will have trouble, because there's no standard way to indicate that a string Observation contains formatting instructions.
After consulting the FHIR community, we have determined that the only way to represent formatted text is by using an attachment value, with the original FT text base64-encoded and the media type set to tell the consuming application what formatting is in the value. It's a bit clumsy to base64-encode what is essentially plain text, but it's the mechanism available, so we will use it.
Our approach will be:
An FT-type result from an OBX will be mapped to an Observation with an attachment value
The original formatted text will be presented base64-encoded in attachment.data
attachment.contentType will be set to "text/x-hl7-ft" (ref)
attachment.title will be set to a string generated by a best-effort attempt at formatting the FT text, for display by clients which can't interpret FT text
see this blog (http://www.healthintersections.com.au/?page_id=441 ) for some guidelines
the 'h' and 'n' directives for highlighting should be ignored, and highlighted text presented as plain text
Simone Heckmann (Aug 16 2016 at 07:47):
My solution turned out to be the following:
*Replace all FT formatting with appropriate html tags and place formatted text into Observation.text
*Replace /.br/ with CR LF and remove all other formatting and place unformatted text in Observation.valueString
Sidenote: the sending system only used linebreak and bold as formatting tags. But I guess for Observations with a more excessive use of formatting, your solution is better.
Grahame Grieve (Aug 16 2016 at 07:59):
does this help? http://www.healthintersections.com.au/?page_id=441
James Butler (Aug 17 2016 at 21:06):
We didn't want to simply drop the Observation value into the narrative because we're not otherwise populating it right now, and:
If narrative is present, it SHALL reflect all content needed for a human to understand the essential clinical and business information otherwise encoded within the resource
and the value doesn't have some pretty essential context, like for instance the test that is being performed. If you are already generating narrative which includes all the important extra stuff, then it makes sense to HTML-ify the value there as well.
James Butler (Aug 17 2016 at 21:06):
Gah formatting fail
Last updated: Apr 12 2022 at 19:14 UTC
