Unit 5: Clinical Decision Support Systems

Lecture A will offer a definition of clinical decision support, provide some historical context surrounding clinical decision support, describe the requirements of a clinical decision support system, and discuss the relationship of clinical practice guidelines and evidence-based practice to clinical decision support systems. Lecture B will identify the challenges and barriers in building and using clinical decision support systems, explain how legal and regulatory technologies may affect their use, and introduce the future directions for clinical decision support systems.

Lectures

Lecture A Notes

Slide 1

Welcome to Health Management Information Systems, Clinical Decision Support Systems. This is Lecture a

The component, Health Management Information Systems, is a “theory” component that provides an introduction to health care applications and the systems that use them, health information technology standards, health-related data structures, and enterprise architecture in health care organizations.

Lecture a will offer a definition of clinical decision support, provide some historical context surrounding clinical decision support, describe the requirements of a clinical decision support system, and discuss the relationship of clinical practice guidelines and evidence-based practice to clinical decision support systems. 

Slide 2

The objectives for this unit, Clinical Decision Support Systems are to:

  • Describe the history and evolution of clinical decision support; 
  • Describe the fundamental requirements of  effective clinical decision support systems;
  • Discuss how clinical practice guidelines and evidence-based practice affect clinical decision support systems;

Slide 3

Additional objectives for this unit, Clinical Decision Support Systems are to: 

  • Identify the challenges and barriers to building and using clinical decision support systems;
  • Discuss legal and regulatory considerations related to the distribution of clinical decision support systems; and
  • Describe current initiatives that will impact the future and effectiveness of clinical decision support systems. 

Slide 4

Osheroff, Pifer, & Teich (as cited in Das & Eichner, 2010) stated “CDS provides clinicians, patients, or caregivers with clinical knowledge and patient-specific information to help them make decisions that enhance patient care” (Das & Eichner, 2010, p. 4). Das & Eichner (2010) go on to explain “The patient’s information is matched to a clinical knowledge base, and patient-specific assessments or recommendations are then communicated effectively at appropriate times during patient care” (p. 4).

Musen, Shahar, and Shortliffe (2006) define a clinical decision support system as “any computer program designed to help healthcare professionals to make clinical decisions” (p. 700).

Bottom line, when one hears CDS or CDSS, think of computer-assisted clinical decision-making. 

Slide 5

Computer-assisted clinical decision-making has been considered viable since the late 1950s when initial publications appeared. Then in the late 1960s, the Leeds Abdominal Pain System was created at the University of Leeds. The Leeds Abdominal Pain System was built based on “computer-based decision aids using Bayesian probability theory” (Musen, Shahar, & Shortliffe, 2006, p. 702).

While it is not possible to explain the theory in depth in this short course, it is important to know the theorem is based on rules of predictive probability.  A clinical decision support system may use Bayesian logic in its inference engine. 

Slide 6

Other systems considered to be key in the evolution of clinical decision support systems are MYCIN and HELP, both of which used rule-based approaches.

According to HIMSS, a rule is “A formal way of specifying a recommendation, directive, or strategy, expressed as ‘IF premise THEN conclusion’ or ‘IF condition THEN action’” (HIMSS Dictionary, 2010, p. 105).

MYCIN, which uses a rules-based methodology, is described by Musen, Shahar, & Shortliffe as “…an early exploration of methods for capturing and applying ill-structured expert knowledge to solve important medical problems” (p. 705).

HELP, an integrated clinical information system, has decision rules called “HELP sectors” encoded into it (Musen, Shahar, & Shortliffe, 2006, p. 705). Kuperman, Gardner, & Pryor, (as cited in Musen, Shahar, & Shortliffe, 2006) stated, “HELP has the ability to generate alerts when abnormalities in the patient record are noted, and its impact on the development of the field has been immense, with applications and methodologies that span nearly the full range of activities in biomedical informatics” (p. 705). 

In addition to Bayesian logic and rule-based approaches, the current clinical decision support systems may use other reasoning methodologies such as neural networks or combinations of several methods.

Slide 7

Two Healthcare Information Technology Standards Panel (HITSP) groups convened a meeting with experts in the area of clinical decision support systems and one outcome was the image shown on this slide. As explained by Boone (2006) in his blog,

clinical decision support was “…viewed as a black box, through which we have three different kinds of inputs, and several different types of outputs… The three different inputs include.

  • Algorithms, or knowledge about how to make inferences or assertions based on existing instance or world knowledge.
  • Instance data describing the specific case that is being addressed by the clinical decision support application.
  • Ontological or "world knowledge", representing facts about the world, such as what drugs interact badly, or how body parts are related, or the relationships between genes and diseases” (para. 13).

