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.

Code System

Note: The characteristics of "Code System" are the characteristics 'relevant' to HL7. Code systems may have additional characteristics not exposed or discussed here. Similarly some of these characteristics may be determined and assigned by HL7 rather than by the code system maintenance organization.

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	Code systems may have a number of different types of annotations
Rationale	See rationales for individual annotations types
Implementation	Definition Usage Constraint Usage Notes Requirements Design Comments Stability Remarks Appendix Other Annotation Open Issue Ballot Comment Change Request Deprecation Information

Requirement	There's a need to capture what concepts and codes are associated with a particular code system
Rationale	This is one of the main reasons for conveying a code system. (Note: For some external code systems, HL7 only maintains information about the code system, not the concepts.
Methodology	Concept
MIF	mif-model-vocabulary.xsd/CodeSystem/concept

Supported Relationship

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 and there's no way to validate that a relationship is following the constraints of the code system
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 be able to be linked to a concept within the code system
Rationale	Some code systems, such as SNOMED, assign a concept id to the relationship types they support
MIF Issue	Not sure why we need both id and defining concept
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/@id mif-model-vocabulary.xsd/SupportedConceptRelationship/definingConcept

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 (inverse-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. Connected: If true, indicates that for any concept it is possible to traverse (in one direction or the other) relationships of this type to reach every other concept in the code system. If false, there will be at least one pair of concepts that cannot be reached by traversing associations of this type.
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 mif-model-vocabulary.xsd/SupportedConceptRelationship/@connected

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	Some types of relationships have constraints on where they can be used. For example, a qualifier relationship of "finding site" can only originate from specializations of finding and can only have a target of specializations of body location. In other cases, an association of a given type may be mandatory on certain types of codes. For example, requiring that role class codes have an association that indicates the root allowed Entity class codes for scoper and player.
Methodology	The same mechanism used to define content for value sets is used to identify constraints on what concepts are allowed to be or required to be the source or target for a given relationship type.
MIF	mif-model-vocabulary.xsd/SupportedConceptRelationship/allowedForSources mif-model-vocabulary.xsd/SupportedConceptRelationship/allowedForTargets mif-model-vocabulary.xsd/SupportedConceptRelationship/requiredForSources mif-model-vocabulary.xsd/SupportedConceptRelationship/requiredForTargets

Supported Property

Requirement	The types of concept properties supported by a given code system need to be exposed.
Rationale	Code systems frequently capture additional metadata or semantic information about concepts. In HL7, examples include formal naming values for classCodes and typeCodes. In UCUM, they include the type of measurement a unit is for. In LOINC they include various aspects of an observation such as site and method. 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 properties can exist.
MIF	mif-model-vocabulary.xsd/CodeSystem/supportedProperty

Requirement	Individual concept properties within a code system must identify what type of property they instantiate.
Rationale	Otherwise there's not much value in capturing the property types in the first place and there's no way to validate that a property is following the constraints of the code system
MIF	mif-model-vocabulary.xsd/SupportedConceptProperty/@propertyName mif-model-vocabulary.xsd/ConceptProperty/@name

Requirement	For each type of property there's a need to know what the type constraints are on the allowed values.
Rationale	For properties to be useful, their values much meet their purpose. In addition, there's a need to be able to validate proposed changes to the code system to ensure that appropriate properties are declared and have the correct values.
Methodology	The allowed values are: boolean, enumeration, integer, real, string, token. For enumerations, the allowed enumeration values are also listed.
MIF	mif-model-vocabulary.xsd/SupportedConceptProperty/@type mif-model-vocabulary.xsd/SupportedConceptProperty/enumerationValue

Requirement	There's a need to control the types of concepts that can have (or must have) a given type of property.
Rationale	Some types of properties have constraints on where they can be used. For example, in UCUM, the indication of whether a given unit has a base of distance, mass, volume, etc. can only appear the units of measure, not prefixes (milli, kilo, etc.). In other cases, a given type of property may be mandatory for certain codes. For example, ActRelationshipType codes have mandatory properties to indicate the formal name characteristics for each direction.
Methodology	For properties that can apply everywhere, there's a simple flag to indicate whether the property is mandatory. For others, the same mechanism used to define content for value sets is used to identify constraints on what concepts are allowed to be or required to have a particular type of property.
MIF	mif-model-vocabulary.xsd/SupportedConceptProperty/@isMandatoryIndicator mif-model-vocabulary.xsd/SupportedConceptProperty/allowedForConcepts mif-model-vocabulary.xsd/SupportedConceptProperty/requiredForConcepts

Requirement	For each type of property there's a need to know what the type constraints are on the allowed values.
Rationale	For properties to be useful, their values much meet their purpose. In addition, there's a need to be able to validate proposed changes to the code system to ensure that appropriate properties are declared and have the correct values.
Methodology	The allowed values are: boolean, enumeration, integer, real, string, token. For enumerations, the allowed enumeration values are also listed.
MIF	mif-model-vocabulary.xsd/SupportedConceptProperty/@type mif-model-vocabulary.xsd/SupportedConceptProperty/enumerationValue

Requirement	When defining what properties are allowed, there's a need to be able to define default values for the properties
Rationale	A default identifies both the most expected value and also indicates what value to assume in the absence of a specified value. While it is theoretically possible to require a value for all properties, it would be extremely inefficient to do so.
Methodology	A property can have both a default as well as an indication of whether in a hierarchical code system whether the default should be taken from the property definition default, or from the nearest ancestor value defined in the subsumption hierarchy.
MIF	mif-model-vocabulary.xsd/SupportedConceptProperty/@defaultValue mif-model-vocabulary.xsd/SupportedConceptProperty/@defaultHandlingCode

Requirement	Some properties can apply not only to concepts within a code system but also valuesets that draw on that code system.
Rationale	HL7 formal naming properties need to be defined for valuesets drawn from classCodes, moodCodes and typeCodes so that classes that are bound to value sets instead of single codes can still have formally defined names.
MIF	mif-model-vocabulary.xsd/SupportedConceptProperty/@applyToValueSetsIndicator

Requirement	Concept property types need to allow descriptions
Rationale	Every type of property 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/SupportedConceptProperty/description

Supported Representation

Requirement	The types of concept representations supported by a given code system need to be exposed
Rationale	Concepts need to be referenced when capturing relationships between concepts (within and across code systems), for conveying concepts in instances (messages, documents, etc.) and exposing concepts to the user. 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 representations can (or must) exist for concepts within the code system.
MIF	mif-model-vocabulary.xsd/CodeSystem/supportedRepresentation

Requirement	Individual concept representations within a code system must identify what type of representation they instantiate.
Rationale	Otherwise there's not much value in capturing the representation types in the first place and there's no way to validate that a representation is following the constraints of the code system
MIF	mif-model-vocabulary.xsd/SupportedRepresentation/@name mif-model-vocabulary.xsd/ConceptRepresentation/@representationType

Requirement	Representation types must identify how a given representation is intended to be used.
Rationale	Concept representations may have one or more of the following uses: ConceptId: Indicates that the representation may be used for internal and external references to the concept within terminology specifications. For example when defining relationships between concepts. Code: Indicates that the representation may be used when identifying the concept as part of a transmitted or persisted instance. Display: Indicates that the representation may be used when exposing the concept to a human user. A given representation might serve multiple purposes. For example, in HL7's AdministrativeGender code system, the representation "F" for the concept of female can be used for all of the above uses - to reference the concept in concept relationships, as a code to send over the wire and as a value to expose to the user.
MIF	mif-model-vocabulary.xsd/SupportedRepresentation/@allowedUse

Requirement	Representation types must identify whether they are the preferred representation for a particular use.
Rationale	Some code systems will have multiple representations for a given use. For example, multiple display names, multiple representations that could go over the wire, etc. Users of the code system need to know which of those representations is the "default" or "most appropriate" for a given use.
MIF	mif-model-vocabulary.xsd/SupportedRepresentation/@preferredForUse

Requirement	A representation type must identify whether the representation is a string or graphic and if a graphic what kind of graphic.
Rationale	Many systems are unable to deal with graphic representations. Those that do may have limitations on what graphic formats they support. And even if they support the format, they still need to know what the format is to render it appropriately.
MIF	mif-model-vocabulary.xsd/SupportedRepresentation/@representationForm

Requirement	For string representations, there's a need to know the maximum length for that type of representation.
Rationale	Maximum lengths are useful in determining storage requirements for "transmitted" representations. They're also important for choosing among possible "display" representations based on the amount of user interface space available. Knowing that one representation is a maximum of 4 characters, another is a maximum of 15 characters and another is a maximum of 40 characters is important when considering screen real-estate.
MIF	mif-model-vocabulary.xsd/SupportedRepresentation/@maximumLength

Requirement	For each representation type, there's a need to know the expectation around the uniqueness and completeness of that representation for the concepts within the code system.
Rationale	When choosing among possible representations it's useful to know things like: Does this type of representation exist for all concepts? Might a concept have more than one representation of this type for a given language? Might multiple concepts have the same representation value? (E.g. multiple concepts sharing the same print name)
Methodology	The following characteristics are captured: Comprehensive: Indicates whether all concepts within the code system have a representation of this type. Synonymy: If true, indicates that some concepts have more than one representation of this type within a single language. Homonymy: If true, indicates that some representation values of this type appear on more than one concept.
MIF	mif-model-vocabulary.xsd/SupportedRepresentation/@isComprehensive mif-model-vocabulary.xsd/SupportedRepresentation/@hasSynonymy mif-model-vocabulary.xsd/SupportedRepresentation/@hasHomonymy

Requirement	For each representation type expressed as a string that can be used as a code or conceptId, there's a need to know the characteristics involved in comparing the representation with other representations
Rationale	For some representations, uppercase and lowercase may not be significant. For other code systems, whitespace may not be significant.
MIF Issue	This was mentioned by someone at the time the MIF was being designed, but it would be good to have specific examples of code systems that actually do either of these things.
MIF	mif-model-vocabulary.xsd/SupportedRepresentation/@isCaseSensitive mif-model-vocabulary.xsd/SupportedRepresentation/@isWhitespaceSensitive

Requirement	Concept representation types may have a number of different types of annotations
Rationale	See rationales for individual annotations types
Implementation	Definition Usage Constraint Usage Notes Rationale Requirements Design Comments Stability Remarks Other Annotation Open Issue Ballot Comment Change Request Deprecation Information

Status & History

Requirement	Code systems need to be able to track versions of that code system
Rationale	Code systems evolve. Some change every few years, some change daily. When defining expectations for interoperability, it's not always sufficient to reference a code system. Sometimes you need to refer to the code system as it existed at a particular time. Also, data captured using the code system may exist for years or decades. It's therefore necessary to know what codes were supported in the past by a code system even if they're not supported any longer.
Methodology	Each new release of a code system is treated as a "version". At present, there's an assumption that there will not be more than one release of a code system within a single day.
MIF	mif-model-vocabulary.xsd/CodeSystem/releasedVersion

Requirement	Code systems need to be able to track what supported relationships, supported properties, supported representations, concept versions, concept representations and concept relationships are supported by a particular version of a code system Any of the above items may move in and out of 'supported' state as new versions are released. I.e. deprecated codes, relationships, etc. may be 'resurrected' after they have been deprecated. Most code system elements will belong to multiple (and possibly all) code system versions
Rationale	A versioning mechanism isn't much use if you don't know what contents are supported by which versions. While it might be logical that when a given code or other code system element has been deprecated it will never come back, reality is that 'resurrections' happen on a fairly regular basis, either because the initial deprecation was in error or because evolving understanding of the terminology area causes the need for an old element to re-appear.
Methodology	Every element that can potentially be tied to code system versions (and possibly code system supplement versions) will have a repeating element showing the first version and last version it was part of as a set of consecutive versions. Multiple repetitions will be used when it is necessary to express membership in non-consecutive versions.
MIF	mif-model-vocabulary.xsd/CodeSystem/releasedVersion mif-model-vocabulary.xsd/CodeSystemVersionable/versionInfo/inVersion mif-model-vocabulary.xsd/CodeSystemVersionable/versionInfo/outVersion

Requirement	Some changes to code system elements can be scheduled to occur before or after a version transition.
Rationale	Sometimes, primarily to give implementers an opportunity to prepare, a new code, display name, relationship or other code system element may be introduced in a version but not scheduled to be 'effective' for several days, weeks or even months. Similarly, an element may be flagged for retirement at some point in the future. Again, this gives implementers an opportunity to prepare.
MIF	mif-model-vocabulary.xsd/CodeSystemVersionable/versionInfo/@effectiveDate mif-model-vocabulary.xsd/CodeSystemVersionable/versionInfo/@retirementDate

Requirement	Some elements may be published before they've actually been approved for use. They need to be flagged as draft. There's a need to differentiate when an item has been 'removed' from a code system whether it is just deprecated or is actually retired.
Rationale	Early publication of draft items allows for review of considered items or items that are "planned for submission". This allows those code system elements to be taken into account during design even if they aren't official yet. Deprecation and Retirement have different expected behaviors. Deprecated codes can still be used, though doing so is discouraged. Use of retired codes however is considered non-conformant. In addition, there may be a decision to publish deprecated code system elements but not retired ones.
Methodology	Status codes are: draft: Indicates that the vocabulary item is not yet approved and therefore should not be used in production systems. active: Indicates that the vocabulary item has been approved and may be used normally. deprecated: Indicates that the vocabulary item is no longer recommended for use and new systems/records should no longer make use of the code. However, the code should still be published and may appear in historical data or systems which have not yet converted to the superseding item(s). (A DeprecationInfo annotation should be present identifying the reason for deprecation, the effectiveDate and the superseding item(s). retired: Indicates that the vocabulary item is no longer permitted for use and new systems/records can no longer make use of the code. The code no longer needs to be published, however it and may appear in historical data. (A DeprecationInfo annotation should be present identifying the reason for deprecation, the effectiveDate and the superseding item(s)).
MIF	mif-model-vocabulary.xsd/CodeSystemVersionable/versionInfo/@status

Partioning

Requirement	There's a need to support independent publication of different portions of a single code system maintained by different groups.
Rationale	Some code systems such as SNOMED and LOINC have a delegation process where they partition part of the namespace for concept ids and codes and give authority to other groups to develop codes. These codes are maintained and published independent of the base code system but use the same OID as the base code system.
Methodology	Code system partitions are handled as if they are full code systems because they need to be published in exactly the same way and have the same sort of metadata (responsible groups, contact people, etc.) However, a code system partition will have the same OID as the base code system and will also have a codeSystemNamespaceId that together with the code system uniquely identifies the partition.
MIF	mif-model-vocabulary.xsd/CodeSystem/@codeSystemNamespaceId

Requirement	Where a code system is partitioned to allow maintenance by multiple organizations, there's a need to identify what the basis is for partitioning the code system amongst the various organizations.
Rationale	Partitioning might occur by pre-pending a string, appending a string, picking subsets of a numeric range or other mechanism. In order to understand, given a particular code or concept id, what partition it's maintained in, it's important to understand how the partitioning occurs.
MIF	mif-model-vocabulary.xsd/CodeSystem/partitionMechanism mif-model-vocabulary.xsd/CodeSystem/partition/partitionDefinition

Requirement	Where a code system is partitioned to allow maintenance by multiple organizations, there's a need to identify what partitions exist and who maintains each partition as well as where the partition can be found.
Rationale	When a code is referenced, the system receiving the code needs to validate it against the code system. In partitioned code systems, they may need to trace from the "base" code system to the partition (and perhaps even to a partition of a partition) to actually find the definition of the code. There needs to be a mechanism to allow a user to navigate through to find the code.
MIF	mif-model-vocabulary.xsd/CodeSystemPartition/@namespaceId mif-model-vocabulary.xsd/CodeSystemPartition/@responsibleGroupName mif-model-vocabulary.xsd/CodeSystemPartition/@contactInformation

Version-specific Information

The following properties may change from version to version of a code system

Requirement	It must be possible to uniquely reference a particular release of a code system It's important to know the release date of a particular release of a code system
Rationale	When constructing value sets, there's sometimes a need to make the value set specific to a particular code system release. The release date gives an idea of when the codes for a given release would first have been available and also provides a sequencing with respect to other releases.
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/@releaseDate

Requirement	It's important to know whether a particular release of a code system is approved for use by HL7.
Rationale	Some code systems may be endorsed as "approved for HL7 use"
MIF Issue	At the moment, HL7 doesn't actually approve code systems, so it's not clear if this is still needed
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/@hl7ApprovedIndicator

Requirement	There's a need to differentiate code systems maintained by HL7 and those that aren't
Rationale	HL7 publishes several code systems it doesn't maintain (e.g. MIME types, Native American Languages, etc.) When performing maintenance, it's important to know which code systems can be updated through harmonization and which can't. In addition, it's important to know whether the HL7 code system representation is the source of truth.
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/@hl7MaintainedIndicator

Requirement	There's a need to capture a code system publisher's version identifier for a particular release.
Rationale	This is useful in publication and searching. HL7 doesn't use it as a primary key because many publishers don't provide a standardized way of expressing their version ids and some don't provide version ids at all.
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/@publisherVersionId

Requirement	There's a need to know if a particular representation of a code system is complete or not.
Rationale	When maintaining external code systems, HL7 doesn't always maintain or publish a complete list. E.g. mime types, trigger event codes. In order to validate, you need to know if you're looking at the complete code system or not.
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/@completeCodesIndicator

Requirement	Code system versions may have a number of different types of annotations
Rationale	See rationales for individual annotations types. Versions have their own annotations because some may change with different versions of the code system.
Implementation	Definition Design Comments Stability Remarks Other Annotation Open Issue Ballot Comment Change Request Deprecation Information

Requirement	There's a need to know if a code system uses post-coordination and, if so, what the syntax is for post-coordinated expressions.
Rationale	Whether post-coordinated expressions are allowed or not significantly affects the process for validating codes. For regular codes, you can just do a look-up. For post-coordinated expressions, you must first parse, the expression, then look up the components, then verify the components are combined in a legal manner.
MIF Issue	The MIF doesn't have a standardized way for documenting post-coordinated expressions. For now, all expressions are captured as free text. That means that every code system (and possibly every code system version) that supports post-coordination needs to have custom code to manage the parsing and validation process.
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/postCoordinationFormat

Requirement	There's a need to know what 'official' terminology servers exist for a particular release, including what format they expose the content in.
Rationale	Particularly where HL7 is not the official source for a particular code system, it's important to know where the official source for a given version is. In addition, it's useful to know how the service exposes the content - CTS1, CTS2, MIF, some rendered format or a custom format (e.g. CSV)
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/publicTerminologyServer

Requirement	There's a need to know what languages are supported by a given code system.
Rationale	This helps in selecting code systems for use and in determining "preferred" code systems based on the language needs of users. It can also be useful for deciding if translation to a different code system will be needed and what code system should be translated to.
MIF	mif-model-vocabulary.xsd/CodeSystemVersion/supportedLanguage