Building Regulated Software for IVD Laboratories

Why Regulated Software Is Different

Building software for in-vitro diagnostic (IVD) laboratories is not the same as building a typical SaaS product. When your software influences clinical decisions - even indirectly - it falls under the EU In Vitro Diagnostic Regulation (IVDR) and must meet the requirements of IEC 62304 (medical device software lifecycle).

This article covers the essential considerations for development teams entering this space.

IEC 62304: The Software Lifecycle Standard

IEC 62304 defines three software safety classes (A, B, C) and prescribes activities for each phase of the development lifecycle:

• Software development planning - Define your processes, tools, and deliverables before writing code.
• Requirements analysis - Capture functional, performance, and safety requirements traceably.
• Architecture and detailed design - Document how components interact and how risks are mitigated.
• Implementation and verification - Unit tests, integration tests, and code reviews must be documented.
• Maintenance - Post-market changes follow the same rigor as initial development.

The higher the safety class, the more documentation and verification is required. Class C software demands full architectural documentation and detailed design for every module.

Practical Architecture Decisions

When designing for regulated environments, certain patterns pay dividends:

• Immutable audit trails - Every data change must be traceable to a user and timestamp. Append-only logs are your friend.
• Role-based access control - Enforce least-privilege access. Regulators will ask who can modify what.
• Validation-ready test suites - Automated tests double as verification evidence. Structure them to map back to requirements.
• Separation of concerns - Keep clinical logic isolated from UI and infrastructure. This simplifies re-validation when the UI changes.

The QMS Connection

Your development process needs to sit within a Quality Management System (typically ISO 13485). This means:

• Controlled document management
• Change control procedures with impact analysis
• CAPA (Corrective and Preventive Action) processes
• Regular management reviews

Working with Notified Bodies

For Class B and above, a Notified Body will review your technical documentation. Prepare for:

• Detailed software lifecycle records
• Risk management files (ISO 14971)
• Clinical evidence and performance evaluation
• Post-market surveillance plans

Key insight: Building regulated software is slower and more deliberate than agile-only teams are used to. But integrating compliance into your development workflow - rather than bolting it on later - is both faster and cheaper in the long run.