Case study 1 of 5 · Decided by ownership

After the software is installed

Epic’s software was installed and still failing at the accounts I inherited. Owning what happened after go-live meant root-cause analysis, re-implementation, and writing Caché plug-ins to close the gaps the base product left — then building the escalation path so regulatory changes and critical bugs stopped arriving as surprises.

Public MyChart app screenshot
MyChart, one of the two products I deployed for the 514-bed research hospital.

Go-live is where a vendor’s project usually ends and the customer’s problems start: workflows that don’t match how the department works, quality measures that won’t report, and federal incentive money riding on both.

One 477-bed regional health organization had accumulated an outpatient issue list long enough that the account was a cancellation risk. Meanwhile PQRS and the other incentive programs changed on Washington’s schedule, not the hospital’s. There was no defined path for getting a regulatory change or a critical bug in front of the right person. 2 CMS, “Physician Quality Reporting System (PQRS) Overview” (Aug 2013)

I treated post-install as the real job, not a warranty period. I worked the issue list to root cause instead of triaging symptoms, re-implemented what was configured wrong, and wrote custom code where the base product didn’t reach. Then I wrote down the escalation path, from issue discovery and triage through customer notification, so the next regulatory change had a route instead of a scramble.

The accounts, and what came of each
Org profileWhat I ownedResult
477-bed regional health organization, an outpatient account at cancellation risk The inherited outpatient issue list: root-cause analysis, re-implementation, and Caché plug-ins where the base product could not reach 95% of the issue list resolved; the account became a reference
514-bed research hospital and health system, 134 years old The MyChart web and mobile portal and EpicCare Link interoperability deployment The health system went online
Eight client organizations — two outpatient software, six patient web-portal Post-install success, and co-lead for CMS PQRS reporting across them All eight still reporting on the federal incentive programs when I left
100+ organizations The hospital-facing curriculum and webinar library, and a monthly policy-and-IT call One standing channel for regulatory change, instead of a support case per organization

I deployed the MyChart web and mobile portal and EpicCare Link interoperability tools for a 514-bed research hospital and health system, and wrote Caché plug-ins for hospital, department and individual-physician needs the base configuration couldn’t meet.

Two of the plug-ins I can still name: a checklist built into the visit workflow that gated Meaningful Use completion before an encounter could close, and automatic immunization scheduling driven by CDC recommendations. I had just read Atul Gawande’s The Checklist Manifesto, on how surgical teams cut errors by making the steps explicit, and built the first one straight out of it. 1 Epic Systems 2 CMS, “Physician Quality Reporting System (PQRS) Overview” (Aug 2013)

1 Software installed and signed off → 2 Issue list grows as departments hit the software in daily work → 3 Root-cause analysis instead of symptom triage → 4 Re-implementation, or a Caché plug-in where the base product can’t reach → 5 Escalation path routes regulatory changes and critical bugs to a named owner → 6 Quality measures report; incentive payments land

The PQRS escalation path became the model for handling regulatory updates and critical bugs, and I was recruited into internal area leadership four months in on the strength of the customer work.

Regulatory change Critical bug × a defined route Circulates no defined route Whoever happened to notice if anyone did
Before the escalation path, at Epic in 2013. A regulatory change and a critical bug entered the same way — by circulating until somebody happened to own them. Nothing here is broken in a way a status report would show: every step has someone touching it and no step has anyone accountable for it. The diagram below is the same two triggers after the route existed.
CMS changes the program a critical bug surfaces Discovery and triage Scope who is affected Named owner not a queue Customer notification before the deadline, not after
The PQRS escalation path, drawn from the route I built at Epic in 2013. It existed to remove the step where a regulatory change or a critical bug circulated until somebody happened to pick it up: every trigger enters one route and ends with a named person who has to notify the customer. Every escalation design on this site descends from it.

Deployment is the start of the obligation, not the end of it. Name the trigger, the owner, and the notification before the problem arrives.

The software was installed, signed off, and live, and still not doing the job, because nobody owned the period after go-live. The PQRS escalation path is the first place I wrote the rule down. Transcarent’s case routing and Andwise’s escalation clocks both use it again.

1 MyChart and EpicCare Link

MyChart is Epic’s patient portal; EpicCare Link is its portal for referring and affiliated providers.

Epic’s own description of the two products.

2 What PQRS was

PQRS was a CMS quality-reporting program tied to federal incentive payments for eligible professionals.

A CMS fact sheet from 2013 says PQRS used incentive payments to encourage eligible professionals to report specific quality measures. PQRS was folded into MIPS after 2016, and its old landing page is gone.

I haven’t named the client organizations, so their size and age, the 95% figure, the cancellation risk, and the incentive programs come from my own records, as do the reach of the curriculum and the monthly call. I don’t have a dollar figure for the incentive payments. Documents from the time back the PQRS role, the escalation path, the 100+ organization call, and the move into leadership.

Revised