The output of information, actions, and alerts is characterized by symbols shown coming from the black box representing clinical decision support.

This image of a model is representative of the components of clinical decision support.

Slide 8

As the previous slide showed, a model of a clinical decision support involves certain inputs in order to arrive at an output. Berner (2009) explains the system requirements in the following way: “Common features of CDS systems that are designed to provide patient-specific guidance include the knowledge base (e.g., compiled clinical information on diagnoses, drug interactions, and guidelines), a program for combining that knowledge with patient-specific information, and a communication mechanism—in other words, a way of entering patient data (or importing it from the EMR) into the CDS application and providing relevant information (e.g., lists of possible diagnoses, drug interaction alerts, or preventive care reminders) back to the clinician” (p. 5).

Each component provides a piece that is important for clinical decision support interventions to occur. For example, clinical decision support could provide suggestions for possible diagnoses (knowledge base) that match a patient’s signs and symptoms (inference engine) and communicate this to the provider through a ranked list of diagnoses that might explain the patient’s signs and symptoms (communication mechanism). 

Slide 9

The first system requirement is the knowledge base. A knowledge base is just what you would expect it to be, that is an automated representation of clinical knowledge.

Osheroff et al. (2006) defined clinical knowledge as “A generally applicable fact (or set of facts), best practice, guideline, logical rule, piece of reference information (such as a text article), or other element of information that is important to know for optimal data interpretation and decision-making regarding individual and population health and health care delivery” (p. 59).

The knowledge base is a collection of clinical information on such things as diagnoses, drug interactions, and evidence-based guidelines. Content for the knowledge base comes from internal as well as external sources such as specialty societies, commercial knowledge vendors, and health care organizations. Because of the amount of time and expertise it takes to create content, healthcare providers usually depend on developers of clinical information systems for the knowledge base who often will obtain and incorporate commercial knowledge bases into their CDS products. For example, a number of drug knowledge bases are available in the marketplace. 

Slide 10

The second system requirement is the inference engine. In a clinical decision support system, the inference engine combines the knowledge base with the patient’s data. According to Spooner (2007), “The inference engine is the portion of the CDSS that combines the input and other data according to some logical scheme for output…One such scheme for an inference engine is the Bayesian network… A Bayesian network is a way to put Bayes’ rule to work by laying out graphically which events influence the likelihood of occurrence of other events” (p. 37).

As mentioned previously, in addition to Bayesian logic, clinical decision support systems may use other reasoning methodologies such as rule-based approaches. 

Slide 11

The final system requirement is the communication mechanism. Berner (2009) describes this component as a mechanism for entering patient data into the CDS application and providing relevant information back to the clinician.

One method for input would be importing it from the electronic medical record. Some examples of information that might be output are lists of possible diagnoses, drug-allergy alerts, duplicate testing reminder, drug interaction alerts, drug formulary guidelines, or preventive care reminders.

One of the five rights in the CDS Five Rights model is communication occurs to the right person, that is consideration of all members of the care team, such as the clinician, patient, parent or caregiver, nurse (Sirajuddin et al., 2009, p. 40). 

Slide 12

Given the components of a CDSS, what are some expectations of its use? Berner (2009) provided examples shown in Table 5.1 of CDS interventions by target area of care.

The first row in Table 5.1 states the target area of care as preventive care with intervention examples of immunization, screening, and disease management guidelines for secondary prevention.

The second row lists diagnosis as the target area of care, where clinical decision support could provide suggestions for possible diagnoses that match a patient’s signs and symptoms.

The third row on the list is the target area planning or implementing treatment. CDS intervention could entail the display treatment guidelines for specific diagnoses, drug dosage recommendations, or alerts for drug-to-drug interactions. 

The fourth row, follow-up management, is the target area of care for clinical decision support an intervention might involve information about corollary orders or reminders for drug adverse event monitoring.

The fifth row states the target area of care as hospital or provider efficiency with care plans to minimize length of stay or the presentation of order sets as examples of CDS intervention.

The sixth and final row is the target area cost reductions and improved patient convenience. Examples of CDS interventions include duplicate testing alerts and drug formulary guidelines.

Thus, CDS interventions can assist health care providers at different stages in the care process, that is, from preventive care through diagnosis and treatment, all the way to monitoring and follow-up. 

Slide 13

