SDCI or Semantic Data Capture Initiative is a project of Henry Ford Health System sponsored by TATRC of Department of Defense.

At its heart the SDCI project has a simple question:

Will the clinicians be more inclined to enter structured data directly into an electronic medical record system if they are provided dynamic clinical decision support?

The key is to reward the clinician with something useful each time they enter some data into the system. Most health information systems do provide some returns, but not always to the clinician who enters the data. If the clinician does get something in return for the data-entry effort, it is usually in the future encounters with the patient. Quite often the benefits accrue to other personnel in the provider organization. No wonder, the data is often not entered. At least it is not entered when it is acquired,  at the point of care, or in a structured way.  This task is relegated to after-the-encounter-activities,  usually as a dictated note or as unstructured free text.

The computer should be doing more for the clinician than the clinician has to do for the computer. Even at the point of care!

The clinician could be rewarded, for example, by decision support about how does the scenario change for the patient with entry of each individual datum. This could be by being offered  fresh diagnoses and status of the patient , or by suggesting the next appropriate action, in the light of the new data.

We are making such dynamic clinical decision support possible by using Proteus. For this we leverage the Abstraction Cascade of the Proteus model, in which ramifications of any change at data element level are propagated to the highest level of abstraction for the patient. Proteus provides such abstractions and also guides the clinician through a previously designed process so that the optimal steps are taken to deliver appropriate care or to reach a diagnosis.

The challenge in SDCI project is to marry abilities of Proteus with Henry Ford’s new EHR, the CarePlus NG. This integration challenge has to be addressed at several levels:

  • Exchange of data based upon
    • Interfacing between the two systems
    • Semantic interoperability
  • Seamless web experience

Here is a picture of how we are making the different components work together.

SDCI Component Model

The EMR Adaptor is the single point connection with the Proteus System. At the heart of Proteus system lies the Proteus Engine, which executes the guidelines and is invoked by the EHR (CarePlus NG) via the EMR Adaptor. The Proteus Engine in turn invokes the GreEd Rule Engine when it needs to make automated inferences. The Proteus engine is also capable of invoking its own web application (SDCI App) when it needs to interact with the clinician e.g., to get user inputs or inferences. The SDCI App is capable of dynamically generating data entry templates and forms, based on the knowledge component specification, to allow user to put in data.

Guidelines are authored and maintained by using Protean (the authoring tool for process knowledge aka Guidelines) and are stored in the Guidelines Repository. Similarly, the rules are authored by GreEd and stored in the Rules Repository. The common semantic currency between the GreEd System, Proteus System and the EHR is the standard-based semantic data elements. These are data elements that are created using Semantic Annotation tool, which uses raw data elements from the EHR (via the metadata interface), and annotates them with SNOMED-CT from the Vocabulary server and stores them in the Semantic Data Element Repository. Semantic Annotation Tool not just annotates them with concepts it also renders them into a form compliant with the ISO/IEC 11179 standard.

Here is an eye candy version of the same component-diagram (well, to us it looks pretty).

SDCI architecture


A word about interfaces.

Remember the famous curly braces {problem}? Poor Arden Syntax (God bless its soul)! The {blame} got nailed to Arden Syntax’s door for no fault of its. The problem really was of how data is represented and shared by the different EHRs. Well, they did represent it in their own unique way but didn’t really share. Or at least they were not inclined to. The designers were so sure that no other EHRs but theirs would exist in the world, so where was the question of sharing.

OMG’s CORBA (God bless its soul too), and its healthcare group (fondly named CORBAMed) imagined a brave new world, where data would be exchanged in an elegant way by just invoking appropriate interfaces, which would be judiciously exposed by the designers of the systems. That effort died unsung.

Or did it? For the last few years, the ghost of CORBA’s healthcare effort is being resurrected by a group of valiant warriors (HSSP), which includes members of HL7 and OMG.

In course of time, this, along with standard vocabularies will serve as the answer to the elusive data sharing problem. Until then, we all are condemned to crafting a wheel each time we need one. The interfaces in the SDCI project are a few such wheels.

We have intentionally kept the interfaces in SDCI very simple knowing well that these will need to be supplanted by products of efforts like HSSP, sometime in the future.

So here are the interfaces, the glue that brings together disparate elements of SDCI to make it a seamless whole.

Proteus System – Decision Support Interface

This interface allows an external system to invoke Proteus engine for its decision support needs. Currently, the interface is very simple, expected to fulfill simple needs of the EHR. This is partly because EHRs do not have the capability to dynamically generate templates from XML specifications for data collection that Proteus engine requires. This could be due to no standard specification for form generation has become prevalent.

EHR – Metadata Interface

The Metadata Interface is invoked only by the Semantic Annotation Tool to access ‘raw’ data elements from the EHR, which can then be annotated with concepts from vocabulary such as SNOMED-CT.

EHR – Patient Data Interface

The Data Interface is accessed by the Proteus Engine during run time for two purposes, to access any data values that are already available so that redundant data entry is avoided and to save any data that is collected during execution of Proteus processes.

Current Status of the SDCI Project

We have completed the development of Protean (Proteus authoring tool), Proteus Execution Engine, GreEd System (a rule authoring tool and a simple rule engine), and the Semantic Annotation Tool. We are now in the process of developing the Web Application which allows executing Proteus processes through a web interface and developing mechanisms of integration with EHR, using the interfaces listed above. We have begun to play with the first cut of the web application that allows executing and controlling a Proteus process.

We are also developing two guidelines, “Hypertension Follow Up” and “Diagnosis of Upper Respiratory Tract Infection”. This development is being done chiefly by non-programmers, which has validated one of our assertions that Proteus and GreEd systems can be used by those with no specialized training in information technology.

We have also identified pilot sites where the system will be evaluating the SDCI system with clinical workforce for actual patients. This will allow us to verify if such a system can encourage direct data entry by clinicians and to study the other aspects of use of a guideline based decision support.


One thought on “SDCI-Project

  1. Pingback: SDCI-Project | Healthimer | Ann Hulton

Leave a Reply

Your email address will not be published. Required fields are marked *