Versions Compared

Old Version 24

changes.mady.by.user Daryl Chertcoff

Saved on

compared with

New Version Current

changes.mady.by.user Phillip Warner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. For each knowledgeModule, provide a way to represent in knowledgeModules.xml,indicate the Concept Determination Methods (CDMs) of interest for that particular knowledgeModule. 
    1. If no CDM is specified in the knowledgeModule.xml, mappings for all CDMs take place. (This is the Current OpenCDS behavior).
  2. If specific CDMs are specified to be applied, then only apply mappings for the specified CDMs for the knowledge module during runtime. (That is, for each runtime request, only mappings for those CDMs listed for the knowledge module will be mapped to a concept and placed on the concept/fact list.)
  3. If specific CDMs are listed for a knowledge module, one primary CDM must be specified. Primary CDMs are are always mapped, except as indicated by replacement CDMs. (PBW: Probably reading too much into this, but it sounds like you want multiple primary CDMs?  Or one and only one primary?  Would it even make sense to have multiple primaries?) (DC I was thinking one and only one primary, but I may not have thought through all the use cases.)
  4. Additive CDMs can be specified for the knowledge module. Additive CDMs ALSO get mapped in addition to the primary CDM. 
  5. Replacement CDMs can be specified for the knowledge module (if any) which will replace any mappings from the primary CDM. So if the primary CDM for a code maps to one concept but the replacement CDM maps to a different concept for that code, the concept associated with the replacement CDM is chosen.   (Note: Need to work out what to do if more than one replacement CDM is specified, or only permit one replacement CDM per knowledge module.)
    PBW: Thoughts on 5...  This is the way it will initially be implemented:
        1. Replacement will only be replacement; if a concept exists in the secondary but does not exist in the primary, the replacement is not 'added' to the map.
        2. Replacement will take a last-one-wins approach, where the last secondary CDM in the list will override all others before it, if the given concept exists in primary and other secondary CDMs which were previously specified 
            (in the list).

DC: Just to confirm the behavior for this one: when you say last-one-wins, this is only the case if more the one replacement-CDM is specified, right? Because additive CDMs would still be mapped. Thanks.

PBW: That is correct.  Also, if you have a number of ADDITIVE CDMs, and add a REPLACEMENT CDM at the end of the list, it will replace matching concepts that were added.  If you replace, then add, ADDITIVE will add the concepts the mappings.  Ordering is important.  I've also added a few docs about this; see Configuration Schemas.

Examples

Example definition of CDMs for a knowledge module

...