Building a HIPAA-Compliant Patient Portal People Will Actually Use Two-factor login is a great idea right up until a 70-year-old patient gives up halfway through and calls the front desk instead. That’s the tension at the heart of part five of our Clinic Scheduling & Recovery series. Every security feature you add is one more thing standing between a patient and the “reschedule” button. Add too few and you’re exposing patient data. Add too many and nobody uses the portal, which means the phones keep ringing and the whole point of the dashboard disappears. So the interesting question isn’t whether we can make it HIPAA compliant. We can. The real question is how much friction patients will put up with before they quit. What does HIPAA actually require from a patient portal? The baseline isn’t up for debate. The HIPAA Security Rule’s technical safeguards, set out in 45 CFR 164.312, require access controls so that only the right people see the right records, and audit controls that log who looked at or changed what, and when. They require integrity protections so records can’t be altered or destroyed improperly, authentication that proves the person logging in is who they say they are, and transmission security that protects data while it’s moving across a network. On top of all that, every vendor that touches patient data, including hosting, email, SMS and backups, needs a signed Business Associate Agreement. That part is paperwork rather than code, and it’s the part small clinics most often get wrong. What are we trying to find out? Our question is what the minimum set of HIPAA safeguards for a small-clinic patient dashboard looks like, and how each one affects whether patients can finish common tasks like rescheduling or checking an appointment. To get there, we’ll map every safeguard to a real feature in our SvelteKit and Postgres stack, with no hand-waving. We’ll measure completion rates and time taken for three everyday tasks: viewing the next visit, rescheduling and cancelling. We’ll compare different login methods, and we’ll document which vendors need BAAs and which of ours already offer one. Which login method is easiest for patients? We’re comparing three approaches. A password plus an SMS code is familiar, but it gives patients two things to get right, and SMS codes are a known weak spot. A magic link sent by email means there’s no password to forget, though it depends on the patient being able to get into their email quickly. Passkeys, which use a fingerprint or face unlock, offer strong security with no password at all, but they’re also the option most patients have never heard of. Our guess is that magic links will win on completion for older patients and passkeys will win for younger ones. But we’d much rather watch real people try it than trust our guess. How are we testing it? We’ll start by writing a safeguard checklist straight from the Security Rule and mapping every item on it to code, configuration or a vendor contract. Then we’ll run a small usability test with eight to twelve people across a range of ages, asking them to complete the three tasks while we watch and say nothing. The silence is the hard part, but you learn the most when you don’t help. In the live demo, we’ll log every point where people drop off, from starting and finishing a login to starting and finishing a task. Once a pilot clinic is live, we’ll A/B test the login methods on real traffic. And we’ll ask someone outside the team to try to break it, probing session handling, patient IDs in URLs that could be swapped to reveal someone else’s record, and error messages that leak too much. Security is part of what we do at ELRQ, and we still don’t trust ourselves to test our own work. What data does this need? The demo logs authentication events, recording which login method was used, whether it succeeded or failed and how long it took, and never the passwords themselves. It keeps an audit log of every record viewed or changed, which HIPAA requires and which is genuinely useful to us as well. It records task events with timestamps, so we can see exactly where people give up, and it notes the device type and a broad age band, because phone versus desktop and younger versus older both change the picture. Alongside all of that, we keep a vendor list with the BAA status of each one, tracking the paperwork side as carefully as the code. Why does this help clinics buy? Most office managers can’t explain HIPAA, but they’re scared of it, and that fear is reasonable. A one-page sheet that shows exactly how we comply, safeguard by safeguard and backed by this research, does a kind of reassuring that no sales call can. It turns “trust us” into “here’s the list.” Previously, we covered what to say after someone cancels. Next, we look at what a WhatsApp or email message is legally allowed to say. If you’re interested in the security side more broadly, our post on website security is a good place to start.