Healthcare & MedTech
When the software is part of the device, so is the evidence behind it.
Your software does not ship alone. It ships inside a device that a notified body has to clear, a hospital has to trust and a clinician has to rely on without ever reading the code. What you demonstrate is not only that it works, but how you know — for every release, over the life of the product.
The evidence usually exists. It is spread across tools, teams and suppliers, produced as a by-product of development rather than designed for review. That holds until a submission, an audit or a field incident, when it has to be read as one file.
Three recur from start-ups to established manufacturers — whatever the device class.
Development tools are built to ship software, not to produce a technical file. Traceability from requirement to risk control to test ends up reconstructed ahead of each submission — at the point where gaps are most expensive to close.
Libraries, operating systems and cloud services sit inside your safety classification. Their behaviour has to be justified, and their updates keep arriving after clearance.
Machine-learning functions now fall under the MDR and the EU AI Act at the same time. Validation that satisfies one does not automatically satisfy the other, and a model that changes after release changes what “validated” means.
As a manufacturer, you answer to a product regulation, lifecycle standards that reach from the software up to the system around it, and a growing layer of cybersecurity and AI rules — much of it assessed through the same conformity route.
Software can be a device in its own right, and its classification decides whether a notified body is involved. A targeted revision of both regulations, including software classification, is in negotiation.
The software lifecycle standard: safety classification, documented development and maintenance, and the handling of third-party software. A second edition is in drafting, extending it to health software and adding AI safety and cybersecurity practices. It is not expected before 2028.
Risk management across the life of the product, with risk controls that must trace through to verification.
Security activities across the system lifecycle, and the cybersecurity expectations applied to connected devices.
AI-enabled devices that need a notified body are high-risk AI systems, with obligations applying from August 2028 in parallel with the MDR. AI-native systems have to establish their risk classification and meet the obligations that follow from it.
The technical file has to read as one argument. These are the three engagements that get it there — and keep it there after clearance.
Independent verification against IEC 62304 and ISO 14971: software safety classification, traceability from requirement to risk control to test, and the verification evidence behind each link in that chain.
- Traceability produced as the work happens, not reconstructed before a submission
- Third-party and off-the-shelf software justified inside your safety classification
A gap assessment against the MDR or IVDR, IEC 62304, IEC 81001-5-1 and the cybersecurity expectations now read alongside them — and, for the US market, the premarket cybersecurity information the FDA expects and the HIPAA safeguards that apply wherever the system touches protected health information.
- Findings mapped to the clause and the section of the technical file they affect
- A prioritized closure plan with the effort already estimated
Machine-learning functions assessed under both regimes at once: the device regulation that clears them and the AI Act that governs them, including what happens when the model changes after release.
- One body of validation evidence that answers the MDR and the AI Act together
- Change control for models that are retrained, updated or allowed to adapt
AI-assisted clinical and operational decision-making that can go into service, with a smaller chance of a regulatory finding, a data leak, or a model being used for something it was never cleared for.
Where our work in regulated medical software concentrates.
Architected and delivered large-scale enterprise medical billing, document scanning and electronic records management systems, with role-based access and data security controls built in.
Developed and delivered graduate-level software security and DevSecOps courses at Carnegie Mellon’s Heinz College and School of Computer Science, training engineering leaders on health data privacy and software assurance.
Active contribution to the Open Group Security Forum, establishing cross-industry enterprise security architectures and data-protection reference frameworks.
Safety classification, development and maintenance processes, and the handling of software you did not write.
Risk controls followed through to the verification that shows each one works.
Security activities across the system lifecycle under IEC 81001-5-1, read with MDCG 2019-16.
SBOM-based analysis of libraries, operating systems and cloud services inside your device.
Evidence designed to satisfy the device regulation and the AI Act from the same work.