In many medical device software programs, “done” only means that the code has been written.
The software may appear complete, but requirements, risk documentation, traceability, verification evidence, architecture records, and release documentation remain unfinished. Teams then spend weeks or months reconstructing the development history and trying to align regulatory artifacts with software that has continued to change.
At Sequenex, we take a different approach.
We use a methodology called Continuous Delivery/Continuous Compliance, in which the software and its supporting regulatory artifacts are developed together.
Our principle is simple:
When it’s done, it’s done.
What Is Continuous Delivery/Continuous Compliance?
Continuous Delivery/Continuous Compliance is an integrated approach to regulated software development.
At Sequenex, we use a Kanban-based workflow aligned with IEC 62304, ISO 14971, our ISO 13485-certified quality management system, and applicable regulatory requirements.
As the software moves through development, the related requirements, design information, risk controls, verification evidence, traceability, configuration records, and release documentation move with it.
A development item is not complete simply because the code works. It is complete when the applicable design, development, testing, risk-management, traceability, review, and documentation activities are also complete.
There is no separate documentation project waiting at the end.
Avoiding Documentation Debt
When documentation is postponed until the end of development, teams must reconstruct the product’s history after the work is done.
They may need to determine:
- Why a feature was developed
- Which requirement does it satisfy
- Which risks does it address
- Which test verified it
- Which software version was tested
- How later changes affected the system
This process is time-consuming, expensive, and vulnerable to gaps.
With Continuous Delivery/Continuous Compliance, regulatory artifacts are developed alongside the software, ensuring that technical decisions and supporting information remain current.
Automation helps maintain the relationships among requirements, risks, code, tests, defects, builds, and releases. Reviews, approvals, risk decisions, and validation conclusions remain the responsibility of qualified personnel, but much of the supporting evidence can be generated and maintained through the development workflow.
The Benefits of Continuous Delivery/Continuous Compliance
The greatest benefit is a more meaningful definition of done.
A feature is not reported as complete while testing, traceability, risk documentation, and regulatory artifacts remain unfinished. Sponsors gain a clearer view of actual progress and product readiness.
This approach helps:
- Reduce late-stage documentation and remediation
- Keep software and regulatory records aligned
- Identify quality, safety, and integration issues earlier
- Maintain traceability across requirements, risks, code, and tests
- Improve visibility into the true status of each release
- Support clinical studies, regulatory submissions, and commercialization
The objective is not to eliminate regulatory work. It is to perform that work as part of development when the relevant information is available.
How Sequenex Uses Continuous Delivery/Continuous Compliance
Sequenex integrates regulated software-development activities into a Kanban-based workflow.
Each work item progresses through the applicable requirements, design, risk-management, implementation, review, testing, traceability, and documentation activities before it is considered complete.
Our definition of done includes both the working software and its supporting development evidence.
Depending on the project, that evidence may include software requirements, architecture and design documentation, software risk analysis, verification results, traceability, configuration records, problem-resolution records, cybersecurity documentation, and release documentation.
These artifacts are not recreated after development. They are developed and maintained alongside the software.
When It’s Done, It’s Done
Continuous Delivery/Continuous Compliance gives medical device companies working software and a development record that accurately reflects it.
Compliance is not treated as a documentation phase that begins after development. It is integrated into how the software is planned, designed, built, tested, reviewed, and released.
When it’s done, it’s done.
Frequently Asked Questions
How does agile development work in a regulated SaMD environment?
Agile development works in a regulated SaMD environment when each work item is only complete once its requirements, risk controls, tests, traceability, and documentation are complete alongside the code. Using a Kanban workflow aligned with IEC 62304 and ISO 14971, the regulatory evidence is produced as the software is built, not reconstructed later, which keeps agile speed without sacrificing the record a submission needs.
What CI/CD approach works for healthcare compliance?
A CI/CD approach works for healthcare compliance when the pipeline maintains the links between requirements, risks, code, tests, and releases, so every build carries its supporting evidence. Automation maintains traceability, while reviews, risk decisions, and validation conclusions stay with qualified personnel. The goal is continuous compliance: each release is tested, documented, and traceable as it ships.
How can every software release meet regulatory requirements without manual review gates slowing delivery?
Every release can meet regulatory requirements without slowing delivery when the evidence is generated through the development workflow rather than assembled at the end. Automation maintains traceability across requirements, risks, code, tests, and releases, so the supporting record is always up to date. Qualified personnel still own the reviews and approvals, but they review existing evidence rather than reconstructing it.
What is the difference between continuous delivery and continuous compliance?
Continuous delivery keeps software in a releasable state through frequent, tested builds. Continuous compliance extends this idea to regulatory evidence, ensuring that requirements, risk controls, traceability, and documentation stay current with every release. Together, they mean a SaMD product is never left with a separate documentation project waiting at the end.
