Care plan sync between practitioner and patient app: the technical story behind a five-year relationship

Most EMRs treat the patient as a one-way audience. The clinician writes the care plan, prints the summary, hands it to the patient, and the patient — at best — files it in a drawer next to last year's discharge letter. The plan lives in the EMR; the patient's reality lives somewhere else. That gap is where multi-year care plans go to die.

What "sync" means here, precisely

MedMETs's care plan is a structured object — goals, medications, lifestyle commitments, lab cadence, review schedule, escalation thresholds — that lives in our backing store (Postgres on Supabase) with row-level security pinned to the patient and their linked practitioners. When the clinician edits the plan in the practitioner web app, the change is committed, the audit row is written, and a realtime channel pushes the delta to the patient app within ~600 ms. The patient sees the same plan their clinician sees. Same source of truth, same data model, two render surfaces.

The handshake

Linking the patient app to the practitioner side is a six-digit handshake — the clinician generates a code in the practitioner UI; the patient enters it in their app; the sync_request RPC verifies expiry, marks the link active, and grants the practitioner read access to the patient's app-side data. The handshake replaces the brittle email-and-DOB matching pattern that older portals rely on. No PHI passes through the handshake itself; it is a short-lived pairing token, not an identity assertion.

What the patient sees

• Today's care-plan progress — which goals are on track, which are due for action.
• Next review date — visible weeks before the recall fires, not hours.
• Active medications with the rationale from the most recent review.
• Lab cadence — what tests are due, when, and where the patient can have them done.
• Past plan history — every prior version of the plan, every clinician who has touched it, every adjustment with timestamp.

None of this is a printout. All of this is live.

Encryption and trust boundaries

Every care-plan payload is encrypted at rest with AES-256 and in transit with TLS 1.3. The patient owns their own data — they have a one-tap export of the entire care-plan history under data-subject-rights frameworks (HIPAA, GDPR, Privacy Act 1988). When a practitioner-patient link is severed (patient changes clinic, practitioner leaves the practice), the practitioner's read access is revoked within minutes, the audit row records the revocation, and the patient retains their full plan history on their own device.

Continuity across clinician changes

When a patient moves clinics, the incoming practitioner receives a one-tap handshake that — with patient consent — brings the full care-plan history into the new clinic. Nothing is re-entered. The receiving clinician sees the prior reviews, the medication trajectory, the goal-completion history, and the AI scribe's prior consult summaries (if the patient grants that scope). A new patient is not a new chart; it is a continuation.

What happens over a five-year horizon

Over a five-year care-plan relationship the data accretes — annual review snapshots, medication titrations, lifestyle goal progressions, hospitalisations, deteriorations, recoveries. The longitudinal view is searchable, plottable, and AI-summarisable. When the clinician sees the patient in year five, the system can surface "this is the third time we've revisited the metformin → empagliflozin question; previously declined twice for GI-side-effect concerns" — context that would take ten minutes of chart review to reconstruct manually.

Why this matters more than the AI scribe alone

Ambient AI scribes are a documentation efficiency play — they save 90 seconds per consult and free clinical attention in the moment. Care plan sync is a continuity play — it keeps the patient inside the plan over years, which is where the outcome moves. The right product roadmap is both: the scribe makes the encounter better, and the care plan makes the relationship better. Either alone is a half-product.