Alzheimer's: Update testing model by NathanielBlairStahn · Pull Request #1888 · ihmeuw/vivarium_research

NathanielBlairStahn · 2026-01-23T11:00:57Z

Update testing coverage function to level off more slowly
Introduce randomness to BBBM testing frequency so that the interval between tests is uniformly distributed between 3 years and 5 years
Extend BBBM testing history to 5 years prior to entering sim instead of 3 years prior
(minor edit) Use automatic numbering and reformat bulleted sublist in BBBM testing algorithm

Note: There are some things left to confirm or update, so I marked this as a draft pull request:

Confirm that the proposed BBBM testing coverage function, testing algorithm, and testing history are what we want
Edit the assumptions and limitations to reflect the above changes
Add model 12.0 to the model run requests table

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst

SylLutze · 2026-01-23T15:07:37Z

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst

+that most people will get retested within 5 years (Lilly requested that
+tests occur every 3-5 years). Specifically, the probability that a
+simulant *doesn't* get retested between 3 and 5 years (i.e., on one of
+the 5 time steps at 3, 3.5, 4, 4.5, 5) is :math:`(1-0.5)^5 = 3.125\%`.


Hmm this works I suppose. I had done it differently in the MSLT and would need to math it out more to compare the relative distribution of testing across years. The MSLT will also be the vast majority of retesting so it probably won't make a huge difference what we do here.

I was thinking, especially since it is the same simulants being retested every time, that when a simulant tested negative we would assign them a "re-test date" uniformly selected for 3-5 years in the future. This would take more data storage, but since everyone in the sim is positive we shouldn't have all that many people testing negative and needing future dates stored.

I suppose I could also update the MSLT to reflect this new methos if we prefer it.

Let's have Nathaniel update this to request the time until retest be uniformly distributed between 3 and 5 years, as we discussed this morning. How to accomplish this can be a detail left to the engineers, but I expect that having a retest_by column of pd.Timestamp data will be a straightforward approach for them.

Ok, instead of introducing an explicit "re-test date," I updated my hazard function to be non-constant so that it results in a uniform distribution for the waiting time instead of a geometric distribution.

NathanielBlairStahn · 2026-01-23T19:29:45Z

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst

-upon entering the simulation, we will assign a BBBM testing history to
-each initialized simulant who is eligible for a BBBM test. Since
-simulants are only eligible for testing every three years (more
-precisely, every 6 time steps), we will assign a random test date within