Osheroff et al. (2006) describes CDS interventions as “…alerts, reminders, and order sets, as well as other techniques for knowledge delivery including reference information and education (delivered with or without context sensitivity), health/clinical protocol and workflow orchestration support, display of context-relevant data, topic-oriented documentation forms, and others” (p. 59). 

Intervention types and examples as summarized by Osheroff (2009) are shown in table 5.2.

While typically several elements from these types are combined in the clinical decision support intervention, each of these intervention types will be examined independently in the next several slides. Drawing from Osheroff, Pifer, Teich, Sittig, & Jenders, (2005) AHRA provides an example of a combination of elements as “an order set might highlight—through a non-interruptive alert—an essential intervention that should routinely be ordered and provide an infobutton link to more detailed reference information that supports the clinical recommendation” (AHRQ, n.d., para 2). 

Slide 14

Each major CDS intervention type results in certain benefits and can be further broken down into subtypes. The benefits of the documentation forms/templates intervention include the ability to “provide complete documentation for care quality/continuity, reimbursement, legal requirements; reduce omission errors by displaying items for selection; reduce commission errors by ensuring critical data—such as allergies—are captured; provide coded data for other data-driven CDS; provide prompts to acquire specific information in the format desired” (Osheroff et al., 2005). 

Subtypes along with examples as summarized by Osheroff et al. (2005) are shown in table 5.3.

Row one lists the subtype of patient self-assessment forms with the example of a pre-visit questionnaire that outlines health problems and current medications.

The second row identifies the subtype of clinician patient assessment forms and an inpatient assessment as its example.

Clinician encounter documentation forms is the third subtype and a structured history and physician examination template is an example.

The fourth row refers to departmental/multidisciplinary clinical documentation forms as a subtype and emergency department document as an example.

The fifth and final row lists data flowsheets as a subtype and the example of a health maintenance/disease management form.

Slide 15

The relevant data presentation intervention has several benefits. They include the ability to “optimize decision making by ensuring all pertinent data are considered and to organize complex data collections to promote understanding of overall clinical picture and to highlight needed actions” (Osheroff et al., 2005). 

Subtypes and examples for this intervention as summarized by Osheroff et al. (2005) are shown in table 5.4.

Row one lists the subtype of relevant data for ordering, administration, or documentation with the example of a longitudinal display of key patient information to highlight trends and issues requiring attention.

The second row identifies the subtype of retrospective/aggregate reporting or filtering and adverse drug event tracking as its example.

Environmental parameter reporting is the third subtype and recent hospital antibiotic sensitivities is an example.

The fourth row refers to choice lists as a subtype and suggested dose choice lists, possibly modified as needed for patient’s kidney or liver function and age as an example.

The fifth and final row lists practice status display as a subtype and the example of ED tracking display. 

Slide 16

The benefit to order/prescription creation facilitators include “promote adherence to standards of care by making the right thing the easiest to do” (Osheroff et al., 2005).

The subtypes and examples for the order/prescription creation intervention as summarized by Osheroff et al. (2005) are shown in table 5.5. 

Row one lists the subtype of single-order completers including consequent orders with the example of suggested drug and/or dose choice lists integrated into ordering function—possibly modified by patient’s kidney or liver function and age. 

Order sets is the second subtype and general order sets such as an order set for hospital admission or problem-oriented ambulatory visit is an example. 

The third and final row identifies tools for complex ordering as a subtype and the example of guided dose algorithms based on weight, body surface area (BSA), kidney function, etc.

Slide 17

The next intervention is protocol/pathway support. The benefit of this intervention is that it “Provides support for multistep care plans, pathways, and protocols that extend over time” (Osheroff et al., 2005). 

As summarized by Osheroff et al. (2005), table 5.6 identifies two subtypes and examples for the protocol/pathway support intervention.

Row one lists the subtype of stepwise processing of multi-step protocol or guideline with the example of tools for monitoring and supporting inpatient clinical pathways (for example, for pneumonia admissions) and multiday/multi-cycle chemotherapy protocols in the inpatient or outpatient setting.

Support for managing clinical problems over long periods and many encounters is the second subtype and computer-assisted management algorithm for treating hyperlipidemia over many outpatient visits is an example. 

Slide 18

"Address recognized information needs of patients and clinicians" (Osheroff et al., 2005) is a benefit of the CDS intervention type, reference information and guidance.

The subtypes and examples as summarized by Osheroff et al. (2005) are shown in table 5.7.

Row one lists the subtype of context-insensitive with the example of a general link from EMR or clinical portal to a reference program (at table of contents or general-search level).

