Dedicated schemas for describing configuration metadata.
- Migration tool to migrate configuration schema from the previous version (1.2.x, 1.1.x, etc.) to the new version.
REST interface for adding/updating and retrieving the configuration metadata
- including reloadability of File-based configuration.
Backwards compatibility with ClassPath- and File-based configuration.
- NOT compatible with previous schemas; migration is required.
New backend configuration scheme using BerkeleyDB (BDB-JE).
- This is the only method that is supported via REST.

Schemas

OpenCDS Configuration schemas consist of a base schema and a REST schema. The REST schema contains the elements that are used for physical configuration metadata (e.g., XML files).

Base Schema

REST Schema

Schema Elements and Examples

The REST schema is the entry point for OpenCDS configuration, whether they exist as files on the filesystem or as objects in BerkeleyDB. The main elements are as follows:

`ConceptDeterminationMethods`

ConceptDeterminationMethods consists of one or more ConceptDeterminationMethod elements.

This style of configuration may be used via the REST service or may exist on the filesystem (as in the 1.2.x and previous configuration).

An example ConceptDeterminationMethods is shown below:

Code Block

theme	Eclipse
language	xml
title	ConceptDeterminationMethods Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:conceptDeterminationMethods xmlns:ns2="org.opencds.dss.config.v1_0" xmlns:ns3="org.opencds.dss.config_rest.v1_0">
    <conceptDeterminationMethod code="C45" displayName="NQF" codeSystem="2.16.840.1.113883.3.795.12.1.1" version="1.0">
    ...
    </conceptDeterminationMethod>
    <conceptDeterminationMethod code="C267" displayName="AHRQ" codeSystem="2.16.840.1.113883.3.795.12.1.1" version="1.0">
    ...
    </conceptDeterminationMethod>
    <conceptDeterminationMethod code="C36" displayName="OpenCDS" codeSystem="2.16.840.1.113883.3.795.12.1.1" version="1.0">
    ...
    </conceptDeterminationMethod>
</ns3:conceptDeterminationMethods>

`ConceptDeterminationMethod`

ConceptDeterminationMethod contains concept mappings from local or standard concepts to OpenCDS concepts. The concept mapping metadata is organized such that toConcept is the OpenCDS concept, while the associated concept elements within fromConcepts compose the local and standard concepts that may be expected in the vMR data. When processing the vMR, for each of the local concepts found, OpenCDS will add the OpenCDS concept (the toConcept) to the internal fact lists.

Elements are described as follows:

conceptMapping - the element wrapping the overall mapping of local/standard concepts to OpenCDS concepts
toConcept - the OpenCDS concept to which all fromConcepts will map
fromConcepts - the wrapper element for local/standard concepts that are mapped to the OpenCDS concept; contains the codeSystem of the concepts (NOTE: multiple fromConcepts within the conceptMapping are supported, in order to support concepts from any number of codeSystems).
- concept - the local/standard concept, within the codeSystem specified in the fromConcepts element.

This style of configuration may be used via the REST service or may exist on the filesystem (as in the 1.2.x and previous configuration).

An example ConceptDeterminationMethod is shown below:

Code Block

theme	Eclipse
language	xml
title	ConceptDeterminationMethod Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:conceptDeterminationMethod xmlns:ns2="org.opencds.dss.config.v1_0" xmlns:ns3="org.opencds.dss.config_rest.v1_0" code="C74" displayName="CDC-RD concept determination method" codeSystem="2.16.840.1.113883.3.795.12.1.1" version="1.0">
    <conceptMapping>
        <toConcept code="C88" codeSystem="2.16.840.1.113883.3.795.12.1.1" codeSystemName="OpenCDS concepts" displayName="Result Negative" />
        <fromConcepts codeSystem="2.16.840.1.113883.3.795.12.1.2" codeSystemName="OpenCDS proprietary local" displayName="Result Negative">
            <concept code="NEGATIVE" displayName="Result Negative" />
            <concept code="Negative" displayName="Result Negative" />
            <concept code="negative" displayName="Result Negative" />
            <concept code="NEG" displayName="Result Negative" />
            <concept code="Neg" displayName="Result Negative" />
            <concept code="neg" displayName="Result Negative" />
            <concept code="N" displayName="Result Negative" />
            <concept code="n" displayName="Result Negative" />
            <concept code="Invalid" displayName="Result Negative" />
            <concept code="Indeterminate" displayName="Result Negative" />
            <concept code="Inadequate" displayName="Result Negative" />
            <concept code="Not Detected" displayName="Result Negative" />
        </fromConcepts>
    </conceptMapping>
    <conceptMapping>
        <toConcept code="C273" codeSystem="2.16.840.1.113883.3.795.12.1.1" codeSystemName="OpenCDS concepts" displayName="Strep Pneumo Test For Organism" />
        <fromConcepts codeSystem="2.16.840.1.113883.3.795.12.1.2" codeSystemName="OpenCDS proprietary local" displayName="Streptococcus pneumoniae">
            <concept code="Strpne" displayName="Streptococcus pneumoniae" />
        </fromConcepts>
    </conceptMapping>
