Every SaMD team running Jira knows the audit drill. Someone from quality shows up two weeks before a submission or a notified body review, and the next several days are spent extracting, reformatting, and pasting content from Jira tickets into documents that look nothing like what developers actually wrote. Same content, different audience, so somebody rewrites it.
The rewrite is not a Jira problem. It is a structural one, and it has a name: the gap between your system of entry and your system of record.
Closing that gap is the central challenge of software as a medical device (SaMD) quality operations. This post lays out why SaMD QMS work is different from hardware, how to diagnose where your development tools and quality system are disconnected, and what it looks like to actually integrate them.
SaMD is different on every dimension from hardware. Requirements are not locked at first release because complex logical systems reveal gaps that physical prototypes do not. Users are a constant source of change pressure. Cybersecurity vulnerabilities emerge mid-product-lifecycle. Design transfer for a software-only device is the deployment pipeline, not a factory floor. Post-market changes are continuous.
The result is that roughly 85 to 90 percent of quality assurance work in a SaMD QMS concentrates in design assurance and change control. Every sprint, every pull request, every release candidate runs through this channel. A hardware-oriented QMS treats these as discrete events. A SaMD team treats them as the steady state.
When design changes are the primary operational surface, the tools used for development must fit inside the quality system, not run alongside it. This is the core premise behind application lifecycle management (ALM) for design controls, and it explains why agile development in regulated environments requires a different QMS architecture than the one most hardware-oriented guidance assumes.
Most SaMD teams run two separate systems without realizing it was a design decision.
The system of entry is where work actually happens. Product managers write requirements in Jira, engineers review and merge pull requests in GitHub, test teams file and track bugs in Jira, and deployment logs live in Jenkins or a similar continuous integration/continuous deployment (CI/CD) orchestrator. These tools are chosen for CI/CD workflow support, not compliance. Their owners are engineering, product, and test teams. Their audience is internal.
The system of record is where quality records live. It handles Part 11-compliant electronic signatures, computer system assurance (CSA, the modern validation approach for quality software tools), and the structured documentation an auditor or notified body reviewer expects to see. Quality owns it, external reviewers consume it, and an electronic quality management system (eQMS) is the canonical example.
When these systems are fully separate and unconnected, something predictable follows. Work gets done in Jira. Quality needs a record of that work. Since Jira content is written for engineers rather than auditors, it does not map cleanly to a design input or change control record. Someone on the quality team manually rewrites it and puts a version in the eQMS. Now there are two sources of what should be the same information. Jira moves first, the eQMS version falls behind, and when audit time arrives the scramble begins.
The most common state SaMD teams are in is entirely structural. The fix is not a process. It is changing what level of integration exists between the two systems.
The gap between parallel disconnected systems and a unified workflow is not binary. There are six levels of integration, from minus one through four, describing how tightly a team's development tools and eQMS are connected.
Level minus one is where content in the system of entry cannot be presented to an auditor without substantial rewriting. The quality team manually rewrites everything before it enters the eQMS, and the two systems contain different versions of the same facts.
Level zero is the same structural setup, but the team has been trained to generate quality-ready content in their development tools. Product managers write requirements that match design input guidelines. Quality can copy-paste rather than rewrite. The operational gap is still large, but at least there is no translation problem layered on top of the integration problem.
Level one means the system of entry is used as a partial system of record for specific document types. A tool qualifies when it has Part 11-compliant electronic record retention: audit logs with timestamps showing who changed what and when, even if it lacks Part 11-compliant electronic signatures. CSA vs CSV covers the compliance distinction in more depth, but for practical purposes, audit logs qualify a tool for electronic record retention while electronic signature workflows are a separate bar. Jenkins generating unit test reports referenced by the eQMS rather than re-entered is a working example. The record lives in Jenkins with content controls and audit logs, the approval happens in the eQMS, and the eQMS references the unique identifier Jenkins produces.
Level two is a one-way sync. The system of entry pushes data into the eQMS, so Jira tickets flow into a change control record and deployment logs flow into a design transfer record. Half the manual work disappears. The remaining friction is directionality: changes made in the eQMS do not propagate back, which creates a governance gap if someone edits the record directly.
Level three is a two-way sync. Changes in either system propagate to the other. This is the most practical high-integration state most SaMD teams can actually reach, and an increasing number of eQMS platforms have built Jira integrations with this bidirectional behavior.
Level four is no integration at all, because the system of entry and system of record are the same tool. Developers work in a system that is itself Part 11-compliant, CSA-documented, and capable of serving as the quality record without any export or sync step. For any CI/CD task, this is the ideal end state. It is also rare because most tool stacks cannot simultaneously satisfy CI/CD workflow requirements and full compliance requirements.
The right goal is not to reach level four everywhere. The goal is to apply this analysis task by task across the full CI/CD pipeline and ask: can I move this up a level?
Three integration patterns appear in nearly every SaMD development environment.
Code review records. Engineers do code reviews as part of the pull request process in GitHub. Those PR records contain exactly what a code review record in a design history file (DHF) needs: who reviewed, what changed, what was approved, and when. Instead of the quality team writing a separate code review report, the PR record from GitHub is synced into the eQMS as the code review document. Quality approves the record rather than creating it.
Unresolved anomalies reports. IEC 62304 requires tracking known anomalies at release. Test teams already track bugs in Jira. A two-way sync between Jira and the eQMS means the unresolved anomalies list in the quality record stays current automatically, with one source of truth and no manual export-and-format step before each submission.
Jira and change control. The key configuration step is distinguishing change requests from work orders in Jira. Most teams use tickets for both, but conflating them breaks the integration. A change request has quality significance and needs to route through the change control workflow. A work order is an engineering task like "edit line ten in component X" and does not. Once Jira is structured with a ticket type corresponding specifically to change requests, the Jira-to-eQMS integration can pull those tickets directly into the change control workflow, and quality approves rather than transcribes.
The agile manifesto was written for general software development and, read literally, contradicts several medical device quality management requirements. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Responding to change over following a plan. No quality team can operate on those terms.
But the ethos behind the agile manifesto, focus on intent over process, is worth translating for SaMD teams. Here is what that translation looks like in practice.
Quality over proceduralism. The intent of the procedure should drive behavior, not the existence of the procedure. When people understand why requirements are written, how they connect to testing, and what role they play in the overall quality system, requirements become useful. When they write requirements because the procedure says so, requirements become checkboxes.
Culture over mandate. A team that understands what is acceptable and unacceptable from a quality, safety, and effectiveness standpoint does not need a procedure for each decision. Training should deliver this understanding, not just procedure exposure.
Redundancy over duplication. Having the intended use statement in five documents is duplication, and those five versions will eventually diverge. That is a maintenance problem, not a quality one. Redundancy means multiple people or processes independently checking the same output, which lowers the probability of defects reaching patients, a quality property worth designing for deliberately.
Conciseness over verbosity. Procedures and documents should contain only what is necessary. The cost of verbosity is attention. A 50-page procedure where the relevant section is paragraph three trains people to skim. Documents that earn every word are the ones people actually read.
If a device genuinely improves patient outcomes, an unnecessary delay in bringing it to market is a form of delayed treatment, and medical device risk analysis already recognizes delayed treatment as a harm. A quality system designed to move slower than necessary contributes to that harm.
The practical implication is that operational efficiency is a patient safety argument. Building a SaMD QMS that operates at the speed software development actually requires, rather than at the speed hardware development historically required, is a design decision worth making deliberately.
Map your full CI/CD pipeline from user needs definition through deployment. For each task, identify the system of entry and the system of record, then assess the integration level using the minus-one-through-four scale. Rank the gaps by operational pain and ask, for each one, whether you can move it up a level. For a deeper walkthrough of this framework in action, including a live Q&A on configuring Jira for change control and building end-to-end traceability, watch the on-demand session from Greenlight Guru's How Modern Software Teams Develop Compliant Devices Virtual Summit.
Integration methods include out-of-the-box connections between the eQMS and tools like Jira, add-ons from the Atlassian marketplace for requirements and test management, custom API integrations if the eQMS supports them, and third-party automation tools for lighter connectors.
Greenlight Guru's Ultralight eQMS includes native Jira and GitHub integrations built for this context. If your team is already running IEC 62304-structured software development, the path from your existing dev stack into a compliant quality record is shorter than it usually looks. The same analysis applies whether you are building SaMD or software in a medical device (SiMD); the integration level framework works across the full spectrum of medtech software development.
Start with the two or three highest-friction points in your current workflow and move each one up a level.