Restricting the Use of a Standard

Restricting the use of a standard is a topic that's come up multiple times in a variety of settings:

Use of GreenCDA "on the wire" was a topic at the HL7 Working Group Meeting, and has also been discussed during various HL7 calls.  On one of the HL7 mailing lists, the topic also came up regarding use of the HL7 Version 2 XML standard (Yes, there is a standard for that) "on the wire".  I happen to like that one for use with local transformations from V2 to CDA and V3 messaging.  It makes a nice bridge between the two that allows me to use off-the-shelf tools to support a variety of features.

Arguments for use on the wire or not are sometimes interesting.  However, the fact of the matter is that if a standard is useful, people will always find ways to use it that weren't thought of when the standard was created.  This is one way that standards support innovation.  One standard that was meant for exchange of information but not for storage is now being used widely for storage:  The HL7 Clinical Document Architecture.

If the standard makes it easy to do something (which is what standards should do), should we try to stop people from doing it?  I don't think so. What we should do, however, is consider how this new use would impact other systems, and how it might or might not be appropriate given conditions that weren't considered when the standard was created.  The complaint about V2 XML on the wire is similar to the issues about Green CDA "on the wire".  It creates a compatibility problem.  A system that only uses ER7 encoding for HL7 V2 cannot easily communicate with one that uses only the XML Schemas for V2.  You need a bridge between the two syntaxes.

There are other things to look out for.  A standard designed for an inpatient setting may not work when it needs to be used across enterprises, or in an outpatient setting.  Implementers need to understand these nuances.  A common example I use is regarding the CCD.  It's not a hammer suitable for all transfer use cases, something we knew before the fact, but became increasingly important afterwards.

As one observer mentioned, converting from ER7 to XML  "is trivial".  I've actually not found it completely trivial, except for simple cases.  I could write a one-off each time I needed it, but why should I have to.  It wastes my time and annoys my customers.  This is a trivial enough problem that HL7 should probably offer it as an open source solution.  That's an interesting consideration as I think about a variety of different  ways that HL7 can provide value in the future.