This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "VocMnt-Intro"

From HL7Wiki
Jump to navigation Jump to search
Line 11: Line 11:
  
 
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.
 
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.
 
----------------------
 
 
<div id="Nt1">'''Not exposed in application'''</div>
 
:Capability that is listed as '''Not exposed in application''' are functions that are not (as of this writing) supported by the Harmonization Tooling application.
 
<div id="Nt2">'''Not fully exposed in application'''</div>
 
: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.
 
<div id="Nt3">'''Exposed under VS in application'''</div>
 
: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
 
<div id="Nt4">'''Concept Domain'''</div>
 
: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".
 

Revision as of 05:44, 27 September 2007

Introduction

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. This mechanism will be supplemented with graphical maintenance tools that may partially or completely replace this language as the primary form of input. As this occurs, it is anticipated that the language specified here will evolve a form that will be used to record and transmit vocabulary changes between systems and tools.

This specification takes a different approach to vocabulary maintenance than that of its Excel-based predecessor. One of the major differences is that this language is procedural vs. table-driven. A vocabulary maintenance description consists of a sequential list of parameterized function calls such as RegisterCodeSystem, AddCodes, CreateValueSet, etc.

A second major difference between this approach and its predecessor is the underlying model. The Excel-based maintenance system blurred the distinction between value sets, concept codes and concept domains. The approach taken in this document 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 (4) – 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.