The second row identifies the subtype of context-sensitive and link within patient-messaging application to relevant patient drug information leaflets as its example.

Slide 19

The final intervention is alerts and reminders. The benefits to this intervention include “provide immediate notification of errors and hazards related to new data or orders entered by clinical information system (CIS) user or the CIS itself (such as when abnormal lab result is posted) or passage of a time interval during which a critical event should occur; help enforce standards of care. Effectiveness requires careful attention to workflow, high value of information to end user, and other factors” (Osheroff et al., 2005).

The subtypes and examples for the alerts and reminders intervention as summarized by Osheroff et al. (2005) are shown in table 5.8.

The first row refers to alerts to prevent potential omission/commission errors or hazards as a subtype and drug interaction alert, for example, with drugs, pregnancy, laboratory, food as an example.

Row two lists the subtype alerts to foster best care and the example disease management such as an alert for needed therapeutic intervention based on guidelines/evidence and patient-specific factors.

Slide 20

This image is an example of the subtype alerts to prevent potential omission/commission errors or hazards. The screen shot depicts an example of a CDS drug warning alert. The warning indicates the patient is currently on another drug and to avoid use due to a patient’s possible allergy to cephalosporins. The user has different options to consider, including canceling or continuing with the order thereby overriding the alert. 

Slide 21

As mentioned previously, requirements for clinical decision support include the knowledge base, inference engine, and the communication mechanism. Each component provides a piece that is essential for clinical decision support interventions to occur. Since clinical decisions are made based on the intervention, then the accuracy and reliability of the knowledge base is vitally important.

Clinical best practices and evidence-based medicine are important to the trustworthiness of the knowledge base or its rules and associations of compiled data. Osheroff et al. (2006) explain CDS has the capability of having the scientific evidence and clinical best practices be more available and helpful and “in so doing adds substantially to the value of health information technology such as EHRs and CPOE.  It is only through CDS that EHRs and CPOE can achieve their full potential for improving the safety, quality and cost-effectiveness of care” (p.22). 

Slide 22

Clinical practice guidelines are a foundational part of the knowledge base. The Quality Assurance Project (QAP), funded by the U.S. Agency for International Development, includes a glossary of useful terms. According to Marquez (2001) “Practice guidelines consist of systematically developed statements, usually based on scientific evidence and expert consensus, to assist practitioner decision making about appropriate care for a specific clinical situation” (p. 5).

A similar definition from the National Library of Medicine (NLM) defines a clinical practice guideline as “Work consisting of a set of directions or principles to assist the health care practitioner with patient care decisions about appropriate diagnostic, therapeutic, or other clinical procedures for specific clinical circumstances. Practice guidelines may be developed by government agencies at any level, institutions, organizations such as professional societies or governing boards, or by the convening of expert panels. They can provide a foundation for assessing and evaluating the quality and effectiveness of health care in terms of measuring improved health, reduction of variation in services or procedures performed, and reduction of variation in outcomes of health care delivered” (NLM, 2012).

Clinical practice guidelines are central to determining the care plan for a patient and are considered to be the preferred process for care.

Slide 23

As the previous slide noted, there a number of places where clinical practice guidelines can be located. For example, government agencies, institutions, professional societies, or expert panels may generate them.

Clinical practice guidelines “…can provide a foundation for assessing and evaluating the quality and effectiveness of health care in terms of measuring improved health, reduction of variation in services or procedures performed, and reduction of variation in outcomes of health care delivered. Clinical or practice guidelines usually cite references from a research study whose findings were used to support the recommendations as noted in the guideline” (Becker Medical Library, 2010, para. 2, 3)

Slide 24

