1 MyChart and EpicCare Link
MyChart is Epic's patient portal; EpicCare Link is its portal for referring and affiliated providers.
Product context for two of the implementations described here.
Case study
What happens 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.
Timeframe
2012–2013
Overview
The decision
Context 2
Installation is where most vendors declare victory. It is where the actual 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 the regulatory programs the incentives depended on — PQRS above all — changed on Washington's schedule, not the deployment's, and there was no defined path for getting a regulatory change or a critical bug in front of the right person.
The Decision
Treat post-install as the real job rather than the warranty period. Work the issue list to root cause instead of triaging symptoms, re-implement what was configured wrong, and write custom code where the base product genuinely didn't reach. Then make the escalation path explicit — from issue discovery and triage through customer notification — so the next regulatory change had a route instead of a scramble.
Resolved 95% of the outpatient issue list at the at-risk account through root-cause analysis, re-implementation, and custom plug-in development, converting it from cancellation risk to reference account. Deployed the MyChart web and mobile portal and EpicCare Link interoperability tools for a 514-bed research hospital and health system — taking a 134-year-old organization online for the first time. Delivered plug-ins in Caché to satisfy hospital, department, and individual physician needs the base configuration couldn't meet. Co-led CMS PQRS and created its escalation path for regulatory issues and software bugs.
Outcome
Eight client organizations kept on federal incentive programs worth millions of dollars in payments. The at-risk account became a reference. The 134-year-old health system went online. 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.
Sources
2 What PQRS was
PQRS was a CMS quality-reporting program tied to federal incentive payments for eligible professionals.
CMS's own fact sheet, dated inside the period described here: PQRS “has been using incentive payments … to encourage eligible health care professionals (EPs) to report on specific quality measures.” The program landing page this used to cite has since 404'd — PQRS was folded into MIPS after 2016.
Client organizations are described by size and age rather than named, so those figures cannot be checked from here — along with the 95% issue-list figure and the cancellation-risk framing, they come from my own record of the engagements. The PQRS co-lead, the escalation path, the 100+ organization monthly call, and the four-month move into area leadership are corroborated by documents written at the time and by a commendation from the client side.
End-to-end flow
1 Software installed and signed off → 2 Issue list accumulates against real department workflows → 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
Implementation
Constraints
- Federal quality-reporting deadlines moved on Washington's schedule, not the deployment's.
- The base configuration didn't reach every hospital, department, and physician need — some gaps could only be closed in code.
- An account already at cancellation risk had no patience left for another round of symptom triage.
What was shipped
- Root-cause analysis and re-implementation across an inherited outpatient issue list.
- Custom Caché plug-ins for needs the base product left unmet.
- A PQRS escalation path with defined discovery, triage, and customer-notification steps.
- Curriculum and video webinars so hospitals could satisfy quality-measurement requirements without a support call.
Outcomes
- 95% of the outpatient issue list resolved at the at-risk account.
- Eight client organizations earning federal incentive payments.
Deliverables
- PQRS escalation path — issue discovery to customer notification Drawn below. The route existed so that a regulatory change or a critical bug reached a named owner instead of circulating until someone adopted it.
- Caché plug-ins deployed at client sites Two 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. The first came out of reading Gawande's Checklist Manifesto.
- Hospital-facing curriculum and webinar library Used by 100+ hospitals to satisfy federal quality-measurement requirements without opening a support case.
Artifacts
Why it matters
This is where the rest of the work starts. The software was installed, signed off, and live — and still not doing the job, because nobody owned what happened after the go-live. Every system I have built since assumes deployment is the beginning of the obligation rather than the end of it, and the escalation path I wrote for PQRS is the direct ancestor of the escalation matrix in the AI governance work: define the trigger, the owner, and the notification before the situation arrives.