Requirements-Code Systems

Code Systems are collections of related concepts and their representations and relationships maintained by a particular organization. Code systems may cover anywhere from 2 or 3 concepts to 10s of thousands of concepts. Common examples of code systems include SNOMED-CT(R), LOINC, ICD10CA, ISO country codes, etc. Where code systems covering the concepts needed for healthcare messaging are not available from other organizations, HL7 may create their own code systems to satisfy the requirement for standardized representation of coded data.

Requirement	There must be a 'short', globally unique and standardized way of referencing a particular code system
Rationale	In order to know what concept is being referenced it's necessary to know both the code and the code system. Furthermore, every application communicating must be able to recognize which code system is being referred to or they won't understand the concepts being shared.
Methodology	All HL7 code systems are identified by OIDs. Furthermore, all code systems used to communicate in HL7 Version 3 are restricted to using code systems registered in HL7's OID registry and are required to use the registered OID. (Registering new code systems is fairly straightforward.)
MIF	mif-model-vocabulary.xsd/CodeSystem/@codeSystemId

Requirement	There's a need to know if a particular code system is intended to be realm-specific or is intended to be generic
Rationale	Some code systems are intended by their construction to apply to a particular jurisdiction or area of healthcare. For example, ICD10-CA is Canadian-specific. NDC-codes are U.S.-specific, etc. When reviewing code systems it's useful to know this information and to be able to filter to include only generic code systems or code systems that are specific to particular realms
MIF Issue	At present this is not populated, but the requirement still exists.
MIF	mif-model-vocabulary.xsd/CodeSystem/@primaryRealm

Requirement	The types of relationships supported by a given code system need to be exposed.
Rationale	Code systems frequently capture relationships between concepts. Examples include "Code A" is a specialization of "Code B", "Code A" is a part of "Code B", "Code A" can be applied to "Code B", etc. "is a specialization of", "is a part of", and "can be applied to" are all types of relationships. In order to know what a code system is capable of, as well as to maintain the code system and propose additions to the code system, there's a need to know what types of relationships can exist
MIF	mif-model-vocabulary.xsd/CodeSystem/supportedRelationship

Requirement	Each type of code system relationship needs to identify the stereotypical type it corresponds to.
Rationale	The vast majority of vocabulary relationships fall into a narrow set of categories. By identifying the category, the semantics and behavior of the relationship can be exposed. In addition, categorization helps those looking at the code system to understand what it can do.
Methodology	Allowed codes are: Specializes - The child code is a more narrow version of concept represented by the parent code. I.e. Every child concept is also a valid parent concept. Used to allow determination of subsumption. Must be transitive, irreflexive, antisymetric. ComponentOf - The child code is a part of the concept represented by the parent code. Used to determine allowed nesting, for example of address components. Must be transitive, irreflexive, antisymetric. GroupedBy - The child code is a part of a grouping represented by the parent code. Used to determine navigational hierarchy not based on a specializes or component relationship. E.g. ICD9 hierarchy. Is transitive, irreflexive and antisymetric LessThan - For coded ordeinal code systems, indicates that the specified code is considered less than the related code. Used to determine relationships for coded ordinals. Must be transitive, irreflexive, antisymetric. DefinitionallyQualifies - Identifies a code that can act as a qualifier for the referenced code, both as part of concept definition within the code system and as part of run-time concept definition to determine concepts allowed for use as qualifiers for a concept within a CD datatype. Must be non-transitive, irreflexive. NonDefinitionallyQualifies - Same as definitionally qualifies, but restricted to only being used at run-time. Must be non-transitive, irreflexive. Generalizes - Inverse of Specializes. Only included as a derived relationship Component - Inverse of ComponentOf. Only included as a derived relationship InGroup - Inverse of GroupedBy. Only included as a derived relationship GreaterThan - Inverse of LessThan. Only included as a derived relationship DefinitionallyQualifiedBy - Inverse of DefinitionallyQualifies. Only included as a derived relationship NonDefinitionallyQualifiedBy - Inverse of NonDefinitionallyQualifies. Only included as a derived relationship Other - The child code has a relationship with the parent that does not follow one of the pre-defined stereotypical patterns. Any application behavior based on the relationship must be custom-coded. Transitivity, Reflexivity and Symmetry must be asserted
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/@relationshipKind

Requirement	Individual concept associations within a code system must identify what type of relationship they instantiate.
Rationale	Otherwise there's not much value in capturing the relationship types in the first place
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/@name mif-model-vocabulary.xsd/ConceptRelationship/@relationshipName

Requirement	There is a need to link supported concept relationships with their inverse
Rationale	Within a code system, associations often exist in both directions. For example "subsumes"/"subsumed by", "greater than"/"less than", "component"/"component of". Knowing this linkage allows bi-directional navigation of concepts along its various hierarchies.
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/@inverseName

Requirement	Relationship types need to have an identifier
Rationale	Some code systems, such as SNOMED, assign a concept id to the relationship types they support
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/@id

Requirement	There's a need to know whether a given type of relationship is intended to be "navigable" when browsing the vocabulary.
Rationale	Some relationships, such as subsumption and composition are expected to be navigated by users when browsing for concepts. Other types of relationships (e.g. greater than) are not usually intended to be used for browsing but only for expressing semantic relationships between concepts
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/@isNavigable

Requirement	There is a need to know the logical properties of each supported relationship type
Rationale	When using ontological tools such as OWL, it's important to know the logical assumptions that can be made based on relationships between codes. This can be used for quality checking (verifying that the relationships asserted for concepts are 'legal') as well as for decision support.
Methodology	The following logical relationships are supported: Functionalism: Indicates whether codes are limited to only one out-going relationship (functional), only one incoming relationship (reverse-functional) or both. Reflexivity: Indicates if the association always holds for a concept with itself (refexive), never holds for a concept with itself (irreflexive) Symmetry: Indicates if the relationship always holds in the reverse direction as well (symetric), never holds in the reverse direction as well (antisymetric) Transitivity: Indicates whether the relationship always (transitive) or never (antitransitive) propagates such that if the association exists from A to B and from B to C that the relationship can be inferred to exist from A to C.
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/@functionalism mif-model-vocabulary.xsd/SupportedConceptRelationship/@reflexivity mif-model-vocabulary.xsd/SupportedConceptRelationship/@symmetry mif-model-vocabulary.xsd/SupportedConceptRelationship/@transitivity

Requirement	Concept relationship types need to allow descriptions
Rationale	Every type of relationship has an intended use and a set of semantics. Not all of those can be captured by discrete metadata and therefore there's a need for ad-hoc text.
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/description

Requirement	There's a need to control the types of concepts that can be (or must be) the source or target for a particular type of relationship.
Rationale
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/description