The National Guideline Clearinghouse (NGC), a program of the Agency for Healthcare Research and Quality (AHRQ), was formed as a partnership with the American Medical Association and the American Association of Health Plans (now America's Health Insurance Plans [AHIP]). The NGH is a public resource for evidence-based clinical practice guidelines.

The image shown is a screen shot taken from AHRQ’s National Guideline Clearinghouse. It shows a portion of the clinical practice guideline for using nontraditional risk factors in coronary heart disease risk assessment. The source of this guideline is the U.S. Preventive Services Task Force, a federally-appointed panel of independent experts. It is an example of a source for clinical practice guidelines from a government agency.

Slide 25

Clinical practice guidelines which are based on evidence present the strongest case for accuracy and reliability. The National Library of Medicine (NLM) defines evidence-based practice as “A way of providing health care that is guided by a thoughtful integration of the best available scientific knowledge with clinical expertise. This approach allows the practitioner to critically assess research data, clinical guidelines, and other information resources in order to correctly identify the clinical problem, apply the most high-quality intervention, and re-evaluate the outcome for future improvement” (NLM, 2012).

The practice of evidence-based medicine is supported through the provision of clinical decision support systems. As Berner (2009) emphasized, “…the quality of the information and the evidence underlying it are the major determinants of the impact of clinical decision support on patient safety and quality improvement” (p. 7).

The accuracy and reliability of the knowledge base is vitally important since clinical decisions are being made based on the intervention. Clinical best practices and evidence-based medicine are essential to the trustworthiness of the knowledge base. Through the provision of clinical decision support systems the practice of evidence-based medicine is supported.

While guidelines exist, the reality is the availability and utility of useful guideline representations and user interface issues continue as challenges in CDS deployment. 

Slide 26

This concludes Lecture a of Clinical Decision Support Systems. This lecture defined clinical decision support, described system requirements, and explained the effects of clinical practice guidelines and evidence-based practice on CDSS.

Lecture B Notes

Slide 1

Welcome to Health Management Information Systems, Clinical Decision Support Systems.  This is Lecture b.  

The component, Health Management Information Systems, is a “theory” component that provides an introduction to health care applications and the systems that use them, health information technology standards, health-related data structures, and enterprise architecture in health care organizations.

Lecture b will identify the challenges and barriers in building and using clinical decision support systems, explain how legal and regulatory technologies may affect their use, and introduce the future directions for clinical decision support systems. 

Slide 2

The objectives for this unit, Clinical Decision Support Systems are to:

  •  Describe the history and evolution of clinical decision support; 
  •  Describe the fundamental requirements of  effective clinical decision support systems;
  •  Discuss how clinical practice guidelines and evidence-based practice affect clinical decision support systems;

Slide 3

Additional Objectives for this unit, Clinical Decision Support Systems are to:

  •  Identify the challenges and barriers to building and using clinical decision support systems;
  •  Discuss legal and regulatory considerations related to the distribution of clinical decision support systems; and
  •  Describe current initiatives that will impact the future and effectiveness of clinical decision support systems. 

Slide 4

As a framework for supporting clinical decisions to improve outcomes, the CDS Five Rights model states CDS-supported improvements in desired healthcare outcomes can be achieved if communication occurs in the following manner:

“The right information:  Evidence-based, suitable to guide action, pertinent to the circumstance

To the right person: Considering all members of the care team, including clinicians, patients, and their caretakers

In the right CDS intervention format: Such as an alert, order set, or reference information to answer a clinical question 

Through the right channel: For example, a clinical information system (CIS) such as an electronic medical record (EMR), personal health record (PHR), or a more general channel, such as the Internet or a mobile device

At the right time in workflow: For example, at time of decision/action/need” (Sirajuddin et al., 2009, p. 40).

However, achieving the five rights for CDS is challenging. Berner (2009) states “Achieving the five rights for CDS presents challenges, and the challenges differ depending on how closely the CDS is tied to what the clinician already intends to do. Clinicians may initially want certain reminders or, after performance assessments, agree that they need other reminders, but in either situation they are choosing to receive the reminders. The key issue in reminding the user about things they choose to be reminded about is the timing of the reminder. For instance, should reminders for preventive care be given to the physician in advance of the patient visit (e.g., the day before), or should the reminders appear during the patient’s visit” (p. 7-8)?

Slide 5

Clinical decision support systems offer so much potential to improve patient care and outcomes. Similar challenges in designing and selecting clinical decision support systems to the five rights model can be posed as questions. Berner (2009) asked them in the following manner: “whose decisions are being supported, what information is presented, when is it presented, and how is it presented to the user” (p. 6).

Each question should be explored and answered before building or selecting a clinical decision support system. If any are ignored, the chances that end-users will use it and the expected system benefits gained are limited.  For example, consider the question – when the intervention will be presented? Depending on the information, the best time to deliver could be at the point of care—for example, delivering an alert about drug-to-drug interactions at the time of prescribing. Other information, such as providing the names of patients being seen on a given day who need immunizations, could occur prior to the patient encounter. Knowing when the information from the CDS should be presented automatically or “on demand”, i.e., when the user chooses to access the information, is no small feat. Tying the answers to the other questions, e.g., whose decisions are being supported, can also be complex. 

Slide 6

Looking further at the challenge of knowing when the information from the CDS should be presented, that is, automatically or “on demand,” another factor that must be considered and presents its own set of challenges is deciding how much control the user has over the decision to use clinical decision support. In other words control over whether users are required to accept the CDS suggestion, whether they can easily ignore it, or whether it takes significant effort to override the advice.

Berner (2009) explains, “These decisions involve not only whether the CDS is set up to be displayed on demand, so that users have full control over whether they choose to access it, but also the circumstances under which users can, after viewing the CDS information, choose whether to accept it. The two aspects of control are related and they connect with how closely the CDS advice matches a clinician’s intention. CDS may be designed to (1) remind clinicians of things they intend to do, but should not have to remember; (2) provide information when clinicians are unsure what to do; (3) correct errors clinicians have made; or (4) recommend that the clinicians change their plans. Conceived of in this way, it should be obvious that the users’ reactions to CDS may differ with these diverse intents” (p. 7).

Slide 7

Building on to the challenges already described, Table 5.1 summarizes three clinical decision support intents and matches each to a user’s intention along with a key issue. 

The first CDS intent is an automatic intervention – a reminder of actions a user intends to do but should not have to remember. As one would expect, timing is a key issue.

Next under CDS intent is an on demand intervention – one that provides information when a user is unsure of what to do, or a request for consultation. In this instance, it is speed and ease of access that the user is looking for.  According to (Berner, 2009), “Users may recognize the need for information, but may be willing to access it only if they can do so efficiently. If access is too difficult or time-consuming, potential users may choose not to use the CDS” (p. 8).

The third row lists the CDS intent as correct user’s errors and/or recommend a user change plans, and could be either an automatic or on-demand intervention. For an automatic intervention, the key issues are timing, autonomy, and user control over the response. For an on demand intervention, they are speed, ease of access, autonomy, and user control over the response. For this CDS intent, users balance the change planned with the desire for autonomy with other demands such as improving patient safety or decreasing practice costs. Another key issue related to autonomy that was previously discussed is the amount of control users have over how they respond to the CDS. 

Berner (2009) goes on to explain, “While some of these issues have been addressed by research, there are no universally accepted guidelines regarding them, in part because clinicians often differ in their preferences. In addition, there are varying clinical approaches that are justified, which makes designing effective CDS a challenge. How these issues are addressed will influence the ultimate impact and effectiveness of CDS” (p. 8). 

Slide 8

The report, Clinical Decision Support Systems: State of the Art, cited several studies and provided insight into other challenges in the building and using of clinical decision support systems. Discussions were split between the impact on care process and patient health outcomes and the impact on structure.

For the first one, impact on care process and patient health outcomes, the three challenges identified were matching of clinical decision support to user intentions, user control, disruptiveness, and risk, and integration of CDS into work processes.

Each one of these challenges presents issues which need to be addressed when building clinical decision support systems. For example, according to the report, “…integrating CDS into the workflow often requires unique customization to local processes, and sometimes to changes in processes (when previous clinical processes were found to be inefficient or ineffective). CDS also needs to be minimally disruptive to the clinician’s “cognitive workflow” and this, too, can be a challenge. For instance, accessing the data needed for the CDS can be disruptive if the clinical systems are not well integrated or if the necessary data are not in a form that the CDS can use. If the lack of data leads to inappropriate alerts, these alerts may be overridden. In addition, to the extent that using CDS or following its advice is disruptive to the clinician’s work or thought processes, the CDS is likely to be ignored” (Berner, 2009, p. 11).

Another group of discussion points addressed studies on the structural impact of CDS. The conclusion was “It is important to recognize that the development, implementation, and maintenance of CDS will have an impact on the structure or work system in which it will be used. The changes that the CDS will introduce need to be incorporated in the planning so that the impact on clinician time is not excessive” (Berner, 2009, p. 13).

In addition, often IT resources are limited due to implementation of other EHR modules, support of systems already in place, and compliance demands, which causes barriers to CDS deployment. 

Slide 9

There are six barriers to the effective implementation of CDS. The first three identified are:

  • Acquisition and validation of patient data – The issues here are the need to have 1) effective techniques for capturing data accurately, completely, and efficiently and 2) a standardized way to express clinical situations that a computer can interpret Musen et al. (2006).
  • Modeling of medical knowledge – Described by Musen et al. (2006) as “deciding what clinical distinctions and patient data are relevant, identifying the concepts and relationships among concepts that bear on the decision-making task, and ascertaining a problem-solving  strategy that can use the relevant clinical knowledge to reach appropriate conclusions” (p. 713).
  • Elicitation of medical knowledge – keeping the knowledge-base up-to-date is portrayed by Musen et al. (2006) as an important problem for CDSS.

