10.1 Systems Development Life Cycle

10.1 Systems Development Life Cycle

Quick Answer: Domain 3 task A.1 is the systems development life cycle (SDLC): plan, analyze, design, implement, and maintain. Waterfall and iterative/agile are delivery styles, not excuses to skip a phase. In regulated healthcare you may iterate, but patient-safety functions still need gated validation. When the problem, the regulation, or work-as-done changes, revisit the phase—do not code through it.

Information and Systems Management is 30% of CPHIMS, the largest domain. Task A.1 asks whether you can place a request on the life cycle instead of jumping to a vendor booth or a printed go-live date. The exam is not scoring a pentagon you memorized in a methods class. It is scoring what you do when an emergency department wants a new tracker “by next month,” when an EHR upgrade is treated as a weekend install, and when a post-go-live workaround proves the analysis was fiction.

CPHIMS practice questionsPractice questions with detailed explanations

Why SDLC is an HIT skill

Healthcare systems fail in phases. A missing planning charter becomes scope creep dressed up as “just one more interface.” A skipped analysis becomes an admission medication-reconciliation screen that does not match what night-shift hospitalists actually do. A design that never met pharmacy, laboratory, or HIM becomes an interface that drops allergies or cannot support a surveyor’s downtime question. An implementation that treats training as a tip sheet produces laminated barcode sheets. A project that ends at first productive use leaves an unowned medication list and a help desk drowning in tickets.

SDLC is how you refuse those failures on a calendar. CPHIMS stems hide the phase inside a political sentence: “just configure what the vendor showed,” “we already bought it, start building,” “agile means we do not write requirements,” “maintenance is operations’ problem.” Name the phase. Then name the control that belongs there.

The five phases you must be able to place

Treat the cycle as a loop, not a one-way staircase. Each phase produces artifacts the next phase is allowed to trust.

Planning is not a kickoff lunch. It names the sponsor, the problem, the out-of-scope list, and the constraints that will kill the work if ignored: capital, interface partners, survey windows, privacy, medical-staff bylaws, and the fact that the emergency department cannot freeze operations for a month. If you cannot say what “done” looks like in a clinical or operational measure, you are not finished planning.

Analysis is where needs, gaps, and requirements live (section 10.2) and where current-state maps earn their keep (section 10.4). If you have not watched a nurse complete admission medication reconciliation at 02:00, you do not have analysis. You have a brochure.

Design translates approved requirements into workflows, data, interfaces, roles, and failure modes. Design includes the downtime path and the identity model. A design that only works when the network is up is incomplete. A design that only works for day-shift attending physicians is also incomplete.

Implementation is build plus test plus training plus conversion plus go-live support. Configuration is not implementation. Neither is “we loaded the vendor starter pack.” Testing here includes integrated paths: order to pharmacy to eMAR, result to acknowledgment, downtime to recovery.

Maintenance is the longest phase. Patches, code upgrades, new order sets, new interfaces, and the slow drift of workarounds all live here. CPHIMS will offer “the project is done at first productive use.” That is a trap. First productive use is when the maintenance clock starts.

Waterfall versus iterative and agile

Waterfall finishes one phase, baselines the output, and moves forward. It fits when the requirement is stable, the interface contract is frozen, and the cost of changing course mid-build is high: a blood-bank analyzer with a locked specification, a regulated medical-device integration, a data-center cutover with a hard weekend window.

Iterative and agile deliver in short increments, show working slices, and learn. They fit EHR optimization, reporting, consumer-portal increments, and many clinical-content cycles—if each increment still has an owner, a test, and a promotion path through non-production environments.

Healthcare is regulated. Agile is not a waiver of:

• Requirements traceability for safety functions
• Change control and environments (development → test → production)
• Validation that a dose-range check, allergy interrupt, two-identifier check, or downtime procedure still works
• Privacy, security, and audit logging
• Named clinical owners for clinical meaning

The CPHIMS-correct model is often hybrid: gated stages for identity, interfaces, medication safety, and revenue-critical claims; iterative delivery for usability, reports, and non-interruptive content. “We are agile, so we will discover the allergy requirement in sprint nine” is how you ship harm.

Fail-fast is for a prototype operations dashboard, not for a hard-stop on look-alike chemotherapy. You can iterate the wording of a best-practice advisory. You cannot iterate whether two identifiers exist at transfusion.

When to revisit a phase

SDLC is a loop because reality changes. Revisit; do not steamroll.

• Back to planning when the sponsor, the problem, or the constraint set changes—a merger, a capital cut, a new CMS or state rule, a survey finding that rewrites scope.
• Back to analysis when implementation or hypercare shows the current-state map was wrong, or when a safety event proves the requirement missed a night-shift or weekend path.
• Back to design when usability testing, integrated testing, or a tabletop downtime drill fails. Do not “train harder” a design that cannot be used.
• Do not jump to implementation because a vendor demo was convincing or because a go-live date was printed on a poster.
• Maintenance findings that look like tickets may be analysis failures. A weekly request to “make the ED tracker show boarding” after an upgrade is a signal to reopen analysis, not to keep patching a screen.

Revisit means you re-baseline the affected artifacts: charter, requirements, design, and tests. Informal hallway redesign is how two units end up on two different standards with no label.

How to read a CPHIMS SDLC stem

1. Name the request (upgrade, new module, interface, optimization).
2. Name the phase the organization is actually in, not the phase on the slide.
3. Ask whether a prior phase was skipped.
4. Ask whether a regulated or safety function is being treated as a casual sprint.
5. Prefer the answer that returns to the missing phase rather than the answer that protects the date.

Scenarios and exam traps

Scenario — EHR upgrade as an install. Leadership schedules a major EHR version upgrade as a technical weekend because “it is just vendor code.” Nobody analyzes which medication-reconciliation screens change, which laboratory interfaces break, or which downtime procedures must be re-rehearsed. Treat the upgrade as a full SDLC event: plan the clinical risk, analyze the delta, design the local build and tests, implement with command-center support, and leave a maintenance owner. A version number is not a completed life cycle.

Scenario — ED tracker by next month. The emergency department wants a new electronic tracker to cut left-without-being-seen after a vendor demo. Operations is already picking colors. The life-cycle move is to finish planning (what outcome, what constraint) and analysis (why patients leave, where boarding actually happens) before design. A prettier board that does not change bed assignment or lab turnaround is skipped analysis wearing a new skin.

Scenario — agile allergy build. A scrum team says medication-allergy checking will “emerge” after several sprints of other stories so the first increment can go live with ordering. Allergy checking is a must-have safety requirement. It is designed, tested, and gated before any increment that lets users order medications. Agile sequencing does not demote it.

Watch these traps:

1. Treating a vendor demo, a purchased license, or certification as completed analysis.
2. Calling the project done at go-live.
3. Using agile as a reason to skip requirements, validation, environments, or change control.
4. Using waterfall as a reason to ignore users until the last month.
5. Training your way out of a design that failed the workflow.
6. Refusing to reopen planning or analysis when the problem, the rule, or work-as-done changed.

Task A.1 is placement: put the work in the right phase, and loop back when evidence says the phase was wrong. Section 10.2 is what analysis is supposed to produce.