| Sign In to gain access to subscriptions and/or personal tools. |
© 2003 SAGE Publications Decision Support at the Point of Care: Challenges in Knowledge Representation, Management, and Patient-specific AccessPresented at "Dental Informatics & Dental Research: Making the Connection", a conference held in, Bethesda, MD, USA, June 12–13, 2003, sponsored by the University of Pittsburgh Center for Dental Informatics and supported in part by award 1R13DE014611-01 from the National Institute of Dental and Craniofacial Research/National Library of Medicine.
Decision Systems Group, Brigham and Women’s Hospital, Harvard Medical School, Boston, MA 02115; greenes{at}harvard.edu
Many applications in a clinical information system can benefit from the incorporation of medical knowledge to provide patient-specific, point-of-care decision support. These include computer-based provider order entry, referral, clinical result interpretation, consultation, adverse event monitoring, scheduling, shared patient-doctor decision-making, and generation of alerts and reminders, among others. To be executable, knowledge must be represented in the form of rules, constraints, calculations, guidelines, and other logical/algorithmic formats. The main difficulty is that the integration of such knowledge into clinical applications, when it occurs, tends to be very system- and application-specific, often encoded in a programming language, or even in the formating specifications of a user interaction display. Also, the data references and services invoked are highly dependent on the system/platform and electronic medical record implementation. This makes it difficult and time-consuming to encode authoritative evidence-based knowledge, severely limits the ability to disseminate and share successes, and hampers efforts to review and update the logic as medical knowledge changes. Solutions to this problem involve the development of standards-based representations for medical knowledge, and tools for authoring/editing, dissemination, adaptation to local environments, and execution. Numerous approaches are being pursued, all of which will be described in this presentation.
Key Words: Clinical information systems • decision support • quality • error reduction • knowledge representation • clinical practice guidelines
There has been a paradigm shift in clinical information systems. Formerly, the foci of development were the electronic medical record, information retrieval and reporting, scheduling, and various communications functions, as well as financial and billing applications. Over the past decade or so, however, emphasis has shifted increasingly to cost-effectiveness, error prevention, safety, and improvement of health care quality. This has required a new emphasis on incorporating executable knowledge and point-of-care decision support into clinical systems. Acquisition, encoding, and management of the underlying knowledge bases have thus become imperative, and tools for facilitating the process have become essential. This requirement has stimulated increased attention to approaches to sharing and standardization of knowledge.
Decision support depends on high-quality, evidence-based medical knowledge. Ideally, this knowledge must be integrated into the process of care and delivered at the point of need in a patient-specific manner. Yet, in the process, the knowledge must still be able to be reviewed, inspected, and updated by domain experts as needed. This imposes several requirements, since there is a wide variety of clinical systems, with different platforms, architectures, and included applications, and the manner of integrating the knowledge into them varies. How does one achieve the dual goal of tight coupling of knowledge and ease of update and management of the knowledge by experts? In this paper, we will discuss some of the kinds of successes in the use of knowledge for decision support (the first goal) and the approaches that have been pursued to manage the knowledge (the second goal). As the reader will note, there has been much more success with the former than with the latter. Reasons are mainly that, to date, the burden has been largely on demonstrating that the use of knowledge for decision support was feasible and cost-effective, with less concern for long-term management. Yet as the applications have been shown to be beneficial, developers have gone on to yet other applications rather than re-engineering already successfully demonstrated ones for ease of management. The only way to achieve both goals is to use consistent standards-based methods for representing the knowledge, developing authoring tools that manage the knowledge in this form, and also developing methods for integrating the knowledge in this form into different host platforms. For knowledge to be effectively integrated into clinical information systems, it needs to have certain qualities that enable it to be evaluated in and applied to clinical settings. How do we get there? The processes of acquisition, documentation, and updating of knowledge are difficult, even when dealing with non-executable content, in terms of the tasks of evaluating the evidence, synthesizing it to develop the knowledge, organizing and indexing it, retrieving it when needed, and updating it on a timely basis. This problem becomes substantially more difficult if we further require that the knowledge be executable. It is even more problematic to adapt knowledge to particular settings, in terms of modifying its representation for the application contexts in which it will be used, platforms in which it will be executed, and local constraints or requirements that may alter its interpretation. Unfortunately, because the traditional focus of clinical information systems was not on the problems of knowledge management and decision support, and because a plethora of systems has evolved with differing platforms and limited embrace of standards, there is no strong base on which to build a knowledge management framework. Nonetheless, several achievements to which we can point are beginning to show the promise of this capability. I will illustrate the issues with the process we have pursued in developing a sharable representation for clinical guidelines, and its status and challenges. I will close with a model and a potential agenda for action.
Motivations for incorporating decision support are manifold. Here are a few key factors:
The 2001 IOM report Crossing the Quality Chasm focused on the nature of our system of health care, and the issues that must be addressed to improve safety and quality, identifying six precepts for health care in the future, namely, that the health care system must be: safe, effective, patient-centered, timely, efficient, and equitable (Richardson, 1999). Additionally, regulations and legislative initiatives have been aimed at improving patient safety and quality of care, such as adverse event reporting to patients, mandated by the Joint Commission on Accreditation of Healthcare Organizations (JCAHO). There have also been moves to increase accountability in health care practices and outcomes, which fortunately have some promising market potential. The Leapfrog Group, a corporate-sponsored consortium that promotes patient safety, has sponsored initiatives on computerized physician order entry and evidence-based hospital referral (last accessed March 2004). California State Senate Bill 1875 (2000) mandates order entry for computerized prescriptions by January, 2005. The bill requires that all general acute care hospitals, surgical clinics, and special hospitals adopt a formal plan to eliminate or substantially reduce medication-related errors.
All of the aforementioned changes are beginning to generate activity to improve patient safety and quality of care. Some of the new mandates, however, do not yet have the supportive infrastructure needed. Although several experiments around the United States, primarily in academic centers, have begun to demonstrate the success of computerized physician order entry, alerts and reminders, appropriateness criteria, and guidelines, in reducing errors, increasing efficiency, and improving quality, the successes have remained isolated and difficult to replicate broadly. In our own health care system, Partners HealthCare is the integrated delivery network that is the parent of Massachusetts General Hospital and Brigham and Women’s Hospital (BWH), as well as several community hospitals and practices in Eastern Massachusetts. The Partners clinical information systems have received considerable attention. The Brigham Integrated Computing System (BICS), for example, is a very comprehensive, feature-laden system (Teich et al., 1999). BICS has an elaborate computerized physician order entry (CPOE) system, which provides timely warnings, advice and information about conflicts and drug interactions, and recommended changes for elderly patients or those with renal insufficiency. Alerts and reminders about abnormal results or other significant clinical events are provided (Kuperman et al., 1997). Studies of the efficacy of error-checking, alerts, and reminders in the CPOE system, by Bates and colleagues (1998), have demonstrated a considerable decrease in medication errors, a decrease in redundant labs, and more appropriate care of renal patients, with associated decreases in costs. Making progress in the adaptation of clinical guidelines for clinical practice has been more difficult. Guidelines have been around, of course, for decades. Recent efforts have focused on computer-based implementation of guidelines so that they can be interpreted and delivered at the point of care, with the ultimate goal of integrating them into applications that deliver patient-specific recommendations (Shiffman et al., 1999). An executable guideline representation can serve as a core technology for a variety of applications—to drive decision support, consultation, alerts and reminders, clinical protocols, utilization review rule triggering, and a range of workflow-oriented applications. This versatility is because the guidelines describe the decision logic and the process flow that must occur for integration into any application to be effective. Although investigators have been working steadily in this area and are seeing some improvements, this is still at a very early stage. As noted earlier, a formidable impediment to integrating knowledge into clinical information systems is the abundance of hard-coding or ad hoc representation of the knowledge, which is not easy to maintain or adapt. The knowledge is embedded into many systems rather than being separate so as to facilitate authoring, editing, and updating. These issues have been true at Partners’ systems as well as most other hospital-based and commercial information systems. The successes, failures, and other practical experiences of systems like that at Partners have thus been difficult to extract, generalize, and replicate where positive. Commercialization attempts have been difficult, and there is very little sharing and re-use of successfully engineered knowledge bases.
Given the slow pace of progress and yet the importance of the focus, it is timely and necessary to examine the process of knowledge management. Political, financial, cultural, and technical forces all need to be marshaled to make this happen. The National Health Information Infrastructure (NHII) report from the National Committee for Vital and Health Statistics (NCVHS, 2001), which provides a blueprint for universal standards, and an Office of the NHII now exist in HHS, responsible for leading the charge toward development of an NHII. The CDC (2002) has a National Electronic Disease Surveillance System, which also provides standards for uniform data collection. The national Patient Medical Record Information (PMRI) dataset that is called for by the NCVHS report, and also comes under the HIPAA regulations, will begin to set the stage for identifying some areas where we can collaborate. But this doesn’t really get us to the point where we can deliver these capabilities to operational clinical information systems.
Since guidelines can be considered a particular form of knowledge, the applications that will use them may be very different from one another. They may be rule-triggered, event-triggered, driven by a workflow model, or dialogue-driven. Thus, implementing a guideline is far more than encoding the decision logic and process flow. It is not easy to go from a flowchart to something that has a well-designed user interface for a patient or for a doctor. The National Guideline Clearinghouse has a growing collection of guidelines available online through its Web site (2004), but most if not all of them are not executable. If we could move to the next step with executable components or a standard format for representation, then when an implementer needs to build an application—for example, to deliver patient-specific advice about hormone replacement therapy—an executable guideline would exist that could be used as a basis for that. The implementer could then concentrate on the user interface, the connections to local resources, and other support functions that make the application unique, but base the implementation on the best available knowledge, in a form that can be interpreted with unambiguous results.
My group at Harvard worked with colleagues at Stanford and Columbia in a project funded by the NLM, the US Army, and AHRQ, known as the InterMed Collaboratory to develop the GuideLine Interchange Format (GLIF). GLIF was intended as a format for the sharing and dissemination of executable guidelines. Our experience in this process illustrates some of the challenges that must be faced in creating an NHII. With GLIF, guidelines are developed in sharable form, and then imported and executed within proprietary environments by adhering to standards. Consider a simple guideline for flu vaccination, as shown in Fig. 1
Several groups have been involved in building guideline models, based on particular intended applications or uses that determined the functional requirements; as a consequence, each has its own representation and its own authoring environment. Through InterMed, we explored the issues of supporting the different kinds of models, and the kinds of applications that were motivating them. GLIF was developed as an attempt to select the most important features from all those models to develop a sharable means for dissemination of guidelines that would have the broadest ability to be utilized in the various modeling environments. The initial released version of GLIF was known as version 2.0 and was not specified to the extent necessary for it to be executable (Ohno-Machado et al., 1998), although it stimulated several projects to incorporate guidelines into clinical systems. The further development of GLIF as version 3.0 (Peleg et al., 2000) added several features to facilitate executability, among other changes. Several different approaches exist for authoring of computer-interpretable guidelines, ranging from mark-up of narrative guidelines and extraction and encoding of steps to using templates or graphic authoring tools to encode guidelines and decision logic directly. As part of the authoring phase, note that a testing and validation process must be included to ensure that the logic is correct, that the data references are valid, etc. Testing and validation are followed by a dissemination phase where the generic guideline representation is exported—for instance, in XML or another agreed-upon format. As noted earlier, GLIF uses RDF, since it provides ontology support not available in XML itself. With respect to implementation, guidelines must address a variety of platform-specific features and constraints. Not only are there differences in vendor systems and in target applications, but even within similar applications in which guidelines are to be embedded, vendors have "architected" them differently. In addition, the target sites themselves have different resources and settings, as a result of which the guidelines need to be adapted to those realities and to preferences. A limiting factor in the implementation of guidelines is the paucity of experience demonstrating their effective integration in clinical practice. If there is a best practice that is represented by a guideline, somehow we ought to be able to build systems that implement or foster that behavior. But whether we deliver this as a recommendation to a doctor or a demand, or if the guideline influences what elements pop up on-screen first, there are many possible ways that may be effective and others that are ineffective, irritating, or otherwise counterproductive. That is why we need an ongoing process of experimentation and feedback. We need to build guidelines into applications to see what works, and then determine from that experience how the model should be refined, whether new features are required, and how the authoring tools should be modified to make that kind of application easier to support. Two kinds of changes may be required as a result of the evaluation: (1) Depending on feedback and experience, the process for modeling and authoring of guidelines may need to be changed to facilitate incorporation of positive features and elimination or improvement of negative ones; and (2) medical knowledge changes, as a result of which the guidelines themselves must be updated.
Considering these tasks together, we view GLIF as facilitating a life-cycle process (Greenes et al., 2001) for guideline modeling, authoring, dissemination, implementation, and experience with use (Fig. 3
In recognizing the need for identifying common elements of the various modeling efforts, we moved GLIF under the auspices of the Health Level Seven (HL7) standards development organization, so as to be able to address standardization with the broadest possible participation. An HL7 Clinical Guidelines Special Interest Group (SIG) was formed in September, 2000, as part of a Clinical Decision Support Technical Committee (TC) (2004). The TC also includes the Arden Syntax SIG. As a result, guideline developers work with Arden developers in developing common approaches where feasible. Through this activity, we found that the best way to proceed is not to emphasize agreement on an overall model, but rather to decompose the problem. Every guideline modeler needs to deal with certain tasks, such as referencing patient data, conducting queries, and forming decision logic expressions. They all need vocabulary tools, and they need to represent process flow and workflow. Thus, the focus of the Clinical Guideline SIG and the CDS TC is on those components, rather than on an overall guideline model. Examples are the following:
The purpose of the above tasks is to break down a larger problem, on which agreement is more difficult, into smaller components that could become industry building blocks which could be used by all parties in building their models and implementing their systems.
I believe that the life-cycle approach described above, for evolution of a sharable guideline representation, together with the consensus-building standardization process for formalization of key components, constitutes an appropriate framework for the process of broader electronic knowledge management. A huge investment is required to generate high-quality evidence-based knowledge in a form that is ready to be integrated into applications. There are many settings and applications in which knowledge could be potentially useful, yet the efficacy of most is unproven. Thus, we need a life-cycle process similar to that described above for sharable guideline representation, to facilitate experimental activity aimed at implementation of applications using knowledge and their evaluation. Further, to achieve a common framework for this process will require, as it has with the guideline effort, a focus on component elements. To move this process forward requires, in my opinion, a broad consensus and funding supporting it. Once the priorities have been identified, we can focus on building the tools and knowledge resources that are needed. With a joint effort, a knowledge inventory would be the basis for a comparison, to establish a consensus on a set of priorities that all or most of our systems need, and we could then focus on the knowledge components for the next generation of clinical information systems.
Health-care quality is finally becoming a priority. There are numerous examples of successful approaches that demonstrate the benefits, yet we face many impediments to widespread experimentation, dissemination, and adoption. We need a concerted effort to integrate executable knowledge, necessary for decision support, in our clinical systems, and to be able to maintain that knowledge. Regulations and legislation requiring quality and safety functionality are being enacted, but if the tools and infrastructure are not capable, the ability to respond will not exist. We need to reach a point in which we actually share the knowledge, the tools, and the experiences to enable these problems to be addressed in a concerted manner. This requires a joint activity of academic, vendor, health provider, payer, and public policy sectors.
This paper is adapted from Greenes RA (2003). Developing a shared agenda for health care systems safety and quality. In: Information Technology Business Models for Quality Health Care: Am EU/US Dialogue. Krishna S, Balaas A, Boren SA, editors. Proceedings, Conference: From Best Practices to Quality Patient Care. Columbia, MO, May, 2002. Amsterdam; IOS Press, pp. 73–84.
Publication supported by Software of Excellence (Auckland, NZ)
Advances in Dental Research, Vol. 17, No. 1,
69-73 (2003)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
|
 |
|
Sign In to gain access to subscriptions and/or personal tools.
TOP
Abstract
Introduction
