Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

AdverseEventAffectedBodySiteConcept

AdverseEventAffectedBodySiteLateralityConcept

AdverseEventAgentConcept

AdverseEventConcept

AdverseEventCriticalityConcept

AdverseEventSeverityConcept

AdverseEventStatusConcept

BrandedMedicationConcept

CDSInputTemplateConcept

CDSOutputTemplateConcept

ClinicalStatementEntityInRoleRelationshipConcept

ClinicalStatementRelationshipConcept

ClinicalStatementTemplateConcept

DataSourceTypeConcept

DoseTypeConcept

DosingSigConcept

EncounterCriticalityConcept

EncounterTypeConcept

EntityRelationshipConcept

EntityTemplateConcept

EntityTypeConcept

EthnicityConcept

EvaluatedPersonRelationshipConcept

GenderConcept

GenericMediccationConcept

GoalCodedValueConcept

GoalCriticalityConcept

GoalFocusConcept

GoalStatusConcept

GoalTargetBodySiteConcept

GoalTargetBodySiteLateralityConcept

ImmunizationConcept

InformationAttestationTypeConcept

InformationRecipientPreferredLanguageConcept

InformationRecipientTypeConcept

ManufacturerConcept

MedicationClassConcept

MedicationConcept

ObservationCodedValueConcept

ObservationCriticalityConcept

ObservationFocusConcept

ObservationInterpretationConcept

ObservationMethodConcept

ObservationTargetBodySiteConcept

ObservationTargetBodySiteLateralityConcept

ObservationUnconductedReasonConcept

PreferredLangugageConcept

ProblemAffectedBodySiteConcept

ProblemAffectedBodySiteLatgeralityConcept

ProblemConcept

ProblemImportanceConcept

ProblemSeverityConcept

ProblemStatusConcept

ProcedureApproachBodySiteConcept

ProcedureApproachBodySiteLateralityConcept

ProcedureConcept

ProcedureCriticalityConcept

ProcedureMethodConcept

ProcedureTargetBodySiteConcept

ProcedureTargetBodySiteLateralityConcept

RaceConcept

ResourceTypeConcept

RoleConcept

SubstanceAdministrationApproachBodySiteConcept

SubstanceAdministrationApproachBodySiteLateralityConcept

SubstanceAdministrationCriticalityConcept

SubstanceAdministrationGeneralPurposeConcept

SubstanceAdministrationTargetBodySiteConcept

SubstanceAdministrationTargetBodySiteLateralityConcept

SubstanceDeliveryMethodConcept

SubstanceDeliveryRouteConcept

SubstanceFormConcept

SubstanceManufacturerConcept

SupplyConcept

SupplyCriticalityConcept

SupplyTargetBodySiteConcept

SupplyTargetBodySiteLateralityConcept

SystemUserPreferredLanguageConcept

SystemUserTaskConctextConcept

SystemUserTypeConcept

UndeliveredProcedureReasonConcept

UndeliveredSubstanceAdministrationReasonConcept

VmrOpenCdsConcept

VMRTemplateConcept

 

...

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.

...

The master set of concepts can be generated for local use within the OpenCDS service from this central Apelon repository using a utility in the opencds-decision-support-service module named org.opencds.terminology.OpenCDSConceptsFileCreator.    

 

...

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. 

...

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.

...

It should be noted that the name of a concept instance has no computable value, it is informative for human consumption.  While we try to give meaningful names to the files, all of the files in the directory are loaded by OpenCDS at startup, regardless of the file name.  All of the computable knowledge is specified by XML within the concept instance.

 

...

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.

...

Concept mappings are intended to be maintained locally by multiple contributors in a distributed fashion, similar to knowledge modules.  This is in contrast to the OpenCDS Concepts, which are intended to be maintained centrally as described above.
 

...

Concepts in Guvnor

While it is possible to write rules for OpenCDS without using Guvnor, and without referring to OpenCDS Concepts at all, we support Guvnor and strongly recommend writing your rules in reference to OpenCDS Concepts.  The combination of Guvnor and OpenCDS Concepts produces rules that have visible and easily understood logic, and can be readily reviewed for accuracy by a clinician.

...

It is a best practice to write thorough tests in Guvnor for your rules, and to run them whenever there is any change to the rules in a KnowledgeModule (aka a “Package” in Guvnor).  This can be done in Guvnor with a single click to run all the tests for a single package.

 

