| Table of Contents | ||||
|---|---|---|---|---|
|
Using OpenCDS Concepts
Introduction
OpenCDS is a Clinical Decision Support system that is built around the notion of “clinical concepts.” There are many medical terminology systems and medical information exchange systems that refer to “concepts,” “concept descriptors (CDs),” or “concept unique identifiers (CUIs).”
When we refer to an OpenCDS Concept we are referring to specific implementation techniques within OpenCDS which have a strong dependence on most of these ideas, but in a concrete implementation.
The purpose of this document is to explain how we use all of these terms in OpenCDS, and how they relate to the general clinical understanding of “concepts.”
What is an “OpenCDS Concept?”
An OpenCDS Concept is an implementation technique in OpenCDS. As a big picture idea, OpenCDS has a structure and methods that are designed to allow the clinical user to develop decision support rules that are written using clinical concepts. We call those particular concepts “OpenCDS Concepts”, and they provide an interface to the detailed data that represents an instance of the clinical concept.
This means that the clinical rule writer can work using clinical terminology that clinicians understand. OpenCDS is designed to support rules written for the open-source Drools inferencing engine, using a domain specific language (DSL). The DSL makes it possible to write the rules so that they read just like the way a clinician would describe them, using terms (OpenCDS Concepts) that the clinician uses every day.
A medical informaticist, terminologist, or vocabulary expert then produces mappings of those concepts to values in a code system which is used in the actual clinical data. In many cases this will involve the use of terminology management systems with large databases, such as Apelon, First DataBank, and UMLS which support potentially large and internationally supported terminologies. However, it is possible to also create simple XML files that map proprietary or special-case codes to OpenCDS Concepts.
The clinical rules use OpenCDS Concepts in preference to references to the raw data, and the terminology mappings provide implementations of those concepts as lists of codes from one or more code systems. This separates the logic of the rules from the details of the data which the rules work on.
Therefore, an OpenCDS Concept is the interface between the clinical ideas and the data details that represent instantiations of the clinical concepts.
This section of this document will explain the following items, and discuss how they are used in OpenCDS:
- Concept Types
- OpenCDS Concepts
- Concept Instances
- Concept Mappings and Enumerations
The diagram below may make this relationship easier to visualize:
Following sections will discuss the techniques used to relate the patient data to the clinical concepts or ideas in the following software:
- JBoss Drools Guvnor (our supported authoring environment for KnowledgeModules, aka “rules” or generically as “knowledge”)
- OpenCDS Decision Support Service (our software service to do clinical decision support)
Concept Types
Definition:
Concept Types in OpenCDS is the term we use to refer to Java classes in OpenCDS that have been created for every “concept descriptor” (aka CD) and “template” found in the input data structured as a virtual medical record (vMR).
A Concept Type represents an entire category of information that can be found at several places in a clinical statement. Clinical statements are the basic building blocks of the vMR. The vMR is more fully discussed in a separate document named “Notes on OpenCDS internal Data Structure.” In addition, there are also a few additional Concept Types that deal with “templates” and some structural elements of the vMR.
In this document, I will always capitalize Concept Type when I am referring to those Java classes, and use lower-case when I am referring to the more common or generic notions of “concept.”
In some cases, we have also post-coordinated more than one CD in the input data (such as “body site” and “laterality”), because there may be a need to make decisions based on the combination of the two, or common coding systems for a procedure or problem may not provide adequate specificity without being associated with both values as a set. For example, we need to be able to say that a rash was present both on the right arm and the left leg.
Examples of Concept Types are a “ProcedureConcept,” an “AdverseEventAgentConcept,” a “ProblemConcept”, or a “MedicationClassConcept.”
Because they are based on specific data elements in the vMR, OpenCDS supports a fixed list of these Concept Types, including a few that are broad enough to fill most needs for an “other” category. While we can add more Concept Types if the need arises, we feel that the current list is useable. Supporting additional Concept Types is non-trivial, so it will not be done casually.
The authoritative list of supported Concept Types can always be found in the source code as separate files in the module opencds-vmr-1_0-internal as separate Java classes in the package org.opencds.vmr.v1_0.internal.concepts. These files have the name of the Concept Types as you would see them in a Drools Rule. They are also listed for a different purpose (building enumerations) in a Java class named “org.opencds.common.terminology.OpenCDSConceptTypes.java”.
The current list of Concept Types as of the time this document was written is shown on the next page:
| Section | ||
|---|---|---|
|
OpenCDS Concepts
Definition
An OpenCDS Concept is a specific instance of an OpenCDS Concept Type that identifies a clinical concept familiar or useful to clinicians in the context of decision support, and has been identified and assigned an ID in OpenCDS using Apelon DTS.
...
Concept Mapping Specifications
Definition:
A concept mapping specification in OpenCDS is an OpenCDS Concept that has an associated Determination Method and may or may not specify an associated Code System.
It is normal usage to create one or more concept mapping specifications for every OpenCDS Concept that is used. Concept mapping specifications will normally be populated with lists of codes from the associated code system(s) that meet the requirements of the associated determination method, and when this happens the concept instance is more commonly called simply a concept mapping. However, it is possible to define a concept mapping specification without mapping instances.
We frequently don’t accurately distinguish between concept instances without mappings and concepts with mappings, because defining the mapping specification is normally the first step to creating the mappings. However, it is useful to separate the notion of a concept mapping specification from the mappings, because it is a two-layer process: There may be multiple sets of concept mapping specifications for each OpenCDS Concept, and there may be multiple mapping instances to specific codes for each concept mapping specification.
Associated Determination Method
One important attribute of a concept mapping specification in OpenCDS is that it is always associated with a “determination method.” This allows for the creation of similar concept mappings that are based on different requirements. This is particularly useful when you want to work with a concept as defined by some regulatory body, such as HEDIS or NQF. These organizations typically have very specific lists of codes and code systems that describe particular concepts they are interested in.
...
Typically, however, you may want to work with a single determination method in any one particular KnowledgeModule. We include sample DSL to select a single determination method for a rule, but you can use them in any way that meets your requirements.
Associated Code System
A second important attribute of a concept mapping specification in OpenCDS is that it may be associated with one particular code system. This means that there may be several distinct instances of the OpenCDS Concept for different code systems, such as LOINC, CPT, ICD9, ICD10, SNOMED-CT, RXNORM, proprietary in-house systems, and so on.
...
Concept Mapping Instances
Definition:
Concept mapping instances in OpenCDS relate a concept mapping specification to one or more codes from the one or more associated Code System(s) as specified by the associated Determination Method.
A A concept mapping instance will include a list of CD elements (code system and code) that imply or specify the clinical concept (aka OpenCDS Concept) associated with the concept mapping specification. They are determined by the associated determination method, and may or may not all be from one associated code system.
...
The same Java classes that define Concept Types in OpenCDS are imported into Guvnor using the jar file from the OpenCDS module named “opencds-vmr-v1_0-internal.” This then gives you exactly the same definitions of Concept Types that are used in the web service. You will also need the OpenCDS Common jar from the OpenCDS module named “opencds-common.”:
If you select the “Edit” tab instead of the “Assets” tab, you will be able to view (and edit) the contents of the model:
If you click the “Advanced View” button, you will be able to edit the model as text, and you may need to do this:
When you first create a new model in Guvnor by importing the two jars from OpenCDS, this list will be in a random order, and it will include some elements from the common jar that you don’t need. We provide a sorted list of the import statements, which you can paste into this window after deleting the generated content. This sorted list is maintained in the OpenCDS source code as a resource named “ImportStatementsForOpenCDSGuvnor.txt” within the opencds-vmr-1_0-internal module.
...