Page Comparison

...

1. This is a guided walk-through of the OpenCDS Java code base
2. The current OpenCDS Java code base is available in the opencds-parent package in bitbucket.
3. Overall approach
   1. We are using Maven for the build process, Eclipse for the development environment, and bitbucket for the source repository
   2. We view the version 1.0 release (as of January, 2012) as the initial production-capable version of OpenCDS.  There have been a half-dozen releases since then, and we are currently at 1.2.0
   3. The various sub-projects are all contained within the overall opencds-parent project.  This allows all sub-projects to be built together using the “Maven clean” and “Maven install” commands on the opencds-parent project.
   4. The following sections give a walk-through of the OpenCDS sub-projects.
4. dss-java-stub
   1. Java implementation of normative OMG Decision Support Service (DSS) specification, for SOAP Web services.
   2. Stub code, auto-generated using Apache CXF.
5. opencds-common
   1. Contains common components used throughout OpenCDS.  These include general utilities, core structural elements (e.g., for CS and CD data types), and classes for assisting with the manipulation of XML.
   2. The AbsoluteTimeDifference class is particularly useful for conducting time-based inferencing in an intuitive manner.
6. opencds-vmr-v1_0 (grouper containing following 3 modules)opencds-vmr-v1_0-schemaconfig This sub-project handles the configuration properties files
   
   1. opencds-config-api
   2. opencds-config-schema
7. opencds-decision-support-service
   
   1. This sub-project contains the XML schema for the vMR, as well as the Java classes auto-generated from the schema via JAXB.  This vMR is referred to as the external vMR.
   2. Opencds-vmr-v1_0-mappers
      1. This module contains classes to map input data from external schema format to internal java beans format, and to map output data from the internal format back into the external XML structure.
   3. opencds-vmr-v1_0-internal
      1. This sub-project contains the vMR that is used internally for knowledge authoring using the Drools Guvnor platform.  It is conceptually equivalent to the external vMR model.
      2. Introduced in the internal vMR is the notion of an OpenCdsConcept.   This approach is critical to the functioning of OpenCDS.  Essentially, it associates a code system and code (e.g., CD data type) to 0…* OpenCDS “concepts” as well as the method used to determine that the code system and code implies that concept.
         1.  Examples:
            - ICD9CM 250.00 → OpenCDS concept of diabetes mellitus
            - NDC XYZ → OpenCDS concepts of lisinopril and ACE inhibitor
         2. The use of OpenCdsConcepts enables a clear separation of concerns between terminology mapping and logic authoring.  Within Guvnor, knowledge engineers only need to worry about OpenCdsConcepts, which populate drop-down lists to facilitate knowledge authoring.
         3. The ability to specify concept determination methods is critical.  In most cases for clinical inferencing, concept mappings can be specified as using the “best available concept determination method,” which allows these mappings to be updated independently of the knowledge resources.  However, especially for quality measures that require specific, versioned mapping approaches, it allows, e.g., a concept mapping to be specified as having been determined via “HEDIS 2009”, “HEDIS 2010”, “NQF”, etc.
         4. An open, important issue is whether a single OpenCDS terminology resource could be used across OpenCDS deployments.  This would maximize knowledge re-use.
      3. This sub-project also includes several utilities, including an EnumerationUtility for loading enumerations into Guvnor, a MappingUtility to assist with conversions between the internal and external vMRs, and a LogicHelperUtility to assist with logical inferencing in Guvnor.
8. opencds-config
   1. This sub-project handles the configuration properties files
9. opencds-guvnor-support
   1. This sub-project is provided for the development of functions to be used in Guvnor
10. opencds-mgmt-interface
    1. This sub-project provides interfaces for management of the OpenCDS run-time.
11. opencds-terminology-support
    1. opencds-terminology-serivce is an abstract class that other OpenCDS sub-projects can interact with in order to obtain terminology inferencing capabilities through a common interface.
    2. opencds-simple-terminology-service
       
       1. This sub-project is a concrete implementation of the abstract opencds-terminology-service.  It provides an implementation based on XML resource files, e.g., that specify mappings between codes from standard terminologies and OpenCDS concepts.
       2. The ApelonResourceCreator class in this sub-project enables users of compatible Apelon DTSs to create the XML resource files required by the service via relevant entries in the DTS.
       3. We intend to convert to a database-driven approach to managing the terminology content currently contained in the XML resource files.
    3. opencds-apelon
       1. Contains an ApelonDtsUtility that provides convenience methods for interacting with the open-source Apelon DTS terminology server.
       2. Note that Apelon is NOT required for using OpenCDS.  The architecture allows for the use of any number of terminology servers.
12. opencds-knowledge-repository
    
    1. This module contains a repository for KnowledgeModules (aka “Rules”), OpenCDSConcept terminology mappings, and other associated information that is needed by OpenCDS at run-time.
    2. It contains methods to store and retrieve updateable information in either file-based structures or from a database.
