Aegis is a Clinical Decision Support System (CDSS) prototype designed to intercept latent suicide risk within the constraints of a 15-minute primary care workflow.
It combines a probabilistic Naïve Bayes baseline with deterministic C-SSRS routing and uses a fixed reference-cohort threshold to create an approximately 8% alert-volume target for Phase 1 workflow evaluation.
Role
Year
Deliverables
- Biomedical Informatics
- Technical Project Management
- Product Management
- Wireframes
- Product & Design Requirements
- Product Requirements
- AI Orchestrated Delivery
Experience the clinical workspace, test the C-SSRS, and inspect the zero-mock validation harness in real time.
Launch Aegis Clinical Workspace (Live Demo)
Inspect the /validate QA Harness
(Note: Accessible via the “Staff sign in” / Tester role toggle in the sidebar footer)
The Clinical Reality: A Gap in the Safety Net
Primary care is a critical point of interception for suicide risk.
On average, 45% of people who died by suicide had contact with a primary care provider within one month before suicide death.
Studies indicate that depression screening alone may fail to detect 30–50% of patients with suicide risk; relying only on PHQ-9 Item 9 presents a particular detection limitation.
Depending on depression screening alone as a standalone safety net increases the risk that patients with suicide risk will remain unidentified during the acute risk window.
To capture the threat accurately, general depression screening must be paired with validated, suicide-specific tools like the Columbia-Suicide Severity Rating Scale (C-SSRS).
The Interception Gap
Primary care creates an opportunity to intervene.
Existing screening alone does not reliably identify who requires suicide-specific assessment.
Opportunity for Intervention
45% of people who died by suicide had contact with a primary care provider within one month before death.
Detection Limitation
30–50% of patients with suicide risk may not be detected by depression screening alone.
Sources:
Luoma et al. (2002) | Horowitz et al. (2023)
Product challenge:
How do you introduce a secondary psychiatric assessment into a tightly constrained 15-minute appointment without destroying the clinic’s schedule?
From Academic Theory to Deployable Reality
The academic proposal described a broad hybrid architecture combining probabilistic risk estimation, structured EHR data, suicide-specific assessment, and, in some versions, NLP-derived chart signals.
For a MVP, that scope was too broad to validate responsibly as a single implementation.
Risk:
Treating a Naïve Bayes output as a literal clinical probability could make a fixed alert threshold unreliable.
Phase 1 architecture narrowed
The MVP would use structured EHR-compatible inputs, pre-computed model outputs, and deterministic workflow routing rather than attempting to validate NLP extraction, live inference, and clinical interaction simultaneously.
This pivot established a controlled testing boundary:
Model outputs remained fixed, while the prototype tested how clearly and consistently clinicians could review a risk signal, complete the suicide-specific assessment, and receive the appropriate disposition.
Designing for Alert-Volume Control
A risk model has limited clinical value if its alert behavior cannot be integrated into the primary care workflow. Rather than treating the Naïve Bayes output as a calibrated estimate of absolute clinical risk, I used the score for its intended MVP function: ordering encounters by relative risk within a fixed reference population.
I reframed the probabilistic layer as an operational prioritization mechanism, while reserving immediate safety escalation for the deterministic C-SSRS rules engine.
Instead of triggering on an uncalibrated probability value, the offline pipeline derives a fixed alert threshold from the historical distribution of scores in a static clinic reference cohort.
Selecting the score associated with the 92nd percentile designates approximately the highest-risk 8% of that reference population for workflow evaluation.
The MVP then applies that fixed cutoff consistently to each synthetic encounter.
This created a testable alert-volume target without tying workflow behavior to an arbitrary raw probability.
It did not assume that exactly 8% of every future patient population would exceed the threshold.
If clinical capacity or the underlying population changes, the cutoff could be reconsidered through the established governance process.
Any revision would require retrospective outcome review, subgroup analysis, and prospective monitoring rather than an automatic adjustment based on staffing alone.
Actionable Explainability:
Making the Risk Signal Inspectable
A risk score without an observable basis becomes a trust demand. Aegis gives the clinician a concise view into the model output without requiring probability calculations during the patient encounter.
The offline statistical pipeline calculates the Naïve Bayes tier scores using class priors and Laplace-smoothed conditional likelihoods.
After assigning the risk tier, the pipeline ranks the patient’s present features by their class-conditional likelihoods, 
, for that tier.
The three highest-ranked factors are exported as static explanation fields with the encounter record.
Interpretation boundary
The interface displays those fields alongside the passive alert, using clinically recognizable labels such as a PHQ-9 finding, a documented prior attempt, or living-alone status.
These factors expose the model terms most associated with the assigned tier. They do not establish causality or provide a complete account of why that tier outranked every alternative.
Phase 1 boundary
For the Phase 1 prototype, this established a deliberate explainability boundary: the interface made the model signal inspectable using native conditional-likelihood terms, while comparative feature attribution and clinician-interpretation testing remained outside the validated scope.
Orchestrating the AI Toolchain for Rapid Validation
The original mandate tested prototype development through a no-code builder within a 48-hour sprint. During implementation, the fixed split-canvas workspace and forward-chaining C-SSRS interactions exposed requirements that needed more explicit control over layout, state, and progressive disclosure.
Before directing implementation, I defined the clinical, mathematical, and architectural boundaries:
- A structured categorical input matrix without NLP-derived features.
- Offline statistical processing using Laplace-smoothed Naïve Bayes likelihoods.
- A fixed threshold derived from the 92nd percentile of the reference cohort.
- Boolean banner outputs and three conditional-likelihood explanation fields.
- Separation of the probabilistic risk output from deterministic C-SSRS routing.
With the architecture and data contracts established, I used multiple AI-assisted development tools to accelerate implementation and verification within those boundaries.
The workflow included Claude Sonnet 4.6, Opus 4.6, Gemini Pro 3.1 and Google AI Studio used as part of the development environment.
The AI-assisted workflow did not originate the clinical logic, mathematical method, or data contract.
I used it to translate defined requirements into interface code, deterministic decision functions, React state-management behavior, and validation assertions.
I directed the tools to generate an initial implementation from the five-case matrix, then reviewed the resulting behavior against the routing requirements.
As implementation progressed, I moved the prototype out of the low-code builder environment and into a standalone React + Vite application using Tailwind CSS and Radix UI primitives.
This transition removed the server-rendered platform dependency and gave me explicit control over layout, progressive disclosure, session isolation, reset behavior, and deterministic testing.
This gave me explicit control over the split-canvas layout, session-isolated state, progressive disclosure, assessment resolution, and deterministic validation behavior.
Intervention 1: Select the Runtime Around State-Dependent Clinical Behavior
As the interaction model became concrete, the primary implementation risk shifted from rapid prototyping to coordinating state-dependent behavior inside a fixed clinical workspace.
The core challenge was not static form assembly.
It was coordinating clinically consequential state transitions inside a fixed workspace.
- Split-canvas transition: Opening the triage drawer shifts the workspace into a 70/30 layout while preserving the visible chart context.
- Progressive Disclosure: Endorsing C-SSRS Question 2 reveals the dependent Questions 3 through 5.
- Dependent-state clearing: Clearing Question 2 conceals and clears Questions 3 through 5 so hidden responses cannot remain eligible for downstream routing.
- Assessment resolution: Pending the selected disposition changes the banner to its resolved state and writes a structured entry into the simulated progress note.
Within the sprint and platform constraints, approximating these transitions would have weakened the evaluation. Reviewers would have been judging an interpretation of the intended workflow rather than the implemented behavior itself
Product decision:
Select the platform around the hardest requirement
For Aegis, that requirement was clinically legible state transition, not rapid page assembly.
Intervention 2: Establishing a Workstation Viewport Policy
Aegis supports viewport widths of 1080 pixels and above. Tablet and phone layouts are intentionally excluded from the Phase 1 boundary.
In many products, excluding smaller screens would represent an incomplete responsive experience.
For this Phase 1 workflow simulation, the narrower boundary protected the interface condition being evaluated: simultaneous visibility of the patient chart and the suicide-risk assessment.
The 70/30 spatial contract: clinician must be able to view the active problem list (left) while simultaneously evaluating the C-SSRS flowsheet (right)
Below the workstation boundary, the Phase 1 design would require one of two major layout changes:
- Stack the surfaces: Move the assessment away from the chart evidence it references.
- Compress the surfaces: Reduce the visible area available to both the chart and assessment.
Either change could remove relevant chart or assessment information from simultaneous view at the moment of disposition. The workstation-oriented EHR reference environment informed the design, but the 1080-pixel minimum was an Aegis Phase 1 product decision rather than a claimed industry standard.
Viewport policy: Aegis renders the Phase 1 chart surface and triage drawer together.
If the spatial contract cannot be maintained, the prototype does not substitute a compressed or stacked version of the workflow.
Resulting Architecture:
Read-Only Baseline, Isolated State
The two scoping decisions produced a four-layer architecture that separates static encounter data, temporary interaction state, deterministic decision logic, and interface presentation.
- Read-Only Encounter Baseline: The application imports
encounters.jsondirectly as its active Phase 1 data source. The file supplies 100 synthetic encounters with fixed chart data, precomputed risk outputs, threshold flags, explanation fields, and QA reference values.
Because the dataset is bundled into the standalone application as a static asset, the interface can read the encounter records but cannot write clinician interactions back into them. - In-Memory Interaction Overlay: React Context maintains a temporary dictionary keyed by encounter ID. Each entry can contain:
– banner state;
– the pended assessment;
– and the generated progress-note snippet.
Unvisited encounters resolve to the clean default state without modifying encounters.json. - Deterministic Decision Functions: Standalone decision functions control dependent-state clearing, disposition priority, order-set selection, and progress-note generation.
The same routing function can therefore support both the clinical interface and the validation harness without reproducing the clinical rules in a separate test-only implementation. - Split-Canvas Clinical Workspace: The interface combines the selected encounters.json record with its corresponding temporary interaction overlay. It renders the fixed chart and risk information together with the current banner, assessment, disposition, and documentation state.
The encounter baseline remains unchanged.
Clinician interactions exist only in the in-memory overlay. Deterministic functions derive disclosure, routing, and documentation from the current assessment values, while the workspace renders those temporary results alongside the fixed encounter record.
Four-layer architecture: read-only encounter baseline, in-memory interaction overlay, deterministic decision functions, and split-canvas clinical workspace.
Once a risk flag exists, does the interface consistently disclose the correct assessment questions, select the highest-priority disposition, and generate the expected documentation state?
Fix the Model Output to Isolate Workflow Behavior
Aegis performs no live machine-learning inference in the browser.
The offline statistical pipeline calculates the Naïve Bayes risk output, applies the fixed threshold derived from the reference cohort, and exports the resulting encounter data to encounters.json baseline.
This boundary separates two systems with different validation requirements.
A model is evaluated statistically. Safety routing is evaluated exactly.
The predictive model would ultimately require population-level evaluation for discrimination, calibration, subgroup performance, and drift. The clinical routing workflow can be evaluated against defined expectations: a given combination of C-SSRS responses should produce the corresponding disclosure state, highest-priority, order-set state, and documentation output.
If model inference and workflow routing both varied during the same Phase 1 test, an incorrect result could originate in either system.
Fixing the model outputs in encounters.json removes inference variance from the workflow test.
A routing defect can then be reproduced against the same encounter data and clinician inputs.
Phase 1 therefore validates the workflow that begins after a risk flag has been produced. It does not validate the predictive performance of a live clinical model. .
Reserve Interruption for the Highest-Acuity Workflow State
Aegis separates the initial risk signal from the subsequent clinical disposition.
A probabilistic flag does not immediately trigger a blocking interaction.
It begins a staged escalation sequence:
This sequence keeps the initial risk signal inspectable without treating every flagged encounter as an emergency.
The review step is preserved between the highest-acuity routing result and the action that commits the disposition.
The hard-stop behavior belongs to the attempted ED Transfer action, not to the probabilistic alert or the Question 5 response alone.
The prototype does not establish that the underlying transfer protocol has been clinically validated in a deployed care environment.
Encode Disclosure and Routing as Pure Decision Functions
The C-SSRS workflow begins with Questions 1, 2, and 6 visible.
Questions 3 through 5 remain hidden until Question 2 is endorsed.
If a clinician endorses Question 2, records responses to Questions 3 through 5, and then reverses Question 2, those dependent responses must also be cleared. Hiding the fields without clearing their values would allow invisible responses to remain eligible for downstream routing.
I separated the workflow into three explicit responsibilities:
- applyProgressiveDisclosureToggle() updates the selected response and clears Questions 3 through 5 when Question 2 is reversed..
- computeTriageState() evaluates the disposition sequence from highest to lowest acuity.
- buildNoteSnippet() converts the endorsed responses and resolved disposition into the documentation text shown in the simulated progress note. .
Because these functions are independent of a server, shared database, and live model request, the clinical interface and validation harness can evaluate the same logic against fixed inputs and expected outputs.
The dependent-state assertion passes only when Questions 3 through 5 can no longer influence routing after Question 2 has been cleared.
A second failure mode is priority inversion.
Multiple C-SSRS conditions may be endorsed in the same assessment. The routing function therefore evaluates the highest-acuity condition first:
Q5 → Q4 or Q6 → Q2 or Q3 → Q1 → negative screen
This ordering ensures that a lower-acuity response cannot replace the disposition associated with Question 5.
When Question 5 is endorsed, computeTriageState() returns VERY_HIGH before evaluating any lower-priority condition.
When multiple criteria are endorsed, the Question 5 condition retains routing priority over lower-acuity responses.
Separate Encounter Baseline From Temporary Interaction State
The application loads 100 synthetic encounters as a read-only baseline.
Clinician interactions do not mutate those underlying records.
Instead, React Context maintains a temporary, per-encounter overlay containing:
- banner state;
- the pended assessment;
- and the generated progress-note snippet.
Isolation is structural
- The encounter record and interaction overlay serve different purposes.
- The encounters.json supplies the fixed chart and risk information.
- The overlay records only the interactions performed during the current session.
- The interface combines the layers for presentation without writing those changes back into encounters.json.
- When an assessment is pended, the Context overlay changes the encounter’s banner to its resolved state, stores the pended assessment, and supplies the generated note text to the simulated progress note.
- The underlying encounter record remains unchanged.
- This boundary supports repeatable and session-isolated evaluation.
A reviewer can dismiss or reopen a banner, complete the assessment, stage a disposition, and generate documentation without altering the shared baseline used by another visitor or future session.
Reset deletes the overlay.
The prototype does not provide longitudinal persistence.
Refreshing or resetting the application removes the temporary assessment state because the overlay is held only in browser memory.
For Phase 1, that limitation is intentional: the prototype evaluates repeatable workflow behavior without presenting temporary demo interactions as durable clinical records.
Make Deterministic QA Visible
The routing logic was too consequential to leave buried in source code. I exposed it through a tester-visible /validate route beside the clinical workspace.
The validation surface executes the same deterministic decision functions used by the triage drawer. It does not recreate the clinical rules in a separate test-only implementation. A reviewer can inspect the expected input, compare it with the resulting disposition, and see whether the assertion passes..
The visible test suite includes:
Complete routing coverage
A five-case matrix exercises the expected C-SSRS outcomes, from a negative screen through the highest-acuity ED Transfer disposition.
Hidden-state protection
The dependent-state assertion verifies that reversing Question 2 clears Questions 3 through 5, preventing concealed responses from continuing to affect routing.
Acuity-priority protection
The priority-inversion assertion verifies that Question 5 retains precedence when lower-acuity conditions are also endorsed.
The clinical workspace and validation route share the same session provider. From the validation surface, the reviewer can also clear the temporary interaction overlay and restore the unchanged encounter baseline.
The QA harness turns an architectural claim into something the reviewer can inspect directly.
The validation surface executes the application’s deterministic routing logic against fixed inputs, exposes the resulting pass or fail states, and allows the temporary session overlay to be cleared without changing the encounter baseline.
What Phase 1 Establishes
Phase 1 establishes that the workflow behaves consistently after a fixed risk flag has been supplied.
It demonstrates that the prototype can:
- preserve chart context while the clinician completes the C-SSRS assessment;
- disclose, clear, and route assessment responses according to the defined rules;
- preserve the highest-acuity disposition when multiple conditions are endorsed;
- generate the expected simulated documentation state;
- and remove temporary interaction state without changing the fixed encounter baseline.
Validation boundary:
This remains a workflow simulation. It does not establish live-model performance, clinical effectiveness, longitudinal persistence, production security, EHR interoperability, or performance in a deployed clinical environment.
Phase 1 does not prove the entire clinical system. It proves that, once a risk flag exists, the interaction and routing behavior can be inspected, repeated, and tested.
That creates the foundation for the next stage: model validation, clinician usability research, persistence design, security engineering, and EHR integration.
From Verified Workflow to Clinical Validation
Phase 1 reduced a broad clinical decision-support concept to one testable product question: could a suicide-specific assessment operate inside the primary care chart without losing context, retaining hidden state, or producing ambiguous routing?
The resulting prototype establishes that the interaction can be implemented as a coherent and repeatable workflow. It preserves the chart-and-assessment relationship, makes the risk signal inspectable, applies deterministic C-SSRS routing, and exposes that behavior through a visible QA surface.
That is an engineering result, not yet a clinical outcome.
The Next Question Is Human
The next phase should place the workflow in front of primary care clinicians and evaluate three questions:
Workflow fit
Can clinicians review the risk signal and complete the assessment without losing chart context or disrupting the encounter?
Alert response
Does the alert attract appropriate attention without encouraging reflexive dismissal or unnecessary interruption?
Decision confidence
Do the displayed rationale, assessment sequence, and resulting disposition give clinicians enough information to understand and act on the recommendation?
These questions deliberately precede deeper investment in live model hosting, persistence, EHR integration, and production governance.
If the workflow does not fit clinical practice, scaling the surrounding infrastructure would only make the wrong interaction more expensive.
Phase 1 made the workflow testable. The next phase must determine whether clinicians find it usable, credible, and appropriate for practice.
Explore the Live Prototype
Experience the 70/30 clinical workspace, test the C-SSRS progressive disclosure logic, and inspect the zero-mock validation harness in real time.
Launch Aegis Clinical Workspace (Live Demo)
Inspect the /validate QA Harness
(Note: Accessible via the “Staff sign in” / Tester role toggle in the sidebar footer)
Angerhofer Richards, J., Cruz, M., Stewart, C., Lee, A. K., Ryan, T. C., Ahmedani, B. K., & Simon, G. E. (2024). Effectiveness of integrating suicide care in primary care: Secondary analysis of a stepped-wedge, cluster randomized implementation trial. Annals of Internal Medicine, 177(11), 1471–1481. https://doi.org/10.7326/M24-0024
Ayer, L., Horowitz, L. M., Colpe, L., Lowry, N. J., Ryan, P. C., Boudreaux, E., Little, V., Erban, S., Ramirez-Estrada, S., & Schoenbaum, M. (2022). Clinical pathway for suicide risk screening in adult primary care settings: Special recommendations. Journal of the Academy of Consultation-Liaison Psychiatry, 63(5), 497–510. https://doi.org/10.1016/j.jaclp.2022.05.003
Bryan, C. J., Allen, M. H., Bryan, A. O., Thomsen, C. J., Baker, J. C., & May, A. M. (2023). Does suicide risk screening improve the identification of primary care patients who will attempt suicide versus depression screening alone? The Joint Commission Journal on Quality and Patient Safety, 49(12), 680–688. https://doi.org/10.1016/j.jcjq.2023.08.008
Cammack, A. L., Stevens, M. R., Naumann, R. B., et al. (2024). Vital signs: Suicide rates and selected county-level factors, United States, 2022. Morbidity and Mortality Weekly Report, 73(37), 810–818. https://doi.org/10.15585/mmwr.mm7337e1
Delgadillo, J., Budimir, S., Barkham, M., Humer, E., Pieh, C., & Probst, T. (2023). A Bayesian network analysis of psychosocial risk and protective factors for suicidal ideation. Frontiers in Public Health, 11, 1010264. https://doi.org/10.3389/fpubh.2023.1010264
Domingos, P., & Pazzani, M. (1997). On the optimality of the simple Bayesian classifier under zero-one loss. Machine Learning, 29(2–3), 103–130.
Etter, D. J., McCord, A., Ouyang, F., Gilbert, A. L., Williams, R. L., Hall, J. A., Tu, W., Downs, S. M., & Aalsma, M. C. (2018). Suicide screening in primary care: Use of an electronic screener to assess suicidality and improve provider follow-up for adolescents. Journal of Adolescent Health, 62(2), 191–197.
Hand, D. J., & Yu, K. (2001). Idiot’s Bayes: Not so stupid after all? International Statistical Review, 69(3), 385–399.
Horowitz, L. M., Ryan, P. C., Wei, A. X., Boudreaux, E. D., Ackerman, J. P., & Bridge, J. A. (2023). Screening and assessing suicide risk in medical settings: Feasible strategies for early detection. Focus, 21(2), 145–151. https://doi.org/10.1176/appi.focus.20220086
Ledley, R. S., & Lusted, L. B. (1959). Reasoning foundations of medical diagnosis. Science, 130(3366), 9–21.
Luoma, J. B., Martin, C. E., & Pearson, J. L. (2002). Contact with mental health and primary care providers before suicide: A review of the evidence. The American Journal of Psychiatry, 159(6), 909–916. https://doi.org/10.1176/appi.ajp.159.6.909
Mitchell, T. M. (1997). Machine learning. McGraw-Hill.
Simon, G. E., Rutter, C. M., Peterson, D., Oliver, M., Whiteside, U., Operskalski, B., & Ludman, E. J. (2013). Does response on the PHQ-9 Depression Questionnaire predict subsequent suicide attempt or suicide death? Psychiatric Services, 64(12), 1195–1202. https://doi.org/10.1176/appi.ps.201200587
Walsh, C. G., Ripperger, M. A., Novak, L., et al. (2025). Risk model-guided clinical decision support for suicide screening: A randomized clinical trial. JAMA Network Open, 8(1), e2452371. https://doi.org/10.1001/jamanetworkopen.2024.52371
