Sharing with a clinician
Export, summary and hand-off surfaces produce something a clinician can read in ninety seconds without the product implying it has done any interpreting.
When to use
Use this pattern when the reader wants to take what the product knows about them to a person who has ten minutes and clinical training.
There are two audiences on this surface and they are in tension. The reader wants to feel that their tracking mattered. The clinician wants the smallest number of facts that change a decision, in a form they can scan on paper or on a phone in a corridor. The pattern resolves it by making the export answer to the clinician and the screen the reader sees before exporting answer to the reader.
Signals:
- The reader has an appointment and has been logging.
- A clinic has asked for readings between visits.
- Someone is being referred and their history has to travel with them.
When not to use
- Continuous clinical monitoring. A feed a clinician is expected to watch is a regulated surface with alerting obligations, and this design system says plainly it is not built for that. See Is opsinjs right for this project? and Regulatory context.
- Sharing with a family member or carer. The audience is different, the vocabulary is different, and the consent decision is different. Design it separately.
- Raw data portability. A machine-readable export for the reader's own use is a different artefact from a clinical summary. Offer both, and do not conflate them.
- You want the consent mechanics. Granting, scoping and revoking access is Consent and permissions.
How it works
flowchart TD
A["Reader chooses to share"] --> B["Pick a window and the metrics to include"]
B --> C["Preview: exactly what the clinician will see"]
C --> D{"Route?"}
D -->|"in person"| E["Printable summary, one page, no colour dependence"]
D -->|"send"| F["Consent: recipient, scope, duration"]
F --> G["Delivery, with a record of what was sent and when"]
E --> H["Revocation and history remain visible to the reader"]
G --> HNOT IMPLEMENTED. This component does not exist in any released version of opsinjs. There is no package to install, no module to import and no props interface to generate code against. Everything on this page is a specification of intended behaviour and may change without notice. Do not write code against it.
This component is not built yet
PlannedRoadmapWhat “planned” means
- Preview is mandatory and literal. The reader sees the artefact, not a description of it. Sharing health data without seeing what you shared is a privacy failure regardless of what the summary contains.
- One page, and the first third is the answer. Identity, window, the measures included, and the summary sentence. Anything a clinician has to scroll for is at risk of not existing.
- Numbers over narrative. The export states values, ranges, dates and completeness. It does not say "your blood pressure has been concerning". The product's status vocabulary is designed for a layperson and is not a clinical assessment; carrying it into a clinical context invites it to be read as one.
- Completeness is declared. "42 of a possible 60 mornings, none between 12 and 19 August." A clinician's first question about self-reported data is how much of it there is, and a summary that does not answer it will be discounted entirely.
- Provenance travels. Which device, which method, self-entered or measured. A cuff reading and a wrist estimate are not interchangeable, and only the export knows which is which. See Data provenance and device accuracy.
- Print is a first-class target. Real clinics print. The summary must be legible in black and white on A4 with no interactive affordances; see Print and export.
States
| State | Behaviour |
|---|---|
| Nothing to share | Say what would be needed, rather than producing an empty document |
| Partial window | Included and rendered with its gaps declared, never gap-filled |
| Contains stale values | Marked per value, with the same rules as Offline and stale data |
| Sent | A record the reader can see: what, to whom, when, and until when |
| Expired | Access lapses visibly; the reader is told, not silently unlinked |
| Revoked | Immediate, with an explicit statement of what the recipient may already hold |
Content
The summary is written for the clinician; the surrounding screen is written for the reader. Do not let either voice bleed into the other.
Do
Export header: "Home blood pressure, 3 May to 2 June 2026. 42 morning readings of a possible 60. Self-measured, upper-arm cuff, model recorded per reading."
Don’t
Export header: "Ellie's health journey 🌱. A summary of your amazing progress!" Written for the wrong reader, and it will be discarded.
Do
On the reader's screen: "This is what Dr Ellis will see. You can change the dates or remove a metric before sending."
Don’t
"Share your data" with a single confirm button and no preview.
Every export carries the scope statement from Safety, scope and limitations. The document will outlive the app it came from, and it must say what it is.
Accessibility
- The export is a document, not a screenshot. Real text, a real heading structure, a real table. An image of a chart cannot be read by anyone using assistive technology and cannot be searched by the clinician either.
- Charts carry their table twin into the export, not only into the app.
- No colour dependence anywhere in the artefact. It will be printed in monochrome and photocopied. Verify with Colour independence.
- The preview is navigable, not a modal image. It has headings, landmarks and a reading order that matches the visual order.
- The share control names the recipient in its accessible name: "Send summary to Dr Ellis's clinic", not "Send".
- Print styles are tested, not assumed. Page breaks fall between sections, and link URLs are exposed in print where the text is not self-describing.
Research
Updates to this page
Last read through against the system on 2026-09-20. Due for review every 6 months; expiry is reported by pnpm run check:freshness.
Offline and stale data
What a health screen shows when it cannot vouch for its numbers. It degrades assertions rather than hiding them, and never lets a cached value pass as current.
Form design
How many questions per page, when validation fires, and how errors are surfaced. The behaviour of a question, as distinct from the code that wires a form up.