Patient Portal Development: What It Actually Takes

Sixty-five percent of US patients accessed their online medical records or a patient portal in 2024, more than double the share who did a decade earlier, according to a July 2025 data brief from the Office of the National Coordinator for Health IT.

Growth like that makes patient portal development one of the higher-leverage projects a healthcare organization can fund this year. It only pays off if the finished product clears three bars most teams underestimate: compliance, usability and integration.

Miss any one of them and you end up with a portal patients were offered but never actually use.

What patient portal development actually requires now

The compliance bar is about to move. In January 2025, HHS proposed the first major rewrite of the HIPAA Security Rule in two decades. Faegre Drinker's analysis of the proposal lays out what would stop being optional.

• Encryption for all patient data, both stored and in transit, with no addressable exception.
• Multifactor authentication for anyone accessing systems that hold electronic health information.
• A written inventory of technology assets and a network map showing how patient data actually flows.
• Vulnerability scans every six months and penetration testing annually.

That list is still a proposal, not law. The comment period closed on March 7, 2025, and HIPAA Journal reported that OCR received 4,745 comments and hasn't set a date for a final rule.

Building against that proposed baseline now costs far less than retrofitting a live portal once it lands.

Why usability decides who actually uses it

A portal that passes a compliance audit can still fail its patients. One mixed-methods study of a dental hospital's web portal, published in the Journal of Medical Internet Research in August 2025, tested 17 patients on core tasks.

Every one of them could log in, though 82% needed help doing it. Fewer than one in five could send the clinic a secure message without any assistance.

The gap wasn't random. Adults under 65 scored 68.8 on the standard usability scale, well above the 59.1 that patients 65 and older managed on the same test.

The portal was also English-only, shutting out the 18.7% of surveyed patients who preferred another language. None of that shows up on a HIPAA checklist.

It shows up in adoption numbers six months after launch, which is exactly the kind of gap our UI/UX work is built to close before it costs a health system real engagement.

The API layer that makes a portal worth building

Photo by StartupStockPhotos on Pixabay

Portals also live or die on what they connect to.

As of February 2026, roughly 9 in 10 US hospitals give patients API-based access to their health information, and 7 in 10 use standards-based APIs such as HL7 FHIR to do it, according to ONC's most recent hospital IT data brief.

That's a real increase in standards adoption from prior years. Hospitals still lean on proprietary interfaces for a lot of routine data sharing, though.

A portal that only mirrors a single EHR's screens is already behind. One built on FHIR can pull lab results, medications and appointment data the way patients now expect, and hand that same data to the apps patients increasingly use instead of the web portal itself.

We've built that integration work into projects like our accessibility rebuild for OptimalMD, and it's the same groundwork behind most EHR software development that has to satisfy a compliance officer and an actual patient at once.

None of these three pieces is optional, and none of them is a one-time task. The safeguards will get stricter, the patients logging in are getting older on average, and the data they expect to see keeps expanding.

Plan for that from the first sprint, whether that means custom apps and SaaS work or an overhaul of what's already live, rather than treating compliance and usability as fixes for after launch.

Cover photo by ovariancancer1 on Pixabay