VocMnt-Intro

Introduction to Original VML and the 2014 Extension

This document describes a formal, XML based language that can be used to create and maintain the HL7 Version 3 reference vocabulary. The immediate purpose of this language is to provide vocabulary facilitators a consistent and rigorous mechanism that can be used to specify HL7 vocabulary additions and updates. (The XML schema for this language is documented in a Zip file here.) This mechanism was to have been supplemented with graphical maintenance tools but this effort has been dropped. At present content changes included in these proposals are applied to the repository of vocabulary content in an Access data base in two ways:

1. Processing with a Java vocabulary update program first created in 2006-7, and
2. Execution of pre-defined Access update queries drawing data from source tables generated by XSLT transforms that convert the "extension" properties that have been defined (below).

The formal represntation of the vocabulary content is expressed in HL7 Model Interncange Format (MIF) files. This expression is undertaken by the RoseTree application working from the Access data base as its sole, primary source.

In this specification, a vocabulary maintenance description consists of a sequential list of parameterized function calls such as RegisterCodeSystem, AddCodes, CreateValueSet, etc. Further, the approach here is to separate the maintenance task into three separate parts:

1. Code Systems – A code system contains a set of unique concept codes. Each concept code serves as a token to represent a useful category or class as viewed from a particular perspective. The definition and organization of the tokens within a code system represents assertions about the organization of the corresponding categories and classes within a real world. A code system may also carry information about the various ways that the categories or classes are identified in different situations and languages, as well as additional defining and identifying information that serves to clarify the intended meaning of the tokens
2. Value Sets – A value set represents a list of concept codes. Value sets are used to specify a set of possible values for one or more RIM-derived coded attributes.
3. Concept Domains - A concept domain represents an abstract conceptual space that can be associated with RIM-derived coded attributes. A concept domain can be represented by one or more value sets, where each associated value set applies in a given context. Further, sub-sets of concept domains may, themselves, be represented as concept domains in a parent-child semantic hierarchy.

Each of the above parts is maintained separately, with the revisions to the code system(s) occurring first followed by changes to the value sets followed by any revisions to concept domain/value set associations that might be necessary.

VML Extension in 2013-14

Over time, it became clear that couple of functions were "missing" from the existing VML. Specifically, the ability to "update" or "remove" a property from a code. As these were required, the update to the Access tables was taken as a manually created update, which while quick was prone to errors.

Beginning about 2009, the need arose to add properties to coded concepts, value sets, concept domains, etc. that could not be documented in the structure of the Access data base. Because the existing Java-based update tool is tightly bound to the data structures of the existing data base, and because no current volunteeers were familiar with the code of the Java application, the "toolsmiths" were reluctant to change the data content existing tables. As an alternative, the extension properties were added through two sets of tables:

1. A pair of tables that treat these properties as name/value pairs, and that identify the target of these properties by their type (such as "vakueSet") and their fully qualified name. These tables are:
   • VCS_property_definition that defines the purpose and type of each if the properties represented in this fashion.

   • VCS_object_property That contains the name/value pairs and the formal identifier of the object to which they apply.

   For several years, the management of the content of these tables required manual updates to the their content in Access.

2. A pair of tables that document the version history of the value sets and code systems in the data base. Each time there is a change to a particular code system or value set, its history records will document in which release-index the change occurred, the formal published release in which the change first appeared, who made the change, and a brief summary of the changes. These data will allow proper release and version management for these code systems and value sets when these updates are completed in the second half of 2014. The tables in which the version history are documented are:
   • VOC_value_set_history. and

   • VCS_code_system_history

The VML Extension, begun in 2013 and completed (we hope) in 2014, automates the manual update processes of properties (done in 2013) and automates the capture of value set and code system hisory. In both cases it was accomplished by adding additional "process elements" to the VML. The "automation" is provided by combination of:

• ANT scripts (run from the command line)

• XSLT Transforms to split the "extensions" from the prior VML, and to create an Vocabulary Update Table that can be imported into Access; and

• Predefined update queries and programmed Visual basic For Applications (VBA) processes in Access that use the update table to change content in the appropriate vocabulary tables.

As the each VML is processed by ANT:

1. the VML file is split to isolate the "extensions" from the "traditional" VML and to create the update table from the extensions;

2. Access is activated to process the SQL-based Update and then shut down

3. The isolated traditional VML is processed to the same Access data base using the Java update program to establish the "traditional" updates.