Abdullah
CadenceDay 1 (Mon): Kick off DoseSpot AND Stripe in parallel — both are heavy and both are carried end-to-end across the entire week (they are the week-long spines). On Day 1 specifically: request DoseSpot/SureScripts sandbox access and start the enrollment paperwork with Imad, and stand up the Stripe foundation (Connect onboarding + payment-method capture). Midweek (Wed onward): begin the main home-page AI chat assistant (ABD-2), the pre-visit AI recording re-architecture (ABD-4), the send-pre-visit-on-demand work (ABD-5), and the related intake work — while Stripe and DoseSpot continue running in the background all week. Schedule the 1:1 with Ansar (ABD-6) for later in the week once telehealth/in-person/chart-notes are testable. End of week: Stripe is end-to-end and DoseSpot has real, documented progress.
ABD-1
Kick off DoseSpot (e-prescribing) integration & enrollment paperwork
P0
Begin the DoseSpot e-prescribing integration so providers can eventually prescribe medications directly from Zcribe. DoseSpot connects to pharmacies through the SureScripts network. This week is about starting the integration properly and making real, visible progress — not finishing it.
NowNo e-prescribing integration exists yet, and the DoseSpot/SureScripts enrollment and credentialing paperwork has not been started.
Should do
- Formally start the DoseSpot integration: request DoseSpot sandbox / developer access.
- Co-fill the SureScripts enrollment and credentialing paperwork together with Imad.
- Produce a short written integration plan: which DoseSpot endpoints we use, how auth works, what data we send and receive, and where it plugs into the patient chart.
- Consolidate open questions and review them with Ansar so the work never gets blocked.
Definition of Done
- DoseSpot sandbox / developer access requested or obtained.
- DoseSpot + SureScripts enrollment paperwork started and tracked with Imad, with outstanding items noted.
- A short written integration plan exists (endpoints, auth, data in/out, chart insertion point).
- Open questions consolidated and reviewed with Ansar.
Confirmed: vendor = DoseSpot (e-prescribing), connecting through the SureScripts network. Enrollment paperwork is co-filled with Imad. Consult Ansar whenever a question comes up — do not get blocked. This is one of the two week-long spines (the other is Stripe, ABD-3) and starts on Day 1, running through the whole week.
ABD-2
Main AI chat assistant on the home page — make it work, reliable, and pleasant to use (read-only)
P0
This is the primary AI chat assistant that lives on the HOME PAGE — the main assistant a user talks to. The goal this week is to make it genuinely work: give it read-only data tools, make it reliable, and clearly improve the experience around it. It stays strictly read-only for now (it answers and summarizes, it does not take any actions or change any data).
NowThe main home-page chat assistant is not functional right now — it does not reliably respond, it has no real connection to patient data, and the experience around it is rough.
Should do
- Work reliably as the main assistant on the home page — it responds consistently every time, with no dead chats or silent failures.
- Use a small set of read-only tools to look up real patient data (for example: allergies, current medications, last visit, upcoming appointments) and answer questions grounded in that data.
- Return meaningful, accurate summaries with no hallucinated or made-up fields — only what the data actually contains.
- Improve the user experience around the chat: clear input and send, visible loading/typing state, readable responses, graceful handling when there is no answer or an error occurs.
- Stay strictly read-only this version — no write actions, no changes to any record.
Definition of Done
- The assistant is reachable and front-and-center on the home page and responds reliably in the UI.
- It has a small set of read-only tools that fetch real patient data.
- Answers are correct and grounded in real data — no hallucinated fields.
- The chat UX is clearly improved: input/send, loading state, readable answers, and sensible empty/error states.
- Read-only confirmed by reviewing the assistant's registered tool list — every tool is a read/query operation; no mutation or action tool is wired in.
- Deployed and testable on the current environment.
Read-only only — action-taking is explicitly out of scope this version. Per the cadence, this work begins midweek (after the Day-1 Stripe + DoseSpot kickoff).
ABD-3
Finish the Stripe billing integration, end-to-end
P0
Build robust, complete billing on Stripe so money can move correctly across the microsite, the patient portal, and the EHR. We are not building our own billing portal — we link out to Stripe (the same pattern Zit360/Z360 already uses) so Stripe owns payments and invoices.
NowStripe is not finished or connected end-to-end. There is no payment-method capture in intake, no pay-at-booking, no subscriptions, no clinic Stripe onboarding, and no billing visibility in the EHR or the patient portal.
Should do
- Payment method in intake: add a default 'Collect Payment Method' step in the intake packet (alongside the ID-upload and insurance blocks) so the clinic can securely collect the patient's card.
- Pay at booking: based on appointment-type configuration, patients can pay for the appointment while booking it.
- Subscriptions: patients can see subscription options on the microsite and patient portal and subscribe; clinics can charge per appointment type and create subscriptions.
- Clinic Stripe onboarding: a clear guide and method for a clinic to connect their own Stripe account (Stripe Connect style).
- Patient portal billing: a logged-in patient sees their Stripe-linked billing and can update their card and view invoices — handled through Stripe, not a custom portal.
- EHR billing view: staff can see all charges, the card on file, charge the card directly, run manual charges, and receive all invoices — all billing activity is visible.
- Notifications: fire notifications when a payment is collected, a card fails, or a payment fails.
Definition of Done
- 'Collect Payment Method' available as a default intake-packet block.
- Pay-at-booking works per appointment-type config.
- Subscriptions visible and subscribable on microsite + patient portal.
- Clinic can connect its own Stripe account; onboarding guide written.
- Patient portal links to Stripe for card update + invoices.
- EHR shows charges, card on file, manual charge, direct charge, and invoices.
- Payment-collected / card-failed / payment-failed notifications fire.
- End-to-end test passes: collect card → charge → invoice → notification, across all three surfaces.
Confirmed pattern: link out to Stripe the way Zit360/Z360 does — do not build our own billing portal. Himesh consumes this on the patient portal, where ALL billing/subscription UI now lives (no separate billing-UI workstream). Aatika consumes the intake payment-method block (ATK-12). Align on the data contract early so they are not blocked. This is one of the two week-long spines (the other is DoseSpot, ABD-1) and starts on Day 1, running end-to-end through the whole week.
ABD-4
Fix pre-visit AI recording & re-architect it for reliability
P0
The pre-visit AI recording needs to actually be captured and viewable, and the encounter needs to start reliably every time. This is a re-architecture, not a patch.
NowOn the current deployment the pre-visit AI recording is not available — after the encounter finishes, the recording cannot be seen. The encounter also could not be started properly.
Should do
- Reliably capture the recording during the pre-visit AI session.
- Make the recording viewable from the chart/encounter area after the encounter completes.
- Make the encounter start cleanly every time, without errors.
- Correct the underlying architecture so this is dependable, not flaky, and document it so the fix is durable.
Definition of Done
- Recording is reliably captured during the pre-visit AI session.
- Recording is viewable after the encounter completes.
- Encounter can be started without errors.
- Architecture/notes documented so the fix is durable (not a patch).
Related to the 'couldn't start the visit / video didn't appear' scheduling bug Aatika owns (ATK-14) — coordinate on the shared root cause. Per the cadence, this begins midweek alongside the chat agent and intake work.
ABD-5
Send the pre-visit AI check-in on demand
P1
Give staff the ability to send/generate the pre-visit AI check-in on demand — exactly the way we already send intake paperwork.
NowThere is no on-demand way to send or generate the pre-visit AI check-in.
Should do
- From the same kind of UX we use for sending intake paperwork, staff can generate and send the pre-visit AI check-in link to a patient on demand.
- The patient receives a working link and can complete the check-in.
- Works both for an already-scheduled appointment and ad-hoc.
Definition of Done
- 'Send pre-visit AI check-in' action available on demand (mirrors the intake-paperwork send flow).
- Patient receives a working link and can complete the check-in.
- Works for an already-scheduled appointment and ad-hoc.
Aatika's scheduling UI should surface this option (cross-ref ATK-13/ATK-17). Per the cadence, this begins midweek with the other pre-visit/intake work.
ABD-6
1:1 with Ansar to review telehealth, in-person & chart-note generation
P1
Schedule a working session with Ansar later in the week so he can test telehealth + in-person appointments and chart-note generation end-to-end and give live feedback.
NowAnsar has not yet had a hands-on review of the current telehealth, in-person, and chart-note generation flows.
Should do
- Schedule and hold the 1:1 with Ansar during the sprint.
- Walk Ansar through testing telehealth + in-person appointments and chart-note generation end-to-end.
- Capture his feedback as concrete follow-up tickets.
Definition of Done
- Meeting scheduled and held during the sprint.
- Ansar tests telehealth + in-person + chart-note generation end-to-end.
- Feedback captured as follow-up tickets.
Hold this later in the week, once telehealth/in-person/chart-notes are testable (after the Day-1 spines are underway and the midweek fixes have landed).
Himesh
Cadence(1) Patient portal first — get it stable and make the core flows (check-in + AI intake, start/join telehealth, the full self-service journey, billing/subscriptions on the portal, inbox wiring) solid and reliable. Then (2) push the UI quality with Claude design across the portal. Then (3) build out the per-org microsite. Run the dedicated portal + microsite bug-bash (HIM-13) alongside, hardening each surface as it stabilizes, so everything is demoable by Friday.
HIM-1
Patient portal: check-in + AI intake from the portal
P0
Patients should be able to check in for their appointment and complete the AI intake (the AI interview) right inside the patient portal.
NowThere is no way for a patient to check in or do the AI intake from the portal.
Should do
- From the patient portal, a patient can check in for their upcoming appointment.
- The patient can complete the AI intake / AI interview (the pre-visit step that happens before the appointment) inside the portal.
- Completion is reflected back to staff in the EHR.
Definition of Done
- Check in is available in the portal for the relevant appointment.
- AI intake / interview can be completed end-to-end in the portal.
- Completion status is reflected back to staff/EHR.
Check-in and AI interview are the same pre-visit step. Coordinate with Abdullah (pre-visit AI, ABD-4/ABD-5) and Aatika (scheduling).
HIM-2
Patient portal: start/join the encounter (telehealth only)
P0
Patients need a clear, correct way to start or join their visit from the portal, but only for telehealth appointments.
NowIn the appointment space there is no correct option to start the encounter.
Should do
- For telehealth appointment types, the patient sees a working Start / Join control and can enter the visit.
- In-person appointments do not show a start-visit option.
- Joining reliably connects the patient into the live visit.
Definition of Done
- Telehealth appointments show a working join control.
- In-person appointments do not show start visit.
- Joining reliably connects the patient to the visit.
Ties to Abdullah's encounter/start-visit fixes (ABD-4) and Aatika's start-visit bug (ATK-14).
HIM-3
Patient portal: full self-service appointment journey
P0
A patient should be able to do everything around their visit inside the portal, end to end.
NowThe journey is fragmented; patients cannot smoothly go from booking to paperwork to check-in to joining.
Should do
- From the portal a patient can schedule an appointment.
- Fill out the paperwork.
- Do the check-in + AI interview (pre-visit step).
- Join the appointment, all in one seamless, convenient flow with no dead ends.
Definition of Done
- Schedule, paperwork, check-in/AI interview, and join all work from the portal.
- The flow feels continuous (no dead-ends, clear next steps).
- Tested end-to-end as a patient.
This is the spine of the patient experience. Depends on HIM-1 and HIM-2 working first.
HIM-4
Patient portal: fix the collapsed view (visibility & alignment)
P1
The collapsed view of the portal UI has layout problems.
NowThe collapsed view is not fully visible and not aligned.
Should do
- The collapsed view renders completely with nothing clipped or hidden.
- Elements are properly aligned at all sizes.
Definition of Done
- Collapsed view shows all content (nothing clipped/hidden).
- Elements are aligned correctly.
- Verified across mobile and desktop widths.
Part of overall portal stability.
HIM-5
Patient portal: add a feedback feature
P1
Patients need a way to share or leave feedback from the portal.
NowThe portal currently has no feedback functionality.
Should do
- Patients can leave feedback from the portal.
- Feedback is captured and made visible to the clinic.
- A confirmation is shown to the patient after submitting.
Definition of Done
- Leave feedback entry point in the portal.
- Submission is stored and visible to staff.
- Confirmation shown to the patient.
The same feedback flow also appears on the microsite (HIM-7).
HIM-6
Patient portal: billing & subscriptions live on the portal (with Abdullah's Stripe)
P1
There is no separate billing-design workstream. The billing UI and all the requested billing/subscription features live on the patient portal itself, powered by Abdullah's Stripe work. The patient sees and manages everything to do with paying the clinic right inside the portal.
NowThe portal has no billing option and no subscription visibility — a patient cannot see clinic subscriptions, update their card, view invoices, or subscribe.
Should do
- Patient sees the clinic's available subscriptions in the portal and can subscribe to them.
- Patient can use the billing option (Stripe-linked) to update their card on file.
- Patient can view their invoices (handled through Stripe, not a custom billing portal).
- All of this is built into the patient portal as part of the portal scope, not as a standalone billing-design deliverable.
Definition of Done
- Available clinic subscriptions are shown in the portal and the subscribe flow works.
- Billing option links to Stripe for card update and invoices.
- Card update and invoice viewing both work end-to-end from the portal.
- Folded into the patient-portal surface (not a separate billing UI workstream).
Depends on Abdullah's Stripe end-to-end work (ABD-3). Agree the data contract with Abdullah early so the portal isn't blocked. Pattern follows Z360: link out to Stripe rather than building our own billing portal.
HIM-7
Build the provider microsite (per organization)
P0
Each organization gets a public microsite that markets the clinic and feeds patients into our product.
NowThe microsite is not built out.
Should do
- A per-org microsite with a landing page, team page, and provider pages.
- A subscriptions section (from Stripe).
- An appointment booking flow.
- A referral flow / link (from the referral system).
- A feedback flow.
- A patient-portal login entry point.
Definition of Done
- Landing page live per org.
- Team page + provider pages.
- Subscriptions section (ties to ABD-3).
- Appointment booking flow.
- Referral flow / link (ties to Aatika's ATK-23).
- Feedback flow.
- Patient portal login entry point.
This is the patient's first impression — push hard on design quality (HIM-8). Subscriptions tie to Abdullah's Stripe (ABD-3); referral link ties to Aatika's referral system (ATK-23). Built after the portal is stable per the cadence.
HIM-8
Microsite + portal: UI/UX enhancement with Claude design
P0
Iterate the look and feel of the microsite and patient portal until they feel premium and effortless, using Claude design (the design-based tooling used for UI work).
NowThe UI/UX is not yet where it needs to be for a patient-facing product.
Should do
- Using Claude design, meaningfully improve the front-end design and user experience of the microsite and portal.
- Make the flows seamless, functional, and consistent with the brand (black/white + #7822CF purple).
- Use ShadCN components only — no custom UI elements.
Definition of Done
- Visible, reviewed UI improvement across portal + microsite.
- Consistent ShadCN components and brand palette.
- Flows feel seamless (validated by walking through them).
Per the cadence, the Claude-design UI pass on the portal comes after portal stability and core flows are solid, and feeds the microsite build.
HIM-9
Patient portal: connect to the inbox & make it stable
P1
Wire the portal to the inbox correctly and make the whole portal stable and smooth.
NowThe portal-to-inbox connection is not right, and the portal needs hardening.
Should do
- Portal communications connect correctly to the inbox.
- The portal is stable and smooth throughout, with no broken states in the core flows.
Definition of Done
- Portal-to-inbox is wired and verified.
- Portal is stable (no broken states in the core flows).
Part of the portal-stability-first phase of the cadence.
HIM-10
Guides portal: fix responsiveness (empty sidebar on resize)
P2
The guides portal does not resize properly.
NowWhen the screen is widened, it adds empty space on the sidebar instead of using the space well.
Should do
- The guides portal is responsive across widths.
- It uses available width correctly with no dead empty sidebar space.
Definition of Done
- Guides portal responsive across widths.
- No empty/misused sidebar space on resize.
Himesh built the guides feature, so this is his to fix.
HIM-11
Guides: make them visible in Settings
P2
Guides should appear in the Settings area.
NowIn Settings, only Changelog shows — Guides do not appear at all.
Should do
- Guides are listed and accessible in the Settings area alongside Changelog.
- Guides open and render correctly from Settings.
Definition of Done
- Guides visible in Settings alongside Changelog.
- Guides open and render correctly.
Pairs with HIM-10 (guides responsiveness).
HIM-12
Coordinate with Aatika & team on additional feedback
P2
Stay in sync with Aatika and the rest of the team to absorb any extra feedback that affects the portal or microsite.
NowNew feedback that touches the patient surfaces can get lost if there's no regular sync.
Should do
- Hold regular check-ins with Aatika and the team.
- Capture any new feedback that affects the portal/microsite as tickets.
Definition of Done
- Regular check-ins held.
- New feedback captured as tickets.
Microsite referral link and subscriptions cross over Aatika's referral system (ATK-23) and Abdullah's Stripe (ABD-3) — keep aligned.
HIM-13
Intensive testing + bug bash across the patient portal AND the microsite
P0
A dedicated QA / bug-bash on Himesh's own surfaces — both the patient portal and the per-org microsite. The goal is to deliberately hunt for, log, and fix bugs so both surfaces are genuinely solid and demoable by Friday, not just 'works on the happy path'.
NowThe portal and microsite have not had a focused, structured QA pass. Bugs are found ad hoc during feature work rather than systematically across all flows and devices.
Should do
- Run a structured test matrix across every patient-portal flow: check-in + AI intake, start/join telehealth, the full self-service journey (book → paperwork → check-in → join), billing/subscriptions, feedback, and inbox.
- Run a structured test matrix across every microsite flow: landing, team, provider pages, subscriptions, booking, referral, feedback, and patient login.
- Test each flow across devices and widths (real phone + desktop, and the collapsed view).
- Log every bug found in a tracked list, fix them, and re-verify the fix.
- Confirm both surfaces are stable and demoable by Friday with no broken states in the core flows.
Definition of Done
- A written test matrix exists covering all portal flows and all microsite flows.
- Each flow tested on a real phone and on desktop, including the collapsed view.
- Every bug found is logged in a tracked list with status.
- All logged bugs are fixed and the fixes re-verified (or explicitly deferred with a reason).
- Both the portal and the microsite are demoable end-to-end with no broken states in the core flows.
- bun run lint && bun run typecheck pass clean on the changes.
This is Himesh's own dedicated QA pass on his two surfaces, separate from Aatika's EHR bug bash. Per the cadence, harden each surface as it stabilizes (portal first, then microsite) so nothing slips to Friday.
Aatika
CadenceDays 1–2 = bug-bash (Bucket 1: intake, chart, scheduling, roles, org defaults, hardening). Days 3–4 = new features (Bucket 2: Faxing V1 + Referrals V1). Throughout the whole week = telehealth go-live support with Imad (Bucket 3) plus carrying the broad patient-chart review/refactor in parallel. Friday = Aatika owns the deployment — all fixes deployed and visibly verifiable in the live UI before end of day.
Bucket 1 · Bug Fixes & Quality
ATK-1
Intake packet ordering is not respected
P0
The order of blocks set in the intake packet builder must be the exact order the patient sees while completing intake.
NowWhen the ID-card and insurance-card upload blocks are moved to sit between forms, the patient intake ignores that order and pushes ID + insurance to the very end.
Should do
- Render every intake block in the exact order configured in the packet builder.
- Honor reordering for all block types, including the ID-upload and insurance-card blocks.
- Place ID/insurance wherever the builder put them, including in the middle of the form sequence.
Definition of Done
- Reordering any block (including ID/insurance) is honored in the patient flow.
- Verified end-to-end with ID/insurance placed in the middle of the forms.
- lint + typecheck clean for the touched files.
Bucket 1 (intake). Quick, high-visibility correctness fix — knock out early in the bug-bash.
ATK-2
Pre-fill (retain) patient data across intake packets
P1
When the same form is reused in a later packet, the patient should not have to retype everything. Basic/demographic info should pre-fill from their previous submission while still being saved as its own separate record.
NowA form reused in a new packet starts completely blank even though the patient already filled it in a prior packet, forcing wasted re-entry.
Should do
- Pre-fill a reused form with the patient's most recent prior answers.
- Let the patient edit, change, or remove any pre-filled value.
- Save the new submission as a new, unique record — never overwrite or delete the prior submission.
Definition of Done
- Reused forms pre-fill from the most recent prior submission.
- Patient can edit the pre-filled values before submitting.
- A new, separate record is created and the prior record is left untouched.
- Confirmed both records exist in the patient's data.
Bucket 1 (intake). Watch the data model so historical submissions stay immutable.
ATK-3
Paperwork UI shows "Demographics" instead of the real packet name
P1
The paperwork UI should label each packet with its actual intake packet name.
NowThe intake packet is always labeled "Demographics" even when that is not what the packet is called.
Should do
- Display the real intake packet name in the paperwork UI.
- Remove the hardcoded "Demographics" label.
Definition of Done
- The correct packet name is shown in the paperwork UI everywhere it appears.
- Verified with multiple packets that have different names.
Bucket 1 (intake). Small label fix — fast win.
ATK-4
Delete an intake packet from a patient account
P1
Staff need a way to remove an intake packet that has been attached to a patient.
NowThere is no option to delete an intake packet from a patient's account.
Should do
- Provide a delete control on a patient's intake packet.
- Reflect the deletion everywhere the packet appears (chart, lists, paperwork views).
- Gate the action behind a confirmation step and the correct permission check.
Definition of Done
- Delete control available on a patient's intake packet.
- Deletion is reflected across chart and lists immediately.
- Confirmation dialog and permission check in place.
Bucket 1 (intake). Ties to roles/permissions (ATK-21) — only allowed roles should delete.
ATK-5
Consent editor: Enter key does not create a new line
P0
When editing a consent form or template, pressing Enter should insert a new line so the text can be spaced and formatted.
NowWhile editing an existing consent packet/form, pressing Enter does nothing — text cannot be broken into new lines or paragraphs. Called out as the single biggest consent issue.
Should do
- Make Enter insert a newline in the consent editor.
- Allow normal spacing and paragraph formatting.
- Persist and re-render the spacing correctly on save and on the generated document.
Definition of Done
- Enter creates a newline in the consent editor.
- Spacing and paragraphs save and render correctly in the UI and in the generated PDF.
- Verified by editing an existing consent template.
Bucket 1 (consent). High priority — flagged as the worst consent pain point.
ATK-6
Signatures and initials must be transparent PNG, not JPEG
P1
Captured signatures and initials should be saved as transparent PNGs so they render cleanly and uniformly everywhere.
NowInitials and signatures are saved as JPEG, so they appear non-uniform and lack transparency (boxy backgrounds).
Should do
- Save signatures and initials as transparent PNG.
- Render them consistently across the UI and in stamped/generated PDFs.
Definition of Done
- Signatures and initials are stored as transparent PNG.
- They render uniformly in the UI and on generated PDFs.
- Verified on a real signed document end-to-end.
Bucket 1 (consent/signing).
ATK-7
Improve the mobile intake experience
P1
Completing intake on a phone needs to be genuinely smooth and fully usable.
NowDoing the intake on a phone was a bad experience — layout, inputs, and flow were awkward on small screens.
Should do
- Make the full intake flow comfortable and usable on mobile.
- Ensure inputs, scrolling, buttons, and layout all behave correctly on small screens.
- Test it by actually logging into the mobile UI and completing intake on a real phone.
Definition of Done
- Intake can be completed comfortably on a real phone.
- Inputs, scrolling, buttons, and layout work on small screens.
- Verified on a real mobile device, not just a resized desktop window.
Bucket 1 (intake). Use the agent-browser/mobile verification before marking done.
ATK-8
Add a "Not applicable / Skip" option for form questions
P1
Many questions won't apply to a given patient. Give them a clean way to mark a field as not applicable instead of leaving it blank or typing filler text.
NowThere is no way to mark a field as not applicable, so patients either leave it empty (ambiguous) or type unnecessary filler.
Should do
- Offer a "Not applicable" (or Nil/Skip) option on applicable field types.
- Let the patient add a real answer if they have one, otherwise mark N/A.
- Record N/A clearly and distinctly from an empty field.
Definition of Done
- "Not applicable" option available on applicable field types.
- N/A is stored and displayed as distinct from empty/unanswered.
- Verified that N/A flows through to the chart correctly.
Bucket 1 (intake). Coordinate with form→chart mapping (ATK-9) so N/A maps cleanly.
ATK-9
Fix form → patient chart mapping errors
P0
Form answers must land in the correct section of the patient chart with no cross-contamination.
NowSome field mappings are incorrect — for example, an allergy value showed up in the chart's Medications section even though the patient never entered it there.
Should do
- Map every form field to the correct chart section.
- Prevent any cross-contamination between medications, allergies, immunizations, history, and other sections.
- Audit the mapping across all intake forms, not just the one where the bug was seen.
Definition of Done
- Mapping audited across all intake forms.
- Allergy / medication / immunization / history and other values land in their correct sections.
- Verified with a real intake → chart walkthrough.
Bucket 1 (chart). Feeds the broader chart review/refactor (ATK-25) — share findings.
ATK-10
Form text fields: Enter should create a new line
P0
In multi-line text inputs (e.g. "list your immunizations"), pressing Enter should add a new line, not jump away.
NowWhile filling a form, pressing Enter jumps focus to the next field instead of adding a newline, so the patient can't list multiple items on separate lines.
Should do
- Make Enter insert a newline in multi-line text fields.
- Keep focus in the field on Enter (no jumping to the next input).
Definition of Done
- Enter inserts a newline in multi-line text inputs.
- Focus does not jump to the next field on Enter.
- Verified on a real multi-line question in the patient flow.
Bucket 1 (intake). Sibling to the consent newline fix (ATK-5).
ATK-11
Providers can manually add/edit/delete clinical data in the chart (currently impossible)
P0
On the patient CHART (the provider-facing chart — the founder informally calls this “the patient portal,” but it is NOT Himesh’s patient-portal surface), a provider must be able to manually manage clinical data: adding data that today cannot be added at all, and editing or deleting existing data. This is core EHR behavior.
NowA provider currently CANNOT manually add clinical data at all. There is no way to add a medication, immunization, allergy, or history item by hand, and there is no way to edit or delete existing chart entries — even after the account is explicitly set to "provider." Suspected to be a role/permission gap (see ATK-21), but the add/edit/delete UI and backend must also genuinely exist and be correct.
Should do
- Let a provider manually ADD a medication, immunization, allergy, and history item directly in the chart — data that currently cannot be entered at all.
- Let a provider EDIT any existing medication, immunization, allergy, and history entry.
- Let a provider DELETE any of those entries.
- Ensure every add/edit/delete writes to the correct chart section and is reflected immediately and accurately (no wrong-section writes, no silent failures).
- Confirm the provider role actually grants these permissions end-to-end.
Definition of Done
- Provider can manually add meds, immunizations, allergies, and history (each previously impossible) and the new entries appear correctly.
- Provider can edit and delete each of those entry types.
- Each action lands in the correct chart section with correct data (cross-checked against ATK-9 mapping).
- Confirmed the provider role grants these permissions by logging in as a real provider (ties to ATK-21).
- Verified live in the UI end-to-end (add → edit → delete for each data type).
Bucket 1 (chart). Strengthened: the headline problem is that manual ADD does not exist at all today. Overlaps with roles/permissions (ATK-21, likely same root cause) and feeds the broad chart review/refactor (ATK-25).
ATK-12
Add "Payment Method" as a 3rd default intake block
P1
Just as the intake packet has default ID-upload and insurance blocks, add a third default block that securely collects the patient's payment method.
NowOnly ID-upload and insurance defaults exist; there is no payment-method block in the intake packet builder.
Should do
- Add a selectable "Payment Method" default block in the intake packet builder.
- When added, securely collect the patient's card via Stripe.
- Sit alongside the ID-upload and insurance blocks and respect packet ordering (ATK-1).
Definition of Done
- "Payment Method" is selectable as a default block in the packet builder.
- Collected card flows into Stripe correctly (ABD-3 contract).
- Verified that the captured card appears as a card on file for the patient.
Bucket 1 (intake). Depends on Abdullah's Stripe work (ABD-3) — align the data contract early so this isn't blocked.
ATK-13
Let staff skip intake / pre-visit at scheduling (no blocking)
P0
When scheduling, the doctor or staff should be able to skip the intake packet and/or the pre-visit AI check-in and start the appointment directly.
NowStaff are effectively blocked — there is no clean way to bypass intake or pre-visit and just start the appointment.
Should do
- Offer skip-intake and skip-pre-visit options at scheduling time.
- Never force staff through a step they chose to skip.
- Let the appointment start directly when steps are skipped.
- Also surface the "send pre-visit AI on demand" option here (cross-ref ABD-5/ATK-17).
Definition of Done
- Skip-intake and skip-pre-visit toggles available at scheduling.
- Skipped steps do not block starting the appointment.
- The on-demand pre-visit send option is reachable from this screen.
- Verified by scheduling and starting an appointment with both steps skipped.
Bucket 1 (scheduling). Connects to ATK-14 (start-visit) and ABD-5/ATK-17 (pre-visit send).
ATK-14
Can't start the visit even after completing prerequisites
P0
After paperwork and the pre-visit check-in are done (or skipped), the visit must actually start and the video must connect.
NowAppointment scheduled, intake paperwork filled, pre-visit AI completed — but the video did not appear and the visit could not be started at all.
Should do
- Start the visit reliably once prerequisites are met or skipped.
- Connect/render the telehealth video every time.
- Remove the dead-end where the start control does nothing.
Definition of Done
- Visit starts reliably after prerequisites are complete or skipped.
- Telehealth video renders and connects.
- Verified end-to-end (schedule → paperwork → pre-visit → start → video).
Bucket 1 (scheduling/encounters). Shares a root cause with Abdullah's pre-visit/encounter fix (ABD-4) and feeds telehealth go-live (ATK-24) — coordinate.
ATK-15
Canceled appointment doesn't show as canceled in the chart
P1
When an appointment is canceled, that status must be reflected in the patient chart's encounter area and everywhere else.
NowAn appointment was canceled, but the patient chart's encounter area still did not show it as canceled.
Should do
- Update the appointment status to "Canceled" everywhere on cancellation, including the chart's encounter list.
- Keep the status consistent across all views.
Definition of Done
- Cancellation status is reflected in the chart/encounter area.
- Status is consistent across calendar, lists, and chart.
- Verified by canceling a real appointment and checking the chart.
Bucket 1 (scheduling/chart). Ties to the cancel action in ATK-16.
ATK-16
Encounters area: automatic + on-demand reminders, plus a cancel option
P1
The encounter actions are too limited today. Reminders should fire automatically and also be triggerable on demand, and staff should be able to cancel from the encounters area.
NowIn the encounters area the only actions are "Start session" and "Send reminder." Reminders are manual-only, and there is no Cancel option in the UI.
Should do
- Send reminders automatically on schedule.
- Keep an on-demand "send reminder" action available too.
- Add a "Cancel appointment" action in the encounters UI.
Definition of Done
- Automatic reminders fire on schedule.
- On-demand "send reminder" still works.
- "Cancel appointment" action present in the encounters UI and updates status everywhere (ties to ATK-15).
- Verified by triggering an automatic reminder, a manual reminder, and a cancellation.
Bucket 1 (scheduling/encounters). Cancellation here must satisfy ATK-15's chart reflection.
ATK-17
Expose "send pre-visit AI on demand" in scheduling
P2
Make sure the scheduling/encounters UI surfaces the on-demand pre-visit AI check-in send.
NowThere is no on-demand pre-visit send option in the scheduling UI, so staff cannot trigger it the way they send intake paperwork.
Should do
- Surface a "send pre-visit AI check-in" action in the scheduling/encounters UI.
- Mirror the existing send-intake-paperwork UX.
- Work for already-scheduled and ad-hoc cases.
Definition of Done
- On-demand pre-visit send is available in the scheduling/encounters UI.
- Triggering it sends a working link the patient can complete.
- Verified live against the backend.
Bucket 1 (scheduling). Backend owned by Abdullah (ABD-5); this is the UI hook. Cross-ref ATK-13.
ATK-18
Security audit + stability refactors
P1
A focused security and stability pass across the product so it is more robust and safe.
NowWe have not done a dedicated security/stability audit; potential issues are unknown and unaddressed.
Should do
- Perform a security audit and document the findings.
- Make the necessary refactors to harden the product.
- Prioritize and fix high-severity issues first.
Definition of Done
- Security audit completed and findings documented.
- High-priority issues fixed/refactored.
- `bun run lint && bun run typecheck && bun run build` all clean.
Bucket 1 (hardening). Feeds the broad chart review/refactor (ATK-25) and the Friday deploy gate (ATK-26).
ATK-19
Real-world insurance test (real NPI + codes + insurance)
P1
Validate the insurance/eligibility/claim path using real data instead of test stubs.
NowThe flow has not been tested with a real provider NPI, real codes, and a real insurance end-to-end.
Should do
- Run the eligibility/claim process end-to-end with a real provider NPI, real codes, and a real insurance.
- Document the outcome and any gaps found.
Definition of Done
- End-to-end test executed with a real NPI + real codes + real insurance.
- Results and any gaps documented for follow-up.
- Any blocking issues raised as tickets.
Bucket 1 (hardening).
ATK-20
Organization defaults on new-org creation
P1
New organizations should come pre-configured so we are not setting everything up by hand each time.
NowA new org starts empty; default intake packets, appointment types, and configs are applied manually.
Should do
- Auto-provision sensible defaults when a new org is created.
- Include default intake packets, default appointment types, and other key configurations.
Definition of Done
- New org auto-provisions default intake packets.
- Default appointment types are created.
- Other key default configs are applied.
- Verified by creating a fresh org from scratch.
Bucket 1 (hardening). The defaults should reflect the corrected intake/packet behaviors from ATK-1..ATK-12.
ATK-21
Roles & permissions review (provider vs support staff)
P1
Define and polish exactly what each role can see and do, and apply it consistently.
NowRole behavior is unclear and in places incorrect — e.g. a "provider" could not edit the chart at all (see ATK-11). Permissions are not reliably enforced.
Should do
- Document a clear permission matrix: what a provider can see/do vs what support staff can see/do.
- Apply the matrix consistently across the app.
- Ensure a provider can perform clinical edits — adding/editing/deleting meds, allergies, immunizations, and history (the root cause behind ATK-11).
Definition of Done
- Permission matrix documented for provider and support staff.
- Provider can do clinical edits (meds/allergies/immunizations/history).
- Each role's access verified by logging in as that role.
- Unauthorized actions are blocked for the wrong role.
Bucket 1 (hardening). Likely the root cause of ATK-11 — fix together. Informs the broad chart review (ATK-25). The provider-add work (ATK-11) should also re-confirm the negative case from here: support staff remain correctly restricted from clinical edits.
ATK-25
Broad patient-chart review & refactor for correctness + stability
P0
Review the entire patient chart module top to bottom and refactor it so it is correct, consistent, and stable — not just patching the individual bugs. This is the umbrella chart-health ticket that the targeted chart fixes feed into.
NowThe chart has accumulated several correctness and stability problems: form data lands in the wrong sections (ATK-9), providers cannot add/edit/delete clinical data at all (ATK-11), cancellations don't reflect (ATK-15), and permissions are inconsistent (ATK-21). These point to underlying structural issues in how the chart reads, writes, and renders clinical data, not isolated one-off bugs.
Should do
- Walk the whole chart module (medications, allergies, immunizations, history, encounters, documents, and how data flows in from intake) and identify correctness and stability gaps.
- Refactor the chart's data read/write paths so every section reads from and writes to the right place, consistently.
- Ensure manual provider entries (ATK-11) and intake-mapped entries (ATK-9) coexist correctly in the same sections without conflict or duplication.
- Make encounter status (including cancellations, ATK-15) render reliably and consistently across all chart views.
- Remove flaky/broken states so the chart is dependable for clinicians.
- Document the refactor so the fixes are durable rather than patches.
Definition of Done
- Full chart module reviewed and a short findings/refactor note written.
- Each chart section reads and writes correct data with no cross-contamination.
- Manual provider data (ATK-11) and intake-mapped data (ATK-9) both display correctly together.
- Encounter/cancellation statuses render consistently across all chart views.
- Chart is stable across the core flows (no broken/empty/duplicated states) — verified live in the UI.
- `bun run lint && bun run typecheck && bun run build` clean for chart changes.
Bucket 1 (chart) — NEW umbrella ticket. Distinct from the mapping fix (ATK-9) and the provider add/edit/delete fix (ATK-11) but cross-references both, plus ATK-15 (cancellations) and ATK-21 (permissions). Carry this in parallel across the week, not just in the first two days.
Bucket 2 · New Features
ATK-22
Faxing via Telnyx (V1) — with a simple dedicated faxing page
P0
Give each clinic a fax number and a simple, clear, dedicated faxing UI where staff can configure faxing, see every incoming fax, and send faxes to allowed recipients. Faxing also feeds the inbox and is the foundation for referrals.
NowNo faxing capability exists at all — no fax number provisioning, no inbound fax handling, no send flow, and no UI to manage faxes.
Should do
- Provision a fax number for each clinic via Telnyx (spelled T-E-L-N-Y-X — the faxing + SMS provider).
- Provide a simple dedicated faxing page with three clear capabilities.
- (a) FAXING SETTINGS: a settings view to configure fax config and the clinic's fax number.
- (b) INCOMING FAXES: a list view showing ALL incoming faxes, viewable in-app.
- (c) SEND FAXES: send faxes to allowed recipients — choose a configured referral clinic (shared with ATK-23) or enter a valid fax number.
- (d) SENT / OUTGOING FAXES: a list of all faxes the clinic has sent (outgoing history) — not just a silent record.
- Surface received faxes in the inbox too, with a filter that shows all faxes.
- Keep the whole experience simple and clear — do not over-build it.
Definition of Done
- Clinic can provision a Telnyx fax number.
- Dedicated faxing page exists with: faxing settings, a list of all incoming faxes, and a send-fax flow.
- Faxing settings let staff view/configure the fax number and config.
- All incoming faxes appear in the list and can be opened/viewed.
- Staff can select a recipient from the configured referral-clinic list OR enter a valid fax number; the send succeeds and the sent fax appears in the sent list — verified end-to-end against a real number.
- Inbound faxes also appear in the inbox with a faxes filter.
- Verified live: receive a fax, view it, and send one out.
- Sent / outgoing faxes appear in a visible list (not only recorded silently).
- `bun run lint && bun run typecheck` pass clean on the faxing changes.
Bucket 2 (new feature). EXPANDED with the UI spec: settings + incoming list + send. Telnyx (T-E-L-N-Y-X) confirmed as the faxing/SMS provider. This is the foundation for the referral system (ATK-23).
ATK-23
Referral management system (V1) — core, stable, two-way with a referral form
P0
A simple, core, stable two-way referral system. The system attaches a referral form; clinics can receive referrals (accept them and convert them into patients), send referrals out, and see correct referral statistics. The goal is a dependable referral system, not a flaky one.
NowNo referral system exists at all.
Should do
- Settings: add and manage referral clinics (doctor name, address, email, fax number, mobile number, etc.).
- Attach/configure a referral FORM that defines what is sent and collected.
- Generate a referral form link (like the intake link) that can be embedded on the microsite; when someone fills it out it arrives as an incoming referral.
- RECEIVE referrals: on receiving a referral form, the user can ACCEPT it.
- After accepting, CONVERT the referral into a PATIENT (and schedule an appointment).
- SEND referrals OUT directly to a referral clinic (e.g. via fax/email).
- Show a referrals view with incoming + outgoing referrals in one place.
- Show referral STATISTICS: counts of incoming, outgoing, accepted, converted-to-patient, and pending/declined referrals, plus a conversion rate.
- Keep the system simple, clear, and stable — correctness over flashiness.
Definition of Done
- Add/manage referral clinics in settings.
- Configure/attach the referral form.
- Generate a referral form link that is embeddable on the microsite (ties to HIM-7).
- Incoming referrals appear in a referrals view; the user can ACCEPT one.
- Accepted referral can be CONVERTED into a patient and an appointment scheduled.
- Send a referral OUT to a referral clinic via fax/email (uses ATK-22).
- Incoming + outgoing referrals visible in one place.
- The referrals screen displays counts for incoming, outgoing, accepted, converted, and pending referrals; each number is verified by creating known test referrals and confirming the counts match.
- Verified end-to-end: receive → accept → convert → patient, and send-out.
- After converting a referral, the new patient record shows the referral’s data in the correct chart fields/sections (cross-checked against ATK-9 / ATK-25) — no missing or misplaced values.
- No broken, empty, or error states across the receive → accept → convert and send-out flows (verified live in the UI).
- `bun run lint && bun run typecheck` pass clean on the referral changes.
Bucket 2 (new feature). EXPANDED with the UI spec: attach form → receive → accept → convert to patient → send out → correct statistics. Builds on faxing (ATK-22) and the microsite (HIM-7). Emphasis on a CORE, STABLE system — design the workflow end-to-end before coding.
Bucket 3 · Telehealth Go-Live
ATK-24
Enable telehealth go-live (with Imad)
P0
Do everything needed to reliably turn telehealth on, working alongside Imad throughout the week.
NowTelehealth is not reliably "go-live" ready — blockers remain and the path to turning it on is not fully de-risked.
Should do
- Create and work through a telehealth go-live checklist.
- Identify and clear every blocker, incorporating Imad's feedback.
- Get telehealth to a state where it can be turned on reliably.
Definition of Done
- Go-live checklist for telehealth created and worked through.
- Blockers resolved with Imad.
- Telehealth can be turned on reliably and is verified end-to-end.
Bucket 3 (go-live) — runs throughout the whole week, not just one block. Pairs with Abdullah's pre-visit/encounter fixes (ABD-4) and the start-visit bug (ATK-14).
Friday Deployment
ATK-26
Aatika owns the Friday deployment — all fixes deployed and verifiable in the UI
P0
Aatika is responsible for the Friday deployment. By end of Friday, every fix and feature in her buckets must be deployed and visibly verifiable in the live UI — not just merged in code. Aatika owns the single Friday deploy of the merged sprint: she smoke-tests her own flows and confirms the cross-owner P0 flows are live with their owners.
NowWithout a single owner for the deploy, fixes risk landing in code but never being visibly live or smoke-tested, so the week's value isn't provably shipped.
Should do
- Own the Friday deployment of the sprint's work end-to-end.
- Make sure the build is clean before deploying.
- Deploy so the changes are live in the real environment.
- Smoke-test each fixed flow live in the UI after deploy to confirm it actually works for a user.
- Confirm with the team that every bucket item is visibly verifiable in the deployed UI.
Definition of Done
- `bun run lint && bun run typecheck && bun run build` all clean before deploy.
- Deployment completed on Friday and the changes are live.
- Each fixed flow is smoke-tested live in the UI: intake ordering / newlines / N-A, consent newline, chart provider add-edit-delete, scheduling skip + start-visit, cancellations + automatic reminders firing on schedule + on-demand reminders, faxing page (settings / incoming / sent / send), and referrals (receive → accept → convert, send-out, stats).
- Any deploy-blocking issue is identified and resolved or clearly flagged before end of day.
- Team confirmation that the sprint's fixes are visibly verifiable in the deployed UI.
- Cross-owner P0 flows confirmed live with their owners: Stripe across portal / microsite / EHR (Abdullah), the home-page AI chat (Abdullah), and the patient portal core flows + microsite (Himesh).
NEW ticket — Aatika owns the Friday deploy. This is the final gate for the whole sprint: code merged is not enough; it must be live and demonstrably working in the UI.