OpenCDS exposes clinical decision support logic as a network service: it takes a patient’s data and returns structured recommendations, instead of living as a library compiled into a single electronic health record. It is a reference implementation, under the Apache 2.0 licence, of two HL7 specifications — the Decision Support Service and the virtual Medical Record — that keep the clinical knowledge separate from the system that consumes it.

Context

For years, clinical decision support (CDS) has been more a question of knowledge representation languages than of operational services. The Arden Syntax, the HL7 standard for Medical Logic Modules, describes a clinical rule as executable text; GELLO defines an expression language for querying a clinical data model. Both solve the problem of how to write a rule, not the problem of how to distribute it across several hospitals and different records without rewriting it each time.

The Arden Syntax curly braces problem shows it well: the syntax leaves undefined how a clinical variable is read from the local record, so every installation has to fill those braces by hand. The logic is portable; the binding to the data is not.

OpenCDS started in 2010 from a consortium led by the University of Utah, with Kensaku Kawamoto — co-chair of the HL7 Clinical Decision Support work group — as the central technical figure, and with the involvement of the US Department of Veterans Affairs. The first public release dates from 2011.

Architecture

OpenCDS is a Java application that publishes a DSS (Decision Support Service) endpoint, a specification that became an HL7 normative standard in 2011 after going through the Object Management Group. DSS describes the interface, not the implementation: the client calls the service passing the identifier of the requested knowledge module and the patient data, and gets back assessments and recommendations. The transport is a SOAP web service, in line with the enterprise integration of the period.

The patient data travels in the vMR (virtual Medical Record) format, the HL7 information model — being consolidated as a Domain Analysis Model — that serialises active problems, medications, laboratory results, procedures and demographics into XML. The vMR is the contract that keeps the service independent of the record: the caller translates its own internal schema into vMR, and the service sees nothing else.

The internal flow has four steps:

  • the DSS endpoint receives the request and deserialises the vMR;
  • a data layer turns the vMR clinical entities into facts for the rule engine;
  • the engine — built on Drools, with rules written as .drl files or as decision tables — evaluates the facts against the requested knowledge module;
  • an output layer rebuilds the DSS response from the conclusions, with recommendations, rationale and references to the guidelines.

The typical deployment is on-premise at the healthcare institution, with one or more records calling the server over a web service. The clinical knowledge lives in a repository of knowledge modules kept separate from the engine, each with its own metadata and version.

The hard part

The hard part is not the engine: Drools is a mature RETE production system, and the round-trip of a DSS call stays under a second for medium-sized modules. The hard part is writing and maintaining the knowledge modules.

A module in OpenCDS is Drools code: .drl rules operating on facts generated from the vMR. Writing it takes programming skills, not only clinical ones. The person who knows the guideline — the epidemiologist, the pharmacologist, the paediatrician — does not write .drl; the person who writes .drl does not own the guideline. Between the two sits a manual translation step, prone to error and hard to validate formally. Excel decision tables ease the problem for simple tabular rules, but they do not hold up for logic with temporal dependencies or deep branching.

Then there is the artefact life cycle. A clinical rule rests on evidence that changes: a dosing threshold gets revised, a screening recommendation is updated, a drug starts interacting with another. Versioning, documented clinical validation, traceability to the underlying guideline and a retirement process for superseded modules are all needed. OpenCDS gives the technical container — the repository, the metadata — but it is the organisational process that fills and maintains it that decides whether the system holds up in production. The standard carries the rule from one hospital to another; it does not carry along whoever guarantees that the rule is still correct.

Implications

Exposing CDS as a standard service has a direct consequence for integration: the contact point between the record and the clinical logic becomes a documented interface (DSS) over a documented format (vMR), and not a plugin tied to a product. In principle the same paediatric immunisation module following the CDC ACIP schedules can serve an open-source record and a commercial one, provided both can produce and read vMR.

This shifts the adoption cost onto the translation adapter. Open-source records such as OpenMRS have prototyped integration with OpenCDS; the US commercial records have their own internal solutions and a weak incentive to expose their data as vMR. The model is worth more the more shareable modules circulate, and as of 2012 that number is low.

The role of the Department of Veterans Affairs weighs here more as a signal than as volume. The VA runs an open-source record with long-standing CDS functions; investing in an external, standardised CDS layer states a deliberate architectural choice — clinical logic as a reusable component, independent of the record that hosts it.

Limits

OpenCDS in 2012 is a young project with clear boundaries. The distributed knowledge module library is made up mostly of reference examples — immunisations, BMI calculation, dose checks — not content ready for production without adaptation to the adopting organisation’s context. Authoring stays in the hands of those who can program in Drools. There is still no shared catalogue of validated, versioned modules: without an ecosystem of recognised curators, each institution ends up rebuilding its own knowledge.

Adoption is confined to US experimental centres and to early presentations in the HL7 work groups. In Italy the topic lives in a handful of research projects: records with widespread HL7 v3 vMR integration APIs are scarce, as are Italian clinical modules validated against national guidelines and institutional investment comparable to the VA’s. The HL7 work on FHIR, still at an early stage, also leaves open the prospect that the input data format will evolve, with OpenCDS needing to hold up several patient representations over time.

Cover image: Schematic diagram of the Rete algorithm showing alpha and beta networks with linked production nodes, some highlighted in green as… — diagram by Razorbliss, CC0 — https://commons.wikimedia.org/wiki/File:Rete.svg