Healthcare & medtech
Software for clinical and care settings, where the constraints are real and I have met them before.
How I approach it
Engineers meeting a clinical dataset for the first time usually need to be walked through what a protocol is, why a consent boundary is not negotiable, and what a research team actually needs from an export. That walkthrough is billable time you would rather not pay for.
Privacy design is an architecture decision, not a policy document. On a recent research pilot the strongest available answer was to keep participant data on the device entirely — which removed hosting cost, data-residency questions, and a deployment dependency along with the risk.
Accessibility works the same way. Retrofitting an interface for screen readers produces a different, worse interface than designing for them from the first screen.
What this covers
- Medical device software and continuous patient monitoring
- Local-first and privacy-by-design architectures for participant data
- Accessibility and WCAG treated as a requirement rather than an audit
- Clinical research tooling, capture workflows, and reporting
What you get
- An architecture that states plainly where participant data lives and where it does not
- Capture and reporting workflows built around the actual protocol
- Exports in the shape the research team needs
- Operator documentation written for clinicians rather than developers
Relevant work
Other services
Need this on a project?
Describe what you are building and where it is stuck. The scoping call costs nothing, and you get a written scope and price before any work starts.