From Jira to Submission: How CertHub Connects Jira to MedTech Technical Documentation
CertHub's Jira integration syncs developer requirements directly into MDR, IVDR, and IEC 62304 technical documentation, closing the gap between engineering and regulatory teams without manual copy-paste.
CertHub's Jira integration pulls developer requirements from Jira straight into your MDR, IVDR, and IEC 62304 technical documentation. No more copy-paste between engineering and regulatory.
TL;DR
- What it does. CertHub connects to Jira and imports the requirements you pick as structured entries in the regulatory data model. From there, any submission template can pull them in.
- Who it's for. MedTech manufacturers, especially SaMD teams and companies with multiple products across multiple countries, whose requirements live in Jira but whose technical documentation has to meet EU MDR, EU IVDR, FDA 510(k), IEC 62304, and ISO 13485.
- What you save. CertHub cuts the time to process a regulatory or product change from around 12 hours down to 2 hours. That's roughly 300 hours saved per year per jurisdiction (assumptions: 6 changes/year, about 5 affected technical documents per change, 100 €/h loaded cost).
- Where the data lives. 100% in EU data centres (Frankfurt). GDPR-compliant, ISO 27001-certified, ISO 80002-2-validated, TLS 1.2+ encrypted, role-based access via Open Policy Agent.
- Time to operate. Eight weeks from kick-off to full operation.
What is the dev-to-regulatory gap?
The dev-to-regulatory gap is the split between where product requirements get created (in Jira, by development teams) and where they have to be documented for regulatory submission (Word templates, Excel traceability matrices, legacy eQMS). In most MedTech companies, requirements live in both places. Teams reconcile them by hand, and they drift out of sync all the time. That gap is a leading cause of audit findings, late-discovered inconsistencies, and delayed market entry.
A single Class IIb medical device usually needs hundreds of interconnected documents across the quality management system, technical documentation, and labelling. When the source of truth for requirements sits in Jira but the technical file is kept by hand, those documents drift further apart with every sprint.
What does CertHub's Jira integration do?
CertHub's Jira integration imports the Jira issues you select into CertHub's regulatory data model as structured requirements. Once they're in, any submission template can reference them: technical documentation, clinical evaluation, instructions for use, labelling. You can refresh them whenever you need. Engineering keeps working in Jira. Regulatory reads from the same source, without transcribing anything.
CertHub is a Regulatory Information Management System (RIMS) developed in Germany for MedTech manufacturers. Jira is a widely used issue-tracking and requirements-management tool from Atlassian, typical in software and hybrid medical-device development.
Why does the dev-to-regulatory gap cost MedTech teams so much?
Every time a requirement changes in Jira, someone on the regulatory side has to spot it, interpret it, and push the change through to all the downstream documents by hand. For a typical MedTech customer, the cost looks like this (manual vs. CertHub, per change):
| Step | Manual | With CertHub |
|---|---|---|
| Impact assessment | 2 hours | 1-click (automated) |
| Update documents (clinical evaluation, IFU, label) | 4 hours | 0.5 hours |
| Review and sign-off | 2 hours | 0.5 hours |
| Technical documentation revision | 2 hours | 1-click (automated) |
| Conformity re-assessment | 3 hours | 1 hour |
| Typical total per change | ~12 hours | ~2 hours |
Row values are the time each step takes on its own. The manual total rounds to about 12 hours, since review and documentation work tend to overlap in practice.
Each change usually affects about five technical documents. With six changes per year, that works out to roughly 12 h × 5 docs × 6 changes = 360 hours of manual work. With CertHub, that drops to 60 hours, and that's for a single jurisdiction. At a loaded cost of 100 €/h, the difference is about 30,000 € per year.
The gap also produces three structural failure modes.
- Errors and redundancies. The same data ends up duplicated across multiple files with no link between them. Two people update two versions, and neither knows the other one exists.
- Lost traceability. EU MDR Annex II requires full traceability from intended purpose through risk analysis to clinical evidence. Manual cross-referencing can't guarantee that chain at portfolio scale.
- Late discovery. Inconsistencies stay hidden until the Notified Body finds them. That's the most expensive moment to find anything.
How does CertHub solve this? Maintain data, not documents.
CertHub's Regulatory Information Management System is built on a simple flip: teams maintain a regulatory data model, not individual documents. The data model is one structured picture of the product. It includes:
- Device description, intended purpose, user population, risk profile
- Requirements and test evidence
- Content aligned to ISO 14971 (risk management), IEC 62366 (usability), IEC 62304 (software lifecycle)
- Design controls, QMS processes, clinical evaluation
Documents become an output of the data model, not the place where data gets entered. Change the intended purpose once, and every affected document across every product variant and every jurisdiction updates automatically.
For this to work, the data model has to be fed by the systems your team already uses. Jira is the first and most common one.
How does the Jira integration work? (4 steps)
Step 1. Connect Jira to CertHub
A regulatory or quality user authorises CertHub to read from Jira through a standard permission flow. You set the connection up once per workspace, and every future sync reuses it.
Step 2. Pick the Jira project
CertHub shows you the Jira projects you have access to. You pick the project that holds the product's requirements. That's usually the project development uses to track everything in scope for a release.
Step 3. Select the issues that belong in the technical file
CertHub shows the issues in the project you picked. You keep the requirements and filter out test cases, spikes, and internal engineering tickets. What's left is the set of Jira issues that actually belong in the regulatory documentation.
Step 4. Import into the regulatory data model
The requirements you selected land in CertHub's requirements section as structured entries. They're not a frozen snapshot. They're live references. You can query them, cross-link them, and pull them into submission templates. Run the sync again later, and the data model lines back up with the current state in Jira.
How does this improve MDR Annex II traceability?
EU MDR Annex II requires a documented chain of evidence from intended purpose through risk analysis to design verification to clinical evidence. Every link has to sit on data that's current, consistent, and defensible in front of a Notified Body.
When requirements come from Jira via a live sync, three things become possible that manual copy-paste just can't do reliably.
- Traceability back to the source, not to a snapshot. Auditors see that the requirement in the technical file is pulled from the same Jira record engineering works against. There's no separate "regulatory version" drifting away from the engineering version.
- Impact analysis that catches changes automatically. When a Jira requirement changes, CertHub's AI impact analysis flags every downstream document, product variant, and jurisdiction affected. No one has to spot it and push it through by hand.
- Traceability that holds up as your portfolio grows. A portfolio with three products across three jurisdictions produces nine regulatory contexts. Manual traceability matrices don't scale to that. A single data model, fed by the real source of each data class, does.
For teams working under IEC 62304 for software lifecycle processes, the point is even sharper: software requirements naturally live in Jira, and binding them directly to the regulatory data model is how a modern software lifecycle should work.
Which other systems can CertHub connect to?
Jira is the first integration for most MedTech teams because that's where software requirements usually sit. But it's not the only supported source. CertHub's regulatory data model is built to read from the systems your team already uses:
- Jira: requirements and issues from software and hybrid products.
- Polarion, DOORS, Dassault: application lifecycle and product lifecycle management tools used by hardware teams.
- Word and Excel: existing documentation in familiar formats.
- Legacy eQMS and document management systems: any format, any system.
- PDFs and SharePoint: scans, papers, and exports of historical documentation.
From the same data model, CertHub generates submissions for:
- EU MDR 2017/745
- EU IVDR 2017/746
- EU AI Act
- UK MDR (MHRA)
- FDA 510(k)
- Swissmedic (MedDev Ordinance)
- ANVISA (Brazil)
- Health Canada (CMDR)
- TGA (Australia)
- IMDRF / MDSAP
It also feeds EUDAMED, Swissdamed, and GUDID from the same source.
What does this look like in practice?
Two moments show the integration earning its keep.
When a developer changes a requirement in Jira. In the old flow, nothing happens on the regulatory side until someone notices. The ticket can sit in "Done" for weeks before a quality engineer realises the verification strategy in the technical file no longer matches. With the Jira integration, the change shows up in the regulatory data model on the next sync. CertHub's AI impact analysis flags the affected documents. You scope the needed edits before the next audit cycle, not after it.
When the regulatory team prepares a submission. In the old flow, preparing a technical file means reconciling dozens of Jira tickets against Word documents that were accurate three sprints ago, and building an Excel traceability matrix that's out of date by the time you hit save. With CertHub, the requirements section of the submission template pulls straight from the current data. The traceability chain is generated from the model, not rebuilt by hand.
Who benefits first?
Teams that get the most out of this on day one tend to share three traits:
- They have software content in their devices, like SaMD (Software as a Medical Device) or embedded software in physical products. So their requirements really do live in Jira.
- They have more than one product variant or more than one jurisdiction. Manual propagation costs grow faster than the portfolio. A single source of truth pays off faster too.
- They have a regulatory team tired of chasing engineering for the current requirements list. That's a surprisingly reliable sign a team is ready to work data-first.
For these teams, the integration is less a feature than a policy change: regulatory stops maintaining its own copy of the requirements and starts reading the copy engineering already maintains.
How long does it take to implement?
CertHub's standard onboarding runs from kick-off to full operation in eight weeks.
- Kick-off (weeks 1–2). Review of the current state and requirement assessment (1 week), setup of predefined knowledge units and system access (1 day), and initial setup training with online tutorials (1 week).
- Implementation (weeks 3–6). Configuration and customisation of templates, forms, and SOPs (2 weeks). Data transfer from existing documentation into CertHub (2 weeks, with continuous transfer after Go Live).
- Operation (weeks 7–8 and beyond). Go Live, with iterative feedback sessions that refine the configuration to the team's specific needs.
Four things keep the timeline on track: you bring the data you already have from any system; AI helps structure it into the regulatory data model; single-source-of-truth logic pushes changes everywhere automatically; and worldwide submissions come from one foundation.
Where is the data stored?
All the product and regulatory data CertHub processes is stored in European data centres in Frankfurt. There's no transfer to the United States or any other third country, and no dependency on US infrastructure partners. Compliance posture as of 2026:
- GDPR-compliant
- ISO 27001 certified information security management
- ISO 80002-2 validated process software
- TLS 1.2+ encrypted communication
- Role-based access control via Open Policy Agent (OPA)
- Isolated VPC with no direct internet access to sensitive systems
Frequently asked questions
What does CertHub's Jira integration actually sync? It imports the Jira issues you pick (usually requirements) into CertHub's regulatory data model as structured entries. You can filter out test cases, spikes, and other non-requirement tickets during import.
Does the integration keep data in sync over time? Yes. Once imported, requirements are referenced, not copied, and you can refresh them any time. A refresh lines the regulatory data model back up with the current state in Jira.
Which regulations and standards does this support? The integration feeds into CertHub's regulatory data model, which supports EU MDR 2017/745, EU IVDR 2017/746, FDA 510(k), UK MDR (MHRA), Swissmedic, ANVISA, Health Canada (CMDR), TGA, IMDRF/MDSAP, and the EU AI Act. It's built around ISO 13485, ISO 14971, IEC 62304, IEC 62366, and the MDR Annex II traceability requirements.
Is this suitable for SaMD and IEC 62304 compliance? Yes. Software requirements naturally live in Jira, which makes SaMD teams under IEC 62304 a primary use case. The integration binds Jira requirements directly to the regulatory data model, so software lifecycle traceability holds.
Can CertHub connect to tools other than Jira? Yes. CertHub's data model reads from Polarion, DOORS, Dassault, Word, Excel, legacy eQMS and document management systems, PDFs, and SharePoint. Jira is the most common first integration because that's where software requirements usually sit.
Where is our data stored when we use CertHub? In European data centres in Frankfurt. No transfer to the US or other third countries. CertHub is GDPR-compliant and ISO 27001 certified.
How much time can we expect to save? In CertHub's reference cost model (based on typical MedTech workflows), the effort per regulatory or product change drops from around 12 hours to 2 hours. If you assume six changes per year across roughly five affected technical documents in one jurisdiction, that's about 300 hours saved per year, or around 30,000 € at a 100 €/h loaded cost. Real savings depend on your portfolio and the documents you touch.
How long does it take to become operational? Eight weeks from kick-off to full operation, including configuration, data transfer, and user onboarding.
What happens if we leave CertHub? CertHub supports full off-boarding and data transfer. Your data stays yours.
Getting started
The Jira integration is available to CertHub customers as part of the Regulatory Information Management System. It's the first of several connectors built to tie the tools MedTech teams already use to the one regulatory data model used for submissions worldwide.
Book a demo to see the Jira connection in action.