Vocabulary Maintenance Language (Object Property Management)

Introduction

Proposal

Code System

Value Set

Domain

Properties

Appendices

Overview ··· CreateDomains · (Re)defineDomain · RenameDomain · MoveDomain · DeleteDomain 

Object Property Revision

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 a sets of tables.

This pair of tables that treat these properties as name/value pairs, and that identify the target of these properties by their type (such as "valueSet") 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.

The VML Extension, undertaken in 2013, automates the manual update processes of these properties (done in 2013). This is accomplished with the VML Extension elements discussed here. The object property revision process is used to create add, remove and replcae propertied on vocabulary objects, as well as to declare the completion of a vocabulary release that is ready for final publication.

The elements beneath objectPropertyRevision are considered in the following sub-sections.

Add Property to Object

A property may be added to any of a set of vocabulary "objects". To be fully useful, any new property should be defined in the object property definition table in the Access data base. These additions are made with manual updates to the Access table. Properties may be added prior to the recording of the dewfinition, but the representaion in MIF and vocabulary publication will be incomplete, displaying a definition as "I haven't a clue!" .

The child element, propertyValue, is required. The text within this element is the value of the property being assigned.

objectType	The type of the object to which the property will be added. The currently acceptable object types are listed in separate table below.
objectId	The identifier (typically the name) of the object to which to add the property.
propertyName	The name of the property being added.
propertyStatus	The intended status for the property. This is optional and will default to a value of "active" if left blank.

objectType Values

relInclusion	Meaning
conceptDomain	The property name will select from the defined Concept Domains in the vocabulary.
codeSystem	The property name will select from the defined Code Systems in the vocabulary.
valueSet	The property name will select from the defined Value Sets in the vocabulary.

Remove Property From Object

Once added, a property may be removed from its targeted vocabulary "object".

objectType	The type of the object from which the property will be removed.
objectId	The identifier (typically the name) of the object from which to remove the property.
propertyName	The name of the property being removed.

Replace Property on Object

Once added, a property may be replaces (updated) on its targeted vocabulary "object". The difference between replace and a simple update is that the old value will be retained in the data base with a status of "replaced".

The child element, propertyValue, is required. The text within this element is replacement value for the property being assigned.

objectType	The type of the object for which the property will be replaced.
objectId	The identifier (typically the name) of the object for which to replace the property.
propertyName	The name of the property being replaced.

Close Vocabulary Release

Closing a vocabulary release is semantically the assignment of a property "closed=true" to a vocabulary release that has been in development. Each vocabulary release (starting summer of 2014) will have a release identifier, like 2014T2 (for harmonization during the second trimester of 2014) and release date (typically the day before the ballot opens during that trimester).

From the time the first Harmonization proposals come in, the VML will prepared with that release identifier as their target. Although informal releases, like those for QA review, will occur, they will not be circulated as a formal release, and the version dates on new content will be dependent upon the date the VML proposal was prepared.

At the time that the Vocabulary and MnM co-chairs conclude that all content is complete, has been checked and that any needed technical corrections have been made, they will use a VML file with closeVocabularyRelease as its only processing element. This will close the release.

When this element is processed, the "proposal" date will be set to the release date. As a consequence, when each of the value sets and code systems that were created or altered during that cycle are processed to MIF, the logic will advance their history meta-data records to that identifier, and their version dates will be set to the release date.

objectType	This required attribute has a fixed value of vocabulary.
action	This required attribute has a fixed value of closeRelease.
closeAsOfRelease	This optional attribute has a default value of releaseId, and this value should be used exclusively. It asserts that the "releaseId" specified in the VML Processing Widget properties will be assigned to all "open" (under process in this cycle) code systems and value sets. The impact of providing an alternate value is unpredictable, because the logic of closing a release is dependent upon the assessment of release dates determined in several places and throughout the weeks over which the content was developed and posted.

Jump to top of page

---

Not exposed in application

Capability that is listed as Not exposed in application are functions that are not (as of this writing) supported by the Harmonization Tooling application.

Not fully exposed in application

Capability that is listed as Not fully exposed in application represents a set of capabilities, some, but not all of which is implemented in the Harmonization Tooling application.

Exposed under VS in application

Code System capability that is listed as Exposed under VS in application are functions that cannot be invoked directly, but that are present in processing value set changes on Value Sets whose Code System is established by a previous binding

Concept Domain

The term Concept Domain was formally adopted by the HL7 Vocabulary Technical Committee as the name for an abstract conceptual space that may be represented by (bound to) a set of concepts found in one or more specific code systems. Previous to this adoption, the preferred name for the same abstract conceptual space was Vocabulary Domain. In editing this document, the term "vocabulary domain" has been replaced with "concept domain", except where the term is part of the XML schema. In order to avoid "breaking" software tools that were built to the previous version of the schema, the XML attribute and element names retain the phrase "vocabularyDomain".