...

Concept Types

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.”:

...

Once you have the model defined, leave it alone!  Changing the model may break rules that are based on the model.

 

...

Guvnor Enumerations start with OpenCDS Concepts

There is a utility in the opencds-decision-support-service module named “org.opencds.terminology.GuvnorEnumerationCreator.java” which creates a list of enumerations that can be placed into Guvnor Package Enumeration assets by using copy and paste. 

...

Refer to the official Guvnor documentation, and to our document “OpenCDS Guvnor 5.3 DSL Best Practices” for more information.

 

...

Domain Specific Language (DSL)

Enumerations make it possible to write rules using DSLs.  These DSLs, when properly designed, may make reference to a Guvnor Enumeration, which then populates a drop-down list in the rule, listing all the OpenCDS Concepts that are included in the enumeration.  DSLs are essentially a macro language that allows the use of plain clinical statement language that is non-technical, and should use a similar language to that a clinician would use to describe what the rule is supposed to do.

...

More information about using DSLs is found in the OpenCDS document named “OpenCDS Guvnor 5.3 DSL Best Practices.” 

 

...

Concept Mappings in Guvnor

We don’t think it is a good idea to reference specific codes in Guvnor.  Your rules should be written against OpenCDS Concepts, and they should be tested against OpenCDS Concepts, without worrying about how the concepts will get populated at run-time while you are in Guvnor.  Run-time mappings can then be updated or modified without changing the rules at all.

For this reason, it is a best practice to do final integration testing of OpenCDS in the run-time environment rather than Guvnor by using the OpenCDS end-to-end testing tool.  You will need to build a library of test data instances.  This library can be enhanced and resubmitted at any time, and should be used as a final validation of both updated rules and updated concept mappings. 

...


Concepts in OpenCDS Decision Support Service

 

OpenCDS Decision Support Service is the run-time implementation of OpenCDS.  Everything about it is designed to support the separation of clinical concepts as used in rules from the values in the data which is to be evaluated.

It has been said before, and I’ll repeat it here:  Write your rules against concepts, and separate the mappings of the codes found in your data from the rules.  OpenCDS provides internal methods at run-time which link each concept instance reference in your rules to every data element which has a mapping to the same concept instance in the concept mappings.

 

...

Concept Types in OpenCDS Internal Data

Concept Types have already been pretty thoroughly discussed above.  The important things to remember are that

  • They are broad categories,
  • They correspond to all the CD data elements in the vMR,
  • They are relatively fixed (adding a new Concept Type      requires a number of modifications to the OpenCDS software), and
  • They are implemented as OpenCDS Concepts, maintained in      Apelon DTS, and implemented by user-specified concept mapping      specifications which are ultimately mapped to concept codes in terminology      systems.

 

...

OpenCDS Internal Data, Concept Mapping Specifications, and Concept Mapping Instances

OpenCDS DSS maps input data to what we call the internal vMR structure.  While the external structure (the vMR schema) provides options to submit data in either listed (relational) structure or nested (object) structure, the internal structure is strictly the listed (relational) structure.

...

Concepts versus   Data

ProblemCode   = 493.1

Intrinsic   Asthma

ProblemCode   = 493.2

Chronic Obstructive   Asthma

ProblemCode   = 510

Emphysema

Chronic Asthma

 

True

 

Asthma

True

True

 

Pulmonary Disease

True

True

True

 

 

...

Updating OpenCDS Concept Mapping Specifications and Mappings

OpenCDS concept mapping specifications and mappings can be maintained in Apelon DTS.  Here is a screen shot showing maintenance of the OpenCDS Concept for Asthma in Apelon DTS:

...

Concept mapping specifications and mapping instances can alternatively be maintained manually in XML files.  This may be adequate for users with a limited number of concepts that have relatively stable code values.

 

Change Log

Date

Author

Notes

12-17-2011

David Shields

Initial document

12-20-2011

Ken Kawamoto

Minor edits; added more details on use of Apelon.

12-20-2011

David Shields

Add supporting graphics and examples, separate “OpenCDS   Concepts” from “concept instances.”

12-21-2011

David Shields

More examples, improved graphics, explain both OpenCDS and   user maintained concepts better.

4-6-2012

David Shields

Reworded definitions, improved graphics, worked on better   linkage from ideas about OpenCDS Concepts to the actual setup files used for   OpenCDS.

 

 

 

 

 

 

 

...