</ns3:conceptDeterminationMethod>

`ExecutionEngines`

ExecutionEngines consists of one or more ExecutionEngine elements.

This style of configuration may be used via the REST service or may exist on the filesystem (as in the 1.2.x and previous configuration).

Code Block

theme	Eclipse
language	xml
title	ExecutionEngines Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8"?>
<rest:executionEngines xsi:schemaLocation="org.opencds.dss.config_rest.v1_0 ../schema/OpenCDSConfigRest.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rest="org.opencds.dss.config_rest.v1_0">
    <!--include all supported executionEngine package names in this list, along with the operations they support -->
    <executionEngine>
	...
    </executionEngine>
    <executionEngine>
	...
    </executionEngine>
</rest:executionEngines>

`ExecutionEngine`

The ExecutionEngine metadata contains information about the rules engine adapter that should be used for rule processing. Elements are as follows:

identifier - the identifier of the ExecutionEngine; this should be the fully-qualified class name of the adapter.
description - a free-form description of the ExecutionEngine
timestamp - the timestamp of metadata creation
userId - the user id of the user who created the metadata
supportedOperation - (may include more than one) describes the types of operations supported by the ExecutionEngine.

This style of configuration may be used via the REST service.

Code Block

theme	Eclipse
language	xml
title	ExecutionEngine Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8"?>
<rest:executionEngine xsi:schemaLocation="org.opencds.dss.config_rest.v1_0 ../schema/OpenCDSConfigRest.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rest="org.opencds.dss.config_rest.v1_0">
    <identifier>org.opencds.service.drools.v55.DroolsAdapter</identifier>
    <description>Drools 5.5 based adapter</description>
    <timestamp>2014-04-08T00:00:00</timestamp>
    <userId>Someone</userId>
    <supportedOperation>EVALUATION.EVALUATE</supportedOperation>
    <supportedOperation>EVALUATION.EVALUATE_AT_SPECIFIED_TIME</supportedOperation>
</rest:executionEngine>

`KnowledgeModules`

KnowledgeModules consists of one or more KnowledgeModule elements.

This style of configuration may be used via the REST service or may exist on the filesystem (as in the 1.2.x and previous configuration).

Code Block

theme	Eclipse
language	xml
title	KnowledgeModules Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:knowledgeModules xmlns:ns2="org.opencds.dss.config.v1_0" xmlns:ns3="org.opencds.dss.config_rest.v1_0">
    <knowledgeModule>
	...
    </knowledgeModule>
    <knowledgeModule>
	...
    </knowledgeModule>
</ns3:knowledgeModules>

`KnowledgeModule`

The KnowledgeModule element consists of metadata describing the KnowledgeModule. Element descriptions are as follows:

identifier - the identifier of the KnowledgeModule, referenced by CDS requests.
status - the status of the KnowledgeModule
executionEngine - the identifier for the ExecutionEngine, used to cross-reference the ExecutionEngine metadata.
semanticSignifierId - the identifier for the SemanticSignifier, used to cross reference the SemanticSignifier metadata.
conceptDeterminationMethods - (to be used in future implementations) describes which Concept Determination Methods should be used for concept mappings, before the data are processed by the rules engine.
package - the metadata describing the knowledge package containing the rules and other artifacts used by the rules engine.
- packageType - the type of package (E.g., Drools accepts, .pkg, .bpmn2, and .drl).
- packageId - the identifier used by OpenCDS to reference the package on the filesystem.
- preload - indication to OpenCDS whether to preload the knowledge package on startup.
primaryProcess - the process name used by Drools (as specified in the BPMN2 process diagram).
timestamp - the time when the metadata were created.
userId - the user id of the user who created/uploaded the KnowledgeModule.

This style of configuration may be used via the REST service.

Code Block

