DPH 850 Module 4 Planning an Information System Example

Reviewed by Douglas Renshaw, MBA Aspen University Updated September 2026

This DPH 850 Module 4 sample paper plans a replacement disease surveillance system for a composite state health department whose current system depends on manual entry for about 30% of case reports. Health Informatics for Public Health Leaders, offered in Aspen's DrPH program, covers planning information systems. The paper states the problem, maps stakeholders including 34 local health departments and gathers requirements through observation and user stories. A four-column table sets priority requirements. Build, buy and shared-platform options are compared, and a $14.6 million three-year budget, timeline, risks and success measures follow. Governance, procurement, data migration, security, funding sustainability, local engagement and rejected alternatives complete the plan.

CourseDPH 850 Health Informatics for Public Health Leaders
ModuleModule 4
Paper typeSystem planning paper
LengthAbout 1,145 words, 7 pages
FormatAPA 7 student paper
SchoolAspen University
ProgramDoctor of Public Health
UpdatedSeptember 2026

Free sample paper for DPH 850 Module 4

1

Before the Contract Is Signed: Planning a Disease Surveillance System for a State Health Department

Student Name

Doctor of Public Health Program, Aspen University

DPH 850: Health Informatics for Public Health Leaders

Instructor Name

Month Day, Year

What this page is doingThe title stresses that most system success or failure is decided in planning. APA 7 student title page.
2

Before the Contract Is Signed: Planning a Disease Surveillance System for a State Health Department

Information systems often fail not because of technology but because of poor planning: unclear goals, missing users, unrealistic budgets and timelines. This paper plans a replacement disease surveillance system for a composite state health department responsible for 4.2 million residents, whose 18-year-old system still needs staff to key in nearly a third of case reports by hand.

Problem Statement

The current system cannot receive electronic case reports, requires staff to re-enter data from faxes, lacks tools for outbreak analysis and cannot share data easily with local health departments. During the pandemic, backlogs of thousands of reports delayed investigations. The new system must automate intake, support investigation and analysis and connect state and local users.

What this page is doingStating the problem in operational terms shows the grader what the system must fix.
3

Stakeholders

Stakeholders include state epidemiologists and disease investigators, 34 local health departments, hospital and commercial laboratories, clinics that report cases, the state's information technology agency, the budget office, national surveillance programs and, indirectly, the public. Each has different needs and different power over the project.

Gathering Requirements

Requirements were gathered by observing investigators at work, holding workshops with local health departments, reviewing data flows and writing user stories such as: as a local investigator, I need new cases in my county to appear in my queue within an hour so that I can call patients the same day. Observation revealed workarounds that interviews alone would have missed.

Key Requirements

The table lists priority requirements with rationale.

RequirementTypePriorityRationale
Receive electronic laboratory and case reports in HL7 version 2 and FHIRFunctionalMust haveEliminate manual entry
Automatic deduplication and case matchingFunctionalMust haveAvoid double counting
Role-based access for state and local usersTechnicalMust haveProtect privacy; share workload
Configurable case investigation formsFunctionalMust haveAdapt to new diseases quickly
Outbreak detection and mapping toolsFunctionalShould haveSpeed recognition of clusters
Data export in standard formatsTechnicalMust haveAvoid vendor lock-in
Capacity for ten times normal volumeTechnicalMust haveHandle surges

Build Versus Buy

Options include building a custom system, buying a commercial product or joining a multistate platform. A custom system fits local needs but is costly to maintain. A commercial product is faster but may require costly customization. A shared platform spreads costs and benefits from other states' experience but offers less control. The analysis recommends a shared platform with state-specific configuration.

Budget

The three-year budget is $14.6 million: $6.2 million for licensing and hosting, $3.8 million for configuration and interfaces, $2.4 million for data migration and testing, $1.3 million for training and change management and $0.9 million for project management and contingency. Ongoing costs after launch are estimated at $2.1 million a year.

Timeline

Year one covers procurement, configuration and interfaces with the largest laboratories. Year two covers data migration, testing and a pilot with six local health departments. Year three covers statewide rollout, retirement of the old system and optimization. Parallel operation of both systems for three months reduces risk at cutover. Each phase ends with a formal go or no-go decision by the steering committee.

Risks

Major risks include delays in laboratory interfaces, data migration errors, staff resistance, vendor performance problems and loss of funding. Each has a mitigation: early interface testing, a migration validation plan, user involvement from the start, contract penalties and milestones tied to payment, and a funding plan that combines federal grants with state appropriations.

Success Measures

Success will be measured using the dimensions of the information systems success model (DeLone & McLean, 2003): system quality, such as uptime; information quality, such as completeness of key fields; service quality, such as help desk response; use; user satisfaction; and net benefits, such as reduced time from report to investigation.

Lessons From Failed Projects

Health information technology has often underdelivered because systems were not interoperable, not user-friendly and not paired with process change (Kellermann & Jones, 2013). The plan addresses these lessons by requiring standards, involving users in design and budgeting for training and workflow redesign.

Organizational Readiness

Implementation research emphasizes that organizational issues, including leadership support, user engagement and fit with work practices, often determine success more than technical features (Cresswell & Sheikh, 2013). The plan names an executive sponsor, forms a user advisory group and assesses readiness in each local health department.

Governance of the Project

A steering committee chaired by the state epidemiologist, with members from local health departments, information technology, finance and legal, will oversee the project. It will approve scope changes, monitor budget and schedule and resolve disputes. A project management office will track milestones weekly and report risks to the committee monthly.

Procurement

Procurement must follow state rules, which can take a year or more. The plan uses an existing multistate contract vehicle to shorten procurement and writes requirements as outcomes where possible, so that vendors propose solutions rather than meeting a rigid checklist.

