Tuesday, June 22, 2010

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.

9 comments:

Joel Amoussou said...

The HL7 Decision Support Service (DSS) Specification defines a functional model for service-oriented CDS capabilities.

Pete said...

The National Parkinson Foundation (where I'm CIO) is deploying a system to provide CDS across its center of excellence network. Our system's guidance will be based on continuous outcomes data collection with monthly review and annual updates.

Benjaloo said...

Fascinating model.
I agree wholeheartedly that we should be using validated or consensus standards for decision support, rather than every health system re-inventing the proverbial wheel.

I'm curious, though, about this model of decision support as a service, vs another model: developing a standard language for decision support that is supported by many different EMR systems internally. Then the decision support rules could be developed nationally by specialty societies or federal agencies and embedded within the EMR locally. The EMR would have to provide some infrastructure to do the decision support, of course. This wouldn't require patient data to be transmitted to a service provider, which seems an unneeded security risk, albeit one that can be reduced by encryption. Of course, it means there is a different business niche for the decision support service provider (formulating and collating the rules, working with EMR vendors to make their systems compatible with the standard language).

Can you comment on these two ways of approaching decision support?

Many thanks for your thoughtful blog which I enjoy reading.

__________________________________

Benjamin A. Kruskal, MD, PhD, FAAP, FIDSA
Pediatrics and Pediatric Infectious Diseases
Director, Infection Control and Travel Medicine
Harvard Vanguard Medical Associates

John Halamka said...

The data sent to the decision support service provider does not need to be disclosing i.e. 30 male, creatinine 3.0, takes an ACE inhibitor is all that is sent.

Creating an engine that crosswalks all the data into standard vocabularies and executes thousands of constantly changing rules takes millions of dollars of effort and engineering. It would be challenging to replicate that in every EHR, hence the reason a service makes sense.

Brian Ahier said...

You can watch the Leiter Lecture online here:

http://videocast.nih.gov/summary.asp?Live=8601

Monty Islam said...

Great initiative by Anvita

Healthcare is behind as far as delivering care as services – IT services. It is not possible for majority of the healthcare service provider, especially for the small, rural, and private care provider to implement, and maintain any kind of CDS systems, including practice guidelines. Service base solution make sense given pricing model is favorable and importantly services are easily discover and consumable. In my opinion, this kind of services should be financially supported by the Federal government.

Point I want to make regarding ‘Anvita’s local dictionaries” – as long as service consumer (the user of the services) do not have to encode there data – part of the XML message – based Anvita’s local dictionaries, then this should not be Ok – service suppose to be a black box. Only concern will be how quickly Anvita’s will be adopt or make changes when external vocabulary sources will change.
On the other hand, if service consumers need to use Anvita’s code, then the users may become dependent or tightly coupled with Anvita’s services, even though the technically service is provided as web services.

Chris Longhurst, MD said...

I could not agree more with the proposed framework. Integrating CDS into client EMR systems is an antiquated approach. My only question is whether the service should be hosted by commercial vendors or the federal government? For example, the AHRQ could host a Joint Commission compliant ruleset for quality/safety, while the CDC hosts a standard set of immunization rules.

TimCook said...

You can see decision support as a service proof of concept implemented in 2004-2006. But alas, funding ran out and there was no interest to maintain it at the time.

Tim Cook - Principle architect
EGADSS http://sourceforge.net/projects/egadss/

We are also implementing decision support on top of the Open Source Health Information Platform The same concepts as EGADSS but slightly modernized using XML. See: http://www.mlhim.org & http:www.oship.org

chunlan said...

Thanks John. I do like the idea that the clinical data sent to a decision support service doesn't need to include patient identification data.

Using decision support service approach across enterprise boundaries may not be feasible since it not only requies standard decision support model and same terminology set, but also standard decision rules. Additionally, significant changes are also required to the existing systems to be able to communicate with the service.

In my understanding, different decision support systems may use different representations for clinical guidelines, and rules etc for some good reasons. There are two big issues that decision support systems are facing: 1) clinical data model is different from system to system. This issue requires great effort to even deploy an existing decision support system to an existing EHR system, maintainance might be a nightmare. 2) terminologies are different from system to system. It is a big challenge to map the terminologies.

I personally do think that openEHR approach will help to define clinical content and terminology term sets. If a decision support system is able to work with openEHR data model, all existing EHR systems' clinical data only needs to be mapped to openEHR data model. It would increase the maintainability and extensibility. More importantly, with the use of Archetype Query Language, sharing decision support clinical guidelines and rules is achievable.