Slide 10

The last three barriers to the effective implementation of CDS are: 

Representation of and reasoning about medical knowledge - Musen et al. (2006) stated “among the ongoing research challenges is the need to refine the computational techniques for encoding the wide range of knowledge used in problem-solving by medical experts” (p. 715). Another part to this is the need to obtain an understanding of the psychology of human problem-solving for use in the development of clinical decision support tools so they more closely reproduce the process by which clinicians move through the diagnostic process (Musen et al., 2006).

Validation of system performance – Here Musen et al. (2006) pointed out issues of having a responsible party for validating the clinical knowledge bases and the challenges in determining how best to evaluate the performance of the tools that use the knowledge particularly when a “gold standard” in which to perform the evaluation doesn’t exist.

Integration of decision-support tools – Musen et al. (2006) state the need for “…more innovative research on how best to tie knowledge-based computer tools to programs designed to store, manipulate, and retrieve patient-specific information” (p. 716). 

Slide 11

One legal barrier to the implementation of clinical decision support systems is the lack of detailed case laws on issues for dealing with clinical decision support systems and under which category of law the systems will fall. Musen et al. (2006) provide the following explanation regarding this barrier: “Under negligence law (which governs medical malpractice), a product or activity must meet reasonable expectations for safety. The principle of strict liability, on the other hand, states that a product must not be harmful. Because it is unrealistic to require that decision support programs make correct assessments under all circumstances—we do not apply such standards to physicians themselves—the determination of which legal principle to apply will have important implications for the dissemination and acceptance of such tools” (p. 731). 

