Skip to main content
The Chain Mountain Podcast
Listen Now
Back to Blog

Case Study: Salvaging a HIPAA-Compliant Patient Portal After the Engineering Firm Was Fired

Case Study

A healthcare organization fired its engineering firm mid-build on a custom patient portal. Here's how we salvaged the work, brought in a trusted partner, changed the approach — and still delivered within the original timeframe.

P
Phil Tearne
••6 min read

Most troubled software programs don't end with a dramatic firing. They end the worse way: eighteen months late, twice over budget, with everyone still technically trying.

This one did end with a firing — and that was the moment it started to go right.

The Situation

A multi-site healthcare organization serving a few hundred thousand members had made the right strategic call: a custom-built member portal where members could submit claims, see the status of their appointments, and access their own health information — integrated with the claims system, the scheduling platform, and the medical records system, and secure to the standards healthcare demands: HIPAA, protected health information handling, audit trails.

They hired a reputable external engineering firm to build it. A year in, the program was in genuine trouble:

  • Requirements were stale. The firm was building from a specification written before a single line of code. Nobody had reconciled it against what the claims, scheduling, and records systems actually exposed — or what members actually needed.
  • No one owned the interface. Questions about claims data mappings, appointment feeds, and record access went to whoever answered the email. Answers contradicted each other, and every contradiction surfaced later as a change order.
  • Security was an afterthought. HIPAA requirements lived in an appendix. Nobody had mapped how protected health information would flow through the portal, who could touch it, or how access would be logged and audited.
  • Progress was theater. Status meetings showed green dashboards over a codebase that couldn't demo end-to-end.

The board fired the engineering firm. And then they faced the harder question: what now? The program had already been announced to members. The launch date existed. And the org was left holding a partially built system, a stale requirements document, and no path forward.

They asked us to come in and salvage it.

What We Did

1. We brought in a partner we already trusted

Salvage programs fail for a predictable reason: the replacement engineering firm spends its first three months learning the domain, the systems, and the client — while the clock keeps running. We removed that risk by bringing in an engineering partner we had worked with previously: a firm we knew deeply, whose people we trusted, and where the working relationships were already established. There was no courtship period, no trust-building phase, no discovery tax. From the first week, they were productive — because the partnership itself was pre-built.

That is a structural advantage no procurement process can replicate. You cannot buy shared history in a contract.

2. We changed the approach — requirements as a guide, not a religion

The old requirements document had one remaining virtue: it captured what the organization thought it needed a year earlier. We used it as a guide, then threw the process out.

We gathered fresh requirements the agile way — working sessions with the claims team, scheduling, clinical operations, and the privacy office, building a live backlog in priority order instead of freezing a specification. Members' actual jobs — submit a claim, check an appointment, see my health information — became the spine of the backlog, and everything else had to justify itself against it.

3. We used AI to accelerate every layer of the build

This is where the recovery stopped being a recovery and became an acceleration:

  • Requirements gathering. We used AI to mine the legacy specification, integration documents, and working-session transcripts into structured, deduplicated, prioritized requirements — work that would have consumed weeks of analyst time compressed into days, with the domain experts validating rather than writing.
  • Code. The AI-assisted development workflow let the new engineering partner rebuild on the salvageable components and generate the rest at a pace a traditional team cannot match — including the unglamorous but critical integration layers for claims, scheduling, and records.
  • Quality. AI-generated test suites covered the functional flows and — critically — the security and privacy surface: authentication, session handling, audit logging, and encryption at rest and in transit. Every protected health information flow had automated tests written against the compliance map before features shipped, not after.

4. We rebuilt the compliance foundation in parallel, not at the end

We mapped every flow of protected health information through the portal in the first weeks: what data comes in from each system, what members can see, what is logged, who can audit what. That map became the engineering partner's working contract and the privacy office's sign-off document — designed in from day one rather than retrofitted before an audit.

The Results

  • Delivered within the original timeframe. This is the result that matters most. A program that restarted from a firing — with a new firm, a new approach, and a partially built codebase — still hit the launch date that had been announced to members. The combination of an existing partnership, agile re-gathering, and AI-accelerated build and test didn't just recover lost ground; it never lost more.
  • Passed the HIPAA security review on the first pass — the compliance map and the AI-generated security test suites became the audit trail; no retrofitting, no findings on data handling
  • Change orders all but disappeared — a prioritized live backlog and a shared decision log replaced the contradiction-and-change-order cycle that killed the original program
  • Members adopted it fast — claims submissions through the portal overtook phone submissions within the first quarter, and appointment-status lookups became the most-used feature on day one

Why the Extra Spend Pays for Itself

The honest question a board should ask after a failure like this: we already paid one firm. Why pay consultants on top of a second one?

Because the failure was never an engineering failure. The first firm had competent engineers. What the program never had was an operating system connecting the business, the compliance office, and the engineers — one accountable interface, one live source of truth on requirements and cost, one compliance map everyone built against. We brought that. And we brought the one thing procurement cannot: an engineering partnership with shared history already in place.

The consulting spend across this engagement was a fraction of the engineering contract it rescued. It paid for itself in the launch date held, the audit passed on the first pass, and the rework that never happened. And it left both the client and the engineering partner working in a better way than either started — the agile backlog, the compliance map, and the AI-assisted test discipline outlived the program.

That is the pattern we see across healthcare custom builds: organizations don't fail because they picked the wrong vendor. They fail because nobody owned the system between the vendors. That is the part we do — and it is what turns a program you have to fire into one you can still ship on time.

This case study has been anonymized to protect client confidentiality. Results are representative of actual engagement outcomes.

Explore Topics

#healthcare#patient-portal#hipaa#software-development#engineering-partnership#ai#technology-strategy
P

Written by

Phil Tearne

Partner at Chain Mountain specializing in IT strategy, MSP transitions, and technology cost optimization for mid-market and PE-backed companies.

Connect on LinkedIn

Explore our Technology & AI Strategy practice.