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 providers are the work groups, of which there may be many, but the material they provide and the types of content provided differ, 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.

The table at the end of this section (which is followed by a legend for the table) displays for each different grouping of submissions, whether those submissions primarily are for common use, the form(s) that the submissions are provided in, and the dependencies that these submissions have upon other submissions. (This table ignores "graphics" used to augment textual documentation in the submissions.)

For a typical ballot in May-2010, V3 Publishing processed:

• 35 PubDbs with
  • 6 for common content and
  • 29 for general domains
• 397 StaticModels (all but 17 of them as VisioXml) with
  • 233 for common content and
  • 164 for general domains
• 50 non-domain specifications (of which roughly 30 were in PubXml)
• 6 MIF or PubXml files for common content (RIM, Vocab, etc.)

Need less to say, the analysis and management of this content must be (and is) supported by automated analysis and needs more a linkages between the analysis and automated processing steps. After processing, this source came together to produce a web-site with about 17,000 files. This "explosion" of source is somewhat controlled. A single static model will, in the final analysis be represented as: 4 Mif files (MT and HMD in each of mif 1.1 and Mif 2.x), 1 html graphics overlay, 2 graphics (thumb-nail and large), 2 table-views (MT and HMD), 1 Excel view, 4 schemafiles s (HMD and MT in both Xsd and HTMl), and (on average) results in 2 interaction schema filess (xsd and html).

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