Slide 12

Another legal barrier described by Musen et al. (2006) is the issue of who will bear the liability. Should it be the physicians or the builders of the systems? Musen et al. (2006) state “A related question is the potential liability borne by physicians who could have accessed such a program, and who chose not to do so, and who made an incorrect decision when the system would have suggested the correct one. As with other medical technologies, precedents suggest that physicians will be liable in such circumstances if the use of consultant programs has become the standard of care in the community” (p. 731).  With no case law yet to establish the precedent, recommendations have been for stronger regulation and guidelines.

Slide 13

There are also regulatory barriers that could affect distribution of clinical decision support systems. One identified by Musen et al.  (2006) is the validation of decision-support tools before their release and what role the government should play.

Where should the government fall with regards to prerelease regulations of medical software?  Musen et al. (2006) point out that “Programs that make decisions directly controlling the patient’s treatment (e.g., closed loop systems that administer insulin or that adjust intravenous infusion rates or respirator settings) are viewed as medical devices subject to FDA regulation” (p. 732).

However, the IOM report Health IT and Patient Safety: Building Safer Systems for Better Care did not recommend the FDA, ONC, CMS, or AHRQ as the regulatory body to oversee health IT safety but did recommend the creation and funding of a new independent federal agency, similar in structure to the National Transportation Safety Board (IOM, 2012, p. 128).

Other barriers include data privacy and security. Identifiable data used for research purposes are afforded protections which is one view of what data used for CDS is.  Aggregated data can be used without consent, but de-identification and aggregation of clinical data across systems is difficult.

While there are challenges and barriers, including legal and regulatory ones, in the building, use, and distribution of clinical decision support systems, their benefits such as avoidance of errors and adverse events, are seen as worth the work involved. A description of the various efforts and initiatives are discussed in the next few slides.

Slide 14

Legislative and regulatory efforts needed to support widespread adoption of clinical decision support systems were identified by the AHIC CDS Workgroups.  

As explained in a letter to Secretary HHS Leavitt the recommendations were as follows (AHIC, 2008):

  • Drive measurable progress toward priority performance goals for health care quality improvement through effective use of CDS
  • Explore options to establish or leverage a public-private entity to facilitate collaboration across many CDS development and deployment activities.
  • Accelerate CDS development and adoption though federal government programs and collaborations.

One of these recommendations has been implemented as the next few slides will show. 

Slide 15

There are a number of projects shaping the future directions for clinical decision support systems. These include the Office of the National Coordinator’s initiatives, the Institute of Medicine’s studies, and the meaningful use criteria, objectives and measures. Each will be explored in the slides that follow.

Slide 16

The Office of the National Coordinator for Health IT (ONC), which is charged with coordinating federal efforts regarding HIT adoption and meaningful use, has stated their commitment and facilitated a number of projects for the purpose of moving CDS development and deployment ahead. The major activities include:

The “Advancing CDS” is a project intended to:

