Page Comparison

...

• 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. PBW: Yes, this is still actively used (there are other places, but they're currently unused and will become deprecated): when building the OpenCDSConcepts and CDs–to get the code system from the OID (via a cached map) provided in the concept mappings..)
  2. Concepts and Codes
     
     1. supportedConceptsConfigFile.xml: (PBW: The contents of this file are unused in the current release candidate–1.2.0.RC1.)    (DC: Without this file, how are the Concept Types loaded on to the fact list, i.e. - is it a ProblemConcept, ImmunizationConcept, etc.)
        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 (See below wrt CDM)
        1. FOR DEPLOYMENT: Add/Replace all mapping files in the conceptMappingSpecifications/manualMappings or conceptMappingSpecifications/autoGeneratedMappings directory. (PBW: Would you want to add/replace all or be able to pick/choose which ones to replace, or add new concept mappings independently of all other mappings?) 
  3. BPMNs/DSLs/DRLs/DSLRs (Knowledge Module – by scopingEntityId, businessId, version)
     1. FOR DEPLOYMENT: Replace all DSLs/DRLs/DSLRs associated with a specified knowledgeModule at once (PBW: All or nothing or piecewise?)  (DC: All or nothing by knowledgeModule; replacing all in one knowledgeModule would not affect another KnowledgeModule)
  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.  PBW: My thought is that it will be an opaque data set–hence whether it is XML or some other document or binary file, it will (should?) be handled, likely, as a byte array. In this case, however, it might make sense to provide additional metadata for the KM implementer to be able to know what type of data exists in the byte array.  Thoughts?) 
     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 (PBW: Which is to say that you want the ability to add/remove/update the SD independently of the KM?  Which implies the KM must first exist in OpenCDS Configuration before adding the SD?)  (DC: that's correct... the SD would be independent of the knowledgeModule, but the SD would have be "linked" to the knowledgeModule. The author would basically be indicating "this SD goes with this  KM". So the knowledgeModule must first exist as you said.)
        2014-09-19 PBW: Is it possible that the SD could be leveraged by multiple knowledge modules?  I'm currently thinking about a plugin system (as we discussed during our last call), where not only the plugin, but SD could potentially be used by multiple knowledge modules.  Thinking about it this way allows me to consider loading a plugin and supporting data (the latter loaded into a cache by a plugin) at a higher level–the same level as the KMs and the CDMs, etc., such that the system only loads an instance of the plugin (and hence SD) for all KMs versus loading the same for each KM.
        DC: 2014-09-24: Yes, I could definitely see the supporting data being used by more than one  Knowledge Moule, and therefore the SD could be loaded in at the plugin level. So this would essentially mean the same plugin could be used by different knowledge modules as well. Is this the design consideration you were intending to decide on?
        2014-09-24 PBW: Yes, that's the path I'm considering.  To that extent, could an instance of SupportingData be used by multiple plugins?
        2014-09-24 DC: I suppose an instance of the supporting data could be used my multiple plugins, but my question would be under what circumstances we envision this would be used. What is the likelihood that different knowledge modules would need the same supporting data instance but use different plugins? Is this to accommodate if - for example -  the knowledge modules used a different set of globals? Also, perhaps related to this, I don't understand what the purpose of the PluginPackage is. Hope this is helpful.
        
     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. (PBW: In the general use case, the KMs may be updated frequently–particularly in the case of active development of rules.) (DC: Would be great to be able to have this automated too... I was just suggesting this is a lower priority.)

...