Patient portals, the surface the clinical team can sign off, the one patients can actually use.
A patient portal lives at the intersection of clinical workflow, accessibility regulation, and consumer expectations. We build them so the patient can do what they came for (book an appointment, see results, message a clinician) and the clinical reviewer can defend what gets shown (consent-scoped, audited, accessible).
What we build
Records from the EHR, mapped to a clean model
FHIR reads against the EHR get normalized at the boundary. The portal shows results, conditions, and medications from a typed internal model the patient surface never has to translate. Vendor differences stay in the integration layer.
WCAG 2.2 AA, not WCAG 'we'll get to it'
Contrast, focus order, keyboard paths, screen-reader semantics, motion preferences, built in from the start. Per-component a11y notes in Storybook; CI fails on axe-core regressions.
Consent at every read, audited at every action
Each portal session carries a consent token. State-changing actions (booking, messaging, prescription refill request) write an audit row the clinical team can review. Patients can see their own audit history.
Messaging that the clinical staff can triage
Patient messages route to a typed work queue with priority, category, and SLA tracking. Acknowledgements happen on a clinical clock, not at message-receive time. Closed-loop confirmations land back in the patient inbox.
Identity proofing scaled to the risk
Low-risk reads (appointment list) clear with standard auth. Higher-risk (lab results, prescription history) layer identity proofing, government ID match against the EHR record, step-up MFA on the action.
Translations that match the patient population
Locale-routed UI from day one. Medical terminology gets translated against an approved glossary, not Google Translate. The portal serves the patient in the language they consented in.
Where this fits
You're building patient-facing software and the next clinical review is in three weeks.
Your existing portal lives in the EHR's iframe and the experience is shaped by what that vendor allows, not what your patients need.
You're entering a market where the local accessibility regulator is stricter than your current implementation.
Tech stack
- TypeScript
- Next.js
- FHIR R4
- WCAG 2.2
- Postgres
Want this for your team?
30 minutes with a founder or senior engineer. We'll scope what you need and tell you straight whether Stacklane fits.
Book a Free CallRelated capabilities