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. I owned what happened after go-live: I traced problems to root cause, re-implemented what was configured 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.
- 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.
- Turned down
- The warranty-period default of triaging symptoms.
- 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.
After the software is installed · Kanav Jain · kanav.net
Context
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
The decision
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.
| Org profile | 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 | 95% of the issue list resolved; 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 |
What happened
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 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.
What I’d keep
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 the period after go-live had been run 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 use it again.
Next step
Advisory and fractional product leadership for healthcare and AI ventures. I partner with technical founders to take complex clinical systems through review, unblock patient adoption, and build products that last.
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. 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 call for 100+ organizations, and the move into leadership.
Revised