theme	Eclipse
language	xml
title	KnowledgeModule Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:knowledgeModule xmlns:ns2="org.opencds.dss.config.v1_0" xmlns:ns3="org.opencds.dss.config_rest.v1_0">
    <identifier scopingEntityId="org.opencds" businessId="NQF_0031_v1" version="1.1.1" />
    <status>APPROVED</status>
    <executionEngine>org.opencds.service.drools.v55.DroolsAdapter</executionEngine>
    <semanticSignifierId scopingEntityId="org.opencds.vmr" businessId="VMR" version="1.0" />
    <conceptDeterminationMethods />
    <package>
        <packageType>PKG</packageType>
        <packageId>org.opencds^NQF_0031_v1^1.1.1.pkg</packageId>
        <preload>false</preload>
    </package>
    <primaryProcess>PrimaryProcess</primaryProcess>
    <timestamp>2014-07-30T13:21:46.772-06:00</timestamp>
    <userId>Someone</userId>
</ns3:knowledgeModule>

`SemanticSignifiers`

SemanticSignifiers consists of one or more SemanticSignifier elements.

This style of configuration may be used via the REST service or may exist on the filesystem (as in the 1.2.x and previous configuration).

Code Block

language	xml
title	SemanticSignifiers Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:semanticSignifiers xmlns:ns2="org.opencds.dss.config.v1_0" xmlns:ns3="org.opencds.dss.config_rest.v1_0">
    <semanticSignifier>
	...
    </semanticSignifier>
</ns3:semanticSignifiers>

`SemanticSignifier`

The SemanticSignifier element describes the external model of the vMR data that will enter the system. These elements describe how the system should process the incoming vMR data:

identifier - the identifier of the SemanticSignifier
name - a human-readable name of the identifier (typically a ^-delimited combination of the identifier attributes)
description - free-form description of the SemanticSignifier
xsdComputableDefinition
- xsdRootGlobalElementName - the global element name of the schema
- xsdURL - the pathname of the schema implementation (e.g., the package name of the JAXB classes)
entryPoint - the entry point used by OpenCDS to transform the incoming data into the internal model.
exitPoint - the exit point used by OpenCDS to transform the outgoing data into the external model.
timestamp - the timestamp of creation
userId - the user id of the user who created the metadata instance.

This style of configuration may be used via the REST service.

Code Block

language	xml
title	SemanticSignifier Example
linenumbers	true

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:semanticSignifier xmlns:ns2="org.opencds.dss.config.v1_0" xmlns:ns3="org.opencds.dss.config_rest.v1_0">
    <identifier scopingEntityId="org.opencds.vmr" businessId="VMR" version="1.0" />
    <name>org.opencds.vmr^VMR^1.0</name>
    <description>org.opencds.vmr^VMR^1.0</description>
    <xsdComputableDefinition>
        <xsdRootGlobalElementName>CDSInput</xsdRootGlobalElementName>
        <xsdURL>org.opencds.vmr.v1_0.schema</xsdURL>
    </xsdComputableDefinition>
    <entryPoint>org.opencds.vmr.v1_0.schema.CDSInput</entryPoint>
    <exitPoint>org.opencds.vmr.v1_0.mappings.out.VMRV10ModelExitPoint</exitPoint>
    <timestamp>2014-07-30T13:21:46.750-06:00</timestamp>
    <userId>Someone</userId>
</ns3:semanticSignifier>

Configuration Schemas

Backend

The OpenCDS backend is configured using one of three methods: Classpath, Filesystem and BDB. The choice of configuration strategy is made within the opencds.properties file (see OpenCDS RunTime Installation Guide for details).

...

Version	Old Version 10	New Version 11
Changes made by	Phillip Warner	Phillip Warner
Saved on	Aug 02, 2014	Aug 04, 2014

Versions Compared

Key

Schemas

Base Schema

REST Schema

Schema Elements and Examples

`ConceptDeterminationMethods`

`ConceptDeterminationMethod`

`ExecutionEngines`

`ExecutionEngine`

`KnowledgeModules`

`KnowledgeModule`

`SemanticSignifiers`

`SemanticSignifier`

Backend

Content Comparison

Versions Compared

Key

Schemas

Base Schema

REST Schema

Schema Elements and Examples

ConceptDeterminationMethods

ConceptDeterminationMethod

ExecutionEngines

ExecutionEngine

KnowledgeModules

KnowledgeModule

SemanticSignifiers

SemanticSignifier

Backend

`ConceptDeterminationMethods`

`ConceptDeterminationMethod`

`ExecutionEngines`

`ExecutionEngine`

`KnowledgeModules`

`KnowledgeModule`

`SemanticSignifiers`

`SemanticSignifier`