HINF 510 Week 1 IT System Implementation and the Systems Life Cycle Example

Replacing the Record in 14 Clinics Without Hurting Anyone: Planning a Health Center Network's EHR Implementation Through the Systems Development Life Cycle

[Student Name]

University of Phoenix

HINF/510: The Systems Life Cycle

Week 1 Assignment

[Instructor Name]

[Date]

The health center network, its clinics, budget and plan are composites written for a model paper; research findings come from the sources listed.

The board of a composite network of 14 community health centers, which serves about 62,000 patients with medical, dental and behavioral health care, voted in January to replace its electronic health record. The system was 15 years old, its vendor would end support in 30 months and clinicians disliked it. The chief operating officer, who is completing a graduate informatics program, was named executive sponsor. This paper plans the implementation through the phases of the systems development life cycle.

Why Replace Rather Than Upgrade

The decision to replace was not automatic. The old vendor offered a new version, but it would still keep medical, dental and behavioral health records in separate modules that did not share problem lists or medications, and it lacked the population health registries the network needs for quality programs. A request for proposals went to four vendors; clinicians scored scripted demonstrations of 12 real scenarios, such as a diabetic patient seen by a physician, a dentist and a behavioral health consultant on the same day. The chosen vendor scored highest on integrated care and reporting, second on cost.

The Life Cycle as a Frame

The systems development life cycle divides a system's life into phases: planning, analysis, design, implementation and maintenance, with evaluation feeding into the next cycle. For a purchased system, design means configuring and building rather than writing software, but the discipline is the same: decide what the system must do before building it, test before using it and keep improving after go-live.

Phase One: Planning

Planning produced a project charter stating the goals: a single record across medical, dental and behavioral health, better tools for population health reporting and less time spent documenting. The budget totals $4.2 million over three years, including licenses, hosting, implementation services, staff backfill for training, hardware and a 12% contingency. The chief operating officer leads a steering committee whose members are the chief medical, dental and behavioral health officers, the nursing director, finance, information technology and a patient board member. A project manager, three application analysts hired for the project and physician, nurse and dentist champions from each clinic group complete the core team.

Phase Two: Analysis

Analysts spent eight weeks observing and mapping 38 core workflows, from check-in and sliding-fee eligibility to prenatal visits, dental charting, behavioral health notes with extra privacy protections, prescription refills and reporting required by the federal health center program. For each, they recorded what works, what does not and what the new system must support. The analysis found that the current system forced staff to document the same information in three places for integrated medical and behavioral visits, a problem the new design must solve.

Phase Three: Design and Build

Design configures the new system to the network's needs: templates for each visit type, order sets for common conditions, clinical decision support such as reminders for cancer screening, security roles for each job and interfaces to the laboratory, the state immunization registry, the health information exchange and the billing clearinghouse. Clinician champions review every template before it is built. Data migration planning decides what moves from the old system: problem lists, medications, allergies, immunizations and two years of notes and results, with older records kept in a read-only archive.

What Can Go Wrong

Research shows that implementation choices can affect patient safety. At one children's hospital, mortality among children transferred for specialized care rose from 2.80% before a commercial order entry system was implemented to 6.57% afterward; the authors pointed to a rapid, all-at-once rollout and new processes that delayed medications and orders for critically ill children (Han et al., 2005). At another children's hospital using the same vendor's system, with more preparation and redesign of workflows, mortality did not increase (Del Beccaro et al., 2006). The software was the same; the implementation was not, and neither were the results.

Unintended Consequences

A review of problems observed after implementations described errors in entering and retrieving information, such as screens that fragmented a patient's story or allowed selection of the wrong patient, and errors in communication and coordination, such as systems that assumed work happens in a rigid sequence when clinical work is often interrupted (Ash et al., 2004). The network's risk plan addresses these by testing templates with real users in simulated clinic sessions, limiting mandatory fields and keeping a rapid-change process after go-live.

Phase Four: Implementation

Implementation includes testing, training, data conversion and go-live. Testing runs in three rounds: each function alone, workflows end to end and full integrated scenarios with interfaces. Training is role-based, from four hours for front-desk staff to 16 hours for clinicians, with a proficiency check before system access. The network chose a phased go-live in three clinic groups, two months apart. A big-bang go-live would shorten the period of running two systems, but phasing lets the team fix problems found in the first group before the larger groups go live. Each go-live includes reduced patient schedules for two weeks, on-site support from super users and vendor staff and a daily command center meeting.

Phase Five: Maintenance and Evaluation

After go-live, the system enters maintenance: fixing problems, applying upgrades and optimizing workflows. The network will track measures before and after go-live: visits per clinician per day, time spent in the record after hours, patient portal use, cancer screening rates, claim denial rates and safety events related to the record. A formal evaluation at six and twelve months will set priorities for optimization.

Communication

A project of this size fails when staff hear about it late or only through rumor. The communication plan includes a monthly newsletter, a page on the network's intranet with the timeline and demonstrations, regular updates at clinic staff meetings from each site's champion and a patient notice explaining that visits may take longer during the first weeks. Front-desk staff, who will field patient questions, receive a short script on what is changing and why.

Budget Risks

Implementation budgets often run over. The largest risks here are staff backfill, because training and reduced schedules cost clinic revenue, and interface work, because each outside connection needs testing with a partner who may be slow. The 12% contingency covers moderate overruns, and the steering committee reviews spending against the budget monthly.

Governance After Go-Live

The steering committee will become a permanent clinical informatics committee, prioritizing change requests and upgrades, because a record that stops improving after go-live soon falls behind clinicians' needs.

Conclusion

Replacing a record across 14 clinics is a clinical change as much as a technical one. The systems development life cycle gives the project structure: a charter and budget, careful workflow analysis, clinician-led design, staged implementation with testing and training and ongoing maintenance and evaluation. Studies of the same system producing different results show that the way the network implements its new record will matter as much as the record it bought.

References

Ash, J. S., Berg, M., & Coiera, E. (2004). Some unintended consequences of information technology in health care: The nature of patient care information system-related errors. Journal of the American Medical Informatics Association, 11(2), 104-112. https://doi.org/10.1197/jamia.M1471

Del Beccaro, M. A., Jeffries, H. E., Eisenberg, M. A., & Harry, E. D. (2006). Computerized provider order entry implementation: No association with increased mortality rates in an intensive care unit. Pediatrics, 118(1), 290-295. https://doi.org/10.1542/peds.2006-0367

Han, Y. Y., Carcillo, J. A., Venkataraman, S. T., Clark, R. S. B., Watson, R. S., Nguyen, T. C., Bayir, H., & Orr, R. A. (2005). Unexpected increased mortality after implementation of a commercially sold computerized physician order entry system. Pediatrics, 116(6), 1506-1512. https://doi.org/10.1542/peds.2005-1287