HL7 v2 defines an FT data type, but it’s very poorly documented. Worse, the documentation is focused on managing text and cursor on a terminal screen. The basic idea of the FT data type is that you have a stream of text with a series of embedded commands such as |This is a line\.br\This is a new line|. The | characters mark the start and end of the content (HL7 v2 syntax) and the embedded commands begin and end with the specified escape character, which is usually “\”.

The following commands are defined:

 .sp[N] End current output line and skip vertical spaces. is a positive integer or absent. If is absent, skip one space. The horizontal character position remains unchanged. Note that only for purposes of compatibility with previous versions of HL7, “^\.sp\” is equivalent to “\.br\.” .br Begin new output line. Set the horizontal position to the current left margin and increment the vertical position by 1. .fi Begin word wrap or fill mode. This is the default state. It can be changed to a no-wrap mode using the .nf command. .nf Begin no-wrap mode .in[N] Indent of spaces, where is a positive or negative integer. This command cannot appear after the first printable character of a line. .ti[N] Temporarily indent of spaces where number is a positive or negative integer. This command cannot appear after the first printable character of a line. .sk[N] Skip spaces to the right. .ce End current output line and center the next line h Start Highlighting n End Highlighting

Fill mode appears to be a synonym for word wrap (EMACS still uses the term). The documentation for the FT type says that the FT type is broken into sections by the component delimiter (^) (I’m not exactly sure how that works in something like the CF type, where the FT type is used as a subcomponent). Such sections reset the temporary indent, and mark the beginning of a new line in no wrap mode.

Formatted Text Documentation

The problem with all this is that no one uses terminals anymore. If you’re going to display the FT data type to a human, it’s going to parsed and converted to another display format – probably either HTML or RTF. From there, it might be rendered to PDF or directly using a RTF or HTML rendering engine (MS word or a browser). And the documentation above is rather obtuse from this point of view. So here’s some updated documentation:

 .sp[N] Don’t use or ignore. You can’t go down x number of rows and not reset the cursor in any of the common display formats .br End of paragraph – \par(d) in rtf,

in HTML. In plain text, this would be .fi Default (normal text). .nf no wrap. This is appropriate when the text is really a table laid out using spaces. A non-proportional font should be used (i.e. Courier New). In HTML, a

tag should be used. There’s no real equivalent for preventing wrapping in RTF – mainly the trick is to make sure that the font size is small enough to force wrapping.
.in[N]  Indent  of spaces, where  is a positive or negative integer. This command cannot appear after the first printable character of a line.add [n] to the current indent. The result must be 0 or greater. For HTML,
can be used for indent, but it’s a crude tool. Better to use CSS and the left-margin attribute. For RTF: todo. .ti[N] This is really synonymous with .in except that the effect resets on ^. .sk[N] Insert N spaces. N must be a positive number. In HTML, use   .ce I think it’s better not to use this. The problem is that this is just not well documented – does it carry past the next line? How does it interact with indents? is the centering affected by leading and trailing spaces? h highlighting – usually interpreted as bold (/\b) n turns highlighting off.

Here in Australia, we’ve added a few more rules:

• Don’t break the FT using ^. If you want a new line, use \.br\.
• Use a fixed width font whether wrapping is on or not. (It’s hard enough getting compliance with simple stuff, let alone subtle stuff like font switching).
• Reset highlighting using \n\ at the end of the line. (Avoids confusion about whether it is automatically reset or not)
• A weird precursor to HL7 called PIT is still used, and when used, is rendered using FT. That’s really a mis-use of the FT data type, and we’re trying to phase it out

These rules have been adopted by convention and/or fixed in the forthcoming MSIA clinical messaging profile.

Sample Test Cases

Here’s a simple case:

|This is a line\.br\This is a new line|

in HTML, this is

  <p>
This is a line
</p>
<p>
This is a new line
</p

which should be rendered as

This is a line

This is a new line

Here’s a more complex case:

|First line.\.br\\in4\Second line (Indented)\.br\
\.nf\\h\Table mode:\n\\.br\+------------+-----------+\.br\
| cell 1/1   | cell 2/1  |\.br\+------------+-----------+\.br\
| cell 1/2   | cell 2/2  |\.br\+------------+-----------+\.br\
\.br\

This doesn’t have line breaks in a real HL7 message, but I added them for readability here.

In HTML, this one is

  <p>
First line.
</p>
Second Line (Indented)
</p>
<pre>
<b>Table Mode</b>
+------------+-----------+
| cell 1/1   | cell 2/1  |
+------------+-----------+
| cell 1/2   | cell 2/2  |
+------------+-----------+
</pre>

The actually amount of indenting for inN depends on many factors (font, screen size, application layout policy). Note that I haven’t added <p> tags in the table mode – it’s likely to introduce inappropriate white space

Which should be rendered as:

First line.

Second Line (Indented)

Table Mode
+------------+-----------+
| cell 1/1   | cell 2/1  |
+------------+-----------+
| cell 1/2   | cell 2/2  |
+------------+-----------+

1. Larry Singer says:

The conversions you have proposed look good.

I would like to suggest one change: .br should probably be <br/> rather that <p>. If there are two .br in a row then these can (optionally) be converted to <p/>.

• Grahame Grieve says:

Maybe. Back-guessing whether one or two \.br\ is a paragraph can be a tricky business.

2. As I read the FT definition, it would not be wrong to use HTML in an FT field. Or CDA narrative formatting.

• Grahame Grieve says:

FT is derived from TX – String data meant for user display – by allowing these additional formatting commands here. So you could stick HTML or whatever in this field, but a proper interpretation would show the html source code as string data meant for display.

• “proper interpretation” could be based on additional conventions. I understand that this is the case in “HTML display segments” as specified in AS4700.2, provided that a reasonable subset of HTML is used. Here I found some potentially useful suggestions: http://wiki.medical-objects.com.au/index.php/Html_display_segment

• Grahame Grieve says:

In the next AS 4700.2, HTML will be recommended as ED. It’s a misuse to add additional conventions that invalidate existing ones.

3. Hi Grahame, for the table structure shouldn’t “|” be encoded as \F\ (field separator) in the message to be rendered as a pipe later, since pipe is the field separator I think using those as table delimiters will mess up the HL7 v2.x messages encoded using ER7.

Also I don’t think the .nf is needed ther because there are .br at the end of each line, si if a .br is redered as the is useless, BUT! if .br is rendered as \n, then the is needed.

Cheers,
Pablo.

• Grahame Grieve says:

yes, the | is an error, you’re right.

.nf is needed, because it says not to wrap before the .br. If the lines are shorter than the screen is wide, that won’t make any difference. But if the lines are longer or the screen space is narrow…

4. Hi,
I have an HL7 ORU message that i would like to highlight some of the text in the OBX segment. Not sure how to use the command to embed in the message. Any help is greatly appreciated. Thanks!

• Grahame Grieve says:

that sounds like a tool dependent question…