Tutorials, M. Duncan Research Note 3 October 2002 Scripting Healthcare Scheduling Software Demonstrations Many healthcare software vendors offer products claiming to handle the enterprisewide scheduling requirements of integrated delivery systems. Developing complex, realistic demonstration scripts is essential to verify the claim. Core Topics Healthcare: Critical Healthcare Applications and Business Processes; Healthcare Business Drivers, Strategies and Management Issues Key Issue How will successful healthcare organizations align and deploy IT to realize value from increasing IT investments? To enable easier patient access to care and smoother patient flow through the healthcare delivery system, many healthcare organizations (HCOs), especially integrated delivery systems (IDSs), have made the purchase of enterprise scheduling systems (ESSs) a high priority. To qualify as an ESS, the software must be able to address patient, physician, staffing (technician and clinical support staff) and resource (including equipment and physical location, such as exam room) scheduling in inpatient, outpatient or ambulatory care settings. It must also accommodate cyclical or recurring appointments, such as multiple therapy sessions over an extended period. The newer generation of ESSs also provides medical necessity checking and Web extensions to accommodate patient self-service functions via the Internet. HCOs should insist on extensive validation of a product's capabilities as part of their evaluation processes during demonstrations and, more importantly, at site visits to similar or larger, more-complex HCOs where the product is installed. The selection team should determine their anticipated enterprise scheduling needs by scripting potential scenarios, then evaluate whether the product can meet those needs within acceptable performance guidelines. It should be noted that the scenarios presented here were deliberately chosen to establish the border at the high end of the state of the art for ESSs. These scripts are not a substitute for, but a supplement to, a more-exhaustive evaluation of functionality through standard product demonstrations, usually developed by the vendors. Because of the range of applications involved in these scenarios and the corresponding integration requirements (such as interfaces with a third-party radiology system), HCOs are advised to limit requests for these types of Gartner Entire contents 2002 Gartner, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.
demonstrations in production environments to only those systems they are seriously considering buying, rather than all applications on an initial selection project (all vendors sent a request for proposal). Scenario 1: Multiple Tests, Cyclical Appointments A patient reports neck pain and numbness of his arms and hands to his primary care physician (PCP) during a scheduled appointment. The PCP conducts reflex and mobility tests and suspects a pinched nerve or disk degeneration in the cervical spine. The receptionist is asked to schedule: A series of X-rays of the patient's neck and spine, to be conducted immediately at the radiology clinic affiliated with the IDS. An electromyography (EMG) to diagnose any nerve damage, to be conducted at the hospital's neurological center. A follow-up appointment with the physician to discuss the test findings and next steps. This appointment must occur after the X-rays and EMG are complete and the results returned. Pending the test results and, for the patient's relief, four weeks of physical therapy sessions three one-hour sessions per week at the closest therapy clinic. These sessions will include ultrasound, moist heat and electronic traction therapy, as well as controlled exercises with a licensed therapist. Because the patient's work schedule does not permit a standing appointment (such as Monday, Wednesday and Friday at noon), the scheduling application must allow flexibility for different times and therapists. Scenario 2: Inpatient/Outpatient/Multiple Test Encounter An older, overweight patient reports nonspecific chest pain to his/her PCP. In a more-ideal or realistic clinical scenario, the PCP would order tests and await results to identify or eliminate pneumonia, heart disease or gastrointestinal (GI) disease, in that sequence. However, for purposes of evaluating the ESS's functionality, this script should be executed without regard to sequence or test results. Hospitalization for observation and testing (schedule a room and preregister). A chest X-ray to determine cardiac size and to evaluate for other causes of chest pain (such as pneumonia or a fractured rib). 3 October 2002 2
Lab tests to evaluate electrolytes, cardiac enzymes and a complete blood count. An electrocardiogram (ECG) and a stress test or nuclear stress test in the cardiology department. An upper GI exam or endoscopy to investigate possible hiatal hernia or ulcer. A follow-up appointment with the PCP to discuss diagnosis, prognosis and treatment. Scenario 3: Verification of Scheduling Sequence Intelligence/Rules Engine Flexibility and Capabilities Some scheduling applications have built-in clinical or administrative intelligence. This type of functionality might be tested by using a script such as this: The PCP suspects a thyroid problem and decides to schedule a computed tomography (CT) scan and a nuclear thyroid scan. The CT scan would involve the injection of normal radiographic contrast, which contains iodine. If the CT scan were performed first, the resultant iodine load would require delaying the thyroid scan for at least four weeks. The scheduling application should theoretically alert the ordering physician to schedule the thyroid scan first. Some ESSs also allow for travel time when a patient is scheduled for multiple tests in one day at various locations within the enterprise, and the system alerts the scheduler if the appointments are too close together. This, of course, requires the HCO to pre-define the travel times between locations and program them into the system. Scenario 4: Web Extension for Consumer Self-Service To enhance patient/member satisfaction, several ESS applications offer the ability to extend some of their functionality to the HCO's Web site. These types of exchanges should be supported: A consumer can place a request to view a physician's appointment schedule for available dates and times. A consumer can directly schedule an appointment without human (telephone or in-person) intervention. The ESS processes the appointment request and sends an acceptance notification to the consumer. 3 October 2002 3
The ESS notifies the physician's office staff of the appointment and manages any conflicts or subsequent changes. The system is built on standards to facilitate integration with departmental applications (Web-enabled and those housed on closed internal networks). An optimal example would be integration with the HCO's contact management software (such as an "Ask-a-Nurse" system). These scenarios are just a few examples of the various requirements that must be addressed for a scheduling application to be labeled "enterprisewide." In these and any other demonstration scripts, HCOs are cautioned to insist on seeing this functionality in a production environment, not just in a marketing demonstration. The product must be seen in action, with concurrent users executing transactions across LANs or WANs. Many ESS implementations have been derailed by inadequate technical infrastructure. Significant bandwidth (usually dedicated T1 or faster communications lines) and powerful, high-memory servers are expensive but necessary requirements for most ESSs. Patient satisfaction will suffer if the patient is kept waiting for any length (more than a few minutes in these scenarios) while the software is searching for and booking time and resources. On these site visits, HCOs are cautioned not to expose their end users to demonstrations that rely on system interfaces that will not be built in their own environments, or to at least clearly communicate these situations to set expectations. HCOs should also request that vendors demonstrate the ESS's ability to perform medical necessity checking. The vendor should provide examples of common advanced beneficiary notices for the system to screen, along with examples of how the medical necessity checking rules engine is updated. Key Facts: Understand your complete organization, and thus your scheduling requirements. Develop comprehensive scripts defining your HCO's enterprise to "stress test" ESSs. Define and communicate realistic expectations regarding the outcomes of these tests, from technical and user perspectives. Execute your scenarios in a production environment at an HCO as similar to or more complex than your enterprise as possible (similarity should encompass number and types of entities). 3 October 2002 4
Acronym Key CT Computed tomography ECG Electrocardiogram EMG Electromyography ESS Enterprise scheduling system GI Gastrointestinal HCO Healthcare organization IDS Integrated delivery system PCP Primary care physician Bottom Line: HCOs must understand their environments and define detailed demonstration scripts that validate whether an ESS meets their requirements. Then, they must observe the execution of these scripts in a production environment at comparable or more-complex organizations. Failure to complete scenario testing leads to incorrect or overstated user expectations, which can derail optimum use of the product and limit the overall return on investment for the organization. 3 October 2002 5