/
Configuration Schemas

Configuration Schemas

Owned by Phillip Warner
Last updated: Aug 12, 2015

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

<insert base schema ref here>

REST Schema

<insert rest schema ref here>

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:

ConceptDeterminationMethods Example
<?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:

ConceptDeterminationMethod Example
<?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).

ExecutionEngines Example
<?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.

ExecutionEngine Example
<?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).

KnowledgeModules Example
<?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Ā - describes which Concept Determination Methods should be applied to incoming data, for concept mappings, before the data are processed by the rules engine.
    • primaryCDM - the primary Concept Determination Method to be used; must match the attributes of the given conceptDeterminationMethod inĀ ConceptDeterminationMethod.
    • secondaryCDMĀ - the secondary Concept Determination Method to be used;Ā must match the attributes of the givenĀ conceptDeterminationMethodĀ inĀ ConceptDeterminationMethod. Ā Any number of secondaryCDM elements may be specified (0 to many).
      • The method attribute must be one of the following:
        • ADDITIVE - indicates that theĀ list of concepts from theĀ primary Concept Determination Method will be augmented byĀ all concepts within theĀ conceptMappings of the secondary Concept Determination Method.
        • REPLACEMENTĀ - indicates that theĀ list of concepts from theĀ primary Concept Determination Method will be replaced byĀ all matching concepts within theĀ conceptMappings of the secondary Concept Determination Method.
          • Note: Only those concepts that are specified in the conceptMappings of the primaryCDM will be replaced.
          • Note: The replacement approach is last-one-wins, i.e., conceptMappings from the last secondaryCDM in the list, will take precedence over conceptMappings from all previousĀ secondaryCDM elements (in the list).
  • 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).
  • preProcessPlugins - the list of pre-process plugins, which are applied before the data are sent to the rules engine.
    • preProcessPluginĀ - one or more may be specified; the attributes of each must match the attributes from the plugin identifier (see .
  • 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.

KnowledgeModule Example
<?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>
        <primaryCDM code="C2511" codeSystem="2.16.840.1.113883.3.795.12.1.1" displayName="HEDIS 2014" version="1.0" />
        <secondaryCDM code="C36"  codeSystem="2.16.840.1.113883.3.795.12.1.1" displayName="OpenCDS" version="1.0" method="ADDITIVE" />
    </conceptDeterminationMethods>
    <package>
        <packageType>PKG</packageType>
        <packageId>org.opencds^NQF_0031_v1^1.1.1.pkg</packageId>
        <preload>false</preload>
    </package>
    <primaryProcess>PrimaryProcess</primaryProcess>
    <preProcessPlugins>
        <preProcessPlugin version="0.1" businessId="EncountersFromProblemAndProcedureConcepts" scopingEntityId="org.opencds.plugin" />
    </preProcessPlugins>
Ā    <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).

SemanticSignifiers Example
<?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.

SemanticSignifier Example
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:semanticSignifiers xmlns:ns2="org.opencds.dss.config_rest.v1_0" xmlns:ns3="org.opencds.dss.config.v1_0">
    <semanticSignifier>
        <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.CdsOutputModelExitPoint</exitPoint>
        <factListsBuilder>org.opencds.vmr.v1_0.mappings.in.CdsInputFactListsBuilder</factListsBuilder>
        <resultSetBuilder>org.opencds.vmr.v1_0.mappings.out.CdsOutputResultSetBuilder</resultSetBuilder>
        <timestamp>2014-11-03T15:24:57.212-07:00</timestamp>
        <userId>userId</userId>
    </semanticSignifier>
</ns2:semanticSignifiers>

