Care, With Context

This system helps clinicians. It does not diagnose a patient. Every recommendation must show the facts for it, the facts against it, where those facts came from, and how old they are. If identity or data is uncertain, the screen must say so.

I will keep five things separate: raw facts from each source, the patient identity links, the recommendation, the clinician’s decision, and any follow-up task. That separation lets us fix a wrong patient match without rewriting history.

Field clinicians view recommendations and record what they did. Care coordinators follow up. Identity and data stewards fix uncertain patient matches and stale sources. Clinical-policy owners approve the rules. Version one joins six sources carefully, builds a dated patient timeline, finds care opportunities, explains the supporting and opposing facts, prepares an encrypted offline visit package, syncs the clinician’s action, and creates an approved follow-up task.

For this mock, we support 60,000 visits a day. Packages should be ready 30 minutes before 99 out of 100 visits, and online recommendations should load within two seconds for 95 out of 100 requests. The app works offline for 72 hours. We are not diagnosing, prescribing medication, denying claims, replacing electronic health record systems, or automatically joining uncertain identities.

Sixty thousand visits a day is 0.694 package builds a second on average and about 14 a second at a 20-times peak. Packages create 180 GB a day, roughly 5.4 TB a month before cache copies. At eight visits a day for three offline days, each clinician stores about 72 MB of encrypted protected health information (PHI). That is small enough for a device, but remote key removal and deletion still matter.

If one package needs 400 milliseconds of processor time, the peak needs about 5.6 processor cores. I would start with eight to ten plus spare capacity for each customer and region. The harder problem is combining many data sources and keeping tomorrow’s visits fresh, not raw queries per second. Reusing unchanged evidence files also avoids downloading the same material for a rescheduled visit.

A SourceObservation is write-once and carries source record ID, event/effective time, ingest time, status, and payload digest. A MemberLink maps source person to enterprise member with method, score, evidence, version, and steward state. Uncertain matches remain candidate links and do not join clinical truth. A resolved ClinicalFact preserves contributing observations and both valid-time and system-time.

An OpportunityVersion stores evidence fact IDs, contradictions, source freshness markers, rule/model/calibration version list, severity, expiry, and explanation. A clinician action points to the exact opportunity version and includes offline device sequence plus retry key. A new lab supersedes the opportunity rather than rewriting what the clinician saw.

Connectors capture change-data feed or batch extracts into write-once source zones with contract checks and per-source freshness markers. An identity service creates fixed-rule links from trusted identifiers and a steward queue for ambiguous cases. A timeline builder builds time-aware member facts. On source change or visit schedule, a durable workflow coordinator evaluates with start and end dates rules and calibrated models, then an explanation service assembles supportive, contradictory, and missing evidence.

Thirty minutes before a visit, a package service pins a member-link version, fact freshness marker vector, opportunity versions, policy version list, expiry, and authorization scope. It encrypts and signs the package. The mobile app verifies it, keeps PHI in hardware-backed storage, records actions in an always-increasing local database-backed event queue, and syncs through a retry-safe gateway. Server-side cross-checking revalidates identity, freshness, opportunity state, and user authority before creating downstream tasks.

I use source-specific IDs from each source as write-once anchors, then fixed-rule high-confidence matches such as verified member ID plus date of birth. AI-based and uncertain matches only propose a link with interpretable evidence. High-risk merges require a steward, and one-to-many contradictions block. The member graph is versioned, so a split or merge has reverse data history to every derived fact, opportunity, package, and action.

Freshness is a vector, not one timestamp: each source has event-time freshness marker, ingest time, expected cadence, completeness status, and known lag distribution. An opportunity can require “lab through T, pharmacy through T−1d, claims through T−45d.” Explanations show these limits. Corrections append a reversed/superseding observation and recompute only impacted members using data history. Policy decides whether stale/absent data causes stopping when unsure, lower confidence, or a caution—not a guessed negative.

The package is a write-once read snapshot. Offline writes are commands in a local database-backed event queue with device ID, always-increasing sequence, opportunity version, user, captured time, and retry key. The gateway acknowledges only after durable storage, deduplicates on device sequence, and returns per-command status. Sync may be repeated safely.

We do not last-write-win clinical decisions. The server checks a state machine and authority: notes can merge as separate attributed entries. Duplicate equivalent accepts collapse. Accept versus resolved/cancelled becomes a conflict requiring human cross-checking. The UI shows the newer evidence and asks the clinician to confirm or withdraw. A downstream task uses a business retry key and database-backed event queue. An unknown timeout is cross-checked by key. Package expiry prevents indefinite use, but emergency offline access has explicit scope and audit.

I freeze the disputed link and stop new package generation. A steward creates a split version. Reverse data history enumerates mixed facts, opportunity versions, packages, accesses, clinician actions, and external tasks. We do not erase the original audit. Correct member timelines and opportunities are regenerated under new identities.

Unacted recommendations are revoked. Viewed or acted cases create privacy/safety incidents with minimum-necessary notification and supervisor workflow. External tasks receive correction/cancellation through retry-safe cross-checking. Unknown outcomes stay open. We analyze whether matching evidence or threshold caused the merge and add a canary/adversarial pair to the identity golden set. Identity false-merge rate is a hard safety gate, not an average matching score.

Green package construction is not fresh data. A source-silence detector compares event freshness marker and expected cadence. When pharmacy exceeds policy lag, affected opportunities become STALE_SOURCE and high-risk recommendations stop and ask for human review. The package version list exposes the stale freshness marker and the UI cannot hide it.

The contraindication produces a priority revocation message. Connected devices invalidate package/opportunity IDs immediately. Offline devices cannot be reached, so server-side downstream actions are blocked on sync and the app shows a prominent “reconnect required” gate for expired high-risk content. For truly offline care, policy defines a safe fallback such as clinician verification from the source system—not false confidence. On reconnect, new facts arrive before pending commands are cross-checked.

Always reading the newest confirmed value protects identity link publication, opportunity state, authorization, command acceptance, and downstream action intent. Timeline/search read-ready copies are allowed to be briefly stale and labeled with freshness markers. Change-data feed and job delivery are at least once. Unique source-event and stage keys make them retry-safe. Per-source queues isolate stalled connectors. Package generation reserves capacity for next-hour visits and sheds background recomputation first.

Customer and region are mandatory partition keys in databases, queues, caches, indexes, object paths, and telemetry. Service identities are purpose-scoped. PHI uses envelope encryption, short-lived tokens, device attestation, remote key revocation, minimal offline retention, and redacted logs. Monitor connector freshness/completeness, identity candidate/false-merge rates, timeline lag, opportunity yield/override/outcome by slice, package readiness/age, sync backlog/conflicts, downstream unknowns, access anomalies, and service target burn. Restore write-once events plus version lists into a warm region and cross-check device command high-water marks.

First run identity and freshness dashboards only. Then construct timelines and compare with source experts. Shadow opportunities against historical visits with time-safe replay. Show explanations to a small clinician group without ranking. Canary low-risk opportunity types. Then enable downstream task creation after dual-run cross-checking. Keep a kill switch per rule/model/source slice.

Measure evidence correctness, opportunity precision/recall on adjudicated review, clinician acceptance/dismissal reasons, action completion, time saved, duplicate alerts, subgroup disparity, and—where causal design permits—care outcomes versus matched or randomized controls. Acceptance alone is not health benefit and can reflect alert fatigue. The trade-off is freshness/coverage versus safe stopping when unsure. I expose staleness and miss some suggestions rather than fabricate a complete chart.

I’ll summarize identity, time-aware facts, explainable opportunities, offline command safety, and outcome evaluation.