Page Comparison

...

Last updated April 21, 2011 by Ken Kawamoto

Last updated November 21, 2011 by David Shields

Last updated June 25, 2014 by David Shields

Document purpose:

1. To provide an overview of the current components of OpenCDS

...

1. For a big-picture overview of the OpenCDS approach, please see http://opencds.org/see OpenCDS Home, and in particular the sub-sections on Architecture, Key Components, and References.
2. For instructions on how to download and install these resources, please see other relevant documentation in the Project Documents section.
3. OpenCDS version 1.2.0 x is intended to support production deployment.  Certain capabilities needed for production deployment (e.g., hot-updating of knowledge bases) will be implemented in this release.

...

1. The current OpenCDS vMR version 1.0 Domain Analysis Model (DAM) and logical data model is available in the opencds-documentation package in SVN, under SoftwareDevelopment\Modelsare available at 
   1. http://develop.opencds.org/OpenCDSProjectDocs/latest/HL7vMR_vMR_Domain_Analysis_Model_2011_Sept_Ballot.pdf
   2. http://develop.opencds.org/OpenCDSProjectDocs/latest/vMR_DAM_R2.zip (this is vMR 1.0 with minor corrections, not the HL7 balloted vMR 2.0)
   3. http://develop.opencds.org/OpenCDSProjectDocs/latest/vMR_DAM_R2.EAP (this is vMR 1.0 with minor corrections, not the HL7 balloted vMR 2.0)
2. Its primary content is vMR_DAM.eap, which is an Enterprise Architect UML model for the HL7-balloted vMR.
3. The version 1.0 vMR is based on the HL7 CCD and the HL7 clinical statement pattern.
4. The vMR logical data model is expressed within OpenCDS by both
   1. an external schema which is designed to support interfaces with be populated from either structured data (such as CCD) or relational data (such as from an enterprise data warehouse), and
   2. an internal java beans structure which is optimized for use within Drools fact lists.

...

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 SVNbitbucket.
3. Overall approach
   1. We are using Maven for the build process, Eclipse for the development environment, and SVN bitbucket for the source repository
   2. We view the version 1.0 release (as of April 2011January, 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)
   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  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 casecases 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.
7. opencds-apelon
8. Contains an ApelonDtsUtility that provides convenience methods for interacting with the open-source Apelon DTS terminology server.
Note that Apelon is NOT required for using OpenCDS.  The architecture allows for the use of any number of terminology serversconfig
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-service
12. This sub-project is intended to be converted into a Web service in the future.
This sub-project contains an abstract TerminologyManager 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.
13. opencds-knowledge-repository
    
    1. This module contains are 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.
14. 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 DroolsDecisionEngineDSSEvaluationAdapaterDroolsAdapater.  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.

...

1. Drools Guvnor is the Web-based knowledge authoring platform for the open-source JBoss Drools business rules engine.  It is still maturing, and does have limitations and bugs.  However, it is under very active development and is getting better rapidly.
2. We intend for OpenCDS to eventually support multiple knowledge authoring platforms, including XML/XSD-based knowledge authoring and knowledge authoring based on the Eclipse Drools knowledge editing platform.  However, based on our analysis, we have concluded that Drools Guvnor is a highly promising platform to serve as our initial foundation for OpenCDS knowledge authoring.  In particular, its ability to provide an intuitive user interface (when properly configured) and its ability to be deployed through a Web browser are highly appealing.
3. The current OpenCDS implementation uses the latest public release version of Guvnor (version 5.1.1).  We plan to migrate to newer versions when they become available.  In particular, the latest developer versions have significantly enhanced capabilities with regard to table-driven knowledge editing and the use of flow diagrams to specify logic.  We intend to investigate and incorporate these approaches as we move forward.
4. In developing the OpenCDS Guvnor platform, our objective was as follows:
   1. Make it as easy as possible for a knowledge engineer to implement rules
   2. Make it as intuitive as possible for clinicians with minimal training to be able to review the implemented rules (and NOT a separate documentation of the rules) to verify the content and to recommend edits as necessary.  The lack of support for this feature can make knowledge maintenance very difficult, as the specifications approved by clinicians can easily diverge from what is actually implemented and in production.  We believe the current approach meets these two objectives well.
5. Drools Guvnor currently has relatively weak metadata support.  We will need to either have Guvnor extended to support better metadata management, or create a separate, linked resource for more proper metadata management.
6. After much deliberation, we have settled on the following grouping/organization of knowledge resources at this point:
   1. Global area → place re-usable, common content
   2. To facilitate conceptual simplicity, we have mapped a single DSS knowledge module to a single Guvnor package.  Each Guvnor package may contain multiple individual Drools rules.
7. There are several components within a given Guvnor package:
   1. Model → the data model used (jar for internal vMR).  Note that the drools-guvnor webapp contains libraries for other OpenCDS jars required by the rules.
   2. Enumerations → primarily populated from Apelon.  Also, manually specified enumerations for the equivalent of local variables used within a package (see below for example).
   3. Domain Specific Language (DSL) configurations → this is at the heart of the OpenCDS knowledge authoring platform.  It provides specifications of how human-readable text is translated into underlying Drools logic.
   4. Business rule assets → the actual rules.
   5. Functions -> provide support for more complex calculations when needed
   6. Test scenarios → various test cases to test boundary conditions, etc.
8. In this alpha release, we We have include two sample knowledge bases/packages: one for the NQF Meaningful Use quality measure for breast cancer screening (NQF 0031), and one for the NQF Meaningful Use quality measure for Pap testing (NQF 0032).  Provided below is a brief guided tour through the 4 rules that comprise the Guvnor package for the NQF quality measure for breast cancer screening:
   
   

...