SupportingData

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

  • identifierĀ - the identifier of theĀ KnowledgeModule, referenced by CDS requests.
  • kmIdĀ - theĀ KnowledgeModuleĀ identifier to which thisĀ SupportingDataĀ is associated.
  • packageĀ - the metadata describing theĀ SupportingDataĀ package containing data to support rule processing.
    • packageTypeĀ - the type of package.
    • packageIdĀ - the identifier used by OpenCDS to reference theĀ SupportingDataĀ package on the filesystem.
    • preloadĀ - (optional) indication to OpenCDS whether to preload theĀ SupportingDataĀ package on startup.
  • loadedBy - the plugin that is used to load the supporting data and prepare it for use within the system. Ā Attributes MUST match the attributes of a valid plugin identifier specified in theĀ PluginPackage. (Implementation is currently incomplete. Ā Will be updated via OP-41 - Getting issue details... STATUS .)
  • timestampĀ - the time when the metadata were created.
  • userIdĀ - the user id of the user who created/uploaded theĀ KnowledgeModule.

For a discussion of theĀ SupportingDataĀ element, please refer toĀ Automated Deployment of Knowledge to OpenCDS - Scenarios.

SupportingData Example
<?xml version="1.0" encoding="UTF-8"?>
<rest:supportingData xmlns:config="org.opencds.dss.config.v1_0" xmlns:rest="org.opencds.dss.config_rest.v1_0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="org.opencds.dss.config_rest.v1_0 ../schema/OpenCDSConfigRest.xsd ">
    <identifier>identifier</identifier>
    <kmId businessId="edu.utah" scopingEntityId="SCIP_VTE_2" version="2014.0.0" />
    <package>
        <link rel="self" href="http://opencds.org/nowhere" />
        <packageType>packageType</packageType>
        <packageId>packageId</packageId>
    </package>
    <loadedBy version="0.1" businessId="SupportingDataLoaderPlugin" scopingEntityId="custom.plugin"/>
    <timestamp>2001-12-31T12:00:00</timestamp>
    <userId>userId</userId>
</rest:supportingData>

PluginPackages

The PluginPackages element describes a list of pluginsĀ used in both pre- and post-processing.

PluginPackages Example
<?xml version="1.0" encoding="UTF-8"?>
<rest:pluginPackages 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">
    <pluginPackage>
	...
    </pluginPackage>
</rest:pluginPackages>

PluginPackage

TheĀ PluginPackageĀ describes the metadata describing theĀ PluginPackagesĀ to be used in both pre- and post-processing. Ā These elements describe how the system should find and load the plugin:

  • identifierĀ - the identifier of theĀ PluginPackage, referenced by the system.
  • loadContext - indicates to the system where to find the plugin. Ā Values are restricted to the following:
    • CLASSPATH - the system should find the package resource on the Java CLASSPATH
    • IMPORTED - (To be implemented in the future.) the system should find the resource in the configuration folders.
  • resourceName - the name of the resource in the location specified in loadContext. Ā This name will (currently) be the name of a jar file.
  • plugins - the list of plugins contained in the plugin package
    • plugin - the plugin metadata, described by the following elements:
      • identifier - the identifier of the plugin, used as a reference by the system in order to obtain the className of the plugin.
      • className - the class name of the plugin.
  • timestampĀ - the time when the metadata were created.
  • userIdĀ - the user id of the user who created/uploaded theĀ PluginPackage.

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).

PluginPackages Example
<?xml version="1.0" encoding="UTF-8"?>
<rest:pluginPackage 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 version="1.3.0-SNAPSHOT" businessId="opencds-plugin-encounters" scopingEntityId="org.opencds.plugin" />
        <loadContext>CLASSPATH</loadContext>
        <resourceName>opencds-plugin-encounters-1.3.0-SNAPSHOT.jar</resourceName>
        <plugins>
            <plugin>
                <identifier version="0.1" businessId="EncountersFromProblemAndProcedureConcepts" scopingEntityId="org.opencds.plugin" />
                <className>org.opencds.plugin.EncountersFromProblemAndProcedureConcepts</className>
            </plugin>
        </plugins>
        <timestamp>2014-10-13T22:39:00</timestamp>
        <userId>userId</userId>
</rest:pluginPackage>

Ā 

Ā