|
|
|
|
|
|
|
|
|
Root Cause AnalystTM |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Software Facilitation of Sentinel Event and Root Cause AnalysisThis document is an elaboration of a chapter we were asked to author in a book edited by Patrice Spath, of Brown-Spath & Associates, the title of which is Error Reduction in Health Care. IntroductionValue of Software Facilitation Critical Features
Introduction. We are all well acquainted with the ongoing pressures in the health care industry to continuously improve patient care and patient satisfaction, while simultaneously reducing costs. The failure to succeed with these at times antithetical goals spells economic failure for any health care facility or organization, with the concomitant loss of the health care services provided by that facility or organization. Progressive medical centers have been fortunate in having accepted this reality as an essential component of their driving philosophy in advance of the severe economic forces now existent; their continuous improvement programs have long, well-established and well-supported histories. With the requirement to perform root cause analyses on sentinel events, that continuous improvement effort has been expanded to include this complex of analytic processes which is new to health care systems, but respected and accepted in a variety of industrial risk management areas, including the energy and transportation industries. While, however, root cause analysis is a set of quality tools used in combination, there are various formats for their use; there is no one way to perform a root cause analysis. The JCAHO is very appropriately stressing a team approach to conducting such an analysis. This can represent, though, a very major expense in both training and in practice. And since it is likely (and hoped) that no particular group of individuals would have to conduct other than an infrequent root cause analysis, one should not count on a significant practice effect. Additionally, establishing a standardized process for performing any task has distinct advantages in terms of consistency, reliability, quality and economy. Software facilitation of root cause analysis would thus offer a number of advantages. For our consulting, we therefore identified a set of features we felt were important for a software product to effectively facilitate a root cause analysis team, and then evaluated a number of such products against those criteria. The following presents those features we felt were important to us, some justification for those choices, and the results of our product evaluation.
Value of Software Facilitation. As with any endeavor in which there are sequential and iterative steps to be followed, a standardized process by which that procedure or set of procedures may be enacted generally adds value in terms of both validity and cost-effectiveness. Flowcharting such processes has become commonplace as part of many continuous improvement activities. Automation of these processes has advantages of data storage, data manipulation, and process guidance in many such applications. Potentially this would be true for root cause analysis. Cost avoidance is an important additional consideration. We estimate that a typical root cause analysis performed in an appropriate team format will cost approximately $8,000 in direct salary costs, and considerably more when indirect costs for lost clinical service availability, support services, etc. are added. The first case on which we were consulted by an outside agency had cost approximately $13,000 in direct salaries expenditures and $23,000 in lost revenues at the time we were consulted; the analysis was less than half completed at that time. It rapidly became clear that a standardized process which was easy to follow had to be developed, or for cost reasons alone root cause analysis would be performed in a pro forma manner to satisfy regulatory requirements, with minimal impact upon patient care. In this age of medical malpractice litigation, an adverse event with a poor outcome could easily invite a malpractice lawsuit from an injured and angry patient. A well done, credible root cause analysis can be very valuable in not only mitigating loss with professional liability claims, but can assist planning for the defense of a malpractice suit against the named practitioner and/or the healthcare organization responsible for the patient's care and safety. The healthcare organization's legal team could be greatly assisted in preparing and presenting their defense. We have observed hospital attorneys encouraging the performance of a root cause analysis in response to an adverse event or outcome. Since automation of a root cause analysis can theoretically produce consistently higher quality analyses, stronger defensive postures can be formulated, with consequent decreased risk of resource losses. In non-health care industries there exist an assortment of software packages designed to facilitate all or part of the root cause analysis process, though a variety of nomenclature exists (fault tree, failure mode, etc). Products range from those offering a single focus (for example, factor and impact weighting in an otherwise completed root cause analysis) to those which purport to guide users through an entire root cause analysis from problem statement to solution impact assessment. Given the very limited level of sophistication as regards root cause analysis in the health care industry, and the urgency with which that industry is being "encouraged" or indeed mandated to embrace this continuous improvement tool, it is the latter end of the spectrum which is most desirable. An ideal software product would guide an essentially untrained or minimally trained analysis team through each step of the root cause analytic process. We decided to attempt to identify a software product to facilitate and/or enhance the effectiveness and efficiency with which root cause analyses were conducted. This decision was made after our first root cause analysis was completed. We found the JCAHO manual ("How to Conduct a Root Cause Analysis in Response to a Sentinel Event") to be useful and helpful as a starting point in learning about the analytic process. Enormous difficulty was encountered, however, in translating this into efficacious, efficient and cost-effective standardized procedures. This is compounded by the variety of tools used in the performance of root cause analyses. We feel that the use of software-guided or software facilitated root cause analysis would offer advantages in a number of realms. If the process of conducting a root cause analysis could be standardized, greater efficiency would result. This does not require automation; a systems analysis and well flowcharted process would offer similar gains, to wit, a consistent analytic procedure. However, a well designed program would eliminate the need to perform such an systems analysis, and similarly eliminate the need to flowchart a process with which we were relative novices. Data organization and collection would be simplified were a program designed to accommodate, for example, a relational database structure which allowed for data collection, analysis and review. Report generation could flow from both the process itself and the reporting needs of the facility and the regulatory agencies involved. Ideally, a software product would be able to guide the development of output which would meet these reporting needs without violating the integrity of the data or the analytic process. Taken together, a product would potentially decrease learning time, shorten the analytic process, increase validity of the process by providing an external expertise and by instilling procedural consistency, facilitate collection, analysis and presentation of data, increase the depth of study and guide the production of meaningful reports, including post-analysis monitoring. We therefore identified a series of requirements for the product we wished to acquire. Those requirements were unique to the needs of our practice and the facilities to which we consulted as we perceived them, and they evolved as we became more knowledgeable about root cause analysis. In their latest iteration, they are offered below. The reader is cautioned, however, that these desired (or required) features will vary as a function of the specific needs of any given facility or group of users.
Windows-Compliance. We felt it unreasonable to assume that a root cause analysis program would also possess a fully featured word processor (like Word® or WordPerfect®) and presentation capability (like PowerPoint® or Presentations®). Windows compliance with full support for drag-and-drop interface was felt to be necessary, else one would be frequently retyping content into other programs. Given operating system development and migration expectations, the software would have to operate under Windows® 95a, 95b, 98, NT. For ease and flexibility of use, full OLE (object linking and embedding) capability, standard Windows controls, etc., were felt to be necessary. Thus, for a number of reasons, we concluded early on that full Windows-compliance not just graphic user interface with Windows emulation) was necessary. Ease of Use. While Windows-compliance would be one major factor facilitating ease of use just by familiarity of controls, the overall structure of the program and the logic of the "data flow" had to be intuitive. The typical user would be an infrequent participant in root cause analyses, and would not able or willing to spend significant time learning basic software functionalities. To ask that the typical user read a manual was not felt to be realistic, and this finding is in keeping with patterns observed in users of most new software developed today. The norm is a "Quick-start" guide or equivalent, supported by on-line help and a rarely used manual. In a hospital setting relatively few persons would be working with the software on a regular basis, since the team performing the root cause analysis would be different for each sentinel event. Intuitive ease of use is felt to be critical. Data Entry. A special feature of ease of use is the requirement that a given bit of data should require being entered only once. As the user progresses from one module to another, data elements should be automatically carried forward, thereby minimizing redundant data entry. Additionally, the software should not unduly limit the length of any given data field; data fields should allow entries with a minimum of 250 characters in length, even in the graphic module(s). Philosophy. Given the resistance which would be encountered regarding the performance of root cause analyses in any form, it was considered critical that the software in no way increase that resistance. In practical terms, this means that there should be nothing in the program flow which conflicts with the health care perspective regarding the three philosophical points raised earlier in this document. There should be no presumption of human error evident in the program's logic structure. Contributing factors (neither necessary nor sufficient) as well as causative factors (necessary and/or sufficient) should be sought. Contributing or partial solutions should be welcomed. A much fuller discussion of this issue is offered in Theory, Philosophy and Justification for Root Cause Analysis. Terminology. Despite the fact that the programs we were to examine were all designed for industries other than health care, it was critical that nomenclature be comfortably understandable. While it was recognized that some process-specific terminology was unavoidable, but the program should allow the user to complete a root cause analysis without having to learn a new language. Terms like "latent cause", "failure mode" and "relative generating causality" would inhibit effective use of the program, and therefore similarly inhibit effective root cause analyses. Similarly, over-abundance of engineering or industrial safety terminology was felt to be disadvantageous, even if the typical user could grasp the meaning, since this would tend to dissuade the users from utilizing the software. In addition, however, to the use of intuitively understandable terminology, an "ideal" program would allow the user to modify the terminology appearing on screens, buttons, etc., so as to meet the needs of that user and/or facility.
Validity. The program would have to in some way help protect the novice users from drawing incomplete or inaccurate conclusions as a consequence of lack of expertise. This would presumably be part of a "Wizard" functionality (or equivalent). In essence, the software should walk the analysis team through the analytic process from start to finish, with protective queries and safeguards along the way. This should start with problem or event identification and team composition and continue through every step of the root cause analysis process including final report of the effectiveness of corrective action or interventions. This concern was highlighted in our examination of one program which appeared initially to be a viable product for our use. It became evident on further examination that while giving the impression of having led one to a valid set of conclusions, the root cause analysis was in fact not "credible and thorough." Only experts in the root cause analysis process would end with complete analyses, and others would believe erroneously that they had done so. It is recognized that this is a very difficult though important demand to place upon a software product, and this is compounded by a lack of JCAHO-established standards by which to judge the quality of any given root cause analysis. Non-Contributory Factors. In the most formal sense, factors which do not contribute to the occurrence of a sentinel or other adverse event have no role in a root cause analysis; they have in essence been "ruled out." In a very real sense, however, it is often critical to include those factors simply to document that their impact (or lack thereof) has been explored. This is of particular importance in reports sent to senior management, litigators and most specifically, the JCAHO. In this regard, explaining why specific, common, potential contributing factors do not apply in a given analysis may be a useful strategy to avoid conflict with regulatory or quality control agencies such as the JCAHO. Doing so is absolutely necessary in order to garner the credibility one requires in order to have the analysis team's recommendations taken seriously. The ability to include such factors both in a causal (or "contributory") factor diagram and in a separate sub-report is critical. Tools. Because the process of performing a root cause analysis involves the use of a number of quality improvement tools, the program should guide the users through the use of those tools. At a minimum, event sequencing, brainstorming, affinitization (categorization) and flowcharting should be prompted by the program in the appropriate analytic sequence(s), with results becoming part of the data for the root cause analysis. We feel that a certain level of familiarity with these basic quality tools must be assumed, but the software should provide facilitation of them. Inductive and Deductive Logic. A root cause analysis may be conducted using deductive and/or inductive logic. Using only one of these approaches drastically reduces the quality of the outcome. In problem-solving applications such as root cause analysis, a program using inductive logic would encourage (and hopefully guide) the user(s) in the use of such creative problem-solving exercises as brainstorming. Inductive logic is what is used when "thinking out of the box." An application of deductive logic to root cause analysis would be exemplified by a program providing a number of specific cues or prompts, which the user(s) would then assess in terms of applicability to the problem at hand. Using only inductive techniques may lead to an incomplete analysis, because it is unlikely that a given analysis team will on its own think of all major categories of possible contributory factors. Using deductive logic will make for a more complete analysis in that the user(s) will be guided through a list of potential contributory factors, but if used alone, creative thinking is stifled. Software to facilitate complete and effective root cause analysis should therefore guide the user(s) in the application of both types of problem-solving reasoning. Operational Logic Flow. The program should lead the analysis team through each step in the analytic process, using the data from prior sections or modules to initiate the next sections in a progressive manner. The software should provide for entry of a full description of the adverse event under investigation. Optimally this would entail a brief narrative entry to begin the process, followed by a detailed sequence of events, to be generated by the analysis team as the root cause analysis is conducted. This detailed sequence of events would provide a starting point for the actual analysis, e.g., iteratively asking the question "Why?" or "What contributed to this step in the sequence?" thus identifying both causal and contributing factors, and proceeding on to aid in the characterization of root causes. The software should prompt the analysis team for general categories of causal, contributing and root causes in order to reduce the likelihood of factors being overlooked. Corrective opportunities, implementation plan, validation of intervention effectiveness should all be addressed in the linear sequence through which the software guides the team. The quality of the logic structure determines the quality of the root cause analysis, and the logic structure is reflective of the underlying philosophy and assumptions of the program developers. The logic structure is the most difficult feature of a software product to analyze and evaluate, but it is the most critical. To assess this well, one must actually conduct several root cause analyses using the software and comparing the results with those which are obtained performing those same analyses without use of the software. Needless to say, this is a very expensive process in time and resources. Alternatively, one may take a completed root cause analysis, and using it as a guide, work through the software, asking such questions as, Does the information flow logically? Are there discontinuities (missing steps)? Does the software help with each step? Does it allow recursive action, e.g., going back to earlier sections to make modifications? Does the software help you answer the questions "Why?" and "How?", or at least prompt you to ask appropriately? Is the underlying philosophy as reflected in the logic flow consistent with your own? Training in Root Cause Analysis versus Training in Use of the Software. Since it is expected that a very limited number of hospital personnel at any given facility would become formally trained in the performance of root cause analysis, we look to the software itself as a training tool. We want the ideal program to teach the novice user the process of conducting a root cause analysis, in addition to having the software make life easier for the individual or team who is already expert in the process. We feel so strongly about this, that if a company recommended formal training in the use of its software (as opposed to seminars on root cause analysis in general), we took this as a dire warning against the use of that software package; this would be a statement by the program developers that their product was overly complex, was not sufficiently intuitive and user-friendly. Such training would also represent a financial "hidden cost" to the use of such a product. Output. A variety of reports are needed, or at least one comprehensive report which can be exported to other Windows-based programs for modification. That report should include all data from problem statement onward, culminating in a tabular sub-document consistent with standard process improvement (FOCUS - PDCA) format, whether using the JCAHO proposed form or equivalent (or improved). The program should afford the user a menu of choices and report formats. One special function report should show a cost accounting of how much the analysis actually cost the organization, laying out both direct and indirect costs to whatever extent this can be easily calculated, based, for example, upon hours expended, salaries and lost productivity time. Such data could enable senior management to better assess the cost of quality improvement versus the cost of status quo. The program should allow for flexibility in reporting output format and structure. Graphics Output. The program should provide a shape library to allow the users to define shape and color coding for various factors and factor categories, so as to increase ease of comprehension of the graphic images (whether Ishikawa, E&CF or other). For ease of comprehension, our preference was for a tree-structure, e.g., Contributory Factor Tree layout, with the adverse event at top, root causes at bottom and intervening steps in between (though we emphasize "contributory" rather than "causal" factors). We prefer this graphic visual presentation for several reasons. Most importantly, the tree-structure can show the reviewer both thoroughness and credibility in a glance. It easily points out the root cause(s) and corrective action opportunities. Each level documents the effort to ask the "why" question with a resultant answer in the block. We have experimented with several graphics applications in generating our root cause analyses in the manner described with very impressive results. Because visual presentation of the analysis is a very potent aid to both comprehension and impact, we feel that a good root cause analysis software package should provide a strong graphics functionality in this area, including the ability to have changes in the outline form of the contributory factor listing immediately and automatically reflected by corresponding changes in the graphical form, and vice versa. The ability to rapidly and easily radically alter the layout of the diagram is critical. Database Functionality. The program should be able to provide two distinct database capabilities. Since all root cause analysis will likely be submitted to and maintained by the risk management or continuous improvement offices of a given facility, as well as within specific departments, the root cause analyses themselves must be maintained within a designated environment. That database environment should provide for access to any entire root cause analysis, and separately should allow access to a collection (database tables) of common elements which may be useful to analysis teams from different departments. Distinct from this, the risk manager and continuous improvement personnel will need a means of tracking the status of all root cause analyses within their facility, or at a lower level, within their departments or functional areas. The latter would not involve the content of the analyses; it would be a status tracking tool by which an authorized individual would be able to determine, for example, whether the recommendations of a specific analysis had been implemented, or data monitoring begun, etc. These built-in databases should offer the ability to create special reports.
Search Function. The program should possess text search capability, for both the current analysis and the entire database, as separate user options. LAN / Report Integration. Increasingly, health care facilities are utilizing more advanced communication and automation technology, especially in the use of LAN's, including intranets, shared databases, etc. The software should be capable of operating in a secure mode in a LAN environment. Additionally, however, since some facilities and some users would be using the program separate from direct LAN connection (e.g., notebook computer at a root cause analysis meeting), the program should allow for such remote operation even on a LAN license, and should further allow for integration of data and reports from within the LAN and for data and reports imported from separate computers. Confidentiality. All quality improvement material is expected to be maintained without identifiers, especially patient identifiers. Provider confidentiality must also be assured. The program should provide a means of coding for pertinent identifiers with access to that coding restricted by the program's security functionality. This confidentiality is necessary to protect patients, the facility and the staff. Additionally, however, without such confidentiality, the likelihood of full, open and voluntary participation in the root cause analysis process diminishes rapidly. Security. It is important that access to identifying data codes, root cause analyses, the database maintaining the status of those analyses and the ability to set certain user preferences (selection of terminology on program screens, etc.) be controlled. At least three levels of hierarchical security would be necessary to allow the needed level of control, with five being preferred. Cost. Especially in these times of managed care, cost is a factor of over-riding importance. Root cause analysis software is relatively inexpensive, with an approximate range of $600 to $1,200. While a price difference of 100% is considerable in a relative sense, the prices for programs currently on the market are all far less than the cost of doing a single root cause analysis; functionality therefore becomes the primary determinant. Even when one considers the strong likelihood of an average-sized health care organization needing several copies of the selected program (or multiple user LAN license), the price range appeared to us to be a relatively minor consideration compared to the desired capabilities.
Conclusions. Developers of three of the many existent root cause analysis packages have made or are making attempts to enter the health care industry market (PROACT®, Reason® and TapRooT®), and the developers of a fourth program are contemplating entry into the medical application marketplace (PHA-Pro®). It was after having extensively tested these programs and several others that we decided to develop our own (Root Cause AnalystTM;). The developers of none of these programs seemed to appreciate the perspectives of persons functioning within the medical environment. No program met even half of the requirements © which we felt to be the most crucial. We have gone so far as to conduct several actual root cause analyses using the above programs versus using the non-automated methodology upon which our logic structure is based, applied to the same events, and have found that at in terms of both quality of results and efficiency, the non-automated methodology was superior --- and was preferred by our staff. The reader must be reminded at this final juncture, however, that the features which we found to be crucial may be relatively unimportant to other persons or facilities, and vice versa. Purchase decisions should be based upon the specific, identified and prioritized needs of the end users. Since most purchasers in the health care arena are likely to be reasonably aware of process improvement tools, the use of such tools as multivoting are recommended to assist in the prioritization of program features. It was after having extensively tested these programs and several other, and as a result of such process improvement with focus groups among our clients (brainstorming, affinitization, multivoting and prioritization matrices with respect to the desired program characteristics identified above) that we decided to develop our own program(Root Cause AnalystTM.) The logic flow for this program is modeled after the process of conducting a root cause analysis documented in The Cost-Effective Root Cause Analysis, but also includes the additional features identified in the foregoing portions of the present article. Root Cause AnalystTM is developed in partnership with Accurate Assessments. Call 1-800-324-7966 to find out how to purchase Root Cause AnalystTM or visit the Accurate Assessments Web site at www.accurateassessments.com
Root Cause Analyst TM Software | FAQs on the Issues | Root Cause Analysis Training Copyright© 1998,1999,2000 MRMA, LLC. All rights reserved. 
|
