SaMD Compliance: Why Your Dev Stack Is Now Your DHF

If you're managing regulatory affairs for a Software as a Medical Device (SaMD) company, you've likely witnessed this painful ritual: two weeks before a submission or notified body audit, someone from quality descends upon the development team. What follows is a frantic extraction exercise—pulling content from Jira tickets and GitHub repositories, reformatting everything into Word documents, rewriting technical language into regulatory prose, and hoping nothing critical gets lost in translation. This isn't just inefficient. It's a fundamental misalignment between how modern software gets built and how regulatory bodies expect to see it documented. But a significant shift is underway in how leading SaMD manufacturers approach IEC 62304 compliance, and it has profound implications for quality operations across the sector.

The Traditional DHF Bottleneck

The Design History File remains a cornerstone of medical device regulation, codifying the complete design and development history of your device. For hardware manufacturers, this documentation paradigm evolved naturally—design reviews, specification documents, and test protocols already existed in relatively static forms. But software development operates differently. Modern SaMD teams work in continuous integration environments where Jira tracks requirements and feature development, GitHub manages version control and code reviews, and automated CI/CD pipelines execute verification testing. These tools weren't designed with FDA or notified body submissions in mind, yet they contain the most accurate, time-stamped record of what actually happened during development.

The disconnect creates risk on multiple fronts. Manual transcription introduces errors and omissions. Documentation quickly becomes outdated as development sprints forward. Most critically, the artefacts you submit for regulatory review don't reflect the actual work practices auditors will observe when they visit your facility. When an auditor asks to see how a specific requirement was implemented and verified, your team scrambles to map a Word document back to actual Jira tickets and pull requests—assuming they can find them at all.

IEC 62304, the international standard for medical device software lifecycle processes, doesn't prescribe specific documentation formats. It requires that you maintain traceable records of software requirements, architecture, detailed design, unit testing, integration testing, and verification activities. Nowhere does it mandate that these records must live in a traditional document management system. This regulatory flexibility is creating space for a more pragmatic approach: treating your development stack itself as a controlled source of DHF content.

From Extraction to Integration

Forward-thinking SaMD manufacturers are rethinking the relationship between quality management systems and development tooling. Rather than extracting content from Jira and GitHub for compliance theatre, they're implementing bidirectional integrations that allow these platforms to function as controlled DHF repositories. The technical implementation varies—some organisations use API integrations to pull structured data into their QMS, others implement plugins that enforce compliance metadata directly within developer workflows, and a few have adopted QMS platforms specifically designed for software development paradigms.

The practical benefits are substantial. When a Jira ticket tagged as a 'regulatory requirement' gets created, it automatically inherits required fields for traceability, risk classification, and verification planning. When developers submit a pull request in GitHub, automated checks verify that commit messages reference appropriate requirements and that required reviewers have approved changes based on risk class. When CI/CD pipelines execute automated tests, results are captured with full traceability to the requirements they verify. The DHF doesn't get assembled before an audit—it builds itself continuously as development progresses.

This approach requires careful implementation. Your development tools must operate under configuration management with appropriate access controls, audit trails, and backup procedures. You need clear procedures defining what constitutes a controlled record versus informal collaboration. Templates and workflows need design to ensure developers capture necessary compliance information without drowning in bureaucracy. Done well, it reduces compliance burden rather than increasing it, because you're capturing information once, in context, rather than recreating it later for regulatory purposes.

Regulatory Acceptance and Practical Considerations

The critical question: will notified bodies and FDA accept this approach? The answer is increasingly yes, provided you meet fundamental regulatory expectations around traceability, version control, and evidence of required activities. Several factors are driving acceptance. First, regulators recognise that software development practices have evolved substantially since medical device quality system regulations were written. Second, recent FDA guidance on software validation and cybersecurity explicitly acknowledges modern development practices including agile methodologies and continuous integration. Third, auditors are encountering this approach often enough that it's no longer novel.

