Secure a patient portal and the electronic health record (EHR) behind it by treating the portal as the internet-facing edge of the record: strong identity, authorization on every record, audited access, encrypted exchange, and tight control of connected apps and vendors. HIPAA safeguards set the baseline and HHS 405(d) practices give a practical list.
Why is the portal a different risk from the EHR?
The EHR sits inside the organization. The portal faces patients and their phones, so it must handle password resets, family access, proxy access and mobile apps, all from networks you do not control. Behind it sit interfaces to labs, billing, scheduling and, increasingly, apps that patients connect themselves.
That chain is only as strong as its weakest link. A flaw in the portal's record lookup exposes the EHR behind it. A flaw in a connected billing vendor exposes data the portal sent it.
What does HIPAA ask for?
The HIPAA Security Rule protects electronic protected health information through administrative, physical and technical safeguards, and it begins with a risk analysis of where that information lives and what could go wrong. It is technology neutral: it states goals such as access control, audit controls, integrity and transmission security, and leaves the choice of tools to you. Read the current regulation text on HHS's site or eCFR to confirm your exact obligations.
For practical guidance, the HHS 405(d) Program, a collaboration between the Health Sector Coordinating Council and the federal government, publishes Health Industry Cybersecurity Practices (HICP) to help healthcare organizations reduce the most relevant cyber threats.
What about the APIs that move records?
Many EHRs expose data through HL7 FHIR APIs. The FHIR specification is clear that FHIR is not a security protocol and defines no security functionality of its own. It says all production data exchange should use TLS, users and clients must be authenticated, with OAuth recommended and the SMART App Launch guide where appropriate, and that implementers are responsible for meeting regulations such as HIPAA and GDPR. It also says to validate all input and to test against injection and invalid input.
So the standard points you to the same fundamentals: transport encryption, strong authentication, scoped authorization, input validation and audit.
What goes wrong, and what is the fix?
A constructed example: a clinic's portal lets patients download visit summaries at an address ending in a record number. A patient changes the number by one and sees someone else's summary. The portal checked that the user was logged in, but not that the record belonged to them.
Typical gaps and fixes:
- Missing object authorization. Check on the server that the record belongs to the requester or an authorized proxy, every time. Test with two accounts.
- Weak account recovery. Reset flows that rely on easily found facts. Use verified channels and multi-factor authentication.
- Proxy and family access. Time limit and log delegated access, and let patients see who accessed their record.
- Third-party apps. Patients connect apps through APIs. Limit scopes, review app registrations, and revoke unused tokens.
- Vendors. List every business associate that receives data from the portal, and confirm agreements and access controls.
- Staff access. Snooping by employees. Alert on unusual record access and review audit logs.
- Logs. Keep audit events for portal and EHR access, and make sure patients' data is not in debug output.
How to check or apply this
- Run and document a risk analysis that includes the portal, APIs and vendors.
- Test every portal endpoint that takes a record ID with two accounts.
- Require multi-factor authentication for patients where possible, and for all staff and admin access.
- Use TLS everywhere and short lived tokens with narrow scopes for API clients.
- Maintain an inventory of connected apps and business associates, with an owner each.
- Review audit logs routinely and rehearse a response plan for a record exposure.
Quick check
Is a portal covered by HIPAA?
If a covered entity or business associate runs it and it handles electronic protected health information, yes. Check with your compliance counsel for your specific case.
Does using FHIR make data exchange secure?
No. The FHIR specification states it is not a security protocol. Security comes from TLS, authentication, authorization and the controls you build around it.
Sources
- HL7 FHIR Security
- HHS 405(d) Program, Health Industry Cybersecurity Practices
- HHS, HIPAA Security Rule
Last reviewed: 18 October 2026.