@aflaxman I wrote this section post hoc to describe what the engineers actually did, which involves counting time steps explicitly. I think they do it that way to ensure uniformity in sampling since the time steps are not exactly half a year (though really they should be if we wanted to do things better...), so maybe if we just rounded from a continuous time, it would tend to be biased in one direction or the other (though I'm not totally sure). Now that we're re-doing this piece, do you think I should rewrite this in terms of continuous time to avoid locking us into a particular time step, or is it fine to leave it in terms of the number of time steps? Rewriting it will require an explicit strategy for mapping continuous time to a discrete time step -- I'm not sure what the best strategy is or what strategies are compatible with how the engineers think about time steps. I think we are slated to have a wider team meeting about time-step-related issues like this at some point, but I'm not sure when.

Fine to keep to minimal change and not rewrite

aflaxman · 2026-01-23T20:14:38Z

Fine to leave in terms of number of time steps. But I don't want to make it a habit for future projects. :yuck face:

________________________________ From: Nathaniel Blair-Stahn ***@***.***> Sent: Friday, January 23, 2026 11:30 AM To: ihmeuw/vivarium_research ***@***.***> Cc: Abraham Flaxman ***@***.***>; Mention ***@***.***> Subject: Re: [ihmeuw/vivarium_research] Alzheimer's: Update testing model (PR #1888) @NathanielBlairStahn commented on this pull request.

________________________________ In docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst<https://urldefense.com/v3/__https://github.com/ihmeuw/vivarium_research/pull/1888*discussion_r2722549117__;Iw!!K-Hz7m0Vt54!l7L2oHL2m5hCL3KuGDzucYs7ocr5VvMlbwCWBkemxFm6OoI6AZVbT28DHgPS4DHCdhTRstFsLfSXrFcTa_1T$>:

On initialization '''''''''''''''''

…

-In order to avoid having all eligible simulants be tested immediately -upon entering the simulation, we will assign a BBBM testing history to -each initialized simulant who is eligible for a BBBM test. Since -simulants are only eligible for testing every three years (more -precisely, every 6 time steps), we will assign a random test date within @aflaxman<https://urldefense.com/v3/__https://github.com/aflaxman__;!!K-Hz7m0Vt54!l7L2oHL2m5hCL3KuGDzucYs7ocr5VvMlbwCWBkemxFm6OoI6AZVbT28DHgPS4DHCdhTRstFsLfSXrKbHkLEn$> I wrote this section post hoc to describe what the engineers actually did, which involves counting time steps explicitly. I think they do it that way to ensure uniformity in sampling since the time steps are not exactly half a year (though really they should be if we wanted to do things better...), so maybe if we just rounded from a continuous time, it would tend to be biased in one direction or the other (though I'm not totally sure). Now that we're re-doing this piece, do you think I should rewrite this in terms of continuous time to avoid locking us into a particular time step, or is it fine to leave it in terms of the number of time steps? Rewriting it will require an explicit strategy for mapping continuous time to a discrete time step -- I'm not sure what the best strategy is or what strategies are compatible with how the engineers think about time steps. I think we are slated to have a wider team meeting about time-step-related issues like this at some point, but I'm not sure when. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/ihmeuw/vivarium_research/pull/1888*pullrequestreview-3699236630__;Iw!!K-Hz7m0Vt54!l7L2oHL2m5hCL3KuGDzucYs7ocr5VvMlbwCWBkemxFm6OoI6AZVbT28DHgPS4DHCdhTRstFsLfSXrIVICEVP$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAAMQJBZHR4YHTYOFOL5WI34IJZD7AVCNFSM6AAAAACSU3WWGGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTMOJZGIZTMNRTGA__;!!K-Hz7m0Vt54!l7L2oHL2m5hCL3KuGDzucYs7ocr5VvMlbwCWBkemxFm6OoI6AZVbT28DHgPS4DHCdhTRstFsLfSXrMjVaNAz$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

… 5 years

aflaxman · 2026-01-23T20:25:05Z

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst

+that most people will get retested within 5 years (Lilly requested that
+tests occur every 3-5 years). Specifically, the probability that a
+simulant *doesn't* get retested between 3 and 5 years (i.e., on one of
+the 5 time steps at 3, 3.5, 4, 4.5, 5) is :math:`(1-0.5)^5 = 3.125\%`.


Let's have Nathaniel update this to request the time until retest be uniformly distributed between 3 and 5 years, as we discussed this morning. How to accomplish this can be a detail left to the engineers, but I expect that having a retest_by column of pd.Timestamp data will be a straightforward approach for them.

aflaxman · 2026-01-23T20:25:51Z

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst

-upon entering the simulation, we will assign a BBBM testing history to
-each initialized simulant who is eligible for a BBBM test. Since
-simulants are only eligible for testing every three years (more
-precisely, every 6 time steps), we will assign a random test date within


Fine to keep to minimal change and not rewrite

…e 'on timestep' instructions

…to use it

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst

…nosis.rst

…implementation

aflaxman · 2026-02-03T16:23:33Z

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst

+
+- Simulant is not in MCI or AD dementia state (they can only be in
+  susceptible or preclinical)
+- Simulant age is :math:`\ge 65` and :math:`< 80`


Note this change: >= 65 now, at CSU client's request. (It was different before)

Albrja/mic 6782/update testing Update testing model - *Category*: Feature - *JIRA issue*: https://jira.ihme.washington.edu/browse/MIC-6782 - *Research reference*: ihmeuw/vivarium_research#1888 Changes and notes -update retesting period so simulants are retested uniformly from 3-5 years instead of every 3 years -update initialization to reflect updates to testing history sampling Verification and Testing Looked at simulants in interactive simulation and saw the correct sampling for simulants test history and future test dates.

NathanielBlairStahn added 3 commits January 23, 2026 01:38

update testing coverage function

e777a80

add randomness to testing interval

6109f70

update BBBM testing history from a 3-year interval to a 5-year interval

9f5b82d

NathanielBlairStahn requested review from SylLutze and aflaxman January 23, 2026 11:00

NathanielBlairStahn added Vivarium modeling strategy Documentation for Vivarium modeling strategy update Add this tag to any section that is updated Alzheimers_sim Alzheimer's simulation for CSU, starting July 2025 labels Jan 23, 2026

SylLutze reviewed Jan 23, 2026

View reviewed changes

NathanielBlairStahn commented Jan 23, 2026

View reviewed changes

adjust algorithm to distribute next test date uniformly between 3 and…

5fbef6e

… 5 years

aflaxman approved these changes Jan 24, 2026

View reviewed changes

NathanielBlairStahn added 7 commits January 26, 2026 11:47

update initialization strategy for BBBM testing and describe it befor…

144321a

…e 'on timestep' instructions

delete old information and add a to-do to explain probability formula

7df9a20

clarifications for how to count time steps

346849b

remove testing function knot at 2050

695a008

edit BBBM testing algorithm to assign a testing history just in time …

f25cfdf

…to use it

rewrite initialization strategy to assign NaT appropriately

875613b

comment out alternate BBBM testing algorithm

4d28ff2

Base automatically changed from alzheimers/model-11-run-request to main January 27, 2026 14:40

Math explanation, adding model run request, adjusting limitations

2bc0abf

SylLutze marked this pull request as ready for review January 27, 2026 15:29

Merge branch 'main' into alzheimers/model-12

bde4322

SylLutze approved these changes Jan 27, 2026

View reviewed changes

Syl Lutze and others added 2 commits January 27, 2026 15:54

changing to test immediately upon eligibility

d421514

clarify testing algorithm and clean up assumptions

cce45a0

SylLutze reviewed Jan 30, 2026

View reviewed changes

docs/source/models/intervention_models/alzheimers/testing_diagnosis.rst Outdated Show resolved Hide resolved

Update docs/source/models/intervention_models/alzheimers/testing_diag…

28bc036

…nosis.rst

albrja mentioned this pull request Feb 3, 2026

Albrja/mic 6782/update testing ihmeuw/vivarium_csu_alzheimers#66

Merged

Updating age, sensitivity value, and reorganizing the match engineer …

febaa79

…implementation

SylLutze requested review from aflaxman, albrja and rmudambi February 3, 2026 16:19

aflaxman reviewed Feb 3, 2026

View reviewed changes

aflaxman approved these changes Feb 3, 2026

View reviewed changes

Updating to test future date not test history date

d6a46ca

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Alzheimer's: Update testing model#1888

Alzheimer's: Update testing model#1888
NathanielBlairStahn wants to merge 18 commits intomainfrom
alzheimers/model-12

NathanielBlairStahn commented Jan 23, 2026 •

edited

Loading

Uh oh!

Uh oh!

SylLutze Jan 23, 2026

Uh oh!

aflaxman Jan 23, 2026

Uh oh!

NathanielBlairStahn Jan 26, 2026

Uh oh!

NathanielBlairStahn Jan 23, 2026

Uh oh!

aflaxman Jan 23, 2026

Uh oh!

aflaxman commented Jan 23, 2026 via email

Uh oh!

aflaxman Jan 23, 2026

Uh oh!

aflaxman Jan 23, 2026

Uh oh!

Uh oh!

aflaxman Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Comments

Conversation

NathanielBlairStahn commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aflaxman commented Jan 23, 2026 via email

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Comments

NathanielBlairStahn commented Jan 23, 2026 •

edited

Loading