HealthTech · Approach
care that connects,records that stay private
Patient portals, video visits, and care messaging where every record view is logged and every login means something. Designed around privacy first, then convenience.
Illustration: a patient portal showing an upcoming video visit, a secure message thread where the care team replies, and an access log recording who viewed or changed the record.
01 · The hard part
What makes health software hard
The features look like any other app. The difference is what happens to the data around them.
Health data spread across tools
Scheduling, messaging, and billing each keep their own copy of patient details, and each is a place to leak.
Access nobody can explain later
Without a log of who opened which record, a simple question from compliance becomes an investigation.
Visits that fail on bad connections
A video visit that drops or a message that never arrives is a missed appointment, not a bug report.
Records stuck in the EHR
Clinical data lives in systems that only speak HL7 or FHIR, and the new app has to meet them there.
02 · The approach
How I would build it
Each solution points at the closest work I have shipped, so you can see the pattern running before it is applied to care.
Patient portals behind real sign-in
Customers of a regulated service signing in to see what they owe and pay it is the same shape as a patient portal: identity first, then records.
- Cognito sign-in with MFA
- Per-record access checks
- Appointment and balance views
- Payments through the processor
- Automated staff notifications
- Serverless on AWS
Video visits and care messaging
Audio and video calling, alerts, and scheduling between residents and staff, applied to patients and care teams.
- Audio and video calling
- Scheduling and reminders
- Push notifications
- Care-team messaging
- Alert routing by role
- Serverless backend
Protected data at rest
Column-level encryption, secrets in a vault, and a gateway in front of every API, as on the regulated financial platform.
- Always Encrypted columns
- Key Vault or KMS for keys
- API gateway policies
- Encryption in transit everywhere
- Cloud services covered by a BAA
- Access logging
EHR integration over FHIR
Not shipped yet. The approach: an integration layer that talks FHIR to the EHR (directly or through an integration vendor), normalizes records, and keeps the app's own store to the minimum it needs.
- FHIR resources in and out
- Integration vendor or direct API
- Normalized patient records
- Minimum necessary data kept
03 · Stack
The tools behind the work
Tools from the related work above, plus the standards a healthcare build has to speak.
Identity
- Cognito
- Azure AD
- JWT
Data
- PostgreSQL
- Azure SQL
- DynamoDB
- Key Vault
Messaging
- Firebase
- SNS
- SES
- Socket.IO
Integration targets
- HL7
- FHIR
04 · Privacy & security
Privacy is the architecture
The safeguards a health build starts with, before the first screen is designed.
Encrypt health data everywhere
At rest with managed keys, in transit with TLS, and sensitive columns encrypted so the database cannot read them.
Only BAA-covered cloud services
Health data only touches cloud services the provider covers under a business associate agreement.
Every record view logged
Who opened which record, when, and from where, kept where the app cannot edit it.
MFA and least privilege
Staff roles see only what their job needs, and sign-in requires a second factor.
Minimum necessary data
The app keeps only what it needs and reads the rest from the source system on demand.
Secrets in a vault
Keys and credentials live in Key Vault or KMS, rotated without a redeploy.
Engineering practices, not a compliance determination. Whether and how HIPAA applies depends on your role as a covered entity or business associate; your compliance team and counsel make that call.
Planning a health product?
Tell me who uses it and what data it touches. I will come back with how I would structure access and storage before any screen gets built, and be clear about which parts would be new for me.