First the real process. Then the code
Most systems that fail an audit don't fail because of the code. They fail because nobody wrote down clearly what the system had to do, or why.
Development and validation, side by side
The software and its validation documentation move forward together. Every phase ends with a signed deliverable, and a requirement that can't be tested is rewritten before moving on.
Top, the software; bottom, its validation documentation.
- 0. AssessmentAssessmentIs it worth it?If it isn't worth it, it ends here
- 1. StrategySoftware development: The real processmapped where the work happensValidation documentation: Validation planscope and responsibilities
- 2. User requirementsSoftware development: Requirementswith the people who will use itValidation documentation: URSreviewed by qualityCan't be tested: it is rewritten
- 3. Design and buildSoftware development: Short deliveriesyou can reviewValidation documentation: TS and DQqualified design
- 4. Risk-based approachValidation documentation: Risk assessmentpatient, product and data integritysets the testing effort
- 5. Continuous verificationSoftware development: Automated testsfrom day oneValidation documentation: Test evidenceand model evidence, if there is AI
- 6. QualificationSoftware development: Installationin your environmentValidation documentation: IQ, OQ and PQprotocol, execution, deviations and report
- 7. ReleaseReleasedocumentation closed and signed
- 8. Validated stateValidated statesupport and change controleach change states which evidence to redo
A preliminary assessment and eight phases, from the real process to the validated state
What happens and what is delivered at each phase.
Assessment
Before starting, we review the process with you: where time is lost, how much control it calls for and whether AI adds value.If it isn't worth it, it ends here. If the assessment shows that the process gains nothing from custom software, that an off-the-shelf tool solves it, or that compliance gets harder with no benefit, we tell you so and we don't go any further.
Deliverable: A clear answer: whether the project is worth it or not.
Strategy
We go where the work happens and map the real process, not the one in the procedure. With that map we set the validation strategy: scope, responsibilities and the client's own procedures that apply.
Deliverable: Validation plan.
User requirements
Written with the people who will use the system and reviewed by quality. If a requirement can't be tested, it isn't a requirement, and we rewrite it.
Deliverable: User requirements specification ().
Design and build
Short, reviewable deliveries. You see the system working long before it is finished, which is when it is still cheap to change.
Deliverable: Technical specification and design qualification ().
Risk-based approach
We assess where a system failure would reach the patient, the product or data integrity. That assessment decides the testing effort for the rest of the project, which is concentrated where the risk justifies it. If there is AI, it also weighs the model's uncertainty, its influence on the decision and how hard its failures are to detect.
Deliverable: Risk assessment.
Continuous verification
Automated testing from day one, with manual effort kept for what the risk justifies. This is the computer software assurance approach, and it cuts paperwork without cutting evidence. If the system includes a model, it is also evaluated with real cases against an acceptance criterion set in advance.
Deliverable: Evidence from the tests and, if there is AI, the model documentation.
Qualification
Installation, operational and performance qualification (IQ, OQ and PQ) in your environment, on a design already qualified in the DQ.
Deliverable: , and , each with its protocol, execution, deviations and report ( is delivered in phase 3).
Release
With the documentation closed and signed, the system goes into production with its validation report, not with a promise to write it.
Deliverable: Traceability matrix, residual risk assessment and final validation report.
Validated state
Support, evolution and change control. Every later change states which evidence has to be redone, and that decision is documented. If you prefer, we also host and maintain the infrastructure on Azure or AWS.
Deliverable: Plan for maintaining the validated state and, if there is AI, the model monitoring plan.
It all starts with the first phase
We assess the process and the risk with you before writing a single line of code.