Data Migration Plan

Eighteen years of records must move to the new system. The plan maps old fields to new ones, cleans duplicates, tests migrated samples against originals and decides which historical data to migrate fully and which to archive. Errors in migration can corrupt trend data used for years, so validation receives dedicated staff and time.

Privacy and Security Requirements

The system will hold identifiable health information. Requirements include encryption in transit and at rest, role-based access, audit logs, multifactor authentication and compliance with state security standards. The vendor must support breach notification and regular security testing.

Funding Sustainability

Federal data modernization grants cover much of the initial cost, but ongoing costs of about $2.1 million a year must be carried in the state budget. The plan includes a request for a recurring appropriation beginning in year three, supported by projected savings from reduced manual entry.

Engaging Local Health Departments

Local health departments will use the system most, so they help shape it. Six local representatives sit on the requirements team, and every local department receives a briefing and a chance to comment on draft requirements. Their early involvement is meant to build ownership and surface needs, such as offline access during field investigations, that state staff might overlook.

Alternatives Considered and Rejected

The team also considered upgrading the current system rather than replacing it. The vendor no longer supports its underlying database, security patches are ending and the architecture cannot accept modern standards, so an upgrade would cost nearly as much as replacement while leaving core limits in place. Documenting rejected options shows funders that the recommendation followed real analysis.

Conclusion

Planning a new surveillance system requires a clear problem statement, broad stakeholder involvement, requirements grounded in real work, a realistic budget and timeline, identified risks and measures of success. The plan recommends a shared platform configured for state needs and places people and processes at the center, giving the modernization a strong foundation before any contract is signed.

References

Cresswell, K., & Sheikh, A. (2013). Organizational issues in the implementation and adoption of health information technology innovations: An interpretative review. International Journal of Medical Informatics, 82(5), e73-e86. https://doi.org/10.1016/j.ijmedinf.2012.10.007

DeLone, W. H., & McLean, E. R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9-30. https://doi.org/10.1080/07421222.2003.11045748

Kellermann, A. L., & Jones, S. S. (2013). What it will take to achieve the as-yet-unfulfilled promises of health information technology. Health Affairs, 32(1), 63-68. https://doi.org/10.1377/hlthaff.2012.0693

Reading the DPH 850 Module 4 assignment instructions

Planning information systems is part of Aspen's DPH 850 catalog description, and the fourth module's instructions are posted only for students taking the course, so this example writes a full plan. Planning papers usually ask for a problem statement, stakeholders, requirements, options, budget, timeline, risks and measures of success. State the problem in operational terms. Gather requirements from observed work, not only interviews. Prioritize requirements in a table. Compare at least three options. Show budget arithmetic. Name risks with mitigations. Define success before launch. Describe how users will be involved in design, not only consulted at the start. Plan data migration as its own workstream.

How this DPH 850 Module 4 example is built

The plan moves from the problem statement and stakeholders to requirements gathering and a four-column requirements table. Build versus buy, budget, timeline, risks and success measures follow, along with lessons from failed projects and organizational readiness. Project governance, procurement, data migration, privacy and security, funding sustainability, engaging local health departments and alternatives considered and rejected are added. Next to the problem statement, a margin comment explains why operational terms make the plan testable. The conclusion recommends a shared platform. The requirements table drives the rest of the plan, since the options analysis, budget and success measures all refer back to its priorities.

Reading the DPH 850 Module 4 grading rubric

System plans are graded on a clear problem, broad stakeholder input, prioritized requirements, realistic budget and timeline, identified risks and defined success. This plan cites DeLone and McLean's success model, Kellermann and Jones on health IT shortfalls and Cresswell and Sheikh on organizational issues in APA style. The requirements table ties each item to a reason. Budget lines sum correctly. Data migration and security receive their own sections. Documenting rejected alternatives shows funders the recommendation came from analysis, which graders value. The plan also addresses procurement rules and ongoing costs, two practical realities that often derail public sector technology projects when they are left out of early planning. Its success measures are defined before launch, so the later evaluation has a baseline.

DPH 850 Module 4 help from the desk

Students often write plans that are really wish lists, with no priorities, costs or risks. Others skip data migration entirely. Rank requirements. Add up your budget. Name who decides at each phase. Plan migration and validation. Include ongoing costs after launch. If you are unsure how to write user stories, a tutor can help you draft several from a real workflow. Finish by stating plainly what you want leaders to approve. Before writing, list every group that will touch the system and one thing each needs from it. That list becomes your stakeholder section and the source of your user stories, and it shows readers that the plan starts from real work.

Write yours, or have the desk draft it

This paper is an original model document written by our desk, not a submitted student paper and not an official Aspen University document. Read it for the moves, then write your own to the instructions in your classroom. If you want one built to your exact prompt and rubric, the first custom sample is free and arrives in 24 to 48 hours.

More DPH 850 and Doctor of Public Health sample papers

DPH 850 Module 4 questions, answered

What does DPH 850 Module 4 usually ask for?

Aspen's DPH 850 covers planning information systems, so a system planning paper is a typical assignment. Confirm with your classroom prompt.

What is a user story?

A short statement of what a user needs a system to do and why, used to define requirements.

Why run old and new systems in parallel?

To catch errors and ensure no data are lost before the old system is retired.

Where can I find a free DPH 850 Module 4 sample paper?

This page presents the surveillance system plan and its table of priority requirements with rationale.

What goes into an information system plan in DPH 850 Module 4?

A problem statement, stakeholders, prioritized requirements, options analysis, budget, timeline, risks, governance and measures of success.