Final Project: Public Health Brief

Modified

September 30, 2026

Important

Due 12/11. See Project Central for the full project overview. Make sure you have addressed the feedback from all of your checkpoints.

Goal

All quarter, you have used probability and simulation to study one public health program. In the final project, you will pull that work together and translate it for the person who runs the program: a program manager who needs to make decisions but has never taken a probability class and will never see your code.

Your brief should answer one question: What does probability tell us about this program, and what should the manager keep in mind when making decisions?

What you will submit

You will submit two pieces. One submission per team.

Piece What it is Who it is for Format
1. Public health brief A 2-page summary of your findings, or a 5-minute recorded explanation The manager of the program in your scenario PDF (brief), or a video link plus a PDF of your slides (recording)
2. Technical appendix Your revised Checkpoints 1–3 combined into one Quarto file Me (and any statistician who wants to check your work) Rendered HTML (with code-fold: true) plus your .qmd

Name your files lastname_firstinit_final_brief.pdf and lastname_firstinit_final_appendix.html (and .qmd). If you work in a pair, use both last names. Submit everything on Brightspace.

Part 1: The public health brief

Who you are writing for

Your reader is the manager of the program in your scenario:

  • Scenario A: the manager of the county’s mobile mammography van program.
  • Scenario B: the manager of the county health department’s COVID-19 testing and contact tracing team.
  • Scenario C: the manager of the state’s newborn screening program.

This person knows their program well. They know what a mammogram, a rapid test, or a pulse oximetry screen is. They do not know what \(P(D \mid T^+)\), a Binomial distribution, or the Central Limit Theorem is, and they do not need to. They need to know what your results mean for the decisions they make.

Format

Choose one format:

  • Written brief: at most 2 pages (8.5” × 11”), exported as a PDF. You may make it in Quarto, Word, PowerPoint, Google Docs, Canva, or any other tool.
  • Recorded explanation: a video of 5 minutes or less where you walk through slides. Submit a link to the video (make sure I can view it) and a PDF of your slides. If you work in a pair, both partners should speak.

Both formats need the same seven sections, described below. You are welcome to change the layout and style.

What your brief should include

  1. Title and headline takeaway
  2. The program and the question
  3. Where the numbers come from
  4. Finding 1: What a positive result means (from Checkpoint 1)
  5. Finding 2: Planning for the count (from Checkpoint 2)
  6. Finding 3: One person versus the average (from Checkpoint 3)
  7. What to keep in mind

A short sources line goes at the bottom of the brief (see Sources).

Title and headline takeaway

  • Title: Keep it plain and descriptive. A reader should know what the brief is about before they read a full sentence. For example: “What Probability Tells Us About Our Mobile Mammography Program.” Include your name(s) under the title.
  • Headline takeaway: One sentence, in plain language, that states the most important thing you want the manager to remember. If the manager only reads one line, this is it.
Tip

Write the title and headline last, after you have written your findings. It is much easier to summarize findings you have already written.

The program and the question

In 2–4 sentences, describe the program (who it serves, and what test, count, or measurement it deals with) and the decisions the manager has to make. You can start from the scenario description you wrote in Checkpoint 0.

Where the numbers come from

In 2–3 sentences, explain in plain language where your input values come from: the published studies in your source packet and the course values on your scenario card. You do not need to list every number here. The point is to show the reader that your results rest on real, published estimates.

Findings

You will have three findings, one from each checkpoint. Each finding has three parts:

  • A short headline: a few words that name the point, like a newspaper subheading. For example: “Most Abnormal Reads Are Not Cancer.”
  • One visual: a polished plot or table from your checkpoint (see Polishing your visuals).
  • A 2–4 sentence caption: state the key number, then say what it means for the program.

Here is what each finding should cover:

Finding Checkpoint What it should tell the manager Good visuals to consider
1. What a positive result means CP 1 Out of the people who get a positive result, how many actually have the condition? How would this change in a group with a higher or lower prevalence? A natural frequency diagram (e.g., “out of 10,000 people screened…”) or your PPV-versus-prevalence plot
2. Planning for the count CP 2 What is a typical day, household, or year? How often does an unusual one happen, and what does that mean for planning? Your PMF plot, with the planning threshold marked
3. One person versus the average CP 3 How different is what happens to one person from what happens on average across many people? The distribution of a single observation next to the distribution of the average

Use natural frequencies instead of probability notation wherever you can. For example, a Finding 1 caption might read:

Headline: Most Abnormal Reads Are Not Cancer

