Concept mapping API
The information model mapping API can be used to return both a value concept , representing the value within that context, . The structure of the mapping module allows multiple contexts to reference a common mapping node (for example when the same type of value is received from multiple sources) and also multiple value types to be referenced from a common mapping node.
Managing codes and taxonomies
The new generation of health record management systems tend towards the recording of concepts, with the objective being for the record entry to closely match the idea behind the entry. These types of concepts can be called term based concepts as the term is the thing that describes the idea.
A modern term based concept is defined in relation to other concepts by a set of assertions indicating whether the concept is equivalent to, or a subtype of, a set of other concepts. This is normally referred to as an ontology.
Snomed-CT is the worlds largest ontology of healthcare term based concepts and is authored using a form of Description logic, which enables a reasoner to automatically classify a concept according to its properties.
The idea of codes originated from a different starting point. The intention of a coded entry is to pre-classify an entry before it is recorded. The code is designed for a particular set of business processes e.g. analytics or payment and it is important to understand the context in which a code has been used. A coded concept, being pre-classified, relies on categorisation of the codes, and that classification may or may not imply that one code is a subtype of another. Nothing can be inferred from a code other than its relation to another code as authored. Consequently, as the philosophy is different, code based concepts have to be dealt with differently from term based concepts, even if they seem to saying the same thing.
Because of their history, it is not always possible to assert the exact meaning of a code. However, it is often the case that meaning can be inferred or approximated from a coded entry. With preference to move to an ontology, this inference can be achieved via the use of a mapping process that matches coded concepts to term based concepts that are identified from a code.
These types of concepts are referred to as "legacy concepts , or non core concepts"
There are two strategies to link none core code concepts to core concepts.
1. A coded term may be stated confidently to be the same as, or a variation on, a concept. Typically code systems like Read2 or CTV3 can be dealt with in this way because they are designed to try and capture the idea in the clinicians mind, and they have been incorporated as concepts anyway. Likewise many system supplier codes have been created in this way. In this case the term code can be said to be a term code of the concept. Read2 G33 - Angina pectoris is a term code for the concept of angina pectoris.
2. A coded term might be the same term as a concept but may have been entered without the assertion that is a true representation of a state. Typically code systems such as ICD10 and OPCS fall into this category. E11 - Diabetes type 2, seems to be the same as the concept of diabetes type 2, but was entered without clinician attestation and may have been approximated for payment purposes. In this case a legacy concept is produced and a map between this concept and the similar clinical concept is generated.
A map is just another form of relationship, but unlike an ontological equivalent or subclass axiom it implies that the relationship is an approximation. It is a sort of statement that something is possibly or probably similar to something else and thus has much less weight than an asserted relationship.
Legacy Code based concepts can be mapped to Core concepts , and this enables the use of the vast volumes of data already recorded in systems. Maps must be used with care as it is almost always the case that the use of a mapped code in a query is dependent on the purpose of the query. This means that mappings are more of a guide to the things to include rather than a confident statement of meaning. When querying records the query author may need to determine which codes to include or exclude on a case by case basis.
Maps between core concepts and legacy concepts
As mentioned above the relationships are managed as mappings which state the type or degree of match.
Maps generally fall into 2 patterns. These are illustrated in the context of code based concepts as follows:
Simple match
A core concept may be matched to many code based concepts. In a simple match the legacy concept is deemed to be probably equivalent to, or a subclass of. the code concept
sn:194828000 |Angina (disorder)
:matchedTo emis:G33 |Angina Pectoris|.
Complex optional match
A concept may be matched to a number of alternative concepts and it is expected that a query author may wish to select these.
In this example, the concept : "Ketoacidotic coma due to diabetes mellitus (disorder)" has a complex map which is selection of either
a) Coma unspecified
and
b) one of either Diabetes mellitus in pregnancy: Pre-existing diabetes mellitus, unspecified, or Diabetes mellitus in pregnancy, unspecified, or Diabetes mellitus arising in pregnancy
In effect meaning that the compound entry in the record would need to have 2 icd 10 codes to fulfill the criteria.
sn:26298008
:hasMap [
:combinationOf [
:oneOf icd10:R402 ]
[
:oneOf icd10:O24.3 icd10:O24.9 O24.4]
Structural transform processes
main article Transform processes builds the narrative of the transformation pipeline using a source graph model mapped to the target graph model