16
Optimizing Specialty Practices
Linda M. Culp
Many organizations settle for “plain vanilla” implementations (e.g., identical note tem- plates and order sets) for all their primary and specialty care practices, despite the dif- ferent workflows and information management needs of different practices. This approach contributes to some outright implementation failures and many missed opportunities for efficiency and quality improvement.
The first task of the implementation team is to analyze practice workflows and under- stand the commonalities and differences between various practices. This knowledge enables the team to create a standardized, efficient implementation process that meets each practice’s unique needs. This chapter builds on Chapter 14 and Chapter 15, pro- viding details on implementing this standardized process to produce effective specialty practice implementations
128
Specialty Care and Customization: A Caveat
Every practice we have implemented had special customization needs. This was true for each of our 42 primary-care practices, as well as our specialty practices.
What is different about specialty practices is the degree of variation among them and the large numbers of specialties to be implemented (about 70 in our system).
We developed many of the principles and methods presented in this chapter for primary-care practices. We now apply them to new implementations of both primary and specialty care practices.
Specialty-Practice Complexities
Collaborative Care
Phased implementation of hospital-based specialty practices can involve intricacies not encountered in freestanding practices:
• The use of a single, shared paper medical record requires that charts are pulled for each patient visit until every practice has gone live on the EHR (in case a paper- based provider has added a note to the chart).
• Multispecialty clinics have providers that rotate to various sites and share support staff. This requires painstaking integration of scheduling, patient registration, docu- mentation, test ordering, test results distribution, and billing.
• Complex patients require collaborative care between the multispecialty clinics and external physicians. This places special demands on effective communication.
• Complex, changing physician schedules include inpatient rounds, supervision of res- idents, and outreach clinic schedules.
• Participation in clinical trials complicates order entry, documentation, and billing.
For these reasons, the patient chart did not become irrelevant nearly as quickly in specialty practices as in our freestanding primary-care practices. Phased implementa- tion meant that some practices were recording their notes in the EHR, while others were still using the paper chart. Despite this, we did not print notes from the EHR for inclusion in the paper chart. Rather, we notified clinicians that additional documenta- tion was available in the EHR by way of a hand-stamped alert (placed by clerical per- sonnel) on the appropriate page in the paper chart.
Ancillary Services
Ancillary testing and treatment areas located in many specialty practices also make these practices complex. For example, cardiology may operate a cardiac catheteriza- tion lab, EKG lab, and echo lab, along with a cardiac rehabilitation service. Neurology may operate an EEG lab and a sleep lab. Integrating these ancillary areas was often the most complex aspect of the implementation. Much of the complexity came from the fact that ancillary services may provide both inpatient and outpatient care. They often produce bills that include physician professional charges, technician fees, and equipment fees. They may perform studies using equipment and software that is unable to communicate electronically with the EHR.
To minimize these complexities, practice leaders choose the level of EHR function that ancillary areas will be allowed to use (e.g., results reviewing, messaging, order entry, documentation). The implementation team performs an analysis of the practice, makes recommendations, and implements decisions. For example, analysis of Cardiol- ogy’s ancillaries revealed that there was no need for them to use any EHR function except messaging. Because of the clinical importance of EKG and echo lab results, that equipment was interfaced to the EHR. In the Ear, Nose and Throat practice audiol- ogy and speech-lab personnel need to use every EHR function, including limited order entry (for billing purposes).
Outreach Clinics
Many of our specialists see patients in outreach clinics located in primary-care prac- tice sites, where the EHR was in use before the specialist’s “home” practice had gone live. Since the workflows and configurations needed to support their use of the EHR were not yet implemented in their practice, they were not permitted to enter orders and document in the EHR in their outreach clinics. These outreach clinics needed to be included in the implementation planning of the specialty practices, to ensure that the system build reflected the workflows of both the home clinic and the outreach clinic and that shadowing support was available at the right times in both locations. Two weeks after go-live at their home practice site, specialists went live in their outreach clinics.
Special Purpose Software
Specialty practices often use one or more special-purpose clinical information systems to manage diagnostic equipment (ultrasound, EKG) or treatments (x-ray therapy, chemotherapy) or to handle the data needed for regulatory and clinical trials report- ing. These systems are an important part of the practice’s workflows and should be included in workflow analysis and redesign. (See Chapter 17.) The optimal approach to special-purpose software can range from including its function in the EHR to linking it to the EHR with an electronic interface to continuing to use it as a freestanding soft- ware application. In many cases, it is most cost-effective to continue to produce paper reports from the special-purpose system and allow clinicians to enter the results into the EHR (e.g., by entering “EEG wnl 5/04” in the patient summary) with or without scanning the report into the EHR. Table 16.1 provides examples of various solutions we have used.
Flexibility
Physicians who provide a mix of inpatient, outpatient, and outreach care have little time for EHR development and training. To make best use of their limited time, imple- mentation teams met with physicians as early as 6:00 a.m. and as late as 9:00 PM (and on weekends).
Preparation
Even more than most adult learners, these physicians expect efficient, relevant analysis and training sessions. Training must focus on workflows and efficiency tools (e.g., note templates and order sets) developed specifically for their practice. (See Chapter 8.)
TABLE16.1. Various Dispositions of Special-Purpose Software.
Specialty Equipment/Auto Solution Workflow
mated System
Cardiology EKG Interface Phase 1: Link to text result. Print paper waveforms. Phase 2: Display waveforms in EHR. Discontinue printing.
Ophthalmology Visual fields and No interface Since colors guide treatment decisions (and topography cannot be scanned), print results and file
them in the paper record.
Dentistry Dental X-rays No interface File films in paper chart.
Eyewear Center Eyeglass ordering Replaced by EHR-based documentation.
EHR.
MOHS Surgery Home-grown FTP Transfer key data elements into the EHR
database by FTP.
Endoscopy Procedure Interface (Scan documents into the EHR during
documentation interface development.)
Pulmonary, Sleep Lab, Various Replaced by Enter results entry directly into the EHR.
Neurophysiology EHR. The ordering physician receives the result
in his in-basket.
Workflow Analysis
Implementation analysts spend 20 to 30 days in each practice, studying patients’ move- ment from appointment scheduling through the visit to final checkout. Checklists of analytic questions (Appendix 11) improve efficiency and completeness, but do not replace sustained observation. For example, a nurse may report that, following check- in, a patient has been “roomed”—placed in the exam room to await the physician. This rooming process can be very practice-specific. In a urology clinic, a complete urinaly- sis may be performed routinely before a patient is placed in the exam room. In ortho- pedics, x-rays may be performed. To be effective, workflow design and user training must incorporate this level of detail. If these differences are not recognized until go- live, chaos can result.
Training
To avoid productivity losses, practice leaders mandated that no training sessions for specialty practices were to be scheduled for longer than two hours. This necessitated increased shadow training.
Special Implementation Challenges
Multispecialty Clinics
One frequent challenge is the multispecialty clinic in which two or more providers from different specialties provide care during a single patient encounter. For example, a patient in the Cleft Palate Clinic might be treated by a dentist, an oral surgeon, a psy- chiatrist, and a throat surgeon—in one exam room, with one check-in and one check- out. Before the EHR, each practice used separate workspaces, workflows, scheduling systems, documentation forms, and billing forms. As a result of the re-designed EHR workflows, the multispecialty clinics now have integrated scheduling, patient notifica- tion, patient records, billing records, and test results distribution to all providers.
Creating an integrated, multispecialty clinic requires the following steps (which take approximately one year to complete):
• Analysts need to understand the existing workflows. This is often difficult, since the various contributing practices may understand the clinic’s existing workflows differently.
• Payers needed to be convinced to accept a single referral for multi-provider visits.
• A single, consistent clinic location must be agreed upon by all participating practices.
• Integrated billing with a single patient co-pay must be developed.
• If possible, scheduling should incorporate a single appointment type for each multi- specialty clinic—comprised of one referral type, one appointment confirmation, one check-in, one EHR patient encounter, and one checkout.
Research Patients
Clinical researchers identified the following needs:
• A patient must be identified as a research participant any time the patient’s record is accessed.
• Registries must be in list of patients participating in each study.
• Appropriate EHR access should be provided for authorized clinical trial reviewers.
• The patient’s study-related medical history should be readily identifiable.
• Study-related charges need to be identified at the time of ordering (to enable ancil- lary and billing personnel to work effectively).
• The patient’s providers must be kept unaware of the patient’s assignment to the treatment or control group, particularly when they enter orders.
Clinical trial participant status is entered into patient demographics and is visible when front desk personnel take a patient message, schedule an appointment, or check a patient in. In addition, trial participation is documented on the patient’s problem list with a unique diagnosis code. The comment field provides brief information about the trial, along with the research coordinator’s contact information. Signed consent forms are scanned into the EHR and displayed with other consent forms. Trial docu- mentation requirements are incorporated into note templates, which produce struc- tured, searchable data. Authorized trial reviewers receive read-only access to the records of participants on the trial list. Their workflows and a customized security access agreement are incorporated into our Standard Operating Procedure. All of the identifiers are inactivated at the completion of the study (or the patient’s withdrawal from it).
Billing for trial-related services proved to be the most complex task. Trial partici- pants often have clinic visits that produce bills payable by their personal insurance, while other charges are solely for trial purposes and must be paid through trial funding.
For example, a rheumatology patient could receive routine care for unrelated knee pain and then have blood samples drawn as part of a rheumatoid arthritis study. Ancil- lary systems (such as the lab) need prior notification to process the bills properly. The EHR generates electronic requisitions that display the necessary processing and billing information, which is also incorporated into billing documents.
Finally, trial medicines require management. We create a unique code for each trial drug or other orderable (e.g., “OKT47 trial”), since trial drugs rarely have a National Drug Code). In a blinded trial, the code only indicates that the patient received either the trial drug (or device) or the placebo. The study name, medicines (or devices) poten- tially received by the patient, and dispensing instructions, are listed on the patient’s drug list. The EHR is configured to prevent the printing of a prescription for a trial drug or device, since all trial drugs (and placebos) are provided to patients according to the trial protocol.
Case Studies
Problem Escalation
Our Obstetrics & Gynecology Department incorporates several inpatient and outpa- tient practices, including maternal/fetal health and outreach clinics serving several counties with testing services (mammography, ultrasound, and andrology laboratory).
When implementation analysts identified unexpectedly complex, interrelated work- flows, they (along with the department’s leaders) concluded that the original project timeline was unrealistically short. Using the issue escalation procedure, they recom- mended an extension of the timeline. The extension was approved by the CMIO, allow- ing the implementation team to develop a customized system build, with note templates and order sets designed for each sub-specialty.
Special-Purpose Software
Hematology/Oncology is another example of a complex, integrated practice with work- flows that include outpatient clinics, a chemotherapy treatment unit, on-site laboratory and pharmacy, radiation therapy, palliative care, and inpatient practice. When Hema- tology/Oncology leaders questioned whether or not the EHR could adequately support these complexities, we conducted a formal needs assessment. Our conclusion was that the EHR would not adequately support the chemotherapy treatment unit for another three years. (See Chapter 2.) Following the planning process described in Chapter 17, the Hematology/Oncology practice developed a business plan to install chemotherapy management software optimized for managing hundreds of cancer treatment protocols.
Summary
Specialty practices differ from primary care in their team approach to patient care. That care may include multispecialty clinics and on-site ancillary departments, more complex physician schedules (due to inpatient rounding and outreach clinics), and the frequent need for special purpose software. Standardized implementation processes can take these differences into account and produce customized specialty implementations.
