- Organization
- Epic
- Period
- 2012–2013
- Decided by
- Ownership
- Case study
- 1 of 5
Go-live is where the job starts
Epic’s software was live and still failing at the accounts I inherited. I owned what happened after go-live: I traced problems to root cause, re-implemented what the install got wrong, and wrote custom Caché code to close the gaps the base product left. Then I built the escalation path, so regulatory changes and critical bugs stopped arriving as surprises.
With hospital IT teams, clinical analysts, and the PQRS subject-matter group I co-led
Installed and still failing
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 so many open outpatient issues that it might cancel. 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
A warranty period or the real job
- My part
-
Technical Services Engineer
- Led post-install success for eight client organizations and co-led their CMS PQRS reporting.
- Originated a monthly policy-and-IT call for an audience of 100+ organizations.
- Built custom Caché code where the product could not reach, and the hospital-facing curriculum and webinar library.
- The call
- Treated post-install as the real job: root causes, re-implementation, and an explicit escalation path.
- Result
- An account at risk of cancelling became a reference account, and all eight client organizations were still reporting on the federal quality programs when I left.
Go-live is where the job starts · Kanav Jain · kanav.net
I treated post-install as the real job, not a warranty period. I went after the root causes on the issue list, not the symptoms, re-implemented what the install got 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.
What I deployed and wrote
I deployed the MyChart web and mobile portal and EpicCare Link interoperability tools for a research hospital and health system, and wrote custom Caché code for hospital, department, and individual-physician needs the base configuration couldn’t meet.
Two pieces of that code I can still name: a visit-workflow checklist that kept an encounter from closing until its Meaningful Use requirements were complete, 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 2
The accounts and the escalation path
| Organization | What I owned | Result |
|---|---|---|
| 477-bed regional health organization, an outpatient account at cancellation risk | The inherited outpatient issue list: root-cause analysis, re-implementation, and custom Caché code where the base product could not reach | Closed 95% of the issue list; the account became a reference |
| Research hospital and health system, 134 years old | The MyChart web and mobile portal and EpicCare Link interoperability deployment | The health system took its MyChart patient portal and EpicCare Link live |
| 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 |
The PQRS escalation path became the model for handling regulatory updates and critical bugs, and Epic recruited me into internal area leadership four months in on the strength of the customer work.
What I’d keep
Name the trigger, the owner, and the notification before the problem arrives.
The hospital had signed off, the software was live, and it still wasn’t doing the job, because teams had run the period after go-live as a warranty, one symptom at a time. The PQRS escalation path is the first place I wrote the rule down. Transcarent’s case routing and Andwise’s escalation clocks both used it again.
Sources
Show sources and citations Hide sources 2 cited sources
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. CMS folded PQRS into MIPS after 2016, and its old landing page is gone.
Operating and project records
- The clients’ size and age
- The 95% resolution figure and the cancellation risk
- The incentive programs’ reach
- The reach of the curriculum and the monthly call
Client organization names and specific incentive payment totals remain confidential. Roles, escalation workflows, and organizational reach reflect contemporaneous project records.
Next step
Advisory and fractional product leadership for healthcare and AI ventures, and founding partnerships with a co-founder or backer who runs sales and distribution. I take software from initial demo through hospital IT approval, clinical sign-off, and operational deployment.
Revised