1. Understanding of the problem and objectives
Two very different people file VAERS reports: a parent describing what they saw at home, and a clinician transcribing a chart. Today they meet the same form, so one group is asked questions it cannot answer and the other is slowed down by questions it finds imprecise. The reporting burden shows up as abandoned reports and as narratives that reviewers have to chase.
The objective this prototype takes as primary is therefore not cosmetic. It is to ask each reporter only what applies to them, in words they already use, and to collect the supporting evidence while they are still in the flow rather than through a second tool afterwards.
2. Soundness and feasibility of the technical approach
The form is a declarative definition — 44 fields with JSON-serialisable visibility and requiredness conditions — evaluated by one pure function. That function runs unchanged in the browser for live field visibility and on the server for submission validation, so the two cannot drift apart. The server re-runs every rule and every validator; nothing about correctness depends on the client.
The stack is deliberately ordinary: a React front end, a small API, and a storage layer behind an interface. Everything demonstrated here is achievable inside the period of performance because none of it depends on novel technology — the innovation is in the model, not the machinery.
3. Innovation and originality
The declarative branching engine. Field visibility is data, not code. The provider case named in PWS 1.6.2 — a vaccine administration error with no adverse event — is one condition object reused by all 16 adverse-event fields. Because it is data, the engine can also report on itself: the form shows a live count of how many adverse-event fields it is currently rendering, so the behaviour is demonstrable rather than asserted.
The low-code content layer. Every reader-facing string is addressed by a content key, and the admin editor writes overrides against those keys. A programme owner can rewrite a tooltip that is confusing reporters, or add a new question-and-answer entry, and see it live on the next page load. The same entries are what the assistant answers from, so improving the help content improves the assistant with no retraining and no release.
Requirements that measure themselves. PRS#4 and PRS#5 are measure-and-report objectives, so the prototype ships the measurement rather than a promise of it: page load from the browser’s own timing API, submission time end to end, abandonment from a page-hide beacon, and completeness counted against only the elements the branching engine actually asked for — so a correctly suppressed branch is never scored as a data-quality failure. Both satisfaction instruments (2 of them, required by PWS 1.5 and 1.7) capture real responses and report them in the same place.
Suggestions that explain themselves. The document suggestion engine — 14 rules in the same condition grammar as field visibility — returns the reason each suggestion fired, not just a list. That is what makes it reviewable by a programme owner rather than opaque.
4. Technical risks and mitigation
- No real VAERS integration
- The transmission channel is real code with a real envelope, checksum and acknowledgement, but the channel it ships with acknowledges locally and reaches no network. Mitigation: transmission sits behind a channel interface, and the mapping layer already produces per-element provenance — so integration is a second channel implementation plus a conformance suite against CDC's element definitions, not a redesign of the intake model.
- Hosting is not the eventual environment
- PWS 3.2 requires deployment inside the CDC-managed, FedRAMP-authorised Azure environment under an ATD. This demonstration runs on ordinary commercial hosting. Mitigation: nothing here depends on the host — a single Node process, a storage layer behind an interface, no platform-specific services — so the move is an environment and authorisation exercise. The storage interface is the seam that becomes Azure SQL Managed Instance or Blob Storage.
- Accessibility is self-assessed, not certified
- The prototype is built to WCAG 2.1 AA and publishes a conformance summary with its known nonconformities, but no assistive-technology testing has been performed and no ACR/VPAT is issued. Mitigation: the gaps are named rather than omitted, accessibility criteria sit in the definition of done, and the AT matrix runs in the beta cycle before the ACR is issued.
- Performance is measured at demonstration scale, not load
- The measurement apparatus PRS#4 asks for exists and reports real numbers, but a handful of evaluator sessions is not a load test. Mitigation: the rules engine is pure and synchronous with no per-field network calls, which is the property that makes the interaction budget achievable; the same instrumentation feeds the monthly report once production volumes exist.
- The abandonment target has no baseline yet
- PWS 1.10 asks for a 30% reduction against a baseline established at project kickoff, which does not exist. Mitigation: the prototype reports against a declared assumption and says so everywhere the number appears, and the assumption is a single constant that CDC's measured baseline replaces.
- The assist layer could become an AI compliance liability
- Mitigation taken now rather than later: the shipped assistant is deterministic, and any model-backed provider must implement the same interface and is contractually limited to the question, the persona, the step and the visible field ids. No answer values, no uploads, no identifiers.
5. Alignment with performance requirements
Every objective in the PWS performance matrix has a row below, including the ones a prototype cannot meet. Eight are demonstrated in the running application, two are measured and reported by instrumentation built for the purpose, four are partial with the missing half named, and four are contract deliverables addressed in other tabs.
| PRS | Objective | Status | Evidence in this prototype |
|---|---|---|---|
| PRS#1 | Branching logic correctness (Task 1.6) | Demonstrated | Provider vaccine-error-with-no-AE suppresses all adverse-event fields; the live panel counts them and the server drops any that are posted anyway. Covered by automated tests. |
| PRS#2 | Mobile and desktop responsiveness (Task 1.3) | Demonstrated | One responsive layout throughout, verified at 375×812 and 1280×800 with no horizontal scrolling of the page body. |
| PRS#3 | Landing page and navigation redesign (Task 1.4) | Demonstrated | Landing page and primary navigation reach the form, the questions page, data downloads, the post-submission upload tool and the guides. CSV and JSON downloads work with filters applied. |
| PRS#4 | Application performance, measure-and-report (Task 1.10) | Measured | Page load is sampled from the browser's Navigation Timing API, submission time is measured end to end, and abandonment is recorded from a page-hide beacon. Reported in the admin Performance tab against the 3-second and 10-minute targets. The abandonment baseline is an assumption until CDC establishes one at kickoff. |
| PRS#5 | Data completeness ≥ 90% of critical elements (Tasks 1.1, 1.6, 1.9) | Measured | Measured per report and aggregated, counting only the elements the branching engine actually asked for. Shown on the confirmation screen and in the admin Performance tab. The critical element set is the prototype's reading of the current VAERS form; CDC supplies the authoritative list at kickoff. |
| PRS#6 | VAERS-compatible capture and transmission (Task 1.9) | Partial | Capture is complete: VAERSDATA, VAERSVAX and VAERSSYMPTOMS with per-element provenance. Transmission runs through a channel interface that builds a checksummed envelope and returns an acknowledgement — but the shipped channel acknowledges locally and reaches no network. Production adds a second channel behind the same interface. |
| PRS#7 | Customer satisfaction surveys (Tasks 1.5, 1.7) | Demonstrated | Both instruments are built, capturing and reporting: the site-navigation survey from the footer of every page, and the post-submission pop-up presented on the confirmation screen. Results aggregate in the admin Satisfaction surveys tab. |
| PRS#8 | Program-personnel editability / low-code UI (Task 1.8) | Demonstrated | Every reader-facing string — including the survey questions — is editable by content key with no deploy. Saves are revisioned, attributed and individually revertible, with an audit trail. The change and configuration process is documented in the guides. |
| PRS#9 | Medical record upload capability (Tasks 2.1, 2.2, 2.5) | Demonstrated | Upload inside the form, a free-text box, and the post-submission upload tool preserved alongside it as Task 2.1 requires. No file contents are transmitted or stored anywhere. |
| PRS#10 | Supplemental document suggestion tool (Task 2.3) | Demonstrated | Rules in the same condition grammar as field visibility, each returning the reason it fired. All three defined scenarios produce suggestions, above the 90% coverage AQL. |
| PRS#11 | Two-phase upload, Phase 1 with Phase 2 provisions (Task 2.4) | Demonstrated | Phase 1 restrictions enforced in the browser and re-enforced on the server. Images are rejected with a message naming the Phase 2 seam. Phase 2 is one flag on one class. |
| PRS#12 | ATD issuance support (Task 3.3) | Contract deliverable | A security and privacy documentation package for CDC and OCIO. A contract deliverable, not something a prototype can produce. |
| PRS#13 | PHI/PII protection and security safeguards (Tasks 3.1, 3.4) | Partial | The prototype holds no real data by construction: synthetic answers only, and file names, sizes and types without contents. Content changes are audit-logged and session tokens are signed and expiring. Formal safeguards documentation and vulnerability scanning belong to the contract. |
| PRS#14 | Section 508 conformance (Task 3.5) | Partial | Built to WCAG 2.1 AA with a published conformance summary, known nonconformities and a remediation plan. Assistive-technology testing and the formal ACR/VPAT are contract deliverables and are named as not evaluated. |
| PRS#15 | Compliance documentation package (Task 3.6) | Contract deliverable | Delivered with beta per the Section 8 schedule. |
| PRS#16 | User and administrator documentation (Tasks 1.12, 3.8) | Partial | Public, provider and administrator guides ship inside the application so they cannot drift from the screens they describe. The three separate formal guides plus O&M and architecture documentation are contract deliverables. |
| PRS#17 | Program management and reporting (Subsection C) | Contract deliverable | PMP, monthly reports and bi-weekly reviews. Addressed in Tab 2-1 and Tab 3-1. |
| PRS#18 | Transition-out readiness (Tasks 4.1–4.9) | Contract deliverable | Addressed in Tab 3-1. |
The measurements behind PRS#4 and PRS#5 are not decoration: they are produced by the running application and reported in the content admin alongside the results of both satisfaction instruments. A performance report that nobody can open is not a report.
6. Scalability and extensibility
Two seams are already visible in the code. The upload classifier sorts files into classes and consults a per-class Phase 1 flag; enabling Phase 2 image upload flips one flag and adds the image pipeline behind it, with no change to any caller. And the suggestion engine returns a ranked list from a rules provider today; a learned ranking layer replaces the provider without altering the contract the interface consumes.
The config-driven field model is the broader answer. New data elements, new personas and new conditional logic are definition changes, which is what makes a form of this kind maintainable by the programme rather than only by its original developers.