Technical approach & risk register
This page makes the engineering behind the prototype explicit: how what you can click today maps to the proposed production architecture in the CDC-managed Azure environment, the measured performance evidence, the Section 508 approach, and the top technical risks with their mitigations.
Architecture: prototype today → production in CDC-managed Azure
The prototype is deliberately built the way the production front end would be built: a static, configuration-driven rendering layer with no framework runtime and no external requests. In production, that same front end is delivered from CDC-managed Azure, and the intake, workflow, storage, and transmission concerns move to managed platform services behind it.
- Demonstrated today: the entire browser layer — configuration-driven rendering, branching logic, dual-audience wording, autosave/resume, validation, the low-code console with version history, and the VAERS-compatible structured output (a contract-first stub for the production transmission path).
- Production phase: the CDC-managed Azure services — Front Door/App Service delivery, Functions for server-side validation and intake, Logic Apps for workflow and notifications, Blob Storage for two-phase upload staging, Data Factory for structured transmission into existing VAERS infrastructure, and Key Vault for secrets under managed identity. All are platform services already operable within a CDC Azure enclave — no bespoke infrastructure to authorize.
- Why this split de-risks the build: the layer with the most product risk (comprehension, branching, accessibility, configurability) is the layer the prototype already proves; the production-phase layer is composed of managed services with well-understood security and operations profiles.
Performance evidence
- ~150 KB total transfer for the full prototype — HTML, CSS, JavaScript, and the entire form configuration
- 0 external requests — no CDN, no fonts, no analytics, no framework runtime
- ≤ 3 s PWS load requirement — met with wide margin on low-bandwidth mobile connections
The margin is structural, not incidental. A static-first front end has no server render time and no framework boot cost, so first load is dominated purely by transfer size — and ~150 KB arrives in well under a second on a typical mobile connection. Because rendering is configuration-driven, the payload also stays flat at scale: adding questions, branching rules, or entire form versions grows the configuration by kilobytes, not the application by megabytes, and content changes ship without redeploying code. Static assets are trivially cacheable at the Front Door edge, so surge events (a new vaccine campaign, a media-driven reporting spike) scale on CDN economics rather than server capacity.
Accessibility (Section 508) approach
Practices already implemented and inspectable in this prototype:
- Semantic structure — native landmarks, headings, fieldsets/legends for choice groups, and definition lists on the review screen; no div-and-ARIA reconstruction of native semantics.
- Label association — every control has a programmatically associated
label; help text and error messages are linked via
aria-describedby. - Live announcements — step changes, validation results, and
configuration actions are announced through a polite
aria-liveregion, so screen-reader users hear what changed without losing their place. - Keyboard operability — the entire wizard and admin console operate without a mouse; focus is managed on step changes (moved to the step heading) and onto the first invalid field after failed validation; a skip link and visible 3px focus indicators throughout.
- Contrast and touch targets — the Oxford/Federal palette meets WCAG AA contrast on all text; interactive targets are a minimum of 44px.
- Reduced motion — transitions are disabled under
prefers-reduced-motion.
Production plan: accessibility is verified continuously, not at the end — automated checks in CI on every change, assistive-technology testing (JAWS, NVDA, VoiceOver, and mobile screen readers) each iteration, and a formal Accessibility Conformance Report (ACR/VPAT) with a remediation plan delivered with the Beta release, as the PWS requires.
Risk register
Top six technical risks, with likelihood, impact, and the mitigation built into the approach.
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Integration with existing VAERS ingestion contracts | Medium | High | Early interface-control-document (ICD) validation at kickoff; contract-first development against stubs — exactly as this demo's FHIR-shaped output already stubs the transmission payload — so integration surprises surface in week one, not at delivery. |
| ATO / security-authorization timeline | Medium | High | Compliance-as-code from day one: Security and Privacy package drafting starts at kickoff, evidence is mapped to controls as it is produced, and the architecture leans on CDC-managed Azure platform services with established inheritance rather than bespoke infrastructure. |
| Plain-language comprehension gaps driving incomplete reports | Medium | Medium | Iterative usability testing with consumer participants each build cycle, and a branching design that asks only relevant questions — plus in-form escape hatches ("describe it in your own words") so a reporter is never blocked by vocabulary. |
| PHI/PII handling in file uploads | Medium | High | Two-phase upload: files land in a quarantined staging container, are scanned, and only then promoted. Encryption in transit and at rest via platform services; least-privilege access through managed identities; no PHI in logs. |
| AI suggestion-tool accuracy and bias | Medium | Medium | Human-in-the-loop by design — suggestions assist, never auto-decide; every suggestion is provenance-linked to its source text; accuracy and bias are monitored and reported under the AI Compliance & Risk Management Plan. |
| Schedule compression on a 9-month period of performance | High | Medium | The config-driven architecture removes the slowest class of change from the critical path — content, wording, and branching evolve without deployments — and the iterative build cadence the PWS prescribes delivers working software every cycle, so schedule risk is visible early instead of discovered late. |
Scalability and extensibility
One schema already serves two audiences: every question carries plain-language and clinical wording plus per-mode visibility, and the same engine renders the public wizard, the provider wizard, the admin preview, and the review screen. That is the extensibility mechanism, demonstrated rather than promised:
- New questions and branching rules — authored in the configuration console (try it: add a question), rendered immediately, no code change, every change snapshotted and reversible.
- New form versions — the schema is versioned
(
schemaVersion); a revised VAERS form is a new configuration, deployable alongside the old one, with submissions stamped by the version that produced them. - New vaccine types — a row in an options list, not a development task; the repeatable vaccine section and per-symptom follow-ups already handle variable cardinality generically.
- Future reporting programs — nothing in the engine is vaccine-specific. The same section/field/rule/mode model can drive an adjacent public-health intake (drug adverse events, exposure registries, outbreak intake forms) by writing a new configuration against the same rendering and validation engine.
See it working: public report wizard · provider wizard · low-code configuration console · back to start