“Advance the widespread dissemination of successful CDS implementation practices to promote broad CDS adoption

Improve the acceptance and usability of medication CDS systems through the development of a clinically important drug-drug interaction list

Advance the practical sharing of effective CDS interventions across care settings

Identify CDS-related gaps and goals specific to a broad range of clinical specialties” (ONC, 2011, para. 3).

Another ONC initiative related to CDS includes the report Development of a Roadmap for National Action on Clinical Decision Support that recommended ways to improve CDS development, implementation and use. Three pillars for fully realizing the promise of CDS were identified. They are: 1) Best knowledge available when needed, 2) High adoption and effective use, and 3) Continuous improvement of knowledge and CDS methods (Osheroff, et al., 2006, p.5).

Other projects include the development of CDS recommendations by the AHIC workgroups mentioned previously, an ONC-sponsored Clinical Decision Support (CDS) Workshop, and the CDS Federal Collaboratory.

The final ONC initiative is an Institute of Medicine study carried out under a $989,000 contract awarded in September 2010. The next slide will provide more information on this work.

Slide 17

The Institute of Medicine (IOM) has for many years published key bodies of work. A press release on September 29, 2010  included a quote from Dr. David Blumenthal who at the time was national coordinator for health information technology which explained IOM’s role “Since 1999, when the IOM published its ground-breaking study To Err Is Human, the Institute has been a leader in the movement to improve patient safety” (CMS, 2010).

The To Err is Human report emphasized “…mistakes can best be prevented by designing the health system at all levels to make it safer--to make it harder for people to do something wrong and easier for them to do it right” (National Academy of Sciences, 2000).

The IOM study launched in 2010 was aimed at examining a comprehensive range of patient safety-related issues, including prevention of HIT-related errors and rapid reporting of any HIT-related patient safety issues. IOM saw its charge as “recommending ways to make patient care safer using health IT so that the nation will be in a better position to realize its potential benefits” (National Academy of Sciences, 2011). As mentioned previously, one of the recommendations was the creation and funding of a new independent federal entity that would have the responsibility to oversee health IT safety. Another recommendation was funding a new Health IT Safety Council to set standards for safety.

Slide 18

The final endeavor having an impact on future directions for CDSS is the American Recovery and Reinvestment Act or ARRA and the associated Health Information Technology for Economic and Clinical Health (HITECH) provision. ARRA, officially Public Law 111-5 signed into law February 2009, provides many different stimulus opportunities, one of which is $19.2 billion for health IT. HITECH is a provision of the American Recovery and Reinvestment Act. The HITECH section of ARRA deals with many of the health information communication and technology provisions.  It established programs under Medicare and Medicaid to provide incentive payments for the "meaningful use" of certified EHR technology.  According to the Centers for Medicare and Medicaid Services (CMS, 2011), “The Medicare and Medicaid EHR Incentive Programs will provide incentive payments to eligible professionals, eligible hospitals and critical access hospitals (CAHs) as they adopt, implement, upgrade or demonstrate meaningful use of certified EHR technology” (para. 1).

On July 13, 2010, the Secretary of HHS published in the Federal Register a final rule that adopted standards, implementation specifications, and certification criteria for HIT. The final rule was released in conjunction with the Medicare and Medicaid EHR Incentive Programs final rule. The CMS regulations specify the objectives that providers must achieve in payment years 2011 and 2012 to qualify for incentive payments. The ONC regulations specify the technical capabilities that EHR technology must have to be certified and to support providers in achieving the “meaningful use” objectives.

Following are meaningful use requirements that must be met to qualify for incentive payments (CMS, 2010, p. 44350):

  • For the eligible professional: Implement one clinical decision support rule relevant to specialty or high clinical priority along with the ability to track compliance with that rule.
  • For the hospital: Implement one clinical decision support rule related to a high priority hospital condition along with the ability to track compliance with that rule 

Slide 19

This concludes Clinical Decision Support Systems. 

Lecture a defined clinical decision support, described system requirements, and explained the effects of clinical practice guidelines and evidence-based practice on CDSS.

Lecture b described challenges and barriers, including legal and regulatory ones, in the building, use, and distribution of clinical decision support systems. To move forward requires further effort. A number of projects shaping the future directions for clinical decision support systems have come to fruition in the last few years, and more initiatives are underway. These include the ONC initiatives and the meaningful use requirements tied to clinical decision support.

You need to be a member of Health Informatics Forum to add comments!

Join Health Informatics Forum

Search

Advertisement


Advertise on the Health Informatics Forum