OpenCDS: open source clinical decision support services

AIHealth

On-premise clinical platform with local LLMs, RAG on FHIR/DICOM data, diagnostic support, remote follow-up. Architecture designed for the MDR pathway.

Discover AIHealth →

Digital Health

Medical software development compliant with CE and MDR regulatory standards. Clinical decision support systems, AI integration in clinical workflows.

Discover →

From language to service

Arden Syntax and GELLO are knowledge representation languages. Drools is a general-purpose rule engine. Operational use in a real hospital requires something more: a service — a self-contained system, network-queryable, that receives a patient as input and returns structured clinical recommendations — supported by a shared reference architecture.

OpenCDS (Open Clinical Decision Support) was born to cover this need. The project was launched in 2010 by a consortium led by the University of Utah — in particular by Ken Kawamoto, a central figure in HL7 CDS specifications work — with involvement of US Veterans Affairs, Partners HealthCare, University of Maryland and other academic and governmental partners. The first public release dates to 2011; the currently available release, OpenCDS 1.0.x, consolidates the architecture.

The project is distributed under the Apache 2.0 licence, and is structured as a reference implementation of a set of HL7 specifications maturing in the same years.

Reference HL7 standards

OpenCDS implements and operationalises three HL7 specifications defining CDS service architecture:

HL7 vMR — virtual Medical Record

vMR is a standardised information model representing a patient’s clinical context as CDS service input. An HL7 v3 specification, it defines how to serialise — in XML — patient demographics, active problems, drugs in use, clinical events, laboratory results, past procedures. The goal is to decouple the CDS service from the client record’s internal formats: the service always speaks vMR, whatever the calling record.

HL7 DSS — Decision Support Service

The DSS (Decision Support Service) specification defines the invocation interface of CDS services as web services. A client — typically an electronic record — invokes the service passing:

• Patient identifiers (or the full vMR)
• Identifier of the requested knowledge module (e.g. a module for paediatric vaccinations, pharmacovigilance, oncology screening)
• Request context

The service returns:

• Structured clinical recommendations (messages, suggested actions, proposed orders)
• Rationale explanations
• Urgency levels
• References to underlying guidelines

DSS is specified as a SOAP Web Service — the enterprise interoperability standard of the era — with intent to include REST in subsequent evolutions.

Health eDecisions (HeD)

The HeD project is a 2012 US initiative — funded by the Office of the National Coordinator for Health IT (ONC) — to standardise the format of shareable CDS knowledge artifacts across organisations. The main expected output is a Knowledge Artifact Schema in XML that encapsulates rules, guidelines and documentation into a single structured document. OpenCDS is one of the implementation vehicles for HeD.

OpenCDS architecture

OpenCDS is a Java enterprise application with key components:

• DSS endpoint — SOAP web service receiving calls from clinical records
• Execution engine — based on Drools, with clinical rules expressed as DRL files or Excel Decision Tables
• Data layer — pipeline that transforms the incoming vMR into Drools facts to inject in the working memory
• Knowledge repository — directory structure with knowledge artifacts and their metadata
• Output layer — builds the DSS response from the conclusions generated by rules

The typical deployment model is: on-premise installation of the OpenCDS server at a healthcare institution (hospital, CDS-as-a-Service provider, VA), with integration with one or more clinical records via web service.

Available knowledge modules

The knowledge module library distributed with OpenCDS 1.x includes reference examples in areas:

• Immunizations — paediatric and adult vaccination schedules per ACIP (Advisory Committee on Immunization Practices) CDC guidelines
• Adult preventive care — reminders for screening (mammography, colonoscopy, Pap test, flu vaccination)
• Drug management — dose checks, interactions, therapeutic duplications
• Pediatric growth — growth percentiles with outlier alerts
• BMI calculator — BMI computation and classification with recommendations

These modules are didactic starting examples, not necessarily production-ready for clinical use without adaptation to the specific adopter organisation’s context.

Record integration

Integration with a real electronic record is the most important operational node:

• The record must produce a vMR from its structured data (diagnoses, drugs, laboratory, demographics)
• The record must invoke OpenCDS via a web service call
• The record must consume the response by presenting recommendations to the user in the right clinical flow context

