Need formatting standards for structured data capture?

Just Use HTML

Lab Soft News recently ran a story by Grahame Grieve about how Australia is dealing with preserving visual report formatting across interfaces. The approach described in the Australian standard is very similar to the approach mTuitive has taken in Ontario with structured anatomic pathology reports. mTuitive sends the formatted, human-readable report in a separate OBX section along with the discrete data elements. This means that the source of the report controls its formatting in the target system.

The downside is that most target systems can only accept plain text or very limited rich text. This means that mTuitive normally formats the document for the target system and its specific capabilities, even though far richer formatting options are available. That is, if an older system can only support plain text, mTuitive must format the document in plain text before sending it. This is safer than sending a richer format and letting the receiving system mangle it, introducing errors that affect patient safety. The problem of letting systems do the conversion for you is well-documented (see p. 91 of Paul Valenstein's Formatting Pathology Reports.)

The Australian standard's ability to specify a document type (RTF, Word, PDF, HTML, etc.) is helpful, except that there will always be a mismatch between document types supported by different systems. This means interoperable systems like ours must support every document type! Just because we can send PDF does not mean that the larger HIS or EMR systems can receive it. In addition, systems will often rely on an external viewer to open these documents, and some viewers are not available on all systems. Still, we should applaud the Australian standard's effort to enable rich formatting to be transmitted across systems that do support it.

Both approaches above suffer from forcing every system to know the formatting capabilities of every other system. Those of us who have spent many hours ensuring that a report will be readable across several systems are all too aware that the lowest common denominator always ends up being plain text in a monospaced font.

I think a better solution is for a standard to emerge that elevates the lowest-common-denominator formatting options across systems. There is something like this in the FT data element in HL7 v.2 but it is supported half-heartedly by vendors and is extremely limited. If only there was a modern standard that would give us rich formatting, proportional fonts, variable font sizes, images, and graphics in a way that works ubiquitously on all computers and mobile devices...

Oh wait, there is! And it's staring you in the face as you read this article. The Web! I would recommend using a small, well-defined subset of HTML that is known to display accurately across web browsers. This would actually give the larger systems who only support plain text an easy upgrade path to rich text formatting, as html rendering technology (ie: an embeddable web browser) is freely available to embed in any application on any platform. Recent advancements with HTML5, including updates to HTML itself, along with CSS and Javascript, bring rich graphics and other capabilities to the standard. I mean, if Microsoft, Google, Apple, and the W3C can all agree, can't healthcare software vendors?

When LIS systems were first created in the 60s and 70s, ASCII text was a good common standard. Now that common standard can be elevated to standards-based HTML, bringing consistent expectations for rich formatting across systems. This would obviously require some collaboration and support by vendors. mTuitive is willing to collaborate!