This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Requirements-Terminology Model"
Jump to navigation
Jump to search
EdSeidewitz (talk | contribs) |
|||
(3 intermediate revisions by 2 users not shown) | |||
Line 21: | Line 21: | ||
| '' Methodology'' | | '' Methodology'' | ||
| mif-vocabulary-model.xsd/VocabularyModel | | mif-vocabulary-model.xsd/VocabularyModel | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-HL7 Profile}} Stereotyped UML Package. | ||
|} | |} | ||
Line 31: | Line 34: | ||
| 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. | | 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. | ||
|- | |- | ||
− | | '' | + | | '' MIF'' |
| mif-vocabulary-model.xsd/VocabularyModel | | mif-vocabulary-model.xsd/VocabularyModel | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-HL7 Profile}} UML already provides for importing of packages. However, such importation is necessary only to make names within the imported package visible without qualification -- it is allowable to reference elements within a package without importing it. Nevertheless, stereotyped UML import relationships could be used to represent the above HL7 dependencies. | ||
+ | |} | ||
+ | |||
+ | |||
+ | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
+ | | '''Requirement''' | ||
+ | | When persisting or exchanging a representation of a terminology model, there are various degrees of detail that may need to be exposed and the persisted artifact needs to indicate what level of representation is present. | ||
+ | |- | ||
+ | | ''Rationale'' | ||
+ | | Some terminology models may be intended for "publication" and therefore provide a more limited view. Others will have been constrained to only show a subset of the artifacts that exist within the model. It's important when looking at a given model representation whether you're looking at the "whole thing" or only a subset. | ||
+ | |- | ||
+ | | ''Methodology'' | ||
+ | | Possible levels are: | ||
+ | * complete: Indicates that the content of the model rendition represents a complete definition of the vocabulary artifacts present within that model. | ||
+ | * partial-validation: Indicates that the content of the model rendition represents a subset as required for validation of static model definitions. This representation may include artifacts defined within other models rather than referencing them as dependent models for simplicity of exchange. | ||
+ | * partial-publishing: Indicates that the content of the model rendition represents a subset as required to expose the vocabulary model for publishing | ||
+ | * partial-implementation: Indicates that the content of the model rendition represents the subset needed to perform implementation of a particular set of static artifacts. This representation may include artifacts defined within other models rather than referencing them as dependent models for simplicity of exchange. | ||
+ | |- | ||
+ | | '' MIF'' | ||
+ | | mif-vocabulary-model.xsd/VocabularyModel/@definitionKind | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-HL7 Profile}} Tagged value on a Package stereotype. | ||
|} | |} | ||
Line 57: | Line 85: | ||
* [[Requirements-Annotations#Change Request|Change Request]] | * [[Requirements-Annotations#Change Request|Change Request]] | ||
* [[Requirements-Annotations#Deprecation Information|Deprecation Information]] | * [[Requirements-Annotations#Deprecation Information|Deprecation Information]] | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-HL7 Profile}} Tagged values on a Package stereotype. | ||
|} | |} |
Latest revision as of 21:44, 15 June 2010
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:
- Concept Domains
- Code Systems
- Value Sets
- Binding Realms
- Context Bindings
- Code Translations
- Code System Supplements
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 |
OMG Mapping | Stereotyped UML Package. |
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. |
MIF | mif-vocabulary-model.xsd/VocabularyModel |
OMG Mapping | UML already provides for importing of packages. However, such importation is necessary only to make names within the imported package visible without qualification -- it is allowable to reference elements within a package without importing it. Nevertheless, stereotyped UML import relationships could be used to represent the above HL7 dependencies. |
Requirement | When persisting or exchanging a representation of a terminology model, there are various degrees of detail that may need to be exposed and the persisted artifact needs to indicate what level of representation is present. |
Rationale | Some terminology models may be intended for "publication" and therefore provide a more limited view. Others will have been constrained to only show a subset of the artifacts that exist within the model. It's important when looking at a given model representation whether you're looking at the "whole thing" or only a subset. |
Methodology | Possible levels are:
|
MIF | mif-vocabulary-model.xsd/VocabularyModel/@definitionKind |
OMG Mapping | Tagged value on a Package stereotype. |
Requirement | Terminology Models may have a number of different types of annotations |
Rationale | See rationales for individual annotations types |
Implementation | |
OMG Mapping | Tagged values on a Package stereotype. |