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	Definition Usage Constraint Usage Notes Rationale Requirements Design Comments Stability Remarks Other Annotation Mapping Open Issue Ballot Comment Change Request Deprecation Information
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

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