DCB0129 route
DCB0129 Evidence Pack
The hazard log, the Clinical Safety Case Report and our in-house CSO's signature, with every control backed by a test on your real product.
Explore DCB0129How it works
From first call to signed evidence.
A 20-minute scoping call, a two-week Sprint on your real product, then the full evidence pack typically four weeks later. After that, every release keeps it current.
- Day 1 Scoping call. A proposal within one working day.
- Weeks 1–2 Compliance Sprint. Your highest-risk area, tested and evidenced.
- Weeks 3–6 Pack completion. The full pack, signed where the route needs it.
- Every release Continuous Coverage. Re-tested and re-issued.
Typical timings for one product and release.
The engagement
Six stops, and you know what you’ll have at each one.
The same path for both routes. What changes is the pack you receive at the end: the DCB0129 Evidence Pack or the IEC 62304 Verification Pack.
-
Day 1
Scoping call
Twenty minutes on your product, the review in front of you and the evidence you already have. No preparation needed.
You leave with
A proposal within one working day: the route, the Sprint scope, the dates and what we need from you.
-
Kickoff
Agree access and inputs
Your build, a test environment and the people we need, confirmed before the clock starts, so the dates hold.
You leave with
A scoped plan, an input list and stated assumptions.
-
Sprint · week 1
Map what matters
Intended use, users and clinical workflows. Hazards or requirements mapped, and the tests designed around your highest-risk area.
You leave with
A map of the risks and requirements that matter most, and the tests that will prove them.
-
Sprint · week 2
Test your real product
Scenarios run on your build and reviewed by a person. Findings, fixes and re-tests stay on one trail.
You leave with
An evidence foundation, a gap list, and a costed route to the full pack. Stop here if you choose, and keep everything.
-
Typically 4 weeks
Complete the pack
The remaining hazards, requirements, tests and documents. For DCB0129, our Clinical Safety Officer reviews and signs the safety case.
You leave with
The signed DCB0129 Evidence Pack, or the IEC 62304 Verification Pack.
-
Every release
Keep it current
Each release re-tested where it changed, and the pack re-issued. After a model change too, if your product uses AI.
You leave with
Evidence that always describes the version your customers are using.
What we need from you
Less than you’d think, agreed before we start.
-
A working view of the product and the release you're preparing
-
The users, setting and clinical workflows that matter
-
Whatever requirements, risks, tests or documents already exist. Nothing has to be tidy
-
Access to your build and a test environment
-
The decision or reviewer question the evidence has to answer
Please do not send patient data. Testing runs on synthetic data in your test environment.
How the testing works
One trail, from the risk to the release.
Every test starts from something a reviewer cares about and ends on the build you release. Nothing is reconstructed afterwards, because it was recorded as it happened.
- Hazard or requirement
- Control
- Test
- Result
- Defect and re-test
- Release record
IEC 62304 route
IEC 62304 Verification Pack
Every requirement verified on your build, from safety classification to technical-file index, including the SOUP register and change records.
Explore IEC 62304A person reviews every scenario
Automation helps with repetition. It never replaces the judgement about what the product did or what the evidence shows.
Real devices and browsers
Phones, tablets and browsers your users actually have, not emulators, including weak signal and interrupted sessions.
Every result stamped with its build
A reviewer can always tell which version of your product the evidence describes.
Practical questions
Before you book the call.
Can we stop after the Sprint?
Yes. The Sprint is fixed scope and stands on its own. You keep everything it produces, including the gap list and the costed route to the full pack. There is no lock-in.
What slows the timeline down?
Three things, none of them testing: waiting for access to the build or test environment, waiting for input from your team, and fixes that land after the window. We agree all three at kickoff so the dates hold.
What happens after the scoping call?
A proposal within one working day: the route, the Sprint scope, the dates and what we need from you. If it fits, we agree access and inputs at kickoff before the clock starts.
Who from our team needs to be involved?
Usually a product owner, technical lead, and someone who can provide clinical, quality, or regulatory input where relevant. We agree the expected input and review points during scoping.
What if we already have some evidence?
We map what is already useful, identify what is missing or needs reworking, and build the delivery path around the material that can be trusted and traced.
How is a Sprint scoped?
A Compliance Sprint is a fixed-scope engagement. The proposal reflects the product, regulatory route, evidence gap, working assumptions, and agreed deliverable. If you continue into Continuous Coverage, the Sprint work can be carried forward into the retainer plan.
Do you need real patient data?
No. We never ask for patient data, and we do not work with it. Testing runs against synthetic data in your test environment.
What happens on the next release?
Continuous Coverage can be scoped to keep evidence current as the product changes. The work is planned around your release model, change context, and evidence priorities.
See your evidence route in 20 minutes.
Bring the product and the question in front of you. We'll map it to the right route and come back with a proposal within one working day.