IDENTIFICATION OF THE SIGNIFICANCE OF THE PROBLEM OR OPPORTUNITY
This proposal addresses the need to develop products to assist all participants in health care in assessing and monitoring the quality of care and level of care furnished to patients. Pressures to limit costs and improve quality by standardizing and managing care are coming from insurers, government agencies, health management organizations and payors of all types. Computer software designed to monitor health care data - by searching for instances that do not meet quality standards and, where appropriate, suggesting specific guidelines to be followed - can be a great assistance in achieving these improvements.
Protocols are sets of conditions, actions, and rules that set standards and guidelines for the delivery of health care and health management services. In most small- and medium-sized health care agencies, they exist on paper and are referred to well after the situations they apply to have occurred. They are refined only sporadically. However, when set up and enforced within an organization's primary software management system, protocols have the potential to greatly improve the quality, efficiency and cost effectiveness of health care.
A search of the last five years of medical literature shows an increasing body of references to the feasibility of clinical guidelines and the implementation thereof. One critical appraisal of the state of research to date concludes that "strong evidence suggests that CDSSs (Computerized Decision Support Systems) can improve physician performance." This report also indicates that four of six studies regarding the use of computer support to enhance the quality of preventive care showed statistically significant effects on clinician performance, as did seven of nine studies assessing the effect in caring for active medical problems.
If designed and developed correctly protocol software should:
The result is a tool that will be of primary assistance to an organization to assess patterns of service and to continually refine protocols, with the aim of improving the quality and cost effectiveness of care.
We propose to develop a prototype Protocol Engine which will have all features listed in the previous paragraph. We use the term "engine", because our concept is of a very specialized application which will provide users with a great deal of flexibility and specificity in defining protocols. It will also work with the health care data they already have, regardless of its source or the format in which it is stored. It is our intent that this product will be designed to work effectively either:
The greatest benefit of maintaining and enforcing protocols on an organization's primary or "live" data management system is the importance of immediate prompting to offer users current, viable guidelines regarding quality care standards and cost effective health care management, right at the time care is being provided or planned. Currently few small- to medium-sized physician offices and clinics have computerized protocol systems. Those that do, have systems that run independently of the facility's primary data gathering system, and commonly cannot share it's data. This combination makes for highly ineffective implementation of protocols.
Having protocol management software closely integrated with the "live" data entry system ensures that medical staff are appraised of information they need to know when they need it. With this kind of information management and monitoring, the opportunity to reduce health care costs while improving the delivery of services is enormous.
Challenges to Full Implementation of Protocols in Clinic Primary Software Systems
1. Difficulty in Categorizing and Coding Protocols
Protocols by their nature often defy categorization. Not only does a protocol lay out a sequence of tasks that need to be performed, it may also include detailed instruction on how to perform a sepcific task. Tasks may include seeking and receiving approvals for recommended treatments, giving the patient specific tests or examinations, and making sure the patient receives certain information on how to speed recovery. Protocols may also include instructions on sending bills or written communications to insurers or employers. Situations or events that need to trigger a protocol may not be codified by a specific software package, and the software may not be designed to see that the rules or tasks laid out by the protocol are carried out. Further complicating the problem, care and case management protocols need to be carried out under a variety of situations.
The conditions that trigger the enforcement of a specific set of rules need to be very specific and yet also have a very wide range of variability. The sequence of actions monitored or the tasks carried out also can have many variations. Computer software can be designed to address these variables, but often does not.
2. Protocol Monitoring is usually not active at the time initial data entry and the actual care occurs.
In clinics and small offices, patient data is usually entered on a software system whose primary purpose is to handle billing. This type of package often has very limited or no means of entering, customizing, or enforcing protocols. The "live" or primary database application package may not be collecting all of the data that is critical to determining if a protocol is relevant to the situation, or if the tasks defined by a protocol have been carried out.
3. Protocols and level of their use vary with size and mission of clinic.
Users of health care and case management software, - whether they are from large or small clinics, general or specialized practices, oversight organizations or payors, - will have very different views about the types of rules they want implemented and how they should be enforced. They also will have widely divergent means of complying with standards because of differences in equipment and staff. Concurrently, studies have shown that clinician compliance with pre-set standards is lowest when they do not agree with the standards and have had no voice in their creation.,
4. Physician Resistance to Inflexible Protocols
A recent debate in the British Medical Journal addressed fears by some physicians that the use of clinical guidelines will lead to "cookbook medicine (that) will reduce doctor's self respect and could reduce patients' confidence in them." Our proposed system will alleviate those fears as it allows practitioners to create guidelines specific to their practice, to override the protocols as they see fit and to analyze their service delivery trends to make further modifications as the computer provides them with concrete data on which to base their decisions. In fact, two studies involving computer support for nursing decisions concluded that the "greatest value of systems for automated rule induction is in creating prototypes that experts can debate and correct." As to patient attitudes, one study found that patients treated in a clinic whose physicians were aided by a medical information system that provided recommendations perceived that they had better health status and quality of communication than did those whose physicians used a manual record.
Proponents of protocols in this debate also pointed out that the problem with clinical guidelines is not the guidelines themselves but the fact that no efficient method of implementation is available. "The typical fate of such guidelines is to be distributed to junior doctors among a mountain of paper to which reference is seldom subsequently made. If guidelines are to influence medical practice the relevant protocol must be in front of the doctors' eyes when clinical decisions are made. Only with computer technology can this be a reality."
Occupational Health Software: The Foundation for the Next Step
Among commercially available health care software packages, occupational health management software has been in the forefront of the attempt to integrate and implement protocol management within overall billing, patient record keeping and case management systems. Because employers pay Workers' Compensation rates directly linked to recent injury costs, there has been more direct pressure in the occupational health field to make sure that appropriate care is delivered in a timely and cost-effective manner and that patient recoveries are followed closely.
In his role as the developer of the Teamwork Integrated Occupational Health Management System, the Principal Investigator for this project, has had a unique opportunity to work closely with physicians, clinic administrators, care review agencies, case managers and clinic staff in designing and integrating a wide range of protocol types with an overall record keeping, case management and billing system. In the effort to make protocols an effective and integrated part of the Teamwork package he has dealt with all aspects of their design, integration and implementation. He has compiled a comparison of protocol types and implementation approaches in several of the most popular occupational software systems, and presented a detailed review od the state of protocol software implementation in a talk given at the first SPAN conference on Occupational Management Information Systems.
The occupational health software systems studied take somewhat different approaches in their implementation of protocols. But an analysis shows that efforts are now under way to set up protocols based on: 1) the patient's diagnosis, 2) the general purpose of the patient's visit, 3) the results of examinations administered to the patient, or 4) events that occur as part of the patient's treatment and rehabilitation.
While the primary triggering event that determines a set of required actions might be a specific diagnosis, visit type or examination result, some packages allow users to define additional factors that must be present before a set of actions will be prescribed. The most common of these defining factors is the company that employs the patient. In the Teamwork system, a set of treatment rules or case management guidelines can be developed to match a specific patient diagnosis. The guidelines then can be altered somewhat for patients who are employees of a specific company, allowing clinics to work out service arrangements with client companies, and use their computer systems to insure that providers and staff are aware of the agreed upon arrangements at the time of service.
Some of the defining factors might be described as status descriptions (patient's employer, insurance carrier, previous medical history), others may themselves be events that occur along with the triggering event or as part of the treatment. It is the unique combination of a specific set of events and conditions that defines the situation under which the protocol will be carried out.
While many of the tasks described in a protocol must be performed by people, computers increasingly will be able to assist with the actual performance of the tasks, particularly those which involve data scanning, reporting, data transfers and treatment approval requests. For those tasks that it cannot actually perform independently, a software system can help enforce protocols by requiring confirmation that prescribed actions not under its direct control were properly completed. Protocol enforcement varies widely between systems. Some systems merely remind the user that there are recommended processes or guidelines in a specific situation but do not initiate action without a user request. This is a passive and unobtrusive way to deal with enforcement. It's main advantage is that in situations where a protocol is not appropriate, other than annoying the user, no other problems are created. However, the negative side, is that when the protocols are appropriate, the computer is not really ensuring that the required tasks are being carried out.
When the processes are triggered automatically or the system insists on confirmation that they were performed, the computer will appear to be taking an active role in protocol enforcement. The more active a system's role in enforcing a protocol, the more critical it is that users be able to define all of the factors that must be present for the protocol to be triggered.
In current occupational health packages many of the approaches to protocol implementation seem somewhat limited and fragmented, but when looking at the overall trends, it is apparent that many of these efforts at development that will be applicable to all facets of health care, not just to occupational health.
What occupational health software has done correctly is demonstrate that protocol implementation and enforcement needs to be happening as data is entered, and while the patient is in the clinic. What still needs to be done is to generalize the definition of protocols, so that they can be used in any health care setting, and seperate protocol definitions from data definitions, so that once protocols are defined, they can work with data in a variety of formats, regardless of which software is controlling the actual data entry.
Future Development: a Unique Opportunity
In the last ten years, the relative ease of developing data management systems for the DOS environment has led to an explosion of reasonably priced independent office management applications. For the most part these applications were designed to handle data generated by the system with little thought for sharing data with other applications. However, as society's information demands increase, the ability to transfer data between different between systems without additional data entry is becoming essential. Consequently, software vendors are converting to "open architecture" data storage. Data is stored in formats that can be accessed by other parties, independent of the original software system. These vendors also have begun to provide documentation regarding data organization, so that other parties can access the data.
The large scale migration of applications from the DOS to the Windows environment over the next several years will have several significant effects on the development of health care systems. Many vendors will be revising and rethinking the way their systems work. Also Windows allows various parts of applications to be packaged separately and linked together dynamically when executing. These Dynamic Link Libraries (DLLs) make it much easier for an application developer to add features produced by an independent developer.
Open architecture data storage and Dynamic Link Libraries now make it possible to successfully produce an application designed as an add-on to be used by a variety of different software systems. Additionally, the ability to run concurrent processes is now a feature of Windows NT and its successors. Thus, on a single desktop with an open architecture database, it will be possible to run both a data entry and a protocol system concurrently, even if two packages are not integrated.
For the past ten years, CK Computer Consultants has designed, developed, evaluated and supported DOS-based health care management software for physician offices, clinics, occupational health services and various other hospital departments. We feel that this is an ideal time to develop a full featured protocol setup and implementation system as a Windows Dynamic Link Library with data drivers that can access data stored in a variety of different formats. This system then can be offered to both ends of the software market -- to software vendors as an add-on to their products or to software users as "middleware" that can run concurrently with their primary data entry system.
While there are technical challenges to overcome in order to develop a such a system, the rewards will be enormous. Once systems are properly configured to meet the needs of the practice and all necessary data entered, computers can monitor enormous amounts of data very efficiently and immediately draw attention to any care plans that fail to meet standards. Such a system also can provide the valuable analytical and historical information necessary to make decisions regarding service delivery and outcomes with which to further define protocols.
| Home | ck_MedRules | ck_CompCare | ck_Medical | Grants | The Company | Employment | Request Info | Links |