This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Requirements-Concept"
Jump to navigation
Jump to search
CoryCasanave (talk | contribs) |
|||
Line 13: | Line 13: | ||
| '' Methodology'' | | '' Methodology'' | ||
| Refer to the [[Requirements-Code_Systems#Status_.26_History|versioning mechanism on Code System]] | | Refer to the [[Requirements-Code_Systems#Status_.26_History|versioning mechanism on Code System]] | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-Model Management}} - Versioning (A MOF or tool feature) | ||
|} | |} | ||
Revision as of 17:00, 16 June 2010
Concepts are the core structure of code systems. They define the "things" that can be communicated about as well as the granularity those things can be expressed at. Concepts may have definitions, relationships and will always have at least one representation.
Concept
Requirement | Concepts and their associated information may be versioned |
Rationale | The definitional information about a concept can change across code system versions. It's important to know exactly what the definition, intended use, relationships, properties and representations of a concept were as part of a particular code system release. |
Methodology | Refer to the versioning mechanism on Code System |
OMG Mapping | - Versioning (A MOF or tool feature) |
Requirement | Concepts may have a number of different types of annotations |
Rationale | See rationales for individual annotations types. Definition, if present, provides the semantics for the concept. |
Implementation |
Requirement | Concepts should identify how they are intended to be used |
Rationale | When a concept is represented in a code system, it has a particular intended use. Some concepts exist to be used in communication or persistence. Some concepts exist for navigation. Some exist only for analysis. Knowing how a concept is intended to be used affects application behavior. |
MIF | mif-model-vocabulary.xsd/ConceptVersion/@intendedUse |
Concept Relationship
Requirement | Concept domains must be able to indicate whether they are primary or derived |
Rationale | Many relationships are bi-directional. MIF asserts relationships as children of one of the concepts. Therefore a relationship only needs to be specified in one direction. The other is derivable. Derived information gets stripped out of formal representations to avoid duplication and the potential for inconsistency, however it is frequently included in versions produced for publication. |
MIF | mif-model-vocabulary.xsd/ConceptRelationship/@isDerived |
Requirement | Concept relationships must identify both source and target concepts |
Rationale | Otherwise, you don't actually have a relationship . . . |
MIF | mif-model-vocabulary.xsd/ConceptRelationship/targetConcept |
Requirement | Concept relationships may have properties |
Rationale | Some relationships need to capture additional information. For example, the relationship between two units in UCUM includes a multiplier to indicate the conversion factor |
MIF | mif-model-vocabulary.xsd/ConceptRelationship/property |
Concept Property
Requirement | Concepts can have properties |
Rationale | Properties convey additional metadata that may be needed for filtering or enforcing rules when using the concept. HL7 has properties for defining formal names, sorting, etc. |
MIF | mif-model-vocabulary.xsd/ConceptVersion/property |
Concept Representation
Requirement | Concepts must have representations |
Rationale | A concept that cannot be referenced in any way is not useful. Therefore concepts require at least one representation that can function as a concept id. To communicate over the wire, a code representation is also required, and to expose the concept to the user, there needs to be some sort of rendering representation as well |
MIF | mif-model-vocabulary.xsd/ConceptVersion/ConceptRepresentation |
Requirement | Concept representations need to be able to identify what language they're in. |
Rationale | Any 'display' concept representation that has a string form is likely to be language specific. Code systems may have distinct representations for different languages. If you don't know what language a representation is for, it's difficult to choose the most appropriate one for a given user. |
MIF | mif-model-vocabulary.xsd/ConceptRepresentation/@language |
Requirement | Concept representations need to be able to identify whether they are the "preferred" representation for their language |
Rationale | Some code systems will have multiple representations of a particular type in a single language. In circumstances where only one representation can be displayed, it's important to know which one that should be. |
MIF | mif-model-vocabulary.xsd/ConceptRepresentation/@preferredForLanguage |
Requirement | "Print name" concept representations sometimes need to be bound to specific "Code" representations within a single concept |
Rationale | For example, in the Canada Post code system for directions, the concept for "direction 270 degrees from north" has two representations of one representation type (conceptId, code & display): "W" and "O" and two representations of a second representation type (display): "West" and "Ouest". There is a need to indicate that the "West" representation is associated with the code representation "W" and the "Ouest" representation is associated with the code representation "O". |
MIF | mif-model-vocabulary.xsd/ConceptRepresentation/representsCode |