The power and value of embedded clinical decision support--Part 2.

CLINICAL DECISION SUPPORT DIFFERENTIATORS

Alerts--Know What Makes Them Work

As previously noted, in today's generation of sophisticated clinical decision support and the power of intelligent rules to drive the logic behind embedded clinical decision support, it is no longer adequate to know just that a system has "alerts". If you are evaluating a clinical information system and that's all you've been told or know, you need to drill down to a greater granularity of detail. Specifically, you need to know these eight essential things:

* WHAT makes the rule fire (order, note, lab result, etc.)?

* WHEN does the alert fire (fire before or after the order is committed to the database)? Can the alert fire off data in another ancillary system BEFORE the order goes to that system? This is "call foreign function" capability or does the data have to be in the CIS master database for the alert to fire.

--The "fire before order commit to the database" function has huge impact on workflow if the alert does not fire until after an order is committed to the database. That means the order then has to be modified or cancelled to accommodate the changes from the alert. If the alert fires before "order commit" the changes can be made in the first iteration of the order.

* HOW does the rule get to the user (real time, slightly delayed or not until device is docked)?

* ANY escalation intelligence or forward chaining of rules?

* SUPPORT for algorithms and protocols?

* Can the product SHARE rules between products and vendors (is it written in industry-standard language)?

* Is the alert engine capable of using MULTIFACTORIAL logic in clinical decision support before an alert will fire to the user?

--A multifactorial knowledge engine means that the clinical decision support system's rules engine can accommodate many "factors" being involved in processing the clinical decision support. These factors can be lab results, problems, patient-specific observations or vital signs or protocol, where a combination of factors creates the logic needed to determine whether or not an alert needs to be fired under a set condition.

* Does the product have the ability to TRACK alerts and CAPTURE data for alert outcomes and statistics?

CONCLUSIONS

When you collect a vast amount of information on the strategy of product development from the language platform to the what/where/when of clinical alerts, you begin to see how they "match up" to an assessment of a clinical decision support and knowledge-driven clinical information system. A generic "scorecard" to use to evaluate vendor products. This

scorecard can "rate" how much knowledge-driven insight is embedded within an HIT company's product line, mission, vision and clinical strategy of product development.

The value of using non-proprietary "rules" within a vendor product is that rules then become "vendor-neutral" and can be shared from product to product as long as they are written in the industry standard for Medical Logic Modules, Arden syntax. Once vendors and healthcare organizations begin "sharing" the knowledge of expertise regarding the rules, through organizations such as The Institute for Medical Knowledge Implementation (IMKI), disease management will be at a level never previously achieved. But a warning - you must be able to "give" and "receive" this knowledge in a platform that is "sharable". Beware of "vendor babble" that they have rules that are "Arden syntax like" or "work just like" Arden syntax. Those rules are unlikely to be sharable in a vendor-neutral way. Clearly, with the complexity and multiple levels of alerting available today, it is no longer sufficient to know that a clinical information system under consideration has alerts. It is the vendor's responsibility to provide an explanation of exactly WHAT kind of alerts they provide so the customer understands the complexity offered in the advanced- and expert-level alerts. If the vendor does not supply that information proactively and willingly, ask pointed and specific questions. When you gather and understand that level of detail, you can TRULY know the power within the clinical information system and what it can do to support your organization's goals of enhanced quality, cost-effectiveness and patient/customer satisfaction. Insist that the vendor give you a detailed account of the eight essentials to know about clinical decision support and get satisfactory answers to these questions.

Based on fundamental principles of management control, retrospective decision support enables healthcare organizations to apply those principles to all areas of focus, including processes, cost, revenue, utilization, and outcomes. By facilitating the process of organizing data from disparate sources into actionable information, clinicians and managers are given the tools they need to affect organizational change. Providing alerts and warnings either at the point of order entry or with collection of other clinical data based on retrospective analysis data is key to improving quality at the point of care and reducing cost.

As noted by Jonathan Teich, MD, PhD, a recognized expert on the subject of clinical decision support--"Clinical decision support systems can help physicians provide better care for patients and make their practices more efficient." (1) These are exciting times ahead, as we address the challenges presented in "To Err is Human" and beyond.

By Robin Raiford, BSN, RN, BC This is a continuation from the last newsletter.

(1) Teich, J., Wrinn, M. Clinical Decision Support Systems Come of Age. MD Computing 2000 Jan/Feb 17(1) Available online at: http://mdcomputing.com/issues/v17n1/clinical_dec.htm