11
System Integration
Elizabeth A. Boyer, Jean A. Adams, and Diane L. Barnes
89 Integrating the EHR, that is, enabling the EHR and other software applications to exchange data with each other without loss of meaning or accuracy, is one of the crit- ical tasks of the EHR implementation and of ongoing production support. Integrating the EHR begins with defining the components to be integrated. The EHR suite is a suite of applications that you purchase from the vendor and that share a common data- base. It may include scheduling, registration, outpatient EHR, inpatient EHR, Emer- gency Department EHR, ADT, pharmacy, laboratory billing, and other applications.
Ancillary applications are external to the EHR suite, but send information to the suite’s database (for example, laboratory and pathology results) and may receive information from it (e.g., patient demographics) (see Figure 11.1).
While part of the value proposition of buying an EHR suite from one vendor is that the suite’s components are theoretically integrated from the design stage forward, this is not likely to be entirely the case. So EHR integration has a dual focus: first on estab- lishing interfaces with ancillary applications, and second on integrating data definitions and shared software functions within the EHR suite.
Ancillary Applications
Integration of ancillary applications is essential to the success of the EHR’s usability and reliability. Before we implemented the EHR in any practice, we interfaced labo- ratory results and ancillary patient registration data to the EHR. Radiology results were added early on in the implementation. The advantages of including these data in the EHR include are detailed in Chapter 14.
Considerable back-end work is necessary to make interfaced results from ancillary applications usable:
• Textual reports should display the most pertinent information first (e.g. the impres- sion or final result), with supporting information following. This saves users from having to scroll through at least one screen to view every radiology and pathology result. Since few EHR or ancillary applications were designed with this goal in mind, putting the results first requires extensive manipulation of the incoming data—and is not be feasible in all cases.
• Formatted information displays from ancillary applications should be as readable in the EHR as they are in the originating application. This is often not feasible. In those cases, we import an image of the table into our image-management system and create a link from the EHR to the image.
Technical Interface Considerations
• Decide what data should be stored in the EHR database and what should remain in ancillary applications. For example, PACS (digital radiology) images are too large to be stored in the EHR. Nor are they needed for real-time transactions (to enable clin- ical decision support).
• Document the specifications for each interface. This documentation should identify each data item and the aggregate data flow. We have learned (from repeated changes in the data needs of various stakeholders) that it is best to interface every data field and then use the interface engine to control which fields actually enter the EHR.
• Active, continuing management of error logs is necessary to assure the integrity of the data in the EHR. Our production support team analyzes the logs, designs a process for handling the errors, and designates the team who will monitor the logs and resolve the errors. When the system served only outpatient practices, we monitored the outpatient EHR logs once daily, Monday through Friday. With the implementation of the inpatient EHR, we monitor the logs every four hours, seven days a week.
• Develop a detailed testing scenario for every interface message type sent and received. For example,
• Patient merges, in which the data in duplicate patient records is merged into a single patient record
• Order and result messages, including different test status indicators (e.g., “In Progress,” “Final,” “Edited,” “Cancelled”)
• Registration messages, including checking a patient in using the scheduling appli- cation or making a change to the patient’s address
Inpatient
EHR Database
Scheduling Outpatient
Registration
ADT
Interface Engine
Pharmacy Radiology
FIGURE11.1. Typical EHR architecture.
Integrating the EHR Suite
Attention must also be given to data integration among the applications that share the single EHR database (the EHR suite). Detailed analysis needs to confirm that shared data fields have the same definition and use in the various EHR applications before the development, population, and maintenance of data tables. For example, in our EHR the “Department Specialty” field is primarily used and controlled by the scheduling application for managing referrals. Well into the implementation, we discovered that this field is also used as a filter for determining which order sets and note templates various groups of users will see. Had we known this at the outset, we would have placed all our family practitioners in a single Department Specialty. The fact that we created a separate scheduling department for each of the 42 practices requires us to maintain 42 separate lists of order sets and note templates.
Translations may be required from one or more fields in one application to another field in another application. For example, entering the visit type and provider type for an appointment in our scheduling system requires translation to the appropriate encounter type in the EHR (Table 11.1).
Integrated Application Testing
Integrated application testing ensures that new and existing software functions perform well together.The first stage is testing within each application.The second stage is testing the functions across all the applications of the EHR suite. A testing plan will help you identify testing dependencies and prerequisites (see Appendix 7). It will also help you coordinate the necessary resources from the involved project teams (e.g., scheduling and patient care). Table 11.2 provides a guide for estimating testing resource needs.
Scenario-based testing ensures that recommended workflows are functional through- out the EHR suite. For example, does making test ordering easier for generalists make it harder for specialists? Test as many non-recommended workflows as your team can identify to make sure that they do not degrade system performance or cause other kinds of problems. (Of course, users will create far more non-recommended workflows than your testing teams can.)
Master File Management
Populating the EHR’s master files (database files that contain static records used to identify, for example, EHR users, work centers, diagnoses or appointment types) appro- priately enables the applications of the EHR suite to work together. We created a
TABLE11.1. Mapping from Appointment Detail to Encounter Type.
Scheduling Application Visit type Provider type EHR
Convert from Encounter type
Appointment Allergy injection. Nurse Nurse only
Appointment Lab Nurse Laboratory
Appointment Weight check Nurse Nurse only
Appointment Nurse specialist Office visit
Appointment Audiologist Office visit
Appointment Physician Office visit
them.
• With the vendor’s assistance, the team identified the application in the EHR suite (e.g., scheduling, patient-care) that uses the table primarily and controls its defini- tion, along with other applications that use the table.
• The team established and maintained naming conventions that are used throughout the EHR suite. For example, departments are given two-part names, with the spe- cialty followed by the location: “Cardiology—Danville.”
• The team determined which master files need to be updated and the methodologies and schedules for those updates. Updates to some master files depend on external application updates. For example, if the laboratory adds, deletes or modifies a test name or number, the procedure and laboratory master files must be changed. Man- aging updates requires 3 to 4 FTEs. Monthly and annual updates create spikes in demand. See Table 11.3 for a sample schedule of external master file updates.
• The team documents master file changes and communicates them to the implemen- tation, training, and production support teams, who communicate them to the appro- priate users. E-mails (with screen shots) are usually adequate, but we present some complex changes in face-to-face demonstrations. The most effective method of recording master file changes for reference is a combination of screen shots and a
TABLE11.2. Testing Resource Planning Guide.
Type of Project Resources Activities Time Commitment
Development 2 FTEs* • Double checking of configuration Varies based on project
project (e.g. new • Testing complexities.
report)
Monthly updates- At least 2 FTEs • Documentation interpretation • 6–8 weeks for one annual upgrades per software • Outline configuration choices monthly update
application for design and feedback groups (in our case, • System configuration
8–10 FTEs • Test application function • 12 weeks for 2 monthly for scheduling, • Test application performance updates
registration, • Train users
ADT, and • Implement system • 16 weeks for 3 monthly patient care • Resolve post-implementation updates
application.) problems
Major upgrade At least 2 FTEs • Interpret upgrade documentation • 6–12 months based on per application • Outline configuration choices the size of the upgrade (e.g. 8–10 FTEs) for design and feedback groups
• Configure system
• Test application function
• Test application performance (simulator)
• Train users
• Implement system
• Resolve post-implementation problems
*2 FTEs are required for any new development project: one primary and one secondary. Two members are needed to provide a comprehensive understanding of the project and for double-checking the configuration settings and testing results.
narrative outlining the options considered, pros and cons identified for each option, reasons for the decision, and stakeholder approval (e.g., feedback groups or leader- ship teams).
EHR Application Upgrades
Because they affect other EHR applications, large upgrades require a structured approach:
• First, the upgrade team reviews the vendor’s upgrade documentation, analyzing func- tional enhancements and the configuration decisions that will need to be made. They bring any gaps in documentation to the vendor for completion.
• If the upgrade involves more than one application, the upgrade team plans how to integrate configuration and testing of the applications.
• The technical team creates an alternative environment for testing.
• The upgrade team compiles a checklist, which details pre-installation and installa- tion tasks. They complete and document the pre-installation tasks and time the installation steps in order to plan the downtime windows that will be needed for installation.
• The team reviews all of the test environment logs, notes all errors, and presents them to the vendor for resolution. (This is one of the situations where a strong and coop- erative partnership with your EHR vendor is most important. You may need them to make changes that you regard as critical before you can implement the upgrade.)
• After the vendor completes the needed improvements, the team installs them in the test environment. Affected application teams are then notified to begin set-up and testing. They apply their upgrade notes, fixes, patches, and enhancements in the test environment and test them thoroughly, with special attention to integrity of data and function across applications.
• Infrastructure components, such as the network, local servers and workstations, are monitored to ensure that the upgrade does not increase network traffic or create software registry incompatibilities. We simulate the number of concurrent users of the production EHR (4100–4500) in the test environment. Specialized testing soft- ware simulates standard workflows, tracks the data, and sends it to the vendor for review. If the results indicate that a new or enhanced software function is slowing performance unacceptably, we inactivate it.
TABLE11.3. Schedule of External Master File Updates.
Update Import Type Frequency Purpose
Medications Monthly Update the EHR with the FDA’s most recent approvals. Interaction checking (drug-drug, drug-food, and drug-allergen) is included.
Laboratory Monthly Update the EHR with current tests. This includes lab locations and reasons for cancelling tests.
Radiology Every other month Update the EHR with current radiology codes. This or as needed allows the radiology results interface to link the result
with the order in the EHR.
ICD/CPT/HCPCS Annually Update the EHR with current codes.
• As testing is completed, the training curriculum is prepared, documentation written, and training classes scheduled.
• As the go-live date approaches, the installation team is informed of the plan and trained in their roles.
• Go-live downtimes are scheduled on weekends (usually Saturday evenings or early Sunday mornings) to minimize the impact on inpatient units, the emergency depart- ment, and outpatient practices. During the downtime, the production environment is unavailable to clinical users, but the shadow copy of the EHR (read only and without real-time interfaced results) remains available. As soon as the installation is completed, each application is tested quickly. When the tests are complete, the Help Desk is notified, the interfaces restarted, and user log-ins re-enabled.
On the Monday after go-live, a team of five to ten production support personnel is ded- icated full-time to resolving any problems the upgrade has created. Within two to three days, the number of new problems has usually decreased enough to handled by the standard production support processes. All problems are recorded, prioritized, moni- tored and communicated with the vendor (as appropriate) using the same methodol- ogy as for pre-installation testing. Using this methodology, we have shortened the average upgrade installation downtime from eight to three hours.
Summary
Integrating the applications that comprise the EHR application suite and the applica- tions that interface with your EHR is critical to your initial and ongoing success. In many cases, major upgrades can create enough data integrity and usability problems to pose a serious threat to patient safety and workflow efficiency. A thorough, proac- tive approach to integrating data and functionality across applications will help you minimize this risk.
