This wiki has undergone a migration to Confluence found Here
Requirements-Concept
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 | |
OMG Mapping | These can be added on as profile tagged values |
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 |
OMG Mapping | Some of the existing UML profile elements exist (such as entity) others can be added in the HL7 profile |
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 |
OMG Mapping | Associations in UML are not, in general, directional but where they are the "other end" can be derived. UML has the concept of a derived property or one way association but that doesn't seem to be what is being asked for. This seems to be a a requirement for mapping to an exchange format such as XMI to only store "one end". XMI does not have that feature for binary relations. |
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 |
OMG Mapping | This is the standard UML association (which can have any number of ends) |
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 |
OMG Mapping | This is a UML association class |
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 |
OMG Mapping |
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 |
OMG Mapping | All MOF objects have a UUID |
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 |
OMG Mapping | UML does not provide good suppot for multi-lingual models due to "named element" and other metemodel issues. |
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 |
OMG Mapping | UML does not provide good suppot for multi-lingual models due to "named element" and other metemodel issues. |
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 |
OMG Mapping | UML does not provide good suppot for multi-lingual models due to "named element" and other metemodel issues. |