Mapping and matching concepts

From Discovery Data Service
Revision as of 08:18, 6 April 2021 by DavidStables (talk | contribs)
Jump to navigation Jump to search

Historical background

Information consists of ideas. Another word for an idea is a 'concept' . A concept may be named,( in which case the meaning of the concept can usually be understood), or they may be an unnamed expression, which is made up of a set of interrelated named or unnamed concepts.

For example the term "chest pain" implies the idea of a pain in the chest. In Snomed-CT it is a named concept. "Chest pain, worsened by exercise" may be an example of an expression style concept made up from the concept of "chest pain", and the statement that it is "made worse by -> exercise". In this case “made worse by” and “exercise” are both different concepts but no author has yet created a single named concept for this expression.

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. The standard approach to this is via the use of Description Logic (DL). By using DL, a computer can automatically classify a concept which can result in a computer deducing additional knowledge over and above the human who created the concept. Snomed-CT is the worlds largest ontology of healthcare term based concepts. A collection of concepts defined in this way constitute an "Ontology".

Coded concepts originate 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. A coded concept, being pre-classified, relies on categorisation of the codes, which may or may not imply subtypes. 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 based concept. However, it is often the case that meaning can be inferred or approximated from a coded entry. This inference is achieved via the use of maps.

A map is just another form of relationship, but it implies that the relationship is an approximation. It is a sort of statement that something is possibly or probably similar to something else. It has much less weight than an asserted relationship.

Code based concepts can be mapped to term based 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.

Code relationships to terms

As mentioned above the relationships are managed as maps.

Maps generally fall into 4 patterns. These are illustrated in the context of code based concepts as follows:

  • Simple match. A concept may be matched to one concept, the mapping having a certain weighting or category. For example the icd10 code for Angina may have a map which maps to the single term based Snomed-CT concept of angina, with a category indicating that the source concept is properly classified. Note that many coded concepts may be mapped to one single term based concept. The map is viewed from the perspective of the coded concept.
icd10:I209 |Angina Pectoris (ICD10 I20.9)|
            :matchedTo sn:194828000 |Angina (disorder),
                    :mapCategory sn:447637006 |Map source concept is properly classified]
  • Complex union match A concept may be matched to a number of alternative concepts and different categories of matching may apply. In other words more than one optional matching category and more than one optional target concept within it.
icd10:E140| Unspecified diabetes mellitus with coma
           //This maps to a number of potential  target concepts
  :matchedTo : [owl:UnionOf 
                 [owl:UnionOf
                   sn:26298008|Ketoacidotic coma due to.....,
                   sn:421725003|Hypoglycemic coma due to diabetes mellitus],
                    [:mapCategory  sn:447637006 |Map source concept is properly classified],
            
             //This map is dependent on the context this map is used in
            sn:267384006 |Coma due to hypoglycemia|,
            [:mapCategory sn:447639009 |Map of source concept is context dependent] ].
  • Complex intersection source match A combination of concepts may be matched to a single target concept (e.g. A and B matches C) implying that the meaning of C should include all of the source concepts.
owl:Intersectionof  
  [
   owl:UnionOf 
     opcs:H029| Unspecified other excision of appendix (OPCS49 H02.9),
     opcs:H021 | Interval appendicectomy (opcs49 H02.1),
     opcs:H028  Other specified other excision of appendix(opcs49 H02.8)],
   [
     owl:UnionOf 
      opcs:Y752 | Laparoscopic approach to abdominal cavity NEC (opcs49 Y75.2),
      opcs:Y755 |Laparoscopic ultrasonic approach to abdominal cavity (opcs49 Y75.5)
   ]

:matchedTo sn:6025007 |Laparoscopic appendectomy (procedure)|


In other words a combination of one of the appendix excision OPCS codes and laparoscopic codes matches to the Snomed-CT concept of laparoscopic appendectomy