Page Comparison

...

Note: For each of the below, we talk about the OpenCDS capability with respect to its XML representation in OpenCDS v1. However, this list is not meant to describe the solution via the as XML - just to describe the functionality. (e.g. - if the data in these files are represented in some other way in future versions of OpenCDS, the functionality requested is the same.)

• 1. Code Systems
     1. Replace entire OpenCDSCodeSystems.xml file.  (Q: Is this still used somehow? We are using code systems not specified in this file and all still seems to work ok. If not, nevermind.)
  2. Concepts and Codes
     
     1. supportedConceptsConfigFile.xml:
        1. FOR DEPLOYMENT: Replace the entire supportedConceptsConfigFile.xml file
        2. FOR DEPLOYMENT: Add/Update/Delete individual entries in the supportedConceptsConfig.xml file
     2. Concept Mapping Files
        1. FOR DEPLOYMENT: Add/Replace all mapping files in the conceptMappingSpecifications/manualMappings or conceptMappingSpecifications/autoGeneratedMappings directory.
  3. BPMNs/DSLs/DRLs/DSLRs
     1. FOR DEPLOYMENT: Replace all DSLs/DRLs/DSLRs associated with a specified knowledgeModule at once
  4. Supporting Data. (The supporting data will be supplied to OpenCDS as an XML (or some other type of) document, and it is up to the knowledgeModule implementer to write the necessary routines to read in the document contents into its custom Java instance objects.) 
     1. FOR DEPLOYMENT: Replace the entire contents of the Supporting Data into the necessary persistence mechanism - likely files, as with artifacts - associated with a specified knowledgeModule at once. 
     2. FOR RUNTIME: Provide the knowledgeModule author a routine for adding the in-memory contents to the global OpenCDS cache, which associates one-and-only-one in-memory supporting data object with a knowledgeModule
     3. FOR RUNTIME: Provide the knowledgeModule author a routine for removing the in-memory contents for a knowledgeModule from the global OpenCDS cache
     4. FOR RUNTIME: Provide the knowledgeModule author a routine for checking if in-memory contents exists for a knowledgeModule from the global OpenCDS cache
        
        
  5. Initial functionality will not support the automated modifications to the knowledgeModule.xml or openCdsExeuctionEngines.xml files; these files can continue to be modified manually as they will rarely change. 

...

The initial document (authored by Dave Shields) with some proposed designs for new features for Concept Determination Method handling in OpenCDS is in the link above. The proposed functionality is a simplification of little simplified from what is in the document.

ICE would like to support the following functionality now - configurable at the knowledge module level:

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 additive or replacement CDMs).
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.) 

...

• ICE 1.0.0 will instantiate concepts for any codes for across all CDMs within the OpenCDS mapping files. 
• ICE 1.0.1 will only map codes->concepts specified by the "NYCICESchedule-Primary" CDM only
• ICE 1.0.2 will map codes->concepts specified by the NYCICESchedule-Primary, additional code->concepts for those mappings specified by "NYCICEShedule-Schools" and "NYCICESchedule-NewFeature". Additionally, any codes that have mappings in both "NYCICESchedule-FIX" AND "NYCICESchedule-Primary" will only be mapped to concepts as specified by the "NYCICESchedule-FIX" mappings; the "NYCICESchedule-Primary" code->concepts for those overlapping/same codes will not be applied.

For example, for the below are 4 mapping files.

...

, the proposed functionality would work as follows:

• org.nyc.cir.ICE.1.0.0 will apply all the concept mappings. The Drools Concept list will contain MMR, Measles, Mumps and Rubella.
• org.nyc.cir.ICE.1.0.1 will only apply the first mapping, and therefore the Drools Concept List will only contain MMR.
• org.nyc.cir.ICE.1.0.2 will only apply the last 3 mappings, and therefore the Drools Concept List will contain Measles, Mumps and Rubella, but not MMR.
  
  

<?xml version="1.0" encoding="UTF-8"?>
<OpenCdsConceptMappingSpecificationFile>
 <specificationNotes>Created manually.</specificationNotes>
 <openCdsConcept code="MMR" displayName="MMR"></openCdsConcept>
 <conceptDeterminationMethod code="NYCICESchedule-Primary" displayName="Best available OpenCDS concept determination method"></conceptDeterminationMethod>
 <membersForCodeSystem codeSystem="2.16.840.1.113883.12.292" codeSystemName="Vaccines administered (CVX)">
 <CD code="03" displayName="MMR" />
 </membersForCodeSystem>
</OpenCdsConceptMappingSpecificationFile>

...