Medical device software, computer system validation and data integrity — engineered for GxP environments and designed to answer an inspector years after release, not just pass user acceptance testing.
Teams that treat regulatory work as a post-launch cleanup rewrite their architecture, their test evidence, or both. The traceability an auditor asks for — requirement to design to test to release — cannot be reconstructed convincingly after the fact, because the artefacts that would prove it were never created in the right order. We build it in from the first architecture decision.
End-to-end development for software as a medical device and software in a device: safety classification and its consequences for the process, architecture and detailed design, SOUP and third-party component management, unit and integration verification, and the software part of the technical file. Risk management runs under ISO 14971 throughout rather than as a document produced at the end, and usability engineering is carried alongside it because most software hazards are use hazards.
Validation of GxP systems — EDC, eCOA, RTSM, LIMS, eTMF, QMS, ERP and clinical platforms — under GAMP 5, 21 CFR Part 11 and EU GMP Annex 11 — and, for clinical trials, the EMA guideline on computerised systems and electronic data. Risk-based and right-sized: critical thinking applied to where the patient risk and data integrity risk actually sit, testing effort concentrated there, and unscripted testing used where it is the better evidence. We also transition organisations from traditional CSV to a computer software assurance approach without leaving a validation gap in the handover.
Data integrity programmes for clinical, laboratory and manufacturing environments: audit trail design and audit trail review that someone actually performs, electronic signature workflows, access and segregation controls, data lifecycle and retention, and remediation where integrity has already been compromised. The hard part is rarely the system — it is the manual steps and spreadsheets between systems, and that is where we look first.
Vendor and supplier qualification for SaaS platforms where you validate what you cannot inspect, shared responsibility models made explicit, validated migration from on-premise to cloud with compliance continuity, and modernisation of legacy GxP systems that are past support but still hold regulated records.
Validation practice was built for systems in a controlled data centre. A study today runs on software executing on a participant's own phone, over a network you do not control, against an operating system that updates without asking. The controls still apply; the evidence has to be gathered differently. Perimeters two and five of our assessment — computerised systems and configuration change — are where that is worked out, and it is the reason our validation work and our device work are the same practice rather than two teams.
Where the software is the medical device, the two halves meet: IEC 62304 governs how it is built, the device perimeter governs whether it needed to be built that way, and an AI-enabled function adds a change control question on top of both. We run those together rather than sequentially, because discovering the qualification answer after the architecture is set is the most expensive order to do it in.
Teams treat the EU AI Act as governance paperwork. For an AI-enabled medical device it is a second conformity route running alongside EU MDR, with its own technical documentation, risk management, data governance, logging, transparency, human oversight and post-market monitoring duties. These are checked within the EU MDR or IVDR conformity assessment, by a notified body that must also meet the AI Act’s requirements for assessing AI systems (AI Act Art. 43(3)).
Whether it applies to you turns on two cumulative conditions, not one. Article 6(1) makes an AI system high-risk where it is a safety component of, or is itself, a product covered by Annex I harmonisation legislation — Section A of which lists EU MDR 2017/745 at item 11 and IVDR 2017/746 at item 12 — and where that product requires third-party conformity assessment. A self-certified Class I device does not satisfy the second condition. A Class IIa device with a notified body does.
The date. The AI Act has applied generally since 2 August 2026. For Annex I products — which include devices under EU MDR 2017/745 and IVDR 2017/746 — the high-risk obligations under Article 6(1) apply from 2 August 2028, the date set by the AI Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026. Nothing about that date is generous: an AI-enabled device in development now has to carry its AI Act technical documentation, risk management, data governance and post-market monitoring in the file it is already writing.
What we do about it. Applicability determination that survives challenge in either direction. Gap assessment of the AI Act duties against what your ISO 13485 and IEC 62304 processes already produce — which is more than most teams expect, and the overlap is where the budget is saved. Change control for models that keep learning, aligned with the change control plan you need for the device anyway. And the documentation set built once, mapped to both regimes, rather than twice.
Validation and data integrity fail when they are treated as a vendor handover. We sit with your IT quality lead, your eClinical vendor and your statistics group to define:
The output is a validation pack and a change-control path that survives vendor turnover — because the reasoning is in your system, not in a consultant's laptop.
A free account opens both — no approval step, no sales call attached.
qointa Services brochuresFree
Computer system validation across the full lifecycle, from validation planning and risk assessment through to execution and reporting.
Download PDF →
Position papersFree
A companion reading from the device-management vendor seat — what the control plane must evidence, and when constraining a device is someone else’s regulatory problem
Read the summary →
Position papers
When a device captures trial data — a handset, a wearable, a home instrument or the gateway that relays them — attribution, time and protection against alteration are decided on the device, and no validated database can decide them later.
Read the summary →A focused gap assessment against IEC 62304, GAMP 5, Part 11 and EU GMP Annex 11 — with a remediation sequence, not just findings.
Book a 15-minute call