Hospital Portal Case Study — HIPAA and Stakeholder Management

Hospital Portal — Why HIPAA Wasn't the Hardest Part

9 min read

We took on a patient portal rebuild for one of America's largest pediatric health systems in 2018. HIPAA compliance, Sitecore integration, 100k+ user migration, legacy data — all real challenges. But three months in, we learned the real project wasn't technical. It was organizational. Fourteen internal stakeholders, each with a different definition of "done."

What We Thought the Project Was

Healthcare IT is regulated. HIPAA specifies encryption, audit logs, access controls, data minimization. Compliance means process, documentation, testing. Complex, but defined. We know how to do it.

The project spec looked straightforward:

  • Rebuild the patient-facing portal (outdated UX)
  • Migrate 100k+ existing users
  • Integrate with legacy hospital systems (Sitecore CMS, patient databases)
  • Maintain HIPAA compliance throughout
  • Phase rollout by hospital region

We scoped it, estimated it, staffed it. 6 months. Senior team. We'd done healthcare before. This was solvable.

We were wrong.

What the Project Actually Was

The first sprint went fine. Technical progress was solid. The portal was coming together. Then we hit a wall — not a technical wall. A human wall.

In our sprint review, we demoed a feature: patients could now update their profile information directly in the portal. Simple, reasonable, aligned with the spec.

The response:

  • Finance: "That's great, but we need to track which fields have been updated so we can audit for billing changes."
  • Clinical: "Patients shouldn't be able to change their medical history, only contact info."
  • Nursing: "Our department needs the ability to verify changes before they go live."
  • Legal: "We need to ensure patient consent is documented."
  • Patient services: "But patients said they want instant updates..."
  • IT Operations: "Who manages the audit logs?"

What we thought was one feature was actually six features, four workflows, and a two-month integration nightmare.

This pattern repeated for every feature. Not because the people were difficult. Because they represented different organizational functions, each with legitimate constraints we didn't know about.

The 14-Stakeholder Problem

We eventually mapped the stakeholder landscape:

  • Clinical: Patient safety requirements, interaction with EMR systems
  • Finance: Billing system integration, audit trails for charges
  • Legal: Compliance, consent documentation, liability
  • IT Operations: Infrastructure, security, uptime SLAs
  • Patient Services: User experience, satisfaction metrics
  • Nursing: Workflow integration, notification requirements
  • Hospital Administration: Timeline and budget pressure

Each had a seat at the table. Each had veto power. Each had a different mental model of what "done" meant.

Clinical wanted rock-solid safety and compliance. Patient Services wanted delightful UX. Finance wanted complete audit trails. Each was right. They were just right about different things.

We couldn't build "the patient portal." We had to build the feature seven times, once for each stakeholder's constraints.

How We Solved It

Three months in, we were behind schedule. Why? Not because development was slow. Because decisions weren't being made.

We called for an alignment workshop. We brought all 14 stakeholders into a room (literally — and virtually for remote ones). We walked through each feature, each decision, and forced explicit trade-offs.

Example: Patient profile updates

The question: Can patients change their own medical information?

Clinical: No. Safety risk. Patients can't be trusted to remember their own medical history accurately.

Patient Services: But patients want to report changes to their condition.

Compromise: Patients can submit changes. But those changes are flagged as "patient-reported" and must be verified by nursing before they're committed to the EMR. Takes one extra click from nursing, solves both problems.

We did that for every feature. Not in meetings. In working sessions with prototypes, actual data, and clear trade-offs.

The result: Clear requirements. Aligned stakeholders. Actual progress.

Lessons We Apply Now

That project taught us three things:

1. Enterprise Projects Are Two Projects

The software project. The organizational alignment project. You can't succeed at one without running the other in parallel. Technical excellence doesn't matter if stakeholders don't agree on what "done" means.

2. Build Stakeholder Alignment Into Discovery

We now run "stakeholder alignment workshops" in week 1 of discovery. Not "let's hear everyone's concerns later." Early. Everyone together. Explicit trade-offs, not implicit resentments.

3. Prototype With Real Data and Real People

Slides don't reveal disagreement. When you show a prototype to nursing, finance, and clinical side-by-side, the disagreements surface immediately. Then you can solve them, not discover them 3 months in.

The hospital portal took 9 months, not 6. Not because we were slow. Because alignment takes time. But now we factor that time in, and projects run on schedule.

Enterprise Healthcare Project? We've Navigated This Before.

We know HIPAA. We know stakeholder complexity. We know how to build alignment before building software.

See how we approach discovery