Requirements-Code Systems

From HL7Wiki
Jump to navigation Jump to search

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


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


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


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