How to prepare a DTAC evidence pack

In short: treat DTAC as an index to evidence you already keep current — not as a separate form you fill at tender time. Write intended use first, then map each of the five areas to a named artefact with an owner and a review date.

Start with intended use, not the form

Every later artefact hangs off a one-page intended-use statement: who uses the product, on whom, to do what, and what it does not do. If that page is vague, the clinical safety case, the DPIA and the SaMD question will contradict each other. Buyers notice.

A sequence that actually finishes

1. Clinical safety — DCB0129 safety case and hazard log for the current version, with a named clinical safety officer. See DCB0129 vs DCB0160.
2. Data protection — lawful basis, retention, processors, and a DPIA where the processing is high-risk (most health AI is).
3. Technical security — testing commensurate with the data, secure development notes, and DSP Toolkit status if you claim it.
4. Interoperability — named standards and targets, not “FHIR-ready.” See FHIR vs HL7.
5. Usability and accessibility — WCAG 2.2 AA evidence against the live product, not a design-system screenshot.

Keep a living pack, not a zip file from last year

The failure mode is a polished pack that describes v2.1 of a product now on v4. Assign an owner to each artefact and a review date. When the product changes intended use, the safety case and DPIA move first; the DTAC answers follow. That is also how the pack becomes reusable across buyers instead of being rewritten for every tender.

What “good” looks like to a panel

Short answers that point to evidence, with the evidence attached. No claims the safety case does not support. An honest list of residual risks and how the deploying organisation is expected to manage them under DCB0160. Over-claiming clinical capability is the fastest way to a longer review — it raises the regulatory bar and the clinical-safety bar at the same time.