Engineering Action Plan — Josh
Overview
Scope principle: with business model, naming, and provider structure still open, engineering builds only what is true in every surviving version of the company. Every item below survives a rename, a revenue-model change, a pivot to implant-only or universal wallet, and any outcome of the Qingdao question. Anything that doesn't meet that bar is behind the fence at the bottom.
The Backlog, Sequenced
1. Branding-config sweep — _first, ~half a day to a day_
Strip every hardcoded "CareFirst" / "Care Wallet" string from the codebase into a single branding config: app display name, logo asset path, domain references, email templates, legal footer text. Neutralize repo names and package identifiers while at it. Why first: converts the scariest open decision (the rename) from a migration into a config change. Cheapest insurance available. Done when: a grep for the brand names returns only the config file and historical docs; swapping the config restyles the whole app.
2. Export engine — _the core promise; ~1–2 weeks to v1_
Patient-triggered, full-archive export of a wallet: original DICOM, PDFs of documents, and a structured JSON manifest (implant specs, treatment history, provenance metadata). Delivered as a downloadable encrypted archive and/or expiring secure link. Why: this single feature is (a) the replacement for the "lifetime guarantee" — the promise kept by architecture, (b) the Qingdao Path A mechanism (patient-carried records are an export), and (c) the wind-down commitment. Three strategic jobs, one feature. Done when: a demo patient can produce a complete, human-readable, standards-format archive of their wallet with one action, and a second system (or dentist with a DICOM viewer) can consume it. Watch: archive integrity (checksums in the manifest), no Google-dependent assets in any patient-facing flow (Great Firewall accessibility), export works without an active account session token expiring mid-download.
3. Implant identity dataset — _the quiet moat; ongoing, start ~1 week_
Structured catalog: manufacturer → system → platform/diameter → connection → compatible abutments/screws/drivers, keyed to UDI where possible. Seed by ingesting the FDA's public AccessGUDID data for dental implants, then hand-curate the systems the pilot offices and Qingdao partners actually place (get this list from Jim). Why: "no implant should ever become unidentified" requires this to be data, not a PDF. No competitor discovered so far appears to have it. Compounds with every hour invested; untouched by any open decision. Done when (v1): given a Passport entry for any of the pilot-relevant systems, the app can display the component family and the driver/abutment compatibility a receiving dentist needs.
4. Consent/audit spine hardening — _~1–2 weeks_
Promote the prototype's sharing model to trustworthy: enforced authorization checks on every record access path, immutable append-only audit log, scoped and expiring shares with tested revocation, encryption at rest. Why: this is the HIPAA-readiness substrate the BAAs (a blocking pilot condition) will sit on, and it's the technical substance behind the patient-controlled promise. Compliance infrastructure is never churn. Done when: revocation tests pass (revoked link is dead within seconds), every access appears in the audit log with actor/scope/timestamp, and an access attempt outside scope fails closed.
5. Record-completeness checklist engine — _~3–5 days_
Small rules engine scoring a CareCase against a per-procedure-type completeness checklist (full-arch v1: CBCT ✓, treatment plan ✓, implant specs ✓, prosthetic details ✓, discharge records ✓). Coordinator-facing view showing per-case gaps. Why: powers the concierge workflow in both pilots, makes the "complete records" promise measurable, and is the embryo of the future internal evidence layer — without any of the public-scoring dangers. Done when: every demo case shows a completeness state and the specific missing items.
6. Ongoing: demo polish, viewers, test harness
Synthetic demo environment, DICOM/STL viewing, CI and test coverage. Safe under every open decision; this is what gets shown to pilot offices and any investor.
Hard data rule throughout: synthetic data only. No real PHI enters the system, or any development tool, until BAAs are signed and controls exist. This is already the Agent Academy rule; it binds engineering too.
Dependency Map (what Jim's answers unblock)
| Jim's decision / action | Unblocks | | ------------------------------------------------------- | --------------------------------------------------------- | | List of implant systems used by pilot + Qingdao offices | Dataset curation targets (item 3) | | Signed BAAs with the three offices | First real patient record; anything beyond synthetic data | | Name cleared by counsel | Branding config flip; public marketing site work | | Revenue model decision | Any payments/billing work (currently fenced) | | Ad campaign approval + neutral campaign brand | Landing page build (fenced until brand is settled) |
The Do-Not-Build Fence
Payments and billing of any kind · PMS/scheduling integrations (concierge model needs none) · anything $FIRST · China-side hosting or entities · public Trust Score / provider ratings · further public marketing sites under the contested brand · patient-facing AI agents (BAA-gated) · the 29-step intake as a live patient form.
If a task isn't in the backlog above and touches the fence, the default answer is no — escalate to Jim/Josh jointly before writing code.