Requirements-Concept

From HL7Wiki
Jump to navigation Jump to search

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.