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

Difference between revisions of "Requirements-Terminology Model"

From HL7Wiki
Jump to navigation Jump to search
m
Line 33: Line 33:
 
| '' Methodology''  
 
| '' Methodology''  
 
| mif-vocabulary-model.xsd/VocabularyModel  
 
| mif-vocabulary-model.xsd/VocabularyModel  
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Terminology Models may have a number of different types of annotations
 +
|-
 +
| ''Rationale''
 +
| See rationales for individual annotations types
 +
|-
 +
| ''Implementation''
 +
|
 +
* [[Requirements-Annotations#Definition|Description]]
 +
* [[Requirements-Annotations#Usage Constraint|Usage Constraint]]
 +
* [[Requirements-Annotations#Usage Notes|Usage Notes]]
 +
* [[Requirements-Annotations#Requirements|Requirements]]
 +
* [[Requirements-Annotations#Design Comments|Design Comments]]
 +
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]]
 +
* [[Requirements-Annotations#Appendix|Appendix]]
 +
* [[Requirements-Annotations#Other Annotation|Other Annotation]]
 +
* [[Requirements-Annotations#Open Issue|Open Issue]]
 +
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]]
 +
* [[Requirements-Annotations#Change Request|Change Request]]
 +
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]]
 
|}
 
|}

Revision as of 07:03, 16 July 2009

A terminology model is a collection of terminology artifacts that, together, support defining the terminology constraints that can apply in standard specifications. The specific types of artifacts that a terminology model may contain include:

Note: The requirements for why each of the above artifacts are necessary are covered either elsewhere within this specification or in the requirements listed below.


Requirement Terminology Models need to be able to be packaged and identified as a single artifact
Rationale While made up of multiple distinct parts, there are significant dependencies between all of the aspects of a set of terminology artifacts. Specifications need to be able to easily reference the set of terminology artifacts that apply to them. The easiest way to do that is to define a single "package" containing all of the terminology artifacts that can be updated from time to time and which can be referenced either as a specific version of the package or as "the current package".
Methodology mif-vocabulary-model.xsd/VocabularyModel


Requirement Terminology models must identify any other terminology models they are dependent on
Rationale Because of the vast number of code systems, value sets, mappings and other terminology artifacts that will exist and the wide variety of organizations that create and maintain those artifacts, it is unrealistic to expect that all terminology artifacts could possibly be encompassed or published within a single model. Multiple models are inevitable. However, most models will have dependencies on contents that are in turn defined within other models. (In some cases, the dependencies may be circular). Understanding the models a given terminology model depends on is therefore essential to being able to use that model.
Methodology mif-vocabulary-model.xsd/VocabularyModel


Requirement Terminology Models may have a number of different types of annotations
Rationale See rationales for individual annotations types
Implementation