13. opencds-decision-support-service
    
    1. This sub-project instantiates a standards-compliant DSS using the OpenCDS vMR and knowledge resources.  By default, knowledge resources are created using Drools Guvnor, but the code is designed to allow the use of other knowledge engines.
    2. Currently, only the Evaluation interface is fully implemented.  The Query and Metadata Management interfaces will be implemented as the need for them grows.
    3. The main class handling the service is DroolsAdapater.  It takes in an evaluation request, converts the external vMR into the internal vMR, and executes one knowledge base (rule) at a time.  Each knowledge base (rule) corresponds to a “package” in Drools Guvnor.  The results are then sent back to the end user.
    4. The first time a knowledge base is called, there is a few second delay as the knowledge base is loaded.  Subsequent calls are very fast due to the knowledge base already having been loaded into memory.
    Currently, knowledge bases are created in Drools Guvnor and then saved into opencds-drools-service as a .drl or .pkg resource file.  In the future, we intend to convert this to a database-driven approach to allow for hot-updating of knowledge basesinstantiates a standards-compliant DSS as a .war file that can be deployed in Tomcat or other application server using the OpenCDS vMR and knowledge resources.  By default, knowledge resources are created using Drools Guvnor, but the code is designed to allow the use of other inference engines, and other Drools technologies than Guvnor to create the knowledge resources.
    5. Currently, only the Evaluation interface is fully implemented.  The Query and Metadata Management interfaces will be implemented as the need for them grows.
    6. The main class handling the service is DroolsAdapater.  It takes in an evaluation request, converts the external vMR into the internal vMR, and executes one knowledge base (rule) at a time.  Each knowledge base (rule) corresponds to a “package” in Drools Guvnor.  The results are then sent back to the end user.
       1. The first time a knowledge base is called, there is a few second delay as the knowledge base is loaded.  Subsequent calls are very fast due to the knowledge base already having been loaded into memory.
       2. Currently, knowledge bases are created in Drools Guvnor and then saved into opencds-drools-service as a .drl or .pkg resource file.  In the future, we intend to convert this to a database-driven approach to allow for hot-updating of knowledge bases.
14. opencds-dss-components
    1. opencds-dss-drools-55-adapter - the default evaluation engine adapter furnished by OpenCDS to interface with Drools v5.5
    2. opencds-dss-evaluation - methods to determine what evaluation engine adapter is required for a given rule (e.g., opencds-dss-drools-55-adapter), and to instantiate and pass data and control to it
    3. opencds-dss-metadata-discovery - standard DSS method stub, not yet implemented
    4. opencds-dss-query - standard DSS method stub, not yet implemented
    5. opencds-dss-sample-java-engine - sample stub code for writing a simple inference engine in Java, not fully implemented.
15. opencds-guvnor-support
    1. This sub-project is provided for the development of functions to be used in Guvnor
16. opencds-knowledge-repository is intended to be expanded to an alternate optional repository using a database
    
    1. opencds-knowledge-repository-file-based
       
       1. This module contains a repository for KnowledgeModules (aka “Rules”), OpenCDSConcept terminology mappings, and other associated information that is needed by OpenCDS at run-time.
       2. It contains methods to store and retrieve updateable information in file-based structures.
17. opencds-mgmt-interface - This sub-project provides interfaces for management of the OpenCDS run-time.
    1. docs
    2. opencds-mgmt-restlet
    3. opencds-mgmt-support
18. opencds-terminology-support
    1. opencds-terminology-serivce is an abstract class that other OpenCDS sub-projects can interact with in order to obtain terminology inferencing capabilities through a common interface.
    2. opencds-simple-terminology-service
       
       1. This sub-project is a concrete implementation of the abstract opencds-terminology-service.  It provides an implementation based on XML resource files, e.g., that specify mappings between codes from standard terminologies and OpenCDS concepts.
       2. The ApelonResourceCreator class in this sub-project enables users of compatible Apelon DTSs to create the XML resource files required by the service via relevant entries in the DTS.
       3. We intend to convert to a database-driven approach to managing the terminology content currently contained in the XML resource files.
    3. opencds-apelon
       1. Contains an ApelonDtsUtility that provides convenience methods for interacting with the open-source Apelon DTS terminology server.
       2. Note that Apelon is NOT required for using OpenCDS.  The architecture allows for the use of any number of terminology servers.
19. opencds-vmr-v1_0 (grouper containing following 3 modules)
    1. opencds-vmr-v1_0-schema
       1. This sub-project contains the XML schema for the vMR, as well as the Java classes auto-generated from the schema via JAXB.  This vMR is referred to as the external vMR.
    2. Opencds-vmr-v1_0-mappers
       1. This module contains classes to map input data from external schema format to internal java beans format, and to map output data from the internal format back into the external XML structure.
    3. opencds-vmr-v1_0-internal
       1. This sub-project contains the vMR that is used internally for knowledge authoring using the Drools Guvnor platform.  It is conceptually equivalent to the external vMR model.
       2. Introduced in the internal vMR is the notion of an OpenCdsConcept.   This approach is critical to the functioning of OpenCDS.  Essentially, it associates a code system and code (e.g., CD data type) to 0…* OpenCDS “concepts” as well as the method used to determine that the code system and code implies that concept.
          1.  Examples:
             - ICD9CM 250.00 → OpenCDS concept of diabetes mellitus
             - NDC XYZ → OpenCDS concepts of lisinopril and ACE inhibitor
          2. The use of OpenCdsConcepts enables a clear separation of concerns between terminology mapping and logic authoring.  Within Guvnor, knowledge engineers only need to worry about OpenCdsConcepts, which populate drop-down lists to facilitate knowledge authoring.
          3. The ability to specify concept determination methods is critical.  In most cases for clinical inferencing, concept mappings can be specified as using the “best available concept determination method,” which allows these mappings to be updated independently of the knowledge resources.  However, especially for quality measures that require specific, versioned mapping approaches, it allows, e.g., a concept mapping to be specified as having been determined via “HEDIS 2009”, “HEDIS 2010”, “NQF”, etc.
          4. An open, important issue is whether a single OpenCDS terminology resource could be used across OpenCDS deployments.  This would maximize knowledge re-use.
       3. This sub-project also includes several utilities, including an EnumerationUtility for loading enumerations into Guvnor, a MappingUtility to assist with conversions between the internal and external vMRs, and a LogicHelperUtility to assist with logical inferencing in Guvnor.

Overview of Apelon DTS terminology service

...