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

Difference between revisions of "Requirements-Concept"

From HL7Wiki
Jump to navigation Jump to search
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.


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.

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