Why TrakCare Go-Lives Fail (And It's Not What You Think)

When a TrakCare go-live goes wrong, the post-incident review almost always surfaces the same uncomfortable truth: the clinical system worked as configured. What failed was everything around it. The HL7 feeds that no one had documented properly. The cutover window that overran because the rehearsal was done on a Monday morning with partial data. The vendor that said they were ready but had never been asked to prove it. The escalation path that looped endlessly between TrakCare config, the interface engine team, and the consuming system's support desk — at 2am, during the most clinically sensitive hours of the cutover.

These are governance and integration delivery problems. TrakCare gets the blame because it is the new variable. But the conditions for failure were set months earlier, often before the first build sprint started.

The Most Common TrakCare Go-Live Failure Patterns

Interface Debt Carried Forward from the Old PAS

Legacy PAS systems accumulate interface debt silently. HL7 v2 feeds that have been running for ten years are usually "working" in the sense that messages flow and results appear — but almost no one can tell you why they work at the message level. The specifications were never written down. The original interface engine developer left six years ago. The consuming system (LIS, RIS, pharmacy, ward management) has custom parsing logic that was built to handle whatever the old PAS actually sent, not what the HL7 v2 standard says it should have sent.

Common variants that surface at go-live:

• Non-standard segment usage: ZDG, ZPI, or other Z-segments that carried site-specific data the old PAS couldn't fit into standard fields. Consuming systems depend on them. TrakCare doesn't produce them by default.
• Field overloading: PV1-19 (visit number) used as an encounter identifier, OBX-5 carrying concatenated values with an implicit delimiter, MSH-3 containing a value the downstream system uses for routing logic.
• Encoding quirks: character set mismatches, unexpected pipe-within-pipe structures, or carriage-return placement that the old engine handled silently and TrakCare's standards-compliant output breaks.

The gap is not between "working" and "broken." It is between "we know it worked" and "we know why it worked." Without the latter, you cannot specify what TrakCare needs to produce, and you cannot test whether it does.

Cutover Not Rehearsed at Full Scale

UAT environments are not production. This is understood in theory and ignored in practice. The rehearsal happens in UAT with a subset of patient data, during business hours, with the full team available and no clinical operations running in the background. The cutover itself happens against production volumes, at night, with a compressed team, while wards are still operating on paper.

Specific gaps that UAT rehearsals fail to surface:

• Message volume: A site that processes 4,000 ADT messages per day during a busy shift will not replicate that in a UAT environment with seeded records. Interface engine queues, database write speeds, and downstream system ingestion rates all behave differently under load.
• Dependency timing: The lab feed failing at 3am in production is a different problem from the lab feed failing at 10am in UAT. Staffing, escalation availability, and decision authority are all different.
• Rollback path: Rehearsals almost never test the rollback. When a cutover rehearsal runs to completion and the team declares success, nobody then runs the rollback procedure to check that it works. Go-live day is the first time the rollback is real — which is precisely when you do not want to discover it is broken.

A meaningful dress rehearsal requires production-equivalent data volumes, a realistic time window (including overnight), a skeleton team approximating what go-live will actually have, and explicit testing of the rollback path. Programmes that run their first proper rehearsal in the final four weeks rarely have time to act on what they find.

Vendor Integration Agreed, Not Governed

"The vendor has confirmed they're ready" is one of the most dangerous sentences in a go-live readiness report. Confirmation is not verification. In practice, vendor readiness often means:

• A project manager sent an email asking if the vendor was ready.
• The vendor's project manager replied yes.
• The reply was recorded as a RAG status of green.

What was not done: a versioned message specification agreed and signed off by both sides; a formal integration test with production-equivalent message types and volumes; a documented rollback plan for if the vendor's system is unable to process TrakCare messages; named contacts with after-hours availability during the cutover window.

Radiology (RIS/PACS), laboratory (LIS), pharmacy, and theatres systems are the most frequent sources of late-breaking integration problems because they are managed by different vendors with their own priorities, change freezes, and technical constraints. "Ready" to them often means "we haven't broken anything on our end" — which is a different thing from "we have tested with TrakCare's actual output and confirmed end-to-end message processing."

Ownership Gaps Between TrakCare and Downstream Systems

At go-live, an HL7 message that is not arriving correctly at the lab system could be:

• A TrakCare configuration problem (wrong ORM trigger event, missing field mapping, incorrect event type)
• An interface engine problem (routing logic, transformation error, queue processing failure)
• A network or connectivity problem (port, firewall, certificate)
• A consuming system problem (wrong acknowledgement code, parsing failure, database constraint)

Without runbooks, without named ownership per interface, and without a clear triage sequence, diagnosing this under go-live pressure means the team goes in circles. The TrakCare team checks their config, finds nothing wrong, and passes it to the interface engine team. The interface engine team checks their logs, finds messages flowing, and passes it to the LIS team. The LIS team is unavailable because it's 3am and their on-call contact isn't technical. Meanwhile, the clinical operations manager is asking whether to invoke paper-based fallback.

Named clinical and technical accountability per feed is not a governance luxury. It is an operational requirement for managing a go-live safely.

Post-Go-Live Stabilisation Under-Resourced

Go-live is not the end of delivery risk — it is a shift in the type of risk. The first two weeks after go-live are when:

• Edge cases surface that no test scenario covered (specific order types, unusual patient pathways, uncommon message combinations)
• Clinicians adapt their workflows and create new pressure on interfaces that were only tested against expected usage patterns
• Deferred integration issues (things that were flagged as post-go-live cleanup) need to be resolved while the system is live and clinical operations depend on it

The typical programme response is to release senior resource and compress the stabilisation team the moment go-live is declared successful. The people with institutional knowledge of the configuration decisions, the interface specifications, and the test results go back to their next engagements. What remains is a smaller, more junior team facing the most complex period of delivery — exhausted, under-staffed, and without easy access to the people who made the original decisions.

A stabilisation plan that runs for four weeks post go-live, with senior technical and clinical resource committed, is not conservative — it reflects what actually happens in practice.

What Good TrakCare Go-Live Preparation Looks Like

The programmes that go live cleanly share a consistent set of practices. None of them are novel. All of them require deliberate effort and organisational will to execute properly.

• Versioned interface specifications for every feed. A document per interface that captures the agreed message structure, trigger events, required segments and fields, Z-segment definitions, encoding requirements, and acknowledgement behaviour. Signed off by both sides before build starts.
• Cutover rehearsals at realistic volume and time window. First rehearsal 12+ weeks out. Dress rehearsal 6-8 weeks out. Both run with the rollback procedure tested, not just the cutover procedure.
• Named clinical and technical ownership per interface. Not team-level ownership. Named individuals who are accountable for a feed's readiness before go-live and its resolution if it fails after go-live.
• Go/no-go criteria agreed and documented before cutover week. Written criteria, not a general understanding. Clear thresholds for which outstanding issues prevent cutover and which do not. Agreed in advance so the decision is not made under pressure at midnight.
• Stabilisation support plan for weeks 1-4 post go-live. Named senior resource committed with defined availability. Runbooks for the most likely failure modes. An issue triage process that does not depend on everyone being in the same room.

When to Bring in Independent Assurance

Not every programme needs external assurance. But there are consistent signals that a programme is carrying more delivery risk than its internal governance can see clearly.

Programmes that benefit from independent review typically show one or more of these:

• Go-live date driven by political or contract commitments, not delivery readiness
• Interface specifications either absent or not agreed with consuming system owners
• Cutover rehearsals planned but not yet run, with go-live less than eight weeks away
• Vendor readiness based on self-declaration rather than tested evidence
• No written go/no-go criteria — readiness is expected to be assessed by consensus on the day
• Senior delivery resource is also carrying other programmes and has limited availability for escalations

An independent assurance review at this point is not a programme audit or a blame exercise. It is a structured look at the specific failure vectors — integration specifications, cutover readiness, rollback design, stabilisation planning, ownership clarity — with the goal of producing a short, actionable list of what needs to change before go-live.

JTX reviews typically produce a red/amber/green assessment of each risk area, a prioritised remediation list, and — where needed — direct support to close the gaps: reviewing or writing interface specifications, running a structured cutover rehearsal, or providing senior on-the-ground support during the cutover window itself.

Frequently Asked Questions