Anti-Doping Case Management Software Problems: The 5 That Cost You Cases, and How to Avoid Them

Why does chain of custody get scoped as an editable log so often?

Because every developer has built an activity log before, and an activity log is a table you write rows into. It looks like the same thing. It is not, and the difference only becomes visible two years later in a hearing room.

An operational log exists so staff can see what happened. A custody record exists so a third party can be satisfied that nothing else happened. That second purpose imposes requirements the first does not: entries written once, corrections recorded as new entries that supersede rather than overwrite, the sequence hashed so alteration is detectable, and a rendering a non technical panel can read without a database administrator present. An audit table an administrator can update fails all four, and the failure is invisible during acceptance testing because the data looks identical.

The other half is capture discipline in the field. Kit codes and sample codes should be scanned rather than typed, because a transposed digit is exactly the kind of error that ends a case, and timestamps should come from a source the collector cannot set. Integrity and temperature observations attach to the specific custody event with any photograph, not to a folder somebody will later have to associate by filename.

Test this before you accept the system. Ask for the complete custody sequence for one sample code, produced as a document, and read it as if you were the panel. If you cannot tell from that document who held the sample, when, and whether anything was changed afterwards, the record is not evidence yet.

What goes wrong when you migrate the test plan and case history?

The test distribution plan is almost always a spreadsheet built by one analyst, and it is the hardest thing in this domain to migrate, because what you need to move is not the numbers. It is the reasoning.

A plan holds risk weightings for physiological demands, competition calendar, historical findings, performance progression and intelligence, and in the spreadsheet those weightings are implicit in formulas and in decisions the analyst made without recording them. Import the allocations and you get a system that says which athletes were tested without being able to say why, which is precisely the question a programme review or an athlete's counsel will ask. Budget real time to write the model down and get it approved before anyone builds it. In our experience that documentation exercise, not the engineering, is what sets the schedule on these projects.

Why do offline field capture and reporting exchange break after launch?

Two integrations decide whether an anti-doping build survives contact with reality, and neither is the one people worry about during procurement.

The first is the device in the field. A no advance notice mission at a residential address at six in the morning is precisely where connectivity fails, and the failure modes are ugly: a form half completed when the app is killed by the operating system, a signature captured and lost, a mission recorded twice because sync created a duplicate after the officer retried. The fixes are specific. Identifiers must be generated on the device so a retry cannot create a second mission. Local storage must survive the app closing and the phone restarting. Sync state must be visible so the officer knows what has reached the server before leaving the building. And the timestamp on a custody event must be captured at the moment of the event, not at the moment of sync. Test this by taking a device into a stairwell and killing the app mid form.

The second is data exchange with the mandated global system. This is a specification exercise against a calendar you do not control, and the failure after launch is silent rather than loud: a submission rejected for a field validation change, queued, and never retried, so your operational system believes something was reported that was not. Treat every outbound submission as unconfirmed until an acknowledgement returns, keep failures in a visible queue rather than a log, and reconcile counts between systems on a schedule. Laboratory interfaces have the same shape, since each accredited laboratory delivers results in its own format and a format change is not announced to you in advance.

What happens when intelligence and exemption confidentiality are not covered?

This is the gap that damages people rather than cases. Programmes increasingly act on information: a whistleblower, a customs referral, a pattern in longitudinal data, a tip from another organisation. Some of that material is attributable to a person at real risk. If it sits in the same case management inbox as general work, protected only by user roles an administrator can change on a Friday afternoon, you do not have source protection. You have an intention.

Separation has to be structural. Intelligence records belong in their own store with independent access control, a controlled path by which intelligence informs the test distribution plan without exposing the source, and permanent access logging showing who opened what. That logging protects your staff as much as the source, because the alternative when something leaks is an investigation with no evidence in either direction.

Therapeutic use exemptions are the mirror image of the same problem. They contain medical records, they are decided by a panel that must be independent of the testing operation, and they must be retrievable at the exact moment a laboratory reports a finding for that substance. A shared drive of documents fails on all three counts, and it fails quietly until the day it matters. The other frequently uncovered gap is separation of duties inside the case itself: the person who collected the sample must not be the person who reviews the resulting missed test, and the system should enforce that rather than trusting a coordinator to remember it during a busy quarter.

Should you build custom or configure what you already own?

If your programme tests a few dozen athletes a year, works mostly in competition, and uses an external service provider for collections, do not build. Operate inside the mandated system with well kept procedures and spend the money on more tests. More tests is a better anti-doping programme than better software, and we would say that to anyone who asked.

Be clear about what the mandated system is and is not. It is the system of record for whereabouts filings, results and results management data exchange, and nothing replaces it. It was not designed to plan your test distribution against a risk model you own, to schedule and pay your collection personnel, to hold intelligence with structural separation, or to assemble an evidence bundle for a hearing. Those gaps are where programmes reach for spreadsheets, and those are the gaps a build should close. Anyone proposing to replace the system of record has misunderstood the domain.

Build when two or more of these are true. You plan and justify your own test distribution rather than executing someone else's. You manage collection personnel directly, with accreditation, conflicts and payment to control. You handle results management through to hearing and have had a case turn on documentation rather than science. You receive intelligence and have no structural separation between that material and general case handling. Or you operate across sports and jurisdictions where the rules genuinely differ and one process cannot express both.

How do hidden costs get into an anti-doping software quote?

Jurisdiction count is the largest multiplier and the one most often missing. Sanction rules, privacy obligations, language requirements and notification formats differ, and each additional jurisdiction is real development rather than a locale setting. If the proposal does not name the jurisdictions in scope, the price is for one.

The athlete facing application is the third, and the item most consistently underestimated. Whereabouts filing is the most legally consequential form your athletes will ever complete on a phone, which means accessibility, multiple languages, an unambiguous confirmation of what was submitted and when, and a support burden that lands on your staff rather than your developer. It also should not be in release one, since athletes can continue filing in the mandated system while your internal workflow is fixed.

Fourth, longitudinal data handling, which is a different analytical shape from pass or fail results and needs specialist input. Fifth, officer payment, especially across borders, because contractor payment is a finance integration with its own compliance requirements. Sixth, your own people, because documenting the risk model is your analyst's time and the notification wording is your counsel's time. Neither appears in a developer's quote and both are on the critical path.

What separates a build that works from one that fails here?

The successful programmes build the operations core first: the plan with its risk model made explicit, mission and officer management, offline field capture, and append only custody through to laboratory dispatch. Then they add the athlete application, exemptions and results management. The failed ones start with the athlete app because it is the visible part, and end up with a polished filing experience feeding a planning process that still lives in a spreadsheet.

Third, involve a doping control officer in weekly reviews from the start. The people who decide whether this software works are standing in a stairwell at six in the morning with cold hands, and their tolerance for a spinning icon is zero. Requirements gathered from the compliance office produce systems that fail in the field. Fourth, insist on append only storage from day one, because retrofitting immutability onto an editable table means restating history, and restated history is exactly what you are building this to avoid.

Finally, settle ownership in writing before kickoff: the repository, the hosting accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. For an organisation whose independence is the product, being unable to leave a vendor is a governance problem rather than a commercial inconvenience.