Mapping and Fuzzy Matching Tool

Grace put together an awesome slidedeck and video on what a Mapping Tool that utilizes fuzzy matching might look like inside OCL. Since this is a big topic with lots of potential requirements, it’s a perfect place to kick off a discussion…

Part 1: Loom | Free Screen & Video Recording Software | Loom
Part 2: Loom | Free Screen & Video Recording Software | Loom

Original Slides:

Some early feedback:

  1. The maps might not be just from one target source, so it is more like a list of preferred sources.
  2. The absolute key thing is to be able to see the candidate matches before you select one. The correct one might not be the one that the algorithm brings to the top (and frequently is not).
  3. Certain things are more important than the text, such as the class of concept. You don’t want to map a question concept to a finding, for example.
  4. Sometimes the maps on the source concept are more important than text. For example, if I know that my source has a correct map to SNOMED, but I need a CIEL code, then which CIEL codes are mapped to that SNOMED (part of the matching algorithm).
  5. Finally, and this is probably an educational issue, when someone wants to get to a concept, they may actually want to get to a code. For example, all CIEL diagnosis codes should be mapped to ICD-10-WHO (including the respiratory concepts mentioned in the video). CIEL maps CLINICALLY-FRIENDLY TERMINOLOGY one-by-one to to ICD-10-WHO codes. The source concept may match CIEL exactly, but is nowhere in ICD-10. You would want to map to CIEL and use CIEL to get to the ICD-10 code. This is what an interface terminology was intended to do. We need to help people to understand this when they are trying to map their dictionaries…

I think you captured my feedback, Jon

1 Like

I haven’t watched the videos, but I would suspect that seeing the matching algorithm’s “score” is also relevant, and I would presume from some previous work that you could assign different default end-user behaviors for various thresholds:

For example:

Above high threshold → no need for human review, as specificity is high and false matches are uncommon
Between low and high threshold → present human with potential match(es) and provide UX for them to select from those choices or alternates
Below low threshold → present UX that allows user to manually review master list and manually match in a UX-optimized method… (because the options presented are most often incorrect)