Appointment data from WebChart: five work-list asks that are one missing input

Open
#564 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
typescript
Domain
api, backend, data

Research direction

Start with the feedback-call entry in docs/JOURNAL.md and ROADMAP §7.12–7.14, then resolve the MIE questions about FHIR Appointment and Slot access, the authoritative PCP field, and WebChart access. The work is ready to split only after those inputs are confirmed; done means the read-path scope and any separate write-path issue are defined without guessing.

Written by the indexing model from the issue text.

Description

backend blocked-on-mie

Raised at the pilot practice's 2026-09-10 feedback call and never filed; recorded in docs/JOURNAL.md (2026-09-10, the feedback-call entry) and as ROADMAP §7.12 on 2026-09-15.

Five asks, one dependency

Each of these was asked separately, and none of them can be designed without the same missing input:

  1. See a patient's upcoming appointments on their row / profile.
  2. Branch the work list between "prep for a visit already booked" and "reach out to someone with none" — a different action for each, which is the actual workflow the practice runs.
  3. Make "prep" create an encounter, rather than a WorkWell-side task.
  4. Schedule onto the provider's own calendar from the gap.
  5. Add an encounter from a card.

Asks 3–5 additionally need a write path (#7.13 / its own issue); asks 1–2 need only the read.

What is needed from MIE

  • Are appointments reachable over FHIR — Appointment, and what a bookable Slot looks like — or only through a WebChart-specific surface?
  • What is the authoritative PCP field? Patient.generalPractitioner is the obvious candidate and has never been confirmed. This overlaps #556: the live WebChart directory currently attributes every patient to one hardcoded provider, so panels cannot work on live data at all.
  • Developer eSIM / WebChart access, so any of this can be verified rather than guessed (ROADMAP §7.14).

Why it is filed now with nothing built

Two of the five (1 and 2) are pure read-path features that would ship quickly once the data exists, and they are the highest-value part of the practice's work-list feedback. Filing keeps them from being re-discovered a third time. Nothing here is actionable on our side until the questions above are answered — the honest state is blocked, named, rather than absent.

Related: #556 (PCP attribution on live data), ROADMAP §7.12–7.14.

Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
6h 6m
Merged PRs (30d)
69

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Taleef7/workwell

All issues in Taleef7/workwell

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.