...

One of the features of interest for a future version of OpenCDS is the ability to "hot deploy" new knowledge bases (e.g. - codes, concepts, drools rules, and supporting data) as needed without having to restart OpenCDS for the changes to take place. ICE, an application based on OpenCDS, envisions the following automated knowledge deployment capabilities within OpenCDS to support the operation of ICE. However, we also believe that the proposed functionality is generic and would benefit any OpenCDS-based services. For purposes of this discussion document, we will talk about the scenarios with respect to ICE for complete understanding of the requirements, and then abstract the requirements afterwards.

• ICE is immunization forecasting software; the customizable rules are written in software called the CDS Administration Tool (CAT).
• CAT manages - and can deploy to OpenCDS - the following artifacts, all of which are can be represented files stored in OpenCDS XML filesthe OpenCDS knowledge-repository-data file structure:
  • OpenCDS concepts    (resourceAttributes/supportedConceptsConfigFile.xml)
  • Code to OpenCDS concepts mappings    (conceptMappingSpecifications/manualMappings)
  • Knowledge Modulesmodules; Scoping Entity ID, /Business ID, Version/Version    (resourceAttributes/knowledgeModules.xml)
  • Code System Code List    (resourceAttributes/OpenCDSCodeSystems.xml)
  • Drools Artifacts (DSLs, DRLs, DSLRs)
• CAT also manages the following non-XML deployable artifacts to OpenCDS (they information that are represented in OpenCDS by some other means or indirectlyindirectly or in memory):
  • Supporting Data Drools Artifacts (DSLs, DRL and DSLR   (in-memory data that is cached by a knowledgeModule, such as immunization schedule parameters)
  • Concept Determination Method (not directly deployable to OpenCDS but contained in code->concept mapping files)
    
    

Supporting data is any kind of data that is cached in instances of Java classes for the knowledge module at by the knowledgeModule during runtime operation. OpenCDS has the infrastructure to support the cached data (see Deployment Scenarios below).

• For ICE, most of the cached data is stored in various Map classes that are accessed by the rules. Examples include table of static data related to vaccine, etc., and static values such as recommended ages and intervals. The cached data is not modified during execution and remains in memory for as long as the knowledge module is in memory by OpenCDS.

Deployment Use Case Scenarios

To start, I propose supporting the following "hot" deployment scenarios to OpenCDS. All proposed functionality is For those functions at the level of a knowledge module (i.e. - associated <scoping, the knowledgeModule is defined by its associated <scoping-entity>/<businessId>/<version>). That is, the OpenCDS web service should have the following capabilities for deploying knowledge to OpenCDS.

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 directory.
3. 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. OpenCDS provides the ability to:
   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 knowledgeMofule
   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. Ability to add/replace all above artifacts listed above replacing all knowledge associated with a specified <scoping-entity>/<businessId>/<version>. 
   
   

...

Revisions to OpenCDS Concept Determination Method

Initial Document Here.

The initial document (authored by Dave Shields) with some proposed solutions for new features for Concept Determination Method handling in OpenCDS is in the link above.