That said, you cannot simply declare Jira your DHF and expect approval. Successful implementation requires demonstrating that your development tools meet the same fundamental controls as traditional DHF systems. This means documented procedures for how these tools support your software development lifecycle, clear definitions of what constitutes a controlled record, appropriate training for users, and periodic audit of compliance. You need to show traceability from user needs through risk management, requirements, design, implementation, verification, and validation. The format matters far less than the completeness and accuracy of the evidence.

For organisations maintaining legacy documentation approaches, transition requires careful planning. You likely cannot flip a switch and move everything to a new paradigm overnight. A phased approach works better—perhaps starting with new product development while maintaining existing practices for legacy devices, or implementing integration for specific DHF components like software requirements and verification while keeping design documentation in traditional formats initially. The goal is continuous improvement toward a more sustainable compliance model, not revolutionary change that introduces new risks.

What This Means for Your Team

If you're responsible for quality or regulatory affairs at a SaMD manufacturer, this shift demands attention now, not later. The companies implementing these approaches are moving faster, spending less on compliance overhead, and maintaining more accurate, auditable records. That creates competitive advantage in time-to-market and quality system effectiveness. More immediately, if your current audit preparation involves weeks of manual document compilation, you're carrying technical debt that will only grow more expensive as your software portfolio expands and regulatory scrutiny intensifies.

For regulatory professionals specifically, this evolution requires expanding your understanding of software development tools and practices. You need sufficient familiarity with platforms like Jira, GitHub, and CI/CD concepts to evaluate whether implementations truly satisfy IEC 62304 requirements. This doesn't mean becoming a developer, but it does mean moving beyond purely document-centric thinking about DHF content. Consider shadowing your development team to understand actual workflows, or requesting training on the tools they use daily. The most effective regulatory professionals in SaMD organisations are becoming bilingual—fluent in both regulatory requirements and development practices.

Quality managers face a parallel challenge: implementing controls around development tooling without imposing friction that drives developers toward workarounds. The most successful approaches involve genuine collaboration between quality and development to design workflows that satisfy both regulatory requirements and developer productivity. When developers perceive compliance activities as bureaucratic obstacles, they find ways around them. When compliance is embedded naturally in tools they already use, adherence improves dramatically. This requires quality professionals to adopt a service mindset—understanding their internal customers' needs and designing systems that make compliance easier, not harder.

Key Takeaways

• Modern SaMD development tools like Jira and GitHub can serve as controlled sources of DHF content when properly implemented with appropriate configuration management, access controls, and audit trails—eliminating costly manual transcription exercises.
• IEC 62304 does not mandate specific documentation formats, creating regulatory flexibility for treating development stack artefacts as primary compliance evidence rather than secondary sources requiring translation into traditional documents.
• Successful implementation requires bidirectional integration between QMS and development tools, clear procedures defining controlled records, and sufficient controls to demonstrate traceability from requirements through verification—regulators increasingly accept this approach when fundamentals are met.
• Regulatory and quality professionals must develop fluency in modern software development practices and tools to effectively evaluate compliance, while maintaining focus on regulatory fundamentals rather than documentation format preferences.
• Transitioning from legacy documentation approaches requires phased implementation, genuine collaboration between quality and development teams, and embedded compliance workflows that support rather than obstruct developer productivity.

The convergence of development tooling and quality management systems represents more than a technical efficiency gain. It reflects a maturing understanding of how software medical devices should be regulated—focusing on evidence of rigorous processes rather than adherence to documentation formats designed for hardware paradigms. For organisations willing to invest in proper implementation, the payoff extends beyond audit preparation. You gain real-time visibility into development activities, more accurate traceability, and quality systems that scale with your software portfolio rather than collapsing under documentation burden. At SMEDTEC, we're working with SaMD manufacturers to navigate this transition thoughtfully, ensuring that modernised approaches satisfy both regulatory expectations and practical business needs. The future of SaMD compliance isn't about making development look like traditional manufacturing—it's about making compliance work the way software actually gets built.