Decision Support Service Providers

Guest author John Halamka is Chief Information Officer of Beth Israel Deaconess Medical Center and the  Harvard Medical School. 

Decision Support Service Providers

In my recent Leiter Lecture, I spoke about the idea that decision support services should be available in the cloud. BIDMC has 2000 decision support rules. Brigham and Women's has 2000 decision support rules. They are entirely different rules maintained by two teams of experts. That's lunacy.

Shouldn't we have have a single set of evidence-based rules that everyone in the country can use?

But how would it work and what standards would be used?

I serve on the Board of AnvitaHealth (note the Conflict of Interest), which is working on this problem.

1. First, rules need to be authored by experts or gleaned from the literature and represented electronically in a decision support cloud.

2. Second, an XML form of patient history needs to be sent to the Decision Support Service Provider. For example, the problem list, medication list, recent labs, age, and gender could be sent in a Continuity of Care Document without specific patient identifiers.

3. Third, the Decision Support Service Provider should respond with clinical care advice, such as drug/drug interactions, alerts/reminders, or wellness guidance

Here's a concrete example. For brevity, I included only pertinent portions of the XML input data. The XML could contain any arbitrary length of data elements and codes sets.

Here's an example of an XML patient data input file (CCD is also natively supported)

The XML response is a realtime answer to every rule set run. Thousands can be executed in realtime (milliseconds). Here's an XML response that indicates two drug safety issues – a drug-disease (MAO+Hypertension) interaction and a dangerous drug-drug combination at severity level 1 (fetanyl-containing meds and MAO inhibitors)

Here's an XML response that indicates a laboratory gap in care. In this case, the patient is taking an ACE Inhibitor and does not have recent serum electrolytes. The compliance to this rule is thus false (underlined).

Thus, Anvita has defined clinical decision support (CDS) standards to transmit decision support recommendations from the service provider back to the EHR. I am unaware any widely implemented standards that do this today.

Additionally, the XML response object is hierarchical. Any response (drug safety, gap in care, etc) can be drilled down further to any level of detail, including the drug package insert, for example. However, for speed of response, Anvita returns portions of the XML response initially.

Additional details from Anvita:

1. The patient data set (longitudinal health record) can be sent to Anvita’s web service as XML or CCD. Anvita’s XML anticipates and extends attributes necessary for decision support, such as presence or absence of different types of dialysis, which are not yet required by CCD.

2. Anvita’s engine includes (a) decision support function requests (e.g., check drug dose, get formulary, find safety-check therapeutic alternatives, find gaps in care) and also (b) utilities, such as: search functions using descriptions within codesets like CPT, NDCs, the ability to find all drugs within a therapeutic class, find all LOINCs that infer the same physiologic laboratory test, etc. Anvita utilitizes freely available vocabularies for maintaining local dictionaries, their synchronization, and taxonomies. The modularity of (a) and (b) allows homegrown systems and next-generation applications to be developed without having to deal with the complexity of thousands of pages of implementation guides pertaining to drug databases, industry codes like CPT, LOINC, NDC, semantic interoperability between non-congruent databases (due to the Anvita Thesaurus), as well as coding of hundreds of quality/ performance measures that Anvita provides out of the box (e.g., HEDIS), in a plug-and-play fashion.

3. A decision support request, posed as XML, returns a response object for that request. The response XML can include drug safety analysis, gaps in care analysis and scoring, formularies, cumulative radiation exposure, etc. Therefore, Anvita is a generalizable, semantic search engine that executes in realtime as a web service. Anvita’s realtime capability not only enables decision support at the Point of Care, but business functions such as electronic prior authorization using EHR data (e.g., high tech imaging).

4. The analytical responses can be delivered as either XML (for instantaneous consumption at the Point of Care) or written directly to an alerts database (for population analytics). The analytical database can be viewed/queried directly by Anvita’s web-based tool or it can mined by 3rd party business intelligence tools (e.g., Cognos, Business Objects, JasperSoft, Pentaho).

5. Anvita also has supporting tools that include:

a. A Rules Authoring application, so that a non-technical specialty society or policy group (e.g,. NQF-endorsed entities) can author computable performance measures without any software coding at the atomic level

b. A Rules Management application, so that local organizations and physicians can decide and configure which rules to run (e.g., Meaningful Use), including the rules they’ve authored themselves and that might be proprietary (e.g., electronic prior-authorization criteria).

I do not present this as an advertisement for Anvita, but as a generalizable, modular approach to decision support in the cloud that could be implemented by many companies instead of duplicating expert resources in every hospital and health information exchange.

Decision Support Service Providers is a concept that is ready for prime time.