Caption: Out of every 1,000 women screened on the van, about 83 will have an abnormal read, but only about 6 of those 83 will have breast cancer. This means that most women who are called back will get good news at their follow-up appointment.

NoteBe honest about uncertainty

Your numbers come from models built on published estimates, not from the program’s own data. Use words like “about,” “we expect,” and “roughly” rather than stating results as exact facts. For example, “we expect about 24 babies with CCHD each year,” not “there will be 24 babies with CCHD.”

What to keep in mind

In 3–5 sentences (or bullet points), tell the manager what your findings mean for their decisions. For example: how to talk with people who get a positive result, how much capacity to plan for, or how to read the averages the program reports.

Include at least one assumption from your checkpoints that might not hold in real life (for example, the assumption most likely to fail from Checkpoint 2), and explain in plain language how it could change your advice.

Tip

You do not need to make formal policy recommendations. Describe what your results suggest and what is worth a closer look. Be careful not to claim more than your models can support.

Sources

Add a short line at the bottom of the brief that cites the published sources you used from your source packet. A short format is fine (e.g., “Lee CI, et al. Radiology. 2023.”), since the full citations are in your technical appendix.

Polishing your visuals

The plots from your checkpoints were made for me. In the brief, they need to stand on their own for a manager. Before you add each one, revise it so that it has:

  • A plain-language, descriptive title (e.g., “Follow-up appointments needed after a van day of 40 screens,” not “PMF of X”)
  • Axis labels in plain language, with units (no \(X\), \(Y\), or variable names from your code)
  • Only the information the reader needs. Remove simulation-versus-theory comparisons, extra lines, and default legends that do not help the reader.
  • A deliberate color choice that is consistent across your visuals, and a clean theme (e.g., theme_minimal() instead of the default gray background)

To save a ggplot as an image:

ggsave(here("project", "images", "finding_2.png"), plot = my_plot,
       width = 5, height = 3.5, units = "in", dpi = 300)

Save at dpi = 300 so the image looks crisp on a printed page, and set the width and height to roughly the size of the space in your brief so you do not have to stretch or squish it. Then open the image and check that the text is still readable at that size.

Tip

Simpler is better. A clear bar chart with one highlighted bar is often easier to understand than a detailed plot. Ask yourself: what is the one thing I want the manager to see in this visual?

Part 2: The technical appendix

The technical appendix is your full statistical work, revised and combined into one document.

  • Combine your Checkpoints 1–3 into one Quarto file with a section for each checkpoint.
  • Revise each checkpoint using my feedback. Fix any calculation errors, missing work, or unclear explanations.
  • At the top of the file, include a short revision notes list that says what you changed in each checkpoint (for example, “CP 2: corrected \(P(X > 6)\), which used the wrong inequality”).
  • Include a references section at the end with the full citation for each source you used.
  • Render to HTML with code-fold: true, and make sure the file renders without errors.

The numbers in your brief should match the numbers in your technical appendix. If you rounded a number in the brief, round it from the value in your appendix.

Before you submit

Read your brief as if you were the program manager seeing it for the first time:

  • Does it read cleanly from top to bottom?
  • Does every visual have a headline and a caption?
  • Is there anything left that still sounds like it was written for this class instead of for the manager (probability notation, distribution names, variable names, or numbers without an explanation)?
  • Do the numbers in the brief match your technical appendix?

For a recording, watch it once all the way through before you submit, and check that the link works when you are logged out.

Rubric

Criterion 3 2 1
Accurate results (numbers in the brief and appendix are correct and match each other) Correct and consistent throughout Small errors or mismatches Major errors
Revisions (appendix addresses checkpoint feedback; revision notes included) All feedback addressed and documented Most feedback addressed Little feedback addressed, or no revision notes
Context (program, question, and sources are clear) Reader understands the program, the decisions, and where the numbers come from Some context is missing or unclear Little or no context
Findings (three findings, each with a headline, visual, and caption) All three findings are clear, and each connects to the program One finding is missing a piece or is unclear Findings are missing or disconnected from the program
Plain language (written for the manager, using natural frequencies) No unexplained jargon or notation; numbers are always interpreted Some jargon, notation, or uninterpreted numbers Written mostly for a statistician
What to keep in mind (implications and at least one assumption) Practical, honest, and does not overreach Vague or overreaches a little Missing or misleading
Visuals (polished and able to stand on their own) Clear, legible, and consistent Readable but not fully polished Hard to read, or missing
Format (length, sources line, file names, renders or plays correctly) Meets all requirements Minor issues Major issues