XML standards for healthcare address a worldwide domain with a vast terminology and knowledge base. HL7 has addressed the size and diversity of information using a model-based process for defining XML specifications. However, it is not feasible to build all necessary constraints into model that drives the structure of the XML instance. For example, laboratory messages for a complete blood count (CBC) should have the same common structure, tag names and attribute types for each result. This can be standardized across a wide domain. Locally, however, requirements for sequence of results, for values of "normal" ranges, for units, and for the individual components of the test will vary.

HL7 is addressing the need for tighter specification on a local or regional level through a proposal for HL7 Templates. From the September 18 ("Baltimore") draft:

In the general sense, a template is a structured collection of data / information that, in total, is of interest to one or more healthcare stakeholders. In the specific sense of this document, an HL7 V3 Template is a constraint against a normative HL7 V3 specification. HL7 V3 instances must conform to some normative HL7 V3 specification, and in addition, can be stated to conform to the additional constraints expressed in one or more HL7 V3 Template.

...An instance that declares the use of a template must first be a valid and conformant HL7 V3 instance. In addition, the receiver can choose to validate the instance against declared templates - using an XSLT script, a W3C or Relax NG schema, or any other mechanism found to be most efficient... the HL7 V3 Template standard does not impose a particular validation mechanism.

Templates will be deposited in a registry/repository. HL7 is assessing use of an ebXML-compliant registry/repository for this purpose and is cooperating with NIST on a prototype as we develop our requirements.

The two-tier approach to validation addressed the social and cultural distribution of domain knowledge as well as the technical requirements of a model-driven XML validation mechanism. By layering the constraints, the industry can establish broad consensus on the technical framework for interoperability while maintaining closer control of domain-specific semantics in the hands of subject matter experts.

The plan for HL7 Templates is that organizations and individuals will submit competing and overlapping templates to the repository without requirement for balloting or consensus beyond the boundaries of the submitting entity. Through a query to the registry, users will learn which entities have built templates for a particular purpose and scope.

Templates is HL7's attempt to provide the industry with the best of both worlds: a generic, easily integrated and simple set of XML specifications that can be localized and customized through templates to meet the most rigorous of interoperability requirements. If successful, we believe this approach will be instructive to other industries as well.

While many open issues remain, we anticipate issuing a draft for comment following the Baltimore Working Group Meeting (Sept 30 - Oct 4). By the second week in December, we should have received a first round of comments and be in preparation for the first formal ballot cycle on HL7 Templates.