HL7 Edition/Ballot Quality Review

The following sections list Vocabulary domain specifications for which a reference cannot be found in the current Vocabulary content. Almost half of the attributes used in HL7 static model (message) designs are coded attributes, and each of these requires a constraint specification that constitutes a reference to an element defined in the HL7 Vocabulary. As a consequence, an HL7 NormativeEdition will contain 50,000 to 100,000 (estimate) vocabulary constraint references. Many of these references are the same. Nevertheless, there are almost 10,000 (measured) unique reference expressions in these designs.

In the HL7 "parallel development" environment these references are frequently inserted in model designs before their "target" has been added to the Vocabulary Content. This portion of the quality review looks for places where the necessary target is not in the Vocabulary. These arise for one of three reasons:

1. The reference may be incorrectly entered.
2. The necessary target has not been defined and approved (through Harmonization) in the Vocabulary.
   
3. The necessary target has been approved through Harmonization, but has not yet been posted to the Vocabulary content.
   

Note: For Normative Edition 2009, there are about 100 reference errors (just over one per-cent of the unique instances). Of these, over 1/3 (35) are incorrectly entered, and can be "fixed" by editing the static model design. The remainder have either not been proposed (majority) or have been approved but not posted.

The current analysis is based on a complete list of all vocabulary constraints cited in static model designs. These are extracted from the "Visio" output (xml) files or the "hmd" files exported from RoseTree. The MIF representation for all static model designs is drawn from one of these two sources. The design process specifies whether the constraint is asserted as:

• A Code System constraint, usually with a specific code reference as well. (These are correct representations for constraints of structural attributes.)
• A Value Set constraint.
• A Concept Domain constraint.

In matching these constraints, the mapping process takes into consideration the fact that early constraints were all expressed as domain constraints, whereas more recent tooling and vocabulary directions have made it easier to constrain directly to value sets or codes. Thus, any reference to a "domain" for which there is currently no Concept Domain is also tested to see if there is a Value Set of the same name. If there is, this is treated as a correct reference.

In preparing a Normative Edition. an attempt is made to analyze each unique error and recommend a "resolution" for the error. These resolutions may be specific corrections, such as"Use D:ControlActReason" or a simple "Need Proposal" for cases where no appropriate target can be identified in the current vocabulary content. As noted above, over a third of the errors represented invalid expressions for which a correct target could be identified. In selected cases (a total of about 50 static model designs), these corrections were made as a "technical correction" to the Normative Edition content before publications. The requirements for making such a technical correction were:

1. All of the vocabulary reference errors for that design must be correctable with simple editing of the reference expression
2. The static model design must have been presented as "design xml" file from Visio, rather than having been processed through the design repository into an "hmd" file. (In this case, one can be sure that other design elements of the model were not affected by the correction.).
   

The following sections list message-to-message binding specifications from the dynamic models (interactions) in this package for which a target cannot be found in the current package content.

As defined in the interaction specifications of the dynamic model, HL7 static models are assembled into complete communicable models by "wrapping" models within models. Thus, a transmission wrapper surrounds a control act wrapper that surrounds a payload. These are bindings from "stubs" to their corresponding payload. In the HL7 "parallel development" environment these references are asserted by one Work Group while another Work Group is creating the target. Thus, it is necessary to check that the referenced target exists.

The incomplete bindings are presented in three categories, in declining order of severity.

1. Complete interactions from a domain but where the binding fails owing to a mismatch between the "stub" type of the wrapper, and the root element type of the target
2. Interactions that lack a pay-load, but that are probably "OK". Check documentation of interaction,
3. Incomplete interactions that lack either or both of a Transmission wrapper or ControlAct wrapper and that were probably created to illustrate a story board

The is table lists interactions from a domain that lack a pay-load, but that are probably "OK". Check documentation of interaction,

The following section lists CMET references for which a target cannot be found in the current ballot content. HL7 static models include a significant amount of "re-use" in the form of Common Model Element Type (CMET) references. In the HL7 "parallel development" environment these references are asserted by one Work Group while another Work Group is creating the target. Thus, it is necessary to check that the referenced target exists.

In the case of CMETs, there are three different sources that should agree. Specifically:

1. Every CMET should be listed in the "CMETinfo" file that defines the package of reusable artifacts from which designers can draw.
2. Each CMET must have a valid static model design, in order that its schema may be defined and linked to the schemas that refers to it.
3. Each CMET must be defined in the context of a publication database.

The CMET reference checking looks at these three sources seeking to determine that each CMET is listed in all three places, and, further, that each design that references a CMET points to one of these documented designs. The listings below show instances where a CMET is missing from one or more of these places. (NOTE: There is no test that confirms whether or not a CMET is actually referenced or used within another static model.)

This report summarizes those CMETs that are referred to in another static model, but for which there is no listing in CMETinfo. This listing includes a flag as to whether a static model for the referenced exists.

CMETs in static models are referenced with both a "name" (like "A_EncounterUniversal") and an "identifier" (like "COCT_MT010000UV"). The V3 methodology says, however, that binding to CMET stubs should be by CMET name, not identifier. This report identifies any CMET references that are suspect because their name/identifier pair used does not match a name/identifier pair in the CMET list. There are several reasons why this circumstance arises, and each such design should be reviewed and corrected. These include:

• The names mis-match because the entry was made from an incorrect CMET-info list. In this case, the generator will frequently fail to make the correct binding.
• The names mis-match because the adopted name was changed in a subsequent release of CMET-info, and the design was not updated. In this case, the generator will frequently fail to make the correct binding.
• The identifiers mis-match because a new oidentifier was subsequentluy assigned to the same design. In this case the Generator binding wis usually correct, but the hyperlink from the static model "clickable graphic" may be invalid.

The following section lists circumstances in which the package content contains a "non-serializable" static model or shows a mismatch between a static model design and a corresponding reference definition (from a Publication Database). There are variants of these errors include:

1. A static model design cannot be uniquely serialized because it contains one or more associations that are not blocked in either direction.
2. A static model design contains names (class, association or attribute) whose pattern or length are not valid and will cause the MIF representation of the model to fail schema validation.
3. A static model design exists (as part of a "Visio xml" or "hmd" file), but there is no equivalent definition in from a publication data base
4. A definition is provided in a publication data base for which there is no corresponding static model design as part of a "Visio xml" or "hmd" file
5. There is both a static model design and a definition whose base identifiers are the same (such as "REAL_MT987123UV") but where the version number (final two digits) do not match.
6. A static model design is duplicated in the submitted package and thus may cause fatal errors in the tooling when it is processed.

The following section lists files that are referenced in the specification, but which cannot be found in the appropriate directories submitted for publication; and references to external "URL"s that must be checked manually for current validity. Specificall::

1. Missing graphic and "other" support files.
2. External hyperlinks that must be checked and maintained manually. These are deprecated in the "best practices" recomended by the Publishing Work Group, because the continued validity of such links cannot be assured.

The following is a summary report for all domains in this publication as it appeared in the console output stream of the V3 Generator.