Design Principles for Alignment, Review and Constraint of V3 Publishing Content

Background

The HL7 V3 design process is predicated on three, inherently conflicting objectives -

1. To allow individual Work Groups to focus on the material or subject matter with which they are experts;
2. To provide coherent standards derived from singular high-level models for RIM, Vocabulary and Data Types;
3. To re-use common specifications in order to reduce development effort increase efficiency; and
4. To provide parallel development in order the provide standards that are respnosive to the evolving needs of the implementers.

Over the years, processes to support these objectives have been developed, including:

• Harmonization to provide singular models for RIM, Vocabulary and Data types;
• Definition of shared common structures for CDA, CMETs and selected message types; and
• Tools to support the parallel development within a Work Group of both static model designs and the documentation of the domain framework in which those designs are used.

Where this all comes together is in "publishing." Four times a year (three ballots and a Normative Edition), the HL7 Director of Technical Publications receives material from myriad Work Groups that must be gathered, analyzed, corrected, and packaged to produce either a reliable ballot, or a formal Normative Edition. This must be done, in collaboration with the facilitators who make up the V3 Publishing Work Group, in a matter of a few weeks, starting with the initial content dead lines, and ending when the ballot opens.

This document attempts to lay out the rules and principles under which this activity proceeds, with a goal to "automating" as much of the process as possible.

Content Sources and Source Types

As noted, the content sources are the work groups, of which there may be many, but the material they provide and types of content provided are different, and the treatment of this content may differ depending upon whether or not its primary intended use as a "common" shared content, or an implementable package.

Submission	Common?	Source Forms			Dependencies
		Primary	Design	Supplemental	RIM/Vocab/DT	Wrappers	CMETs	CommonMsgs
RIM and DTs	Y	MIF			Y
Vocabulary	Y	MIF			Y
CMETs	Y	PubDb	StaticModel	PubDb	Y		Y
Wrappers	Y	PubDb	StaticModel	PubDb	Y		Y	Y
CommonMsgs	Y	PubDb	StaticModel	PubDb	Y	Y	Y	Y
Domains		PubDb	StaticModel	PubDb or PDF	Y	Y	Y	Y
Non-Domain Specs		MIF or PubXml or PDF		PDF	?

A legend for the above table follows:

• CMETs - Common Model Element Types
• Common - Material whose primary intent is to provide re-usable specifications for use in defining RIM-derived static model or for use in assembling "Domain" content.
• CommonMsgs - Shared messages and interactions, primarily for acknowledgment transmittals
• Domains - Every content specification that is not intended primarily as "Common", that includes RIM-derived, implementable static models, and that relies on a defined behavioral framework.
• DTs - Data Types Specifications
• MIF - File in Model Interchange Format (replacing PubXml and VisioXml formats
• Non-DomainSpecs - Content specifications that are not intended primarily as "Common content" and that are not "Domains"
• PDF - Page Description Format files for document publication.
• Primary - This column under Source Forms lists the primary content format or a specification.
• PubDb - Publication data base, which is expressed as PubXml
• PubXml - File in HL7's XML document type definition defined in 2000.
• RIM - Reference Information Model
• StaticModel - Form for expressing static models. In 2010 this is principally VisioXML and Visio "vsd" files. In future will be MIF with both graphics and design content.
• VisioXML - File in HL7's XML type used to represent the design content of a static model defined in Hl7's RMIM Designer in Visio.
• Wrappers - Transmission, Query, and Control Act Wrappers