Typical round-trip time is sub-second for medium-sized knowledge modules, compatible with record interactivity.

Some open source records (OpenMRS, OpenEMR) have prototyped OpenCDS integrations; US commercial records (Epic, Cerner, Allscripts) have their internal solutions but some explore integration with external OpenCDS services for specific domains.

The VA as sponsor and user

The role of the US Department of Veterans Affairs is particularly important. The VA runs a pervasive healthcare system with over 150 hospital centres and millions of patients; its record (VistA) is open source and has historical internal CDS functionality. VA investment in OpenCDS reflects a modernisation strategy: moving CDS logic into an external standardised layer, record-independent, reusable beyond VistA.

Intermountain Healthcare — another US centre with an advanced CDS tradition, historical Arden Syntax user — is evaluating OpenCDS as convergence platform.

Comparison with alternatives

OpenCDS is not the only open source CDS service:

• Arden2ByteCode and other Arden tools are MLM-specific, without full web service infrastructure
• GLIF implementations (Stanford’s GuideLineExec, Oxford’s PROforma/Tallis interpreters) are more academic and oriented to full guideline authoring
• Proprietary engines of EHR vendors (Epic Cogito, Cerner HealtheIntent) offer integrated but closed CDS
• Zynx Health and First Databank supply commercially curated CDS content, often integrated in various EHRs

OpenCDS stands out for:

• Truly open Apache 2.0 licence
• HL7 standardisation (vMR + DSS)
• Modularity — knowledge modules separate from the engine
• Interoperability — any record can integrate via standard web service

2012 limits

OpenCDS is a young project with recognised limits:

• Limited knowledge module library — few ready modules, most value has to be built by adopters
• Complex authoring — writing knowledge modules in Drools DRL requires programming skills; visual authoring tools for clinicians are still primitive
• Knowledge curation — the lifecycle of a CDS artefact (creation, clinical validation, versioning, publication, update from new evidence) requires organisational processes still immature
• Narrow adoption — OpenCDS in 2012 is in use at some experimental US centres, with initial international exposure in HL7 groups
• Commercial record integration — the vMR format dependency requires non-trivial adapters; in closed records change is slow

The Italian landscape

In Italy OpenCDS uptake in 2012 is limited to some research projects. Obstacles are those common to standardised CDS in general:

• Italian clinical records without standardised integration APIs (HL7 v3 vMR is not common)
• Lack of clinically validated, regularly updated Italian knowledge modules
• Absence of institutional investment comparable to the US VA
• FSE programme priority on the documentary part rather than active CDS

The topic is discussed in HL7 Italia working groups and in some medical schools. The possibility of participating in the OpenCDS project by contributing Italian clinical modules — based on Italian guidelines (AIFA for drugs, ministerial for screening) — is an open but not structurally seized opportunity.

Outlook

OpenCDS evolution directions in coming years will include:

• Entry of emerging formats — HL7’s work on FHIR, in early phase as of 2012, will in coming years create an alternative to vMR. OpenCDS will need to support both
• Authoring tools for clinicians — visual composition tools for knowledge artifacts, without directly writing DRL
• Shareable knowledge artifacts — a marketplace or catalogue of validated modules, inspired by open source package projects (CPAN, Maven Central, CRAN). Still missing — requires a trusted curator ecosystem
• Integration with international guidelines and transformation of textual clinical practice guidelines into executable knowledge artifacts
• Cloud deployment — CDS-as-a-Service with emerging business models

OpenCDS in 2012 represents a fundamental piece of a broader ecosystem still under construction. Its success will depend less on technical quality — already solid — and more on the organisational and clinical culture that manages to operationalise the paradigm of standardised CDS as shared service.

References: OpenCDS (www.opencds.org), version 1.x (2011-2012). University of Utah (Ken Kawamoto), Veterans Affairs, Partners HealthCare. HL7 vMR — virtual Medical Record. HL7 Decision Support Service (DSS). Health eDecisions (HeD) initiative, ONC 2012. Apache 2.0 licence. Drools as underlying engine.