# Integrations
Source: https://docs.withdovetail.com/assistant/integrations
Learn how to connect built-in integrations and custom MCP servers so the assistant can use them when you need them.
# TL;DR
* Open **User Settings** and go to the **Integrations** section.
* Use **Connect** on a built-in integration card to start its OAuth flow.
* Use **Add Integration** to add a custom MCP server.
* Turn on **Agent Access** only for the connections you want the assistant to use right now.
For the full User Settings walkthrough, including notification email controls, see [User Settings](/organization/user-settings).
Enable integrations and MCP servers only when you need them. Connections with **Agent Access** turned on are the ones the assistant loads for tool use by default. Leaving extra connections enabled can add unnecessary tools and external context, which can bloat an agent's context window and make tool selection noisier.
# Before You Start
Make sure you are working in the correct organization before you connect anything. Integrations and custom MCP servers are managed from **User Settings** inside the current organization.
If you plan to use OAuth, allow your browser to open the authorization popup when prompted.
# Connect a Built-In Integration
The current built-in integrations shown in the app are:
* **GitHub**
* **Linear**
* **Jira**: marked as **Beta**
* **Slack**: currently shown as **Coming Soon**
To connect GitHub, Linear, or Jira:
1. Open **User Settings**.
2. Find the **Integrations** section.
3. On the card you want, click **Connect**.
4. Complete the OAuth flow in the popup window.
5. Return to Formly and confirm the card now shows **Connected**.
After a built-in integration is connected, you can:
* Use **Agent Access** to decide whether the assistant can use it.
* Use **Disconnect** to remove it from your account in that organization.
# Add a Custom MCP Server
Use a custom MCP server when you want the assistant to work with a third-party tool that is exposed over the MCP protocol.
Before you start, make sure you have:
* A full MCP server URL that starts with `https://`
* Either an access token for manual bearer auth, or an OAuth-capable MCP server
To add the server:
1. Open **User Settings**.
2. In **Integrations**, click **Add Integration**.
3. Enter a **Connection Name**.
4. Enter the **MCP Server URL**.
5. Choose your authentication method:
* Enter **Access Token** to connect with manual bearer auth.
* Leave **Access Token** blank to start an OAuth flow.
6. Click **Connect**.
7. If you used OAuth, finish the authorization flow in the popup window.
After the server is added, its card appears in the same integrations list.
# Manage a Connected MCP Server
Custom MCP server cards include a few controls after setup:
* **Test**: checks whether the MCP server is reachable with the saved credentials
* **Disconnect**: removes the saved connection
* **Agent Access**: controls whether the assistant can use that MCP server
You may also see these statuses:
* **Connected**: the server has saved credentials and is ready to use
* **Not Authenticated**: the server record exists, but authentication has not completed successfully
Custom MCP servers require a full HTTPS URL. A bare domain such as `mcp.example.com/mcp` will not work.
# Best Practices
* Keep **Agent Access** disabled for integrations and MCP servers you are not actively using.
* Use clear connection names so it is obvious which workspace, environment, or vendor each MCP server belongs to.
* Test a custom MCP server after connecting it so you can catch URL or authentication problems early.
* Disconnect old or duplicate connections instead of leaving them in place indefinitely.
# FAQ
## Which built-in integrations can I connect today?
GitHub, Linear, and Jira can be connected from **User Settings**. Slack is visible in the UI but currently marked **Coming Soon**.
## When should I enter an access token?
Enter an access token when the MCP server expects manual bearer authentication. If the server supports OAuth instead, leave the token blank and use the popup flow.
## Why was my MCP server URL rejected?
The URL must be a complete `https://` address. The app rejects incomplete or non-HTTPS values.
## Why should I disable unused connections?
Disabled connections stay available in your settings, but the assistant does not load them for normal tool use. That helps keep the assistant focused and avoids adding unnecessary external context.
# Overview
Source: https://docs.withdovetail.com/assistant/overview
The Assistant provides AI-powered help for managing your **post-certification** regulatory requirements.
# Document Updates
The Assistant helps you maintain and update your documentation after device changes or updates. By analyzing your change description, it automatically identifies affected documents that require updates.
The Assistant interface guides you continuously through each document update to make sure all relevant documents are updated in one go.
# Workflow
1. Select the **update type** from the dropdown menu
2. Describe the **changes** made to your device
3. Review the **list of affected documents**
4. Click **Next** to enter the assistant interface
5. Enter the **required information** for each document
6. Review the **final list** of affected documents
7. **Generate** the updated documentation
8. **Submit** for approval from responsible team members
The Assistant helps you update **existing documentation** and identifies when **new documents** or update protocols are required.
# Skills
Source: https://docs.withdovetail.com/assistant/skills
Create reusable assistant instructions and apply them to Formly runs.
Skills are reusable instructions that tell the Formly assistant how you want it to work. Use them for repeat workflows, review styles, regulatory decision trees, reusable checklists, or output formats that you want the assistant to apply across future runs.
Editing a skill updates the saved version. Duplicate a shared skill first if you want a personal copy.
## Open Skills
Open **Tools > Skills** from the Formly app navigation. The Skills page has a searchable, filterable list on the left and the selected skill detail or form on the right.
Use the toolbar to:
* search by skill name or description
* filter by visibility
* create a new skill
* upload a markdown file
Selecting a skill opens its details, including its description, instructions, author, last update, visibility, and enabled setting. If a form is open while a saved skill is selected, Formly asks before discarding unsaved form changes when you start another context-changing action.
## Create a skill
Click **New skill** and choose **Create skill**. The form opens in the right panel.
Required fields:
* **Name** - a short, recognizable name using lowercase letters, numbers, and single hyphens, up to 64 characters, for example `reviewer-voice`.
* **Description** - what the skill does and when the assistant should use it.
* **Visibility** - who can access the skill.
* **Content** - markdown instructions for the assistant.
The content field should describe the future behavior you want. For example, tell the assistant what to check, what tone to use, what evidence to cite, or what format to return.
Use **Draft in Agent** from a skill form when you want the assistant to help write or revise the skill. The assistant opens an editable draft card with the proposed name, description, visibility, and markdown content. Review the card and click **Apply** to create, edit, or duplicate the skill.
## Visibility
Choose the narrowest visibility that fits the skill:
* **Private** - only you can see and use it.
* **Organization** - members of your organization can see and use it.
* **Global** - a set of skills that Formly curates.
You can edit skills you created. If you cannot edit a shared skill, duplicate it to create your own version.
## Skill settings
Skills have separate run settings:
**Enabled** controls whether a visible skill is active for your runs and appears in skill pickers. Turning Enabled off only changes your own preference; it does not affect other users. Disabled skills remain visible on the Skills page so you can enable them again.
## Create from chat
In an assistant thread, open the Skills menu and choose **Create skill from chat**. Formly fills the chat input with a reusable-skill request for the current conversation. Review or edit the prompt, then send it.
The assistant uses the current thread context to draft the skill, then adds an editable draft card to the thread.
Review the generated fields before applying:
* Name
* Description
* Visibility
* Markdown content
Edit the card if you want to change the name, instructions, or visibility. Clicking **Apply** saves the draft as a skill. If you ask for more changes instead of applying the card, the assistant keeps drafting and waits for confirmation before saving.
## Upload and download
Skills can be imported and exported as `.md` files.
When uploading markdown:
* the skill name is prefilled from the filename
* optional frontmatter can prefill `name`, `description`, and `visibility`
* frontmatter is stripped from the saved content, and the remaining markdown body becomes the skill content
* the description is extracted from the first non-heading paragraph when possible
Review the imported fields before saving. Invalid or unavailable visibility values fall back to the normal form and permission rules. On the Skills page, use **Download .md** from a selected skill to export it.
## Edit, duplicate, and delete
Use **Edit** to update a skill you can modify. Edits update the saved skill directly.
If you cannot edit a shared skill, use **Duplicate**. Duplicating creates an editable copy with the content prefilled. The copy defaults to private visibility unless you choose another available visibility.
Only the creator can delete a skill. Deleting removes it from everyone who can access it and prevents it from loading in future runs.
## Apply skills in chat
To apply a skill only for a specific run:
1. Open the Skills menu in the chat composer.
2. Choose **Attach skill to run**.
3. Search for a skill and select it.
4. Send your prompt.
Attached skills appear as removable chips near the chat input. When the run starts, the assistant reads and applies the selected skill instructions for that response.
## MCP support
The Formly MCP server supports listing, reading, creating, editing, duplicating, deleting, and importing skills from markdown. External MCP clients can also include selected skills when starting a Formly agent run.
When an external MCP assistant changes a skill, it should show the proposed change first, then save only after you approve it or after you have already given a clear save instruction.
# App
Source: https://docs.withdovetail.com/changelog/release-notes-webapp
Follow along with the latest updates and improvements to Dovetail.
**A new era of document collaboration**
Our collaboration suite has been rebuilt around a faster, more reliable editor. Teams can now work together in real time, review proposed edits clearly, and build reusable documents that adapt to their context.
## Work together in real time
Multiple people can now work in the same document in real time, with every edit kept in sync as it happens.
## Review with confidence
Suggested changes give reviewers a clear way to propose edits without overwriting the original content. A complete audit trail records every document edit, so you can see what changed and who made the change.
## Build smarter, reusable documents
Dynamic variables let you insert answers, device details, and organization context anywhere in a document. Conditional content can then show or hide sections based on that context, making it easier to reuse one document or template across devices and workspaces.
## Bring the agent into the review process
The agent can now make suggested changes directly in any document. It can also read comment threads, create new comments, and reply to your team, so collaboration and document updates can stay in one workflow.
**Document Explorer, rebuilt for faster document work**
![Document Explorer preview icon]()
**Document Explorer**
We revamped Document Explorer because regulated teams do not just store documents in Formly. They need to scan what exists, understand where each record belongs, see what needs attention, and reorganize files without losing context. The new experience turns document management into a focused workspace instead of a narrow navigation panel.
*Better navigation and more context*
Documents now live in a dedicated table view with breadcrumbs, folder context, scope, status, revision, type, owner, dates, and routing details visible together. This makes it easier to move from a high-level folder structure into the exact record you need, while keeping device and organization context clear.
**Training for controlled documents**
![Training program matrix]()
**Training programs**
Training is now part of Formly. Create training programs from controlled documents, assign them to functional groups or individual users, and give trainees a clear deadline for completing their work.
The new training matrix shows which functional groups are assigned to each document-based program, while the detail view keeps the current training pool, revision history, and completion status together. Teams can switch between their own training tasks and the organization-wide view, depending on their permissions.
[Read more about training programs →](https://docs.withdovetail.com/eqms/training-programs)
**Reusable skills for consistent agent work**
Skills let your team save repeatable instructions for how Formly should work, such as review rules, report formats, or company-specific workflows. You can create them in the Skills workspace, upload an existing markdown skill, or ask the agent to draft one from a chat.
Attach a skill to a conversation when that run needs extra guidance, or keep trusted skills enabled so the agent can apply them when relevant. This reduces repeated prompting and helps teams get more consistent results from the same regulated process.
**A new dashboard for your team**
![New organization dashboard]()
**New dashboard**
The new organization dashboard gives your team one place to see organization and device work at a glance. It brings overall roadmap progress, documents currently routing, urgent due-soon work, open tasks, recent team activity, and unresolved comments into a single device-aware view.
**Focused views**
Use dashboard filters to narrow each card to the work that matters right now, while the page keeps counts and rows responsive as you move between organization-wide and device-specific context.
* Improved agent performance so assistant workflows respond faster
We have been busy fixing small issues and cleaning up the app.
**Functional groups and streamlined navigation**
**Improved traceability**
![Improved traceability]()
Improved the usability and presentation of the traceability feature. It also moved to the top level navigation on the left sidebar.
**Functional groups**
![Adding users to a functional group]()
Organizations now come seeded with the usual defaults (QA, Software, Regulatory, and more) and you can create, rename, and delete your own groups from the organization settings. Add users to one or many groups so documents carry the right ownership context.
**Streamlined navigation**
![New menu for organization and user settings]()
Organization and user settings now live in a cleaner single menu so it is quicker to jump between workspaces and manage your account.
* Replaced the hardcoded functional group list with a real org-scoped entity so groups can be renamed and extended per organization
* Sorted organizations in the switch workspace menu
* Fixed workspace menu stacking over the revision dropdown
* Fixed terminal tooltip offset in the collapsed menu
**A new place for all your documents**
![Old to new document workspace]()
**Document workspace**
All documents across all devices now live in a dedicated space in the left menu with a full folder tree for both organization-level and device-specific content. You can create, rename, and delete folders by right-clicking on them, drag and drop folders and documents to reorganize the structure, and use native-feeling range multi-select to manage several items at once.
**Search and document actions**
![New search and document actions]()
The new documents area also brings org-wide search and faster document actions into one place. You can create or upload documents from the documents menu and search across the full document set with filters for scope, status, functional group, document type, approvers, authors, and outstanding actions.
**Device-aware workflows**
Device context is now easier to control across the app. Switch the active device directly from the roadmap and the agent chat. The updated document navigation makes it clearer whether a document belongs to a device or is managed at the organization level.
* Extended global device switching into roadmap and agent flows for faster context changes
We have been busy fixing small issues and cleaning up the app.
**Custom data key references in the raw editor**
**Custom data key references**
You can now insert custom data key references directly in the document editor by typing `@` and choosing a data key. References render inline inside the document. Click the edit icon to adjust a value right inside the document and it gets updated automatically wherever it is used.
* Document editor usability
We have been busy fixing small issues and cleaning up the app.
**Stronger document control and traceability**
**Traceability (beta)**
We added a branching traceability graph with broken-link visibility so you can follow relationships more easily and spot gaps before they turn into release issues.
![Traceability]()
**Document workflows**
Signature tables now work in both custom documents and uploaded files. You can also edit custom document metadata, create linked documents directly from task detail, filter the explorer down to documents with unresolved comments, and reliably copy document content from the top bar.
**Collaboration and approvals**
Commenting and approval flows are more robust. Previously commented text can now be reselected correctly, teammates can resolve comments regardless of who created them.
You can also now filter the explorer down to documents with unresolved comments. Click the more options icon on the explorer to see the filter.
![Comments]()
**Assistant and organization updates**
The assistant now defaults to GPT-5.4, MCP integrations got a more complete setup experience, selected context chip titles stay readable.
Organizations can now store a company description that the agent can use as context. Go to the organization settings to add or edit the description.
* Prevented users from deleting themselves from the organization users table
* Required onboarding name fields before advancing
* Added `isCanada` support alongside the existing `isUK` device behavior
* Improved answer-item save flow so Next and Generate do not skip unsaved edits
* Fixed ordered-list numbering after nested sublists in the raw editor
* Fixed custom upload flows where RCD options did not behave correctly with user uploads
* Fixed missing `isUK` handling in affected device import paths
* Fixed a blank approval popup and improved approval panel behavior
* Fixed oversized device-label images in custom document rendering
* Included dependency, security, and build reliability cleanup across the app
**Better collaboration and integrations**
**Comments**
We now have comments for documents in the eQMS. Mark any text to add a comment. Tag your collaborators to get their attention and iterate on documents together. Coming soon: Tag formly to get support by the agent to help you resolve questions or use it to adjust documents considering comments from your collaborators.
**Tasks**
We have added a new Tasks feature to the app. Tasks are a way to track the progress of your work and collaborate with your team. You can now assign document creation tasks to yourself or others and track their progress. You can also add deadlines to make sure your tasks are completed on time.
**Integrations**
![Integrations]()
We have added a new Integrations feature to the app. You can now connect your Linear account to the app and use the agent to help you resolve questions or use it to adjust documents considering comments from your collaborators. To connect an integration head to User Settings -> Integrations.
* Right click actions to add and remove columns and rows in the table editor
* Added a changelog modal to the app
We have been busy fixing small issues and cleaning up the app.
# Overview
Source: https://docs.withdovetail.com/dashboard/overview
Use the Dashboard to track progress, approvals, upcoming work, recent activity, and unresolved comments across your organization or a selected device.
## What the Dashboard is
The Dashboard gives you one place to monitor the work moving across your organization. You can use it to check overall progress, see what is on your plate, spot documents waiting for approval, review urgent work, catch up on recent activity, and clear unresolved comment threads without jumping between multiple pages.
![Dashboard overview with the device selector, overall progress heading, and dashboard cards visible.]()
## Open the Dashboard
Open **Dashboard** from the left sidebar. The page opens with an overall progress summary, then shows the current dashboard cards below it.
If your dashboard is mostly empty, create a device first with the [Create a Device guide](../getting-started/create-a-device).
## Change dashboard scope by device
Use the device selector in the page breadcrumb to switch between **All Devices** and a single device. Choose **All Devices** when you want a broad organization view, or choose one device when you want to focus on the work for that product.
When you open the Dashboard without choosing a scope, Formly keeps your active device context when one is already selected. If there is no active device, the Dashboard starts from your latest device.
Changing the device scope updates every card on the page. If you apply filters while looking at one scope, they stay tied to that card and that scope, so your all-device view and your device-specific view can stay focused in different ways.
## Current dashboard cards
The Dashboard currently shows an overall progress heading followed by five cards:
1. **Overall Progress** shows how much of your roadmap is being worked on, how many assigned tasks and unresolved comments need your attention, and how much of the roadmap is in draft, routing, live, or remaining.
2. **Documents Currently Routing** shows documents that are moving through the approval process so you can see what is waiting on review. Learn more about approvals in [Approvals](../eqms/approvals).
3. **Outdated / Due Soon** highlights work with overdue or upcoming due dates so you can triage the most urgent items first.
4. **Open Tasks** shows active work that still needs attention and links you back to the related [tasks](../roadmap/tasks) and documents.
5. **Activity in the Last 7 Days** groups recently completed tasks, fully approved documents, and recently resolved comments into one recent-activity view.
6. **Unresolved Comments** shows documents that still have open comment threads so you can jump back into review conversations quickly.
Many rows in these cards take you straight to the related document or supporting record, which makes the Dashboard a fast starting point before you continue deeper in the [Document Explorer](../eqms/explorer).
## Filter cards
Most list-style cards include a filter button in the card header. Use it to narrow the rows in that card without changing the rest of the dashboard.
![Open Tasks card with the dashboard filter menu expanded.]()
Filters apply to the card you opened and the scope you are currently viewing. Depending on the card, you can filter by due date, task status, assignee, document status, author, approver, or recent comment activity. Use **Reset Filters** to return the card to its default view.
## Review comments from the Dashboard
Use the **Unresolved Comments** card to find documents that still need discussion or a final decision. Select the comment button on a row to open a thread preview directly from the dashboard.
![Unresolved comments card with the thread preview popover open.]()
From the preview, you can read the conversation, reply, resolve a thread, or open the full document to continue the review in context. This is a quick way to clear comment backlog without manually searching through folders in the [Document Explorer](../eqms/explorer).
## Best practices
* Start with **All Devices** for a broad triage pass, then switch to one device when you want a focused working view.
* Check **Documents Currently Routing** before review meetings so you know which approvals are still waiting.
* Use **Outdated / Due Soon** and **Open Tasks** together to separate urgent work from the rest of your backlog.
* Review **Activity in the Last 7 Days** after a review cycle or release so you can quickly confirm what changed recently.
* Clear **Unresolved Comments** regularly so review conversations do not block document progress.
# Approvals
Source: https://docs.withdovetail.com/eqms/approvals
Understand the document approval process to secure compliance with all regulations.
## What are approvals?
Document Approval is the formal process of reviewing and signing off on documents within the eQMS. This ensures that documents like Standard Operating Procedures (SOPs), plans, or reports found in the Document Explorer are accurate, complete, and meet the required standards before they become official or "live".
Think of it as a quality checkpoint for your important documentation managed within the eQMS.
## Why are approvals required?
For medical devices, regulations like ISO 13485 require strict control over documents and records. The approval process is critical because it:
* **Ensures Accuracy:** Experts review documents for correctness.
* **Demonstrates Control:** It shows regulators that you have formal processes for managing your documentation.
* **Maintains Traceability:** It creates a record of who approved what and when, which is essential for audits.
* **Prevents Unauthorized Changes:** Only approved documents are considered official.
Proper document control and approval are fundamental pillars of a compliant Quality Management System.
## Understanding the document lifecycle
Each time a document is changed and approved, a new revision is created (e.g., Revision 1, Revision 2) and stored in the eQMS. All document versions are managed within the eQMS and have the following statuses:
* **Draft:** The document is a draft and has not been reviewed or approved.
* **In Review:** The document is currently being reviewed by the approvers.
* **Live:** The document has been reviewed and approved by the approvers.
* **Archived:** The document has been archived because a new revision has been approved and is now Live. Archived documents are kept for historical records and audit purposes but are no longer the primary version shown in the explorer.
## Approval History
The **eQMS** keeps track of all revisions, approvers, approval dates, and the revision summaries you provided.
This history is viewable by clicking on the **"Approval"** button in the top right corner or by scrolling down to the **revision history** section at the bottom of the document.
## How to approve documents
When a document is ready for review and approval, follow these steps:
1. **Navigate to the Document:** Locate and open the document you need approved using the eQMS Document Explorer or jump directly to the document through your **Todos**.
2. **Initiate Approval:** Click the "Approval" button, usually located in the top right corner of the document viewer. This will open the Approval modal.
3. **Assign Approvers:** Select the required individuals from the dropdown lists (e.g., "Select Approver #1", "Select Approver #2"). You might also have the option to invite other users if needed.
4. **Write the Revision Summary:** This is a critical step! Provide a clear description of the changes made in this revision.
* **For the very first version:** Simply state "Initial release."
* **For subsequent revisions:** Detail *exactly* what was changed (e.g., "Updated section 4.2 to reflect new testing procedure", "Corrected typographical errors in Introduction", "Added Appendix C with validation results"). This creates an essential audit trail visible within the document's history in the eQMS.
5. **Submit for Approval:** Click the "Submit" button. The assigned approvers will be notified via email to review and approve the document.
# Edit
Source: https://docs.withdovetail.com/eqms/edit-document
Learn how to edit documents in FormlyAI's eQMS using the wizard or raw edit.
## Edit Document
To edit the document in the **wizard**, select an unapproved document and click the **pencil icon** in the top right corner.
This will create a **new draft** version of the document and open the wizard where you can edit the document with the help of the FormlyAI assistant.
## Edit Raw Document
If you want to edit the draft version of the document, you can do so by clicking on the three dots next to the "Approval" button and select **"Edit raw document"**.
This will change the document into its raw markdown format and allows you to edit the document directly in the explorer.
![Delete Draft]()
As any changes you make here will be **deleted** as soon as you edit the document in the **wizard** again, this is only intended to make small finishing touches before submitting the document for approval.
## Delete Draft
To delete the currrent draft click **"Delete draft"** right below "Edit raw document".
This will delete the draft version of the document and you will no longer be able to edit it.
You can only delete documents with the **Unapproved** status. If the document is still being drafted in the wizard, you would have to finish generating the document to delete it.
## Reset Draft
For automatically generated documents that don't require user input, you can
click **"Reset draft"** in the top right corner to revert any changes made in the **raw** document view back.
# Explorer
Source: https://docs.withdovetail.com/eqms/explorer
Navigate your medical device documentation with the Explorer.
Inside the eQMS, the **Document Explorer** provides a structured view of all your documents, typically organized into folders (e.g., Corporate, Product, Quality Management, Software, Technical). This allows you to:
* **Browse:** Easily navigate through the folder structure to find specific documents.
* **Upload:** Upload new external documents to the eQMS.
To upload a document click on the three dots next to the magnifying glass icon and click on "Upload Document". The uploaded document will be saved in the folder "Misc."
* **Search:** Use the search bar to quickly locate documents by name or content.
* **View Status:** See the current status of documents (e.g., Draft, In Review, Approved/Live, Archived).
The Document Explorer is where you will find the latest approved ("Live") versions of documents, as well as access their revision history and archived predecessors.
# Export
Source: https://docs.withdovetail.com/eqms/export
Learn how to extract documents from your FormlyAI eQMS for external use.
## Export Text
![Export Text]()
This maintains the **original formatting** of the document including headers, lists, and tables
## Export PDF
To export a document as a **PDF** click on the three dots in the top right corner of the document and select **"Export as PDF"**
![Export as PDF]()
# Overview
Source: https://docs.withdovetail.com/eqms/overview
FormlyAI's electronic Quality Management System (eQMS) for flawless medical device documentation.
The eQMS is a digital system that allows you to **create**, **manage**, and **track** all your quality and regulatory documentation.
It is a comprehensive tool that helps you manage your documentation from start to finish and makes sure you are complying with document control requirements.
A Quality Management System consists of two main elements which are covered in your success criteria:
1. A **document storage system** for tracking document drafting, review, and approval
2. Standard operating procedures (SOPs) that define how you build, test, sell, and monitor your device
The **eQMS** covers the first part of the Quality Management System.
You can access the eQMS by clicking the "eQMS" icon in the left sidebar. Note that you must first select a device in the "Device Library" to see the menu item.
FormlyAI provides a complete, scalable solution that grows with your organization,
offering more robust features than basic solutions while maintaining the ease of use you need
# Records
Source: https://docs.withdovetail.com/eqms/records
Document and manage compliance records for medical device certification in FormlyAI's eQMS.
Records in medical device certification are documented evidence of activities performed, results achieved, or requirements
met - they serve as proof of compliance during audits and regulatory reviews.
Records only have **one** revision per document
To view your **existing records**, go to a document that has multiple records (e.g. "Training Log") and select the drop down menu right above the headline.
To create a new record select the **"New Record"** button in the drop down menu below you list of records.
# Revisions
Source: https://docs.withdovetail.com/eqms/revisions
Document revisions allow you to maintain an audit trail of changes in your documentation.
## Create a New Revision
To create a new revision of the selected document select "New Revision" in the top right corner.
This is button is only visible when viewing the **live version** of the document.
It is not possible to have more than one of the same document with the **draft** or **unapproved** status.
After confirming, a **draft version** of the document will be created and the wizard will open where you can edit the document.
This does **not** affect the live version, which you can still go back to via the revision history.
After generating the new revision, the document will have the **"unapproved"** status and you can select the approvers from your team by clicking the approval button.
Only **after** the revsions final approval the document will be updated to the **"live"** status and the former live version will be archived.
Some revisions may cause a **dependency warning**. This means that the content of the revised document **directly impacts** other documents which should be updated and re-approved.
## View Revision History
To view the **version history** of the selected document click on the drop down menu located right above the headline of the document.
## Revision Summary
The **revision summary** of each approved revision is found by clicking on the **"Approval"** button in the top right corner or by scrolling down to the **revision history** section at the bottom of the document.
## Revision Workflow
The document revision process follows this workflow:
1. **Live Document**: The currently approved version
2. **Draft Creation**: Creating a new draft for editing
3. **Edit Phase**: Making necessary changes to the document
4. **Unapproved**: After generating the new revision, the document will have the **"unapproved"** status
5. **Approval**: Select approvers from your team by clicking the approval button
6. **Live Status**: Only **after** the revision's final approval will the new document be updated to the **"live"** status
7. **Archive**: The former live version will be automatically archived
Use the revision history feature to compare changes between different versions or to refer back to previously approved documentation if needed.
# Training Programs
Source: https://docs.withdovetail.com/eqms/training-programs
Assign document training, manage training pools, and complete training tasks in FormlyAI.
Training Programs let individual documents be trained on by users or functional groups. Training programs will emit Training tasks on each document revision for users to read and sign (in other words: train) on the new updates in a document revision.
You can think of Training Programs as a generators that are assigned to a document that will generate training tasks on certain rules.
## Who can manage training
Users can manage organization-wide training when they have:
* Membership in a functional group with **Can Manage Trainings** enabled.
Training managers can open **All Training Programs**, assign document training, manage trainee pools, send training for document revisions, and delete pending training tasks when needed.
Users without training-management permission see **My Training Programs** only. This view shows training assigned to them directly or through their functional groups.
The default QA functional group can manage trainings. You can enable or disable this permission from **Manage Organization** > **Functional Groups**.
## Assign document training
If you are in a group with **Can Manage Trainings** enabled:
Use **Assign Trainings** from **Training Programs** to assign one or more documents.
1. Open **Training Programs**.
2. Switch to **All Training Programs** if you are not already there.
3. Click **Assign Trainings**.
4. Select the documents people need to train on.
5. Select the functional groups and individual users who should receive the training.
6. Set a time that a training must be completed by, from when its emitted.
7. Save.
If a selected document already has a training program, FormlyAI updates the existing training pool instead of creating a duplicate program. If the document has a live revision, eligible trainees receive a training task immediately.
## Understand the Training Matrix
The Training Programs page shows a matrix of documents and functional groups. Each row is a training program. Each functional group column shows whether that group is assigned to the program.
Use the scope selector to switch between:
* **All Training Programs**: organization-wide training programs and organization-wide completion stats.
* **My Training Programs**: programs assigned to you and completion stats for your own tasks.
Click a training program name to open its detail page.
## Manage a training pool
If you are in a group with **Can Manage Trainings** enabled:
Open a training program to review its document, revisions, training history, and trainee pool.
Adding functional groups or users includes those trainees in future training occurrences. If the program already has a current occurrence, newly covered trainees are added to that occurrence when they do not already have a task.
Removing a functional group or user deletes unsigned pending training tasks only when that trainee is no longer covered by another assigned group or direct assignment. Signed trainings remain as completion evidence.
## Send training for a revision
When a document has a live revision, a training manager can send training from the program detail page. FormlyAI creates one task per eligible trainee and records which document revision each person must review.
Training revision labels are shown as **Revision 1**, **Revision 2**, and so on to match the document revision users see in the eQMS.
## Delete a training program
If you are in a group with **Can Manage Trainings** enabled:
Open the training program and use **Delete** to remove it.
Deleting a training program removes every training task associated with it, including signed training records that previously served as completion evidence. Trainees lose any pending tasks for the program, and the program no longer appears in either training scope.
Deleting a training program is permanent. Completed and signed trainings are deleted along with pending ones. If you only want to stop assigning new training tasks, disable the program instead.
## Complete a training task
Training tasks appear in your Tasks list. Open the task to review the assigned document revision in a read-only viewer.
To complete the task:
1. Review the document.
2. Check **I have read the entire document**.
3. Click **Mark as read**.
4. Click **Sign training**.
5. Enter your 4-digit eCFR PIN.
After signing, the task is complete and the signature is stored with the training record.
## Functional group changes
Functional group membership can affect training automatically:
* Adding a user to a group gives them the group's assigned trainings.
* Removing a user from a group removes unsigned pending training tasks when that group was their only assignment path.
* Signed training records are retained.
FormlyAI asks for confirmation before adding or removing group members because those changes can create or remove pending training tasks.
# MCP Server
Source: https://docs.withdovetail.com/formly-for-ai/mcp-server
Connect external AI assistants to your Dovetail workspace using the Dovetail MCP Server.
The Dovetail MCP Server is currently **experimental**. Available tools and behaviour may change without notice. Use it to explore and give us feedback.
Dovetail exposes a first-party MCP server so you can connect external AI assistants — such as Claude Desktop or Cursor — directly to your Dovetail workspace. Once connected, the assistant can read and edit your devices, documents, and data keys, search FDA standards and 510(k) summaries, run Dovetail's built-in regulatory AI agents on your behalf, and work with reusable Skills.
## What's available
The server exposes tools across four areas:
**Your workspace** — read and write operations on your Dovetail data: list organizations and devices, read and edit data keys and documents, create custom documents, search documents by keyword, and view document templates.
**Regulatory research** — browse and full-text search the built-in standards library, look up FDA 510(k) predicate summaries, and run semantic memory recall over Dovetail's expert knowledge base.
**AI agents** — trigger Dovetail's agents directly: the predicate researcher, the standards & guidances researcher, and the expert reviewer. Use `get_agent_run_result` to poll for results once a run is in progress.
**Skills** — list, read, create, edit, duplicate, delete, and import reusable assistant skills from markdown. Mutating skill tools ask for confirmation, and agent-run tools accept `skill_ids` to prompt-pin specific `/skills/user//SKILL.md` references for a run.
## How to connect
The server is available at:
```
https://mcp.withdovetail.com/mcp
```
It uses OAuth 2.0, so no manual token is required. Your MCP client will redirect you to sign in with your Dovetail account the first time it connects.
The exact setup steps depend on which client you use. In general:
1. Open your MCP client's settings or configuration file.
2. Add a new MCP server with the URL `https://mcp.withdovetail.com/mcp`.
3. Set the transport type to **Streamable HTTP** (or **HTTP** / **SSE**, depending on your client).
4. Save the configuration and restart the client if needed.
5. When prompted, complete the OAuth sign-in with your Dovetail account.
### Clients
Claude Desktop supports remote MCP connectors. Follow Claude's guide to [get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), then use `https://mcp.withdovetail.com/mcp` as the server URL for Dovetail.
On the first tool call, a browser window will open asking you to sign in to Dovetail.
Run:
```bash theme={null}
claude mcp add --transport http Dovetail https://mcp.withdovetail.com/mcp
```
Run:
```bash theme={null}
codex mcp add Dovetail --url https://mcp.withdovetail.com/mcp
```
## Troubleshooting
**OAuth sign-in doesn't complete** — Make sure your browser isn't blocking pop-ups from your MCP client, and that you're signing in with the Dovetail account that has access to the relevant devices.
**Tools don't appear after connecting** — Restart your MCP client and check that the server URL is exactly `https://mcp.withdovetail.com/mcp` with no trailing slash.
**Connection errors** — Confirm your client supports Streamable HTTP or SSE transport. Stdio-only clients are not supported.
# Create Device
Source: https://docs.withdovetail.com/getting-started/create-a-device
Learn how to add your medical device to FormlyAI using AI-powered import or manual setup for regulatory compliance.
After creating an account, you'll be taken to your device library. Here, you can add your medical device and start the documentation process.
You have two ways to add your device:
# Importing Your Device with AI
Enter the URL of a webpage with a detailed description of your medical device.
Our AI will automatically extract relevant information and pre-fill the form for you.
# Filling in Your Device Manually
Manually enter the required information, including:
* **Device Name:** The official name of your device.
* **Device Description:** Provide a comprehensive description. Our AI uses this to help generate documentation, so detail and length is key.
* **Relevant Regulations:** Specify the target markets. Selling in the US requires FDA compliance, while the EU requires compliance with
regulations like MDR or IVDR for CE marking.
If your device processes human samples, it's an In Vitro Diagnostic (IVD) medical device and falls under the EU's IVDR.
## Hardware Components
Examples of hardware components would be a **smart-watch** or a **pacemaker**
If your medical device includes physical components, you'll need to describe each one separately.
Physical components are closed systems which typically combine hardware, firmware, and potentially embedded software.
For multiple components, repeat this process for each part. To evaluate the scope of physical documentation and testing requirements needed,
answer the following questions:
* Is **sterilization** required?
* Does it come into **contact with the human body**?
* Is it **implantable**?
* Does it contain **mechanical parts**?
* Does it contain **electrical parts**?
* Does it contain **firmware**?
* Does it contain **software**?
Each hardware component's characteristics **directly impact** specific regulatory requirements and documentation.
## Standalone Software
If your medical device includes standalone, in-house developed software, you'll need to enter its name and provide a description.
This is only about **standalone software** and not about software that is part of the device.
The presence of AI capabilities will also influence your regulatory classification and documentation requirements under medical device regulations.
You also have the option of adding multiple software components, which could be helpful for independent releases and updates.
## Editing Your Device
To edit your device characteristics after creation, open the **Roadmap** and click the pencil icon right next to the device name. After editing, click the **update** buttom at the bottom of the page to save your changes.
# FAQ
Source: https://docs.withdovetail.com/getting-started/faq
Answers to frequently asked questions about FormlyAI's medical device certification platform, regulatory pathways, and features.
## Platform & Services
***
### What regulatory markets does Formly currently support?
Formly primarily supports the EU (MDR) and FDA markets, with plans to add support for Health Canada and MDSAP by the end of 2025. The platform has specific features for both MDR and IVDR compliance in Europe, along with comprehensive FDA submission preparation tools.
***
### What are the key features of Formly's platform?
Formly offers an AI-embedded regulatory compliance platform with features including:
* Pre-built SOPs and documentation templates customized to device type
* AI-powered risk assessment and technical documentation generation
* Visual roadmap interface based on device classification and target markets
* QMS documentation management with approval workflows
* Document control system with version tracking
* Change management with automated impact analysis
* Training management with document-linked records
* Requirements traceability matrices
* Export capabilities to PDF and editable formats
***
### How does the AI-assisted document generation work?
Formly uses multiple AI models for different tasks: GPT for language crafting and general content, Anthropic for technical documentation and requirements, and Gemini Pro for scientific content and web-integrated research. The system focuses on small, precise AI tasks to maintain accuracy, with a target accuracy of 90-95%. All AI suggestions require human review and verification before finalization.
***
### How does Formly handle data security and GDPR compliance?
Formly is fully GDPR-compliant with servers based in France (EU). The platform implements data processing agreements for confidentiality, and no client data is used for AI training. The system encrypts device-specific data and maintains strict separation between different companies' information, ensuring no data sharing occurs between clients.
***
### Can Formly integrate with existing tools like Jira or Confluence?
Formly is developing integration capabilities with Jira, Confluence, and GitHub. Currently, the platform offers manual options for working with external systems, including document export/import capabilities, reference to external documents within the system, and custom document IDs for cross-referencing. Direct export functionality to Confluence for approved documentation is in development.
## Regulatory Process
***
### How long does the certification process typically take when using Formly?
Timelines vary by device classification and market, but Formly generally helps companies get to market 10x faster than traditional approaches. For Class I devices, the documentation can typically be completed in 6-8 weeks with dedicated focus, with some teams completing it in 4-6 weeks. For higher-class devices, the total certification process (including regulatory review) ranges from 9-12 months.
***
### Does Formly help with specific regulatory pathways like De Novo or 510(k)?
Yes, Formly supports various regulatory pathways including 510(k) submissions with a built-in 510(k) builder that includes XML export functionality. The platform also helps with De Novo pathway submissions by creating appropriate documentation and guiding users through the process. For complex submissions, the Premium and Virtual CRO service tiers provide expert guidance on selecting and navigating the most appropriate regulatory pathway.
***
### How does Formly handle documentation updates and change management after certification?
Formly includes a comprehensive change management system that tracks document dependencies and provides AI-assisted impact analysis when changes are made. The system can automatically update related documents based on changes, generate change reports, and manage the review and approval workflow. Post-certification options include continued software access for ongoing compliance management or a more affordable "hibernate mode" for basic maintenance.
## Implementation & Support
***
### What level of regulatory expertise is required from our team?
Formly is designed to work for teams with varying levels of regulatory experience. The platform guides users through the compliance process with AI assistance, making it accessible to those without deep regulatory expertise. For teams needing additional support, the Premium service tier includes expert consulting, and the full-service Virtual Chief Regulatory Officer option provides complete documentation creation and regulatory decision-making support.
***
### What support options are available during the certification process?
Formly offers multiple support tiers:
1. Basic Plan: Self-managed software access with technical assistance for basic questions
2. Premium Plan: Adds 4 hours of monthly consulting, direct expert chat access via Discord, and 24/7 support with \~1 day response time
3. Virtual CRO Service: Full regulatory team replacement with hands-on system setup and complete documentation creation
All plans include unlimited user seats, with pricing based on device classification rather than user count.
## Company & Experience
***
### How many clients does Formly currently serve and what's your success rate?
As of mid-2025, Formly serves approximately 30 clients, with 7 having achieved certification in Europe and 5 actively pursuing FDA submission. The company has experience with various device types, including software as medical device (SaMD), IVDs, and hardware products. The team behind Formly has previously completed 35 conformity assessments prior to launching the platform.
***
# Introduction
Source: https://docs.withdovetail.com/getting-started/introduction
Dovetail is the all-in-one platform for medical device certification, regulatory compliance, and quality management systems.
Our expert guidance and automated documentation management make sure you got a best in class Quality Management System compliant
with ISO 13485 and Technical documentation according to EU MDR, EU IVDR, FDA 21 CFR Part 820.
## Supported Standards
We support EU MDR, EU IVDR, FDA 21 CFR Part 820 and ISO 13485.
## Supported Devices
We support all types of medical devices (both EU and USA):
* Class I
* Class II
* Class III
To learn more about device classification, please refer to our [blog post about device classification](https://blog.withdovetail.com/blog-post/am-i-a-medical-device-a-strategic-guide-on-eu-medical-device-classification).
# Migration
Source: https://docs.withdovetail.com/getting-started/migration
Seamlessly migrate your existing medical device documentation to FormlyAI with expert guidance and comprehensive planning.
You can migrate your existing documentation to FormlyAI by sending us your existing documentation. We will review it and get back to you with a plan for migrating your documentation.
# EU AI Act for Medical Devices: A Practical Compliance Guide
Source: https://docs.withdovetail.com/guides/eu-ai-act-practical-compliance-overview
Learn how the EU AI Act applies to medical devices, what MDR processes already cover, and which AI-specific controls manufacturers still need.
**TL;DR**
If an AI system is a medical device or safety component covered by the MDR or IVDR **and** the product requires third-party conformity assessment, the AI system will generally be high-risk under the EU AI Act.
Your existing quality system gives you a strong starting point. It does not close every gap. You will still need AI-specific classification, data governance, logging, human oversight, transparency, performance monitoring, and documentation.
Under the AI Act currently in force, high-risk rules for AI embedded in regulated products apply from **2 August 2027**. An approved amendment would move this date to **2 August 2028**, but it had not yet entered into force as of 14 July 2026.
## Introduction
If you are developing an AI-enabled medical device, you do not need to build a second compliance system from scratch. Your MDR or IVDR quality system already covers much of the underlying work: risk management, technical documentation, verification and validation, conformity assessment, and post-market surveillance.
But MDR or IVDR conformity does not automatically demonstrate conformity with the EU AI Act. The AI Act adds a separate classification test and requirements that existing medical-device frameworks only cover in part. The biggest gaps usually concern training and validation data, bias, fundamental rights, model behaviour, logging, human oversight, and performance over time.
This guide shows you how to identify the requirements that apply, reuse evidence you already have, and focus your gap assessment on the AI-specific work that remains.
**Source and scope.** This guide translates the [official text of Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) into a practical overview for medical-device teams. Its legal-status information was checked on 14 July 2026. It is general information, not a substitute for a case-specific regulatory or legal assessment.
## How the EU AI Act risk framework works
The AI Act follows a risk-based approach. The more an AI system can affect health, safety, or fundamental rights, the more control and evidence the Act requires.
The commonly used labels "unacceptable," "high," "limited," and "minimal" risk are useful shorthand, but they can hide important details. A system outside the high-risk category may still be subject to AI literacy, prohibited-practice, or transparency rules. General-purpose AI models follow a separate obligation path.
| Category | What it means | Example relevant to a medical-device company |
| :----------------------------------- | :------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------- |
| **Prohibited practices** | Certain uses of AI are banned. | AI that manipulates people or exploits vulnerabilities in a way that causes or is likely to cause significant harm. |
| **High-risk AI systems** | The full set of high-risk requirements applies. | An AI-based diagnostic device that requires third-party conformity assessment. |
| **Systems with transparency duties** | Users must receive specific disclosures in situations covered by Article 50. | A support chatbot that interacts directly with users or synthetic content that must be marked as AI-generated. |
| **Other AI systems** | The high-risk chapter may not apply, but horizontal obligations can still apply. | An internal tool that does not make or materially influence safety-critical decisions. |
| **General-purpose AI models** | Model providers have separate obligations, with additional rules for models posing systemic risk. | A foundation model integrated into a medical-device workflow. The model provider and downstream manufacturer may have different duties. |
## Current EU AI Act timeline
The AI Act entered into force on 1 August 2024 and applies in phases.
Definitions, AI literacy duties, and prohibited AI practices began to apply.
Governance provisions and obligations for providers of general-purpose AI models began to apply.
Most remaining provisions apply under the law currently in force, including the high-risk rules for systems listed in Annex III and the Article 50 transparency requirements.
The high-risk rules for AI systems covered by Article 6(1) apply under the law currently in force. This includes qualifying AI systems embedded in products regulated under the MDR or IVDR.
**Pending timeline change—status on 14 July 2026.** The Council gave final approval to an amendment that would move the Annex III high-risk date to **2 December 2027** and the Article 6(1) product-embedded high-risk date to **2 August 2028**. As of 14 July 2026, the amendment was awaiting publication in the Official Journal and had not entered into force. Until it does, the dates above remain legally binding. See the [Council announcement](https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/pdf/), the [Council-approved text (PE-CONS 30/1/26 REV 1)](https://data.consilium.europa.eu/doc/document/PE-30-2026-REV-1/en/pdf), and the [draft Commission guidelines for high-risk AI systems](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems). The draft guidelines are non-binding; their consultation remains open until 23 July 2026 and final adoption is pending. Check the latest Official Journal version before making a deadline-dependent decision.
## First identify your role
Your obligations depend on what you do in the AI value chain, not only on the technology you use.
You develop an AI system or have one developed, and you place it on the market or put it into service under your name or trademark. A medical-device manufacturer will often be the provider of AI embedded in its device.
You use an AI system under your authority in a professional context. A hospital using an AI-enabled device may be a deployer.
You are located or established in the EU and place on the market an AI system that bears the name or trademark of an entity established outside the EU.
You make an AI system available in the EU supply chain without being the provider or importer.
One organisation can hold more than one role. Your role can also change if you rebrand a system, make a substantial modification, or change its intended purpose. Record the role assessment for every AI system in your inventory.
## When is an AI medical device high-risk?
For regulated products, [Article 6(1)](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6) uses a two-part test. An AI system is high-risk when **both** conditions are true:
1. The AI system is itself a product, or a safety component of a product, covered by legislation listed in Annex I of the AI Act. The MDR and IVDR are included.
2. The product requires a third-party conformity assessment before it can be placed on the market or put into service.
In plain language: if the AI is the medical device or is intended to be a safety component of it, and a Notified Body must assess the product, you should expect the AI system to be high-risk.
Not every piece of software used by a medical-device company is automatically a high-risk medical-device AI system. An internal writing assistant, customer-support chatbot, or administrative tool needs its own assessment. It may fall under transparency or other rules without meeting the Article 6(1) high-risk test.
Use this decision path for each system:
Compare the system with the AI Act definition. Do not classify a product from its marketing label alone.
State what the system does, who uses it, whose decisions it affects, and whether it performs a medical-device or safety function.
Determine whether the system is a product or safety component under the MDR or IVDR and whether third-party conformity assessment is required.
If Article 6(1) does not apply, check Annex III high-risk use cases, prohibited practices, Article 50 transparency duties, and any general-purpose AI obligations.
Keep the decision, supporting evidence, reviewer, and review date under change control. Reassess it when the intended purpose, model, product, or regulatory guidance changes.
## What high-risk AI compliance requires
High-risk AI compliance is not one document. It is a controlled evidence system that covers the full lifecycle.
| Area | What you need to demonstrate | What your existing medical-device system can contribute |
| :------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Quality management and accountability** | Defined responsibilities, controlled processes, supplier oversight, competence, and evidence that requirements are consistently met. | Your MDR/IVDR and ISO 13485 quality system provides the structure. Add AI-specific roles, review gates, supplier controls, and literacy requirements. |
| **Risk management** | Continuous identification, evaluation, control, testing, and monitoring of risks to health, safety, and fundamental rights. | [ISO 14971 risk management](/regulatory-requirements/risk-management) is a strong foundation. Extend it to dataset bias, model behaviour, foreseeable misuse, automation effects, and affected groups. |
| **Data governance** | Relevant and sufficiently representative training, validation, and test data with documented provenance, preparation, assumptions, limitations, and bias controls. | Clinical and design-control processes provide useful evidence, but most teams need additional dataset governance and traceability. |
| **Technical documentation and records** | Intended purpose, architecture, development methods, data, performance metrics, risk controls, validation, model versions, and automatically generated logs. | Your [technical file](/regulatory-requirements/technical-file) and software lifecycle records cover part of this. Add AI-specific design decisions, datasets, model behaviour, and logging. |
| **Transparency and information** | Clear information about capabilities, limitations, expected accuracy, input requirements, foreseeable misuse, and human oversight. | Labelling, instructions for use, and usability engineering provide the delivery mechanisms. Review whether the content meets AI-specific information duties. |
| **Human oversight** | People can understand relevant outputs, detect anomalies, intervene, and disregard, reverse, or stop the system where appropriate. | Clinical workflow and usability controls help, but oversight must be designed into the system and validated rather than assumed. |
| **Accuracy, robustness, and cybersecurity** | Defined and tested performance that remains appropriate over time, including resilience to faults, model drift, misuse, and adversarial manipulation. | Verification, validation, software lifecycle, and cybersecurity controls provide the base. Add AI-specific failure modes and monitoring thresholds. |
| **Post-market monitoring and incidents** | Active monitoring of behaviour and outcomes, corrective action, and reporting of serious incidents where required. | Your [post-market surveillance system](/regulatory-requirements/post-market-surveillance) already provides the feedback loop. Extend it to model drift, data shifts, unexpected outputs, and AI-specific incident criteria. |
### Human oversight must be designed, not assumed
Putting a clinician in the workflow does not automatically meet the human-oversight requirement. The interface, instructions, training, and operating controls must allow that person to:
* understand what the output means and where its limits are;
* recognise anomalies or over-reliance;
* intervene before harm occurs;
* disregard, override, or reverse an output when appropriate; and
* stop the system or move to a safe state when necessary.
Test these controls in realistic use conditions. A policy that says "a human reviews the result" is not enough if the design makes meaningful review impractical.
### Data governance goes beyond data quality
Good model performance on one validation dataset is not the same as controlled data governance. For datasets covered by Article 10, document:
* where training, validation, and test data came from;
* why the data is relevant to the intended purpose and target population;
* how you identified and addressed missing, imbalanced, or biased data;
* which preprocessing, annotation, and exclusion rules you applied;
* which limitations remain and how you control them; and
* how you will detect material changes in real-world input data.
As a validation best practice—not an express checklist item in the AI Act—also document how you separated datasets and controlled leakage risk.
The practical goal is traceability. A reviewer should be able to follow the path from intended purpose to dataset choices, performance claims, identified risks, controls, validation evidence, and post-market monitoring.
## How existing frameworks help—and where they stop
Standards can reduce duplicated work. Under the law currently in force, none of them replaces the legal classification, role assessment, or conformity obligations in the AI Act.
The approved but not-yet-in-force amendment would add a targeted mechanism to reduce overlap. Through delegated acts, the Commission could limit specific requirements in Articles 9–15 and obligations in Articles 17–25 where Annex I sectoral legislation, including the MDR or IVDR, provides equivalent or higher protection. This would not create automatic equivalence: it would apply only after the amendment enters into force and the Commission adopts the relevant delegated act.
| Standard or framework | Strongest contribution | What it does not replace |
| :-------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- |
| **EU MDR / IVDR** | Quality management, product risk, technical documentation, clinical or performance evaluation, conformity assessment, and post-market surveillance. | AI Act classification, fundamental-rights analysis, AI-specific data governance, transparency, and model-behaviour controls. |
| **ISO 14971** | Lifecycle medical-device risk management. | Dataset governance, bias assessment, AI transparency, and the AI Act's legal classification test. |
| **ISO/IEC 42001** | AI management-system governance, accountability, objectives, controls, and continual improvement. | Product classification, prohibited-practice screening, conformity assessment, and other binding legal duties. |
| **ISO/IEC 23894** | A structured method for identifying and managing AI-specific risks. | A complete quality system, technical documentation, registration, or conformity assessment. |
| **ISO/IEC 27001 and 27701** | Information security and privacy management. | AI performance, human oversight, transparency, bias, and high-risk system classification. |
| **NIST AI RMF** | Voluntary practices for governing and measuring trustworthy AI risk across the lifecycle. | EU legal obligations, CE marking, registration, incident reporting, or conformity assessment. |
The cleanest approach is to map AI Act requirements into your existing quality system. Reuse procedures and records where they genuinely satisfy both frameworks. Add AI-specific evidence where they do not.
## A practical EU AI Act compliance plan
Include AI you develop, buy, embed, rebrand, or use internally. Record the owner, intended purpose, users, model or supplier, affected product, data, market, and lifecycle status.
Decide whether you are the provider, deployer, importer, distributor, or a combination. Document dependencies on model providers and other suppliers.
Apply the Article 6 tests, screen prohibited practices, check Article 50 transparency duties, and record the rationale. Do not use a single classification for an entire product portfolio.
Link each applicable AI Act requirement to an existing procedure, record, control, or owner. Mark partial coverage honestly.
Prioritise dataset governance, bias and affected-group analysis, model documentation, logging, human oversight, AI-specific cybersecurity, and model-change control.
Set performance metrics, acceptance criteria, subgroup analyses, drift thresholds, oversight tests, and logging requirements before verification and validation begins.
Align AI evidence with your MDR or IVDR technical documentation and Notified Body plan. Confirm responsibilities and evidence expectations early rather than adding an AI file at the end.
Connect model, data, supplier, intended-purpose, and software changes to regulatory reassessment. Feed post-market signals back into risk management, validation, and corrective action.
## Conclusion
The product-embedded high-risk date under the law currently in force is 2 August 2027. An approved amendment is expected to move it to 2 August 2028, but you should not plan against the later date until the amendment enters into force.
The shortest path is to use the quality system you already have. Start with your MDR or IVDR evidence, map it to the AI Act, and isolate the gaps. Then build AI-specific data, oversight, logging, performance, and monitoring controls into the same lifecycle rather than creating a parallel compliance programme.
If you want a second set of eyes on the classification or gap assessment, [ask Dovetail to review the regulatory pathway with your team](https://www.withdovetail.com/).
## Main takeaways
Your obligations depend on the system's intended purpose, your role, and the Article 6 classification test. Record the rationale before planning controls.
Reuse your QMS, risk, technical documentation, validation, and post-market processes. Add the AI-specific evidence they do not cover.
Dataset provenance, representativeness, bias, model versions, logging, drift, human oversight, and real-world performance need explicit controls and evidence.
As of 14 July 2026, the binding product-embedded date remains 2 August 2027. The approved amendment would move it to 2 August 2028 after publication and entry into force. Keep integrating the requirements into development and conformity planning now.
## Official sources
* [Regulation (EU) 2024/1689 — Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
* [Current Article 113 application dates](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113)
* [Council-approved Digital Omnibus text (PE-CONS 30/1/26 REV 1)](https://data.consilium.europa.eu/doc/document/PE-30-2026-REV-1/en/pdf)
* [Draft European Commission guidelines for providers and deployers of high-risk AI systems](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems)
* [Council final approval of the revised AI Act implementation rules, 29 June 2026](https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/pdf/)
* [MDCG 2025-6 FAQ on the interplay between MDR, IVDR, and the AI Act](https://health.ec.europa.eu/latest-updates/mdcg-2025-6-faq-interplay-between-medical-devices-regulation-vitro-diagnostic-medical-devices-2025-06-19_en)
## Frequently asked questions
No. First confirm that the software meets the AI Act definition of an AI system. Then assess its intended purpose, role in the product, conformity pathway, and other possible obligation categories. Software is not high-risk under the AI Act simply because a medical-device company uses it.
Not automatically. Under Article 6(1), the AI must be a regulated product or safety component and the product must require third-party conformity assessment. Systems that do not meet both conditions still need screening for Annex III, prohibited practices, transparency duties, and other applicable rules.
No automatic equivalence applies under the law currently in force. MDR or IVDR conformity gives you substantial reusable evidence, but the AI Act adds its own classification, data governance, transparency, human-oversight, logging, and lifecycle-performance requirements. The approved but not-yet-in-force amendment would let the Commission limit selected AI Act requirements through delegated acts where sectoral law provides equivalent or higher protection. Perform a documented gap assessment unless and until a relevant delegated act applies.
Under the law currently in force, the Article 6(1) high-risk rules for qualifying AI embedded in regulated products apply from 2 August 2027. An approved amendment would move this date to 2 August 2028, but as of 14 July 2026 it had not entered into force. Other AI Act obligations already apply or begin earlier, so do not postpone your inventory, literacy, prohibited-practice screening, or transparency work.
The AI Act does not make ISO/IEC 42001 certification a universal requirement. The standard can provide a useful governance structure, but certification does not replace the legal requirements or prove that a specific product conforms.
Separate the model provider's obligations from your own. As the manufacturer placing the AI-enabled device on the market, you may still be the provider of the downstream AI system. Define the information, change notifications, performance evidence, security controls, and access rights you need from the supplier.
Start with an inventory and classification record. Without those, you cannot reliably determine which controls, evidence, suppliers, deadlines, or owners matter.
# Introduction
Source: https://docs.withdovetail.com/guides/introduction
Learn about high level strategy to get your medical products approved in the US or EU.
The following sections provide helpful guides around strategy and compliance for your medical device.
# Website & Marketing Compliance
Source: https://docs.withdovetail.com/guides/webiste-and-marketing
Learn about the compliance requirements for your medical device's website and marketing materials.
## TL;DR
All public-facing content for a medical device including your website, social media, and marketing materials is considered **advertising** by regulators like the FDA. Every claim you make online **must** perfectly match the claims proven in your official regulatory submission. Any misalignment creates serious compliance risks, potentially leading to warning letters, fines, and even criminal charges. Be truthful, not aspirational.
## Introduction
Regulators view their primary mission as patient protection. To them, your company's website isn't just a marketing tool; it's a collection of claims that must be rigorously fact-checked against your official device submission. They scrutinize every piece of content associated with your device to ensure you are not making unproven, misleading, or off-label claims.
This guide provides a high-level overview of what you can and cannot say, helping you navigate the digital tightrope and ensure your online presence supports, rather than jeopardizes, your regulatory success.
## The Golden Rule: Be Truthful, Not Aspirational
Your website is not the place for your "vision" of what your product might do one day. It's for what it is **proven to do right now**. All your content must be:
* **Truthful** ✅: Based only on verified data and evidence from your regulatory submission.
* **Balanced** ⚖️: Always present both the benefits and the risks, including contraindications and limitations.
* **Not Misleading** 🚫: Avoid any language that could cause patients or doctors to believe your device does more than it is cleared for.
Ask yourself this **critical question** for every piece of content: "Could a patient or doctor misunderstand this and believe our device does more than it's cleared for?" If the answer is "maybe," you must revise the wording immediately.
## What You CAN Say
What you're allowed to say depends on your device's regulatory status. Let's look at the two cases:
### If Your Device is NOT YET Cleared/Approved
Focus on the company and the technology, not the product's unproven medical benefits.
* **Company & Technology Focus**:
* Discuss the problem you're solving (e.g., disease state education).
* Highlight your team's expertise and credentials.
* Provide general descriptions of the science or technology.
* Share company news like mission, history, and funding.
* **Required Disclaimers**: You must display a clear and prominent disclaimer.
* *Example 1*: "This product is investigational and not available for sale in \[Country/Region]."
* *Example 2*: "This technology is in development. Claims have not been evaluated by the FDA."
### If Your Device IS Cleared/Approved
Stick strictly to the scope of your approval.
* **Approved Content**:
* Quote your **Indications for Use (IFU)** directly from your clearance document.
* Explain the **mechanism of action** as proven in your submission.
* Present **clinical data** that directly supports your cleared IFU.
* Provide balanced risk and benefit information.
* **Testimonials**: Patient and physician testimonials are allowed, but they must be:
* **Truthful** and representative of typical experiences.
* **Reflective** of your cleared IFU only.
* Accompanied by **appropriate disclaimers**.
***
## What You CANNOT Say 🛑
Certain words and promotional tactics are major red flags for regulators. Avoid them at all costs.
* **"Magic Words" to Avoid**: Unproven superlatives will attract immediate scrutiny. Don't use words like "**Best**," "**Most Effective**," "**Revolutionary**," "**Guaranteed**," or "**First-ever**" unless you have incredibly strong, direct comparative clinical data to prove it.
* **Pre-Approval Promotion**: Never promote an investigational device as safe or effective before it's officially cleared. This is a serious violation that can delay or prevent approval.
* **Off-Label Hints**: Never discuss, hint at, or imply how your device could be used for conditions outside of its specific clearance. This is "off-label promotion" and a major compliance violation.
* **Downplaying Risks**: Never use terms like "**completely safe**" or imply there are no side effects. You must always present balanced risk information as required by your labeling.
* **"Cure" Claims**: This word is a regulatory landmine. Your device *treats*, *diagnoses*, or *manages* conditions—it does not "**cure**" them. Using this word can trigger immediate enforcement action.
***
## Simple Phrasing to Keep You Safe
Here’s how to transform risky language into compliant messaging that still communicates value.
| Instead of This | Try This | Why It's Better |
| :---------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------------- |
| "Our revolutionary device treats all forms of chronic back pain." | "Our device is indicated for the temporary relief of chronic, intractable back pain." | Aligns with a specific, cleared indication and avoids superlative language. |
| "The safest and most effective solution on the market." | "In a clinical study, X% of patients experienced \[cleared outcome] compared to Y% with a sham device." | Replaces a subjective claim with objective, verifiable clinical data. |
| "A guaranteed way to monitor your heart health." | "Our device is intended to record, store, and transfer single-channel ECG rhythms." | States the device's specific function rather than promising a broad health outcome. |
| "The future of surgery is here." (for an investigational device) | "This device is limited by Federal law to investigational use." | Provides the legally required disclaimer for unapproved devices. |
## Cautionary Tales: Real-World Examples
* **Off-Label Promotion (Vascular Solutions, Inc.)**: The company promoted its Vari-Lase device for treating perforator veins, a use for which it was not cleared. **Consequence**: The CEO faced criminal charges, and the company suffered significant legal costs and reputational damage.
* **Premature Marketing (WHOOP, Inc.)**: The company marketed its Blood Pressure Insights feature with claims like "medical-grade health & performance insights" before receiving FDA authorization. **Consequence**: The FDA issued a warning letter, forcing the company to remove misleading language from its website.
* **Unsubstantiated Claims (Vevazz LLC)**: Their website claimed their LED-light therapy devices could be used for fat loss, skin tightening, and scar treatment, which were uses not supported by their clearance. **Consequence**: An FDA Warning Letter forced them to alter their claims and damaged their credibility.
## Conclusion: Your Action Plan
Integrate these simple steps into your workflow to build a culture of compliance.
1. **Assign a "Compliance Captain"**: Designate one person (e.g., from regulatory affairs or legal) as the final checkpoint for *all* public content. No exceptions.
2. **Make Your IFU Your North Star** ⭐: Print your official **Indications for Use (IFU)** statement and post it where your marketing team can see it. If a claim isn't supported by that exact statement, it doesn't go online.
3. **Create a "Banned Words" List**: Start a list of words to avoid. Include: **Cure, Perfect, Guaranteed, Safest, Revolutionary, Best,** and **Most Effective.**
4. **Audit Monthly**: Dedicate 30 minutes each month to reviewing your website, social media, and ads from a regulator's perspective. Document your findings and corrections in a compliance log.
***
## FAQ
Regulators take a very broad view. "Advertising" includes your website and all its subpages, social media posts, LinkedIn updates, trade show materials, email newsletters, and any other public-facing promotional content.
Yes, but you must be careful. You can provide general descriptions of the science or technology and discuss your company's mission and team. However, you cannot make any claims that the device is safe or effective for a medical purpose. You must also include a clear disclaimer stating the device is investigational and not for sale.
Yes, if your device is cleared/approved, but they must be managed carefully. Testimonials must reflect typical experiences and only discuss the device's cleared Indications for Use. They should also be accompanied by appropriate disclaimers.
Off-label promotion is suggesting, either directly or indirectly, that your device can be used for conditions or patient populations it wasn't officially cleared for. It's a major violation because the safety and effectiveness for that use haven't been reviewed by regulators, potentially putting patients at risk.
It depends entirely on the claims you make. If your marketing implies your wellness product can be used to diagnose, treat, or manage a medical condition (like the WHOOP example with "medical-grade" blood pressure insights), the FDA will consider it a medical device and regulate it as such. The claims you make define your product.
# Billing
Source: https://docs.withdovetail.com/organization/billing
Manage your FormlyAI billing and payment information including invoice access and payment method updates for subscriptions.
You can manage your billing information by clicking your organization name in the top left corner and then selecting **"Billing"** from the dropdown menu.
This will take you to the billing page where you can see all of your billing history and download your **invoices**.
There you are also able to **update** your billing information or add a new **payment method**.
# Manage Organization
Source: https://docs.withdovetail.com/organization/manage
Configure your organization name, members, and functional groups.
Open **Manage Organization** from the organization menu to update the organization name, manage members, and configure functional groups.
# Organization Name
Edit the organization name at the top of the page. The name is used in suggestions, appears across the app, and is included on your final submission, so use the **full legal name** of your organization.
# Members
Use the **Members** section to add or remove people from the organization. New members receive an email invitation to join. Once they accept, they show up in the users table and can be added to functional groups.
# Functional Groups
![Adding users to a functional group]()
Functional groups describe the areas in your organization that own documents (for example, Quality Management and Assurance, Software, Regulatory). Every document can be attributed to a functional group so it is clear who is responsible for it.
## Defaults
Every organization is seeded with a standard set of functional groups when it is created, so existing document classifications keep working out of the box. You can rename or remove the defaults and add your own.
## Create a group
1. Open the **Functional Groups** section on the Manage Organization page.
2. Click **Create functional group**.
3. Enter a **name** (for example, "Quality Management and Assurance"). An **acronym** is suggested automatically and can be edited (for example, `QA`).
4. Optionally enable **Can Manage Trainings** if members of this group should manage organization-wide [Training Programs](../eqms/training-programs).
5. Save.
Both the name and the acronym must be unique within your organization.
## Training management permission
Enable **Can Manage Trainings** for a functional group when its members should assign and manage organization-wide training.
Members of a group with this permission can open **All Training Programs**, assign document training, manage trainee pools, send training for revisions, and delete pending training tasks. Members without this permission can still complete their own assigned trainings from **My Training Programs**.
The default QA functional group has **Can Manage Trainings** enabled when an organization is created. Normally this is the only group that needs this permission.
## Rename or delete a group
* Use the edit icon next to a group to update its name or acronym.
* Use the delete icon to remove a group. Any documents that referenced the group are kept — their functional group is simply cleared. Document templates that pointed at the group by acronym are unaffected.
## Manage members
Click a group to open its member list. From there you can:
* **Add members** from the organization.
* **Remove members** from the group without affecting their organization membership.
A user can belong to none, one, or many functional groups. Their groups show up as chips in the organization users table and in the user menu so it is easy to see who owns what.
Any member of the organization can create, edit, and delete functional groups and manage their membership. If you need stricter control, let us know.
# User Settings
Source: https://docs.withdovetail.com/organization/user-settings
Manage your profile, integrations, and notification email preferences.
# TL;DR
* Open **User Settings** from the organization menu.
* Use **Profile** to update your name and review your functional group memberships.
* Use **Integrations** to connect or remove built-in integrations and custom MCP servers.
* Use **Notification Settings** to choose which system emails you receive.
* Use the small **notification settings** link at the bottom of supported emails to jump straight back to these controls.
User Settings are scoped to the organization you are currently viewing. If you belong to multiple organizations, switch to the correct one before you change integrations or notification preferences.
# Open User Settings
1. Open the organization you want to work in.
2. Open the organization menu.
3. Select **User Settings**.
The page is organized into three sections in this order:
1. **Profile**
2. **Integrations**
3. **Notification Settings**
# Profile
Use **Profile** to review your current name, email address, and functional group memberships.
* Click the edit icon next to your name to update it.
* Your email address is shown here for reference.
* Your **functional groups** in the current organization are listed as chips. Memberships are managed from [Manage Organization](/organization/manage#functional-groups) by anyone in the org.
# Integrations
Use **Integrations** to manage tools connected to your account in the current organization.
* Built-in integrations such as GitHub, Linear, and Jira can be connected from this section.
* You can also add custom MCP servers with **Add Integration**.
* Each connection can be enabled or disabled for agent access independently.
For detailed setup steps, see [Integrations](/assistant/integrations).
# Notification Settings
Use **Notification Settings** to control which non-mandatory system emails Formly sends to you.
Each setting updates your account preference immediately and applies to future emails in the current organization.
## Comments
* **Email me when someone mentions me in a comment**
* **Email me when someone replies to a thread I'm in**
## Approvals
* **Email me when a document is sent to me for approval**
* **Email me when my document is fully approved**
## Tasks
* **Email me when a task is assigned to me**
* **Email me when one of my tasks changes status**
* **Email me when one of my tasks is updated**
## Digest
* **Receive weekly digest emails**
The weekly digest is separate from live notification emails. Turning it off stops the scheduled digest email but does not change your comment, approval, or task alerts.
Invite emails and PIN reset emails are always sent. These are required account and access emails and are not controlled by notification preferences.
# Manage Notifications From an Email
Supported notification emails include a small grey **notification settings** link at the very bottom of the email.
Use that link when you want to:
* turn off a specific category after receiving an email
* stop the weekly digest
* review your current notification preferences
# Best Practices
* Leave only the alerts on that you actually act on.
* Keep approval request emails enabled if you are an approver on controlled documents.
* Keep task assignment emails enabled if your team uses Formly tasks operationally.
* Review your settings after joining a new organization or taking on a new role.
# FAQ
## Are notification settings shared across organizations?
No. User Settings are managed in the organization you are currently viewing, and the notification footer link takes you back to that organization's settings page.
## What happens if I turn off the weekly digest?
You will stop receiving the scheduled weekly digest email. Your live comment, approval, and task emails stay controlled by their own toggles.
## Why am I still getting an invite or PIN reset email?
Those emails are mandatory account and access emails, so they are not affected by notification preferences.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/audits-and-review
Implement systematic audit programs and management reviews ensuring quality system effectiveness and regulatory compliance.
## Summary
Audits and reviews establish **systematic quality assurance mechanisms** that verify your Quality Management System (QMS) operates effectively and remains compliant with regulatory requirements. You must implement comprehensive audit programs and management reviews that demonstrate proactive quality oversight, identify improvement opportunities, and provide objective evidence of regulatory compliance to authorities and notified bodies.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Quality audits are **mandatory** under Section 820.22
* Must be conducted by individuals **not directly responsible** for areas being audited
* Results must be **documented** and reviewed by management with executive responsibility
* Audit findings must feed into your **Corrective and Preventive Action (CAPA)** system
**Key Standards:**
* FDA Quality System Regulation (21 CFR Part 820)
* FDA Quality Manual Guidance for design control auditing
* ISO 19011 Guidelines for auditing management systems
**Special attention required for:**
* Design controls (820.30) - especially for software medical devices requiring systematic review
* CAPA system effectiveness (820.100) - audit findings must trigger appropriate corrective actions
* Production and process controls (820.70) - manufacturing processes require ongoing verification
* Document controls and change management (820.40) - systematic review of document effectiveness
Under **EU MDR 2017/745**:
* Manufacturers must implement a quality management system (Article 10(9))
* Must comply with **EN ISO 13485:2016** requirements for internal audits (Section 8.2.4)
* Audit results must be available for **notified body assessment**
* Regular systematic reviews are required for CE marking maintenance
**Key Standards:**
* ISO 13485:2016 Medical devices - Quality management systems
* ISO 19011:2018 Guidelines for auditing management systems
* EN ISO 14971:2019 Medical devices - Risk management (audit requirements)
**Special attention required for:**
* Clinical evaluation processes (Article 61) and ongoing clinical follow-up requiring systematic oversight
* Post-market surveillance system (Articles 83-86) - audit findings inform PMS effectiveness
* Person Responsible for Regulatory Compliance (PRRC) oversight and review participation
* Unique Device Identification (UDI) compliance (Article 27) and implementation verification
## Overview
Audits and reviews represent the **central nervous system** of your quality management framework, providing systematic feedback mechanisms that ensure your medical device quality system remains effective, compliant, and continuously improving throughout the product lifecycle. This card establishes comprehensive oversight structures that transform quality management from reactive compliance activities into proactive strategic quality leadership.
### Strategic Quality Oversight Architecture
Your audit and review system operates through **interconnected oversight mechanisms** that provide multiple perspectives on quality management effectiveness, from operational process verification through executive strategic assessment. The architecture balances **systematic compliance verification** with **strategic quality intelligence**, ensuring both regulatory adherence and continuous organizational learning drive quality improvements.
**Regulatory requirements management** establishes the foundation for effective oversight by systematically identifying and tracking all applicable regulations, standards, and guidance documents that govern your medical device quality system. This comprehensive requirements baseline ensures audits and reviews address current regulatory expectations while adapting to evolving regulatory landscapes that affect medical device compliance and market access.
**Audit program development** provides the strategic framework for systematic quality system verification, scheduling comprehensive coverage of all QMS processes over defined audit cycles while prioritizing high-risk areas and processes with previous findings. The program ensures independent, objective evaluation of quality system effectiveness while optimizing resource allocation and maintaining audit credibility through proper auditor qualification and independence.
### Systematic Process Verification Framework
Your audit implementation transforms quality system documentation into **operational reality verification**, ensuring documented procedures translate into consistent practice that supports medical device quality and regulatory compliance. **Audit planning** establishes detailed roadmaps for systematic evaluation of specific QMS processes, defining scope, criteria, activities, and participants that ensure comprehensive coverage while maintaining efficient resource utilization.
**Audit execution and reporting** provide objective evidence of quality system performance through systematic evaluation against regulatory standards and internal procedures. Audit reports document findings, nonconformities, and improvement opportunities while driving corrective and preventive actions that address systemic quality issues before they affect product quality or regulatory compliance.
**Audit program management** ensures systematic coverage of all quality processes over defined cycles, typically spanning three years to balance comprehensive oversight with practical resource constraints. The program adapts to organizational changes, regulatory updates, and process maturity while maintaining consistent audit quality and independence requirements essential for credible quality system verification.
### Executive Quality Leadership Integration
Management reviews transform **operational quality data into strategic quality intelligence** that guides executive decision-making, resource allocation, and organizational quality priorities. These systematic evaluations demonstrate management commitment to quality while ensuring senior leadership maintains direct oversight of quality system performance and strategic quality planning.
**Key Performance Indicator (KPI) analysis** provides quantitative assessment of quality system effectiveness across all QMS processes, tracking metrics including training completion rates, audit findings, customer feedback response times, CAPA closure rates, and regulatory compliance indicators. KPI trends inform management decisions about process improvements, resource needs, and strategic quality investments.
**Management accountability structures** establish clear executive responsibility for quality system performance through formal review participation, documented assessments, and commitment to improvement actions. Management signatures on review reports demonstrate executive engagement while establishing accountability for quality system effectiveness and continuous improvement initiatives.
### Integration with Quality System Processes
Audit and review activities integrate deeply with **multiple quality management processes**, creating feedback loops that strengthen overall system effectiveness while providing early warning indicators of potential quality issues. **CAPA system integration** ensures audit findings drive systematic investigation and corrective action, preventing recurring issues while building organizational learning from quality system gaps.
**Risk management integration** connects audit findings with risk assessment and control activities, ensuring quality system weaknesses receive appropriate risk evaluation while risk control effectiveness receives systematic verification through audit activities. This integration strengthens both quality system reliability and risk management effectiveness.
**Change management coordination** ensures quality system modifications receive appropriate evaluation through audit and review processes while providing feedback on change effectiveness and unintended consequences. Systematic review of change outcomes supports continuous improvement while preventing quality system degradation through uncontrolled modifications.
### Regulatory Compliance and Audit Readiness
Your audit and review system provides **essential preparation for regulatory inspections** by maintaining current awareness of regulatory requirements, systematic process verification, and comprehensive documentation of quality system performance. **Regulatory intelligence management** ensures audit criteria remain aligned with current regulatory expectations while identifying emerging requirements that require quality system adaptation.
**Notified body and FDA inspection preparation** benefits significantly from robust internal audit programs that identify and address compliance gaps before external inspection. Well-documented audit programs, comprehensive finding resolution, and systematic management review demonstrate proactive quality management that typically results in favorable inspection outcomes.
**International regulatory harmonization** drives audit approaches that address multiple regulatory jurisdictions efficiently, ensuring audit criteria cover EU MDR, FDA QSR, and other applicable requirements without duplicative effort. Harmonized audit programs support global device development and commercialization while maintaining regulatory compliance across multiple markets.
### Continuous Improvement and Organizational Learning
Effective audit and review programs extend beyond **compliance verification to drive organizational learning** that enhances quality culture, process effectiveness, and strategic quality capability. **Audit trend analysis** identifies systemic improvement opportunities while recognizing high-performing processes that provide models for organizational learning and best practice development.
**Management review strategic planning** connects quality system performance with business objectives, ensuring quality investments support organizational success while identifying quality capabilities that enable competitive advantage. Strategic quality planning balances short-term compliance needs with long-term quality capability development.
**Quality culture development** through systematic audit and review activities builds organizational commitment to quality excellence while providing regular opportunities for quality education, process improvement, and recognition of quality achievements. This cultural foundation supports sustainable quality performance that extends beyond regulatory compliance to encompass quality leadership.
The audits and review card establishes the **comprehensive oversight infrastructure** that enables proactive quality management, regulatory compliance, and continuous improvement throughout the medical device lifecycle, creating sustainable quality leadership that supports both patient safety and business success.
# CAPAs and Vigilance
Source: https://docs.withdovetail.com/regulatory-requirements/capas-vigilance
Integrate systematic problem resolution with proactive safety communication and incident management.
## Summary
CAPAs and Vigilance integrates **corrective and preventive action management** with **medical device vigilance** to ensure systematic problem resolution and safety communication. You implement structured processes through five key documents: **Incident Assessment Forms** for evaluating reportable events, **Field Safety Notices** for urgent user communication, **CAPA Plans** for systematic problem resolution, **CAPA Reports** for documenting implementation effectiveness, and **Lists of CAPAs** for trend analysis and management oversight.
## Regulatory Context
Under **21 CFR Part 820.100** (Corrective and Preventive Action) and **21 CFR Part 803** (Medical Device Reporting):
* **CAPA procedures** must be established and maintained for systematic problem resolution
* **Root cause analysis** required to identify and eliminate causes of nonconformities
* **Medical Device Reports (MDRs)** must be submitted for serious incidents within specified timeframes
* **Verification of effectiveness** must be documented for all corrective actions
* **Field corrections** and removals require FDA notification under 21 CFR Part 806
**Special attention required for:**
* Class I recalls requiring immediate FDA notification
* Software malfunctions affecting device safety or effectiveness
* CAPAs resulting from FDA inspections or warning letters
* Integration with complaint handling and post-market surveillance systems
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Serious incidents** must be reported immediately via EUDAMED (Article 87)
* **Field Safety Corrective Actions** require notification without delay (Article 89)
* **CAPA system** must address nonconformity causes (ISO 13485 Section 8.5)
* **Management review** must evaluate CAPA effectiveness and trends (Article 10(9))
* **Incident evaluation** must use three-criteria test for reporting determination
**Special attention required for:**
* Compliance with MDCG 2023-3 guidance for incident reporting
* Translation requirements for multi-country Field Safety Notices
* Post-market clinical follow-up implications for reported incidents
* Integration with notified body surveillance and certificate renewal
## Overview
CAPAs and Vigilance forms the **cornerstone of post-market safety management** by combining systematic problem resolution with proactive risk communication. This card ensures that quality issues, safety concerns, and adverse events receive appropriate investigation, correction, and prevention while maintaining transparent communication with users and regulatory authorities.
The **Incident Assessment Form** provides your **primary tool for vigilance compliance** by systematically evaluating whether events meet regulatory reporting criteria. This structured assessment uses the **three-criteria test** to determine if incidents constitute serious and reportable events requiring formal notification to competent authorities. The form ensures consistent decision-making, maintains audit trails for regulatory inspections, and prevents both under-reporting of serious events and over-reporting of minor issues.
**Field Safety Notices** serve as your **rapid response mechanism** for communicating urgent safety information to users when post-market surveillance reveals risks requiring immediate action. These standardized communications enable quick notification of users about hazards, provide specific corrective instructions, and coordinate protective actions before serious incidents occur. The notices demonstrate regulatory compliance, protect patient safety, and maintain stakeholder trust during crisis situations.
The **CAPA Plan** establishes your **systematic approach to problem resolution** when quality issues, nonconformities, or safety concerns require structured intervention. This planning document guides root cause investigation, defines corrective actions to fix immediate problems, and establishes preventive actions to prevent recurrence. CAPA Plans ensure resource allocation, timeline management, and verification planning while connecting individual problems to your broader quality improvement strategy.
**CAPA Reports** provide **auditable evidence** of effective problem resolution by documenting the execution and verification of planned corrective and preventive actions. These reports demonstrate implementation completeness, measure effectiveness through objective evidence, and support closure decisions based on verified problem resolution. They enable continuous improvement by documenting lessons learned and successful problem-solving approaches.
The **List of CAPAs** creates **centralized oversight** of all corrective and preventive actions, enabling trend analysis, resource planning, and management review activities. This comprehensive register supports strategic quality improvement planning by identifying recurring themes, monitoring cycle times, and tracking effectiveness indicators across your organization.
Together, these five documents create an **integrated safety management system** that transforms reactive problem-solving into proactive risk prevention. The system ensures that incidents trigger appropriate investigations, corrective actions address root causes rather than symptoms, and lessons learned contribute to systematic quality improvement. This comprehensive approach protects patients through early hazard identification, demonstrates regulatory compliance through systematic documentation, and builds stakeholder confidence through transparent safety communication.
The CAPA and vigilance processes integrate seamlessly with your **post-market surveillance** for trend identification, **risk management** for hazard assessment, **change management** for implementing corrections, and **clinical evaluation** for benefit-risk reassessment. This integration ensures that safety signals transform into systematic improvements while maintaining the rigorous documentation required for medical device quality management.
# Clinical Evaluation
Source: https://docs.withdovetail.com/regulatory-requirements/clinical-evaluation
Systematically evaluate clinical evidence demonstrating device safety and performance for regulatory approval.
## Summary
You must systematically gather, analyze, and evaluate clinical evidence that demonstrates your medical device's safety and clinical performance while maintaining an acceptable benefit-risk ratio. Clinical evaluation provides the essential evidence foundation that supports regulatory approval, marketing claims, and ongoing post-market surveillance through structured literature review, equivalence analysis, and clinical data assessment.
## Regulatory Context
Under **21 CFR Part 820** (Design Controls) and FDA guidance documents, you must implement:
* **Clinical data requirements** supporting 510(k) substantial equivalence or PMA approval
* **Predicate device comparison** demonstrating safety and effectiveness equivalence
* **Literature searches** and clinical evidence analysis supporting device validation
* **Clinical investigation protocols** for novel devices requiring clinical studies
* **Risk-benefit analysis** demonstrating acceptable safety profile for intended use
**Special attention required for:**
* **Software medical devices** requiring clinical validation of algorithms and decision support
* **Novel devices** without adequate predicate devices requiring clinical investigations
* **AI/ML devices** requiring algorithm performance validation in clinical settings
* **Devices with new indications** requiring additional clinical evidence beyond predicate devices
Under **EU MDR 2017/745** Article 61 and Annex XIV, you must comply with:
* **Clinical evaluation mandatory** for all medical devices per Article 61
* **Annex XIV requirements** for clinical evidence generation and documentation
* **MDCG 2020-1 guidance** for software as medical device clinical evaluation
* **Equivalence demonstration** following MDCG 2020-5 methodology
* **Post-market clinical follow-up** integration per Article 74 requirements
**Special attention required for:**
* **Class IIa and above** devices requiring more extensive clinical evidence
* **Software with clinical decision support** functions requiring algorithm validation
* **Devices claiming equivalence** to non-CE marked devices requiring additional justification
* **Novel devices** requiring clinical investigations under MDCG 2020-6 guidance
## Overview
Clinical evaluation represents the **systematic assessment** of clinical evidence that transforms technical device development into clinically validated medical solutions by demonstrating safety, performance, and clinical benefit through structured evidence collection and analysis. This comprehensive evaluation process ensures that your device meets regulatory requirements while providing healthcare providers and patients with confidence in clinical effectiveness and safety performance.
**Clinical Evaluation Planning** establishes the systematic methodology for gathering and analyzing clinical evidence appropriate to your device's risk classification, intended use, and regulatory pathway. Clinical evaluation planning requires careful consideration of your device's clinical claims, target patient population, and available evidence sources while determining whether literature-based evaluation, clinical investigations, or combined approaches provide sufficient evidence. The planning process includes establishment of clinical evaluation teams with appropriate expertise, definition of evidence requirements based on device classification and novelty, and development of systematic procedures for literature searching, data analysis, and evidence synthesis that support regulatory submissions and ongoing clinical monitoring.
**Literature Search and Analysis** provides systematic access to published clinical evidence that may support or challenge your device's safety and performance claims through comprehensive database searches and structured evidence evaluation. Literature activities require development of PICO (Patient, Intervention, Comparison, Outcomes) frameworks that guide systematic searches across medical databases including PubMed, Cochrane Library, and clinical trial registries. Effective literature analysis includes establishment of inclusion and exclusion criteria for evidence quality, systematic appraisal of study design and methodology, and synthesis of findings that address your specific clinical claims and regulatory requirements.
**Equivalence Demonstration** enables clinical evidence leveraging from existing devices that share similar technical, biological, and clinical characteristics with your device through systematic comparison and gap analysis. Equivalence analysis requires identification of appropriate equivalent devices that are CE-marked or FDA-cleared for similar indications, comprehensive comparison across technical characteristics, biological safety considerations, and clinical performance parameters. Successful equivalence demonstration must address any differences between devices and provide justification that these differences do not affect clinical safety or performance while documenting how equivalent device evidence supports your device's clinical claims.
**Clinical Investigation Management** addresses situations where literature-based evaluation and equivalence demonstration provide insufficient evidence, requiring original clinical studies to demonstrate safety and performance. Clinical investigation activities include protocol development that addresses specific evidence gaps, study design that meets regulatory standards for evidence quality, and execution that follows Good Clinical Practice guidelines. Investigation management requires coordination with clinical sites, regulatory notification or approval processes, and data collection that supports both regulatory requirements and ongoing clinical evaluation updates.
**Post-Market Clinical Follow-up Integration** ensures that clinical evaluation remains current throughout your device's commercial lifecycle by establishing systematic procedures for monitoring new clinical evidence and real-world performance data. Post-market clinical follow-up includes establishment of literature monitoring procedures that identify new relevant publications, integration with post-market surveillance systems that collect real-world performance data, and procedures for updating clinical evaluation documents when new evidence affects benefit-risk assessment. Effective integration ensures that clinical evaluation conclusions remain valid while supporting ongoing regulatory compliance and clinical confidence.
**Clinical Evidence Synthesis and Reporting** transforms collected clinical data into structured documentation that supports regulatory submissions and clinical decision-making through systematic analysis and clear communication of clinical findings. Evidence synthesis requires objective evaluation of clinical data quality and relevance, identification of evidence gaps that may require additional investigation, and clear presentation of benefit-risk analysis that supports intended use claims. Clinical reporting must address all aspects of clinical safety and performance while providing transparent documentation of evidence limitations and areas requiring ongoing monitoring.
**Regulatory Integration and Submission Support** ensures that clinical evaluation activities align with regulatory submission requirements while providing the evidence foundation for marketing authorization and ongoing compliance. Integration activities include coordination with technical documentation requirements, alignment with risk management findings and safety claims, and preparation of clinical evaluation reports that meet regulatory submission standards. Effective integration ensures that clinical evidence supports all regulatory requirements while enabling efficient regulatory review and approval processes.
**Quality Assurance and Team Management** ensures that clinical evaluation activities maintain appropriate scientific rigor and objectivity through qualified personnel and systematic quality controls. Quality management includes establishment of clinical evaluation teams with appropriate clinical expertise and regulatory knowledge, implementation of conflict of interest management procedures, and maintenance of documentation standards that support regulatory review and ongoing compliance. Effective team management ensures that clinical evaluation activities meet scientific and regulatory standards while providing credible evidence for clinical and regulatory decision-making.
**Evidence Level Assessment and Risk-Based Approach** ensures that clinical evidence generation is proportional to device risk and novelty while meeting regulatory requirements for evidence quality and quantity. Risk-based clinical evaluation includes assessment of appropriate evidence levels based on MDCG 2020-6 guidance, determination of evidence requirements based on device classification and clinical claims, and implementation of systematic approaches that optimize evidence generation efficiency while maintaining regulatory compliance. Effective risk-based approaches prevent over-investigation while ensuring adequate evidence for confident clinical and regulatory decision-making.
Your clinical evaluation activities must demonstrate **systematic evidence assessment** that supports confident regulatory approval and clinical adoption while establishing the foundation for ongoing post-market surveillance and clinical confidence. Well-executed clinical evaluation provides regulatory authorities with credible evidence for approval decisions, supports healthcare providers with clinical confidence in device performance, and establishes the evidence foundation for successful long-term market presence through demonstrated clinical value and safety performance.
# Complaints
Source: https://docs.withdovetail.com/regulatory-requirements/complaints
Establish systematic customer feedback management enabling quality improvement and regulatory compliance.
## Summary
Complaints establishes your **systematic approach to customer feedback management** by documenting and tracking all device-related complaints and negative product events. You implement structured complaint handling through the **Complaint Log** which serves as your central repository for complaint management, enabling regulatory compliance, trend analysis, and quality improvement activities throughout your post-market surveillance system.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Complaint files** required under Section 820.198 for all device-related complaints
* Must maintain records of **oral and written complaints** involving device failures
* **Investigation and evaluation** of complaints affecting device safety required
* **Medical Device Reports (MDRs)** under 21 CFR 803 for serious complaint-related incidents
* **Trend analysis** required to identify systematic quality problems
**Special attention required for:**
* Class III devices requiring enhanced complaint investigation procedures
* Software malfunctions that could affect patient safety or device effectiveness
* Repeat complaints indicating systematic quality issues requiring CAPA
* Use errors potentially related to design or labeling deficiencies
Under **EU MDR 2017/745**:
* **Complaint handling** required as part of quality management system (Article 10)
* Must comply with **EN ISO 13485:2016** complaint handling requirements
* **Serious incidents** identified through complaints must be reported to EUDAMED
* **Trend analysis** required for complaint pattern identification and prevention
* **Post-market surveillance** integration with complaint data analysis mandatory
**Special attention required for:**
* Serious incidents requiring immediate regulatory reporting (Article 87)
* Field Safety Corrective Actions based on complaint investigations
* Integration with vigilance system for incident assessment
* Clinical evaluation updates based on real-world use experience
## Overview
Complaints provides the **foundation for customer feedback management** by establishing systematic processes to capture, evaluate, and respond to all device-related concerns that could impact safety, performance, or regulatory compliance. This card ensures that customer communications alleging deficiencies in device quality, reliability, safety, effectiveness, or performance receive appropriate documentation, investigation, and resolution through your quality management system.
The **Complaint Log** serves as your **central repository** for tracking all complaints and negative product events while distinguishing them from general customer support inquiries that don't relate to device performance issues. This systematic documentation enables regulatory compliance by maintaining the comprehensive complaint files required under FDA QSR and EU MDR, while supporting post-market surveillance activities through trend analysis and pattern identification that can reveal emerging safety concerns or systematic quality issues.
The complaint management process provides **early warning signals** for potential safety issues by capturing real-world user experiences that may indicate design deficiencies, manufacturing problems, or labeling inadequacies. Unlike controlled clinical environments, complaints reveal how devices perform in diverse real-world conditions with varied user populations and use environments. This feedback enables proactive identification of issues before they escalate into serious incidents or widespread safety concerns.
**Complaint categorization and routing** ensures that different types of issues receive appropriate resolution processes based on their impact on device performance and safety. Software issues follow **Software Problem Resolution** procedures with systematic debugging and verification, product compliance issues trigger **Corrective and Preventive Action (CAPA)** investigations for root cause analysis, and design changes follow **Change Management** processes with proper impact assessment and regulatory evaluation.
The systematic approach to complaint handling integrates seamlessly with your **vigilance system** for incident assessment, **post-market surveillance** for trend analysis, **risk management** for hazard evaluation, and **clinical evaluation** for real-world performance validation. This integration ensures that customer feedback contributes to continuous improvement while maintaining the audit trail and documentation standards required for regulatory compliance.
Effective complaint management demonstrates your commitment to **customer safety** and **quality improvement** by showing that you systematically monitor user experiences, respond appropriately to concerns, and implement preventive measures to avoid recurrence. This systematic approach protects patients through early problem identification, maintains regulatory compliance through comprehensive documentation, and builds stakeholder confidence through responsive customer service and continuous product improvement.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/computer-system-validation
Validate computer systems ensuring software reliability and data integrity for quality management and regulatory compliance.
## Summary
Computer System Validation (CSV) ensures that **software systems critical to medical device quality** perform consistently and reliably according to their intended purpose. You must validate computer systems used in quality management, design controls, manufacturing processes, or regulatory compliance to demonstrate they maintain data integrity and produce accurate results throughout their operational lifecycle.
## Regulatory Context
Under **21 CFR Part 820.70(i)** (Production and Process Controls) and **21 CFR Part 11** (Electronic Records):
* **Computer software validation** required for systems used in production or quality management
* **Process validation** mandatory where output cannot be verified through subsequent inspection/test
* **Electronic record systems** must maintain data integrity and audit trail capabilities
* **Software change control** requires validation before approval and implementation
**Key Standards:**
* FDA Quality System Regulation (21 CFR Part 820)
* FDA General Principles of Software Validation guidance
* 21 CFR Part 11 Electronic Records and Electronic Signatures
* GAMP 5 guidelines for computer system validation approaches
**Special attention required for:**
* Design control software requiring validation as part of design and development processes
* Quality system software supporting document control, CAPA, and management review
* Manufacturing control systems affecting device production and testing
* Electronic signature systems requiring 21 CFR Part 11 compliance validation
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Computer system validation** required for systems affecting product quality or QMS effectiveness (ISO 13485 4.1.6)
* **Process validation** mandatory where output cannot be verified through monitoring/measurement
* **Risk management principles** apply to software validation approaches and ongoing maintenance
* **Documentation requirements** mandate procedures for software validation and revalidation
**Key Standards:**
* ISO 13485:2016 Medical devices - Quality management systems
* IEC 62304:2006 Medical device software - Software life cycle processes
* GAMP 5 Good Automated Manufacturing Practice guidelines
* EU GDPR for software processing personal data
**Special attention required for:**
* Cybersecurity validation requirements per MDCG 2019-16 guidance for connected systems
* EU GDPR compliance for software processing personal data in clinical or quality contexts
* Notified Body expectations for validated software supporting technical documentation
* Software lifecycle management when supporting clinical evaluation and post-market surveillance
## Overview
Computer System Validation represents the **technological backbone** of modern medical device quality assurance, ensuring that digital systems supporting critical quality and regulatory functions operate with the reliability and consistency required for patient safety and regulatory compliance. This card establishes comprehensive frameworks for validating, deploying, and maintaining computer systems that have become integral to medical device development, manufacturing, and lifecycle management.
### Digital Quality Infrastructure Validation
Your organization increasingly relies on **interconnected software systems** that automate quality management processes, support design and development activities, and enable regulatory compliance through electronic records and signatures. These systems require systematic validation to demonstrate they perform intended functions reliably while maintaining data integrity and supporting audit requirements throughout their operational lifecycle.
**Software validation strategies** must accommodate diverse system types ranging from commercial off-the-shelf (COTS) applications requiring configuration validation to custom-developed systems needing comprehensive development lifecycle verification. The validation approach balances **thorough verification** with **practical resource allocation**, ensuring critical systems receive appropriate validation rigor while avoiding unnecessary burden on low-risk applications.
**Validation documentation** provides audit-ready evidence that software systems supporting quality and regulatory activities have been systematically evaluated, tested, and approved for their intended use. This documentation transforms software deployment from informal technology adoption into **controlled quality system implementation** that demonstrates regulatory compliance and operational reliability.
### Risk-Based Validation Framework
Effective computer system validation requires **systematic risk assessment** that determines appropriate validation rigor based on software impact on device quality, patient safety, and regulatory compliance. **High-risk systems** affecting critical quality processes receive comprehensive validation including detailed testing and ongoing monitoring, while **lower-risk systems** may require basic functional verification without extensive documentation.
**GAMP 5 categorization principles** guide validation approaches by classifying software based on complexity and customization levels, from infrastructure software requiring minimal validation to bespoke applications needing full development lifecycle verification. This categorization ensures validation efforts align with actual risk and complexity rather than applying uniform approaches across diverse software types.
**Validation lifecycle management** extends beyond initial deployment to encompass ongoing system maintenance, version updates, and periodic revalidation activities. The lifecycle approach ensures software systems remain validated throughout their operational use, addressing changes that could affect validated functions or introduce new risks to quality or compliance.
### Integration with Quality System Processes
Computer system validation integrates deeply with **multiple quality management activities**, creating technological enablement for processes including document control, training management, corrective and preventive actions, and regulatory submissions. **Validated software systems** support rather than complicate quality processes, providing reliable tools that enhance efficiency while maintaining regulatory compliance.
**Change control procedures** ensure software modifications receive appropriate evaluation and validation before implementation, preventing uncontrolled changes that could compromise validated functions or introduce compliance risks. Change control connects software validation with broader quality system change management, ensuring technological changes align with quality objectives and regulatory requirements.
**Data integrity requirements** drive validation approaches that verify software systems maintain accurate, complete, and secure records throughout their lifecycle. Data integrity validation encompasses user access controls, audit trail functionality, backup and recovery procedures, and protection against unauthorized modifications that could compromise regulatory compliance or quality decision-making.
### Software Deployment and Operational Management
Successful computer system validation requires **comprehensive deployment planning** that considers system integration, user training, change management, and ongoing operational support. **Deployment strategies** balance rapid implementation with controlled validation, ensuring new systems enhance rather than disrupt existing quality processes while maintaining validation compliance.
**User training and competency management** ensure personnel operating validated systems understand their responsibilities for maintaining system integrity and compliance. Training programs address both technical system operation and regulatory requirements, creating competent users who support rather than compromise validation effectiveness through appropriate system use.
**Ongoing monitoring and maintenance** activities ensure validated systems continue performing as intended throughout their operational lifecycle. Monitoring encompasses system performance assessment, error log review, user feedback collection, and periodic validation review to identify potential issues before they affect quality or compliance.
### Technology Evolution and Validation Adaptation
The medical device industry's **rapid technology adoption** requires validation approaches that accommodate emerging technologies including cloud computing, artificial intelligence, cybersecurity tools, and integrated development environments. **Validation frameworks** must evolve to address new technology risks while maintaining fundamental principles of systematic verification and ongoing control.
**Cloud-based system validation** focuses on configuration verification, service level agreements, data security, and supplier assessment rather than traditional installation qualification approaches. Cloud validation emphasizes ongoing service monitoring and supplier relationship management while ensuring data protection and business continuity throughout service relationships.
**Software-as-a-Service (SaaS) validation** requires collaborative approaches with service providers, emphasizing configuration testing, integration verification, and ongoing service monitoring rather than underlying software development verification. SaaS validation balances reliance on supplier validation documentation with organization-specific verification of system configuration and intended use.
### Regulatory Compliance and Audit Readiness
Computer system validation documentation provides **essential audit evidence** demonstrating systematic control over software systems affecting medical device quality and regulatory compliance. **Audit preparation** emphasizes readily accessible validation records, comprehensive system inventories, and clear demonstration of ongoing validation maintenance rather than theoretical compliance claims.
**Regulatory submission support** requires validated systems for managing clinical data, design documentation, and regulatory correspondence. **Submission-ready validation** demonstrates that systems supporting regulatory activities maintain data integrity, provide appropriate security controls, and enable reliable document management throughout submission preparation and regulatory review processes.
**International regulatory harmonization** drives validation approaches that support multiple regulatory jurisdictions while avoiding duplicative validation efforts. **Harmonized validation** emphasizes core quality and safety principles rather than jurisdiction-specific technical requirements, enabling efficient global device development and commercialization strategies.
The computer system validation card establishes the **comprehensive technological foundation** for reliable medical device quality assurance, enabling digital transformation that enhances rather than complicates regulatory compliance while supporting efficient device development and lifecycle management.
# Declaration of Conformity
Source: https://docs.withdovetail.com/regulatory-requirements/declaration-of-conformity
Issue formal legal declaration certifying device compliance with EU requirements for market authorization.
## Summary
You must issue a formal legal declaration stating that your medical device complies with all applicable EU MDR requirements before placing it on the European market. The Declaration of Conformity serves as your official certification that demonstrates compliance with essential safety and performance requirements while providing the legal foundation for CE marking and commercial distribution.
## Regulatory Context
Under **EU MDR 2017/745** Article 19 and Annex IV, you must comply with:
* **Declaration of Conformity** mandatory per Article 19 before market placement
* **Annex IV content requirements** for declaration structure and information
* **Conformity assessment** completion per applicable annexes (IX, X, XI)
* **Technical documentation** supporting all conformity claims per Annex II
* **Basic UDI-DI** inclusion and EUDAMED registration per Article 27
**Special attention required for:**
* **Person Responsible for Regulatory Compliance** identification per Article 15
* **Notified body assessment** completion for higher-risk devices
* **Authorized representative** information for non-EU manufacturers per Article 11
* **CE marking validity** ensuring continued compliance with essential requirements
## Overview
The Declaration of Conformity represents your **formal legal commitment** to regulatory compliance by officially certifying that your medical device meets all applicable EU MDR requirements and can be safely placed on the European market. This critical document transforms your technical compliance activities into legal market authorization while establishing accountability for ongoing regulatory obligations and post-market performance.
**EU Declaration of Conformity Creation** requires systematic compilation of all compliance evidence into a formal legal statement that follows the mandatory structure defined in Annex IV of EU MDR 2017/745. The declaration process involves documenting your device identification information, manufacturer details, conformity assessment pathway, applied standards, and regulatory oversight arrangements while ensuring that all statements are supported by objective evidence in your technical documentation. Declaration creation requires careful attention to legal language and accuracy since this document represents your formal liability acceptance for device compliance and safety performance.
**Manufacturer Information Documentation** establishes your legal identity and accountability by providing complete details about your organization, regulatory contacts, and authorized representatives where applicable. Manufacturer information must include your legal company name and registered address, contact information for regulatory inquiries, identification of your Person Responsible for Regulatory Compliance (PRRC), and authorized representative details if you are not EU-based. This information enables regulatory authorities to establish clear accountability chains while providing contact mechanisms for post-market surveillance and regulatory communication.
**Device Identification and Classification** provides comprehensive technical details that enable regulatory authorities to understand your device's characteristics, intended use, and appropriate regulatory treatment. Device identification must include your product name, software version, Basic UDI-DI, intended purpose statement, device classification with rule justification, and EMDN code selection. Accurate device identification ensures that regulatory authorities can properly categorize your device while enabling effective post-market surveillance and market oversight activities.
**Conformity Assessment Documentation** establishes the regulatory pathway you followed to demonstrate compliance with EU MDR requirements while providing evidence that appropriate oversight was conducted. Conformity assessment documentation varies by device classification but includes identification of applicable conformity assessment annexes, notified body information for higher-risk devices, reference to supporting technical documentation, and confirmation that all required assessment activities were completed. This documentation provides regulatory authorities with confidence that systematic compliance verification was conducted according to established requirements.
**Applied Standards and Compliance Evidence** demonstrates your systematic approach to regulatory compliance by documenting all harmonized standards, technical specifications, and regulatory requirements that were applied during device development. Standards documentation includes comprehensive listing of applied harmonized standards such as EN ISO 13485, ISO 14971, and IEC 62304, explanation of how each standard supports compliance with specific essential requirements, and reference to verification evidence that demonstrates standards compliance. Complete standards documentation provides presumption of conformity while supporting regulatory review and post-market evaluation activities.
**Legal Signature and Authorization** establishes formal accountability by ensuring that appropriate personnel with legal authority take responsibility for compliance declarations and ongoing regulatory obligations. Signature requirements include identification of personnel with authority to bind the manufacturer legally, confirmation that signatories understand their regulatory responsibilities and potential liability, and documentation of signing authority through corporate governance structures. Proper signature authorization ensures that declaration commitments are legally binding while establishing clear accountability for ongoing compliance maintenance.
**Version Control and Maintenance** ensures that Declaration of Conformity documents remain current and accurate throughout your device's commercial lifecycle while supporting change control and regulatory communication requirements. Maintenance activities include establishing unique document identification and version control, implementing systematic review procedures for regulatory changes and device modifications, maintaining archives for required retention periods, and establishing procedures for declaration updates when necessary. Effective version control prevents compliance gaps while ensuring that regulatory authorities have access to current and accurate compliance documentation.
**Integration with CE Marking** establishes the direct connection between your Declaration of Conformity and your legal authorization to affix CE marking and place devices on the European market. CE marking integration includes verification that all declaration requirements are satisfied before marking application, confirmation that technical documentation supports all declaration statements, and establishment of procedures for maintaining marking validity throughout commercial distribution. Proper integration ensures that CE marking accurately reflects compliance status while preventing premature or invalid market placement.
**Post-Market Obligations Integration** ensures that your Declaration of Conformity commitments are supported by ongoing systems and procedures that maintain compliance throughout the commercial device lifecycle. Post-market integration includes establishment of surveillance systems that monitor continued compliance with declared requirements, procedures for updating declarations when device changes affect compliance status, and systems for communicating with regulatory authorities about compliance issues or changes. Effective post-market integration ensures that declaration commitments remain valid while supporting ongoing regulatory obligations and patient safety.
Your Declaration of Conformity activities must demonstrate **systematic regulatory compliance** while establishing the legal foundation for market authorization and commercial success. Well-executed declaration processes provide regulatory confidence, prevent market access delays, and establish credible accountability frameworks that support long-term commercial success while maintaining public trust in device safety and effectiveness.
# Deployment
Source: https://docs.withdovetail.com/regulatory-requirements/deployment
Manage software deployment risks ensuring safe operation in customer environments throughout lifecycle.
## Summary
You must systematically evaluate and manage the risks associated with deploying your medical device software in customer environments to ensure safe and effective operation throughout the deployment lifecycle. Deployment activities assess infrastructure complexity, establish installation procedures, implement monitoring systems, and document successful deployment to maintain device safety and performance in real-world environments.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation), you must implement:
* **Design validation** per Section 820.30(g) confirming device performance in intended use environment
* **Installation and servicing** per Section 820.200 ensuring controlled deployment procedures
* **Change control** per Section 820.40 for deployment configuration management
* **Post-market surveillance** per Section 820.100 monitoring deployment performance
* **Cybersecurity management** per FDA guidance for networked device deployment
**Special attention required for:**
* **Network security** requirements for connected devices in healthcare environments
* **Software validation** in intended use environment per FDA software guidance
* **Change control** for deployment configuration differences from development environment
* **Post-market surveillance** of deployment-related issues and performance degradation
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must comply with:
* **GSPR 17** ensuring software reliability and performance in intended use environment
* **Software development lifecycle** per EN 62304 including deployment planning and execution
* **Network security** per IEC 80001-1 for medical device network deployment
* **Post-market surveillance** per Article 83 monitoring deployment-related issues
* **Risk management** per ISO 14971 addressing deployment-specific risks
**Special attention required for:**
* **Infrastructure complexity** assessment for patient safety impact evaluation
* **Cybersecurity risk management** in customer deployment environments
* **Clinical evaluation** of software performance in real-world deployment settings
* **Incident reporting** for deployment-related safety issues and performance problems
## Overview
Deployment represents the **critical transition phase** where your medical device software moves from controlled development and testing environments into real-world customer operations where infrastructure complexity, user workflows, and environmental factors can significantly impact device safety and performance. This systematic deployment process ensures that real-world operating conditions support safe and effective device operation while establishing ongoing monitoring and support systems that maintain device performance throughout the commercial lifecycle.
**Deployment Evaluation and Risk Assessment** provides systematic evaluation of customer environments and deployment complexity to determine appropriate deployment procedures and risk controls. Deployment evaluation requires assessment of customer infrastructure complexity including network architecture, interdependencies, and potential failure modes that could affect device safety or performance. The evaluation process includes identification of deployment-specific risks that differ from development environment risks, determination of whether simplified or comprehensive deployment procedures are appropriate, and establishment of risk controls that address identified deployment hazards while maintaining operational efficiency.
**Customer Environment Assessment** establishes comprehensive understanding of each deployment environment including technical infrastructure, organizational factors, and operational workflows that may affect device performance. Environment assessment includes evaluation of technical infrastructure including network architecture, security policies, and integration requirements with existing systems. Assessment activities also address organizational factors including IT support capabilities, user training requirements, and change management procedures that affect successful deployment and ongoing operation.
**Installation Planning and Procedure Development** creates systematic approaches for deploying your device software in customer environments while minimizing risks and ensuring consistent installation quality. Installation planning requires development of deployment procedures that address customer-specific requirements, establishment of acceptance criteria that confirm successful installation and operation, and definition of rollback procedures for addressing installation issues. Planning activities include coordination with customer technical teams, scheduling of installation activities to minimize operational disruption, and preparation of installation documentation and support materials.
**Infrastructure Complexity Management** addresses the varying levels of technical and operational complexity across customer environments that may require different deployment approaches and risk controls. Complexity management includes systematic assessment of infrastructure interdependencies that could affect device operation, evaluation of backup and redundancy systems that support device availability, and assessment of technical support capabilities that enable ongoing device maintenance. Complex environments require more comprehensive deployment evaluation and enhanced monitoring procedures while simple environments may support streamlined deployment approaches.
**Installation Execution and Verification** ensures systematic deployment implementation that follows established procedures while providing objective evidence of successful installation and device readiness. Installation execution includes systematic implementation of planned deployment procedures, verification of installation success against established acceptance criteria, and documentation of any issues encountered and their resolution. Verification activities include testing of critical device functions in the deployment environment, confirmation of integration with customer systems, and validation of user access and authentication systems.
**Monitoring and Performance Management** establishes ongoing oversight systems that ensure deployed devices continue to operate safely and effectively while providing early warning of performance issues or safety concerns. Monitoring systems include automated monitoring capabilities that track device performance metrics and system health indicators, manual monitoring procedures that include regular communication with customer technical teams, and escalation procedures for addressing identified issues. Performance management requires establishment of key performance indicators that reflect device safety and effectiveness while providing systematic procedures for responding to performance degradation or system issues.
**Technical Support and Maintenance** provides ongoing support capabilities that enable effective resolution of deployment issues while maintaining device performance throughout the operational lifecycle. Support activities include establishment of technical support contact procedures and escalation paths, development of troubleshooting guides and common issue resolution procedures, and coordination with customer IT teams for system maintenance and updates. Effective support systems prevent minor issues from escalating into safety concerns while ensuring that customer operations continue smoothly.
**Change Management and Update Procedures** ensures that software updates and configuration changes are properly managed in deployed environments while maintaining device safety and performance. Change management includes establishment of procedures for communicating and coordinating software updates with customer teams, implementation of testing and validation procedures for updates in deployment environments, and documentation of change control procedures that maintain traceability and regulatory compliance. Effective change management prevents uncontrolled modifications while enabling necessary updates and improvements.
**Cybersecurity and Network Security Management** addresses the unique security challenges of deploying medical device software in customer network environments while maintaining device functionality and data protection. Security management includes assessment of customer network security policies and their compatibility with device requirements, implementation of device security controls that address network-based threats, and coordination with customer security teams for ongoing security monitoring and incident response. Security considerations require balance between robust protection and operational functionality while ensuring compliance with applicable cybersecurity requirements.
**Documentation and Regulatory Compliance** ensures that deployment activities are properly documented and maintained to support regulatory obligations and ongoing compliance verification. Documentation requirements include comprehensive deployment records that document installation procedures and verification results, maintenance of deployment-specific risk assessments and control measures, and establishment of procedures for reporting deployment-related incidents or safety issues. Effective documentation supports regulatory compliance while providing evidence of systematic deployment management and ongoing safety oversight.
Your deployment activities must demonstrate **systematic risk management** and **comprehensive support systems** that ensure safe and effective device operation in real-world customer environments while maintaining regulatory compliance and supporting ongoing commercial success. Well-executed deployment processes provide customers with confidence in device reliability and safety, enable effective technical support and maintenance, and establish the operational foundation for successful long-term device utilization through systematic deployment management and ongoing performance monitoring.
# Design
Source: https://docs.withdovetail.com/regulatory-requirements/design
Transform requirements into implementable solutions defining architecture, components and technical specifications.
## Summary
You must create detailed design specifications that transform your product requirements into implementable solutions, defining the architecture, components, interfaces, and technical details needed to build your medical device. Design activities establish the blueprint that enables manufacturing and verification while ensuring regulatory compliance and patient safety.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), you must implement:
* **Design outputs** that meet all design input requirements
* **Documented design specifications** enabling manufacturing and verification
* **Design review** before proceeding to verification activities
* **Software architecture** documentation per IEC 62304 for software devices
* **Risk control implementation** integrated into design specifications
**Special attention required for:**
* **Software as Medical Device** architecture and SOUP management
* **Cybersecurity by design** implementation per FDA guidance
* **Biocompatibility assessment** for patient-contacting materials per ISO 10993
* **Electromagnetic compatibility** (EMC) considerations for all electronic devices
Under **EU MDR 2017/745** and **EN ISO 13485:2016** Section 7.3.5, you must comply with:
* **Design outputs** meeting all General Safety and Performance Requirements
* **Complete technical documentation** supporting conformity assessment
* **Software lifecycle processes** per IEC 62304 for software-containing devices
* **Risk management integration** per EN ISO 14971:2019 throughout design
* **Clinical evaluation planning** considerations in design specifications
**Special attention required for:**
* **Material biocompatibility** assessment per EN ISO 10993 series
* **Software cybersecurity** requirements per MDR Article 17
* **Unique Device Identification** (UDI) integration in design planning
* **Post-market surveillance** considerations influencing design decisions
## Overview
Design represents the **creative transformation** of your product requirements into tangible, implementable solutions that define exactly how your medical device will be built, operate, and deliver its intended medical benefits. This comprehensive process bridges the gap between what your device must do and how it will actually accomplish those functions through systematic architecture definition and detailed specification development.
**Software Architecture** establishes the foundational structure for software-containing devices by defining software items, their interconnections, deployment infrastructure, and security frameworks. The architecture must demonstrate systematic organization that supports your device's safety classification under IEC 62304 while enabling verification activities and ongoing maintenance. Your software design must address scalability, reliability, and cybersecurity from the ground up, incorporating risk control measures as integral features rather than add-on protections. The architecture serves as the blueprint that guides all software development activities and provides the framework for managing Software of Unknown Provenance (SOUP) components safely.
**SOUP management** represents a critical subset of software design that requires systematic identification, assessment, and control of all third-party software components integrated into your device. Each SOUP item must be evaluated for patient safety impact, documented with specific version control, and monitored for security vulnerabilities throughout the device lifecycle. SOUP risk classifications drive verification requirements and ongoing monitoring procedures, ensuring that external dependencies don't compromise device safety or effectiveness.
**Interface Design** defines how users interact with your device and how different system components communicate with each other. User interfaces must support safe, effective use while minimizing use-related risks identified in your risk assessment. Technical interfaces between hardware and software components require precise specification of communication protocols, data formats, timing requirements, and error handling to ensure reliable operation and maintainability.
**Hardware design activities** encompass mechanical, electrical, firmware, and packaging specifications that transform functional requirements into physical components. Mechanical design must address structural integrity, environmental resistance, and user ergonomics while ensuring manufacturability and serviceability. Electrical design requires consideration of power management, signal integrity, electromagnetic compatibility, and safety isolation. Firmware design bridges hardware and software domains, requiring careful attention to real-time constraints, safety-critical functions, and update mechanisms.
**Packaging and shelf-life design** ensure your device reaches users in safe, effective condition and maintains its performance throughout the intended storage and use periods. Design considerations include environmental protection, sterility maintenance (where applicable), labeling requirements, and degradation prevention mechanisms that support your device's intended shelf life and operational lifetime.
The **integrated nature** of design activities requires careful coordination between different engineering disciplines to ensure that hardware, software, mechanical, and user interface components work together seamlessly. Design decisions in one area often impact other components, requiring systematic impact assessment and traceability maintenance throughout the design process.
**Design verification planning** begins during design specification by establishing clear criteria for confirming that design outputs meet design inputs. Each design element must include verification methods that can objectively demonstrate compliance with requirements, supporting efficient transition to verification and validation phases.
**Risk control integration** ensures that safety measures identified in your risk management process are built into the design rather than relying on external protections or user training. Design-level risk controls are typically more effective and reliable than protective measures or information for safety, contributing to overall device safety and user confidence.
Your design activities must balance **innovation with regulatory compliance**, creating solutions that meet user needs effectively while adhering to applicable standards and regulations. Well-executed design reduces verification complexity, manufacturing costs, and regulatory approval timelines while establishing the foundation for successful commercial deployment and ongoing maintenance throughout the device lifecycle.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/design-and-development-plans
Establish systematic development frameworks ensuring regulatory compliance and traceability throughout product lifecycles.
## Summary
Design and development plans establish your systematic approach to transforming user needs into compliant medical devices. These plans define the framework for both software and hardware development, ensuring traceability, risk management, and regulatory compliance throughout your product lifecycle while preventing costly rework and documentation gaps.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), the FDA requires:
* **Documented development planning** describing design activities and responsibilities
* **Software lifecycle processes** following IEC 62304 consensus standard
* **Hardware development approach** with systematic materials selection and verification
* **Risk management integration** throughout development phases
* **Design History File (DHF)** documentation for all activities
**Standards applicable:**
* IEC 62304:2006 - Medical device software lifecycle processes
* ISO 14971:2019 - Application of risk management to medical devices
* ISO 13485:2016 - Medical devices quality management systems
* IEC 60601-1 - Medical electrical equipment safety (if applicable)
**Special attention required for:**
* Software safety classification accuracy - misclassification leads to inadequate development rigor
* SOUP vulnerability management and ongoing monitoring for software components
* Biocompatibility testing requirements for hardware materials in patient contact
* Cybersecurity considerations per FDA guidance for connected devices
Under **EU MDR 2017/745**, development planning must comply with:
* **EN ISO 13485:2016** Section 7.3 for design and development planning
* **IEC 62304:2006/AMD 1:2015** for software lifecycle processes
* **Annex I GSPRs** driving hardware design requirements
* **MDCG 2019-11 Guidance** for software qualification and classification
**Standards applicable:**
* EN ISO 13485:2016 - Medical devices quality management systems
* IEC 62304:2006/AMD 1:2015 - Medical device software lifecycle processes
* EN 62366-1:2015 - Usability engineering for medical devices
* ISO 10993 series - Biological evaluation of medical devices
* IEC 60601-1:2005+A1:2012 - Medical electrical equipment safety
**Special attention required for:**
* Software as Medical Device (SaMD) classification impact on clinical evidence requirements
* AI/ML software considerations per emerging MDCG guidance
* Person Responsible for Regulatory Compliance (PRRC) oversight of development changes
* Post-market surveillance integration for ongoing safety monitoring
## Overview
Design and development plans serve as your **regulatory roadmap** for creating compliant medical devices by establishing structured processes that transform user needs into market-ready products. These plans are essential for demonstrating to regulatory authorities that your development follows recognized standards while ensuring your team has clear guidance throughout the product lifecycle.
The **Software Development and Maintenance Plan** addresses the unique challenges of medical device software development. This plan establishes your approach to software safety classification according to IEC 62304, defines development lifecycle methodology, and implements risk-based development processes. It covers critical areas including configuration management, Software of Unknown Provenance (SOUP) management, verification strategies, and post-market maintenance procedures. The plan ensures your software development generates the documentation needed for regulatory submissions while maintaining traceability from user needs through implementation to verification activities.
Your **Hardware Design and Development Plan** provides the framework for designing physical device components that meet safety, performance, and regulatory requirements. This plan addresses materials selection with biocompatibility considerations, component sourcing and qualification, prototype development strategies, and comprehensive verification testing approaches. It establishes clear development phases from conceptual design through manufacturing transfer, ensuring hardware components meet their intended specifications while maintaining safety throughout the device service life.
Both plans integrate **risk management activities** throughout development, ensuring identified hazards are systematically addressed through design controls and verification activities. They establish clear team responsibilities across functional groups while defining interfaces between software and hardware development activities. The plans also address configuration management and change control processes that maintain design integrity as your device evolves.
These development plans work together to create a **comprehensive framework** that addresses the complexities of modern medical device development. They ensure your development activities generate the evidence needed for regulatory submissions while preventing the common pitfalls of unstructured development that lead to compliance gaps, missed requirements, and costly rework. The plans also establish the foundation for ongoing product maintenance and post-market surveillance activities that ensure continued compliance throughout your device's market life.
The structured approach defined in these plans provides **regulatory confidence** by demonstrating your development follows established best practices and recognized standards. This systematic methodology helps you manage development complexity while ensuring all regulatory requirements are addressed consistently and thoroughly throughout your product development process.
# Design Stage Checklists
Source: https://docs.withdovetail.com/regulatory-requirements/design-stage-checklists
Conduct systematic design reviews ensuring completeness and regulatory compliance before verification activities.
## Summary
You must conduct systematic design reviews using structured checklists to verify that your medical device design is complete, compliant, and ready for verification and validation activities. Design stage checklists provide objective criteria to confirm that all design inputs are properly implemented and regulatory requirements are met before proceeding to testing phases.
## Regulatory Context
Under **21 CFR Part 820.30(e)** (Design Controls), you must implement:
* **Mandatory design review** conducted by qualified individuals not directly responsible for design
* **Documented evidence** that design outputs meet design inputs and user needs
* **Systematic evaluation** of design completeness before verification activities
* **Objective criteria** for determining design readiness and regulatory compliance
* **Review records** maintained as evidence of design control execution
**Special attention required for:**
* **Software medical devices** requiring IEC 62304 compliance verification
* **Risk management integration** confirmation per ISO 14971 standards
* **Cybersecurity design** validation per FDA cybersecurity guidance
* **Design input validation** against user needs and intended use requirements
Under **EU MDR 2017/745** and **EN ISO 13485:2016** Section 7.3.4, you must comply with:
* **Design review requirements** ensuring General Safety and Performance Requirements compliance
* **Technical documentation preparation** supporting conformity assessment procedures
* **Systematic design evaluation** before proceeding to verification and validation
* **Quality management system** integration per Article 10(9) requirements
* **Risk management verification** per EN ISO 14971:2019 throughout design process
**Special attention required for:**
* **GSPR compliance verification** through systematic design review
* **Clinical evaluation planning** integration with design completeness assessment
* **Software lifecycle processes** compliance per IEC 62304 for software devices
* **Post-market surveillance** preparation through design review activities
## Overview
Design stage checklists serve as **critical quality gates** that systematically verify your medical device design is complete, compliant, and ready for the verification and validation phases that follow. These structured evaluations prevent costly rework by identifying missing requirements, incomplete designs, or regulatory compliance gaps before you invest significant resources in testing and validation activities.
**Design Review Checklists** provide comprehensive evaluation frameworks that examine your design from multiple perspectives to ensure regulatory compliance and development readiness. The review process requires systematic examination of design completeness, requirement implementation, and regulatory alignment using objective criteria that eliminate subjective decision-making. These checklists transform abstract design control requirements into concrete evaluation steps that provide clear evidence of compliance for regulatory submissions.
**General design review** focuses on fundamental design control requirements by verifying that user needs are properly translated into design inputs and that design outputs adequately address all specified requirements. The review confirms that your development process maintains proper traceability from user needs through design implementation, ensuring that every aspect of your device's intended functionality is deliberately planned and implemented. Critical elements include verification that risk control measures from your risk management process are integrated into the design rather than relying solely on protective measures or user information.
**Software architecture review** addresses the specialized requirements for software-containing medical devices by confirming compliance with IEC 62304 software lifecycle processes. The review verifies that your software architecture implements all system and software requirements with appropriate safety classification and that all software items and interfaces are properly documented. For devices containing Software of Unknown Provenance (SOUP), the review confirms that third-party components are properly integrated, assessed, and controlled according to regulatory requirements.
**Physical product review** evaluates hardware components to ensure that design specifications support manufacturing, assembly, and testing requirements. The review confirms that material selection meets biocompatibility and durability requirements, that design addresses environmental and safety factors comprehensively, and that packaging and shelf-life considerations support the intended product lifecycle. Even primarily software-based devices often require physical product considerations for deployment hardware and user interaction components.
**Regulatory compliance verification** ensures that your design addresses all applicable standards and regulations before proceeding to verification activities. The review confirms that design inputs align with regulatory requirements, that applicable standards are properly implemented, and that design outputs provide sufficient specification detail to enable comprehensive verification and validation testing.
**Risk control implementation** represents a critical aspect of design review that verifies safety measures identified in your risk management process are properly integrated into design specifications. The review confirms that hazards are controlled through design features rather than relying primarily on protective equipment or user training, which provides more reliable and effective risk mitigation.
**Documentation completeness** assessment ensures that your design specifications provide sufficient detail to enable manufacturing, testing, and regulatory review. The review verifies that design documents include all necessary technical specifications, interface definitions, performance criteria, and verification requirements needed for successful product development and regulatory approval.
**Resource and timeline validation** confirms that your design can be implemented with available resources, technical capabilities, and schedule constraints. The review identifies potential implementation challenges early, enabling proactive risk mitigation and realistic project planning for subsequent development phases.
The **systematic nature** of design stage checklists provides objective evidence that your design process was thorough and compliant, supporting regulatory submissions and demonstrating due diligence in device safety and effectiveness considerations. Well-executed design reviews reduce verification complexity, prevent late-stage design changes, and increase confidence in regulatory approval success by ensuring that fundamental design issues are resolved before testing begins.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/device-characteristics-and-classification
Define device characteristics and determine regulatory classification establishing your certification strategy and pathway.
## Summary
Defining your device characteristics and determining its regulatory classification forms the **foundation of your entire certification strategy**. This critical step establishes your regulatory pathway, determines required documentation depth, and influences every subsequent decision in your medical device development process. Your device's intended use statement and classification assignment directly impact timelines, costs, and market access requirements across both EU and US jurisdictions.
## Regulatory Context
Under **21 CFR Parts 862-892** and **Federal Food, Drug, and Cosmetic Act Section 513**:
* **Device classification** determines Class I, II, or III assignment based on intended use and risk profile
* **Product codes** drive regulatory pathway selection (510(k), PMA, De Novo)
* **Predicate device identification** establishes substantial equivalence framework for Class II devices
* **Intended use statements** must align with FDA-cleared indications and clinical evidence
**Special attention required for:**
* Software medical devices - classification based on clinical decision-making impact, not technical complexity
* AI/ML algorithms - limited predicates available, may require De Novo pathway establishment
* Novel technologies - absence of appropriate predicates necessitates De Novo pathway consideration
* Combination products - each component requires separate classification analysis
Under **EU MDR 2017/745, Annex VIII** and **EU IVDR 2017/746, Annex VIII**:
* **Classification rules** are mandatory and rule-based for medical devices (Class I, IIa, IIb, III)
* **IVDR classification** follows separate rules for in vitro diagnostics (Class A, B, C, D)
* **Intended purpose** drives Annex VIII rule application and conformity assessment procedures
* **Notified body involvement** required for higher classifications (IIb, III, IVDR C/D)
**Special attention required for:**
* Multiple rule applicability - strictest rule resulting in highest classification must be applied
* Software medical devices - Rule 11 classification based on clinical decision impact
* Active implantable devices - automatically Class III under Rule 9
* Companion diagnostics - typically IVDR Class C with extensive clinical performance requirements
## Overview
Device characteristics and classification encompasses five interconnected tasks that establish your regulatory foundation. **Your intended use statement** serves as the cornerstone document that defines your device's medical purpose, patient population, and clinical application scope. This statement drives all subsequent classification decisions and regulatory requirements, making its precision absolutely critical for successful certification.
**Classification under FDA regulations** focuses on product code assignment based on intended use rather than physical characteristics. Your product code determines whether you pursue 510(k) clearance, PMA approval, or De Novo pathway establishment. The classification process requires systematic evaluation of existing device categories and careful analysis of your device's clinical application within established regulatory frameworks.
**Predicate device identification** becomes essential for Class II devices pursuing 510(k) clearance, as substantial equivalence forms the basis for FDA authorization. Your predicate selection influences required testing protocols, acceptable performance specifications, and regulatory review timeline. Multiple predicates may be necessary when no single device provides adequate technological or clinical comparison.
**EU MDR classification** follows a fundamentally different approach using rule-based analysis from Annex VIII. Your classification depends on intended purpose, invasiveness, duration of use, and body interaction characteristics. The systematic application of implementing rules determines your conformity assessment procedure and notified body requirements, with higher classifications demanding more extensive clinical evidence and quality management system compliance.
**IVDR classification** applies specifically to in vitro diagnostic devices using separate rules focused on clinical significance rather than physical characteristics. The classification considers the consequences of incorrect results on patient management, with companion diagnostics, genetic testing, and blood grouping typically requiring higher classifications and notified body involvement.
These classification decisions fundamentally shape your regulatory strategy because they determine the depth of clinical evidence required, the extent of quality management system compliance needed, and the timeline for market access. Higher classifications across both jurisdictions require more extensive documentation, longer review processes, and ongoing post-market surveillance obligations. Understanding these implications early in development allows for strategic planning of resources, timelines, and clinical development programs.
The interconnection between intended use and classification creates cascading effects throughout your certification process. Your intended use scope directly influences classification outcomes, which in turn determine your testing requirements, clinical evidence needs, and labeling obligations. Strategic decisions about intended use breadth must balance market access goals with regulatory burden and development timelines.
Software and artificial intelligence components add complexity to both intended use definition and classification processes. These technologies require careful analysis of clinical decision-making impact, algorithm validation requirements, and performance monitoring obligations. The evolving regulatory landscape for digital health technologies demands particular attention to guidance documents and precedent devices when establishing your regulatory approach.
Classification also affects your business model and market access strategy. Higher classifications typically require longer development timelines, more extensive clinical programs, and greater regulatory expertise. However, they may also provide stronger competitive protection and broader market applications. Understanding these trade-offs enables informed strategic decision-making during device development planning.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/establish-quality-management-system
Implement comprehensive quality management systems that ensure regulatory compliance and operational excellence for medical devices.
## Summary
Establishing a **Quality Management System (QMS)** forms the regulatory foundation of your medical device company, providing systematic procedures that control every aspect of your device lifecycle from design through post-market surveillance. Your QMS demonstrates to regulatory authorities that you have consistent processes, defined responsibilities, and measurable quality objectives that ensure patient safety and regulatory compliance.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Quality management system is **mandatory** for all medical device manufacturers
* Must establish **document and record controls** (820.40) for all QMS procedures
* **Management responsibility** requirements (820.20) including designated management representative
* Design controls (820.30) required for Class II and III devices
* Manufacturing controls (820.70) and corrective/preventive actions (820.100)
**Special attention required for:**
* Responsible Corporate Officer Doctrine - executives remain personally liable for QMS failures
* Design History File maintenance for devices subject to design controls
* Electronic record compliance (21 CFR Part 11) if using electronic QMS systems
* Software medical devices require integrated software lifecycle procedures (IEC 62304)
Under **EU MDR 2017/745**:
* Quality management system **required** for all manufacturers (Article 10(9))
* Must comply with **EN ISO 13485:2016** harmonized standard requirements
* Person Responsible for Regulatory Compliance (PRRC) integration mandatory
* Technical file maintenance throughout device lifecycle (Article 11)
* Post-market surveillance system integration (Articles 83-86)
**Special attention required for:**
* Notified body QMS assessment requirements for higher-risk devices
* Clinical evaluation and post-market clinical follow-up integration
* UDI system compliance and EUDAMED registration requirements
* Authorized representative roles for non-EU manufacturers
## Overview
Your **Quality Management System establishment** involves creating and implementing comprehensive procedures that form the backbone of regulatory compliance and operational excellence. This foundational card encompasses **27 critical tasks** that collectively establish your systematic approach to quality management, from high-level policy documents to detailed operational procedures.
The **Quality Manual and Policy Objectives** serves as your QMS cornerstone, establishing organizational commitment, management structure, and measurable quality targets that guide all subsequent activities. This foundational document demonstrates to regulators and stakeholders that your organization has systematic leadership and clear accountability for quality outcomes.
**Document and Record Control** procedures establish the critical infrastructure for managing all quality documentation throughout its lifecycle. These procedures ensure that teams always use current, approved versions of procedures while maintaining complete traceability and audit trails required for regulatory compliance and effective change management.
Your **Design Control** procedures provide the systematic framework for medical device development, ensuring that products meet user needs and regulatory requirements through controlled design inputs, outputs, verification, validation, and transfer processes. This structured approach transforms device development from ad-hoc engineering into a regulated process that builds regulatory confidence.
**Software-specific procedures** address the unique challenges of software medical devices through integrated development lifecycles, problem resolution, validation, and cybersecurity management. These procedures ensure that software development follows recognized standards like IEC 62304 while maintaining compatibility with overall quality management requirements.
**Risk Management** procedures integrate systematic hazard identification, risk assessment, and control measures throughout your device lifecycle. These procedures ensure compliance with ISO 14971 while providing practical frameworks for identifying, evaluating, and mitigating risks before they impact patients or business operations.
**Human Resources and Training** procedures establish competency requirements, training programs, and personnel qualifications that ensure your team has the knowledge and skills necessary for quality-critical activities. These procedures address both initial training and ongoing competency maintenance throughout employee tenure.
**Operational procedures** cover critical business processes including manufacturing controls, purchasing and supplier management, sales activities, and deployment procedures. These procedures ensure that business operations maintain quality standards while supporting efficient commercial activities and regulatory compliance.
**Change Management** procedures provide systematic approaches for evaluating, implementing, and monitoring changes to products, processes, or quality systems. These procedures ensure that changes undergo appropriate risk assessment and approval before implementation while maintaining complete traceability for regulatory purposes.
**Post-market procedures** establish comprehensive systems for monitoring device performance, managing customer feedback, implementing corrective and preventive actions, and conducting regulatory vigilance activities. These procedures ensure ongoing safety monitoring and continuous improvement throughout your device's commercial lifecycle.
**Clinical and Performance Evaluation** procedures define systematic approaches for demonstrating clinical safety and performance throughout development and post-market phases. These procedures ensure that clinical evidence generation meets regulatory requirements while supporting marketing claims and safety monitoring.
**Internal Audit procedures** establish independent assessment capabilities that verify QMS effectiveness and regulatory compliance. These procedures provide systematic approaches for conducting audits, managing findings, and implementing improvements that strengthen your quality management system.
**Regulatory Management** procedures ensure systematic tracking of regulatory requirements, product registration activities, and certification maintenance. These procedures provide frameworks for staying current with evolving regulations while maintaining compliance across multiple jurisdictions and product lines.
Each procedure within this comprehensive framework connects to create an **integrated quality management system** that supports efficient operations while ensuring regulatory compliance. The procedures establish clear roles, responsibilities, and interfaces between different organizational functions while providing practical guidance for daily activities. Your implementation approach should prioritize core procedures first, then systematically build additional capabilities as your organization grows and product portfolio expands.
This systematic approach transforms quality management from a compliance burden into a **strategic enabler** that supports business growth, regulatory confidence, and ultimately better patient outcomes through safer, more effective medical devices.
# FDA Registration
Source: https://docs.withdovetail.com/regulatory-requirements/fda-registration
Complete establishment registration and device listing establishing legal FDA presence for US market.
## Summary
You must complete FDA Registration and Listing to establish your legal presence in the FDA database and obtain authorization to manufacture, import, or distribute medical devices in the United States. This mandatory process includes establishment registration, device listing, and maintenance of current information that enables FDA oversight and regulatory communication throughout your device's commercial lifecycle.
## Regulatory Context
Under **21 CFR Part 807** (Establishment Registration and Device Listing), you must comply with:
* **Annual registration** per Section 807.20 for all device establishments
* **Device listing** per Section 807.25 for all marketed devices
* **US Agent designation** per Section 807.40 for foreign establishments
* **Registration renewal** per Section 807.22 annually between October 1 and December 31
* **Premarket notification** per Section 807.81 for most Class II devices before marketing
**Special attention required for:**
* **Foreign establishments** must designate qualified US Agent for FDA communications
* **Software as Medical Device** classification and appropriate product code selection
* **Combination products** requiring coordination with other FDA centers
* **Export-only manufacturers** having different registration requirements than domestic marketers
## Overview
FDA Registration and Listing establishes the **fundamental regulatory foundation** for medical device marketing in the United States by creating your official presence in FDA databases while enabling regulatory oversight, communication, and market surveillance activities. This essential regulatory process transforms your organization from unrecognized entity to officially registered medical device establishment with specific rights and obligations under FDA jurisdiction.
**Establishment Registration Process** creates your official FDA presence by registering your company as a medical device establishment with appropriate activity designations and contact information. Registration process requires completion of electronic registration through FDA systems including provision of complete business information, designation of establishment activities such as manufacturing or importing, and establishment of communication protocols with FDA. Foreign establishments must additionally designate qualified US Agents who serve as primary FDA communication points and have authority to represent the company in regulatory matters including inspection scheduling and regulatory correspondence.
**Device Listing and Classification** establishes official recognition of your specific medical devices within FDA databases while confirming appropriate regulatory classification and product codes. Device listing requires accurate device identification including proprietary names, common names, and intended use statements that clearly define device scope and limitations. Classification activities include determination of appropriate FDA product codes based on device technology and intended use, confirmation of device class designation that determines regulatory requirements, and identification of applicable predicate devices for substantial equivalence demonstration when required.
**US Agent Designation and Management** ensures effective FDA communication for foreign establishments through qualified representatives who understand FDA requirements and can facilitate regulatory interactions. US Agent management requires selection of qualified individuals or organizations with appropriate FDA knowledge and authority to represent your company, establishment of clear communication protocols and responsibilities including inspection coordination and regulatory correspondence, and maintenance of current contact information and availability during normal business hours for FDA interactions.
**Premarket Submission Coordination** aligns registration and listing activities with required premarket submissions including 510(k) clearance, PMA approval, or De Novo classification while ensuring regulatory pathway optimization. Submission coordination requires understanding of device classification requirements that determine premarket submission needs, preparation of substantial equivalence demonstrations for 510(k) submissions including predicate device identification and comparison, and coordination of submission timing with registration and listing activities to enable efficient market entry.
**Annual Renewal and Maintenance** ensures continued registration validity through timely renewal and updates while maintaining current information in FDA databases throughout the commercial device lifecycle. Renewal activities include completion of annual registration renewal between October 1 and December 31, updates to device listings when significant changes occur including new device versions or modifications, and maintenance of current contact information and establishment activity designations that reflect actual business operations.
**Design History File Integration** connects FDA registration requirements with comprehensive design control documentation that supports premarket submissions and ongoing regulatory compliance. DHF integration requires compilation of complete design control records including design inputs, outputs, reviews, verification, validation, and transfer documentation that demonstrates systematic device development. Integration activities ensure that DHF contents support registration requirements while providing comprehensive evidence for premarket submissions and regulatory inspections.
**Software Device Considerations** addresses unique registration requirements for software medical devices including appropriate classification, product code selection, and regulatory pathway determination. Software considerations require understanding of Software as Medical Device (SaMD) classification frameworks, selection of appropriate product codes that reflect software functionality and intended use, and coordination with FDA software guidance requirements including lifecycle documentation and cybersecurity considerations that affect registration and submission requirements.
**Post-Market Reporting Integration** establishes connections between registration requirements and ongoing post-market surveillance obligations including adverse event reporting and periodic reporting. Reporting integration requires implementation of Medical Device Reporting (MDR) procedures for adverse events, malfunctions, and deaths associated with registered devices, establishment of post-market surveillance systems that monitor device performance and safety, and coordination with registration maintenance activities that ensure continued compliance with FDA requirements.
**Multi-Product and Multi-Site Management** addresses complexities of managing registration and listing for organizations with multiple devices, manufacturing sites, or business activities while ensuring comprehensive compliance and efficient administration. Multi-site management requires coordination of registration activities across different establishments and locations, management of device listings for product portfolios with varying regulatory requirements, and implementation of systematic procedures that ensure consistent compliance across all registered activities and locations.
**Regulatory Communication and Inspection Readiness** ensures effective interaction with FDA through proper registration channels while maintaining readiness for regulatory inspections and inquiries. Communication readiness requires establishment of systematic procedures for responding to FDA correspondence and inspection requests, maintenance of registration documentation and supporting materials in readily accessible formats, and implementation of internal audit procedures that ensure ongoing registration compliance and inspection readiness.
Your FDA Registration activities must demonstrate **systematic regulatory compliance** while establishing the legal foundation necessary for confident US market entry and ongoing commercial success. Well-executed registration processes provide FDA with accurate information for effective oversight, enable efficient regulatory communication and submission review, and establish the compliance foundation for successful long-term market presence through demonstrated adherence to fundamental FDA requirements and professional regulatory management.
# FDA Submission
Source: https://docs.withdovetail.com/regulatory-requirements/fda-submission
Prepare comprehensive premarket submissions demonstrating safety and effectiveness for FDA clearance.
## Summary
You must prepare and submit appropriate premarket applications to FDA to obtain marketing authorization for your medical device in the United States through 510(k) clearance, PMA approval, or De Novo classification pathways. This comprehensive submission process demonstrates substantial equivalence, safety and effectiveness, or establishes new device classifications while providing FDA with evidence necessary for confident marketing authorization decisions.
## Regulatory Context
Under **21 CFR Part 807** (Premarket Notification) and **21 CFR Part 814** (PMA), you must comply with:
* **510(k) clearance** per Section 807.81 for most Class II devices demonstrating substantial equivalence
* **PMA approval** per Part 814 for Class III devices requiring safety and effectiveness evidence
* **De Novo classification** per Section 807.85 for novel devices without appropriate predicates
* **eSTAR electronic submission** per Section 807.87 using FDA electronic submission systems
* **User fee payment** per MDUFA requirements accompanying submission
**Special attention required for:**
* **Software validation** per FDA software guidance requiring comprehensive lifecycle documentation
* **Cybersecurity considerations** per FDA premarket cybersecurity guidance for networked devices
* **Clinical data requirements** varying by device classification and intended use
* **Predicate device comparison** ensuring appropriate substantial equivalence demonstration
## Overview
FDA Submission represents the **culminating regulatory activity** that transforms completed device development into market-ready medical devices through comprehensive demonstration of safety, effectiveness, and regulatory compliance to FDA reviewers. This critical submission process requires systematic compilation of technical evidence, clinical data, and regulatory documentation that enables FDA to make confident marketing authorization decisions while establishing the regulatory foundation for successful US commercial launch.
**Submission Pathway Determination** establishes the appropriate regulatory route for your device based on classification, risk profile, and predicate device availability while optimizing regulatory efficiency and approval probability. Pathway determination requires comprehensive analysis of device characteristics and intended use to confirm appropriate classification, systematic evaluation of available predicate devices to assess substantial equivalence potential, and assessment of clinical data requirements that vary significantly between 510(k), PMA, and De Novo pathways. Effective pathway selection balances regulatory requirements with development resources while ensuring optimal approval probability and time to market.
**510(k) Submission Preparation** demonstrates substantial equivalence to legally marketed predicate devices through systematic comparison of intended use, technological characteristics, and performance data. 510(k) preparation requires identification and analysis of appropriate predicate devices that share similar intended use and technological characteristics, comprehensive comparison across safety and effectiveness parameters including bench testing, software validation, and clinical evidence where required. Submission development includes preparation of clear and concise equivalence arguments, compilation of supporting technical data and testing evidence, and presentation of information in formats that facilitate efficient FDA review and approval.
**Clinical Data Strategy and Integration** provides appropriate clinical evidence to support safety and effectiveness claims while addressing FDA reviewer expectations and regulatory requirements. Clinical strategy requires assessment of clinical data requirements based on device classification and novelty, integration of clinical evaluation findings with FDA submission requirements, and presentation of clinical evidence in formats that support regulatory decision-making. Clinical integration ensures that clinical data directly addresses intended use claims while providing adequate evidence for FDA reviewer confidence in device safety and effectiveness.
**Technical Documentation Compilation** organizes comprehensive technical evidence including design controls, risk management, verification and validation, and manufacturing information into coherent submission packages. Documentation compilation requires systematic organization of Design History File contents into FDA submission format, integration of risk management findings with safety and effectiveness claims, and presentation of verification and validation evidence that demonstrates device performance and reliability. Technical compilation ensures that all required information is complete, accurate, and presented in logical order that facilitates FDA review efficiency.
**Electronic Submission Preparation and Management** ensures proper formatting, organization, and submission of electronic files through FDA eSTAR system while maintaining data integrity and submission quality. Electronic preparation requires understanding of FDA electronic submission requirements and formatting specifications, organization of submission files in eCTD format with appropriate folder structure and file naming, and implementation of quality control procedures that ensure submission completeness and accuracy. Electronic management includes coordination of submission timing with regulatory strategy while ensuring proper user fee payment and acknowledgment procedures.
**Regulatory Communication and Interaction** facilitates effective communication with FDA throughout the submission review process while addressing reviewer questions and requests for additional information efficiently. Communication management requires preparation for potential FDA questions through comprehensive submission content and supporting documentation, establishment of procedures for responding to FDA requests for additional information within specified timeframes, and coordination with FDA review team through appropriate communication channels. Effective communication ensures efficient review process while demonstrating responsive regulatory engagement.
**Software Documentation and Validation Evidence** addresses unique FDA requirements for software medical devices including software lifecycle documentation, cybersecurity considerations, and algorithm validation evidence. Software documentation requires comprehensive software development lifecycle evidence per FDA software guidance, detailed cybersecurity risk assessment and control documentation for networked devices, and extensive testing evidence that demonstrates software safety and effectiveness under normal and fault conditions. Software submissions must address regulatory expectations for software quality assurance, change control, and post-market software maintenance procedures.
**Quality System and Manufacturing Documentation** demonstrates manufacturing capability and quality control systems that ensure consistent device production and quality throughout commercial manufacturing. Manufacturing documentation requires evidence of design transfer from development to production, comprehensive manufacturing procedures and quality control systems, and validation evidence that demonstrates manufacturing process capability and control. Quality system documentation must demonstrate compliance with FDA Quality System Regulation while providing confidence in ongoing manufacturing quality and consistency.
**Post-Approval Considerations and Planning** prepares for post-market obligations and ongoing regulatory compliance activities that begin following FDA clearance or approval. Post-approval planning requires understanding of labeling requirements and marketing claim limitations established by FDA clearance or approval, implementation of post-market surveillance systems that monitor device performance and safety, and establishment of procedures for managing device changes and reporting requirements. Effective planning ensures smooth transition from approval to commercial launch while maintaining ongoing regulatory compliance and stakeholder confidence.
**Multi-Jurisdictional Coordination** optimizes submission strategy for devices seeking approval in multiple markets by coordinating FDA submissions with EU MDR and other international regulatory requirements. International coordination requires alignment of clinical data and technical documentation across multiple jurisdictions, optimization of submission timing to support global launch strategies, and coordination of regulatory interactions to avoid conflicting requirements or inefficiencies. Effective coordination enables efficient global regulatory approval while minimizing redundant efforts and maximizing regulatory efficiency.
Your FDA Submission activities must demonstrate **comprehensive regulatory excellence** while providing FDA reviewers with complete, accurate, and compelling evidence for confident marketing authorization decisions. Well-executed submission processes provide FDA with systematic evidence of device safety and effectiveness, demonstrate professional regulatory capability and compliance commitment, and establish the regulatory foundation for successful long-term US market presence through demonstrated adherence to rigorous FDA standards and professional regulatory management.
# General Safety and Performance Requirements Checklist
Source: https://docs.withdovetail.com/regulatory-requirements/general-safety-performance-requirements-checklist
Systematically evaluate device compliance with essential safety and performance requirements.
## Summary
You must systematically evaluate your medical device against all General Safety and Performance Requirements (GSPR) in EU MDR Annex I to demonstrate comprehensive compliance with essential safety and performance standards. This structured checklist provides systematic assessment of each requirement's applicability, identifies relevant standards, documents compliance evidence, and justifies any deviations from standard approaches.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation), comparable assessments include:
* **Design controls compliance** per Section 820.30 ensuring systematic safety evaluation
* **Risk analysis documentation** per design control requirements
* **Standards compliance** verification for FDA-recognized consensus standards
* **510(k) submission** requirements for substantial equivalence demonstration
* **Essential performance** validation per applicable FDA guidance documents
**Special attention required for:**
* **Software validation** per FDA software guidance documents and standards
* **Cybersecurity requirements** per FDA premarket cybersecurity guidance
* **Usability engineering** per FDA Human Factors guidance requirements
* **Predicate device comparison** for demonstrating substantial equivalence
Under **EU MDR 2017/745** Annex I and Article 10(9), you must comply with:
* **GSPR compliance demonstration** mandatory for all medical devices per Article 10(9)
* **Annex I requirements** covering general, design, manufacturing, and information requirements
* **Technical documentation** inclusion per Annex II requirements
* **Harmonized standards application** providing presumption of conformity
* **CE marking authorization** dependent on complete GSPR compliance demonstration
**Special attention required for:**
* **Software as Medical Device** specific requirements per GSPR 17 and GSPR 18.8
* **Cybersecurity and data protection** requirements integrated throughout GSPR
* **Clinical evaluation alignment** with GSPR claims and performance requirements
* **Post-market surveillance** integration with GSPR compliance monitoring
## Overview
The General Safety and Performance Requirements Checklist serves as the **comprehensive compliance verification tool** that systematically demonstrates your medical device meets all applicable EU MDR essential requirements through structured evaluation, evidence documentation, and transparent justification of compliance approaches. This critical assessment transforms regulatory requirements into actionable compliance verification while providing regulatory authorities with clear evidence of systematic safety and performance consideration.
**GSPR Checklist Structure and Application** follows the systematic organization of EU MDR Annex I requirements including General Requirements (GSPRs 1-9), Design and Manufacturing Requirements (GSPRs 10-22), and Information Requirements (GSPR 23). The checklist application process requires careful evaluation of each requirement's applicability to your specific device based on intended use, design characteristics, and risk profile while ensuring that all applicable requirements receive appropriate attention and compliance verification. Systematic application includes determination of requirement applicability through device-specific analysis, identification of applicable harmonized standards that provide compliance pathways, and documentation of objective evidence that demonstrates conformity with each applicable requirement.
**Applicability Assessment and Justification** ensures that each GSPR requirement receives appropriate consideration through systematic evaluation of device characteristics, intended use, and design features that determine requirement relevance. Applicability assessment requires careful analysis of device functionality and characteristics to determine which requirements apply, consideration of intended use and user population to assess relevance of specific safety and performance requirements, and evaluation of device design and technology to determine applicable technical requirements. Clear justification must be provided for any requirements marked as not applicable, including device-specific technical reasoning that explains why certain requirements don't apply to your device design or intended use.
**Harmonized Standards Identification and Application** provides systematic pathways to GSPR compliance through application of recognized technical standards that provide presumption of conformity with essential requirements. Standards identification requires reference to the Official Journal of the European Union for current harmonized standards, selection of standards that address your device's specific technical characteristics and safety requirements, and documentation of how standards application supports compliance with specific GSPR requirements. Key standards for software medical devices include EN 62304 for software lifecycle processes, IEC 82304-1 for health software requirements, EN ISO 14971 for risk management, and EN 62366-1 for usability engineering.
**Evidence Documentation and Traceability** establishes clear connections between GSPR requirements and objective evidence that demonstrates compliance through systematic documentation and cross-referencing. Evidence documentation requires identification of specific documents from your technical file that provide compliance evidence, clear description of how evidence addresses specific GSPR requirements, and establishment of traceability links between requirements, evidence, and compliance conclusions. Evidence must be current, relevant, and sufficient to support compliance claims while enabling independent verification by regulatory authorities and notified bodies.
**Software-Specific GSPR Compliance** addresses the unique requirements for software medical devices including software development lifecycle compliance, cybersecurity considerations, and user interface requirements. Software GSPR compliance requires particular attention to GSPR 17 requirements for electronic programmable systems including software development according to recognized lifecycle standards, risk management including cybersecurity risk assessment, and verification and validation of software performance and safety. Additional software considerations include GSPR 18.8 requirements for protection against unauthorized access, mobile platform considerations if applicable, and integration with network security requirements.
**Risk Management Integration** ensures that GSPR compliance assessment aligns with systematic risk management activities while demonstrating that identified risks have been appropriately controlled and residual risks are acceptable. Risk management integration requires demonstration of how risk analysis findings support GSPR compliance, evidence that risk controls address GSPR requirements where applicable, and documentation of how GSPR compliance contributes to overall benefit-risk assessment. Integration activities ensure that GSPR compliance and risk management activities reinforce each other while providing comprehensive safety evidence.
**Clinical Evaluation Alignment** verifies that GSPR compliance claims are supported by appropriate clinical evidence and that clinical evaluation conclusions support GSPR compliance assertions. Clinical alignment requires confirmation that clinical evaluation addresses GSPR requirements where applicable, evidence that clinical data supports performance claims made in GSPR compliance, and demonstration that benefit-risk analysis supports GSPR compliance conclusions. Effective alignment ensures that technical compliance and clinical evidence provide consistent and mutually supportive safety and performance evidence.
**Post-Market Surveillance Integration** establishes connections between GSPR compliance verification and ongoing post-market monitoring activities that ensure continued compliance throughout the device lifecycle. Surveillance integration requires identification of GSPR requirements that require ongoing monitoring, establishment of post-market procedures that monitor continued compliance with applicable requirements, and implementation of change control procedures that address GSPR implications of device modifications. Effective integration ensures that GSPR compliance remains valid throughout the commercial device lifecycle.
**Documentation Quality and Regulatory Review Preparation** ensures that GSPR checklist documentation meets regulatory standards for clarity, completeness, and regulatory review efficiency. Documentation quality requirements include clear and specific compliance statements that avoid generic or vague assertions, comprehensive evidence references that enable independent verification, and logical organization that facilitates regulatory and notified body review. Quality documentation prevents regulatory queries while enabling efficient compliance assessment and approval processes.
**Continuous Compliance Monitoring and Updates** establishes procedures for maintaining GSPR compliance currency throughout the device lifecycle including updates for device changes, regulatory evolution, and new evidence availability. Compliance monitoring includes systematic review of GSPR compliance when device changes are implemented, monitoring of regulatory guidance updates that may affect compliance approaches, and procedures for updating compliance documentation when new evidence becomes available. Effective monitoring ensures that GSPR compliance remains current and accurate while supporting ongoing regulatory obligations and commercial success.
Your GSPR Checklist activities must demonstrate **systematic compliance verification** with all applicable EU MDR essential requirements while providing transparent, evidence-based documentation that supports confident regulatory approval and ongoing market authorization. Well-executed GSPR compliance verification provides regulatory authorities with clear evidence of comprehensive safety and performance consideration, enables efficient regulatory review and approval processes, and establishes the compliance foundation for successful long-term market presence through demonstrated adherence to essential safety and performance requirements.
# Introduction
Source: https://docs.withdovetail.com/regulatory-requirements/introduction
Comprehensive introduction into the world of medical device regulatory requirements.
## Overview
Medical device software operates within a **complex regulatory landscape** designed to ensure patient safety and device effectiveness. Understanding these requirements early in your development process is essential for bringing compliant devices to market efficiently and maintaining regulatory approval throughout the product lifecycle.
This guide provides a comprehensive overview of the regulatory framework governing software medical devices across major markets including the **European Union (EU MDR)**, **United States (FDA)**.
This guides strucuture is directly based on the **FormlyAI** Roadmap, and offers a more detailed description of the regulatory requirements for each task on the roadmap, as well as examples for the finished documents.
The actual amout and scope of tasks can differ for each user as they are based directly on the applied regulations. Things like region, device characteristics and device class all influence the regulatory requirements.
Each Roadmap is individually tailored to you device characteristics and the subsequent regulatory requirements. With the completion of the Roadmap, you will have a complete set of documents that fullfill your specific set of requirements.
## Key Regulatory Frameworks
The **US Food and Drug Administration (FDA)** regulates medical devices under Title 21 of the Code of Federal Regulations. The FDA uses a risk-based classification system (Class I, II, III) with various regulatory pathways including 510(k) clearance, De Novo classification, and Premarket Approval (PMA). The agency emphasizes quality systems, clinical data, and cybersecurity for software devices.
Subject to the applicable product characteristics and product risk class, the following standards will be supported:
* **21 CFR Part 820** – Quality System Regulation (QSR)
* **21 CFR Part 807** – Establishment Registration and Device Listing
* **21 CFR Part 801** – Labeling Requirements
* **21 CFR Part 11** – Electronic Records and Electronic Signatures (where applicable)
* **21 CFR Part 812** – Investigational Device Exemptions
* **21 CFR Part 814** – Premarket Approval
* **ISO 14971** – Application of Risk Management to Medical Devices
* **IEC 62304** – Medical Device Software – Software Lifecycle Processes
* **IEC 60601 series** – Safety and Essential Performance of Medical Electrical Equipment
* **IEC 62366** – Application of Usability Engineering
* **ISO 10993 series** – Biological Evaluation of Medical Devices
**Software-specific considerations**: FDA categorizes Software as Medical Device (SaMD) based on healthcare situation and state of healthcare decision.
The **Medical Device Regulation (MDR) 2017/745** governs medical devices in the European Union. This regulation applies to devices intended for medical purposes including diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. It emphasizes clinical evidence, post-market surveillance, and enhanced transparency requirements.
Subject to the applicable product characteristics and product risk class, the following standards will be supported:
* **General Safety and Performance Requirements (GSPR)** – Annex I, MDR 2017/745
* **ISO 13485** – Quality Management Systems – Requirements for regulatory purposes
* **ISO 14971** – Application of Risk Management to Medical Devices
* **IEC 62304** – Medical Device Software – Software Lifecycle Processes
* **IEC 60601 series** – Safety and Essential Performance of Medical Electrical Equipment
* **IEC 62366** – Application of Usability Engineering
* **ISO 10993 series** – Biological Evaluation of Medical Devices
* **EN ISO 14155** – Clinical Investigation of Medical Devices
* **MEDDEV 2.7/1 rev. 4** – Clinical Evaluation: A Guide for Manufacturers
**Software-specific considerations**: Software is classified as a medical device if it has a medical purpose. Classification depends on the healthcare decision it informs or enables.
The **In Vitro Diagnostic Regulation (IVDR) 2017/746** governs in vitro diagnostic medical devices in the European Union. This regulation applies to devices intended to examine specimens from the human body to provide diagnostic, screening, or monitoring information. It introduces stricter requirements for clinical evidence and performance evaluation of IVDs.
Subject to the applicable product characteristics and product risk class, the following standards will be supported:
* **General Safety and Performance Requirements (GSPR)** – Annex I, IVDR 2017/746
* **ISO 13485:2016** – Quality Management Systems
* **ISO 14971** – Risk Management for Medical Devices
* **ISO 18113 series** – Labelling and Instructions for Use of IVDs
* **ISO 15189:2022** – Medical Laboratories – Quality and Competence
* **CLSI Guidelines** – Various clinical and performance validation standards
* **ISO 20916** – Clinical Performance Studies for IVDs
* **ISO 17511** – Metrological Traceability of Values Assigned to Calibrators and Control Materials
**IVD-specific considerations**: IVD software classification depends on the risk class of the IVD device and the healthcare decision it enables or influences.
**Stay Current**: Subscribe to regulatory authority guidance documents and participate in industry associations to stay ahead of evolving requirements.
## Common Compliance Challenges
Medical device software development presents unique regulatory challenges that can delay market entry or compromise compliance. Understanding these challenges helps you prepare effectively.
### Documentation and Process Challenges
**Documentation Burden**: Regulatory compliance generates extensive documentation across all development phases. Many organizations underestimate the volume and interconnectedness of required documents.
Key challenges:
* Managing complex document relationships and dependencies
* Maintaining document consistency throughout the lifecycle
* Ensuring all documents remain current and synchronized
* Establishing efficient review and approval processes
**Traceability Gaps**: Missing traceability links can halt regulatory submissions entirely. Requirements, risks, design elements, tests, and clinical evidence must be traceable throughout the device lifecycle.
Critical areas:
* User needs to system requirements linkage
* Risk analysis to mitigation measures mapping
* Design specifications to verification results connection
* Clinical evidence to safety and effectiveness claims
**Change Control Complexity**: All changes must be controlled and assessed for regulatory impact. Companies often struggle with change classification and impact assessment.
Common issues:
* Determining when changes require regulatory notification
* Assessing cascading effects of software updates
* Managing change documentation and approvals
* Balancing agility with regulatory requirements
### Technical and Development Challenges
**Software Lifecycle Management**: IEC 62304 compliance requires extensive documentation that may not align naturally with agile development practices.
Key considerations:
* Adapting agile workflows to accommodate regulatory checkpoints
* Documenting software architecture and detailed design
* Managing iterative development within regulatory frameworks
* Balancing development speed with compliance requirements
**Clinical Evidence Requirements**: Demonstrating clinical safety and effectiveness is challenging, especially for novel AI/ML applications.
Planning essentials:
* Early clinical strategy development
* Multi-source evidence consideration (literature, real-world data)
* Jurisdiction-specific clinical data requirements
* Novel validation approaches for AI/ML devices
**Verification and Validation Scope**: Determining appropriate V\&V activities for software devices requires balancing thoroughness with efficiency.
Critical factors:
* Risk-based testing strategy development
* Representative test data selection
* AI/ML algorithm validation approaches
* Performance validation across intended use conditions
### Organizational and Resource Challenges
**Regulatory Expertise Gaps**: Software companies often lack in-house regulatory knowledge, leading to inefficient compliance approaches.
Impact areas:
* Misunderstanding of regulatory requirements
* Over-engineering or under-engineering solutions
* Poor regulatory pathway decisions
* Inadequate compliance planning
**Multi-Jurisdictional Complexity**: Global market access requires managing different regulatory requirements across jurisdictions.
Key challenges:
* Varying classification and clinical evidence requirements
* Different submission timelines and processes
* Evolving regulations across markets
* Resource allocation across multiple regulatory tracks
**Resource Allocation**: Regulatory activities consume substantial time, personnel, and financial resources that are often underestimated.
Planning considerations:
* Quality management system implementation costs
* Clinical study investments
* Regulatory submission expenses
* Ongoing compliance maintenance resources
### Post-Market and Ongoing Challenges
**Post-Market Surveillance**: Software devices require specialized monitoring systems for real-world evidence collection and incident management.
Essential elements:
* Real-world performance monitoring
* User experience data collection
* Incident trend analysis and reporting
* Clinical significance assessment of software-related events
**Cybersecurity Evolution**: Rapidly evolving cybersecurity requirements demand adaptive security approaches throughout the device lifecycle.
Ongoing requirements:
* Continuous threat landscape monitoring
* Security update management processes
* Balance between security and usability
* Regulatory compliance with evolving cybersecurity guidance
**Quality Management System Integration**: Implementing ISO 13485 in software environments requires adapting traditional manufacturing QMS concepts.
Adaptation areas:
* Document control for software development
* Design controls in agile environments
* Supplier management for software components
* Corrective action processes for software issues
# Labeling, Instructions for Use, and Manuals
Source: https://docs.withdovetail.com/regulatory-requirements/labeling-instructions-manuals
Create comprehensive user documentation ensuring safe device operation and regulatory compliance.
## Summary
You must create comprehensive user-facing documentation including device labels, Instructions for Use (IFU), and supplementary manuals that ensure safe and effective device operation while meeting regulatory requirements for content, language, and accessibility. These critical documents serve as the primary communication between you and device users, providing essential safety information, operational guidance, and regulatory compliance details.
## Regulatory Context
Under **21 CFR Part 801** (Labeling) and **21 CFR Part 820.120** (Device Labeling), you must implement:
* **Adequate instructions** for intended use per Section 801.5 and Section 801.15
* **Legible and permanent** labeling meeting requirements per Section 820.120
* **UDI labeling compliance** per 21 CFR Part 830 for device identification
* **Cybersecurity information** for software devices per FDA cybersecurity guidance
* **Language requirements** ensuring user comprehension per Section 801.15
**Special attention required for:**
* **Prescription device labeling** specific requirements per Section 801.109
* **Software as Medical Device** labeling including cybersecurity and update information
* **Combination product labeling** coordination between device and drug requirements
* **510(k) predicate consistency** ensuring labeling aligns with substantial equivalence claims
Under **EU MDR 2017/745** Article 10 and Annex I GSPR 23, you must comply with:
* **Information supplied by manufacturer** requirements per Annex I Chapter III
* **Instructions for Use** mandatory content per GSPR 23.1 specifications
* **Local language requirements** per Article 10(11) for target markets
* **Electronic IFU provisions** per GSPR 23.1(s) under specific conditions
* **UDI integration** per Article 27 and Commission Implementing Regulation (EU) 2017/2226
**Special attention required for:**
* **Authorized representative information** for non-EU manufacturers per Article 11
* **Class III and implantable device** specific labeling requirements per GSPR 23.2
* **Patient cards** for implantable devices per Article 18 requirements
* **Electronic IFU conditions** including website availability and paper copy provision
## Overview
Labeling, Instructions for Use, and manuals represent the **final safety barrier** between your medical device and potential user errors by providing comprehensive, regulatory-compliant documentation that enables safe and effective device operation across diverse user populations and clinical environments. These user-facing documents transform complex technical specifications into accessible guidance while meeting stringent regulatory requirements for content, format, and language compliance.
**Instructions for Use (IFU)** serve as the primary comprehensive guidance document that must include device identification, intended purpose, safety information, operational instructions, and regulatory compliance details in language appropriate for your intended users. The IFU development process requires systematic integration of information from risk management, usability engineering, and clinical evaluation activities to ensure that all safety-critical information is properly communicated. Your IFU must address contraindications based on risk analysis, warnings and precautions derived from risk controls, operational procedures validated through usability testing, and technical specifications that support safe device integration into clinical workflows.
**Device Labeling** encompasses the physical or electronic identification information that must be immediately visible to users, including device name, manufacturer information, UDI identification, regulatory markings, and critical safety warnings. Device labels serve as the first point of contact between users and regulatory information while providing essential traceability data for post-market surveillance and incident investigation. Label development requires careful consideration of space constraints, readability requirements, regulatory symbol standards, and integration with packaging and distribution systems.
**User Manuals and Physician Handbooks** provide detailed operational guidance tailored to specific user populations, offering more comprehensive instructions than the basic IFU while maintaining regulatory compliance and safety focus. These supplementary documents enable customization for different user groups while ensuring consistent safety messaging across all documentation types. User manual development requires coordination with usability engineering findings to address identified user difficulties and integration with clinical evaluation results to support appropriate clinical use.
**Marketing Content and Promotional Materials** must maintain regulatory compliance while supporting commercial objectives, ensuring that all claims align with approved intended use statements and that promotional messaging doesn't contradict safety information in regulatory documents. Marketing content development requires careful review to prevent off-label promotion while effectively communicating device benefits to appropriate clinical audiences.
**Translation and Localization** activities ensure that user-facing documentation meets local language requirements while maintaining regulatory accuracy and cultural appropriateness across target markets. The translation process requires professional medical translation services, back-translation verification, local regulatory review, and ongoing maintenance to ensure consistency when source documents are updated. Quality translation processes prevent misunderstandings that could compromise device safety while enabling market access across diverse linguistic regions.
**Electronic Instructions for Use (eIFU)** implementation enables cost-effective distribution while meeting specific regulatory conditions for website availability, user accessibility, and paper copy provision upon request. eIFU development requires robust web infrastructure, accessibility compliance for users with disabilities, version control systems, and backup procedures that ensure continuous availability throughout the device commercial lifetime.
**Symbol and Regulatory Marking Integration** ensures that all required symbols, warnings, and regulatory information are properly incorporated according to international standards while maintaining readability and user comprehension. Symbol implementation requires reference to ISO 15223-1 standards, integration with risk management findings, and coordination with regulatory submission requirements across target markets.
**Content Management and Version Control** systems maintain consistency across all documentation types while enabling efficient updates when regulatory requirements change or post-market findings require labeling modifications. Effective content management prevents version conflicts, ensures consistent messaging across document types, and supports regulatory change control requirements for labeling updates.
**Usability Integration** ensures that labeling and instruction content addresses user difficulties identified during human factors testing while supporting safe device operation in real-world clinical environments. This integration requires synthesis of usability testing findings, incorporation of user feedback, and validation that final documentation supports error-free device operation by intended users.
Your labeling, Instructions for Use, and manual development activities must demonstrate **regulatory compliance** while supporting safe device use through clear, accessible communication that addresses all identified risks and operational requirements. Well-executed documentation reduces use-related risks, supports regulatory approval processes, and enables successful commercial deployment by ensuring that users have comprehensive, accessible guidance for safe and effective device operation throughout its intended lifecycle.
# Manufacturing
Source: https://docs.withdovetail.com/regulatory-requirements/manufacturing
Validate manufacturing processes ensuring consistent production of devices meeting safety and quality requirements.
## Summary
You must validate that your manufacturing processes consistently produce medical devices meeting predetermined specifications and quality attributes before commercial production begins. Manufacturing validation demonstrates that your production methods are controlled, capable, and reliable, ensuring every device manufactured meets safety and effectiveness requirements throughout commercial production.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation), you must implement:
* **Process validation** mandatory under Section 820.75 for all manufacturing processes
* **Documented procedures** demonstrating consistent production of conforming products
* **Statistical validation** per Section 820.250 where appropriate for process control
* **Design transfer** validation ensuring manufacturing meets design specifications
* **Change control** procedures for maintaining validated process status
**Special attention required for:**
* **Software manufacturing processes** including compilation, testing, and digital distribution
* **Sterilization validation** for devices requiring sterile packaging or components
* **Automated manufacturing systems** requiring software validation and cybersecurity controls
* **Critical process parameters** identification and ongoing monitoring procedures
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must comply with:
* **Process validation** requirements per EN ISO 13485:2016 Section 7.5.1.1
* **Quality management system** integration per Article 10(9) for all manufacturing
* **Technical documentation** including manufacturing information per Annex II Section 3
* **Traceability requirements** throughout manufacturing per Article 27 (UDI)
* **Post-market surveillance** integration for manufacturing process improvement
**Special attention required for:**
* **Unique Device Identification** (UDI) integration throughout manufacturing processes
* **Supply chain traceability** for components and materials per MDR requirements
* **Notified body assessment** of manufacturing validation documentation completeness
* **Manufacturing site changes** requiring validation updates and regulatory notification
## Overview
Manufacturing validation serves as the **critical bridge** between proven device design and reliable commercial production by demonstrating that your manufacturing processes can consistently produce devices that meet all specifications and quality requirements. This systematic validation approach transforms design outputs into production-ready processes while providing objective evidence that your manufacturing capabilities support safe, effective device production at commercial scale.
**Manufacturing Validation Planning** establishes your comprehensive strategy for proving that production processes operate consistently within predetermined limits and produce devices meeting all quality attributes. The planning process requires systematic identification of critical manufacturing processes, definition of process parameters that affect device quality, and establishment of validation protocols that demonstrate process capability. Your validation approach must address not only primary manufacturing operations but also supporting processes like sterilization, packaging, labeling, and quality testing that ensure final devices meet specifications.
**Manufacturing Validation Protocols** translate your strategic validation approach into detailed, executable procedures that systematically evaluate process performance under normal operating conditions. These protocols specify installation qualification to verify equipment is installed correctly, operational qualification to confirm processes function as designed, and performance qualification to demonstrate consistent production of conforming devices. The protocol development process requires careful consideration of process variables, sampling strategies, acceptance criteria, and statistical methods that provide confident conclusions about process capability.
**Validation Reporting** documents the systematic execution of validation protocols and provides evidence that manufacturing processes are controlled, capable, and ready for commercial production. The reporting process synthesizes data from all validation activities to demonstrate that processes consistently produce devices meeting specifications and that manufacturing operations are ready to support market supply while maintaining quality and regulatory compliance.
**Design Transfer Validation** represents a critical subset of manufacturing validation that confirms your production processes can reliably reproduce devices that match design specifications and performance characteristics established during development. This validation bridges the gap between development prototypes and commercial production by proving that manufacturing methods, materials, and processes produce devices with identical performance to those used in verification and validation testing.
**Process Control Systems** must be validated to ensure that manufacturing operations remain within validated parameters throughout commercial production. This includes validation of automated manufacturing equipment, process monitoring systems, environmental controls, and quality testing procedures that maintain product consistency. Control system validation provides confidence that processes will continue to operate as validated and that deviations will be detected and corrected promptly.
**Software Manufacturing Validation** addresses the unique requirements for devices containing software by validating compilation processes, automated testing systems, digital signing procedures, and software distribution methods. Software manufacturing validation must demonstrate that identical software is produced from source code and that all quality controls function correctly throughout the software production lifecycle. This includes validation of version control systems, build automation, security controls, and software packaging processes.
**Change Control Integration** ensures that validated manufacturing processes remain in a validated state throughout the product lifecycle by establishing procedures for evaluating, implementing, and validating process changes. Manufacturing changes require careful assessment of their impact on device quality, safety, and effectiveness, with appropriate validation activities to confirm that changes don't compromise process capability or product quality.
**Ongoing Process Monitoring** maintains validated status through systematic collection and analysis of process data, product quality metrics, and performance indicators that confirm processes continue to operate as validated. This monitoring provides early detection of process drift or capability changes that might affect device quality, enabling proactive corrective actions before products are affected.
**Risk-Based Validation** focuses validation efforts on processes and parameters that most significantly impact device safety, effectiveness, and quality while applying appropriate controls to less critical processes. This approach optimizes validation resources by concentrating on high-risk areas while ensuring comprehensive coverage of all manufacturing activities that affect device conformity.
Your manufacturing validation activities must demonstrate **regulatory compliance** by following established validation principles, maintaining comprehensive documentation of all validation activities, and providing objective evidence that processes are capable of consistent commercial production. The success of your manufacturing validation directly impacts product quality, regulatory approval maintenance, and commercial supply reliability by ensuring that every device produced meets the same standards established during development and regulatory review.
# Medical Device File
Source: https://docs.withdovetail.com/regulatory-requirements/medical-device-file
Compile comprehensive technical documentation supporting device safety and regulatory compliance throughout lifecycle.
## Summary
You must compile and maintain a comprehensive Medical Device File that serves as the central repository for all technical documentation supporting your device's safety, performance, and regulatory compliance throughout its commercial lifecycle. This structured file organization ensures systematic document management while facilitating efficient regulatory submissions and post-market compliance activities.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation), comparable file management includes:
* **Design History File** per Section 820.30(j) containing complete design control records
* **Device Master Record** per Section 820.181 documenting device specifications and procedures
* **Technical documentation** supporting 510(k) submissions and PMA applications
* **Document control** per Section 820.40 ensuring current and controlled documentation
* **Record retention** requirements maintaining documents throughout device lifecycle
**Special attention required for:**
* **Software documentation** per FDA software validation guidance requirements
* **Cybersecurity documentation** per FDA premarket cybersecurity guidance
* **Design control integration** ensuring DHF completeness and accessibility
* **Change control documentation** tracking all device modifications and their impact
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must maintain:
* **Technical documentation** per Annex II containing comprehensive device information
* **Document control** per ISO 13485:2016 Section 4.2.3 ensuring current documentation
* **Design and development files** per ISO 13485:2016 Section 7.3 documenting design activities
* **Post-market surveillance documentation** per Article 83 monitoring device performance
* **Quality management system records** per ISO 13485:2016 supporting ongoing compliance
**Special attention required for:**
* **Technical file completeness** ensuring all Annex II requirements are addressed
* **Notified body accessibility** maintaining documents available for review within specified timeframes
* **Document currency** ensuring all documentation reflects current device configuration
* **Multi-language requirements** maintaining documentation in appropriate languages for market access
## Overview
The Medical Device File establishes the **comprehensive documentation framework** that organizes, maintains, and controls all technical documentation required for medical device regulatory compliance while providing systematic access to device information throughout the commercial lifecycle. This centralized file management system ensures that all stakeholders have access to current, controlled documentation while supporting efficient regulatory interactions and ongoing compliance activities.
**File Structure and Organization** establishes systematic organization of technical documentation that enables efficient access and management while ensuring regulatory compliance and stakeholder accessibility. File organization requires logical grouping of related documents including design and development records, regulatory submissions, post-market surveillance data, and quality management system documentation. Effective structure includes clear naming conventions that facilitate document identification, version control systems that maintain document currency, and access controls that ensure appropriate stakeholder access while maintaining confidentiality and data integrity.
**Document Control and Version Management** ensures that all file contents remain current, controlled, and traceable while preventing use of obsolete documentation and maintaining regulatory compliance. Document control requires implementation of systematic procedures for document creation, review, approval, and distribution that ensure only current versions are available for use. Version management includes establishment of clear version numbering systems, maintenance of document change histories, and implementation of controlled distribution procedures that ensure stakeholders receive appropriate documentation updates.
**Technical Documentation Integration** consolidates all technical documents including design controls, risk management, clinical evaluation, verification and validation, and manufacturing documentation into a cohesive file structure. Technical integration requires systematic organization of design and development documentation that supports regulatory submissions, comprehensive compilation of testing and validation evidence that demonstrates device safety and performance, and integration of risk management documentation that addresses device hazards and controls throughout the lifecycle.
**Regulatory Submission Support** organizes file contents to facilitate efficient preparation of regulatory submissions including 510(k) clearance, PMA applications, CE marking submissions, and ongoing regulatory correspondence. Submission support requires maintenance of submission-ready documentation that meets regulatory requirements, organization of supporting evidence that addresses anticipated regulatory questions, and establishment of procedures for rapidly compiling submission packages from file contents while ensuring completeness and accuracy.
**Quality Management System Integration** connects the medical device file with broader quality management system documentation including procedures, work instructions, and quality records that support ongoing compliance and operational excellence. QMS integration requires alignment of file organization with quality system structure, integration of device-specific documentation with company-wide procedures and policies, and establishment of procedures that ensure file updates reflect quality system changes and continuous improvement activities.
**Post-Market Documentation Management** ensures systematic collection, organization, and maintenance of post-market data including surveillance reports, complaint investigations, corrective actions, and performance monitoring that support ongoing regulatory compliance. Post-market management requires establishment of procedures for collecting and organizing real-world performance data, integration of post-market findings with device file documentation, and maintenance of documentation that supports regulatory reporting and communication requirements.
**Multi-Regulatory Environment Management** addresses the complexity of maintaining device files that support multiple regulatory jurisdictions including FDA, EU MDR, and other international requirements through coordinated documentation strategies. Multi-regulatory management requires understanding of jurisdiction-specific documentation requirements, establishment of file organization that supports multiple submission formats, and implementation of procedures that ensure documentation currency across all applicable regulatory environments.
**Stakeholder Access and Security** provides appropriate access to device file contents for internal teams, regulatory authorities, notified bodies, and other stakeholders while maintaining confidentiality and data integrity. Access management requires establishment of role-based access controls that ensure appropriate stakeholder access, implementation of security measures that protect confidential information, and establishment of procedures for providing regulatory authorities with timely access to requested documentation.
**Electronic File Management and Backup** ensures reliable electronic storage, backup, and retrieval of device file contents while maintaining data integrity and accessibility throughout the device lifecycle. Electronic management requires implementation of robust data storage systems with appropriate backup and disaster recovery capabilities, establishment of procedures for maintaining electronic file accessibility and searchability, and implementation of data migration procedures that ensure long-term file accessibility despite technology changes.
**Change Impact Assessment and File Updates** ensures that device changes are systematically evaluated for their impact on file contents while maintaining documentation currency and regulatory compliance. Change assessment requires implementation of procedures that evaluate the documentation impact of device modifications, establishment of update procedures that ensure timely file updates following device changes, and maintenance of change documentation that supports regulatory compliance and stakeholder communication.
**Audit and Inspection Readiness** maintains device files in a state of constant readiness for regulatory inspections, notified body audits, and internal quality audits while ensuring rapid response to documentation requests. Inspection readiness requires maintenance of organized, complete, and current documentation that can be rapidly accessed and provided to auditors, establishment of procedures for responding to audit findings and corrective action requests, and implementation of self-audit procedures that ensure ongoing file completeness and compliance.
Your Medical Device File activities must demonstrate **systematic documentation management** that supports confident regulatory compliance while enabling efficient business operations and stakeholder communication throughout the device commercial lifecycle. Well-maintained device files provide regulatory authorities with evidence of systematic compliance management, enable efficient preparation of regulatory submissions and responses, and establish the documentation foundation for successful long-term market presence through demonstrated organizational capability and regulatory adherence.
# Performance Evaluation
Source: https://docs.withdovetail.com/regulatory-requirements/performance-evaluation
Evaluate technical performance characteristics ensuring devices meet specifications and user requirements.
## Summary
You must systematically evaluate your medical device's technical performance characteristics against specified requirements and intended use conditions to demonstrate that it achieves its intended performance throughout its operational lifecycle. Performance evaluation provides objective evidence that your device meets all technical specifications while maintaining consistent performance under various operating conditions and user scenarios.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), you must implement:
* **Design verification** per Section 820.30(f) confirming design outputs meet design inputs
* **Design validation** per Section 820.30(g) ensuring devices meet user needs
* **Performance testing** demonstrating device specifications under intended use conditions
* **Statistical analysis** per Section 820.250 for test result interpretation and validation
* **Objective evidence** documentation supporting all performance claims and specifications
**Special attention required for:**
* **Software performance validation** per FDA software validation guidance
* **Algorithm performance** evaluation for AI/ML devices per FDA guidance
* **Real-world performance** monitoring for devices with adaptive algorithms
* **Cybersecurity performance** validation for networked devices per FDA guidance
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must comply with:
* **Design verification and validation** per EN ISO 13485:2016 Section 7.3.6
* **Essential requirements compliance** demonstration per Annex I GSPR
* **Performance standards compliance** for harmonized standards application
* **Clinical performance evaluation** integration with clinical evaluation per Article 61
* **Post-market performance monitoring** per Article 83 surveillance requirements
**Special attention required for:**
* **Software lifecycle performance** validation per IEC 62304 requirements
* **Usability performance** evaluation per IEC 62366-1 integration
* **Risk control effectiveness** verification per ISO 14971 requirements
* **Real-world performance** data collection for post-market surveillance
## Overview
Performance evaluation establishes the **comprehensive assessment framework** that demonstrates your medical device achieves its intended technical specifications while maintaining consistent, reliable operation under all anticipated use conditions and environmental factors. This systematic evaluation process transforms design specifications into verified performance capabilities through structured testing, analysis, and documentation that supports regulatory approval and ongoing commercial success.
**Technical Performance Specification Development** establishes the measurable criteria that define acceptable device performance across all critical functional areas including accuracy, precision, reliability, speed, and environmental tolerance. Performance specification development requires systematic translation of user needs and intended use requirements into specific, testable performance parameters that can be objectively measured and validated. The specification process includes identification of critical performance characteristics that affect safety and effectiveness, establishment of acceptance criteria based on clinical requirements and state-of-the-art performance, and definition of test conditions that represent intended use environments and user scenarios.
**Performance Testing Protocol Development** creates systematic testing procedures that enable objective evaluation of device performance against specifications under controlled and realistic conditions. Protocol development requires careful consideration of test environments that represent intended use conditions, selection of appropriate test methods and measurement systems, and establishment of statistical approaches that provide confidence in performance conclusions. Effective protocols address both normal operating conditions and boundary conditions that may reveal performance limitations while ensuring that testing approaches are reproducible and regulatory-compliant.
**Bench Testing and Laboratory Verification** provides controlled evaluation of device performance characteristics under standardized conditions that enable precise measurement and comparison against specifications. Bench testing activities include systematic evaluation of accuracy and precision under controlled conditions, assessment of measurement repeatability and reproducibility, evaluation of environmental tolerance across temperature, humidity, and other relevant factors, and assessment of performance stability over time and usage cycles. Laboratory verification provides the foundation for performance claims while identifying any limitations or constraints that affect device operation.
**Real-World Performance Validation** demonstrates that device performance specifications translate into effective operation under actual use conditions with real users and environments. Real-world validation includes evaluation of device performance in intended use environments with representative users, assessment of performance under typical workflow conditions and operational stresses, evaluation of user interaction effects on device performance, and validation that performance specifications support effective clinical or intended use outcomes. Real-world validation bridges the gap between laboratory performance and actual user experience while providing confidence in commercial deployment.
**Software and Algorithm Performance Evaluation** addresses the unique performance characteristics of software medical devices including computational accuracy, processing speed, user interface responsiveness, and algorithm reliability. Software performance evaluation requires assessment of computational accuracy across the full range of input data and conditions, evaluation of processing speed and response times under various system loads, validation of user interface performance across different devices and screen sizes, and assessment of algorithm performance and reliability across diverse data sets. Software evaluation must address both functional performance and non-functional characteristics that affect user experience and clinical effectiveness.
**Performance Benchmarking and Competitive Analysis** provides context for device performance by comparing capabilities against state-of-the-art devices and established clinical standards. Benchmarking activities include systematic comparison of performance characteristics against competitive devices and industry standards, evaluation of performance advantages and limitations relative to existing solutions, assessment of performance claims against clinical requirements and user expectations, and identification of performance differentiation that supports commercial positioning. Effective benchmarking ensures that performance specifications are competitive while identifying areas for continuous improvement.
**Environmental and Stress Testing** evaluates device performance under challenging conditions that may occur during transportation, storage, and use to ensure reliable operation throughout the device lifecycle. Environmental testing includes assessment of performance under extreme temperature and humidity conditions, evaluation of electromagnetic compatibility and interference resistance, testing of mechanical shock and vibration tolerance for devices with physical components, and assessment of performance degradation under extended use or stress conditions. Environmental testing ensures that devices maintain performance specifications under all anticipated operating conditions.
**Performance Data Analysis and Statistical Evaluation** transforms raw performance test data into meaningful conclusions about device capability and reliability through appropriate statistical methods and interpretation. Statistical analysis includes application of appropriate statistical methods for performance data evaluation, calculation of confidence intervals and statistical significance for performance claims, identification of performance trends and patterns that may indicate systematic issues, and presentation of performance data in formats that support regulatory review and clinical decision-making. Rigorous statistical analysis ensures that performance conclusions are scientifically valid and regulatory-compliant.
**Performance Documentation and Reporting** provides comprehensive documentation of performance evaluation activities and conclusions that supports regulatory submissions and ongoing quality management. Documentation activities include preparation of performance evaluation reports that summarize testing procedures, results, and conclusions, compilation of supporting data and analysis that enables independent verification of performance claims, creation of performance specifications documentation that guides manufacturing and quality control, and establishment of performance monitoring procedures that support ongoing compliance and improvement. Complete documentation enables confident regulatory interactions while supporting ongoing performance management.
**Integration with Design Controls and Quality Management** ensures that performance evaluation activities are properly integrated with overall device development and quality management systems. Integration activities include alignment of performance specifications with design inputs and user needs, incorporation of performance verification and validation into design control procedures, integration of performance data with risk management and clinical evaluation activities, and establishment of performance monitoring procedures that support ongoing quality management and continuous improvement. Effective integration ensures that performance evaluation supports overall regulatory compliance while enabling systematic performance management throughout the device lifecycle.
Your performance evaluation activities must demonstrate **systematic validation** of device performance capabilities while providing the evidence foundation necessary for confident regulatory approval and successful commercial deployment. Well-executed performance evaluation provides regulatory authorities with objective evidence of device capability, supports healthcare providers and users with confidence in device performance, and establishes the foundation for ongoing performance monitoring and continuous improvement throughout the commercial device lifecycle.
# Post-Market Surveillance
Source: https://docs.withdovetail.com/regulatory-requirements/post-market-surveillance
Monitor device safety and performance after market release through systematic data collection and analysis.
## Summary
You must establish systematic procedures to monitor your medical device's safety and performance after market release through ongoing data collection, analysis, and reporting that identifies emerging risks and confirms expected device behavior. Post-market surveillance ensures continuous patient safety while meeting regulatory obligations for ongoing compliance and risk management throughout the commercial device lifecycle.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **21 CFR Part 803** (Medical Device Reporting), you must implement:
* **Post-market surveillance system** per Section 820.100 for corrective and preventive actions
* **Medical Device Reporting (MDR)** mandatory for deaths, serious injuries, and malfunctions per Part 803
* **Complaint handling procedures** per Section 820.198 for systematic data collection
* **Periodic reporting** requirements for specific device types and conditions
* **Unique Device Identification (UDI)** integration for traceability per 21 CFR Part 830
**Special attention required for:**
* **Software medical devices** requiring cybersecurity monitoring per FDA guidance
* **Class III devices** with enhanced post-market study requirements
* **FDA-mandated post-market studies** as conditions of device approval
* **Real-world performance monitoring** for AI/ML-enabled devices per FDA guidance
Under **EU MDR 2017/745** Article 83 and supporting regulations, you must comply with:
* **Post-market surveillance system** mandatory per Article 83 systematic requirements
* **Post-Market Clinical Follow-up (PMCF)** per Article 74 and Annex XIV requirements
* **Vigilance reporting** per Article 87 within specified timeframes
* **Periodic Safety Update Reports (PSUR)** for higher-risk devices per Article 86
* **EUDAMED integration** for incident reporting and surveillance data
**Special attention required for:**
* **Trend reporting** for statistically significant increases in incidents
* **Authorized representative obligations** for non-EU manufacturers per Article 11
* **Implantable device** specific surveillance requirements per GSPR and Article 18
* **Clinical evaluation updates** based on post-market findings per Article 61
## Overview
Post-market surveillance represents your **ongoing commitment** to patient safety and regulatory compliance by establishing systematic monitoring procedures that detect emerging risks, validate pre-market assumptions, and ensure continued device safety throughout its commercial lifecycle. This comprehensive surveillance framework transforms passive compliance into proactive safety management that protects patients while supporting business sustainability through early identification and resolution of potential issues.
**Post-Market Surveillance Planning** establishes the comprehensive framework for ongoing device monitoring by defining data collection sources, analysis methodologies, reporting procedures, and organizational responsibilities. Your surveillance plan must specify how you will monitor vigilance databases, user complaints, literature sources, and field experience data while establishing statistical methods for trend analysis and risk assessment procedures. Planning activities require integration with your risk management system to ensure that post-market findings trigger appropriate risk assessment updates and corrective actions when necessary.
**Vigilance Database Monitoring** provides systematic access to global adverse event data that may indicate emerging safety issues or unexpected device behaviors not apparent during pre-market testing. This monitoring requires regular searches of FDA MAUDE, European vigilance databases, and other international reporting systems using device-specific keywords and classification codes. Effective vigilance monitoring enables early detection of safety signals while providing competitive intelligence about similar devices and industry-wide issues that may affect your device's risk profile.
**Complaint Management and Analysis** transforms user feedback into actionable safety intelligence by systematically collecting, categorizing, and analyzing complaints related to device performance, safety concerns, and user difficulties. Your complaint management system must distinguish between general customer service issues and medical device-related complaints that require regulatory attention while maintaining complete documentation for trending analysis and regulatory reporting. Complaint analysis provides real-world insights into device performance and user interaction that may reveal risks not identified during controlled testing.
**Literature and Registry Monitoring** ensures awareness of published research, clinical studies, and registry data that may contain relevant safety information about your device or similar technologies. This monitoring requires systematic review of medical literature, conference proceedings, and device registries while establishing procedures for evaluating the relevance and impact of new findings on your device's safety profile. Literature monitoring provides scientific context for post-market findings and may identify emerging clinical evidence that affects your device's benefit-risk assessment.
**Statistical Analysis and Trending** transforms raw surveillance data into meaningful safety intelligence through appropriate statistical methods that can detect significant changes in incident frequency or severity. Your analysis procedures must include complaint rate calculations, trend analysis using methods such as the Mann-Kendall test, and risk assessment integration that determines when post-market findings require immediate action versus inclusion in periodic reports. Statistical rigor ensures that surveillance activities provide reliable safety signals while preventing overreaction to normal variation in reported events.
**Reporting and Regulatory Communication** ensures timely, accurate submission of required post-market surveillance reports while maintaining effective communication with regulatory authorities about emerging safety issues. Your reporting procedures must address immediate notification requirements for serious incidents, periodic surveillance report submission, and proactive communication about safety signals or corrective actions. Effective regulatory communication builds trust with authorities while ensuring compliance with evolving surveillance requirements.
**Corrective and Preventive Action Integration** links surveillance findings to systematic improvement processes that address identified risks while preventing recurrence of safety issues. This integration requires clear escalation procedures for surveillance findings that exceed acceptable risk levels, systematic root cause analysis of identified issues, and verification that corrective actions effectively address underlying problems. CAPA integration ensures that surveillance activities result in continuous safety improvement rather than passive monitoring.
**International Surveillance Coordination** addresses the complexity of monitoring device performance across multiple markets with different regulatory requirements, reporting systems, and cultural contexts. Coordination activities include establishing consistent surveillance procedures across markets, integrating diverse data sources, and ensuring that local findings are appropriately shared across your global operations. International coordination prevents surveillance gaps while ensuring that safety signals detected in one market are properly evaluated for global implications.
**Technology and Data Management** supports surveillance activities through robust systems that enable efficient data collection, analysis, and reporting while maintaining data integrity and regulatory compliance. Technology requirements include database systems for complaint and incident tracking, analytical tools for statistical trending, and integration platforms that combine diverse data sources into comprehensive surveillance insights. Effective data management enables scalable surveillance operations while supporting regulatory requirements for data retention and audit trails.
Your post-market surveillance activities must demonstrate **continuous improvement** in device safety and performance while providing regulatory authorities with transparent, systematic evidence of ongoing safety monitoring. Well-executed surveillance programs enable early detection and resolution of safety issues, reduce liability exposure, and support successful long-term market presence by maintaining public confidence in device safety through proactive risk management and transparent regulatory compliance.
# Product Changes
Source: https://docs.withdovetail.com/regulatory-requirements/product-changes
Manage systematic device modifications ensuring controlled evolution and regulatory compliance.
## Summary
Product Changes encompasses the systematic management of modifications to your medical device after market release. You implement structured change control processes through three key documents: **Change Requests** to initiate modifications, **Bug Fix Reports** to address software defects, and **Change Evaluation Reports** to assess the significance and impact of implemented changes.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design changes require **design controls** under Section 820.30(i)
* Change control procedures must be **established and maintained**
* **Management approval** required for design changes (820.30(i))
* Changes must be **documented** and **verified/validated** as appropriate
* **Risk analysis** must be updated for changes affecting safety or effectiveness
**Special attention required for:**
* Changes that may require FDA notification or new 510(k) submission
* Software changes affecting device classification or predicate comparison
* Modifications impacting labeling, intended use, or contraindications
* Bug fixes affecting safety-critical device functions
Under **EU MDR 2017/745**:
* Significant changes require **notified body notification** under Article 120
* Changes must be evaluated against **general safety and performance requirements**
* **Quality management system** must control all changes (Article 10(9))
* **Technical documentation** must be updated to reflect changes (Annex II)
* **CE marking** validity depends on change significance assessment
**Special attention required for:**
* Assessment of change significance using Article 120 criteria
* EUDAMED registration updates for device modifications
* Software problem resolution compliance with IEC 62304 Chapter 9
* Integration with post-market surveillance and vigilance systems
## Overview
Product Changes provides the **foundation for controlled device evolution** throughout your device's post-market lifecycle. This card ensures that all modifications—whether driven by customer feedback, technical improvements, or regulatory requirements—follow systematic processes that maintain device safety and regulatory compliance.
The **Change Request** serves as your gateway for initiating modifications, requiring cross-functional evaluation from product, quality, and business teams before implementation. This process prevents uncontrolled changes while ensuring proper impact assessment of proposed modifications. You use change requests to document the rationale for changes, identify affected products and components, and anticipate impacts on documentation, testing, and regulatory submissions.
**Bug Fix Reports** address the unique requirements for resolving software defects in medical device applications. Unlike general software development, medical device bug fixes require **regulatory-compliant documentation** that demonstrates systematic investigation, risk analysis, and verification of corrections. These reports ensure that software defect resolution follows your change management process while maintaining traceability to your design controls and risk management systems.
The **Change Evaluation Report** provides post-implementation assessment of changes to determine their regulatory significance and guide compliance decisions. This critical document evaluates whether implemented changes require **notified body notification**, affect **CE marking validity**, or necessitate **FDA submissions**. The evaluation process uses specific regulatory criteria to classify changes as significant or nonsignificant, directly impacting your ongoing market authorization.
Together, these three documents create a **comprehensive change control ecosystem** that enables innovation while maintaining regulatory compliance. They provide auditable evidence of systematic change management, support post-market surveillance activities, and ensure that device evolution enhances rather than compromises safety and effectiveness. This systematic approach protects patients, maintains stakeholder confidence, and supports sustainable device improvement throughout the product lifecycle.
The change management process integrates seamlessly with your broader quality management system, connecting to **risk management** for hazard assessment, **design controls** for verification requirements, **post-market surveillance** for trend analysis, and **vigilance systems** for safety reporting. This integration ensures that changes contribute to continuous improvement while maintaining the systematic quality approach required for medical device manufacturing.
# Product Release
Source: https://docs.withdovetail.com/regulatory-requirements/product-release
Verify regulatory documentation and processes ensuring complete compliance before commercial deployment.
## Summary
You must conduct systematic verification of all regulatory documentation and processes before releasing your medical device to ensure complete compliance with quality management requirements and market authorization conditions. Product release activities serve as the final quality gate that confirms your device is ready for safe commercial deployment while meeting all applicable regulatory obligations.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation), you must implement:
* **Design transfer verification** per Section 820.30(h) confirming production readiness
* **Production and process controls** per Section 820.70 ensuring quality manufacturing
* **Design history file** completion per Section 820.30(j) before commercial distribution
* **Device labeling controls** per Section 820.120 ensuring proper identification and instructions
* **Finished device acceptance** per Section 820.80 confirming device specifications
**Special attention required for:**
* **Software validation completion** per FDA software validation guidance
* **Cybersecurity documentation** updates for software devices per FDA guidance
* **510(k) substantial equivalence** maintenance for predicate device changes
* **Post-market surveillance** system activation per Section 820.100
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must comply with:
* **Design transfer completion** per EN ISO 13485:2016 Section 7.3.7
* **Production and service provision** controls per EN ISO 13485:2016 Section 7.5
* **Technical documentation** completion supporting CE marking per Annex II
* **Declaration of Conformity** issuance per Article 19 before market placement
* **EUDAMED registration** completion per Article 29 before distribution
**Special attention required for:**
* **UDI-PI assignment** for each device version per Article 27
* **Notified body notification** for significant device changes
* **Post-market surveillance** system implementation per Article 83
* **Clinical evaluation** completion supporting market authorization per Article 61
## Overview
Product release represents the **culminating milestone** in medical device development where systematic verification confirms that all regulatory requirements have been met and your device is ready for safe commercial deployment. This comprehensive process transforms development outputs into market-ready products through rigorous documentation review, compliance verification, and quality system confirmation that provides confidence in device safety and regulatory compliance.
**Software Release Checklist Verification** ensures systematic completion of all software development lifecycle requirements including design controls, verification and validation activities, risk management updates, and documentation currency. The software release checklist serves as a comprehensive quality gate that confirms all software requirements are properly implemented, tested, and documented according to IEC 62304 standards. This verification process includes confirming that version control procedures have been followed, that all testing activities demonstrate software functionality and safety, and that any identified anomalies have been properly evaluated and resolved through your established quality management procedures.
**Release Notes Documentation** provides comprehensive communication about device changes, new features, resolved issues, and any important information that users or healthcare providers need to know about the new device version. Release notes serve as critical user communication that ensures proper device utilization while supporting post-market surveillance activities by establishing clear documentation of what changes were implemented in each device version. The documentation process requires synthesis of development activities, testing results, and risk assessment findings into user-friendly communication that supports safe device deployment.
**Device Label Creation and Verification** ensures that all required identification, safety, and regulatory information is properly displayed on device packaging and within software interfaces according to applicable labeling requirements. Device labeling serves as the primary identification mechanism that enables traceability, regulatory compliance, and user safety by providing essential information including device identification, regulatory markings, safety warnings, and user instructions. Label verification requires systematic review against regulatory requirements while ensuring consistency with other device documentation and marketing materials.
**List of Medical Devices Management** maintains comprehensive records of all device variants, software versions, and configuration options that are authorized for commercial distribution. This systematic device management enables effective post-market surveillance, regulatory reporting, and change control by providing clear identification and tracking of all devices that have been released to market. Device list management requires integration with UDI systems, regulatory registrations, and quality management procedures to ensure complete traceability and compliance throughout the commercial device lifecycle.
**Regulatory Registration Verification** confirms that all required registrations have been completed with appropriate regulatory authorities before commercial distribution begins. Registration verification includes confirmation that FDA establishment registration and device listing activities are current, that EU competent authority and notified body notifications are complete, and that all market-specific requirements have been satisfied. This verification process prevents regulatory violations while ensuring that appropriate authorities are aware of your device's commercial availability and can effectively conduct post-market oversight activities.
**Quality Management System Readiness** confirmation ensures that all required procedures, personnel training, and system capabilities are in place to support commercial operations while maintaining regulatory compliance. Quality system readiness includes verification that manufacturing controls are validated, complaint handling procedures are operational, corrective and preventive action systems are functional, and post-market surveillance activities are prepared for implementation. This systematic readiness assessment ensures that commercial operations can maintain the same quality standards that were established during development activities.
**Documentation Package Completeness** verification ensures that all regulatory documents are current, accurate, and properly controlled before device release. Documentation review includes confirmation that the technical file or design history file is complete, that all required testing and evaluation reports are finalized, that risk management documentation reflects final device configuration, and that clinical evaluation activities support the intended use and market claims. Complete documentation packages enable confident regulatory interactions while supporting ongoing compliance and post-market activities.
**Change Control Integration** ensures that all device modifications implemented during final development stages have been properly evaluated, approved, and documented according to established change control procedures. Change control verification includes confirmation that any late-stage design changes have undergone appropriate risk assessment, that verification and validation activities address the changes, and that all affected documentation has been updated accordingly. Proper change control prevents uncontrolled modifications while maintaining regulatory compliance throughout the development-to-commercialization transition.
**Post-Market Surveillance Preparation** confirms that systems and procedures are in place to monitor device performance, collect user feedback, and respond to safety issues after commercial deployment begins. Surveillance preparation includes verification that complaint handling procedures are operational, that adverse event reporting systems are functional, that post-market study protocols are implemented if required, and that personnel are trained on regulatory reporting obligations. Well-prepared surveillance systems enable proactive safety monitoring while supporting regulatory compliance and continuous improvement activities.
Your product release activities must demonstrate **systematic completion** of all development requirements while providing confidence that commercial operations can maintain the same quality and safety standards that were established during device development. Effective product release processes prevent premature market deployment, reduce post-market risks, and support successful commercial launch by ensuring that all regulatory obligations have been systematically addressed before devices reach patients and healthcare providers.
# Product Requirements
Source: https://docs.withdovetail.com/regulatory-requirements/product-requirements
Transform user needs into testable technical specifications bridging expectations with implementable design criteria.
## Summary
You must translate user needs into specific, testable technical requirements that define exactly what your medical device must do to meet user expectations. Product requirements establish the foundation for all design and development activities by creating measurable criteria that bridge the gap between user needs and technical implementation.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), you must implement:
* **Documented design inputs** derived from user needs and regulatory requirements
* **Objective and testable** requirements enabling design output verification
* **Traceability** from user needs through system and subsystem requirements
* **Review and approval** of all requirements before implementation
* **Change control** procedures governing requirement modifications
**Special attention required for:**
* **Software medical devices** per FDA Software as Medical Device guidance
* **Design input requirements** must be unambiguous and verifiable
* **Risk control requirements** derived from ISO 14971 risk management
* **Cybersecurity requirements** per FDA cybersecurity guidance framework
Under **EU MDR 2017/745** and **EN ISO 13485:2016** Section 7.3.3, you must comply with:
* **Functional, performance, and safety** requirements specification
* **Complete, unambiguous, and verifiable** design inputs
* **General Safety and Performance Requirements** (GSPR) implementation
* **Traceability throughout design process** per Article 10(9)
* **Risk management integration** per EN ISO 14971:2019
**Special attention required for:**
* **Software lifecycle processes** per IEC 62304 for software requirements
* **Clinical evaluation requirements** influencing system design specifications
* **Post-market surveillance** considerations in requirement definition
* **AI/ML devices** requiring specific requirement considerations per emerging MDCG guidance
## Overview
Product requirements form the **critical bridge** between user expectations and technical implementation by transforming high-level user needs into specific, measurable criteria that your development team can design against. This systematic translation process ensures that every aspect of your device's functionality is deliberately planned, traceable, and verifiable through testing.
Your **System Requirements List** establishes the foundation by defining what your device must do at the highest level of technical specification. These requirements translate user needs into objective, testable criteria that specify functional performance, safety characteristics, and operational constraints without prescribing implementation details. System requirements provide the strategic framework that guides all subsequent design decisions while maintaining flexibility for innovative solutions. Each requirement must trace directly back to user needs, ensuring that your development efforts address real user expectations rather than unnecessary features.
**Subsystem Requirements** break down system-level specifications into detailed, implementable requirements for each component or functional area of your device. These granular requirements provide the technical specifications that individual development teams need to design, build, and verify specific subsystems. The subsystem level ensures comprehensive coverage by addressing hardware components, software modules, user interfaces, and system integrations with sufficient detail for implementation while maintaining clear traceability to system requirements.
**Risk control requirements** represent a critical subset that transforms your risk assessment findings into specific safety features and protective measures. These requirements ensure that identified hazards are controlled through design rather than relying solely on user training or protective equipment. Risk control requirements must be seamlessly integrated with functional requirements to create cohesive designs that are both effective and safe.
The **hierarchical relationship** between requirements levels creates a comprehensive specification framework that scales from user needs through system implementation. User needs inform system requirements, which drive subsystem requirements, which guide detailed design specifications. This structured approach ensures nothing falls through the cracks while maintaining clear decision-making criteria at each development level.
**Requirement quality** directly impacts development success and regulatory approval. Well-written requirements use active voice, specific measurable criteria, and unambiguous language that eliminates interpretation differences between team members. Poor requirements lead to design inconsistencies, verification failures, and regulatory compliance issues that require costly rework and delay market approval.
Your requirements must address **complete device functionality** including normal operation, edge cases, error conditions, and environmental variations. Consider performance under stress, degraded conditions, and reasonably foreseeable misuse scenarios. Requirements should specify not only what the device does, but how well it performs, under what conditions, and with what reliability.
**Traceability maintenance** throughout the requirements hierarchy enables impact assessment for changes, comprehensive verification planning, and regulatory compliance demonstration. Each requirement must clearly link to its source (user needs or regulatory requirements) and its implementation (design outputs and verification methods). This traceability becomes essential during design changes, post-market surveillance, and regulatory inspections.
The quality and completeness of your product requirements directly determine development efficiency, verification success, and regulatory approval outcomes. Well-structured requirements enable focused development, comprehensive testing, and confident regulatory submissions while reducing development costs and time-to-market.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/purchasing,-sales-and-suppliers
Control supply chain quality through systematic supplier evaluation, qualification, and ongoing performance monitoring.
## Summary
Supplier management establishes **critical control points** throughout your medical device supply chain, ensuring all purchased materials, components, and services meet specified quality requirements and regulatory standards. You must implement systematic supplier evaluation, qualification, and ongoing monitoring processes that demonstrate control over your entire supply chain from raw materials to finished device components.
## Regulatory Context
Under **21 CFR Part 820.50** (Purchasing Controls):
* **Supplier evaluation and selection** based on ability to meet specified requirements including quality systems
* **Purchasing documentation** must define product specifications and quality requirements clearly
* **Supplier control measures** proportionate to supplier impact on device quality and safety
* **Receiving inspection** or verification activities to ensure purchased products meet specifications
**Key Standards:**
* FDA Quality System Regulation (21 CFR Part 820)
* FDA Software Guidance for software supplier validation
* ISO 9001 quality management principles for supplier relationships
**Special attention required for:**
* Critical component suppliers requiring enhanced qualification and ongoing surveillance
* Contract manufacturer oversight including process validation and quality agreements
* Software supplier validation for design control and production systems
* Single-source supplier risk management and contingency planning
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Supplier evaluation processes** must consider ability to provide products meeting organization requirements (ISO 13485 7.4.1)
* **Risk-based supplier control** with oversight proportionate to supplier impact on product quality
* **Purchasing information documentation** including specifications and supplier qualification criteria
* **Critical supplier oversight** through quality agreements and periodic re-evaluation
**Key Standards:**
* ISO 13485:2016 Medical devices - Quality management systems
* ISO 9001:2015 Quality management systems - Requirements
* ISO 14971:2019 Medical devices - Risk management (for supplier risk assessment)
**Special attention required for:**
* Notified Body expectations for critical supplier documentation and audit evidence
* EU GDPR compliance when suppliers process personal data
* Supply chain traceability requirements for higher-risk device classifications
* Authorized representative and distributor qualification for EU market access
## Overview
Supplier management represents the **strategic foundation** for medical device quality assurance, extending your quality management system beyond organizational boundaries to encompass the entire supply chain that influences device safety and regulatory compliance. This card establishes the systematic frameworks necessary for transforming vendor relationships into controlled quality partnerships that support consistent medical device performance throughout the product lifecycle.
### Supply Chain Quality Architecture
Your supplier management program operates through **interconnected control systems** that assess, qualify, and monitor external suppliers providing materials, components, and services affecting medical device quality. The architecture balances **comprehensive supplier oversight** with **resource efficiency**, ensuring critical suppliers receive appropriate attention while avoiding unnecessary bureaucracy for low-risk commercial relationships.
**Supplier qualification processes** establish the entry criteria for your supply chain, evaluating potential suppliers against systematic requirements including quality management systems, technical capabilities, regulatory compliance, and business stability. This qualification framework ensures only capable suppliers enter your supply chain while providing documented evidence of systematic supplier selection for regulatory compliance.
**Approved supplier lists** serve as the operational registry that documents qualified suppliers, tracks their performance over time, and maintains current contact information and qualification status. These lists function as both procurement tools and audit evidence, demonstrating ongoing supplier control and providing traceability for purchased materials and services throughout device development and manufacturing.
### Risk-Based Supplier Control Strategy
Effective supplier management requires **differentiated control strategies** that allocate oversight resources proportionate to supplier impact on device quality, safety, and regulatory compliance. **Critical suppliers** providing components directly affecting device performance receive enhanced evaluation, formal quality agreements, and ongoing surveillance, while **non-critical suppliers** require basic qualification without extensive ongoing monitoring.
**Criticality assessment processes** systematically evaluate each supplier's potential impact on device quality, considering factors including component criticality, supplier uniqueness, regulatory implications, and business continuity risks. This assessment drives appropriate control measures including audit requirements, quality agreement terms, performance monitoring frequency, and contingency planning needs.
**Performance monitoring systems** track supplier quality, delivery, and service performance over time, identifying suppliers requiring corrective action and recognizing high-performing suppliers for expanded relationships. Performance data feeds back into qualification decisions, providing objective evidence for supplier approvals, restrictions, or terminations based on demonstrated capabilities rather than initial assessments alone.
### Integration with Quality Management System
Supplier management integrates deeply with multiple quality system processes, creating **bidirectional relationships** that strengthen overall device quality and regulatory compliance. **Design control processes** rely on qualified suppliers for critical components and services, while supplier performance data influences design decisions and risk assessments throughout device development.
**Change management procedures** ensure supplier modifications affecting device specifications receive appropriate evaluation through design controls, risk management, and validation processes. Supplier change notifications trigger systematic assessment of impacts on device performance, regulatory compliance, and manufacturing consistency, ensuring controlled evaluation of all supply chain modifications.
**Corrective and preventive action (CAPA) systems** address supplier-related quality issues systematically, identifying root causes and implementing appropriate corrective measures including supplier development, alternative sourcing, or enhanced incoming inspection. CAPA effectiveness feeds back into supplier performance assessments and future qualification decisions.
### Supplier Lifecycle Management
Supplier relationships evolve throughout medical device development and commercialization, requiring **adaptive management approaches** that respond to changing technical requirements, regulatory landscapes, and business conditions. **Early development phases** emphasize technical capability assessment and development support, while **commercial phases** focus on manufacturing consistency, cost management, and supply chain stability.
**Supplier development activities** support continuous improvement of supplier capabilities through collaboration, training, and technical assistance that benefits both organizations. Development investments in critical suppliers strengthen supply chain capabilities while demonstrating commitment to long-term quality partnerships rather than transactional purchasing relationships.
**Supply chain resilience planning** addresses potential disruptions through qualified backup suppliers, inventory management strategies, and contingency procedures that maintain production continuity during supplier changes or market disruptions. Resilience planning becomes increasingly important as devices achieve commercial success and supply chain disruptions could affect patient access to needed medical devices.
### Technology and Service Provider Management
Modern medical device development increasingly relies on **specialized service providers** including software developers, testing laboratories, regulatory consultants, and cloud service providers that require specific qualification approaches different from traditional material suppliers. These relationships often involve intellectual property, data security, and regulatory expertise that extend beyond traditional supplier evaluation criteria.
**Software supplier validation** encompasses both software-as-a-service providers and software components integrated into medical devices, requiring evaluation of cybersecurity, data integrity, validation documentation, and ongoing support capabilities. Software suppliers often require ongoing validation maintenance as systems evolve and security requirements change.
**Professional service providers** including regulatory consultants, testing laboratories, and clinical research organizations require qualification based on technical expertise, regulatory knowledge, and quality system compliance rather than manufacturing capabilities. Service provider management emphasizes competency verification, project management capabilities, and result quality rather than product consistency.
The supplier management card establishes the **comprehensive infrastructure** for supply chain quality assurance that enables reliable medical device development, manufacturing, and commercialization while maintaining regulatory compliance and supporting audit readiness throughout the device lifecycle.
# Risk Management
Source: https://docs.withdovetail.com/regulatory-requirements/risk-management
Identify analyze and control potential hazards ensuring patient safety through systematic risk mitigation strategies.
## Summary
You must systematically identify, analyze, control, and monitor all potential risks throughout your medical device lifecycle to ensure patient safety and regulatory compliance. Risk management establishes the foundation for safe device design by transforming potential hazards into controlled, acceptable risks through structured analysis and targeted mitigation strategies.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), you must implement:
* **Documented risk management processes** integrated with design controls
* **Risk analysis** following **ISO 14971:2019** consensus standard
* **Risk control measures** verified through testing and validation
* **Risk management file** maintained throughout device lifecycle
* **Post-market risk monitoring** with documented updates
**Special attention required for:**
* Software risk management per **IEC 62304** with safety classification integration
* **Cybersecurity risks** requiring ongoing threat assessment and controls
* **Combination devices** needing coordinated risk management across all components
* **Use-related risks** per FDA Human Factors guidance and **IEC 62366-1**
Under **EU MDR 2017/745** Article 10 and Annex I GSPR 3, you must comply with:
* **EN ISO 14971:2019** harmonized standard for risk management
* **Comprehensive risk assessment** documented in technical file (Annex II)
* **Clinical evaluation integration** addressing benefit-risk balance (Article 61)
* **Post-market surveillance** feeding risk management updates (Articles 83-86)
* **PRRC oversight** ensuring risk management compliance
**Special attention required for:**
* **Clinical evidence** requirements driven by risk management outcomes
* **Post-market clinical follow-up** monitoring risks requiring ongoing evaluation
* **AI/ML devices** requiring specific risk considerations per emerging MDCG guidance
* **Vigilance reporting** coordinated with risk management processes
## Overview
Risk management forms the **critical safety foundation** for your entire medical device development process, requiring you to proactively identify and control potential hazards before they can cause patient harm. This comprehensive approach transforms abstract safety concerns into concrete, manageable risks through systematic analysis and targeted control measures.
Your **Risk Management Plan** establishes the strategic framework for all risk activities by defining your organizational approach, risk acceptance criteria, assessment methodologies, and team responsibilities. This foundational document transforms regulatory requirements into actionable processes that guide your team through complex safety decisions. The plan integrates risk management with design controls, quality systems, and post-market surveillance, ensuring safety considerations drive development decisions rather than being afterthoughts.
Through your **Risk Assessment**, you systematically identify every foreseeable hazard associated with your device, analyzing how these hazards could lead to patient harm and quantifying both probability and severity. This detailed analysis covers hardware failures, software malfunctions, cybersecurity threats, use errors, environmental factors, and biological risks across your device's complete lifecycle. The assessment provides the analytical foundation for determining which risks are acceptable and which require control measures, establishing clear traceability from hazards to harms to controls.
Your **Risk Management Report** demonstrates successful execution of your risk management strategy by summarizing all activities, documenting control measure effectiveness, and providing final risk acceptability conclusions. This critical document proves to regulators that you have systematically addressed safety throughout development and that any residual risks are acceptable compared to clinical benefits.
The **interconnected nature** of these risk management tasks creates a comprehensive safety net that evolves with your device development. Risk management drives design requirements by identifying needed safety features, influences verification testing by determining critical failure modes to test, and shapes clinical evaluation by establishing benefit-risk criteria. Post-market surveillance feeds back into risk management through real-world incident data, creating a continuous improvement cycle that maintains device safety throughout its commercial lifecycle.
**Software-containing devices** require special consideration through IEC 62304 safety classification, which determines development rigor based on potential software contribution to hazardous situations. **Cybersecurity risks** demand ongoing assessment and control as threats evolve, while **usability engineering** must address use-related risks that could lead to use errors. These specialized risk areas integrate with your overall risk management approach rather than standing alone.
Your risk management activities must demonstrate **regulatory compliance** by following recognized standards like ISO 14971, maintaining complete documentation with clear traceability, and proving that benefits outweigh residual risks. The quality of your risk management directly impacts regulatory approval timelines, post-market surveillance requirements, and long-term market success by establishing credible evidence of device safety and effective risk control.
# Surveillance Reports
Source: https://docs.withdovetail.com/regulatory-requirements/surveillance-reports
Document systematic device monitoring providing regulatory evidence of ongoing safety analysis.
## Summary
Surveillance Reports document your **systematic analysis of device safety and performance** throughout the post-market lifecycle through comprehensive evidence evaluation. You demonstrate ongoing compliance through three critical reports: **Post-Market Surveillance Reports** for safety and performance monitoring, **Periodic Safety Update Reports** for comprehensive benefit-risk analysis, and **Post-Market Clinical Follow-Up Reports** for real-world clinical evidence evaluation.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and various FDA guidance documents:
* **Post-market surveillance studies** under 21 CFR 822 require periodic reporting to FDA
* **Real-World Evidence (RWE)** submissions support regulatory decision-making
* **Premarket Approval (PMA)** devices require periodic safety updates under 21 CFR 814.84
* **Risk Evaluation and Mitigation Strategies (REMS)** assessments for certain devices
* **Systematic data collection** and trend analysis must be documented
**Special attention required for:**
* Devices under FDA enforcement actions requiring enhanced surveillance
* Class III devices with intensive surveillance requirements
* Software updates affecting safety profiles requiring validation
* Post-market study commitments requiring compliance reporting
Under **EU MDR 2017/745**:
* **Post-Market Surveillance Report** required under Article 84 with systematic analysis
* **Periodic Safety Update Reports (PSURs)** required for implantable and Class III devices (Article 86)
* **Post-Market Clinical Follow-up (PMCF)** reports must feed into clinical evaluation updates (Article 61)
* **Notified body submission** required at intervals determined during conformity assessment
* **EUDAMED integration** for incident tracking and trend analysis
**Special attention required for:**
* High-risk devices requiring enhanced surveillance frequency
* Clinical evaluation updates based on surveillance findings
* Benefit-risk analysis integration with all surveillance data sources
* Compliance with MDCG guidance documents for surveillance reporting
## Overview
Surveillance Reports provide **regulatory evidence** of your active commitment to monitoring device safety and performance throughout the post-market lifecycle. This card ensures that you systematically collect, analyze, and report comprehensive data that demonstrates ongoing device safety, effectiveness, and compliance with essential requirements while identifying emerging risks requiring intervention.
The **Post-Market Surveillance Report** serves as your **primary evidence** of systematic safety monitoring by synthesizing vigilance data, complaints, incidents, and trend analyses collected during defined surveillance periods. These reports demonstrate your capability to identify safety signals, assess their clinical significance, and implement appropriate risk controls. The comprehensive analysis includes statistical trend evaluation, international vigilance database searches, and integration with your corrective and preventive action systems to ensure systematic response to emerging safety concerns.
**Periodic Safety Update Reports** provide **comprehensive benefit-risk analysis** specifically required for implantable devices and certain high-risk medical devices. Unlike standard surveillance reports, PSURs require integration of clinical data, real-world evidence, and safety signals to support continued market authorization decisions. These reports demonstrate that device benefits continue to outweigh risks as clinical experience accumulates, providing notified bodies and competent authorities with evidence needed for certificate renewals and ongoing compliance assessments.
**Post-Market Clinical Follow-Up Reports** document **real-world clinical evidence** collected through systematic PMCF activities outlined in your PMCF plan. These reports integrate literature findings, registry studies, user surveys, and clinical data collection to verify that pre-market clinical evaluation conclusions remain valid in real-world use environments. PMCF reports provide evidence of continued clinical effectiveness, user satisfaction, and appropriate real-world performance while identifying any discrepancies requiring clinical evaluation updates.
Together, these three reports create a **comprehensive surveillance evidence base** that supports regulatory compliance, demonstrates systematic quality improvement, and provides objective evidence of ongoing device safety and effectiveness. The reports enable proactive risk management by identifying trends before they become serious incidents, support strategic decision-making through comprehensive data analysis, and maintain stakeholder confidence through transparent safety communication.
The surveillance reporting process integrates seamlessly with your **vigilance system** for incident data, **CAPA processes** for systematic improvement, **risk management** for hazard assessment, and **clinical evaluation** for benefit-risk updates. This integration ensures that surveillance findings transform into actionable improvements while maintaining the rigorous documentation standards required for medical device post-market oversight.
The systematic approach to surveillance reporting demonstrates your commitment to **continuous monitoring** and **evidence-based decision-making** throughout the device lifecycle. By providing comprehensive analysis of real-world performance data, these reports enable regulatory authorities to assess ongoing device safety, support market access decisions, and ensure that patients continue to receive safe and effective medical devices as clinical experience expands.
# Technical File
Source: https://docs.withdovetail.com/regulatory-requirements/technical-file
Compile comprehensive technical documentation demonstrating compliance with EU regulatory requirements.
## Summary
You must compile a comprehensive Technical File that demonstrates your medical device's compliance with EU MDR requirements through systematic documentation of design, manufacturing, safety, performance, and clinical evidence. This essential regulatory package serves as the foundation for conformity assessment, CE marking authorization, and ongoing regulatory compliance throughout your device's commercial lifecycle.
## Regulatory Context
Under **EU MDR 2017/745** Annex II and supporting requirements, you must comply with:
* **Technical documentation** mandatory per Annex II for all device classes
* **Annex III requirements** for higher-risk devices requiring additional documentation
* **Clinical evaluation** integration per Article 61 and Annex XIV
* **Post-market clinical follow-up** documentation per Article 74
* **UDI and EUDAMED** integration per Article 27 and Article 29
**Special attention required for:**
* **Software lifecycle documentation** per IEC 62304 for software-containing devices
* **Notified body assessment** preparation for Class Is, Im, Ir, IIa, IIb, and III devices
* **Essential requirements compliance** demonstration per Annex I GSPR
* **Clinical evaluation updates** reflecting post-market findings and literature
## Overview
The Technical File represents the **comprehensive regulatory foundation** that systematically documents all aspects of your medical device development, validation, and compliance activities to demonstrate conformity with EU MDR requirements. This critical documentation package transforms your technical compliance efforts into structured evidence that supports regulatory review, notified body assessment, and ongoing market authorization while providing the regulatory backbone for commercial success and post-market compliance.
**Technical File Compilation and Structure** requires systematic organization of all regulatory documentation according to the mandatory structure defined in Annex II of EU MDR 2017/745. Technical file compilation involves gathering documentation from across your development activities including design controls, risk management, clinical evaluation, verification and validation, and post-market surveillance planning while ensuring that all information is current, accurate, and properly cross-referenced. The compilation process requires careful attention to document relationships and dependencies to create a coherent regulatory package that enables efficient review and demonstrates systematic compliance with all applicable requirements.
**Device Description and Identification Documentation** provides comprehensive technical details that enable regulatory authorities and notified bodies to understand your device's characteristics, intended use, and appropriate regulatory treatment. Device documentation must include detailed device descriptions covering principles of operation and technical functionality, intended purpose statements that align with clinical evaluation and marketing claims, device classification justification according to Annex VIII rules, and comprehensive technical specifications that support safety and performance evaluation. Complete device documentation enables accurate regulatory assessment while providing the foundation for appropriate oversight and post-market surveillance activities.
**Design and Development Documentation** demonstrates systematic application of design controls throughout your device development lifecycle while providing evidence that all user needs have been appropriately translated into safe and effective device implementation. Design documentation includes comprehensive design planning and control procedures, systematic requirements management from user needs through implementation, verification and validation evidence demonstrating requirement compliance, and design transfer documentation confirming manufacturing readiness. Effective design documentation provides confidence in development rigor while supporting regulatory review and ongoing compliance activities.
**Risk Management Integration** demonstrates systematic identification, analysis, and control of all potential device-related risks throughout the development and commercial lifecycle. Risk management documentation must include comprehensive risk management planning according to ISO 14971, systematic hazard identification and risk assessment covering all foreseeable risks, risk control implementation and verification evidence, and post-market risk monitoring procedures. Complete risk management integration provides evidence of systematic safety consideration while supporting benefit-risk evaluation and ongoing safety monitoring activities.
**Clinical Evaluation and Evidence Documentation** provides systematic evaluation of clinical safety and performance that supports intended use claims and regulatory approval. Clinical documentation includes comprehensive clinical evaluation planning that addresses evidence requirements, systematic literature review and analysis of relevant clinical data, clinical investigation protocols and results if applicable, and post-market clinical follow-up planning for ongoing evidence generation. Robust clinical documentation supports regulatory confidence while providing the evidence foundation for marketing claims and ongoing safety monitoring.
**Quality Management System Documentation** demonstrates systematic implementation of quality management requirements that ensure consistent device quality and regulatory compliance throughout commercial operations. Quality documentation includes quality management system procedures according to EN ISO 13485, manufacturing control procedures that ensure product consistency, supplier management and control procedures for external dependencies, and corrective and preventive action procedures for continuous improvement. Comprehensive quality documentation provides confidence in operational capability while supporting ongoing compliance and business sustainability.
**Verification and Validation Evidence** demonstrates systematic testing and evaluation that confirms device compliance with specifications and user needs under intended use conditions. Verification and validation documentation includes comprehensive test planning that addresses all critical device functions, systematic test execution and results documentation, usability evaluation evidence demonstrating safe and effective use, and performance evaluation under various operating conditions. Complete verification and validation evidence provides objective demonstration of device capability while supporting regulatory approval and user confidence.
**Labeling and User Information Documentation** ensures that all user-facing information supports safe and effective device use while meeting regulatory requirements for content, format, and accessibility. Labeling documentation includes comprehensive instructions for use that address all aspects of safe device operation, device labeling that meets identification and safety requirements, marketing materials that align with approved claims and evidence, and translation documentation ensuring accuracy across target markets. Effective labeling documentation supports user safety while enabling market access and commercial success.
**Post-Market Surveillance Planning Documentation** establishes systematic procedures for monitoring device performance and safety throughout the commercial lifecycle while enabling proactive identification and response to emerging safety issues. Surveillance documentation includes comprehensive post-market surveillance planning according to regulatory requirements, vigilance reporting procedures for adverse event management, complaint handling and analysis procedures, and clinical follow-up procedures for ongoing evidence generation. Robust surveillance planning provides confidence in ongoing safety monitoring while supporting regulatory obligations and continuous improvement.
**Document Control and Maintenance Procedures** ensure that Technical File documentation remains current, accurate, and properly controlled throughout the device lifecycle while supporting change control and regulatory communication requirements. Document control includes systematic version control and change management procedures, archive and retention procedures meeting regulatory requirements, access control and security procedures for confidential information, and update procedures that maintain currency with evolving requirements and device changes. Effective document control prevents compliance gaps while ensuring regulatory authorities have access to current and accurate information.
Your Technical File activities must demonstrate **systematic regulatory compliance** while providing the comprehensive evidence foundation necessary for confident regulatory approval and ongoing commercial success. Well-executed Technical File development provides regulatory confidence, enables efficient approval processes, and establishes the documentation foundation for successful long-term market presence by ensuring that all aspects of device development and compliance are systematically documented and maintained.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/training
Develop systematic training programs ensuring personnel competency and regulatory compliance across all medical device roles.
## Summary
Employee training forms the **foundational pillar** of your Quality Management System (QMS), ensuring every team member possesses the competencies necessary for medical device certification. You must establish systematic training programs that demonstrate personnel qualifications, maintain current knowledge of procedures, and provide documented evidence of competency for regulatory compliance under FDA and EU MDR requirements.
## Regulatory Context
Under **21 CFR Part 820.25** (Personnel):
* **Training procedures** must identify needs and ensure personnel understand quality responsibilities
* **Documented competency** is mandatory for all tasks affecting product quality
* **Training effectiveness** must be evaluated through systematic assessment methods
* **Management representative** requires specific QMS competency documentation
**Key Standards:**
* FDA Quality System Regulation (21 CFR Part 820)
* FDA Software Guidance Documents for software-related training
* FDA Cybersecurity Guidance for cybersecurity training requirements
**Special attention required for:**
* Design control personnel requiring comprehensive training on FDA design procedures (21 CFR 820.30)
* Software validation training for personnel developing software medical devices
* CAPA system training when implementing process improvements
* Clinical evaluation training for personnel managing clinical data
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Competence determination** for all personnel affecting product quality (ISO 13485 6.2.1)
* **Training documentation** demonstrating understanding of quality objectives and work relevance
* **Person Responsible for Regulatory Compliance (PRRC)** requires specific qualification training
* **Continuous improvement** of training programs through management review processes
**Key Standards:**
* ISO 13485:2016 Medical devices - Quality management systems
* EN ISO 14971:2019 Medical devices - Risk management
* MDCG 2019-16 Guidance on Cybersecurity for medical devices
**Special attention required for:**
* Clinical evaluation team qualifications requiring medical writing and systematic review expertise
* Post-market surveillance personnel needing vigilance and safety reporting training
* Risk management training aligned with ISO 14971 requirements
* Cybersecurity training addressing MDCG 2019-16 implementation
## Overview
Training represents the **critical intersection** between your organizational capabilities and regulatory compliance requirements, transforming procedural documentation into operational competency across your entire medical device organization. This card encompasses the systematic development, implementation, and maintenance of training programs that ensure every team member understands their role in producing safe and effective medical devices.
### Strategic Training Framework
Your training program must balance **comprehensive coverage** with **role-specific relevance**, ensuring employees receive training directly applicable to their quality responsibilities without overwhelming them with irrelevant procedures. The framework operates through two interconnected components: **individual training documentation** that tracks each employee's competency development over time, and **functional group training matrices** that systematically assign appropriate training requirements based on organizational roles and responsibilities.
**Individual training logs** serve as the primary evidence of competency development, documenting completion of required training activities and demonstrating understanding through learning summaries and formal acknowledgments. These logs create **audit-ready documentation** that proves regulatory compliance while supporting ongoing competency management throughout employee tenure.
**Functional group training requirements** provide the strategic structure for determining which procedures and training activities apply to different organizational roles. This systematic approach ensures **management personnel** receive appropriate oversight training, **technical teams** focus on development and validation procedures, **quality personnel** receive comprehensive QMS training, and **support teams** understand their interfaces with quality requirements.
### Training Integration with Quality System
Training programs integrate deeply with multiple aspects of your quality management system, creating **bidirectional relationships** that strengthen overall quality performance. **Document control procedures** trigger training requirements when SOPs are updated, ensuring employees understand current procedures before implementation. **Corrective and preventive action (CAPA) systems** identify training needs when non-conformities reveal competency gaps, while training effectiveness assessments feed back into process improvement activities.
**Management review processes** regularly evaluate training program performance through completion metrics, effectiveness assessments, and correlation with quality outcomes. This systematic evaluation ensures training programs remain aligned with organizational objectives and regulatory requirements while identifying opportunities for continuous improvement.
**Internal audit activities** verify training implementation effectiveness and identify gaps between training completion and actual job performance. Audit findings often reveal areas where additional training or alternative training methods may improve quality outcomes and regulatory compliance.
### Competency Management Throughout Product Lifecycle
Training requirements evolve throughout your medical device development and commercialization process, requiring **adaptive training programs** that respond to changing regulatory landscapes and organizational growth. **Early development phases** emphasize design control, risk management, and validation training for technical teams, while **commercialization phases** expand to include post-market surveillance, complaint handling, and clinical evaluation training.
**Organizational scaling** introduces additional training complexity as new employees join different functional groups and existing employees assume expanded responsibilities. Your training program must accommodate **rapid onboarding** of new personnel while maintaining training currency for existing team members facing evolving procedures and regulatory requirements.
**Regulatory changes** such as updated guidance documents, new standards, or modified regulatory requirements trigger **systematic training updates** across affected functional groups. Your training program must demonstrate agility in incorporating regulatory changes while maintaining comprehensive documentation of training activities and competency verification.
### Training Effectiveness and Continuous Improvement
Effective training programs extend beyond **completion documentation** to encompass **performance impact assessment** and **continuous improvement methodologies**. Training effectiveness manifests through improved quality metrics, reduced non-conformities, enhanced audit performance, and stronger regulatory compliance across all organizational functions.
**Performance correlation analysis** examines relationships between training completion and quality outcomes, identifying training programs that drive measurable improvements versus those requiring enhancement or modification. This analytical approach ensures training investments generate tangible quality improvements while optimizing resource allocation across competing training priorities.
**Feedback integration** from employees, managers, and external auditors provides continuous insight into training program effectiveness and relevance. Regular assessment of training methods, content accuracy, and practical applicability ensures training programs remain current with organizational needs and industry best practices.
The training card establishes the **foundational infrastructure** for competency management that supports all other quality system activities, creating sustained organizational capability for medical device development, manufacturing, and commercialization in compliance with applicable regulatory requirements.
# UDI Creation and EUDAMED Registration
Source: https://docs.withdovetail.com/regulatory-requirements/udi-eudamed-registration
Create unique device identifiers and register in EUDAMED database for EU market traceability.
## Summary
You must create Unique Device Identification (UDI) codes and register your medical device in the EUDAMED database before placing it on the EU market. This systematic identification and registration process enables complete device traceability, supports post-market surveillance activities, and fulfills mandatory regulatory requirements for market authorization and ongoing compliance monitoring.
## Regulatory Context
Under **EU MDR 2017/745** Article 27 and supporting regulations, you must comply with:
* **UDI Device Identifier (UDI-DI)** from EU-recognized issuing entities
* **UDI Production Identifier (UDI-PI)** with device-specific production information
* **Basic UDI-DI** creation for device families and regulatory documentation
* **EUDAMED registration** mandatory before market placement per Article 29
* **Single Registration Number (SRN)** prerequisite for EUDAMED access
**Special attention required for:**
* **European Medical Device Nomenclature (EMDN)** code accuracy for device classification
* **Software versioning** and UDI-PI format requirements for software devices
* **Custom-made device** UDI exemptions and alternative identification requirements
* **Legacy device** UDI implementation timelines and transition requirements
## Overview
UDI Creation and EUDAMED Registration establish the **foundational identification infrastructure** that enables complete device traceability throughout the commercial lifecycle while supporting regulatory oversight, post-market surveillance, and supply chain management. This systematic identification process transforms your medical device into a trackable, regulatorily-compliant product that can be effectively monitored and managed across global markets and healthcare systems.
**UDI Creation Process** involves obtaining unique identifiers from approved issuing entities that provide both permanent device identification and production-specific information enabling complete traceability. The UDI creation process requires selection of an appropriate issuing entity such as GS1, HIBCC, ICCBBA, or IFA based on your business needs and global distribution requirements. UDI-DI creation establishes the permanent identifier that remains constant for your device model, while UDI-PI creation provides production-specific information including software versions, manufacturing dates, and batch information that enables precise device tracking and post-market surveillance.
**Issuing Entity Registration** establishes your relationship with approved UDI issuing organizations that provide the technical infrastructure and identifier allocation systems necessary for UDI creation and management. Registration processes vary by issuing entity but typically involve purchasing company prefixes, establishing account relationships, and gaining access to identifier generation tools and databases. Effective issuing entity relationships provide ongoing support for UDI management while ensuring compliance with evolving UDI requirements and technical standards.
**Basic UDI-DI Creation** provides the simplified device family identifier that appears in regulatory documentation and enables systematic device grouping for regulatory and commercial purposes. Basic UDI-DI creation involves applying standardized algorithms to your UDI-DI that generate simplified identifiers for use in Declarations of Conformity, technical documentation, and regulatory submissions. This simplified identification enables efficient regulatory review while maintaining connection to detailed device-specific UDI information that supports traceability and post-market activities.
**Single Registration Number (SRN) Acquisition** provides the prerequisite manufacturer identification that enables access to EUDAMED registration systems and establishes your regulatory identity within EU databases. SRN acquisition involves completing manufacturer registration with EU competent authorities, providing comprehensive company information and regulatory contact details, and undergoing review processes that confirm your legitimacy as a medical device manufacturer. The SRN serves as your unique identifier within EU regulatory systems while enabling access to device registration and ongoing regulatory communication systems.
**European Medical Device Nomenclature (EMDN) Code Selection** ensures accurate device classification that supports appropriate regulatory treatment and effective post-market surveillance activities. EMDN code selection requires systematic analysis of your device's primary function and clinical application to identify the most specific and accurate nomenclature code that describes your device's intended use. Accurate EMDN coding affects regulatory classification decisions, post-market surveillance grouping, and vigilance reporting categories while ensuring that your device is properly categorized within European regulatory systems.
**EUDAMED Device Registration** completes the formal registration process that authorizes your device for EU market placement while establishing your presence in European regulatory databases. EUDAMED registration requires compilation of comprehensive device information including technical specifications, regulatory pathway, UDI information, and manufacturer details into systematic database entries. Registration completion enables CE marking application while establishing the regulatory foundation for post-market surveillance, vigilance reporting, and ongoing regulatory communication.
**Software Version Management** addresses the unique challenges of UDI implementation for software medical devices including version control, change management, and production identifier updates that maintain traceability across software evolution. Software UDI management requires establishing systematic procedures for UDI-PI updates that reflect significant software changes while maintaining constant UDI-DI identification for the software platform. Effective software UDI management enables precise tracking of software versions while supporting change control and post-market surveillance activities specific to software medical devices.
**Registration Maintenance and Updates** ensures that UDI and EUDAMED information remains current and accurate throughout your device's commercial lifecycle while supporting ongoing regulatory obligations and change management requirements. Maintenance activities include systematic review of registered information for accuracy, implementation of change control procedures that update registration data when device modifications occur, and monitoring of regulatory requirements that may affect UDI or registration obligations. Effective maintenance prevents compliance gaps while ensuring that regulatory authorities have access to current and accurate device information.
**Integration with Quality Management Systems** ensures that UDI and registration activities are properly integrated with your overall quality management and regulatory compliance systems. Integration activities include establishing procedures that link UDI creation with product development milestones, implementing change control processes that address UDI and registration updates, and creating traceability systems that connect UDI information with design controls, risk management, and post-market surveillance activities. Effective integration ensures that identification and registration activities support overall regulatory compliance while enabling efficient business operations.
Your UDI Creation and EUDAMED Registration activities must demonstrate **systematic compliance** with identification and traceability requirements while establishing the infrastructure necessary for effective post-market management and regulatory oversight. Well-executed UDI and registration processes enable confident market authorization, support effective post-market surveillance, and provide the foundation for long-term commercial success by ensuring that your devices can be effectively tracked and managed throughout their commercial lifecycle.
# Usability and Human Factors Engineering
Source: https://docs.withdovetail.com/regulatory-requirements/usability-human-factors-engineering
Evaluate user interactions identifying and mitigating use-related risks through systematic human factors testing.
## Summary
You must systematically evaluate how users interact with your medical device to identify and mitigate use-related risks that could lead to patient harm. Usability engineering ensures your device can be operated safely and effectively by intended users through structured testing and design optimization that addresses human factors throughout the development process.
## Regulatory Context
Under **FDA Human Factors Guidance** and **21 CFR Part 820.30** (Design Controls), you must implement:
* **Human factors engineering** addressing use-related hazards and user interface safety
* **Risk-based usability evaluation** focusing on critical tasks where errors could cause harm
* **Formative and summative testing** validating user interface design throughout development
* **Critical task identification** where user errors could lead to significant patient harm
* **Design control integration** ensuring usability findings inform design requirements
**Special attention required for:**
* **High-risk devices** requiring formal summative usability validation studies
* **Software medical devices** with complex user interfaces and workflow integration
* **Use-related hazard scenarios** documented in risk assessment and testing protocols
* **Clinical workflow integration** ensuring devices fit safely into existing care processes
Under **EU MDR 2017/745** and **IEC 62366-1:2015**, you must comply with:
* **Usability engineering** mandatory per General Safety and Performance Requirements
* **IEC 62366-1:2015** harmonized standard for usability engineering processes
* **Use-related hazard scenarios** identification and systematic testing
* **Usability engineering file** demonstrating systematic approach to human factors
* **Technical documentation integration** supporting conformity assessment procedures
**Special attention required for:**
* **Clinical evaluation integration** with usability findings per Article 61
* **Post-market surveillance** monitoring for use errors and difficulties
* **Risk management integration** per EN ISO 14971:2019 throughout development
* **AI/ML devices** requiring specific usability considerations for algorithmic outputs
## Overview
Usability and human factors engineering represents the **critical intersection** between human psychology, device design, and patient safety by ensuring your medical device can be operated safely and effectively by real users in real-world conditions. This systematic approach recognizes that even well-designed devices can cause patient harm if users cannot operate them correctly, making human factors engineering essential for both device effectiveness and regulatory compliance.
**Usability Evaluation Planning** establishes your strategic framework for understanding and controlling use-related risks throughout the device development lifecycle. The planning process transforms abstract human factors principles into concrete testing strategies that systematically evaluate how users interact with your device. Your plan must distinguish between formative evaluation activities that improve design during development and summative evaluation activities that validate final design safety and effectiveness. This strategic approach ensures that human factors considerations influence design decisions rather than being afterthoughts that require costly redesigns.
**Usability Evaluation Protocols** translate your high-level planning into specific, executable testing procedures that generate regulatory-compliant evidence of user interface safety and effectiveness. These detailed protocols transform use-related hazard scenarios from your risk assessment into specific test tasks that can be observed and measured objectively. The protocol development process requires careful consideration of participant selection criteria, testing environments that simulate real-world use conditions, and data collection methods that capture not only task completion but also use difficulties and near-miss situations that could indicate potential safety issues.
**Usability Evaluation Reporting** documents your systematic evaluation of human factors, providing evidence that your device can be used safely by intended users and that use-related risks have been identified and controlled. The reporting process synthesizes findings from both formative and summative evaluations to demonstrate that your user interface design supports safe, effective use while identifying any residual use-related risks that require ongoing monitoring or additional risk controls.
The **integrated nature** of usability engineering requires close coordination with risk management activities to ensure that use-related hazards are properly identified, assessed, and controlled throughout development. Use-related risks often represent some of the most significant threats to patient safety because they involve the complex interaction between human psychology, device design, and clinical environments that cannot be fully predicted through technical testing alone.
**Critical task identification** drives the focus and rigor of your usability evaluation by distinguishing between routine interactions and situations where user errors could lead to serious patient harm. Critical tasks require more extensive testing, stricter acceptance criteria, and often necessitate design changes if users cannot complete them reliably. The identification process must consider not only normal device operation but also use during emergencies, by stressed users, and in challenging environmental conditions.
**Testing environment design** ensures that your usability evaluation reflects realistic use conditions rather than idealized laboratory settings. Real-world use often involves distractions, time pressures, workflow interruptions, and environmental stressors that can significantly impact user performance. Your testing approach must balance controlled conditions that allow systematic observation with realistic conditions that reflect actual device use.
**Results integration** with your overall development process ensures that usability findings influence design decisions, inform risk management activities, and support regulatory submissions. Usability engineering is not a one-time activity but an ongoing process that continues through design iterations, design changes, and post-market surveillance to ensure that user interface safety is maintained throughout the device lifecycle.
Your usability engineering activities must demonstrate **regulatory compliance** by following recognized standards like IEC 62366-1, maintaining comprehensive documentation of evaluation activities, and proving that critical user interactions have been systematically evaluated and optimized for safety. The quality and thoroughness of your human factors engineering directly impacts user acceptance, clinical workflow integration, and long-term device success by ensuring that your device not only meets technical specifications but also supports safe, effective use in real clinical environments.
# User Needs
Source: https://docs.withdovetail.com/regulatory-requirements/user-needs
Capture comprehensive user expectations driving design decisions and establishing validation foundations for device development.
## Summary
User needs define what your users expect and require from your medical device, serving as the foundational document that drives all design decisions, requirements development, risk management activities, and validation testing. These documented needs ensure regulatory traceability and prevent costly redesigns by establishing clear user expectations before development begins.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), the FDA requires:
* **Documented user needs** as design inputs establishing device requirements
* **Traceability** from user needs through design requirements to verification and validation
* **Design review** of user needs to ensure completeness and accuracy
* **User needs validation** through clinical evaluation or usability testing
* **Change control** for user needs updates throughout development
**Standards applicable:**
* FDA Human Factors Guidance - Use-related risk analysis and usability engineering
* IEC 62366-1:2015 - Usability engineering for medical devices
* ISO 14971:2019 - Application of risk management to medical devices
* ISO 13485:2016 - Medical devices quality management systems
**Special attention required for:**
* Software as Medical Device (SaMD) user needs must address clinical workflow integration and decision-making support
* Combination devices require user needs for both hardware and software components with clear interfaces
* Cybersecurity considerations must be reflected in user needs for connected devices
* Usability engineering per FDA Human Factors guidance requires user needs to address use-related risks
Under **EU MDR 2017/745**, user needs support compliance with:
* **Annex I GSPR 1** requiring devices to achieve intended performance for users
* **EN ISO 13485:2016** Section 7.2.1 for customer-related processes
* **IEC 62366-1:2015** Section 5.2 for identifying user interface characteristics
* **EN ISO 14971:2019** for risk management based on intended use
**Standards applicable:**
* EN ISO 13485:2016 - Medical devices quality management systems
* IEC 62366-1:2015 - Medical devices usability engineering
* EN ISO 14971:2019 - Application of risk management to medical devices
* MDCG 2019-11 - Guidance on software qualification and classification
**Special attention required for:**
* Clinical evidence requirements may be driven by specific user needs claims about clinical benefits
* Person Responsible for Regulatory Compliance (PRRC) must ensure user needs remain current and accurate
* Post-market surveillance must include monitoring whether user needs continue to be met in real-world use
* AI/ML devices require user needs that address algorithm transparency and clinical decision support
## Overview
User needs serve as the **foundational cornerstone** of medical device development by capturing what users truly expect and require from your device before any design decisions are made. This critical documentation transforms abstract user expectations into concrete development inputs that guide every subsequent design decision throughout your product lifecycle.
The **User Needs List** represents your comprehensive capture of user expectations across all stakeholder groups including primary users, secondary users, technical staff, and regulatory considerations. This document establishes the basis for requirements traceability by ensuring every system requirement, software feature, and risk control can be traced back to a specific user need. The list must be solution-neutral and broad enough to accommodate future design changes while remaining specific enough to guide meaningful development decisions.
Effective user needs development requires **comprehensive user research** involving interviews with intended users, observation of current workflows, and analysis of pain points and inefficiencies in existing solutions. This research must engage multiple stakeholder groups to understand different perspectives on device use including functional needs, performance expectations, usability requirements, safety considerations, and environmental constraints.
The documentation distinguishes between **essential user needs** that apply to all devices in your category and **product-specific needs** that reflect your device's unique value proposition. Essential needs often relate to basic safety, regulatory compliance, and fundamental usability requirements, while product-specific needs drive innovation and differentiation by addressing the unique problems your device solves.
User needs establish the **validation foundation** for your entire development process by defining what success looks like from the user's perspective. They prevent over-engineering by focusing development efforts on features that truly matter to users while ensuring safety and effectiveness requirements are captured early. The documented needs also provide the foundation for validation activities that demonstrate your device meets its intended use through appropriate testing methods.
Throughout development, user needs require **ongoing maintenance and validation** through methods such as user interviews, usability testing, clinical evaluation, or pilot studies. Change control procedures must assess the impact of user needs updates on derived requirements, design decisions, and verification activities while maintaining traceability throughout the development process.
The comprehensive user needs documentation serves as your **design compass** throughout development while providing regulatory authorities with clear evidence that your device development is grounded in real user requirements and validated through appropriate methods. This systematic approach to user needs development ensures your device development remains focused on solving meaningful user problems while maintaining regulatory compliance and market relevance.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/verification-validation-planning
Create comprehensive testing roadmap proving device meets specifications and fulfills intended medical purpose.
## Summary
You must create comprehensive plans that systematically verify your medical device meets design specifications and validate it fulfills user needs and intended use requirements. Verification and validation planning establishes the testing roadmap that proves you built the device correctly and built the right device for its intended medical purpose.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), you must implement:
* **Design verification** per Section 820.30(f) confirming design outputs meet design inputs
* **Design validation** per Section 820.30(g) ensuring devices meet user needs and intended use
* **Statistical techniques** per Section 820.250 for determining sample sizes and acceptance criteria
* **Software validation** per FDA guidance for devices containing software components
* **Risk-based testing** focusing resources on safety-critical device functions
**Special attention required for:**
* **Software as Medical Device** validation per FDA SaMD classification framework
* **Cybersecurity validation** for networked devices per FDA premarket guidance
* **Clinical validation** requirements for novel devices or new indications
* **Predicate device comparison** for substantial equivalence demonstration in 510(k) pathway
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must comply with:
* **Design verification and validation** per EN ISO 13485:2016 Section 7.3.6
* **Technical documentation** requirements per Annex II supporting conformity assessment
* **Clinical evaluation** integration per Article 61 and Annex XIV
* **Essential requirements demonstration** through systematic verification and validation
* **Software lifecycle processes** per IEC 62304 for software-containing devices
**Special attention required for:**
* **Clinical evaluation requirements** potentially driving validation study design
* **Post-market clinical follow-up** integration with validation planning
* **Notified body assessment** of verification and validation completeness
* **Harmonized standards** application for presumption of conformity with essential requirements
## Overview
Verification and validation planning represents the **strategic foundation** for systematically proving your medical device is both built correctly and suitable for its intended medical purpose through comprehensive testing activities that demonstrate regulatory compliance and clinical effectiveness. This planning process transforms abstract requirements into concrete testing strategies that provide objective evidence of device safety, effectiveness, and quality.
**Verification and Validation Strategy Development** establishes your overarching approach to proving device compliance by distinguishing between verification activities that confirm design outputs meet design inputs and validation activities that demonstrate the complete device meets user needs and intended use requirements. Your strategic approach must address hardware verification through electrical safety and performance testing, software verification through systematic code and system testing, biocompatibility evaluation for patient-contacting materials, usability validation through human factors testing, and clinical validation when required for device effectiveness claims.
**Software System Test Planning** creates systematic approaches for verifying that your software components function correctly according to specifications while integrating safely with hardware and user interfaces. Software testing plans must address functional testing of software requirements, performance testing under various load conditions, security testing for cybersecurity risks, integration testing between software components, and regression testing to ensure changes don't introduce new defects. The planning process must consider Software of Unknown Provenance (SOUP) components, automated versus manual testing strategies, and test environment management that supports reproducible results.
**Performance and Bench Testing Planning** establishes methodologies for demonstrating that your device meets essential performance characteristics under various operating conditions. These plans must specify test methods that objectively measure device performance against specifications, environmental testing that confirms operation under intended use conditions, durability testing that validates device lifetime expectations, and accuracy testing that demonstrates measurement capabilities meet clinical requirements. Performance testing planning must consider statistical approaches for sample size determination and acceptance criteria that provide confidence in device capability.
**Biological Evaluation Planning** addresses biocompatibility assessment for devices that contact patients directly by establishing testing strategies according to ISO 10993-1 based on contact type, duration, and exposure pathways. The planning process must consider existing biocompatibility data for materials, testing requirements specific to your device's patient contact profile, and integration with risk management to address biological risks. Biological evaluation planning may reduce testing requirements through appropriate use of existing data while ensuring comprehensive safety assessment.
**Verification and Validation Protocol Development** translates strategic testing approaches into detailed, executable procedures that specify test methods, sample requirements, acceptance criteria, and documentation standards. Protocol development requires careful consideration of testing sequence dependencies, resource requirements, timeline constraints, and outsourced testing coordination. Each protocol must reference applicable standards, justify testing approaches, and establish clear pass/fail criteria that support regulatory decision-making.
**Electrical and Shelf-Life Testing Planning** ensures that your device meets electrical safety requirements per IEC 60601 series standards and maintains performance throughout its intended shelf life and operational lifetime. Electrical testing planning must address basic safety, essential performance, electromagnetic compatibility, and cybersecurity requirements while shelf-life planning validates device stability, packaging integrity, and performance degradation over time. These specialized testing areas require coordination with risk management to address identified electrical and aging-related hazards.
**Testing Resource and Timeline Management** coordinates all verification and validation activities to optimize testing efficiency while meeting development milestones and regulatory submission deadlines. Resource planning must consider laboratory capacity, testing equipment availability, sample preparation requirements, and results analysis timelines. Effective planning identifies critical path testing activities and develops contingency approaches for testing delays or failures that could impact development schedules.
**Acceptance Criteria Development** establishes objective, measurable standards for determining test success that align with device specifications, user needs, and regulatory requirements. Acceptance criteria must be clearly defined before testing begins to prevent subjective interpretation disputes and ensure consistent evaluation across all testing activities. The criteria development process requires statistical consideration of measurement uncertainty, device variability, and clinical relevance of performance parameters.
**Documentation and Traceability Planning** ensures that all verification and validation activities generate appropriate documentation that supports regulatory submissions and demonstrates systematic compliance with design control requirements. Documentation planning must address test report formats, data management procedures, traceability matrix maintenance, and change control integration that maintains testing integrity throughout development iterations.
Your verification and validation planning activities provide the **regulatory foundation** for demonstrating device safety and effectiveness through systematic testing that addresses all applicable requirements while optimizing development resources and timelines. Well-executed planning reduces testing redundancy, prevents late-stage discoveries of fundamental performance issues, and ensures comprehensive documentation that supports confident regulatory submissions and successful market authorization.
# Overview
Source: https://docs.withdovetail.com/regulatory-requirements/verification-validation-reports
Document testing results and evidence demonstrating device safety and regulatory compliance.
## Summary
You must document the execution and results of all verification and validation activities through comprehensive reports that demonstrate your medical device meets design specifications and fulfills user needs. These reports provide objective evidence of regulatory compliance and device safety through systematic documentation of testing outcomes, identified deviations, and corrective actions.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), you must implement:
* **Design verification reports** per Section 820.30(f) demonstrating design outputs meet inputs
* **Design validation reports** per Section 820.30(g) confirming devices meet user needs
* **Objective evidence** documentation supporting all verification and validation conclusions
* **Design history file** maintenance including all verification and validation records
* **Statistical analysis** documentation per Section 820.250 for test result interpretation
**Special attention required for:**
* **Software validation reports** per FDA guidance on software validation principles
* **Clinical validation documentation** for devices requiring clinical evidence
* **Predicate device comparison** documentation for 510(k) substantial equivalence
* **Cybersecurity validation** results for networked devices per FDA guidance
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must comply with:
* **Design verification and validation** documentation per EN ISO 13485:2016 Section 7.3.6
* **Technical documentation** completion supporting conformity assessment per Annex II
* **Essential requirements compliance** demonstration through verification and validation evidence
* **Notified body assessment** preparation with complete verification and validation documentation
* **Clinical evaluation integration** with validation findings per Article 61
**Special attention required for:**
* **Software lifecycle documentation** per IEC 62304 for software-containing devices
* **Risk management integration** showing verification of risk controls per EN ISO 14971
* **Post-market surveillance planning** based on verification and validation findings
* **Harmonized standards compliance** documentation for presumption of conformity
## Overview
Verification and validation reports represent the **culminating documentation** that transforms your testing activities into regulatory evidence by systematically documenting how your medical device meets both technical specifications and user needs through comprehensive testing and evaluation. These reports serve as the definitive proof that your device is safe, effective, and ready for market deployment while providing regulatory authorities with the objective evidence needed for approval decisions.
**Software System Test Reports** document the systematic execution of software verification activities, providing detailed evidence that your software components function correctly according to specifications while maintaining safety and performance standards. These reports capture test execution details including test environment configurations, actual test results, pass/fail determinations, and resolution of any identified defects or anomalies. Software test reporting must demonstrate complete requirement coverage, document regression testing results after defect fixes, and provide traceability between software requirements and verification evidence that supports regulatory submissions and ongoing software maintenance.
**Additional Software Test Reports** address specialized testing areas including integration testing between software components, performance testing under various load conditions, security testing for cybersecurity compliance, and compatibility testing across different platforms or operating systems. These supplementary reports ensure comprehensive coverage of software verification requirements while addressing specific technical domains that require specialized testing approaches and documentation standards.
**Biocompatibility Evaluation Reports** document biological safety assessment for devices that contact patients directly, providing evidence that materials and device components meet biocompatibility requirements according to ISO 10993 standards. These reports synthesize testing data or existing biocompatibility evidence to demonstrate that device materials pose acceptable biological risks based on contact type, duration, and exposure pathways identified in your intended use assessment.
**Verification Reports for Physical Components** encompass electrical safety testing, mechanical performance validation, environmental testing, and electromagnetic compatibility assessment that demonstrate hardware components meet safety and performance specifications. These reports document compliance with applicable standards such as IEC 60601 series for electrical safety, environmental testing standards, and mechanical testing protocols while providing evidence that physical device components operate safely under intended use conditions.
**Performance and Bench Verification Reports** document systematic testing of device performance characteristics against specifications, providing objective evidence that your device meets essential performance requirements under various operating conditions. These reports capture accuracy testing, reliability assessment, durability validation, and performance boundary testing that demonstrate device capability and identify any performance limitations that require user awareness or risk control measures.
**Shelf-Life and Packaging Verification Reports** demonstrate that your device maintains performance and safety throughout its intended storage period and operational lifetime. These reports document accelerated aging studies, packaging integrity testing, and stability assessment that support shelf-life claims and ensure device quality from manufacturing through end-of-life disposal.
The **integrated nature** of verification and validation reporting requires careful coordination between different testing domains to ensure comprehensive coverage without gaps or redundancies. Reports must demonstrate not only individual component compliance but also system-level integration and overall device performance that meets user needs and regulatory requirements.
**Deviation and anomaly documentation** within verification and validation reports provides transparency about testing challenges and their resolution while demonstrating systematic problem-solving approaches. Complete documentation of test failures, root cause investigations, corrective actions, and retest results shows regulatory authorities that your verification process is thorough and reliable.
**Traceability demonstration** through verification and validation reports links testing activities back to specific requirements, design outputs, and user needs while providing clear evidence that all aspects of device performance have been systematically evaluated. This traceability supports regulatory review processes and enables efficient impact assessment when design changes or post-market issues require evaluation.
Your verification and validation reports must provide **regulatory confidence** through clear, objective documentation that supports approval decisions and demonstrates ongoing compliance with design control requirements. Well-executed reporting reduces regulatory review timelines, prevents late-stage compliance issues, and provides the foundation for confident market authorization and commercial success by establishing credible evidence of device safety and effectiveness through systematic testing and evaluation.
# Verification and Validation Stage Checklists
Source: https://docs.withdovetail.com/regulatory-requirements/verification-validation-stage-checklists
Review testing completeness and readiness for regulatory submission through systematic checklists.
## Summary
You must conduct systematic reviews using structured checklists to verify that all verification and validation activities are complete, compliant, and provide sufficient evidence for regulatory approval. These checklists ensure comprehensive coverage of testing requirements and provide objective criteria for determining readiness to proceed with regulatory submission and market launch.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), you must implement:
* **Design verification completion** documented through systematic review per Section 820.30(f)
* **Design validation completion** confirmed through comprehensive evaluation per Section 820.30(g)
* **Design history file** completeness verified before regulatory submission
* **Objective evidence** review ensuring all verification and validation conclusions are supported
* **Risk management verification** confirming all risk controls are validated and effective
**Special attention required for:**
* **Software validation completeness** per FDA software validation guidance
* **Clinical validation adequacy** for devices requiring clinical evidence
* **Cybersecurity validation** coverage for networked devices per FDA guidance
* **510(k) submission readiness** including predicate device comparison adequacy
Under **EU MDR 2017/745** and **EN ISO 13485:2016**, you must comply with:
* **Design verification and validation** completeness per EN ISO 13485:2016 Section 7.3.6
* **Technical documentation** readiness supporting conformity assessment per Annex II
* **Essential requirements compliance** verification through systematic checklist review
* **Notified body submission** preparation with complete verification and validation evidence
* **Risk management completion** per EN ISO 14971:2019 integration requirements
**Special attention required for:**
* **Clinical evaluation completeness** supporting technical documentation per Article 61
* **Post-market surveillance preparation** integration with verification and validation findings
* **Harmonized standards compliance** documentation for presumption of conformity
* **Software lifecycle completion** per IEC 62304 for software-containing devices
## Overview
Verification and validation stage checklists serve as **comprehensive quality gates** that systematically evaluate the completeness and adequacy of all testing activities before proceeding with regulatory submission and commercial deployment. These structured reviews ensure that no critical verification or validation requirements have been overlooked and that all testing evidence supports confident regulatory approval and safe market introduction.
**Risk Management Report Completion** verification ensures that your systematic risk management process has been properly executed and documented throughout the development lifecycle. The checklist confirms that all identified risks have been appropriately analyzed, controlled, and monitored, with residual risks remaining at acceptable levels or properly justified through benefit-risk analysis. This verification includes confirmation that risk controls have been implemented as specified and validated through testing, that post-market risk management procedures are established, and that the risk management file provides complete documentation supporting regulatory submission and ongoing compliance.
**List of Known Anomalies Documentation** provides comprehensive accounting of all identified issues, their investigation findings, and resolution status throughout the development process. This systematic documentation demonstrates transparency about device limitations and ensures that all anomalies have been properly evaluated for safety impact and regulatory reporting requirements. The anomalies list enables regulatory reviewers to understand the complete development experience and confirms that all identified issues have been appropriately addressed or accepted through risk assessment.
**Traceability Matrix Completion** verification confirms that systematic traceability has been maintained from user needs through design implementation, verification testing, and validation activities. The checklist ensures that every user need has been translated into appropriate requirements, that all requirements have been implemented in design outputs, and that comprehensive testing has verified and validated all aspects of device performance. This traceability verification provides confidence that development was systematic and complete while supporting efficient regulatory review and ongoing maintenance activities.
**Verification and Validation Report Integration** ensures that all individual testing reports combine to provide comprehensive evidence of device compliance with specifications and user needs. The integration review confirms that testing coverage is complete without significant gaps, that test results support regulatory conclusions, and that any identified limitations or restrictions are properly documented and communicated. This systematic review validates that the complete verification and validation program provides sufficient evidence for regulatory approval and commercial deployment.
**Regulatory Submission Readiness Assessment** evaluates whether your verification and validation documentation package meets all applicable regulatory requirements for your target markets. The assessment confirms that all required testing has been completed according to applicable standards, that documentation meets regulatory submission requirements, and that evidence supports the claims and intended use statements in your regulatory application. This readiness evaluation prevents submission delays and regulatory queries by ensuring comprehensive preparation.
**Clinical Evidence Integration** verification ensures that clinical evaluation activities are properly integrated with verification and validation findings to support overall device safety and effectiveness claims. For devices requiring clinical evidence, the checklist confirms that clinical data addresses verification findings and supports validation conclusions while providing appropriate evidence for the intended use and target patient population.
**Manufacturing Readiness Verification** confirms that manufacturing processes have been validated and integrated with design verification and validation activities. This verification ensures that commercial manufacturing can reliably produce devices that match the performance characteristics established during verification and validation testing, maintaining consistency between development articles and commercial products.
**Post-Market Surveillance Preparation** verification ensures that systems are in place to monitor device performance after market introduction and to detect any issues that weren't apparent during pre-market testing. The checklist confirms that post-market surveillance plans address verification and validation findings, that reporting systems are established for regulatory compliance, and that procedures exist for updating risk management and device labeling based on real-world experience.
**Documentation Completeness and Quality** assessment ensures that all verification and validation documentation meets regulatory standards for clarity, completeness, and traceability. This comprehensive review confirms that reports provide sufficient detail for regulatory evaluation, that conclusions are properly supported by objective evidence, and that documentation packages are organized for efficient regulatory review and ongoing maintenance.
The **systematic nature** of verification and validation stage checklists provides objective evidence that your testing program was comprehensive and compliant while identifying any remaining gaps that must be addressed before regulatory submission. These checklists transform subjective readiness assessments into objective, criteria-based evaluations that support confident regulatory interactions and successful market authorization by ensuring that all verification and validation requirements have been systematically addressed and documented.
# Overview
Source: https://docs.withdovetail.com/roadmap/overview
Navigate your medical device regulatory journey with FormlyAI's roadmap covering QMS, design, development, and submission.
The Regulatory Roadmap provides a visual overview of all the key steps involved in bringing your medical device to market while complying with regulations. It's organized into **stages**, starting from Quality Management System (QMS) setup and planning, through design, development, verification, validation, regulatory preparation, submission, and finally post-market activities.
## Cards
The Regulatory Roadmap is made up of **cards**. Each card includes specific tasks, processes, or set of documents you need to complete. Think of it as a checklist for your regulatory journey.
As you work through the requirements and complete the documentation associated with each card, the card will turn green. This gives you a clear, at-a-glance view of your progress towards regulatory compliance and market readiness.
## How to use the Roadmap
1. **Open the Regulatory Roadmap**: Click on the "Roadmap" icon in the left sidebar.
2. **Navigate through the stages**: Stages include QMS, Planning, Design and Development, Verification and Validation, Regulatory Preparation, Submission, and Post-Market. You will complete these from left to right and top to bottom.
3. **Using the cards**: Click on a card to open the card modal. This will list all of the tasks associated with the card and the processes you need to complete. Once all the processes in the card are complete, then you can move on to the next card in the stage.
4. **Complete the tasks**: Each card lists the tasks that need to be completed. Clicking on a task will take you to the document assistant or, if the document does not require any user input, to the fully generated document itself.
5. **Send documents for approval**: Once the document is generated, you can send it for approval by clicking the "Approval" button on the top right of the document viewer. Learn more about the approval process in the document approval section.
6. **Complete the stage**: Once all the tasks in the card are complete and the documents are approved, the card will turn green. This will indicate that the requirements covered by the card are now covered and you can move on to the next card in the stage.
7. **Complete the roadmap**: Once all the cards in the stage are complete, the stage will turn green. This will indicate that the stage is now complete and you can move on to the next stage.
8. **Repeat**: Repeat the process until you have completed all the stages in the roadmap up to the Submission stage. This will complete the roadmap for initial certification and you will be able to submit your device to the regulatory authority.
# Tasks
Source: https://docs.withdovetail.com/roadmap/tasks
Understand FormlyAI's task management system for medical device documentation with states, dependencies, and workflow tracking.
Tasks represent individual work items that help you achieve your medical device documentation and regulatory compliance.
Each task is associated with a specific document and contains a set of inputs that you need to fill in.
Tasks vary in user input, while some documents are automatically generated, others require you to fill in a form or upload certain information.
## Task States
Tasks can be in one of the following states:
}>
This task is **dependent** on another task that is not yet complete. Click on the task to show task dependencies.
The preceding tasks must reach at least the **Unapproved** state to unlock this task.
After generating the listed tasks you can come back and start working on this task.
FormlyAI will automatically guide you to the preceding tasks to complete them first.
}>
The task is **available** for you to start working on. Clicking on the task will transition it into the **Draft** state and open the wizard.
}>
The document for this task is being **drafted** and requires your input. Leaving the wizard without generating the document will keep the task in the **Draft** state.
}>
The document was **generated** and can still be **edited** or sent out for approval.
Some tasks don't require approval and will stay in the **Unapproved** state.
}>
The task has been **completed**, **approved**, and is now **active** in your documentation.
# Additional Software Test Plans
Source: https://docs.withdovetail.com/tasks/additional-software-test-plans
Create specialized testing strategies addressing cybersecurity, performance, and integration requirements.
## Summary
Additional Software Test Plans provide **specialized testing strategies** beyond basic system testing to address specific software characteristics, risk areas, or regulatory requirements. These plans ensure comprehensive coverage of software verification and validation activities that may not be adequately addressed in standard system test plans.
## Why are Additional Software Test Plans important?
Additional software test plans are essential because medical device software often requires **specialized testing approaches** that go beyond standard functional testing. These may include cybersecurity testing, performance testing under stress conditions, usability testing of software interfaces, or testing of specific software components like artificial intelligence algorithms.
These specialized plans ensure **comprehensive risk coverage** by addressing software-specific hazards that could impact patient safety or device effectiveness. They also demonstrate regulatory compliance with software-specific guidance documents and standards that require testing beyond basic functional verification.
## Regulatory Context
Under **21 CFR Part 820.30** and **FDA Software Guidance Documents**:
* **FDA Guidance "General Principles of Software Validation"** requires comprehensive software testing
* **FDA Cybersecurity Guidance** mandates security testing for networked devices
* **IEC 62304** requires software testing appropriate for safety classification
* **Software as Medical Device (SaMD)** guidance requires risk-based testing approaches
**Special attention required for:**
* Artificial Intelligence/Machine Learning algorithm validation
* Cybersecurity testing for connected devices
* Software change control and regression testing
* Integration testing with third-party software components
Under **EU MDR 2017/745** and supporting standards:
* **IEC 62304:2006+A1:2015** mandatory for medical device software lifecycle
* **IEC 62366-1** required for software usability engineering
* **ISO 14971** requires software-specific risk management and testing
* **Essential requirements** must be demonstrated through appropriate software testing
**Special attention required for:**
* Software as Medical Device (SaMD) classification and testing rigor
* Post-market surveillance of software performance
* Clinical evaluation integration for software with clinical claims
* Notified body assessment of software testing completeness
## Guide
### Identifying Need for Additional Test Plans
**Risk-based assessment** should drive decisions about additional testing needs. Review your software risk analysis to identify areas where standard system testing may not provide adequate coverage of identified risks.
**Regulatory requirements** may mandate specific types of testing beyond basic functional verification. Review applicable guidance documents and standards for your device type and software classification to identify additional testing requirements.
**Software complexity factors** such as artificial intelligence, real-time processing, network connectivity, or safety-critical functions often require specialized testing approaches that warrant separate test plans.
### Common Types of Additional Software Test Plans
**Cybersecurity test plans** address security vulnerabilities, data protection, and resilience against cyber attacks. These plans are essential for any software that connects to networks, processes sensitive data, or could be targeted by malicious actors.
**Performance test plans** evaluate software behavior under stress conditions, high loads, or resource constraints. These plans are important for software that must maintain performance during peak usage or in challenging operating environments.
**Usability test plans** for software interfaces ensure that users can safely and effectively interact with software components. These plans are critical when software interfaces could contribute to use errors that impact patient safety.
**Algorithm validation plans** address specific testing needs for artificial intelligence, machine learning, or complex decision-support algorithms that require specialized validation approaches.
**Integration test plans** focus on testing interactions between software components, third-party software, or software-hardware interfaces that may not be adequately covered in system testing.
### Developing Cybersecurity Test Plans
**Threat modeling** should identify potential attack vectors, vulnerabilities, and security risks specific to your software architecture and deployment environment. Use this analysis to prioritize cybersecurity testing activities.
**Security testing scope** should address authentication, authorization, data encryption, secure communication, input validation, and resilience against common attack patterns. Include both automated vulnerability scanning and manual penetration testing.
**Test environment security** must represent your production environment while maintaining appropriate isolation for security testing. Consider using dedicated test environments that don't compromise production systems.
### Developing Performance Test Plans
**Performance requirements** should be clearly defined based on user needs and system requirements. Specify measurable criteria for response times, throughput, resource utilization, and availability under various load conditions.
**Load testing scenarios** should represent realistic usage patterns including normal operation, peak usage, and stress conditions that could occur in clinical environments. Consider concurrent users, data volumes, and processing demands.
**Performance monitoring** during testing should capture detailed metrics that help identify performance bottlenecks and validate that performance requirements are met under all tested conditions.
### Developing Algorithm Validation Plans
**Algorithm characterization** should document the algorithm's intended function, inputs, outputs, decision logic, and performance characteristics. This forms the foundation for developing appropriate validation strategies.
**Validation datasets** should be representative of the intended use population and include sufficient diversity to demonstrate algorithm performance across the expected range of inputs. Consider edge cases and challenging scenarios.
**Performance metrics** should be clinically relevant and aligned with the algorithm's intended use. Include measures of accuracy, sensitivity, specificity, and any other metrics relevant to clinical decision-making.
### Managing Test Plan Integration
**Coordination with system testing** ensures that additional test plans complement rather than duplicate system testing activities. Identify areas of overlap and plan for efficient execution that avoids unnecessary redundancy.
**Traceability maintenance** ensures that additional testing activities are properly linked to requirements, risks, and other verification and validation activities. Maintain clear documentation of how additional testing contributes to overall V\&V objectives.
**Results integration** should combine findings from additional test plans with system testing results to provide a comprehensive assessment of software verification and validation.
## Example
**Scenario**: You are developing a mobile app for diabetes management that uses machine learning to predict glucose trends and provides insulin dosing recommendations. The app connects to glucose meters via Bluetooth and stores data in a cloud database with patient health information.
Your additional software test plans include: (1) Cybersecurity testing for data protection and secure communication, (2) Algorithm validation for the machine learning prediction model, (3) Performance testing for real-time data processing and cloud synchronization, and (4) Integration testing for Bluetooth device connectivity and cloud service interactions.
### Additional Software Test Plans
**Document ID**: ASTP-001\
**Version**: 1.0
#### 1. Cybersecurity Test Plan
**1.1 Purpose**\
Validate security controls and resilience against cyber threats for the DiabetesManager app and cloud infrastructure.
**1.2 Scope**
* Mobile application security (authentication, data storage, communication)
* Cloud service security (API security, data protection, access controls)
* End-to-end data protection during transmission and storage
**1.3 Test Categories**
| Test Category | Test Description | Acceptance Criteria |
| ---------------------- | ----------------------------------------- | ------------------------------------------------------------------ |
| Authentication Testing | Verify user authentication mechanisms | Multi-factor authentication required, session timeout \<30 minutes |
| Data Encryption | Validate encryption of sensitive data | AES-256 encryption for data at rest, TLS 1.3 for data in transit |
| API Security | Test API authentication and authorization | All API calls require valid authentication tokens |
| Penetration Testing | Simulate attack scenarios | No critical vulnerabilities identified |
| Input Validation | Test handling of malicious inputs | All inputs properly validated and sanitized |
#### 2. Algorithm Validation Test Plan
**2.1 Purpose**\
Validate the machine learning algorithm for glucose trend prediction and insulin dosing recommendations.
**2.2 Scope**
* Glucose trend prediction accuracy
* Insulin dosing recommendation safety and effectiveness
* Algorithm performance across diverse patient populations
**2.3 Validation Approach**
| Validation Component | Method | Acceptance Criteria |
| -------------------- | --------------------------------------------- | ----------------------------------------------------- |
| Prediction Accuracy | Retrospective analysis with clinical datasets | Mean absolute error \<15 mg/dL for 4-hour predictions |
| Dosing Safety | Clinical expert review of recommendations | No unsafe dosing recommendations in test scenarios |
| Population Diversity | Subgroup analysis by age, diabetes type | Algorithm performance consistent across subgroups |
| Edge Case Handling | Testing with extreme glucose values | Appropriate warnings for values outside normal range |
#### 3. Performance Test Plan
**3.1 Purpose**\
Verify software performance under various load conditions and usage scenarios.
**3.2 Scope**
* Mobile app responsiveness during normal and peak usage
* Cloud service performance under concurrent user loads
* Data synchronization performance across network conditions
**3.3 Performance Requirements**
| Performance Metric | Requirement | Test Method |
| ------------------ | ----------------------------------------- | --------------------------------------------- |
| App Response Time | \<2 seconds for all user actions | Automated UI testing with timing measurements |
| Data Sync Time | \<30 seconds for glucose reading upload | Network simulation testing |
| Concurrent Users | Support 10,000 simultaneous users | Load testing with simulated user sessions |
| Battery Impact | \<5% battery drain per hour of active use | Power consumption measurement |
#### 4. Integration Test Plan
**4.1 Purpose**\
Validate integration between mobile app, Bluetooth devices, and cloud services.
**4.2 Scope**
* Bluetooth connectivity with supported glucose meters
* Cloud API integration for data storage and retrieval
* Error handling for integration failures
**4.3 Integration Scenarios**
| Integration Point | Test Scenario | Acceptance Criteria |
| ----------------- | -------------------------------------- | ---------------------------------------------- |
| Bluetooth Pairing | Device discovery and pairing | Successful pairing within 30 seconds |
| Data Transfer | Glucose reading transmission | 100% data integrity during transfer |
| Cloud Sync | Data backup and retrieval | Successful sync with \<1% data loss |
| Offline Mode | App functionality without connectivity | Core features available offline |
| Error Recovery | Handling of connection failures | Graceful error handling with user notification |
#### 5. Test Execution Strategy
**5.1 Test Environment**
* Dedicated test environments for cybersecurity and performance testing
* Clinical data simulation environments for algorithm validation
* Multiple mobile device configurations for integration testing
**5.2 Test Schedule**
* Cybersecurity testing: Weeks 1-3 of testing phase
* Algorithm validation: Weeks 2-6 (parallel with cybersecurity)
* Performance testing: Weeks 4-7 (requires stable software build)
* Integration testing: Weeks 5-8 (requires hardware and cloud services)
**5.3 Success Criteria**\
All additional test plans must demonstrate acceptable results before software release. Critical security vulnerabilities must be resolved, algorithm performance must meet clinical requirements, and integration must be reliable under normal use conditions.
## Q\&A
Review your software risk analysis to identify risks that may not be adequately addressed by standard functional testing. Consider factors like network connectivity (requiring cybersecurity testing), complex algorithms (requiring specialized validation), real-time performance requirements (requiring performance testing), or safety-critical interfaces (requiring usability testing). Also review regulatory guidance for your device type to identify any specific testing requirements beyond basic functional verification.
Cybersecurity testing requirements depend on your device's connectivity and data handling. For networked devices, you need testing that addresses the FDA cybersecurity guidance including authentication, authorization, data protection, and resilience against attacks. This typically includes vulnerability scanning, penetration testing, and validation of security controls. The extent of testing should be proportional to the cybersecurity risks identified in your threat model.
AI/ML algorithm validation requires specialized approaches beyond traditional software testing. Develop validation datasets that represent your intended use population, define clinically relevant performance metrics, and test algorithm performance across diverse scenarios including edge cases. Consider algorithm transparency, bias assessment, and performance monitoring over time. Follow emerging guidance documents specific to AI/ML in medical devices and consider clinical validation when algorithms make diagnostic or treatment recommendations.
The decision depends on the complexity and scope of each testing area. Related testing activities (like different aspects of cybersecurity) can often be combined in a single plan. However, highly specialized testing (like algorithm validation) may warrant separate plans due to different methodologies, expertise requirements, and timelines. Consider your team's expertise, testing resources, and regulatory submission requirements when deciding on plan structure.
Integrate additional test plans into your overall V\&V strategy by ensuring traceability to requirements and risks, coordinating test execution timelines, and planning for results integration. Identify dependencies between different test plans and system testing to optimize resource utilization. Ensure that additional testing complements rather than duplicates other V\&V activities, and plan for comprehensive reporting that combines all testing results.
Issues found in additional testing should be investigated to determine their root cause and potential impact on system functionality. Determine if the issue represents a design flaw, implementation error, or gap in system testing coverage. Document the issue, implement appropriate corrective actions, and consider whether additional system testing or regression testing is needed. Update your risk analysis and testing strategies to prevent similar issues in future development cycles.
# Additional Software Test Reports
Source: https://docs.withdovetail.com/tasks/additional-software-test-reports
Document specialized testing results covering cybersecurity, performance, and integration verification.
## Summary
Additional Software Test Reports document **specialized testing activities** beyond standard system testing, including unit testing, integration testing, performance testing, security testing, and other verification activities. These reports provide comprehensive evidence that all aspects of your medical device software have been thoroughly tested and verified.
## Why are Additional Software Test Reports important?
Additional software test reports provide **comprehensive verification coverage** that goes beyond basic system testing to address specific technical, safety, and regulatory requirements. Different types of testing serve different purposes - unit testing verifies individual components, integration testing validates component interactions, performance testing confirms operational requirements, and security testing ensures cybersecurity compliance.
These reports are essential for **regulatory submissions** as they demonstrate thorough verification of all software aspects. They provide evidence that you have systematically addressed all potential failure modes and verified that your software meets both functional and non-functional requirements across all development lifecycle phases.
## Regulatory Context
Under **21 CFR Part 820.30(g)** (Design Validation) and **FDA Guidance "General Principles of Software Validation"**:
* **IEC 62304** requires verification activities appropriate to software safety classification
* **Unit testing** required for Class B and C software per IEC 62304
* **Integration testing** must verify component interfaces and data flow
* **Cybersecurity testing** mandatory per FDA premarket cybersecurity guidance
**Special attention required for:**
* Software of Unknown Provenance (SOUP) integration testing
* Performance testing under worst-case conditions
* Security testing for networked medical devices
* Automated testing validation and tool qualification
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* Must comply with **IEC 62304:2006+A1:2015** verification requirements
* **Risk-based testing** aligned with ISO 14971 risk management
* **Performance testing** must support essential requirements compliance
* **Usability testing integration** per IEC 62366-1 requirements
**Special attention required for:**
* Clinical evaluation integration for software with clinical claims
* Post-market surveillance data collection from testing
* Notified body assessment of testing completeness
* Essential requirements verification through specialized testing
## Guide
### Understanding Additional Testing Types
**Unit testing** verifies individual software components in isolation, ensuring that each module, function, or class performs correctly according to its specification. This testing is particularly important for safety-critical functions and complex algorithms.
**Integration testing** validates that software components work correctly when combined, focusing on interfaces, data flow, and component interactions. This includes testing integration with external systems, databases, and hardware components.
**Performance testing** verifies that software meets timing, throughput, memory usage, and other operational requirements under various load conditions. This is critical for real-time medical devices and systems with strict performance requirements.
**Security testing** validates cybersecurity controls, including authentication, authorization, data encryption, input validation, and resistance to common attack vectors. This is mandatory for networked medical devices.
### Planning Additional Testing Activities
**Test strategy alignment** ensures that additional testing activities complement your overall verification approach without unnecessary duplication. Each type of testing should address specific risks or requirements not covered by system testing.
**Resource planning** considers the tools, environments, expertise, and time required for specialized testing. Some testing may require specific equipment, software tools, or external expertise.
**Scheduling coordination** ensures that additional testing activities are properly sequenced with development activities and other testing phases. Some testing may need to occur early in development, while other testing requires near-final software.
### Unit Testing Documentation
**Test coverage analysis** documents which code modules, functions, and branches have been tested. Aim for high coverage of safety-critical and complex code, with justification for any untested code.
**Test case design** should cover normal operation, boundary conditions, error conditions, and edge cases for each unit. Document test inputs, expected outputs, and actual results.
**Defect tracking** documents any issues found during unit testing, including root cause analysis, fixes implemented, and verification that fixes resolve the issues.
### Integration Testing Documentation
**Interface testing** verifies that data flows correctly between components and that interface contracts are properly implemented. Document all interfaces tested and any issues discovered.
**End-to-end workflow testing** validates that complete user scenarios work correctly across multiple components. This is particularly important for complex medical device workflows.
**External system integration** documents testing with databases, cloud services, medical devices, and other external systems your software interacts with.
### Performance Testing Documentation
**Load testing** documents system behavior under expected operational loads. Include response times, throughput measurements, and resource utilization data.
**Stress testing** documents system behavior under extreme conditions, including peak loads, resource constraints, and failure scenarios. This helps identify system limits and failure modes.
**Scalability testing** documents how system performance changes as load increases, helping predict behavior in different deployment scenarios.
### Security Testing Documentation
**Vulnerability assessment** documents testing for common security vulnerabilities including injection attacks, authentication bypasses, and data exposure risks.
**Penetration testing** documents attempts to exploit security weaknesses, including both automated scanning and manual testing techniques.
**Cryptographic testing** verifies that encryption, hashing, and other cryptographic functions are properly implemented and configured.
## Example
**Scenario**: You are developing a cardiac monitoring system with real-time ECG analysis, cloud connectivity, and mobile app integration. Your additional testing includes unit testing of signal processing algorithms, integration testing with ECG hardware, performance testing under high data loads, and security testing of cloud communications.
Your unit testing revealed calculation errors in heart rate variability algorithms that were corrected. Integration testing identified timing issues with ECG data acquisition that required buffer optimization. Performance testing confirmed the system meets real-time requirements even under peak loads. Security testing validated encryption and authentication mechanisms.
### Additional Software Test Reports Summary
**Document ID**: ASTR-001\
**Version**: 1.0\
**Testing Period**: April 1-30, 2024
#### 1. Unit Testing Report
**Scope**: Signal processing modules, calculation algorithms, data validation functions\
**Coverage**: 94% line coverage, 89% branch coverage\
**Test Cases**: 342 unit tests executed\
**Results**: 338 passed, 4 failed and corrected
**Key Findings**:
* Heart rate variability calculation error in edge case (corrected)
* Buffer overflow protection working correctly
* All safety-critical functions verified
#### 2. Integration Testing Report
**Scope**: ECG hardware interface, cloud API integration, mobile app communication\
**Test Scenarios**: 45 integration test scenarios\
**Results**: 43 passed, 2 required optimization
**Key Findings**:
* ECG data acquisition timing optimized for high sample rates
* Cloud API error handling verified under network failures
* Mobile app synchronization working correctly
#### 3. Performance Testing Report
**Scope**: Real-time ECG processing, cloud data transmission, concurrent user support\
**Load Conditions**: 1x, 5x, and 10x expected operational load\
**Results**: All performance requirements met
**Performance Metrics**:
* ECG processing latency: \<50ms (requirement: \<100ms)
* Cloud transmission: \<2 seconds (requirement: \<5 seconds)
* Concurrent users: 1000+ supported (requirement: 500)
#### 4. Security Testing Report
**Scope**: Authentication, data encryption, network security, input validation\
**Testing Methods**: Automated vulnerability scanning, manual penetration testing\
**Results**: No critical vulnerabilities identified
**Security Verification**:
* TLS 1.3 encryption properly implemented
* Authentication mechanisms secure against common attacks
* Input validation prevents injection attacks
* Data at rest properly encrypted
#### 5. Automated Testing Validation
**Test Automation Coverage**: 78% of test cases automated\
**Tool Qualification**: Testing tools validated for medical device use\
**Continuous Integration**: Automated tests integrated into build pipeline
#### 6. Overall Assessment
All additional testing activities have been completed successfully. Software components function correctly in isolation and integration. Performance meets all requirements under expected and stress conditions. Security controls provide adequate protection for patient data and system integrity.
**Recommendations**: Deploy to production environment with continued monitoring of performance metrics and security events.
## Q\&A
Common additional testing includes unit testing (for individual components), integration testing (for component interactions), performance testing (for timing and throughput requirements), security testing (for cybersecurity compliance), usability testing (for user interface validation), and compatibility testing (for different platforms or environments). The specific testing required depends on your software's safety classification, complexity, and regulatory requirements.
Automated testing tools and frameworks should be validated to ensure they produce reliable results. Document the tools used, their configuration, validation of tool accuracy, and any limitations. Maintain version control of test automation code and treat it as part of your software development lifecycle. Ensure that automated test results are reviewed and approved by qualified personnel.
While there's no specific coverage requirement, aim for high coverage of safety-critical and complex code. IEC 62304 requires unit testing for Class B and C software. Document your coverage targets, actual coverage achieved, and justification for any untested code. Focus on achieving meaningful coverage rather than just high percentages - ensure that critical functions and edge cases are thoroughly tested.
Integration testing should verify that SOUP components function correctly within your system context. Test SOUP interfaces, error handling, and integration points. Verify that SOUP failures are detected and handled appropriately. Document SOUP versions used during testing and establish procedures for testing when SOUP components are updated. Consider SOUP-specific risks in your integration test planning.
Security testing should address authentication, authorization, data encryption, input validation, network security, and resistance to common attack vectors. Include both automated vulnerability scanning and manual penetration testing. Test security controls under various attack scenarios and verify that security failures are handled appropriately. Document security test results and any vulnerabilities found and resolved.
Performance testing results should be compared against specific requirements and acceptance criteria. Document test conditions, measurement methods, actual results, and pass/fail determinations. Include analysis of performance under normal, peak, and stress conditions. Identify any performance bottlenecks or limitations and their impact on system operation. Consider performance implications for different deployment scenarios and user loads.
# Audit Plan
Source: https://docs.withdovetail.com/tasks/audit-plan
Plan systematic audit activities defining scope, objectives, timing, and logistics for quality system evaluation.
## Summary
An **Audit Plan** is a structured document that defines the scope, objectives, timing, and logistics of an internal or external audit. It serves as a roadmap for systematically evaluating your Quality Management System (QMS) against regulatory standards like ISO 13485 and applicable regulations. The plan ensures audits are conducted efficiently, cover all critical areas, and provide meaningful insights for continuous improvement of your quality processes.
## Why is an Audit Plan important?
The **Audit Plan** exists because regulatory frameworks require systematic verification that your quality management system actually works as intended. Rather than hoping your processes are compliant, audits provide **objective evidence** that your procedures are being followed and are effective.
For medical device manufacturers, an Audit Plan is crucial because it **demonstrates proactive quality management** to regulatory authorities. It shows you're not just documenting processes but actively monitoring and improving them. This systematic approach helps prevent quality issues that could affect patient safety and ensures you can respond effectively when notified bodies or regulatory inspectors arrive. Without proper audit planning, you risk missing critical compliance gaps, wasting resources on unfocused reviews, and facing regulatory sanctions for inadequate oversight of your quality system.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Quality audits are **mandatory** under Section 820.22
* Must be conducted by individuals **not directly responsible** for areas being audited
* Results must be **documented** and reviewed by management with executive responsibility
* Audit findings must feed into your **Corrective and Preventive Action (CAPA)** system
**Special attention required for:**
* Design controls (820.30) - especially for software medical devices
* CAPA system effectiveness (820.100)
* Production and process controls (820.70)
* Document controls and change management (820.40)
Under **EU MDR 2017/745**:
* Manufacturers must implement a quality management system (Article 10(9))
* Must comply with **EN ISO 13485:2016** requirements for internal audits (Section 8.2.4)
* Audit results must be available for **notified body assessment**
* Regular systematic reviews are required for CE marking maintenance
**Special attention required for:**
* Clinical evaluation processes (Article 61) and ongoing clinical follow-up
* Post-market surveillance system (Articles 83-86)
* Person Responsible for Regulatory Compliance (PRRC) oversight
* Unique Device Identification (UDI) compliance (Article 27)
## Guide
Your **Audit Plan** must address four essential components that work together to ensure comprehensive and effective audits. Each section builds upon the previous to create a complete audit framework.
### 1. Information and Participants
The **audit information** section establishes the fundamental logistics that make your audit possible. You must specify the **exact date and time** when the audit will occur, allowing all participants to prepare adequately. The **audit location** should be clearly defined, whether it's your main facility, a specific department, or conducted virtually. This information ensures everyone knows when and where to be present.
The **auditor information** identifies who will conduct the audit and their qualifications. For internal audits, you must ensure auditors are **independent** from the areas they're auditing - someone from software development cannot audit software processes. Include the **lead auditor's name, position, and company** to establish clear accountability. If multiple auditors participate, document each person's role and expertise to ensure proper coverage of all audit areas.
Your **audit participants** section lists company employees who will be directly involved during the audit. Focus on **subject matter experts** for each process being reviewed rather than creating an exhaustive list. Include their names and specific roles relevant to the audit scope. Remember this is a planned list - the actual participants may change slightly during the audit based on auditor requests or availability.
### 2. Audit Criteria
The **audit scope** defines exactly which standards, regulations, and internal procedures will be evaluated during this specific audit. You must clearly indicate which criteria are **covered in this audit** versus which are excluded. This prevents scope creep and ensures focused, efficient use of audit time.
Common audit criteria include **ISO 13485:2016** for quality management, **ISO 14971:2019** for risk management, **EU MDR 2017/745** or **FDA 21 CFR 820** for regulatory compliance, and **IEC 62304** for software lifecycle processes. Don't try to cover everything in one audit - it's more effective to focus on specific areas and cycle through your entire QMS over time.
The scope should align with your **audit program** that schedules different QMS elements across multiple audits. For example, one audit might focus on design controls and risk management, while another covers post-market surveillance and CAPA processes.
### 3. Audit Activities
Your **audit activities** section provides a detailed schedule that transforms the audit from a general concept into specific, actionable time blocks. Each activity should include the **date, time range, specific topic or process being reviewed, applicable audit criteria, and designated participants**.
Start with an **opening meeting** to set expectations and review the audit plan. Schedule sufficient time for each process review - complex areas like design controls typically require more time than simpler processes like document control. Include **breaks and lunch** to maintain productivity and allow for informal discussions that often reveal important insights.
Plan for a **closing meeting** where auditors present preliminary findings and discuss next steps. Be realistic with timing - rushing through important processes defeats the purpose of systematic evaluation. Allow flexibility for auditors to spend additional time in areas where they identify concerns.
### 4. Template Variable Configuration
Based on the template structure, you need to populate five key elements:
The **audit-information** table captures basic logistics including audit date, time, and location. The **auditor-information** table identifies lead auditors and supporting auditors with their positions and companies. The **audit-participants** table lists your company personnel who will participate, focusing on process owners and subject matter experts.
The **audit-scope** table marks which standards and regulations are covered in this specific audit, allowing you to focus efforts and manage scope effectively. The **audit-activities** table provides the detailed schedule with dates, times, topics, criteria, and participants for each audit session.
Each table supports adding additional rows as needed, giving you flexibility to accommodate complex audits involving multiple auditors, extensive participant lists, or detailed activity schedules spanning multiple days.
## Example
**Scenario:** You're planning an internal audit of your document control and risk management processes before an upcoming notified body assessment. Your quality manager will lead the audit, supported by a senior engineer who's independent from both processes. The audit will review ISO 13485 requirements and your internal procedures to ensure everything is working effectively and ready for external scrutiny.
### Complete Audit Plan Document
**Audit Plan**
ID: AP-2024-001
### 1. Information and Participants
| Audit Information | Details |
| ----------------- | ------------------------------ |
| Audit Date | March 15, 2024 |
| Audit Time | 09:00 - 17:00 |
| Audit Location | Main Office, Conference Room B |
| Auditor Information | Details |
| ------------------------------- | ------------------------------------------------- |
| Lead Auditor Name | Sarah Johnson |
| Lead Auditor Position & Company | Quality Manager, MedDevice Solutions Inc. |
| Auditor Name | Michael Chen |
| Auditor Position & Company | Senior Process Engineer, MedDevice Solutions Inc. |
### 2. Planned Audit Participants
| Name | Position / Role |
| ----------------- | ---------------------------- |
| Emily Rodriguez | Document Control Specialist |
| David Kim | Risk Management Lead |
| Jennifer Martinez | Regulatory Affairs Manager |
| Thomas Anderson | Software Development Manager |
### 3. Audit Criteria
| Audit Criterion | Covered in this Audit |
| ------------------------------------------ | --------------------------- |
| EN ISO 13485:2016 | Yes |
| ISO 14971:2019 | Yes |
| (EU) Medical Device Regulation 2017/745 | Partially (Articles 10, 61) |
| IEC 62304:2006 | No |
| IEC 62366-1:2015 | No |
| FDA Quality System Regulation (21 CFR 820) | No |
| Internal SOP-003 Document Control | Yes |
| Internal SOP-007 Risk Management | Yes |
### 4. Audit Activities
| Date | Time | Topic / Process / Requirement | Audit Criteria | Participants |
| -------------- | ------------- | ----------------------------------- | ---------------------------------------- | ---------------------------------- |
| March 15, 2024 | 09:00 - 09:30 | Opening Meeting & Audit Plan Review | ISO 13485:2016, cl 8.2.4 | All participants |
| March 15, 2024 | 09:30 - 11:30 | Document Control Process Review | ISO 13485:2016, cl 4.2.4, 4.2.5; SOP-003 | Emily Rodriguez, Jennifer Martinez |
| March 15, 2024 | 11:30 - 11:45 | Break | N/A | N/A |
| March 15, 2024 | 11:45 - 13:00 | Document Control Records Review | ISO 13485:2016, cl 4.2.5 | Emily Rodriguez |
| March 15, 2024 | 13:00 - 14:00 | Lunch | N/A | N/A |
| March 15, 2024 | 14:00 - 15:30 | Risk Management Process Review | ISO 14971:2019, cl 4-8; SOP-007 | David Kim, Thomas Anderson |
| March 15, 2024 | 15:30 - 15:45 | Break | N/A | N/A |
| March 15, 2024 | 15:45 - 16:30 | Risk Management Files Review | ISO 14971:2019, cl 9; MDR Art 61 | David Kim, Jennifer Martinez |
| March 15, 2024 | 16:30 - 17:00 | Closing Meeting & Next Steps | ISO 13485:2016, cl 8.2.4 | All participants |
## Q\&A
You must audit all QMS processes over a defined cycle, typically every 1-3 years. The frequency should be based on process risk, complexity, and previous audit findings. Critical processes like design controls or risk management may need annual audits, while stable processes like document control might be audited every two years.
Auditors must be independent of the area being audited. In small companies, consider using external auditors or rotating responsibilities among staff members. For example, your quality manager can audit software development, but someone from software development cannot audit their own processes.
Document all findings in your audit report and initiate corrective actions through your CAPA system. Assign responsibility for addressing each finding, set target completion dates, and verify effectiveness of corrections during subsequent audits or management reviews.
Your schedule should be detailed enough to ensure comprehensive coverage while remaining flexible. Allocate realistic time for each process review - complex areas like design controls typically need 2-3 hours, while simpler processes might only need 1 hour. Include breaks and buffer time for unexpected discoveries.
Auditors should review your quality manual, relevant SOPs, work instructions, records of implementation, training records, and any previous audit or inspection findings. Focus on evidence that your processes are actually being followed, not just documented.
Brief participants on the audit scope and schedule in advance. Ensure all relevant records are accessible and up-to-date. Remind staff that audits are improvement opportunities, not evaluations of individual performance. Have process owners prepare to explain their procedures and show evidence of implementation.
# Audit Program
Source: https://docs.withdovetail.com/tasks/audit-program
Schedule comprehensive audit coverage across multiple years ensuring systematic quality management system verification.
## Summary
An audit program is your **strategic roadmap** for internal audits over a defined period, typically covering all Quality Management System (QMS) processes within a 3-year cycle. It ensures systematic compliance verification, identifies improvement opportunities, and demonstrates regulatory commitment to authorities like the FDA and notified bodies under EU MDR.
## Why is an Audit Program Important?
Your audit program serves as the **backbone of quality assurance** within your medical device organization. Regulatory authorities require you to systematically verify that your QMS actually works as documented, not just on paper. The audit program ensures you **proactively identify potential compliance gaps** before they become serious violations during regulatory inspections. It provides evidence of your commitment to quality and helps maintain CE marking or FDA clearance by demonstrating continuous monitoring of your processes.
Without a structured audit program, you risk **missing critical process failures** that could lead to product recalls, regulatory warnings, or market withdrawal. The program also helps you allocate resources efficiently by prioritizing high-risk processes and areas with previous findings.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Internal audits are **mandatory** under Section 820.22
* Must be conducted by individuals **not directly responsible** for areas being audited
* Results must be **documented** and reviewed by management with executive responsibility
* Audit findings must feed into your **Corrective and Preventive Action (CAPA)** system
* Audit programs must be **planned** and demonstrate systematic coverage of all QMS processes
**Special attention required for:**
* Design controls (820.30) - especially for software medical devices
* CAPA system effectiveness (820.100)
* Production and process controls (820.70)
* Document controls and change management (820.40)
Under **EU MDR 2017/745**:
* Manufacturers must implement a quality management system (Article 10(9))
* Must comply with **EN ISO 13485:2016** requirements for internal audits (Section 8.2.4)
* Audit results must be available for **notified body assessment**
* Regular systematic reviews are required for CE marking maintenance
* Post-market surveillance processes require specific audit attention
**Special attention required for:**
* Clinical evaluation processes (Article 61) and ongoing clinical follow-up
* Post-market surveillance system (Articles 83-86)
* Person Responsible for Regulatory Compliance (PRRC) oversight
* Unique Device Identification (UDI) compliance (Article 27)
* Vigilance and incident reporting (Articles 87-90)
## Guide
### Understanding Audit Program Structure
Your audit program is fundamentally a **multi-year planning document** that maps out when and how you'll audit different aspects of your QMS. The program must ensure that all critical processes receive appropriate audit attention based on their **risk level and regulatory importance**.
### Key Components You Must Include
**Audit Scheduling Matrix**: Create a table showing planned audits across multiple years (typically 3 years) with columns for each planned audit cycle. This matrix should cover all **ISO 13485:2016 clauses** relevant to your device type, plus specific EU MDR articles for European markets.
**Process Prioritization**: Not all processes require annual auditing. **High-risk processes** like design controls, risk management, and post-market surveillance typically need annual attention, while stable processes like document control might be audited every 2-3 years.
**Resource Allocation**: Your program must account for **auditor availability and independence requirements**. You cannot audit your own work, so plan accordingly if you're a small organization.
### Defining Audit Scope and Frequency
Base your audit frequency on several critical factors:
**Regulatory Risk**: Processes directly affecting patient safety (design controls, risk management) require more frequent auditing than administrative processes.
**Process Maturity**: New or recently changed processes need more frequent verification until they demonstrate stability.
**Previous Findings**: Areas with historical nonconformities or CAPA actions require increased audit attention.
**Regulatory Changes**: When standards or regulations change, affected processes need immediate audit coverage.
### Creating Your Audit Program Table
The core of your audit program is a comprehensive table that identifies:
* **Specific audit periods** (dates when audits will occur)
* **Audit plan identifiers** (linking to specific audit plan documents)
* **QMS process coverage** (which ISO 13485 clauses will be reviewed)
* **Regulatory compliance verification** (MDR articles, FDA requirements)
For each planned audit, mark which specific processes will be covered. Use clear indicators like checkmarks, "Yes/No," or specific dates. Some processes marked as "n/a" (like work environment controls) may not apply to software-only medical devices.
### Integrating with Your SOP Internal Audit
Your audit program must align with your **SOP Internal Audit** procedures. The program provides the "what and when" while your SOP defines the "how." Ensure your program references your internal audit SOP document identifier to maintain clear procedural links.
### Managing Program Updates
Your audit program is a **living document** that requires regular updates. After completing each audit, update the program to reflect:
* Actual audit completion dates
* Specific audit plan document identifiers
* Any scope changes or additional areas covered
* Results that influence future audit planning
### Planning for Different Organizational Structures
**Small Organizations**: If you have limited personnel, consider using external auditors or rotating audit responsibilities. Plan audits when key personnel are available and ensure adequate coverage without overwhelming your team.
**Multi-site Operations**: Your program must cover all sites where QMS processes occur. Consider centralizing some audits or coordinating between sites to ensure comprehensive coverage.
**Software-only Devices**: Focus on software development lifecycle processes, design controls, risk management, and post-market surveillance. Some ISO 13485 clauses related to manufacturing facilities may not apply.
## Example
**Scenario**: You're a startup developing a software medical device for diabetes management. Your team includes a CEO, software engineers, a quality manager, and a regulatory consultant. You need to establish an audit program covering the next three years while building toward FDA submission and CE marking.
Your audit program table would look like this:
| Audit ID | Audit #1 | Audit #2 | Audit #3 |
| -------------------------------------------------------------------------------------------------- | ----------- | ----------- | ----------- |
| Date | 2024-03-15 | 2024-09-15 | 2025-03-15 |
| Audit Plan ID | AP-2024-001 | AP-2024-002 | AP-2025-001 |
| ISO 13485:2016, para. 4.1, 4.21: General QMS requirements | ✓ | | ✓ |
| ISO 13485:2016, para. 4.2.2, 5.3, 5.4: Quality manual and QMS planning | ✓ | | |
| ISO 13485: 2016, para. 4.2.3: Medical device file | | ✓ | |
| ISO 13485:2016, para. 4.2.4, 4.2.5: Control of documents and records | ✓ | | ✓ |
| ISO 13485:2016, para. 5.1, 5.2, 5.3., 5.4, 5.5: Management responsibility | | ✓ | |
| ISO 13485:2016, para. 5.6: Management review | | ✓ | ✓ |
| ISO 13485:2016, para. 6.1, 6.3: Resource management | | | ✓ |
| ISO 13485:2016, para. 6.2: Human resources management | | ✓ | |
| ISO 13485:2016, para. 6.4: Work environment and contamination control | n/a | n/a | n/a |
| ISO 13485:2016, para. 7.1: Planning product realization | ✓ | | |
| ISO 13485:2016, para. 7.2: Customer-related processes | | | ✓ |
| ISO 13485:2016, para. 7.3: Design and development | ✓ | ✓ | ✓ |
| ISO 13485:2016, para. 7.4: Purchasing | | ✓ | |
| ISO 13485:2016, para. 7.5: Production and service provision | | ✓ | ✓ |
| ISO 13485:2016, para. 7.6: Measuring equipment | | ✓ | |
| ISO 13485:2016, para. 8.1, 8.2.1, 8.2.2: Feedback and complaints handling | | | ✓ |
| ISO 13485:2016, para. 8.1, 8.2.3: Reporting to authorities | | | ✓ |
| ISO 13485:2016, para. 8.1, 8.2.4: Internal auditing | | ✓ | |
| ISO 13485:2016, para. 8.1, 8.2.5, 8.2.6: Measurement of products and processes | | ✓ | |
| ISO 13485:2016, para. 8.3: Nonconforming products | | | ✓ |
| ISO 13485:2016, para. 8.4: Analysis of data | | ✓ | |
| ISO 13485:2016, para. 8.5: Improvement | | ✓ | ✓ |
| Reg. (EU) 2017/745, Chapter VII, Art. 83-86: Post-Market Surveillance | | | ✓ |
| Reg. (EU) 2017/745, Chapter VII, Art. 87-90: Vigilance | | | ✓ |
| Reg. (EU) 2017/745, Chapter 61 & Annex XIV: Clinical Evaluation and Post-Market Clinical Follow-up | | | ✓ |
In this example, your first audit focuses on **foundational QMS processes** and design controls since you're still developing your device. The second audit emphasizes **operational processes** as you prepare for market entry. The third audit covers **post-market processes** once your device is commercially available.
You use your regulatory consultant as the lead auditor for independence, with different team members participating based on their process responsibilities. Each audit generates an audit plan document (AP-2024-001, etc.) and feeds results into your management review and CAPA system.
## Q\&A
Update your audit program **after each completed audit** to reflect actual dates and findings. Conduct a comprehensive program review **annually** during management review to adjust frequencies based on process changes, regulatory updates, or previous audit results.
Focus on **high-risk processes** first - design controls, risk management, and complaint handling typically require annual coverage. Lower-risk processes like document control can extend to 3-year cycles. Consider using **external auditors** for independence and additional capacity, or conduct **combined audits** covering multiple related processes.
**Rotate audit responsibilities** among team members so no one audits their own work. Use **external consultants** for critical processes or areas where you lack internal independence. Document your approach to independence in your audit program and ensure it's consistently applied.
Only audit **applicable clauses**. For software-only devices, manufacturing facility requirements (clause 6.4) typically don't apply - mark these as "n/a" in your program. However, ensure you can **justify non-applicability** with documented rationale for regulatory inspections.
**Document all findings** in your audit reports and address them through your **CAPA system**. Update your audit program to increase frequency for problem areas. If findings are significant, consider accelerating your audit schedule and notifying relevant regulatory authorities if required by regulations.
Your audit program demonstrates **proactive quality management** to inspectors. They'll review your program to verify you're systematically monitoring QMS effectiveness. Strong audit programs with documented findings and corrective actions typically result in **more favorable inspection outcomes**.
# Audit Report
Source: https://docs.withdovetail.com/tasks/audit-report
Document audit findings and corrective actions providing objective evidence of quality system performance.
## Summary
An **Audit Report** documents the findings, conclusions, and corrective actions from internal or external audits of your Quality Management System (QMS). It provides objective evidence that your quality processes have been systematically evaluated against regulatory standards and identifies opportunities for improvement. The report serves as a critical record for regulatory compliance and demonstrates your commitment to maintaining effective quality controls.
## Why is an Audit Report important?
The **Audit Report** exists because regulatory authorities require documented evidence that you actively monitor and improve your quality management system. It's not enough to simply have procedures - you must demonstrate through systematic auditing that these procedures are being followed and are effective in practice.
For medical device manufacturers, the Audit Report is essential because it **provides objective evidence of QMS effectiveness** to regulatory inspectors and notified bodies. It shows you're proactively identifying and addressing compliance gaps before they become serious issues. The report also drives your **Corrective and Preventive Action (CAPA)** system by documenting nonconformities that require systematic resolution. Without proper audit reporting, you risk missing critical quality issues, failing regulatory inspections, and potentially compromising patient safety through undetected process failures.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Quality audits are **mandatory** under Section 820.22
* Audit results must be **documented** and reviewed by management with executive responsibility
* Findings must feed into your **Corrective and Preventive Action (CAPA)** system under Section 820.100
* Records must be maintained for the lifetime of the device plus two years
**Special attention required for:**
* Design controls (820.30) - audit findings often reveal design control weaknesses
* CAPA system effectiveness (820.100) - audit reports must trigger appropriate corrective actions
* Management responsibility (820.20) - executive review of audit findings is mandatory
* Document controls (820.40) - audit reports themselves must be controlled documents
Under **EU MDR 2017/745**:
* Manufacturers must implement a quality management system with regular internal audits (Article 10(9))
* Must comply with **EN ISO 13485:2016** requirements for audit reporting (Section 8.2.4)
* Audit results must be available for **notified body assessment** and regulatory inspections
* Reports support ongoing CE marking maintenance and post-market surveillance obligations
**Special attention required for:**
* Clinical evaluation processes (Article 61) - audits must verify clinical data management
* Post-market surveillance system (Articles 83-86) - audit findings inform PMS activities
* Person Responsible for Regulatory Compliance (PRRC) oversight - PRRC must review audit outcomes
* Unique Device Identification (UDI) compliance (Article 27) - audits verify UDI implementation
## Guide
Your **Audit Report** must systematically document what was audited, what was found, and what actions are required. The report transforms audit observations into actionable improvements for your quality management system.
### 1. Audit Information and Participants
The **audit information** section establishes the context and credibility of your audit. You must document the **exact dates** when the audit was conducted, identify the **lead auditor and their qualifications**, and specify whether the audit was conducted on-site or remotely. This information demonstrates that the audit was properly planned and executed by qualified personnel.
Your **audit participants** table identifies company personnel who were directly involved in the audit process. Focus on listing the **actual participants** rather than those originally planned, as audits often require additional subject matter experts or exclude planned participants due to availability. Include their **specific responsibilities** during the audit to show that appropriate expertise was available for each area reviewed.
### 2. Audit Results and Findings
The **audit results** table provides a systematic overview of what was evaluated and what was found. For each regulation, standard, or internal procedure reviewed, you must indicate the number of **major nonconformities**, **minor nonconformities**, and **recommendations** identified. This quantitative summary allows management to quickly assess the overall audit outcome and prioritize corrective actions.
Major nonconformities represent serious gaps that could affect product safety or regulatory compliance. Minor nonconformities are less critical issues that still require correction. Recommendations are opportunities for improvement that don't represent actual nonconformities but could enhance process effectiveness.
### 3. Detailed Findings Documentation
Your **major nonconformities** section must provide detailed descriptions of serious findings that require immediate attention. For each major nonconformity, describe the **specific process or procedure** that was deficient, the **evidence** that supports the finding, and the **potential impact** on product quality or patient safety. Reference the specific regulatory requirement or standard clause that was not met.
The **minor nonconformities** section documents less critical but still important findings. These might include incomplete records, minor procedural deviations, or opportunities to strengthen existing processes. While not immediately threatening to compliance, these findings should be addressed systematically to prevent escalation to major issues.
Your **recommendations** section captures improvement opportunities identified during the audit. These might include suggestions for process optimization, additional training needs, or technology upgrades that could enhance quality system effectiveness. Recommendations don't require formal corrective action but should be considered during management review.
### 4. Audit Conclusion and Next Steps
The **audit conclusion** provides management with a clear assessment of QMS effectiveness and required actions. Summarize the overall audit findings, highlight any systemic issues that require attention, and provide recommendations for improving audit performance in future cycles. If no significant issues were found, state this clearly while noting any minor improvements that could enhance system effectiveness.
The conclusion should also address the **timing and responsibility** for corrective actions, ensuring that findings are properly assigned and tracked through your CAPA system. Reference how audit findings will be reviewed during the next management review and how effectiveness of corrective actions will be verified.
## Example
**Scenario:** You conduct an internal audit of your document control and risk management processes before an upcoming notified body assessment. The audit reveals that some training records are missing signatures and risk assessment updates haven't been properly documented. You document these findings, assign corrective actions, and plan verification activities for the next audit cycle.
### Complete Audit Report Document
**Audit Report**
ID: AR-2024-001
### 1. Audit Information
| Audit Information | Details |
| ------------------------------ | ----------------------------------------- |
| Date(s) of Audit | March 15, 2024 |
| Lead Auditor Name | Sarah Johnson |
| Lead Auditor Title and Company | Quality Manager, MedDevice Solutions Inc. |
| Other Auditor(s) Name(s) | Michael Chen, Senior Process Engineer |
| Site of Audit (or remote) | Main Office, Conference Room B |
| Person Participating in Audit | Responsibilities |
| ------------------------------------------ | ------------------------------------------------------------- |
| Emily Rodriguez / Document Control Manager | Document control procedures, training records management |
| David Kim / Risk Manager | Risk management processes, risk assessment documentation |
| Jennifer Martinez / Quality Coordinator | Cross-functional quality processes, CAPA coordination |
| Thomas Anderson / Software Lead | Software development processes, design control implementation |
### 2. Audit Results
The audit was conducted on the processes identified in the table below. The number of major nonconformities (NC), minor nonconformities, and recommendations (REC) are provided as well. A description of the findings, if any, are described in the later sections.
| Regulation or Standard | Section | Description | Major NC | Minor NC | Rec |
| ---------------------- | ------------ | -------------------------------- | -------- | -------- | --- |
| ISO 13485:2016 | 4.2.4, 4.2.5 | Control of documents and records | 0 | 1 | 0 |
| ISO 13485:2016 | 6.2 | Human resources management | 0 | 1 | 1 |
| ISO 14971:2019 | 4-8 | Risk management process | 0 | 0 | 1 |
| ISO 14971:2019 | 9 | Risk management file | 0 | 1 | 0 |
| ISO 13485:2016 | 8.2.4 | Internal audit process | 0 | 0 | 1 |
#### 2.1 Major Nonconformities
No major nonconformities identified during the audit.
#### 2.2 Minor Nonconformities
**Document Control (ISO 13485:2016, 4.2.5):** Three training records in the document control system were missing required signatures from trainees, indicating incomplete documentation of training completion. The affected records were from January 2024 training sessions on updated procedures.
**Human Resources (ISO 13485:2016, 6.2):** Training effectiveness evaluation for the Q4 2023 period was not documented as required by the training procedure SOP-HR-001. While training was conducted and recorded, the systematic evaluation of training effectiveness was not performed.
**Risk Management File (ISO 14971:2019, 9):** Risk assessment updates from the December 2023 software release were not properly integrated into the master risk management file. The individual risk assessments were completed but not consolidated into the central documentation.
#### 2.3 Recommendations
**Training Program Enhancement:** Consider implementing automated reminders for training signature completion to prevent future documentation gaps. This could improve compliance and reduce administrative burden.
**Risk Management Process:** Develop a checklist for risk management file updates during product releases to ensure systematic integration of new risk assessments. This would strengthen the connection between development activities and risk documentation.
**Audit Program Optimization:** Consider extending audit cycles for consistently well-performing processes while increasing frequency for areas with recurring findings. This risk-based approach could improve audit efficiency.
### 3. Conclusion
The audit demonstrated that the quality management system is generally effective and well-implemented. The minor nonconformities identified are administrative in nature and do not indicate systemic process failures. All findings have been assigned to responsible personnel with target completion dates within 30 days.
The document control and risk management processes showed strong procedural compliance with only minor documentation gaps. The training program is functioning effectively but would benefit from enhanced tracking mechanisms. Overall, the QMS is ready for the upcoming notified body assessment with completion of the identified corrective actions.
Follow-up verification of corrective action effectiveness will be conducted during the next scheduled internal audit in Q3 2024. All findings will be reviewed during the annual management review to identify any systemic improvement opportunities.
## Q\&A
You must create an audit report for every internal audit conducted. The frequency depends on your audit program, but typically you'll audit all QMS processes over a 1-3 year cycle, generating multiple reports annually.
Audit reports must be reviewed by management with executive responsibility for the QMS. This is typically your quality manager and senior management team. The lead auditor should also review the report for accuracy before approval.
Major nonconformities are serious gaps that could affect product safety or regulatory compliance and require immediate corrective action. Minor nonconformities are less critical issues that still need correction but don't pose immediate risks.
All nonconformities identified in audit reports must be entered into your CAPA system for systematic investigation and corrective action. The audit report provides the initial documentation that triggers CAPA activities.
If no nonconformities are found, clearly state this in the report and explain why the processes are effective. Consider whether the audit scope was sufficient and if any recommendations for improvement can still be made.
Audit reports must be retained for the lifetime of the device plus two years (FDA) or as required by applicable regulations. They're critical records for demonstrating ongoing QMS effectiveness to regulatory authorities.
# Biocompatibility Evaluation Report
Source: https://docs.withdovetail.com/tasks/biocompatibility-evaluation-report
Document biological safety assessment demonstrating material compatibility and patient protection.
## Summary
The Biocompatibility Evaluation Report documents the **biological safety assessment** of your medical device materials and components that come into contact with patients. This report provides evidence that your device materials do not cause adverse biological responses and are safe for their intended use and duration of contact.
## Why is Biocompatibility Evaluation Reporting important?
Biocompatibility evaluation is **mandatory for medical devices** that have direct or indirect patient contact, as biological incompatibility can cause serious adverse reactions including cytotoxicity, sensitization, irritation, systemic toxicity, or carcinogenicity. The evaluation report demonstrates that you have systematically assessed biological risks and verified material safety.
This documentation is **critical for regulatory approval** as it provides evidence that your device meets essential safety requirements. Without proper biocompatibility evaluation, you cannot demonstrate that your device is safe for patient use, and regulatory authorities will not approve your device for market.
## Regulatory Context
Under **21 CFR Part 820.30(g)** (Design Validation) and **FDA Guidance "Use of International Standard ISO 10993-1"**:
* **ISO 10993-1** provides framework for biological evaluation of medical devices
* **Risk-based approach** required based on device contact type and duration
* **Testing or literature review** acceptable depending on material history
* **510(k) submissions** must include biocompatibility information
**Special attention required for:**
* Devices with prolonged or permanent patient contact
* Novel materials without established safety history
* Combination products with drug or biologic components
* Devices intended for vulnerable populations (pediatric, pregnant)
Under **EU MDR 2017/745** and **EN ISO 10993-1:2018**:
* **Biological evaluation** required per Annex I Essential Requirements
* **ISO 10993 series** standards provide evaluation framework
* **Notified body assessment** of biocompatibility data required
* **Clinical evaluation** may need to consider biocompatibility aspects
**Special attention required for:**
* Essential requirements 10.1 (chemical, physical, biological properties)
* Post-market surveillance of biological safety
* Material characterization and risk assessment documentation
* Compliance with REACH regulation for chemical substances
## Guide
### Understanding Biocompatibility Assessment Scope
**Contact categorization** determines the level of biological evaluation required. Devices are categorized by contact type (surface contact, external communicating, implant) and duration (limited ≤24 hours, prolonged ≤30 days, permanent >30 days).
**Material identification** requires complete characterization of all materials that may contact patients, including base materials, additives, processing aids, sterilization residuals, and degradation products.
**Risk assessment** considers the biological endpoints relevant to your device based on contact type and duration. Not all endpoints apply to every device - focus on those relevant to your specific application.
### Developing Biocompatibility Strategy
**Literature review** should be conducted first to identify existing biocompatibility data for your materials. Many established materials have extensive safety histories that may reduce or eliminate testing requirements.
**Testing strategy** should be risk-based and follow ISO 10993-1 guidance. Consider whether testing is needed, what endpoints to evaluate, and whether existing data is sufficient for your application.
**Material equivalence** assessment determines whether your materials are equivalent to previously evaluated materials. Equivalence can reduce testing requirements if properly justified.
### Conducting Biological Testing
**Test selection** should follow ISO 10993-1 matrix recommendations based on your device's contact categorization. Common tests include cytotoxicity, sensitization, irritation, systemic toxicity, and genotoxicity.
**Testing laboratory** must be qualified to perform biological testing according to relevant ISO 10993 standards. Ensure laboratories have appropriate accreditation and experience with medical device testing.
**Test article preparation** must represent your final device materials, including any processing, sterilization, or aging that may affect biological properties.
### Documenting Literature Review
**Literature search strategy** should be systematic and comprehensive, covering peer-reviewed publications, regulatory databases, and industry sources. Document search terms, databases used, and inclusion/exclusion criteria.
**Data evaluation** should assess the quality and relevance of literature data to your specific application. Consider study design, test methods, material equivalence, and applicability to your device.
**Gap analysis** identifies where literature data is insufficient and additional testing may be required. Document the rationale for relying on literature versus conducting new testing.
### Reporting Test Results
**Test summaries** should provide clear descriptions of test methods, test articles, results, and conclusions for each biological endpoint evaluated. Include both positive and negative results.
**Data interpretation** should relate test results to clinical safety, considering the intended use, patient population, and exposure conditions. Discuss any limitations or uncertainties in the data.
**Risk-benefit analysis** should weigh any identified biological risks against the clinical benefits of the device. Minor biological effects may be acceptable if clinical benefits outweigh risks.
### Addressing Biocompatibility Issues
**Material modifications** may be needed if biocompatibility testing identifies safety concerns. Document any changes made to address biological safety issues and verify that modifications resolve the concerns.
**Risk mitigation** strategies should be implemented if biological risks cannot be eliminated through material changes. This may include design modifications, usage restrictions, or enhanced labeling.
**Post-market monitoring** should be planned to detect any biological safety issues that may emerge during clinical use, particularly for novel materials or applications.
## Example
**Scenario**: You are developing a wearable glucose monitoring patch that adheres to skin for 14 days. The device contains a plastic housing, adhesive, sensor components, and electronic circuits. Some components contact skin directly while others are separated by protective barriers.
Your biocompatibility evaluation includes literature review for established materials and testing for novel adhesive formulations. Testing covers cytotoxicity, skin sensitization, and skin irritation based on the prolonged skin contact classification. Results show acceptable biological safety for all materials.
### Biocompatibility Evaluation Report
**Document ID**: BER-001\
**Version**: 1.0\
**Device**: GlucoWatch Continuous Glucose Monitor
#### 1. Device Description and Contact Assessment
**Device Overview**: Wearable patch for continuous glucose monitoring, applied to upper arm skin for 14-day wear period.
**Contact Classification**:
* Contact Type: Surface contact with intact skin
* Duration: Prolonged (≤30 days)
* Contact Category: Prolonged surface contact device
**Materials in Patient Contact**:
* Adhesive layer: Medical-grade acrylic adhesive
* Housing: Biocompatible polyurethane
* Sensor window: Medical-grade silicone
* Protective backing: Polyethylene terephthalate (PET)
#### 2. Biological Evaluation Strategy
**Risk Assessment**: Based on prolonged skin contact, evaluation focuses on local effects including cytotoxicity, sensitization, and irritation. Systemic effects not expected due to surface contact nature.
**Evaluation Approach**:
* Literature review for established materials
* Biological testing for novel adhesive formulation
* Material characterization for all patient-contact materials
#### 3. Literature Review Results
**Polyurethane Housing**: Extensive literature supports biocompatibility for medical device applications. No additional testing required.
**Medical Silicone**: Well-established safety profile for prolonged skin contact applications. Literature data sufficient for safety assessment.
**PET Backing**: Commonly used in medical applications with established safety history. No additional testing required.
#### 4. Biological Testing Results
**Test Article**: Novel acrylic adhesive formulation (Batch #2024-001)
**Cytotoxicity Testing (ISO 10993-5)**:
* Method: Elution test with L929 mouse fibroblast cells
* Result: No cytotoxic effects observed
* Conclusion: Meets acceptance criteria for cytotoxicity
**Skin Sensitization Testing (ISO 10993-10)**:
* Method: Local lymph node assay (LLNA)
* Result: No sensitization response observed
* Conclusion: Non-sensitizing under test conditions
**Skin Irritation Testing (ISO 10993-10)**:
* Method: Primary skin irritation test
* Result: Minimal irritation (score 0.5/8.0)
* Conclusion: Practically non-irritating
#### 5. Material Characterization
**Chemical Analysis**: All materials characterized for extractable and leachable substances. No substances of toxicological concern identified above threshold levels.
**Sterilization Impact**: Gamma sterilization validated to not affect material biocompatibility properties.
#### 6. Risk Assessment and Conclusions
**Biological Safety Assessment**: All materials demonstrate acceptable biocompatibility for prolonged skin contact application. Testing and literature review support safe use for 14-day wear period.
**Risk-Benefit Analysis**: Minor skin irritation potential is outweighed by clinical benefits of continuous glucose monitoring. Risk is further mitigated by proper application instructions and user training.
**Overall Conclusion**: GlucoWatch device materials are biocompatible for intended use and duration of contact.
#### 7. Post-Market Surveillance Plan
**Monitoring Strategy**: Track skin reactions and adhesive-related adverse events through complaint handling and post-market surveillance activities.
**Reporting**: Any biological safety concerns will be evaluated and reported according to regulatory requirements.
## Q\&A
Biocompatibility testing may be reduced through comprehensive literature review if sufficient data exists for your materials and application. Document systematic literature searches, evaluate data quality and relevance, and justify why existing data is sufficient for your specific use. Many established medical device materials have extensive safety histories that can reduce testing requirements when properly documented.
Biological endpoints depend on your device's contact type and duration per ISO 10993-1. Surface contact devices typically require cytotoxicity, sensitization, and irritation testing. External communicating devices may also need systemic toxicity evaluation. Implant devices require the most comprehensive testing including genotoxicity, implantation, and potentially carcinogenicity studies.
Novel materials require comprehensive biological evaluation since limited safety history exists. Conduct full testing according to ISO 10993-1 recommendations for your device category. Consider additional testing beyond minimum requirements if the material has unique properties or intended use. Document material characterization thoroughly and consider post-market surveillance to monitor long-term safety.
Document your evaluation strategy, literature review methodology and results, test summaries with complete data, material characterization, risk assessment, and conclusions. Include certificates of analysis for materials, test reports from qualified laboratories, and justification for any deviations from standard approaches. Ensure traceability between materials, testing, and safety conclusions.
Combination products must address biocompatibility for all components that may contact patients, including device materials, drug substances, and any interaction products. Consider potential interactions between device materials and drug components. Coordinate biocompatibility evaluation with drug safety assessment and ensure compatibility between device and drug regulatory pathways.
Sterilization can affect material biocompatibility by creating residuals, degradation products, or changing material properties. Evaluate biocompatibility using materials processed with your intended sterilization method. Document sterilization validation and its impact on biological safety. Consider sterilization residuals in your risk assessment and ensure they meet acceptable limits.
# Biological Evaluation Plan
Source: https://docs.withdovetail.com/tasks/biological-evaluation-plan
Develop biocompatibility testing strategy ensuring patient-contact materials meet safety standards.
## Summary
The Biological Evaluation Plan establishes a **systematic approach** to assess the biological safety of your medical device through appropriate biocompatibility testing. This plan ensures your device materials and design do not pose unacceptable biological risks to patients or users throughout the device lifecycle.
## Why is Biological Evaluation Planning important?
Biological evaluation planning is critical because medical devices that contact patients directly must demonstrate **biological safety** before market approval. Even brief contact with skin or longer contact with internal tissues can cause adverse biological responses ranging from irritation to systemic toxicity or carcinogenicity.
This planning ensures you conduct **appropriate and sufficient testing** to demonstrate biological safety while avoiding unnecessary testing that increases costs and development time. The plan also helps optimize material selection and device design to minimize biological risks from the earliest development stages.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **FDA Guidance Documents**:
* **ISO 10993-1** provides framework for biological evaluation of medical devices
* **FDA Guidance "Use of International Standard ISO 10993-1"** clarifies FDA expectations
* **Biocompatibility testing** must be appropriate for device contact type and duration
* **Existing data** can reduce testing requirements when properly justified
**Special attention required for:**
* Devices with novel materials requiring comprehensive testing
* Combination products with drug or biologic components
* Devices with degradable materials requiring additional toxicity assessment
* Software-controlled devices where biological evaluation may still apply to hardware components
Under **EU MDR 2017/745** and supporting standards:
* **Annex I, Section 10.4** requires biological and chemical safety demonstration
* Must comply with **ISO 10993 series** for biological evaluation
* **Essential requirements** include biocompatibility appropriate for intended use
* **Clinical evaluation** must consider biological safety data
**Special attention required for:**
* Notified body assessment of biological evaluation completeness
* Post-market surveillance of biological safety performance
* Material characterization requirements for novel substances
* Integration with clinical evaluation and risk management processes
## Guide
### Understanding ISO 10993-1 Framework
**ISO 10993-1** provides the foundation for biological evaluation by categorizing devices based on **contact type**, **contact duration**, and **patient population**. This categorization determines which biological tests are required, recommended, or not necessary for your device.
**Contact categories** include surface devices (skin, mucosal membrane, breached surface), external communicating devices (blood path, tissue/bone/dentin), and implant devices (tissue/bone, blood). Each category has different biological risk profiles requiring different testing approaches.
**Duration categories** range from limited exposure (\<24 hours) to permanent contact (>30 days). Longer contact durations generally require more extensive testing to address cumulative effects and long-term biological responses.
### Conducting Biological Risk Assessment
**Material characterization** forms the foundation of biological evaluation. Document all materials that contact patients, including base materials, additives, processing aids, sterilization residuals, and degradation products. Consider the entire material composition, not just primary components.
**Contact assessment** requires detailed analysis of how, where, and for how long your device contacts patients. Consider direct contact, indirect contact through fluids or gases, and potential contact during normal use and reasonably foreseeable misuse.
**Existing data evaluation** can significantly reduce testing requirements when materials have established safety profiles for similar applications. Evaluate published literature, supplier data, and regulatory databases for relevant biocompatibility information.
### Developing Your Testing Strategy
**Test selection** should follow ISO 10993-1 guidance while considering your specific device characteristics and risk profile. The standard provides a matrix of recommended tests, but you may justify deviations based on scientific rationale.
**Testing sequence** should prioritize screening tests that can identify major biological risks early. Cytotoxicity testing is typically performed first as a screening test, followed by more specific tests based on contact type and duration.
**Sample preparation** must represent your final device configuration, including all manufacturing processes, sterilization, and packaging that could affect biological properties. Test samples should be prepared using the same methods as commercial devices.
### Planning for Special Considerations
**Sterilization impact** on biological safety must be evaluated, as sterilization processes can create new chemical entities or residuals that affect biocompatibility. Plan testing on sterilized samples when sterilization is part of your commercial process.
**Degradation products** require special attention for devices with degradable materials. Plan testing that addresses both the degradation process and the biological effects of degradation products over time.
**Combination effects** should be considered when devices contain multiple materials or when materials undergo chemical interactions. Plan testing that evaluates the complete material system, not just individual components.
### Integrating with Risk Management
**Risk-benefit analysis** should guide biological evaluation planning by focusing testing on the most significant biological risks while considering the clinical benefits of device use. Document how biological risks compare to clinical benefits and alternative treatment options.
**Risk control measures** may include material selection, design modifications, or user instructions that minimize biological exposure. Plan testing to verify the effectiveness of implemented risk controls.
**Post-market surveillance** should include monitoring for biological safety issues that might not be detected in premarket testing. Plan for collecting and analyzing post-market biological safety data.
## Example
**Scenario**: You are developing a silicone-based wound dressing that contacts broken skin for up to 7 days. The dressing includes a silver-containing antimicrobial coating and uses medical-grade adhesive around the perimeter. The device is sterilized using gamma radiation.
Your biological evaluation plan addresses the silicone base material, silver coating, adhesive, and any gamma radiation-induced changes. Based on ISO 10993-1, you plan cytotoxicity, sensitization, irritation, and systemic toxicity testing for the 7-day contact duration. You evaluate existing data for medical-grade silicone and silver to potentially reduce testing requirements.
### Biological Evaluation Plan
**Document ID**: BEP-001\
**Version**: 1.0
#### 1. Purpose
This plan establishes the biological evaluation strategy for the SilverHeal antimicrobial wound dressing to demonstrate biological safety for intended use on broken skin for up to 7 days.
#### 2. Device Description and Contact Assessment
**Device**: SilverHeal antimicrobial wound dressing\
**Materials**: Medical-grade silicone base, silver nanoparticle coating, acrylic adhesive border\
**Contact Type**: Breached or compromised surface (broken skin)\
**Contact Duration**: Extended contact (>24 hours to ≤30 days, specifically up to 7 days)\
**Patient Population**: General population including pediatric and geriatric patients
#### 3. Material Characterization
| Component | Material | Supplier | Grade | Contact Assessment |
| --------------------- | -------------------- | -------------- | --------------------- | ------------------------------------------------ |
| Base Layer | Silicone elastomer | MedSil Corp | USP Class VI | Direct contact with wound bed |
| Antimicrobial Coating | Silver nanoparticles | NanoSilver Inc | Medical grade | Direct contact with wound and surrounding tissue |
| Adhesive Border | Acrylic adhesive | AdhesiveMed | Skin-contact approved | Direct contact with intact skin |
| Backing Film | Polyurethane | FlexFilm Ltd | Medical grade | No patient contact |
#### 4. Biological Testing Requirements
Based on ISO 10993-1 Table A.1 for breached/compromised surface contact with extended duration:
| Test Category | Required | Test Method | Rationale |
| ------------------------------ | -------- | ------------ | ------------------------------------------------------- |
| Cytotoxicity | Yes | ISO 10993-5 | Screening test for all devices |
| Sensitization | Yes | ISO 10993-10 | Extended skin contact requires sensitization assessment |
| Irritation | Yes | ISO 10993-10 | Direct contact with compromised tissue |
| Systemic Toxicity (Acute) | Yes | ISO 10993-11 | Extended contact duration requirement |
| Systemic Toxicity (Subchronic) | No | - | Contact duration \<30 days |
| Implantation | No | - | Not an implantable device |
| Hemocompatibility | No | - | No blood contact |
| Genotoxicity | Optional | ISO 10993-3 | Consider due to silver nanoparticles |
| Carcinogenicity | No | - | Contact duration \<30 days |
#### 5. Testing Strategy
**5.1 Sample Preparation**
* Test complete device system including all materials in final configuration
* Include gamma sterilization in sample preparation to represent commercial product
* Prepare extraction samples using polar and non-polar solvents per ISO 10993-12
**5.2 Testing Sequence**
1. **Cytotoxicity** (ISO 10993-5): Screen for basic cellular toxicity
2. **Irritation** (ISO 10993-10): Assess local tissue response
3. **Sensitization** (ISO 10993-10): Evaluate allergic potential
4. **Systemic Toxicity** (ISO 10993-11): Assess systemic effects
5. **Genotoxicity** (ISO 10993-3): Evaluate if cytotoxicity results warrant further investigation
#### 6. Existing Data Evaluation
**Silicone Base Material**: Extensive biocompatibility data available for medical-grade silicone in wound contact applications. Review existing data to potentially support testing strategy.
**Silver Antimicrobial**: Evaluate published literature on silver nanoparticle biocompatibility in wound care applications. Consider concentration-dependent effects.
**Acrylic Adhesive**: Review supplier biocompatibility data for skin contact applications.
#### 7. Risk Assessment Integration
**Identified Risks**: Potential skin sensitization from silver, cytotoxicity from sterilization residuals, irritation from adhesive components.
**Risk Controls**: Material selection based on biocompatibility history, controlled silver concentration, validated sterilization process.
**Risk-Benefit Analysis**: Antimicrobial benefits must outweigh potential biological risks for infected wound treatment.
#### 8. Acceptance Criteria
* **Cytotoxicity**: No significant reduction in cell viability compared to negative controls
* **Irritation**: Primary irritation index ≤2.0 (mild irritation acceptable for wound care application)
* **Sensitization**: No evidence of delayed-type hypersensitivity response
* **Systemic Toxicity**: No adverse systemic effects at clinical exposure levels
* **Overall Assessment**: Biological risks acceptable considering clinical benefits for wound treatment
## Q\&A
Use ISO 10993-1 Table A.1 to determine required tests based on your device's contact type (surface, external communicating, or implant), contact duration (limited, prolonged, or permanent), and contact location (skin, mucosal membrane, blood, etc.). The table provides guidance on which tests are typically required, but you can justify deviations based on scientific rationale and risk assessment. Consider your specific device characteristics and any novel materials that might require additional testing.
Yes, existing data can significantly reduce testing requirements when properly evaluated and documented. This includes published literature, supplier data, regulatory databases, and data from similar devices. The data must be relevant to your specific application, contact conditions, and material composition. Document your evaluation thoroughly and justify how existing data applies to your device. You may still need some testing to address gaps or device-specific factors.
Sterilization can create new chemical entities, residuals, or material changes that affect biocompatibility. Test samples should represent your final sterilized product when sterilization is part of your commercial process. Some sterilization methods (like ethylene oxide) leave residuals that require specific testing. Gamma radiation can create degradation products that need evaluation. Plan your testing to address both the base materials and any sterilization-related changes.
Novel materials with limited biocompatibility history may require more comprehensive testing than established materials. Conduct thorough material characterization including chemical composition, potential leachables, and degradation products. Consider additional testing beyond ISO 10993-1 minimum requirements based on material properties and potential risks. Engage with regulatory agencies early for guidance on appropriate testing strategies for novel materials.
Combination products require coordination between device biocompatibility and drug/biologic safety assessments. The device components still need biocompatibility evaluation, but you must also consider interactions between device materials and drug/biologic components. Plan testing that addresses both individual component safety and potential interaction effects. Coordinate with drug regulatory pathways and consider guidance specific to combination products.
Adverse results require investigation to determine if they represent true biological risks or testing artifacts. Consider whether results are clinically relevant given your intended use and patient population. Options include material substitution, design modifications, risk mitigation measures, or additional testing to better characterize the risk. Document your investigation and risk-benefit analysis. Some level of biological response may be acceptable if clinical benefits outweigh risks.
# Bug Fix Report Template
Source: https://docs.withdovetail.com/tasks/bug-fix-report
Document systematic software defect resolution ensuring regulatory compliance and patient safety.
## Summary
The Bug Fix Report Template documents the evaluation and implementation of bug fixes according to your company's change management process. It ensures that all software defects are properly analyzed, corrected, tested, and documented to maintain product safety and regulatory compliance.
## Why is Bug Fix Report Template important?
Bug fix report templates are critical for maintaining consistent documentation of software defects and their resolution in your medical device software. Regulatory authorities require systematic documentation of all software changes, including bug fixes, to ensure that corrections don't introduce new risks or compromise device performance. This template ensures standardized documentation that demonstrates your commitment to continuous improvement and helps maintain user trust by showing that identified issues are promptly and thoroughly addressed.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **IEC 62304**:
* Software problem resolution must be documented under **IEC 62304 Chapter 9**
* Changes require evaluation under **820.30(i)** design controls
* Bug fixes must follow your **change control procedures** (820.30(i))
* **Risk analysis** must be updated if new risks are identified (820.30(g))
* **Verification and validation** may be required for significant fixes (820.30(f))
**Special attention required for:**
* Class B and C software where bugs could affect safety
* Changes that impact software requirements or architecture
* Bug fixes that require new or modified testing procedures
* Integration with your CAPA system for systematic issues
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* Software lifecycle processes must comply with **IEC 62304:2006+A1:2015**
* Changes require evaluation under **Article 120** (significant change assessment)
* Bug fixes must be integrated with your **quality management system** (Article 10(9))
* **Post-market surveillance** data must inform bug identification and resolution
* **Technical documentation** must reflect current software state (Annex II)
**Special attention required for:**
* Assessment of whether bug fixes constitute significant changes
* Integration with post-market clinical follow-up requirements
* Notified body notification for significant software changes
* EUDAMED registration updates for software modifications
## Guide
### Documentation Requirements
Your Bug Fix Report Template must capture the complete lifecycle of a software defect from identification to resolution. **Start with a unique bug ID** that links to your existing tracking systems (like Jira or GitHub issues). This ensures traceability across your development and quality systems.
**Document the bug thoroughly** using the template fields to describe the specific software version affected, the conditions under which the bug occurs, and its impact on device functionality. Include details about user scenarios or system states that trigger the issue, as this information is crucial for both correction and prevention.
### Corrective and Preventive Actions
**Corrective actions** describe how you will fix the immediate problem. Focus on the technical approach without revealing proprietary code details. Explain whether the fix involves code changes, configuration updates, or process modifications.
**Preventive actions** are equally important and demonstrate your commitment to continuous improvement. Consider whether additional testing, code reviews, or development process changes could prevent similar bugs. If existing processes already capture this type of issue, document why additional prevention isn't necessary.
### Requirements and Risk Analysis
**Link bugs to software requirements** when applicable. If the bug reveals a gap in your requirements, document whether new requirements should be added or existing ones modified. This connection helps maintain traceability between your requirements and testing.
**Evaluate risks** associated with both the bug and its fix. Use your existing risk assessment format to document any new risks or changes to existing risk controls. Consider both the risk of leaving the bug unfixed and any risks introduced by the correction.
### Testing and Verification
**Design specific tests** to verify that your bug fix works correctly. These tests should demonstrate that the bug no longer occurs under the original conditions and that the fix doesn't introduce new problems. Reference existing test procedures when possible, or create new ones following your established testing protocols.
**Document test results** thoroughly, including who performed the testing and when. Failed tests require additional corrective action, while passed tests provide evidence that your fix is effective.
### Integration with Change Management
**Connect your bug fix** to your broader change management process. Reference your Change Management SOP and ensure that significant bug fixes trigger appropriate change evaluation procedures. This integration ensures that bug fixes receive proper review and approval before implementation.
## Example
### Scenario
Your diabetes management app crashes when users try to export their glucose data to PDF format. The bug occurs in version 2.1.3 and affects approximately 15% of users who attempt data export. A user reported this through your customer support system, and your development team has identified the root cause as a memory allocation issue in the PDF generation library.
### Bug Fix Report Template Document
**Bug ID:** BF-2024-001
**Date Bug Reported:** 2024-03-15
**Bug Description:** Application crashes when users attempt to export glucose data to PDF format. The crash occurs during PDF generation and results in complete application termination. Users lose unsaved data and must restart the application. The issue affects the data export functionality which is used by patients to share information with healthcare providers.
**Software Product and Version:** DiabetesTracker Mobile App v2.1.3
**Corrective Action:** Replace the current PDF generation library (PDFKit v1.2.1) with an updated version (PDFKit v1.4.2) that includes memory management improvements. Implement additional error handling around PDF generation to gracefully handle memory constraints and provide user feedback if export fails.
**Preventive Action:** Add automated testing for PDF export functionality with large datasets to catch memory-related issues before release. Include PDF export testing in the usability evaluation protocol to ensure real-world usage patterns are tested. Update the software system test plan to include stress testing of export functions.
**Relevant Software Requirements:** SR-045: The system shall allow users to export glucose data in PDF format. The bug reveals that this requirement needs additional detail about error handling and memory constraints.
**Relevant Risks:**
| Risk ID | Hazard | Hazardous Situation | Harm |
| ------- | --------------------------------- | ----------------------------------- | ---------------------------------------- |
| R-023 | Software crash during data export | User loses unsaved glucose readings | Delayed or incorrect treatment decisions |
**Bug Software Test:**
| SR ID | Test ID | Objective | Test Steps | Acceptance Criteria |
| ------ | --------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| SR-045 | T-PDF-001 | Verify PDF export works with large datasets | 1. Load app with 1000+ glucose readings 2. Navigate to export function 3. Select PDF format 4. Initiate export | PDF generates successfully without crash, file opens correctly |
**Bug Software Test Results:**
| SR ID | Test ID | Objective | Test Steps | Acceptance Criteria | Acceptable (Yes/No) | Comments |
| ------ | --------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ------------------- | ---------------------------------------- |
| SR-045 | T-PDF-001 | Verify PDF export works with large datasets | 1. Load app with 1000+ glucose readings 2. Navigate to export function 3. Select PDF format 4. Initiate export | PDF generates successfully without crash, file opens correctly | Yes | Test passed on iOS and Android platforms |
**Bug Test Date and Tester:** 2024-03-22, Sarah Johnson (QA Engineer)
**Additional Testing Required:** Regression testing of all export formats (CSV, Excel) to ensure the library update doesn't affect other export functions. Performance testing with various dataset sizes.
**Updated Software Release:** Version 2.1.4 scheduled for release 2024-04-01
## Q\&A
Each bug fix requires a change request and a bug fix report that must be updated for every release. The change request dictates how much documentation needs to be updated and involves describing the changes and updating relevant documents and reports.
Documents can be transferred sequentially and changes can be made as drafts, referencing old versions for traceability. After making changes, it's recommended to set up a review call or send updated documents for review.
Minor updates such as bug fixes and minor UI changes do not require extensive documentation changes. However, each bug fix still requires proper documentation through the bug fix report process. Major updates should be batched together to minimize documentation overhead.
Before starting new version changes, the test report and release checklist need to be approved. This ensures that the current version is properly documented and tested before implementing additional changes.
Consider the scope and impact of the fix. If the bug affects safety-critical functions, involves changes to core algorithms, or modifies multiple software components, additional testing is typically required. Reference your risk assessment to determine if new risks are introduced that need verification.
# CAPA Plan
Source: https://docs.withdovetail.com/tasks/capa-plan
Plan systematic corrective and preventive actions addressing quality issues and root causes.
## Summary
A CAPA Plan documents your **systematic approach to corrective and preventive actions** when quality issues, nonconformities, or safety concerns require structured resolution. You use this plan to investigate root causes, implement corrective actions to fix immediate problems, and establish preventive actions to prevent recurrence.
## Why is the CAPA Plan important?
CAPA Plans provide the **foundation for continuous improvement** in your quality management system by ensuring systematic investigation and resolution of problems. They demonstrate regulatory compliance, prevent recurring issues, and protect patient safety through structured problem-solving. Without effective CAPA processes, quality issues can escalate into serious incidents, regulatory violations, and market access problems. CAPA Plans also provide auditable evidence that you take quality seriously and continuously improve your processes.
## Regulatory Context
Under **21 CFR Part 820.100** (Corrective and Preventive Action):
* Manufacturers must **establish and maintain procedures** for implementing corrective and preventive action
* **Investigation of nonconforming product** and quality problems must be documented
* **Root cause analysis** is required to identify and eliminate causes of nonconformities
* **Verification of effectiveness** must be documented for all CAPA activities
**Special attention required for:**
* Design control CAPAs affecting device safety or effectiveness
* Software-related CAPAs requiring validation of fixes
* CAPAs resulting from complaint investigations
* Integration with risk management and post-market surveillance
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Corrective action** must address nonconformity causes (ISO 13485 Section 8.5.2)
* **Preventive action** must eliminate potential nonconformity causes (ISO 13485 Section 8.5.3)
* **Management review** must evaluate CAPA effectiveness (Article 10(9))
* **Documentation requirements** for all CAPA activities and outcomes
**Special attention required for:**
* CAPAs affecting CE marking or notified body oversight
* Post-market surveillance CAPAs requiring regulatory notification
* Clinical evaluation updates based on CAPA findings
* Integration with vigilance and Field Safety Corrective Actions
## Guide
### CAPA Initiation Criteria
**Use the scoring system** to determine if formal CAPA is required. Score based on input type (audit findings, customer complaints, post-market surveillance), whether the issue is systemic, involves trend analysis, has significant safety impact, or caused patient harm.
**Initiate CAPA if** your total score exceeds 3 points and the issue cannot be easily fixed through simple corrective measures. Don't initiate CAPA for minor issues that can be resolved through routine change management or if existing CAPAs already address the problem.
### Root Cause Analysis
**Conduct thorough investigation** using structured methods like Five Whys, fishbone diagrams, or fault tree analysis. Document your investigation process and findings systematically to ensure you identify true root causes rather than symptoms.
**Focus on system causes** rather than individual blame. Look for process failures, inadequate procedures, insufficient training, or design deficiencies that enabled the problem to occur.
### Planning Corrective Actions
**Address immediate problems** through corrective actions that fix the specific nonconformity or issue. These actions should be implemented quickly to prevent continued problems while you develop preventive measures.
**Ensure actions are proportionate** to the risk and impact of the problem. Simple issues may require only procedural updates, while safety-critical problems may need comprehensive system redesign.
### Planning Preventive Actions
**Prevent recurrence** through preventive actions that address root causes and strengthen your quality system. This may include procedure updates, training programs, design changes, or enhanced monitoring systems.
**Consider broader implications** by evaluating whether similar problems could occur in other areas of your organization or with other products. Implement preventive measures that address systemic vulnerabilities.
### Effectiveness Verification
**Plan verification activities** to confirm your CAPA actions successfully resolve the problem and prevent recurrence. This may include follow-up audits, data analysis, customer feedback monitoring, or performance testing.
**Set measurable criteria** for success and establish timelines for verification activities. Document your verification plan as part of the CAPA to ensure accountability and completeness.
## Example
**Scenario**: Your post-market surveillance reveals a pattern of user complaints about your diabetes monitoring app providing inconsistent glucose readings. Investigation shows the issue affects 5% of users and correlates with specific smartphone models. You need to develop a CAPA plan to address this systematic software compatibility problem.
### Example CAPA Plan
**Document ID**: CAPA-2024-002
#### CAPA Title and Number
| Criteria | Information |
| --------------- | ------------------------------------------------------------------------------------------ |
| **CAPA Title** | Software Compatibility Issue - Inconsistent Glucose Readings on Specific Smartphone Models |
| **CAPA Number** | CAPA-2024-002 |
#### CAPA Qualification Score
| Category | Scoring | Score |
| ---------------------- | --------------------------------------- | ----- |
| **Input Type** | Customer complaints (+2) | 2 |
| **Systemic** | Systemic issue (+2) | 2 |
| **Trend Analysis** | Result of trend analysis (+2) | 2 |
| **Significant Impact** | Significant impact on performance (+2) | 2 |
| **Patient/User Harm** | No direct harm (+0) | 0 |
| **Not Easily Fixed** | Cannot be easily fixed (Disagree) | - |
| **Existing CAPA** | No existing CAPAs cover this (Disagree) | - |
| **CAPA Total Score** | | **8** |
**CAPA Initiation Decision**: **Initiate CAPA** - Score >3 and all agree/disagree questions answered "Disagree"
#### CAPA Information
| CAPA Information | Description |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Source of CAPA** | Post-market surveillance analysis of customer complaints received through support system over 3-month period |
| **Product and Version Affected** | GlucoTrack Mobile App versions 2.1.0-2.1.3, affecting Samsung Galaxy S22 and Google Pixel 6 devices |
| **Description of Problem** | Users report glucose readings varying by ±15% compared to reference meter, occurring intermittently during peak usage hours |
| **Description of Investigation** | Analysis of 47 complaints, device logs, and compatibility testing revealed memory management issues during high CPU load conditions on affected smartphone models |
| **Root Cause** | Inadequate memory allocation handling in glucose calculation algorithm when running on devices with specific Android memory management configurations |
#### Planned Actions
**Corrective Actions (Immediate)**:
1. Release hotfix version 2.1.4 with improved memory management for affected device models
2. Implement additional input validation and error handling in glucose calculation module
3. Add device-specific calibration parameters for Samsung Galaxy S22 and Google Pixel 6
4. Issue Field Safety Notice to affected users recommending immediate app update
**Preventive Actions (Long-term)**:
1. Expand compatibility testing matrix to include top 20 smartphone models by market share
2. Implement automated memory stress testing in continuous integration pipeline
3. Develop device compatibility database with model-specific optimization parameters
4. Enhance post-market surveillance monitoring to detect compatibility issues earlier
5. Update software development procedures to require compatibility testing for all releases
**Verification Activities**:
1. Conduct user acceptance testing with 10 affected users before hotfix release
2. Monitor complaint rates for 90 days post-release to confirm issue resolution
3. Perform quarterly compatibility testing with new smartphone models
4. Review post-market surveillance data monthly for emerging compatibility patterns
#### Impact Assessment
**Performance and Safety Impact**: This CAPA addresses a significant performance issue affecting measurement accuracy, which is critical for diabetes management decisions. While no direct patient harm has been reported, inaccurate readings could lead to inappropriate insulin dosing. The corrective actions will restore measurement accuracy to specification levels.
**Regulatory Impact**: No changes to device classification or regulatory requirements. However, the Field Safety Notice must be reported to competent authorities as a Field Safety Corrective Action. Updated compatibility testing procedures will strengthen our quality management system and demonstrate enhanced post-market surveillance capabilities.
## Q\&A
Unofficial audit recommendations should be reviewed and considered for implementation. They don't require a formal CAPA but can be managed through change management by updating documents to improve compliance. Evaluate each recommendation based on risk and potential improvement value.
Use the CAPA scoring system to evaluate input type, systemic nature, trend analysis results, safety impact, and patient harm. Initiate CAPA if the total score exceeds 3 points and the issue cannot be easily fixed through routine corrective measures or existing CAPAs.
Corrective actions address existing nonconformities and their immediate causes to prevent recurrence of the specific problem. Preventive actions address potential nonconformities and their causes to prevent occurrence of similar problems in the future.
Use structured methods like Five Whys, fishbone diagrams, or fault tree analysis. Focus on identifying system causes rather than individual blame. Document your investigation process thoroughly and ensure you identify true root causes rather than just symptoms.
Plan specific verification activities such as follow-up audits, data analysis, performance testing, or customer feedback monitoring. Set measurable success criteria and timelines. Document verification results and take additional action if the CAPA proves ineffective.
# CAPA Report
Source: https://docs.withdovetail.com/tasks/capa-report
Document CAPA execution and effectiveness verification proving successful problem resolution.
## Summary
A CAPA Report documents the **execution and completion** of corrective and preventive actions outlined in your CAPA Plan. You use this report to demonstrate that planned actions were implemented effectively, verify their success in resolving the original problem, and formally close the CAPA process.
## Why is the CAPA Report important?
CAPA Reports provide **auditable evidence** that your quality management system effectively resolves problems and prevents recurrence. They demonstrate regulatory compliance by showing systematic follow-through on corrective actions and verification of effectiveness. Without proper CAPA reporting, you cannot prove that identified problems were actually resolved, leaving your organization vulnerable to recurring issues and regulatory scrutiny. CAPA Reports also enable continuous improvement by documenting lessons learned and successful problem-solving approaches.
## Regulatory Context
Under **21 CFR Part 820.100** (Corrective and Preventive Action):
* **Documentation of implementation** must show corrective actions were taken
* **Verification of effectiveness** must be documented with objective evidence
* **Records must be maintained** for the life of the device plus additional time
* **Management review** must evaluate CAPA effectiveness and closure decisions
**Special attention required for:**
* CAPAs affecting design controls requiring design history file updates
* Software CAPAs requiring validation evidence for implemented fixes
* CAPAs resulting from FDA inspections or warning letters
* Integration with complaint handling and MDR reporting systems
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Implementation records** must demonstrate corrective actions were completed (ISO 13485 Section 8.5.2)
* **Effectiveness verification** must be documented with measurable results (ISO 13485 Section 8.5.3)
* **Management review** must evaluate CAPA outcomes and system effectiveness (Article 10(9))
* **Notified body access** to CAPA records during surveillance audits
**Special attention required for:**
* CAPAs affecting CE marking requiring notified body notification
* Post-market surveillance CAPAs requiring competent authority reporting
* Clinical evaluation updates based on CAPA findings
* Integration with vigilance system and Field Safety Corrective Actions
## Guide
### Documenting Implementation
**Record actual actions taken** in detail, comparing them to the planned actions from your CAPA Plan. If you deviated from the original plan, explain why and justify the alternative approach. Include dates, responsible parties, and specific deliverables for each action.
**Document any challenges** encountered during implementation and how they were overcome. This information helps improve future CAPA planning and demonstrates thorough execution of the corrective actions.
### Verification of Effectiveness
**Provide objective evidence** that your CAPA actions successfully resolved the original problem. This may include test results, audit findings, performance data, customer feedback, or other measurable indicators that demonstrate improvement.
**Compare before and after conditions** to show the impact of your corrective actions. Use the same metrics that identified the original problem to demonstrate resolution and prevention of recurrence.
### Closure Decision
**Evaluate completeness** by confirming all planned actions were implemented and verification activities completed successfully. Review whether the root cause was adequately addressed and preventive measures are in place.
**Make closure decision** based on objective evidence of effectiveness. If the CAPA cannot be closed, document remaining actions and timeline for completion. Only close CAPAs when you have confidence the problem is resolved.
### Integration with Quality System
**Update related documents** such as procedures, work instructions, training materials, or risk assessments based on CAPA findings. Ensure changes are properly controlled and communicated to affected personnel.
**Add to CAPA list** for tracking and trend analysis. Update your management review data to include CAPA outcomes and lessons learned for continuous improvement planning.
## Example
**Scenario**: Following the CAPA Plan for software compatibility issues with glucose readings, you have implemented corrective actions including a software hotfix, Field Safety Notice, and enhanced testing procedures. After 90 days of monitoring, you need to document the results and determine if the CAPA can be closed.
### Example CAPA Report
**Document ID**: CAPA-RPT-2024-002\
**CAPA Plan Reference**: CAPA-2024-002
#### CAPA Information Summary
| Criteria | Information |
| --------------- | ------------------------------------------------------------------------------------------ |
| **CAPA Title** | Software Compatibility Issue - Inconsistent Glucose Readings on Specific Smartphone Models |
| **CAPA Number** | CAPA-2024-002 |
| CAPA Information | Description |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Source of CAPA** | Post-market surveillance analysis of customer complaints received through support system over 3-month period |
| **Product and Version Affected** | GlucoTrack Mobile App versions 2.1.0-2.1.3, affecting Samsung Galaxy S22 and Google Pixel 6 devices |
| **Description of Problem** | Users report glucose readings varying by ±15% compared to reference meter, occurring intermittently during peak usage hours |
| **Description of Investigation** | Analysis of 47 complaints, device logs, and compatibility testing revealed memory management issues during high CPU load conditions on affected smartphone models |
| **Root Cause** | Inadequate memory allocation handling in glucose calculation algorithm when running on devices with specific Android memory management configurations |
#### Actions Performed
**Planned Actions from CAPA Plan**:
* Release hotfix version 2.1.4 with improved memory management
* Implement additional input validation and error handling
* Add device-specific calibration parameters for affected models
* Issue Field Safety Notice to affected users
* Expand compatibility testing matrix to include top 20 smartphone models
* Implement automated memory stress testing in CI pipeline
* Develop device compatibility database
* Enhance post-market surveillance monitoring
* Update software development procedures
**Actions Actually Performed**:
**Corrective Actions (Completed June 15, 2024)**:
1. **Software Hotfix**: Released version 2.1.4 on May 25, 2024, with improved memory management algorithms specifically optimized for Samsung Galaxy S22 and Google Pixel 6 devices. Hotfix included enhanced garbage collection and memory pool optimization.
2. **Input Validation**: Implemented additional bounds checking and error handling in glucose calculation module. Added real-time memory monitoring with automatic algorithm fallback for low-memory conditions.
3. **Device Calibration**: Added device-specific calibration parameters for affected smartphone models, reducing measurement variability by 85% in laboratory testing.
4. **Field Safety Notice**: Issued FSN-2024-001 on May 25, 2024, to 1,247 affected users. Achieved 94% app update compliance within 48 hours through automated push notifications and email follow-up.
**Preventive Actions (Completed June 10, 2024)**:
1. **Expanded Testing**: Updated compatibility testing matrix to include 25 smartphone models representing 90% market share. Established quarterly testing schedule for new device releases.
2. **Automated Testing**: Integrated memory stress testing into continuous integration pipeline. All builds now undergo 4-hour stress testing on virtual device environments before release approval.
3. **Compatibility Database**: Developed comprehensive device compatibility database with 150+ smartphone models and their specific optimization parameters. Database automatically updates app configuration based on detected device model.
4. **Enhanced Monitoring**: Implemented real-time post-market surveillance dashboard with automated alerts for compatibility issues. System now detects potential problems within 24 hours of occurrence.
5. **Procedure Updates**: Updated Software Development SOP to require compatibility testing for all releases and mandatory memory profiling for algorithm changes.
#### Verification of Effectiveness
**Quantitative Results (90-day monitoring period)**:
* **Complaint Reduction**: Customer complaints related to measurement accuracy decreased from 47 complaints/month to 2 complaints/month (96% reduction)
* **App Performance**: Memory-related crashes reduced from 2.3% to 0.1% of sessions on affected devices
* **Measurement Accuracy**: Laboratory testing shows measurement variability reduced from ±15% to ±3% on previously affected devices
* **User Satisfaction**: App store ratings improved from 3.2 to 4.6 stars, with 89% of recent reviews mentioning improved reliability
**Qualitative Evidence**:
* **User Feedback**: Post-update surveys show 92% user satisfaction with app performance on previously affected devices
* **Healthcare Provider Feedback**: Three partner clinics report no further concerns about measurement reliability
* **Technical Validation**: Independent testing laboratory confirmed measurement accuracy meets ISO 15197:2013 requirements across all tested smartphone models
**Verification Activities Completed**:
1. **User Acceptance Testing**: Conducted with 15 affected users showing 100% satisfaction with updated app performance
2. **Complaint Monitoring**: 90-day tracking period shows sustained reduction in compatibility-related complaints
3. **Performance Testing**: Quarterly compatibility testing completed with zero failures on expanded device matrix
4. **Surveillance Review**: Monthly post-market surveillance reviews show no emerging compatibility patterns
#### CAPA Status and Closure
**Effectiveness Assessment**: All planned corrective and preventive actions were successfully implemented and verified effective. The root cause of inadequate memory management has been addressed through both immediate fixes and systematic process improvements. Quantitative evidence demonstrates sustained resolution of the original problem.
**Lessons Learned**:
* Early compatibility testing prevents post-market issues
* Real-time monitoring enables rapid problem detection
* Device-specific optimization significantly improves performance
* Automated testing integration prevents regression
**Current Status**: **CLOSED** - All objectives achieved with verified effectiveness over 90-day monitoring period. No further action required. CAPA added to List of CAPAs for trend analysis and management review.
## Q\&A
Document the ineffectiveness with objective evidence, analyze why the actions failed, and develop additional corrective measures. Don't close the CAPA until effectiveness is verified. Consider whether the root cause analysis was adequate or if additional investigation is needed.
Monitor for a period appropriate to the problem and risk level. Simple procedural issues may require 30-60 days, while complex safety issues may need 6-12 months. The monitoring period should be long enough to demonstrate sustained improvement and catch any recurrence.
Provide objective, measurable evidence such as performance data, audit results, complaint rates, test results, or customer feedback. The evidence should directly relate to the original problem and demonstrate that both the immediate issue and root cause have been addressed.
CAPAs can be closed if the completed actions effectively resolve the problem and prevent recurrence, even if not all originally planned actions were implemented. However, you must justify why certain actions were not needed and provide evidence that the problem is resolved.
Include CAPA outcomes in management review data, focusing on effectiveness trends, resource requirements, and system improvements. Use CAPA results to identify opportunities for preventive action and continuous improvement of your quality management system.
# Change Evaluation Report
Source: https://docs.withdovetail.com/tasks/change-evaluation-report
Assess implemented changes determining regulatory significance and required compliance actions.
## Summary
The Change Evaluation Report documents the evaluation of approved change requests after implementation. It assesses the impact of changes on device safety and performance, determines whether changes are significant or nonsignificant, and guides decisions about notified body notifications and user communications.
## Why is Change Evaluation Report important?
Change evaluation reports are essential for demonstrating regulatory compliance and maintaining market authorization for your medical device. They provide evidence that you have systematically evaluated the impact of changes on device safety, effectiveness, and regulatory status. This documentation helps determine whether changes require notified body notification, supports post-market surveillance activities, and ensures that users receive appropriate information about device modifications.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design changes must be **verified and validated** as appropriate (820.30(f))
* Changes require **documentation** and **approval** (820.30(i))
* **Risk analysis** must be updated for changes affecting safety (820.30(g))
* Significant changes may require **new 510(k) submission** or FDA notification
* Changes must be evaluated against **predicate device** comparison
**Special attention required for:**
* Changes affecting substantial equivalence determination
* Modifications that could impact device classification
* Software changes that alter core functionality or safety features
* Changes requiring updated labeling or instructions for use
Under **EU MDR 2017/745**:
* Significant changes require **notified body notification** under Article 120
* Changes must be evaluated against **general safety and performance requirements**
* **Technical documentation** must reflect current device state (Annex II)
* Manufacturers must assess change significance using **specific criteria**
* **CE marking** validity depends on change significance assessment
**Special attention required for:**
* Six specific criteria for determining change significance (Article 120)
* EUDAMED registration updates for device modifications
* Clinical evaluation updates for changes affecting safety or performance
* Post-market surveillance plan updates for significant changes
## Guide
### Linking to Change Requests
**Reference the original change request** by providing its document number and ensuring traceability between the request and evaluation. This connection demonstrates that changes were properly authorized and that the evaluation addresses the originally proposed modifications.
**Describe implemented changes** in detail, including any deviations from the original change request. Document new or changed code, updated documentation, modified processes, and any new requirements or risks that were identified during implementation.
### Impact Evaluation Framework
**Assess changes against regulatory criteria** systematically. For EU MDR compliance, evaluate whether changes impact intended use, patient population, contraindications, general safety and performance requirements, risk profile, clinical performance, built-in control mechanisms, or core algorithms. For FDA compliance, consider impacts on substantial equivalence, device classification, and predicate device comparison.
**Document your evaluation rationale** for each criterion. Provide specific explanations for why you determined that a particular aspect was or was not impacted. This documentation demonstrates thorough analysis and supports your significance determination.
### Verification and Validation Evidence
**Document verification activities** that demonstrate changes were implemented correctly. Include testing results, code reviews, documentation updates, and any other evidence that confirms the changes work as intended and don't introduce new problems.
**Provide validation evidence** when changes affect device performance or user interaction. This may include updated usability testing, clinical data analysis, or performance verification that demonstrates the changed device continues to meet user needs and safety requirements.
### Significance Determination
**Apply significance criteria** consistently based on your evaluation results. If any evaluation criterion indicates significant impact, the overall change should be classified as significant. This conservative approach ensures appropriate regulatory oversight and user notification.
**Consider cumulative effects** of multiple changes when evaluating significance. Even individually minor changes may become significant when considered together, particularly if they affect related device functions or user interactions.
### Regulatory and User Communication
**Plan notified body communications** for significant changes. Prepare the necessary documentation and notifications required by your notified body, including updated technical documentation and change impact assessments.
**Determine user notification requirements** based on change significance and impact on device use. Even nonsignificant changes may require user notification if they affect device operation, user interface, or safety information.
## Example
### Scenario
Following your approved change request to add heart rate variability (HRV) analysis to your cardiac monitoring app, you have implemented the new functionality. The implementation included new algorithms, user interface changes, additional data storage, and updated documentation. Now you need to evaluate whether this change is significant and determine next steps for regulatory compliance and user communication.
### Change Evaluation Report Document
**Change Request Number:** CR-2024-003
**Change Description:** Successfully implemented heart rate variability (HRV) analysis and display functionality in CardioTracker Mobile App v3.3.0. The implementation included:
* **New Code:** Integrated time-domain HRV analysis algorithms (RMSSD, pNN50, SDNN) with real-time calculation capabilities
* **Documentation Updates:** Updated system requirements list, software architecture document, user manual, and risk management file
* **Testing Performed:** Completed verification testing of HRV algorithms, usability testing of new interface elements, and regression testing of existing functionality
* **Process Changes:** Updated software development procedures to include HRV algorithm validation requirements
**Evaluation of Changes:**
| Evaluation Criteria | Impact | Details |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Does the change impact the intended use, patient population, intended users, use environment, contraindications, or interaction with the body? | Impacted | Intended use expanded to include HRV monitoring for cardiac patients. Patient population remains the same but now includes additional monitoring capability. |
| Does the change impact the device's conformity with the general safety and performance requirements? | Not Impacted | Device continues to meet all GSPR requirements. HRV functionality enhances monitoring capabilities without compromising existing safety features. |
| Does the change introduce new risks that require control measures or is the existing risk profile for the device negatively affected by the new risks? | Impacted | New risk identified: R-087 - Incorrect HRV calculation could lead to misinterpretation of cardiac status. Risk controls implemented through algorithm validation and user training materials. |
| Does the change have an impact on clinical performance or safety which necessitates additional clinical or usability testing? | Impacted | Usability testing performed to validate new HRV interface elements. Clinical literature review conducted to support HRV parameter selection and normal ranges. |
| Does the change alter built-in control mechanisms or alarms, core operating principles, operating systems or sources of energy or introduce a new channel of interoperability? | Not Impacted | No changes to existing alarms or control mechanisms. HRV analysis operates as additional monitoring feature without affecting core heart rate monitoring functions. |
| Does the change introduce a new or change to the algorithm used for the core medical functionality? | Impacted | New HRV analysis algorithms added for medical functionality. Algorithms validated against established clinical standards and tested with diverse patient data sets. |
**Change Verification:** Comprehensive verification performed including:
* Algorithm accuracy testing against reference implementations with >99% correlation
* Usability testing with 15 healthcare professionals confirming intuitive interface design
* Regression testing of all existing functionality with 100% pass rate
* Performance testing confirming HRV calculations complete within 2 seconds
* Updated risk management file with new risk controls validated through testing
**Significance of Change:** According to the evaluation of the change, the change is considered to be **Significant**.
**Actions to be Performed:** As this is a significant change:
1. **Notified Body Notification:** Submit change notification to TÜV SÜD including updated technical documentation, change evaluation report, and verification evidence
2. **User Notification:** Prepare user communication describing new HRV functionality, including updated user manual and training materials for healthcare providers
3. **EUDAMED Update:** Update device registration in EUDAMED to reflect new HRV monitoring capabilities
4. **Clinical Evaluation Update:** Update clinical evaluation report to include HRV functionality and supporting clinical literature
5. **Post-Market Surveillance:** Monitor user feedback and clinical outcomes related to HRV functionality through enhanced post-market surveillance activities
## Q\&A
The process involves creating a change request for each modification, updating software requirements if needed, reviewing and updating test plans, generating new test reports, updating the List of Known Anomalies with the new version, updating the UDI-PI, and completing a change evaluation report.
Evaluate the change against the six criteria specified in EU MDR Article 120 or FDA substantial equivalence criteria. If any criterion indicates significant impact, classify the overall change as significant. Consider cumulative effects of multiple changes and err on the side of caution when in doubt.
Document all verification activities that demonstrate changes were implemented correctly, including testing results, code reviews, documentation updates, and validation evidence. The scope of verification should be proportional to the change impact and risk level.
Notify your notified body for all significant changes as determined by your change evaluation. Some notified bodies may also want notification of certain nonsignificant changes, so check your specific agreements and requirements.
Evaluate cumulative effects of multiple changes, especially when they affect related device functions. Consider creating periodic comprehensive change evaluations that assess the combined impact of multiple individual changes implemented over time.
Update technical documentation, risk management files, clinical evaluation reports, and post-market surveillance plans as appropriate. Ensure EUDAMED registration reflects current device state and prepare user communications for significant changes.
# Change Request
Source: https://docs.withdovetail.com/tasks/change-request
Initiate controlled device modifications through systematic evaluation and approval processes.
## Summary
The Change Request is a formal document used to initiate changes to already released medical device products. It serves as the starting point for your change management process, requiring review and approval from quality, product, and business teams before implementation.
## Why is Change Request important?
Change requests provide structured control over modifications to your medical device after market release. They ensure that all proposed changes are properly evaluated for their impact on safety, effectiveness, and regulatory compliance before implementation. This systematic approach prevents uncontrolled changes that could compromise device performance or introduce new risks, while maintaining traceability for regulatory authorities and supporting your quality management system.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design changes require **design controls** under Section 820.30(i)
* Change control procedures must be established and maintained
* **Management approval** required for design changes (820.30(i))
* Changes must be **documented** and **verified/validated** as appropriate
* **Risk analysis** must be updated for changes affecting safety or effectiveness
**Special attention required for:**
* Changes that may require FDA notification or new 510(k) submission
* Software changes that affect device classification or predicate comparison
* Changes impacting labeling, intended use, or contraindications
* Modifications that could affect substantial equivalence determination
Under **EU MDR 2017/745**:
* Significant changes require **notified body notification** under Article 120
* Changes must be evaluated against **general safety and performance requirements**
* **Quality management system** must control all changes (Article 10(9))
* **Technical documentation** must be updated to reflect changes (Annex II)
* **Post-market surveillance** data must inform change decisions
**Special attention required for:**
* Assessment of change significance under Article 120 criteria
* EUDAMED registration updates for device modifications
* CE marking validity after significant changes
* Clinical evaluation updates for changes affecting safety or performance
## Guide
### Initiating Change Requests
**Identify the source** of your change request clearly. Changes can originate from customer complaints, new feature requirements, problem reports, clinical evaluation findings, post-market surveillance data, or internal team identification. Each source type may require different levels of documentation and evaluation, so accurate categorization is essential.
**Document the change comprehensively** by describing what will be added, removed, or modified. Provide sufficient detail for reviewers to understand the scope and implications of the proposed change. Include the rationale for why the change is necessary and any supporting data or evidence.
### Impact Assessment
**Identify affected products and versions** systematically. Create a clear table showing which product variants and software versions will be impacted by the change. This information is crucial for determining the scope of testing, documentation updates, and regulatory notifications required.
**Evaluate software item impacts** when your device includes software components. Use your existing software architecture documentation to identify which software items will be affected and which will remain unchanged. This analysis helps scope the technical implementation and testing requirements.
### Documentation and Process Impact Analysis
**Assess documentation impacts** by reviewing your existing document library against the proposed change. Consider whether the change will affect your intended use, device classification, user needs, risk management file, system requirements, design documentation, testing protocols, clinical evaluation, or labeling materials.
**Anticipate process changes** that may be required. Some changes may necessitate updates to your manufacturing processes, quality procedures, or post-market surveillance activities. Early identification of these impacts helps ensure comprehensive change planning.
### Team Responsibilities and Review
**Engage appropriate teams** in the review process. The product team evaluates technical feasibility and necessity, the quality team assesses regulatory and documentation impacts, and the business team considers commercial and operational implications. Each team brings essential expertise to the change evaluation process.
**Ensure proper approval** before proceeding with implementation. The change request serves as a gate that prevents unauthorized modifications while ensuring that all stakeholders understand and agree with the proposed changes.
### Integration with Change Management Process
**Connect to your broader change management system** by referencing your Change Management SOP. Ensure that approved change requests trigger the appropriate downstream activities, including change evaluation reports, updated documentation, and verification testing.
## Example
### Scenario
Your cardiac monitoring mobile app currently displays heart rate data in beats per minute (BPM) only. Based on customer feedback and clinical evaluation findings, you want to add heart rate variability (HRV) analysis and display capabilities. This change would involve new algorithms, additional user interface elements, and expanded data storage requirements.
### Change Request Document
**Source of Change Request:** Clinical Evaluation or Post-Market Surveillance
**Description of Change:** Add heart rate variability (HRV) analysis and display functionality to the cardiac monitoring mobile application. This enhancement will include:
* Implementation of time-domain HRV analysis algorithms (RMSSD, pNN50, SDNN)
* New user interface screens for HRV data visualization
* Additional data storage requirements for HRV metrics
* Updated export functionality to include HRV data in reports
* Enhanced user manual and help documentation
The change is driven by clinical feedback indicating that HRV data would provide additional value for patient monitoring and healthcare provider decision-making.
**Affected Products and Versions:**
| Product Name(s) | Version(s) |
| --------------------------- | ---------------- |
| CardioTracker Mobile App | v3.2.0 and later |
| CardioTracker Web Dashboard | v2.1.0 and later |
**Affected Software Items:**
| Software Item | Affected by Change (Yes/No) | Comments |
| ------------------------- | --------------------------- | ------------------------------------------- |
| Data Acquisition Module | Yes | Must capture additional R-R interval data |
| Signal Processing Engine | Yes | New HRV calculation algorithms required |
| User Interface Components | Yes | New screens and data visualization elements |
| Data Storage Layer | Yes | Additional database fields for HRV metrics |
| Export/Reporting Module | Yes | Include HRV data in generated reports |
| Authentication System | No | No changes to user login or security |
| Cloud Sync Service | Yes | Sync HRV data across devices |
**Anticipated Impacts of Change:**
| Document / Process | Update Anticipated | Comments |
| ----------------------------------- | ------------------ | --------------------------------------------- |
| Intended Use | Yes | Expand to include HRV monitoring capabilities |
| Device Classification | No | Remains Class II medical device software |
| User Needs list | Yes | Add user needs related to HRV analysis |
| Risk Management File | Yes | Assess risks of HRV algorithm accuracy |
| System Requirements | Yes | New functional requirements for HRV features |
| Subsystem Requirements | Yes | Algorithm performance and accuracy specs |
| Product Design / Architecture | Yes | Software architecture updates for new modules |
| Verification or Validation Testing | Yes | New test protocols for HRV functionality |
| Usability Testing | Yes | Test new user interface elements |
| Clinical Evaluation | Yes | Evaluate clinical utility of HRV features |
| Labeling or Informational Materials | Yes | Update user manual and marketing materials |
### Team Responsibilities
**Product / Software Team:** Responsible for determining technical feasibility of HRV implementation, estimating development effort, and identifying affected software components. Will assist in defining new system requirements and architecture changes.
**Quality Team:** Responsible for reviewing regulatory implications of adding HRV functionality, determining impact on device classification, and identifying all documentation requiring updates. Will ensure change aligns with quality management system requirements.
**Business Team:** Responsible for evaluating commercial impact, resource allocation, and timeline considerations. Will assess market demand and competitive positioning for HRV features.
## Q\&A
The change request dictates how much documentation needs to be updated and involves selecting the source, describing the changes, and updating relevant documents and reports. It serves as the foundation for all subsequent change management activities.
A new feature is in development to streamline version comparison, which will show differences between versions, guide users through required document updates, and provide a compressed roadmap view. This will help automate some of the impact assessment process.
The process involves creating a change request for each modification, updating software requirements if needed, reviewing and updating test plans, generating new test reports, updating the List of Known Anomalies with the new version, updating the UDI-PI, and completing a change evaluation report.
Changes should be documented by creating new versions of documents and noting in the revision history that they have been adapted to a new template for improved compliance. This maintains traceability while improving documentation quality.
Consider all aspects that could be affected: intended use, device classification, user needs, risk management, requirements, design, testing, clinical evaluation, and labeling. Also evaluate whether the change might require notified body notification or FDA submission updates.
Change requests should be reviewed by representatives from product/software teams (technical feasibility), quality teams (regulatory compliance), and business teams (commercial impact). Each team brings essential expertise to ensure comprehensive evaluation.
# Checklist Software Release
Source: https://docs.withdovetail.com/tasks/checklist-software-release
Verify documentation completeness and process compliance before releasing medical device software versions.
## Summary
The Software Release Checklist is a comprehensive verification tool that ensures all documentation and required processes are completed before releasing a new version of your medical device software. This checklist validates compliance with IEC 62304 software lifecycle requirements and confirms that all regulatory documentation is current and accurate for the new software version.
## Why is Software Release Checklist important?
Medical device software releases require **systematic verification** to ensure patient safety and regulatory compliance. Each software version introduces potential new risks and must be thoroughly validated before market release. The release checklist serves as your **final quality gate**, preventing incomplete or non-compliant software from reaching patients and healthcare providers. This systematic approach demonstrates due diligence to regulatory authorities and provides documented evidence that all required processes were followed according to your established quality management system.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Design controls** (820.30) require documented design validation before release
* **Software validation** guidance mandates release procedures for medical device software
* **Change control** (820.40) requires documentation of all software modifications
* **Production and process controls** (820.70) apply to software release processes
**Special attention required for:**
* Software validation in intended use environment before release
* Cybersecurity documentation updates for each release
* Predicate device comparison for substantial equivalence maintenance
* Post-market surveillance integration for software performance monitoring
Under **EU MDR 2017/745**:
* **GSPR 17** requires software reliability and performance validation
* **EN 62304** mandates software release activities (Section 5.8)
* **Post-market surveillance** (Articles 83-86) must monitor software performance
* **Notified body notification** required for significant software changes
**Special attention required for:**
* IEC 62304 compliance for all software safety classes (A, B, C)
* Clinical evaluation updates for software functionality changes
* UDI-PI updates for each software version release
* CE marking validity for software modifications
## Guide
### Pre-Release Process Verification
Your release checklist must verify completion of all **design control processes** before software release. This includes confirming that software requirements are complete and traceable, risk management activities have evaluated all known anomalies, and verification activities through code review and system testing have been completed. The checklist ensures **traceability** from stakeholder requirements through software requirements to risk controls, system tests, and usability evaluation.
### Documentation Update Assessment
Each software release requires systematic review of **all regulatory documentation** to determine what needs updating. The checklist provides a comprehensive list of documents that may require updates, including user needs, intended use, risk management files, system and subsystem requirements, software architecture, test plans and reports, usability engineering files, clinical evaluation documents, instructions for use, and labeling documents. You must justify why documents were not updated if changes don't affect their content.
### Version Control and Identification
Proper **version identification** according to your Software Development and Maintenance Plan is critical for traceability and regulatory compliance. The checklist verifies that version numbers are assigned correctly, tagged in your version control system, and properly reflected in all documentation. This ensures clear identification of what software version is being released and maintains traceability throughout the product lifecycle.
### Regulatory Registration Verification
Before release, verify that your software is **properly registered** with competent authorities and notified bodies as required for your device classification. For Class Im/Ir/Is, Class IIa, Class IIb, and Class III devices, registration with both competent authorities and notified bodies is mandatory. The checklist confirms these registrations are current and that notified bodies have been informed of significant changes as required.
### Labeling and Marking Compliance
The release checklist verifies that **device labeling** is correctly applied, including the CE mark for European markets. This includes confirming that the device label contains all required information, UDI-PI is updated for the new version, and all regulatory symbols and information are accurately displayed. Proper labeling is essential for market access and regulatory compliance.
### Change Impact Assessment
For each release, assess whether changes constitute **significant modifications** that require additional regulatory activities. Significant changes may require notified body notification, clinical evaluation updates, or additional testing. The checklist helps you systematically evaluate the impact of your changes and ensure appropriate regulatory steps are taken.
## Example
### Scenario
You are releasing version 2.1.0 of your diagnostic imaging software that includes new AI algorithms for enhanced image analysis, improved user interface elements, and several bug fixes. The software processes medical images and provides diagnostic recommendations to radiologists in hospital settings.
### Example Software Release Checklist
#### Software Release Information
**Software version for release:** 2.1.0
**Release date:** March 15, 2024
#### Process Verification Checklist
| Item | Yes / No | Comment |
| ---------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------- |
| The Software Requirement List and Software Requirements List Checklist have been completed to ensure design specification has occurred. | Yes | Updated requirements for new AI algorithms documented in SRL-2024-003 |
| All relevant risks (including risks of known anomalies) have been evaluated; the Risk Management Report is complete. | Yes | Risk assessment updated for AI algorithm changes, no new unacceptable risks identified |
| Software verification in the form of code review and Software System Test Plan and Software System Test Reports have been completed if needed. | Yes | Code review completed for all AI algorithm changes, system testing passed all acceptance criteria |
| Design control traceability has been implemented | Yes | Traceability matrix updated to reflect new requirements and test cases |
| A version number as defined in the Software Development and Maintenance Plan has been assigned and added as a tag to git. | Yes | Version 2.1.0 tagged in Git repository on March 10, 2024 |
| Software is registered with the competent authority and with a Notified Body if Class Im/Ir/Is, Class IIa, Class IIb and Class III. | Yes | Class IIa device registered with TÜV SÜD, registration updated for new version |
| If release includes a significant change: Notified Body has been informed. | No | Changes assessed as non-significant, no notified body notification required |
| Label is applied correctly including CE mark | Yes | Device label updated with new version number and release date |
#### Documentation Update Assessment
| Document Name | Document Number | Updated | Justification for no update |
| --------------------------- | --------------- | ------- | ------------------------------------------------------------- |
| User Needs List | UNL-2024-001 | No | AI algorithm improvements don't change fundamental user needs |
| Intended Use | IU-2024-001 | No | Diagnostic imaging purpose remains unchanged |
| Risk Management Plan | RMP-2024-001 | Yes | Updated to include AI algorithm risk assessment procedures |
| Risk Assessment | RA-2024-002 | Yes | New risks evaluated for AI algorithm changes |
| Risk Management Report | RMR-2024-002 | Yes | Updated with AI algorithm risk evaluation results |
| System Requirements List | SRL-2024-003 | Yes | New requirements added for enhanced AI algorithms |
| Software Architecture | SA-2024-002 | Yes | Architecture updated to reflect AI algorithm integration |
| Software System Test Plan | SSTP-2024-002 | Yes | New test cases added for AI algorithm functionality |
| Software System Test Report | SSTR-2024-002 | Yes | Test results documented for version 2.1.0 |
| Instructions for Use | IFU-2024-001 | Yes | Updated to describe new AI algorithm features |
| Release Notes | RN-2024-002 | Yes | New release notes created for version 2.1.0 |
| Device Label | DL-2024-002 | Yes | Updated with new version number and release date |
## Q\&A
Stop the release process immediately and complete the missing documentation. Update your release checklist to reflect the completion of required documents before proceeding with the software release. This ensures regulatory compliance and patient safety.
Evaluate changes against your risk management criteria and regulatory guidance. Significant changes typically include new intended uses, major algorithm modifications, safety-critical functionality changes, or modifications that could affect clinical outcomes. When in doubt, consult with your regulatory affairs team or notified body.
Create a new version of the affected documents and update your release checklist accordingly. Document the reason for the late update and ensure all stakeholders are informed. Consider implementing process improvements to prevent similar issues in future releases.
Review and update your release checklist template whenever you add new document types to your quality management system, when regulatory requirements change, or when you identify process improvements. Ensure the checklist remains current with your actual documentation and processes.
Yes, if you provide adequate justification for why updates weren't needed. The key is demonstrating that the unchanged documents remain accurate and current for the new software version. Unjustified 'No' responses may indicate incomplete release preparation.
Treat the release checklist as a controlled document with its own version number and approval process. Each software release should have its own completed checklist that becomes part of the permanent record for that release version.
# Clinical Evaluation Plan
Source: https://docs.withdovetail.com/tasks/clinical-evaluation-plan
Establish systematic approach demonstrating device safety and clinical performance through evidence analysis.
## Summary
A clinical evaluation plan establishes your systematic approach to gathering, analyzing, and evaluating clinical evidence that demonstrates your device's safety and clinical performance. This document outlines your methodology for literature searches, equivalence analysis, and clinical data collection to support regulatory compliance and market access.
## Why is Clinical Evaluation Plan important?
Clinical evaluation is **mandatory under EU MDR Article 61** and serves as the foundation for demonstrating that your device achieves its intended clinical benefits while maintaining an acceptable benefit-risk ratio. Regulators require this systematic approach to ensure you've thoroughly assessed available clinical evidence before placing your device on the market. Without a robust clinical evaluation plan, you cannot demonstrate compliance with General Safety and Performance Requirements (GSPRs) or justify your device's clinical claims. The plan also guides your post-market clinical follow-up activities and helps identify any gaps in clinical evidence that may require additional studies.
## Regulatory Context
Under **21 CFR Part 820** and FDA guidance documents:
* Clinical evaluation supports **510(k) predicate device comparison** and substantial equivalence determination
* Must demonstrate **safety and effectiveness** through appropriate clinical data
* **Clinical data requirements** vary by device classification and risk level
* Literature searches and **predicate device analysis** are standard approaches for Class II devices
**Special attention required for:**
* Software medical devices requiring clinical validation of algorithms
* Novel devices without adequate predicate devices
* Devices with new indications for use requiring clinical studies
* AI/ML devices requiring algorithm performance validation
Under **EU MDR 2017/745**:
* **Article 61** mandates clinical evaluation for all medical devices
* Must comply with **Annex XIV** requirements for clinical evidence
* **MDCG 2020-1** provides specific guidance for medical device software
* **Equivalence demonstration** follows MDCG 2020-5 guidance
**Special attention required for:**
* Class IIa and above devices requiring more extensive clinical evidence
* Software medical devices with clinical decision support functions
* Devices claiming equivalence to non-CE marked devices
* Novel devices requiring clinical investigations under MDCG 2020-6
## Guide
Your clinical evaluation plan must establish a **systematic and objective methodology** for gathering and analyzing clinical evidence. The plan serves as your roadmap for demonstrating clinical safety and performance throughout your device's lifecycle.
### Device Information and Claims
Start by clearly defining your **device description, intended purpose, and clinical claims**. Your clinical evaluation scope must align precisely with your intended use statement and target patient population. Document your device classification, as this determines the level of clinical evidence required. Higher-risk devices require more extensive clinical data and may need clinical investigations rather than literature-based evaluations alone.
### Clinical Development Strategy
Establish your **clinical development pathway** based on your device's risk classification and novelty. For most software medical devices and Class I/IIa devices, literature-based evaluation combined with equivalence demonstration provides sufficient evidence. Document whether you'll pursue **equivalence to existing devices**, conduct **clinical investigations**, or rely primarily on **literature and state-of-the-art analysis**.
### Literature Search Methodology
Design your literature search using the **PICO methodology** (Patient, Intervention, Comparison, Outcomes) to ensure comprehensive coverage. Plan searches across **PubMed and Cochrane Library** using systematic keywords related to your device, equivalent devices, and the clinical condition. Establish clear **inclusion and exclusion criteria** for literature appraisal, including language restrictions, publication types, and relevance thresholds.
### Equivalence Strategy
If claiming equivalence, identify **potential equivalent devices** that are CE-marked or FDA-cleared for similar indications. Plan your equivalence analysis across **technical, biological, and clinical characteristics** as required by MDCG 2020-5. Document how you'll demonstrate that any differences between devices don't affect clinical safety or performance.
### Post-Market Data Integration
Plan your approach to **vigilance database searches** across FDA MAUDE, BfArM, and other international databases. Establish search keywords for your device, equivalent devices, and the state of the art. This data helps identify any safety signals or performance issues that could affect your clinical evaluation conclusions.
### Clinical Evaluation Team
Assemble a team with **appropriate clinical expertise** in your device's clinical area. Team members must have either a higher education degree with five years of professional experience or ten years of professional experience without a degree. Document team member qualifications and ensure **declarations of interest** to maintain objectivity.
### Evidence Level Requirements
Plan your evidence collection based on **MDCG 2020-6 evidence levels**. For low-risk devices, Level 6 evidence (state of the art evaluation) and above typically suffices. Higher-risk devices may require Level 1-4 evidence from clinical investigations. Document your rationale for the evidence level you're targeting.
## Example
**Scenario:** You're developing a mobile app that analyzes heart rate variability data to provide stress level assessments for wellness monitoring. The app is classified as Class IIa software and you plan to demonstrate equivalence to existing heart rate monitoring devices.
### Clinical Evaluation Plan Structure
**1. Device Information**
* Device: StressMonitor Pro mobile application v1.0
* Classification: Class IIa medical device software
* Intended Purpose: To analyze heart rate variability patterns and provide stress level assessments for adult users in home environments
* Patient Population: Healthy adults aged 18-65 seeking stress monitoring
* Clinical Claims: Accurately measures heart rate variability and correlates measurements with validated stress assessment scales
**2. Clinical Development Strategy**
* Primary approach: Literature-based evaluation with equivalence demonstration
* Equivalent device: HeartWatch Pro (CE-marked Class IIa HRV monitor)
* No clinical investigation planned based on low-risk classification and available equivalent device
**3. Literature Search Plan**
* PICO Framework:
* P: Healthy adults, stress monitoring, heart rate variability
* I: Mobile heart rate monitoring, HRV analysis software
* C: Traditional stress assessment methods, other HRV devices
* O: Stress level accuracy, user safety, clinical utility
* Databases: PubMed, Cochrane Library, ClinicalTrials.gov
* Keywords: "heart rate variability," "stress monitoring," "mobile health," "HRV analysis," "stress assessment"
**4. Equivalence Analysis Plan**
* Technical: Similar HRV algorithms, comparable measurement accuracy, same data processing methods
* Biological: No direct body contact (both use external sensors)
* Clinical: Same intended population, similar stress assessment outputs, comparable clinical utility
**5. Post-Market Data Plan**
* Vigilance searches: FDA MAUDE, BfArM databases
* Keywords: Device names, manufacturer names, "heart rate monitor," "stress monitor," "HRV device"
* Focus on safety signals related to false readings or user misinterpretation
**6. Clinical Evaluation Team**
* Dr. Sarah Johnson, Cardiologist (15 years experience, MD from Johns Hopkins)
* Dr. Michael Chen, Clinical Psychologist (8 years stress research, PhD Stanford)
* Jane Smith, Biomedical Engineer (6 years medical device experience, MS Bioengineering)
## Q\&A
A clinical evaluation plan and report assess the clinical performance and safety of your medical device. The plan establishes your methodology for gathering and analyzing clinical evidence, while the report documents your findings and conclusions. Together, they demonstrate that your device meets regulatory requirements and provides clinical benefits that outweigh any risks.
Your clinical evaluation team must include someone familiar with your device's clinical field, with either a higher education degree and five years of relevant professional experience, or ten years of professional experience if a degree isn't available. Team members must provide CVs and sign declarations of interest to ensure objectivity. The team should have expertise in your specific clinical area and understanding of medical device regulations.
Perform an initial literature search and review when creating your plan, then conduct an updated search closer to your document approval date to capture any newly published studies. This ensures your clinical evaluation reflects the most current available evidence. Plan for regular updates post-market based on new clinical data, safety signals, or changes to your device.
The approach depends on your device's risk classification, novelty, and availability of equivalent devices. Most Class I and IIa devices can rely on literature-based evaluation with equivalence demonstration. Higher-risk devices, novel technologies, or devices without adequate equivalent devices typically require clinical investigations. Consult MDCG 2020-6 for specific evidence level requirements based on your device characteristics.
Search PubMed for biomedical literature and Cochrane Library for systematic reviews and clinical trials. Also search ClinicalTrials.gov for ongoing or completed clinical studies. For post-market data, search FDA MAUDE, BfArM, and other vigilance databases. Use systematic search strategies with appropriate keywords related to your device, equivalent devices, and clinical condition.
# Clinical Evaluation Report
Source: https://docs.withdovetail.com/tasks/clinical-evaluation-report
Document systematic clinical evidence analysis supporting regulatory approval and market compliance.
## Summary
A clinical evaluation report documents your systematic analysis of clinical evidence demonstrating your device's safety and clinical performance. This comprehensive document presents your literature review findings, equivalence analysis, and clinical data evaluation to support regulatory approval and ongoing market compliance.
## Why is Clinical Evaluation Report important?
The clinical evaluation report serves as **primary evidence for regulatory authorities** that your device meets safety and performance requirements under EU MDR Article 61 and FDA regulations. This document directly supports your CE marking application, 510(k) submission, or other regulatory pathways by demonstrating clinical evidence adequacy. Regulators use this report to assess whether your device achieves its intended clinical benefits while maintaining an acceptable benefit-risk ratio. The report also establishes the foundation for **post-market clinical follow-up** activities and provides evidence for General Safety and Performance Requirements (GSPR) compliance. Without a robust clinical evaluation report, you cannot demonstrate regulatory compliance or justify market access.
## Regulatory Context
Under **21 CFR Part 820** and FDA guidance documents:
* Clinical evaluation report supports **510(k) substantial equivalence** determination
* Must demonstrate **safety and effectiveness** through appropriate clinical evidence
* **Predicate device comparison** requires detailed clinical performance analysis
* Literature review and **clinical data analysis** must follow FDA guidance standards
**Special attention required for:**
* Software medical devices requiring algorithm validation data
* Novel devices without adequate predicate devices requiring clinical studies
* Class III devices requiring Premarket Approval (PMA) with clinical trial data
* AI/ML devices requiring real-world performance validation
Under **EU MDR 2017/745**:
* **Article 61** requires clinical evaluation report for all medical devices
* Must comply with **Annex XIV** clinical evidence requirements
* **MDCG 2020-13** provides clinical evaluation assessment report template
* Report must support **GSPR compliance** demonstration
**Special attention required for:**
* Class IIb and III devices requiring extensive clinical evidence
* Software medical devices following MDCG 2020-1 guidance
* Equivalence claims requiring MDCG 2020-5 compliance
* Post-market clinical follow-up integration per Article 61(11)
## Guide
Your clinical evaluation report must present a **comprehensive and objective analysis** of all available clinical evidence supporting your device's safety and clinical performance. The report serves as the definitive document demonstrating regulatory compliance and clinical adequacy.
### Device Information and Clinical Claims
Begin with detailed **device characterization** including technical specifications, intended purpose, patient population, and use environment. Document all **clinical claims and benefits** your device provides, ensuring alignment with your intended use statement. Present your device classification and regulatory pathway, as these determine the evidence standards your report must meet.
### Literature Review and Analysis
Present your **systematic literature search results** following your clinical evaluation plan methodology. Document search strategies, databases queried, and inclusion/exclusion criteria applied. Analyze retrieved literature using structured appraisal criteria, categorizing evidence by relevance to your device, equivalent devices, and state of the art. Present **evidence tables** summarizing key findings from relevant publications, including study design, patient populations, clinical outcomes, and relevance scores.
### Equivalence Demonstration
If claiming equivalence, provide detailed **technical, biological, and clinical comparison** between your device and the equivalent device. Present comparison tables addressing all relevant characteristics per MDCG 2020-5 requirements. Justify any differences and demonstrate they don't affect clinical safety or performance. Document the equivalent device's clinical history and regulatory status to support your equivalence claim.
### State of the Art Analysis
Analyze the **current clinical landscape** for your device's intended use, including existing treatment options, clinical standards, and competing technologies. Compare your device's performance against established benchmarks and demonstrate how it fits within or advances current clinical practice. This analysis supports your benefit-risk assessment and clinical positioning.
### Pre-Clinical and Clinical Data Integration
Integrate relevant **verification and validation data**, usability testing results, and any clinical investigation findings. Present how pre-clinical testing supports your clinical claims and addresses identified risks. Document any **biocompatibility, electrical safety, or performance testing** results that contribute to clinical evidence.
### Post-Market Data Analysis
Present findings from **vigilance database searches** and any available post-market surveillance data. Analyze safety signals, adverse events, and performance issues reported for your device, equivalent devices, and similar technologies. Demonstrate how this data informs your benefit-risk assessment and clinical conclusions.
### Benefit-Risk Analysis
Conduct a comprehensive **benefit-risk assessment** weighing your device's clinical benefits against identified risks. Present evidence supporting each claimed benefit and demonstrate risk acceptability based on clinical evidence. Address how your device's benefit-risk profile compares to existing treatment options and meets GSPR requirements.
### Clinical Conclusions and GSPR Compliance
Present clear **clinical conclusions** regarding your device's safety and clinical performance based on all evaluated evidence. Demonstrate compliance with relevant GSPRs, particularly GSPR 1, 2, 6, and 8. Document any evidence gaps and plans for addressing them through post-market activities.
### Post-Market Clinical Follow-Up Planning
Outline your **PMCF strategy** based on clinical evaluation findings, including specific clinical questions requiring ongoing monitoring. Plan data collection methods, timelines, and success criteria for post-market clinical activities.
## Example
**Scenario:** You've completed the clinical evaluation for your StressMonitor Pro mobile app that analyzes heart rate variability for stress assessment. Your report documents literature review findings, equivalence to HeartWatch Pro, and clinical conclusions supporting Class IIa classification.
### Clinical Evaluation Report Structure
**1. Executive Summary**
* Device: StressMonitor Pro v1.0, Class IIa medical device software
* Clinical evaluation approach: Literature-based with equivalence demonstration
* Key finding: Sufficient clinical evidence supports safety and performance claims
* Conclusion: Acceptable benefit-risk ratio for intended use
**2. Literature Review Results**
* Databases searched: PubMed (n=847 articles), Cochrane (n=23 reviews)
* Final inclusion: 15 relevant publications after screening
* Evidence levels: 8 Level 6 studies, 4 Level 7 studies, 3 Level 8 studies
* Key findings: HRV analysis demonstrates 85-92% correlation with validated stress scales
**3. Equivalence Analysis**
* Equivalent device: HeartWatch Pro (CE-marked, Class IIa)
* Technical comparison: Similar HRV algorithms, comparable accuracy (±3% difference)
* Clinical comparison: Same patient population, similar stress assessment methodology
* Differences: Enhanced user interface, additional data visualization features
* Conclusion: Differences don't affect clinical safety or performance
**4. State of the Art Analysis**
* Current stress monitoring methods: Questionnaires, cortisol testing, HRV devices
* Clinical benchmarks: 80-90% accuracy for stress level detection
* Market analysis: 12 similar devices identified, 3 with equivalent functionality
* Clinical positioning: Comparable performance to established devices
**5. Benefit-Risk Assessment**
* Clinical benefits: Non-invasive stress monitoring, real-time feedback, trend analysis
* Identified risks: False readings leading to inappropriate stress management
* Risk mitigation: User training, clear limitations in IFU, healthcare provider guidance
* Conclusion: Benefits significantly outweigh risks for intended population
**6. GSPR Compliance**
* GSPR 1: Device achieves intended stress monitoring purpose with acceptable accuracy
* GSPR 2: Risks reduced through software controls and user guidance
* GSPR 6: Performance maintained through software validation and testing
* GSPR 8: Residual risks acceptable when weighed against clinical benefits
**7. Clinical Conclusions**
* Sufficient clinical evidence supports device safety and performance
* Equivalence to HeartWatch Pro adequately demonstrated
* Benefit-risk ratio acceptable for Class IIa classification
* No additional clinical investigations required pre-market
**8. PMCF Plan**
* Monitor real-world accuracy through user feedback collection
* Track adverse events and use errors through complaint system
* Annual literature review updates for new HRV research
* Clinical evaluation update planned within 2 years post-market
## Q\&A
The clinical evaluation plan establishes your methodology for gathering clinical evidence, while the report documents your analysis and conclusions. Together, they demonstrate that your device meets regulatory requirements by showing adequate clinical evidence for safety and performance. The report serves as primary evidence for regulatory submissions and ongoing compliance monitoring.
Evidence requirements depend on your device's risk classification, novelty, and intended use. Class I devices typically need minimal clinical evidence, while Class III devices require extensive clinical data including investigations. Most Class IIa software devices can rely on literature review and equivalence demonstration. Consult MDCG 2020-6 evidence level requirements for your specific device type.
Yes, you can use literature from similar devices as supportive evidence for state-of-the-art analysis. However, for equivalence claims, you need a specific equivalent device that closely matches your technical, biological, and clinical characteristics. Literature from the broader clinical field helps establish clinical background and benchmarks but cannot substitute for device-specific evidence.
Limited literature is common for novel devices or niche applications. Document your search strategy thoroughly and justify why available evidence is sufficient for your device's risk level. Consider expanding search terms, including older studies, or looking at related clinical areas. For higher-risk devices with insufficient literature, you may need to conduct clinical investigations.
Focus on demonstrating that core clinical functionality remains equivalent while additional features don't introduce new risks. Document technical, biological, and clinical similarities systematically. Justify any differences by showing they don't affect safety or clinical performance. Enhanced features that improve usability without changing core function typically support rather than undermine equivalence claims.
Update your report when new clinical evidence becomes available, safety signals emerge, or your device changes significantly. Plan regular updates based on your PMCF activities and literature monitoring. Major updates may be required for significant software changes, new indications, or regulatory guidance updates. Maintain version control and document all changes in revision history.
# Clinical Investigations Consult with FormlyAI
Source: https://docs.withdovetail.com/tasks/clinical-investigations-consult-with-formlyai
Receive expert guidance determining clinical study needs and designing efficient investigation protocols.
## Summary
A clinical investigations consult provides expert guidance on whether your medical device requires clinical studies and how to design appropriate clinical investigation protocols. This consultation helps determine if literature-based clinical evaluation is sufficient or if you need to conduct clinical trials to demonstrate safety and clinical performance.
## Why is Clinical Investigations Consult important?
Clinical investigations represent a **significant investment in time, resources, and regulatory complexity** that many medical device companies want to avoid if possible. However, certain devices **cannot achieve market approval** without clinical study data, particularly novel technologies, high-risk devices, or those lacking adequate equivalent devices. A clinical investigations consult helps you make informed decisions about whether clinical studies are necessary for your specific device and regulatory pathway. This consultation can **save substantial costs** by identifying alternative evidence strategies or ensuring you design efficient studies that meet regulatory requirements. Without proper guidance, you risk conducting unnecessary studies or designing inadequate protocols that don't support regulatory approval.
## Regulatory Context
Under **21 CFR Part 812** (Investigational Device Exemptions):
* **Significant risk devices** require FDA IDE approval before clinical studies
* **Non-significant risk devices** may proceed with IRB approval only
* **510(k) pathway** typically relies on predicate device comparison rather than clinical studies
* **De Novo pathway** for novel devices often requires clinical data
**Special attention required for:**
* Class III devices requiring PMA with clinical trial data
* Software medical devices with AI/ML algorithms requiring real-world validation
* Novel devices without adequate predicate devices
* Devices with new indications for use requiring clinical validation
Under **EU MDR 2017/745**:
* **Article 62** governs clinical investigations requirements
* **Annex XV** provides clinical investigation requirements
* **ISO 14155** standard for clinical investigation design and conduct
* **MDCG 2020-6** guidance on clinical evidence requirements by device type
**Special attention required for:**
* Class IIb and III devices often requiring clinical investigations
* Implantable devices requiring long-term safety data
* Novel devices without equivalent devices for comparison
* Software medical devices with clinical decision support functions
## Guide
A clinical investigations consult systematically evaluates your device's **clinical evidence needs** and determines the most efficient pathway to regulatory approval. The consultation process helps optimize your clinical development strategy while minimizing unnecessary costs and delays.
### Device Assessment and Classification
The consultation begins with comprehensive **device characterization** including intended use, patient population, risk classification, and regulatory pathway. Your device's novelty, complexity, and risk profile directly influence clinical investigation requirements. Software medical devices, particularly those with AI/ML components, may require clinical validation even at lower risk classifications.
### Regulatory Pathway Analysis
Different regulatory pathways have varying **clinical evidence requirements**. The 510(k) pathway typically relies on predicate device comparison and literature review, while PMA requires extensive clinical data. De Novo submissions for novel devices often need clinical studies to establish safety and effectiveness. The consultation evaluates which pathway best suits your device and evidence availability.
### Equivalent Device Analysis
A critical assessment determines whether **adequate equivalent devices** exist for your intended use. If suitable equivalent devices are available and you can demonstrate technical, biological, and clinical equivalence, clinical investigations may not be necessary. The consultation evaluates potential equivalent devices and assesses the strength of equivalence claims.
### Literature and State-of-the-Art Review
The consultation examines **available clinical literature** and state-of-the-art analysis to determine if existing evidence supports your device's safety and performance claims. Comprehensive literature may provide sufficient evidence for lower-risk devices, while novel applications or limited literature may necessitate clinical studies.
### Risk-Benefit Assessment
A thorough **risk analysis** evaluates whether your device's risks can be adequately characterized through non-clinical testing or require clinical validation. High-risk devices, those with novel mechanisms of action, or devices targeting vulnerable populations typically require clinical investigation data.
### Clinical Study Design Recommendations
If clinical investigations are necessary, the consultation provides **study design guidance** including primary endpoints, patient populations, sample size considerations, and regulatory submission strategies. The goal is designing efficient studies that provide adequate evidence while minimizing time and cost.
### Alternative Evidence Strategies
The consultation explores **alternative evidence approaches** such as real-world evidence collection, registry studies, or post-market clinical follow-up that might satisfy regulatory requirements without traditional clinical trials. These approaches can be particularly valuable for software devices or those with existing clinical use.
### Regulatory Submission Strategy
The consultation develops a comprehensive **regulatory strategy** integrating clinical evidence with other submission components. This includes timing recommendations, regulatory meeting strategies, and coordination with quality system and technical documentation requirements.
## Example
**Scenario:** You've developed an AI-powered diagnostic software that analyzes medical images to detect early-stage skin cancer. The software is classified as Class IIb and you're considering both FDA 510(k) and EU MDR pathways. You need guidance on whether clinical investigations are required.
### Clinical Investigations Consult Process
**1. Device Assessment**
* Device: DermAI Pro v2.0, AI-powered skin cancer detection software
* Classification: Class IIb (EU), Class II (US)
* Intended use: Assist dermatologists in early skin cancer detection
* Patient population: Adults with suspicious skin lesions
* Novel aspects: Proprietary AI algorithm, enhanced detection accuracy claims
**2. Regulatory Pathway Analysis**
* FDA pathway: 510(k) with predicate device comparison
* EU pathway: CE marking under MDR with clinical evaluation
* Key challenge: AI algorithm requires performance validation
* Recommendation: Pursue 510(k) first, then leverage data for EU submission
**3. Equivalent Device Evaluation**
* Identified predicates: 3 FDA-cleared skin imaging devices
* Limitations: Different AI algorithms, varying performance claims
* Equivalence assessment: Technical similarities exist, but clinical performance differs
* Conclusion: Equivalence claims may be challenging due to AI algorithm differences
**4. Clinical Evidence Requirements**
* FDA: Clinical validation study likely required for AI algorithm performance
* EU: Literature review plus clinical performance study recommended
* Evidence gaps: Real-world diagnostic accuracy, user interface validation
* Alternative: Real-world evidence collection from existing clinical use
**5. Recommended Clinical Study Design**
* Study type: Prospective, multi-center diagnostic accuracy study
* Primary endpoint: Sensitivity and specificity vs. histopathology gold standard
* Sample size: 500 lesions (based on power analysis for 90% sensitivity)
* Duration: 12 months enrollment, 6 months follow-up
* Sites: 5 dermatology clinics with varying patient populations
**6. Alternative Evidence Strategy**
* Phase 1: Retrospective analysis of existing image database (n=2,000)
* Phase 2: Prospective validation study (n=500) if retrospective shows promise
* Real-world evidence: Partner with dermatology practices for ongoing data collection
* Post-market: PMCF study for EU requirements and 510(k) special controls
**7. Regulatory Strategy**
* Pre-submission meeting with FDA to discuss study design
* EU consultation with notified body on clinical evidence requirements
* Parallel development: Conduct studies to satisfy both FDA and EU requirements
* Timeline: 18 months for clinical studies, 6 months for regulatory review
**8. Cost-Benefit Analysis**
* Clinical study costs: $750,000 - $1,200,000
* Alternative approaches: $200,000 - $400,000 for retrospective analysis
* Market opportunity: \$50M annually, justifying clinical investment
* Recommendation: Proceed with clinical studies for optimal market access
## Q\&A
Clinical investigation requirements depend on your device's risk classification, novelty, and available equivalent devices. Class III and some Class IIb devices typically require clinical studies. Novel devices without adequate predicates often need clinical data. Software devices with AI/ML components may require clinical validation regardless of classification. A clinical investigations consult evaluates these factors for your specific device.
Yes, if adequate equivalent devices exist and you can demonstrate technical, biological, and clinical equivalence. Literature-based clinical evaluation is often sufficient for Class I and IIa devices with established equivalent devices. However, novel technologies, AI algorithms, or devices with new indications typically require clinical validation even with equivalent devices available.
Significant risk devices require FDA IDE approval before starting clinical studies, while non-significant risk devices can proceed with IRB approval only. The determination depends on factors like invasiveness, implantation, life support use, and potential for serious harm. Most software medical devices are considered non-significant risk, but AI diagnostic devices may be classified as significant risk.
Timeline varies significantly based on study design, patient population, and endpoints. Simple usability studies may take 3-6 months, while diagnostic accuracy studies typically require 12-18 months. Long-term safety studies for implantable devices can take 2-5 years. Early consultation helps optimize study design to minimize duration while meeting regulatory requirements.
Alternatives include real-world evidence collection, registry studies, retrospective database analyses, and post-market clinical follow-up studies. These approaches can be particularly valuable for software devices or those with existing clinical use. However, regulatory acceptance varies by device type and jurisdiction, requiring careful strategy development.
Costs vary widely based on study complexity, duration, and patient population. Simple usability studies may cost $50,000-$150,000, while multi-center diagnostic studies can cost $500,000-$2,000,000. Pivotal trials for high-risk devices may exceed \$5,000,000. Early consultation helps optimize study design to control costs while meeting regulatory requirements.
# Complaint Log
Source: https://docs.withdovetail.com/tasks/complaint-log
Track customer complaints systematically enabling trend analysis and quality improvement.
## Summary
The Complaint Log systematically records and tracks **customer complaints** and **negative product events** related to device performance, safety, or effectiveness. This document serves as your central repository for complaint management, enabling **regulatory compliance**, **trend analysis**, and **quality improvement** activities.
## Why is Complaint Log important?
The Complaint Log provides **regulatory evidence** that you systematically monitor and respond to customer feedback about device safety and performance issues. Regulatory authorities require documented complaint handling processes to ensure manufacturers identify and address potential safety risks before they cause patient harm. Your complaint log feeds directly into **post-market surveillance activities**, **trend analysis**, and **corrective action decisions**. Without proper complaint documentation, you risk **regulatory non-compliance**, **missed safety signals**, and potential liability for failing to address known device issues.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Complaint files** required under Section 820.198 for device-related complaints
* Must maintain records of **oral and written complaints** involving device failures
* **Investigation and evaluation** of complaints affecting device safety required
* **Medical Device Reports (MDRs)** under 21 CFR 803 for serious complaints
**Special attention required for:**
* **Class III devices** requiring enhanced complaint investigation
* **Software malfunctions** that could affect patient safety
* **Repeat complaints** indicating systematic quality issues
* **Use errors** potentially related to design or labeling deficiencies
Under **EU MDR 2017/745**:
* **Complaint handling** required as part of quality management system (Article 10)
* Must comply with **EN ISO 13485:2016** complaint handling requirements
* **Serious incidents** must be reported to EUDAMED within specified timeframes
* **Trend analysis** required for complaint pattern identification
**Special attention required for:**
* **Serious incidents** requiring immediate regulatory reporting (Article 87)
* **Field Safety Corrective Actions** based on complaint investigations
* **Post-market surveillance** integration with complaint data analysis
* **Clinical evaluation updates** based on real-world use experience
## Guide
Your Complaint Log must capture all **device-related complaints** and **negative product events** while distinguishing them from general customer support inquiries that don't relate to device performance or safety.
### Complaint Identification and Classification
**Distinguish between complaints and general feedback** by focusing on communications alleging deficiencies in device **identity**, **quality**, **durability**, **reliability**, **safety**, **effectiveness**, or **performance**. Record complaints that cannot be resolved by providing basic use instructions or clarifying information to users.
**Identify negative product events** including any feedback resulting from device problems that could cause or may have caused death or serious health deterioration, device malfunctions affecting characteristics or performance, use errors due to ergonomic features, inadequate manufacturer information, or undesirable side effects.
**Assign unique complaint identifiers** using the format "CT" followed by a four-digit number (e.g., CT0001, CT0002) to ensure traceability and systematic tracking throughout your quality management system.
### Data Collection and Documentation
**Capture essential complaint information** including customer identification, date received, product version affected, complaint source (email, social media, vigilance database), detailed issue description, and assessment of impact on device performance or safety.
**Document resolution processes** by categorizing complaints according to their nature and required response: software issues requiring bug resolution procedures, product issues potentially leading to regulatory non-compliance requiring corrective actions, changes requiring change management processes, or minor issues requiring only documentation for future improvements.
**Track complaint resolution** from initial receipt through final closure, documenting specific actions taken and justification for decisions including no action when appropriate. Record closure dates when complaints are sent to appropriate resolution processes, not when those processes are completed.
### Quality Management Integration
**Connect complaints to your quality system** by routing software issues through **Software Problem Resolution** procedures, product compliance issues through **Corrective and Preventive Action (CAPA)** systems, and required changes through **Change Management** processes.
**Evaluate complaint significance** by assessing whether issues relate to device performance, safety, or regulatory compliance. Complaints affecting these areas require more serious investigation and potential regulatory reporting compared to user preferences or unverifiable issues.
**Perform trend analysis** by reviewing complaint patterns, frequencies, and types to identify systematic issues requiring preventive action. Use complaint data to inform **post-market surveillance reports** and **risk management file** updates.
### Regulatory Reporting and Follow-up
**Assess regulatory reporting requirements** for serious complaints that may constitute reportable incidents under FDA MDR requirements or EU MDR serious incident reporting obligations. Determine appropriate timeframes and notification procedures based on complaint severity.
**Monitor complaint effectiveness** by tracking whether implemented solutions successfully address underlying issues and prevent recurrence. Document lessons learned and process improvements based on complaint investigation outcomes.
**Maintain complaint records** according to regulatory requirements for record retention, ensuring complaint files remain accessible for regulatory inspections and audit activities.
## Example
**Scenario:** You manufacture a glucose monitoring app and receive various customer communications. You need to distinguish between complaints requiring documentation and general support inquiries while properly categorizing and processing each complaint through appropriate resolution procedures.
### Complaint Log for GlucoTrack Mobile App
| Complaint ID | Customer ID | Date Received | Product / Version | Source | Description | Impact on Performance / Safety | Resolution Process | Action Taken | Date Closed |
| ------------ | ----------- | ------------- | ----------------- | ---------------- | ------------------------------------------------------------ | -------------------------------------------------- | -------------------------------- | ------------------------------------------------------ | ----------- |
| CT0001 | CS0001 | 2024-03-15 | GlucoTrack v2.1 | Email complaint | App crashes when entering glucose values above 400 mg/dL | Yes - prevents critical high glucose documentation | SOP Software Problem Resolution | Bug fix implemented in v2.1.1, user notified of update | 2024-03-18 |
| CT0002 | CS0002 | 2024-03-20 | GlucoTrack v2.1 | App store review | Insulin calculator provides incorrect dosing recommendations | Yes - potential for medication errors | SOP CAPA | CAPA-2024-001 initiated, algorithm validation required | 2024-03-21 |
| CT0003 | CS0003 | 2024-03-25 | GlucoTrack v2.1 | Customer support | Cannot sync data with doctor's system | Yes - affects clinical decision support | SOP Change Management | CR-2024-005 submitted for API compatibility update | 2024-03-26 |
| CT0004 | CS0004 | 2024-04-02 | GlucoTrack v2.1 | Social media | Prefers different color scheme for charts | No - user preference only | Recorded for future improvements | Feedback documented for next version planning | 2024-04-02 |
**Complaint Processing Examples:**
**CT0001** - Software crash affecting safety-critical functionality required immediate software problem resolution with user notification and version update.
**CT0002** - Dosing calculation error identified as potential regulatory compliance issue requiring formal CAPA investigation and algorithm validation.
**CT0003** - Data synchronization failure affecting clinical workflow required change management process to evaluate and implement system compatibility improvements.
**CT0004** - User interface preference classified as enhancement request for future consideration without immediate action required.
## Q\&A
Record complaints alleging deficiencies in device identity, quality, durability, reliability, safety, effectiveness, or performance that cannot be resolved with basic instructions. Include negative product events that could cause health deterioration, device malfunctions, use errors, or inadequate information. General support inquiries and user preferences don't require complaint log entry.
Log only feedback related to device performance or safety in your complaint log. General feedback or support issues that can be resolved with instructions don't need QMS documentation. Use separate systems like ticketing platforms to track non-complaint feedback while ensuring medical device-related issues are properly categorized.
Implement ticket management systems that categorize medical and non-medical device complaints. Log all complaints but mark their relevance to medical device performance. Track additional criteria for relevant complaints including severity, resolution requirements, and regulatory implications. Consider automation tools for initial categorization.
Route software issues through Software Problem Resolution procedures, product compliance issues through CAPA systems, and required changes through Change Management processes. Document complaints that are duplicate, unverifiable, or represent user preferences for future improvements or mark as requiring no immediate action.
Maintain running lists of all complaints specifying their relevance to medical device performance. Use systematic categorization based on impact on performance, safety, or compliance. Ensure complaint logs support post-market surveillance activities and provide evidence of systematic complaint handling for regulatory inspections.
Report serious incidents immediately when complaints involve death, serious injury, or life-threatening situations. Assess whether complaint patterns indicate trends requiring regulatory notification. Consult regulatory requirements for specific timeframes and reporting procedures based on complaint severity and geographic markets.
# EU Declaration Of Conformity
Source: https://docs.withdovetail.com/tasks/declaration-of-conformity
Issue formal legal statement declaring device compliance with EU regulatory requirements for CE marking.
## Summary
The **EU Declaration of Conformity** is a formal legal statement where you, as the manufacturer, declare under your sole responsibility that your medical device complies with all applicable regulatory requirements. This document serves as your official certification that the device meets **EU MDR 2017/745** standards and can be legally placed on the European market.
## Why is EU Declaration of Conformity important?
The EU Declaration of Conformity represents the **final regulatory milestone** before market entry in the EU. Without this document, you cannot legally sell your medical device in Europe. It serves as your **legal guarantee** to regulatory authorities, healthcare providers, and patients that your device has undergone proper conformity assessment procedures and meets all essential safety and performance requirements. This document also provides **legal protection** for your company by demonstrating due diligence in regulatory compliance and establishes **traceability** for post-market surveillance activities.
## Regulatory Context
Under **EU MDR 2017/745**:
* **Article 19** mandates the Declaration of Conformity for all medical devices
* **Annex IV** specifies the exact content requirements
* Must be issued **before** CE marking and market placement
* Required for all device classes with **different conformity assessment routes**
**Special attention required for:**
* Class I devices (non-sterile, non-measuring, non-reusable): Self-declaration based on technical documentation
* Class I (sterile, measuring, reusable), IIa, IIb, III: Notified body involvement required
* Basic UDI-DI must be included and registered in EUDAMED
* Person Responsible for Regulatory Compliance (PRRC) must be identified
## Guide
Your EU Declaration of Conformity must include **specific mandatory elements** as defined by Annex IV of MDR 2017/745. The document structure follows a standardized format that regulatory authorities expect to see.
### Essential Information Requirements
**Manufacturer Details**: Include your complete legal name, registered address, and contact information. If you're not EU-based, you must also include your **authorized representative's** details who acts on your behalf within the EU.
**Device Identification**: Provide your device's **product/trade name**, **software version**, **Basic UDI-DI**, and **intended purpose**. The intended purpose must match exactly what you've defined in your technical documentation and cannot be broader than what you've validated.
**Classification Information**: State your device's **classification** (Class I, IIa, IIb, or III) and provide the **classification rule justification**. This determines which conformity assessment procedure applies to your device.
### Conformity Assessment Declaration
The conformity assessment section varies based on your device class:
**Class I (non-sterile, non-measuring, non-reusable)**: Declare that conformity was demonstrated by drawing up technical documentation according to **Annexes II and III** and issuing the declaration according to **Article 19 and Annex IV**.
**Class I (sterile, measuring, reusable) and higher classes**: Reference the specific **Annex IX procedures** followed and include your **notified body's name and identification number** if applicable.
### Technical Standards Compliance
Include an **Annex A** listing all applicable technical standards your device complies with, such as:
* **EN ISO 13485:2016** for quality management systems
* **ISO 14971:2019** for risk management
* **IEC 62304:2006** for medical device software
* **IEC 62366-1:2015** for usability engineering
### Signature Requirements
The EU declaration must be signed by someone with **authority to bind the manufacturer legally**. Typically this includes:
* **CEO or Managing Director** representing overall company responsibility
* **Person Responsible for Regulatory Compliance (PRRC)** confirming regulatory oversight
### Document Control
Assign a unique **document identifier** and maintain **version control**. The EU declaration must be kept available for **10 years after** the last device covered by it has been placed on the market.
## Example
### Scenario
You've developed a Class IIa software medical device for cardiac monitoring. After completing your technical documentation, risk management, clinical evaluation, and notified body assessment, you're ready to create your Declaration of Conformity. Your notified body has issued a certificate confirming compliance with Annex IX procedures.
### Example EU Declaration of Conformity
**EU Declaration of Conformity**
ID: DOC-001-2024
The EU Declaration of Conformity is issued under the sole responsibility of the manufacturer. This document is a formal statement by the manufacturer that the medical device described below conforms to the requirements of the Medical Device Regulation (MDR) 2017/745.
**Manufacturer Information**
**Legal Manufacturer:**\
CardioTech Solutions GmbH
**Manufacturer Address:**\
Hauptstraße 123\
10115 Berlin, Germany
**Regulatory Contact Information**\
Dr. Sarah Mueller, PRRC\
Email: [regulatory@cardiotech.de](mailto:regulatory@cardiotech.de)\
Phone: +49 30 12345678
**Medical Device Information**
**Product/Trade Name:**\
CardioMonitor Pro
**Software Version:**\
v2.1.0
**Basic UDI-DI:**\
4012345678901
**Intended Purpose:**\
Software for continuous monitoring and analysis of cardiac rhythm patterns in hospital settings for healthcare professionals.
**Medical Device Classification Information**
**Medical Device Class:**\
Class IIa
**Classification Rule Justification:**\
According to Rule 11 of Annex VIII, software intended to provide information for decisions with diagnosis or therapeutic purposes is classified as Class IIa.
**Conformity Assessment**
According to Article 52, conformity assessment was performed according to Chapters I and III of Annex IX of the Regulation (EU) 2017/745.
**Notified Body**
TÜV SÜD Product Service GmbH (NB 0123)
The Medical Device referenced above meets the provisions of Regulation (EU) 2017/745 on medical devices. For a full list of applicable technical standards for the device, refer to Annex A.
**Name:** Dr. Michael Weber\
**Title:** CEO\
**Signature:** \[Signature]
**Name:** Dr. Sarah Mueller\
**Title:** Person Responsible for Regulatory Compliance (PRRC)\
**Signature:** \[Signature]
**Annex A - List of Applicable Technical Standards**
| Standard Number | Standard Name |
| ----------------- | ----------------------------------------------------------------------------------- |
| EN ISO 13485:2016 | Medical devices - Quality management systems - Requirements for regulatory purposes |
| ISO 14971:2019 | Medical devices - Application of risk management to medical devices |
| IEC 62304:2006 | Medical device software - Software life cycle processes |
| IEC 62366-1:2015 | Medical devices - Application of usability engineering to medical devices |
## Q\&A
Yes, the EU Declaration of Conformity must be in the local language of each target market where you plan to sell your device. For initial market entry, create a comprehensive English master version first, then translate into required local languages. This is a legal requirement under MDR Article 10(11).
For Class I devices (non-sterile, non-measuring, non-reusable), you can issue the EU declaration once your technical documentation is complete and demonstrates compliance. For higher classes or special Class I devices, you must wait until your notified body has completed the conformity assessment and issued the relevant certificates.
You must issue a new EU Declaration of Conformity whenever there are significant changes to your device, such as software updates that affect safety or performance, changes in intended use, or modifications to your quality management system. Minor updates like bug fixes typically don't require a new declaration, but document the rationale in your change control records.
The EU declaration must be signed by someone with legal authority to bind your company, typically the CEO, Managing Director, or authorized representative. The Person Responsible for Regulatory Compliance (PRRC) should also sign to confirm regulatory oversight. Both signatories must have the competence and authority to take responsibility for the device's compliance.
You must maintain the EU Declaration of Conformity for at least 10 years after the last device covered by the declaration has been placed on the market. This is required under MDR Article 10(8) and is essential for post-market surveillance and regulatory inspections.
# Deployment Evaluation Checklist
Source: https://docs.withdovetail.com/tasks/deployment-evaluation-checklist
Assess deployment complexity and risks ensuring safe software operation in customer environments.
## Summary
The Deployment Evaluation Checklist is a systematic assessment tool that evaluates the complexity and risks associated with deploying your medical device software in customer environments. This document helps determine whether additional deployment evaluation is required, establishes installation and monitoring procedures, and documents the successful deployment of your device to ensure ongoing safety and performance.
## Why is Deployment Evaluation Checklist important?
Medical device software deployment introduces **unique risks** that don't exist during development or testing phases. Real-world customer environments have varying infrastructure complexity, interdependencies, and potential failure modes that could compromise device safety and performance. The deployment evaluation ensures you have **systematically assessed these risks** and implemented appropriate controls before releasing your device to customers. This proactive approach helps prevent deployment-related incidents and demonstrates regulatory compliance with software lifecycle requirements.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Design controls** (820.30) require validation in actual use environment
* **Installation and servicing** (820.200) must be controlled and documented
* **Software validation** guidance requires deployment environment consideration
* **Cybersecurity guidance** emphasizes secure deployment practices
**Special attention required for:**
* Network security requirements for connected devices
* Software validation in intended use environment
* Change control for deployment configuration differences
* Post-market surveillance of deployment-related issues
Under **EU MDR 2017/745**:
* **GSPR 17** requires software reliability and performance in intended use
* **EN 62304** mandates software deployment planning and execution
* **IEC 80001-1** provides network security requirements for medical devices
* **Post-market surveillance** (Articles 83-86) must monitor deployment issues
**Special attention required for:**
* Infrastructure complexity assessment for patient safety impact
* Cybersecurity risk management in deployment environments
* Clinical evaluation of software performance in real-world settings
* Incident reporting for deployment-related safety issues
## Guide
### Infrastructure Complexity Assessment
The first critical step is evaluating your customer's **infrastructure complexity**. Insignificant complexity environments are well-established with few interdependencies, robust backup systems, and very low risk of failures that could compromise device safety. Significant complexity environments have multiple interdependencies, medium to high risk of system failures, and potential for compromising device safety and performance. This assessment determines whether full deployment evaluation is required.
### Customer Information Documentation
Document comprehensive **customer contact information** including technical contacts, company details, and communication preferences. This information is essential for ongoing support, incident response, and post-market surveillance activities. Ensure you have multiple contact methods and understand the customer's organizational structure for device management.
### Installation Planning and Execution
Develop a detailed **installation plan** that addresses the specific customer environment, including on-site versus remote installation approaches. Define clear **acceptance criteria** that must be met for successful installation, such as user authentication functionality, system startup verification, and basic operational tests. Document team member responsibilities, expected timelines, and contingency procedures for installation issues.
### Monitoring and Measurement Strategy
Establish how you will **monitor and measure** your deployed device performance. Automatic monitoring through software telemetry, remote monitoring systems, or on-site equipment provides continuous oversight. Manual monitoring through customer communications, scheduled check-ins, or site visits offers direct feedback but requires more resources. Define monitoring frequency, key performance indicators, and escalation procedures for identified issues.
### Deployment Documentation and Verification
Document the **actual deployment process** including installation success against acceptance criteria, any issues encountered, and resolution approaches. Record the specific software version deployed and verify that deployment occurred successfully according to your plan. This documentation provides evidence of controlled deployment and supports post-market surveillance activities.
### Risk Management Integration
Your deployment evaluation must integrate with your overall **risk management process**. Consider deployment-specific risks such as network security vulnerabilities, infrastructure failures, user training gaps, and environmental factors. Implement appropriate risk controls and monitor their effectiveness throughout the deployment lifecycle.
### Change Control and Version Management
Establish procedures for **managing software updates** and configuration changes in deployed environments. Document the deployed software version, track any customizations or configurations, and maintain change control procedures for future updates. This ensures traceability and supports regulatory compliance for software modifications.
## Example
### Scenario
You are deploying a cloud-based diagnostic imaging software to a large hospital network. The hospital has multiple departments, complex IT infrastructure with various imaging systems, and strict cybersecurity requirements. The software processes medical images from different modalities and provides AI-assisted diagnostic recommendations to radiologists.
### Example Deployment Evaluation
#### Customer Information
| Customer Information | Details |
| ------------------------ | --------------------------------------------------------------- |
| Customer Contact Name | Dr. Sarah Johnson, Chief Medical Officer |
| Customer Contact Email | [s.johnson@cityhospital.com](mailto:s.johnson@cityhospital.com) |
| Customer Contact Phone | +1-555-0123 |
| Customer Company Name | City General Hospital Network |
| Customer Company Address | 123 Medical Center Drive, Healthcare City, HC 12345 |
#### Infrastructure Assessment
**Infrastructure Description:** Large hospital network with 500+ beds, multiple imaging departments (radiology, cardiology, emergency), existing PACS system, hospital information system (HIS), and electronic health records (EHR). Network includes both wired and wireless connectivity with strict firewall policies and VPN access for remote users.
**Infrastructure Complexity:** The infrastructure is complex with multiple interdependencies and a medium to high risk of system failures or issues that could compromise the safety and performance of the deployed device.
**Justification:** The hospital environment has critical interdependencies between imaging systems, network infrastructure, and clinical workflows. Network failures could prevent access to diagnostic tools during emergency situations, potentially impacting patient care. The complex security requirements and integration with existing systems create multiple potential failure points.
#### Installation Plan
**Installation Approach:** Remote installation with on-site technical support during initial deployment.
**Installation Steps:**
1. Pre-deployment network connectivity testing
2. Software installation on hospital servers
3. Integration testing with existing PACS system
4. User account setup and authentication verification
5. Clinical workflow testing with sample cases
6. Staff training and go-live support
**Acceptance Criteria:**
* Radiologists can successfully log into the system
* Medical images load within 10 seconds from PACS integration
* AI diagnostic recommendations display correctly
* Audit logs capture all user activities
* System maintains 99.9% uptime during 48-hour monitoring period
#### Monitoring Plan
**Monitoring Approach:** Automatic monitoring with manual oversight.
**Monitoring Description:** Automated system monitoring through cloud-based telemetry collecting performance metrics, error logs, and usage statistics. Weekly check-in calls with IT department and monthly clinical feedback sessions with radiologists. Real-time alerts for system errors or performance degradation.
## Q\&A
Deployment evaluation is required when your customer's infrastructure has significant complexity with multiple interdependencies and medium to high risk of failures that could compromise device safety and performance. Simple, well-established environments with robust backup systems typically don't require full evaluation.
Document the specific failures, implement corrective actions, and retest against acceptance criteria. Don't proceed with deployment until all criteria are met. Update your installation plan based on lessons learned and consider whether additional risk controls are needed.
Work closely with customer IT security teams to understand requirements, provide security documentation for your software, conduct security assessments, and implement additional controls as needed. Document all security measures in your deployment evaluation.
Monitor device performance, user feedback, system errors, and any safety-related incidents. The monitoring approach (automatic vs. manual) and frequency should be proportional to the device risk class and infrastructure complexity. Document monitoring results for post-market surveillance.
Establish change control procedures that include customer notification, testing in the deployment environment, scheduled maintenance windows, and verification of successful updates. Document the update process and maintain version traceability.
Reassess infrastructure complexity if significant changes occur, update your deployment evaluation if needed, and verify that your device continues to perform safely and effectively. Major infrastructure changes may require revalidation of your deployment.
Deployment evaluation focuses on technical infrastructure and installation risks, while clinical evaluation assesses clinical safety and performance. However, deployment issues that could impact clinical outcomes should be considered in your overall clinical risk assessment and post-market surveillance.
# Design History File
Source: https://docs.withdovetail.com/tasks/design-history-file
Compile comprehensive design control records demonstrating systematic development and regulatory compliance.
## Summary
The **Design History File (DHF)** is a comprehensive compilation of records documenting the design and development of your medical device according to FDA design control requirements. It contains all design inputs, outputs, reviews, verification, validation, and design transfer activities, serving as evidence of systematic design control compliance under **21 CFR Part 820.30**.
## Why is Design History File important?
The Design History File serves as the **regulatory foundation** for demonstrating FDA design control compliance and is essential for **510(k) submissions** and **PMA applications**. It provides the FDA with complete evidence that your device was developed using systematic design controls, ensuring safety and effectiveness. The DHF is your **primary defense** during FDA inspections and demonstrates that your device meets all specified requirements. Without a properly maintained DHF, you cannot demonstrate design control compliance or obtain FDA clearance for most medical devices.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls):
* **Mandatory** for Class II and III devices and some Class I devices
* Must contain design inputs, outputs, reviews, verification, validation, and transfer
* Required for **510(k) submissions** and **PMA applications**
* Must be maintained throughout device lifecycle and available for **FDA inspection**
**Special attention required for:**
* Software lifecycle documentation according to FDA software guidance
* Risk management integration throughout design process
* Design change control and impact assessment procedures
* Verification and validation evidence for all design outputs
## Guide
Your Design History File must demonstrate systematic application of **design controls** throughout your device development process. The DHF serves as a comprehensive record that links design inputs through outputs, reviews, verification, validation, and transfer activities.
### Design Inputs Documentation
**User Needs and Requirements**: Document all **user needs** identified through stakeholder analysis, market research, and clinical input. Transform these into specific **design inputs** that are measurable, verifiable, and traceable. For software medical devices, include **functional requirements**, **performance requirements**, **interface requirements**, and **safety requirements**.
**Regulatory Requirements**: Include all applicable **FDA regulations**, **consensus standards**, and **guidance documents** that apply to your device. Reference specific sections of **21 CFR Part 820**, relevant **FDA guidance documents**, and applicable standards such as **IEC 62304** for software or **ISO 14971** for risk management.
**Risk Management Integration**: Document how **risk management activities** inform design inputs. Include hazard analysis results, risk assessments, and risk control measures that drive specific design requirements. Demonstrate traceability from identified hazards to design inputs that address those risks.
### Design Outputs Documentation
**Design Specifications**: Document all **design outputs** including software specifications, architectural designs, interface specifications, and performance specifications. For software devices, include **software requirements specifications**, **software architecture documents**, and **detailed design documents**.
**Design Reviews**: Maintain records of all **design reviews** conducted throughout development. Include review agendas, attendee lists, review findings, and resolution of identified issues. Demonstrate that reviews were conducted by qualified personnel not directly responsible for the design stage being reviewed.
**Verification and Validation**: Document all **verification activities** that demonstrate design outputs meet design inputs, and **validation activities** that demonstrate the device meets user needs and intended use. Include test protocols, test reports, and evidence that all requirements have been verified and validated.
### Design Controls Implementation
**Design Planning**: Document your **design control procedures** and how they're implemented throughout development. Include design planning documents, responsibility assignments, and resource allocation. Demonstrate that design controls are proportional to device risk and complexity.
**Design Changes**: Maintain records of all **design changes** including change requests, impact assessments, approvals, and verification of change implementation. Demonstrate that changes are controlled and don't adversely affect device safety or effectiveness.
**Design Transfer**: Document **design transfer activities** that ensure design outputs are correctly translated into production specifications. Include manufacturing procedures, quality control measures, and evidence that production units meet design specifications.
### Software-Specific Documentation
**Software Lifecycle Process**: For software medical devices, document your **software lifecycle process** according to **IEC 62304** or equivalent. Include software planning, requirements analysis, architectural design, detailed design, implementation, integration testing, and system testing.
**Software Risk Management**: Document **software risk management activities** including software safety classification, hazard analysis, and risk control measures. Demonstrate how software risks are identified, analyzed, and controlled throughout the lifecycle.
**Software Verification and Validation**: Include comprehensive **software testing documentation** including unit testing, integration testing, system testing, and user acceptance testing. Demonstrate that software meets all specified requirements and performs safely under normal and fault conditions.
## Example
### Scenario
You've developed a Class II software application for remote patient monitoring that analyzes vital signs and alerts healthcare providers to abnormal patterns. You need to compile your Design History File for 510(k) submission to the FDA.
### Design History File Structure Example
**1. Design Inputs**
**User Needs Document:** UN-001-2024
* Healthcare providers need real-time patient monitoring
* System must detect abnormal vital sign patterns
* Alerts must be timely and actionable
* Interface must be intuitive for clinical workflow
**Design Input Specifications:** DI-001-2024
* Monitor heart rate, blood pressure, temperature, oxygen saturation
* Detect abnormal patterns within 30 seconds
* Generate alerts with 95% sensitivity and 90% specificity
* Comply with HIPAA security requirements
**Regulatory Requirements:** RR-001-2024
* 21 CFR Part 820 (Quality System Regulation)
* IEC 62304 (Medical device software)
* ISO 14971 (Risk management)
* IEC 62366 (Usability engineering)
**2. Design Outputs**
**Software Requirements Specification:** SRS-001-2024
* 127 functional requirements covering all monitoring functions
* 45 performance requirements including response times
* 23 interface requirements for user interaction
* 34 safety requirements addressing identified risks
**Software Architecture Document:** SAD-001-2024
* Modular architecture with monitoring, analysis, and alert modules
* Database design for patient data storage
* Communication protocols for device integration
* Security architecture for data protection
**3. Design Reviews**
**Design Review 1:** Completed March 15, 2024 - User needs and design inputs approved\
**Design Review 2:** Completed May 20, 2024 - Software architecture approved\
**Design Review 3:** Completed July 10, 2024 - Detailed design approved\
**Design Review 4:** Completed September 5, 2024 - Verification and validation approved\
**Design Review 5:** Completed October 15, 2024 - Design transfer approved
**4. Verification and Validation**
**Software System Test Plan:** SSTP-001-2024\
**Software System Test Report:** SSTR-001-2024
* 156 test cases executed with 100% pass rate
* Performance testing confirms 15-second response time
* Security testing validates HIPAA compliance
**Usability Validation Report:** UVR-001-2024
* 15 healthcare providers completed usability testing
* 98% task completion rate achieved
* No critical usability issues identified
**5. Risk Management**
**Risk Management Plan:** RMP-001-2024\
**Risk Assessment:** RA-001-2024
* 23 hazards identified and analyzed
* 15 risk control measures implemented
* All residual risks determined acceptable
**6. Design Transfer**
**Design Transfer Plan:** DTP-001-2024\
**Design Transfer Report:** DTR-001-2024
* Production procedures established
* Quality control measures implemented
* First production units verified against design specifications
## Q\&A
Your DHF must include design inputs, design outputs, design review records, verification and validation documentation, design change records, and design transfer documentation. For software devices, also include software lifecycle documentation, software requirements, architecture documents, and comprehensive testing records. The exact contents depend on your device complexity and risk classification.
For software devices, your DHF must include comprehensive software lifecycle documentation according to IEC 62304 or equivalent standards. This includes software planning, requirements analysis, architectural design, detailed design, implementation records, and extensive testing documentation. The level of detail should be proportional to your software safety classification (Class A, B, or C).
You must update your DHF whenever you make design changes that affect device safety, effectiveness, or performance. This includes software updates, hardware modifications, or changes to intended use. Minor bug fixes may not require DHF updates, but document the rationale in your change control records. Major changes typically require design review and reverification.
You must maintain your DHF for the lifetime of the device type plus additional time as specified in your quality system procedures. The FDA recommends maintaining DHF records for at least the expected lifetime of the device. The DHF must be readily available for FDA inspection and should be stored in a secure, retrievable format.
You can maintain one DHF for a device type, but you must document all design changes and their verification in the file. Each significant software version that affects safety or effectiveness should have its own design change documentation within the DHF. Minor updates can be documented as design changes without creating a new DHF.
Verification demonstrates that design outputs meet design inputs (building the device right), while validation demonstrates that the device meets user needs and intended use (building the right device). Your DHF must include both verification evidence (like testing against specifications) and validation evidence (like clinical or usability studies demonstrating the device works for its intended users and use environment).
# Design Review Checklist
Source: https://docs.withdovetail.com/tasks/design-review-checklist
Verify design completeness and readiness for verification through systematic review criteria and evaluation.
## Summary
The Design Review Checklist verifies that your medical device design is complete and ready for transition to verification and validation. This systematic review ensures **all design inputs** are properly implemented, **user needs are addressed**, and **risk controls are incorporated** before proceeding to testing phases.
## Why is Design Review Checklist important?
Design review serves as a **critical quality gate** between design and verification phases. Regulators require evidence that your design process was systematic and complete before you begin testing. This checkpoint prevents costly rework by identifying missing requirements, incomplete designs, or inadequate risk controls early. The checklist provides **objective criteria** to demonstrate that your design outputs meet all inputs and are ready for validation, ensuring regulatory compliance and reducing development risks.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls):
* **Design review** is mandatory before verification activities (Section 820.30(e))
* Must verify design outputs meet design inputs and user needs
* Review must be conducted by **qualified individuals** not directly responsible for the design
* **Documented evidence** of review completion is required
* Design controls apply to **all Class II and III devices** and most Class I devices
**Special attention required for:**
* Software medical devices (FDA Guidance on Software as Medical Device)
* Design input validation against user needs and intended use
* Risk management integration per ISO 14971
* Traceability between user needs, design inputs, and design outputs
Under **EU MDR 2017/745**:
* Design review required under **EN ISO 13485:2016** Section 7.3.4
* Must demonstrate compliance with **General Safety and Performance Requirements** (Annex I)
* Review outcomes must support **technical documentation** requirements (Annex II)
* **EN ISO 14971:2019** risk management integration mandatory
**Special attention required for:**
* Article 10(9) quality management system requirements
* Annex I GSPR compliance verification through design
* Clinical evaluation planning integration (Article 61)
* Software lifecycle processes per IEC 62304 (if applicable)
## Guide
Your design review checklist systematically evaluates three critical areas to ensure regulatory compliance and design completeness.
### General Design Review
The primary checklist verifies fundamental design control requirements. Each **user need must have traceable identifiers** linking to design inputs and outputs. Your user needs should address **all stakeholder requirements** including patients, healthcare providers, and regulatory bodies. Verify that user needs consider **intended use comprehensively**, covering normal operation, reasonably foreseeable misuse, and environmental conditions.
Design inputs must **align precisely with user needs** while incorporating applicable standards and regulatory requirements. Your product design should demonstrate **manufacturability** through detailed specifications, assembly instructions, and process controls. Most critically, verify that **risk control measures** identified in your risk management process are properly integrated into the design rather than relying solely on protective measures or information for safety.
### Software Architecture Review
For software medical devices, conduct additional verification focusing on **requirements implementation** and safety classification. Ensure your software architecture implements **all system and software requirements** with clear traceability. Each **software system must have determined safety classification** following IEC 62304 standards.
Document all **software items and interfaces** comprehensively, including data flows, communication protocols, and integration points. Verify that interfaces between software items and with hardware are **properly specified and supported**. For Software of Unknown Provenance (SOUP), ensure your architecture supports **proper operation and integration** with documented version control and risk assessments.
Confirm that your software architecture is **implementable with available resources**, considering development team capabilities, timeline constraints, and technical infrastructure requirements.
### Physical Product Review
Hardware components require verification of **design schematics completeness** ensuring all electrical, mechanical, and assembly drawings meet specified requirements. **Material selection** must demonstrate biocompatibility through appropriate testing per ISO 10993 series and durability validation for intended use duration.
Your design must address **comprehensive safety factors** including electromagnetic compatibility (EMC), electrical safety, mechanical integrity, and environmental resilience. Even software-only devices often require EMC consideration for deployment hardware.
**Packaging and shelf-life design** must comply with sterility requirements (if applicable), environmental protection needs, and labeling regulations while supporting the intended product lifecycle.
## Example
### Scenario
You are reviewing the design of a mobile ECG monitoring app with a connected hardware sensor before proceeding to verification testing. Your team has completed user needs analysis, system requirements, software architecture, and hardware design. The design review ensures all components are ready for validation.
### Example Design Review Checklist
**ID:** DRC-001-ECG-Monitor
**Purpose:** This checklist verifies that the ECG monitoring system design is confirmed and design inputs were properly generated based on user needs.
**Scope:** This checklist applies to the Mobile ECG Monitor System including mobile application and sensor hardware.
**Design Review Checklist**
| Checklist Items | Yes/No | Justification if No |
| -------------------------------------------------------------------------------------- | ------ | -------------------------------------------------------------------------------- |
| Each user need has an identifiable number for traceability. | Yes | User needs UN-001 through UN-015 all assigned unique identifiers |
| The user needs address all relevant stakeholder requirements. | Yes | Requirements from cardiologists, patients, and IT administrators captured |
| The user needs take into consideration all relevant aspects of intended use. | Yes | Includes home monitoring, clinical review, and emergency detection scenarios |
| The user needs include all necessary organizational, technical, or other requirements. | Yes | HIPAA compliance, FDA cybersecurity, and clinical workflow requirements included |
| The user needs are not ambiguous, self-contradicting or conflicting with each other. | Yes | Requirements review identified and resolved three conflicts in version 2.0 |
| Design inputs align with user needs, intended use, and regulatory requirements. | Yes | Traceability matrix demonstrates complete alignment with 21 CFR 820.30 |
| Product design can be manufactured, assembled, and tested. | Yes | Manufacturing partner confirmed feasibility and provided cost estimates |
| Risk control measures have been incorporated into the design, if applicable. | Yes | Implemented encryption, signal validation algorithms, and fail-safe mechanisms |
**Software Products**
| Criteria | Yes/No | Comments |
| ------------------------------------------------------------------------------------------------------------- | ------ | ------------------------------------------------------------------------ |
| The software architecture implements all system and software requirements. | Yes | Architecture review confirmed coverage of SRS-001 through SRS-087 |
| All software systems are listed and their respective safety class has been determined. | Yes | Mobile app: Class B, Cloud backend: Class A, Sensor firmware: Class B |
| All software items are listed and described, including interfaces. | Yes | 12 software items documented with API specifications and data schemas |
| The software architecture supports interfaces between software items and between software items and hardware. | Yes | Bluetooth LE, HTTPS REST APIs, and USB interfaces fully specified |
| The architecture supports proper operation of any SOUP items, as needed. | Yes | React Native, AWS services, and encryption libraries properly integrated |
| The software architecture can be implemented with resources provided by the manufacturer. | Yes | Development team skills assessed, AWS infrastructure capacity confirmed |
**Physical Products**
| Checklist Items | Yes/No | Justification if No |
| -------------------------------------------------------------------------------------------------------- | ------ | ---------------------------------------------------------------------------------- |
| Design and assembly schematics of the product are complete and meet requirements. | Yes | Electrical schematics, PCB layout, and enclosure drawings approved by engineering |
| Material selection meets biocompatibility and durability needs. | Yes | Medical-grade silicone tested per ISO 10993-5, ABS plastic for 5-year lifecycle |
| Physical, environmental, performance, and safety factors have been considered in the design. | Yes | IP65 rating for water resistance, drop testing specifications, EMC compliance plan |
| Design follows Electromagnetic Compatibility (EMC), safety, and environmental compliance, if applicable. | Yes | Pre-compliance testing completed, formal EMC testing scheduled before release |
| Design of packaging and shelf-life is compliant with product and regulatory requirements. | Yes | 24-month shelf life validated, packaging includes all required labeling elements |
## Q\&A
User needs should be documented as high-level requirements that capture essential product functions while remaining flexible enough to accommodate future changes. Document needs that cover basic functions, performance expectations, and regulatory requirements. Ensure each need has a unique identifier for traceability and addresses all relevant stakeholders including end users, healthcare providers, and regulatory requirements. If user needs are incomplete during design review, they can be updated, which will lead to new system and software requirements.
System requirements should be more granular than user needs but remain objective and testable. They should translate user needs into specific, measurable design criteria that can be verified through testing. Requirements should be flexible enough to allow design evolution while maintaining traceability. Focus on covering all intended software and hardware functions comprehensively rather than being overly technical in specification.
If the design review reveals gaps, update the relevant requirements documents before proceeding to verification. This may require revising user needs, system requirements, or software requirements. Document all changes in your change control process and update traceability matrices. It's acceptable and preferable to revise requirements before certification rather than discovering gaps during testing or regulatory review.
Software architecture documentation should demonstrate complete implementation of all system and software requirements with clear traceability. Document all software items, their interfaces, safety classifications per IEC 62304, and integration with any Software of Unknown Provenance (SOUP). Include data flow diagrams, interface specifications, and evidence that the architecture is implementable with available resources and timeline constraints.
Risk control measures should be designed into the product rather than relying primarily on protective measures or user information. During design review, verify that identified risks from your risk management process have corresponding design controls implemented. Examples include fail-safe mechanisms, input validation, encryption for cybersecurity risks, and physical safeguards. Document how each risk control measure is integrated into the design specification.
Document all design review findings with clear identification of any "No" responses and their justifications. Strong justifications should demonstrate why the finding doesn't prevent proceeding to verification or how alternative measures address the concern. Track any required corrective actions through your change management process and ensure all findings are resolved before final design approval. Maintain review records as evidence of design control compliance.
# Design Transfer Plan
Source: https://docs.withdovetail.com/tasks/design-transfer-plan
Establish systematic approach for transferring validated design to manufacturing ensuring production accuracy.
## Summary
A Design Transfer Plan establishes the systematic approach for transferring your finalized medical device design from development to manufacturing, ensuring that all design outputs are accurately translated into production specifications and procedures. This plan defines the activities, responsibilities, and acceptance criteria for successful design transfer.
## Why is Design Transfer Plan important?
Design transfer is a critical regulatory requirement that ensures your manufacturing process can consistently produce devices that conform to the validated design. This process bridges the gap between design development and commercial manufacturing, preventing design intent from being lost during production scale-up. Without proper design transfer planning, manufacturing may produce devices that differ from the validated design, leading to safety issues, regulatory non-compliance, and potential product recalls.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design transfer is **mandatory** under Section 820.30(h)
* Must ensure design outputs are **correctly translated** to production specifications
* Transfer activities must be **documented and verified**
* Must establish procedures for **design transfer** activities
* Required before **commercial distribution** begins
**Special attention required for:**
* Complete transfer of design controls to manufacturing
* Verification that production specifications match design outputs
* Documentation of manufacturing procedures and work instructions
* Training of manufacturing personnel on new procedures
Under **EU MDR 2017/745**:
* Design transfer must be part of **quality management system** (Article 10(9))
* Must comply with **EN ISO 13485:2016** design transfer requirements (Section 7.3.7)
* Transfer documentation must be included in **technical documentation** (Annex II)
* Must demonstrate **design control** throughout transfer process
**Special attention required for:**
* Risk management integration throughout transfer process
* Post-market surveillance considerations in manufacturing setup
* Traceability requirements implementation
* Notified body notification of significant manufacturing changes
## Guide
Your Design Transfer Plan should systematically address all aspects of transitioning from validated design to controlled manufacturing, ensuring design integrity is maintained throughout the transfer process.
### Transfer Scope and Objectives
**Design Output Identification**: Clearly identify all design outputs that must be transferred to manufacturing including specifications, drawings, software, procedures, and acceptance criteria. Create a comprehensive inventory of all design documentation and deliverables.
**Manufacturing Requirements**: Define the manufacturing processes, equipment, facilities, and personnel required to produce the device according to design specifications. Identify any new manufacturing capabilities that must be developed or qualified.
**Transfer Objectives**: Establish specific, measurable objectives for the design transfer including quality targets, timeline requirements, and success criteria. Define what constitutes successful completion of design transfer activities.
### Transfer Activities and Timeline
**Phase-Gate Approach**: Structure design transfer as a series of phases with defined deliverables and approval gates. Typical phases include transfer planning, manufacturing setup, process qualification, and transfer verification. Establish clear criteria for advancing between phases.
**Activity Sequencing**: Define the sequence and dependencies of transfer activities including manufacturing setup, equipment qualification, personnel training, and process validation. Identify critical path activities and potential bottlenecks.
**Resource Allocation**: Identify personnel, equipment, and facility resources required for each transfer activity. Assign responsibilities and ensure adequate resource availability throughout the transfer timeline.
### Manufacturing Documentation Development
**Production Specifications**: Develop detailed manufacturing specifications that accurately reflect design requirements including materials, processes, equipment settings, and quality controls. Ensure specifications are clear, complete, and unambiguous.
**Work Instructions**: Create step-by-step work instructions for all manufacturing operations including assembly, testing, packaging, and labeling procedures. Include visual aids, quality checkpoints, and troubleshooting guidance.
**Quality Control Procedures**: Establish quality control procedures for monitoring and controlling manufacturing processes including inspection requirements, test procedures, and acceptance criteria. Define sampling plans and statistical process control methods.
### Personnel Training and Qualification
**Training Requirements**: Define training requirements for all personnel involved in manufacturing operations including technical skills, quality procedures, and regulatory requirements. Establish competency assessment criteria and ongoing training needs.
**Qualification Procedures**: Develop procedures for qualifying manufacturing personnel including initial training, competency testing, and ongoing performance monitoring. Document qualification requirements for each manufacturing role.
**Knowledge Transfer**: Plan for effective knowledge transfer from design team to manufacturing personnel including technical briefings, hands-on training, and documentation review sessions. Ensure critical design knowledge is preserved and communicated.
### Verification and Validation Activities
**Transfer Verification**: Define verification activities to confirm that manufacturing processes produce devices conforming to design specifications. Include first article inspection, process capability studies, and comparative testing with development prototypes.
**Process Validation**: Plan process validation activities to demonstrate that manufacturing processes consistently produce conforming devices. Reference manufacturing validation protocols and acceptance criteria.
**Design Verification Confirmation**: Confirm that transferred manufacturing processes maintain design verification results including performance testing, safety testing, and regulatory compliance verification.
## Example
### Scenario
You have completed design validation for your wearable cardiac monitoring device and need to transfer the design to your contract manufacturing partner. The device includes hardware components, embedded software, mobile application, and cloud-based data processing. You need to ensure all design elements are properly transferred and manufacturing can consistently produce devices meeting design specifications.
### Design Transfer Plan
**1. Transfer Scope and Objectives**
This plan covers the transfer of the CardioWatch wearable device design (Version 2.0) to MedTech Manufacturing Solutions. Transfer includes:
* Hardware assembly and testing procedures
* Embedded software installation and verification
* Mobile application build and distribution setup
* Cloud infrastructure deployment and configuration
* Quality control and testing procedures
**2. Transfer Timeline and Phases**
*Phase 1: Manufacturing Setup (Weeks 1-4)*
* Facility qualification and equipment installation
* Personnel training and qualification
* Initial documentation review and approval
* Gate Criteria: Facility ready, personnel qualified, procedures approved
*Phase 2: Process Development (Weeks 5-8)*
* Manufacturing process setup and optimization
* First article production and testing
* Process capability assessment
* Gate Criteria: Process capable, first articles pass all tests
*Phase 3: Process Validation (Weeks 9-12)*
* Manufacturing validation execution
* Statistical process control implementation
* Final documentation approval
* Gate Criteria: Validation successful, processes under control
*Phase 4: Commercial Readiness (Weeks 13-14)*
* Final transfer verification
* Commercial production authorization
* Post-transfer monitoring setup
* Gate Criteria: All transfer objectives met, ready for commercial production
**3. Key Transfer Activities**
*Hardware Manufacturing:*
* Transfer PCB assembly specifications and test procedures
* Qualify component suppliers and establish supply chain
* Set up automated optical inspection and functional testing
* Validate enclosure assembly and sealing processes
*Software Manufacturing:*
* Establish secure software build and signing environment
* Transfer automated testing procedures and acceptance criteria
* Set up software distribution and update mechanisms
* Validate cybersecurity controls and data protection measures
*Quality Control:*
* Transfer all test procedures and acceptance criteria
* Set up statistical process control and monitoring systems
* Establish calibration and maintenance procedures for test equipment
* Train quality personnel on inspection and testing procedures
**4. Success Criteria**
* All manufacturing processes demonstrate capability (Cpk ≥ 1.33)
* First production units pass all design verification tests
* Manufacturing personnel demonstrate competency on all procedures
* Quality system demonstrates effective control of manufacturing processes
* Cost and cycle time targets achieved
**5. Risk Mitigation**
* Parallel manufacturing setup at backup facility
* Extended overlap period with design team support
* Comprehensive documentation and knowledge transfer sessions
* Regular progress reviews and issue escalation procedures
## Q\&A
Design transfer planning should begin during the design development phase, well before design validation is complete. Early planning allows for identification of manufacturing requirements, resource needs, and potential challenges. The plan should be finalized before design validation completion to ensure smooth transition to manufacturing.
All design outputs must be transferred including specifications, drawings, software, test procedures, acceptance criteria, and risk management documentation. Manufacturing-specific documentation such as work instructions, quality procedures, and training materials must also be developed and transferred. The goal is complete transfer of design intent to manufacturing.
Design transfer verification involves confirming that manufacturing processes produce devices conforming to design specifications. This includes first article inspection, process capability studies, comparative testing with development units, and confirmation that all design verification results are maintained. Statistical evidence of process capability is typically required.
Manufacturing validation is a key component of design transfer that demonstrates manufacturing processes consistently produce conforming devices. Validation activities should be planned as part of design transfer and executed before commercial production begins. Validation results provide evidence that design transfer was successful.
Design changes during transfer should be managed through formal change control procedures. Changes must be evaluated for impact on manufacturing processes, validation activities, and regulatory compliance. Significant changes may require re-validation or additional transfer activities. The goal is to minimize changes during transfer through thorough design completion before transfer begins.
Manufacturing personnel must be trained on all procedures, specifications, and quality requirements related to the transferred design. Training should include technical aspects of the device, manufacturing processes, quality control procedures, and regulatory requirements. Competency must be demonstrated and documented before personnel can perform manufacturing operations independently.
# Design Transfer Report
Source: https://docs.withdovetail.com/tasks/design-transfer-report
Document successful design transfer completion proving manufacturing capability and regulatory readiness.
## Summary
A Design Transfer Report documents the completion and results of design transfer activities, providing evidence that your medical device design has been successfully transferred from development to manufacturing. This report demonstrates that manufacturing processes can consistently produce devices conforming to validated design specifications and regulatory requirements.
## Why is Design Transfer Report important?
The Design Transfer Report serves as critical documentation proving that your manufacturing process accurately reflects the validated design and can consistently produce compliant medical devices. Regulatory authorities require this evidence to verify that design controls were properly maintained during the transition to manufacturing. Without a comprehensive transfer report, you cannot demonstrate that manufactured devices will perform as intended or meet the safety and effectiveness requirements established during design validation.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design transfer documentation is **required** under Section 820.30(h)
* Must provide **objective evidence** that design outputs were correctly translated
* Transfer results must be **documented and verified** before commercial distribution
* Required for **Design History File** completeness (820.30)
* Must demonstrate **manufacturing capability** to produce conforming devices
**Special attention required for:**
* Complete verification of manufacturing process capability
* Documentation of all transfer verification activities
* Evidence of personnel training and qualification completion
* Integration with overall design control documentation
Under **EU MDR 2017/745**:
* Transfer documentation must be part of **technical documentation** (Annex II, Section 3)
* Must demonstrate compliance with **EN ISO 13485:2016** design transfer requirements
* Reports must be available for **notified body assessment**
* Must support **declaration of conformity** for manufacturing processes
**Special attention required for:**
* Risk management integration throughout transfer verification
* Post-market surveillance system readiness documentation
* Traceability system implementation verification
* Quality management system effectiveness demonstration
## Guide
Your Design Transfer Report should comprehensively document the execution and results of design transfer activities, demonstrating successful transition from design to manufacturing.
### Executive Summary and Transfer Overview
**Transfer Objectives Achievement**: Summarize how well the design transfer met its stated objectives including quality targets, timeline adherence, and success criteria fulfillment. Provide a clear assessment of transfer success and readiness for commercial manufacturing.
**Scope Completion**: Document the complete scope of design transfer activities including all design outputs transferred, manufacturing processes established, and quality systems implemented. Confirm that all planned transfer activities were completed successfully.
**Key Accomplishments**: Highlight major achievements during design transfer including process capability demonstrations, personnel qualifications, and system implementations. Emphasize critical milestones that support manufacturing readiness.
### Transfer Activity Results Documentation
**Manufacturing Setup Results**: Document the results of manufacturing facility preparation, equipment installation and qualification, and infrastructure setup. Include evidence that manufacturing capabilities meet design requirements and regulatory standards.
**Process Development Outcomes**: Report the results of manufacturing process development including process optimization, capability studies, and control system implementation. Demonstrate that processes are capable of consistently producing conforming devices.
**Personnel Training and Qualification**: Document completion of all personnel training and qualification activities including competency assessments, certification records, and ongoing training plans. Confirm that manufacturing personnel are qualified to perform their assigned functions.
### Verification and Validation Results
**Transfer Verification Evidence**: Present comprehensive results of design transfer verification activities including first article inspection results, process capability studies, and comparative testing with development units. Demonstrate that manufacturing processes produce devices conforming to design specifications.
**Manufacturing Validation Summary**: Summarize manufacturing validation results including process capability indices, statistical control evidence, and acceptance criteria achievement. Reference detailed validation reports and confirm manufacturing readiness.
**Design Verification Maintenance**: Document confirmation that manufacturing processes maintain all design verification results including performance, safety, and regulatory compliance verification. Demonstrate continuity between design validation and manufacturing capability.
### Quality System Implementation
**Quality Control System**: Document implementation of quality control procedures including inspection requirements, test procedures, statistical process control, and corrective action systems. Demonstrate effective quality oversight of manufacturing operations.
**Documentation and Records**: Confirm implementation of documentation control systems including manufacturing procedures, work instructions, batch records, and quality records. Demonstrate traceability and control of manufacturing documentation.
**Change Control Integration**: Document integration of manufacturing processes with change control procedures including change evaluation criteria, approval processes, and impact assessment procedures. Establish clear boundaries for manufacturing changes.
### Risk Management and Compliance
**Risk Control Implementation**: Document implementation of risk controls in manufacturing processes including design controls, process controls, and quality controls. Demonstrate that manufacturing maintains risk control effectiveness established during design.
**Regulatory Compliance Verification**: Confirm that manufacturing processes comply with applicable regulatory requirements including quality system regulations, device-specific standards, and labeling requirements. Document compliance verification activities and results.
**Post-Market Surveillance Readiness**: Document manufacturing system readiness to support post-market surveillance activities including complaint handling, adverse event reporting, and corrective action implementation. Establish clear interfaces between manufacturing and post-market activities.
## Example
### Scenario
You have completed design transfer for your mobile cardiac monitoring application to your software development and distribution partner. The transfer included establishing automated build processes, quality control procedures, and distribution systems. You need to document the transfer results and confirm readiness for commercial software manufacturing.
### Design Transfer Report
**1. Executive Summary**
This report documents the successful completion of design transfer for the CardioMonitor mobile application (Version 2.1.0) to CloudTech Software Solutions. All transfer objectives were achieved, and the manufacturing process is ready for commercial production. Transfer activities were completed on schedule with all acceptance criteria met.
**2. Transfer Scope and Completion**
The design transfer encompassed:
* Automated software build and compilation system establishment
* Quality assurance and testing procedure implementation
* Digital signing and security control setup
* Distribution and deployment system configuration
* Personnel training and qualification completion
All planned activities were completed successfully with documented evidence of compliance with design specifications and regulatory requirements.
**3. Manufacturing Process Verification Results**
*Build Process Capability:*
* Process capability index (Cpk): 4.57 (target: ≥ 1.33)
* Build success rate: 100% over 15 verification builds
* Average build time: 24.1 minutes (specification: ≤ 30 minutes)
* Automated test pass rate: 100% (1,247 tests per build)
*Quality Control Implementation:*
* All quality control procedures implemented and verified
* Statistical process control system operational
* Automated quality gates functioning correctly
* Non-conformance handling procedures established
*Security Control Verification:*
* Digital signing process validated with 100% success rate
* Certificate management procedures implemented
* Cybersecurity controls verified and operational
* Data protection measures confirmed compliant
**4. Personnel Qualification Results**
All manufacturing personnel completed required training and demonstrated competency:
* Software build engineers: 3 personnel qualified
* Quality assurance specialists: 2 personnel qualified
* Release management team: 2 personnel qualified
* Cybersecurity specialist: 1 personnel qualified
Competency assessments documented 100% pass rate with all personnel demonstrating proficiency in assigned responsibilities.
**5. First Article Verification**
Three first article software builds were produced and verified:
* All builds passed complete verification testing
* Functional performance matched design validation results
* Security controls operated as specified
* Distribution packages met all quality requirements
* User interface and functionality identical to validated design
**6. Risk Control Implementation**
All design risk controls successfully implemented in manufacturing:
* Automated testing prevents release of defective software
* Digital signing ensures software integrity and authenticity
* Version control prevents unauthorized software modifications
* Access controls limit manufacturing system access to qualified personnel
**7. Regulatory Compliance Confirmation**
Manufacturing processes comply with all applicable requirements:
* FDA 21 CFR Part 820 design control requirements
* EU MDR quality management system requirements
* Cybersecurity framework implementation
* Software lifecycle process compliance
**8. Commercial Manufacturing Authorization**
Based on successful completion of all design transfer activities and achievement of all acceptance criteria, the CardioMonitor software manufacturing process is authorized for commercial production effective immediately. Ongoing monitoring and periodic review procedures are established to maintain manufacturing capability.
## Q\&A
A design transfer report must include objective evidence that all design outputs were correctly transferred to manufacturing, manufacturing processes are capable of producing conforming devices, personnel are qualified, and quality systems are operational. This includes verification test results, process capability data, training records, and compliance confirmation documentation.
Design transfer reports should be reviewed by representatives from design, manufacturing, quality assurance, and regulatory affairs. Final approval should be by personnel with authority to authorize commercial manufacturing. For software devices, this typically includes software quality assurance and regulatory affairs personnel.
Manufacturing process capability is demonstrated through statistical analysis of process performance data including process capability indices (Cp, Cpk), first article inspection results, and comparative testing with design validation units. The report should show that manufacturing processes consistently produce devices meeting design specifications.
If design transfer verification fails, the issues must be investigated, root causes identified, and corrective actions implemented. Additional verification activities may be required after corrective actions. Commercial manufacturing cannot begin until all transfer verification activities are successfully completed and documented.
Design transfer and manufacturing validation are complementary activities. Design transfer focuses on correctly translating design outputs to manufacturing, while manufacturing validation demonstrates process consistency and capability. Both must be successfully completed before commercial manufacturing can begin.
After successful design transfer, ongoing activities include manufacturing process monitoring, periodic capability studies, personnel requalification, and change control management. Any significant changes to manufacturing processes may require partial re-transfer or additional verification activities.
# Device Label
Source: https://docs.withdovetail.com/tasks/device-label
Create regulatory-compliant device identification displaying required safety and regulatory markings.
## Summary
The Device Label is a regulatory-compliant information display that contains all required identification, safety, and regulatory information for your medical device software. This label must be accessible within your software interface and includes essential elements like CE marking, UDI information, manufacturer details, and safety warnings required for market access and regulatory compliance.
## Why is Device Label important?
Device labeling is **legally mandated** for all medical devices and serves as the primary source of identification and safety information for users and regulatory authorities. The label ensures **traceability** throughout the device lifecycle and provides critical information that healthcare providers need to use your device safely and effectively. For software medical devices, the label must be electronically accessible and contain all the same regulatory information required for physical devices, demonstrating compliance with labeling regulations and enabling proper device identification in clinical settings.
## Regulatory Context
Under **21 CFR Part 801** (Labeling):
* **Device identification** (801.1) requires clear device identification and manufacturer information
* **Labeling requirements** (801.15) mandate specific information display
* **Software labeling** guidance requires electronic accessibility of label information
* **UDI requirements** (801 Subpart B) mandate unique device identification
**Special attention required for:**
* Software version identification and traceability requirements
* Electronic labeling accessibility for software-only devices
* Prescription device labeling requirements (Rx only designation)
* Integration with FDA Establishment Registration and Device Listing
Under **EU MDR 2017/745**:
* **GSPR 23** requires comprehensive device labeling information
* **Article 20** mandates CE marking for conformity assessment
* **Article 27** requires UDI system compliance and display
* **Annex I Chapter III** specifies detailed labeling requirements
**Special attention required for:**
* CE marking validity and notified body identification when required
* UDI-DI and UDI-PI display requirements for software versions
* Authorized representative information for non-EU manufacturers
* Multi-language requirements for different EU markets
## Guide
### Regulatory Marking Requirements
Your device label must display the **CE marking** prominently to indicate conformity with EU MDR requirements. The CE marking must be visible, legible, and indelible, which for software means it should be permanently accessible within the user interface. Include the medical device symbol to clearly identify your software as a medical device, helping users understand the regulatory status and intended medical purpose.
### Device Identification Information
Clearly display your **device name** exactly as specified in your technical documentation and regulatory submissions. Include the complete manufacturer name and address as registered with regulatory authorities. This information enables proper identification and contact for regulatory, safety, or support purposes. Ensure consistency between your label information and all other regulatory documentation.
### UDI System Compliance
Display both the **UDI-DI (Device Identifier)** and **UDI-PI (Production Identifier)** with appropriate symbols. The UDI-DI identifies your device model while the UDI-PI identifies the specific software version and release date. Format the UDI-PI according to established standards with proper identifiers for software version and release date. This enables complete traceability throughout the device lifecycle.
### Version and Release Information
Include the **software version number** and release date prominently on your device label. Use the version numbering scheme established in your Software Development and Maintenance Plan to ensure consistency across all documentation. The release date should match the date when the software version was made available to users, providing clear temporal identification for regulatory and support purposes.
### Instructions for Use Reference
Provide clear information about where users can access the **Instructions for Use (IFU)**. For software devices, this typically includes a web URL or electronic location where the complete IFU can be accessed. Use the appropriate symbol to indicate electronic instructions for use, helping users understand how to access complete usage information.
### Authorized Representative Information
If you are a non-EU manufacturer, include **authorized representative** information as required by MDR Article 11. Display the authorized representative symbol along with contact information for your EU-based representative. This enables EU authorities and users to contact a local representative for regulatory and safety matters.
### Safety Information Integration
Include appropriate **warnings and precautions** references on your device label. While the complete safety information is typically in your Instructions for Use, the label should direct users to review all warnings and precautions before use. This ensures users are aware of important safety considerations and know where to find complete safety information.
### Electronic Accessibility Requirements
For software medical devices, ensure your device label is **easily accessible** within the software interface. Consider placing it in an "About" section, settings menu, or help section where users can readily find it. The label should be accessible without requiring special permissions or administrative access, ensuring all users can view the regulatory information when needed.
## Example
### Scenario
You are creating a device label for your AI-powered diagnostic imaging software version 4.1.2 that analyzes chest X-rays and provides diagnostic recommendations to radiologists. The software is classified as Class IIa under EU MDR and is manufactured by MedTech Innovations Inc. based in California, with an authorized representative in Germany.
### Example Device Label
![CE Mark Symbol]()
*This product is a Class IIa medical device according to EU MDR 2017/745.*
![Medical Device Symbol]()
**ChestScan AI Pro**
![UDI Symbol]()
**(01)04012345678901(11)240315(10)4.1.2**
![Manufacturer Symbol]()
**MedTech Innovations Inc.**
1234 Innovation Drive, Suite 100
San Francisco, CA 94105, USA
![Date of Manufacture Symbol]()
Software released on March 15, 2024
![Software Version Symbol]()
Software version 4.1.2
![eIFU Symbol]()
Instructions available for use at [https://www.medtechinnovations.com/chestscan-ifu](https://www.medtechinnovations.com/chestscan-ifu)
![AU Rep Symbol]()
**European Authorized Representative:**
MedDevice Regulatory Services GmbH
Regulatory Affairs Department
Hauptstraße 123, 10115 Berlin, Germany
Tel: +49 30 12345678
Email: [regulatory@meddevice-services.de](mailto:regulatory@meddevice-services.de)
**Warnings and Precautions:**
Please refer to the instructions for use for a full listing of warnings and precautions.
## Q\&A
Place the device label in an easily accessible location such as an "About" section, settings menu, or help area. It should be available to all users without requiring special permissions and should be clearly labeled so users can find it when needed for regulatory or support purposes.
Update the device label for each software release to reflect the new version number, release date, and UDI-PI. Ensure the label information matches your updated release documentation and maintain consistency across all regulatory documents.
If you are an EU-based manufacturer, you don't need an authorized representative. If you are a non-EU manufacturer without an authorized representative, you cannot legally market your device in the EU under MDR. You must appoint an authorized representative before market access.
Use the complete legal manufacturer name and address as registered with regulatory authorities. Abbreviations may cause confusion and regulatory compliance issues. Ensure the information exactly matches your regulatory registrations and other official documentation.
For EU markets, the device label may need to be available in local languages depending on national requirements. Check specific country requirements and consider providing language selection options within your software interface for the device label display.
Update your device label immediately to reflect any UDI changes. Ensure the updated label is included in your software before release and verify that all regulatory databases are updated with the new UDI information to maintain proper traceability.
# Electrical Design
Source: https://docs.withdovetail.com/tasks/electrical-design
Specify electronic components, circuits and electrical safety measures for reliable device performance.
## Summary
The Electrical Design document defines the electronic components, circuits, and electrical specifications of your medical device. This document covers component selection, circuit schematics, PCB layouts, power requirements, and electrical safety measures essential for safe and reliable device operation.
## Why is Electrical Design important?
Electrical design documentation is **critical for patient safety** because electrical components can pose risks of shock, fire, or electromagnetic interference that directly affect patient care. Poor electrical design can lead to **device malfunction**, **safety hazards**, or **electromagnetic compatibility issues** that compromise device performance. Regulatory authorities require detailed electrical specifications to ensure devices meet safety standards and perform reliably in medical environments.
The electrical design also demonstrates that you have systematically considered **electrical safety**, **power management**, and **electromagnetic compatibility**. This documentation supports **risk management**, **safety testing**, and **verification activities** throughout the development process.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **IEC 60601 Part 1** (Medical Electrical Equipment):
* Electrical specifications must be **documented** as design inputs
* **Electrical safety** requirements per IEC 60601 Part 1 series standards
* **Electromagnetic compatibility** per IEC 60601 Part 1-2
* **Risk management** for electrical hazards per ISO 14971
**Special attention required for:**
* Electrical safety testing (leakage current, dielectric strength, grounding)
* EMC testing for electromagnetic compatibility
* Power supply safety and efficiency requirements
* Cybersecurity considerations for connected devices
Under **EU MDR 2017/745** and **General Safety and Performance Requirements**:
* Electrical design must comply with **Essential Requirements** Annex I
* **Electrical safety** per IEC 60601 Part 1 and harmonized standards
* **EMC compliance** per IEC 60601 Part 1-2 for medical environments
* **Risk management** for electrical hazards per EN ISO 14971
**Special attention required for:**
* CE marking requirements for electrical safety and EMC
* Harmonized standards compliance (IEC 60601 series)
* Electrical safety documentation for notified body review
* Energy efficiency requirements where applicable
## Guide
### Understanding Electrical Design
Electrical design encompasses **all electronic aspects** of your medical device that handle power, signals, or data processing. This includes:
* **Power Systems**: Batteries, power supplies, charging circuits, and power management
* **Signal Processing**: Amplifiers, filters, analog-to-digital converters, and sensors
* **Control Circuits**: Microcontrollers, processors, memory, and control logic
* **Communication Interfaces**: Wireless modules, USB, Ethernet, and data transmission
* **Safety Circuits**: Isolation, protection, monitoring, and fail-safe mechanisms
### Component Selection and Specifications
Document each electrical component systematically:
* **Component List**: Identify all electrical parts with manufacturer part numbers
* **Electrical Specifications**: Voltage, current, power, frequency, and tolerance requirements
* **Environmental Ratings**: Operating temperature, humidity, and vibration specifications
* **Safety Certifications**: UL, CE, or other safety approvals for critical components
* **Supply Chain Information**: Primary and backup suppliers for critical components
### Circuit Design and Schematics
Your electrical design documentation should include:
* **System Block Diagrams**: High-level functional blocks and signal flow
* **Detailed Schematics**: Complete circuit diagrams with component values
* **Power Distribution**: Power supply design and distribution networks
* **Signal Integrity**: Impedance control, noise reduction, and signal routing
* **Protection Circuits**: Overcurrent, overvoltage, and ESD protection
### PCB Layout and Assembly
Document the physical implementation:
* **PCB Stack-up**: Layer count, thickness, and material specifications
* **Component Placement**: Critical component positioning and thermal considerations
* **Routing Guidelines**: Trace width, spacing, and impedance requirements
* **Manufacturing Specifications**: Drill sizes, solder mask, and silkscreen requirements
* **Assembly Instructions**: Pick-and-place files and soldering specifications
### Electrical Safety Requirements
Your electrical design must address:
* **Isolation Requirements**: Patient isolation per IEC 60601 Part 1 standards
* **Leakage Current**: Limits for patient and earth leakage currents
* **Protective Earth**: Grounding and bonding requirements for safety
* **Fault Conditions**: Single fault safety and redundancy requirements
* **Environmental Protection**: Ingress protection (IP) ratings for enclosures
### Electromagnetic Compatibility (EMC)
Design for EMC compliance:
* **Emission Control**: Limiting electromagnetic emissions per CISPR standards
* **Immunity Requirements**: Resistance to electromagnetic interference
* **Shielding Design**: Enclosure shielding and cable shielding requirements
* **Filtering**: Power line filters and signal filters for noise reduction
* **Layout Considerations**: PCB layout techniques for EMC compliance
## Example
**Scenario**: You're developing a wearable heart rate monitor that continuously measures ECG signals and transmits data wirelessly to a smartphone app. Your electrical design must ensure patient safety, signal accuracy, and reliable wireless communication.
### Electrical Component Specifications
| Component | Part Number | Manufacturer | Specifications | Function |
| ------------------ | ------------ | -------------------- | --------------------------------------- | -------------------------------------------- |
| ECG AFE | ADS1293 | Texas Instruments | 3-channel, 24-bit ADC, 125 SPS | ECG signal acquisition |
| Microcontroller | nRF52840 | Nordic Semiconductor | ARM Cortex-M4, Bluetooth 5.0, 1MB Flash | Signal processing and wireless communication |
| Battery | ICR18650-26F | Samsung SDI | 3.7V, 2600mAh, Li-ion | Power supply |
| Charging IC | BQ24040 | Texas Instruments | 1A, USB charging, thermal regulation | Battery charging management |
| Accelerometer | LSM6DS3 | STMicroelectronics | 3-axis, +/-16g, I2C interface | Motion detection and artifact removal |
| Crystal Oscillator | FC-135 | Epson | 32.768 kHz, +/-20 ppm | Real-time clock reference |
### Circuit Design Specifications
**Power Supply Design**: 3.7V Li-ion battery with 3.3V and 1.8V regulated outputs using low-dropout regulators. Power consumption optimized for 7-day battery life with continuous monitoring.
**ECG Signal Chain**: Differential input with 40dB gain, 0.5-100 Hz bandpass filtering, and right-leg drive for common-mode rejection. Input impedance >10 GOhm to minimize electrode artifacts.
**Wireless Communication**: Bluetooth Low Energy 5.0 with -20 dBm to +8 dBm transmit power. Antenna design optimized for body-worn applications with SAR compliance.
### Electrical Safety Implementation
**Patient Isolation**: Reinforced isolation between patient-connected ECG inputs and all other circuits per IEC 60601 Part 1. Isolation barrier rated for 4000V AC.
**Leakage Current**: Patient leakage current \<10 microA under normal conditions and \<50 microA under single fault conditions. Earth leakage current \<500 microA.
**Protection Circuits**: ESD protection on all patient-connected inputs rated for +/-15 kV air discharge. Overcurrent protection on battery charging circuit.
### PCB Design Requirements
**4-Layer PCB Stack-up**: Signal/Ground/Power/Signal with 1.6mm total thickness. FR-4 material with controlled impedance for high-speed signals.
**Component Placement**: ECG analog front-end isolated from digital switching circuits. Crystal oscillator placed close to microcontroller with guard traces.
**EMC Considerations**: Continuous ground plane, proper via stitching, and ferrite beads on power supplies. Bluetooth antenna keepout zones maintained.
### Testing and Verification
**Electrical Safety Testing**: IEC 60601 Part 1 compliance testing including leakage current, dielectric strength, and protective earth resistance.
**EMC Testing**: IEC 60601 Part 1-2 compliance for emissions and immunity in medical environments.
**Performance Testing**: ECG signal accuracy verification, wireless range testing, and battery life validation under various usage scenarios.
## Q\&A
Include enough detail for engineers to implement the circuits and for verification teams to test them. Specify component part numbers, electrical ratings, circuit topologies, and performance requirements. Document both normal operating conditions and fault conditions. Include power consumption, signal integrity, and timing requirements.
Follow IEC 60601 Part 1 standards for medical electrical equipment. Implement proper patient isolation, limit leakage currents, provide protective earth connections, and design for single fault safety. Use safety-certified components where required and plan for comprehensive electrical safety testing by accredited laboratories.
Design for both emissions control and immunity to interference. Use proper grounding, shielding, and filtering techniques. Consider the medical environment with other electronic equipment nearby. Follow IEC 60601 Part 1-2 for medical EMC requirements. Plan PCB layout carefully with continuous ground planes and proper signal routing.
Provide complete PCB specifications including layer stack-up, material requirements, trace width and spacing rules, via specifications, and component placement guidelines. Include manufacturing files (Gerber, drill, pick-and-place) and assembly drawings. Document any special requirements for impedance control or thermal management.
Consider patient safety, efficiency, and reliability. Use medical-grade power supplies or design isolated supplies per IEC 60601 Part 1. Plan for battery backup where required. Consider power consumption for portable devices and thermal management for high-power applications. Document power sequencing and protection requirements.
Ensure compliance with medical device wireless standards and regional regulations (FCC, CE). Consider coexistence with other medical devices and hospital equipment. Implement proper antenna design and SAR compliance for body-worn devices. Document wireless performance requirements and interference mitigation strategies.
# Electrical Verification Protocol
Source: https://docs.withdovetail.com/tasks/electrical-verification-protocol
Execute systematic electrical safety testing ensuring IEC 60601 compliance and patient protection.
## Summary
The Electrical Verification Protocol establishes **systematic procedures** for testing the electrical safety and performance of your medical device to ensure compliance with applicable electrical safety standards. This protocol verifies that electrical components meet design specifications and operate safely under normal and fault conditions.
## Why is Electrical Verification important?
Electrical verification is critical because electrical hazards in medical devices can cause **immediate harm to patients and users** through electric shock, burns, or fire. Unlike other device failures that may develop gradually, electrical failures can cause instantaneous injury or death, making rigorous electrical testing essential for patient safety.
This verification demonstrates **compliance with mandatory electrical safety standards** like IEC 60601, which are required for regulatory approval in most markets. Proper electrical verification also validates your electrical design decisions, ensures manufacturing consistency, and provides evidence that electrical risk controls are effective.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **FDA Recognition of IEC 60601**:
* **IEC 60601-1** General requirements for basic safety and essential performance
* **IEC 60601-1-2** Electromagnetic disturbances requirements and tests
* **IEC 60601-1-6** Usability engineering for medical electrical equipment
* **Device-specific standards** (IEC 60601-2-X series) for particular equipment types
**Special attention required for:**
* Home healthcare devices requiring additional safety considerations
* Devices with wireless connectivity requiring EMC compliance
* Battery-powered devices requiring power system verification
* Devices with patient-applied parts requiring leakage current testing
Under **EU MDR 2017/745** and **harmonized standards**:
* **EN 60601-1** harmonized under MDR for electrical safety
* **EN 60601-1-2** for electromagnetic compatibility requirements
* **Essential Requirements** Annex I requires electrical safety demonstration
* **Notified body assessment** of electrical verification completeness
**Special attention required for:**
* CE marking requirements for electrical safety compliance
* Declaration of conformity including electrical safety standards
* Post-market surveillance of electrical safety performance
* Clinical evaluation integration for electrically-powered therapeutic devices
## Guide
### Understanding IEC 60601 Requirements
**IEC 60601-1** forms the foundation for medical electrical equipment safety by establishing requirements for basic safety and essential performance. The standard addresses protection against electrical shock, mechanical hazards, fire, and other risks associated with medical electrical equipment.
**Applied parts classification** determines the level of electrical safety required. Type B applied parts have basic protection, Type BF parts are floating (isolated from earth), and Type CF parts provide the highest protection for direct cardiac contact. Your classification drives specific testing requirements and acceptance criteria.
**Essential performance** must be maintained even during single fault conditions. Define what functions are essential for patient safety and verify that these functions continue operating or fail safely when electrical faults occur.
### Planning Your Electrical Test Strategy
**Risk-based testing approach** should prioritize electrical hazards identified in your risk analysis. Focus testing on areas where electrical failures could cause the most harm, such as patient contact points, power systems, and safety-critical circuits.
**Test sequence planning** should follow a logical progression from basic safety tests to more complex performance verification. Start with insulation resistance and dielectric strength testing before proceeding to leakage current and EMC testing.
**Sample preparation** must represent your final commercial configuration including all electrical connections, enclosures, and accessories. Test samples should be manufactured using validated processes and include any electrical modifications made during development.
### Electrical Safety Testing Requirements
**Insulation resistance testing** verifies that electrical insulation provides adequate protection against electric shock. Test all insulation barriers including basic insulation, supplementary insulation, and reinforced insulation according to IEC 60601-1 requirements.
**Dielectric strength testing** applies high voltage to insulation systems to verify they can withstand electrical stress without breakdown. This testing validates insulation design margins and manufacturing quality.
**Leakage current testing** measures unwanted electrical current that could flow through patients or users. Test earth leakage current, enclosure leakage current, and patient leakage current under normal and single fault conditions.
**Protective earth testing** verifies the integrity of safety earth connections that protect against electric shock. Test earth bond resistance and earth continuity to ensure protective earth systems function properly.
### Electromagnetic Compatibility Testing
**EMC testing per IEC 60601-1-2** ensures your device doesn't interfere with other equipment and operates correctly in electromagnetic environments. This includes both emissions testing (what your device puts out) and immunity testing (how your device responds to external interference).
**Emissions testing** measures electromagnetic energy radiated or conducted by your device to ensure it doesn't interfere with other medical devices or communication systems. Test both radiated and conducted emissions across required frequency ranges.
**Immunity testing** verifies your device continues to operate correctly when exposed to electromagnetic disturbances like electrostatic discharge, radiated fields, electrical fast transients, and power line disturbances.
### Performance and Functional Testing
**Essential performance verification** ensures that safety-critical functions operate correctly under normal and fault conditions. Test all functions that could affect patient safety if they fail or perform incorrectly.
**Accuracy testing** verifies that electrical measurements or outputs meet specified tolerances. This includes testing of sensors, displays, alarms, and any therapeutic outputs under various operating conditions.
**Environmental testing** validates electrical performance across specified temperature, humidity, and altitude ranges. Include testing at environmental extremes to verify performance margins.
### Documentation and Acceptance Criteria
**Test procedures** must be detailed enough to ensure reproducible results and include specific test equipment requirements, test setups, and measurement procedures. Reference applicable standards and specify any deviations or additional requirements.
**Acceptance criteria** should be based on applicable standards with appropriate safety margins. Consider both absolute limits (e.g., leakage current \<10 μA) and relative performance requirements (e.g., accuracy within ±5%).
**Test records** must document all test conditions, measurements, calculations, and pass/fail determinations. Include environmental conditions, test equipment calibration status, and any deviations from planned procedures.
## Example
**Scenario**: You are developing a portable ECG monitor with wireless connectivity that patients use at home. The device has electrodes that contact the patient's skin, operates on rechargeable batteries, and transmits data via Bluetooth to a smartphone app.
Your electrical verification protocol addresses IEC 60601-1 Type BF applied parts requirements for the electrodes, battery safety testing, wireless EMC compliance, and essential performance verification for ECG signal acquisition and processing. Testing includes leakage current measurement, EMC emissions and immunity testing, and accuracy verification of ECG measurements.
### Electrical Verification Protocol
**Document ID**: EVP-001\
**Version**: 1.0
#### 1. Purpose
This protocol establishes electrical verification procedures for the CardioPortable ECG monitor to demonstrate compliance with IEC 60601-1, IEC 60601-1-2, and applicable electrical safety requirements.
#### 2. Device Description and Classification
**Device**: CardioPortable wireless ECG monitor\
**Applied Parts**: Type BF (body floating) electrodes for skin contact\
**Power Source**: Internal rechargeable lithium-ion battery\
**Environment**: Home healthcare environment\
**Connectivity**: Bluetooth wireless communication
#### 3. Applicable Standards
| Standard | Title | Applicable Sections |
| -------------- | --------------------------------------------------------------- | ------------------------------ |
| IEC 60601-1 | General requirements for basic safety and essential performance | All applicable clauses |
| IEC 60601-1-2 | Electromagnetic disturbances - Requirements and tests | All applicable clauses |
| IEC 60601-2-25 | Particular requirements for electrocardiographs | Device-specific requirements |
| IEC 62304 | Medical device software lifecycle processes | Software safety classification |
#### 4. Electrical Safety Tests
**4.1 Insulation Resistance Testing**
| Test | Requirement | Test Voltage | Acceptance Criteria |
| ------------------------ | ------------------------ | ------------ | ------------------- |
| Basic Insulation | IEC 60601-1 Clause 8.8.3 | 500V DC | ≥2 MΩ |
| Reinforced Insulation | IEC 60601-1 Clause 8.8.3 | 500V DC | ≥4 MΩ |
| Applied Parts Insulation | IEC 60601-1 Clause 8.8.3 | 500V DC | ≥10 MΩ |
**4.2 Dielectric Strength Testing**
| Test | Test Voltage | Duration | Acceptance Criteria |
| --------------------- | ------------ | ---------- | ------------------------- |
| Basic Insulation | 1500V AC | 60 seconds | No breakdown or flashover |
| Reinforced Insulation | 3000V AC | 60 seconds | No breakdown or flashover |
| Applied Parts | 1500V AC | 60 seconds | No breakdown or flashover |
**4.3 Leakage Current Testing**
| Leakage Current Type | Normal Condition | Single Fault Condition | Acceptance Criteria |
| ------------------------- | ---------------- | ---------------------- | ------------------- |
| Earth Leakage | \<500 μA | \<1000 μA | IEC 60601-1 Table 3 |
| Enclosure Leakage | \<100 μA | \<500 μA | IEC 60601-1 Table 3 |
| Patient Leakage (Type BF) | \<100 μA | \<500 μA | IEC 60601-1 Table 3 |
#### 5. Electromagnetic Compatibility Tests
**5.1 Emissions Testing**
| Test | Standard | Frequency Range | Acceptance Criteria |
| ------------------- | -------- | ---------------- | ---------------------- |
| Radiated Emissions | CISPR 11 | 30 MHz - 1 GHz | Group 1 Class B limits |
| Conducted Emissions | CISPR 11 | 150 kHz - 30 MHz | Group 1 Class B limits |
**5.2 Immunity Testing**
| Test | Standard | Test Level | Acceptance Criteria |
| -------------------------- | ------------- | ------------------------- | --------------------------------------------- |
| Electrostatic Discharge | IEC 61000-4-2 | ±8 kV contact, ±15 kV air | Criterion B: Temporary degradation acceptable |
| Radiated Immunity | IEC 61000-4-3 | 10 V/m, 80-2700 MHz | Criterion A: Normal operation maintained |
| Electrical Fast Transients | IEC 61000-4-4 | ±2 kV power, ±1 kV signal | Criterion B: Temporary degradation acceptable |
#### 6. Performance Verification Tests
**6.1 ECG Signal Accuracy**
| Parameter | Requirement | Test Method | Acceptance Criteria |
| --------------------- | ------------------- | ---------------------------- | ----------------------------- |
| Amplitude Accuracy | ±5% or ±50 μV | Calibrated signal generator | Within specified tolerance |
| Frequency Response | 0.05-150 Hz (±3 dB) | Swept frequency testing | Meet frequency response curve |
| Common Mode Rejection | >80 dB | Common mode signal injection | >80 dB rejection ratio |
**6.2 Battery Performance**
| Test | Requirement | Test Method | Acceptance Criteria |
| ------------------- | ----------------------- | ------------------------- | ----------------------- |
| Operating Time | ≥24 hours continuous | Continuous operation test | Meet specified duration |
| Charging Safety | No overcharge hazard | Charge cycle testing | Safe charging behavior |
| Low Battery Warning | Warning at 10% capacity | Battery discharge test | Timely warning provided |
#### 7. Test Environment and Equipment
**Environmental Conditions**: 23°C ± 2°C, 45-75% RH, 86-106 kPa\
**Test Equipment**: Calibrated electrical safety analyzer, EMC test chamber, signal generators\
**Sample Size**: 3 units minimum for each test category\
**Test Sequence**: Safety tests first, followed by EMC, then performance tests
#### 8. Pass/Fail Criteria
**Pass Criteria**: All electrical safety tests meet IEC 60601-1 requirements, EMC tests meet IEC 60601-1-2 requirements, performance tests meet design specifications\
**Fail Criteria**: Any safety test failure, EMC non-compliance, or performance outside specifications\
**Deviation Handling**: All test failures must be investigated and resolved before device release
## Q\&A
The primary standard is IEC 60601-1 for general electrical safety requirements. Additionally, IEC 60601-1-2 applies for electromagnetic compatibility, and device-specific standards (IEC 60601-2-X series) may apply based on your device type. For home healthcare devices, consider IEC 60601-1-11. Battery-powered devices may need additional battery safety standards. Check with regulatory agencies for specific requirements in your target markets.
Applied parts classification depends on the type and duration of patient contact. Type B provides basic protection for external contact, Type BF (body floating) provides isolation from earth for prolonged contact, and Type CF (cardiac floating) provides the highest protection for direct cardiac contact. Consider the contact location, duration, and potential for current pathways through the patient when determining classification.
Basic insulation provides fundamental protection against electric shock under normal conditions. Supplementary insulation is additional insulation applied independently of basic insulation for protection under single fault conditions. Reinforced insulation is a single insulation system that provides protection equivalent to basic plus supplementary insulation. Each type has different testing requirements and acceptance criteria.
Wireless devices require additional EMC considerations including intentional radiator testing, coexistence with other wireless devices, and immunity to wireless interference. Test both the wireless function and medical device function separately and together. Consider frequency coordination, power levels, and antenna characteristics. Some regions have specific requirements for medical wireless devices that go beyond general EMC standards.
First, verify the test setup and procedures to ensure the failure is real. Investigate the root cause - is it a design issue, manufacturing problem, or test method issue? For safety-critical failures, stop testing and address the issue before continuing. Document the failure, implement corrective actions, and retest. Some failures may require design changes, while others might be resolved through manufacturing process improvements.
Essential performance includes functions that, if lost or degraded, could result in unacceptable risk. Define these functions based on your intended use and risk analysis. Test essential performance under normal conditions and during single fault conditions like power supply interruption, component failures, or electromagnetic disturbances. Verify that essential performance is maintained or the device fails safely with appropriate alarms.
# Electrical Verification Report
Source: https://docs.withdovetail.com/tasks/electrical-verification-report
Document electrical safety testing results proving IEC compliance and hazard protection.
## Summary
The Electrical Verification Report documents the **electrical safety testing** and verification activities that demonstrate your medical device meets electrical safety standards and requirements. This report provides evidence that your device operates safely under normal and fault conditions, protecting patients and users from electrical hazards.
## Why is Electrical Verification Reporting important?
Electrical verification is **mandatory for medical devices** with electrical components, as electrical hazards can cause serious injury or death through electric shock, burns, or fire. The verification report demonstrates that you have systematically tested electrical safety and verified compliance with applicable electrical safety standards.
This documentation is **essential for regulatory approval** as it provides objective evidence that your device meets electrical safety requirements. Without proper electrical verification, you cannot demonstrate that your device is safe for clinical use, and regulatory authorities will not approve electrically powered medical devices.
## Regulatory Context
Under **21 CFR Part 820.30(g)** (Design Validation) and **FDA Recognition of IEC 60601-1**:
* **IEC 60601-1** (Medical electrical equipment - General requirements for basic safety and essential performance)
* **IEC 60601-1-2** (Electromagnetic compatibility requirements)
* **IEC 60601-1-6** (Usability engineering for medical electrical equipment)
* **510(k) submissions** must include electrical safety testing data
**Special attention required for:**
* Home healthcare devices (IEC 60601-1-11)
* Software-controlled medical devices (IEC 62304 integration)
* Wireless and networked devices (cybersecurity considerations)
* Devices with patient-applied parts (enhanced safety requirements)
Under **EU MDR 2017/745** and **EN 60601 series standards**:
* **EN 60601-1:2006+A1:2013** (General requirements for basic safety and essential performance)
* **EN 60601-1-2:2015** (Electromagnetic compatibility)
* **Essential requirements** 14 and 15 (electrical safety and EMC)
* **Notified body assessment** of electrical safety compliance required
**Special attention required for:**
* CE marking requirements for electrical safety compliance
* Post-market surveillance of electrical safety performance
* Essential requirements compliance demonstration
* Harmonized standards application and deviations documentation
## Guide
### Understanding Electrical Safety Requirements
**IEC 60601-1 compliance** is the foundation for medical electrical equipment safety. This standard addresses protection against electric shock, mechanical hazards, fire, explosion, and other risks associated with medical electrical equipment.
**Classification requirements** determine the level of protection needed based on your device's intended use. Consider type of protection against electric shock (Class I, II, or internally powered), degree of protection against ingress of water (IPX ratings), and application part classification (B, BF, or CF).
**Risk management integration** ensures that electrical safety verification addresses risks identified in your risk analysis. Electrical hazards should be systematically identified, evaluated, and controlled through design and verification.
### Planning Electrical Verification Testing
**Test planning** should identify all applicable electrical safety tests based on your device classification and intended use. Common tests include electrical safety, electromagnetic compatibility (EMC), environmental testing, and mechanical testing.
**Testing laboratory selection** requires choosing accredited laboratories with experience in medical device electrical safety testing. Ensure laboratories are familiar with IEC 60601 series standards and have appropriate test equipment.
**Test article preparation** must represent your final device configuration, including all electrical components, enclosures, cables, and accessories that will be provided to end users.
### Conducting Electrical Safety Testing
**Basic safety testing** verifies protection against electric shock, including insulation resistance, dielectric strength, leakage current, and protective earth resistance measurements.
**Essential performance testing** verifies that your device continues to perform its intended function even when electrical safety measures are applied or when subjected to electromagnetic disturbances.
**Environmental testing** validates electrical safety under various environmental conditions including temperature, humidity, altitude, and mechanical stress that your device may encounter.
### Electromagnetic Compatibility (EMC) Verification
**Emissions testing** verifies that your device does not generate electromagnetic interference that could affect other equipment. This includes conducted and radiated emissions testing.
**Immunity testing** verifies that your device continues to operate correctly when subjected to electromagnetic disturbances from other equipment or environmental sources.
**Risk management approach** for EMC considers the electromagnetic environment where your device will be used and ensures appropriate immunity levels for that environment.
### Documenting Test Results
**Test reports** should provide complete documentation of test methods, test setup, test results, and pass/fail determinations for each electrical safety requirement.
**Deviation documentation** must address any test failures, non-conformances, or deviations from standard test methods. Include root cause analysis and corrective actions taken.
**Compliance demonstration** should clearly show how test results demonstrate compliance with applicable electrical safety standards and requirements.
### Addressing Non-Conformances
**Design modifications** may be required if electrical safety testing identifies safety issues. Document any changes made to address electrical safety concerns and verify that modifications resolve the issues.
**Risk assessment** should evaluate any residual electrical risks that cannot be eliminated through design changes. Consider whether additional risk controls or user warnings are needed.
**Retesting requirements** ensure that design changes don't introduce new electrical safety issues. Plan appropriate regression testing after any modifications.
## Example
**Scenario**: You are developing a portable ultrasound system with battery power, touchscreen display, and wireless connectivity. The device includes patient-applied ultrasound transducers and is intended for use in clinical and home healthcare environments.
Your electrical verification includes IEC 60601-1 basic safety testing, IEC 60601-1-2 EMC testing, and IEC 60601-1-11 home healthcare environment testing. Testing reveals compliance with all electrical safety requirements, with minor EMC immunity improvements needed for wireless communication robustness.
### Electrical Verification Report
**Document ID**: EVR-001\
**Version**: 1.0\
**Device**: PortaScan Ultrasound System Model PS-2024
#### 1. Device Description and Classification
**Device Overview**: Portable ultrasound imaging system with battery power, 10-inch touchscreen, and wireless connectivity for clinical and home use.
**Electrical Classification**:
* Protection against electric shock: Class II (double insulation)
* Degree of protection against water ingress: IPX1 (drip-proof)
* Application parts: Type BF (body floating, patient-applied transducers)
* Operating mode: Continuous operation
**Applicable Standards**:
* IEC 60601-1:2005+A1:2012 (General requirements)
* IEC 60601-1-2:2014 (EMC requirements)
* IEC 60601-1-11:2015 (Home healthcare environment)
#### 2. Test Laboratory and Accreditation
**Testing Laboratory**: MedTest Laboratories, Inc.\
**Accreditation**: ISO/IEC 17025:2017, A2LA Certificate #1234\
**Test Period**: May 15-30, 2024\
**Test Report Numbers**: MT-2024-0567 (Electrical Safety), MT-2024-0568 (EMC)
#### 3. Electrical Safety Test Results
**3.1 Protection Against Electric Shock**
* Insulation Resistance: >10 MΩ (Requirement: >2 MΩ) - PASS
* Dielectric Strength: No breakdown at 1500V AC (Requirement: 1500V) - PASS
* Patient Leakage Current: 8 μA (Requirement: \<10 μA) - PASS
* Earth Leakage Current: 45 μA (Requirement: \<500 μA) - PASS
**3.2 Mechanical Safety**
* Enclosure Integrity: No accessible sharp edges or points - PASS
* Stability: Device stable in all operating positions - PASS
* Mechanical Strength: Enclosure withstands specified forces - PASS
**3.3 Fire and Explosion Protection**
* Flammability: Materials meet V-0 rating requirements - PASS
* Temperature Rise: Maximum 35°C above ambient (Requirement: \<60°C) - PASS
#### 4. Electromagnetic Compatibility Test Results
**4.1 Emissions Testing**
* Conducted Emissions: Compliant with CISPR 11 Class B limits - PASS
* Radiated Emissions: Compliant with CISPR 11 Class B limits - PASS
**4.2 Immunity Testing**
* Electrostatic Discharge: 8kV contact, 15kV air (IEC 61000-4-2) - PASS
* Radiated RF Immunity: 10 V/m (IEC 61000-4-3) - PASS
* Electrical Fast Transients: 2kV (IEC 61000-4-4) - PASS
* Surge Immunity: 2kV (IEC 61000-4-5) - PASS
* Conducted RF Immunity: 10V (IEC 61000-4-6) - PASS
#### 5. Home Healthcare Environment Testing
**5.1 Enhanced EMC Requirements**
* Wireless Communication Immunity: Verified operation with common home wireless devices - PASS
* Power Quality: Verified operation with typical home power conditions - PASS
**5.2 Usability in Home Environment**
* User Interface: Simplified controls appropriate for non-professional users - PASS
* Alarm System: Audible and visual alarms clearly distinguishable - PASS
#### 6. Non-Conformances and Resolutions
**NC-001**: Initial wireless communication interference during conducted RF immunity testing
* **Root Cause**: Insufficient filtering on wireless module power supply
* **Corrective Action**: Added ferrite beads and improved power supply filtering
* **Retest Result**: PASS - No interference observed after modification
#### 7. Risk Assessment Integration
**Electrical Hazards Addressed**:
* Electric shock protection verified through insulation and leakage current testing
* Fire risk mitigated through temperature monitoring and material selection
* EMC risks controlled through comprehensive immunity testing
**Residual Risks**: No unacceptable electrical risks identified after verification testing.
#### 8. Compliance Summary
All electrical safety and EMC requirements have been successfully verified. PortaScan Ultrasound System demonstrates compliance with:
* IEC 60601-1:2005+A1:2012 - COMPLIANT
* IEC 60601-1-2:2014 - COMPLIANT
* IEC 60601-1-11:2015 - COMPLIANT
**Conclusion**: Device is electrically safe for intended clinical and home healthcare use.
**Approved by**: \[Test Engineer], \[Quality Assurance], \[Regulatory Affairs]
## Q\&A
The primary standard is IEC 60601-1 for general electrical safety requirements. Additional standards include IEC 60601-1-2 for electromagnetic compatibility, IEC 60601-1-6 for usability engineering, and specific collateral standards like IEC 60601-1-11 for home healthcare devices. The applicable standards depend on your device type, intended use environment, and electrical characteristics.
Medical devices are classified based on protection against electric shock (Class I, II, or internally powered), degree of protection against water ingress (IPX ratings), and application part type (B, BF, or CF). Classification determines the specific electrical safety requirements and test methods that apply to your device. Document your classification rationale and ensure testing covers all applicable requirements.
EMC testing includes both emissions testing (to verify your device doesn't interfere with other equipment) and immunity testing (to verify your device operates correctly when subjected to electromagnetic disturbances). Testing requirements depend on your device's intended electromagnetic environment and are specified in IEC 60601-1-2. Include both conducted and radiated emissions/immunity testing.
Electrical safety testing should address electrical hazards identified in your risk analysis. Use risk management to determine which electrical safety tests are most critical for your device and intended use. Document how test results demonstrate that electrical risks have been reduced to acceptable levels. Consider both normal operation and single fault conditions in your testing approach.
When tests fail, conduct root cause analysis to identify the underlying issue. Implement design changes to address the failure and retest to verify the fix. Document all failures, investigations, corrective actions, and retest results. Ensure that fixes don't introduce new electrical safety issues through appropriate regression testing.
Home healthcare devices have enhanced requirements per IEC 60601-1-11, including additional EMC immunity levels, enhanced usability requirements, and consideration of the home electromagnetic environment. Testing must account for non-professional users, typical home electrical conditions, and potential interference from common household devices. Document how your device meets these enhanced requirements.
# FDA 510(k) ESTAR
Source: https://docs.withdovetail.com/tasks/fda-510k-estar
Prepare electronic submission demonstrating substantial equivalence for FDA clearance and market authorization.
Content coming soon.
# FDA Device Classification
Source: https://docs.withdovetail.com/tasks/fda-device-classification
Determine product code and regulatory pathway through intended use analysis and classification database research.
## Summary
**FDA device classification** determines your medical device's risk class (I, II, or III) and regulatory pathway in the United States, directly impacting your submission requirements, testing obligations, and market access timeline. Classification is based on your device's intended use, indications for use, and product code assignment rather than physical characteristics. Your classification determines whether you need 510(k) clearance, PMA approval, or qualify for exemptions, making it fundamental to your US regulatory strategy.
## Why is FDA Device Classification Important?
FDA classification is **the foundation of your US regulatory pathway** because it determines the level of regulatory control and evidence required for market authorization. Class I devices typically require minimal regulatory oversight, Class II devices usually need 510(k) clearance with predicate device comparison, and Class III devices require PMA approval with extensive clinical data. Misunderstanding your classification can lead to pursuing the wrong regulatory pathway, unnecessary delays, or inadequate preparation for FDA requirements. Your classification also affects your quality system requirements, labeling obligations, and post-market surveillance responsibilities.
## Regulatory Context
Under **21 CFR Parts 862-892** and **Federal Food, Drug, and Cosmetic Act Section 513**:
* Classification is **product code-specific** and based on intended use and indications
* **Class I:** Low risk, minimal regulatory controls (some exempt from 510(k))
* **Class II:** Moderate risk, usually requires 510(k) clearance and special controls
* **Class III:** High risk, requires PMA approval with clinical data
**Special attention required for:**
* Software medical devices - classification based on clinical decision-making impact
* AI/ML devices - may require novel classification or De Novo pathway
* Combination products - each component may have different classification
* Novel devices - may require De Novo pathway to establish new product code
## Guide
**Start with the FDA Product Classification Database** to search for your device type by intended use, device name, or medical specialty. The database provides product codes, classification, and regulatory requirements for thousands of device types. Your product code determines your classification and regulatory pathway.
**Understand your intended use and indications for use precisely.** FDA classification is driven by **what your device does clinically**, not its physical characteristics. The same physical device can have different classifications based on different intended uses. Document your intended use clearly and search for product codes that match your clinical application.
**Evaluate existing product codes systematically.** Review the classification regulation (21 CFR Part) for your medical specialty area. Each product code has specific classification criteria, special controls, and regulatory requirements. If multiple product codes could apply, choose the one that most closely matches your intended use and technological characteristics.
**Consider the De Novo pathway for novel devices.** If no existing product code adequately describes your device, you may be eligible for the De Novo pathway. This process establishes a new product code and classification for novel, low-to-moderate risk devices. De Novo devices become predicates for future similar devices.
**Assess special controls and guidance documents.** Class II devices typically have special controls (performance standards, labeling requirements, post-market studies) that you must meet. Review FDA guidance documents for your device type to understand specific requirements and expectations.
**Document your classification rationale thoroughly.** Explain why your chosen product code and classification are appropriate based on your intended use, technological characteristics, and clinical application. This documentation supports your regulatory submission and demonstrates your understanding of FDA requirements.
**Consider software and AI/ML implications.** Software medical devices are classified based on their clinical decision-making impact, not their technical complexity. AI/ML devices may require special consideration for algorithm validation, training data, and performance monitoring.
## Example
### Complete FDA Device Classification Analysis
**FDA Device Classification Analysis**
ID: FDA-CLASS-2024-001
### Device Information
**Device Name:** CardioWatch Pro
**Intended Use:** Continuous monitoring and recording of heart rate and heart rhythm in adults (18 years and older) in home and clinical settings for healthcare provider review
### Product Code Analysis
**Primary Product Code:** MYN
**Product Code Name:** Electrocardiograph, Single Channel
**Classification:** Class II
**Regulation:** 21 CFR 870.2340
**Product Code Justification:**
CardioWatch Pro is appropriately classified under product code MYN based on the following analysis:
**Intended Use Alignment:**
* Device records single-channel electrocardiogram (ECG) signals
* Intended for monitoring heart rate and rhythm
* Used by healthcare professionals and patients
* Provides ECG data for clinical interpretation
* Matches the scope of 21 CFR 870.2340 for single-channel electrocardiographs
**Technological Characteristics:**
* Single-channel ECG recording capability
* Dry electrode contact with intact skin
* Digital signal processing and R-wave detection
* Bluetooth connectivity for data transmission
* Mobile application for data visualization
* Continuous monitoring capability (enhancement over typical spot recordings)
### Classification Determination
**Class II Device**
* Requires 510(k) clearance before marketing
* Subject to general controls and special controls
* Must demonstrate substantial equivalence to predicate device
**Special Controls Analysis:**
Under 21 CFR 870.2340, electrocardiographs are subject to the following special controls:
1. **Performance testing** demonstrating accuracy of ECG signal acquisition and processing
2. **Software validation** for signal processing algorithms and mobile application
3. **Electrical safety testing** according to IEC 60601-1 and related standards
4. **Electromagnetic compatibility** testing per IEC 60601-1-2
5. **Biocompatibility assessment** for skin-contacting materials
6. **Labeling requirements** including contraindications and user instructions
### Alternative Classifications Considered
**Product Code DSI (Electrocardiograph, Telephone Transmitting):**
* **Not applicable:** CardioWatch Pro uses Bluetooth, not telephone transmission
* **Different technology:** DSI devices typically use analog telephone lines
**Product Code DPS (Monitor, Cardiac (Including Cardiotachometer and Rate Alarm)):**
* **Not applicable:** CardioWatch Pro records ECG waveforms, not just heart rate monitoring
* **Different scope:** DPS focuses on rate monitoring without ECG recording capability
**Product Code MYO (Electrocardiograph, Multiple Channel):**
* **Not applicable:** CardioWatch Pro is single-channel, not multiple-channel device
### Regulatory Pathway
**510(k) Clearance Required**
* Must demonstrate substantial equivalence to appropriate predicate device
* Predicate device: AliveCor KardiaMobile 6L (K193869)
* Testing required: Performance, safety, software validation, biocompatibility
* Timeline: Typically 90 days FDA review after submission
**Quality System Requirements:**
* Must comply with 21 CFR Part 820 (Quality System Regulation)
* Design controls required for Class II devices
* Risk management per ISO 14971
**Post-Market Requirements:**
* Medical Device Reporting (MDR) for adverse events
* Registration and listing with FDA
* 510(k) required for significant modifications
## Q\&A
Use the **FDA Product Classification Database** to search by intended use, device name, or medical specialty. Review the classification regulation (21 CFR Part) for your area to understand specific product codes. If multiple codes could apply, choose the one that most closely matches your intended use and clinical application. Consult with regulatory experts if you're uncertain.
If no existing product code adequately describes your device, you may be eligible for the **De Novo pathway**. This process establishes a new product code and classification for novel, low-to-moderate risk devices. Submit a De Novo request with evidence that your device is novel and meets safety and effectiveness standards for its intended use.
**Yes, classification depends on intended use.** The same physical device can have different product codes and classifications based on different intended uses or indications. You must choose the classification that matches your specific intended use and clinical application. You cannot market a device for uses beyond its cleared indications.
**Software classification depends on clinical decision-making impact**, not technical complexity. Software that provides information to healthcare providers is typically Class II, while software that makes autonomous clinical decisions may be Class III. AI/ML algorithms require special consideration for validation, training data, and performance monitoring.
**Class II devices** typically require 510(k) clearance with predicate device comparison and are subject to special controls. **Class III devices** require PMA approval with extensive clinical data demonstrating safety and effectiveness. Class III is reserved for high-risk devices that support or sustain life or present unreasonable risk of illness or injury.
**Classification changes require new regulatory submissions.** If you modify your device's intended use or technological characteristics significantly, you may need a new 510(k) or even reclassification. Minor modifications may qualify for special 510(k) procedures. Always consult with FDA or regulatory experts before making significant changes to cleared devices.
# FDA Predicate Device
Source: https://docs.withdovetail.com/tasks/fda-predicate-device
Identify appropriate predicate devices establishing substantial equivalence foundation for successful clearance submissions.
## Summary
**FDA predicate device** identification is the foundation of your 510(k) submission, establishing substantial equivalence between your device and a legally marketed predicate device with the same intended use and technological characteristics. Your predicate device must be FDA-cleared, share the same product code, and demonstrate similar safety and effectiveness. Proper predicate selection determines your regulatory pathway, required testing, and likelihood of FDA clearance.
## Why is FDA Predicate Device Important?
Predicate device selection is **critical for 510(k) success** because it establishes the regulatory framework for demonstrating substantial equivalence. The FDA evaluates your device against your chosen predicate, not against absolute safety standards. A well-chosen predicate with similar intended use, technology, and performance characteristics streamlines your submission and reduces testing requirements. Poor predicate selection can result in additional testing requests, clinical study requirements, or outright rejection of your 510(k) submission. Your predicate also influences your labeling, indications for use, and post-market obligations.
## Regulatory Context
Under **21 CFR 807.87** and **21 CFR 807.92**:
* Predicate device must be **legally marketed** in the US (510(k)-cleared or PMA-approved)
* Must have **same intended use** and **same product code** as your device
* **Substantial equivalence** requires similar safety and effectiveness
* **Multiple predicates** may be used if no single device provides adequate comparison
**Special attention required for:**
* Software medical devices - predicate must have similar software functionality and risk profile
* AI/ML devices - limited predicates available, may require De Novo pathway
* Combination products - each component may require separate predicate analysis
* Novel technologies - if no appropriate predicate exists, consider De Novo pathway
## Guide
**Start with the FDA Product Classification Database** to identify devices with your product code and intended use. Search by product code, device name, or 510(k) number to find potential predicates. Focus on devices cleared within the last 10 years, as older devices may not reflect current FDA expectations.
**Evaluate intended use alignment carefully.** Your predicate must have the **same intended use** as your device. Minor differences in patient population, clinical application, or use environment may be acceptable, but fundamental differences in medical purpose will disqualify a predicate. Document how your intended use aligns with your predicate's cleared indications.
**Assess technological characteristics systematically.** Compare your device's design, materials, energy source, operating principle, and performance specifications with potential predicates. Differences are acceptable if they don't raise new safety or effectiveness questions. **New technological characteristics** may require additional testing or clinical data to demonstrate substantial equivalence.
**Review predicate performance data thoroughly.** Examine your predicate's 510(k) summary, labeling, and any FDA correspondence to understand cleared performance specifications, testing requirements, and special controls. Your device should meet or exceed predicate performance while maintaining similar risk profile.
**Consider multiple predicates strategically.** If no single device provides adequate comparison, you may use multiple predicates to address different aspects of your device. For example, one predicate for hardware design and another for software functionality. Document the rationale for each predicate selection.
**Evaluate predicate regulatory history.** Check for FDA recalls, safety communications, or post-market issues that might affect your predicate's suitability. Avoid predicates with significant safety concerns or regulatory problems that could complicate your submission.
**Document your predicate justification comprehensively.** Explain why your chosen predicate is appropriate, how your device compares technologically, and what testing demonstrates substantial equivalence. Address any differences and explain why they don't raise new safety or effectiveness questions.
## Example
### Complete FDA Predicate Device Document
**FDA Predicate Device**
ID: PRED-2024-001
### 1. Purpose
The purpose of this document is to define the predicate devices to be used for substantial equivalence to CardioWatch Pro.
### 2. Scope
This document covers predicate and potential reference devices related to CardioWatch Pro for submission to the U.S. Food and Drug Administration.
### 3. Predicate Device Information
**Predicate Device Trade Name:**
AliveCor KardiaMobile 6L
**Predicate Submission Number:**
K193869
**Product Code:**
MYN - Electrocardiograph, Single Channel
**Product Code Name:**
Electrocardiograph, Single Channel
**Predicate Device Intended Use:**
The AliveCor KardiaMobile 6L is a single-channel electrocardiograph intended for use by healthcare professionals and patients for recording, storing, transferring, and displaying single-channel electrocardiogram (ECG) rhythms. The device is intended for patients 18 years of age and over. The device is not intended to be used on patients who have implanted pacemakers or defibrillators.
**Substantial Equivalence Justification:**
CardioWatch Pro demonstrates substantial equivalence to the AliveCor KardiaMobile 6L based on the following comparison:
**Intended Use Comparison:**
* **Same:** Both devices are intended for ECG recording and monitoring in adults 18+ years
* **Same:** Both devices are intended for healthcare professional and patient use
* **Same:** Both devices record, store, and display single-channel ECG data
* **Same:** Both devices are contraindicated for patients with implanted cardiac devices
* **Similar:** CardioWatch Pro adds continuous monitoring capability while maintaining the same core ECG recording function
**Technological Characteristics:**
* **Same:** Single-channel ECG recording using dry electrodes
* **Same:** Digital signal processing and R-wave detection algorithms
* **Same:** Bluetooth connectivity for data transmission to mobile devices
* **Same:** Mobile application for data visualization and storage
* **Different:** CardioWatch Pro uses wearable form factor vs. handheld device - this difference does not raise new safety or effectiveness questions as both contact intact skin with dry electrodes
* **Different:** CardioWatch Pro provides continuous monitoring vs. spot recordings - this enhances functionality without introducing new risks
**Performance Characteristics:**
* **Same:** ECG signal acquisition and processing capabilities
* **Same:** Heart rate detection and rhythm analysis
* **Same:** Data storage and transmission protocols
* **Enhanced:** Continuous monitoring provides more comprehensive data collection
* **Same:** Mobile application interface and cloud connectivity
### 4. Reference Device Information
| Device Trade Name | Submission Number | Product Code | Description |
| ------------------------ | ----------------- | ------------ | ---------------------------------------------------------------------------------------------------------------------- |
| Zio XT Patch | K143254 | MYN | Single-channel ambulatory ECG monitor for continuous recording - provides reference for extended monitoring capability |
| Apple Watch Series 4 ECG | K182749 | MYN | Wearable ECG device with mobile app - provides reference for wearable form factor and consumer use |
**Reference Device Rationale:**
* **Zio XT Patch:** Provides precedent for continuous ECG monitoring in ambulatory settings, supporting CardioWatch Pro's extended monitoring capability
* **Apple Watch Series 4:** Demonstrates FDA acceptance of wearable ECG devices with consumer accessibility, supporting CardioWatch Pro's wearable design and patient use
## Q\&A
A good predicate device has the **same intended use and product code** as your device, similar technological characteristics, and a clear regulatory pathway. Choose predicates cleared within the last 10 years with well-documented performance specifications. Avoid predicates with significant safety issues, recalls, or complex regulatory histories that could complicate your submission.
**Yes, you can use multiple predicates** if no single device provides adequate comparison for all aspects of your device. For example, one predicate for hardware design and another for software functionality. Document the rationale for each predicate and explain how they collectively support substantial equivalence for your device.
**New technological characteristics are acceptable** if they don't raise new safety or effectiveness questions. You must provide additional testing or clinical data to demonstrate that these differences don't affect safety or effectiveness. If new characteristics raise significant questions, you may need to pursue the De Novo pathway instead of 510(k).
Use the **FDA Product Classification Database** to search by product code, device name, or intended use. Review 510(k) summaries and FDA clearance letters for potential predicates. Focus on recently cleared devices (within 10 years) with similar technology and intended use. Consult with regulatory experts if you're having difficulty identifying appropriate predicates.
If no appropriate predicate exists, your device may be eligible for the **De Novo pathway** for novel, low-to-moderate risk devices. The De Novo process establishes a new product code and classification, potentially creating a predicate for future similar devices. Consult with FDA through the Q-Sub process to discuss your regulatory pathway options.
Your predicate comparison should be **comprehensive and systematic**, covering intended use, technological characteristics, performance specifications, and safety considerations. Use tables and side-by-side comparisons to clearly demonstrate similarities and differences. Address any differences with rationale for why they don't raise new safety or effectiveness questions, supported by appropriate testing data.
# FDA Registration And Listing
Source: https://docs.withdovetail.com/tasks/fda-registration-and-listing
Register establishment and list devices with FDA establishing legal presence for US market access.
## Summary
**FDA Registration and Listing** is the mandatory process of registering your company as a medical device establishment and listing your medical devices with the **Food and Drug Administration (FDA)** before marketing them in the United States. This process establishes your legal presence in the FDA database and enables regulatory oversight of your devices.
## Why is FDA Registration and Listing important?
FDA Registration and Listing serves as the **foundation** for all medical device activities in the US market. Without proper registration, you cannot legally manufacture, import, or distribute medical devices in the United States. The process establishes your company in the **FDA database**, enables **regulatory communication**, and provides the FDA with essential information for **market surveillance** and **safety monitoring**. Registration also demonstrates your commitment to **regulatory compliance** and enables the FDA to conduct **inspections** and **oversight activities** when necessary.
## Regulatory Context
Under **21 CFR Part 807** (Establishment Registration and Device Listing):
* **Annual registration** required for all device establishments
* **Device listing** required for all marketed devices
* **510(k) clearance** or **PMA approval** required before marketing most devices
* **Registration renewal** required annually between October 1 and December 31
**Special attention required for:**
* Foreign establishments must designate a US Agent for FDA communications
* Software as Medical Device (SaMD) classification and listing requirements
* Combination products requiring coordination with other FDA centers
* Export-only manufacturers have different registration requirements
## Guide
FDA Registration and Listing involves **two distinct but related processes** that must be completed before marketing your medical device in the United States. The process establishes your regulatory identity and provides the FDA with essential oversight information.
### Step 1: Establishment Registration
**Company Information**: Register your company as a **medical device establishment** using the FDA's **electronic registration system**. Provide complete business information including legal name, physical address, business activities, and contact information. For software companies, clearly indicate your role as a **device manufacturer**.
**US Agent Designation**: If you're a **foreign establishment**, you must designate a **US Agent** who serves as your communication point with the FDA. The US Agent must be physically located in the United States and have authority to represent your company in FDA matters. This person receives all FDA communications and must be available during normal business hours.
**Registration Activities**: Specify your **establishment activities** such as manufacturing, importing, or distributing medical devices. For software medical devices, select **"Manufacture"** as your primary activity. Include any **contract manufacturing** or **sterilization** activities if applicable.
### Step 2: Device Listing
**Device Classification**: Determine your device's **FDA product code** and **classification** (Class I, II, or III). For software medical devices, common product codes include **DQO** (Software, Medical Device), **LLZ** (System, Physiological Monitoring), or device-specific codes based on your intended use.
**Device Information**: Provide detailed device information including **proprietary name**, **common name**, **intended use**, and **product code**. For software devices, include the **software version** and specify whether it's **standalone software** or **software in a medical device**.
**Predicate Device**: If submitting a **510(k)**, identify your **predicate device** by name and **510(k) number**. The predicate device must be legally marketed and substantially equivalent to your device in terms of intended use and technological characteristics.
### Step 3: Premarket Submission Requirements
**510(k) Clearance**: Most **Class II devices** and some **Class I devices** require **510(k) clearance** before marketing. Submit your 510(k) application demonstrating **substantial equivalence** to a predicate device. Include comprehensive testing data, software documentation, and clinical evidence as required.
**PMA Approval**: **Class III devices** typically require **Premarket Approval (PMA)**, which involves extensive clinical trials and comprehensive safety and effectiveness data. This process is significantly more complex and time-consuming than 510(k) clearance.
**De Novo Classification**: For **novel devices** without appropriate predicates, consider the **De Novo pathway** to establish a new device classification and create a predicate for future similar devices.
### Step 4: Annual Maintenance
**Registration Renewal**: Renew your establishment registration **annually** between **October 1 and December 31**. Failure to renew results in **automatic cancellation** of your registration and inability to market devices.
**Device Listing Updates**: Update your device listings whenever you make **significant changes** to device design, intended use, or manufacturing processes. Add new devices to your listing before marketing them.
**Adverse Event Reporting**: Implement **Medical Device Reporting (MDR)** procedures to report adverse events, malfunctions, and deaths associated with your device. Software devices must report software failures that could lead to patient harm.
## Example
### Scenario
You've developed a Class II software application for diabetes management that helps patients track glucose levels and provides insulin dosing recommendations. You need to complete FDA registration and listing before launching in the US market.
### FDA Registration and Listing Process Example
**Step 1: Establishment Registration**
**Company:** DiabetesTracker Solutions LLC\
**Address:** 123 Innovation Drive, Austin, TX 78701\
**Business Activity:** Medical Device Manufacturer\
**Registration Type:** Domestic Establishment\
**FDA Registration Number:** 12345678 (assigned by FDA)
**Step 2: Device Listing**
**Proprietary Name:** GlucoSmart Pro\
**Common Name:** Diabetes Management Software\
**Product Code:** DQO (Software, Medical Device)\
**Device Class:** Class II\
**Regulation Number:** 21 CFR 862.2100\
**Intended Use:** Software intended to help diabetes patients track blood glucose levels and receive insulin dosing recommendations under healthcare provider supervision.
**Step 3: 510(k) Submission**
**Predicate Device:** MySugr Bundle (K171816)\
**Substantial Equivalence:** Both devices provide diabetes management software with glucose tracking and insulin dosing support\
**510(k) Number:** K241234 (assigned after clearance)\
**Clearance Date:** March 15, 2024
**Step 4: Annual Maintenance**
**Registration Renewal:** Completed October 15, 2024\
**Device Listing Update:** Updated software version from v1.0 to v1.1 on June 1, 2024\
**MDR Reports:** No adverse events reported in first year of marketing
### Registration Timeline
**Month 1:** Completed establishment registration and initial device listing\
**Month 2-4:** Prepared and submitted 510(k) application\
**Month 6:** Received 510(k) clearance\
**Month 7:** Launched device in US market\
**Month 12:** Completed annual registration renewal
## Q\&A
You must complete establishment registration and device listing before marketing your medical device in the United States. Registration should be done early in your development process, but device listing can only be completed after you have FDA clearance or approval (for devices requiring premarket submission). Plan to complete registration at least 30 days before your planned market launch.
FDA registration establishes your company in the FDA database and lists your devices, while 510(k) clearance provides marketing authorization for specific devices. Registration is administrative and required for all establishments, while 510(k) clearance requires demonstrating substantial equivalence to a predicate device and is required for most Class II devices before marketing.
Yes, all foreign establishments must designate a US Agent who serves as the communication point with the FDA. The US Agent must be physically located in the United States, have authority to represent your company, and be available during normal business hours. The US Agent receives all FDA communications and can be contacted for inspections or regulatory matters.
You must renew your establishment registration annually between October 1 and December 31. The FDA sends renewal notices, but it's your responsibility to complete the renewal. Failure to renew results in automatic cancellation of your registration, which prevents you from legally marketing devices until you re-register.
Minor software updates like bug fixes typically require an internal "letter to file" documenting the change and its impact. Major feature additions or changes affecting safety or effectiveness require FDA resubmission through a new 510(k) or PMA supplement. Develop a software change control strategy to avoid unnecessary retesting and resubmission requirements.
Use the FDA's product classification database to find the appropriate product code based on your device's intended use and technological characteristics. Common software codes include DQO (Software, Medical Device) for general software or specific codes like LLZ for physiological monitoring systems. When in doubt, consult with FDA through a pre-submission meeting to confirm the appropriate classification.
# Field Safety Notice Form
Source: https://docs.withdovetail.com/tasks/field-safety-notice
Communicate urgent safety information to users requiring immediate protective actions.
## Summary
A Field Safety Notice Form is an **urgent communication template** used to notify users, patients, and healthcare professionals about safety issues with your medical device that require immediate action. You use this form when you identify risks that could cause serious harm and need to implement Field Safety Corrective Actions (FSCA) to protect users.
## Why is the Field Safety Notice Form important?
Field Safety Notice Forms serve as your **primary tool for rapid and standardized risk communication** when post-market surveillance reveals safety concerns. They enable you to quickly inform users about hazards, provide protective instructions, and coordinate corrective actions before serious incidents occur using a consistent format. FSN forms demonstrate regulatory compliance, protect patient safety, and maintain stakeholder trust during crisis situations. Without timely and effective FSN forms, safety issues can escalate into widespread harm, regulatory sanctions, and permanent market withdrawal.
## Regulatory Context
Under **21 CFR Part 806** (Medical Device Correction and Removal):
* Manufacturers must **notify FDA** within 10 working days of initiating a correction or removal
* **Device recalls** must be reported immediately if they could cause serious health consequences
* FSNs must reach all affected users and include **specific corrective actions**
* Follow-up reports required to document effectiveness of corrective actions
**Special attention required for:**
* Class I recalls requiring immediate FDA notification
* Software updates that address safety-critical vulnerabilities
* Devices used in life-supporting or life-sustaining applications
* Coordination with FDA's MedWatch safety alert system
Under **EU MDR 2017/745**:
* **Field Safety Corrective Actions** must be reported via EUDAMED (Article 89)
* FSNs must be submitted to competent authorities **without delay**
* Must comply with **MDCG 2019-9** guidance on Field Safety Notices
* Notified bodies must be informed of FSCAs affecting certified devices
**Special attention required for:**
* Translation requirements for multi-country distribution
* Coordination with authorized representatives in each member state
* Integration with national vigilance systems
* Post-market clinical follow-up implications for ongoing studies
## Guide
### When to Use the Field Safety Notice Form
**Use the FSN form template immediately** when you identify device-related risks that could cause death, serious injury, or serious public health threats. This includes software malfunctions, hardware failures, labeling errors, or use-errors that compromise safety.
**Don't delay for complete investigations** - use the preliminary FSN form based on initial risk assessments and follow up with additional information as your investigation progresses. The goal is rapid risk mitigation, not perfect information.
### FSN Form Content Requirements
**Risk description** must clearly explain the hazard, its likelihood, and potential consequences for users and patients using the structured form fields. Use plain language that non-technical users can understand while providing sufficient detail for healthcare professionals to make informed decisions.
**Corrective actions** should be specific, actionable, and time-bound using the form template. Specify exactly what users must do, by when, and how to confirm completion. Include contact information for questions and support during implementation.
**Device identification** must enable users to determine if their devices are affected using the form's device information section. Include UDI-DI numbers, software versions, serial number ranges, and manufacturing dates as applicable.
### Distribution and Follow-up
**Reach all affected users** through multiple channels including direct mail, email, website postings, and professional networks using the completed form. Maintain distribution lists and track delivery confirmation to ensure comprehensive coverage.
**Monitor implementation** by tracking user responses, measuring corrective action completion rates, and assessing residual risk levels. Document effectiveness and prepare follow-up communications as needed.
**Coordinate with authorities** by submitting completed FSN forms to competent authorities simultaneously with user distribution. Provide regular updates on implementation progress and effectiveness measurements.
### Integration with Quality Management
Connect your FSN form process to your **incident management system** for rapid response to emerging safety signals. Link to your **CAPA system** to address root causes and prevent recurrence. Update your **risk management file** to reflect new hazards and control measures identified through FSN activities.
## Example
**Scenario**: Your cardiac monitoring app experiences a critical software bug that causes false arrhythmia alarms in 2% of users, leading to unnecessary emergency room visits. Post-market surveillance data shows this affects version 3.2.1 released three weeks ago. You must immediately issue an FSN to prevent further incidents while developing a software fix.
### Example Field Safety Notice Form
**FSN Number**: FSN-2024-001\
**Date**: March 20, 2024
**URGENT FIELD SAFETY NOTICE**
**CardioWatch Pro Mobile App**
**For the Attention of**: All CardioWatch Pro users, cardiologists, and healthcare facilities using our cardiac monitoring system
**Contact Details of Local Representative**:
CardioWatch Support Team\
Email: [safety@cardiowatch.com](mailto:safety@cardiowatch.com)\
Phone: +49-30-12345678\
Address: Medizintechnik Straße 15, 10115 Berlin, Germany
#### Device Information
| Device Information | Description |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| **Device Name** | CardioWatch Pro Mobile App |
| **Device UDI-DI** | (01)04012345123456 |
| **Manufacturer Name** | CardioWatch Technologies GmbH |
| **Single Registration Number (SRN)** | DE-MF-000012345 |
| **Device Description** | Mobile application for continuous cardiac rhythm monitoring and arrhythmia detection in ambulatory patients |
| **Associated Devices Affected** | CardioWatch Pro Hardware Sensor (Model CW-100) when used with affected app version |
#### Risk Information
| Risk Information | Description |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Description of Product Issue** | Software algorithm error in version 3.2.1 causing false positive arrhythmia alerts in approximately 2% of monitoring sessions |
| **Hazard Resulting from Issue** | Unnecessary emergency medical interventions, patient anxiety, healthcare system burden, and potential delayed response to actual emergencies |
| **Likelihood of Risk** | Moderate - affects 2% of monitoring sessions, with higher incidence in patients with baseline heart rate variability |
| **Risk to Users/Patients** | **Patients**: Unnecessary stress, emergency room visits, potential medical procedures. **Healthcare providers**: Resource allocation issues, diagnostic confusion |
| **Additional Information** | Issue identified through post-market surveillance analysis of user reports. Root cause: algorithm sensitivity threshold error introduced in version 3.2.1 update |
#### Action Information
| Action Information | Description |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Action to be Taken by User** | **Immediately update** CardioWatch Pro app to version 3.2.2 (available now). **Verify** alert settings are configured correctly. **Contact physician** if you received false alarms in the past 3 weeks |
| **User Action Timeline** | Update app within **48 hours** of receiving this notice |
| **Customer Reply Required** | **Yes** - Confirm app update completion via email to [safety@cardiowatch.com](mailto:safety@cardiowatch.com) or through in-app notification |
| **Action Taken by Manufacturer** | Released corrected software version 3.2.2 with fixed algorithm. Implementing enhanced testing protocols for future releases. Notifying regulatory authorities and healthcare networks |
| **Manufacturer Action Timeline** | Software fix released March 20, 2024. Enhanced testing protocols implemented by April 1, 2024 |
| **Information for Lay Patient or User** | **For patients**: Update your app immediately. If you visited emergency care due to CardioWatch alerts in the past 3 weeks, inform your doctor about this notice. Continue normal monitoring - the device remains safe and effective with the update |
**Follow-up FSN**: A follow-up notice will be issued within 30 days to report on update completion rates and any additional corrective actions if needed.
## Q\&A
Distribute FSNs immediately upon identifying safety risks - within 24-48 hours of risk confirmation. Don't wait for complete investigations. Issue preliminary notices and follow up with additional information as it becomes available.
FSNs must be provided in the local language of each market where your device is distributed. For EU markets, this typically means translating into the official language(s) of each member state where you have users.
Maintain comprehensive user databases with multiple contact methods. Use direct mail, email, website postings, professional networks, and distributor channels. Track delivery confirmation and follow up with non-responders through alternative channels.
Issue follow-up FSNs when you have significant new information about the risk, when initial corrective actions prove insufficient, or when you need to report on implementation effectiveness. Regular follow-ups may be required until the safety issue is fully resolved.
Implement escalating communication strategies including repeat notices through different channels, direct phone contact for high-risk situations, and coordination with healthcare providers. Document all attempts and consider additional regulatory reporting for non-responsive users in critical situations.
# Firmware Design
Source: https://docs.withdovetail.com/tasks/firmware-design
Develop low-level software controlling hardware components with real-time requirements and safety measures.
## Summary
The Firmware Design document defines the low-level software that directly controls hardware components in your medical device. This document covers embedded software architecture, real-time requirements, hardware interfaces, and safety-critical firmware functions essential for reliable device operation.
## Why is Firmware Design important?
Firmware design documentation is **essential for patient safety** because firmware directly controls hardware functions and real-time operations that can immediately affect patient care. Poor firmware design can lead to **device malfunction**, **timing failures**, or **hardware control errors** that compromise patient safety. Regulatory authorities require detailed firmware specifications to ensure devices operate reliably and safely under all conditions.
The firmware design also demonstrates that you have systematically considered **real-time constraints**, **hardware safety**, and **fault handling**. This documentation supports **risk management**, **software verification**, and **hardware-software integration** throughout the development process.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **IEC 62304** (Medical Device Software):
* Firmware specifications must be **documented** as design inputs
* **Software lifecycle processes** per IEC 62304 for firmware development
* **Risk management** for firmware hazards per ISO 14971
* **Cybersecurity** considerations for connected firmware
**Special attention required for:**
* Real-time safety requirements and timing constraints
* Hardware abstraction layer documentation
* Firmware update mechanisms and security
* Integration with higher-level software systems
Under **EU MDR 2017/745** and **IEC 62304:2006**:
* Firmware must comply with **IEC 62304** software lifecycle processes
* **Software safety classification** (Class A, B, or C) applies to firmware
* **Risk management** per EN ISO 14971 for firmware-related risks
* **Essential Requirements** compliance for firmware safety functions
**Special attention required for:**
* Software safety classification impacts firmware documentation requirements
* Real-time performance verification and validation
* Firmware security and update mechanisms
* Hardware-software interface verification
## Guide
### Understanding Firmware Design
Firmware is **low-level software** that directly interfaces with hardware components and provides the foundation for higher-level software applications. Firmware typically includes:
* **Hardware Abstraction Layer (HAL)**: Software interface to hardware peripherals
* **Real-Time Operating System (RTOS)**: Task scheduling and resource management
* **Device Drivers**: Software that controls specific hardware components
* **Communication Protocols**: Low-level data transmission and reception
* **Safety Monitoring**: Watchdog timers, fault detection, and error handling
### Firmware Architecture
Document your firmware structure systematically:
* **System Architecture**: Overall firmware organization and module relationships
* **Task Structure**: Real-time tasks, priorities, and scheduling requirements
* **Memory Management**: RAM and flash memory allocation and usage
* **Interrupt Handling**: Interrupt service routines and priority levels
* **Communication Interfaces**: Hardware communication protocols and data flow
### Real-Time Requirements
Firmware must meet strict timing requirements:
* **Response Times**: Maximum allowable delays for critical functions
* **Task Priorities**: Priority assignment for real-time tasks
* **Interrupt Latency**: Maximum time to respond to hardware interrupts
* **Scheduling Requirements**: Task scheduling algorithms and timing constraints
* **Deterministic Behavior**: Predictable timing under all operating conditions
### Hardware Interface Specifications
Document how firmware controls hardware:
* **Peripheral Configuration**: Setup and configuration of hardware peripherals
* **Register Mapping**: Memory-mapped register access and control
* **Signal Timing**: Hardware signal timing requirements and constraints
* **Power Management**: Low-power modes and power state transitions
* **Fault Detection**: Hardware monitoring and fault response mechanisms
### Safety and Reliability Features
Firmware must implement safety mechanisms:
* **Watchdog Timers**: System monitoring and automatic reset capabilities
* **Error Detection**: Hardware and software error detection mechanisms
* **Fault Handling**: Response to hardware faults and error conditions
* **Safe States**: Default safe operating modes during fault conditions
* **Data Integrity**: Memory protection and data validation mechanisms
### Development and Testing Considerations
Plan for firmware verification:
* **Development Environment**: Tools, compilers, and debugging interfaces
* **Testing Strategies**: Unit testing, integration testing, and hardware-in-the-loop testing
* **Code Coverage**: Testing coverage requirements for safety-critical functions
* **Version Control**: Firmware versioning and configuration management
* **Update Mechanisms**: Secure firmware update procedures and rollback capabilities
## Example
**Scenario**: You're developing firmware for an insulin pump that must precisely control motor-driven insulin delivery while monitoring battery levels, detecting occlusions, and communicating with a smartphone app. Your firmware must ensure patient safety through reliable real-time operation.
### Firmware Architecture Overview
The insulin pump firmware is built on a real-time operating system (FreeRTOS) running on an ARM Cortex-M4 microcontroller. The architecture consists of five main modules: Motor Control, Safety Monitoring, Communication, User Interface, and Power Management. Each module operates as separate tasks with defined priorities and inter-task communication through message queues.
### Task Structure and Priorities
| Task | Priority | Period | Function |
| ---------------- | ----------- | ------ | ----------------------------------------------------------------- |
| Safety Monitor | 1 (Highest) | 100ms | Occlusion detection, battery monitoring, fault detection |
| Motor Control | 2 | 50ms | Insulin delivery control, motor positioning, flow rate regulation |
| Communication | 3 | 500ms | Bluetooth communication with smartphone app |
| User Interface | 4 | 200ms | Button input processing, display updates, alarm management |
| Power Management | 5 (Lowest) | 1000ms | Battery monitoring, low-power mode transitions |
### Hardware Interface Implementation
**Motor Control Interface**: PWM signal generation at 20 kHz for stepper motor control with microstepping capability. Position feedback through optical encoder with 1000 pulses per revolution. Motor current monitoring through ADC for stall detection.
**Sensor Interfaces**: Pressure sensor monitoring via 12-bit ADC at 100 Hz sampling rate for occlusion detection. Battery voltage monitoring with 0.1V resolution. Temperature sensor for environmental monitoring and compensation.
**Communication Hardware**: UART interface to Bluetooth module at 115200 baud with hardware flow control. SPI interface to external flash memory for data logging at 8 MHz clock rate.
### Safety and Fault Handling
**Watchdog Timer**: 500ms timeout with automatic system reset if not refreshed. Safety monitor task refreshes watchdog every 100ms during normal operation.
**Occlusion Detection**: Pressure sensor monitoring with 3-sigma threshold detection. Motor stall detection through current monitoring. Automatic delivery stop and alarm generation upon detection.
**Battery Safety**: Low battery warning at 20% capacity, critical battery alarm at 10% capacity with delivery suspension. Battery voltage monitoring every 100ms with trend analysis.
**Fault Response**: Three-level fault classification (Warning, Alarm, Critical). Critical faults result in immediate delivery stop and safe state entry. All faults logged to non-volatile memory with timestamp.
### Real-Time Performance Requirements
**Motor Control Timing**: Motor step commands must be generated within ±1ms of scheduled time to maintain delivery accuracy. Maximum jitter of 100μs for consistent flow rate.
**Safety Response Time**: Occlusion detection must trigger delivery stop within 200ms of threshold crossing. Battery critical alarm must activate within 500ms of detection.
**Communication Latency**: Bluetooth commands must be processed within 1 second. Status updates transmitted every 5 seconds during active delivery.
### Memory Management
**Flash Memory Usage**: 256KB total with 180KB for application code, 32KB for bootloader, 32KB for configuration data, and 12KB reserved for firmware updates.
**RAM Allocation**: 64KB total with 32KB for RTOS heap, 16KB for stack space, 8KB for communication buffers, and 8KB for data logging buffers.
**Non-Volatile Storage**: External 1MB flash for delivery history logging with wear leveling. Configuration parameters stored in internal EEPROM with redundancy.
## Q\&A
Include enough detail for firmware engineers to implement the system and for verification teams to test real-time performance. Specify task structures, timing requirements, hardware interfaces, and safety mechanisms. Document both functional requirements (what the firmware must do) and non-functional requirements (timing, memory, power consumption).
Analyze the medical function and patient safety requirements to determine critical timing constraints. Consider physiological time constants, user response times, and safety response requirements. Document worst-case timing scenarios and specify maximum allowable delays for safety-critical functions. Use real-time analysis techniques to verify timing feasibility.
Implement watchdog timers, error detection and correction, fault monitoring, and safe state transitions. Design for single fault tolerance where required by risk analysis. Include hardware monitoring, software self-tests, and graceful degradation capabilities. Document all safety mechanisms and their verification requirements.
Design secure update mechanisms with authentication and integrity verification. Implement rollback capabilities for failed updates. Use semantic versioning and maintain configuration management for all firmware releases. Document update procedures and testing requirements. Consider over-the-air update capabilities for connected devices.
Use a combination of unit testing, integration testing, and hardware-in-the-loop testing. Implement code coverage analysis for safety-critical functions. Test real-time performance under worst-case conditions. Use static analysis tools for code quality and safety verification. Document all testing procedures and acceptance criteria.
Specify exact hardware register mappings, signal timing requirements, and communication protocols. Document initialization sequences, configuration parameters, and error handling procedures. Include timing diagrams for critical interfaces and specify electrical characteristics where relevant. Maintain traceability between hardware and firmware requirements.
# GSPR Checklist
Source: https://docs.withdovetail.com/tasks/gspr-checklist
Systematically evaluate compliance with essential safety and performance requirements for EU market access.
## Summary
The General Safety and Performance Requirements (GSPR) Checklist is a comprehensive evaluation tool that demonstrates your medical device's compliance with EU MDR Annex I requirements. This document systematically reviews each GSPR requirement, determines its applicability to your device, identifies relevant standards, provides evidence of conformity, and justifies any deviations from the requirements.
## Why is GSPR Checklist important?
The GSPR Checklist serves as the **cornerstone of EU MDR compliance** by ensuring your device meets all fundamental safety and performance requirements before market entry. European regulators require this systematic evaluation to verify that manufacturers have thoroughly considered every applicable safety requirement and implemented appropriate risk controls. The checklist provides **transparent documentation** of your compliance strategy, making it easier for notified bodies to assess your technical file and for you to maintain ongoing compliance throughout your device's lifecycle.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* No direct equivalent to GSPR checklist exists in FDA regulations
* However, **510(k) submissions** must demonstrate substantial equivalence and safety
* **Design controls** (820.30) require systematic evaluation of device requirements
* **Risk analysis** must be documented as part of design controls
**Special attention required for:**
* Software devices must comply with FDA software guidance documents
* Cybersecurity requirements under FDA premarket guidance
* Usability engineering per FDA Human Factors guidance
* Predicate device comparison for substantial equivalence
Under **EU MDR 2017/745**:
* **Annex I** contains all General Safety and Performance Requirements (GSPRs)
* **Article 10(9)** requires manufacturers to demonstrate GSPR compliance
* Must be included in **technical documentation** (Annex II)
* Required for **CE marking** and market access in EU
**Special attention required for:**
* Software as Medical Device (SaMD) specific requirements (GSPR 17)
* Cybersecurity and data protection requirements
* Clinical evaluation alignment with GSPR claims
* Post-market surveillance integration with GSPR monitoring
## Guide
### Understanding GSPR Structure
The GSPR checklist follows the **three-chapter structure** of MDR Annex I: General Requirements (GSPRs 1-9), Design and Manufacture Requirements (GSPRs 10-22), and Information Requirements (GSPR 23). Each requirement must be evaluated for **applicability, standards compliance, evidence provision, and deviation justification**.
### Determining Applicability
For each GSPR, you must determine whether it applies to your device based on its **intended use, design characteristics, and risk profile**. Software medical devices typically have "No" applicability for physical requirements like biocompatibility, sterilization, or mechanical properties, but must carefully address software-specific requirements in GSPRs 17-18.
### Identifying Applicable Standards
When a GSPR applies to your device, identify the **harmonized standards** that provide presumption of conformity. Key standards for software devices include **EN 62304** (medical device software lifecycle), **IEC 82304-1** (health software general requirements), **EN ISO 14971** (risk management), and **EN 62366-1** (usability engineering). Reference the **Official Journal of the European Union** for the current list of harmonized standards.
### Providing Evidence of Conformity
Your evidence must demonstrate **objective compliance** with each applicable GSPR. This includes referencing specific documents from your technical file such as risk management files, clinical evaluation reports, verification and validation reports, usability engineering files, and design documentation. Ensure your evidence is **traceable, verifiable, and current**.
### Justifying Deviations
When a GSPR is not applicable or when you deviate from standard approaches, provide **clear, technical justification**. For software devices, common justifications include "device is software and not susceptible to \[physical requirement]" or "device does not contain \[specific component/substance]". Avoid generic statements and provide **device-specific reasoning**.
### Key Considerations for Software Devices
Software medical devices must pay particular attention to **GSPR 17** (electronic programmable systems and software), which requires compliance with software development lifecycle standards, risk management including cybersecurity, and verification and validation. Address **mobile platform considerations** (GSPR 17.3) if your software runs on mobile devices, including screen size limitations and environmental factors.
### Integration with Other Documentation
Your GSPR checklist must align with other technical documentation including your **risk management file, clinical evaluation, usability engineering file, and verification and validation reports**. Ensure consistency in claims, evidence references, and compliance statements across all documents.
## Example
### Scenario
You are developing a mobile application that analyzes medical images and provides diagnostic support to healthcare professionals. The app processes uploaded images, applies AI algorithms for analysis, and displays results with confidence scores. It does not store patient data locally and requires internet connectivity for processing.
### Example GSPR Checklist Entry
**GSPR 17.1: Electronic Programmable Systems**
| Element | Content |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Requirement** | Devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use. |
| **Applicable** | Yes |
| **Applicable Standards** | EN 62304:2006+A1:2015
IEC 82304-1:2016
EN ISO 14971:2019 |
| **Evidence of Conformity** | Software Development and Maintenance Plan (DOC-001)
Software Architecture Document (DOC-015)
Software System Test Report (DOC-045)
Risk Management File (DOC-008) |
| **Rationale for Deviations** | No deviations |
**GSPR 10.1: Chemical, Physical and Biological Properties**
| Element | Content |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Requirement** | Devices shall be designed and manufactured in such a way as to ensure that the characteristics and performance requirements referred to in Chapter I are fulfilled, with particular attention to choice of materials, toxicity, and flammability. |
| **Applicable** | No |
| **Applicable Standards** | N/A |
| **Evidence of Conformity** | N/A |
| **Rationale for Deviations** | The device is software-only and does not contain physical materials susceptible to toxicity, flammability, or other chemical and physical properties. |
## Q\&A
If a notified body questions your applicability assessment, you must provide additional technical justification or revise your evaluation. Document your reasoning clearly and be prepared to demonstrate why specific requirements don't apply to your device design and intended use.
Break down the GSPR into its component parts and evaluate each separately. Mark the overall GSPR as "Yes" if any part applies, then provide detailed justification explaining which aspects apply and which don't, with specific evidence for applicable portions.
Yes, you can use non-harmonized standards, but you must provide additional justification demonstrating how they ensure GSPR compliance. Harmonized standards provide presumption of conformity, while non-harmonized standards require you to prove equivalence.
Update your GSPR checklist whenever you make significant design changes, when new harmonized standards are published, or when regulatory guidance changes. Minor software updates typically don't require GSPR checklist updates unless they affect safety or performance claims.
If your device has measuring functions with claimed accuracy, you must address GSPR 15 requirements. This includes demonstrating sufficient accuracy, precision, and stability for your intended purpose, and expressing measurements in legal units where applicable.
Cybersecurity is primarily addressed through GSPR 17.2 (software development lifecycle) and GSPR 18.8 (protection against unauthorized access). Reference your risk management file, cybersecurity documentation, and relevant standards like IEC 80001-1 for network security.
# Hardware Design and Development Plan
Source: https://docs.withdovetail.com/tasks/hardware-design-and-development-plan
Design physical device components through systematic development phases ensuring safety and regulatory compliance.
## Summary
The Hardware Design and Development Plan establishes your systematic approach to designing, building, and validating the physical components of your medical device, ensuring regulatory compliance through structured development phases, risk management, and comprehensive verification activities.
## Why is a Hardware Design and Development Plan Important?
A comprehensive Hardware Design and Development Plan provides the **regulatory framework** for medical device hardware development. Without this structured approach, hardware development becomes disorganized and reactive, leading to **design inconsistencies**, **regulatory gaps**, and **costly rework** that can delay market entry and increase development costs.
This plan transforms regulatory requirements into **actionable development activities** that guide your team through critical processes like **materials selection**, **component sourcing**, **prototype development**, and **manufacturing transfer**. It establishes clear expectations for all team members while ensuring your hardware development follows regulatory standards and quality requirements.
Medical device hardware must operate reliably in its intended environment while maintaining safety and effectiveness throughout its service life. The plan defines the **verification activities** needed to validate design decisions and the **documentation requirements** to demonstrate compliance with regulatory standards. This structured approach ensures your hardware development generates the evidence needed for regulatory submissions and market approval.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), the FDA requires:
* **Documented development planning** describing design activities and responsibilities
* **Systematic approach** to materials selection with biocompatibility considerations
* **Component-level and system-level verification** activities
* **Design review milestones** with documented decisions and rationale
* **Risk management integration** throughout the design process
* **Design transfer to manufacturing** with appropriate controls
Key FDA expectations for hardware include:
* Materials biocompatibility per ISO 10993 series
* Electrical safety per IEC 60601-1 (if applicable)
* Mechanical safety and durability testing
* Environmental testing for intended use conditions
* Design History File (DHF) documentation
**Special attention required for:**
* Biocompatibility testing for materials in patient contact - testing requirements vary by contact type and duration
* Electrical safety for powered devices - comprehensive testing per IEC 60601-1 and related standards
* Sterilization validation if device requires sterile presentation
* Shelf life and packaging validation for stability and sterility maintenance
Under **EU MDR 2017/745**, Annex I establishes General Safety and Performance Requirements (GSPRs) that directly impact hardware design:
* **Materials selection and biocompatibility** (Section 10.1) per ISO 10993 series
* **Chemical, physical, and biological properties** (Section 10.2)
* **Mechanical safety** (Section 10.3) including durability and reliability
* **Electrical safety** (Section 10.4) per harmonized standards
* **Protection against radiation** (Section 10.5) if applicable
The MDR requires structured design approach with:
* Design planning for all hardware components
* Risk management per ISO 14971 throughout development
* Comprehensive verification and validation activities
* Complete technical documentation per Annex II
* Design transfer to production with process validation
**Special attention required for:**
* Clinical evaluation requirements for hardware components that affect clinical performance
* Post-market surveillance planning for hardware reliability and safety monitoring
* Unique Device Identification (UDI) requirements for hardware components
* Person Responsible for Regulatory Compliance (PRRC) oversight of hardware changes
## Guide
Your Hardware Design and Development Plan must establish a comprehensive framework that addresses all aspects of medical device hardware development while ensuring regulatory compliance and product quality.
### Device Scope and Requirements Definition
Begin by clearly documenting your **device's physical boundaries and components**. Define functional and performance requirements, user interface specifications, environmental operating conditions, and expected service life. Establish compatibility requirements with other devices or systems and document any special handling or storage requirements.
Ensure **user needs and design inputs** are fully established before detailed hardware design begins. These inputs drive all subsequent design decisions and verification activities. Document requirements for materials, manufacturing processes, and quality characteristics that affect device safety and performance.
### Team Structure and Resource Planning
Establish your **multidisciplinary development team** with clear roles and responsibilities. Mechanical engineers handle structural design and materials selection. Electrical engineers manage circuit design and power systems. Materials engineers assess biocompatibility and environmental compatibility. Manufacturing engineers ensure design for manufacturability and process development.
Document **resource requirements** including facilities, equipment, and external consultants. Define coordination methods between disciplines and establish key stakeholders with decision-making authority. Plan for regulatory affairs involvement throughout development to ensure compliance considerations are integrated early.
### Development Phases and Methodology
Define your **development lifecycle approach** whether waterfall, stage-gate, or hybrid methodologies. Establish major phases typically including conceptual design, preliminary design, detailed design, prototype development, verification testing, and design transfer to manufacturing.
For each phase, document **required activities, inputs, outputs, and review criteria**. Conceptual phase focuses on concept generation and feasibility assessment. Preliminary design develops detailed specifications and initial prototypes. Detailed design produces final drawings and specifications. Verification phase validates design through comprehensive testing.
### Risk Management Integration
Integrate **risk management activities** throughout hardware development following ISO 14971. Conduct initial risk assessment during conceptual design, update risk analysis as design evolves, implement risk controls through design features, and verify control effectiveness through testing and analysis.
Document **risk analysis methods** appropriate for hardware components including failure mode and effects analysis (FMEA), fault tree analysis, and hazard analysis. Maintain traceability between identified hazards, implemented risk controls, and verification activities that demonstrate control effectiveness.
### Verification and Testing Strategy
Establish **comprehensive verification activities** appropriate to your device classification and risk profile. Component-level testing validates individual parts and materials. System-level testing verifies integrated performance and safety. Environmental testing confirms operation under specified conditions.
Define **testing methods and acceptance criteria** for mechanical integrity, electrical safety, biocompatibility, environmental resistance, and functional performance. Document prototype testing procedures, production verification requirements, and ongoing quality control testing. Establish criteria for test pass/fail decisions and procedures for handling non-conformances.
### Materials and Component Management
Document **materials selection criteria** including biocompatibility requirements, mechanical properties, environmental resistance, and manufacturing compatibility. Establish supplier qualification procedures and component specification requirements. Plan for materials testing and certification activities.
Address **biocompatibility assessment** per ISO 10993 series based on device contact type and duration. Plan for chemical characterization, biological evaluation, and toxicological risk assessment as appropriate. Document sterilization compatibility if applicable.
### Design Transfer and Manufacturing
Define **design transfer activities** that transition development outputs to manufacturing. Develop production specifications, manufacturing process requirements, and quality control procedures. Plan pilot production activities and process validation requirements.
Establish **manufacturing feasibility considerations** early in design to ensure producibility at scale. Document design for manufacturing and assembly requirements. Plan for production equipment qualification and first article inspection procedures.
### Configuration Management
Implement **design change control processes** that assess proposed changes for impact on safety, performance, and regulatory compliance. Define approval requirements based on change significance and document change rationale and verification activities.
Establish **document control procedures** for drawings, specifications, and design records. Implement revision control for components and assemblies. Maintain bill of materials accuracy and traceability between design inputs and outputs.
## Example
**Scenario:** You're developing a wearable stress monitoring device with an ankle strap that houses sensors, electronics, and a battery. The device must be waterproof, comfortable for extended wear, and biocompatible for skin contact. Hardware failure could lead to skin irritation or device malfunction but would not cause serious injury.
### Hardware Design and Development Plan
**ID:** HDDP-StressWear-2024-001
**1. Scope and Classification**
This plan covers the physical components of the StressWear ankle strap including housing, sensors, electronics, battery, and strap materials. The device is classified as Class IIa under EU MDR and Class II under FDA regulations. Hardware components require biocompatibility assessment for skin contact and IP67 water resistance rating.
**2. Team Structure and Responsibilities**
* **Mechanical Engineering:** Housing design, waterproofing systems, strap ergonomics, mechanical interfaces, drop testing
* **Electrical Engineering:** Circuit design, sensor integration, power management, signal processing, EMC compliance
* **Materials Engineering:** Biocompatibility assessment, materials selection, adhesive systems, environmental testing
* **Manufacturing Engineering:** Design for manufacturability, process development, tooling design, quality control procedures
* **Quality Assurance:** Design reviews, verification oversight, documentation compliance, supplier audits
* **Regulatory Affairs:** Standards compliance, biocompatibility strategy, regulatory submission preparation
**3. Development Phases**
**Phase 1 - Conceptual Design:**
* Activities: Concept generation, feasibility assessment, preliminary risk analysis, user needs validation
* Deliverables: Concept description, feasibility study, preliminary risk assessment, design inputs specification
* Review Criteria: Concept viability, user needs alignment, technical feasibility, regulatory pathway clarity
**Phase 2 - Preliminary Design:**
* Activities: Materials selection, component specification, preliminary CAD models, initial prototyping
* Deliverables: Preliminary 3D models, materials list, component specifications, prototype units
* Review Criteria: Design concept validation, materials compatibility, manufacturing feasibility
**Phase 3 - Detailed Design:**
* Activities: Final CAD models, engineering drawings, tolerance analysis, design optimization
* Deliverables: Complete 3D models, engineering drawings package, bill of materials, assembly procedures
* Review Criteria: Design completeness, manufacturing readiness, regulatory compliance
**Phase 4 - Verification and Validation:**
* Activities: Prototype testing, verification testing, design validation, manufacturing process development
* Deliverables: Verification test reports, validation results, process specifications, quality procedures
* Review Criteria: Performance verification, safety validation, manufacturing capability
**Phase 5 - Design Transfer:**
* Activities: Production setup, process validation, first article inspection, quality system implementation
* Deliverables: Production specifications, validated processes, quality control procedures, transfer documentation
* Review Criteria: Manufacturing capability, quality system effectiveness, regulatory readiness
**4. Verification Activities**
**Mechanical Testing:**
* Drop testing per IEC 60068-2-32 (1.5m drops on concrete)
* Vibration testing per IEC 60068-2-6 (transportation and use)
* Compression testing for strap durability (10,000 cycles)
* Waterproofing validation per IP67 standard (1m depth, 30 minutes)
**Electrical Testing:**
* EMC testing per IEC 60601-1-2 (electromagnetic compatibility)
* Electrical safety per IEC 60601-1 (if applicable)
* Battery safety per IEC 62133 (lithium battery safety)
* Sensor calibration and accuracy verification
**Biocompatibility Testing:**
* Cytotoxicity testing per ISO 10993-5 (skin contact materials)
* Sensitization testing per ISO 10993-10 (allergic response)
* Irritation testing per ISO 10993-10 (skin irritation potential)
* Chemical characterization per ISO 10993-18
**Environmental Testing:**
* Temperature cycling per IEC 60068-2-14 (-10°C to +50°C)
* Humidity testing per IEC 60068-2-78 (85% RH, 40°C)
* Salt spray testing per IEC 60068-2-52 (corrosion resistance)
* UV exposure testing per ISO 4892 (material degradation)
**5. Risk Management**
Risk assessment focuses on:
* **Skin contact safety:** Material biocompatibility, allergic reactions, mechanical irritation
* **Electrical safety:** Battery failure, charging safety, electromagnetic interference
* **Mechanical integrity:** Housing failure, water ingress, strap breakage
* **Data security:** Wireless communication security, data encryption
* **Use environment:** Temperature extremes, moisture exposure, physical impacts
**6. Materials and Components**
**Housing Materials:**
* Medical grade silicone (USP Class VI) for skin contact surfaces
* Polycarbonate for structural components
* Stainless steel for electronic shielding
**Electronic Components:**
* Lithium polymer battery with protection circuit
* Bluetooth Low Energy communication module
* Accelerometer and heart rate sensors
* Waterproof connectors and seals
**7. Design Transfer Requirements**
* Manufacturing process validation for injection molding
* Assembly procedure validation and training
* Quality control procedure implementation
* Supplier qualification and ongoing monitoring
* First article inspection and approval
* Production equipment qualification
## Q\&A
Biocompatibility testing depends on **contact type and duration**. For limited skin contact (≤24 hours), conduct cytotoxicity and sensitization testing per ISO 10993-5 and 10993-10. For prolonged contact (>24 hours to 30 days), add irritation testing. For permanent contact (>30 days), include systemic toxicity and implantation testing. All skin-contact materials require chemical characterization per ISO 10993-18. Consider additional testing for specific patient populations or if materials contain known sensitizers.
Environmental testing should reflect your device's **intended use conditions and transportation/storage requirements**. Review your intended use statement and user needs to identify temperature ranges, humidity levels, and physical stresses. Consider transportation conditions from manufacturing to end use. Reference IEC 60068 series standards for standardized test methods. For medical devices, common tests include temperature cycling, humidity exposure, vibration, and drop testing. Document rationale for test conditions and acceptance criteria based on clinical use requirements.
Include **detailed specifications for all critical components** that affect safety, performance, or regulatory compliance. Document electrical parameters, mechanical dimensions, material properties, environmental ratings, and special requirements like biocompatibility or sterilization compatibility. For each critical component, specify supplier requirements, incoming inspection criteria, and change control procedures. Non-critical components can have less detailed specifications but should still include basic performance and quality requirements.
Establish a **formal change control process** that evaluates each proposed change for impact on safety, performance, cost, and schedule. Define change categories (minor, major, critical) with appropriate approval levels. Document change rationale, impact assessment, and verification requirements. For medical devices, consider regulatory implications of changes - some may require notified body notification or additional testing. Maintain design history and traceability between original requirements and final design through all changes.
Plan for **design for manufacturability (DFM)** early in development. Consider material availability, manufacturing process capabilities, tooling requirements, and quality control methods. Document assembly procedures, inspection requirements, and process validation needs. Plan for supplier qualification and ongoing monitoring. Consider manufacturing scale-up requirements and capacity planning. Include cost considerations and design optimization for production efficiency while maintaining quality and regulatory compliance.
Establish **clear interface definitions** between hardware and software components early in development. Define communication protocols, power requirements, and physical interfaces. Create joint development milestones where hardware and software teams must coordinate. Plan integration testing that validates hardware-software interfaces. Document dependencies and critical path activities that affect both domains. Ensure both hardware and software development plans reference each other and include coordination points for design reviews and testing activities.
# Incident Assessment Form
Source: https://docs.withdovetail.com/tasks/incident-assessment-form
Evaluate device incidents systematically determining regulatory reporting requirements and actions.
## Summary
The Incident Assessment Form systematically evaluates whether an event with potentially negative health impacts constitutes a **serious and reportable incident** under medical device vigilance regulations. You use this form to determine if an incident meets the three basic reporting criteria and requires formal notification to competent authorities.
## Why is the Incident Assessment Form important?
Medical device incidents can cause patient harm, device recalls, and regulatory action that threatens your market access. The Incident Assessment Form provides a **structured decision-making framework** that ensures you properly classify events and comply with vigilance reporting requirements. This systematic approach protects patients, maintains regulatory compliance, and demonstrates your commitment to post-market safety monitoring. Without proper incident assessment, you risk under-reporting serious events or over-reporting minor issues, both of which can lead to regulatory scrutiny and lost stakeholder confidence.
## Regulatory Context
Under **21 CFR Part 803** (Medical Device Reporting):
* Manufacturers must report **device malfunctions** that could cause or contribute to death or serious injury if the malfunction were to recur
* **Death or serious injury** reports must be submitted within 24 hours to FDA and the user facility
* **Malfunction-only** reports must be submitted within 30 days to FDA
* Reports must include remedial action taken or planned by the manufacturer
**Special attention required for:**
* Software malfunctions that affect device safety or effectiveness
* Use-errors due to inadequate labeling or training materials
* Device-device interactions in connected systems
* Cybersecurity incidents affecting device functionality
Under **EU MDR 2017/745**:
* **Serious incidents** must be reported immediately via EUDAMED (Article 87)
* Incidents must be evaluated using the **three-criteria test** (Article 2(64-65))
* **Field Safety Corrective Actions** may be required based on incident severity (Article 89)
* Must comply with **MDCG 2023-3** guidance for incident reporting
**Special attention required for:**
* Events occurring during clinical investigations (Article 80-82)
* Incidents involving multiple devices or manufacturers
* Software updates that could affect device safety or performance
* Post-market clinical follow-up findings that reveal new risks
## Guide
### Understanding Incident Classification
**An incident** includes any malfunction, deterioration in device characteristics, use-error due to ergonomic features, inadequate manufacturer information, or undesirable side-effects. Not every incident requires reporting - you must determine if it qualifies as a **serious incident**.
### The Three-Criteria Test
You must evaluate every incident against these three mandatory criteria:
**Criterion A**: Does the event meet the definition of an incident according to regulatory requirements? This includes device malfunctions, performance deterioration, use-errors, or inadequate information that affects device safety or effectiveness.
**Criterion B**: Did the incident directly or indirectly lead to, might have led to, or might lead to death, serious deterioration in health, or serious public health threat? Consider both actual outcomes and potential consequences if the incident recurred.
**Criterion C**: Has a causal relationship between the incident and your device been established, is reasonably possible, or is suspected? You don't need definitive proof - reasonable possibility or suspicion is sufficient.
### Completing the Assessment
**Document the event details** systematically, including when and where it occurred, which product version was involved, and what actions you plan to take. If the incident involves multiple users or locations, document each occurrence separately.
**Identify planned actions** such as Field Safety Corrective Actions (FSCA), software updates, or label changes. Specify which competent authorities require notification based on where the incident occurred and where your device is marketed.
**Make the reporting decision** based on your three-criteria evaluation. If all three criteria are met, you must report the incident. If any criterion is not met, document your reasoning and retain the assessment for your records.
### Integration with Quality Management
Your incident assessment must connect to your **CAPA system** for systematic issues requiring corrective action. Link assessments to your **post-market surveillance** activities to identify trends and patterns. Update your **risk management file** when incidents reveal previously unidentified hazards.
## Example
**Scenario**: Your mobile ECG monitoring app crashes during a critical heart rhythm analysis for a patient with known cardiac risk factors. The crash prevents the completion of the analysis, and the patient seeks emergency medical care later that evening due to chest pains. You receive this report through your customer feedback system and must determine if it constitutes a reportable incident.
### Example Incident Assessment Form
**Document ID**: IAF-2024-003
#### Section 1: Incident Qualification
| Criteria | Response |
| ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Does the event meet the definition of an incident according to Art. 2(64) MDR? | **Yes** - Software malfunction preventing completion of intended analysis |
| Does the incident directly or indirectly lead to serious outcomes? | **Deterioration of state of health** - Patient required emergency medical care |
| Has causal relationship been established or is suspected? | **Yes** - App failure prevented timely cardiac assessment |
| Explanation | The software crash constituted a malfunction that prevented the device from completing its intended ECG analysis. While the patient's emergency care was not directly caused by the device failure, the inability to complete the cardiac assessment may have contributed to delayed recognition of the patient's condition. |
| Is this considered a reportable incident? | **Yes** - All three criteria are met |
#### Section 2: Incident Assessment Report
| Category | Information |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Event Description** | Mobile ECG app (v2.3.1) crashed during heart rhythm analysis at 14:32 on March 15, 2024. Error code: "Memory allocation failure during signal processing." Patient was analyzing 30-second ECG recording when app terminated unexpectedly. |
| **Source of Event** | Customer complaint via support email, confirmed by device logs uploaded automatically |
| **Location of Event** | Patient's home in Munich, Germany |
| **Date and Time Event Reported** | March 16, 2024 at 09:15 CET via customer support |
| **Product and Version Affected** | CardioWatch Mobile App v2.3.1, Build 2024.03.01 |
| **Planned Actions** | **Immediate**: Release hotfix v2.3.2 addressing memory allocation issue. **FSCA**: Issue Field Safety Notice to all users recommending app update. **Preventive**: Implement additional memory management testing in QA processes. |
| **Relevant Competent Authorities** | BfArM (Germany) - primary incident location; ANSM (France), AIFA (Italy) - other EU markets where device is sold |
## Q\&A
If you identify a new risk during vigilance database review, add it to your risk assessment to ensure all foreseeable risks are properly documented. Update your risk management file and consider whether additional risk controls are needed for your device.
Examine all complaints for product performance and safety issues. Significant complaints should be recorded in your complaint log, and serious ones should be evaluated using the incident assessment form. Minor complaints that can be resolved with instructions typically don't require formal incident assessment.
Reportable incidents must meet all three basic criteria: qualify as an incident, lead to or potentially lead to serious outcomes, and have an established or suspected causal relationship with your device. Non-reportable events fail to meet one or more of these criteria but should still be documented for your records and post-market surveillance activities.
Begin incident assessment immediately upon receiving a report. For potentially serious incidents, complete your initial assessment within 24 hours to determine if immediate reporting is required. You can supplement your assessment with additional information as your investigation continues.
Software malfunctions constitute incidents when they affect device safety, effectiveness, or performance. Minor software bugs that don't impact the device's intended use or patient safety may not qualify as incidents. Consider the potential consequences and whether the malfunction could affect clinical decision-making or patient care.
# Instructions For Use
Source: https://docs.withdovetail.com/tasks/instructions-for-use
Provide comprehensive guidance ensuring safe effective device operation with regulatory compliance.
## Summary
Instructions for Use (IFU) is the **primary user-facing document** that provides comprehensive guidance for safe and effective device operation. Your IFU must include device identification, intended purpose, safety information, operational instructions, and regulatory compliance details. This document serves as the critical communication link between your device and its users, ensuring they have all necessary information to operate your device safely and effectively.
## Why is Instructions for Use important?
The Instructions for Use document is **legally mandated** by both FDA and EU MDR regulations as the primary means of communicating essential device information to users. Inadequate or missing instructions are a leading cause of medical device incidents and user errors that can result in patient harm. Your IFU serves as the **final safety barrier** between your device and potential adverse events.
Regulatory authorities require comprehensive IFU because users must understand device limitations, proper operation procedures, and safety precautions before using any medical device. Without proper instructions, your device cannot be legally marketed, and you face significant liability if users are harmed due to inadequate information. The IFU also demonstrates your commitment to user safety and regulatory compliance to notified bodies and FDA reviewers.
## Regulatory Context
Under **21 CFR Part 801** (Labeling):
* Instructions must be **adequate for intended use** (801.5)
* Must include **directions for use** and **warnings** (801.15)
* Software devices require **cybersecurity information** per FDA guidance
* Must comply with **UDI labeling requirements** (21 CFR Part 830)
* Language must be **understandable to intended users**
**Special attention required for:**
* Prescription device labeling requirements (801.109) vs. over-the-counter devices
* Software as Medical Device (SaMD) specific instructions and warnings
* Combination product labeling coordination requirements
* 510(k) consistency with predicate device instructions
Under **EU MDR 2017/745 GSPR 23.1**:
* Must be provided **with each device** or available electronically
* Must include **intended purpose, contraindications, warnings**
* Required in **official language** of target market (Article 10.11)
* Electronic IFU allowed under **specific conditions** (GSPR 23.1.s)
* Must enable **traceability** through UDI information
**Special attention required for:**
* Electronic IFU implementation requirements - website availability and accessibility
* Authorized representative information for non-EU manufacturers
* Class-specific requirements for implantable devices (GSPR 23.2)
* Post-market surveillance contact information requirements
## Guide
### Document Structure and Content
Your **IFU header section** must include device name exactly as registered, manufacturer name and complete address, UDI Product Identifier (UDI-PI), software version for software devices, release or manufacture date, and CE marking or FDA clearance information. This identification section enables proper device traceability and regulatory compliance verification.
The **device description section** provides users with essential understanding of your device's purpose and capabilities. Include your intended purpose statement exactly as defined in your regulatory submission, indications for use that specify the target patient population and clinical conditions, device functionality explanation in user-friendly language, and compatibility requirements including minimum system specifications for software devices.
**User information** helps users understand if the device is appropriate for their situation. Define your intended user profile including healthcare providers, patients, or caregivers, specify any required training or qualifications, list contraindications that identify when the device should not be used, and describe the patient population or clinical scenarios where the device is intended for use.
### Safety Information Requirements
Your **warnings and precautions section** forms the core of user safety communication. Include all warnings derived from your risk analysis and risk controls, precautions that users must take to avoid potential hazards, information about known side effects or adverse events, and clear instructions for emergency situations or device malfunctions. This information must be prominently displayed and easily understood by your intended users.
**Contraindications** must clearly identify situations where device use is inappropriate or dangerous. Base these on your clinical evaluation, risk analysis findings, and known limitations of your device technology. Present contraindications in clear, unambiguous language that users can easily understand and apply to their specific situation.
### Operational Instructions
**Setup and installation guidance** should provide step-by-step instructions for device preparation and initial configuration. For software devices, include download and installation procedures, account creation and verification steps, initial device setup and calibration, and integration with other systems or devices if applicable. Use clear, sequential steps with visual aids when helpful.
**User instructions** must be comprehensive enough for safe device operation without additional training unless specifically required. Provide detailed operational procedures for all device functions, troubleshooting guidance for common issues, maintenance or care instructions if applicable, and data management procedures including backup and security measures for software devices.
### Technical and Support Information
**Technical specifications** help users ensure compatibility and proper device performance. Include minimum system requirements for software devices, hardware specifications for physical devices, network or connectivity requirements, and storage or environmental requirements. Present technical information in user-friendly language while maintaining accuracy.
**Support and contact information** ensures users can access help when needed. Provide technical support contact details including phone, email, or website, adverse event reporting procedures and contact information, manufacturer contact information for regulatory inquiries, and website location for updated instructions or additional resources.
### Electronic IFU Implementation
**Electronic Instructions for Use (eIFU)** can replace paper instructions under specific regulatory conditions. You must ensure your target user group has reliable access to electronic devices and internet connectivity, provide the complete website URL on your device label, maintain website availability throughout your device's commercial lifetime, and offer paper copies upon request at no additional cost to users.
Your **eIFU website** must provide direct access to current instructions without requiring user registration, maintain version control to ensure users access the most current information, comply with accessibility standards for users with disabilities, and include backup systems to ensure continuous availability. The electronic format must not compromise user access to critical safety information.
### Translation and Localization
**Language requirements** mandate that user-facing instructions be provided in the official language of each target market. Begin with a comprehensive English master document that serves as your source for all translations. Professional medical translation services ensure regulatory compliance and technical accuracy while maintaining consistency across markets.
**Quality assurance** for translations includes back-translation verification to ensure accuracy, regulatory review by local experts familiar with market-specific requirements, consistency checks across all translated materials and related documents, and regular updates when source documents change. Maintain strict version control across all language versions to ensure regulatory compliance.
## Example
**Scenario:** You develop a mobile application called "CardioMonitor Pro" that analyzes heart rhythm data from wearable devices and provides arrhythmia detection alerts for patients with known cardiac conditions.
### Device Identification Section
**CardioMonitor Pro**\
IFU Release Date: March 15, 2024
\| Medical Device Symbol | Software Version 3.2.1 |
\| CE Marking | Release Date: March 15, 2024 |
\| UDI-PI: 01234567890123 | Manufacturer: HeartTech Solutions |
\| | 123 Medical Device Lane, Boston, MA 02101 |
### Device Description
**Intended Purpose:** CardioMonitor Pro is intended for use by adults with known cardiac arrhythmias to monitor heart rhythm patterns and receive alerts for potential arrhythmic events detected from compatible wearable heart rate monitors.
**Indications for Use:** This device is indicated for patients aged 18 and older with diagnosed atrial fibrillation, atrial flutter, or other cardiac arrhythmias who require continuous rhythm monitoring as part of their cardiac care management.
**Device Functionality:** The application continuously analyzes heart rhythm data from connected wearable devices, applies FDA-cleared algorithms to detect irregular patterns, and provides real-time alerts when potential arrhythmic events are identified.
**Device Compatibility Requirements:**
* iOS 14.0 or later / Android 10.0 or later
* Minimum 2GB available storage
* Bluetooth 5.0 capability
* Compatible with FDA-cleared heart rate monitors: FitBit Sense, Apple Watch Series 6 or later, Garmin Vivosmart 5
### Safety Information
**Contraindications:**
* Not intended for patients under 18 years of age
* Not suitable for patients without previously diagnosed cardiac arrhythmias
* Do not use during pregnancy without physician consultation
* Not intended for emergency cardiac event detection
**Warnings and Precautions:**
* This device does not replace regular medical care or emergency services
* Consult your healthcare provider before making treatment changes based on device alerts
* Seek immediate medical attention for chest pain, shortness of breath, or other cardiac symptoms
* Device alerts may have false positives or miss some arrhythmic events
* Ensure wearable device is properly fitted and charged for accurate readings
### User Instructions
**Installation and Setup:**
1. Download CardioMonitor Pro from official app store using provided QR code
2. Create secure account using email verification process
3. Complete medical history questionnaire as guided by setup wizard
4. Connect compatible heart rate monitor via Bluetooth pairing
5. Calibrate device according to wearable manufacturer instructions
6. Set personalized alert preferences with healthcare provider guidance
**Daily Operation:**
1. Ensure wearable device is charged and properly positioned
2. Open CardioMonitor Pro to verify connection status
3. Review daily rhythm summary and any overnight alerts
4. Respond to real-time alerts by following provided guidance
5. Share weekly reports with healthcare provider as recommended
**Technical Assistance:** For technical support, visit [www.hearttechsolutions.com/support](http://www.hearttechsolutions.com/support) or call 1-800-CARDIO-1 (1-800-227-3461)
**Adverse Event Reporting:** Report any serious incidents to FDA MedWatch at [www.fda.gov/medwatch](http://www.fda.gov/medwatch) or HeartTech Solutions at [safety@hearttechsolutions.com](mailto:safety@hearttechsolutions.com)
## Q\&A
Yes, electronic Instructions for Use (eIFU) are permitted under specific regulatory conditions. You must ensure your target users have reliable access to electronic devices and internet, provide the complete website URL on your device label, maintain website availability throughout your device's commercial lifetime, and offer paper copies upon request at no cost. The eIFU website must provide direct access without requiring registration and comply with accessibility standards for users with disabilities.
User instructions must be comprehensive enough for safe device operation without additional training unless specifically required by your risk analysis. Include step-by-step procedures for all device functions, troubleshooting guidance for common issues, and clear explanations of any technical requirements. The level of detail should match your intended user's technical expertise while ensuring safety and effectiveness. When in doubt, provide more detail rather than less to prevent user errors.
Include all warnings derived from your risk analysis and risk controls, precautions users must take to avoid identified hazards, information about known side effects or limitations, and clear emergency procedures. Base warnings on your clinical evaluation findings, known device limitations, and potential user errors identified during usability testing. Present safety information prominently and in language appropriate for your intended users.
Contraindications should be based on your clinical evaluation, risk analysis findings, and known limitations of your device technology. Include patient populations for whom the device is inappropriate, clinical conditions where device use could be harmful, and situations where device limitations could compromise safety. Present contraindications in clear, unambiguous language that users can easily understand and apply to their specific circumstances.
Include minimum system requirements such as operating system versions, memory and storage requirements, network connectivity needs, and compatibility with other devices or systems. Specify any hardware requirements like camera, microphone, or sensor access. Present technical information in user-friendly language while maintaining accuracy. Include troubleshooting guidance for common technical issues and contact information for technical support.
Customize your IFU based on your intended user profile while maintaining all regulatory requirements. For healthcare providers, include more technical detail and clinical context. For patients, focus on practical operation steps and safety information in accessible language. You can create separate documents for different user groups or a single comprehensive document with clearly marked sections. Ensure each version meets core regulatory criteria for its intended audience.
# Intended Use
Source: https://docs.withdovetail.com/tasks/intended-use
Define precise medical purpose and application scope determining regulatory classification and testing requirements.
## Summary
**Intended use** defines the specific purpose, medical indication, and application for which your medical device is designed and marketed. This foundational document establishes the scope of your device's functionality and directly determines your regulatory classification, required testing, and submission pathway. Your intended use statement must be precise, defensible with data, and will appear in your instructions for use.
## Why is Intended Use Important?
Intended use is the **cornerstone of medical device regulation** because it determines everything that follows in your certification process. Regulatory authorities use your intended use to classify your device, establish testing requirements, and evaluate safety and effectiveness. A well-defined intended use protects you from regulatory scope creep while ensuring you can defend every claim with appropriate evidence. Your intended use statement becomes legally binding and must be supported by your clinical evaluation, risk management, and verification testing.
## Regulatory Context
Under **21 CFR 801.4** and **21 CFR 814.20(b)(3)**:
* Intended use determines **device classification** and regulatory pathway (510(k), PMA, De Novo)
* Must be clearly stated in **labeling and instructions for use**
* Drives **predicate device selection** for substantial equivalence claims
* Establishes scope for **clinical data requirements** and testing protocols
**Special attention required for:**
* Software medical devices - intended use affects algorithm validation requirements
* AI/ML devices - must specify learning capabilities and clinical decision support level
* Combination products - intended use must address each component's function
* Novel devices - may require De Novo pathway if no appropriate predicate exists
Under **EU MDR 2017/745**:
* Article 2(12) defines intended purpose as the **basis for classification** under Annex VIII
* Must be documented in **technical documentation** (Annex II, Section 1.1)
* Drives **conformity assessment** procedure selection and notified body involvement
* Establishes scope for **clinical evaluation** under Article 61
**Special attention required for:**
* Software medical devices - MDCG 2019-11 guidance on qualification and classification
* AI systems - must specify autonomous vs. semi-autonomous decision-making
* Borderline products - MDCG 2022-5 guidance for medical device vs. non-medical device determination
* Class III devices - intended purpose must justify high-risk classification
## Guide
Your intended use document must comprehensively define your device's purpose and application. **Start with your core functionality** - what does your device actually do? Describe the medical condition or clinical need it addresses, but avoid overpromising capabilities you cannot defend with data.
**Define your medical indication clearly.** Specify the disease, condition, or physiological parameter your device monitors, diagnoses, treats, or prevents. Use established medical terminology and avoid vague language. Your indication must align with your clinical evaluation and any claims you make.
**Identify your patient population precisely.** Include relevant demographics, health conditions, and any exclusions. Consider age ranges, disease severity, comorbidities, and other factors that affect device use. Your patient population drives your clinical evaluation requirements and risk assessment.
**Describe your user profile in detail.** Specify who will operate your device - healthcare professionals, patients, or caregivers. Include required training, qualifications, or competencies. Your user profile affects your usability requirements and instructions for use.
**Document your use environment comprehensively.** Describe where and how your device will be used - hospital, clinic, home, ambulatory setting. Include environmental conditions, required infrastructure, and any supporting equipment or software. Your use environment affects your design requirements and risk assessment.
**Explain your operating principle clearly.** Describe how your device works at a high level without revealing proprietary details. Include input data, processing methods, and output information. Your operating principle must be consistent with your technical documentation and risk analysis.
**Specify body interaction if applicable.** If your device contacts the body, describe the anatomical location, tissue type, and nature of contact. This information drives your biocompatibility requirements and classification under MDR Annex VIII rules.
**Address variants and accessories appropriately.** Document any different configurations, optional features, or accessories that are part of your device system. Each variant may require separate consideration for classification and testing.
## Example
### Complete Intended Use Document
**Intended Use**
ID: IU-2024-001
### Product
* Name: CardioWatch Pro
### Intended Use / Intended Purpose
CardioWatch Pro is a wearable medical device intended for continuous monitoring and recording of heart rate and heart rhythm in adults (18 years and older) in home and clinical settings. The device provides real-time heart rate measurements and stores electrocardiogram (ECG) data for healthcare provider review to support clinical decision-making in patients with known or suspected cardiac arrhythmias.
### Intended Medical Indication
Monitoring of heart rate and rhythm in adult patients with diagnosed or suspected cardiac arrhythmias, including atrial fibrillation, premature ventricular contractions, and bradycardia. The device is intended to detect and record irregular heart rhythms for healthcare provider evaluation and does not provide automated diagnosis or treatment recommendations.
### Contraindications
* Patients under 18 years of age
* Patients with implanted cardiac devices (pacemakers, ICDs) without physician approval
* Patients with known allergies to device materials (silicone, stainless steel)
* Use during MRI procedures
* Use in patients requiring continuous cardiac monitoring in critical care settings
### Patient Population
Adult patients (18 years and older) with known or suspected cardiac arrhythmias who require intermittent or continuous heart rhythm monitoring outside of hospital settings. This includes patients with atrial fibrillation, patients on antiarrhythmic medications, and patients experiencing symptoms suggestive of cardiac arrhythmias such as palpitations, dizziness, or syncope.
### User Profile
Primary users are adult patients capable of operating a wearable device and following basic instructions. Secondary users are healthcare providers (physicians, nurses, cardiac technicians) who review recorded data and provide clinical interpretation. Patients must be able to charge the device, wear it properly, and use the companion mobile application for data synchronization.
### Use Environment Including Software/Hardware
The device is intended for use in home, clinic, and ambulatory settings. The wearable sensor operates in normal indoor and outdoor environments (temperature range 10-40°C, humidity 15-85% non-condensing). The system requires a compatible smartphone (iOS 14+ or Android 10+) with Bluetooth connectivity for data transmission and a secure cloud platform for data storage and healthcare provider access.
### Operating Principle
CardioWatch Pro uses a single-lead ECG sensor with dry electrodes to detect electrical activity of the heart. The device continuously samples cardiac signals at 250 Hz, applies digital filtering to remove artifacts, and calculates heart rate using R-wave detection algorithms. ECG waveforms are stored locally and transmitted via Bluetooth to a mobile application, which uploads data to a secure cloud platform for healthcare provider review through a web-based dashboard.
### Part of the Body / Type of Tissue Interacted With
The device contacts intact skin on the chest area through dry metal electrodes (stainless steel). Contact is non-invasive and limited to the external surface of the skin. The device does not penetrate the skin or contact internal body structures.
### Variants / Accessories
CardioWatch Pro is available in three sizes (Small, Medium, Large) to accommodate different chest circumferences. The system includes a charging dock, mobile application (iOS/Android), and web-based healthcare provider dashboard. No additional accessories are required for normal operation.
## Q\&A
Your intended use should be **specific enough to be defensible** but not so narrow that it limits your market unnecessarily. Include the medical condition, patient population, and clinical purpose, but avoid overly technical details that belong in your technical documentation. Every claim in your intended use must be supported by your clinical evaluation and testing data.
**Yes, but with significant regulatory implications.** Changes to intended use may require a new submission, additional clinical data, or reclassification of your device. Document any changes thoroughly and consult with regulatory authorities or your notified body before implementation. Minor clarifications may be acceptable, but substantial changes typically require new regulatory review.
Intended use is the **primary factor** in device classification. The FDA uses intended use to determine your product code and class, while the EU MDR uses intended purpose to apply Annex VIII classification rules. A broader intended use may result in higher classification and more stringent requirements, while a narrower intended use may allow for lower classification but limits your market scope.
Your device **must not exceed your stated intended use** in its labeling, marketing, or functionality. If your device has additional capabilities, you must either include them in your intended use (with appropriate regulatory support) or disable/hide them. Operating outside your intended use constitutes off-label use and may create regulatory and liability issues.
Software medical devices require **particularly precise intended use statements** that specify the type of clinical decision support provided. Clearly state whether your software provides information to healthcare providers, makes recommendations, or enables autonomous decision-making. Reference MDCG 2019-11 guidance for EU submissions and FDA Software as Medical Device guidance for US submissions.
**Yes, contraindications are essential** for defining the safe use boundaries of your device. Include patient populations, conditions, or circumstances where your device should not be used. Contraindications help establish your risk-benefit profile and protect both patients and your organization from inappropriate use. They will also appear in your instructions for use and labeling.
# Interface Design
Source: https://docs.withdovetail.com/tasks/interface-design
Design user interactions and system communications ensuring safety and effective device operation.
## Summary
The Interface Design document defines how different subsystems within your medical device communicate and interact with each other, as well as how users interact with the device. This document specifies connection methods, data flows, user interface elements, and interoperability requirements essential for safe and effective device operation.
## Why is Interface Design important?
Interface design documentation is **critical for patient safety** because interfaces are common points of failure in medical devices. Poor interface design can lead to **user errors**, **communication failures**, and **system malfunctions** that directly impact patient care. Regulatory authorities require detailed interface specifications to ensure that all connections are robust, secure, and appropriate for the medical environment.
The interface design also demonstrates that you have systematically considered how users will interact with your device and how different components will work together. This documentation supports **risk management**, **usability engineering**, and **verification activities** throughout the development process.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **FDA Human Factors Guidance**:
* Interface specifications must be **documented** as design inputs
* User interfaces must consider **human factors engineering** principles
* **Interoperability** requirements must be clearly specified
* Interface designs must support **verification and validation** activities
**Special attention required for:**
* Human factors engineering for user interfaces (FDA HFE guidance)
* Cybersecurity considerations for network interfaces
* Interoperability standards (HL7, DICOM, etc.) where applicable
* Usability validation requirements for user interfaces
Under **EU MDR 2017/745** and **EN ISO 14971**:
* Interface design must comply with **General Safety and Performance Requirements**
* **Usability engineering** per IEC 62366-1 required for user interfaces
* **Risk management** must address interface-related risks
* **Interoperability** requirements per relevant harmonized standards
**Special attention required for:**
* Usability engineering process per IEC 62366-1
* Cybersecurity requirements per MDR Article 17
* Data protection considerations (GDPR) for data interfaces
* Essential requirements for user interface design and safety
## Guide
### Understanding Interface Design
Interface design encompasses **all points of interaction** within your medical device system:
* **Internal Interfaces**: How subsystems communicate with each other (software APIs, hardware connections, data protocols)
* **User Interfaces**: How users interact with your device (graphical interfaces, physical controls, displays, input methods)
* **External Interfaces**: How your device connects with other systems (networks, other medical devices, hospital systems)
### Internal Interface Specifications
Document how your subsystems connect and communicate:
* **Physical Connections**: USB, Bluetooth, Wi-Fi, wired connections, proprietary connectors
* **Data Protocols**: Communication standards, data formats, message structures
* **Timing Requirements**: Response times, synchronization needs, data transfer rates
* **Error Handling**: How interfaces detect and respond to communication failures
* **Security Measures**: Authentication, encryption, access controls for data interfaces
### User Interface Design
Your user interface documentation should address:
* **Interaction Methods**: Touch screens, physical buttons, voice commands, gesture controls
* **Information Display**: Screen layouts, visual indicators, alerts, status displays
* **User Workflows**: Step-by-step processes users follow to accomplish tasks
* **Accessibility**: Support for users with disabilities or limitations
* **Error Prevention**: Design features that prevent user mistakes
Consider the **use environment** where your device will be operated - hospital settings may require different interface approaches than home use.
### Interoperability Requirements
Document any external system connections:
* **Healthcare Networks**: Integration with Electronic Health Records (EHR), Hospital Information Systems (HIS)
* **Medical Device Networks**: Communication with other medical devices or monitoring systems
* **Cloud Services**: Data synchronization, remote monitoring, software updates
* **Regulatory Standards**: Compliance with HL7, DICOM, IHE, or other interoperability standards
### Interface Risk Considerations
Interfaces introduce specific risks that must be addressed:
* **Communication Failures**: What happens when connections are lost or data is corrupted
* **User Errors**: How interface design prevents or mitigates user mistakes
* **Cybersecurity Threats**: Protection against unauthorized access or data breaches
* **Electromagnetic Interference**: How interfaces maintain integrity in medical environments
## Example
**Scenario**: You're developing a patient monitoring system that collects vital signs from multiple sensors, displays data to clinicians, and integrates with hospital networks. Your system includes wearable sensors, a bedside monitor, and a central nursing station display.
### Interface Description
The patient monitoring system consists of three main subsystems: wearable sensors, bedside monitor, and nursing station display. Sensors communicate wirelessly with the bedside monitor using Bluetooth Low Energy. The bedside monitor processes sensor data and displays real-time vital signs while simultaneously transmitting data to the nursing station via secure Wi-Fi. The nursing station aggregates data from multiple patients and provides centralized monitoring capabilities.
### User Interface Design
**Bedside Monitor**: 15-inch touchscreen display with large, high-contrast vital signs readings visible from 3 meters. Touch interface allows clinicians to access patient history, adjust alarm thresholds, and acknowledge alerts. Physical emergency silence button provides immediate alarm muting. Interface uses color coding (green=normal, yellow=caution, red=critical) with audio alerts for abnormal readings.
**Nursing Station**: Multi-patient dashboard showing overview of all monitored patients with drill-down capability for detailed views. Keyboard and mouse input for data entry and system configuration. Priority-based alert system highlights most critical patients. Interface supports multiple user roles with appropriate access controls.
### Interface Connections
| Subsystems | Component | Interface Description |
| --------------------------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| Sensors ↔ Bedside Monitor | Bluetooth LE Module | Wireless data transmission using custom protocol over Bluetooth 5.0, encrypted with AES-128, automatic reconnection on signal loss |
| Bedside Monitor ↔ Nursing Station | Wi-Fi Network Interface | TCP/IP over WPA3-secured hospital network, JSON data format, heartbeat monitoring every 30 seconds |
| Nursing Station ↔ Hospital EHR | HL7 Interface Engine | HL7 FHIR R4 messages over HTTPS, patient data synchronization, authentication via OAuth 2.0 |
| User ↔ Bedside Monitor | Touchscreen Controller | Capacitive touch input with haptic feedback, 1920x1080 resolution, medical-grade cleanable surface |
| User ↔ Nursing Station | Keyboard/Mouse Interface | Standard USB HID devices, medical-grade washable peripherals, multi-monitor support |
### Interoperability
The system integrates with hospital Electronic Health Record (EHR) systems using HL7 FHIR R4 standards for patient data exchange. Real-time vital signs data is transmitted to the hospital's clinical information system for permanent storage and trending analysis. The system supports IHE Patient Care Device (PCD) profiles for medical device interoperability. Network connectivity requires hospital Wi-Fi infrastructure with WPA3 security and dedicated VLAN for medical devices.
## Q\&A
Include enough detail for developers to implement the interfaces and for verification teams to test them. Specify communication protocols, data formats, timing requirements, error handling, and security measures. Document both normal operation and failure modes. Include performance requirements like response times, data rates, and reliability metrics.
Document authentication mechanisms, encryption methods, access controls, and network security measures for all interfaces. Consider FDA cybersecurity guidance and MDR requirements. Specify how interfaces protect against unauthorized access, data breaches, and malicious attacks. Include monitoring and incident response procedures for security events.
Focus on **clarity, simplicity, and error prevention**. Use high contrast displays, large fonts, and intuitive layouts. Design for the use environment (lighting, noise, stress levels). Implement confirmation steps for critical actions. Consider accessibility requirements and support for users with disabilities. Follow human factors engineering principles throughout the design process.
Research the specific standards used by your target healthcare facilities (HL7, DICOM, IHE profiles). Design interfaces that comply with relevant interoperability standards. Consider data mapping requirements between your device and hospital systems. Plan for configuration flexibility to accommodate different hospital network architectures and security policies.
Document what happens when each interface fails, how failures are detected, and what recovery procedures are implemented. Specify timeout values, retry mechanisms, and fallback modes. Consider the impact of interface failures on patient safety and device functionality. Design graceful degradation where possible to maintain critical functions during partial system failures.
Design interfaces with testability in mind. Specify measurable performance criteria, provide test points for verification, and document expected behaviors under various conditions. Include interface specifications that can be objectively verified through testing. Consider how interfaces will be validated in the intended use environment.
# IVDR Device Classification
Source: https://docs.withdovetail.com/tasks/ivdr-device-classification
Classify in vitro diagnostic devices based on clinical significance and patient impact for proper conformity assessment.
## Summary
**IVDR device classification** determines your in vitro diagnostic medical device's risk class (A, B, C, or D) under EU In Vitro Diagnostic Medical Device Regulation 2017/746, which directly impacts your conformity assessment procedure, notified body requirements, and market access timeline. Classification is based on your device's intended purpose, clinical significance, and potential impact on patient management according to the specific rules in Annex VIII. Accurate classification is mandatory for CE marking and commercialization of IVD devices in the European Union.
## Why is IVDR Device Classification Important?
IVDR classification is **critical for your regulatory strategy** because it determines the level of regulatory oversight, required clinical evidence, and conformity assessment pathway. Higher-risk classifications (Class C and D) require notified body involvement, extensive clinical performance studies, and more rigorous quality management systems. Misclassification can result in significant delays, increased costs, or inability to market your device. Your classification also affects your post-market surveillance obligations, the depth of technical documentation required, and the timeline for achieving CE marking under the IVDR transition period.
## Regulatory Context
Under **EU IVDR 2017/746, Annex VIII**:
* Classification rules are **mandatory and specific** to IVD characteristics
* Based on **clinical significance, intended purpose, and patient impact**
* Determines **conformity assessment procedure** under Annex IX, X, or XI
* **Class C and D devices** require notified body involvement and clinical performance studies
**Special attention required for:**
* Companion diagnostics - typically Class C under Rule 3f
* Self-testing devices - Rule 4a with specific exceptions for Class B
* Blood grouping and tissue typing - Rules 2a-2e typically result in Class D
* Software IVDs - apply general classification rules based on clinical impact
## Guide
IVDR classification follows **specific rules in Annex VIII** that focus on clinical significance and patient impact. Unlike MDR classification, IVDR rules are more directly tied to the clinical consequences of incorrect results rather than physical device characteristics.
**Start with the highest-risk categories (Rules 1-2).** Rule 1 covers devices for detecting transmissible agents in blood, tissues, or organs, and devices for life-threatening diseases with high propagation risk - these are typically Class D. Rule 2 addresses blood grouping and tissue typing, with specific markers (ABO, Rhesus, Kell, Kidd, Duffy) resulting in Class D classification.
**Evaluate clinical significance rules (Rule 3).** This comprehensive rule covers many clinically significant applications including sexually transmitted agents, infectious agents in blood/CSF, companion diagnostics, cancer screening/diagnosis/staging, genetic testing, and therapeutic drug monitoring. Most applications under Rule 3 result in Class C classification.
**Consider self-testing and near-patient testing (Rule 4).** Self-testing devices are generally Class C, with specific exceptions for pregnancy, fertility, cholesterol, glucose, and urine testing (Class B). Near-patient testing devices are classified based on their specific intended purpose.
**Apply general laboratory rules (Rules 5-7).** Rule 5 covers general laboratory products and instruments (Class A). Rule 6 is a catch-all for devices not covered by other rules (Class B). Rule 7 addresses controls without assigned values (Class B).
**Document your classification rationale thoroughly.** Reference the specific IVDR Annex VIII rule applied, explain the clinical significance of your test, and justify why other rules don't apply. Consider the consequences of false positive and false negative results on patient management.
**Consider software and algorithm components.** Software IVDs are classified based on their clinical impact using the same rules as hardware devices. AI/ML algorithms that provide diagnostic information follow the same classification principles based on clinical significance.
## Example
### Complete IVDR Classification Document
**IVDR Classification Document**
ID: IVDR-CLASS-2024-001
### Device Classification
Class C
### Device Classification Justification
The CardioGenetic Risk Panel is classified as **Class C** under EU IVDR 2017/746 based on the following analysis of Annex VIII classification rules:
**Rule 3i (Human genetic testing):**
The CardioGenetic Risk Panel is an in vitro diagnostic device intended for human genetic testing to identify genetic variants associated with inherited cardiac conditions including hypertrophic cardiomyopathy, arrhythmogenic right ventricular cardiomyopathy, and long QT syndrome. Under Rule 3i, devices for human genetic testing are classified as Class C.
**Clinical Significance Analysis:**
The test analyzes genetic variants in genes including MYH7, MYBPC3, TNNT2, TNNI3, SCN5A, and KCNQ1 that are associated with inherited cardiac conditions. Results are used by healthcare providers to:
* Assess genetic risk for developing cardiac conditions
* Guide family screening recommendations
* Inform clinical management decisions including surveillance frequency
* Support reproductive counseling decisions
**Impact of Erroneous Results:**
* **False Positive:** Could lead to unnecessary anxiety, inappropriate clinical surveillance, and family screening. May result in lifestyle restrictions or medical interventions that are not clinically indicated.
* **False Negative:** Could result in missed diagnosis of genetic predisposition, inadequate clinical surveillance, and failure to implement appropriate family screening protocols. This could lead to undiagnosed cardiac events in the patient or family members.
**Other Rules Considered:**
* **Rule 1:** Not applicable - device does not detect transmissible agents or life-threatening diseases with propagation risk
* **Rule 2:** Not applicable - device does not perform blood grouping or tissue typing
* **Rule 3c:** Not applicable - while cardiac conditions can be serious, the genetic testing context does not meet the criteria for "erroneous result could cause death or severe disability"
* **Rule 3g:** Not applicable - device is not used for disease staging
* **Rule 3h:** Not applicable - device does not screen, diagnose, or stage cancer
* **Rule 4:** Not applicable - device is not intended for self-testing
* **Rule 6:** Not applicable - device is specifically covered under Rule 3i
**Conclusion:** The CardioGenetic Risk Panel is classified as **Class C** under Rule 3i for human genetic testing. This classification reflects the clinical significance of genetic information for inherited cardiac conditions and the potential impact on patient and family management decisions.
## Q\&A
**Software IVDs are classified using the same rules** as hardware devices based on their clinical significance and intended purpose. Apply the relevant Annex VIII rules based on what the software does clinically, not its technical implementation. AI/ML algorithms that provide diagnostic information follow the same classification principles - focus on the clinical impact of the results, not the underlying technology.
**Class D devices typically involve life-threatening conditions** with high propagation risk (Rule 1) or critical blood/tissue compatibility testing (Rule 2). Class C devices cover most other clinically significant applications including companion diagnostics, cancer testing, genetic testing, and therapeutic drug monitoring. The key difference is the immediacy and severity of clinical consequences from incorrect results.
**Companion diagnostics are typically Class C** under Rule 3f. These are devices used to identify patients who are most likely to benefit from a particular therapeutic product or to identify patients likely to be at increased risk for serious adverse reactions. The classification reflects the significant impact on treatment decisions and patient safety.
**Self-testing devices are generally Class C** under Rule 4a, with specific exceptions for pregnancy, fertility, cholesterol, glucose, and certain urine tests which are Class B. Self-testing devices are **never Class A** (which is reserved for general laboratory products) and rarely Class D unless they also meet Rule 1 or Rule 2 criteria for other reasons.
Unlike MDR, IVDR rules are generally **mutually exclusive** and specific to particular applications. However, if multiple rules could theoretically apply, document your analysis of each rule and explain why the selected rule is most appropriate. Focus on the **primary intended purpose** and clinical application of your device.
Document your **clinical significance analysis**, including the consequences of false positive and false negative results on patient management. Reference the specific Annex VIII rule applied and explain why other rules don't apply. Include evidence of your device's intended purpose, target population, and clinical context. This documentation will be reviewed by your notified body for Class C and D devices.
# List of CAPAs
Source: https://docs.withdovetail.com/tasks/list-capa
Maintain centralized register enabling CAPA trend analysis and management oversight activities.
## Summary
The List of CAPAs is a **centralized register** of all corrective and preventive actions implemented in your quality management system. You use this list to track CAPA status, analyze trends, and provide management with oversight of quality improvement activities across your organization.
## Why is the List of CAPAs important?
The List of CAPAs provides **essential oversight and trend analysis** capabilities for your quality management system by consolidating all corrective and preventive actions in one accessible document. It enables management review of CAPA effectiveness, identification of recurring problems, and strategic quality improvement planning. Without a comprehensive list of CAPAs, you cannot effectively analyze patterns, allocate resources, or demonstrate systematic quality improvement to regulators and auditors. This list also serves as a critical input for management reviews and continuous improvement initiatives.
## Regulatory Context
Under **21 CFR Part 820.100** (Corrective and Preventive Action):
* **Records must be maintained** for all CAPA activities and their outcomes
* **Management review** must evaluate CAPA effectiveness and trends (820.20)
* **Documentation must be available** for FDA inspection and audit
* **Trend analysis** is required to identify recurring quality problems
**Special attention required for:**
* CAPAs resulting from FDA inspections or warning letters
* Design control CAPAs affecting device safety or effectiveness
* CAPAs related to complaint investigations and MDR reporting
* Integration with management review and quality metrics
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **CAPA records** must be maintained as part of quality management system (ISO 13485 Section 8.5)
* **Management review** must evaluate CAPA effectiveness and trends (Article 10(9))
* **Notified body access** to CAPA records during surveillance audits
* **Continuous improvement** must be demonstrated through CAPA analysis
**Special attention required for:**
* CAPAs affecting CE marking or notified body oversight
* Post-market surveillance CAPAs requiring regulatory notification
* Clinical evaluation updates based on CAPA findings
* Integration with vigilance system and risk management
## Guide
### CAPA Registration Process
**Add completed CAPAs** to the list only after they have been formally closed through your CAPA Report process. Include all essential information that enables tracking and trend analysis without duplicating detailed information available in individual CAPA documents.
**Maintain chronological order** or use a systematic numbering scheme that enables easy reference and retrieval. Ensure each CAPA has a unique identifier that links to the detailed CAPA Plan and Report documents.
### Essential Information Elements
**CAPA identification** should include the unique CAPA ID, source of the CAPA (audit, complaint, surveillance), and brief problem description. This enables quick identification and categorization for analysis purposes.
**Timeline tracking** must include initiation date, verification date, and closure date to monitor CAPA cycle times and identify process improvement opportunities. Long cycle times may indicate resource constraints or process inefficiencies.
**Action summary** should provide a concise description of the corrective and preventive actions taken without duplicating detailed information from CAPA reports. Focus on the key interventions that resolved the problem.
### Trend Analysis and Review
**Analyze CAPA sources** to identify whether problems originate from audits, complaints, post-market surveillance, or other inputs. Patterns in CAPA sources can reveal systematic issues in your quality management system.
**Monitor cycle times** to ensure CAPAs are completed within reasonable timeframes. Extended cycle times may indicate resource constraints, inadequate planning, or process inefficiencies that need attention.
**Identify recurring themes** in problem types, affected products, or root causes. Recurring patterns suggest opportunities for preventive action or systematic process improvements.
### Management Review Integration
**Prepare summary reports** for management review that highlight CAPA trends, effectiveness metrics, and resource requirements. Include recommendations for preventive actions based on trend analysis.
**Track effectiveness indicators** such as CAPA cycle times, recurrence rates, and customer satisfaction improvements. These metrics demonstrate the value of your CAPA system and identify improvement opportunities.
## Example
**Scenario**: Your organization has completed several CAPAs over the past year related to software quality, customer complaints, and audit findings. You need to maintain a comprehensive list that enables trend analysis and supports management review activities.
### Example List of CAPAs
**Document ID**: LST-CAPA-2024
#### CAPA Register
| CAPA ID | Source of CAPA | Problem | Actions | Initiation Date | Verification Date | Close Date |
| ----------------- | ------------------------ | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------- | ----------------- | ---------- |
| **CAPA-2024-001** | Internal Audit | Incomplete design review documentation for software module updates | Updated design review procedures, retrained development team, implemented automated documentation checks | 2024-01-15 | 2024-02-28 | 2024-03-15 |
| **CAPA-2024-002** | Customer Complaints | Software compatibility issues causing inconsistent glucose readings on specific smartphone models | Released software hotfix, expanded compatibility testing, enhanced post-market surveillance monitoring | 2024-03-10 | 2024-06-15 | 2024-06-30 |
| **CAPA-2024-003** | Post-Market Surveillance | Increased user reports of app crashes during peak usage hours | Optimized memory management, implemented load balancing, added performance monitoring | 2024-04-20 | 2024-07-10 | 2024-07-25 |
| **CAPA-2024-004** | Management Review | Supplier quality issues affecting component delivery schedules | Updated supplier qualification criteria, implemented backup supplier program, enhanced supplier monitoring | 2024-05-05 | 2024-08-20 | 2024-09-10 |
| **CAPA-2024-005** | Customer Complaints | User interface confusion leading to incorrect device setup | Redesigned setup wizard, updated user manual, conducted usability testing with target users | 2024-06-12 | 2024-09-30 | 2024-10-15 |
| **CAPA-2024-006** | External Audit | Inadequate training records for quality management system procedures | Implemented digital training tracking system, updated training procedures, conducted refresher training | 2024-07-08 | 2024-10-25 | 2024-11-10 |
| **CAPA-2024-007** | Risk Assessment | Potential cybersecurity vulnerability in data transmission protocols | Upgraded encryption protocols, implemented additional security testing, updated cybersecurity procedures | 2024-08-15 | 2024-11-30 | 2024-12-15 |
#### Trend Analysis Summary
**CAPA Sources (2024)**:
* Customer Complaints: 29% (2 of 7 CAPAs)
* Internal/External Audits: 43% (3 of 7 CAPAs)
* Post-Market Surveillance: 14% (1 of 7 CAPAs)
* Management Review: 14% (1 of 7 CAPAs)
**Problem Categories**:
* Software/Technical Issues: 43% (3 of 7 CAPAs)
* Process/Documentation: 29% (2 of 7 CAPAs)
* Training/Human Factors: 14% (1 of 7 CAPAs)
* Supplier Management: 14% (1 of 7 CAPAs)
**Average Cycle Times**:
* Initiation to Verification: 98 days
* Verification to Closure: 18 days
* Total Cycle Time: 116 days
**Key Insights**:
* Software-related issues represent the largest category, suggesting need for enhanced software quality processes
* Audit findings indicate opportunities for proactive process improvement
* Customer complaints are effectively driving product improvements
* Cycle times are within acceptable ranges but could be optimized for software CAPAs
## Q\&A
Update the List of CAPAs immediately when CAPAs are closed and review it monthly for trend analysis. Include CAPA trend analysis in quarterly management reviews to identify patterns and improvement opportunities. Annual comprehensive reviews should evaluate overall CAPA system effectiveness.
The List of CAPAs should include essential tracking information: CAPA ID, source, brief problem description, summary of actions, and key dates. Detailed root cause analysis, implementation plans, and verification evidence should remain in individual CAPA Plan and Report documents.
Identify recurring problems through trend analysis and initiate preventive CAPAs to address systemic causes. Cross-reference related CAPAs in the list and consider whether previous CAPAs were effective or if additional preventive action is needed.
Monitor CAPA sources (audits, complaints, surveillance), problem categories (software, process, training), affected products, cycle times, and recurrence rates. Look for patterns that indicate systematic issues requiring preventive action or process improvements.
Prepare trend analysis summaries showing CAPA effectiveness, resource requirements, and improvement opportunities. Include metrics on cycle times, problem categories, and preventive action effectiveness. Use CAPA data to identify strategic quality improvement priorities and resource allocation needs.
# List Of Known Anomalies
Source: https://docs.withdovetail.com/tasks/list-of-known-anomalies
Document residual software bugs ensuring transparent risk assessment and informed release decisions.
## Summary
The List of Known Anomalies documents all residual software bugs or anomalies that exist in your medical device software but will not be corrected prior to the current software release, including their risk impact and planned correction timeline.
## Why is a List of Known Anomalies important?
The List of Known Anomalies is essential for demonstrating transparency and risk management in software medical devices. It shows regulatory authorities that you have thoroughly tested your software, identified all known issues, and made informed decisions about which anomalies are acceptable for release based on risk assessment. This document protects both patients and your organization by ensuring that all stakeholders understand the limitations of the current software version and that appropriate risk controls are in place. Without this documentation, you cannot demonstrate that you have adequately assessed the safety implications of releasing software with known issues.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **FDA Software Guidance**:
* All known software anomalies must be **documented** and risk-assessed
* **Risk-based approach** required for determining which anomalies are acceptable for release
* Software validation must include **anomaly assessment** (21 CFR 820.70(i))
* **Change control** procedures must address anomaly corrections in future releases
**Special attention required for:**
* Class III software devices requiring more stringent anomaly documentation
* Software as Medical Device (SaMD) requiring comprehensive anomaly risk assessment
* Cybersecurity-related anomalies requiring immediate attention regardless of risk level
* AI/ML devices where anomalies may indicate training data or algorithm issues
Under **EU MDR 2017/745** and **IEC 62304:2006**:
* Software anomalies must be documented per **IEC 62304 Section 5.7.5**
* Risk assessment required for all anomalies per **ISO 14971** integration
* **Software safety classification** determines anomaly acceptance criteria
* Post-market surveillance must monitor for **new anomalies** (Article 83)
**Special attention required for:**
* Class IIa and above devices requiring notified body review of anomaly documentation
* Software lifecycle processes must include anomaly management procedures
* Clinical evaluation must consider impact of known anomalies on clinical performance
* Unique Device Identification (UDI) updates may be required for significant anomaly corrections
## Guide
Your List of Known Anomalies must provide complete transparency about software issues that remain in your device at the time of release. This document demonstrates your commitment to patient safety through honest disclosure and risk-based decision making.
### Software Version Documentation
Clearly specify the **software-version** for which this anomaly list applies. Each software release should have its own anomaly list, allowing for proper version control and traceability. This ensures that stakeholders understand exactly which version of your software contains the documented anomalies.
### Comprehensive Anomaly Documentation
Your **known-anomalies** table must include detailed information for each anomaly. Document the **Name of Anomaly** using clear, descriptive terminology that allows easy identification. Provide a comprehensive **Description** that explains what the anomaly is, when it occurs, and under what conditions it manifests.
### Risk Impact Assessment
For each anomaly, assess its **Impact on Risk** using the three-tier system: "No impact on risk" for issues that cannot lead to patient harm, "Low impact on risk" for issues that could cause minor patient harm, and "Significant impact on risk" for issues that could cause serious patient harm. This assessment must align with your overall risk management approach and risk acceptability criteria.
### Risk Acceptability Determination
Determine whether each anomaly's risk is **Risk Acceptable** based on your established risk matrix. Anomalies with "No impact on risk" or "Low impact on risk" can typically be marked as "Acceptable," while those with "Significant impact on risk" should be "Unacceptable" and require immediate correction before release.
### Correction Planning
Document your **Correction Action(s)** for each anomaly, describing specific steps you will take to address the issue in future releases. Provide realistic **Correction Timeline** estimates such as "Next major software release," "Next minor software release," or "Next bug fix," allowing stakeholders to understand when improvements will be available.
### Quality Assurance Integration
Ensure your anomaly list integrates with your overall quality management system. Anomalies should be tracked through your software problem resolution process and may trigger change management or CAPA procedures depending on their severity and impact.
## Example
**Scenario:** You develop a telemedicine platform for remote patient monitoring. During final testing, you identify three software anomalies: a minor UI display issue, a data synchronization delay, and an occasional login timeout. You assess their risk impact and determine correction priorities for the next software releases.
### List of Known Anomalies
**ID:** LKA-001
**1. Scope**
The list within this document identifies the residual anomalies or "bugs" that exist in the software that will not be corrected prior to the software release in this version.
**Software Version:** v2.1.0
**2. Known Residual Anomalies**
| Name of Anomaly | Description | Impact on Risk | Risk Acceptable | Correction Action(s) | Correction Timeline |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | --------------- | ----------------------------------------------------------------------------------------- | --------------------------- |
| Patient List Display Truncation | Patient names longer than 25 characters are truncated in the main patient list view, showing only the first 25 characters followed by "..." | No impact on risk | Acceptable | Implement dynamic text sizing and tooltip display for full names | Next minor software release |
| Data Sync Delay | Patient vital signs data synchronization between mobile app and web portal experiences delays of 30-60 seconds under high network load conditions | Low impact on risk | Acceptable | Optimize data synchronization algorithm and implement progressive sync for large datasets | Next major software release |
| Session Timeout Warning | Users occasionally do not receive the 5-minute session timeout warning dialog, resulting in unexpected session termination during data entry | Low impact on risk | Acceptable | Refactor session management system and implement redundant timeout warning mechanisms | Next bug fix |
## Q\&A
If you have no known anomalies remaining after testing, you can leave the anomalies table blank. This demonstrates excellent software quality and thorough testing. However, ensure your testing was comprehensive enough to identify potential issues.
Anomalies with significant impact on risk should typically be marked as "Unacceptable" and corrected before release. If you must release with such anomalies, you need strong justification through benefit-risk analysis and additional risk controls.
In medical device software, "anomaly" is the preferred term as it encompasses any deviation from expected behavior, including bugs, unexpected behaviors, and performance issues. All software anomalies should be documented regardless of their technical classification.
Update the list for each software release. Each version should have its own anomaly list, and you should track how anomalies are resolved or new ones discovered between releases. This provides clear version-to-version traceability.
Yes, include usability issues that could impact patient safety or device effectiveness. However, minor user preference issues that don't affect safety or performance may not need to be documented as anomalies.
Base correction timelines on the anomaly's risk impact, technical complexity, and your development schedule. High-risk anomalies should be corrected in the next bug fix, while low-risk issues can wait for minor or major releases.
# List Of Medical Devices
Source: https://docs.withdovetail.com/tasks/list-of-medical-devices
Maintain comprehensive registry tracking all device versions and market availability throughout lifecycle.
## Summary
The List of Medical Devices is a comprehensive registry that documents all current and previous versions of your medical device software, including version details, release dates, device identifiers, and market availability. This document serves as a master record for device lifecycle management and provides essential traceability information for regulatory authorities, customers, and internal quality management.
## Why is List of Medical Devices important?
This document provides **complete traceability** of your device versions throughout the entire product lifecycle, which is essential for regulatory compliance and post-market surveillance. Regulatory authorities require clear documentation of all device versions to track safety performance, manage recalls if necessary, and verify compliance with ongoing regulatory requirements. For manufacturers, this list enables **systematic version management**, helps identify which versions are still supported in the market, and provides critical information for customer support and technical assistance.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Design history file** (820.30) requires records of all design versions
* **Device master record** (820.181) must include version identification
* **Change control** (820.40) requires documentation of version changes
* **Traceability** (820.65) mandates device identification and tracking
**Special attention required for:**
* Software version tracking for post-market surveillance reporting
* Integration with FDA Establishment Registration and Device Listing updates
* Version control alignment with 510(k) submissions and amendments
* Recall management and version-specific safety communications
Under **EU MDR 2017/745**:
* **Technical documentation** (Annex II) requires device version records
* **UDI system** (Article 27) mandates version-specific identification
* **Post-market surveillance** (Articles 83-86) requires version tracking
* **EUDAMED registration** requires current device information maintenance
**Special attention required for:**
* UDI-PI updates for each software version in EUDAMED
* Version-specific clinical evaluation and safety monitoring
* Market availability tracking for different EU member states
* Notified body notification for significant version changes
## Guide
### Current Device Information Management
Maintain accurate information about your **current device version** including the exact device name, current software version, release date, UDI-DI, and complete market availability information. This section should always reflect the most recent version available to customers and must be updated with each new release. Ensure consistency between this information and your device registration databases, technical documentation, and marketing materials.
### Version History Documentation
Document all **previous software versions** with complete details including version numbers, release dates, decommissioning dates when applicable, and associated device identifiers. This historical record is crucial for traceability, customer support, and regulatory compliance. Include information about when older versions were withdrawn from the market and any transition periods where multiple versions were simultaneously available.
### Market Availability Tracking
Clearly document which **markets and countries** your device is available in for each version. This information is essential for regulatory compliance, as different markets may have different approval timelines and requirements. Update this information when you gain market access in new countries or when regulatory status changes in existing markets. Consider including specific regulatory approval dates for major markets.
### Device Identifier Management
Maintain accurate **UDI-DI information** for each device version, ensuring consistency with regulatory databases and labeling. Each software version may have a different UDI-PI while sharing the same UDI-DI, so document these relationships clearly. This information is critical for regulatory traceability and post-market surveillance activities.
### Similar Device Documentation
Include information about **similar marketed devices** that may be relevant for regulatory comparison, competitive analysis, or clinical evaluation purposes. This can include predicate devices used for FDA submissions, similar devices in your product portfolio, or competitor devices that serve similar clinical purposes. This information supports regulatory strategy and market positioning.
### Lifecycle Status Management
Track the **lifecycle status** of each device version including active, deprecated, or decommissioned status. Document support timelines, end-of-life dates, and migration paths for customers using older versions. This information helps manage customer relationships and ensures appropriate support for devices still in clinical use.
### Integration with Quality Management
Ensure your device list integrates with your **quality management system** and change control processes. Each new version should be added through your established change control procedures, and the list should be updated as part of your software release process. This ensures consistency between your device registry and other quality documentation.
## Example
### Scenario
You are maintaining the device list for your telemedicine platform that provides remote patient monitoring and consultation services. The platform has evolved through several versions with different feature sets and market availability, and you need to track all versions for regulatory compliance and customer support.
### Example List of Medical Devices
## 1. Scope
This document describes the latest device details and as well as details for previous device versions for TeleCare Pro remote patient monitoring platform.
## 2. Current Medical Devices
| Device Name | Current Version | Release Date | Device Identifier | Markets / Countries Available |
| ------------ | --------------- | -------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| TeleCare Pro | 5.2.1 | April 10, 2024 | (01)04012345678901 | Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, United States |
## 3. Previous Versions
| Device Name | Device Version | Release Date | Decommissioning Date | Device Identifier | Markets Available | Support Status |
| ------------ | -------------- | ----------------- | -------------------- | ------------------ | ----------------- | -------------- |
| TeleCare Pro | 5.2.0 | February 15, 2024 | April 10, 2024 | (01)04012345678901 | EU, US | Superseded |
| TeleCare Pro | 5.1.3 | December 8, 2023 | February 15, 2024 | (01)04012345678901 | EU, US | End of Support |
| TeleCare Pro | 5.1.2 | October 22, 2023 | December 8, 2023 | (01)04012345678901 | EU, US | End of Support |
| TeleCare Pro | 5.1.1 | September 5, 2023 | October 22, 2023 | (01)04012345678901 | EU, US | End of Support |
| TeleCare Pro | 5.1.0 | July 18, 2023 | September 5, 2023 | (01)04012345678901 | EU, US | End of Support |
| TeleCare Pro | 5.0.2 | May 30, 2023 | July 18, 2023 | (01)04012345678901 | EU, US | End of Support |
| TeleCare Pro | 5.0.1 | April 12, 2023 | May 30, 2023 | (01)04012345678901 | EU, US | End of Support |
| TeleCare Pro | 5.0.0 | February 28, 2023 | April 12, 2023 | (01)04012345678901 | EU, US | End of Support |
## 4. Similar Devices
| Device Name | Manufacturer | Market | Regulatory Status | Clinical Purpose | Comparison Notes |
| -------------------- | -------------------- | ---------- | --------------------------------- | ---------------------------------- | --------------------------------------------------------- |
| RemoteHealth Monitor | HealthTech Solutions | EU, US | CE marked, FDA cleared | Remote patient monitoring | Predicate device for FDA 510(k) submission |
| VitalWatch Pro | MedDevice Corp | EU | CE marked | Patient vital signs monitoring | Similar monitoring capabilities, different user interface |
| CareConnect Platform | Digital Health Inc | US | FDA cleared | Telemedicine consultations | Similar consultation features, no monitoring component |
| PatientLink Remote | TeleMed Systems | EU, Canada | CE marked, Health Canada approved | Remote monitoring and consultation | Direct competitor with similar feature set |
## Q\&A
Update the list with every software release to reflect new versions, and review it regularly to ensure market availability information remains current. Also update when devices are decommissioned or when market access changes in different countries.
Keep historical records of all versions for regulatory traceability, but clearly mark their support status as "End of Support" or "Decommissioned." Include decommissioning dates and any relevant safety or support information for customers who may still be using older versions.
Document market-specific availability for each version, as regulatory approval timelines may vary between countries. Some markets may still be using older versions while others have access to newer releases. Track this information carefully for regulatory compliance and customer support.
Generally no, include only commercially released versions that are or were available to customers. Beta versions should be tracked separately in your development documentation. However, if beta versions were provided to clinical sites for evaluation, consider documenting them separately with clear identification of their non-commercial status.
Ensure consistency between your device list and UDI database registrations. Each version should have corresponding UDI-PI entries in regulatory databases, and any changes to market availability should be reflected in both your internal list and regulatory registrations.
Include devices that are relevant for regulatory comparison (like predicate devices), competitive analysis, or clinical evaluation purposes. Focus on devices with similar intended use, clinical purpose, or technological approach. This information supports regulatory strategy and market positioning activities.
# Approved Supplier List
Source: https://docs.withdovetail.com/tasks/list-of-qualified-suppliers
Maintain qualified supplier registry with performance tracking and risk-based monitoring for supply chain assurance.
## Summary
**Approved Supplier List** provides systematic documentation of all qualified suppliers that have been evaluated and approved for providing materials, components, services, or manufacturing processes affecting medical device quality and regulatory compliance. This essential Quality Management System (QMS) record maintains current supplier status, criticality assessments, performance scores, and ongoing surveillance requirements to ensure continuous supply chain quality assurance.
## Why is Approved Supplier List important?
Supplier management represents a **critical control point** that directly impacts medical device safety, quality, and regulatory compliance. **Without systematic supplier qualification and ongoing monitoring**, organizations risk incorporating defective components, unreliable services, or non-compliant materials that could compromise device performance or create regulatory violations.
**Regulatory requirements mandate** structured supplier control processes. FDA Quality System Regulation (21 CFR 820.50) and ISO 13485:2016 (Section 7.4) require organizations to evaluate and select suppliers based on their ability to provide products meeting specified requirements. **The Approved Supplier List provides evidence** of systematic supplier evaluation and ongoing performance monitoring.
The documented approach transforms supplier management from ad-hoc purchasing decisions into **strategic quality assurance**. **Well-maintained supplier lists** support procurement decisions, enable risk-based supplier monitoring, and provide audit evidence of systematic supplier control throughout the medical device lifecycle.
## Regulatory Context
Under **21 CFR Part 820.50** (Purchasing Controls):
* **Supplier evaluation and selection** based on ability to meet specified requirements
* **Purchasing data documentation** including product specifications and quality requirements
* **Supplier notification requirements** for changes affecting product specifications
* **Receiving inspection** or other verification activities to ensure purchased products meet requirements
**Special attention required for:**
* Critical supplier qualification requiring enhanced oversight and documentation
* Component supplier changes requiring design control evaluation
* Software supplier validation for design control and production systems
* Contract manufacturer qualification including process validation oversight
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Supplier evaluation processes** must consider supplier ability to provide products meeting organization requirements (ISO 13485 7.4.1)
* **Purchasing information documentation** including product requirements and supplier qualification criteria
* **Critical supplier oversight** with risk-based monitoring and periodic re-evaluation
* **Outsourced process control** when suppliers perform activities affecting product conformity
**Special attention required for:**
* Notified Body expectations for critical supplier documentation and oversight
* EU GDPR compliance for suppliers processing personal data
* Supply chain traceability requirements for higher-risk device classifications
* Authorized representative and distributor qualification for EU market access
## Guide
### Supplier Criticality Assessment
**Determine supplier criticality** using systematic criteria that assess impact on device performance, safety, and regulatory compliance. **Classify suppliers as critical** if purchased products/services could directly impact device performance or safety, affect regulatory compliance, or represent single-source supply situations with no alternatives.
**Document criticality rationales** clearly, explaining why specific suppliers require enhanced oversight versus standard commercial relationships. **Critical suppliers** require comprehensive qualification including detailed evaluation, ongoing surveillance, and formal agreements. **Non-critical suppliers** may require basic assessment without extensive documentation.
**Review supplier criticality** periodically as device designs evolve, supply chains change, or regulatory requirements update. **Update criticality classifications** when supplier roles change or new risk factors emerge.
### Supplier Qualification Process
**Conduct systematic supplier evaluation** using structured criteria including quality management systems, technical capabilities, financial stability, and service performance. **Score suppliers** across multiple dimensions using standardized rating scales (0=Poor, 1=Fair, 2=Good, 3=Excellent).
**Evaluate supplier quality systems** including ISO 13485 certification, FDA registration status, and other relevant quality certifications. **Assess technical capabilities** including manufacturing processes, testing capabilities, and quality control procedures relevant to purchased products/services.
**Document qualification decisions** clearly, including evaluation scores, approval rationale, and any conditions or restrictions for supplier use. **Maintain qualification records** as objective evidence of systematic supplier control.
### Approved Supplier List Management
**Maintain current supplier information** including contact details, product/service descriptions, criticality classifications, approval status, and performance monitoring requirements. **Update supplier records** regularly as contact information changes, services evolve, or performance issues arise.
**Track supplier status systematically** using categories including Approved, Approved with Monitoring, or Blocked. **Approved suppliers** meet all qualification requirements without restrictions. **Approved with Monitoring** requires additional surveillance due to moderate performance scores or risk factors. **Blocked suppliers** cannot be used due to qualification failures or performance issues.
**Document monitoring requirements** for each supplier including inspection frequencies, audit schedules, performance review cycles, and escalation criteria. **Tailor monitoring intensity** to supplier criticality and historical performance.
### Ongoing Supplier Surveillance
**Implement risk-based monitoring** proportionate to supplier criticality and performance history. **High-risk or critical suppliers** may require frequent performance reviews, regular audits, and enhanced incoming inspection. **Low-risk suppliers** may need only annual reviews and routine verification activities.
**Monitor supplier performance** through multiple channels including incoming inspection results, delivery performance, customer complaints, and supplier communications. **Document performance issues** systematically and implement corrective actions when necessary.
**Conduct periodic re-evaluation** of all suppliers, typically annually before management review. **Update qualification status** based on performance trends, capability changes, or regulatory requirement modifications.
### Supplier Agreements and Documentation
**Establish formal agreements** with critical suppliers including quality assurance agreements (QAA), service level agreements, and change notification requirements. **QAAs should specify** quality standards, inspection rights, corrective action procedures, and regulatory compliance obligations.
**Require change notification** for modifications affecting product specifications, manufacturing processes, or regulatory status. **This ensures** design control evaluation and risk assessment when supplier changes could impact device compliance or performance.
**Maintain purchasing documentation** including specifications, quality requirements, and acceptance criteria for purchased products/services. **Link purchasing requirements** to device specifications and regulatory requirements to ensure traceability.
### Supplier Performance Management
**Track key performance indicators** including quality metrics, delivery performance, responsiveness, and compliance with agreements. **Establish performance thresholds** that trigger increased monitoring, corrective actions, or supplier status changes.
**Address performance issues** systematically through corrective action requests, supplier development activities, or alternative supplier qualification. **Document issue resolution** and verify effectiveness of corrective actions.
**Recognize good performance** through supplier feedback, preferred supplier status, or expanded business opportunities. **Use performance data** to inform future sourcing decisions and supplier development priorities.
## Example
**Scenario:** Your organization develops a wearable health monitoring device and needs to qualify suppliers for key components including sensors, batteries, wireless modules, and contract manufacturing services.
### Supplier Identification and Criticality Assessment
You identify five key suppliers: SensorTech (critical heart rate sensors), PowerCell (critical batteries), RadioCorp (wireless modules), PlasticPro (non-critical housing components), and ManufacturingPlus (critical contract manufacturer). Critical suppliers directly impact device performance and safety, while PlasticPro provides standard housing with multiple alternative sources.
### Supplier Qualification Process
You complete Supplier Qualification Checklists for each supplier, evaluating quality systems (ISO 13485 certification), technical capabilities, financial stability, and service performance. SensorTech scores 2.8/3.0 (approved), PowerCell scores 1.5/3.0 (approved with monitoring), RadioCorp scores 2.5/3.0 (approved), PlasticPro scores 2.0/3.0 (approved), and ManufacturingPlus scores 2.7/3.0 (approved).
### Approved Supplier List Documentation
Your list documents each supplier with contact information, product descriptions, criticality classifications, approval status, and monitoring requirements. PowerCell requires enhanced incoming inspection due to moderate scores, while other approved suppliers follow standard monitoring procedures.
### Ongoing Surveillance Implementation
You establish monthly performance reviews for critical suppliers, quarterly reviews for non-critical suppliers, and annual comprehensive re-evaluations for all suppliers. Critical suppliers require formal QAAs and change notification agreements. You track quality metrics, delivery performance, and compliance with specifications.
### Performance Management
After six months, PowerCell demonstrates improved performance through corrective actions, earning upgrade to standard approval status. You update their record in the Approved Supplier List and adjust monitoring requirements accordingly.
## Q\&A
Classify suppliers as critical if their products/services could directly impact device performance or safety, affect regulatory compliance, or represent single-source situations with no alternatives. Consider whether supplier failure would prevent device development, manufacturing, or market release. Document criticality rationale clearly for each determination.
Evaluate suppliers based on quality management systems (ISO 13485, FDA registration), technical capabilities, financial stability, delivery performance, customer service, and pricing competitiveness. Use standardized scoring (0-3 scale) across consistent criteria. Consider additional factors like certifications, geographic location, and capacity for critical suppliers.
Conduct comprehensive supplier re-evaluation annually before management review. Update supplier performance continuously based on incoming inspection, delivery metrics, and customer feedback. Conduct immediate re-evaluation when significant issues arise or supplier capabilities change. Document all evaluation activities and status changes.
Address failed qualification by marking suppliers as blocked and seeking alternatives. For performance issues with approved suppliers, implement corrective action requests, increase monitoring frequency, or change status to "approved with monitoring." Document all issues and resolution efforts. Severe issues may require supplier blocking and alternative sourcing.
Establish Quality Assurance Agreements (QAA) specifying quality standards, inspection rights, corrective action procedures, and change notification requirements. Include service level agreements for delivery and responsiveness. For critical suppliers, consider non-disclosure agreements and preferential pricing agreements. Ensure all agreements support regulatory compliance requirements.
Require suppliers to notify your organization before implementing changes affecting product specifications, manufacturing processes, or regulatory status. Evaluate changes through design control processes to assess impact on device performance and regulatory compliance. Update supplier qualifications and device documentation as necessary before accepting changes.
Maintain Supplier Qualification Checklists, Approved Supplier List, supplier agreements (QAA, NDAs), performance monitoring records, audit reports, and corrective action documentation. Include purchasing specifications, incoming inspection records, and correspondence regarding specification changes. Ensure documentation supports regulatory compliance and audit requirements.
Evaluate software suppliers based on security standards, data protection compliance, service reliability, and regulatory alignment. For SaaS providers, assess service level agreements, data backup procedures, and business continuity planning. Include software suppliers in validation activities when they support quality management or production processes. Document supplier roles in device development and lifecycle management.
# List Of Regulatory Requirements
Source: https://docs.withdovetail.com/tasks/list-of-regulatory-requirements
Track applicable regulations and standards ensuring comprehensive compliance coverage across all target markets.
## Summary
A **List of Regulatory Requirements** is a structured document that identifies and tracks all applicable regulations, standards, and guidance documents that apply to your medical device. It serves as the foundation for regulatory compliance by ensuring you understand and address every legal obligation relevant to your product. This living document must be regularly updated to reflect changes in regulatory landscapes and supports systematic compliance verification throughout your quality management system.
## Why is a List of Regulatory Requirements important?
The **List of Regulatory Requirements** exists because medical device regulations are complex, constantly evolving, and vary by jurisdiction. You cannot achieve compliance without first understanding exactly which requirements apply to your specific device and intended markets. This document prevents regulatory gaps that could delay market access or result in enforcement actions.
For medical device manufacturers, this list is essential because it **drives all other compliance activities** throughout your product lifecycle. It informs your quality management system design, clinical evaluation strategy, technical documentation requirements, and post-market obligations. The list also demonstrates **due diligence** to regulatory authorities by showing you've systematically identified applicable requirements rather than making assumptions. Without a comprehensive regulatory requirements list, you risk missing critical obligations, facing regulatory delays, or discovering compliance gaps during inspections that could have been prevented through proper planning.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Quality planning must address **applicable regulatory requirements** (Section 820.20)
* Design controls must ensure compliance with **applicable standards** (Section 820.30)
* Must maintain **current awareness** of regulatory changes affecting your devices
* Documentation must demonstrate **systematic compliance** with all applicable requirements
**Special attention required for:**
* FDA guidance documents - while not legally binding, they represent FDA's current thinking
* Consensus standards referenced in FDA guidance (e.g., ISO 14971, IEC 62304)
* State-specific requirements that may apply in addition to federal regulations
* International standards that may be required for global market access
Under **EU MDR 2017/745**:
* Manufacturers must ensure compliance with **all applicable requirements** (Article 10)
* Must maintain **current knowledge** of regulatory developments (Article 10(9))
* Technical documentation must demonstrate compliance with **applicable standards** (Annex II)
* Post-market surveillance must monitor **regulatory changes** affecting devices (Article 83)
**Special attention required for:**
* Harmonized standards published in the Official Journal of the European Union
* MDCG guidance documents that clarify MDR implementation
* National regulations that supplement MDR requirements in specific member states
* Common Specifications (CS) that may become mandatory for certain device types
## Guide
Your **List of Regulatory Requirements** must systematically capture every regulatory obligation that applies to your medical device across all intended markets. This comprehensive approach ensures no compliance gaps and supports systematic verification of regulatory adherence.
### 1. Regulations and Legal Requirements
The **regulations** section identifies the primary legal frameworks that govern your medical device. You must list each applicable regulation with its **full title and reference number**, specify whether your **coverage is full, partial, or none**, provide a **clear description** of what the regulation covers, and document the **last review date** to ensure currency.
For medical devices, core regulations typically include the **EU MDR 2017/745** for European markets, **FDA 21 CFR Part 820** for US markets, and jurisdiction-specific laws like the **German Medical Devices Law (MPDG)** for national requirements. You must also consider **data protection regulations** like GDPR if your device processes personal data, and **cybersecurity frameworks** if your device has network connectivity.
Your coverage assessment should be realistic - many regulations apply partially to specific device types or use cases. Document exactly which sections apply to avoid unnecessary compliance burden while ensuring you don't miss applicable requirements.
### 2. Standards and Technical Requirements
Standards provide the technical specifications and methodologies for demonstrating regulatory compliance. Your list must include **quality management standards** (ISO 13485), **risk management standards** (ISO 14971), **software lifecycle standards** (IEC 62304), **usability engineering standards** (ISO 62366), and **clinical evaluation standards** (ISO 14155) as applicable to your device type.
For each standard, document the **specific version and amendments** you're implementing, as regulatory authorities often reference specific versions. Include the **publication date** and **last review date** to ensure you're working with current versions. Note any **transition periods** for new standard versions that may affect your compliance timeline.
### 3. Guidance Documents and Interpretive Materials
The **guidance documents** section captures non-binding but influential regulatory guidance that clarifies how authorities interpret legal requirements. These documents often provide practical implementation advice and represent current regulatory thinking on complex topics.
Key guidance documents include **MDCG guidance** for EU MDR implementation, **FDA guidance documents** for specific device types or regulatory pathways, **ISO technical reports** that supplement standards, and **industry consensus documents** that provide best practices. While not legally binding, following recognized guidance documents demonstrates good regulatory practice and reduces inspection risk.
### 4. Maintenance and Review Process
Your regulatory requirements list must be a **living document** that reflects the current regulatory landscape. Establish a **regular review cycle** (typically annually or semi-annually) to identify new requirements, updated standards, or changed guidance documents. Assign **responsibility** for monitoring regulatory changes and updating the list accordingly.
Document the **last review date** for each requirement to demonstrate currency and establish **review triggers** such as new product releases, market expansion, or significant regulatory announcements. This systematic approach ensures your compliance activities remain aligned with current requirements.
## Example
**Scenario:** You're developing a software-based medical device for both EU and US markets. Your list includes EU MDR, FDA QSR, GDPR for data protection, ISO 13485 for quality management, IEC 62304 for software lifecycle, and relevant MDCG and FDA guidance documents. You review the list quarterly and update it whenever you receive regulatory alerts or plan market expansion.
### Complete List of Regulatory Requirements Document
**List of Regulatory Requirements**
ID: LRR-2024-001
### 1. Purpose
The purpose of this document is to provide a structured list of applicable regulations, ensuring that all necessary compliance obligations are met. By maintaining an up-to-date record of standards and legal requirements, this document helps facilitate regulatory adherence and supports the ongoing quality and safety of the medical device.
### 2. Scope
This document applies to all medical devices managed by the organization.
### 3. Regulations
| Regulation | Coverage (Full / Partial / None) | Description | Last Review |
| ----------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------- |
| EU Medical Device Regulations 2017/745 | Full | Regulations required for CE marking of medical devices in the EU. | 2024-03-15 |
| (GDPR) General Data Protection Regulation | Full | Regulates the protection of natural persons with regard to the processing of personal data. | 2024-03-15 |
| (MPDG) German Medical Devices Law | Full | Law providing additional medical device requirements to medical products listed in Germany. | 2024-03-15 |
| FDA 21 CFR Part 820 | Full | Quality System Regulation for medical devices marketed in the United States. | 2024-03-15 |
| FDA 21 CFR Part 814 | Partial | Premarket approval requirements for Class III devices (applicable if pursuing PMA pathway). | 2024-03-15 |
| FDA 21 CFR Part 807 | Partial | Establishment registration and device listing requirements for US market. | 2024-03-15 |
| ISO 13485:2016 + AC:2018 + A11:2021 | Full | Quality management systems for medical devices. | 2024-03-15 |
| ISO 14971:2019 | Full | Application of risk management to medical devices. | 2024-03-15 |
| IEC 62304:2006 | Full | Medical device software lifecycle processes. | 2024-03-15 |
| ISO 62366-1:2015 + A1:2021 | Full | Medical devices - Application of usability engineering to medical devices. | 2024-03-15 |
| ISO 14155:2020 | Partial | Clinical investigation of medical devices for human subjects (if clinical studies required). | 2024-03-15 |
| ISO 15223-1:2016 | Full | Medical devices - Symbols to be used with medical device labels, labelling and information to be supplied. | 2024-03-15 |
| ISO/TR 24971:2020 | Full | Medical devices - Guidance on the application of ISO 14971. | 2024-03-15 |
| ISO 20417:2021 | Full | Medical devices - Information to be provided by the manufacturer. | 2024-03-15 |
### 4. Guidance Documents
| Regulation | Coverage (Full / Partial / None) | Description | Last Review |
| --------------------------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------- |
| MDCG 2020-1 | Full | Guidance on clinical evaluation (MDR) / Performance evaluation (IVDR) of medical device software | 2024-03-15 |
| MDCG 2020-5 | Full | Guidance on Clinical Evaluation – Equivalence | 2024-03-15 |
| MDCG 2019-11 | Full | Guidance on Qualification and Classification of Software | 2024-03-15 |
| MDCG 2019-16 rev.1 | Full | Guidance on cybersecurity for medical devices | 2024-03-15 |
| MDCG 2020-7 | Full | Guidance on PMCF plan template | 2024-03-15 |
| MDCG 2020-8 | Full | Guidance on significant changes to the intended purpose | 2024-03-15 |
| MDCG 2020-13 | Full | Guidance on clinical evaluation of medical devices | 2024-03-15 |
| MDCG 2022-12 | Full | Guidance on harmonized administrative practices and alternative technical solutions until Eudamed is fully functional | 2024-03-15 |
| MDCG 2019-7 | Full | Guidance on Article 15 of the MDR and IVDR regarding a "person responsible for regulatory compliance" | 2024-03-15 |
| MDCG 2022-21 | Full | Guidance on Periodic Safety Update Reports (PSURs) according to Regulation (EU) 2017/745 | 2024-03-15 |
| MDCG 2018-1 rev.4 | Full | Guidance on basic UDI-DI and changes to UDI-DI | 2024-03-15 |
| FDA Software as Medical Device Guidance | Full | FDA guidance on software as a medical device (SaMD) regulatory framework | 2024-03-15 |
| FDA Cybersecurity Guidance | Full | Content of Premarket Submissions for Management of Cybersecurity in Medical Devices | 2024-03-15 |
| FDA Clinical Evaluation Guidance | Partial | Clinical evaluation guidance for specific device types (as applicable) | 2024-03-15 |
| FDA 510(k) Guidance | Partial | Guidance for 510(k) submissions (if pursuing 510(k) pathway) | 2024-03-15 |
| ISO/IEC 27001:2013 | Partial | Information security management systems (for cybersecurity compliance) | 2024-03-15 |
| NIST Cybersecurity Framework | Partial | Framework for improving critical infrastructure cybersecurity | 2024-03-15 |
## Q\&A
You should review and update the list at least annually, but also whenever you receive regulatory alerts, plan market expansion, release new products, or become aware of regulatory changes affecting your devices.
Regulations are legally binding requirements that you must comply with. Guidance documents are non-binding interpretations that clarify how regulatory authorities expect you to implement legal requirements, but following them demonstrates good regulatory practice.
Review the scope and applicability sections of each regulation or standard. Consider your device classification, intended use, target markets, and specific features. When in doubt, assume full applicability and seek regulatory consultation.
Yes, include all standards that are directly referenced in applicable regulations, as well as consensus standards that provide recognized methods for demonstrating compliance with regulatory requirements.
Subscribe to regulatory authority newsletters, join industry associations, monitor official journals and websites, and consider using regulatory intelligence services that track changes affecting medical devices.
Add it to your list immediately, assess the compliance gap, develop an implementation plan, and update your quality management system and technical documentation as needed to address the new requirement.
# List of Validated Software
Source: https://docs.withdovetail.com/tasks/list-of-validated-software
Maintain centralized registry of validated software systems with deployment status and ongoing review schedules.
## Summary
**List of Validated Software** provides centralized documentation of all computer systems and software applications that have been validated for use in quality management processes or production/service provision activities affecting medical device quality and regulatory compliance. This essential Quality Management System (QMS) record maintains current validation status, deployment information, and review schedules to ensure ongoing compliance and operational integrity.
## Why is List of Validated Software important?
The List of Validated Software serves as the **central registry** that demonstrates systematic computer system validation across your organization. **Without comprehensive tracking**, organizations risk using unvalidated software, losing validation records, or failing to maintain validation currency through software updates and changes.
**Regulatory compliance demands** systematic documentation of validated systems. FDA Quality System Regulation (21 CFR 820.75) and ISO 13485:2016 (Section 7.5.6) require validation of processes where output cannot be verified through subsequent monitoring. **The validated software list provides evidence** that computer systems affecting quality are systematically controlled and maintained.
The centralized approach transforms software validation from isolated activities into **systematic lifecycle management**. **Well-maintained software lists** support audit readiness, enable proactive validation planning, and provide management oversight of information technology systems critical to quality and regulatory compliance.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **21 CFR Part 11** (Electronic Records):
* **Process validation** required for processes where output cannot be verified by subsequent inspection/test (21 CFR 820.75)
* **Computer system validation** must ensure software performs intended functions reliably
* **Electronic record systems** require validation demonstrating system integrity and compliance
* **Documentation requirements** mandate maintaining records of validation activities and results
**Special attention required for:**
* GAMP 5 compliance for pharmaceutical and medical device computer system validation
* 21 CFR Part 11 systems requiring enhanced validation and ongoing compliance monitoring
* Design control software requiring validation as part of design and development processes
* Quality system software supporting CAPA, document control, and management review activities
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Process validation** mandatory where output cannot be verified through monitoring/measurement (ISO 13485 7.5.6)
* **Computer system validation** required for systems affecting product quality or QMS effectiveness (ISO 13485 4.1.6)
* **Management system documentation** must include procedures for computer system control and validation
* **Risk management principles** apply to software validation approaches and ongoing maintenance
**Special attention required for:**
* EU GDPR compliance for software processing personal data in clinical or quality contexts
* Cybersecurity validation requirements per MDCG 2019-16 guidance for connected devices
* Notified Body expectations for validated software supporting technical documentation
* Software lifecycle management when supporting clinical evaluation and post-market surveillance
## Guide
### Validated Software Registry Management
**Maintain comprehensive software inventory** documenting all validated systems used for quality management or production/service provision. **Include essential information** for each software including name, manufacturer, version, validation form reference, deployment status, and review schedules.
**Update the list systematically** when new software is validated, existing software is updated, or systems are decommissioned. **Ensure accuracy** by cross-referencing with Software Validation Forms and maintaining version control for software deployments.
**Organize information logically** using consistent categorization and naming conventions. **Group software** by functional area, criticality level, or validation status to support management review and audit activities.
### Software Status Tracking
**Document current deployment status** for each validated software including "In Use" for active systems and "Decommissioned" for retired software. **Maintain historical records** of decommissioned software to support audit trails and regulatory inquiries.
**Track validation currency** through last validation dates and next review schedules. **Ensure validation remains current** through planned reviews, version assessments, and revalidation activities when necessary.
**Monitor validation form references** linking each software entry to its comprehensive validation documentation. **Maintain traceability** between the list entries and detailed validation records for audit and compliance purposes.
### Review and Maintenance Scheduling
**Establish systematic review cycles** based on software risk classification and operational criticality. **High-risk or critical systems** may require annual reviews, while lower-risk systems might need review every 2-3 years.
**Plan review activities** to align with management review cycles and audit schedules. **Coordinate reviews** with software vendors, internal IT teams, and quality personnel to ensure comprehensive assessment of validation currency.
**Document review outcomes** including validation status confirmation, identification of needed updates, or requirements for revalidation. **Update the list** based on review findings and schedule follow-up activities as necessary.
### Integration with Quality Management System
**Connect validated software management** with broader quality system processes including change management, risk management, and supplier control. **Consider software changes** through established change control procedures when updates affect validated functions.
**Support audit activities** by maintaining readily accessible records that demonstrate systematic software validation and ongoing control. **Prepare summary reports** showing validation status, overdue reviews, and validation program effectiveness for management and auditor review.
**Coordinate with supplier management** when software vendors perform services affecting product quality. **Include vendor assessment** in software validation approaches and maintain appropriate agreements for software support and change notification.
### Software Lifecycle Management
**Plan for software evolution** including version updates, technology changes, and end-of-life transitions. **Evaluate software changes** for impact on validated functions and determine revalidation requirements systematically.
**Manage software transitions** including migration to new systems, data conversion activities, and parallel operation periods. **Document transition activities** and verify validation status throughout change processes.
**Address software obsolescence** through sunset planning, alternative software evaluation, and validation transfer activities. **Maintain business continuity** while ensuring validation compliance during software lifecycle transitions.
## Example
**Scenario:** Your medical device organization uses multiple software systems for quality management and production activities including an electronic Quality Management System (eQMS), laboratory information management system (LIMS), enterprise resource planning (ERP) system, and various design control software tools.
### Software Inventory Development
You document all validated software in your list including: FormlyAI eQMS v2.3 (critical quality management), LabTech LIMS v4.1 (critical production testing), SAP ERP v12.2 (non-critical business operations), AutoCAD v2024 (critical design control), and MATLAB v2023b (critical design verification).
### Validation Status Documentation
Each software entry references its Software Validation Form document number, showing complete validation documentation. You document last validation dates ranging from recent (eQMS - 3 months ago) to older validations requiring review (MATLAB - 18 months ago). Next review dates are scheduled based on software criticality and risk assessment.
### Deployment Status Tracking
All systems show "In Use" status except for legacy eQMS v1.8 which shows "Decommissioned" following migration to current version. You maintain decommissioned entries for audit trail purposes while clearly indicating they are no longer active in your operations.
### Review Schedule Management
Critical systems (eQMS, LIMS, AutoCAD) have annual review schedules aligned with management review cycles. Non-critical systems (ERP) have biennial review schedules. You track review completion and update validation status based on findings.
### Ongoing Maintenance
During quarterly management reviews, you report validation status including completed reviews, overdue validations, and planned software changes requiring revalidation. The list serves as your central reference for software validation compliance and planning.
## Q\&A
Include all software validated for quality management or production/service provision activities. This covers electronic QMS platforms, manufacturing control systems, laboratory data management systems, design control software, and any applications where failure could affect product quality or regulatory compliance. Exclude general office software unless it supports validated processes.
Update the list immediately when new software is validated, existing software is upgraded, or systems are decommissioned. Review the entire list systematically during management reviews and before internal audits. Ensure the list accurately reflects current software deployment and validation status at all times.
Document software name, manufacturer, current version, processes covered, validation form document number, deployment status (in use/decommissioned), last validation date, and next review date. Include criticality classification and any special monitoring requirements based on risk assessment results.
Evaluate version updates for impact on validated functions. Minor updates may only require updating version numbers after change evaluation. Major updates may require revalidation and new Software Validation Form documentation. Update the list to reflect current deployed versions and maintain validation currency.
Plan software replacement through systematic evaluation of alternatives, including validation requirements for replacement systems. Document transition activities and maintain parallel operations during changeover periods. Update the list to show obsolete software as decommissioned and new software as validated and in use.
The list provides auditors with comprehensive overview of validated software supporting quality and production activities. It demonstrates systematic software validation management and enables efficient audit review. Prepare summary reports showing validation status, review completion, and program effectiveness for audit presentations.
The list serves as an index referencing detailed Software Validation Forms for each validated software. Each list entry should reference its corresponding validation form document number. The list provides summary status while validation forms contain comprehensive validation documentation including requirements, testing, and ongoing monitoring.
Establish review schedules based on software risk and criticality. Schedule reviews to align with management review cycles and audit preparation activities. Track review completion and document outcomes including validation status confirmation or revalidation requirements. Use the list to plan and monitor validation program activities systematically.
# Management Review Report
Source: https://docs.withdovetail.com/tasks/management-review-report
Evaluate quality system effectiveness through executive assessment and strategic planning for continuous improvement.
## Summary
A **Management Review Report** documents the periodic evaluation of your Quality Management System (QMS) by top management. It provides a systematic assessment of QMS performance through Key Performance Indicators (KPIs), audit results, customer feedback, and process effectiveness. The report demonstrates management commitment to quality and drives strategic decisions for continuous improvement of your medical device quality system.
## Why is a Management Review Report important?
The **Management Review Report** exists because regulatory frameworks require top management to take active responsibility for quality management system effectiveness. It's not sufficient for management to simply approve procedures - they must regularly evaluate whether the entire quality system is working and achieving its intended outcomes.
For medical device manufacturers, the Management Review Report is crucial because it **demonstrates executive oversight** to regulatory authorities and notified bodies. It shows that quality decisions are made at the highest organizational level with full awareness of system performance. The report drives **strategic quality planning** by identifying trends, resource needs, and improvement opportunities that require management attention. Without systematic management review, you risk quality system drift, missed improvement opportunities, and regulatory findings related to inadequate management responsibility for quality.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Management responsibility is **mandatory** under Section 820.20
* Management reviews are required under Section 820.20(c) with **executive oversight**
* Must review QMS effectiveness and **adequacy of resources**
* Results must drive **quality planning** and improvement activities
**Special attention required for:**
* Management responsibility (820.20) - executives must actively participate in quality decisions
* Quality planning (820.20(b)) - management reviews inform strategic quality planning
* CAPA system oversight (820.100) - management must review CAPA effectiveness
* Resource management (820.25) - reviews must address adequacy of quality resources
Under **EU MDR 2017/745**:
* Management responsibility is required under **Article 10(9)** for QMS implementation
* Must comply with **EN ISO 13485:2016** requirements for management review (Section 5.6)
* Reviews must be available for **notified body assessment**
* Management must ensure **continual improvement** of the QMS
**Special attention required for:**
* Person Responsible for Regulatory Compliance (PRRC) involvement in reviews
* Post-market surveillance system effectiveness (Articles 83-86)
* Clinical evaluation and PMCF oversight (Article 61)
* Quality management system continual improvement requirements
## Guide
Your **Management Review Report** must systematically evaluate QMS performance and drive strategic quality decisions. The report transforms operational data into management insights that guide resource allocation and improvement priorities.
### 1. Overall QMS Assessment
The **management review assessment** provides your executive summary of quality system performance. This section requires you to synthesize information from multiple sources - audit results, KPI performance, customer feedback, and process metrics - into a clear management perspective on QMS effectiveness.
You must address whether your quality system is **suitable** (appropriate for your organization and products), **adequate** (sufficient to meet regulatory requirements), and **effective** (achieving intended quality outcomes). If performance meets expectations, state this clearly with supporting evidence. If improvements are needed, identify specific areas requiring management attention and resource allocation.
### 2. Key Performance Indicator Review
The **KPI assessment** table provides the detailed data that supports your overall QMS assessment. For each quality process, you must evaluate actual performance against established acceptance criteria and provide a management assessment of results.
Your KPI review should cover all critical quality processes including document control, human resources, software development, risk management, change management, customer feedback, vigilance, CAPA, deployment, validation, post-market surveillance, internal audits, clinical evaluation, regulatory updates, purchasing, sales, and usability engineering.
For each KPI, document the **actual data** collected during the review period, compare it to **acceptance criteria**, provide a **management assessment** of performance, identify any **improvement measures** needed, and evaluate the **effectiveness of previous improvement measures**. This systematic approach ensures comprehensive coverage of quality system performance.
### 3. Management Signatures and Accountability
The **management review signatures** section establishes clear accountability for quality decisions. You must identify the management team members who participated in the review and obtain their formal commitment to the findings and resulting actions.
Include the **position, name, and signature** of each management team member involved in the review. This typically includes senior executives, quality management, and other key decision-makers who have authority to allocate resources and drive organizational change. The signatures demonstrate that management has reviewed the data, understands the implications, and commits to supporting necessary improvements.
### 4. Review Timing and Follow-up
Document the **date of review** and establish clear timelines for implementing any improvement measures identified during the review. The management review should occur at planned intervals (typically annually) but may be conducted more frequently if significant quality issues arise.
Ensure that review findings are properly communicated throughout the organization and that responsible personnel understand their roles in implementing improvement measures. Plan for follow-up activities to verify that improvement measures are effective and achieving intended outcomes.
## Example
**Scenario:** You conduct your annual management review covering the previous 12 months of QMS performance. The review shows that most KPIs are meeting acceptance criteria, but training completion rates have dropped slightly and there's been an increase in customer feedback requiring response. Management decides to implement automated training reminders and enhance the customer feedback process to improve performance in these areas.
### Complete Management Review Report Document
**Management Review Report**
ID: MRR-2024-001
### 1. Scope
This report provides the results of the management review of the quality management system (QMS) performed according to SOP Management Review. The review was conducted to assess the suitability, adequacy, and effectiveness of the QMS and to identify opportunities for improvement, if needed.
### 2. Management Review Assessment
**Overall QMS Assessment:**
The quality management system has performed effectively during the 2023 review period, with 22 of 24 key performance indicators meeting or exceeding acceptance criteria. The QMS demonstrates strong suitability for our medical device operations and adequate resource allocation to maintain regulatory compliance.
Two areas require management attention: training completion rates have decreased from 98% to 92%, and customer feedback response time has increased slightly. These issues do not indicate systemic failures but represent opportunities for process enhancement through improved automation and resource allocation.
The QMS continues to be effective in maintaining product quality, regulatory compliance, and customer satisfaction. No major changes to the quality system structure are required, but targeted improvements in training management and customer communication will enhance overall performance.
#### 2.1 Management Signatures
**Date of Review**: March 20, 2024
| Position | Name | Signature |
| -------------------------- | -------------- | ----------- |
| Chief Executive Officer | Robert Chen | R. Chen |
| Chief Technology Officer | Sarah Martinez | S. Martinez |
| Quality Manager | David Kim | D. Kim |
| Regulatory Affairs Manager | Jennifer Lopez | J. Lopez |
### 3. QMS and Key Performance Indicator Review
| Process | Key Performance Indicator | Data on KPI | Management Assessment | Improvement Measures | Evaluation of Previous Measures |
| --------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------ | -------------------------------------- | ----------------------------------------- |
| Quality Manual | All quality objectives are met | 100% of objectives met | QMS is effective and meets requirements | None | N/A |
| Document and Record Control | Archived documents maintained for device lifetime | 100% of documents retained | Document management process is effective | None | N/A |
| Document and Record Control | No process non-conformities during external audits | 0 non-conformities | Document management process is effective | None | N/A |
| Human Resources | Initial training completion rate for employees | 92% of employees complete | Training process needs improvement | Implement automated training reminders | Previous manual tracking was insufficient |
| Integrated Software Development | Software system testing with limited failures | Failure under 25% of testing | Software development process is effective | None | N/A |
| Integrated Software Development | Known software anomalies lead to no adverse events | 0 adverse events due to known software anomalies | Software development process is effective | None | N/A |
| Software Problem Resolution | Efficient investigation and resolution of software problems | 94% of problems resolved successfully | Software problem resolution process is effective | None | N/A |
| Risk Management | Number of unacceptable risks mitigated | 100% of unacceptable risks mitigated with risk controls | Risk management process is effective | None | N/A |
| Risk Management | Risk controls successfully implemented | 100% of risk controls implemented | Risk management process is effective | None | N/A |
| Change Management | No non-conformities due to incomplete change documentation | 0 non-conformities | Change management process is effective | None | N/A |
| Feedback and Customer Management | Customer feedback response rate | 78% of feedback processed | Customer feedback process needs improvement | Enhance response tracking system | Previous informal tracking was inadequate |
| Vigilance | Incidents reported within legal reporting deadlines | 100% of incidents reported | Vigilance process is effective | None | N/A |
| Corrective and Preventative Action | CAPA closure rate | 93% of CAPAs closed | CAPA process is effective | None | N/A |
| Deployment | No deployment without prior system testing | 100% of deployments tested | Deployment process is effective | None | N/A |
| Software Validation | Software validation completed for all necessary software | 100% of software validated | Software validation process is effective | None | N/A |
| Post-Market Surveillance | PMS Report, PSUR, or Summary of Safety and Clinical Performance delivered within timeframe required | 0 late reports | Post-market surveillance process is effective | None | N/A |
| Internal Audit | Number of internal audits completed on schedule | 100% of audits completed | Internal audit process is effective | None | N/A |
| Clinical Evaluation | On-time and as planned PMCF activities | PMCF activities conducted on schedule | Clinical evaluation process is effective | None | N/A |
| Management Review | Frequency of management review meetings | 1 meeting annually completed | Management review process is effective | None | N/A |
| Update of Regulations | Regulatory updates identified and implemented within six months of publication effective dates | Updates implemented within 4 months average | Regulatory update process is effective | None | N/A |
| Product Registration and Certification | Zero unsuccessful attempts of Notified Body assessment due to incomplete documentation | No failed assessments due to documentation issues | Registration process is effective | None | N/A |
| Purchasing | Supplier acceptance on surveillance | 8% of suppliers moved from accepted to blocked during surveillance | Purchasing process is effective | None | N/A |
| Sales | Sales and marketing materials approved prior to use | 100% of materials approved prior to use | Sales process is effective | None | N/A |
| Usability and Human Factors Engineering | Usability testing with no failed critical tasks | 100% of usability critical tasks passed | Usability engineering process is effective | None | N/A |
### Annex 1 - KPI Acceptance Criteria
The following acceptance criteria were used to evaluate the KPIs:
| Process | KPI | Acceptance Criteria | Primary Responsibility |
| --------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ---------------------- |
| Quality Manual | All quality objectives are met | 100% of objectives met | Quality |
| Document and Record Control | Archived documents maintained for device lifetime | 100% of documents retained | Quality |
| Document and Record Control | No process non-conformities during external audits | 0 non-conformities | Quality |
| Human Resources | Initial training completion rate for employees | 95% of employees complete | Corporate |
| Integrated Software Development | Software system testing with limited failures | Failure under 30% of testing | Software |
| Integrated Software Development | Known software anomalies lead to no adverse events | 0 adverse events due to known software anomalies | Software |
| Software Problem Resolution | Efficient investigation and resolution of software problems | Greater than 90% of problems resolved successfully | Software |
| Risk Management | Number of unacceptable risks mitigated | 100% of unacceptable risks mitigated with risk controls | Quality |
| Risk Management | Risk controls successfully implemented | 100% of risk controls implemented | Quality |
| Change Management | No non-conformities due to incomplete change documentation | 0 non-conformities | Quality |
| Feedback and Customer Management | Customer feedback response rate | Over 80% of feedback processed | Quality |
| Vigilance | Incidents reported within legal reporting deadlines | 100% of incidents reported | Quality |
| Corrective and Preventative Action | CAPA closure rate | Over 90% of CAPAs closed | Quality |
| Deployment | No deployment without prior system testing | 100% of deployments tested | Software |
| Software Validation | Software validation completed for all necessary software | 100% of software validated | Software |
| Post-Market Surveillance | PMS Report, PSUR, or Summary of Safety and Clinical Performance delivered within timeframe required | 0 late reports | Quality |
| Internal Audit | Number of internal audits completed on schedule | 100% of audits completed | Quality |
| Clinical Evaluation | On-time and as planned PMCF activities | PMCF activities conducted on schedule | Quality |
| Management Review | Frequency of management review meetings | At least 1 meeting annually | Management |
| Update of Regulations | Regulatory updates identified and implemented within six months of publication effective dates | Updates implemented within 6 months | Quality |
| Product Registration and Certification | Zero unsuccessful attempts of Notified Body assessment due to incomplete documentation | No failed assessments due to documentation issues | Quality |
| Purchasing | Supplier acceptance on surveillance | Under 10% of suppliers moved from accepted to blocked during surveillance | Product |
| Sales | Sales and marketing materials approved prior to use | 100% of materials approved prior to use | Business |
| Usability and Human Factors Engineering | Usability testing with no failed critical tasks | 100% of usability critical tasks passed | Quality |
## Q\&A
Management reviews must be conducted at least annually, but may be performed more frequently if significant quality issues arise or if required by your quality management system procedures.
Management reviews require participation by personnel with executive responsibility for the QMS. This typically includes senior management, quality management, and other key decision-makers who can authorize resource allocation and organizational changes.
Management reviews should include audit results, customer feedback, process performance data, nonconformities, corrective actions, regulatory changes, and resource adequacy. The specific data depends on your QMS scope and organizational structure.
Management review findings must drive quality planning activities, including resource allocation, process improvements, training needs, and strategic quality objectives for the coming period.
When KPIs fail to meet acceptance criteria, management must identify root causes, implement improvement measures, and establish timelines for corrective action. The effectiveness of these measures should be evaluated in subsequent reviews.
Management review records must be maintained as controlled documents with appropriate retention periods. They serve as evidence of management commitment and must be available for regulatory inspections and notified body assessments.
# Manufacturing Validation Plan and Protocol
Source: https://docs.withdovetail.com/tasks/manufacturing-validation-plan-and-protocol
Establish systematic procedures proving manufacturing processes produce consistent, compliant devices.
## Summary
A Manufacturing Validation Plan and Protocol establishes documented procedures to demonstrate that your manufacturing process consistently produces medical devices meeting predetermined specifications and quality attributes. This critical document outlines the systematic approach for validating manufacturing processes before commercial production begins.
## Why is Manufacturing Validation Plan and Protocol important?
Manufacturing validation ensures your production process reliably creates safe and effective medical devices that meet design specifications. Regulatory authorities require this validation to demonstrate that your manufacturing process is under control and capable of consistently producing devices that comply with quality requirements. Without proper manufacturing validation, you cannot demonstrate that your device will perform as intended when produced at scale, potentially leading to product failures, patient harm, and regulatory non-compliance.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Process validation is **mandatory** under Section 820.75
* Must demonstrate that processes can **consistently** produce conforming products
* Validation activities must be **documented** and include protocols and reports
* **Statistical techniques** must be employed where appropriate (820.250)
* Process validation must occur **before** commercial distribution
**Special attention required for:**
* Software manufacturing processes and automated systems validation
* Sterilization process validation (if applicable)
* Critical process parameters identification and control
* Change control procedures for validated processes
Under **EU MDR 2017/745**:
* Manufacturers must ensure production processes are **validated** (Article 10(9))
* Must comply with **EN ISO 13485:2016** requirements for process validation (Section 7.5.1.1)
* Technical documentation must include **manufacturing information** (Annex II, Section 3)
* Process validation must be part of the **quality management system**
**Special attention required for:**
* Unique Device Identification (UDI) integration in manufacturing processes
* Traceability requirements throughout manufacturing (Article 27)
* Post-market surveillance data integration for process improvement
* Notified body assessment of manufacturing validation documentation
## Guide
Your Manufacturing Validation Plan and Protocol should comprehensively address all aspects of process validation to ensure consistent production of compliant medical devices.
### Planning Phase Documentation
**Validation Scope Definition**: Clearly define which manufacturing processes require validation based on their impact on device safety and performance. Include all critical processes such as assembly, testing, packaging, labeling, and sterilization. Document the rationale for including or excluding specific processes.
**Process Characterization**: Document your understanding of each manufacturing process including inputs, outputs, process parameters, and controls. Identify critical process parameters that directly affect device quality and establish acceptable ranges based on design requirements and risk analysis.
**Validation Approach**: Define your validation strategy including the number of validation runs, acceptance criteria, and statistical methods for data analysis. Establish protocols for Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) where applicable.
### Protocol Development
**Detailed Test Procedures**: Develop step-by-step procedures for each validation activity including equipment setup, process parameters, sampling plans, and measurement methods. Ensure procedures are clear enough for consistent execution by different operators.
**Acceptance Criteria**: Establish quantitative acceptance criteria based on device specifications, regulatory requirements, and risk analysis. Define both individual unit criteria and overall process capability requirements including statistical measures such as Cpk values.
**Documentation Requirements**: Specify all data collection requirements including process parameters, environmental conditions, equipment performance, and product quality measurements. Plan for real-time data collection and batch record documentation.
### Risk-Based Validation Strategy
**Critical Process Identification**: Use risk management principles to identify processes that most significantly impact device safety and effectiveness. Focus validation efforts on these critical processes while applying appropriate controls to less critical processes.
**Failure Mode Analysis**: Document potential failure modes for each manufacturing process and establish validation activities to demonstrate control of these failure modes. Include both equipment failures and process variations in your analysis.
**Contingency Planning**: Develop procedures for handling validation failures including investigation requirements, corrective actions, and re-validation criteria. Establish clear decision trees for proceeding with commercial production.
### Equipment and Facility Qualification
**Equipment Validation**: Document requirements for validating manufacturing equipment including calibration, performance verification, and software validation where applicable. Establish maintenance and re-qualification schedules.
**Environmental Controls**: Define validation requirements for environmental conditions affecting manufacturing including temperature, humidity, cleanliness, and contamination control. Establish monitoring and control procedures.
**Personnel Qualification**: Document training and qualification requirements for personnel involved in manufacturing operations. Include competency assessment procedures and ongoing training requirements.
## Example
### Scenario
You are manufacturing a software-based medical device that includes a mobile application and cloud-based processing system. Your manufacturing process involves software compilation, automated testing, digital signing, and distribution through app stores. You need to validate this software manufacturing process to ensure consistent, secure, and compliant software releases.
### Manufacturing Validation Plan and Protocol
**1. Validation Scope**
This validation covers the complete software manufacturing process from source code compilation through final distribution, including:
* Automated build and compilation processes
* Integrated testing and quality assurance procedures
* Digital signing and security validation
* Distribution package creation and deployment
**2. Critical Process Parameters**
* Source code version control and branch management
* Compilation environment configuration and dependencies
* Automated test execution and pass/fail criteria
* Digital certificate validation and signing procedures
* Distribution package integrity verification
**3. Validation Protocol**
*Installation Qualification (IQ):*
* Verify build environment configuration matches specifications
* Confirm all required software tools and dependencies are installed
* Validate version control system integration and access controls
* Document hardware and software infrastructure specifications
*Operational Qualification (OQ):*
* Execute build process with known test code to verify functionality
* Confirm automated testing framework operates correctly
* Validate digital signing process with test certificates
* Verify distribution package creation meets format requirements
*Performance Qualification (PQ):*
* Execute three consecutive production builds using actual device software
* Demonstrate consistent build outputs with identical source code
* Validate automated test results accuracy through manual verification
* Confirm digital signatures meet security requirements across all builds
**4. Acceptance Criteria**
* 100% successful compilation with zero build errors
* All automated tests must pass with documented traceability
* Digital signatures must validate successfully using certificate authority verification
* Distribution packages must pass integrity checks and malware scanning
* Build process must complete within specified time limits (≤ 30 minutes)
**5. Documentation and Records**
* Build logs with timestamps and version information
* Test execution reports with pass/fail status for each test case
* Digital signature validation certificates
* Distribution package checksums and integrity verification results
* Environmental monitoring data for build infrastructure
## Q\&A
All processes that affect device safety, effectiveness, or quality require validation. This includes assembly, testing, sterilization, packaging, labeling, and software compilation. The extent of validation should be proportional to the risk associated with each process. Critical processes affecting patient safety require more rigorous validation than processes with minimal quality impact.
Typically, three consecutive successful validation runs are required to demonstrate process consistency, though this may vary based on process complexity and risk. For high-risk processes or complex manufacturing, additional runs may be necessary. Statistical analysis should support the conclusion that the process is capable and under control.
Manufacturing validation must be completed before commercial distribution begins. Validation should occur after process development is complete and the manufacturing process is stable. Any significant changes to validated processes require re-validation or validation of the changes.
Process validation demonstrates that a process consistently produces conforming products under normal operating conditions. Process verification confirms that specific process parameters are within acceptable limits during production. Validation is performed initially and after significant changes, while verification is ongoing during routine production.
Software manufacturing validation should cover the complete software build and release process including compilation, testing, digital signing, and distribution. Focus on demonstrating that the process consistently produces identical software from the same source code and that all quality controls function correctly. Include validation of automated testing systems and security controls.
Required documentation includes a validation plan, detailed protocols, validation reports with data and analysis, and procedures for maintaining validated status. All validation activities must be documented with objective evidence demonstrating that acceptance criteria were met. Documentation should be sufficient to support regulatory inspections and audits.
# Manufacturing Validation Report
Source: https://docs.withdovetail.com/tasks/manufacturing-validation-report
Document manufacturing process validation results demonstrating production capability and control.
## Summary
A Manufacturing Validation Report documents the execution and results of manufacturing process validation activities, providing objective evidence that your manufacturing processes consistently produce medical devices meeting predetermined specifications. This report demonstrates compliance with regulatory requirements and supports commercial release decisions.
## Why is Manufacturing Validation Report important?
The Manufacturing Validation Report serves as critical evidence that your manufacturing process is under control and capable of consistently producing safe and effective medical devices. Regulatory authorities require this documentation to verify that validation activities were properly executed and acceptance criteria were met before approving commercial distribution. Without a comprehensive validation report, you cannot demonstrate process capability or justify the release of manufactured devices to market.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Validation reports are **required documentation** under Section 820.75
* Must contain **objective evidence** that processes meet predetermined requirements
* Reports must be **reviewed and approved** by authorized personnel
* Must demonstrate **statistical control** where applicable (820.250)
* Required for **Design History File** documentation (820.30)
**Special attention required for:**
* Statistical analysis and process capability demonstration
* Deviation investigation and resolution documentation
* Approval signatures from qualified personnel
* Integration with overall device validation strategy
Under **EU MDR 2017/745**:
* Validation reports must be part of **technical documentation** (Annex II, Section 3)
* Must demonstrate compliance with **EN ISO 13485:2016** validation requirements
* Reports must be available for **notified body assessment**
* Must support **declaration of conformity** statements
**Special attention required for:**
* Comprehensive data analysis and trending
* Risk-based approach documentation
* Continuous improvement evidence
* Post-market surveillance integration planning
## Guide
Your Manufacturing Validation Report should provide comprehensive documentation of validation execution, results analysis, and conclusions supporting commercial manufacturing decisions.
### Executive Summary and Scope
**Validation Objectives**: Clearly state the purpose and scope of the validation activities including which processes were validated and the rationale for validation approach. Reference the approved validation plan and any deviations from planned activities.
**Process Description**: Provide a concise description of the manufacturing processes that were validated including critical process parameters, equipment used, and environmental conditions. Include process flow diagrams and key control points.
**Validation Approach Summary**: Summarize the validation strategy including the number of validation runs performed, statistical methods employed, and acceptance criteria applied. Document any changes from the original validation plan.
### Detailed Results Documentation
**Protocol Execution Results**: Document the execution of each validation protocol including Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) results. Provide detailed data for each validation run including process parameters, environmental conditions, and product quality measurements.
**Statistical Analysis**: Present comprehensive statistical analysis of validation data including process capability studies, control charts, and trend analysis. Calculate and report process capability indices (Cp, Cpk) and demonstrate statistical control where applicable.
**Acceptance Criteria Assessment**: Systematically evaluate all validation results against predetermined acceptance criteria. Clearly document whether each criterion was met and provide justification for any deviations or non-conformances encountered during validation.
### Deviation and Investigation Documentation
**Deviation Reporting**: Document all deviations from planned validation activities including equipment failures, environmental excursions, and procedural deviations. Provide detailed investigation results and root cause analysis for each deviation.
**Corrective Actions**: Document all corrective actions taken to address deviations including process adjustments, equipment repairs, and procedural modifications. Demonstrate that corrective actions were effective and did not compromise validation integrity.
**Impact Assessment**: Evaluate the impact of deviations on validation conclusions and commercial manufacturing. Document any additional validation activities required to address deviation impacts.
### Process Capability and Control
**Process Performance Metrics**: Present key performance indicators for the validated manufacturing process including yield rates, cycle times, and quality metrics. Establish baseline performance expectations for commercial manufacturing.
**Control Strategy**: Document the control strategy for maintaining validated status during commercial manufacturing including critical process parameters, monitoring requirements, and control limits. Establish procedures for ongoing process verification.
**Change Control Integration**: Define procedures for managing changes to validated processes including change evaluation criteria, re-validation requirements, and approval procedures. Establish clear boundaries for changes that can be made without re-validation.
### Validation Conclusions and Recommendations
**Overall Assessment**: Provide a comprehensive assessment of validation results and conclusions regarding process readiness for commercial manufacturing. Address all validation objectives and demonstrate that acceptance criteria were met.
**Manufacturing Readiness**: Document recommendations for commercial manufacturing including any additional controls, monitoring requirements, or process improvements identified during validation. Establish clear criteria for ongoing process performance assessment.
**Continuous Improvement**: Identify opportunities for process improvement based on validation results and establish plans for implementing improvements. Document lessons learned and recommendations for future validation activities.
## Example
### Scenario
You have completed validation of your software manufacturing process for a mobile medical device application. The validation included three consecutive production builds with comprehensive testing and analysis. You need to document the validation results and conclusions to support commercial release approval.
### Manufacturing Validation Report
**1. Executive Summary**
This report documents the successful validation of the software manufacturing process for the CardioMonitor mobile application (Version 2.1.0). Validation activities were conducted according to the approved Manufacturing Validation Plan (MVP-001) from March 15-22, 2024. Three consecutive validation runs were completed with all acceptance criteria met.
**2. Validation Scope and Objectives**
The validation covered the complete software manufacturing process including:
* Automated source code compilation and build generation
* Integrated testing execution and results verification
* Digital signing and security validation procedures
* Distribution package creation and integrity verification
**3. Validation Results Summary**
*Run 1 (March 15, 2024):*
* Build completion time: 24 minutes, 33 seconds
* Automated test results: 1,247 tests passed, 0 failed
* Digital signature validation: Successful
* Package integrity check: Passed (SHA-256: a1b2c3d4...)
*Run 2 (March 18, 2024):*
* Build completion time: 23 minutes, 47 seconds
* Automated test results: 1,247 tests passed, 0 failed
* Digital signature validation: Successful
* Package integrity check: Passed (SHA-256: a1b2c3d4...)
*Run 3 (March 22, 2024):*
* Build completion time: 24 minutes, 12 seconds
* Automated test results: 1,247 tests passed, 0 failed
* Digital signature validation: Successful
* Package integrity check: Passed (SHA-256: a1b2c3d4...)
**4. Statistical Analysis**
Process capability analysis demonstrates excellent control:
* Build time average: 24.1 minutes (specification: ≤ 30 minutes)
* Build time standard deviation: 0.43 minutes
* Process capability (Cpk): 4.57 (target: ≥ 1.33)
* Test pass rate: 100% across all validation runs
**5. Deviations and Investigations**
One minor deviation occurred during Run 2 when the build server experienced a temporary network connectivity issue lasting 3 minutes. Investigation confirmed no impact on build integrity as the automated retry mechanism functioned correctly. No corrective action required.
**6. Validation Conclusions**
The software manufacturing process has been successfully validated and is ready for commercial production. All acceptance criteria were met with excellent process capability demonstrated. The process consistently produces identical software builds from the same source code with robust quality controls.
**7. Recommendations for Commercial Manufacturing**
* Implement continuous monitoring of build times and test results
* Establish monthly review of process performance metrics
* Maintain current digital certificate management procedures
* Schedule annual re-validation or upon significant infrastructure changes
## Q\&A
A validation report must include the validation protocol execution results, statistical analysis of data, assessment against acceptance criteria, deviation investigations, and overall conclusions. All raw data, calculations, and supporting documentation should be included or referenced. The report must demonstrate that the manufacturing process is capable and under control.
Validation reports should be reviewed by quality assurance, manufacturing, and regulatory personnel. Final approval should be by authorized personnel with appropriate technical expertise and authority. For software manufacturing, this typically includes software quality assurance and regulatory affairs personnel.
All deviations must be documented with detailed investigation results, root cause analysis, and corrective actions taken. The impact of deviations on validation conclusions must be assessed. Minor deviations may not invalidate results if properly investigated and justified, while major deviations may require additional validation activities.
Statistical analysis should demonstrate process capability and control including calculation of process capability indices (Cp, Cpk), control charts, and trend analysis. The specific statistical methods depend on the process and data type. For software manufacturing, focus on consistency metrics and automated test reliability statistics.
Commercial manufacturing can begin only after the validation report demonstrates that all acceptance criteria were met and the process is capable of consistently producing conforming products. The report must be reviewed and approved by authorized personnel before commercial release authorization.
Validation reports should be retained for the life of the device plus additional time as required by applicable regulations. For FDA, this is typically the life of the device. For EU MDR, technical documentation including validation reports must be retained for at least 10 years after the last device was placed on the market.
# Marketing Content
Source: https://docs.withdovetail.com/tasks/marketing-content
Develop regulatory-compliant promotional materials communicating device benefits while maintaining accuracy.
## Summary
Marketing Content for medical devices encompasses **regulatory-compliant promotional materials** that communicate device benefits, clinical evidence, and value propositions to target audiences while adhering to strict medical device advertising regulations. This content includes websites, brochures, presentations, and digital materials that support commercial objectives while maintaining accuracy, evidence-based claims, and regulatory compliance across all marketing channels.
## Why is Marketing Content important?
**Commercial success and market adoption** depend on effective communication of device value propositions to healthcare providers, patients, and other stakeholders. Marketing content serves as the primary vehicle for educating target audiences about device capabilities, clinical benefits, and competitive advantages. Without compliant, compelling marketing materials, even superior medical devices may fail to achieve market penetration and commercial success.
**Regulatory compliance in marketing** is mandatory and strictly enforced by regulatory authorities. Medical device marketing content must comply with specific advertising regulations, avoid unsupported claims, and maintain consistency with approved indications and clinical evidence. Non-compliant marketing materials can result in regulatory enforcement actions, market withdrawal requirements, and significant financial penalties that threaten business viability.
## Regulatory Context
Under **21 CFR Part 801.4** (Labeling) and **21 CFR Part 807.97** (Misbranding):
* Marketing materials are **labeling** subject to FDA oversight and enforcement
* Must be **truthful, not misleading** and supported by adequate evidence
* Cannot make **unsupported claims** beyond approved indications for use
* Must include **appropriate risk information** and contraindications
* Subject to **FDA enforcement** including warning letters and injunctions
**Special attention required for:**
* Off-label use promotion restrictions and FDA guidance compliance
* Clinical evidence requirements for comparative and superiority claims
* Risk information presentation requirements for promotional materials
* Social media and digital marketing compliance with FDA guidance
Under **EU MDR 2017/745 Article 7** (Advertising):
* Marketing materials must not be **misleading** regarding device characteristics
* Cannot make **unsupported claims** about safety, efficacy, or performance
* Must be **consistent with approved indications** and clinical evaluation
* Subject to **national advertising regulations** in each EU member state
* Must include **appropriate risk information** and contraindications
**Special attention required for:**
* National advertising law compliance varies across EU member states
* Clinical evidence requirements for marketing claims and comparisons
* Authorized representative oversight for marketing materials in EU markets
* Post-market surveillance integration with marketing claim validation
## Guide
### Regulatory Compliance Framework
Your **marketing compliance strategy** must establish clear processes for content development, review, and approval that ensure regulatory adherence across all marketing channels. Implement systematic review procedures for all marketing materials, establish clear approval workflows involving regulatory and legal expertise, maintain documentation of evidence supporting all marketing claims, and create monitoring systems for ongoing compliance verification.
**Evidence-based marketing** requires that all claims be supported by appropriate clinical evidence and regulatory approvals. Base marketing claims on approved indications for use and clinical evaluation findings, ensure comparative claims are supported by adequate clinical evidence, avoid unsupported superiority or safety claims, and maintain consistency with regulatory submissions and approved labeling.
### Target Audience Development
**Healthcare provider marketing** requires professional-level content that addresses clinical decision-making needs and practice integration considerations. Develop materials that communicate clinical evidence and outcomes data, address practice workflow integration and efficiency benefits, provide economic value propositions and cost-effectiveness information, and support clinical education and professional development needs.
**Patient and consumer marketing** must be accessible, accurate, and appropriate for the intended user population. Create content that explains device benefits in understandable language, addresses patient concerns and decision-making factors, provides clear information about device use and expectations, and maintains appropriate tone and cultural sensitivity for target demographics.
### Content Development and Messaging
**Value proposition development** articulates clear, compelling reasons for target audiences to choose your device over alternatives. Identify unique clinical benefits and competitive advantages supported by evidence, address specific pain points and unmet needs in target markets, communicate economic value and return on investment for healthcare systems, and demonstrate superior outcomes or efficiency compared to current standard of care.
**Message consistency** ensures coherent communication across all marketing channels and materials. Establish core messaging frameworks that align with regulatory approvals and clinical evidence, maintain consistent terminology and claims across all marketing materials, coordinate messaging between different audience segments and marketing channels, and implement review processes that ensure message alignment and accuracy.
### Digital Marketing and Online Presence
**Website development** serves as the central hub for digital marketing efforts and regulatory compliance. Create comprehensive product information that aligns with approved labeling, provide easy access to Instructions for Use and regulatory information, implement appropriate disclaimers and risk information presentation, and ensure accessibility compliance and user experience optimization.
**Social media and digital advertising** require specialized compliance considerations for medical device marketing. Develop social media policies that ensure regulatory compliance, implement monitoring systems for user-generated content and interactions, create compliant digital advertising that meets platform and regulatory requirements, and establish response protocols for customer inquiries and complaints through digital channels.
### Sales Support and Professional Education
**Sales enablement materials** provide field teams with compliant tools for healthcare provider engagement. Develop presentation templates that include required regulatory information, create clinical evidence summaries and competitive comparison tools, provide objection handling guidance based on approved claims and evidence, and establish training programs for sales teams on regulatory compliance and appropriate marketing practices.
**Professional education programs** support clinical adoption while maintaining regulatory compliance. Design continuing medical education programs that provide clinical value, create clinical case studies and best practice sharing opportunities, develop webinars and educational content that support device adoption, and establish key opinion leader relationships and collaboration programs.
### Monitoring and Compliance Maintenance
**Ongoing compliance monitoring** ensures marketing materials remain accurate and compliant as regulations and evidence evolve. Implement regular review cycles for all marketing materials and claims, establish monitoring systems for regulatory guidance updates and enforcement actions, create update procedures when clinical evidence or regulatory status changes, and maintain audit trails for all marketing content decisions and approvals.
**Performance measurement and optimization** balances commercial effectiveness with regulatory compliance. Track marketing performance metrics and audience engagement, monitor customer feedback and market response to marketing messages, assess competitive positioning and market differentiation effectiveness, and optimize marketing strategies based on performance data while maintaining regulatory compliance.
## Example
**Scenario:** You develop marketing content for "GlucoTracker Pro," a diabetes management application, targeting both endocrinologists and primary care physicians with different value propositions and clinical evidence.
### Healthcare Provider Marketing Materials
**Clinical Evidence Brochure for Endocrinologists:**
**Headline:** "Evidence-Based Diabetes Management: Clinical Outcomes with GlucoTracker Pro"
**Clinical Evidence Section:**
"In a 12-month clinical study of 500 patients with Type 2 diabetes, GlucoTracker Pro demonstrated significant improvement in glycemic control compared to standard care. Patients using GlucoTracker Pro achieved an average HbA1c reduction of 0.8% (p\<0.001) and 73% of patients achieved target HbA1c levels compared to 45% in the control group."
**Practice Integration Benefits:**
"Streamline patient monitoring with automated data collection and trend analysis. Reduce office visit frequency for stable patients while maintaining clinical oversight through remote monitoring capabilities. Integrate seamlessly with existing EMR systems for comprehensive patient record management."
**Economic Value Proposition:**
"Healthcare systems report 25% reduction in diabetes-related emergency department visits and 15% decrease in hospitalization rates among patients using continuous glucose monitoring with GlucoTracker Pro support."
### Primary Care Physician Marketing Materials
**Practice Efficiency Brochure:**
**Headline:** "Simplify Diabetes Management in Primary Care"
**Workflow Benefits:**
"Reduce time spent on diabetes management documentation with automated patient data collection and clinical summary reports. Identify patients requiring intervention through intelligent alert systems and trend analysis. Provide evidence-based patient education materials integrated with clinical monitoring."
**Patient Engagement Features:**
"Improve patient adherence with personalized coaching and medication reminders. Enhance patient-provider communication through secure messaging and data sharing. Support patient self-management with educational resources and goal-setting tools."
**Implementation Support:**
"Complete practice integration support including staff training, EMR integration assistance, and ongoing technical support. Flexible implementation timeline accommodating practice workflow and patient population needs."
### Patient-Facing Marketing Content
**Website Patient Information Section:**
**Headline:** "Take Control of Your Diabetes Management"
**Patient Benefits in Accessible Language:**
"GlucoTracker Pro helps you understand your blood sugar patterns and make informed decisions about your diabetes care. The app provides personalized recommendations based on your individual health data and connects you with your healthcare team for ongoing support."
**Ease of Use Messaging:**
"Simple smartphone app that works with your existing glucose meter. No additional devices required. Step-by-step setup guidance and 24/7 technical support available. Compatible with most smartphones and glucose monitoring devices."
**Safety and Support Information:**
"GlucoTracker Pro supplements but does not replace regular medical care. Always consult your healthcare provider before making changes to your diabetes management plan. Emergency support available 24/7 for urgent questions or technical issues."
### Digital Marketing Campaign
**Social Media Content Strategy:**
**Educational Content Posts:**
"Did you know that continuous glucose monitoring can help identify patterns in your blood sugar that traditional testing might miss? Learn how technology can support your diabetes management journey. #DiabetesAwareness #HealthTech"
**Patient Success Stories (with appropriate disclaimers):**
"Sarah, a Type 2 diabetes patient, shares how GlucoTracker Pro helped her achieve her HbA1c goals. Individual results may vary. Always consult your healthcare provider about diabetes management options."
**Healthcare Provider Engagement:**
"New clinical evidence shows improved patient outcomes with continuous glucose monitoring integration. Download our latest clinical summary for evidence-based diabetes management strategies."
## Q\&A
Medical device marketing materials are considered labeling under FDA and EU MDR regulations and must be truthful, not misleading, and supported by adequate evidence. Content cannot make unsupported claims beyond approved indications, must include appropriate risk information and contraindications, and is subject to regulatory enforcement including warning letters and market withdrawal requirements. All marketing claims must be consistent with regulatory submissions and clinical evidence.
Present clinical evidence accurately and in context, ensuring all claims are supported by appropriate studies and regulatory approvals. Include relevant study details such as patient population, study design, and statistical significance. Avoid cherry-picking data or presenting results out of context. Provide balanced information that includes both benefits and limitations. Ensure comparative claims are supported by head-to-head studies or appropriate indirect comparisons.
Include appropriate risk information and contraindications consistent with approved labeling and Instructions for Use. Present risk information in a balanced manner that doesn't minimize or obscure important safety considerations. Ensure risk information is prominently displayed and easily accessible to target audiences. For promotional materials, include fair balance of benefits and risks as required by regulatory guidance.
Tailor content complexity and terminology to audience expertise levels while maintaining regulatory compliance. Healthcare provider materials can include technical clinical information and professional terminology. Patient materials should use accessible language and focus on practical benefits and safety information. Ensure all audience-specific materials maintain consistency with approved indications and evidence-based claims.
Establish systematic review procedures involving regulatory, legal, and clinical expertise for all marketing materials. Implement clear approval workflows with documented evidence supporting all claims. Create monitoring systems for ongoing compliance verification and regular review cycles. Maintain audit trails for all marketing content decisions and establish update procedures when clinical evidence or regulatory status changes.
Develop social media policies ensuring regulatory compliance across all digital platforms. Implement monitoring systems for user-generated content and customer interactions. Create compliant digital advertising that meets both platform requirements and medical device regulations. Establish response protocols for customer inquiries and complaints through digital channels. Ensure all digital content includes appropriate disclaimers and risk information.
# MDR Device Classification
Source: https://docs.withdovetail.com/tasks/mdr-device-classification
Determine device risk class through systematic rule application ensuring proper conformity assessment procedures.
## Summary
**MDR device classification** determines your medical device's risk class (I, IIa, IIb, or III) under EU Medical Device Regulation 2017/745, which directly impacts your conformity assessment procedure, notified body requirements, and regulatory obligations. Classification is based on your device's intended purpose, duration of use, invasiveness, and specific characteristics according to the detailed rules in Annex VIII. Accurate classification is mandatory for CE marking and market access in the European Union.
## Why is MDR Device Classification Important?
Device classification under the MDR is **fundamental to your entire regulatory strategy** because it determines the level of regulatory scrutiny, required documentation, and conformity assessment pathway. Higher-risk classifications require more extensive clinical evidence, notified body involvement, and ongoing surveillance obligations. Misclassification can result in regulatory delays, additional costs, or market withdrawal. Your classification also affects your quality management system requirements, post-market surveillance obligations, and the depth of technical documentation required for your technical file.
## Regulatory Context
Under **EU MDR 2017/745, Annex VIII**:
* Classification rules are **mandatory and rule-based** - no discretionary interpretation
* Based on **intended purpose, invasiveness, duration of use, and body interaction**
* Determines **conformity assessment procedure** under Annex IX, X, or XI
* Higher classes require **notified body involvement** and more extensive documentation
**Special attention required for:**
* Software medical devices - apply Rules 11 and specific MDCG 2019-11 guidance
* Active implantable devices - automatically Class III under Rule 9
* Devices with medicinal substances - Rule 14 typically results in Class III
* Nanomaterials - Rule 19 with specific exposure potential assessment
## Guide
MDR classification follows a **systematic rule-based approach** using Annex VIII. Start by understanding the fundamental definitions in Chapter 1, particularly duration of use categories: transient (less than 60 minutes), short-term (60 minutes to 30 days), and long-term (more than 30 days).
**Apply the implementing rules systematically.** Rule 3.1 states that classification is governed by intended purpose. Rule 3.5 is critical - if multiple rules apply, use the **strictest rule resulting in higher classification**. This means you must evaluate all potentially applicable rules and select the highest classification result.
**Start with non-invasive device rules (Rules 1-4).** Rule 1 classifies all non-invasive devices as Class I unless other rules apply. Rule 2 addresses devices for channeling or storing body fluids. Rule 3 covers devices that modify biological or chemical composition. Rule 4 applies to devices contacting injured skin or mucous membranes.
**Evaluate invasive device rules (Rules 5-8).** Rule 5 covers body orifice devices based on duration and connection to active devices. Rules 6-8 address surgically invasive devices with increasing duration and specific anatomical considerations. Pay special attention to devices contacting the central circulatory system or central nervous system, which typically result in Class III.
**Consider active device rules (Rules 9-13).** Rule 9 covers therapeutic devices that administer energy. Rule 10 addresses diagnostic and monitoring devices. Rule 11 is specifically for software medical devices and requires careful analysis of clinical decision-making impact. Rules 12-13 cover devices that administer substances and other active devices.
**Apply special rules (Rules 14-22) when relevant.** These cover specific situations like devices incorporating medicinal substances (Rule 14), contraceptive devices (Rule 15), sterilization devices (Rule 16), and nanomaterials (Rule 19). Software devices often require evaluation under Rule 11, which classifies based on the impact of clinical decisions.
**Document your classification justification thoroughly.** Reference the specific Annex VIII rule(s) applied, explain why other rules don't apply, and provide rationale for any interpretation. Your justification must be defensible during notified body assessment and regulatory review.
## Example
### Complete MDR Classification Document
**MDR Classification Document**
ID: MDR-CLASS-2024-001
### Device Duration of Use
Short term - not less than 60 minutes and not more than 30 days.
The CardioWatch Pro is intended for continuous monitoring periods ranging from several hours to multiple days, with typical use cycles of 24-48 hours before requiring charging. The device may be worn continuously for up to 14 days for extended monitoring as prescribed by healthcare providers.
### Device Classification
Class IIa
### Device Classification Justification
CardioWatch Pro is classified as **Class IIa** under EU MDR 2017/745 based on the following analysis of Annex VIII classification rules:
**Rule 10 (Active devices intended for diagnosis and monitoring):**
CardioWatch Pro is an active device intended for monitoring vital physiological processes (heart rate and rhythm). Under Rule 10, active devices intended for monitoring vital physiological parameters are classified as Class IIa, except when "the nature of variations of those parameters is such that it could result in immediate danger to the patient," which would result in Class IIb classification.
**Analysis:** While cardiac arrhythmias can be serious, the CardioWatch Pro is intended for **monitoring and recording** rather than real-time alerting or emergency response. The device does not provide immediate alarms or automated interventions that would place patients in immediate danger if the device malfunctioned. Healthcare providers review recorded data during scheduled appointments or routine monitoring, not for emergency decision-making.
**Rule 11 (Software):**
The device incorporates software that provides information used for monitoring physiological processes. Under Rule 11, software intended to monitor physiological processes is classified as Class IIa, except if intended for monitoring vital physiological parameters where variations could result in immediate danger (Class IIb).
**Analysis:** The software component monitors heart rate and rhythm but does not make autonomous clinical decisions or provide immediate alerts that could result in immediate danger if incorrect. The software provides **information for healthcare provider review** rather than direct clinical decision-making.
**Other Rules Considered:**
* **Rule 1:** Not applicable - device is active, not non-invasive passive device
* **Rule 4:** Not applicable - device contacts intact skin, not injured skin or mucous membrane
* **Rule 9:** Not applicable - device monitors rather than administers therapeutic energy
* **Rule 5:** Not applicable - device is not invasive with respect to body orifices
**Conclusion:** Under Rule 3.5 (strictest rule applies), both applicable rules (Rule 10 and Rule 11) result in Class IIa classification. No rules result in higher classification. Therefore, CardioWatch Pro is classified as **Class IIa**.
## Q\&A
**Always apply the strictest rule** that results in the highest classification according to Rule 3.5. You must evaluate all potentially applicable rules and document why each does or doesn't apply. If two rules could apply, use the one that results in higher classification. This is mandatory under MDR and not subject to interpretation.
Software medical devices are classified under **Rule 11** based on the impact of clinical decisions. Class I for general software, Class IIa for software providing information for clinical decisions, Class IIb for decisions that could cause serious deterioration or surgical intervention, and Class III for decisions that could cause death or irreversible deterioration. Reference MDCG 2019-11 guidance for detailed examples.
**Yes, but with significant limitations.** You can potentially achieve lower classification by narrowing your intended purpose, but this limits your market scope and labeling claims. Any classification strategy must be **genuine and defensible** - you cannot artificially limit intended use just to avoid higher classification if your device's actual capabilities suggest broader use.
If you disagree with your notified body's classification, you can **request clarification** and provide additional justification. If disagreement persists, you can consult with competent authorities or seek a second opinion from another notified body. However, classification disputes can cause significant delays, so ensure your initial classification is well-documented and defensible.
Review your classification whenever you make **significant changes to intended purpose, design, or functionality**. Minor software updates or design improvements typically don't affect classification, but new features, expanded indications, or changes to clinical decision-making capabilities may require reclassification. Document your review process and rationale for maintaining or changing classification.
**Yes, accessories are classified separately** according to Rule 3.2. Each accessory is classified based on its own intended purpose and characteristics. Software that drives a device falls within the same class as the device, but **independent software is classified separately**. This can result in different classification requirements for different components of your system.
# Mechanical Design
Source: https://docs.withdovetail.com/tasks/mechanical-design
Define physical structure, materials and mechanical specifications ensuring safety and biocompatibility.
## Summary
The Mechanical Design document defines the physical structure, materials, and mechanical specifications of your medical device. This document covers component design, material selection, manufacturing processes, and mechanical safety requirements essential for reliable device performance and patient safety.
## Why is Mechanical Design important?
Mechanical design documentation is **essential for patient safety** because the physical structure directly affects device functionality and user interaction. Poor mechanical design can lead to **device failure**, **user injury**, or **contamination risks** that compromise patient care. Regulatory authorities require detailed mechanical specifications to ensure devices are robust, biocompatible, and suitable for their intended use environment.
The mechanical design also demonstrates that you have systematically considered **material biocompatibility**, **structural integrity**, and **manufacturing feasibility**. This documentation supports **risk management**, **usability engineering**, and **verification activities** throughout the development process.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **ISO 10993** (Biological Evaluation):
* Mechanical specifications must be **documented** as design inputs
* **Biocompatibility** requirements per ISO 10993 series standards
* **Material safety** and chemical characterization requirements
* **Mechanical testing** per relevant ASTM and ISO standards
**Special attention required for:**
* Biocompatibility testing for patient-contacting materials
* Mechanical strength and fatigue testing requirements
* Sterilization compatibility and material degradation
* Human factors considerations for mechanical interfaces
Under **EU MDR 2017/745** and **General Safety and Performance Requirements**:
* Mechanical design must comply with **Essential Requirements** Annex I
* **Biocompatibility** per EN ISO 10993 for patient-contacting materials
* **Mechanical safety** per relevant harmonized standards
* **Material documentation** including chemical composition and safety data
**Special attention required for:**
* CE marking requirements for mechanical safety and biocompatibility
* Harmonized standards compliance (ISO 10993, ISO 14971)
* Material supplier documentation and certificates of compliance
* Post-market surveillance for mechanical failures
## Guide
### Understanding Mechanical Design
Mechanical design encompasses **all physical aspects** of your medical device including structure, materials, and manufacturing. Key areas include:
* **Structural Design**: Load-bearing components, joints, fasteners, and mechanical assemblies
* **Material Selection**: Biocompatible materials, mechanical properties, and environmental resistance
* **Manufacturing Processes**: Machining, molding, additive manufacturing, and assembly methods
* **Surface Treatments**: Coatings, textures, sterilization compatibility, and wear resistance
* **Mechanical Interfaces**: User controls, connections, mounting systems, and ergonomic features
### Material Selection and Biocompatibility
Document material choices systematically:
* **Material Specifications**: Grade, composition, mechanical properties, and supplier information
* **Biocompatibility Assessment**: ISO 10993 testing requirements based on contact type and duration
* **Chemical Compatibility**: Resistance to cleaning agents, sterilization methods, and body fluids
* **Mechanical Properties**: Strength, stiffness, fatigue resistance, and temperature stability
* **Supply Chain Documentation**: Material certificates, traceability, and quality agreements
### Structural Design and Analysis
Your mechanical design should address:
* **Load Analysis**: Static and dynamic loads, safety factors, and failure modes
* **Stress Analysis**: Finite element analysis (FEA) for critical components and assemblies
* **Fatigue Assessment**: Cyclic loading analysis for components subject to repeated use
* **Tolerance Analysis**: Dimensional tolerances, stack-up analysis, and assembly requirements
* **Environmental Conditions**: Temperature, humidity, vibration, and shock resistance
### Manufacturing and Assembly
Document production requirements:
* **Manufacturing Processes**: Detailed process specifications, tooling requirements, and quality controls
* **Assembly Procedures**: Step-by-step assembly instructions, torque specifications, and inspection points
* **Quality Control**: Dimensional inspection, material testing, and process validation requirements
* **Packaging Design**: Protective packaging, sterilization packaging, and shelf-life considerations
* **Traceability Systems**: Component tracking, lot control, and recall procedures
### Mechanical Safety and Testing
Address safety through design:
* **Failure Mode Analysis**: Identification of potential mechanical failures and their consequences
* **Safety Testing**: Mechanical testing protocols per relevant standards (ASTM, ISO, IEC)
* **Durability Testing**: Accelerated aging, wear testing, and lifetime validation
* **User Safety**: Sharp edges, pinch points, ergonomic hazards, and protective features
* **Maintenance Requirements**: Serviceability, replacement parts, and user maintenance procedures
## Example
**Scenario**: You're developing a handheld ultrasound probe that must withstand repeated use in clinical environments while maintaining precise acoustic performance. Your mechanical design must ensure durability, biocompatibility, and ergonomic usability.
### Material Selection
**Housing Material**: Medical-grade polycarbonate (PC-ISO) with biocompatibility per ISO 10993-5 and ISO 10993-10. Material provides impact resistance, chemical compatibility with disinfectants, and transparency for internal component visibility.
**Transducer Housing**: Aluminum 6061-T6 with anodized surface treatment for corrosion resistance and electrical isolation. Material selection based on acoustic properties, thermal conductivity, and manufacturing precision requirements.
**Cable Assembly**: Medical-grade TPU (thermoplastic polyurethane) jacket with biocompatibility certification. Cable design includes strain relief, flexibility for 100,000 bend cycles, and resistance to cleaning chemicals.
**Sealing Components**: Medical-grade silicone elastomer (USP Class VI) for O-rings and gaskets. Material provides IP67 ingress protection, sterilization compatibility, and long-term sealing performance.
### Structural Design Specifications
**Overall Dimensions**: 180mm length × 45mm width × 25mm thickness, weight \<300g for single-handed operation
**Grip Design**: Ergonomic contours with textured surface for secure handling in wet conditions. Grip diameter optimized for 5th to 95th percentile hand sizes.
**Transducer Array**: 128-element linear array with 0.3mm pitch, protected by acoustic lens and wear plate. Array mounting designed for thermal expansion compensation.
**Internal Structure**: Ribbed housing design with integrated cable strain relief. FEA analysis confirms safety factor >3 for 2-meter drop test.
### Manufacturing and Assembly
**Housing Manufacturing**: Injection molding with Class 8 surface finish. Mold design includes integrated threads, snap features, and cable entry with overmolding capability.
**Transducer Assembly**: Precision machining of aluminum housing with +/-0.025mm tolerance. Acoustic matching layers applied using controlled-environment bonding process.
**Cable Assembly**: Multi-conductor cable with individual shielding, assembled using automated crimping and overmolding processes. 100% electrical testing before final assembly.
**Final Assembly**: Clean room assembly with documented procedures, torque specifications, and functional testing. Each unit receives unique serial number for traceability.
### Testing and Validation
**Mechanical Testing**: Drop testing per IEC 60601-1-11, vibration testing per ASTM D4169, and IP67 ingress protection testing per IEC 60529.
**Biocompatibility Testing**: ISO 10993-5 cytotoxicity testing for all patient-contacting materials. ISO 10993-10 irritation and sensitization testing for prolonged skin contact.
**Durability Testing**: 500,000 cycle button actuation testing, 100,000 cycle cable flex testing, and accelerated aging per ASTM F1980.
**Acoustic Performance**: Transducer sensitivity, beam profile, and acoustic output testing per IEC 60601-2-37 ultrasound equipment standards.
## Q\&A
Include enough detail for engineers to manufacture the device and for verification teams to test it. Specify materials with grades and suppliers, dimensional tolerances, surface finishes, and assembly requirements. Document both functional requirements (what the device must do) and manufacturing requirements (how it will be made).
Use ISO 10993-1 to categorize your device by contact type (surface, external communicating, implant) and contact duration (limited, prolonged, permanent). This determines which biocompatibility tests are required. Consider all patient-contacting materials including housings, cables, and accessories.
Testing requirements depend on your device type and intended use. Common tests include drop testing, vibration testing, ingress protection testing, and durability testing. Follow relevant standards (IEC 60601 series, ASTM, ISO) and consider your specific use environment and failure modes.
Provide detailed process specifications including tooling requirements, process parameters, quality controls, and inspection procedures. Include assembly drawings, torque specifications, and material handling requirements. Document any special processes like sterilization, coating, or heat treatment.
Consider the user environment, task requirements, and anthropometric data for your target users. Design for single-handed operation where appropriate, minimize force requirements, and provide clear visual and tactile feedback. Follow human factors engineering principles and plan for usability validation testing.
Establish material specifications with approved suppliers, maintain certificates of compliance, and implement lot tracking systems. Document material properties, test results, and any changes to formulations or suppliers. Plan for material qualification and re-qualification procedures.
# Other Languages Translated IFUs
Source: https://docs.withdovetail.com/tasks/other-languages-translated-ifus
Develop additional language versions ensuring consistent safety information across global markets.
## Summary
Other Languages Translated IFUs are **additional language versions** of your Instructions for Use required for secondary markets beyond your primary target market. These translations must maintain complete regulatory accuracy and cultural appropriateness while ensuring consistent safety information and operational guidance across all target markets. Each translation serves specific regional markets with unique language requirements and regulatory considerations.
## Why is Other Languages Translated IFUs important?
**Market access requirements** mandate local language instructions for regulatory compliance in each target market. Many countries require Instructions for Use in their official language as a condition for device registration and market authorization. Without proper translations, you cannot legally distribute your device in these markets, significantly limiting your commercial opportunities and regulatory compliance.
**User safety and comprehension** depend on accurate, culturally appropriate instructions in users' native languages. Medical device instructions contain critical safety information that users must fully understand to prevent adverse events and ensure effective device operation. Poor or missing translations can lead to user errors, regulatory violations, and significant liability exposure across multiple markets.
## Regulatory Context
Under **21 CFR Part 801.15** (Medical device labeling):
* Instructions must be **understandable to intended users** in their primary language
* **Multi-language markets** may require multiple language versions
* **Accuracy requirements** apply to all translated content regardless of market size
* **Professional translation** recommended for regulatory compliance
* **Consistency requirements** across all language versions for regulatory submissions
**Special attention required for:**
* Puerto Rico and US territories requiring Spanish language instructions
* Native American tribal markets with specific language requirements
* Export markets requiring FDA-compliant English plus local language versions
* Consistency with 510(k) submissions across all intended markets
Under **EU MDR 2017/745 Article 10(11)**:
* Information must be in **official language of each target market**
* **Multi-language EU markets** require multiple official language versions
* **Professional translation required** for all market languages
* **Notified body assessment** may include all language versions
* **Authorized representative** information must be accurately translated for each market
**Special attention required for:**
* Belgium, Switzerland, and other multi-language markets requiring multiple versions
* Regional language variations within single markets (e.g., Catalan in Spain)
* Brexit implications for UK market language requirements
* Version control complexity across multiple EU language versions
## Guide
### Multi-Language Strategy Development
Your **translation strategy** should prioritize markets based on commercial importance, regulatory complexity, and resource requirements. Develop a phased approach that begins with your primary language translation and systematically adds secondary markets based on business priorities. Consider translation dependencies where one language version can serve multiple markets or regions.
**Market prioritization** helps optimize translation resources and timeline management. Evaluate market size and revenue potential, regulatory complexity and timeline requirements, translation resource availability and cost considerations, and competitive landscape language standards. Establish clear criteria for market entry sequence and translation priority to maximize commercial impact while managing resource constraints.
### Translation Project Management
**Centralized translation management** ensures consistency and quality across all language versions. Establish standardized translation processes and quality criteria, maintain comprehensive terminology databases across all languages, implement version control systems that track relationships between all language versions, and coordinate translation timelines with market entry strategies and regulatory submission requirements.
**Resource coordination** optimizes translation efficiency and cost management. Develop relationships with qualified medical translators for each target language, establish translation memory systems to leverage previous work and ensure consistency, implement project management systems for tracking multiple concurrent translation projects, and coordinate review cycles across multiple languages and markets.
### Quality Assurance Across Languages
**Standardized quality processes** ensure consistent accuracy across all language versions. Implement uniform back-translation verification procedures for all languages, establish medical terminology consistency checks across language families and regions, conduct cultural appropriateness reviews by native speakers with medical expertise, and maintain regulatory compliance verification for each target market's specific requirements.
**Cross-language consistency** prevents conflicting information and regulatory compliance issues. Establish terminology databases that maintain consistency across related languages, implement review processes that identify and resolve conflicts between language versions, coordinate updates across all language versions when source documents change, and maintain audit trails for all translation decisions and quality assurance activities.
### Regulatory Compliance Management
**Market-specific compliance** ensures each translation meets local regulatory requirements. Research and document language requirements for each target market, verify compliance with local medical device labeling regulations, confirm accuracy of regulatory symbols and explanations for each market, and establish relationships with local regulatory experts for compliance verification and ongoing support.
**Documentation and traceability** support regulatory submissions and compliance verification. Maintain comprehensive records of translation processes and quality assurance activities, document translator qualifications and experience for each language, establish version control systems that track all language versions and their relationships, and prepare regulatory submission documentation that demonstrates translation quality and compliance.
### Implementation and Maintenance
**Coordinated deployment** ensures translated IFUs are available when devices enter new markets. Synchronize translation completion with market entry timelines and regulatory approval processes, establish distribution systems for translated instructions in each target market, coordinate customer support availability in target languages, and implement user feedback collection systems for translation quality improvement.
**Ongoing maintenance** keeps all language versions current and accurate. Establish procedures for updating all language versions when source documents change, implement regular review cycles for translation accuracy and cultural appropriateness across all markets, maintain translator relationships for consistent terminology and style in each language, and monitor user feedback across all markets for translation improvement opportunities.
## Example
**Scenario:** Your diabetes management application "GlucoTracker Pro" expands beyond the German market to include French, Spanish, Italian, and Dutch markets, requiring comprehensive multi-language IFU development.
### Multi-Language Project Planning
**Market Prioritization Strategy:**
You prioritize translations based on market analysis: French for France and Belgium (largest market opportunity), Spanish for Spain (significant diabetes population), Italian for Italy (regulatory pathway established), and Dutch for Netherlands and Belgium (completing Benelux coverage). This sequence optimizes commercial impact while managing translation resources efficiently.
**Translation Resource Coordination:**
You establish relationships with certified medical translators for each language, all with specific experience in diabetes management devices and EU MDR requirements. A centralized project manager coordinates timelines, terminology consistency, and quality assurance across all languages to ensure synchronized market entry.
### Language-Specific Development
**French Translation (France/Belgium):**
"GlucoTracker Pro est destiné à être utilisé par des adultes atteints de diabète de type 1 ou de type 2 pour surveiller les niveaux de glucose sanguin et recevoir des recommandations de style de vie."
**Spanish Translation (Spain):**
"GlucoTracker Pro está destinado para uso por adultos con diabetes tipo 1 o tipo 2 para monitorear los niveles de glucosa en sangre y recibir recomendaciones de estilo de vida."
**Italian Translation (Italy):**
"GlucoTracker Pro è destinato all'uso da parte di adulti con diabete di tipo 1 o di tipo 2 per monitorare i livelli di glucosio nel sangue e ricevere raccomandazioni sullo stile di vita."
**Dutch Translation (Netherlands/Belgium):**
"GlucoTracker Pro is bestemd voor gebruik door volwassenen met type 1 of type 2 diabetes om bloedglucosewaarden te monitoren en levensstijladviezen te ontvangen."
### Cross-Language Quality Assurance
**Terminology Consistency Management:**
You develop comprehensive terminology databases for diabetes-related terms across all Romance and Germanic languages. Key terms like "blood glucose," "insulin sensitivity," and "glycemic control" receive standardized translations that maintain medical accuracy while ensuring cultural appropriateness in each market.
**Cultural Adaptation Verification:**
Each translation undergoes cultural appropriateness review by native speakers with diabetes management expertise. French reviewers confirm terminology aligns with French healthcare system practices, Spanish reviewers verify compatibility with Spanish diabetes care protocols, and similar reviews ensure cultural appropriateness across all target markets.
**Regulatory Compliance Coordination:**
All translations undergo regulatory compliance verification for their specific markets. French versions comply with ANSM requirements, Spanish versions meet AEMPS standards, Italian versions satisfy ISS regulations, and Dutch versions conform to IGJ requirements, ensuring market-specific regulatory compliance.
### Implementation and Maintenance Strategy
**Synchronized Market Entry:**
Translation completion coordinates with regulatory approval timelines in each market. French and Spanish translations complete first to support priority market entries, followed by Italian and Dutch versions as regulatory approvals progress. Customer support teams receive training in diabetes terminology for each target language.
**Version Control Management:**
A centralized document management system tracks relationships between all language versions and the English master document. When source documents require updates, all language versions receive synchronized updates to maintain regulatory compliance and user safety across all markets.
## Q\&A
Prioritize translations based on market size and revenue potential, regulatory complexity and timeline requirements, translation resource availability and cost considerations, and competitive landscape standards. Evaluate each market's commercial importance, regulatory pathway complexity, and resource requirements to establish a phased translation approach. Consider translation dependencies where one language version can serve multiple markets or regions to optimize resource utilization.
Key challenges include terminology consistency across language families and regions, coordinated updates when source documents change, cultural adaptation while maintaining regulatory accuracy, and version control complexity across multiple languages. Establish terminology databases, implement standardized quality processes, coordinate review cycles across languages, and maintain comprehensive audit trails for all translation decisions to address these challenges effectively.
Address cultural differences through native speaker review by medical experts, adaptation of medical terminology to local healthcare practices, consideration of healthcare system integration differences, and verification of regulatory symbol recognition and interpretation. Maintain regulatory accuracy while enhancing cultural appropriateness through professional medical translation services with local market expertise and ongoing cultural appropriateness reviews.
Implement uniform back-translation verification procedures for all languages, establish medical terminology consistency checks across language families, conduct cultural appropriateness reviews by qualified native speakers, and maintain regulatory compliance verification for each target market. Use standardized quality processes, cross-language consistency checks, and comprehensive documentation to ensure accuracy and compliance across all language versions.
Research and document language requirements for each target market, verify compliance with local medical device labeling regulations, confirm accuracy of regulatory symbols and explanations for each market, and establish relationships with local regulatory experts. Maintain comprehensive records of compliance verification activities and prepare regulatory submission documentation that demonstrates translation quality and market-specific compliance.
Consider professional medical translator costs for each language, quality assurance and back-translation verification expenses, ongoing maintenance and update costs across all languages, and regulatory compliance verification requirements for each market. Develop relationships with qualified translators, establish translation memory systems for efficiency, implement centralized project management, and coordinate timelines to optimize resource utilization and cost management across multiple language projects.
# Packaging and Shelf Life Design
Source: https://docs.withdovetail.com/tasks/packaging-and-shelf-life-design
Design protective packaging systems and validate shelf life ensuring product integrity and sterility.
## Summary
The Packaging and Shelf Life Design document defines the protective packaging systems and shelf life specifications for your medical device. This document covers primary packaging, secondary packaging, sterilization packaging, labeling requirements, and shelf life validation essential for product integrity and regulatory compliance.
## Why is Packaging and Shelf Life Design important?
Packaging design documentation is **critical for product integrity** because packaging protects your medical device from contamination, damage, and degradation throughout its lifecycle. Poor packaging design can lead to **sterility breaches**, **product damage**, or **labeling errors** that compromise patient safety. Regulatory authorities require detailed packaging specifications to ensure devices remain safe and effective until use.
The packaging design also demonstrates that you have systematically considered **sterilization compatibility**, **shelf life validation**, and **supply chain protection**. This documentation supports **risk management**, **stability testing**, and **regulatory submission** activities throughout the development process.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **21 CFR Part 801** (Labeling):
* Packaging specifications must be **documented** as design inputs
* **Sterilization packaging** requirements per ISO 11607 series standards
* **Labeling requirements** per 21 CFR Part 801 and device-specific guidance
* **Shelf life validation** per FDA guidance documents
**Special attention required for:**
* Sterilization validation for packaging systems
* Package integrity testing and validation protocols
* Labeling compliance including UDI requirements
* Shelf life studies and stability testing protocols
Under **EU MDR 2017/745** and **General Safety and Performance Requirements**:
* Packaging must comply with **Essential Requirements** Annex I
* **Sterilization packaging** per EN ISO 11607 for sterile devices
* **Labeling requirements** per MDR Article 10 and Annex I
* **UDI requirements** per MDR Article 27 and implementing regulations
**Special attention required for:**
* CE marking and conformity assessment requirements
* Multi-language labeling for EU market access
* EUDAMED registration and UDI compliance
* Post-market surveillance for packaging failures
## Guide
### Understanding Packaging Design
Packaging design encompasses **all protective and informational elements** that contain and identify your medical device. Key components include:
* **Primary Packaging**: Direct device contact packaging including pouches, trays, and protective films
* **Secondary Packaging**: Outer packaging including boxes, cartons, and shipping containers
* **Sterilization Packaging**: Specialized packaging that maintains sterility after sterilization processes
* **Labeling Systems**: All text, symbols, and graphics that identify and provide information about the device
* **Protective Features**: Cushioning, moisture barriers, and tamper-evident seals
### Sterilization Packaging Requirements
For sterile medical devices, document:
* **Packaging Materials**: Sterilization-compatible materials per ISO 11607 Part 1
* **Seal Integrity**: Heat seal parameters, peel strength, and integrity testing methods
* **Sterilant Penetration**: Material permeability for sterilization gases or radiation
* **Microbial Barriers**: Barrier properties that maintain sterility during storage and handling
* **Package Design**: Aseptic presentation features for sterile opening procedures
### Labeling and Information Design
Your labeling system must include:
* **Device Identification**: Product name, model number, and manufacturer information
* **Regulatory Information**: CE marking, FDA clearance numbers, and classification details
* **Safety Information**: Warnings, precautions, and contraindications
* **Usage Instructions**: Symbols, directions, and reference to instructions for use
* **Traceability Information**: Lot numbers, serial numbers, and UDI compliance
### Shelf Life and Stability
Document shelf life determination:
* **Stability Testing**: Accelerated aging studies and real-time aging protocols
* **Package Integrity**: Seal strength testing and barrier property validation over time
* **Product Performance**: Functional testing after storage under various conditions
* **Environmental Conditions**: Temperature, humidity, and light exposure limits
* **Expiration Dating**: Shelf life assignment and dating format requirements
### Packaging Validation and Testing
Establish comprehensive testing protocols:
* **Package Integrity Testing**: Bubble leak testing, dye penetration, and vacuum decay methods
* **Distribution Testing**: Vibration, compression, and drop testing per ASTM D4169
* **Sterilization Validation**: Process validation for packaging materials and configurations
* **Accelerated Aging**: ASTM F1980 protocols for shelf life validation
* **User Testing**: Package opening studies and usability validation
### Supply Chain and Distribution
Consider distribution requirements:
* **Transportation Protection**: Shock, vibration, and temperature protection during shipping
* **Storage Requirements**: Warehouse conditions and stacking limitations
* **Handling Instructions**: Special handling requirements and orientation markings
* **Inventory Management**: First-in-first-out (FIFO) rotation and expiration tracking
* **International Shipping**: Customs documentation and international labeling requirements
## Example
**Scenario**: You're developing packaging for a sterile surgical instrument that requires ethylene oxide sterilization and has a 5-year shelf life. Your packaging must maintain sterility, protect the instrument, and provide clear identification and instructions.
### Packaging System Design
**Primary Package**: Medical-grade Tyvek/polyethylene pouch (150mm × 200mm) with heat-sealed edges. Tyvek provides ethylene oxide penetration while maintaining microbial barrier. Transparent polyethylene window allows visual inspection without opening.
**Secondary Package**: Corrugated cardboard box (200mm × 250mm × 50mm) with foam insert for shock protection. Box includes tamper-evident tape and orientation arrows. Inner box provides additional protection and professional presentation.
**Tertiary Package**: Master shipping carton containing 20 individual devices with protective foam and desiccant packets. Carton designed for automated handling with standardized dimensions for efficient shipping.
### Sterilization Packaging Specifications
**Material Selection**: DuPont Tyvek 1073B medical packaging with 75-micron thickness for optimal ethylene oxide penetration and microbial barrier properties. Polyethylene film (50-micron) provides transparent viewing window and heat-seal compatibility.
**Seal Parameters**: Heat seal temperature 180°C, pressure 40 PSI, dwell time 2 seconds. Seal width 10mm minimum with peel strength 1.5-4.0 lbf per ASTM F88. Gradient seal design prevents channel leaks.
**Sterilization Compatibility**: Validated for ethylene oxide sterilization at 54°C with 12-hour cycle time. Package maintains integrity through degassing period and demonstrates sterility maintenance for 5-year shelf life.
### Labeling and Identification
**Primary Label**: Waterproof polyester label (50mm × 75mm) with device name, model number, lot number, expiration date, and sterilization indicator. Includes CE marking and UDI barcode per GS1 standards.
**Secondary Label**: Full-color product label with instructions for use symbols, warnings, and manufacturer contact information. Multi-language text for EU compliance including English, German, French, and Spanish.
**Shipping Label**: Master carton label with product description, quantity, storage conditions, and handling instructions. Includes orientation arrows and "Do Not Stack" markings for fragile contents.
### Shelf Life Validation
**Accelerated Aging**: ASTM F1980 protocol using 55°C aging to simulate 5-year shelf life in 6 months. Package integrity testing every 2 weeks including seal strength, leak testing, and sterility maintenance.
**Real-Time Aging**: Parallel real-time study at ambient conditions (23°C, 50% RH) with testing at 6-month intervals. Includes package integrity, product functionality, and sterility testing.
**Environmental Testing**: Temperature cycling (-20°C to +60°C), humidity exposure (85% RH), and UV exposure testing to validate package performance under distribution and storage conditions.
### Testing and Validation Protocols
**Package Integrity**: Bubble leak testing per ASTM F2096, dye penetration testing per ASTM F1929, and vacuum decay testing for quantitative leak detection. Acceptance criteria: no detectable leaks.
**Distribution Testing**: ASTM D4169 Level II testing including vibration (1 hour), compression (24 hours), and drop testing (1.2 meter height). Package must maintain integrity and protect device.
**Sterilization Validation**: ISO 11135 ethylene oxide sterilization validation with biological indicators and chemical indicators. Sterility testing per ISO 11737 with 10^-6 sterility assurance level.
**Usability Testing**: Package opening studies with healthcare professionals to validate aseptic presentation and ease of opening. Testing includes gloved and non-gloved conditions.
## Q\&A
Include enough detail for packaging suppliers to manufacture the system and for verification teams to test it. Specify materials with grades and suppliers, dimensions with tolerances, seal parameters, and testing requirements. Document both functional requirements (barrier properties, protection) and regulatory requirements (labeling, sterilization compatibility).
Conduct stability testing using both accelerated aging (ASTM F1980) and real-time aging studies. Test package integrity, product functionality, and sterility maintenance over time. Consider worst-case storage conditions and establish shelf life based on the earliest failure point with appropriate safety margins.
Follow ISO 11607 Part 1 for packaging materials and Part 2 for validation requirements. Ensure materials are compatible with your sterilization method, provide adequate microbial barriers, and allow sterilant penetration. Validate seal integrity and sterility maintenance throughout the intended shelf life.
Consider varying regulatory requirements, climate conditions, and distribution methods across markets. Design for worst-case shipping conditions including temperature extremes, humidity, and handling stresses. Include multi-language labeling and ensure compliance with regional marking requirements (CE, FDA, Health Canada).
Conduct package integrity testing (leak testing), distribution testing (ASTM D4169), accelerated aging studies, and sterilization validation. Test both individual packages and master cartons. Include usability testing for package opening and sterile presentation. Document all testing protocols and acceptance criteria.
Include UDI on both device labels and packaging per FDA and MDR requirements. Use GS1 standards for barcode formatting and ensure UDI is human-readable and machine-readable. Register UDI information in appropriate databases (GUDID, EUDAMED) and maintain UDI throughout product lifecycle including packaging changes.
# Packaging And Shelf-Life Verification Protocol
Source: https://docs.withdovetail.com/tasks/packaging-and-shelf-life-verification-protocol
Implement detailed testing procedures validating packaging integrity and device stability claims.
## Summary
The Packaging and Shelf-Life Verification Protocol establishes **systematic procedures** for testing packaging integrity and validating device shelf-life claims through real-time and accelerated aging studies. This protocol ensures your packaging protects device safety and performance throughout the claimed shelf-life period.
## Why is Packaging and Shelf-Life Verification important?
Packaging and shelf-life verification is critical because **packaging failures can compromise device sterility, functionality, or safety** before the device reaches patients. Even minor packaging defects can allow contamination, moisture ingress, or physical damage that renders devices unsafe or ineffective.
Shelf-life validation provides **scientific evidence** to support expiration dating and storage claims made on device labeling. Regulatory agencies require this evidence to ensure devices maintain their safety and performance characteristics throughout their claimed shelf-life under specified storage conditions.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **FDA Guidance Documents**:
* **ASTM F1980** Standard guide for accelerated aging of sterile barrier systems
* **ISO 11607** Packaging for terminally sterilized medical devices
* **FDA Guidance "Shelf Life of Medical Devices"** provides shelf-life validation expectations
* **510(k) submissions** must include shelf-life validation data for predicate comparison
**Special attention required for:**
* Sterile devices requiring sterile barrier system validation
* Combination products with drug or biologic components
* Devices with electronic components sensitive to environmental conditions
* Software devices requiring data integrity over time
Under **EU MDR 2017/745** and supporting standards:
* **EN ISO 11607-1** Requirements for materials, sterile barrier systems and packaging systems
* **EN ISO 11607-2** Validation requirements for forming, sealing and assembly processes
* **Essential Requirements** include packaging and shelf-life demonstration
* **Notified body assessment** of packaging and shelf-life validation completeness
**Special attention required for:**
* CE marking requirements including packaging validation
* Declaration of conformity covering packaging systems
* Post-market surveillance of packaging performance
* Clinical evaluation integration for devices with time-dependent performance
## Guide
### Understanding Packaging System Requirements
**Sterile barrier systems** must maintain sterility throughout the device shelf-life while allowing aseptic presentation at the point of use. The packaging system includes all materials and seals that maintain sterility from sterilization through device use.
**Protective packaging** shields devices from physical damage, environmental conditions, and contamination during storage and distribution. Consider the complete distribution environment including temperature extremes, humidity, vibration, and handling stresses.
**Labeling integration** ensures that packaging supports required labeling elements including expiration dates, storage conditions, sterility indicators, and use instructions while maintaining legibility throughout shelf-life.
### Developing Accelerated Aging Protocols
**Accelerated aging** uses elevated temperature to simulate real-time aging in a compressed timeframe. The most common approach uses the Arrhenius equation with a Q10 factor of 2.0, meaning each 10°C temperature increase doubles the aging rate.
**Aging factor (AAF) calculation** determines the relationship between accelerated and real-time aging. For example, aging at 55°C with a Q10 of 2.0 provides an AAF of 4 compared to 25°C storage, so 1 week at 55°C equals 4 weeks at 25°C.
**Temperature selection** should be high enough to provide meaningful acceleration but not so high as to cause unrealistic failure modes. Typical accelerated aging temperatures range from 50-60°C for most medical device packaging systems.
### Planning Real-Time Aging Studies
**Real-time aging** provides the most accurate assessment of shelf-life performance but requires extended time periods. Plan real-time studies to run parallel with accelerated aging to confirm that accelerated results accurately predict real-time performance.
**Storage conditions** should represent the most challenging conditions within your specified storage range. If you claim storage at 15-30°C, conduct real-time aging at 30°C to represent worst-case conditions.
**Sampling schedules** should provide adequate data points to characterize performance over time. Include testing at the beginning, middle, and end of the claimed shelf-life, with additional time points if performance changes are expected.
### Packaging Integrity Testing
**Seal strength testing** verifies that package seals maintain integrity throughout shelf-life while allowing appropriate opening force for users. Test both peel strength and burst strength to ensure seals don't fail prematurely or become too difficult to open.
**Leak testing** detects microscopic holes or seal defects that could compromise sterility. Methods include dye penetration, bubble emission, vacuum decay, and pressure decay testing depending on package configuration and sensitivity requirements.
**Physical testing** evaluates package resistance to distribution hazards including compression, vibration, drop testing, and environmental cycling. Test complete packages with devices to ensure the entire system maintains integrity.
### Device Performance Testing
**Functional testing** verifies that devices maintain their essential performance characteristics throughout shelf-life. Test all critical functions that could be affected by aging, environmental exposure, or packaging interactions.
**Material degradation assessment** monitors changes in device materials that could affect safety or performance. This includes testing for chemical changes, physical property changes, and biocompatibility changes over time.
**Sterility maintenance** for sterile devices requires testing to confirm that sterility is maintained throughout shelf-life. This typically involves sterility testing of aged packages and bioburden testing of packaging materials.
### Statistical Analysis and Acceptance Criteria
**Sample size determination** should provide adequate statistical power to detect meaningful changes in packaging or device performance. Consider the variability of your test methods and the magnitude of change that would be clinically significant.
**Trend analysis** helps identify gradual changes in performance that might not be apparent from individual time points. Use statistical methods to detect trends and predict when performance might fall below acceptable levels.
**Acceptance criteria** should be based on clinical relevance and regulatory requirements. Consider both absolute limits (e.g., seal strength >2 N) and relative changes (e.g., \<10% decrease from initial values).
## Example
**Scenario**: You are developing sterile surgical forceps packaged in a Tyvek/film pouch with a claimed 5-year shelf-life. The device is sterilized by gamma radiation and stored at room temperature. The forceps have precision tips that must maintain dimensional accuracy and smooth operation.
Your packaging and shelf-life verification protocol includes accelerated aging at 55°C (AAF=4) for 65 weeks to simulate 5 years at 25°C, real-time aging studies at 25°C and 30°C, seal strength testing, sterility maintenance testing, and functional testing of forceps precision and operation throughout the aging period.
### Packaging and Shelf-Life Verification Protocol
**Document ID**: PSLVP-001\
**Version**: 1.0
#### 1. Purpose
This protocol establishes packaging integrity and shelf-life verification procedures for the PrecisionGrip surgical forceps to validate 5-year shelf-life claims and packaging system performance.
#### 2. Device and Packaging Description
**Device**: PrecisionGrip surgical forceps, sterile, single-use\
**Packaging**: Tyvek/film pouch with heat seal\
**Sterilization**: Gamma radiation (25-40 kGy)\
**Claimed Shelf-Life**: 5 years\
**Storage Conditions**: 15-30°C, ≤75% RH
#### 3. Applicable Standards
| Standard | Title | Applicable Sections |
| ----------- | ------------------------------------------------------------------------------------- | ----------------------------- |
| ISO 11607-1 | Packaging for terminally sterilized medical devices - Part 1: Requirements | All applicable clauses |
| ISO 11607-2 | Packaging for terminally sterilized medical devices - Part 2: Validation requirements | All applicable clauses |
| ASTM F1980 | Standard guide for accelerated aging of sterile barrier systems | Accelerated aging methodology |
| ASTM F88 | Standard test method for seal strength of flexible barrier materials | Seal strength testing |
#### 4. Accelerated Aging Study Design
**4.1 Aging Conditions**
| Study Type | Temperature | Relative Humidity | Duration | Aging Factor |
| ---------------------- | ----------- | ----------------- | -------- | ------------ |
| Accelerated | 55°C | Ambient | 65 weeks | AAF = 4 |
| Real-time | 25°C | ≤75% RH | 5 years | AAF = 1 |
| Real-time (worst case) | 30°C | 75% RH | 5 years | AAF = 1.6 |
**4.2 Sampling Schedule**
| Time Point | Accelerated (55°C) | Real-time (25°C) | Real-time (30°C) | Sample Size |
| ------------ | ------------------ | ---------------- | ---------------- | ----------- |
| Initial (T0) | Week 0 | Month 0 | Month 0 | n=30 |
| 6 months | Week 6.5 | Month 6 | Month 6 | n=30 |
| 1 year | Week 13 | Month 12 | Month 12 | n=30 |
| 2 years | Week 26 | Month 24 | Month 24 | n=30 |
| 3 years | Week 39 | Month 36 | Month 36 | n=30 |
| 5 years | Week 65 | Month 60 | Month 60 | n=30 |
#### 5. Packaging Integrity Tests
**5.1 Seal Strength Testing**
| Test | Method | Sample Size | Acceptance Criteria |
| -------------- | --------------- | ------------------- | ------------------------------ |
| Peel Strength | ASTM F88 | n=10 per time point | 2-8 N, no channel failures |
| Burst Strength | Internal method | n=10 per time point | >15 N, consistent failure mode |
**5.2 Package Integrity Testing**
| Test | Method | Sample Size | Acceptance Criteria |
| --------------- | ---------- | ------------------- | ------------------- |
| Dye Penetration | ASTM F1929 | n=10 per time point | No dye penetration |
| Bubble Emission | ASTM F2096 | n=10 per time point | No bubble emission |
**5.3 Physical Testing**
| Test | Method | Sample Size | Acceptance Criteria |
| ------------------- | ---------- | ------------------- | ------------------- |
| Package Compression | ASTM D642 | n=10 per time point | No package damage |
| Drop Test | ASTM D5276 | n=10 per time point | No package damage |
#### 6. Device Performance Tests
**6.1 Functional Testing**
| Parameter | Test Method | Sample Size | Acceptance Criteria |
| ----------------- | ----------------------- | ------------------- | ---------------------------- |
| Tip Alignment | Dimensional measurement | n=10 per time point | Within ±0.1 mm specification |
| Jaw Closure Force | Force measurement | n=10 per time point | 5-15 N closing force |
| Surface Finish | Visual inspection | n=10 per time point | No corrosion or degradation |
**6.2 Material Testing**
| Test | Method | Sample Size | Acceptance Criteria |
| ---------------- | -------- | ------------------ | ---------------------------- |
| Tensile Strength | ASTM E8 | n=5 per time point | >80% of initial value |
| Hardness | ASTM E18 | n=5 per time point | Within ±10% of initial value |
#### 7. Sterility Testing
| Test | Method | Sample Size | Acceptance Criteria |
| -------------- | ----------- | ------------------- | ----------------------- |
| Sterility Test | USP \<71> | n=20 per time point | No growth in test media |
| Bioburden | ISO 11737-1 | n=10 per time point | \<10 CFU per package |
#### 8. Environmental Conditions
**Storage Environment**: Controlled temperature and humidity chambers\
**Monitoring**: Continuous temperature and humidity recording\
**Calibration**: All environmental chambers calibrated annually\
**Documentation**: Environmental conditions recorded for each time point
#### 9. Statistical Analysis
**Primary Analysis**: Descriptive statistics and trend analysis for all measured parameters\
**Acceptance Criteria**: All tests must meet specified criteria at all time points\
**Trend Analysis**: Linear regression to detect significant trends over time\
**Shelf-Life Determination**: Time point where 95% confidence interval lower bound meets acceptance criteria
#### 10. Success Criteria
**Package Integrity**: All integrity tests pass throughout study duration\
**Device Performance**: All functional tests meet specifications throughout study duration\
**Sterility**: Sterility maintained throughout claimed shelf-life\
**Statistical Significance**: No statistically significant degradation trends that would compromise safety or performance
## Q\&A
Select a temperature high enough to provide meaningful acceleration (typically 50-60°C) but not so high as to cause unrealistic failure modes. The temperature should be at least 15°C above your maximum storage temperature. Consider your packaging materials' thermal limits and validate that accelerated aging produces the same failure modes as real-time aging. Document your temperature selection rationale and consider multiple temperatures if needed.
Sterile barrier systems maintain sterility from sterilization through aseptic presentation, while protective packaging shields devices from physical and environmental damage. Sterile barrier systems require validation per ISO 11607 including microbial barrier testing, while protective packaging focuses on physical protection. Many packages serve both functions and must meet requirements for both sterile barriers and protective packaging.
Use the Arrhenius equation with a Q10 factor (typically 2.0 for packaging materials). The aging factor (AAF) = Q10^((T\_accelerated - T\_reference)/10), where temperatures are in Celsius. For example, aging at 55°C vs 25°C reference gives AAF = 2^((55-25)/10) = 2^3 = 8. This means 1 week at 55°C equals 8 weeks at 25°C. Validate your Q10 assumption with real-time data when possible.
Sample sizes depend on test variability and the magnitude of change you need to detect. Typical sample sizes range from 10-30 units per test per time point. Consider the destructive nature of testing, statistical power requirements, and practical constraints. For critical tests like sterility, larger sample sizes may be needed. Use power analysis to determine appropriate sample sizes based on your specific test methods and acceptance criteria.
Investigate failures immediately to determine if they represent real degradation or test artifacts. Consider whether failures are isolated incidents or part of a trend. For packaging failures, examine failure modes to determine if they're realistic for normal storage conditions. Document all failures and their investigation. Significant failures may require design changes, storage condition modifications, or shelf-life reduction.
While accelerated aging provides valuable data quickly, real-time aging studies are generally preferred by regulatory agencies for final shelf-life validation. Use accelerated aging for initial shelf-life estimates and design optimization, but plan real-time studies to confirm accelerated aging predictions. Some agencies may accept accelerated aging data if properly validated, but real-time data provides the strongest regulatory support for shelf-life claims.
# Packaging and Shelf-Life Verification Report
Source: https://docs.withdovetail.com/tasks/packaging-and-shelf-life-verification-report
Document packaging integrity testing validating stability claims and storage requirements.
## Summary
The Packaging and Shelf-Life Verification Report documents the **testing and validation** of your medical device packaging system and shelf-life claims. This report provides evidence that your packaging maintains device sterility, integrity, and functionality throughout the claimed shelf-life under specified storage and transportation conditions.
## Why is Packaging and Shelf-Life Verification Reporting important?
Packaging and shelf-life verification is **essential for medical device safety** as inadequate packaging can lead to contamination, device degradation, or loss of functionality before use. The verification report demonstrates that your packaging system protects the device throughout its intended shelf-life and that expiration dating is scientifically justified.
This documentation is **required for regulatory approval** as it provides evidence that your device will remain safe and effective until its expiration date. Without proper packaging and shelf-life verification, you cannot establish valid expiration dating or demonstrate that your device maintains its essential performance throughout its claimed shelf-life.
## Regulatory Context
Under **21 CFR Part 820.30(g)** (Design Validation) and **FDA Guidance "Shelf Life of Medical Devices"**:
* **Packaging validation** required per ISO 11607 (Packaging for terminally sterilized medical devices)
* **Shelf-life validation** must support expiration dating claims
* **510(k) submissions** must include packaging and shelf-life data
* **Accelerated aging** acceptable per ASTM F1980 with appropriate validation
**Special attention required for:**
* Sterile medical devices requiring sterile barrier systems
* Devices with electronic components sensitive to environmental conditions
* Combination products with drug or biologic components
* Devices with critical performance parameters that may degrade over time
Under **EU MDR 2017/745** and **EN ISO 11607 series standards**:
* **Packaging system validation** required per EN ISO 11607-1 and 11607-2
* **Essential requirements** 10.3 (packaging and labeling)
* **Shelf-life justification** must support expiration dating
* **Notified body assessment** of packaging and shelf-life data required
**Special attention required for:**
* Essential requirements compliance for packaging systems
* Post-market surveillance of packaging performance
* Environmental impact considerations for packaging materials
* Unique Device Identification (UDI) integration with expiration dating
## Guide
### Understanding Packaging System Requirements
**Sterile barrier system** design must maintain sterility throughout the device's shelf-life while allowing aseptic presentation at the point of use. Consider material selection, seal integrity, microbial barrier properties, and compatibility with sterilization processes.
**Protective packaging** must protect the device from physical damage, environmental conditions, and contamination during storage and transportation. Consider shock, vibration, compression, temperature, humidity, and light protection requirements.
**Labeling integration** ensures that all required labeling information remains legible and adherent throughout the shelf-life. Consider label materials, adhesives, printing methods, and environmental resistance.
### Planning Packaging and Shelf-Life Studies
**Study design** should address all critical packaging functions and potential failure modes. Consider package integrity, sterile barrier maintenance, device protection, and labeling durability under relevant environmental conditions.
**Aging conditions** should represent or accelerate the storage and transportation conditions your device will experience. Use real-time aging at recommended storage conditions and consider accelerated aging studies to support initial shelf-life claims.
**Test intervals** should provide sufficient data points to characterize packaging performance over time. Plan testing at time zero, intermediate time points, and at the claimed shelf-life endpoint.
### Conducting Package Integrity Testing
**Seal strength testing** verifies that package seals maintain adequate strength throughout the shelf-life while still allowing easy opening. Test peel strength, burst strength, and creep resistance as appropriate for your package design.
**Microbial barrier testing** demonstrates that the sterile barrier system prevents microbial ingress throughout the shelf-life. Use appropriate test methods such as microbial challenge testing or dye penetration testing.
**Physical integrity testing** verifies that packaging materials maintain their protective properties throughout the shelf-life. Test for material degradation, dimensional changes, and barrier property maintenance.
### Shelf-Life Validation Testing
**Device functionality testing** verifies that the device continues to meet all performance specifications throughout the claimed shelf-life. Test all critical performance parameters and safety functions.
**Sterility maintenance** must be verified for sterile devices throughout the shelf-life. Use sterility testing or bioburden monitoring as appropriate for your device and sterilization method.
**Material compatibility** testing ensures that packaging materials don't adversely affect device performance or safety through leachables, extractables, or other interactions.
### Accelerated Aging Studies
**Aging protocol development** should follow established guidelines such as ASTM F1980 for accelerated aging of sterile medical device packages. Establish appropriate temperature and humidity conditions based on your device's storage requirements.
**Correlation studies** may be needed to demonstrate that accelerated aging results correlate with real-time aging. This is particularly important for novel materials or complex devices.
**Statistical analysis** should provide confidence that accelerated aging results support your shelf-life claims. Use appropriate statistical methods to analyze aging data and establish shelf-life endpoints.
### Environmental Testing
**Transportation testing** simulates the environmental stresses your packaged device may encounter during shipping and handling. Include vibration, shock, compression, and temperature cycling as appropriate.
**Storage condition testing** verifies packaging performance under various storage conditions including temperature, humidity, and light exposure that may occur during distribution and storage.
**Extreme condition testing** evaluates packaging performance under worst-case environmental conditions that may be encountered during transportation or storage.
## Example
**Scenario**: You are developing a sterile surgical instrument with a 5-year shelf-life claim. The device is packaged in a Tyvek/film sterile barrier system with protective outer packaging. The device must maintain sterility and functionality throughout the shelf-life under specified storage conditions.
Your packaging and shelf-life verification includes real-time aging studies, accelerated aging per ASTM F1980, package integrity testing, and device functionality testing. Results support a 5-year shelf-life with appropriate storage conditions and demonstrate packaging system effectiveness.
### Packaging and Shelf-Life Verification Report
**Document ID**: PSLVR-001\
**Version**: 1.0\
**Device**: SurgiPrecision Laparoscopic Grasper Model SP-2024
#### 1. Device and Packaging Description
**Device Overview**: Sterile, single-use laparoscopic grasper with titanium jaws and polymer handle, terminally sterilized by gamma radiation.
**Packaging System**:
* Primary package: Tyvek 1073B/PET film sterile barrier system
* Secondary package: Corrugated cardboard protective box
* Labeling: Pressure-sensitive labels with device information and UDI
**Shelf-Life Claim**: 5 years from date of sterilization when stored at 15-30°C, ≤75% RH, protected from light
#### 2. Study Design and Methodology
**Aging Studies**:
* Real-time aging: 15-30°C, ≤75% RH for 60 months (ongoing)
* Accelerated aging: 55°C, 75% RH per ASTM F1980 (equivalent to 24 months real-time)
**Test Intervals**: 0, 6, 12, 18, 24 months (real-time); 0, 1, 2, 3, 6 months (accelerated)
**Sample Size**: n=30 per test interval for statistical significance
#### 3. Package Integrity Test Results
**3.1 Seal Strength Testing (ASTM F88)**
* Initial peel strength: 2.8 N/15mm (Specification: 1.5-6.0 N/15mm)
* 24-month real-time: 2.6 N/15mm - PASS
* 6-month accelerated (24-month equivalent): 2.5 N/15mm - PASS
**3.2 Microbial Barrier Testing (ASTM F1608)**
* Initial: No microbial ingress detected
* 24-month real-time: No microbial ingress detected - PASS
* 6-month accelerated: No microbial ingress detected - PASS
**3.3 Package Integrity Visual Inspection**
* No package defects, seal failures, or material degradation observed at any test interval
#### 4. Device Functionality Test Results
**4.1 Mechanical Performance**
* Jaw closure force: 45±5 N (Specification: 40-50 N)
* Initial: 45.2 N - PASS
* 24-month real-time: 44.8 N - PASS
* 6-month accelerated: 44.5 N - PASS
**4.2 Material Properties**
* Titanium jaw hardness: HV 320±20 (Specification: 300-340 HV)
* Polymer handle tensile strength: 65±5 MPa (Specification: 60-70 MPa)
* All measurements within specification at all test intervals
#### 5. Sterility Maintenance
**5.1 Sterility Testing (USP \<71>)**
* All samples sterile at all test intervals
* No growth observed in any sterility test medium
**5.2 Bioburden Monitoring**
* Pre-sterilization bioburden: \<10 CFU (Specification: \<100 CFU)
* Consistent low bioburden levels maintained throughout study
#### 6. Environmental Testing Results
**6.1 Transportation Testing (ISTA 2A)**
* Package integrity maintained after simulated transportation
* No device damage or performance degradation observed
**6.2 Temperature Cycling**
* 10 cycles: -10°C to +60°C
* Package and device performance maintained - PASS
#### 7. Accelerated Aging Validation
**7.1 Arrhenius Modeling**
* Activation energy: 83.7 kJ/mol (within acceptable range for polymer materials)
* Q10 value: 2.1 (validates accelerated aging conditions)
**7.2 Correlation Study**
* Accelerated aging results correlate well with real-time data (R² = 0.95)
* Supports use of accelerated aging for shelf-life validation
#### 8. Statistical Analysis
**8.1 Shelf-Life Determination**
* Statistical analysis supports 5-year shelf-life claim with 95% confidence
* All critical parameters remain within specification limits
**8.2 Stability Trending**
* No significant degradation trends observed for any critical parameter
* Packaging system maintains protective function throughout study period
#### 9. Conclusions and Recommendations
**Packaging System Performance**: Tyvek/film sterile barrier system effectively maintains sterility and device integrity throughout 5-year shelf-life.
**Device Stability**: SurgiPrecision Laparoscopic Grasper maintains all critical performance parameters throughout claimed shelf-life.
**Shelf-Life Validation**: 5-year shelf-life claim is supported by both real-time and accelerated aging data.
**Storage Recommendations**: Store at 15-30°C, ≤75% RH, protected from light as specified on labeling.
**Approved by**: \[Packaging Engineer], \[Quality Assurance], \[Regulatory Affairs]
## Q\&A
Sterile medical device packaging requires validation per ISO 11607 standards, including package design qualification, package integrity testing, sterile barrier system validation, and shelf-life validation. Testing should address seal strength, microbial barrier properties, material compatibility, and package integrity under aging and environmental conditions. The specific testing depends on your packaging materials, sterilization method, and device characteristics.
Accelerated aging studies should follow established guidelines like ASTM F1980, using elevated temperature and humidity to accelerate aging processes. Validate the accelerated conditions through Arrhenius modeling or correlation studies with real-time data. Ensure that accelerated conditions don't introduce failure modes that wouldn't occur under normal storage conditions. Document the scientific rationale for your accelerated aging protocol.
Initial shelf-life claims can be supported by accelerated aging studies if properly validated. However, real-time data should be generated to confirm accelerated aging predictions. Conservative initial shelf-life claims (typically 1-2 years) may be acceptable based on accelerated aging alone, with extensions supported by real-time data. The acceptability depends on device risk, regulatory pathway, and quality of accelerated aging validation.
Packaging validation should include testing under relevant transportation and storage conditions including vibration, shock, compression, temperature cycling, and humidity exposure. Use appropriate test standards like ISTA protocols for transportation testing. Consider worst-case conditions that may be encountered during distribution. Document how your packaging protects the device under these conditions throughout the shelf-life.
Document your validation protocol, test methods, acceptance criteria, test results, statistical analysis, and conclusions. Include package design specifications, material certificates, sterilization validation data, and environmental testing results. Provide traceability between packaging requirements, test results, and shelf-life claims. Ensure documentation supports regulatory submissions and quality system requirements.
Packaging validation must be specific to your sterilization method since different methods may affect packaging materials differently. Gamma radiation may cause polymer degradation, EtO may leave residuals, and steam sterilization involves high temperature and moisture. Validate package integrity and material compatibility with your specific sterilization process and parameters. Consider sterilization effects in your aging studies.
# Performance and Bench Verification and Validation Report
Source: https://docs.withdovetail.com/tasks/performance-and-bench-verification-and-validation-report
Document laboratory testing results demonstrating device performance specifications and safety compliance.
## Summary
The Performance and Bench Verification and Validation Report documents **laboratory testing** that demonstrates your medical device meets all performance specifications and safety requirements under controlled conditions. This report provides objective evidence that your device functions correctly and safely according to its intended use through systematic bench testing.
## Why is Performance and Bench Verification and Validation Reporting important?
Performance and bench verification provides **fundamental evidence** that your medical device meets its design specifications and safety requirements before clinical use. This testing establishes baseline performance characteristics, verifies design outputs, and demonstrates that your device functions as intended under controlled laboratory conditions.
This documentation is **essential for regulatory approval** as it provides objective evidence of device performance and safety. Without proper performance verification, you cannot demonstrate that your device meets its intended use requirements or provide evidence that design controls have been effectively implemented.
## Regulatory Context
Under **21 CFR Part 820.30(g)** (Design Validation) and **FDA Guidance "Design Controls"**:
* **Performance testing** must verify that design outputs meet design inputs
* **Bench testing** required to demonstrate safety and effectiveness
* **510(k) submissions** must include performance testing data
* **Predicate device comparison** often requires performance testing
**Special attention required for:**
* Devices with quantitative performance claims requiring analytical validation
* Software medical devices requiring algorithm performance verification
* Combination products requiring integrated performance testing
* Novel devices without established performance standards
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* **Performance verification** required per design control requirements
* **Essential requirements** compliance must be demonstrated through testing
* **Notified body assessment** of performance data required
* **Clinical evaluation** may rely on performance testing data
**Special attention required for:**
* Essential requirements 1, 2, and 3 (safety and performance)
* Post-market surveillance of device performance
* Clinical evaluation integration with performance data
* Harmonized standards compliance demonstration
## Guide
### Understanding Performance Testing Scope
**Functional performance testing** verifies that your device performs its intended functions according to specifications. This includes accuracy, precision, sensitivity, specificity, and other performance characteristics relevant to your device's intended use.
**Safety testing** demonstrates that your device operates safely under normal and fault conditions. This includes testing of safety mechanisms, fail-safe behaviors, and protection against foreseeable misuse.
**Environmental testing** verifies that your device maintains performance and safety under various environmental conditions it may encounter during use, storage, and transportation.
### Planning Performance Testing
**Test protocol development** should address all critical performance parameters and safety requirements identified in your design inputs. Consider normal operation, boundary conditions, and fault conditions in your test planning.
**Test method selection** should use established standards where available, or develop validated test methods for novel performance characteristics. Ensure test methods are appropriate for your device type and intended use.
**Acceptance criteria** should be clearly defined and traceable to design inputs and user needs. Criteria should be objective, measurable, and clinically relevant where appropriate.
### Conducting Functional Performance Testing
**Accuracy testing** verifies that your device provides correct results within specified tolerances. Use appropriate reference standards, calibrated instruments, and statistical methods to evaluate accuracy.
**Precision testing** evaluates the repeatability and reproducibility of device measurements or outputs. Consider both within-device precision and between-device precision as appropriate.
**Range testing** verifies that your device performs correctly across its entire specified operating range. Test at minimum, maximum, and intermediate values within the specified range.
### Safety and Fault Condition Testing
**Normal operation testing** verifies that your device operates safely under all intended use conditions. Test all user-accessible functions and operating modes.
**Single fault condition testing** evaluates device behavior when single components or systems fail. Verify that safety mechanisms function correctly and that the device fails safely.
**Misuse testing** evaluates device behavior under foreseeable misuse conditions. Consider user errors, environmental extremes, and other reasonably foreseeable misuse scenarios.
### Environmental Performance Testing
**Operating environment testing** verifies that your device maintains performance under the environmental conditions specified for normal use. Include temperature, humidity, altitude, and other relevant environmental factors.
**Storage and transportation testing** ensures that environmental conditions during storage and shipping don't affect device performance when subsequently used.
**Electromagnetic compatibility testing** verifies that your device operates correctly in the presence of electromagnetic interference and doesn't interfere with other equipment.
### Algorithm and Software Performance Testing
**Algorithm validation** for software medical devices requires verification that algorithms perform correctly across their intended input ranges. Use appropriate test datasets and statistical validation methods.
**Software performance testing** verifies that software meets timing, throughput, and resource utilization requirements. Include testing under various load conditions and system configurations.
**User interface testing** validates that software interfaces are intuitive, error-resistant, and provide appropriate feedback to users.
### Statistical Analysis and Reporting
**Statistical methods** should be appropriate for your device type and performance characteristics. Consider sample sizes, confidence intervals, and statistical power in your analysis.
**Data analysis** should evaluate both individual test results and overall performance trends. Identify any outliers or unexpected results and investigate root causes.
**Performance characterization** should provide a complete picture of device performance, including central tendencies, variability, and performance limits.
## Example
**Scenario**: You are developing a blood glucose meter that measures glucose concentrations from capillary blood samples. The device must meet accuracy requirements per ISO 15197, demonstrate precision across the measurement range, and operate correctly under various environmental conditions.
Your performance testing includes accuracy testing against reference methods, precision studies, interference testing, environmental testing, and user interface validation. Results demonstrate compliance with ISO 15197 accuracy requirements and robust performance under intended use conditions.
### Performance and Bench Verification and Validation Report
**Document ID**: PBVVR-001\
**Version**: 1.0\
**Device**: GlucoCheck Pro Blood Glucose Meter Model GCP-2024
#### 1. Device Description and Performance Requirements
**Device Overview**: Portable blood glucose meter for self-monitoring of blood glucose using capillary blood samples with electrochemical test strips.
**Performance Requirements**:
* Measurement range: 20-600 mg/dL (1.1-33.3 mmol/L)
* Accuracy: ±15 mg/dL or ±15% per ISO 15197:2013
* Precision: CV ≤5% for glucose concentrations ≥100 mg/dL
* Sample volume: 0.5 μL
* Test time: ≤5 seconds
**Applicable Standards**:
* ISO 15197:2013 (In vitro diagnostic test systems - Requirements for blood-glucose monitoring systems)
* IEC 62304:2006+A1:2015 (Medical device software lifecycle processes)
#### 2. Test Methods and Protocols
**Accuracy Testing**: Comparison with YSI 2300 STAT Plus reference analyzer using venous blood samples from 100 subjects across glucose range.
**Precision Testing**: Replicate measurements (n=20) at low, medium, and high glucose concentrations using control solutions.
**Interference Testing**: Evaluation of common interfering substances per ISO 15197 requirements.
**Environmental Testing**: Performance verification at temperature and humidity extremes per IEC 60601-1-11.
#### 3. Accuracy Test Results
**3.1 ISO 15197 Accuracy Requirements**
* Total samples tested: 200 (100 subjects × 2 measurements)
* Glucose range: 23-587 mg/dL
* Results within ±15 mg/dL or ±15%: 198/200 (99.0%)
* Requirement: ≥95% - PASS
**3.2 Consensus Error Grid Analysis**
* Zone A (clinically accurate): 195/200 (97.5%)
* Zone B (clinically acceptable): 5/200 (2.5%)
* Zones C, D, E (clinically significant errors): 0/200 (0%)
* Requirement: ≥99% in Zones A+B - PASS
#### 4. Precision Test Results
**4.1 Repeatability (Within-Device Precision)**
* Low glucose (65 mg/dL): CV = 3.2% (Requirement: ≤5%) - PASS
* Medium glucose (150 mg/dL): CV = 2.8% (Requirement: ≤5%) - PASS
* High glucose (350 mg/dL): CV = 3.5% (Requirement: ≤5%) - PASS
**4.2 Intermediate Precision (Between-Day)**
* Testing over 20 days with same control solutions
* Overall CV = 4.1% (Requirement: ≤7%) - PASS
#### 5. Interference Testing Results
**5.1 Endogenous Substances**
* Hematocrit (20-70%): No significant interference
* Triglycerides (up to 3000 mg/dL): No significant interference
* Cholesterol (up to 500 mg/dL): No significant interference
* Bilirubin (up to 20 mg/dL): No significant interference
**5.2 Exogenous Substances**
* Acetaminophen (up to 20 mg/dL): No significant interference
* Ascorbic acid (up to 15 mg/dL): No significant interference
* Dopamine (up to 40 μg/dL): No significant interference
#### 6. Environmental Testing Results
**6.1 Temperature Testing**
* Operating range: 5-45°C
* Accuracy maintained across temperature range - PASS
* Automatic temperature compensation verified
**6.2 Humidity Testing**
* Operating range: 10-90% RH (non-condensing)
* Performance maintained at humidity extremes - PASS
**6.3 Altitude Testing**
* Operating range: -500 to 3000 meters
* No significant performance impact observed - PASS
#### 7. Software Performance Testing
**7.1 Algorithm Validation**
* Glucose calculation algorithm verified across measurement range
* Error detection algorithms function correctly
* Quality control algorithms properly implemented
**7.2 User Interface Testing**
* Display readability under various lighting conditions - PASS
* Button responsiveness and tactile feedback - PASS
* Audio alerts audible in typical use environments - PASS
#### 8. Safety and Fault Condition Testing
**8.1 Error Detection**
* Insufficient sample volume detection: 100% success rate
* Strip insertion error detection: 100% success rate
* Temperature out-of-range detection: 100% success rate
**8.2 Fail-Safe Behavior**
* Device shuts down safely when battery low
* Error messages clearly displayed for all fault conditions
* No false glucose readings displayed during error conditions
#### 9. Statistical Analysis
**9.1 Method Comparison Statistics**
* Correlation coefficient (r): 0.998
* Slope: 1.02 (95% CI: 0.99-1.05)
* Intercept: -1.8 mg/dL (95% CI: -4.2 to 0.6)
* Bias: -0.5 mg/dL (clinically insignificant)
**9.2 Performance Capability**
* Process capability index (Cpk): 1.67 (Requirement: ≥1.33) - PASS
* Demonstrates robust performance with margin for manufacturing variation
#### 10. Conclusions and Recommendations
**Performance Verification**: GlucoCheck Pro Blood Glucose Meter meets all performance requirements and demonstrates excellent accuracy and precision across the measurement range.
**Safety Verification**: All safety mechanisms function correctly, and the device fails safely under fault conditions.
**Regulatory Compliance**: Device performance meets ISO 15197:2013 requirements for blood glucose monitoring systems.
**Clinical Readiness**: Device is ready for clinical validation studies and regulatory submission.
**Approved by**: \[Test Engineer], \[Quality Assurance], \[Regulatory Affairs]
## Q\&A
Performance testing requirements depend on your device type and intended use. Common testing includes accuracy and precision verification, safety testing under normal and fault conditions, environmental testing, and interference testing. Software devices require algorithm validation and user interface testing. Refer to applicable device-specific standards (like ISO 15197 for glucose meters) for specific requirements.
Accuracy should be evaluated by comparison with appropriate reference methods or standards using clinical samples across the device's measurement range. Precision should be evaluated through replicate measurements to assess repeatability and reproducibility. Use appropriate statistical methods and sample sizes to ensure reliable results. Follow device-specific standards where available for specific requirements and acceptance criteria.
Statistical analysis should include appropriate descriptive statistics, correlation analysis for method comparisons, bias assessment, and confidence intervals. Consider sample size requirements for adequate statistical power. Use appropriate statistical tests for your data type and distribution. Document statistical methods and justify their appropriateness for your device and performance characteristics.
Environmental testing should cover the full range of conditions your device may encounter during use, storage, and transportation. Include temperature, humidity, altitude, vibration, and electromagnetic compatibility testing as appropriate. Test at extremes and intermediate conditions within specified ranges. Verify that performance remains within specifications under all environmental conditions.
Safety testing should verify that safety mechanisms function correctly under normal and fault conditions. Test error detection systems, fail-safe behaviors, and protection against foreseeable misuse. Include single fault condition testing to verify that the device fails safely when components malfunction. Document that all safety requirements are met through testing.
Software algorithm validation requires testing with appropriate datasets that cover the algorithm's intended input range and edge cases. Use statistical validation methods appropriate for your algorithm type (classification, regression, etc.). Consider sensitivity, specificity, positive/negative predictive values for diagnostic algorithms. Validate with independent datasets and document algorithm limitations and assumptions.
# Performance and Bench Verification Guide
Source: https://docs.withdovetail.com/tasks/performance-and-bench-verification-guide
Plan systematic laboratory testing framework verifying device specifications and validating user needs.
## Summary
The Performance and Bench Verification Guide provides a **systematic framework** for planning and executing non-clinical testing that verifies your medical device meets design specifications (verification) and validates it fulfills user needs (validation). This guide focuses on mechanical and functional performance testing that can be conducted in laboratory settings.
## Why is Performance and Bench Verification important?
Performance and bench verification is essential because it provides **objective evidence** that your device functions as intended before human testing or market release. This testing identifies design flaws, validates engineering assumptions, and demonstrates compliance with performance requirements in controlled laboratory conditions.
Bench testing is often **more cost-effective and faster** than clinical testing while providing precise, repeatable measurements of device performance. It allows you to optimize device design, validate manufacturing processes, and build confidence in device performance before proceeding to more expensive validation activities like clinical studies or usability testing.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls):
* **Section 820.30(f)** requires verification that design outputs meet design inputs
* **Section 820.30(g)** mandates validation that devices meet user needs and intended use
* **Performance testing** must demonstrate essential performance characteristics
* **Test methods** should follow recognized consensus standards when available
**Special attention required for:**
* Predicate device performance comparison for 510(k) submissions
* Software performance testing including cybersecurity and data integrity
* Combination product testing addressing both device and drug/biologic components
* Novel device testing where established standards may not exist
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* **Annex II** requires comprehensive verification and validation documentation
* Must demonstrate **essential requirements** compliance through testing
* **Performance testing** must align with harmonized standards where applicable
* **Clinical evaluation** must be supported by appropriate performance data
**Special attention required for:**
* Essential requirements demonstration per Annex I of MDR
* Notified body assessment of performance testing adequacy
* Post-market performance monitoring integration
* Performance testing for software as medical device (SaMD) classification
## Guide
### Understanding Verification vs. Validation Testing
**Verification testing** confirms that your design outputs meet design inputs by testing against specific technical requirements. This includes testing individual subsystems and components to ensure they perform according to specifications.
**Validation testing** confirms that your complete device meets user needs and intended use requirements. This involves testing the integrated system under realistic use conditions to demonstrate it solves the clinical problem it was designed to address.
### Planning Your Performance Testing Strategy
Your performance testing strategy should address **all critical device functions** identified in your user needs and system requirements. Prioritize testing based on risk analysis, focusing on functions that could impact patient safety or device effectiveness if they fail.
**Test method selection** should follow established standards when available, as this provides regulatory credibility and enables comparison with other devices. When standards don't exist, develop test methods based on scientific principles and justify your approach.
**Test environment design** should represent realistic use conditions while maintaining sufficient control for repeatable measurements. Consider factors like temperature, humidity, vibration, electromagnetic interference, and user variability that could affect device performance.
### Developing Verification Test Plans
**Subsystem requirement testing** verifies that individual device components meet their specified performance criteria. Each subsystem requirement should be traceable to specific test cases that objectively measure compliance.
**Test case development** should specify test procedures, sample sizes, acceptance criteria, and statistical analysis methods. Include both normal operating conditions and edge cases that represent the limits of acceptable performance.
**Measurement system validation** ensures your test methods are capable of detecting meaningful differences in device performance. Consider measurement accuracy, precision, and repeatability when designing test protocols.
### Developing Validation Test Plans
**User need validation** demonstrates that your device successfully addresses the clinical problems identified in your user needs analysis. These tests should simulate realistic use scenarios and measure outcomes that matter to users.
**Integrated system testing** evaluates how well different device components work together to deliver the intended clinical benefit. This testing often reveals interface issues or system-level performance limitations not apparent in component testing.
**Use case scenario testing** validates device performance across the range of intended use conditions, user types, and clinical scenarios. Include testing with different patient populations, use environments, and operator skill levels as appropriate.
### Statistical Considerations and Sample Sizing
**Sample size determination** should provide adequate statistical power to detect meaningful differences while considering practical constraints like cost and timeline. Use your Statistical Methods SOP to guide sample size calculations based on expected effect sizes and measurement variability.
**Statistical analysis planning** should be defined before testing begins to avoid bias in data interpretation. Specify primary endpoints, statistical tests, and criteria for statistical significance.
**Acceptance criteria definition** should be based on clinical relevance, not just statistical significance. Consider what level of performance difference would be meaningful to users and patients when setting acceptance thresholds.
### Managing Test Execution and Documentation
**Test protocol adherence** is critical for generating reliable, defensible data. Train test operators on proper procedures and implement quality controls to ensure consistent test execution.
**Data integrity** requires careful documentation of test conditions, raw data, calculations, and any deviations from planned procedures. Use electronic data capture systems when possible to reduce transcription errors.
**Change control** ensures that protocol modifications are properly documented and justified. Significant protocol changes may require retesting to maintain data integrity.
## Example
**Scenario**: You are developing a wearable heart rate monitor that provides continuous monitoring and alerts for abnormal rhythms. The device includes optical sensors, signal processing algorithms, and wireless connectivity for data transmission to a smartphone app.
Your performance verification plan tests sensor accuracy against reference ECG devices across different heart rate ranges, validates algorithm performance for detecting arrhythmias using known test signals, and verifies wireless transmission reliability under various interference conditions. Validation testing demonstrates that the complete system can accurately detect clinically significant arrhythmias in realistic use scenarios and provides appropriate user notifications.
### Performance and Bench Verification Guide
**Document ID**: PBVG-001\
**Version**: 1.0
#### 1. Purpose
This guide provides a structured approach to plan, execute, and document non-clinical performance testing of the CardioWatch wearable heart rate monitor to verify design requirements and validate user needs.
#### 2. Scope
This guide covers mechanical and functional performance testing of the CardioWatch system, excluding packaging, shelf-life, electrical safety, and biocompatibility testing which are addressed in separate protocols.
#### 3. Verification Testing
| Subsystem ID | Subsystem Requirement | Test ID | Testing Required | Acceptance Criteria |
| ------------ | --------------------------------------------- | ------- | ----------------------------------------------------- | -------------------------------------------------------------- |
| SS-001 | Heart rate accuracy ±3 bpm (60-180 bpm range) | VT-001 | Optical sensor accuracy testing against reference ECG | Measured HR within ±3 bpm of reference for 95% of measurements |
| SS-002 | Arrhythmia detection sensitivity ≥95% | VT-002 | Algorithm testing with known arrhythmia signals | Detect ≥95% of atrial fibrillation episodes in test dataset |
| SS-003 | Battery life ≥7 days continuous monitoring | VT-003 | Power consumption measurement under continuous use | Average power consumption ≤5mW during monitoring mode |
| SS-004 | Wireless range ≥10 meters line-of-sight | VT-004 | Bluetooth transmission range testing | Maintain connection at 10m distance with \<1% packet loss |
| SS-005 | Water resistance IPX7 rating | VT-005 | Immersion testing per IEC 60529 | No water ingress after 30 minutes at 1m depth |
#### 4. Validation Testing
| UN ID | User Need | Test ID | Testing Required | Acceptance Criteria |
| ------ | ------------------------------------------------------- | ------- | ------------------------------------------ | ------------------------------------------------------------------------- |
| UN-001 | Accurately monitor heart rate during daily activities | VL-001 | Real-world activity simulation testing | HR accuracy maintained during walking, running, and stationary activities |
| UN-002 | Detect irregular heart rhythms and alert user | VL-002 | Integrated arrhythmia detection validation | System detects AF episodes and delivers alerts within 30 seconds |
| UN-003 | Provide continuous monitoring without frequent charging | VL-003 | Extended wear testing simulation | Device operates ≥7 days with typical usage patterns |
| UN-004 | Sync data reliably with smartphone app | VL-004 | End-to-end data transmission validation | ≥99% successful data synchronization under normal use conditions |
#### 5. Test Methods and Procedures
**5.1 Heart Rate Accuracy Testing (VT-001)**
* **Reference Standard**: 12-lead ECG with validated heart rate calculation
* **Test Conditions**: Controlled laboratory environment, multiple subjects
* **Procedure**: Simultaneous measurement with CardioWatch and reference ECG
* **Sample Size**: 30 subjects, 5 measurements per subject across HR range
* **Analysis**: Bland-Altman analysis of agreement between methods
**5.2 Arrhythmia Detection Testing (VT-002)**
* **Test Signals**: MIT-BIH Arrhythmia Database with known AF episodes
* **Procedure**: Process test signals through CardioWatch algorithm
* **Metrics**: Sensitivity, specificity, positive predictive value
* **Sample Size**: 100 AF episodes, 100 normal rhythm segments
**5.3 Battery Life Testing (VT-003)**
* **Test Setup**: Continuous monitoring mode with periodic data transmission
* **Measurement**: Current consumption using precision power analyzer
* **Duration**: 168 hours (7 days) continuous operation
* **Conditions**: 25°C ambient temperature, typical usage profile
#### 6. Statistical Analysis Plan
**Primary Analysis**: Descriptive statistics for all measured parameters with 95% confidence intervals. Comparison of measured values to acceptance criteria using appropriate statistical tests.
**Sample Size Justification**: Sample sizes calculated to detect clinically meaningful differences with 80% power and α=0.05. Minimum 30 subjects for accuracy testing based on FDA guidance for heart rate monitors.
**Acceptance Criteria**: All primary endpoints must meet specified criteria. Secondary endpoints provide supporting evidence but don't determine pass/fail status.
#### 7. Test Report Requirements
**Data Documentation**: Raw data, calculated results, statistical analysis, and graphical summaries for all test activities.
**Deviation Reporting**: Any deviations from planned procedures must be documented with justification and impact assessment.
**Conclusion**: Clear statement of whether device meets all verification and validation criteria with supporting evidence.
## Q\&A
Start with your user needs and system requirements to identify critical performance characteristics. Focus on functions that could impact patient safety or device effectiveness if they fail. Use your risk analysis to prioritize testing based on potential harm. Consider regulatory guidance and standards for your device type, as these often specify required performance testing. Include both functional performance (what the device does) and non-functional performance (how well it does it).
Verification testing confirms that design outputs meet design inputs - essentially testing that you built the device according to specifications. Validation testing confirms that the device meets user needs and intended use - testing that you built the right device. In practice, some tests serve both purposes. For example, testing heart rate accuracy verifies the sensor meets its specification and validates that users get accurate heart rate information.
When established standards don't exist, develop test methods based on scientific principles and clinical relevance. Consider how the device will be used in practice and design tests that simulate those conditions. Consult published literature for similar devices or applications. Document your rationale for test method selection and consider having methods reviewed by clinical experts. Be prepared to justify your approach to regulatory reviewers.
Sample sizes depend on the variability of your measurements, the magnitude of difference you need to detect, and your desired statistical confidence. Use power analysis to calculate appropriate sample sizes based on these factors. Consider practical constraints like cost and timeline, but ensure adequate statistical power. For safety-critical functions, err on the side of larger sample sizes. Document your sample size rationale and consider regulatory guidance for your device type.
When tests fail, first verify that the failure is real and not due to test setup issues or measurement errors. Investigate the root cause - is it a design problem, manufacturing issue, or test method problem? Document the failure and your investigation thoroughly. If it's a design issue, determine if design changes are needed or if acceptance criteria should be reconsidered. All failures and their resolution should be documented in your test report.
Yes, well-designed tests can provide evidence for both verification and validation. For example, accuracy testing against specifications (verification) using realistic use scenarios (validation) serves both purposes. However, ensure your test design adequately addresses both the technical requirements and user needs. Some verification testing may be too narrow for validation purposes, and some validation testing may not provide sufficient detail for verification. Plan your testing strategy to efficiently address both needs.
# Performance And Bench Verification Protocol
Source: https://docs.withdovetail.com/tasks/performance-and-bench-verification-protocol
Execute detailed testing procedures ensuring reproducible performance verification and validation results.
## Summary
The Performance and Bench Verification Protocol establishes **detailed testing procedures** for executing non-clinical performance testing that verifies your medical device meets design specifications and validates it fulfills user needs. This protocol provides step-by-step procedures for conducting systematic laboratory testing with objective acceptance criteria.
## Why is Performance and Bench Verification Protocol important?
Performance and bench verification protocols are essential because they provide **standardized, reproducible procedures** that ensure consistent testing across different operators, laboratories, and time periods. Without detailed protocols, testing results may vary due to procedural differences, leading to unreliable data and potential regulatory challenges.
These protocols also ensure **comprehensive test coverage** by specifying exactly what to test, how to test it, and what constitutes acceptable performance. This systematic approach prevents oversight of critical performance characteristics and provides clear documentation for regulatory submissions.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **FDA Guidance Documents**:
* **Section 820.30(f)** requires verification protocols that demonstrate design outputs meet design inputs
* **Section 820.30(g)** mandates validation protocols that confirm devices meet user needs
* **FDA Guidance "Design Control Guidance"** emphasizes protocol-driven testing approaches
* **Good Laboratory Practices** apply to testing that supports regulatory submissions
**Special attention required for:**
* Protocol deviations must be documented and justified
* Test methods should follow recognized consensus standards when available
* Statistical analysis plans must be defined before testing begins
* Data integrity requirements for electronic records and signatures
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* **Annex II** requires detailed verification and validation protocols
* **ISO 13485 Section 7.3.6** specifies protocol requirements for design verification and validation
* **Essential requirements** must be demonstrated through systematic protocol execution
* **Notified body assessment** includes protocol review and adequacy evaluation
**Special attention required for:**
* Protocol approval and change control procedures
* Competency requirements for personnel executing protocols
* Equipment qualification and calibration requirements
* Post-market surveillance integration with protocol results
## Guide
### Protocol Development Principles
**Objective-driven design** ensures that each protocol addresses specific verification or validation objectives derived from your design requirements and user needs. Clearly state what you are trying to prove and how the testing will demonstrate compliance.
**Standardized methodology** should follow established test methods and standards whenever possible to ensure regulatory acceptance and enable comparison with other devices. When standards don't exist, develop methods based on scientific principles and document your rationale.
**Reproducible procedures** must be detailed enough that different operators can execute the protocol and obtain consistent results. Include specific equipment requirements, environmental conditions, sample preparation procedures, and measurement techniques.
### Defining Test Objectives and Scope
**Verification objectives** should directly link to design inputs and system requirements. Each requirement that can be objectively tested should have corresponding verification testing with clear pass/fail criteria.
**Validation objectives** should address user needs and intended use scenarios. Focus on testing that demonstrates the device solves the clinical problem it was designed to address under realistic use conditions.
**Scope definition** should clearly specify what is included and excluded from the protocol. Consider device configurations, use scenarios, user populations, and environmental conditions that are within scope.
### Test Method Selection and Justification
**Standard method selection** should prioritize recognized consensus standards that are appropriate for your device type and testing objectives. Document which standards apply and justify any deviations from standard methods.
**Custom method development** may be necessary when standards don't exist or don't adequately address your specific testing needs. Base custom methods on scientific principles and validate their appropriateness through method verification studies.
**Method validation** should demonstrate that your test methods are suitable for their intended purpose. Consider accuracy, precision, specificity, linearity, range, and robustness when validating test methods.
### Sample Preparation and Handling
**Sample selection** should represent your commercial device configuration including all manufacturing processes, sterilization, and packaging that could affect performance. Document how test samples relate to commercial products.
**Sample size determination** should provide adequate statistical power while considering practical constraints. Use statistical methods to calculate appropriate sample sizes based on expected variability and effect sizes.
**Sample handling procedures** must ensure sample integrity throughout testing. Include storage conditions, handling precautions, and chain of custody requirements to prevent sample degradation or contamination.
### Environmental and Equipment Requirements
**Environmental control** should specify temperature, humidity, pressure, and other environmental conditions required for testing. Consider both the conditions needed for accurate measurements and the conditions that represent realistic use environments.
**Equipment specifications** should detail all equipment needed for testing including accuracy requirements, calibration status, and qualification criteria. Ensure equipment is suitable for the measurements being made.
**Calibration requirements** should specify calibration intervals, standards used, and acceptance criteria for all measurement equipment. Maintain calibration records and ensure traceability to national standards.
### Data Collection and Analysis
**Data collection procedures** should specify what data to collect, how to record it, and what calculations to perform. Use standardized data collection forms and electronic systems when possible to reduce transcription errors.
**Statistical analysis plans** must be defined before testing begins to avoid bias in data interpretation. Specify primary endpoints, statistical tests, significance levels, and criteria for outlier handling.
**Acceptance criteria** should be objective, measurable, and based on clinical relevance or regulatory requirements. Avoid subjective criteria that could lead to interpretation disputes.
### Quality Control and Documentation
**Quality control measures** should ensure data integrity and protocol compliance throughout testing. Include procedures for monitoring test execution, reviewing data, and handling deviations.
**Documentation requirements** should specify what records to maintain and how to organize them for regulatory submissions. Include raw data, calculations, observations, and any deviations from planned procedures.
**Change control** should address how to handle protocol modifications during testing. Significant changes may require retesting, while minor clarifications can be documented as amendments.
## Example
**Scenario**: You are developing a blood pressure monitor for home use that must meet accuracy requirements of ±3 mmHg or ±2% of reading. The device uses an oscillometric measurement method and displays results on an LCD screen. You need to verify measurement accuracy across the full measurement range and validate usability for intended users.
Your performance and bench verification protocol includes accuracy testing against reference sphygmomanometers using standardized test procedures, environmental testing across specified operating conditions, and usability testing with representative users to validate that the device can be used safely and effectively in home environments.
### Performance and Bench Verification Protocol
**Document ID**: PBVP-001\
**Version**: 1.0
#### 1. Purpose and Objectives
**Primary Objective**: Verify that the HomeBP blood pressure monitor meets accuracy specifications of ±3 mmHg or ±2% of reading across the measurement range of 60-280 mmHg systolic and 40-150 mmHg diastolic.
**Secondary Objectives**:
* Validate measurement repeatability and reproducibility
* Verify performance across specified environmental conditions
* Validate usability for intended home users
#### 2. Scope and Limitations
**In Scope**: HomeBP Model 2024 blood pressure monitor with standard adult cuff (22-32 cm arm circumference)\
**Out of Scope**: Pediatric applications, large adult cuffs, clinical validation studies\
**Test Environment**: Laboratory testing under controlled conditions\
**User Population**: Healthy adult volunteers representing intended user demographics
#### 3. Applicable Standards
| Standard | Title | Applicable Sections |
| --------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------- |
| ISO 81060-2 | Non-invasive sphygmomanometers - Part 2: Clinical investigation of automated measurement type | Accuracy testing methodology |
| ANSI/AAMI/ISO 81060-2 | Non-invasive sphygmomanometers - Part 2: Clinical investigation | US-specific requirements |
| IEC 60601-1 | Medical electrical equipment - General requirements for basic safety and essential performance | Electrical safety requirements |
| IEC 62304 | Medical device software - Software life cycle processes | Software verification requirements |
#### 4. Test Equipment and Calibration
**4.1 Primary Equipment**
| Equipment | Model/Type | Accuracy Requirement | Calibration Interval |
| -------------------------- | ------------------------------- | -------------------- | -------------------- |
| Reference Sphygmomanometer | Mercury or aneroid, calibrated | ±1 mmHg | 6 months |
| Pressure Simulator | Fluke Biomedical BP Pump 2 | ±0.1 mmHg | 12 months |
| Environmental Chamber | Temperature/humidity controlled | ±1°C, ±3% RH | 12 months |
| Stopwatch | Digital, calibrated | ±0.1 seconds | 12 months |
**4.2 Calibration Requirements**
* All equipment calibrated before testing begins
* Calibration certificates traceable to national standards
* Daily verification checks for critical equipment
* Calibration status documented for each test session
#### 5. Test Procedures
**5.1 Accuracy Verification Testing**
**Objective**: Verify measurement accuracy meets ±3 mmHg or ±2% specification
**Test Setup**:
1. Connect HomeBP device to pressure simulator via T-connector
2. Connect reference sphygmomanometer to same pressure source
3. Ensure all connections are leak-free
4. Allow devices to stabilize for 30 minutes
**Test Procedure**:
1. Set pressure simulator to target pressure
2. Record reference pressure reading
3. Initiate measurement cycle on HomeBP device
4. Record HomeBP reading when measurement completes
5. Repeat for all test pressures in random order
6. Perform 3 measurements at each pressure level
**Test Pressures**: 60, 80, 100, 120, 140, 160, 180, 200, 220, 240, 260, 280 mmHg
**Sample Size**: n=30 measurements per pressure level (10 devices × 3 measurements)
**Acceptance Criteria**:
* Mean difference ≤±3 mmHg for pressures ≤100 mmHg
* Mean difference ≤±2% for pressures >100 mmHg
* Standard deviation ≤8 mmHg for all pressure levels
**5.2 Environmental Testing**
**Objective**: Verify performance across specified operating conditions
**Test Conditions**:
* Temperature: 10°C, 23°C, 40°C
* Relative Humidity: 30%, 60%, 85%
* Atmospheric Pressure: 86 kPa, 101 kPa, 106 kPa
**Test Procedure**:
1. Condition devices in environmental chamber for 2 hours
2. Perform accuracy testing at 3 pressure levels (80, 120, 160 mmHg)
3. Record environmental conditions during testing
4. Test 5 devices per environmental condition
**Acceptance Criteria**: Accuracy specifications maintained across all environmental conditions
**5.3 Repeatability Testing**
**Objective**: Verify measurement consistency within device
**Test Procedure**:
1. Set pressure simulator to 120 mmHg
2. Perform 10 consecutive measurements without changing setup
3. Calculate mean, standard deviation, and coefficient of variation
4. Repeat for 10 devices
**Acceptance Criteria**:
* Standard deviation ≤5 mmHg
* Coefficient of variation ≤4%
**5.4 Reproducibility Testing**
**Objective**: Verify measurement consistency between devices
**Test Procedure**:
1. Test 10 devices at same pressure level (120 mmHg)
2. Use same test setup and operator
3. Perform 3 measurements per device
4. Calculate between-device variability
**Acceptance Criteria**: Between-device standard deviation ≤8 mmHg
#### 6. Data Collection and Analysis
**6.1 Data Recording**
* Use standardized data collection forms
* Record all measurements, environmental conditions, and observations
* Document any deviations from protocol procedures
* Maintain chain of custody for test devices
**6.2 Statistical Analysis**
* Calculate descriptive statistics for all measurements
* Perform Bland-Altman analysis for agreement assessment
* Use ANOVA to assess environmental effects
* Apply Bonferroni correction for multiple comparisons
**6.3 Acceptance Criteria Summary**
* Primary: Accuracy within ±3 mmHg or ±2% specification
* Secondary: Repeatability SD ≤5 mmHg, Reproducibility SD ≤8 mmHg
* Environmental: Performance maintained across all test conditions
#### 7. Quality Control
**7.1 Protocol Compliance**
* Daily review of test procedures and data collection
* Independent verification of critical measurements
* Documentation of all protocol deviations
**7.2 Data Integrity**
* Electronic data backup and version control
* Audit trail for all data modifications
* Independent data review before analysis
#### 8. Reporting Requirements
**Test Report Contents**:
* Executive summary with pass/fail determination
* Detailed results for all test procedures
* Statistical analysis and graphical presentations
* Discussion of any deviations or anomalies
* Conclusions and recommendations
**Timeline**: Draft report within 2 weeks of testing completion, final report within 4 weeks
## Q\&A
Test procedures should be detailed enough that different operators can execute them consistently and obtain reproducible results. Include specific equipment settings, environmental conditions, sample preparation steps, measurement techniques, and data recording requirements. The level of detail should be sufficient for regulatory review and for training new operators. Consider including photographs or diagrams for complex setups.
First, verify that the failure is real and not due to test setup issues or operator error. Investigate the root cause - is it a design problem, manufacturing issue, or test method problem? Document the failure and your investigation thoroughly. Depending on the cause, you may need design changes, manufacturing process improvements, or protocol modifications. Significant failures may require retesting after corrective actions are implemented.
Document all deviations immediately when they occur, including the reason for the deviation and any impact on test results. Minor deviations (like small environmental variations) may be acceptable if they don't affect the validity of results. Major deviations may require retesting or protocol amendments. Have a predefined process for evaluating and approving deviations, and ensure all deviations are reviewed before finalizing test results.
Define your statistical analysis plan before testing begins to avoid bias. Include descriptive statistics (mean, standard deviation, confidence intervals), appropriate statistical tests for your hypotheses, and criteria for statistical significance. Consider power analysis for sample size determination and methods for handling outliers. For accuracy testing, Bland-Altman analysis is often useful for assessing agreement between test and reference methods.
When developing custom test methods, validate them through method verification studies that assess accuracy, precision, specificity, linearity, range, and robustness. Compare your method to established methods when possible, or use reference materials with known values. Document your method development rationale and validation results. Consider having methods reviewed by external experts or testing laboratories.
All measurement equipment should be qualified for its intended use through installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ). Maintain calibration to traceable standards with appropriate intervals based on equipment stability and criticality. Document equipment specifications, calibration procedures, and acceptance criteria. Ensure equipment accuracy is adequate for the measurements being made - typically 10 times better than the specification being tested.
# Periodic Safety Update Report
Source: https://docs.withdovetail.com/tasks/periodic-safety-update-report
Provide comprehensive benefit-risk analysis supporting continued device market authorization.
## Summary
The Periodic Safety Update Report (PSUR) provides a **comprehensive benefit-risk analysis** integrating clinical data, real-world evidence, and safety signals collected over a defined surveillance period. This report is specifically required for implantable devices and certain high-risk medical devices. Unlike standard post-market surveillance reports, PSURs require **comprehensive benefit-risk analysis** that integrates clinical data, real-world evidence, and safety signals to support continued market authorization.
## Why is Periodic Safety Update Report important?
Regulatory authorities mandate PSURs to ensure **ongoing benefit-risk evaluation** of medical devices based on real-world evidence. The PSUR demonstrates that your device's benefits continue to outweigh risks as clinical experience accumulates. Notified bodies use PSURs to **assess continued compliance** with essential requirements and determine whether **certificate renewals** are appropriate. Failure to provide adequate PSURs can result in **certificate suspension**, **market withdrawal**, or **additional surveillance requirements** imposed by authorities.
## Regulatory Context
While FDA doesn't specifically require PSURs, equivalent reporting may be required for:
* **Post-market surveillance studies** under 21 CFR 822 requiring benefit-risk analysis
* **Premarket Approval (PMA)** devices requiring periodic reports under 21 CFR 814.84
* **Risk Evaluation and Mitigation Strategies (REMS)** assessments
* **De Novo pathway devices** with special controls requiring surveillance
**Special attention required for:**
* **Class III devices** requiring comprehensive safety data analysis
* **Breakthrough devices** with accelerated approval pathways
* **Software as Medical Device** requiring algorithm performance monitoring
* **Combination products** requiring coordinated safety assessment
Under **EU MDR 2017/745**:
* **PSURs required** for implantable devices and Class III devices (Article 86)
* Must be submitted to **notified body** at intervals determined during conformity assessment
* **Benefit-risk analysis** must integrate all available safety and performance data
* **EUDAMED submission** required for high-risk device categories
**Special attention required for:**
* **Implantable devices** requiring annual or biennial PSURs
* **Class IIb devices** in sterile or measuring functions may require PSURs
* **Novel technologies** with limited clinical evidence requiring enhanced monitoring
* **Device grouping** justification when multiple devices covered in single PSUR
## Guide
Your PSUR must demonstrate **systematic benefit-risk evaluation** using comprehensive data analysis, statistical assessment, and clinical interpretation of accumulated evidence.
### Market Data Analysis
**Document device exposure** by providing accurate **sales volumes** and **patient exposure estimates** across different geographic regions. Use consistent metrics throughout your PSUR (devices placed on market, patient-years of exposure, or episodes of use) to enable meaningful trend analysis.
**Calculate exposure-adjusted incident rates** to account for changes in market penetration. Present data for **European Economic Area (EEA)**, **Turkey**, **Northern Ireland**, and **worldwide** markets separately to meet regulatory reporting requirements.
**Assess device lifecycle status** including first market introduction date, current market status (active, withdrawn, recalled), and any **basic UDI-DI variations** within your device family.
### Safety Data Integration
**Analyze serious incidents** using **IMDRF Adverse Event Terminology** categories covering medical device problems (Annex A), investigation findings (Annexes B-D), health effects (Annexes E-F), and component issues (Annex G). Calculate both absolute numbers and percentage rates relative to exposure.
**Evaluate trend patterns** using statistical methods to identify **clinically significant increases** in incident frequency or severity. Document whether trends represent random variation, increased reporting awareness, or genuine safety signals requiring intervention.
**Review Field Safety Corrective Actions** (FSCAs) and **Corrective and Preventive Actions** (CAPAs) implemented during the surveillance period. Assess **effectiveness** of corrective measures and whether additional actions are required.
### Clinical Evidence Evaluation
**Integrate literature findings** from your clinical evaluation activities, including new publications, clinical studies, and **state-of-the-art developments** that may affect your device's benefit-risk profile.
**Assess Post-Market Clinical Follow-up** (PMCF) data and determine whether findings require updates to your **clinical evaluation report** or **risk management file**. Document how PMCF conclusions support continued device authorization.
**Evaluate complaints and user feedback** that don't qualify as serious incidents but provide insights into device performance, user satisfaction, and **real-world effectiveness**.
### Benefit-Risk Assessment
**Conduct comprehensive benefit-risk analysis** by weighing accumulated safety data against demonstrated clinical benefits. Consider whether new evidence affects your **intended use**, **user populations**, or **clinical claims**.
**Assess data limitations** including surveillance gaps, under-reporting factors, and methodological constraints that may affect your conclusions. Demonstrate **scientific rigor** in acknowledging uncertainties while drawing appropriate conclusions.
**Determine impact on device authorization** by concluding whether your benefit-risk profile remains favorable, requires enhanced monitoring, or necessitates regulatory action such as labeling updates or design modifications.
## Example
**Scenario:** You manufacture an implantable cardiac defibrillator and prepare your biennial PSUR covering 24 months of comprehensive safety and performance monitoring across global markets.
### Periodic Safety Update Report for DefibGuard Pro ICD System
**1. Executive Summary**
This PSUR covers DefibGuard Pro ICD models DG-300 through DG-305 for the period January 1, 2023 to December 31, 2024. Analysis of 847,000 patient-years of exposure, 234 serious incidents, and comprehensive literature review confirms favorable benefit-risk profile supporting continued market authorization.
**2. Device Information and Market Data**
| Market Region | Total Devices Implanted | Patient-Years Exposure | Serious Incidents | Incident Rate per 1000 Patient-Years |
| ------------- | ----------------------- | ---------------------- | ----------------- | ------------------------------------ |
| EEA + TR + NI | 145,230 | 423,100 | 89 | 0.21 |
| Worldwide | 298,450 | 847,000 | 234 | 0.28 |
**3. Safety Analysis**
**Serious Incidents by IMDRF Category:**
* Medical Device Problems (Annex A): 156 incidents (66.7%)
* Health Effects (Annex E): 45 incidents (19.2%)
* Component Issues (Annex G): 33 incidents (14.1%)
**4. Trend Analysis**
Statistical analysis using Poisson regression showed **stable incident rates** over the surveillance period (p = 0.34). No significant trends identified requiring immediate regulatory action.
**5. Field Safety Corrective Actions**
One FSCA initiated (FSCA-2024-001) for battery longevity communication enhancement. Implementation achieved 94% user notification rate with positive user feedback.
**6. Literature and Clinical Evidence**
Review of 67 new publications confirms continued clinical effectiveness for primary prevention of sudden cardiac death. Post-market clinical follow-up data from 12,500 patients demonstrates 96.2% appropriate therapy delivery rate.
**7. Benefit-Risk Conclusion**
Based on analysis of comprehensive safety and performance data, the benefit-risk profile of DefibGuard Pro ICD System remains **favorable** with benefits continuing to outweigh risks. No regulatory action required beyond continued routine surveillance.
## Q\&A
PSURs are required for implantable devices and certain Class III devices under EU MDR. The specific reporting frequency is determined during your conformity assessment process. Typically, implantable devices require annual or biennial PSURs depending on risk profile and clinical experience.
Use consistent exposure metrics such as patient-years (number of patients × years of device use), device-years, or episodes of use. Choose the most appropriate metric for your device type and maintain consistency throughout your PSUR for meaningful trend analysis. Document your calculation methodology.
Immediately assess the clinical significance and implement appropriate risk mitigation measures. This may require updating labeling, implementing additional risk controls, conducting enhanced surveillance, or in severe cases, market withdrawal. Notify your notified body and relevant authorities promptly.
Device grouping is acceptable when devices share similar safety profiles, have equivalent clinical performance, and address the same medical conditions. Provide clear justification for grouping decisions and identify the leading device for the group. Separate analysis may be required if safety profiles diverge.
Use methods appropriate for your data characteristics: Poisson regression for incident rates, Mann-Kendall tests for non-parametric trends, or time-series analysis for complex patterns. Establish significance thresholds (typically p \< 0.05) and consider clinical significance alongside statistical significance.
PSUR frequency is determined during conformity assessment but typically ranges from annual to every five years depending on device risk, clinical experience, and market maturity. High-risk or novel devices typically require more frequent reporting than well-established technologies with extensive clinical history.
# Physician's Handbook
Source: https://docs.withdovetail.com/tasks/physicians-handbook
Create specialized clinical reference supporting healthcare providers with professional implementation guidance.
## Summary
The Physician's Handbook is a **specialized clinical reference document** designed specifically for healthcare providers who prescribe, recommend, or oversee patient use of your medical device. This handbook provides comprehensive clinical information, integration guidance, and professional support resources that go beyond basic user instructions. It serves as the authoritative clinical resource for healthcare providers to effectively incorporate your device into patient care workflows.
## Why is Physician's Handbook important?
Healthcare providers require **detailed clinical context** and professional-level information to make informed decisions about device prescription and patient monitoring. The Physician's Handbook bridges the gap between regulatory compliance documents and practical clinical implementation, providing the depth of information that healthcare professionals need to confidently integrate your device into their practice and patient care protocols.
**Professional credibility and adoption** depend on comprehensive clinical documentation that demonstrates your understanding of healthcare workflows and clinical decision-making processes. A well-developed Physician's Handbook enhances provider confidence in your device, facilitates clinical adoption, and supports evidence-based integration into existing healthcare systems and treatment protocols.
## Regulatory Context
Under **21 CFR Part 820.120** (Device Labeling):
* Physician handbooks are **supplementary professional labeling** that must be accurate and evidence-based
* Must be **consistent with Instructions for Use** and regulatory submissions
* Cannot make **unsupported clinical claims** beyond approved indications
* Must include **appropriate clinical warnings** and contraindications
* Subject to **promotional labeling regulations** under 21 CFR Part 801.4
**Special attention required for:**
* Consistency with 510(k) predicate device comparisons and clinical data
* Off-label use discussions must comply with FDA guidance on promotional materials
* Clinical evidence citations must be accurate and not misleading
* Professional distribution channels and continuing medical education compliance
Under **EU MDR 2017/745**:
* Must be **consistent with clinical evaluation** and technical documentation
* Cannot contradict **GSPR requirements** or expand approved indications
* Must support **intended purpose** with appropriate clinical evidence
* Subject to **quality management system** controls for clinical accuracy
* Must align with **post-market clinical follow-up** requirements
**Special attention required for:**
* Consistency with clinical evaluation report and post-market clinical follow-up plan
* Authorized representative contact information for clinical inquiries
* Integration with post-market surveillance and clinical data collection
* Professional education compliance with EU medical device advertising regulations
## Guide
### Clinical Content Development
Your **clinical information architecture** should provide healthcare providers with comprehensive understanding of device capabilities, limitations, and integration requirements. Structure content around clinical decision-making processes, patient selection criteria, monitoring protocols, and outcome assessment procedures. Focus on practical clinical implementation rather than technical device specifications.
**Evidence-based content** establishes credibility and supports clinical decision-making. Include relevant clinical studies and evidence supporting device efficacy, comparative effectiveness data when available, clinical outcome measures and assessment protocols, and integration guidance for existing clinical workflows. Ensure all clinical claims are supported by appropriate evidence and consistent with regulatory submissions.
### Healthcare Provider Audience
**Clinical specialization** requires tailored content for different healthcare provider types and practice settings. Consider primary care physicians who may be first-line prescribers, specialists who provide ongoing patient management, nurses and clinical staff who support device implementation, and healthcare administrators who oversee clinical protocols and resource allocation.
**Practice integration guidance** helps providers understand how your device fits into existing clinical workflows. Address patient selection and screening procedures, clinical assessment and monitoring protocols, integration with electronic health records and clinical documentation systems, and coordination with other healthcare team members and specialties.
### Clinical Implementation Support
**Patient management protocols** provide structured guidance for healthcare providers throughout the patient care continuum. Include patient selection criteria and contraindication assessment, device prescription and setup procedures, ongoing monitoring and follow-up protocols, troubleshooting guidance for clinical issues, and patient education and support strategies.
**Clinical decision support** helps providers make informed decisions about device use and patient management. Provide clinical algorithms for patient selection and monitoring, outcome assessment tools and interpretation guidance, integration protocols with existing treatment plans, and escalation procedures for clinical concerns or adverse events.
### Professional Education and Training
**Clinical competency development** ensures healthcare providers can effectively utilize your device in patient care. Include learning objectives for different provider types and practice settings, clinical case studies and practical application examples, competency assessment tools and training verification procedures, and continuing medical education resources and accreditation information.
**Ongoing professional support** maintains provider competency and addresses evolving clinical needs. Provide access to clinical experts and consultation services, regular updates on clinical evidence and best practices, professional user communities and peer support networks, and advanced training opportunities for complex clinical applications.
### Clinical Evidence and Research
**Clinical data presentation** should be comprehensive yet accessible to busy healthcare providers. Include summaries of pivotal clinical studies and regulatory submissions, real-world evidence and post-market clinical data, comparative effectiveness information when available, and ongoing clinical research opportunities and collaboration possibilities.
**Research integration** supports evidence-based practice and continuous improvement. Provide guidance for contributing to post-market clinical data collection, participation in clinical research and registry studies, publication opportunities and clinical presentation support, and collaboration with clinical research organizations and academic institutions.
## Example
**Scenario:** You develop a Physician's Handbook for "CardioMonitor Pro," a smartphone application that provides continuous cardiac rhythm monitoring for patients with atrial fibrillation, targeting cardiologists and primary care physicians.
### Clinical Overview Section
**Device Description for Healthcare Providers:**
CardioMonitor Pro is an FDA-cleared smartphone application that provides continuous cardiac rhythm analysis for patients with diagnosed atrial fibrillation. The device integrates with FDA-cleared wearable heart rate monitors to provide real-time arrhythmia detection and patient alert capabilities, supporting clinical management of patients with known cardiac rhythm disorders.
**Clinical Indications and Patient Selection:**
This device is indicated for adult patients (≥18 years) with previously diagnosed atrial fibrillation, atrial flutter, or other documented cardiac arrhythmias who require continuous rhythm monitoring as part of their cardiac care management. Ideal candidates include patients with paroxysmal atrial fibrillation requiring rhythm burden assessment, patients on antiarrhythmic therapy requiring monitoring for efficacy and safety, and patients with symptomatic episodes requiring correlation with objective rhythm data.
**Contraindications and Clinical Limitations:**
CardioMonitor Pro is contraindicated for patients without previously established cardiac arrhythmia diagnoses, pediatric patients under 18 years of age, and emergency cardiac event detection or acute care management. The device is not intended for insulin pump integration, pacemaker monitoring, or replacement of standard cardiac monitoring in acute care settings.
### Clinical Implementation Section
**Patient Assessment and Selection Protocol:**
Begin with comprehensive cardiac history and current arrhythmia management review. Verify patient's technical capability and smartphone compatibility for reliable device operation. Assess patient's understanding of device limitations and appropriate response to alerts. Confirm patient's ability to maintain consistent wearable device use and charging routines.
**Prescription and Setup Guidance:**
Prescribe CardioMonitor Pro through your standard clinical workflow with specific monitoring objectives and alert thresholds. Provide patients with device download instructions and initial setup support. Configure alert parameters based on individual patient clinical needs and arrhythmia history. Establish follow-up schedule for data review and clinical assessment.
**Clinical Monitoring and Follow-up:**
Review rhythm data weekly during initial month, then monthly for stable patients. Assess alert frequency and patient response patterns for clinical significance. Correlate device data with patient symptoms and clinical presentation. Adjust alert thresholds based on clinical findings and patient tolerance.
### Clinical Decision Support Section
**Rhythm Data Interpretation:**
CardioMonitor Pro provides rhythm burden analysis, episode frequency tracking, and correlation with patient activity and symptoms. Use trend analysis to assess treatment efficacy and disease progression. Consider device data alongside standard clinical assessment and diagnostic testing for comprehensive patient evaluation.
**Clinical Action Protocols:**
For increased arrhythmia burden: Review current medications, assess for triggers or underlying causes, consider additional diagnostic testing or specialist consultation. For decreased device compliance: Address technical barriers, provide additional patient education, consider alternative monitoring strategies if needed.
**Integration with Clinical Care:**
Incorporate device data into routine clinical documentation and treatment planning. Share relevant data with consulting specialists and healthcare team members. Use objective rhythm data to support clinical decision-making and patient education about their condition and treatment response.
### Professional Support Section
**Clinical Consultation Services:**
Access to CardioMonitor clinical team for complex patient management questions, consultation on unusual rhythm patterns or device data interpretation, and support for challenging patient cases or technical issues. Contact clinical support at [clinicalsupport@cardiomonitor.com](mailto:clinicalsupport@cardiomonitor.com) or 1-800-CARDIO-MD.
**Continuing Medical Education:**
Quarterly webinars on cardiac rhythm monitoring best practices, annual clinical symposium with CME credits available, online learning modules for device optimization and patient management, and peer consultation network for clinical experience sharing.
**Research and Clinical Evidence:**
Ongoing post-market clinical studies examining real-world effectiveness and patient outcomes. Opportunities for clinical data contribution and research collaboration. Regular updates on clinical evidence and peer-reviewed publications related to continuous cardiac monitoring.
## Q\&A
Include comprehensive clinical context for device use, patient selection criteria and contraindications, clinical implementation and monitoring protocols, evidence-based efficacy and safety information, integration guidance for existing clinical workflows, and professional support resources. Focus on practical clinical decision-making support rather than technical device specifications. Ensure all clinical information is evidence-based and consistent with regulatory submissions and approved indications.
Tailor content for different provider types including primary care physicians, specialists, nurses, and healthcare administrators. Consider varying levels of clinical expertise and practice settings. Provide specialty-specific guidance for patient selection, monitoring protocols, and clinical integration. Include role-specific responsibilities and coordination guidance for multidisciplinary care teams. Address different practice environments from large health systems to individual practices.
Present summaries of pivotal clinical studies and regulatory submissions, real-world evidence and post-market clinical data, comparative effectiveness information when available, and ongoing clinical research opportunities. Ensure all clinical claims are supported by appropriate evidence and consistent with regulatory approvals. Provide accessible summaries for busy healthcare providers while maintaining scientific accuracy and clinical relevance.
Structure protocols around clinical decision-making processes including patient selection and screening, device prescription and setup, ongoing monitoring and follow-up, troubleshooting clinical issues, and patient education strategies. Provide clinical algorithms, outcome assessment tools, integration guidance with existing treatment plans, and escalation procedures for clinical concerns. Focus on practical implementation in real-world clinical settings.
Offer clinical consultation services for complex cases, continuing medical education opportunities with accreditation, professional user communities and peer support networks, regular updates on clinical evidence and best practices, and advanced training for complex applications. Provide multiple support channels including phone, email, and online resources. Ensure support is available during clinical hours and for urgent clinical questions.
Address integration with electronic health records and clinical documentation systems, coordination with other healthcare team members and specialties, incorporation into existing patient care protocols, and alignment with clinical quality measures and outcomes assessment. Provide practical guidance for workflow modification, staff training requirements, and change management considerations for clinical implementation in various healthcare settings.
# Post-Market Clinical Follow-up Plan
Source: https://docs.withdovetail.com/tasks/post-market-clinical-follow-up-plan
Define clinical data collection strategy addressing evidence gaps and confirming real-world performance.
## Summary
The Post-Market Clinical Follow-up Plan defines your systematic approach to **collecting and analyzing clinical data** after device commercialization. This plan establishes specific activities to confirm device safety and performance, identify emerging risks, and ensure continued clinical evidence adequacy throughout the device lifecycle.
## Why is Post-Market Clinical Follow-up Plan important?
Post-market clinical follow-up addresses the **inherent limitations** of pre-market clinical evidence, which is typically collected under controlled conditions with limited patient populations and follow-up periods. Real-world clinical performance may reveal **previously unidentified risks**, **long-term effects**, or **performance variations** across diverse patient populations. PMCF ensures your clinical evidence remains **current and comprehensive**, supporting ongoing regulatory compliance and patient safety. Without structured clinical follow-up, you risk missing critical clinical insights that could affect your device's benefit-risk profile and regulatory status.
## Regulatory Context
Under **21 CFR Part 820** and **FDA Guidance Documents**:
* Post-market studies may be **required as condition of approval** for certain devices
* **522 Post-Market Surveillance Studies** mandated for specific device types
* **Clinical data collection** must support ongoing safety and effectiveness claims
* **Real-World Evidence (RWE)** programs increasingly accepted for regulatory decisions
**Special attention required for:**
* **Software as Medical Device (SaMD)** requiring ongoing performance validation
* **AI/ML-enabled devices** with adaptive algorithms requiring continuous monitoring
* **Breakthrough devices** with expedited approval pathways requiring post-market confirmation
* **De Novo devices** establishing new device classifications requiring safety confirmation
Under **EU MDR 2017/745**:
* PMCF is **mandatory** for all devices under Article 61 and Annex XIV Part B
* Must be **proportionate to risk class** and device characteristics
* **PMCF Evaluation Report** required annually or as specified
* Integration with **clinical evaluation updates** and **PSUR reporting**
**Special attention required for:**
* **Novel devices** requiring enhanced clinical follow-up (Article 61(4))
* **Implantable devices** requiring **Periodic Safety Update Reports (PSUR)**
* **Class III devices** requiring comprehensive clinical follow-up
* **Devices with clinical data gaps** requiring targeted data collection
## Guide
Your Post-Market Clinical Follow-up Plan must establish **systematic procedures** for collecting clinical evidence that addresses specific gaps or uncertainties in your pre-market clinical evaluation. The plan should be **proportionate to your device's risk profile** and clinical evidence needs.
### Defining PMCF Objectives
**Identify specific clinical questions** that require post-market investigation. These typically arise from **clinical evaluation gaps**, **risk management uncertainties**, or **regulatory requirements**. Focus on aspects where pre-market data was limited, such as **long-term safety**, **rare adverse events**, or **performance in specific patient subgroups**.
**Establish clear endpoints** for each PMCF activity, including **safety endpoints** (adverse events, complications), **performance endpoints** (clinical outcomes, device functionality), and **usability endpoints** (user errors, training effectiveness). Ensure endpoints are **measurable and clinically relevant**.
**Define success criteria** that will demonstrate acceptable device performance and safety. Include **statistical considerations** such as sample sizes, confidence intervals, and significance levels appropriate for your clinical questions.
### Selecting Appropriate PMCF Methods
**Literature surveillance** provides ongoing monitoring of published clinical data about your device or similar devices. Establish **systematic search strategies** with defined keywords, databases, and review frequencies. This method is **cost-effective** but may have **limited device-specific data**.
**Registry studies** leverage existing clinical databases to collect real-world performance data. Identify relevant **disease registries** or **device registries** that capture your target patient population. Registry studies provide **large sample sizes** but may have **limited data standardization**.
**Post-market clinical studies** generate prospective clinical data addressing specific research questions. Design studies with appropriate **controls**, **endpoints**, and **statistical power**. These studies provide **high-quality evidence** but require **significant resources** and **regulatory oversight**.
**Healthcare provider surveys** collect structured feedback about device performance and safety from clinical users. Design surveys to capture **quantitative performance metrics** and **qualitative safety observations**. This method provides **rapid feedback** but may have **response bias limitations**.
### Implementation Planning
**Establish timelines** for PMCF activities based on device risk, clinical evidence needs, and regulatory requirements. **Higher-risk devices** typically require **earlier initiation** and **more frequent reporting** of PMCF activities.
**Define resource requirements** including personnel, funding, and infrastructure needed for each PMCF activity. Consider **external partnerships** with clinical research organizations, academic institutions, or registry operators to supplement internal capabilities.
**Plan for data management** including **data collection systems**, **quality assurance procedures**, and **regulatory compliance measures**. Ensure systems can support **long-term data collection** and **regulatory reporting requirements**.
### Integration with Quality Management System
**Connect PMCF findings** to your **risk management process** by establishing procedures for incorporating new clinical data into risk assessments and risk control measures. Define **escalation procedures** for significant safety findings requiring immediate action.
**Integrate with vigilance reporting** by ensuring PMCF activities can identify **reportable incidents** and feed into your **post-market surveillance system**. Establish **data sharing protocols** between PMCF and vigilance functions.
**Plan for clinical evaluation updates** by defining how PMCF data will be incorporated into **periodic clinical evaluation reviews** and **regulatory submissions**. Ensure PMCF findings support ongoing **clinical evidence adequacy**.
## Example
**Scenario:** You develop a novel AI-powered diagnostic imaging software for detecting diabetic retinopathy. Your PMCF plan addresses algorithm performance across diverse populations, long-term diagnostic accuracy, and integration with clinical workflows.
### Post-Market Clinical Follow-up Plan for RetinaScan AI Diagnostic Software
**1. Device Information**
RetinaScan AI v3.2 - Class IIa software for automated diabetic retinopathy screening in primary care settings. Novel AI algorithm trained on limited population diversity requiring real-world validation.
**2. PMCF Objectives**
* Confirm diagnostic accuracy across diverse ethnic populations
* Monitor algorithm performance degradation over time
* Assess clinical workflow integration and user acceptance
* Identify rare false positive/negative patterns
**3. Planned PMCF Activities**
| Activity | Description | Aim | Timeline |
| -------- | -------------------------------- | ------------------------------------------------------ | --------- |
| PMCF-001 | Multi-site registry study | Validate diagnostic accuracy in 5,000 diverse patients | 24 months |
| PMCF-002 | Healthcare provider survey | Assess workflow integration and usability | 12 months |
| PMCF-003 | Literature surveillance | Monitor published data on AI diagnostic tools | Ongoing |
| PMCF-004 | Algorithm performance monitoring | Track diagnostic metrics through device telemetry | Ongoing |
**4. Clinical Evaluation Gaps Addressed**
* Limited ethnic diversity in pre-market clinical studies
* Short-term follow-up in pivotal trials (6 months vs. required 2-year monitoring)
* Controlled clinical environment vs. real-world primary care settings
* Algorithm stability over extended deployment periods
**5. Risk Management Integration**
PMCF activities specifically address identified risks:
* R-015: Diagnostic accuracy degradation in underrepresented populations
* R-023: User workflow disruption leading to screening delays
* R-031: Algorithm bias affecting clinical decision-making
**6. Reporting Schedule**
* Quarterly: Internal PMCF data review and safety monitoring
* Annually: PMCF Evaluation Report with regulatory submission
* As needed: Safety signal investigation and reporting
## Q\&A
Choose PMCF activities based on your clinical evidence gaps and device risk profile. Literature surveillance and registry studies are cost-effective for most devices. Post-market clinical studies are needed for novel devices or when specific clinical questions require prospective data collection.
All devices under MDR require some form of PMCF. The extent depends on your device classification, novelty, and clinical evidence adequacy. Novel devices, higher-risk devices, and those with clinical evidence gaps require more comprehensive PMCF activities.
Immediately assess the clinical significance and reportability of new safety findings. Update your risk management file, implement additional risk controls if needed, and report to regulatory authorities according to vigilance requirements. Consider whether findings require immediate device modifications.
Review your PMCF plan annually or when significant changes occur to your device, clinical evidence, or regulatory requirements. Update the plan when PMCF activities are completed, new clinical questions arise, or regulatory feedback requires modifications.
Yes, real-world data from electronic health records, registries, and claims databases can provide valuable PMCF evidence. Ensure data quality, patient privacy protection, and regulatory acceptance of your real-world data sources and analysis methods.
# Post-Market Clinical Follow-Up Report
Source: https://docs.withdovetail.com/tasks/post-market-clinical-follow-up-report
Document real-world clinical evidence validating continued device safety and effectiveness.
## Summary
The Post-Market Clinical Follow-Up (PMCF) Report documents the **results and analysis** of all PMCF activities outlined in your PMCF plan, providing evidence for **continued clinical performance** and device safety. This report integrates **real-world clinical data** with your clinical evaluation to demonstrate ongoing compliance with essential requirements and support regulatory decision-making about continued market authorization.
## Why is Post-Market Clinical Follow-Up Report important?
The PMCF Report serves as **regulatory evidence** that your device continues to perform safely and effectively in real-world clinical settings. Regulatory authorities require PMCF reports to **verify clinical evaluation conclusions** and ensure that **clinical benefits continue to outweigh risks** as market experience accumulates. Notified bodies use PMCF reports during **surveillance audits** and **certificate renewal assessments** to evaluate your ongoing compliance with clinical evidence requirements. Inadequate PMCF reporting can result in **regulatory scrutiny**, **additional clinical studies**, or **market restrictions**.
## Regulatory Context
While FDA doesn't specifically mandate PMCF reports, equivalent requirements exist under:
* **Real-World Evidence (RWE)** submissions for regulatory decision support
* **Post-market surveillance studies** under 21 CFR 822 requiring clinical data
* **Premarket Approval (PMA)** devices requiring periodic safety updates
* **Breakthrough device** designation requiring real-world performance data
**Special attention required for:**
* **Software as Medical Device** requiring algorithm performance validation
* **AI/ML devices** needing continuous learning validation
* **Digital therapeutics** requiring real-world effectiveness evidence
* **Novel devices** with limited pre-market clinical data requiring enhanced monitoring
Under **EU MDR 2017/745**:
* **PMCF reports required** for all medical devices as part of clinical evidence updates
* Must feed into **clinical evaluation report** updates (Article 61)
* **Notified body submission** required at intervals determined during conformity assessment
* **Integration with risk management** file updates required (Article 10)
**Special attention required for:**
* **Class III and implantable devices** requiring comprehensive PMCF programs
* **Novel devices** with limited equivalent device data requiring enhanced follow-up
* **PMCF plan deviations** requiring justification and impact assessment
* **Clinical evaluation updates** based on PMCF findings requiring regulatory notification
## Guide
Your PMCF Report must demonstrate **systematic evaluation** of real-world clinical performance and provide **evidence-based conclusions** about continued device safety and effectiveness.
### PMCF Activities Documentation
**Document all planned PMCF activities** from your PMCF plan including **literature reviews**, **registry studies**, **user surveys**, **clinical data collection**, and **surveillance activities**. Provide **completion status** for each activity and explain any **deviations** from original timelines or methodologies.
**Analyze PMCF results systematically** by evaluating whether objectives were met, **clinical questions** were answered, and **evidence gaps** were addressed. Compare actual findings with **expected outcomes** and **pre-market predictions** to identify any discrepancies requiring investigation.
**Assess data quality and limitations** including **study design adequacy**, **sample size sufficiency**, **follow-up duration appropriateness**, and **potential biases** that may affect result interpretation. Document **methodological constraints** and their impact on conclusions.
### Clinical Performance Analysis
**Evaluate device effectiveness** by analyzing **clinical outcomes**, **performance measures**, and **user satisfaction** data collected through PMCF activities. Compare results with **pre-market clinical data** and **intended performance specifications** to verify continued effectiveness.
**Assess safety profile** by analyzing **adverse events**, **device-related complications**, and **long-term safety outcomes** observed during PMCF activities. Identify any **new risks** or **risk pattern changes** requiring risk management file updates.
**Monitor user experience** through **usability assessments**, **training effectiveness evaluations**, and **real-world use error analysis**. Ensure that **intended users** can operate the device safely and effectively in **actual use environments**.
### Integration with Technical Documentation
**Update clinical evaluation** by incorporating PMCF findings into your **clinical evaluation report**. Assess whether new evidence affects **benefit-risk analysis**, **equivalent device justifications**, or **state-of-the-art comparisons**.
**Revise risk management file** based on PMCF findings that identify **new hazards**, **modified risk estimates**, or **control measure effectiveness**. Document how PMCF data influences **risk acceptability decisions** and **control strategy updates**.
**Evaluate labeling adequacy** by reviewing whether **Instructions for Use**, **contraindications**, **warnings**, and **precautions** remain appropriate based on real-world use experience and observed outcomes.
### Conclusions and Future Planning
**Provide evidence-based conclusions** about device **clinical performance**, **safety profile**, and **continued compliance** with essential requirements. Address whether **clinical evidence remains adequate** or requires **additional data collection**.
**Identify future PMCF needs** based on current findings including **new clinical questions**, **enhanced monitoring requirements**, or **additional studies** needed to address emerging evidence gaps or safety concerns.
**Plan regulatory submissions** based on PMCF conclusions including **clinical evaluation updates**, **labeling modifications**, or **design change notifications** required by your findings.
## Example
**Scenario:** You manufacture a digital therapeutic app for diabetes management and prepare your annual PMCF report covering real-world effectiveness studies, user outcome data, and safety monitoring results.
### Post-Market Clinical Follow-Up Report for GlucoGuide Digital Therapeutic
**1. Scope and PMCF Activities**
This report covers PMCF activities for GlucoGuide v3.1 from January 1, 2024 to December 31, 2024. All planned PMCF activities completed successfully including real-world registry study (n=2,450), user outcome survey (n=1,200), and healthcare provider feedback assessment (n=89 clinical sites).
**2. PMCF Results Summary**
| PMCF Activity | Target | Achieved | Key Findings |
| ------------------- | --------------- | --------------- | ------------------------------- |
| Registry Study | 2,000 patients | 2,450 patients | HbA1c reduction 0.8% average |
| User Survey | 1,000 responses | 1,200 responses | 92% user satisfaction rate |
| Provider Assessment | 75 sites | 89 sites | 96% would recommend to patients |
**3. Clinical Performance Analysis**
Real-world effectiveness data confirms pre-market clinical study results with **sustained HbA1c reductions** averaging 0.8% at 6-month follow-up. **Time-in-range** improvements observed in 87% of users, exceeding pre-market study performance (79%).
**4. Safety Profile Assessment**
No device-related serious adverse events identified. **User behavior changes** observed including improved medication adherence (78% vs 45% baseline) and increased glucose monitoring frequency (4.2 vs 1.8 tests/day baseline).
**5. Technical Documentation Impact**
**Clinical Evaluation:** PMCF data supports continued favorable benefit-risk profile. Real-world effectiveness meets or exceeds pre-market study outcomes. No updates required to clinical evaluation conclusions.
**Risk Management:** No new risks identified. Existing risk controls remain adequate. Enhanced user engagement observed reduces risk of poor glycemic control through improved self-management behaviors.
**6. PMCF Conclusions**
GlucoGuide demonstrates **continued clinical effectiveness** and **acceptable safety profile** in real-world use. Clinical evidence remains adequate to support intended use claims. No immediate regulatory actions required.
**7. Future PMCF Planning**
Continue annual registry data collection with expanded pediatric population assessment planned for 2025. Enhanced long-term outcome monitoring (2-year follow-up) initiated to support clinical evaluation updates.
## Q\&A
PMCF reporting frequency depends on your device risk class, clinical evidence maturity, and notified body requirements. Typically, Class III and implantable devices require annual PMCF reports, while lower-risk devices may report biennially. Check your specific regulatory obligations and notified body agreements.
Immediately assess the clinical significance and implement appropriate risk controls. Update your risk management file, consider whether immediate regulatory notification is required, and plan additional PMCF activities to monitor the safety concern. Document all actions taken and their effectiveness.
Document all deviations from your original PMCF plan including reasons for changes, alternative approaches taken, and impact on study validity. Provide scientific justification for deviations and assess whether modified activities still address original clinical questions adequately.
Adequate PMCF data should address clinical questions identified in your PMCF plan, provide sufficient evidence to support continued clinical evaluation conclusions, and demonstrate ongoing safety and effectiveness. Data quality, sample size, and follow-up duration should be appropriate for your device risk profile and clinical claims.
Systematically incorporate PMCF data into your clinical evaluation report updates, assessing impact on benefit-risk analysis, equivalent device justifications, and state-of-the-art comparisons. Consider whether new evidence affects clinical claims, user populations, or risk assessments requiring regulatory notification.
Thoroughly investigate discrepancies between PMCF and pre-market data considering study design differences, population variations, and real-world factors. Update your clinical evaluation with new evidence, reassess benefit-risk balance, and consider whether design changes or labeling updates are needed.
# Post-Market Surveillance Plan
Source: https://docs.withdovetail.com/tasks/post-market-surveillance-plan
Establish systematic monitoring approach ensuring ongoing device safety and regulatory compliance.
## Summary
The Post-Market Surveillance Plan establishes your systematic approach to **monitoring device safety and performance** after market release. This plan defines data collection methods, analysis procedures, and reporting requirements to ensure ongoing compliance with regulatory obligations and patient safety.
## Why is Post-Market Surveillance Plan important?
Post-market surveillance exists because **real-world device performance** often differs from controlled testing environments. Regulatory authorities require manufacturers to **continuously monitor** their devices to identify previously unknown risks, confirm expected performance, and detect emerging safety issues. This proactive monitoring protects patients, maintains regulatory compliance, and provides valuable data for device improvements. Without a structured surveillance plan, you risk missing critical safety signals that could lead to patient harm, regulatory enforcement actions, or costly device recalls.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **21 CFR Part 803** (Medical Device Reporting):
* Post-market surveillance is **mandatory** under Section 820.100 (Corrective and Preventive Actions)
* Must establish procedures for **data collection and analysis** from various sources
* **Medical Device Reporting (MDR)** requires reporting of deaths, serious injuries, and malfunctions
* **Periodic reporting** may be required for certain device types
**Special attention required for:**
* Software medical devices requiring **cybersecurity monitoring** (FDA Guidance 2022)
* Class III devices with **enhanced post-market study requirements**
* Devices with **FDA-mandated post-market studies** as condition of approval
* **Unique Device Identification (UDI)** integration for traceability
Under **EU MDR 2017/745**:
* Post-market surveillance system is **mandatory** under Article 83
* Must comply with **Annex III requirements** for systematic data collection
* **Post-Market Surveillance Report** required annually for Class I devices, others as specified
* Integration with **EUDAMED database** for incident reporting
**Special attention required for:**
* **Post-Market Clinical Follow-up (PMCF)** requirements for higher-risk devices
* **Periodic Safety Update Reports (PSUR)** for implantable devices and Class III devices
* **Vigilance reporting** within specified timeframes (Article 87)
* **Trend reporting** for statistically significant increases in incidents
## Guide
Your Post-Market Surveillance Plan must establish **systematic procedures** for collecting, analyzing, and acting on post-market data. The plan serves as your roadmap for ongoing device monitoring and regulatory compliance.
### Data Collection Sources
**Define comprehensive data inputs** that will provide visibility into device performance. Your plan must specify how you'll collect information from **vigilance databases**, including FDA MAUDE, BfArM, and Swissmedic systems. Establish **search keywords** specific to your device type and intended use to ensure relevant incident identification. Include procedures for monitoring **complaints and feedback** from users, distributors, and healthcare providers.
**Establish complaint management integration** by defining which complaints require logging in your quality management system versus general customer support issues. Focus on complaints related to **device performance, safety concerns, or unexpected behaviors** that could indicate emerging risks.
**Plan for literature and registry monitoring** by identifying relevant medical journals, conference proceedings, and device registries that may contain safety information about your device or similar products. This includes monitoring **competitor recalls** and **field safety notices** that might indicate industry-wide issues.
### Analysis and Trending Methodology
**Implement statistical trend analysis** using appropriate methods such as the **Mann-Kendall test** for identifying significant increases in incident frequency or severity. Define your **significance thresholds** (typically p-value \< 0.05) and establish procedures for investigating positive trends.
**Calculate complaint rates** by comparing complaint volumes against device sales or installation numbers. This provides context for determining whether complaint levels represent normal variation or concerning trends requiring investigation.
**Establish risk assessment integration** by defining how post-market findings will trigger updates to your risk management file. Include procedures for determining when new risks require immediate reporting versus inclusion in periodic reports.
### Reporting and Documentation Requirements
**Define reporting timelines** based on your device classification and regulatory requirements. Specify when you'll generate **Post-Market Surveillance Reports**, **Periodic Safety Update Reports**, or other required documentation.
**Establish escalation procedures** for serious incidents requiring immediate regulatory notification. Include clear criteria for determining reportability and timelines for submission to appropriate authorities.
**Plan for corrective action integration** by defining how surveillance findings will trigger your CAPA system when risks exceed acceptable levels or new hazards are identified.
### Implementation and Review Procedures
**Assign responsibilities** for surveillance activities, including data collection, analysis, and reporting. Ensure personnel have appropriate training and access to necessary databases and systems.
**Establish review frequencies** for surveillance data analysis. While formal reports may be annual, ongoing monitoring should occur more frequently to enable rapid response to emerging issues.
**Plan for surveillance plan updates** as your device evolves, market conditions change, or regulatory requirements are modified. Include procedures for version control and approval of plan revisions.
## Example
**Scenario:** You manufacture a mobile health app that monitors blood glucose levels and provides dosing recommendations. Your Post-Market Surveillance Plan establishes monthly vigilance database searches, quarterly complaint analysis, and annual comprehensive reporting.
### Post-Market Surveillance Plan for GlucoTrack Mobile Health Application
**1. Scope**
This plan describes post-market surveillance activities for GlucoTrack v2.1, a Class II mobile medical device application for diabetes management. The plan addresses data collection from vigilance databases, user complaints, and clinical literature to ensure ongoing device safety and performance monitoring.
**2. PMS Data Inputs**
**2.1 Vigilance Data**
Monthly searches of FDA MAUDE, BfArM, and Swissmedic databases using keywords: "glucose monitoring app," "diabetes software," "insulin dosing error," "hypoglycemic event," "mobile health device malfunction."
**2.2 Complaints Data**
Integration with customer support system to identify complaints related to:
* Incorrect glucose readings or calculations
* App crashes during critical functions
* Dosing recommendation errors
* Data synchronization failures
* User interface confusion leading to medication errors
Complaint rate calculation: Monthly complaints ÷ Active monthly users × 1000
**2.3 Literature Monitoring**
Quarterly review of diabetes technology journals and conference proceedings for reports of similar device issues or emerging safety concerns.
**3. Trend Analysis Methodology**
Mann-Kendall test applied to monthly complaint data with significance threshold p \< 0.05. Positive trends trigger immediate investigation and potential risk assessment updates.
**4. Reporting Schedule**
* Monthly: Internal surveillance data review
* Quarterly: Complaint trend analysis and literature review
* Annually: Comprehensive Post-Market Surveillance Report
* As needed: Serious incident reports within 24 hours of identification
**5. Responsibilities**
Quality Assurance Manager: Database monitoring and trend analysis
Regulatory Affairs Specialist: Report preparation and submission
Clinical Affairs: Literature review and clinical significance assessment
## Q\&A
Post-market surveillance monitors your device after market release to identify safety issues, confirm expected performance, and detect emerging risks that weren't apparent during pre-market testing. It's required to ensure ongoing patient safety and regulatory compliance.
Log only complaints related to device performance or safety in your complaint management system. General feedback or support issues that can be resolved with instructions don't need formal logging. Focus on complaints that could indicate device malfunctions or safety concerns.
If you identify a new risk during vigilance database review, add it to your risk assessment to ensure all foreseeable risks are accounted for. Update your Risk Management Report and determine if immediate regulatory reporting is required based on the risk's severity and probability.
Implement a ticket management system that categorizes medical device-related complaints separately from general support issues. Log all complaints but mark their relevance to device safety and performance. This ensures regulatory compliance while managing workflow efficiently.
Maintain a system that categorizes complaints based on their relevance to device safety and performance. Track whether complaints relate to device malfunctions, user errors, or safety concerns. This categorization facilitates trend analysis and regulatory reporting requirements.
# Post-Market Surveillance Report
Source: https://docs.withdovetail.com/tasks/post-market-surveillance-report
Analyze systematic safety data demonstrating ongoing device monitoring and risk assessment.
## Summary
The Post-Market Surveillance Report documents your **systematic analysis** of device safety and performance data collected during a defined surveillance period. This report synthesizes vigilance data, complaints, incidents, and trend analyses to demonstrate ongoing device safety and identify any emerging risks requiring action.
## Why is Post-Market Surveillance Report important?
The Post-Market Surveillance Report serves as your **regulatory evidence** that you're actively monitoring device safety and responding appropriately to emerging risks. Regulatory authorities use these reports to assess your **post-market oversight capabilities** and ensure your device continues to meet safety and performance requirements after market authorization. Without comprehensive surveillance reporting, you risk regulatory enforcement actions, loss of market authorization, and potential liability for unaddressed safety issues.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and various FDA guidance documents:
* **Post-market surveillance studies** under 21 CFR 822 require periodic reporting
* **MDR reporting** (21 CFR 803) incidents must be included in surveillance analysis
* **522 Post-Market Surveillance Studies** require periodic reporting to FDA
* Must demonstrate **systematic data collection** and **trend analysis**
**Special attention required for:**
* **Devices under FDA enforcement actions** requiring enhanced surveillance
* **Class III devices** with intensive surveillance requirements
* **Software updates** that may affect safety profiles
* **Combination products** requiring coordinated surveillance approaches
Under **EU MDR 2017/745**:
* **Post-Market Surveillance Report** required under Article 84
* Must comply with **Annex III requirements** for surveillance documentation
* **Periodic Safety Update Reports** (PSURs) may incorporate surveillance findings
* **Notified body** may request surveillance reports for assessment
**Special attention required for:**
* **High-risk devices** requiring enhanced surveillance frequency
* **Clinical evaluation updates** based on surveillance findings
* **EUDAMED integration** for incident tracking
* **Trend reporting** with statistical significance assessment
## Guide
Your Post-Market Surveillance Report must provide **comprehensive analysis** of all surveillance data collected during the reporting period, demonstrating systematic monitoring and appropriate response to safety signals.
### Data Collection and Sources
**Gather vigilance data** from multiple international databases including **FDA MAUDE**, **FDA Recalls**, **BfArM**, and **Swissmedic**. Use consistent **search keywords** related to your device, technology class, and medical conditions. Document your search methodology and results comprehensively.
**Compile complaints data** from your complaint management system, focusing on **safety-related complaints**, **performance issues**, and **user feedback**. Calculate **complaint rates** using the formula: Complaint Rate = Complaints / Sales Volume. Track both **serious incidents** and **non-serious events**.
**Analyze corrective and preventive actions** (CAPAs) implemented during the surveillance period. Document **CAPA effectiveness**, **timeline compliance**, and **recurring issues** that may indicate systematic problems requiring additional intervention.
### Statistical Trend Analysis
**Perform trend analysis** using appropriate statistical methods such as the **Mann-Kendall test** for non-parametric data, **regression analysis** for linear trends, or **Nelson Rules** for control charts. Assess **frequency patterns**, **severity trends**, and **seasonal variations** over the surveillance period.
**Evaluate new risks** identified through surveillance activities and determine whether they require **risk management file updates**. Assess whether **existing risk controls** remain adequate or require enhancement based on real-world performance data.
**Update benefit-risk analysis** by incorporating surveillance findings into your overall **device benefit-risk assessment**. Consider whether new data affects your **clinical evaluation conclusions** or requires **labeling updates**.
### Reporting and Documentation Requirements
**Structure your report** systematically covering scope, data inputs, trend analysis, and conclusions. Ensure **traceability** between surveillance plan objectives and report findings.
**Document limitations** of your surveillance activities including **data gaps**, **methodological constraints**, and **areas requiring enhanced monitoring**. This demonstrates **transparency** and **continuous improvement** commitment.
**Prepare regulatory submissions** based on surveillance findings, including **incident reports**, **labeling updates**, or **design change notifications** as required by your findings.
## Example
**Scenario:** You manufacture a wearable cardiac monitoring device and prepare your annual Post-Market Surveillance Report covering 12 months of surveillance data including vigilance searches, complaint analysis, and trend assessment.
### Post-Market Surveillance Report for CardioWatch Pro Wearable Monitor
**1. Scope and Overview**
This report covers post-market surveillance activities for CardioWatch Pro v4.2 from January 1, 2024 to December 31, 2024. Analysis of 2,847 complaints, vigilance database searches, and trend analysis identified no significant safety signals requiring immediate regulatory action.
**2. Surveillance Data Analysis**
| Data Source | Records Analyzed | Safety-Related | Action Required |
| ------------------- | ------------------- | -------------- | ------------------- |
| Customer Complaints | 2,847 | 23 | 3 CAPAs initiated |
| FDA MAUDE | 156 similar devices | 12 relevant | Monitor for trends |
| Internal Incidents | 8 | 2 | Updated user manual |
**3. Trend Analysis Results**
Mann-Kendall test (p = 0.23) showed no statistically significant trend in complaint rates over the surveillance period. Seasonal variation observed with higher complaint rates in Q2 correlating with increased physical activity.
**4. Risk Management Updates**
Two new risks identified: battery performance degradation during extreme temperatures and skin irritation from extended wear. Both risks added to risk management file with appropriate control measures.
**5. Conclusions**
Surveillance data confirms acceptable safety profile with no emerging risks requiring immediate action. Continued monitoring recommended for exercise-related performance issues. Next surveillance report due December 31, 2025.
## Q\&A
The frequency depends on your device risk class and regulatory requirements. Most manufacturers prepare annual reports, but high-risk devices may require semi-annual reporting. Check your surveillance plan and regulatory guidance for specific timelines.
Immediately assess the severity and implement appropriate risk controls. Update your risk management file, consider whether labeling changes are needed, and determine if immediate regulatory notification is required. Document all actions taken and monitor effectiveness.
The Mann-Kendall test is commonly used for medical device surveillance as it doesn't require normal data distribution. Other methods include Nelson Rules for control charts, regression analysis for linear trends, or Weibull analysis for reliability data. Choose methods appropriate for your data characteristics.
Thoroughly investigate discrepancies between surveillance findings and pre-market assessments. Update your risk management file with new information, reassess risk controls, and consider whether design changes or labeling updates are needed. Document your investigation and conclusions.
Search using keywords related to your device type, technology class, intended use, and medical conditions treated. Include both positive and negative search terms. Document your search strategy, databases searched, date ranges, and number of relevant results found.
# Primary Language Translated IFU
Source: https://docs.withdovetail.com/tasks/primary-language-translated-ifu
Create master language translation maintaining regulatory accuracy and cultural appropriateness.
## Summary
Primary Language Translated IFU is your **master language version** of the Instructions for Use that serves as the source document for all subsequent translations. This document must be professionally translated into the primary language of your target market while maintaining complete regulatory accuracy and cultural appropriateness. It establishes the foundation for consistent, compliant user communication across all markets where your device will be distributed.
## Why is Primary Language Translated IFU important?
Regulatory authorities **mandate local language instructions** to ensure users can fully understand device operation, safety information, and regulatory compliance details. The EU MDR Article 10(11) specifically requires that information supplied by the manufacturer be in the official language of the target market. Your primary language translation demonstrates regulatory compliance and commitment to user safety in local markets.
Professional translation **prevents misunderstandings and user errors** that could result from inadequate or inaccurate instructions. Medical device terminology requires specialized translation expertise to maintain regulatory accuracy while ensuring cultural appropriateness and user comprehension. Poor translations can lead to device misuse, regulatory non-compliance, and significant liability exposure in target markets.
## Regulatory Context
Under **21 CFR Part 801.15** (Medical device labeling):
* Instructions must be **understandable to intended users** in their primary language
* **Accuracy requirements** apply to all translated content
* Must maintain **consistency with English master** version for regulatory submissions
* **Professional translation** recommended for medical terminology accuracy
* Subject to **labeling controls** under Quality System Regulation
**Special attention required for:**
* State-specific language requirements for certain medical devices
* Spanish language requirements in specific US markets and territories
* Consistency with 510(k) submissions and predicate device labeling
* Professional medical translation for complex or high-risk devices
Under **EU MDR 2017/745 Article 10(11)**:
* Information must be in **official language of target market**
* **Professional translation required** for regulatory compliance
* Must maintain **complete accuracy** with source documentation
* **Notified body review** may include translation quality assessment
* **Authorized representative** information must be accurately translated
**Special attention required for:**
* Multi-language markets requiring multiple official language versions
* Technical terminology consistency across EU member state translations
* Cultural adaptation while maintaining regulatory accuracy
* Version control across all language versions for regulatory updates
## Guide
### Translation Strategy and Planning
Your **translation approach** should begin with comprehensive source document preparation to ensure clarity and completeness before translation begins. Identify your primary target market and its specific language requirements, including regional variations and technical terminology preferences. Select qualified medical translation services with regulatory experience and establish clear quality assurance procedures for translation accuracy verification.
**Market analysis** helps determine your primary language priority and translation requirements. Consider market size and regulatory requirements, user demographics and language preferences, healthcare system integration needs, and competitive landscape language standards. Your primary language translation often serves as the template for additional language versions, making accuracy and completeness critical.
### Professional Translation Requirements
**Translator qualifications** are essential for regulatory compliance and user safety. Require medical translation expertise with specific experience in medical device documentation, regulatory translation experience in your target market, native language proficiency in the target language, and familiarity with relevant medical terminology and cultural context. Verify translator credentials and previous medical device translation experience.
**Quality assurance processes** ensure translation accuracy and regulatory compliance. Implement back-translation verification where translated content is translated back to the source language for accuracy comparison, regulatory review by local experts familiar with market-specific requirements, medical terminology consistency checks across all translated materials, and cultural appropriateness review to ensure user comprehension and acceptance.
### Content Adaptation and Localization
**Cultural adaptation** goes beyond literal translation to ensure user comprehension and acceptance. Consider cultural context for medical terminology and treatment approaches, local healthcare system integration and workflow considerations, regulatory symbol recognition and interpretation differences, and user interface design elements that may require cultural adaptation. Maintain regulatory accuracy while enhancing cultural appropriateness.
**Technical terminology management** ensures consistency and accuracy across all translated content. Develop comprehensive glossaries of medical and technical terms with approved translations, establish terminology databases for consistency across multiple documents, implement quality control procedures for technical accuracy verification, and maintain version control for terminology updates and revisions.
### Regulatory Compliance and Documentation
**Regulatory alignment** ensures your translated IFU meets all local market requirements. Verify compliance with local language regulations and guidelines, confirm accuracy of regulatory symbols and their explanations, ensure proper translation of manufacturer and authorized representative information, and validate compliance with local advertising and marketing regulations for medical devices.
**Documentation management** maintains regulatory traceability and version control. Establish clear version control procedures for all language versions, maintain translation records and quality assurance documentation, implement change control procedures for updates and revisions, and ensure regulatory submission documentation includes appropriate translation verification records.
### Implementation and Maintenance
**Distribution and availability** ensures users can access translated instructions when needed. Coordinate translated IFU availability with device distribution timelines, establish procedures for electronic IFU implementation in local languages, ensure customer support availability in target languages, and implement user feedback collection procedures for translation quality improvement.
**Ongoing maintenance** keeps translated content current and accurate. Establish procedures for updating translations when source documents change, implement regular review cycles for translation accuracy and cultural appropriateness, maintain translator relationships for consistent terminology and style, and monitor user feedback for translation improvement opportunities.
## Example
**Scenario:** You develop a diabetes management application and need to create a German-language IFU for the European market, starting with your English master document.
### Translation Project Setup
**Source Document Preparation:**
Your English IFU for "GlucoTracker Pro" serves as the master document. Before translation, you conduct a final review to ensure completeness, clarity, and regulatory accuracy. You identify technical terms that require specialized medical translation, such as "glycemic variability," "postprandial glucose," and "insulin sensitivity," and prepare a comprehensive glossary for translator reference.
**Translator Selection:**
You select a certified medical translator with specific experience in diabetes management devices and German medical device regulations. The translator demonstrates familiarity with German healthcare terminology, EU MDR requirements, and cultural considerations for diabetes management in German-speaking markets.
### German Translation Development
**Technical Content Translation:**
**Intended Purpose (German):**
"GlucoTracker Pro ist für die Verwendung durch Erwachsene mit bekannten Herzrhythmusstörungen zur Überwachung von Herzrhythmusmustern und zum Empfang von Warnungen bei potenziellen arrhythmischen Ereignissen bestimmt, die von kompatiblen tragbaren Herzfrequenzmessgeräten erkannt werden."
**Contraindications (German):**
"Kontraindikationen:
* Nicht für Patienten unter 18 Jahren bestimmt
* Nicht geeignet für Patienten ohne zuvor diagnostizierte Herzrhythmusstörungen
* Nicht während der Schwangerschaft ohne ärztliche Beratung verwenden
* Nicht für die Erkennung kardialer Notfallereignisse bestimmt"
**Warnings and Precautions (German):**
"Warnungen und Vorsichtsmaßnahmen:
* Dieses Gerät ersetzt nicht die regelmäßige medizinische Versorgung oder Notdienste
* Konsultieren Sie Ihren Arzt, bevor Sie Behandlungsänderungen basierend auf Gerätewarnungen vornehmen
* Suchen Sie sofort medizinische Hilfe bei Brustschmerzen, Atemnot oder anderen Herzsymptomen"
### Quality Assurance Process
**Back-Translation Verification:**
A second qualified translator translates the German version back to English without access to the original document. Comparison reveals that "Herzrhythmusstörungen" accurately translates to "cardiac arrhythmias" and technical terminology maintains consistency with medical standards.
**Cultural Adaptation Review:**
German healthcare experts review the translation for cultural appropriateness and healthcare system integration. They confirm that terminology aligns with German medical practice standards and that user instructions are appropriate for the German healthcare context.
**Regulatory Compliance Verification:**
The translated IFU undergoes review for EU MDR compliance, ensuring all required information is accurately translated and culturally appropriate. Regulatory symbols and their explanations are verified for accuracy in the German market context.
## Q\&A
Medical device translators should have specialized medical translation expertise with specific experience in medical device documentation, regulatory translation experience in your target market, native language proficiency in the target language, and familiarity with relevant medical terminology and cultural context. Verify translator credentials, previous medical device translation experience, and knowledge of local regulatory requirements. Professional certification in medical translation and membership in relevant translation associations indicate qualified expertise.
Develop comprehensive glossaries of medical and technical terms with approved translations for each target language. Establish terminology databases for consistency across multiple documents and implement quality control procedures for technical accuracy verification. Maintain version control for terminology updates and ensure all translators use approved terminology consistently. Regular terminology reviews help maintain accuracy as medical language evolves.
Translation focuses on accurate conversion of text from one language to another while maintaining regulatory compliance and technical accuracy. Localization goes beyond translation to adapt content for cultural context, local healthcare systems, regulatory requirements, and user preferences. Medical device localization includes cultural adaptation of medical terminology, local healthcare workflow integration, regulatory symbol recognition differences, and user interface elements that enhance cultural appropriateness while maintaining safety and effectiveness.
Implement back-translation verification where translated content is translated back to the source language for accuracy comparison. Conduct regulatory review by local experts familiar with market-specific requirements and perform medical terminology consistency checks across all translated materials. Regular quality audits, user feedback collection, and ongoing translator relationships help maintain translation quality over time. Document all quality assurance activities for regulatory compliance.
EU MDR Article 10(11) requires information to be in the official language of the target market with professional translation for regulatory compliance. Translated content must maintain complete accuracy with source documentation and may be subject to notified body review for translation quality. FDA requirements focus on user comprehension with instructions that must be understandable to intended users in their primary language. Both regulations require accuracy and consistency with regulatory submissions.
Establish clear version control procedures for all language versions with synchronized update schedules when source documents change. Maintain translation records and quality assurance documentation for regulatory traceability. Implement change control procedures that ensure all language versions reflect current regulatory requirements and technical specifications. Use document management systems that track version relationships between source and translated documents to prevent regulatory compliance issues.
# Quality Manual, Policy & Objectives
Source: https://docs.withdovetail.com/tasks/quality-manual-policy-objectives
Develop quality policy foundations and measurable objectives that guide QMS effectiveness and regulatory compliance.
## Summary
Your **Quality Manual** serves as the foundation document of your Quality Management System (QMS), establishing your company's quality policy, objectives, and organizational structure while demonstrating compliance with ISO 13485:2016, FDA QSR, and EU MDR requirements.
## Why is Quality Manual, Policy & Objectives important?
The Quality Manual exists because regulators need assurance that your organization has a **systematic approach** to quality management rather than relying on ad-hoc practices. It demonstrates to regulatory bodies, notified bodies, and auditors that your company has clearly defined quality responsibilities, measurable objectives, and a commitment to continuous improvement.
Your quality policy communicates your organization's **core values** regarding quality to all stakeholders, while quality objectives provide concrete, measurable targets that guide daily operations and strategic decisions. This document also establishes the **management representative** role, which is legally required and makes this person accountable for quality system effectiveness.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Quality policy and objectives are **mandatory** under Section 820.20(a)
* Management representative must be **formally designated** with authority (820.20(b))
* Quality manual must **document the QMS** and reference all procedures (820.40)
* Must demonstrate **management responsibility** for the quality system
**Special attention required for:**
* Management representative designation - this person receives FDA warning letters
* Responsible Corporate Officer Doctrine (Park Doctrine) - executives remain liable
* Document control requirements (820.40) for manual maintenance
* Management review integration (820.20(c))
Under **EU MDR 2017/745**:
* Quality management system **required** for all manufacturers (Article 10(9))
* Must comply with **EN ISO 13485:2016** including quality policy (Section 5.3)
* Quality manual required for **notified body assessment**
* Person Responsible for Regulatory Compliance (PRRC) must be integrated
**Special attention required for:**
* PRRC role definition and integration with quality management
* Authorized representative roles for non-EU manufacturers
* Quality objectives must align with EU requirements
* Regular review and update requirements for CE marking maintenance
## Guide
Your Quality Manual establishes the **framework** for your entire QMS. Start by defining your company's role as manufacturer, authorized representative, or distributor, as this determines your regulatory obligations and scope.
### Defining Your Quality Policy
Your **quality policy** should be a concise statement that reflects your company's mission while committing to regulatory compliance and continuous improvement. Write it in language that resonates with your team and customers. Include commitments to meet legal requirements, maintain an effective QMS, and establish measurable quality objectives.
### Establishing Quality Objectives
Quality objectives must be **measurable and achievable** while aligning with your quality policy. Focus on QMS effectiveness rather than just product quality metrics. Consider objectives like "achieve 95% employee training completion rates," "maintain zero major audit findings," or "respond to customer complaints within 48 hours."
Avoid overly specific technical metrics in your quality manual, as these should be captured in your key performance indicators (KPIs) that can be updated more frequently without revising your foundational quality documents.
### Management Representative Selection
Choose your **management representative** carefully. This person will be legally accountable for QMS effectiveness and will receive regulatory correspondence including warning letters. In startups, this should typically be a C-suite executive due to the Responsible Corporate Officer Doctrine. The representative needs sufficient authority to ensure QMS compliance across all organizational levels.
### Organizational Structure Documentation
Document your **management team** with clear roles and responsibilities. Include the quality representative and other key personnel who manage, perform, or verify quality-affecting work. This provides auditors with a clear understanding of your quality organization and accountability structure.
### Process Overview and Exclusions
List all QMS processes your organization implements and clearly document any **ISO 13485:2016 exclusions** based on your product characteristics. Software-only devices can exclude sterilization and contamination controls, while hardware devices may only exclude specific requirements based on whether they're sterile or implantable.
## Example
### Scenario
MedTech Solutions develops a mobile application for diabetes management. As a software-only medical device manufacturer, they need to establish their Quality Manual to define their quality policy, set measurable objectives, and designate management responsibilities before pursuing FDA 510(k) clearance.
### Example Quality Manual Structure
**Quality Policy:**
"MedTech Solutions is committed to developing innovative digital health solutions that improve patient outcomes while maintaining the highest standards of safety, security, and regulatory compliance. We will continuously improve our Quality Management System, meet all applicable regulatory requirements, and empower our team to deliver exceptional quality in everything we do."
**Quality Objectives:**
* Achieve 100% completion of mandatory employee training within 30 days of hire
* Maintain zero major nonconformities during internal and external audits
* Respond to customer feedback and complaints within 48 hours
* Complete management review annually with documented improvement actions
* Ensure 95% of quality objectives are met during each management review cycle
**Management Structure:**
* CEO: Sarah Johnson (Top Management)
* VP of Quality: Michael Chen (Management Representative)
* CTO: David Kim (Software Development)
* VP of Operations: Lisa Rodriguez (Business Operations)
**Scope and Exclusions:**
The QMS applies to all software development, post-market surveillance, and quality management activities. The following ISO 13485:2016 sections are excluded due to software-only product characteristics:
* 6.4.2 Contamination control
* 7.5.2 Cleanliness of product
* 7.5.5 Particular requirements for sterile medical devices
* 7.5.7 Sterilization process validation
* 7.5.9.2 Implantable medical device requirements
* 7.5.11 Preservation of product
## Q\&A
A QMS is like an instruction manual for your company, outlining processes for designing and testing devices. Technical documentation is specific to your product and includes test plans and reports based on the high-level processes defined in the QMS. The Quality Manual is the foundational QMS document that ties everything together.
Freelancers working on device development should be added as employees if they are under contract. This ensures they are considered part of the quality management system and have access to necessary documents. Include them in your organizational structure documentation and ensure they receive appropriate training.
The management representative and all team members should review all relevant SOPs and certify that they have read them. This ensures compliance with regulatory requirements. The management representative specifically needs training on quality management system oversight, audit processes, and regulatory compliance responsibilities.
Quality objectives should be reviewed at least annually during management review, but can be updated more frequently if needed. Your quality manual should contain stable, high-level objectives, while specific targets and KPIs can be adjusted in supporting documents without requiring quality manual revisions.
No, quality objectives should not only refer to device quality but also the quality of your QMS and overall organizational work. Include objectives for training excellence, customer satisfaction, audit performance, and continuous improvement to demonstrate comprehensive quality management.
# Release Notes
Source: https://docs.withdovetail.com/tasks/release-notes
Document software changes and improvements communicating updates to users and regulatory authorities.
## Summary
Release Notes document the changes, improvements, and bug fixes implemented in each version of your medical device software. This document provides users, regulatory authorities, and internal teams with clear information about what has changed between software versions and serves as a critical component of your software lifecycle documentation.
## Why is Release Notes important?
Release Notes serve as **transparent communication** about software changes to all stakeholders including healthcare providers, patients, and regulatory authorities. They provide essential **traceability** for software modifications and demonstrate systematic change management required by medical device regulations. For healthcare users, release notes help them understand new functionality, safety improvements, and any workflow changes that may affect patient care. Regulatory authorities use release notes to assess the impact of software changes and verify compliance with post-market surveillance requirements.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Change control** (820.40) requires documentation of all design changes
* **Design history file** (820.30) must include records of design changes
* **Software validation** guidance requires documentation of software modifications
* **Labeling controls** (820.120) apply to software version identification
**Special attention required for:**
* Documentation of cybersecurity-related changes and improvements
* Clear identification of changes that affect substantial equivalence
* Integration with post-market surveillance reporting requirements
* Version control alignment with FDA software guidance documents
Under **EU MDR 2017/745**:
* **GSPR 17** requires software development lifecycle documentation
* **EN 62304** mandates software modification documentation (Section 6)
* **Post-market surveillance** (Articles 83-86) requires change monitoring
* **Technical documentation** (Annex II) must include software change records
**Special attention required for:**
* Documentation of changes affecting clinical evaluation or safety
* Integration with UDI-PI version tracking requirements
* Notified body notification for significant software changes
* CE marking validity assessment for software modifications
## Guide
### Version Identification and Dating
Each release notes document must clearly identify the **specific software version** and release date. Use your established version numbering scheme from your Software Development and Maintenance Plan to ensure consistency across all documentation. The release date should reflect when the software version was made available to users, not when the release notes were written. This information is critical for traceability and regulatory compliance.
### Change Documentation Structure
Organize your release notes into clear categories that help users understand the **nature and impact** of changes. Typically include sections for new features or enhancements, bug fixes, security improvements, and any known limitations or issues. Each change should be described in user-friendly language that healthcare professionals can understand, avoiding technical jargon when possible while maintaining accuracy.
### Feature and Enhancement Documentation
When documenting new features or enhancements, focus on the **clinical benefit and user impact** rather than technical implementation details. Describe how the changes improve patient care, workflow efficiency, or safety. Include any new user interface elements, workflow changes, or performance improvements that users will notice. This helps healthcare providers understand how to leverage new capabilities effectively.
### Bug Fix Documentation
Document all **safety-relevant bug fixes** and significant functional corrections. While you don't need to list every minor bug fix, include those that could affect clinical decision-making, patient safety, or workflow reliability. Describe the issue that was resolved and the improvement users can expect. This transparency builds trust and helps users understand the ongoing quality improvements.
### Security and Performance Updates
Clearly document any **cybersecurity improvements** or performance enhancements, as these are increasingly important for medical device software. Describe security patches, encryption improvements, or access control enhancements in terms that help users understand the safety benefits. Performance improvements should be quantified when possible to help users understand the practical impact.
### User Communication Considerations
Write release notes for your **primary users** - healthcare professionals who may not have technical backgrounds. Use clear, concise language and focus on practical implications rather than technical details. Consider including guidance on any workflow changes or new training requirements that may result from the software updates.
## Example
### Scenario
You are releasing version 3.2.1 of your patient monitoring software that includes enhanced alarm algorithms, improved data visualization, and several critical bug fixes. The software is used in intensive care units to monitor patient vital signs and alert healthcare staff to critical changes.
### Example Release Notes Document
#### Release Notes - CardioWatch Pro - Version 3.2.1
**Date:** April 22, 2024
**Version:** 3.2.1
#### Changes
##### Enhanced Alarm Intelligence
* Implemented advanced machine learning algorithms to reduce false alarms by 35% while maintaining 100% sensitivity for critical events
* Added contextual alarm prioritization that considers patient history and current clinical status
* Introduced smart alarm clustering to prevent alarm fatigue during multi-parameter events
* Enhanced arrhythmia detection with improved specificity for atrial fibrillation and ventricular tachycardia
##### Improved Data Visualization
* Redesigned trend display with customizable time scales (1-hour to 7-day views)
* Added color-coded severity indicators for all monitored parameters
* Implemented high-contrast mode for improved visibility in low-light environments
* Enhanced touch interface responsiveness for tablet-based monitoring stations
##### Workflow Enhancements
* Added quick-access buttons for common clinical scenarios (post-operative, cardiac care, respiratory distress)
* Implemented automatic parameter adjustment based on patient age and condition
* Enhanced report generation with customizable templates for different clinical specialties
* Added integration with hospital information systems for automatic patient data synchronization
#### Bug Fixes
##### Critical Fixes
* Resolved intermittent alarm delay issue that could cause up to 3-second delays in critical alarm notifications
* Fixed data synchronization error that occasionally caused patient parameter history to display incorrectly
* Corrected calculation error in mean arterial pressure that affected readings above 150 mmHg
* Resolved network connectivity issue that could cause temporary data loss during WiFi handoffs
##### Functional Improvements
* Fixed user interface freezing issue when accessing patient history during high network traffic
* Corrected timestamp accuracy for alarm logs to ensure precise event documentation
* Resolved printing issues with trend reports on certain network printer models
* Fixed minor display artifacts in waveform rendering during screen rotation
##### Security Updates
* Enhanced encryption protocols for patient data transmission
* Implemented additional access controls for administrative functions
* Updated authentication mechanisms to prevent unauthorized device access
* Strengthened audit logging for all user interactions and system events
## Q\&A
Include all changes that could affect user workflow, patient safety, or clinical decision-making, regardless of how minor they seem. Even small bug fixes can be important to healthcare users. Focus on user impact rather than technical complexity when determining what to include.
Generally no, unless the technical details directly impact how users interact with the software. Focus on what changed from the user's perspective and how it benefits patient care. Save technical details for internal documentation or developer notes.
Document security improvements in general terms that highlight the benefit without revealing specific vulnerabilities or implementation details. Focus on how the changes improve patient data protection and system reliability rather than technical security mechanisms.
Issue corrected release notes with a clear indication of what was changed and why. Maintain version control for your release notes and ensure all stakeholders receive the corrected information. Document the correction process for future reference.
Release notes should align with your change requests and change evaluation reports. Each item in your release notes should be traceable back to approved change documentation. This ensures consistency between your internal change management and external communication.
Yes, include any known limitations or issues that could affect clinical use, especially if they represent changes from previous versions. This transparency helps users make informed decisions and demonstrates responsible software lifecycle management.
# Required Documentation Training by Functional Group
Source: https://docs.withdovetail.com/tasks/required-documentation-training-by-functional-group
Assign role-specific training requirements through systematic functional group matrices ensuring relevant competency development.
## Summary
**Required Documentation Training by Functional Group** provides systematic framework for assigning appropriate Quality Management System (QMS) training requirements to employees based on their functional roles and responsibilities within the medical device organization. This essential training matrix ensures each team member receives relevant regulatory and quality training aligned with their job duties while preventing training gaps or excessive training overhead.
## Why is Required Documentation Training by Functional Group important?
Functional group-based training represents **strategic resource allocation** that ensures employees receive training directly relevant to their quality responsibilities without overwhelming them with irrelevant procedures. **Without systematic training assignments**, organizations risk providing insufficient training for critical roles or wasting resources on unnecessary training that doesn't improve job performance.
**Regulatory requirements mandate** competency-based training approaches. FDA Quality System Regulation (21 CFR 820.25) and ISO 13485:2016 (Section 6.2) require organizations to ensure personnel are competent to perform tasks affecting product quality. **Functional group training matrices provide evidence** of systematic competency management aligned with organizational structure.
The structured approach transforms training from generic requirement into **role-specific competency development**. **Well-designed training assignments** improve job performance, reduce quality errors, and ensure employees understand their specific contributions to product quality and regulatory compliance.
## Regulatory Context
Under **21 CFR Part 820.25** (Personnel):
* **Training procedures** must identify training needs and ensure personnel understand quality responsibilities
* **Documented training** must demonstrate competency for tasks affecting product quality
* **Training effectiveness** must be evaluated and documented for personnel in quality-related roles
* **Management representative** requires documented competency in quality system management
**Special attention required for:**
* Design control personnel requiring specific training on design procedures and FDA regulations
* Quality team training must cover all applicable quality system procedures
* Software team training must include cybersecurity, validation, and change control procedures
* Management training must ensure understanding of quality system responsibilities and regulatory oversight
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Competence determination** must identify necessary competencies for personnel affecting product quality (ISO 13485 6.2.1)
* **Training provision** must address competency gaps and demonstrate understanding of quality objectives
* **Person Responsible for Regulatory Compliance (PRRC)** requires specific qualifications and ongoing training
* **Training effectiveness evaluation** must verify that training achieves intended competency outcomes
**Special attention required for:**
* Clinical evaluation team requiring specialized training on MDR clinical evidence requirements
* Post-market surveillance personnel needing training on vigilance and safety reporting procedures
* Risk management team training on ISO 14971 and MDR risk management requirements
* Software team training on cybersecurity requirements per MDCG 2019-16 guidance
## Guide
### Functional Group Definition and Scope
**Define organizational functional groups** clearly based on actual job responsibilities rather than formal organizational chart positions. **Common groups include** Management (C-level and designated leadership), Quality and Regulatory (QMS and regulatory specialists), Product and Software (design and development teams), Corporate (HR, finance, business operations), and Business (marketing, sales, business development).
**Allow flexibility** for employees belonging to multiple functional groups when job responsibilities span traditional boundaries. **Document group assignments** clearly and update them when roles evolve or organizational structure changes.
**Consider geographic and cultural factors** when defining functional groups for international organizations. **Adapt group definitions** to reflect local regulatory requirements and business practices while maintaining consistency in training approaches.
### Training Requirement Matrix Development
**Create comprehensive training matrix** mapping QMS procedures to functional groups based on relevance to job responsibilities. **Universal training** such as Quality Manual and Document Control applies to all groups. **Specialized training** such as Software Development or Clinical Evaluation applies only to relevant functional groups.
**Prioritize training assignments** based on regulatory criticality and job impact. **Management groups** require broad training covering oversight responsibilities. **Quality and Regulatory groups** need comprehensive training across all QMS procedures. **Technical groups** require training focused on their specific technical and quality responsibilities.
**Balance training comprehensiveness** with practical resource constraints. **Avoid training overload** by focusing on procedures directly relevant to job performance while ensuring adequate coverage of quality responsibilities.
### Role-Specific Training Requirements
**Management training** should emphasize leadership responsibilities, regulatory oversight, quality objectives, and management review requirements. **Include training** on quality policy implementation, resource allocation, and strategic quality planning to support effective quality system leadership.
**Quality and Regulatory personnel** require comprehensive training covering all QMS procedures, regulatory requirements, and specialized quality tools. **Emphasize** risk management, corrective action, internal audit, and regulatory strategy procedures essential for quality system maintenance.
**Product and Software teams** need training focused on design controls, risk management, change management, and technical procedures directly affecting product development. **Include cybersecurity**, validation, and testing procedures essential for technical quality assurance.
**Corporate and Business teams** require training on procedures affecting their support functions including document control, purchasing, sales, and complaint management. **Focus on** interfaces between business operations and quality requirements.
### Training Implementation and Tracking
**Implement training systematically** using individual training logs that track completion against functional group requirements. **Schedule training** to align with employee onboarding, role changes, and procedure updates affecting their functional responsibilities.
**Provide training delivery flexibility** including online review, in-person sessions, mentoring, and external courses appropriate for different learning objectives and group needs. **Document training methods** and ensure consistency across similar functional roles.
**Track training completion** against functional group requirements and identify overdue training systematically. **Escalate training gaps** to management and ensure timely completion before employees perform quality-related tasks.
### Training Program Management
**Review functional group assignments** regularly during management reviews and organizational changes. **Update training requirements** when new procedures are introduced, existing procedures are revised, or functional responsibilities evolve.
**Assess training effectiveness** through performance monitoring, audit findings, and employee feedback. **Adjust training assignments** based on effectiveness data and changing organizational needs.
**Coordinate training programs** with human resources processes including performance evaluations, career development, and succession planning. **Use training data** to support talent management and organizational development activities.
### Continuous Improvement
**Monitor training program performance** through metrics including completion rates, overdue training, and correlation with quality performance. **Identify improvement opportunities** in training content, delivery methods, or assignment strategies.
**Gather feedback** from employees and managers regarding training relevance, effectiveness, and practical application. **Update training programs** based on feedback and changing business needs.
**Benchmark training approaches** against industry best practices and regulatory guidance. **Adapt programs** to incorporate lessons learned and emerging quality management practices.
## Example
**Scenario:** Your medical device organization has 25 employees across five functional groups developing a Class IIa wearable health monitoring device. You need to establish appropriate training requirements for each group to ensure regulatory compliance while optimizing resource utilization.
### Functional Group Definition
You define five groups: Management (CEO, CTO, VP Quality - 3 people), Quality and Regulatory (Quality Manager, Regulatory Specialist - 2 people), Product and Software (software engineers, designers, testers - 12 people), Corporate (HR, Finance, Operations - 5 people), and Business (Marketing, Sales, Business Development - 3 people).
### Training Matrix Development
Management receives training on 15 key SOPs including Quality Manual, Management Review, Risk Management, and regulatory procedures. Quality and Regulatory receives comprehensive training on all 22 SOPs. Product and Software receives training on 18 SOPs covering technical and quality procedures. Corporate receives training on 12 SOPs covering business and quality interfaces. Business receives training on 14 SOPs covering customer-facing and quality procedures.
### Implementation Strategy
You implement training through individual training logs tracking completion against functional group requirements. New employees complete initial training within 30 days of starting. Procedure updates trigger continuous training for affected functional groups within 2 weeks of procedure release.
### Training Delivery
Management receives executive briefings and focused sessions on leadership responsibilities. Quality and Regulatory receives detailed training including practical application exercises. Technical teams receive hands-on training emphasizing daily application. Support teams receive overview training focusing on their specific interfaces with quality requirements.
### Program Management
You track training completion monthly and report status during management reviews. Training gaps are escalated immediately and addressed through accelerated training schedules. You review functional group assignments annually and update training requirements based on organizational changes and regulatory updates.
## Q\&A
Map SOPs to functional groups based on job responsibilities and quality impact. Include procedures that employees will implement, be affected by, or need to understand for effective job performance. Management needs oversight procedures, technical teams need development procedures, and support teams need interface procedures. Consider both direct implementation and awareness requirements.
Assign training requirements covering all relevant functional groups for multi-role employees. Document their multiple group memberships clearly and ensure they receive training appropriate for all their responsibilities. Consider creating custom training plans for employees with unique role combinations while maintaining systematic tracking.
Review functional group assignments and training requirements annually during management review and immediately when organizational changes occur. Update requirements when new SOPs are introduced, existing procedures are significantly revised, or when role responsibilities change. Document review activities and rationale for requirement changes.
Tailor delivery methods to group needs and learning objectives. Management may prefer executive briefings and strategic overviews. Technical teams benefit from hands-on training and practical application. Support teams need focused training on their specific quality interfaces. Use online review for standard procedures and in-person sessions for complex topics.
Apply functional group training requirements to temporary employees and contractors based on their assigned responsibilities and quality impact. Establish training requirements in contracts and ensure completion before beginning work. Document training completion and maintain records according to your quality system procedures.
Evaluate SOP relevance carefully considering both direct implementation and awareness needs. Employees may need awareness training even if they don't directly implement procedures. Remove SOPs from training requirements only when there is clear evidence of no relevance to job performance or quality responsibilities. Document rationale for exclusions.
Monitor training effectiveness through performance metrics, audit findings, and employee feedback specific to each functional group. Track correlation between training completion and job performance quality. Assess whether training translates into improved quality outcomes and regulatory compliance for each group.
Maintain functional group definitions, training requirement matrices, individual training logs, training delivery records, and effectiveness assessments. Document training program reviews, requirement updates, and rationale for changes. Ensure documentation supports audit requirements and demonstrates systematic competency management.
# Risk Assessment
Source: https://docs.withdovetail.com/tasks/risk-assessment
Systematically identify analyze and evaluate device hazards establishing foundation for targeted risk control measures.
## Summary
The Risk Assessment systematically identifies, analyzes, and evaluates all potential hazards and risks associated with your medical device, establishing the foundation for risk control measures and demonstrating compliance with ISO 14971 requirements throughout the device development process.
## Why is a Risk Assessment Important?
A comprehensive Risk Assessment provides the **analytical foundation** for medical device safety by systematically identifying all foreseeable hazards before they can cause harm. Without thorough risk assessment, development teams miss critical safety issues, leading to **inadequate risk controls**, **post-market safety problems**, and **regulatory compliance failures** that can result in device recalls or market withdrawal.
This assessment transforms potential safety concerns into **documented risks with quantified likelihood and severity**, enabling informed decision-making about risk acceptability and control measures. It establishes the **evidence base** for demonstrating that your device is safe for its intended use and that all foreseeable risks have been appropriately addressed.
For medical device development, risk assessment serves as your **safety roadmap** by identifying where risk controls are needed and providing the rationale for design decisions. It demonstrates to regulatory authorities that your organization has systematically considered device safety and implemented appropriate measures to protect users and patients from harm.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), the FDA requires:
* **Risk analysis** as part of design and development activities
* **Documented evaluation** of device-related hazards and risks
* **Risk control measures** implemented based on risk assessment findings
* **Design review** of risk assessment results and risk control decisions
* **Risk management file** maintained with complete risk assessment documentation
The FDA recognizes **ISO 14971:2019** as the consensus standard for risk assessment, requiring:
* Systematic hazard identification and risk analysis
* Risk evaluation against predefined acceptance criteria
* Risk control implementation and verification
* Residual risk assessment and overall risk evaluation
* Post-market risk monitoring and assessment updates
**Special attention required for:**
* Software risk assessment must follow IEC 62304 requirements and integrate with overall device risk assessment
* Cybersecurity risks require ongoing assessment per FDA cybersecurity guidance including threat modeling
* Use-related risks must be assessed per FDA Human Factors guidance and IEC 62366-1
* Combination devices require coordinated risk assessment across all device components
Under **EU MDR 2017/745**, risk assessment must comply with:
* **Annex I GSPR 3** requiring comprehensive risk assessment and management
* **EN ISO 14971:2019** as harmonized standard for risk assessment processes
* **Annex II Section 4** requiring risk assessment documentation in technical file
* **Article 61** requiring clinical evaluation to address risks identified in risk assessment
Key MDR requirements include:
* Risk assessment covering entire device lifecycle including post-market phase
* Clinical evaluation must address benefit-risk balance based on risk assessment
* Post-market surveillance must monitor risks identified in risk assessment
* Notified body assessment of risk assessment adequacy and conclusions
* Person Responsible for Regulatory Compliance (PRRC) oversight of risk assessment
**Special attention required for:**
* Clinical evidence requirements may be driven by specific risks identified in risk assessment
* Post-market clinical follow-up (PMCF) must monitor risks that require ongoing evaluation
* Vigilance reporting must be coordinated with risk assessment findings and updates
* AI/ML devices require specific risk assessment considerations per emerging MDCG guidance
## Guide
Your Risk Assessment must comprehensively identify and evaluate all foreseeable risks associated with your medical device while providing clear justification for risk acceptability decisions.
### Preliminary Hazard Analysis
Begin with **systematic hazard identification** using structured methods appropriate to your device type. Conduct preliminary hazard analysis (PHA) to identify system-level hazards, failure mode and effects analysis (FMEA) for component-level failures, and use-related risk analysis for human factors issues.
Consider **multiple hazard categories** including software malfunctions, hardware failures, user interface issues, environmental factors, cybersecurity threats, and biological risks. Review similar devices, incident databases, and published literature to ensure comprehensive hazard identification. Engage multidisciplinary teams to capture different perspectives on potential hazards.
### Hazard-to-Harm Analysis
Establish **clear linkages** between identified hazards, hazardous situations, and potential harms. For each hazard, identify the sequence of events that could lead to a hazardous situation and the potential harms that could result. Document the causal relationships and consider multiple pathways from hazard to harm.
Define **harm categories** that reflect the severity of potential consequences including temporary discomfort, reversible injury, irreversible injury, and life-threatening situations. Consider both immediate and delayed effects, direct and indirect harms, and impacts on different user populations.
### Risk Analysis and Estimation
Conduct **probability estimation** for each identified risk using available data, expert judgment, and appropriate analysis methods. Estimate both the probability of hazardous situation occurrence (P1) and the probability of harm given the hazardous situation (P2). Calculate overall probability as P1 multiplied by P2.
Perform **severity assessment** for each potential harm using your established severity categories. Consider worst-case scenarios while maintaining realistic assessments based on available evidence. Document assumptions and uncertainty in probability and severity estimates.
### Risk Evaluation and Acceptability
Apply **risk acceptance criteria** from your Risk Management Plan to determine if each risk is acceptable, requires reduction as far as possible (AFAP), or is unacceptable. Use your risk acceptance matrix to make consistent decisions across all identified risks.
Document **risk acceptability decisions** with clear rationale including consideration of intended use, user population, and available alternatives. For risks requiring reduction, identify potential risk control measures and their expected effectiveness.
### Software Safety Classification
For devices containing software, determine **IEC 62304 safety classification** (Class A, B, or C) based on the potential for software failure to contribute to hazardous situations. Consider both direct software failures and software contributions to system-level hazards.
Document **software risk analysis** that addresses software-specific hazards including coding errors, integration failures, cybersecurity vulnerabilities, and software-hardware interface issues. Ensure software safety classification drives appropriate development rigor and verification activities.
### Risk Control Planning
Identify **potential risk control measures** for unacceptable risks and those requiring reduction AFAP. Prioritize controls following the ISO 14971 hierarchy: inherent safety by design, protective measures, and information for safety.
Evaluate **risk control effectiveness** and potential for introducing new risks. Document how risk controls will be implemented as design requirements, protective features, or user information. Plan verification activities to confirm risk control effectiveness.
### Residual Risk Assessment
Assess **residual risks** remaining after implementation of risk control measures. Re-evaluate probability and severity considering the effectiveness of implemented controls. Determine if residual risks are acceptable according to your risk acceptance criteria.
Conduct **overall residual risk evaluation** considering the cumulative effect of all residual risks. Document benefit-risk analysis for any unacceptable residual risks, demonstrating that clinical benefits outweigh remaining risks.
### Documentation and Traceability
Maintain **comprehensive risk assessment documentation** including hazard identification records, risk analysis tables, risk evaluation decisions, and risk control specifications. Ensure traceability between hazards, risks, controls, and verification activities.
Establish **review and update procedures** for risk assessment documentation including triggers for updates, review frequencies, and approval processes. Plan for incorporating post-market information and design changes into risk assessment updates.
## Example
**Scenario:** You're conducting risk assessment for a wearable stress monitoring device that collects physiological data and provides stress management recommendations. The assessment must address hardware, software, cybersecurity, and clinical use risks across the complete system.
### Risk Assessment
**ID:** RA-StressWear-2024-001
**Device:** StressWear Stress Monitoring System
**Software Safety Classification:** Class B - Non-serious injury possible from software failure (incorrect stress level readings could lead to inappropriate user actions)
**Risk Analysis Process:**
* **P1:** Probability of hazardous situation occurring from hazard
* **P2:** Probability of harm occurring from hazardous situation
* **Overall Probability:** P1 multiplied by P2
* **Risk Level:** Determined using risk acceptance matrix from Risk Management Plan
**Risk Analysis Table:**
| Risk ID | Risk Type | Hazard | P1 | Hazardous Situation | P2 | Harm | Severity | Overall Prob | Risk Level |
| ------- | ------------- | --------------------------------- | -- | --------------------------------------------------- | -- | ------------------------------------------------------------------- | -------- | ------------ | ----------- |
| R001 | Hardware | Sensor malfunction | P3 | Inaccurate physiological readings | P3 | Incorrect stress level information leading to inappropriate actions | S2 | P3 | Reduce AFAP |
| R002 | Software | Algorithm error | P2 | Stress level calculation error | P3 | User misinterprets stress state, ignoring symptoms | S2 | P2 | Acceptable |
| R003 | Usability | Confusing user interface | P4 | User misunderstands stress display | P2 | Inappropriate action based on misunderstanding | S2 | P3 | Reduce AFAP |
| R004 | Cybersecurity | Data breach | P2 | Unauthorized access to health data | P4 | Privacy violation and potential discrimination | S3 | P3 | Reduce AFAP |
| R005 | Hardware | Battery overheating | P1 | Device becomes hot during charging | P2 | Skin burn from prolonged contact | S3 | P1 | Acceptable |
| R006 | Biological | Allergic reaction | P2 | Skin contact with device materials | P3 | Contact dermatitis or allergic reaction | S2 | P2 | Acceptable |
| R007 | Software | App crash during critical reading | P3 | Loss of stress monitoring during high-stress period | P2 | User unaware of stress level when intervention needed | S2 | P2 | Acceptable |
| R008 | Environmental | Water damage | P2 | Device exposed to water beyond IP rating | P4 | Device malfunction leading to no stress monitoring | S1 | P3 | Acceptable |
| R009 | Use Error | Incorrect device placement | P4 | Device worn incorrectly affecting readings | P3 | Inaccurate stress measurements, poor management | S2 | P4 | Reduce AFAP |
| R010 | Cybersecurity | Malware infection | P1 | Malicious software affects device operation | P2 | Device provides false readings or stops functioning | S3 | P1 | Acceptable |
**Risk Control Measures:**
| Risk ID | Risk Control Type | Control Description | Implementation | Verification Method |
| ------- | ---------------------- | ------------------------------------------------------------------------------- | ------------------------------ | --------------------------------------------- |
| R001 | Inherent Safety | Implement sensor redundancy and cross-validation algorithms | Software Requirements Document | System testing with sensor failure simulation |
| R001 | Information for Safety | User training on recognizing device malfunction indicators | Instructions for Use | Usability testing validation |
| R003 | Inherent Safety | Redesign user interface with clear stress level indicators and explanatory text | Software Requirements Document | Usability testing with target users |
| R003 | Information for Safety | Provide user guide with interpretation examples | Instructions for Use | Usability testing validation |
| R004 | Protective Measures | Implement end-to-end encryption and secure authentication | Software Requirements Document | Cybersecurity penetration testing |
| R004 | Protective Measures | Regular security updates and vulnerability monitoring | Software Maintenance Plan | Post-market security monitoring |
| R009 | Information for Safety | Clear placement instructions with visual guides | Instructions for Use | Usability testing validation |
| R009 | Protective Measures | Device placement detection algorithm with user feedback | Software Requirements Document | System testing with placement variations |
**Residual Risk Assessment:**
After implementation of risk control measures:
* **R001:** Reduced to P2/S2 = Acceptable (sensor redundancy significantly reduces probability)
* **R003:** Reduced to P2/S2 = Acceptable (improved UI design reduces misunderstanding)
* **R004:** Reduced to P1/S3 = Acceptable (encryption and security measures reduce breach probability)
* **R009:** Reduced to P2/S2 = Acceptable (placement detection and training reduce incorrect use)
**Overall Residual Risk:** Acceptable - All individual risks are acceptable after control measures, and overall benefit-risk ratio is positive based on stress management benefits.
**Conclusion:**
The risk assessment has identified and evaluated all foreseeable risks associated with the StressWear system. Risk control measures have been implemented to reduce unacceptable risks to acceptable levels. The overall residual risk is acceptable considering the clinical benefits of objective stress monitoring and personalized stress management recommendations.
## Q\&A
Use **multiple systematic methods** including preliminary hazard analysis (PHA), failure mode and effects analysis (FMEA), and use-related risk analysis. Review incident databases, similar device recalls, and published literature for your device type. Engage multidisciplinary teams including clinical, technical, and quality perspectives. Consider the complete device lifecycle from manufacturing through disposal. Use structured checklists for different hazard categories (software, hardware, environmental, use-related, cybersecurity). When in doubt, err on the side of including potential hazards that can be evaluated and potentially dismissed rather than missing important risks.
Use **qualitative probability assessment** with clearly defined categories and expert judgment. Establish probability ranges (e.g., P1: less than 1 in 1,000,000, P2: 1 in 100,000 to 1 in 1,000,000) and use available evidence including similar devices, component reliability data, and clinical literature. Document assumptions and uncertainty in estimates. Consider worst-case scenarios while maintaining realistic assessments. Plan for data collection through testing, clinical evaluation, or post-market surveillance to refine estimates over time. Focus on relative probability ranking when absolute values are uncertain.
Include **sufficient detail for regulatory review and team understanding** while maintaining practical usability. Document the complete chain from hazard to harm with clear causal relationships. Include probability and severity estimates with supporting rationale. Specify risk control measures with implementation details and verification methods. Maintain traceability between risks, controls, and verification activities. Use structured tables for consistency but supplement with narrative explanations for complex risks. Ensure documentation supports design decisions and regulatory submissions.
Conduct **system-level risk analysis** that considers interactions between components. Map risks across hardware, software, and user interface boundaries. Consider failure propagation and cascading effects between subsystems. Use system-level hazard analysis methods like fault tree analysis for complex interactions. Ensure risk controls are coordinated across all affected components. Document system-level risks separately from component-level risks while maintaining clear relationships. Assign clear responsibility for system-level risk management and control implementation.
Update risk assessment when **design changes affect safety** or when **new hazards are identified**. Common triggers include design modifications, new user feedback, component changes, software updates, or regulatory guidance changes. Conduct formal reviews at design milestones and before major releases. Implement change control procedures that evaluate risk impact of all design changes. Maintain living risk documentation that evolves with development rather than static assessments. Plan for post-market risk assessment updates based on real-world experience and incident reports.
Ensure **systematic methodology** following recognized standards like ISO 14971. Document clear rationale for all risk acceptability decisions with reference to established criteria. Demonstrate comprehensive hazard identification using multiple methods and expert review. Show traceability between risks, controls, and verification activities. Include appropriate clinical and technical expertise in risk assessment teams. Maintain complete documentation with version control and change rationale. Conduct independent review of risk assessment conclusions before regulatory submission.
# Risk Management Plan
Source: https://docs.withdovetail.com/tasks/risk-management-plan
Establish systematic risk management framework defining acceptance criteria responsibilities and lifecycle processes.
## Summary
The Risk Management Plan establishes your systematic approach to identifying, analyzing, controlling, and monitoring risks throughout your medical device lifecycle, defining risk acceptance criteria, responsibilities, and processes that ensure compliance with ISO 14971 and regulatory requirements.
## Why is a Risk Management Plan Important?
A comprehensive Risk Management Plan provides the **regulatory framework** for systematic risk management throughout your device development and lifecycle. Without a structured plan, risk management becomes reactive and inconsistent, leading to **missed hazards**, **inadequate controls**, and **regulatory compliance failures** that can prevent market approval and compromise patient safety.
This plan transforms abstract risk management requirements into **concrete processes and criteria** that guide your team through critical activities like hazard identification, risk assessment, and control implementation. It establishes clear **risk acceptance criteria** that enable consistent decision-making about what risks are acceptable and what require additional controls.
For medical device development, the plan serves as your **risk management roadmap** by defining how you'll systematically address safety throughout the device lifecycle. It demonstrates to regulatory authorities that your organization has established appropriate processes for managing risks and ensures that risk management activities are integrated with design controls and quality management systems.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), the FDA requires:
* **Documented risk management processes** as part of design controls
* **Risk analysis** during design and development activities
* **Risk control measures** implemented through design requirements
* **Risk management file** maintained throughout device lifecycle
* **Design review** of risk management activities and outcomes
The FDA recognizes **ISO 14971:2019** as the consensus standard for medical device risk management, requiring:
* Risk management plan defining scope, responsibilities, and criteria
* Systematic risk analysis and evaluation processes
* Risk control implementation and verification
* Post-market risk monitoring and review
* Benefit-risk analysis for overall residual risk evaluation
**Special attention required for:**
* Software risk management per IEC 62304 must be integrated with overall device risk management
* Cybersecurity risks require ongoing assessment and control per FDA cybersecurity guidance
* Combination devices need coordinated risk management across hardware and software components
* Post-market surveillance must feed back into risk management file updates
Under **EU MDR 2017/745**, risk management must comply with:
* **Annex I GSPR 3** requiring risk management throughout device lifecycle
* **EN ISO 14971:2019** as harmonized standard for risk management processes
* **Annex II Section 4** requiring risk management documentation in technical file
* **Article 10.3** requiring risk-benefit analysis for device classification
Key MDR requirements include:
* Risk management plan covering entire device lifecycle
* Clinical evaluation integration with risk management
* Post-market surveillance feeding risk management updates
* Person Responsible for Regulatory Compliance (PRRC) oversight
* Notified body assessment of risk management processes
**Special attention required for:**
* Clinical evidence requirements may be driven by risk management outcomes and benefit-risk analysis
* Post-market clinical follow-up (PMCF) must address risks identified in risk management file
* Unique Device Identification (UDI) changes may be triggered by significant risk management updates
* Vigilance reporting requirements must be coordinated with risk management processes
## Guide
Your Risk Management Plan must establish a comprehensive framework that defines how your organization will systematically manage risks throughout the medical device lifecycle.
### Scope and Objectives Definition
Begin by clearly defining the **scope of your risk management activities**. Identify which device components, software modules, and lifecycle phases are covered by the plan. Document the intended use, user population, and use environment that will influence risk identification and assessment.
Establish **risk management objectives** that align with your organization's safety goals and regulatory requirements. Define how risk management will integrate with design controls, quality management, and post-market surveillance activities. Ensure objectives address both individual risk acceptability and overall residual risk evaluation.
### Risk Policy and Acceptance Criteria
Develop your **organizational risk policy** that establishes the framework for risk acceptability decisions. Define the principles that will guide risk management activities, including commitment to reducing risks as far as possible (AFAP) and prioritizing risk control measures appropriately.
Create **risk acceptance criteria** using a structured risk matrix that combines probability and severity assessments. Define severity categories from negligible to catastrophic based on potential harm to users and patients. Establish probability categories that reflect realistic occurrence rates for your device type and use environment.
### Risk Assessment Methodology
Define your **risk analysis process** following ISO 14971 requirements. Establish methods for hazard identification including preliminary hazard analysis, failure mode analysis, and use-related risk analysis. Document how you'll link hazards to hazardous situations and potential harms.
Specify **risk evaluation procedures** that use your risk acceptance matrix to determine if risks are acceptable, require reduction as far as possible, or are unacceptable. Define how you'll handle situations where probability cannot be estimated and establish criteria for benefit-risk analysis when residual risks remain unacceptable.
### Risk Control Strategy
Establish **risk control priorities** following the ISO 14971 hierarchy: inherent safety by design, protective measures, and information for safety. Define how risk controls will be implemented as design requirements, protective features, or user information and training.
Document **verification requirements** for risk control measures including testing methods, acceptance criteria, and documentation standards. Establish procedures for assessing whether risk controls introduce new risks and how those will be evaluated and controlled.
### Responsibilities and Authorities
Define **team roles and responsibilities** for risk management activities. Assign responsibility for risk management plan development, risk assessment conduct, risk control implementation, and risk management file maintenance. Establish review and approval authorities for risk management decisions.
Document **competency requirements** for personnel involved in risk management activities. Define training needs and establish procedures for ensuring team members have appropriate knowledge of risk management principles, device technology, and regulatory requirements.
### Risk Management File Structure
Establish **documentation requirements** for your risk management file including required documents, version control procedures, and traceability requirements. Define how risk management records will be organized and maintained throughout the device lifecycle.
Specify **review and update procedures** for risk management documentation including triggers for updates, review frequencies, and approval processes. Establish procedures for incorporating post-market information into risk management file updates.
### Integration with Development Processes
Define how **risk management integrates with design controls** including when risk assessments will be conducted, how risk controls become design requirements, and how verification activities will confirm risk control effectiveness.
Establish **change control procedures** that ensure design changes are evaluated for risk impact and that risk management documentation is updated appropriately. Define how risk management will inform design review decisions and release criteria.
### Post-Market Risk Management
Document **post-market surveillance integration** including how complaint data, adverse event reports, and clinical feedback will be evaluated for risk management implications. Establish procedures for updating risk assessments based on real-world experience.
Define **production and post-production information** collection and evaluation procedures. Establish criteria for determining when post-market information requires risk management file updates or additional risk control measures.
## Example
**Scenario:** You're developing a wearable stress monitoring device that collects physiological data and provides stress management recommendations. The device includes hardware sensors, firmware, mobile app software, and cloud services. Risk management must address both technical failures and clinical use risks.
### Risk Management Plan
**ID:** RMP-StressWear-2024-001
**1. Scope and Objectives**
This Risk Management Plan applies to the StressWear Stress Monitoring System including:
* Wearable hardware device with physiological sensors
* Device firmware and embedded software
* Mobile application (iOS/Android)
* Cloud-based data processing and storage services
* User interface and recommendation algorithms
**Objectives:**
* Systematically identify and control all foreseeable risks throughout device lifecycle
* Ensure compliance with ISO 14971:2019, FDA design controls, and EU MDR requirements
* Integrate risk management with design controls and quality management processes
* Establish clear criteria for risk acceptability and benefit-risk evaluation
* Maintain comprehensive risk management file with appropriate traceability
**2. Risk Policy**
StressWear is committed to reducing risks as far as possible (AFAP) without adversely affecting the benefit-risk ratio. Risk control measures will be prioritized as follows:
1. **Inherent safety by design** - Eliminate hazards through design choices
2. **Protective measures** - Implement safeguards in device or processes
3. **Information for safety** - Provide warnings, training, and user guidance
All identified risks must be evaluated against established acceptance criteria. Unacceptable risks require additional control measures or benefit-risk justification through clinical evaluation.
**3. Risk Acceptance Criteria**
**Severity Categories:**
* **S1 (Negligible):** Inconvenience or temporary discomfort
* **S2 (Minor):** Temporary injury not requiring medical intervention
* **S3 (Serious):** Injury requiring medical or surgical intervention
* **S4 (Critical):** Permanent impairment or irreversible injury
* **S5 (Catastrophic):** Death
**Probability Categories:**
* **P1 (Improbable):** 1 in 1,000,000 uses
* **P2 (Remote):** 1 in 100,000 uses
* **P3 (Occasional):** 1 in 10,000 uses
* **P4 (Probable):** 1 in 1,000 uses
* **P5 (Frequent):** 1 in 100 uses
**Risk Acceptance Matrix:**
| Probability | S1 | S2 | S3 | S4 | S5 |
| ----------- | ----------- | ------------ | ------------ | ------------ | ------------ |
| P1 | Acceptable | Acceptable | Acceptable | Reduce AFAP | Unacceptable |
| P2 | Acceptable | Acceptable | Reduce AFAP | Reduce AFAP | Unacceptable |
| P3 | Acceptable | Reduce AFAP | Reduce AFAP | Unacceptable | Unacceptable |
| P4 | Reduce AFAP | Reduce AFAP | Unacceptable | Unacceptable | Unacceptable |
| P5 | Reduce AFAP | Unacceptable | Unacceptable | Unacceptable | Unacceptable |
**4. Risk Assessment Process**
**Hazard Identification Methods:**
* Preliminary Hazard Analysis (PHA) for system-level hazards
* Failure Mode and Effects Analysis (FMEA) for component failures
* Use-related risk analysis per IEC 62366-1
* Software hazard analysis per IEC 62304
* Cybersecurity risk assessment per FDA guidance
**Risk Analysis Process:**
1. Identify hazards associated with device components and use
2. Link hazards to hazardous situations and potential harms
3. Estimate probability of hazardous situation occurrence (P1)
4. Estimate probability of harm given hazardous situation (P2)
5. Calculate overall probability (P1 × P2) and assign probability category
6. Estimate severity of potential harm and assign severity category
7. Determine risk acceptability using risk acceptance matrix
**5. Risk Control Implementation**
**Design Controls Integration:**
* Risk controls implemented as design requirements in Software Requirements List
* Hardware risk controls specified in Hardware Design Requirements
* User interface risk controls addressed in Usability Engineering activities
* Information for safety included in Instructions for Use and user training
**Verification Requirements:**
* Risk control effectiveness verified through appropriate testing methods
* Verification results documented in verification and validation reports
* New risks from risk controls evaluated and controlled appropriately
**6. Responsibilities**
| Role | Responsibilities |
| -------------------- | ----------------------------------------------------------------------- |
| **Quality Manager** | Risk management plan approval, process oversight, regulatory compliance |
| **Product Manager** | Risk assessment participation, user needs input, clinical context |
| **Software Lead** | Software risk analysis, IEC 62304 compliance, cybersecurity risks |
| **Hardware Lead** | Hardware risk analysis, component failure modes, environmental risks |
| **Clinical Advisor** | Clinical risk evaluation, benefit-risk analysis, use-related risks |
**7. Risk Management File**
**Required Documents:**
* Risk Management Plan (this document)
* Risk Assessment with risk analysis tables
* Risk Management Report summarizing activities and conclusions
* Risk control verification records
* Post-market risk evaluation records
**Review and Update Triggers:**
* Design changes affecting safety
* New hazards identified during development or post-market
* Risk control effectiveness issues
* Regulatory guidance updates
* Annual management review
**8. Post-Market Risk Management**
**Information Sources:**
* Customer complaints and feedback
* Technical support incident reports
* Clinical data from real-world use
* Cybersecurity threat intelligence
* Regulatory adverse event databases
**Evaluation Process:**
* Monthly review of post-market information for risk implications
* Quarterly risk management file updates as needed
* Annual comprehensive risk management review
* Immediate evaluation for serious safety issues
## Q\&A
Risk acceptance criteria should reflect your **device's intended use, user population, and clinical context**. Consider the baseline risks your users face from their medical condition and alternative treatments. For monitoring devices, temporary discomfort may be acceptable while serious injury is not. For therapeutic devices, higher risks may be acceptable if benefits are significant. Review similar devices, clinical literature, and regulatory guidance to establish appropriate severity and probability thresholds. When in doubt, choose more conservative criteria that can be refined based on clinical evidence.
Define **specific roles and decision-making authorities** rather than generic responsibilities. Identify who conducts risk assessments, who approves risk acceptance decisions, and who has authority to implement risk controls. Include competency requirements and training needs for each role. For small teams, individuals may have multiple roles, but ensure clear accountability for each risk management activity. Document backup responsibilities and escalation procedures for risk management decisions that exceed normal authority levels.
Adapt risk management activities to **agile sprint cycles** while maintaining ISO 14971 compliance. Conduct initial risk assessment during sprint planning and update risks during sprint reviews. Use risk-based criteria for sprint prioritization and feature acceptance. Maintain living risk documentation that evolves with each sprint rather than waiting for formal milestones. Ensure risk controls are implemented as user stories or acceptance criteria. Conduct risk reviews during retrospectives to identify process improvements.
Update the risk management plan when **fundamental assumptions change** about your device, users, or regulatory requirements. Common triggers include scope changes, new regulatory guidance, significant design changes, or post-market information that affects risk assessment approaches. Minor updates to risk acceptance criteria or responsibilities may not require full plan revision. Document all changes with rationale and ensure team training on updated procedures. Maintain version control and traceability for all plan changes.
Use **qualitative risk assessment methods** when quantitative data is unavailable. Establish qualitative probability categories (very low, low, medium, high, very high) with clear definitions based on available evidence. Consider worst-case scenarios and use expert judgment from clinical advisors. Document assumptions and uncertainty in risk estimates. Plan for additional data collection through clinical evaluation or post-market surveillance to refine risk estimates over time. Focus on implementing robust risk controls regardless of probability uncertainty.
**Risk management informs clinical evaluation** by identifying risks that require clinical evidence to demonstrate acceptability. Clinical evaluation provides evidence for benefit-risk analysis when residual risks remain unacceptable after control measures. Clinical data can refine risk probability estimates and validate risk control effectiveness. Post-market clinical follow-up should monitor risks identified in risk management. Ensure coordination between risk management and clinical evaluation teams to maintain consistency in risk-benefit conclusions.
# Risk Management Report
Source: https://docs.withdovetail.com/tasks/risk-management-report
Summarize risk management activities demonstrating successful hazard control and regulatory compliance achievement.
## Summary
The Risk Management Report summarizes all risk management activities conducted during your medical device development, demonstrating that your Risk Management Plan was executed successfully and that all identified risks have been appropriately controlled or mitigated.
## Why is Risk Management Report important?
The Risk Management Report serves as the final checkpoint in your risk management process, providing regulatory authorities with evidence that you have systematically identified, analyzed, and controlled all foreseeable risks associated with your medical device. This document is crucial because it demonstrates that your device's benefits outweigh its residual risks and that you have implemented appropriate risk controls to ensure patient safety. Without a comprehensive Risk Management Report, you cannot demonstrate regulatory compliance or justify that your device is safe for market release.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **FDA Guidance on Risk Management**:
* Risk management activities must be **documented** throughout the device lifecycle
* Risk analysis must be conducted according to **recognized standards** (ISO 14971)
* **Benefit-risk assessment** must demonstrate that benefits outweigh residual risks
* Risk management file must be maintained and **updated** throughout device lifecycle
**Special attention required for:**
* Software medical devices requiring additional cybersecurity risk considerations
* Combination products requiring coordination between device and drug risk assessments
* Class III devices requiring more extensive risk documentation
* Post-market risk management updates for 510(k) modifications
Under **EU MDR 2017/745** and **EN ISO 14971:2019**:
* Risk management must be **integrated** into quality management system (Article 10(9))
* Risk management file must be part of **technical documentation** (Annex II)
* **Benefit-risk analysis** must be documented in clinical evaluation (Article 61)
* Post-market surveillance must include **risk management updates** (Article 83)
**Special attention required for:**
* Clinical evaluation integration with risk management outcomes
* Post-market clinical follow-up (PMCF) risk data incorporation
* Notified body assessment of risk management completeness
* Unique Device Identification (UDI) traceability for risk-related incidents
## Guide
Your Risk Management Report must demonstrate that you have successfully executed your Risk Management Plan and that all identified risks are appropriately controlled. The report should provide a comprehensive overview of your risk management activities and their outcomes.
### Risk Analysis Summary
Document the scope and results of your risk analysis activities. Your **risk-analysis-results** table should automatically populate with data from your Risk Assessment, showing the total number of risks identified, types of risks found, and how many were initially acceptable versus unacceptable. This provides regulators with a clear picture of the comprehensiveness of your risk analysis.
### Risk Control Implementation
Detail the risk control measures you implemented for any unacceptable risks. Your **risk-controls-results** table should categorize your risk controls according to the three-tier hierarchy: inherent safety by design (most preferred), protective measures (second choice), and information for safety (least preferred). Document how many controls you implemented in each category and their effectiveness.
### Overall Residual Risk Assessment
Provide a clear statement about your device's **overall-residual-risk** after all risk controls have been implemented. If any risks remain unacceptable after risk controls, they must be explicitly identified and justified through benefit-risk analysis. Most devices should achieve acceptable overall residual risk through proper risk control implementation.
### Benefit-Risk Integration
Reference how your risk management outcomes integrate with your clinical evaluation. The clinical evaluation should demonstrate that your device's clinical benefits outweigh any residual risks, particularly for any risks that remain unacceptable after risk controls.
### Production and Post-Production Risk Management
Establish clear processes for ongoing risk management throughout your device lifecycle. Reference your relevant SOPs that address how new risks identified during production or post-market surveillance will be incorporated into your risk management file and trigger updates to your risk assessment.
## Example
**Scenario:** You develop a mobile health app that monitors blood glucose levels and provides dosing recommendations. During risk analysis, you identify 15 total risks including data security breaches, incorrect dosing calculations, and device connectivity failures. Initially, 8 risks are acceptable and 7 are unacceptable. You implement risk controls including data encryption (inherent safety), user authentication (protective measures), and warning messages (information for safety). After controls, only 1 risk remains unacceptable but is justified through clinical benefit analysis.
### Risk Management Report
**ID:** RMR-001
**1. Scope**
The Risk Management Report contains the output and summary of risk management activities for the risk management file. The procedures used for the risk assessment and risk management file in general are captured in the Risk Management Plan and the risk management report is a review that the risk management plan has been executed successfully.
Additional information related to the implementation of risk controls and processes related to product development and risk procedures are found in the SOP Integrated Software Development.
**2. Relevant Documents**
* SOP Integrated Software Development
* Risk Management Plan
* Risk Assessment
* Software Requirements List
* Software System Test Plan
* User Needs List
**3. Risk Analysis**
The risk analysis is captured in the Risk Assessment and was conducted according to the Risk Management Plan.
The following table provides information regarding the data included in the risk analysis performed as part of the risk assessment.
| Criteria | Data |
| --------------------------------------------------- | ---------------------------------------------------------- |
| Number of Risks | 15 |
| Risk types identified | Data Security, Calculation Error, Connectivity, User Error |
| Number of Acceptable Risks | 8 |
| Number of Unacceptable Risks Prior to Risk Controls | 7 |
| Number of Unacceptable Risks After Risk Controls | 1 |
**4. Risk Control Measures**
Risks were reduced as far as possible (AFAP). If a risk was classified as "unacceptable" based on the Risk Matrix, risk control measures were implemented.
The following categories of risk control measures were implemented in priority as listed below:
1. Inherent safety by design
2. Protective measures
3. Information for safety
The table below provides data regarding risk control measures implemented.
| Criteria | Data |
| ----------------------------------------- | ---- |
| Number of Inherent Safety Controls | 3 |
| Number of Protective Measures | 2 |
| Number of Information for Safety Controls | 2 |
| Total Risk Controls Implemented | 7 |
**5. Overall Residual Risk**
Following implementation of risk controls, the overall residual risk is acceptable. One risk (incorrect dosing calculation due to extreme user input values) remains unacceptable but is outweighed by the clinical benefits of improved glucose monitoring and dosing accuracy for the majority of use cases, as demonstrated in the clinical evaluation report.
**6. Benefit-Risk Assessment**
The benefit-risk assessment of the product is described in the clinical evaluation and takes into account the overall residual risk of the product evaluated through the risk assessment process. All unacceptable risks, if any, will be identified and compared against the benefits of the product in the clinical evaluation report to determine the overall benefit-risk ratio.
**7. Production and Post-Production Risks**
There has been established a process for the identification and analyzation of potential risks during production and post-production for the medical device. These processes are captured in the following documents:
* SOP Integrated Software Development
* SOP Feedback and Complaints Management
* SOP Clinical Evaluation
* SOP Problem Resolution
Risks identified during this processes can serve as inputs to the risk management file and may require review of the risk assessment following incorporation of the new risks.
## Q\&A
Add more serious risks, particularly around psychological stress, and consider adding "personal harm" as a risk category. Make risk descriptions specific and create test scenarios for each risk to ensure comprehensive coverage.
If a new risk is identified during the vigilance database review, it should be added to the risk assessment to ensure all foreseeable risks are accounted for. Update your Risk Management Report accordingly.
Cover all obvious foreseeable risks comprehensively. If there are things that are very unlikely to happen or are not thought of, that's acceptable. Auditors look for a robust list of foreseeable risks. If something is missed, a minor update can be done later.
It is recommended to categorize at least one component as medium risk to demonstrate risk assessment, even if the software is generally low risk. This shows you have properly considered the risk spectrum.
Any risks that remain unacceptable after implementing risk controls must be explicitly documented in the Overall Residual Risk section and justified through benefit-risk analysis in your clinical evaluation. The clinical benefits must clearly outweigh these residual risks.
# Shelf Life Verification Guide
Source: https://docs.withdovetail.com/tasks/shelf-life-verification-guide
Plan systematic aging studies validating device stability and performance throughout storage periods.
## Summary
The Shelf Life Verification Guide provides a **structured approach** to determine and validate your medical device's shelf life through systematic testing under real-time and accelerated aging conditions. This guide ensures your device maintains its intended functionality, performance, and safety throughout its labeled shelf life period.
## Why is Shelf Life Verification important?
Shelf life verification is critical because medical devices must maintain their **safety and effectiveness** throughout their entire storage period before use. Degradation during storage can compromise device performance, introduce safety risks, or render the device ineffective when patients need it most.
This verification provides **scientific evidence** to support your shelf life claims on device labeling and regulatory submissions. Without proper shelf life validation, you risk premature device failures, regulatory non-compliance, or liability issues if devices fail to perform as expected after storage. The testing also helps optimize packaging design and storage conditions to maximize device stability.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **FDA Guidance Documents**:
* **Design validation** must demonstrate devices meet user needs throughout shelf life
* **ASTM F1980** provides standard practice for accelerated aging of sterile barrier systems
* **Shelf life claims** must be supported by appropriate stability data
* **Package integrity** must be maintained throughout claimed shelf life
**Special attention required for:**
* Sterile device packaging validation per ISO 11607 standards
* Software devices with time-limited licenses or certificates
* Combination products with drug or biologic components
* Devices with batteries or electronic components subject to degradation
Under **EU MDR 2017/745** and supporting standards:
* **Annex I, Section 10.3** requires appropriate shelf life determination
* Must comply with **ISO 11607-1** for packaging of terminally sterilized devices
* **ASTM F1980** standard for accelerated aging protocols
* **Essential requirements** must be maintained throughout shelf life
**Special attention required for:**
* Clinical evaluation integration for devices with performance claims over time
* Post-market surveillance of shelf life performance in real-world conditions
* Notified body assessment of shelf life validation data
* Unique Device Identification (UDI) considerations for shelf life labeling
## Guide
### Understanding Shelf Life Testing Approaches
Shelf life verification uses **two complementary approaches**: real-time aging and accelerated aging. Real-time aging provides definitive evidence by storing devices under normal conditions for the full claimed shelf life. Accelerated aging uses elevated temperatures to simulate long-term aging in shorter timeframes, allowing earlier market entry while real-time studies continue.
**Real-time aging** is the gold standard but requires long study durations. Plan real-time studies early in development to ensure data availability for regulatory submissions. Real-time data ultimately validates accelerated aging predictions and provides the most convincing evidence of shelf life claims.
**Accelerated aging** uses the Arrhenius model to predict long-term stability from short-term elevated temperature studies. This approach assumes that chemical and physical degradation processes follow predictable temperature-dependent kinetics.
### Calculating Accelerated Aging Parameters
The **Accelerated Aging Factor (AAF)** determines how much faster aging occurs at elevated temperatures compared to normal storage conditions. Use the formula: AAF = Q₁₀^((TAA - TRT) / 10), where TAA is accelerated aging temperature, TRT is real-time temperature, and Q₁₀ is the reaction rate factor (typically 2).
**Temperature selection** should be high enough to accelerate aging but not so high as to introduce unrealistic failure modes. Common accelerated aging temperatures are 40°C, 50°C, or 55°C, depending on device materials and packaging.
**Study duration** equals your claimed shelf life divided by the AAF. For example, a 2-year shelf life with an AAF of 8 requires approximately 3 months of accelerated aging. Include additional time for testing and analysis.
### Defining Test Outcomes and Acceptance Criteria
Your test plan must specify **what attributes will be measured** after aging to determine if the device remains acceptable for use. Focus on attributes that could affect safety, effectiveness, or usability.
**Functional testing** verifies that core device functions remain within specifications. Test the same parameters you would test for initial device verification, ensuring performance hasn't degraded below acceptable levels.
**Physical integrity testing** examines packaging seals, material properties, and structural integrity. Look for signs of degradation like discoloration, brittleness, seal failures, or dimensional changes that could affect device performance.
**Sterility maintenance** is critical for sterile devices. Test package integrity using appropriate methods like bubble emission testing, dye penetration, or microbial challenge testing to ensure sterile barriers remain intact.
**Labeling durability** ensures critical information remains legible throughout shelf life. Test label adhesion, print quality, and barcode readability, especially for devices stored in challenging environments.
### Planning Test Sample Management
**Sample size determination** should consider statistical requirements for demonstrating shelf life with appropriate confidence levels. Larger sample sizes provide more statistical power but increase testing costs. Consider the criticality of shelf life claims and regulatory expectations for your device class.
**Sample selection** should represent your commercial manufacturing process and packaging configuration. Use devices manufactured using validated processes and materials identical to commercial production.
**Storage conditions** for both real-time and accelerated aging should be controlled and monitored. Document temperature, humidity, and other environmental conditions throughout the study. Use calibrated monitoring equipment and maintain detailed records.
### Integrating with Overall V\&V Strategy
Shelf life verification should be **coordinated with other verification activities** to optimize resource utilization and timeline efficiency. Some verification testing can be performed on aged samples to simultaneously demonstrate both initial performance and shelf life maintenance.
**Packaging verification** often overlaps with shelf life testing, as both evaluate package integrity and protection. Coordinate these activities to avoid duplication while ensuring comprehensive coverage.
**Risk management integration** ensures that shelf life testing addresses identified risks related to device degradation over time. Use your risk analysis to prioritize which attributes are most critical to test after aging.
## Example
**Scenario**: You are developing a disposable blood glucose test strip with a claimed 18-month shelf life. The strips are individually packaged in foil pouches and stored at room temperature. Key performance attributes include measurement accuracy, strip integrity, and package seal integrity.
Your shelf life verification plan includes accelerated aging at 50°C for 8 weeks (AAF = 4, simulating 8 months) and real-time aging at 25°C for the full 18 months. Test outcomes include glucose measurement accuracy compared to reference standards, visual inspection for physical degradation, package seal integrity testing, and label durability assessment.
### Shelf Life Verification Guide
**Document ID**: SLVG-001\
**Version**: 1.0
#### 1. Purpose
To investigate the integrity of the GlucoStrip blood glucose test strips and packaging under real-time and accelerated storage conditions to validate the claimed 18-month shelf life.
#### 2. Scope
Applies to GlucoStrip test strips in final commercial packaging configuration stored under ambient conditions (15-30°C, 10-75% RH).
#### 3. Test Outcomes
| Tested Attribute | Test Method | Acceptance Criteria |
| ---------------------------- | ----------------------------------- | ------------------------------------------- |
| Glucose Measurement Accuracy | ISO 15197:2013 accuracy testing | Within ±15% or ±15 mg/dL of reference value |
| Strip Physical Integrity | Visual inspection and handling test | No cracks, delamination, or color changes |
| Package Seal Integrity | Bubble emission test per ASTM F2096 | No bubble emission indicating seal failure |
| Label Durability | Visual inspection and barcode scan | All text legible, barcode scannable |
| Reagent Activity | Enzymatic activity assay | ≥90% of initial activity level |
#### 4. Accelerated Aging Protocol
**Temperature**: 50°C ± 2°C\
**Humidity**: 75% ± 5% RH\
**Duration**: 8 weeks\
**AAF Calculation**: Q₁₀ = 2, TAA = 50°C, TRT = 25°C\
AAF = 2^((50-25)/10) = 2^2.5 = 5.66\
**Equivalent Real-Time**: 8 weeks × 5.66 = 45 weeks (\~11 months)
**Sample Size**: 30 strips per test timepoint\
**Test Timepoints**: 0, 4, and 8 weeks\
**Storage**: Environmental chamber with continuous monitoring
#### 5. Real-Time Aging Protocol
**Conditions**: 25°C ± 2°C, 60% ± 10% RH\
**Duration**: 18 months\
**Sample Size**: 30 strips per test timepoint\
**Test Timepoints**: 0, 6, 12, and 18 months\
**Storage**: Controlled storage room with daily monitoring
#### 6. Test Execution
**Sample Preparation**: Use strips from three different manufacturing lots to represent process variability. Store samples in original packaging configuration.
**Environmental Monitoring**: Record temperature and humidity every 15 minutes using calibrated data loggers. Investigate any excursions outside specified ranges.
**Testing Schedule**:
* Week 0: Baseline testing on fresh samples
* Week 4: Interim accelerated aging testing
* Week 8: Final accelerated aging testing
* Month 6, 12, 18: Real-time aging testing
#### 7. Acceptance Criteria
* All test outcomes must meet specified acceptance criteria at all timepoints
* No statistically significant degradation trends that would compromise safety or effectiveness
* Package integrity maintained throughout study duration
* Results support claimed 18-month shelf life with appropriate safety margin
## Q\&A
Select a temperature high enough to accelerate aging but not so high as to introduce unrealistic failure modes. Common temperatures are 40°C, 50°C, or 55°C. Consider your device materials and packaging - polymers may degrade differently at very high temperatures than they would during normal aging. If uncertain, conduct preliminary studies at multiple temperatures to validate your Arrhenius model assumptions.
Discrepancies between accelerated and real-time aging suggest that the Arrhenius model may not accurately predict your device's aging behavior. This could indicate different degradation mechanisms at elevated temperatures or non-linear aging kinetics. In such cases, rely on real-time data for shelf life claims and use accelerated aging only for screening purposes. Consider adjusting your accelerated aging protocol or Q₁₀ value based on the observed correlation.
Sample size depends on the variability of your test methods, the magnitude of change you need to detect, and your desired statistical confidence level. A minimum of 10 samples per timepoint is often used, but 20-30 samples provide better statistical power. Consider the cost of testing versus the risk of insufficient data. For critical safety attributes, use larger sample sizes to ensure adequate statistical power.
Yes, accelerated aging data can support initial shelf life claims for market entry, but you should continue real-time studies to confirm these claims. Many regulatory agencies accept accelerated aging data with the understanding that real-time data will be provided later. Be conservative in your initial shelf life claims and consider including a safety margin to account for potential differences between accelerated and real-time aging.
Use storage conditions that represent typical storage environments for your device. Standard conditions are often 25°C ± 2°C and 60% ± 10% relative humidity, but consider your device's intended storage environment. If devices will be stored in challenging conditions (high temperature, humidity, or light exposure), include these conditions in your testing. Document and justify your chosen conditions based on intended use and storage requirements.
Test failures should be investigated to determine if they represent true shelf life limitations or testing artifacts. Consider whether failures are related to the aging process or other factors like manufacturing variability or test method issues. If failures are aging-related, you may need to reduce your shelf life claim or improve your packaging/formulation. Document all failures and their investigation in your shelf life report.
# Software Architecture
Source: https://docs.withdovetail.com/tasks/software-architecture
Define software structure, organization and components following safety classification and development standards.
## Summary
The Software Architecture document defines the structure and organization of your medical device software according to IEC 62304 standards. It identifies software items, their interconnections, security measures, and deployment requirements, providing the foundation for software development and verification activities.
## Why is Software Architecture important?
Software architecture documentation is **mandatory** under IEC 62304 for medical device software development. It provides the blueprint that guides your development team and demonstrates to regulators that your software is **systematically designed** and **properly structured**. The architecture ensures that all software components work together safely and effectively to deliver the intended medical functionality.
Without proper architecture documentation, you cannot demonstrate that your software design is appropriate for its intended use, that risks have been properly considered, or that verification activities will be comprehensive. The architecture also serves as the foundation for change control and maintenance throughout the product lifecycle.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **FDA Software as Medical Device Guidance**:
* Software architecture must be **documented** as part of design inputs
* Must demonstrate **systematic software development** approach
* Architecture must support **verification and validation** activities
* **Cybersecurity considerations** must be integrated into architecture design
**Special attention required for:**
* Software as Medical Device (SaMD) classification and risk categorization
* Cybersecurity framework implementation per FDA guidance
* Software lifecycle processes documentation
* Third-party software (SOUP) integration and risk assessment
Under **EU MDR 2017/745** and **IEC 62304:2006**:
* Must comply with **IEC 62304** software lifecycle processes
* Architecture must support **software safety classification**
* **Risk management** integration per ISO 14971 is mandatory
* Must demonstrate **systematic approach** to software development
**Special attention required for:**
* Software safety classification (Class A, B, or C) impacts architecture requirements
* SOUP (Software of Unknown Provenance) documentation and risk assessment
* Cybersecurity requirements per MDR Article 17 and standards
* Data protection and privacy considerations (GDPR compliance)
## Guide
### Understanding Software Architecture
Software architecture defines the **high-level structure** of your medical device software. It identifies software items (components), their relationships, and how they work together to deliver medical functionality. The architecture should be detailed enough for auditors to understand your software organization but high-level enough to remain stable throughout development.
### Software Items and Decomposition
According to IEC 62304, your software system consists of:
* **Software System**: The complete integrated collection of software items
* **Software Items**: Identifiable parts of the software that can be separately developed and tested
* **Software Units**: The lowest level components that are not further decomposed
Structure your software items logically based on functionality, not just technical implementation. Common software items include:
* **Frontend/User Interface**: Components that users interact with directly
* **Backend/Processing Engine**: Core logic and data processing components
* **Database/Storage**: Data persistence and retrieval components
* **Communication/Interface**: Components that handle external communications
* **Medical Algorithm**: Core medical functionality and calculations
### Software Connections and Deployment
Document how your software items connect and communicate:
* **Infrastructure**: Where each software item is deployed (cloud services, local hardware, mobile devices)
* **Hardware Requirements**: Minimum specifications needed for each component
* **Operating Systems**: Supported platforms and versions
* **Connections**: Data flow and communication between software items
This information is crucial for **risk assessment**, **verification planning**, and **cybersecurity analysis**.
### Security and Data Protection
Your architecture must address:
* **Encryption**: How sensitive data is protected in transit and at rest
* **Authentication**: User verification and access control mechanisms
* **Data Security**: Protection of patient health information
* **Network Security**: Secure communication protocols and network protection
### Backup and Data Integrity
Document your approach to:
* **Data Backup**: Frequency, location, and methods for data backup
* **Recovery Procedures**: How data can be restored in case of failure
* **Data Integrity**: Measures to ensure data accuracy and completeness
* **Business Continuity**: How the system maintains availability
### Minimum System Requirements
Specify the minimum requirements for end-user systems:
* **Hardware**: CPU, memory, storage, and connectivity requirements
* **Software**: Operating system versions, browser requirements, runtime environments
* **Network**: Bandwidth, connectivity, and protocol requirements
* **Peripherals**: Any required external devices or accessories
## Example
**Scenario**: You're developing a remote patient monitoring system that collects vital signs data from wearable devices and provides analysis to healthcare providers. Your system needs to handle real-time data processing, secure storage, and clinical decision support.
### Software Items Table
| Software Item | Description | Programming Language (Version) | Framework (Version) |
| ---------------------- | -------------------------------------------------------- | ------------------------------ | -------------------------------- |
| Mobile App | Patient interface for data viewing and device pairing | Swift (5.8), Kotlin (1.8) | iOS SDK (16.0), Android SDK (33) |
| Web Dashboard | Clinician interface for patient monitoring and alerts | TypeScript (5.0) | React (18.2), Node.js (18.16) |
| Data Processing Engine | Real-time vital signs analysis and alert generation | Python (3.11) | FastAPI (0.100), NumPy (1.24) |
| Database System | Secure storage of patient data and clinical records | SQL | PostgreSQL (15.3) |
| Device Gateway | Communication interface with wearable monitoring devices | C++ (17) | Embedded Linux, Bluetooth LE |
### Software Connections Table
| Software Item | Infrastructure | Hardware Requirements | Operating System | Connections |
| ---------------------- | -------------- | ---------------------- | -------------------- | ------------------------------------------ |
| Mobile App | User devices | 2GB RAM, 1GB storage | iOS 14+, Android 10+ | Data Processing Engine, Device Gateway |
| Web Dashboard | AWS Cloud | 4GB RAM, 2 vCPU | Ubuntu 22.04 LTS | Data Processing Engine, Database System |
| Data Processing Engine | AWS Cloud | 8GB RAM, 4 vCPU | Ubuntu 22.04 LTS | Mobile App, Web Dashboard, Database System |
| Database System | AWS RDS | 16GB RAM, 4 vCPU | PostgreSQL on Linux | Data Processing Engine |
| Device Gateway | Edge device | 1GB RAM, ARM processor | Embedded Linux | Mobile App, wearable devices |
### Security Implementation
The system implements end-to-end encryption using AES-256 for data at rest and TLS 1.3 for data in transit. Patient authentication uses OAuth 2.0 with multi-factor authentication. All API communications are secured with JWT tokens and rate limiting. Healthcare provider access is controlled through role-based permissions with audit logging of all data access.
### Backup Procedures
Patient data is automatically backed up to encrypted AWS S3 storage every 4 hours. Database snapshots are created daily and retained for 30 days. Critical system configurations are version-controlled and backed up to separate geographic regions. Recovery procedures can restore full system functionality within 2 hours of any component failure.
### Minimum User System Requirements
* **For Mobile App**: iOS 14.0+ or Android 10+, 2GB RAM, 1GB available storage, Bluetooth 5.0+, internet connectivity
* **For Web Dashboard**: Modern web browser (Chrome 100+, Firefox 100+, Safari 15+), 4GB RAM, broadband internet connection (5 Mbps minimum)
* **For Wearable Devices**: Bluetooth Low Energy 5.0+, compatible with iOS/Android pairing protocols
## Q\&A
The architecture should be detailed enough for auditors to understand your software organization and for developers to implement the design, but high-level enough to remain stable throughout development. Focus on software items, their responsibilities, and key interfaces rather than implementation details. Include technology versions and frameworks to demonstrate systematic approach.
Third-party software can be integrated as a medical device system module, listed as a supplier, and added to architecture documentation. Create specific subsystem requirements for third-party components and maintain your current device classification. Document all third-party software in your SOUP (Software of Unknown Provenance) list with risk assessments.
Include encryption methods for data protection during transfer and storage, authentication mechanisms, access controls, and network security measures. Document how patient data is protected, how system integrity is maintained, and how cybersecurity risks are mitigated. Consider FDA cybersecurity guidance and MDR requirements for data protection.
Clearly specify how each software item communicates with others, including data formats, communication protocols, timing requirements, and error handling. Document both internal interfaces between your software items and external interfaces with third-party systems, medical devices, or user systems.
Specify hardware requirements (CPU, memory, storage), software requirements (operating systems, browsers, runtime environments), network requirements (bandwidth, protocols), and any special peripherals or accessories. These requirements should support your intended use and user environment while ensuring reliable operation.
Your software safety classification (Class A, B, or C) determines the level of detail required in your architecture documentation. Higher classification levels require more detailed documentation of software items, interfaces, and verification approaches. The architecture must support your chosen development lifecycle and verification strategy.
# Software Development and Maintenance Plan
Source: https://docs.withdovetail.com/tasks/software-development-and-maintenance-plan
Structure comprehensive software lifecycle processes ensuring safety classification compliance and systematic development.
## Summary
The Software Development and Maintenance Plan establishes your systematic approach to creating compliant medical device software, defining the complete lifecycle from requirements through development, testing, and post-market maintenance according to IEC 62304 and regulatory standards.
## Why is a Software Development and Maintenance Plan Important?
A comprehensive Software Development and Maintenance Plan provides the **regulatory foundation** for medical device software development. Without this structured framework, software development becomes chaotic and unpredictable, leading to **documentation gaps**, **missed safety requirements**, and **regulatory compliance failures** that can prevent market approval.
This plan transforms abstract regulatory requirements into **concrete development activities** that your team can follow. It establishes critical processes like **risk-based development**, **configuration management**, and **verification activities** that ensure your software meets both user needs and safety standards. The plan also demonstrates to regulatory authorities that your development process follows recognized standards and best practices.
For medical device software, the plan serves as your **roadmap to compliance** by defining how you'll manage software safety classification, handle Software of Unknown Provenance (SOUP), and maintain traceability between requirements and implementation. This structured approach prevents costly rework and ensures your software development activities generate the documentation needed for regulatory submissions.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), the FDA requires:
* **Documented development planning** that describes design activities and responsibilities
* **Software lifecycle processes** following recognized consensus standards like IEC 62304
* **Risk-based approach** to software development with appropriate verification activities
* **Configuration management** and change control processes
* **Design History File (DHF)** documentation for all development activities
The FDA recognizes **IEC 62304:2006** as the consensus standard for medical device software lifecycle processes, requiring:
* Software safety classification (Class A, B, or C)
* Risk management integration throughout development
* SOUP management and evaluation
* Verification and validation appropriate to safety class
**Special attention required for:**
* Software safety classification accuracy - misclassification can lead to inadequate development rigor
* SOUP vulnerability management and ongoing monitoring
* Cybersecurity considerations per FDA guidance on medical device cybersecurity
* Software Bill of Materials (SBOM) for transparency in software components
Under **EU MDR 2017/745**, software development must comply with:
* **EN ISO 13485:2016** Section 7.3 for design and development planning
* **IEC 62304:2006/AMD 1:2015** for software lifecycle processes
* **EN 62366-1:2015** for usability engineering integration
* **MDCG 2019-11 Guidance** for software qualification and classification
Key MDR requirements include:
* Software safety classification determining development rigor
* Comprehensive risk management per ISO 14971
* Clinical evaluation for software medical devices
* Post-market surveillance integration
* Technical documentation per Annex II
**Special attention required for:**
* Software as Medical Device (SaMD) classification and its impact on clinical evidence requirements
* AI/ML software considerations per emerging MDCG guidance
* Cybersecurity requirements and ongoing vulnerability management
* Person Responsible for Regulatory Compliance (PRRC) oversight of software changes
## Guide
Your Software Development and Maintenance Plan must establish a comprehensive framework that addresses all aspects of medical device software development while ensuring regulatory compliance.
### Planning Foundation
Start by defining your **software scope and classification**. Identify all software components, their intended use, and determine the IEC 62304 safety classification (Class A, B, or C) based on potential harm from software failure. This classification drives the rigor required for all subsequent development activities.
Establish **team responsibilities** across functional groups. Software teams handle requirements, architecture, implementation, and testing. Quality teams oversee process compliance, risk management, and release approval. Clinical teams validate user needs and participate in usability evaluation. Document clear interfaces between these groups and their decision-making authorities.
### Development Methodology
Define your **development lifecycle model** whether waterfall, agile, or hybrid approaches. For each development stage, specify required activities, inputs, outputs, and review criteria. Medical device software typically follows a stage-gate approach with defined milestones for requirements, design, implementation, verification, and release.
Document **design and development stages** with clear entry and exit criteria. Stage 1 focuses on planning and requirements. Stage 2 covers architecture and detailed design. Stage 3 handles implementation and unit testing. Stage 4 addresses system verification and validation. Stage 5 manages release preparation and deployment.
### Configuration Management
Establish robust **version control processes** using your chosen system (GitHub, GitLab, etc.). Define branching strategies with main, development, feature, and release branches. Implement semantic versioning (MAJOR.MINOR.PATCH) with clear criteria for each change type.
Document **change management procedures** that categorize changes by impact. Major changes affecting safety or functionality require comprehensive review and may trigger UDI updates. Minor changes need standard verification. Patches for bug fixes follow expedited procedures while maintaining traceability.
### Risk Management Integration
Integrate **risk management activities** throughout development. Conduct initial risk assessment during planning, update risks during design changes, implement risk controls through software features, and verify control effectiveness through testing. Maintain traceability between identified risks and implemented controls.
### Verification and Validation Strategy
Define **testing approaches** appropriate to your software classification. Class A software requires basic verification. Class B needs comprehensive testing including integration and system testing. Class C demands the most rigorous verification including formal methods where appropriate.
Establish **verification activities** including code reviews, unit testing, integration testing, and system testing. Document test planning, execution, and results. Define criteria for test pass/fail decisions and procedures for handling defects and anomalies.
### SOUP Management
Document processes for **Software of Unknown Provenance** including identification, risk assessment, and ongoing monitoring. Classify SOUP by risk level (low, medium, high) and establish monitoring frequencies. Low-risk SOUP requires review every two years, medium-risk annually, and high-risk every six months.
### Maintenance and Post-Market Activities
Define **post-release maintenance** including bug tracking, feature enhancements, security updates, and emergency fixes. Establish procedures for incorporating post-market surveillance feedback and user complaints into software improvements.
## Example
**Scenario:** You're developing a mobile application for stress monitoring that collects physiological data and provides wellness recommendations. The app connects to a wearable device and stores data in the cloud. A software malfunction could lead to incorrect stress level readings, potentially causing user anxiety but no serious physical harm.
### Software Development and Maintenance Plan
**ID:** SDMP-StressWear-2024-001
**1. Scope**
This plan covers the StressWear mobile application (iOS/Android), cloud backend services, and device communication firmware. The software enables stress monitoring through physiological data collection and analysis, classified as IEC 62304 Class B software.
**2. Software Classification**
StressWear is classified as **Class B software** under IEC 62304. Software failure could result in incorrect stress readings leading to user anxiety or inappropriate wellness recommendations, but would not cause serious physical injury.
**3. Team Responsibilities**
* **Software Team:** Requirements documentation, architecture design, implementation, unit testing, integration testing, SOUP management, release notes
* **Quality Team:** Process oversight, verification planning, risk management review, release approval, post-market surveillance
* **Clinical Team:** User needs validation, usability testing, clinical evaluation, user feedback analysis
**4. Development Stages**
**Stage 1 - Planning:**
* Activities: User needs specification, software requirements development, risk assessment, architecture planning
* Deliverables: User Needs List, Software Requirements Document, Risk Management Plan, Software Architecture outline
* Review Criteria: Requirements traceability, risk completeness, architecture feasibility
**Stage 2 - Design and Implementation:**
* Activities: Detailed architecture, code implementation, SOUP identification, unit testing
* Deliverables: Software Architecture Document, SOUP List, implemented code, unit test reports
* Review Criteria: Architecture compliance, code quality standards, SOUP risk assessment
**Stage 3 - Verification:**
* Activities: Integration testing, system testing, anomaly documentation, usability test planning
* Deliverables: Integration test reports, system test reports, known anomalies list, usability test plan
* Review Criteria: Test coverage adequacy, requirement verification, anomaly acceptability
**Stage 4 - Validation:**
* Activities: Usability testing, clinical validation, final risk assessment
* Deliverables: Usability evaluation report, clinical validation results, updated risk assessment
* Review Criteria: User acceptance, clinical effectiveness, residual risk acceptability
**Stage 5 - Release:**
* Activities: Release preparation, final documentation review, deployment planning
* Deliverables: Release notes, release checklist, deployment guide
* Review Criteria: Documentation completeness, release readiness, deployment verification
**5. Configuration Management**
Version control managed in **GitHub** with semantic versioning:
* **MAJOR (X.0.0):** New features affecting device functionality, UDI-DI update required
* **MINOR (1.X.0):** Feature additions, backward compatible, UDI-PI update
* **PATCH (1.1.X):** Bug fixes, security updates, no UDI change required
**Branching Strategy:**
* **main:** Production releases only
* **develop:** Integration branch for features
* **feature/\*:** Individual feature development
* **hotfix/\*:** Emergency fixes from main
**6. SOUP Management**
SOUP components documented with risk classification:
* **React Native (Medium Risk):** Core framework, annual security review
* **AWS SDK (Low Risk):** Cloud services, biannual review
* **Encryption Libraries (High Risk):** Security critical, quarterly review
**7. Verification Activities**
* **Code Review:** All code reviewed by team member not involved in implementation
* **Unit Testing:** Minimum 80% code coverage for critical functions
* **Integration Testing:** API interfaces, device communication, data flow
* **System Testing:** End-to-end scenarios, performance, security
* **Usability Testing:** Task completion, error recovery, user satisfaction
**8. Risk Management**
Risk assessment updated at each stage with focus on:
* Data accuracy and reliability
* User interface clarity and error prevention
* Cybersecurity and data protection
* Device communication reliability
* Cloud service availability
**9. Maintenance Procedures**
* **Bug Reports:** Tracked in GitHub Issues with severity classification
* **Security Updates:** Emergency process for critical vulnerabilities
* **Feature Requests:** Evaluated through change control process
* **Post-Market Feedback:** Integrated into quarterly software reviews
## Q\&A
Software classification depends on the potential harm from software failure. **Class A** means no injury or damage possible (e.g., administrative software). **Class B** indicates non-serious injury possible (e.g., monitoring apps that could cause anxiety). **Class C** means death or serious injury possible (e.g., insulin dosing software). Consider the worst-case scenario if your software fails completely or provides incorrect information. When in doubt, choose the higher classification for additional safety margin.
Document all SOUP components with their **name, version, source, and functional purpose**. Include risk classification based on potential impact if the SOUP fails. For each SOUP item, specify verification approach, known anomalies, and monitoring frequency. High-risk SOUP requires quarterly review, medium-risk annual review, and low-risk biannual review. Maintain a SOUP list as a living document updated with each software release.
IEC 62304 is compatible with agile methodologies when properly structured. Map agile activities to IEC 62304 requirements - user stories become software requirements, sprints align with development activities, and retrospectives support continuous improvement. Maintain documentation incrementally rather than at the end. Use automated testing and continuous integration to support verification activities. Ensure each sprint produces appropriate documentation and that design reviews occur at logical intervals.
Maintain **software requirements**, **architecture documentation**, **verification results**, **risk management records**, and **change history**. For Class B and C software, add detailed design documentation and comprehensive test records. All documentation must be version-controlled and traceable. Keep records of design decisions, review outcomes, and rationale for changes. Documentation should be sufficient to demonstrate compliance during regulatory inspections.
Establish a **change control process** that evaluates each change for regulatory impact. Minor changes like bug fixes may require minimal documentation. Major changes affecting safety or functionality need comprehensive review including risk assessment updates, verification testing, and potential regulatory notification. Maintain change logs, assess cumulative impact of multiple changes, and ensure post-market surveillance data informs change decisions. Some changes may require notified body notification or new regulatory submissions.
**Class A software** requires basic verification that software requirements are met. **Class B software** needs comprehensive verification including unit testing, integration testing, and system testing with documented procedures and results. **Class C software** demands the most rigorous verification including formal methods where appropriate, comprehensive testing at all levels, and additional verification of safety-related functions. Higher classifications require more detailed documentation and independent review of verification activities.
# Software System Test Plan
Source: https://docs.withdovetail.com/tasks/software-system-test-plan
Define comprehensive software testing approach verifying requirements and ensuring regulatory compliance.
## Summary
The Software System Test Plan defines your **systematic approach** to verifying that your medical device software meets all specified requirements through comprehensive testing. This document establishes test procedures, acceptance criteria, and documentation standards that ensure your software functions safely and effectively before release.
## Why is Software System Test Planning important?
Software system test planning is essential because software defects in medical devices can directly impact patient safety and device effectiveness. Unlike hardware failures that are often immediately apparent, software failures can be **subtle, intermittent, or context-dependent**, making systematic testing crucial for identifying potential issues before market release.
The planning phase ensures you have **comprehensive test coverage** of all software requirements, establishes objective pass/fail criteria, and creates documentation that demonstrates regulatory compliance. Without proper test planning, you risk missing critical software defects, failing to demonstrate requirement compliance, or lacking sufficient evidence for regulatory submissions.
## Regulatory Context
Under **21 CFR Part 820.30(g)** (Design Validation) and **FDA Guidance "General Principles of Software Validation"**:
* Software testing must demonstrate that **software requirements are correctly implemented**
* Testing must cover **normal operation, boundary conditions, and error conditions**
* **IEC 62304** compliance required for medical device software lifecycle processes
* **Cybersecurity testing** per FDA premarket cybersecurity guidance for networked devices
**Special attention required for:**
* Software of Unknown Provenance (SOUP) verification and risk assessment
* Cybersecurity testing for devices with network connectivity
* Software change control and regression testing procedures
* Integration testing between software and hardware components
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* Must comply with **IEC 62304:2006+A1:2015** for medical device software lifecycle
* Software testing must demonstrate **essential requirements compliance**
* **Risk-based testing approach** aligned with ISO 14971 risk management
* **Usability testing integration** per IEC 62366-1 for user interface validation
**Special attention required for:**
* Clinical evaluation integration for software with clinical claims
* Post-market surveillance planning for software performance monitoring
* Notified body assessment of software testing completeness
* Software as Medical Device (SaMD) classification and corresponding testing rigor
## Guide
### Understanding Software System Testing Scope
Software system testing verifies that your **complete software system** meets all specified requirements when operating as an integrated whole. This differs from unit testing (individual components) and integration testing (component interactions) by focusing on **end-to-end system behavior** under realistic operating conditions.
Your test plan must address **functional requirements** (what the software does), **performance requirements** (how well it performs), **safety requirements** (how it handles errors and failures), and **usability requirements** (how users interact with it).
### Developing Test Cases from Requirements
Each software requirement must be **traceable to specific test cases** that verify the requirement is correctly implemented. Start with your system requirements and subsystem requirements to identify what needs testing.
**Functional test cases** verify that software features work as specified. For each functional requirement, create test cases that exercise normal operation, boundary conditions, and error conditions. Include both positive testing (verifying correct behavior) and negative testing (verifying proper error handling).
**Performance test cases** verify that software meets timing, throughput, and resource utilization requirements. Test under various load conditions, including peak usage scenarios and resource-constrained environments.
**Safety test cases** verify that software handles failures gracefully and maintains safety even when components fail. Test error detection, error recovery, and fail-safe behaviors identified in your risk analysis.
### Establishing Test Environments and Data
Your test plan must specify **test environments** that represent realistic operating conditions. Consider different hardware configurations, operating system versions, network conditions, and user environments your software will encounter.
**Test data management** is crucial for reproducible testing. Plan for test data that covers normal use cases, edge cases, and error conditions. For medical device software, ensure test data doesn't contain real patient information and consider using synthetic data that represents realistic clinical scenarios.
**Configuration management** ensures test environments remain stable and controlled. Document software versions, hardware configurations, and environmental conditions for each test execution.
### Defining Acceptance Criteria
Each test case requires **objective, measurable acceptance criteria** that clearly define pass/fail conditions. Avoid subjective criteria that could lead to interpretation disputes.
**Functional acceptance criteria** should specify expected outputs, behaviors, or state changes for given inputs. Include timing requirements where relevant (e.g., "response time \<2 seconds").
**Performance acceptance criteria** should specify measurable thresholds for response times, throughput, resource usage, and availability. Base these on your system requirements and user needs.
**Safety acceptance criteria** should verify that safety mechanisms function correctly and that the software fails safely when errors occur.
### Planning Test Execution and Documentation
Your test plan must specify **who executes tests**, **when tests are executed**, and **how results are documented**. Consider whether tests will be manual, automated, or a combination of both.
**Test execution sequencing** should consider dependencies between tests and optimize for efficient execution. Some tests may require specific system states or data conditions established by previous tests.
**Results documentation** must capture sufficient detail to demonstrate requirement compliance and support regulatory submissions. Plan for documenting test procedures, actual results, pass/fail determinations, and any deviations or anomalies.
### Handling Test Failures and Anomalies
Your test plan must address **how test failures are handled**. Not all test failures indicate software defects - some may result from test environment issues, incorrect test procedures, or requirement ambiguities.
**Failure investigation procedures** should determine root causes and appropriate corrective actions. Document whether failures result from software defects, test issues, or requirement clarifications.
**Regression testing** ensures that defect fixes don't introduce new problems. Plan for retesting affected functionality and related areas that might be impacted by changes.
## Example
**Scenario**: You are developing a diabetes management app that tracks blood glucose readings, calculates insulin dosing recommendations, and provides trend analysis. The app integrates with glucose meters via Bluetooth and stores data in a cloud database.
Your software system test plan covers functional testing of glucose data import, insulin calculation algorithms, and trend analysis features. Performance testing verifies app responsiveness and data synchronization times. Safety testing ensures the app handles invalid glucose readings appropriately and provides appropriate warnings for extreme values. Integration testing verifies proper communication with glucose meters and cloud services.
### Software System Test Plan
**Document ID**: SSTP-001\
**Version**: 1.0
#### 1. Purpose
This document defines the system testing approach for the DiabetesManager mobile application to verify all software requirements are correctly implemented and the system operates safely and effectively.
#### 2. Scope
This test plan covers the complete DiabetesManager system including mobile application, cloud services, device integration, and user interfaces.
#### 3. Test Strategy
**3.1 Functional Testing**
* **Glucose Data Management**: Verify data entry, validation, storage, and retrieval
* **Insulin Calculation**: Test dosing algorithms against clinical scenarios
* **Trend Analysis**: Validate statistical calculations and graphical displays
* **Device Integration**: Test Bluetooth connectivity and data synchronization
**3.2 Performance Testing**
* **Response Time**: Verify app responsiveness \<2 seconds for all user actions
* **Data Synchronization**: Test cloud sync performance under various network conditions
* **Battery Usage**: Validate power consumption within acceptable limits
**3.3 Safety Testing**
* **Input Validation**: Test handling of invalid glucose readings and user inputs
* **Error Handling**: Verify appropriate warnings for extreme glucose values
* **Fail-Safe Behavior**: Test app behavior when cloud services are unavailable
#### 4. Test Cases
| Test ID | Requirement | Test Description | Acceptance Criteria |
| ------- | ----------- | ------------------------------- | ------------------------------------------------------------------------------------------------ |
| TC-001 | REQ-001 | Manual glucose entry validation | App accepts valid glucose values (20-600 mg/dL), rejects invalid values with clear error message |
| TC-002 | REQ-005 | Insulin calculation accuracy | Calculated insulin dose within ±5% of expected value for standard clinical scenarios |
| TC-003 | REQ-012 | Bluetooth device pairing | App successfully pairs with supported glucose meters within 30 seconds |
| TC-004 | REQ-018 | Extreme value warnings | App displays appropriate warnings for glucose \<70 or >300 mg/dL |
#### 5. Test Environment
* **Mobile Devices**: iOS 14+ (iPhone 8 and newer), Android 9+ (Samsung Galaxy S9 and newer)
* **Network Conditions**: WiFi, 4G LTE, limited connectivity scenarios
* **Test Glucose Meters**: Accu-Chek Guide, OneTouch Verio models
* **Test Data**: Synthetic glucose datasets covering normal, hypoglycemic, and hyperglycemic ranges
#### 6. Test Execution
* **Phase 1**: Functional testing on primary test devices
* **Phase 2**: Performance testing under various load conditions
* **Phase 3**: Safety and error handling testing
* **Phase 4**: Integration testing with external devices and services
#### 7. Pass/Fail Criteria
* **Pass**: All test cases meet acceptance criteria, no critical defects remain unresolved
* **Fail**: Any critical safety requirement fails, >5% of test cases fail, or performance requirements not met
## Q\&A
Software testing documentation should include detailed test procedures, actual results, pass/fail determinations, and traceability to requirements. System testing serves as both verification and validation evidence. Document test plans that generate tests based on requirements, and create test reports that clearly show pass/fail status with justifications. While extensive automated testing frameworks aren't required, ensure systematic testing covers all software requirements and use-related risks.
There's no specific requirement for test automation, but automated testing can improve consistency and repeatability. Focus on automating tests that are frequently executed, prone to human error, or require precise timing. Manual testing may be more appropriate for usability aspects and complex integration scenarios. Document your testing approach and justify the mix of automated and manual testing based on risk and practicality.
SOUP components should be verified during system testing to ensure they function correctly within your system context. Test SOUP integration points, verify that SOUP components meet your requirements, and validate that SOUP failures are handled appropriately. Document SOUP versions used during testing and establish procedures for testing when SOUP components are updated.
When test cases fail, first determine if the failure is due to a software defect, test environment issue, or test procedure error. Document the failure, investigate the root cause, and determine appropriate corrective action. If it's a software defect, fix the defect and perform regression testing. If it's a test issue, correct the test and re-execute. All failures and their resolutions should be documented in the test report.
Cybersecurity testing should be integrated throughout your test plan, not treated as a separate activity. Include tests for authentication, authorization, data encryption, secure communication, and input validation. Test how the system handles security failures and verify that security controls don't interfere with essential functionality. Consider penetration testing for networked devices and document security test results as part of your overall test report.
Software system testing focuses on verifying that software requirements are correctly implemented, while usability testing validates that users can safely and effectively use the software. However, there's overlap in user interface testing and user workflow validation. Plan coordination between these testing activities to avoid duplication and ensure comprehensive coverage of user-facing functionality.
# Software System Test Report
Source: https://docs.withdovetail.com/tasks/software-system-test-report
Document software testing execution proving requirements compliance and regulatory readiness.
## Summary
The Software System Test Report documents the **execution results** of your systematic testing approach, providing evidence that your medical device software meets all specified requirements. This report captures test outcomes, identifies any deviations, and demonstrates regulatory compliance through comprehensive documentation of verification activities.
## Why is Software System Test Reporting important?
Software system test reporting provides **objective evidence** that your medical device software functions safely and effectively according to its specifications. This documentation is critical for regulatory submissions, as it demonstrates that you have systematically verified all software requirements and identified any issues before market release.
The test report serves as **legal evidence** of due diligence in software verification and provides traceability between requirements, test procedures, and actual results. Without proper test reporting, you cannot demonstrate compliance with software validation requirements or provide evidence that your software is safe for patient use.
## Regulatory Context
Under **21 CFR Part 820.30(g)** (Design Validation) and **FDA Guidance "General Principles of Software Validation"**:
* Test reports must provide **objective evidence** that software requirements are correctly implemented
* Documentation must demonstrate **traceability** from requirements through test results
* **IEC 62304** requires documented evidence of software verification activities
* Test reports must support **510(k) submissions** or other regulatory filings
**Special attention required for:**
* Complete documentation of test failures and their resolution
* Evidence of regression testing after defect fixes
* Verification of Software of Unknown Provenance (SOUP) integration
* Cybersecurity testing results for networked devices
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* Test reports must comply with **IEC 62304:2006+A1:2015** documentation requirements
* Must provide evidence for **technical documentation** and CE marking
* **Risk-based testing results** must align with ISO 14971 risk management
* Reports must support **notified body assessment** of software verification
**Special attention required for:**
* Clinical evaluation integration for software with clinical claims
* Post-market surveillance data collection planning
* Essential requirements compliance demonstration
* Software as Medical Device (SaMD) verification evidence
## Guide
### Understanding Test Report Structure
Your software system test report must provide **complete documentation** of test execution, including test procedures followed, actual results obtained, and pass/fail determinations for each test case. The report should clearly link test results back to specific software requirements to demonstrate verification completeness.
**Test execution summary** provides an overview of testing scope, test environment, and overall results. Include the number of test cases executed, passed, failed, and any test cases that were skipped or deferred.
**Individual test results** must document each test case execution with sufficient detail to support regulatory review. Include test case identifier, requirement being verified, test procedure followed, actual results observed, and pass/fail determination.
### Documenting Test Execution Details
For each test case, document the **specific test environment** used, including software versions, hardware configuration, test data, and environmental conditions. This information is crucial for result reproducibility and regulatory review.
**Actual results documentation** should capture what actually happened during test execution, not just whether the test passed or failed. Include screenshots, log files, measurement data, or other objective evidence of test outcomes.
**Deviation documentation** is critical when test execution differs from planned procedures. Document any deviations from the test plan, the reason for the deviation, and how the deviation affects test validity.
### Handling Test Failures and Anomalies
When test cases fail, your report must document the **failure investigation process** and resolution. Include root cause analysis, corrective actions taken, and verification that fixes resolve the issue without introducing new problems.
**Anomaly documentation** should capture unexpected behaviors that don't necessarily constitute test failures but may indicate potential issues. Document the anomaly, investigation results, and determination of whether further action is required.
**Regression testing results** must be documented when software changes are made to address test failures. Show that fixes resolve the original issue and don't introduce new problems in previously working functionality.
### Demonstrating Requirement Verification
Your test report must clearly demonstrate that **all software requirements have been verified** through testing. Use a traceability matrix or similar mechanism to show the relationship between requirements and test results.
**Coverage analysis** should identify any requirements that weren't fully verified through testing and provide justification for alternative verification methods or acceptance of residual risk.
**Risk verification** should demonstrate that safety-related requirements and risk controls have been properly tested and function as intended.
### Preparing for Regulatory Review
Structure your test report to facilitate **regulatory review** by organizing information logically and providing clear summaries. Include executive summaries that highlight key findings and overall verification status.
**Supporting documentation** should be referenced and available, including test procedures, test data, configuration information, and any tools or equipment used during testing.
**Quality assurance review** should be documented, showing that test results have been reviewed and approved by appropriate personnel before finalizing the report.
## Example
**Scenario**: You have completed system testing for your diabetes management app that tracks blood glucose readings, calculates insulin dosing recommendations, and provides trend analysis. Testing covered functional verification, performance validation, safety testing, and integration with glucose meters and cloud services.
Your test execution revealed that 98% of test cases passed on first execution. Two test cases failed initially due to incorrect insulin calculation rounding, which was fixed and successfully retested. One performance test showed slower than expected cloud synchronization under poor network conditions, which was accepted as within acceptable limits after risk analysis.
### Software System Test Report
**Document ID**: SSTR-001\
**Version**: 1.0\
**Test Period**: March 15-29, 2024
#### 1. Executive Summary
System testing of DiabetesManager v2.1 has been completed successfully. Of 127 test cases executed, 125 passed and 2 initially failed but passed after defect correction. All software requirements have been verified, and the system is ready for release.
#### 2. Test Execution Summary
**Test Environment**:
* Mobile Devices: iPhone 12 (iOS 16.3), Samsung Galaxy S21 (Android 12)
* Network: WiFi 802.11n, 4G LTE, limited connectivity simulation
* Test Glucose Meters: Accu-Chek Guide v1.2, OneTouch Verio v2.0
* Cloud Environment: AWS staging environment
**Test Results Overview**:
* Total Test Cases: 127
* Passed: 125 (98.4%)
* Failed (Initial): 2 (1.6%)
* Failed (Final): 0 (0%)
* Skipped: 0
#### 3. Test Results by Category
**3.1 Functional Testing (85 test cases)**
* Glucose Data Management: 25/25 passed
* Insulin Calculation: 23/25 passed (2 initially failed, corrected and retested)
* Trend Analysis: 20/20 passed
* Device Integration: 17/17 passed
**3.2 Performance Testing (22 test cases)**
* Response Time: 20/20 passed
* Data Synchronization: 2/2 passed (1 with acceptable deviation)
* Battery Usage: 0/0 (deferred to hardware testing)
**3.3 Safety Testing (20 test cases)**
* Input Validation: 8/8 passed
* Error Handling: 7/7 passed
* Fail-Safe Behavior: 5/5 passed
#### 4. Failed Test Cases and Resolution
| Test ID | Requirement | Failure Description | Root Cause | Resolution | Retest Result |
| ------- | ----------- | ------------------------------------------- | -------------------------------- | -------------------------------------------- | ------------- |
| TC-015 | REQ-005 | Insulin calculation 0.05 units off expected | Rounding algorithm error | Updated rounding logic in calculation module | PASS |
| TC-016 | REQ-005 | Insulin calculation incorrect for edge case | Missing boundary condition check | Added boundary validation | PASS |
#### 5. Anomalies and Deviations
**Anomaly AN-001**: Cloud synchronization under poor network conditions (TC-089)
* **Description**: Sync time 8.2 seconds vs. expected \<5 seconds
* **Investigation**: Network simulation more restrictive than real-world conditions
* **Resolution**: Accepted as within acceptable limits based on risk analysis
* **Impact**: No safety impact, user experience acceptable
#### 6. Requirement Verification Status
All 45 software requirements have been successfully verified through system testing:
* Functional Requirements: 32/32 verified
* Performance Requirements: 8/8 verified
* Safety Requirements: 5/5 verified
#### 7. Conclusions and Recommendations
System testing demonstrates that DiabetesManager v2.1 meets all specified requirements and is suitable for release. All critical safety functions operate correctly, and performance meets user needs. The software is recommended for production deployment.
**Outstanding Actions**: None
**Approved by**: \[Test Manager], \[Quality Assurance], \[Project Manager]
## Q\&A
Document each test failure with complete details including the specific test case, expected vs. actual results, investigation findings, root cause analysis, corrective actions taken, and retest results. Include evidence that fixes resolve the issue without introducing new problems. All failures and their resolutions must be traceable and approved before finalizing the report.
Provide sufficient detail to demonstrate that requirements were properly verified and to support regulatory review. Include test case identifiers, requirement traceability, test procedures followed, actual results observed, and pass/fail determinations. Capture objective evidence such as screenshots, log files, or measurement data where relevant to support conclusions.
Document all relevant aspects of the test environment including software versions, hardware configurations, test data sets, network conditions, and any external systems or devices used. This information is crucial for result reproducibility and regulatory review. Include configuration management details to ensure test environment integrity.
Document any test cases that were skipped or deferred, including the reason and impact assessment. Provide alternative verification evidence where possible, or document acceptance of residual risk. Ensure that all critical safety requirements are still adequately verified through executed test cases or alternative methods.
Document regression testing as part of the overall test execution, clearly identifying which tests were performed after software changes. Show traceability between defect fixes and regression test results. Demonstrate that fixes resolve original issues without introducing new problems in previously working functionality.
Test reports should be reviewed and approved by appropriate personnel including test managers, quality assurance, and project management. Document the review process and maintain records of approvals. Ensure that all test failures have been resolved and that the report accurately reflects test execution before final approval.
# Software Validation Form
Source: https://docs.withdovetail.com/tasks/software-validation-form
Document systematic software validation through risk assessment, testing, and compliance verification processes.
## Summary
**Software Validation Form** provides structured documentation for validating computer systems and software applications used in quality management processes or production/service provision activities that impact medical device safety and quality. This essential Quality Management System (QMS) record ensures systematic evaluation of software reliability, performance, and compliance with regulatory requirements through risk-based validation approaches.
## Why is Software Validation Form important?
Computer system validation represents a **regulatory requirement** that ensures software systems perform consistently and reliably in ways that affect product quality or regulatory compliance. **Without proper software validation**, organizations risk using unverified systems that could introduce errors, data integrity issues, or compliance failures affecting medical device safety and effectiveness.
**ISO 13485:2016 mandates validation** of processes where output cannot be verified through subsequent monitoring or measurement (Section 7.5.6). **Software validation demonstrates** that applications perform their intended functions accurately and maintain data integrity throughout their operational lifecycle. **This protects against** systematic errors that could affect multiple devices or compromise quality management system effectiveness.
The structured validation approach transforms software evaluation from informal testing into **systematic verification** that supports regulatory compliance, audit readiness, and operational confidence. **Well-executed software validation** provides objective evidence that computer systems support rather than compromise quality objectives and regulatory requirements.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **21 CFR Part 11** (Electronic Records):
* **Process validation** required for processes where output cannot be verified by subsequent inspection/test (21 CFR 820.75)
* **Computer system validation** must ensure software performs intended functions accurately and reliably
* **Electronic signature systems** must be validated per 21 CFR Part 11 requirements
* **Data integrity** requirements mandate validated systems for electronic records affecting device quality
**Special attention required for:**
* GAMP 5 guidelines for computer system validation approaches
* 21 CFR Part 11 compliance for systems managing electronic records/signatures
* Software as Medical Device (SaMD) development tool validation
* Quality system software supporting design controls, CAPA, and document management
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Process validation** mandatory where output cannot be verified through monitoring/measurement (ISO 13485 7.5.6)
* **Computer system validation** required for systems affecting product quality or QMS effectiveness (ISO 13485 4.1.6)
* **Software lifecycle processes** must be validated when supporting medical device development
* **Risk management principles** apply to software validation approaches and documentation
**Special attention required for:**
* EU GDPR compliance for software processing personal data
* Cybersecurity validation requirements per MDCG 2019-16 guidance
* Supplier software validation when outsourcing quality processes
* Software supporting clinical evaluation and post-market surveillance activities
## Guide
### Software Qualification and Risk Assessment
**Determine validation requirements** using qualification criteria that assess software impact on quality management systems and medical device safety. **Evaluate three key questions**: Does software failure affect device safety or quality? Does software automate regulatory-required activities? Could software output reach released products without verification?
**Conduct systematic risk assessment** considering software impact on quality management systems, potential failure consequences, regulatory compliance requirements, and user impact scenarios. **Categorize software risk levels** as low, medium, or high based on assessment results to determine appropriate validation rigor and documentation requirements.
**Apply GAMP 5 categorization** when appropriate, classifying software as infrastructure (Category 1), non-configurable commercial off-the-shelf (Category 3), configurable COTS (Category 4), or bespoke custom software (Category 5). **Match validation approach** to software category and risk level for efficient resource allocation.
### Software Requirements and Intended Use Definition
**Document software intended use** clearly, specifying exactly how your organization will utilize the software and which processes it will replace or support. **Identify specific features** your organization will use rather than cataloging all available software capabilities.
**Establish software requirements** that define what the software must accomplish to meet your intended use. **Structure requirements systematically** using unique identifiers and clear, testable statements. **Link requirements** to risk controls and validation testing to ensure comprehensive coverage.
**Define software replacement scope** by documenting existing processes the software will automate or replace. **This establishes validation boundaries** and helps determine which software functions require validation versus those outside your scope of use.
### Risk Management and Control Implementation
**Identify software-related hazards** that could lead to harm including device quality impacts, manufacturing process disruptions, regulatory compliance failures, or personnel/environmental safety concerns. **Assess likelihood and severity** of identified risks using structured risk acceptability matrices.
**Implement risk controls** for unacceptable risks through software design modifications, process controls, user training, or downstream verification activities. **Document risk control effectiveness** and reassess residual risks after control implementation.
**Establish risk acceptability criteria** based on software impact potential and your organization's risk tolerance. **Use structured matrices** that consider harm severity (low, moderate, high) and occurrence likelihood (infrequent, occasional, regular) to guide risk management decisions.
### Validation Testing and Documentation
**Develop comprehensive test plans** that verify software requirements fulfillment and risk control effectiveness. **Design test cases** with clear objectives, detailed test steps, and specific acceptance criteria linked to software requirements.
**Establish appropriate test environments** that represent actual software deployment conditions including hardware, operating systems, network configurations, and user access controls. **Document test environment specifications** to ensure validation relevance and reproducibility.
**Execute validation testing systematically** with qualified personnel documenting test results, pass/fail determinations, and any deviations from expected performance. **Include both positive and negative testing** to verify software handles normal operations and error conditions appropriately.
**Document validation conclusions** that summarize testing results, assess software suitability for intended use, and identify any limitations or restrictions for deployment. **Address failed tests** through software modifications, risk control adjustments, or use restriction implementation.
### Deployment and Ongoing Management
**Plan software deployment** considering integration with existing systems, user training requirements, transition timelines, and rollback procedures if issues arise. **Document deployment processes** to ensure consistent implementation and change control.
**Establish ongoing monitoring and review procedures** proportionate to software risk and criticality. **Define monitoring activities** including periodic performance reviews, error log analysis, user feedback collection, and compliance verification.
**Maintain validation documentation** throughout software lifecycle including version updates, configuration changes, and periodic revalidation activities. **Update List of Validated Software** to reflect current validation status and deployment information.
### Software Updates and Change Control
**Evaluate software updates** for impact on validated functions and previously identified risks. **Determine revalidation requirements** based on change scope, risk implications, and intended use modifications.
**Document change evaluation** in validation records including assessment rationale, revalidation decisions, and any additional risk controls implemented. **Maintain validation history** showing software evolution and validation activities over time.
**Coordinate software validation** with broader change management processes to ensure systematic evaluation and approval of software modifications affecting quality or compliance.
## Example
**Scenario:** Your organization implements a new electronic Quality Management System (eQMS) platform to replace paper-based document control and electronic signature processes. The eQMS will manage SOPs, training records, CAPA documentation, and audit reports for your Class IIa medical device.
### Software Qualification
You complete qualification criteria assessment determining the eQMS requires validation because it automates regulatory-required activities (document control, electronic signatures) and could impact device quality if it fails. Risk assessment identifies medium-to-high risk due to quality management system criticality and regulatory compliance requirements.
### Requirements Definition
Your software requirements specify document version control capabilities, electronic signature compliance, user access controls, audit trail functionality, and backup/recovery procedures. Intended use focuses on replacing paper-based QMS processes while maintaining regulatory traceability and compliance.
### Risk Assessment and Controls
You identify risks including data loss, unauthorized access, system downtime, and electronic signature non-compliance. Risk controls include automated backup systems, user authentication protocols, system redundancy, and 21 CFR Part 11 compliance features. Residual risks are assessed as acceptable after control implementation.
### Validation Testing
Your test plan includes document upload/download testing, electronic signature verification, user access control validation, audit trail functionality testing, and backup/recovery procedures verification. Testing occurs in production-equivalent environment with actual users performing typical QMS activities.
### Deployment and Monitoring
Following successful validation, you deploy the eQMS with phased user training and parallel operations during transition. Ongoing monitoring includes monthly system performance reviews, quarterly compliance audits, and annual validation effectiveness assessments. The validated eQMS is added to your List of Validated Software.
## Q\&A
Validate software that automates regulatory-required activities, could affect device quality if it fails, or produces output that reaches released products without verification. Common examples include electronic QMS platforms, manufacturing control systems, laboratory data management systems, and design control software.
Base validation rigor on software risk assessment results and GAMP 5 categorization. High-risk or custom software requires comprehensive validation including detailed testing and documentation. Low-risk commercial software may require basic functional testing and configuration verification. Match validation effort to risk and complexity.
Validation testing must verify all software requirements are met and risk controls are effective. Include installation qualification, operational qualification, and performance qualification testing as appropriate. Test both normal operations and error conditions. Document test procedures, results, and acceptance criteria clearly.
Review validated software based on risk level and change frequency. High-risk systems may require annual reviews while low-risk systems might need review every 2-3 years. Revalidate when software versions change significantly, intended use expands, or new risks are identified. Document all review activities.
Address software deficiencies through software modifications, additional risk controls, use restrictions, or deployment delays. Document all issues and resolution approaches. Repeat testing after implementing corrective actions. Only deploy software after successful validation completion or with documented risk acceptance.
SaaS validation focuses on configuration verification, interface testing, and supplier assessment rather than underlying software development. Validate your specific configuration and integration while relying on supplier validation documentation for core functionality. Include supplier audits and service level agreements in validation approach.
Maintain completed Software Validation Forms, test protocols and results, risk assessments, software requirements specifications, and ongoing monitoring records. Include supplier documentation, configuration records, and validation history. Ensure documentation supports audit requirements and demonstrates ongoing compliance.
Software supporting electronic records or signatures must comply with 21 CFR Part 11 requirements including user authentication, audit trails, electronic signature controls, and data integrity protections. Include Part 11 compliance verification in validation testing and document compliance features and controls in validation records.
# SOP Corrective and Preventive Action (CAPA)
Source: https://docs.withdovetail.com/tasks/sop-capa
Investigate and resolve quality issues through systematic root cause analysis and proportionate corrective actions.
## Summary
Your **Corrective and Preventive Action (CAPA)** SOP establishes a systematic process for identifying, investigating, and resolving actual or potential nonconformities to eliminate root causes and prevent recurrence while ensuring proportionate responses that maintain device safety and regulatory compliance.
## Why is SOP CAPA important?
CAPA exists because regulators require **systematic problem-solving** rather than reactive fixes that only address symptoms. It transforms quality issues from isolated incidents into opportunities for systematic improvement by addressing root causes and preventing similar problems across your entire quality system.
The SOP ensures consistency in how you evaluate events, conduct investigations, and implement solutions. It also provides auditors with evidence that your organization learns from mistakes and proactively prevents issues. Most importantly, it demonstrates that your quality system is **continuously improving** rather than just maintaining compliance, which builds regulatory confidence and customer trust.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* CAPA system is **mandatory** under Section 820.100
* Must address **all actual nonconformities** and potential problems
* Requires **systematic investigation** and root cause analysis
* Actions must be **proportionate** to the magnitude of problems
* Must verify **implementation and effectiveness** of corrective actions
**Special attention required for:**
* Medical Device Reporting (MDR) integration (21 CFR Part 803)
* Field corrective actions that may require FDA notification
* CAPA trending analysis and management review integration
* Documentation requirements for FDA inspections and 483 observations
Under **EU MDR 2017/745**:
* CAPA required as part of **quality management system** (Article 10(10))
* Must comply with **EN ISO 13485:2016 Sections 8.5.1-8.5.3**
* Integration with **post-market surveillance** system (Article 83)
* Must support **vigilance reporting** requirements (Article 88)
* PRRC oversight and **notified body assessment** readiness required
**Special attention required for:**
* Vigilance system integration and serious incident reporting
* Field Safety Corrective Actions (FSCA) and Field Safety Notices (FSN)
* Clinical evaluation updates based on CAPA findings
* Post-market surveillance plan updates and trend analysis
## Guide
Your CAPA SOP establishes the **framework** for systematic problem resolution. Design the process to focus on root cause elimination rather than quick fixes that only address symptoms.
### CAPA Qualification and Initiation
Implement a **risk-based qualification process** to determine when CAPAs are necessary. Not every issue requires a full CAPA - use systematic criteria considering factors like patient safety impact, systemic nature, trend analysis, and severity. Establish clear thresholds that trigger CAPA initiation while avoiding overwhelming your team with low-impact events.
Create qualification criteria that include input type scoring (patient safety issues receive highest priority), systemic impact assessment, trend analysis results, and potential for patient harm. Document the rationale for CAPA decisions to demonstrate consistent application of your criteria during audits.
### Investigation and Root Cause Analysis
Conduct **thorough investigations** using structured methodologies like the Five Whys or fishbone diagrams. Involve subject matter experts from affected areas rather than limiting investigation to quality personnel alone. The goal is identifying systemic root causes rather than individual blame or surface-level symptoms.
Document investigation findings comprehensively, including timeline reconstruction, contributing factors, and multiple potential root causes. Use evidence-based analysis rather than assumptions, and validate findings through data review and stakeholder interviews.
### Action Planning and Implementation
Develop **action plans** that address identified root causes proportionately. Consider immediate containment actions for urgent issues, corrective actions to fix existing problems, and preventive actions to avoid similar future issues. Ensure actions don't create unintended consequences or compromise device safety.
Assign clear responsibilities, realistic timelines, and measurable success criteria for each action. Include resource requirements and management approval for significant changes. Integrate action implementation with existing change control processes to maintain system integrity.
### Effectiveness Verification
Establish **verification methods** before implementing actions. Define specific metrics and timeframes for measuring CAPA effectiveness. This might include monitoring complaint trends, audit findings, process performance indicators, or customer satisfaction metrics.
Conduct effectiveness reviews at predetermined intervals rather than assuming actions worked. Document verification results and close CAPAs only when effectiveness is demonstrated. If actions prove ineffective, initiate new CAPAs rather than extending existing ones indefinitely.
### Integration with Quality System
Connect your CAPA system to **all quality processes** including audit programs, management review, post-market surveillance, and design controls. CAPA outcomes should inform risk management updates, training needs assessments, and quality objective setting.
Maintain CAPA trending analysis to identify systemic issues requiring management attention. Use CAPA data during management review to demonstrate quality system effectiveness and guide strategic quality decisions.
## Example
### Scenario
MedTech Solutions receives multiple customer complaints about their diabetes monitoring app crashing during glucose readings. The quality team uses their CAPA qualification process to assess the issue, conducts a root cause investigation involving the software development team, and implements systematic corrections to prevent similar software failures.
### CAPA Process Implementation
**Event:** Three customer complaints received within two weeks about app crashes during critical glucose readings, with one report of delayed insulin administration.
**CAPA Qualification:**
* Input Type: Customer complaints (+2) with patient safety implications (+3)
* Systemic: Multiple similar complaints indicate systemic issue (+2)
* Trend Analysis: Pattern identified through complaint monitoring (+2)
* Significant Impact: App crashes during critical medical function (+2)
* Patient Harm: Potential delayed treatment (+1)
* **Total Score: 12** (exceeds threshold of 3)
* **Decision: Initiate CAPA**
**Investigation and Root Cause Analysis:**
Quality team collaborates with software development team using Five Whys methodology:
* **Problem:** App crashes during glucose reading function
* **Why #1:** Memory overflow in glucose calculation module
* **Why #2:** Inadequate memory allocation for complex calculations
* **Why #3:** Algorithm optimization not performed during recent feature updates
* **Why #4:** Testing protocols don't include memory stress testing
* **Why #5:** Software validation procedures lack comprehensive performance testing requirements
* **Root Cause:** Insufficient software validation procedures for performance under stress conditions
**Action Plan:**
1. **Immediate Containment:** Release hotfix within 48 hours to optimize memory usage
2. **Corrective Action:** Update software validation SOP to include performance stress testing
3. **Preventive Action:** Implement automated memory monitoring in development environment
4. **System Updates:** Revise design control procedures to require performance validation
**Implementation and Verification:**
* Hotfix deployed successfully with zero crashes reported in two-week monitoring period
* Updated SOPs reviewed and approved by management representative
* Development team trained on new testing requirements
* Automated monitoring tools integrated into continuous integration pipeline
* **Effectiveness Verification:** No similar crashes reported in 90-day monitoring period
* **CAPA Status:** Closed after effectiveness confirmation
## Q\&A
Use your risk-based qualification process to evaluate each event systematically. Consider factors like patient safety impact, whether the issue is systemic, if it's part of a trend, and the potential for harm. Score these factors according to your established criteria and initiate CAPA when thresholds are exceeded. Document your decision rationale for audit purposes.
Corrective actions fix existing problems to prevent recurrence, while preventive actions address potential problems before they occur. In practice, most CAPAs include both elements - correcting the immediate issue and preventing similar problems across your quality system. Focus on root cause elimination for lasting effectiveness.
Log complaints related to device performance or safety in your complaint management system and evaluate each for CAPA qualification. Significant complaints indicating systemic issues or safety concerns should trigger CAPA initiation. Compile complaint data for trend analysis and include findings in your post-market surveillance reporting.
CAPAs should remain open until effectiveness is verified through your predetermined metrics and timeframes. Avoid arbitrary closure timelines - instead focus on completing investigation, implementing actions, and demonstrating effectiveness. If actions prove ineffective, initiate new CAPAs rather than extending existing ones indefinitely.
Include quality team members for oversight and subject matter experts from affected areas for technical expertise. For software issues, involve development teams; for manufacturing problems, include production personnel. The key is combining quality system knowledge with domain expertise for thorough investigation and effective solutions.
Unofficial audit recommendations should be reviewed and considered for implementation but don't automatically require CAPA initiation. They can be managed through change management by updating documents to improve compliance. Evaluate each recommendation using your CAPA qualification criteria to determine if formal CAPA is warranted.
# SOP Change Management
Source: https://docs.withdovetail.com/tasks/sop-change-management
Evaluate and implement device modifications through systematic risk assessment and regulatory compliance procedures.
## Summary
Your **Change Management** SOP establishes the systematic process for evaluating, approving, and implementing modifications to released medical devices and quality management systems. It distinguishes between significant changes requiring full regulatory oversight and minor bug fixes, ensuring proper documentation, risk assessment, and regulatory compliance for all post-market modifications.
## Why is SOP Change Management important?
Change management exists because regulators recognize that medical devices continue to evolve after market release through software updates, design improvements, and corrective actions. Without systematic control, **uncontrolled changes** could introduce new risks, invalidate previous testing, or compromise regulatory compliance. This SOP transforms ad-hoc modifications into a **controlled process** that maintains device safety and effectiveness while enabling innovation.
The process protects both patients and manufacturers by ensuring that every change undergoes appropriate risk evaluation, receives proper approvals, and maintains traceability to the original device validation. It also demonstrates to auditors that your organization has systematic mechanisms to prevent unauthorized modifications that could compromise device integrity.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design changes must follow **documented procedures** under Section 820.30(i)
* Changes require **verification and validation** equivalent to original design controls
* Documentation changes must be **controlled** according to Section 820.40(b)
* **Management approval** required for significant modifications
**Special attention required for:**
* Software modifications that could affect safety or effectiveness
* Changes affecting predicate device equivalence (for 510(k) devices)
* Risk management file updates for new hazardous situations
* Labeling changes that require FDA notification
Under **EU MDR 2017/745**:
* Manufacturers must assess **substantial changes** requiring notified body notification (Article 120)
* Changes affecting **safety and performance** require technical documentation updates
* **MDCG 2020-3** provides guidance on significant change assessment
* Post-market surveillance data must inform change evaluation (Articles 83-86)
**Special attention required for:**
* Clinical evaluation updates for changes affecting clinical evidence
* UDI system updates for product identification changes
* Notified body assessment for substantial modifications
* EUDAMED registration updates for device changes
## Guide
Your Change Management SOP creates a **structured framework** for controlling all modifications to released products and organizational processes. Design the system to balance innovation with regulatory compliance while maintaining complete traceability.
### Defining Change Categories
Establish clear **criteria** for distinguishing between change requests and bug fixes. Change requests introduce new functionality, alter existing features, or modify device performance characteristics. Bug fixes restore the device to its originally intended function without adding capabilities. This distinction determines the required documentation depth and approval pathway.
Document specific examples of each category to eliminate ambiguity. Include borderline cases and how they should be classified. Train your team on these distinctions since misclassification can lead to inadequate oversight or unnecessary bureaucracy.
### Change Initiation and Documentation
Create standardized **change request forms** that capture essential information including change source, detailed description, affected products and versions, and anticipated documentation impacts. Require requestors to identify potential risks and regulatory implications early in the process.
Implement a centralized tracking system for all change requests, whether they proceed to implementation or not. This creates an audit trail demonstrating systematic evaluation of all proposed modifications and provides valuable data for trend analysis and process improvement.
### Risk and Impact Assessment
Develop a **systematic evaluation process** that examines each change for safety, performance, and regulatory impacts. Include cross-functional team members from product development, quality assurance, and regulatory affairs in the assessment. Consider effects on existing risk controls, validation testing, and clinical evidence.
Pay particular attention to changes affecting SOUP (Software of Unknown Provenance) components, as these may introduce unforeseen interactions. Evaluate whether modifications create new use-related hazards or invalidate previous usability testing results.
### Approval Workflows and Authority Matrix
Define **clear approval authority** based on change significance and impact assessment results. Minor changes may require quality manager approval while significant modifications need executive management and potentially notified body involvement. Document specific criteria for each approval level to ensure consistency.
Establish expedited pathways for critical bug fixes that address safety issues, while maintaining appropriate oversight. Balance the need for rapid response with regulatory compliance requirements, particularly for software medical devices where updates can be deployed quickly.
### Implementation and Verification
Require **verification and validation** activities proportional to change significance. Minor modifications may need focused testing while major changes could require full design control processes. Reference your existing SOPs for software development, design control, and risk management to ensure consistent application.
Document implementation timelines, rollback procedures, and success criteria before beginning modification work. This preparation enables rapid response if issues arise during deployment and demonstrates systematic approach to change implementation.
### Post-Implementation Monitoring
Establish **monitoring mechanisms** to track change effectiveness and identify any unexpected consequences. Include customer feedback analysis, performance metrics evaluation, and adverse event monitoring in your post-implementation review process.
Use this monitoring data to refine your change evaluation process and improve future risk assessments. Document lessons learned and update your change management procedures based on real-world experience with implemented modifications.
## Example
### Scenario
MediSoft Solutions receives customer feedback requesting a new data export feature for their diagnostic software. The product team initiates a change request, evaluating the modification's impact on system architecture, risk management, and regulatory compliance. After approval, they implement the change following established development procedures and monitor its performance post-deployment.
### Example Change Management Process
**Change Request Initiation:**
* **Source:** Customer feedback requesting enhanced data export functionality
* **Description:** Add ability to export patient data in multiple file formats (PDF, CSV, XML)
* **Affected Products:** DiagnosticPro Software v2.1 and later versions
* **Anticipated Impact:** Software architecture updates, new user interface elements, data handling procedures
**Risk and Impact Assessment:**
* **Safety Evaluation:** No new hazardous situations identified - export function is read-only
* **Performance Impact:** Minimal - background processing with user notification
* **Regulatory Impact:** No changes to intended use or device classification
* **Documentation Updates:** System requirements, software architecture, user manual, risk management file
**Approval Process:**
* **Initial Review:** Quality Manager approves as non-significant change
* **Technical Review:** Software team confirms feasibility and resource requirements
* **Final Approval:** VP of Product Development authorizes implementation
* **Regulatory Clearance:** No notified body notification required
**Implementation Steps:**
1. **Requirements Update:** Add specific export functionality requirements
2. **Design Modification:** Update software architecture documentation
3. **Development:** Implement export features following SOP Software Development
4. **Testing:** Execute focused verification testing on export functions
5. **Risk Assessment:** Update risk management file with new user interface elements
6. **Documentation:** Revise user manual and instructions for use
**Post-Implementation Monitoring:**
* **Performance Metrics:** Monitor export function usage and completion rates
* **Customer Feedback:** Track support requests related to new functionality
* **Adverse Events:** Monitor for any issues related to data export accuracy
* **Effectiveness Review:** Quarterly assessment of change objectives achievement
**Change Evaluation Report Completion:**
* Document successful implementation of all planned modifications
* Confirm compliance with design control and risk management procedures
* Record any deviations from planned implementation approach
* Validate that change objectives were achieved without introducing new risks
## Q\&A
The process involves creating a change request for each modification, updating software requirements if needed, reviewing and updating test plans, generating new test reports, updating the List of Known Anomalies with the new version, updating the UDI-PI with the format DD/MM/YY + version, and completing a change evaluation report.
The change request dictates how much documentation needs to be updated and involves selecting the source of the change, describing the specific modifications being made, and identifying which documents and reports require updates. It serves as the foundation for determining the scope of verification and validation activities needed.
Each bug fix requires a change request to document the issue and proposed solution. A bug fix report needs to be updated for every release, documenting that the modification restores the device to its originally intended function without introducing new features or significant changes.
A new feature is in development to streamline version comparison, which will show differences between versions, guide users through required document updates, and provide a compressed roadmap view of necessary changes. This reduces the manual effort required to identify all affected documentation.
Documentation updates may include system requirements, software architecture, risk management files, verification and validation plans and reports, user manuals, instructions for use, and the List of Known Anomalies. The specific documents requiring updates depend on the nature and scope of the change.
Changes should be evaluated based on their impact on device safety, performance, intended use, and regulatory compliance. Consider whether the modification introduces new risks, affects existing risk controls, changes user interactions, or requires notified body notification. Use established criteria to ensure consistent evaluation across all changes.
A change request introduces new functionality, modifies existing features, or alters device performance characteristics. A bug fix restores the device to its originally intended function without adding new capabilities or making significant changes. Bug fixes typically require less documentation and approval oversight than change requests.
Notified body involvement is required for substantial changes that could affect device safety, performance, or the conditions prescribed for use. This includes modifications to intended use, significant design changes, or alterations that impact clinical evidence. Consult MDCG 2020-3 guidance for specific criteria.
# SOP Clinical Evaluation
Source: https://docs.withdovetail.com/tasks/sop-clinical-evaluation
Generate clinical evidence demonstrating device safety and effectiveness through systematic evaluation and literature review.
## Summary
Your **Clinical Evaluation** SOP establishes the systematic process for continuously generating, collecting, analyzing, and assessing clinical data to verify the safety, performance, and clinical benefits of your medical device. It encompasses planning through execution of clinical evaluation reports, ensuring compliance with EU MDR requirements and ongoing post-market clinical follow-up activities.
## Why is SOP Clinical Evaluation important?
Clinical evaluation exists because regulators require **objective evidence** that medical devices deliver promised clinical benefits while maintaining acceptable risk-benefit ratios. Unlike marketing claims, clinical evaluation demands systematic review of scientific literature, analysis of real-world performance data, and potentially new clinical investigations to substantiate device safety and effectiveness.
This SOP transforms clinical evidence from subjective assertions into **rigorous scientific assessment**. It protects patients by ensuring only devices with proven clinical value reach the market, while protecting manufacturers by providing defensible documentation for regulatory submissions and post-market surveillance obligations. The process also drives continuous improvement by identifying areas where additional clinical data strengthens device positioning and clinical utility.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Clinical data requirements vary by **device classification** and submission pathway
* **Predicate device equivalence** may reduce clinical data requirements for 510(k) submissions
* **Valid scientific evidence** must support safety and effectiveness claims
* Post-market studies may be required for **ongoing safety monitoring**
**Special attention required for:**
* Software as Medical Device (SaMD) clinical validation requirements
* Real-world evidence expectations for AI/ML enabled devices
* Clinical trial requirements for novel or high-risk devices
* Post-market surveillance data integration into benefit-risk assessment
Under **EU MDR 2017/745**:
* Clinical evaluation is **mandatory** for all device classes (Article 61, Annex XIV)
* Must follow **MEDDEV 2.7/1 Rev. 4** systematic methodology
* **Post-market clinical follow-up (PMCF)** required for ongoing evaluation
* Clinical evaluation must be **updated regularly** based on device classification
**Special attention required for:**
* Valid clinical association requirements for medical device software (MDCG 2020-1)
* Equivalence demonstration criteria (MDCG 2020-5) for predicate device approaches
* Literature search methodology and quality standards
* Integration with post-market surveillance and vigilance reporting
## Guide
Your Clinical Evaluation SOP establishes a **comprehensive framework** for demonstrating clinical safety and performance throughout your device lifecycle. Design the process to generate robust clinical evidence while efficiently leveraging existing scientific knowledge.
### Establishing the Clinical Evaluation Team
Assemble a **qualified evaluation team** with appropriate expertise for your device technology and clinical application. Include team members with research methodology knowledge, experience in relevant medical specialties, and regulatory requirements understanding. For software medical devices, ensure expertise in algorithm validation and real-world performance assessment.
Document team qualifications including education, professional experience, and any conflicts of interest. Consider engaging external clinical experts when internal expertise is insufficient. Maintain at least one team member with a degree from higher education and five years of documented professional experience, or ten years of professional experience if a degree is not available.
### Clinical Evaluation Planning
Develop your **clinical evaluation plan** before initiating data collection activities. Define the intended purpose, target patient populations, clinical benefits, and outcome parameters you will assess. Identify general safety and performance requirements requiring clinical data support and specify methods for evaluating both safety and effectiveness.
Include a clinical development plan indicating progression from initial feasibility studies through confirmatory investigations and post-market clinical follow-up. Establish acceptance criteria for benefit-risk evaluation and describe how you will address any device-specific clinical concerns such as biocompatibility or human tissue interactions.
### Literature Search and Review
Conduct **systematic literature searches** using appropriate databases such as MEDLINE and EMBASE. Develop comprehensive search strategies including relevant keywords, device types, clinical conditions, and outcome measures. Document your search methodology, databases used, date ranges, and inclusion/exclusion criteria.
Critically appraise retrieved literature for relevance, quality, and applicability to your device. Evaluate study design, patient populations, outcome measures, and statistical analyses. Pay particular attention to studies using equivalent devices and assess whether equivalence can be appropriately claimed based on technical, biological, and clinical characteristics.
### Clinical Data Analysis and Gap Assessment
Analyze **available clinical data** to identify strengths and limitations in the clinical evidence base. Assess whether existing data adequately supports your intended use, clinical benefits, and safety claims. For software medical devices, pay particular attention to technical performance validation, clinical performance demonstration, and valid clinical association establishment.
Document any gaps in clinical evidence and develop strategies to address them through additional literature review, clinical investigations, or post-market data collection. Consider whether real-world evidence from post-market surveillance can supplement clinical study data.
### Clinical Investigation Planning
Plan **clinical investigations** when existing clinical data is insufficient to support safety and effectiveness claims. Develop investigation protocols that address identified evidence gaps while following good clinical practice standards. Consider whether feasibility studies are needed before confirmatory investigations.
For software medical devices, design studies that validate both technical performance (accuracy, reliability, precision) and clinical performance (clinically relevant outcomes). Ensure studies include appropriate patient populations and use conditions representative of intended clinical use.
### Post-Market Clinical Follow-up Integration
Establish **PMCF activities** to continuously collect clinical performance and safety data after market release. Define data collection methodologies including clinical registries, literature monitoring, user feedback analysis, and adverse event evaluation. Set regular review periods not exceeding one year.
Use PMCF data to update clinical evaluation conclusions and identify any changes to benefit-risk assessment. Establish clear criteria for triggering corrective actions if new clinical data raises safety concerns or questions clinical effectiveness.
## Example
### Scenario
CardioCare Technologies develops AI-powered ECG analysis software for detecting arrhythmias. Their clinical team conducts a comprehensive clinical evaluation including literature review, equivalence assessment to predicate devices, and planning for post-market clinical follow-up to support EU MDR compliance and clinical benefit claims.
### Example Clinical Evaluation Process
**Clinical Evaluation Team Formation:**
* **Clinical Lead:** Board-certified cardiologist with 8 years device evaluation experience
* **Research Methodologist:** PhD biostatistician with systematic review expertise
* **Regulatory Specialist:** MSc with 6 years medical device regulatory experience
* **Software Expert:** Computer scientist with AI/ML algorithm validation background
**Clinical Evaluation Plan Development:**
* **Intended Purpose:** Aid in detecting cardiac arrhythmias from standard 12-lead ECG recordings
* **Target Population:** Adult patients (≥18 years) undergoing routine ECG screening
* **Clinical Benefits:** Improved arrhythmia detection accuracy compared to manual interpretation
* **Outcome Parameters:** Sensitivity, specificity, positive/negative predictive values for arrhythmia detection
**Literature Search Strategy:**
* **Databases:** MEDLINE, EMBASE, IEEE Xplore, Cochrane Library
* **Keywords:** "ECG analysis," "arrhythmia detection," "artificial intelligence," "machine learning," "automated electrocardiography"
* **Date Range:** January 2015 - Present
* **Inclusion Criteria:** Studies using AI/ML for ECG arrhythmia detection in adult populations
**Clinical Data Analysis Results:**
* **Studies Identified:** 45 relevant publications from systematic search
* **High-Quality Studies:** 12 studies meeting inclusion criteria for evidence evaluation
* **Predicate Device Assessment:** 3 CE-marked devices with similar AI algorithms identified
* **Performance Benchmarks:** Sensitivity 85-95%, Specificity 90-98% for comparable systems
**Evidence Gap Assessment:**
* **Adequate Evidence:** Technical performance validation for common arrhythmias
* **Limited Evidence:** Performance in elderly patients with multiple comorbidities
* **Gap Identified:** Real-world performance data outside controlled clinical settings
* **Action Plan:** Design PMCF registry to collect real-world performance data
**Valid Clinical Association (Software-Specific):**
* **Technical Performance:** Algorithm accurately identifies ECG waveform patterns associated with specific arrhythmias
* **Clinical Association:** ECG pattern recognition correlates with established diagnostic criteria for cardiac arrhythmias
* **Clinical Performance:** Software output enables healthcare providers to make more accurate diagnostic decisions
**Post-Market Clinical Follow-up Plan:**
* **PMCF Registry:** 500-patient registry collecting real-world performance over 12 months
* **Literature Monitoring:** Quarterly searches for new relevant publications
* **Adverse Event Analysis:** Integration with vigilance system for safety signal detection
* **Annual Review:** Comprehensive clinical evaluation update including all PMCF data
## Q\&A
A clinical evaluation plan and report assess the clinical performance and safety of a medical device. It involves answering a series of questions and compiling data to demonstrate that the device meets regulatory requirements and provides clinical benefits. The plan outlines the methodology while the report presents the evidence and conclusions.
Clinical benefits should be minimal and supported by clinical data. They are included in the instructions for use and should not make unsupported claims. Focus on measurable, patient-relevant clinical outcomes that can be substantiated through scientific evidence or clinical investigations.
Initially, it is advisable to avoid making specific performance claims that require clinical validation. Focus on design claims that are factual and can be supported without extensive data. Performance claims can be made later based on post-market data or additional clinical studies.
The best practice is to perform an initial search and review of scientific literature and then redo the search closer to the document approval date to include any new studies that may have been published. This ensures your clinical evaluation reflects the most current scientific knowledge.
The number of participants is usually recommended in the standards and guidance documents. A power analysis can also be conducted to statistically determine the required sample size based on the study's objectives and expected effect sizes. Consider the device classification and regulatory requirements when determining sample size.
The clinical evaluation team must include someone familiar with the field, with a higher education degree and relevant professional experience. Team members should have knowledge of research methodology, the device technology, and clinical application area. Their CV should be kept on file and declarations of interest documented.
Equivalence should be demonstrated based on technical, biological, and clinical characteristics according to MDCG 2020-5 guidance. Consider similar design, conditions of use, materials, clinical applications, and target populations. Predicate devices should be CE-marked or have justified regulatory status.
Valid clinical association is the extent to which the software's output is associated with the targeted physiological state or clinical condition. It should be well-founded or clinically accepted and includes validation of both technical performance (accuracy and reliability) and clinical performance (clinically relevant outcomes).
Clinical evaluation should be updated at least annually for devices carrying significant risks or not yet well established, or every 2-5 years for well-established devices with lower risk profiles. Class I devices typically require updates every 5 years while Class IIA and above devices need annual to biennial updates.
PMCF provides ongoing clinical evidence to verify continued safety and performance during market use. It feeds into regular clinical evaluation updates and can identify new risks or confirm clinical benefits. PMCF data helps maintain the benefit-risk assessment and may trigger corrective actions if safety issues arise.
# SOP Cybersecurity
Source: https://docs.withdovetail.com/tasks/sop-cybersecurity
Implement comprehensive cybersecurity frameworks protecting medical devices from cyber threats throughout device lifecycles.
## Summary
The Standard Operating Procedure (SOP) for Cybersecurity establishes systematic processes to protect Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD) from cyber threats throughout their lifecycle. This SOP ensures compliance with regulatory cybersecurity requirements while safeguarding patient safety and device functionality through robust security controls, threat modeling, and continuous monitoring.
## Why is SOP Cybersecurity important?
Cybersecurity for medical devices exists because modern healthcare technology faces increasing threats from malicious actors who can compromise patient safety, steal sensitive health data, or disrupt critical medical functions. Regulatory authorities require cybersecurity measures because **cyber attacks on medical devices can directly harm patients** - imagine malware disabling an insulin pump or hackers accessing patient medical records. The SOP Cybersecurity framework ensures you systematically identify vulnerabilities, implement protective measures, and maintain security throughout your device's lifecycle. This is crucial for your certification because regulators need evidence that you've proactively considered and mitigated cybersecurity risks before your device reaches patients.
## Regulatory Context
Under **FDA's Cybersecurity Guidance** (2023):
* **Premarket cybersecurity submissions** are mandatory for all connected medical devices
* Must include **threat modeling** and cybersecurity risk assessment in your submission
* Requires **Software Bill of Materials (SBOM)** listing all software components
* **Postmarket monitoring** and patch management plans are required
* Device labeling must include **cybersecurity information** for users
**Special attention required for:**
* Legacy device updates with new connectivity features
* Cloud-connected devices requiring data encryption
* Devices using third-party software components
* Internet-of-Things (IoT) medical devices with wireless connectivity
Under **EU MDR 2017/745**:
* **General Safety and Performance Requirement 17.2** mandates cybersecurity measures
* Must demonstrate cybersecurity throughout device lifecycle in **Technical Documentation**
* **MDCG 2019-16 guidance** provides specific cybersecurity implementation requirements
* Post-market surveillance must include **cybersecurity incident monitoring**
**Special attention required for:**
* Data protection compliance with GDPR requirements
* Secure software development lifecycle documentation
* Third-party component security assessment
* Incident reporting to competent authorities within required timeframes
## Guide
### Establishing Your Cybersecurity Framework
Your SOP Cybersecurity must address cybersecurity systematically across your entire device lifecycle. Start by creating a **cybersecurity risk management plan** that defines how you'll identify, assess, and mitigate security threats. This plan should integrate with your overall risk management process and consider both technical vulnerabilities and human factors that could lead to security breaches.
### Threat Modeling and Risk Assessment
Conduct comprehensive **threat modeling** to identify potential attack vectors against your device. Consider threats like unauthorized access, malware injection, denial-of-service attacks, and data interception. For each identified threat, assess the **likelihood of occurrence** and **severity of impact** on patient safety and device functionality. Document your threat analysis methodology and ensure it covers all device interfaces, communication channels, and data handling processes.
### Security Controls Implementation
Implement appropriate **risk control measures** based on your threat assessment. Essential controls include **data encryption** both in transit and at rest, **multi-factor authentication** for administrative access, **secure boot processes**, and **software integrity verification**. For networked devices, implement **network segmentation** and **intrusion detection** capabilities. Document how each control addresses specific identified risks and provide evidence of their effectiveness.
### Secure Development Practices
Integrate cybersecurity into your **software development lifecycle** (SDLC) through secure coding practices, automated security testing, and regular code reviews. Use **static analysis tools** to identify potential vulnerabilities in your code and implement **dynamic testing** to verify security controls function correctly. Maintain a **software bill of materials** (SBOM) listing all third-party components and their security status.
### Premarket Documentation Requirements
Your premarket submission must include a **cybersecurity summary** documenting your risk assessment, implemented controls, and validation testing results. Include your **threat model**, evidence of security testing, and plans for maintaining cybersecurity post-market. Address how users should configure and maintain device security, including guidance on software updates and security incident reporting.
### Post-Market Monitoring and Response
Establish continuous **post-market surveillance** to monitor emerging cybersecurity threats affecting your device. Create an **incident response plan** detailing how you'll detect, contain, and remediate security incidents. Implement a **patch management process** for delivering security updates while maintaining device integrity and regulatory compliance. Monitor cybersecurity databases and threat intelligence sources for vulnerabilities affecting your device or its components.
### Training and Documentation
Train all personnel involved in device design, development, and maintenance on cybersecurity best practices and regulatory requirements. Maintain comprehensive documentation of all cybersecurity activities, including risk assessments, control implementations, testing results, and incident responses. This documentation supports regulatory submissions and demonstrates ongoing compliance with cybersecurity requirements.
## Example
### Scenario:
You're developing a connected glucose monitoring app that transmits patient data to healthcare providers. During threat modeling, you identify risks including data interception during transmission, unauthorized access to patient accounts, and potential injection of false glucose readings. You implement AES-256 encryption for data transmission, OAuth 2.0 with multi-factor authentication for user access, and digital signatures to verify data integrity. Security testing includes penetration testing of the mobile app, vulnerability scanning of cloud infrastructure, and validation that encrypted data cannot be decrypted by unauthorized parties. Your incident response plan includes procedures for isolating compromised accounts, notifying affected users and healthcare providers, and reporting significant incidents to regulatory authorities within required timeframes.
### Example SOP Structure:
**SOP Cybersecurity Document**
**1. Purpose and Scope**
This SOP establishes cybersecurity processes for protecting our connected glucose monitoring system from cyber threats throughout its lifecycle, ensuring patient data confidentiality and device functionality integrity.
**2. Cybersecurity Risk Management Framework**
* Risk assessment methodology using NIST Cybersecurity Framework
* Threat modeling process for identifying attack vectors
* Risk control selection criteria based on impact and likelihood
* Residual risk acceptance criteria and approval process
**3. Secure Development Requirements**
* Mandatory security training for all developers
* Static analysis tools integrated into build pipeline
* Security code review requirements for all changes
* Vulnerability testing protocols for each software release
**4. Premarket Security Validation**
* Penetration testing scope and methodology
* Data encryption validation procedures
* Authentication system testing protocols
* Security control effectiveness verification
**5. Post-Market Monitoring and Response**
* Continuous monitoring of cybersecurity threat databases
* Incident detection and classification procedures
* Security patch development and deployment process
* Regulatory reporting requirements and timelines
**6. Documentation and Training**
* Required cybersecurity documentation and retention periods
* Staff training requirements and competency verification
* External stakeholder communication procedures
* Regulatory submission documentation requirements
## Q\&A
Start with a systematic threat modeling approach using frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Map all device interfaces including network connections, user interfaces, APIs, and physical ports. Consider threats from different actor types: external attackers, malicious insiders, and unintentional user errors. Review cybersecurity incidents affecting similar devices and analyze vulnerabilities in third-party components you're using.
Conduct penetration testing to simulate real-world attacks against your device and supporting infrastructure. Perform vulnerability scanning using automated tools to identify known security weaknesses. Test authentication mechanisms to ensure they cannot be bypassed or compromised. Validate that data encryption works correctly and cannot be easily broken. Conduct fuzz testing to identify how your device handles malformed inputs that could be used in attacks.
Maintain a Software Bill of Materials (SBOM) listing all third-party components including operating systems, libraries, and frameworks. Monitor security advisories for each component and track when security patches are available. Establish criteria for evaluating the security posture of third-party vendors. Document how you assess and mitigate risks from third-party components, including plans for updating or replacing components with known vulnerabilities.
Define clear incident classification criteria based on severity and impact on patient safety. Establish communication procedures for notifying internal teams, customers, and regulatory authorities. Include steps for containing the incident, preserving evidence, and analyzing root causes. Document recovery procedures to restore normal operations while preventing reoccurrence. Specify timelines for each response phase and identify responsible personnel for each action.
Monitor cybersecurity threat intelligence sources regularly for new vulnerabilities affecting your device or its components. Establish partnerships with cybersecurity research organizations and participate in information sharing initiatives. Track security incidents reported by users and analyze patterns that might indicate systemic vulnerabilities. Maintain the capability to rapidly deploy security patches while ensuring they don't compromise device safety or effectiveness.
# SOP Deployment
Source: https://docs.withdovetail.com/tasks/sop-deployment
Coordinate controlled deployment processes for medical device software installation, integration, and monitoring.
## Summary
This Standard Operating Procedure (SOP) establishes comprehensive processes for **production, deployment, installation, and integration** of medical device software into customer environments. It ensures that validated software builds are properly installed, configured, and monitored while maintaining compliance with quality management requirements for production and service provision.
## Why is SOP Deployment important?
**Deployment control** is critical because medical device software must maintain its validated state when moved from development environments to customer production systems. Even properly validated software can fail to perform as intended if deployment processes introduce configuration errors, infrastructure incompatibilities, or validation gaps.
This SOP is essential because deployment represents the **transition point** where theoretical validation becomes real-world performance. Without controlled deployment processes, validated software might be incorrectly installed, improperly configured, or placed in environments that compromise its safety and effectiveness. Regulatory authorities require manufacturers to maintain control over production and service provision, including installation and integration activities.
**Infrastructure qualification** ensures that customer environments can properly support your medical device software, while **deployment monitoring** provides ongoing verification that devices continue to operate as intended in their production environments.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Section **820.70** requires production and process controls to ensure devices conform to specifications
* Section **820.170** mandates installation procedures and verification for devices requiring installation
* Section **820.200** requires servicing procedures including updates and maintenance
* Deployment must maintain **design control** integrity established under 820.30
**Production control requirements**:
* **Documented procedures** for deployment, installation, and integration
* **Qualification of infrastructure** where necessary for device performance
* **Monitoring and measurement** of deployment processes and device performance
* **Version control** and traceability of deployed software builds
**Special attention required for:**
* Installation verification and validation procedures
* Configuration management during deployment
* User training requirements for deployed devices
* Documentation of deployment activities and outcomes
Under **EU MDR 2017/745**:
* **Article 10(9)** requires quality management system implementation including production controls
* **Annex I Section 14** specifies construction and manufacturing requirements
* Deployment must maintain **CE marking** validity and device conformity
* **Post-market surveillance** must monitor deployed device performance
**EU-specific considerations**:
* Deployment processes must support **continuous compliance** with essential requirements
* **Technical file** documentation must reflect actual deployment configurations
* **PRRC oversight** required for significant deployment or configuration changes
* **Data protection** compliance (GDPR) for deployment and removal activities
**Special attention required for:**
* Maintaining conformity assessment validity during deployment
* Customer environment qualification for CE marked devices
* Data privacy and security during deployment and removal
* Post-market surveillance data collection from deployed devices
## Guide
### Understanding Deployment Scope and Risk Assessment
**Deployment complexity** varies significantly based on your device type, customer environment, and integration requirements. **Simple deployments** might involve installing software on standard computing platforms with minimal configuration. **Complex deployments** might require custom hardware interfaces, integration with existing clinical systems, or specialized infrastructure qualification.
**Risk-based approach** to deployment planning considers the potential impact of deployment failures on device safety and effectiveness. High-risk deployments require more rigorous qualification, testing, and monitoring procedures.
**Infrastructure assessment** determines whether customer environments can properly support your device. Evaluate computing resources, network requirements, security controls, backup systems, and integration interfaces needed for proper device operation.
### Implementing Build Control and Release Management
**Validated build control** ensures that only properly tested and approved software versions are deployed to customer environments. Establish clear criteria for release readiness including completion of verification and validation activities, approval of all required documentation, and confirmation of regulatory compliance.
**Version traceability** maintains clear records of which software versions are deployed where. Use unique version identifiers that connect deployed software to specific development records, test results, and approval documentation.
**Configuration management** documents any environment-specific settings or customizations required for proper device operation. Version control these configurations and maintain traceability to base software versions.
**Release approval process** requires appropriate authorization before deployment occurs. Ensure business teams verify correct versions are being deployed and have authority to approve customer-specific deployments.
### Establishing Infrastructure Qualification Procedures
**Qualification requirements** depend on infrastructure complexity and risk level. **Well-defined, controlled environments** (such as standard cloud platforms) may require minimal qualification if their characteristics are well-understood and validated during development. **Custom or complex environments** require formal qualification to ensure they can support device operation.
**Deployment Evaluation Checklist** provides systematic assessment of infrastructure requirements, qualification needs, installation procedures, and acceptance criteria. Complete this assessment before beginning deployment activities.
**Installation qualification** verifies that infrastructure can support device requirements including computing resources, network connectivity, security controls, and integration interfaces. Document qualification criteria and test results.
**Performance qualification** confirms that devices operate correctly in the qualified infrastructure. Establish acceptance criteria for device performance and functionality verification.
### Managing Installation and Integration Processes
**Installation planning** defines step-by-step procedures for deploying device software into customer environments. Include pre-installation requirements, installation sequence, configuration steps, and post-installation verification activities.
**Pre-defined acceptance criteria** establish clear standards for successful installation. Define measurable criteria for device functionality, performance, integration, and user access that must be met before considering installation complete.
**Installation documentation** records all activities performed during deployment including configuration settings, test results, identified issues, and resolution actions. This documentation supports troubleshooting and provides evidence of proper installation procedures.
**Failure recovery procedures** define actions to take when installations don't meet acceptance criteria. Include rollback procedures, issue diagnosis methods, and escalation processes for complex problems.
### Implementing Deployment Monitoring and Measurement
**Performance monitoring** establishes ongoing surveillance of deployed device operation. This might include automated monitoring systems, regular performance reports, or manual check-ins with customers to verify continued proper operation.
**Issue reporting channels** ensure customers can quickly report device problems or performance issues. Establish clear communication procedures and response timeframes for different types of issues.
**User training verification** confirms that device users receive appropriate training before beginning device use. Training should cover device operation, safety precautions, and proper procedures as defined in Instructions for Use.
**Customer support processes** provide ongoing assistance for deployed devices including technical support, user questions, and performance optimization guidance.
### Managing Updates and Maintenance
**Update deployment** for existing installations requires careful planning to minimize disruption while ensuring continued device compliance. Evaluate whether updates require additional integration steps, infrastructure changes, or user retraining.
**Change impact assessment** determines the scope of validation and qualification required for software updates. Major changes may require repeating portions of the deployment qualification process.
**Customer notification** procedures ensure users are informed about updates, potential system downtime, and any required actions on their part. Provide appropriate advance notice and clear instructions.
**Update verification** confirms that deployed updates function correctly and maintain device compliance. Include regression testing appropriate to the scope of changes.
### Handling Device Removal and Data Management
**Removal procedures** ensure complete and secure device removal when customer contracts end or devices are replaced. Include verification that devices are fully non-operational and customer data is handled appropriately.
**Data migration and archival** processes protect customer data while complying with data protection regulations. Coordinate with customers to ensure their data needs are met during device removal.
**GDPR compliance** requires careful handling of personal data during deployment and removal activities. Ensure appropriate data protection measures are implemented throughout the device lifecycle.
**Removal verification** confirms that devices are completely removed from customer systems and no longer accessible or functional. Document removal activities and verify customer satisfaction with the process.
## Example
### Scenario
You're deploying a cloud-based medical device software application to a hospital's clinical environment. The software integrates with the hospital's electronic medical record (EMR) system and requires specific security and performance configurations. Here's how the deployment process applies:
**Pre-Deployment Assessment**: Complete Deployment Evaluation Checklist to assess hospital infrastructure including network security, EMR integration capabilities, user access controls, and backup systems. Determine that infrastructure qualification is required due to custom EMR integration.
**Infrastructure Qualification**: Verify hospital's network meets security requirements, EMR integration APIs function correctly, required computing resources are available, and backup/disaster recovery systems are operational. Document qualification test results and acceptance criteria.
**Installation Planning**: Create detailed installation plan including software deployment sequence, EMR integration configuration, user account setup, security configuration, and performance verification procedures. Define specific acceptance criteria for each installation step.
**Deployment Execution**: Deploy validated software build v2.3.1 to hospital's qualified infrastructure, configure EMR integration with proper authentication, set up user accounts and permissions, conduct installation verification testing.
**Installation Verification**: Confirm software operates correctly, EMR integration functions properly, users can access required functions, performance meets specifications, and security controls are active. Document all verification activities and results.
**User Training and Go-Live**: Provide user training per Instructions for Use, establish ongoing support procedures, activate monitoring and reporting systems, and formally transfer device to production status.
### Example Deployment Documentation
**Installation Plan for Regional Medical Center**:
* **Software Version**: MedDevice v2.3.1 (Build 2024.03.15.001)
* **Target Environment**: Hospital private cloud infrastructure
* **EMR Integration**: Epic EHR v2023.2 via HL7 FHIR API
* **User Population**: 50 clinicians across 3 departments
**Infrastructure Qualification Results**:
* Network security assessment: PASSED - Meets HIPAA requirements
* Computing resources: PASSED - 99.9% uptime, sufficient capacity
* EMR integration testing: PASSED - All required APIs functional
* Backup systems: PASSED - 24-hour recovery time objective met
* User authentication: PASSED - Single sign-on integration successful
**Installation Verification Checklist**:
* ✓ Software deployment completed successfully
* ✓ Database initialization and data migration verified
* ✓ EMR integration functional testing passed
* ✓ User access and permissions configured correctly
* ✓ Performance benchmarks met (response time \<2 seconds)
* ✓ Security controls active and verified
* ✓ Monitoring and alerting systems operational
**Post-Installation Activities**:
* User training completed for all 50 clinicians
* Customer support contact information provided
* Monitoring dashboard access configured
* First month performance review scheduled
* Update notification procedures established
## Q\&A
**Infrastructure qualification** is required when customer environments are complex, non-standard, or when deployment failures could impact device safety or effectiveness. **Standard, well-controlled environments** (like certified cloud platforms) may not require formal qualification if their characteristics are well-understood and validated during development. Use your **Deployment Evaluation Checklist** to systematically assess qualification needs.
Document **installation plans**, infrastructure qualification results, installation verification activities, user training completion, and ongoing monitoring procedures. Maintain records of **which software versions** are deployed where, configuration settings used, and any customer-specific customizations. This documentation supports regulatory compliance and troubleshooting activities.
**Software updates** require evaluation of change impact, infrastructure compatibility, and validation requirements. Minor updates may use simplified procedures, while **major changes** might require repeating portions of infrastructure qualification. Always notify customers appropriately, minimize system downtime, and verify update success after deployment.
You need sufficient **oversight** to ensure deployed devices continue operating as validated, but customer environments remain under customer control. Focus on **device-specific requirements** like computing resources, security controls, and integration interfaces rather than trying to control entire customer IT environments. Establish clear requirements and monitoring procedures.
Implement **appropriate monitoring** based on device complexity and risk level. This might include automated performance monitoring, regular customer check-ins, issue reporting systems, or periodic verification activities. The monitoring level should be **proportional to safety risk** and deployment complexity.
User training must cover **safe and effective use** as defined in your Instructions for Use. Training should be provided before device use begins and updated when software changes affect user procedures. Document training completion and maintain records of who has been trained on which software versions.
**Device removal** requires complete deactivation of software functionality, secure data handling per GDPR requirements, and verification that devices are no longer operational. Coordinate with customers for **data migration or archival** needs, document removal activities, and confirm customer satisfaction with the removal process.
If **installation verification** doesn't meet predefined acceptance criteria, stop the installation process and investigate root causes. You may attempt **repairs or adjustments** to meet criteria, but if acceptance criteria still can't be met, consider the installation **failed** and implement recovery procedures. Document all attempts and decisions made.
# SOP Design Control
Source: https://docs.withdovetail.com/tasks/sop-design-control
Deploy systematic design control frameworks for safe and effective medical device development from concept to market.
## Summary
Your **Design Control** SOP establishes a systematic framework for medical device development from concept through post-market activities, ensuring that your device meets user needs, regulatory requirements, and safety standards through controlled design inputs, outputs, verification, validation, and transfer processes.
## Why is SOP Design Control important?
Design controls exist because regulators require **systematic evidence** that medical devices are designed safely and effectively before reaching patients. Without structured design controls, organizations risk developing devices that don't meet user needs, fail safety requirements, or cannot demonstrate regulatory compliance during submission reviews.
The SOP ensures **traceability and risk mitigation** by establishing clear phases, deliverables, and approval gates that connect user needs through design outputs to verification evidence. It transforms device development from an ad-hoc engineering exercise into a **regulated process** that builds confidence with regulators, customers, and internal stakeholders.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design controls are **mandatory** under Section 820.30 for Class II and III devices
* Must establish procedures for **design inputs, outputs, review, verification, validation, transfer, and changes**
* Design History File (DHF) must be **maintained** with evidence of design control compliance
* Each design phase must have **appropriate approvals** before proceeding
**Special attention required for:**
* Software medical devices require special design control considerations
* Design verification vs. validation distinction (820.30(f) vs 820.30(g))
* Design transfer requirements (820.30(h)) before production
* Design change control (820.30(i)) for post-market modifications
Under **EU MDR 2017/745**:
* Design controls required as part of **quality management system** (Article 10(9))
* Must comply with **EN ISO 13485:2016** design and development requirements (Section 7.3)
* Risk management must be **integrated** throughout design process (Article 10(2))
* Technical documentation must demonstrate **design control compliance** (Annex II)
**Special attention required for:**
* Clinical evaluation integration throughout design process (Article 61)
* Post-market surveillance planning during design (Articles 83-86)
* Essential requirements compliance demonstration (Annex I)
* Notified body involvement for higher-risk devices
## Guide
Your Design Control SOP establishes the **systematic approach** to device development that regulators expect. Structure the process in clear phases with defined inputs, outputs, and decision points.
### Phase 1: Planning and Design Inputs
Begin with **comprehensive planning** that defines project scope, timeline, resources, and responsibilities. This phase is critical because poor planning leads to scope creep, timeline delays, and incomplete requirements capture.
Gather **complete design inputs** including user needs, intended use specifications, regulatory requirements, applicable standards, and performance requirements. Ensure inputs are complete, unambiguous, and verifiable. Incomplete or vague design inputs lead to design outputs that cannot be properly verified.
Conduct thorough **risk analysis planning** early to identify potential hazards and establish risk management strategy. Early risk identification enables proactive design decisions rather than reactive corrections later in development.
### Phase 2: Design Development and Outputs
Develop **detailed design outputs** that directly address each design input. Outputs should include specifications, drawings, software architecture, procedures, and any other documentation needed to manufacture and test the device.
Ensure **traceability** between design inputs and outputs through systematic documentation. Each design input should map to specific design outputs, and each output should trace back to inputs. This traceability is critical for regulatory submissions and audits.
Implement **design transfer planning** early to ensure manufacturing feasibility. Consider how design outputs will translate into manufacturing procedures, quality controls, and commercial production capabilities.
### Phase 3: Verification and Validation
Conduct **design verification** to confirm that design outputs meet design inputs. This typically involves testing against specifications, requirements verification, and objective measurement against predetermined criteria.
Perform **design validation** to confirm the device meets user needs and intended use in realistic conditions. Validation often involves clinical studies, usability testing, or real-world performance evaluation with actual users.
Execute **risk management verification** to confirm that risk controls are effective and residual risks are acceptable. This includes verification of risk control measures and validation of overall risk management effectiveness.
### Phase 4: Design Transfer and Release
Complete **design transfer** to manufacturing by ensuring production processes can consistently produce devices meeting design specifications. This includes process validation, manufacturing procedure development, and quality control establishment.
Conduct **market release activities** including regulatory submission preparation, post-market surveillance planning, and commercial readiness verification. Ensure all regulatory requirements are met before commercial distribution.
Establish **post-market monitoring** procedures to collect performance data and identify potential issues requiring design changes or safety updates.
### Integration with Other QMS Processes
Connect design control outputs to **risk management, verification and validation, change control, and post-market surveillance** processes. Design controls should not operate in isolation but integrate with your broader quality management system.
## Example
### Scenario
MedDevice Corp develops a wearable glucose monitoring system for diabetes management. They implement design controls to systematically progress from user needs identification through regulatory clearance and commercial launch while ensuring safety and effectiveness throughout the process.
### Example Design Control Implementation
**Phase 1: Planning and Inputs**
* **User Needs:** "Patients need continuous glucose monitoring without finger pricks"
* **Design Inputs:** Accuracy ±15%, 14-day wear time, waterproof to 1 meter, smartphone connectivity
* **Regulatory Strategy:** FDA 510(k) submission with predicate device comparison
* **Risk Management Plan:** Risk assessment covering sensor accuracy, skin irritation, data security
**Phase 2: Design and Development**
* **Design Outputs:** Sensor specifications, algorithm requirements, mobile app design, packaging design
* **Traceability Matrix:** Links each design input to specific outputs and verification methods
* **Supplier Management:** Qualify sensor component suppliers and adhesive manufacturers
* **Design Transfer Plan:** Manufacturing process definition and quality control procedures
**Phase 3: Verification and Validation**
* **Verification Testing:** Laboratory accuracy testing, environmental conditioning, electromagnetic compatibility
* **Validation Studies:** Clinical accuracy study with 100 diabetic patients over 14 days
* **Usability Validation:** Human factors testing with intended users in simulated home environment
* **Risk Control Verification:** Confirm sensor alarm functionality and data encryption effectiveness
**Phase 4: Transfer and Release**
* **Manufacturing Validation:** Process validation at contract manufacturer facility
* **510(k) Submission:** FDA submission with verification and validation evidence
* **Commercial Readiness:** Post-market surveillance procedures, customer support training
* **Market Launch:** Product registration in GUDID database with assigned UDI
**Phase 5: Post-Market Activities**
* **Performance Monitoring:** Customer complaint analysis and adverse event reporting
* **Design Change Control:** Systematic evaluation of proposed improvements or issue corrections
* **Continuous Improvement:** Annual design review incorporating post-market data
## Q\&A
Design changes after market release must follow systematic change control procedures that evaluate the impact on safety, effectiveness, and regulatory status. Major changes may require new regulatory submissions, while minor changes may only need internal documentation. All changes should be evaluated through your risk management process.
Design verification confirms that design outputs meet design inputs - essentially "did we build it right?" Validation confirms that the device meets user needs and intended use - "did we build the right thing?" Both are required but address different aspects of design assurance.
Software medical devices require special consideration in design controls, including software lifecycle processes, risk management for software, cybersecurity considerations, and appropriate verification and validation methods. Follow IEC 62304 for software lifecycle processes within your design control framework.
Design reviews should be conducted at key milestones throughout the design process, typically at the end of each phase before proceeding to the next. Reviews should include appropriate stakeholders and document decisions, action items, and approval to proceed.
Risk management should be integrated throughout all design control phases, starting with hazard identification in planning, continuing through risk control implementation in design development, and concluding with risk control verification and post-market risk monitoring.
The Design History File should contain all documentation demonstrating compliance with design control requirements, including design inputs, outputs, review records, verification and validation protocols and reports, design transfer documentation, and design change records.
# SOP Document and Record Control
Source: https://docs.withdovetail.com/tasks/sop-document-record-control
Structure systematic document control procedures for quality management system compliance and information integrity.
## Summary
Your **Document and Record Control** SOP establishes systematic procedures for creating, reviewing, approving, distributing, and maintaining all quality management system documents and records to ensure regulatory compliance and effective information management throughout your organization.
## Why is SOP Document and Record Control important?
Document control exists because regulators require **controlled processes** to ensure that teams use current, approved procedures and that evidence of compliance is properly maintained. Without systematic document control, organizations risk using outdated procedures, losing critical records, or failing to demonstrate regulatory compliance during audits.
The SOP ensures **consistency and traceability** by establishing clear naming conventions, approval workflows, retention requirements, and access controls. It transforms document management from an administrative burden into a **strategic enabler** that supports quality decision-making and regulatory confidence.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Document controls are **mandatory** under Section 820.40
* Must ensure **current revisions** are available at points of use
* Document changes must be **reviewed and approved** by same function that performed original review
* Records must be **maintained** to demonstrate conformity (820.180)
**Special attention required for:**
* Design History File (DHF) document control requirements (820.30(j))
* Device Master Record (DMR) control (820.181)
* Device History Record (DHR) maintenance (820.184)
* Electronic record requirements if using electronic systems (21 CFR Part 11)
Under **EU MDR 2017/745**:
* Document control required as part of **quality management system** (Article 10(9))
* Must comply with **EN ISO 13485:2016** Sections 4.2.4 and 4.2.5
* Technical documentation must be **maintained and updated** (Article 11)
* Records must be available for **notified body assessment**
**Special attention required for:**
* Technical file maintenance and updates (Annex II)
* Post-market surveillance documentation (Articles 83-86)
* Clinical evaluation documentation control (Article 61)
* UDI database information maintenance (Article 27)
## Guide
Your Document and Record Control SOP establishes the **foundation** for all other QMS processes. Design the system to be practical and scalable while ensuring regulatory compliance.
### Document Classification and Naming
Establish **clear document categories** such as SOPs, work instructions, templates, lists, and records. Create a systematic naming convention that includes functional group, document type, unique identifier, revision number, and descriptive name. This ensures consistent identification and retrieval.
Use a standardized approach like `QA-SOP-[UUID].01-Document Control` to provide immediate context about document ownership, type, and version. Train all team members on the naming convention to ensure consistency across the organization.
### Approval Workflows and Authority
Define **approval authority** based on document type and impact. Quality system documents typically require quality management approval, while technical documents may need engineering and quality review. Establish clear approval matrices that specify who must approve different document types.
Implement approval workflows that ensure **appropriate review** without creating bottlenecks. Consider parallel approvals for documents requiring multiple reviewers. Document the rationale for approval authority assignments so auditors understand your decision-making process.
### Version Control and Change Management
Implement **rigorous version control** to prevent use of obsolete documents. Use revision numbers that clearly indicate document status and ensure only current versions are accessible at points of use. Archive previous versions while maintaining retrieval capability for regulatory purposes.
Establish change control procedures that require **justification for changes**, impact assessment, and appropriate approvals. Minor editorial changes may require different approval than substantive procedural changes. Document the change rationale and ensure affected personnel are notified.
### Electronic System Implementation
If using electronic document management systems, ensure they meet **regulatory requirements** for electronic records. Implement access controls, audit trails, and backup procedures. Consider FDA 21 CFR Part 11 requirements if operating under FDA jurisdiction.
Establish procedures for **system maintenance**, user access management, and data integrity verification. Include contingency plans for system failures that ensure continued access to critical documents during emergencies.
### Record Retention and Disposal
Establish **retention periods** that meet or exceed regulatory requirements. Quality records typically require retention for device lifetime plus additional years, while some records may have specific regulatory timeframes. Create retention schedules that are practical to implement and monitor.
Implement secure disposal procedures for records reaching end-of-life. Ensure confidential information is properly destroyed while maintaining evidence of disposal for audit purposes. Consider legal holds that may extend retention beyond normal schedules.
## Example
### Scenario
DeviceTech Systems implements an electronic document management system to control their quality procedures, work instructions, and technical documentation. They establish naming conventions, approval workflows, and retention schedules to ensure regulatory compliance while enabling efficient operations.
### Example Document Control System
**Document Categories and Naming:**
* Quality SOPs: `QA-SOP-[UUID].01-Risk Management`
* Software Procedures: `SW-TCD-[UUID].01-Code Review Checklist`
* Training Records: `CP-RCD-[UUID].01-Employee Training Log`
* Technical Reports: `TD-TCD-[UUID].01-Verification Testing Report`
**Approval Matrix:**
* **Quality SOPs:** Quality Manager + Management Representative
* **Technical Documents:** Technical Lead + Quality Manager
* **Training Materials:** HR Manager + Quality Manager
* **Work Instructions:** Process Owner + Quality Representative
**Version Control Process:**
1. **Draft Creation** - Author creates document in "Draft" status
2. **Review Cycle** - Reviewers provide feedback in document review system
3. **Approval Process** - Sequential or parallel approvals based on document type
4. **Release** - Approved document moves to "Active" status, previous version archived
5. **Change Management** - Changes require change request with impact assessment
**Electronic System Features:**
* Role-based access controls limiting editing permissions
* Automated approval workflows with email notifications
* Audit trail tracking all document activities and user actions
* Automated archival of superseded versions
* Search functionality by document type, owner, or content
**Retention Schedule:**
* Quality system documents: 10 years after archival
* Technical documentation: Device lifetime + 10 years
* Training records: Employee tenure + 7 years
* Audit records: 10 years after completion
## Q\&A
Updates to the EQMS documentation system should include proper change management with impact assessment, appropriate approvals, and notification to affected users. The current setup should remain compliant while changes aim at improving the process. Maintain version control and audit trails for all system changes.
Formly uses an electronic quality management system (EQMS) for document approvals. Documents are considered live once approved through the established workflow. Drafts can be created and revised multiple times without regulatory compliance issues until final approval and release.
Quality management system documents and records should be stored for at least 10 years after their archival date. Technical documentation, DHF, DHR, and QMS documents should be stored for at least the device lifetime plus additional years as specified by regulatory requirements, but not less than two years from device release.
External documents should be properly identified and controlled through suitable identification procedures. They must be prevented from unintended use of obsolete versions and remain legible and readily identifiable. Establish procedures for monitoring external document updates and ensuring current versions are used.
Implement role-based access controls that limit document access to authorized personnel only. Protect confidential health information in accordance with relevant regulatory requirements. Establish user access management procedures and regular access reviews to ensure appropriate permissions.
All document changes should be identified through version control, change summaries, and audit trails. Maintain revision histories that clearly show what changed, who made the change, when it was made, and why. Use change control procedures that require impact assessment and appropriate approvals for modifications.
# SOP Feedback and Complaint Management
Source: https://docs.withdovetail.com/tasks/sop-feedback-management
Handle customer feedback and complaints through systematic investigation, resolution, and corrective action processes.
## Summary
Your **Feedback and Complaint Management** SOP establishes systematic processes for receiving, categorizing, investigating, and resolving customer feedback and complaints to ensure device-related issues are identified early, properly escalated, and addressed through appropriate corrective actions.
## Why is SOP Feedback and Complaint Management important?
Feedback and complaint management exists because customer experiences provide **real-world intelligence** about device performance that cannot be captured through pre-market testing alone. It serves as an early warning system for potential safety issues, quality problems, and usability concerns that could impact patient outcomes or regulatory compliance.
Your feedback and complaint system demonstrates **proactive customer focus** rather than reactive problem-solving. It transforms scattered customer communications into systematic data that drives product improvements, informs risk management decisions, and supports post-market surveillance requirements. This protects patients while building trust through responsive customer service.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Complaint handling **mandatory** under Section 820.198
* Must maintain **complaint files** with investigation records
* Serious injuries and deaths require **MDR reporting** (21 CFR Part 803)
* Complaint analysis required for **corrective action** evaluation
* Integration with design controls and management review required
**Special attention required for:**
* MDR reporting timelines: 24 hours for deaths, 10 days for serious injuries
* Complaint file maintenance and investigation documentation
* Trending analysis for CAPA qualification
* Integration with post-market surveillance and labeling updates
Under **EU MDR 2017/745**:
* Complaint management required for **post-market surveillance** (Articles 83-86)
* Must classify and investigate **all device-related complaints**
* Serious incidents require **vigilance reporting** within specified timelines
* Integration with **trend reporting** requirements (Article 88)
* PRRC oversight and **systematic complaint analysis** required
**Special attention required for:**
* Vigilance reporting timelines and EUDAMED submissions
* Classification of incidents versus complaints for reporting purposes
* Integration with PMCF and clinical evaluation updates
* Trend analysis and statistical significance determination
## Guide
Your Feedback and Complaint Management SOP establishes **systematic customer communication** processes that capture valuable intelligence while ensuring regulatory compliance. Focus on creating efficient workflows that provide meaningful insights without overwhelming your team.
### Feedback and Complaint Classification and Triage
Implement **systematic classification** procedures that distinguish between general feedback, customer support requests, formal complaints, and serious incidents. Create clear definitions and examples for each category to ensure consistent handling across your organization. This classification drives appropriate response procedures and reporting requirements.
Establish triage procedures that route different feedback and complaint types to appropriate team members with defined response timelines. Include escalation criteria for issues requiring immediate attention such as safety concerns or serious incidents requiring regulatory reporting.
### Complaint Logging and Documentation
Create **standardized complaint logging** procedures that capture essential information including customer details, product information, incident description, impact assessment, and resolution actions. Implement systematic numbering and tracking to ensure no complaints are lost or forgotten.
Design complaint log templates that facilitate efficient data entry while ensuring completeness for regulatory requirements. Include fields for trending analysis and integration with other quality processes such as CAPA and post-market surveillance.
### Investigation and Resolution Procedures
Establish **systematic investigation** procedures appropriate for different complaint types. Technical issues may require engineering analysis, while safety concerns require risk assessment and potential regulatory reporting. Create investigation workflows that involve appropriate subject matter experts.
Develop resolution procedures that address root causes rather than just symptoms. Include customer communication requirements, timeline expectations, and criteria for determining when additional actions such as CAPA initiation are necessary.
### Integration with Quality System
Connect feedback and complaint management to **all relevant quality processes** including CAPA, post-market surveillance, risk management, and vigilance reporting. Establish clear triggers for escalating complaints to other processes based on severity, frequency, or potential impact.
Include complaint trending analysis in management review reporting to identify systemic issues requiring management attention. Use complaint data to inform product improvement decisions and regulatory update requirements.
### Customer Communication and Service
Establish **professional communication** procedures that acknowledge customer concerns promptly and provide regular updates during investigation. Create templates for common response scenarios while allowing personalization for specific situations.
Develop customer service procedures that resolve simple issues quickly while ensuring potential quality concerns are properly escalated. Include training requirements for customer-facing personnel to recognize and appropriately handle different feedback and complaint types.
## Example
### Scenario
MedTech Solutions receives diverse feedback about their diabetes monitoring app through multiple channels including app store reviews, customer support emails, and direct user communications. They implement systematic procedures to categorize, investigate, and resolve issues while identifying trends that inform product improvements.
### Feedback and Complaint Management Implementation
**Feedback and Complaint Classification System:**
* **General Feedback:** App feature requests, positive reviews, general suggestions
* **Customer Support:** Login difficulties, tutorial requests, account management issues
* **Customer Complaints:** App crashes, inaccurate readings, sync failures affecting device function
* **Serious Incidents:** Delayed insulin decisions due to app malfunction, incorrect glucose trend displays
**Complaint Logging Process:**
**Example Customer Complaint Entry:**
* **Complaint ID:** COMP-2024-045
* **Customer ID:** USER7823
* **Date Received:** March 22, 2024
* **Product Version:** DiabetesCare App v2.1.3
* **Source:** Customer support email
* **Description:** App crashes during glucose trend analysis, requiring restart to view current readings
* **Impact Assessment:** Potential delay in diabetes management decisions
* **Investigation Assigned:** Software development team
* **Resolution Target:** 5 business days
**Investigation and Resolution Workflow:**
1. **Initial Assessment:** Customer support team logs complaint and performs initial severity assessment
2. **Technical Investigation:** Development team reproduces issue and identifies root cause
3. **Risk Evaluation:** Quality team assesses potential safety impact and regulatory reporting requirements
4. **Resolution Implementation:** Software fix developed and tested
5. **Customer Communication:** Customer notified of resolution and provided updated app version
6. **Follow-up Verification:** Customer confirms issue resolution and satisfaction
**Trending Analysis Example:**
**Monthly Complaint Summary:**
* **App Crashes:** 12 complaints (increase from 8 last month)
* **Sync Issues:** 5 complaints (stable trend)
* **Accuracy Concerns:** 2 complaints (decrease from 4 last month)
* **Action Required:** Investigate app crash trend for potential CAPA initiation
**Integration with Quality Processes:**
* **CAPA Qualification:** App crash trend exceeds threshold, CAPA initiated
* **Post-Market Surveillance:** Complaint data included in quarterly PMS report
* **Risk Management:** Safety assessment updates based on complaint patterns
* **Management Review:** Complaint metrics and trends reported quarterly
## Q\&A
Categorize feedback into general feedback (suggestions, positive comments), customer support (usage questions), customer complaints (performance or quality issues), and serious incidents (safety-related events). Use clear definitions and provide training to ensure consistent classification across your organization.
Include complaint ID, customer information, product details, incident description, impact assessment, investigation findings, resolution actions, and closure date. Capture enough detail to support trending analysis, regulatory reporting, and quality improvement decisions while maintaining efficient workflow.
Implement systematic triage procedures with clear escalation criteria. Use automated tools where possible for initial categorization and routing. Focus investigation resources on complaints with safety implications or trending patterns. Consider outsourcing routine customer support to trained providers.
Report serious incidents (deaths, serious injuries, safety-related malfunctions) according to regulatory timelines. For FDA: 24 hours for deaths, 10 days for serious injuries. For EU: immediate reporting for serious incidents through vigilance system. Use systematic criteria to determine reporting requirements.
Establish systematic trending criteria including frequency thresholds, severity assessments, and statistical significance testing. Conduct regular trend analysis and use findings to trigger CAPA investigations, product improvements, or regulatory updates. Include trend data in management review.
Log only complaints related to device performance or safety in your formal complaint log. General feedback and support issues that can be resolved with instructions don't require formal logging. Use systematic categorization and routing to ensure appropriate handling and resource allocation.
# SOP Human Resources and Training
Source: https://docs.withdovetail.com/tasks/sop-human-resources-administration
Organize comprehensive HR frameworks for personnel qualification, training documentation, and competency verification.
## Summary
This Standard Operating Procedure (SOP) defines the comprehensive framework for **human resources management and training** within medical device organizations. It establishes processes for employee qualification, training documentation, competency verification, and ongoing performance management to ensure that all personnel are adequately qualified to maintain product quality and meet regulatory compliance requirements.
## Why is SOP Human Resources and Training important?
**Personnel competency** is fundamental to medical device safety and effectiveness. Regulatory authorities recognize that human error is a significant risk factor in medical device development, manufacturing, and post-market activities. This SOP exists to ensure that your organization maintains a **qualified workforce** capable of consistently producing safe and effective medical devices.
The regulation requires that employees understand their **impact on product quality** and patient safety. Every person in your organization—from software developers to quality assurance personnel—must be competent in their specific roles and understand how their work contributes to the overall quality management system. Without proper training and competency verification, your organization faces increased risks of product defects, regulatory non-compliance, and potential patient harm.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Section **820.25** mandates that personnel performing work affecting product quality must be qualified based on appropriate education, training, skills, and experience
* Must designate a **Management Representative** with established authority over quality system requirements (820.20(b)(3))
* Training effectiveness must be **documented and verified**
* Personnel must understand the **relevance of their activities** to achieving quality objectives
**Special attention required for:**
* Management Representative qualification and authority
* Documentation of training effectiveness verification
* Competency requirements for personnel performing design control activities
* Training records retention as quality records under 820.180
Under **EU MDR 2017/745**:
* Article **10(8)** requires manufacturers to have adequately qualified personnel for quality management activities
* Article **15** mandates a **Person Responsible for Regulatory Compliance (PRRC)** with specific qualification requirements
* Must demonstrate competency through appropriate education, training, skills, and experience
* Germany's **MPDG §83** requires special training for medical device consultants
**Special attention required for:**
* PRRC must have university degree + 1 year experience OR 4 years professional experience
* Medical device consultants in Germany require specialized training
* Training documentation must support technical file requirements
* Personnel competency impacts notified body assessment
## Guide
### Understanding Employee Roles and Qualification Requirements
Your organization must clearly define **every role** that affects product quality. This includes obvious positions like quality managers and design engineers, but also support roles such as IT administrators managing your quality management system or procurement personnel selecting suppliers.
For each role, you need to establish **minimum qualification criteria** based on education, training, skills, and experience. Document these requirements in job descriptions that specify both the **technical competencies** needed (such as knowledge of ISO 13485 or software development practices) and any **regulatory-specific qualifications** required for specialized roles.
The **Quality Team** should maintain oversight of all training and qualification requirements. They determine when additional training is needed and verify that personnel meet the established criteria before assuming new responsibilities.
### Implementing Comprehensive Training Programs
**Initial training** for new employees must cover both role-specific competencies and **quality management system awareness**. Every employee needs to understand how their work impacts product quality and patient safety, even if they don't directly touch the product.
Your training program should include:
* **Document review and comprehension** of relevant SOPs and procedures
* **Hands-on training** for role-specific tasks and responsibilities
* **Quality system overview** showing how individual roles contribute to overall objectives
* **Regulatory awareness** appropriate to each person's responsibilities
Use **multiple training methods** to ensure effective learning: structured sessions, document review with verification, webinars, professional courses, or self-study materials. The key is ensuring each person can demonstrate **competency** in their assigned tasks.
### Documenting and Verifying Training Effectiveness
**Documentation** is critical for regulatory compliance. Maintain records showing what training each person received, when it occurred, and how competency was verified. You can use individual training records or group training documentation for sessions involving multiple employees.
**Verification of training effectiveness** goes beyond simply completing training modules. Supervisors must observe job performance and confirm that employees can properly apply their training. This might include:
* **Performance reviews** evaluating how well training translated to actual work
* **Competency testing** for critical skills or knowledge areas
* **Supervisor observations** during routine work activities
* **Ongoing monitoring** of work quality and compliance
If performance reviews reveal training gaps, immediately address them through additional training or process improvements.
### Managing Specialized Regulatory Roles
**Person Responsible for Regulatory Compliance (PRRC)** requires specific qualifications under EU MDR. This person must have either a university degree in a relevant field plus one year of regulatory or QMS experience, or four years of professional experience in regulatory affairs or quality management systems. Document their qualifications thoroughly as this will be reviewed during notified body assessments.
**Management Representative** under FDA regulations must have established authority over quality system requirements and report directly to executive management. Ensure this person understands both the technical aspects of your quality system and has sufficient organizational authority to implement necessary changes.
### Establishing Ongoing Training and Performance Management
**Continuous training** is required throughout employment, not just during onboarding. Trigger additional training when:
* SOPs or procedures are updated
* Job roles change or expand
* Nonconformities reveal training gaps through root cause analysis
* New regulatory requirements emerge
* Performance reviews identify development needs
Conduct **annual performance reviews** at minimum to identify training needs and verify ongoing competency. Use these reviews to discuss career development, regulatory updates, and any quality system changes affecting the employee's role.
### Maintaining Employee Records and Documentation
Keep comprehensive **employee records** including contracts, qualifications, job descriptions, training records, and performance evaluations. Ensure these records are maintained according to your document control procedures and privacy requirements in your operating jurisdiction.
**Training records** should clearly show the training provided, date completed, competency verification method, and results. These records serve as objective evidence during audits and support your overall quality management system documentation.
## Example
### Scenario
You're hiring a new software engineer for your medical device software team. The position requires developing software components that directly affect device safety and effectiveness. Here's how you would implement the training requirements:
**Initial Assessment**: Review the candidate's resume showing a computer science degree and three years of software development experience. The job description requires knowledge of IEC 62304 software lifecycle processes and experience with medical device development.
**Onboarding Training**: Provide initial training covering your quality management system, design control procedures, software development lifecycle SOP, and risk management processes. Include training on regulatory requirements specific to medical device software.
**Competency Verification**: Have the employee complete a supervised project demonstrating ability to follow your software development procedures, properly document design decisions, and identify safety-related requirements.
**Ongoing Training**: Provide annual training on updated software standards, participate in design control training when procedures change, and receive additional training if post-market surveillance reveals software-related issues.
### Example Training Documentation
**Employee**: John Smith, Software Engineer\
**Training Completed**: SOP Software Development Lifecycle\
**Date**: March 15, 2024\
**Method**: Document review + hands-on project\
**Verification**: Successfully completed supervised development task following all SOP requirements\
**Verified by**: Sarah Johnson, Software Team Lead\
**Next Review**: March 15, 2025 (annual performance review)
**Training Record**:
* **03/15/2024** - SOP Software Development Lifecycle (Initial training)
* **03/20/2024** - Risk Management Process Training
* **03/25/2024** - Design Control Procedures
* **04/01/2024** - Competency verification completed - PASSED
* **04/01/2024** - Authorized for independent software development work
## Q\&A
Yes, all employees whose work could affect product quality must receive appropriate training. This includes IT personnel managing your quality systems, administrative staff handling regulatory submissions, and support personnel. The training should be **proportionate to their role's impact** on product quality and regulatory compliance.
Retraining is required when **SOPs are updated**, job roles change, or performance issues indicate training gaps. At minimum, conduct annual performance reviews to assess ongoing competency. Some organizations provide annual refresher training on critical procedures, but this isn't always required if competency is maintained.
Under EU MDR Article 15, the PRRC must have either **(a)** a university degree in law, medicine, pharmacy, engineering, or relevant scientific discipline plus one year regulatory/QMS experience, or **(b)** four years professional experience in regulatory affairs or quality management systems relating to medical devices.
Both internal and external training are acceptable. External training through **professional courses, webinars, or industry seminars** can be very effective. However, you must still verify that the training meets your specific needs and document competency verification. Internal training allows more customization to your specific procedures and quality system.
Document training effectiveness through **supervisor observations**, performance reviews, competency testing, or work quality assessments. The verification should demonstrate that the employee can properly apply the training to their actual work. Simple completion certificates are not sufficient - you need evidence of **practical competency**.
If initial training is ineffective, provide **additional training** using different methods or more detailed instruction. If the employee still cannot demonstrate competency, consider whether they're suited for the role or if the training program needs improvement. Document all training attempts and decisions as part of your quality records.
Yes, software development personnel should receive training on **IEC 62304 software lifecycle processes**, cybersecurity requirements, and your specific software development procedures. Document their competency in areas like requirement analysis, software architecture, verification and validation, and risk management as these directly impact device safety.
Consultants and temporary personnel performing work affecting product quality must receive **appropriate training** for their specific tasks. This may be abbreviated compared to full-time employees but must still cover relevant quality system requirements and regulatory compliance. Document their qualifications and any training provided.
To establish a PRRC, you need someone with a higher education degree and at least one year of experience in medical device quality or regulatory. A PRRC signature contract is required, and the person must register in the EUDAMED system to obtain a Single Registration Number (SRN). Document their qualifications thoroughly as this will be reviewed during notified body assessments.
# SOP Software Development
Source: https://docs.withdovetail.com/tasks/sop-integrated-software-development
Integrate software development lifecycles ensuring medical device safety and regulatory compliance.
## Summary
This Standard Operating Procedure (SOP) defines the comprehensive **integrated software development lifecycle** for medical device software products. It establishes a systematic approach following **IEC 62304** standards to ensure software safety, effectiveness, and regulatory compliance through defined stages from specification to release, incorporating risk management, usability engineering, and change control throughout the development process.
## Why is SOP Software Development important?
**Software development** in medical devices requires rigorous control because software failures can directly impact patient safety and device effectiveness. Unlike traditional software development, medical device software must follow **validated development processes** that demonstrate safety and effectiveness through each stage of the lifecycle.
This SOP is critical because it integrates **multiple regulatory requirements** into a cohesive development process. IEC 62304 mandates specific development activities based on software safety classification, while FDA and EU regulations require design controls, risk management, and usability engineering. Without a structured approach, your development process may miss critical safety requirements, fail regulatory inspections, or produce software that cannot be validated for medical use.
The **integrated approach** ensures that risk management, usability considerations, and verification activities occur throughout development rather than as afterthoughts, significantly improving software quality and reducing development risks.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Section **820.30** requires design controls for medical device software
* Software development must follow **systematic design controls** including planning, inputs, outputs, reviews, verification, validation, and changes
* **Design History File (DHF)** must document the design control process
* Software changes require **change control** procedures under 820.30(i)
**IEC 62304** compliance expectations:
* FDA recognizes **IEC 62304** as consensus standard for software lifecycle processes
* Software safety classification (**Class A, B, C**) determines rigor of development activities
* **Verification and validation** requirements scale with safety classification
**Special attention required for:**
* Software safety classification must be documented and justified
* Design controls must be maintained throughout development lifecycle
* Software of Unknown Provenance (SOUP) requires special evaluation
* Cybersecurity considerations throughout development process
Under **EU MDR 2017/745**:
* **Annex I Section 17.2** requires software lifecycle processes following harmonized standards
* Software development must support **clinical evaluation** and **benefit-risk analysis**
* **IEC 62304** compliance demonstrates conformity with essential requirements
* Software changes may require **notified body** notification or assessment
**Integration with EU requirements**:
* Software development supports **General Safety and Performance Requirements (GSPR)**
* Development process must maintain **CE marking** validity
* **Post-market surveillance** data must inform software updates
**Special attention required for:**
* Software classification impacts notified body involvement
* Clinical evaluation requirements for software medical devices
* Post-market surveillance integration with software updates
* PRRC oversight of software development and changes
## Guide
### Understanding the Five-Stage Development Process
**Stage-based development** ensures systematic progression from requirements through release while maintaining regulatory compliance. Each stage has specific **entry criteria, activities, and exit criteria** that must be satisfied before proceeding.
**Stage 1 (Specification)** establishes the foundation with user needs, software requirements, risk management planning, and safety classification. This stage defines **what** the software must accomplish and **how safely** it must operate.
**Stage 2 (Design and Development)** creates the software architecture, implements code, and conducts verification testing. This stage addresses **how** the software will meet requirements while maintaining safety and performance.
**Stage 3 (Testing)** performs system-level verification to ensure all requirements are properly implemented. Integration testing and anomaly identification occur during this critical validation stage.
**Stage 4 (Validation)** confirms that the software meets user needs through usability evaluation and, for IVD software, performance evaluation studies. This stage demonstrates **fitness for intended use**.
**Stage 5 (Release)** finalizes documentation, conducts regulatory submissions, and prepares for market deployment with appropriate labeling and instructions for use.
### Implementing Risk-Based Development Approaches
**Software safety classification** drives development rigor throughout the process. **Class A** software (no contribution to hazardous situations) requires basic documentation and testing. **Class B** software (contributes to non-serious injury) needs moderate rigor with defined architecture and verification. **Class C** software (contributes to death or serious injury) demands comprehensive documentation, detailed design, and extensive testing.
**Risk management integration** occurs throughout all stages, not just at the beginning. Continuously evaluate how development decisions affect risk levels, update risk assessments when new hazards are identified, and ensure risk controls are properly implemented and verified.
**Change impact assessment** is critical when modifying existing software. Use your change management process to evaluate how modifications affect safety classification, risk levels, verification requirements, and regulatory compliance.
### Establishing Effective Verification and Validation Strategies
**Verification activities** demonstrate that software correctly implements requirements. This includes code reviews, unit testing, integration testing, and system testing. The depth of verification must match your software safety classification and complexity.
**Unit-level verification** ensures individual software components function correctly. Use code reviews for critical algorithms and automated testing for functional verification. Document verification methods and results for regulatory compliance.
**System-level testing** validates that integrated software meets all requirements. Create comprehensive test plans covering normal operation, error conditions, and boundary cases. Pay special attention to safety-critical functions and user interface elements.
**Validation through usability evaluation** demonstrates that software meets user needs in realistic conditions. Conduct formative evaluation during development to identify usability issues early, and summative evaluation to confirm safe and effective use.
### Managing Software Architecture and Design Controls
**Software architecture documentation** must clearly describe system structure, interfaces, data flow, and safety-critical elements. For Class C software, create detailed design documentation showing how safety requirements are implemented at the code level.
**Software of Unknown Provenance (SOUP)** requires special attention throughout development. Evaluate SOUP components for safety impact, maintain version control, and assess security vulnerabilities. Document SOUP evaluation and ongoing monitoring procedures.
**Traceability maintenance** connects user needs through requirements to design elements, code implementation, and test cases. This traceability supports change impact analysis and regulatory compliance demonstration.
### Integrating Usability Engineering and Performance Evaluation
**Usability engineering integration** ensures that safety and effectiveness considerations guide user interface design. Identify hazardous use scenarios early in development and design interfaces to prevent use errors.
**Critical task identification** focuses validation efforts on the most important user interactions. These tasks typically involve safety-critical functions, complex procedures, or error-prone activities that could impact patient safety.
**For IVD software**, performance evaluation encompasses scientific validity, analytical performance, and clinical performance. Plan these evaluations early in development to ensure appropriate data collection and analysis.
### Preparing for Regulatory Submissions and Release
**Documentation completeness** verification ensures all required deliverables are created and approved before release. Use release checklists to confirm that development, verification, validation, and regulatory requirements are satisfied.
**Regulatory submission preparation** varies by jurisdiction and device classification. Ensure appropriate **510(k), PMA, or CE marking** submissions are prepared with complete software documentation.
**Post-market surveillance integration** establishes processes for collecting and analyzing software performance data after release. Plan how user feedback, software problems, and performance monitoring will inform future development cycles.
## Example
### Scenario
You're developing a Class B medical device software application that calculates medication dosages based on patient parameters. The software interfaces with hospital information systems and displays recommendations to healthcare providers. Here's how the five-stage process applies:
**Stage 1 - Specification**: Define user needs for dosage calculation accuracy, patient safety alerts, and system integration. Establish software requirements including calculation algorithms, user interface specifications, and data validation requirements. Classify as Class B software due to potential for incorrect dosing recommendations. Create risk management plan identifying calculation errors and interface failures as primary hazards.
**Stage 2 - Design and Development**: Design software architecture with separate modules for data input, calculation algorithms, safety checks, and user interface. Document interfaces with hospital systems and SOUP components used for calculations. Implement code with unit testing for calculation algorithms and integration testing for system interfaces. Conduct code reviews focusing on safety-critical calculation functions.
**Stage 3 - Testing**: Execute comprehensive system testing covering all calculation scenarios, edge cases, and error conditions. Test integration with simulated hospital systems and verify data validation functions. Document any anomalies in the known anomalies list and address safety-critical issues immediately.
**Stage 4 - Validation**: Conduct usability evaluation with healthcare providers using realistic clinical scenarios. Focus on critical tasks like dosage calculation review, safety alert recognition, and error recovery procedures. Validate that users can safely and effectively use the software in their clinical environment.
**Stage 5 - Release**: Complete regulatory submissions (510(k) for FDA, technical file for EU), finalize labeling and instructions for use, and prepare post-market surveillance plan. Ensure all documentation is approved and release checklist is completed before deployment.
### Example Development Documentation
**Software Requirements Specification**:
* **REQ-001**: Calculate pediatric medication doses based on weight with accuracy ±2%
* **REQ-002**: Display safety alerts when calculated dose exceeds maximum recommended
* **REQ-003**: Integrate with hospital EMR systems via HL7 FHIR interface
* **REQ-004**: Validate all patient data inputs before calculation processing
**Risk Assessment Integration**:
* **Risk ID R-001**: Incorrect dose calculation due to algorithm error → Implement dual calculation verification
* **Risk ID R-002**: Interface failure causing data corruption → Add data validation and error detection
* **Risk ID R-003**: User interface confusion leading to wrong dose selection → Usability testing and interface optimization
**Stage Gate Reviews**:
* **Stage 1 Review**: Requirements approved, risk management plan established, safety classification confirmed
* **Stage 2 Review**: Architecture verified, code reviews completed, unit testing passed
* **Stage 3 Review**: System testing successful, known anomalies documented and acceptable
* **Stage 4 Review**: Usability evaluation completed, validation criteria met
* **Stage 5 Review**: All documentation complete, regulatory submissions ready, release criteria satisfied
## Q\&A
Software safety classification depends on the **potential for software failure to contribute to hazardous situations**. **Class A** software cannot contribute to hazardous situations. **Class B** software can contribute to non-serious injury. **Class C** software can contribute to death or serious injury. Evaluate your software's role in device safety through risk analysis, considering both direct effects and failure modes.
**Class A** requires basic planning, requirements, architecture, and verification documentation. **Class B** adds detailed verification procedures and integration testing requirements. **Class C** requires comprehensive documentation including detailed design, extensive verification and validation, and rigorous change control. The documentation depth should be **proportional to safety risk**.
**SOUP evaluation** should assess safety impact, security vulnerabilities, and functional suitability for your device. Document SOUP version control, known anomalies, and monitoring procedures. For safety-critical applications, consider **additional verification testing** of SOUP functionality. Maintain SOUP lists and update them when versions change.
**Major changes** affecting safety classification, user interface, or core functionality typically require full development process review. **Minor changes** like bug fixes or cosmetic updates may use abbreviated change control. The key is **change impact assessment** - evaluate how changes affect requirements, architecture, verification, and risk management. Safety-related changes always require thorough evaluation.
**Usability integration** starts in Stage 1 with user needs analysis and continues through all stages. Identify **hazardous use scenarios** early, design interfaces to prevent use errors, conduct **formative evaluation** during development, and perform **summative evaluation** for validation. Critical tasks should be identified and validated to ensure safe and effective use.
**Class A** requires basic functional testing and user needs validation. **Class B** adds systematic verification of all requirements and usability evaluation. **Class C** requires comprehensive verification including unit testing, integration testing, system testing, and extensive usability validation. **Regression testing** is important for all classes when making changes.
Establish **traceability matrices** linking user needs to requirements, requirements to design elements, design to code implementation, and code to test cases. Use tools that automatically maintain these relationships where possible. **Bidirectional traceability** helps with change impact analysis and regulatory compliance demonstration.
The release checklist should verify **all development stages are complete**, required documentation is approved, verification and validation activities are successful, risk management is current, regulatory submissions are prepared, labeling is complete, and post-market surveillance is established. Include **stage gate review approvals** and confirmation that all deliverables meet acceptance criteria.
# SOP Internal Audit
Source: https://docs.withdovetail.com/tasks/sop-internal-audit
Audit quality management systems through independent evaluation ensuring regulatory compliance and continuous improvement.
## Summary
Your **Internal Audit** SOP establishes a systematic process for independently evaluating QMS compliance, identifying improvement opportunities, and ensuring your quality management system meets regulatory requirements through objective assessment by qualified auditors.
## Why is SOP Internal Audit important?
Internal audits exist because regulators require **independent verification** that your QMS actually works as documented. They provide objective evidence that your organization follows its own procedures and meets regulatory requirements. This process identifies gaps before external auditors or regulatory inspectors find them, allowing you to address issues proactively.
The SOP ensures **consistency and objectivity** in audit execution by establishing clear qualification requirements, standardized processes, and objective criteria for findings. It transforms internal audits from informal reviews into systematic evaluations that provide meaningful insights into QMS effectiveness and compliance status.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Quality audits are **mandatory** under Section 820.22
* Must be conducted by individuals **not directly responsible** for areas being audited
* Results must be **documented** and reviewed by management with executive responsibility
* Audit findings must feed into your **Corrective and Preventive Action (CAPA)** system
**Special attention required for:**
* Design controls (820.30) - especially for software medical devices
* CAPA system effectiveness (820.100)
* Production and process controls (820.70)
* Document controls and change management (820.40)
Under **EU MDR 2017/745**:
* Manufacturers must implement a quality management system (Article 10(9))
* Must comply with **EN ISO 13485:2016** requirements for internal audits (Section 8.2.4)
* Audit results must be available for **notified body assessment**
* Regular systematic reviews are required for CE marking maintenance
**Special attention required for:**
* Clinical evaluation processes (Article 61) and ongoing clinical follow-up
* Post-market surveillance system (Articles 83-86)
* Person Responsible for Regulatory Compliance (PRRC) oversight
* Unique Device Identification (UDI) compliance (Article 27)
## Guide
Your Internal Audit SOP establishes the **framework** for systematic QMS evaluation through independent assessment. Design the process to provide meaningful insights rather than just checking compliance boxes.
### Auditor Qualification and Selection
Establish **clear qualification criteria** for internal auditors including training requirements, experience levels, and competency assessment. Auditors must understand both auditing techniques and the specific regulatory requirements applicable to your organization. Consider requiring formal audit training or certification.
Ensure **auditor independence** by preventing individuals from auditing their own work areas. In small organizations, this may require using external auditors or cross-functional team members. Document the selection rationale and any potential conflicts of interest.
### Audit Planning and Scheduling
Develop an **annual audit program** that covers all QMS processes over a planned cycle. Not every process needs annual auditing, but high-risk areas, processes with previous findings, or areas undergoing significant changes should receive more frequent attention.
Create detailed **audit plans** for each audit that specify scope, timing, resources, and specific requirements to be evaluated. Share plans with auditees in advance to ensure availability and preparation. Include relevant standards, regulations, and internal procedures in your scope definition.
### Audit Execution and Evidence Collection
Structure audit activities to **systematically evaluate** process effectiveness through document review, interviews, and observation. Focus on verifying that processes achieve their intended outcomes rather than just checking procedural compliance.
Collect **objective evidence** to support findings. This includes reviewing records, observing activities, and interviewing personnel. Document evidence clearly and reference specific requirements or procedures being evaluated. Avoid subjective opinions or recommendations that cannot be supported by concrete evidence.
### Finding Classification and Documentation
Establish **clear criteria** for classifying findings as major nonconformities, minor nonconformities, or opportunities for improvement. Major nonconformities represent systematic failures or absence of required processes. Minor nonconformities are isolated deviations that don't compromise overall process effectiveness.
Document findings with **sufficient detail** for follow-up action. Include specific evidence, applicable requirements, and clear description of the gap. Avoid vague statements - be specific about what was observed and why it represents a nonconformity.
### Follow-up and CAPA Integration
Connect audit findings to your **CAPA system** for systematic resolution. Major nonconformities typically require formal CAPA investigation, while minor findings may be addressed through simple corrective actions. Establish timelines for response and verification of corrective actions.
Use audit results as **input to management review** to demonstrate QMS effectiveness and identify systemic improvement opportunities. Track trends in audit findings to identify recurring issues or process weaknesses.
## Example
### Scenario
You schedule an internal audit of your document control process. An independent team member reviews procedures, records, and recent changes. The audit finds that some training records are missing signatures. You document the finding, assign a corrective action, and verify completion at the next audit. During the annual management review, you discuss audit results, customer complaints, and process improvements, and set new quality objectives for the coming year.
### Example Internal Audit Process
**Audit Planning:**
* **Scope:** Document and Record Control SOP compliance
* **Auditor:** Quality Manager (independent of document control process)
* **Duration:** 4 hours over 2 days
* **Auditees:** Documentation Coordinator, Training Manager
* **Standards:** ISO 13485:2016 Sections 4.2.4 and 4.2.5
**Audit Activities:**
1. **Document Review** - Examine 20 controlled documents for proper approval signatures
2. **Record Sampling** - Review training records for 15 employees hired in past 6 months
3. **Process Interview** - Discuss document change control with Documentation Coordinator
4. **System Verification** - Check electronic document management system access controls
**Findings:**
* **Minor Nonconformity:** 3 of 15 training records lacked required signatures per SOP-HR-001
* **Opportunity for Improvement:** Consider automated alerts for training record completion
* **Positive Observation:** Document change control process working effectively
**Follow-up Actions:**
* **Immediate Correction:** Obtain missing signatures within 5 business days
* **Corrective Action:** Update training record checklist to include signature verification
* **Timeline:** Complete corrective action within 30 days
* **Verification:** Re-audit training records at next scheduled audit
**Management Review Input:**
* Document control process generally effective with minor training record gap
* Recommend consideration of automated training tracking system
* No major systemic issues identified requiring immediate attention
## Q\&A
Internal audits are required for ISO 13485 compliance and involve testing your team's understanding of processes. Management reviews should be done annually, focusing on KPIs and quality performance. They are recommended before a conformity assessment but are not mandatory before product release. The SOP should establish clear connections between these processes.
Unofficial audit recommendations should be reviewed and considered for implementation. They don't require a CAPA but can be managed through change management by updating documents to improve compliance. Document the evaluation and decision regarding implementation of recommendations.
In small organizations, auditors can come from within the company or be external, as long as they don't audit their own work. Cross-functional team members or external consultants are common solutions. The key is ensuring objectivity and appropriate qualifications for the audit scope.
A full audit of the QMS is not required annually but should be planned with consideration of processes most important to your organization or those at highest risk. High-risk areas, processes with previous findings, or areas undergoing changes should receive more frequent attention.
Major nonconformities represent systemic failures to meet regulatory requirements or the complete absence of required processes. Minor nonconformities are isolated deviations that don't compromise overall process effectiveness. The classification affects the response required and CAPA initiation.
All major nonconformities should initiate formal CAPA according to your CAPA SOP. Minor nonconformities may be addressed through simple corrective actions. Include the audit report as inputs for management review to ensure systematic follow-up and trend analysis.
# SOP Management Review
Source: https://docs.withdovetail.com/tasks/sop-management-review
Build effective management review procedures to assess your QMS, to ensure quality outcomes.
## Summary
Your **Management Review** SOP defines how your leadership team systematically evaluates QMS effectiveness, reviews quality objectives, and makes strategic decisions to ensure continuous improvement and regulatory compliance through structured annual assessments.
## Why is SOP Management Review important?
Management review exists because regulators require **top management accountability** for quality system effectiveness. It demonstrates that your leadership actively oversees quality performance rather than delegating it entirely to quality personnel. This process transforms quality management from a compliance exercise into a **strategic business function** that drives organizational improvement.
The SOP ensures consistency in how management evaluates QMS performance, makes data-driven decisions about resource allocation, and responds to regulatory changes. It also provides auditors with evidence that your organization has systematic oversight mechanisms in place and that quality management receives appropriate executive attention.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Management review is **mandatory** under Section 820.20(c)
* Must include **adequate resources** and assignment of trained personnel
* Review must cover **QMS effectiveness** and corrective actions
* Top management must demonstrate **commitment** to quality system
**Special attention required for:**
* Management responsibility documentation (820.20)
* Integration with CAPA system (820.100)
* Resource allocation decisions (820.20(a))
* Quality system effectiveness metrics tracking
Under **EU MDR 2017/745**:
* Management review required as part of **quality management system** (Article 10(9))
* Must comply with **EN ISO 13485:2016 Section 5.6** requirements
* Review must include **post-market surveillance** data evaluation
* PRRC role integration and **regulatory update** assessment required
**Special attention required for:**
* Post-market surveillance system effectiveness (Articles 83-86)
* Clinical evaluation and PMCF integration (Article 61)
* PRRC responsibilities and regulatory change management
* Notified body assessment preparation and findings review
## Guide
Your Management Review SOP establishes the **framework** for systematic quality system evaluation. Design the process to provide meaningful insights rather than just completing a compliance checklist.
### Defining Key Performance Indicators (KPIs)
Establish **measurable KPIs** that align with your quality objectives and provide meaningful insights into QMS effectiveness. Include metrics for training completion, audit findings, customer complaints, CAPA closure rates, and regulatory compliance. Avoid metrics that are too numerous or difficult to track consistently.
Set realistic acceptance criteria for each KPI. Not every metric needs to achieve 100% success - focus on trends and continuous improvement rather than perfection. Document the rationale for your acceptance criteria so auditors understand your approach.
### Input Data Collection
Systematically collect **input data** throughout the year rather than scrambling before the review. Assign responsibility for each data type to specific team members. Include feedback and complaints, audit results, monitoring data, CAPA status, regulatory changes, and improvement recommendations.
Create a centralized system for tracking this information. Many organizations use spreadsheets or quality management software to maintain ongoing data collection. The key is consistency and completeness rather than sophisticated tools.
### Review Meeting Structure
Plan your **management review meeting** to be productive and decision-focused. Distribute input data in advance so participants can prepare. Structure the agenda around KPI review, trend analysis, problem identification, and action planning rather than just reading through data.
Include all management team members with quality responsibilities. This typically includes C-level executives, quality managers, and functional area leaders. Document attendance and ensure decisions have appropriate authority backing.
### Decision Documentation and Follow-up
Document **specific decisions** and action items with assigned responsibilities and timelines. Avoid vague commitments like "improve training" - instead specify "implement quarterly training effectiveness assessments by Q3." This provides clear direction and accountability.
Establish a follow-up mechanism to track action item completion. Many organizations incorporate management review follow-up into quarterly business reviews or monthly quality meetings. The goal is ensuring decisions translate into actual improvements.
### Integration with Other QMS Processes
Connect management review **outputs** to other QMS processes. CAPA investigations may arise from review findings. Resource allocation decisions affect multiple processes. Quality objective updates impact performance monitoring throughout the organization.
This integration demonstrates that management review is not an isolated activity but a central coordination mechanism for your quality system.
## Example
### Scenario
BioMed Innovations conducts their annual management review after completing internal audits and collecting customer feedback data. The CEO, VP of Quality, CTO, and VP of Operations evaluate QMS performance against predetermined KPIs, identify improvement opportunities, and set strategic direction for the upcoming year.
### Example Management Review Process
**Pre-Review Data Collection:**
* Training completion rates: 98% (Target: 95%)
* Internal audit findings: 2 minor nonconformities (Target: \<5)
* Customer complaints: 12 received, 11 resolved (Target: 95% resolution)
* CAPA closure rate: 89% (Target: 90%)
* Regulatory updates: 3 identified, all implemented within 6 months
**Review Meeting Agenda:**
1. **KPI Performance Review** - Quality Manager presents dashboard
2. **Trend Analysis** - Discussion of year-over-year improvements
3. **Problem Areas** - Focus on CAPA closure rate shortfall
4. **Resource Needs** - Request for additional training budget
5. **Regulatory Changes** - Impact assessment of new FDA guidance
6. **Action Planning** - Specific improvement initiatives for next year
**Key Decisions:**
* Approve 20% increase in training budget for specialized courses
* Implement monthly CAPA status reviews to improve closure rates
* Assign VP of Operations to lead regulatory change assessment process
* Update quality objectives to include customer satisfaction metrics
* Schedule quarterly mini-reviews to monitor progress
**Follow-up Actions:**
* Quality Manager to implement monthly CAPA reviews by March 15
* VP of Operations to develop regulatory change procedure by April 30
* CEO to approve budget allocation by February 28
* All department heads to incorporate new objectives by January 31
## Q\&A
Internal audits are required for ISO 13485 compliance and involve testing your team's understanding of processes. Management reviews should be done annually, focusing on KPIs and quality performance. They are recommended before a conformity assessment but are not mandatory before product release. The SOP should integrate audit results as key input data.
Unofficial audit recommendations should be reviewed and considered for implementation. They don't require a CAPA but can be managed through change management by updating documents to improve compliance. Include these recommendations in your management review input data for evaluation.
Include feedback and complaints, reporting to regulatory authorities, audit results, monitoring and measurement of processes and products, corrective and preventive actions, follow-up from previous reviews, changes affecting the QMS, improvement recommendations, and applicable new regulatory requirements.
Management review should be conducted at least annually, but more frequent reviews may be beneficial for rapidly growing organizations or those experiencing significant changes. The SOP should specify timing relative to other QMS activities like internal audits and regulatory deadlines.
The management team should include C-level executives and other key personnel responsible for quality-affecting work. This typically includes the management representative, functional area leaders, and anyone with authority to allocate resources or make strategic decisions affecting quality.
Management review outputs should be recorded according to your document control SOP and should address QMS improvement needs, product improvement related to customer requirements, responses to new regulatory requirements, and resource needs. Assign specific responsibilities and timelines for each action item.
# SOP Manufacturing
Source: https://docs.withdovetail.com/tasks/sop-manufacturing
Control systematic manufacturing processes ensuring design transfer, production quality, and regulatory compliance.
## Summary
The Standard Operating Procedure (SOP) for Manufacturing establishes systematic processes for design transfer, manufacturing transfer, and production control activities for medical devices. This SOP ensures consistent manufacturing processes, proper documentation control, and seamless transfer of designs from development to production while maintaining regulatory compliance and product quality throughout the manufacturing lifecycle.
## Why is SOP Manufacturing important?
Manufacturing controls for medical devices exist because **production processes must consistently produce devices that meet safety and performance specifications** established during design and development. Poor manufacturing controls can introduce defects, contamination, or variability that compromises patient safety even if the original design was sound. Regulatory authorities require manufacturing SOPs because they need assurance that every device produced will perform as intended throughout its lifecycle. This SOP is critical for your certification because it demonstrates you have systematic controls to prevent manufacturing errors, ensure traceability, and maintain design integrity during production scaling and site transfers.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Section 820.181** requires Device Master Record (DMR) for all manufacturing procedures
* **Section 820.184** mandates Device History Record (DHR) for traceability of each device
* **Design Controls (820.30)** must be maintained through manufacturing transfer
* **Process validation (820.75)** required for manufacturing processes affecting device safety
**Special attention required for:**
* Manufacturing site changes requiring FDA notification or approval
* Contract manufacturer qualification and oversight requirements
* Design transfer validation ensuring manufacturing maintains design integrity
* Process controls for software medical device production and deployment
Under **EU MDR 2017/745**:
* **Article 10(9)** requires quality management system for manufacturing activities
* **Annex II Technical Documentation** must include manufacturing information
* **Article 23** mandates Authorized Representative oversight of manufacturing
* **GSPR 3** requires manufacturing processes to ensure consistent conformity
**Special attention required for:**
* Notified body notification for significant manufacturing changes
* EU Authorized Representative responsibilities for manufacturing oversight
* Post-market surveillance integration with manufacturing quality data
* UDI database updates for manufacturing and distribution information
## Guide
### Establishing Manufacturing Transfer Framework
Create a systematic **manufacturing transfer process** that ensures design integrity is maintained when moving from development to production or between manufacturing sites. Define **transfer phases** including planning, execution, and post-transfer monitoring with specific deliverables and approval criteria for each phase. Establish **cross-functional teams** including design, manufacturing, quality, and regulatory personnel with clearly defined roles and responsibilities. Document **transfer plans** that address scope, timeline, resources, risk assessment, and success criteria for each transfer project.
### Design History File and Device Master Record Management
Maintain comprehensive **Design History Files (DHF)** containing all design development documentation and link them to corresponding **Device Master Records (DMR)** that specify exactly how devices should be manufactured. Ensure DMRs include detailed manufacturing procedures, specifications, acceptance criteria, and quality control measures. Implement **version control** and **change management** processes that maintain traceability between design changes and manufacturing updates. Document the **complete bill of materials (BOM)** with approved suppliers, specifications, and qualification status for all components.
### Process Validation and Control
Implement **process validation** for all manufacturing processes that could affect device safety, effectiveness, or performance. Conduct **installation qualification (IQ)**, **operational qualification (OQ)**, and **performance qualification (PQ)** for manufacturing equipment and processes. Establish **statistical process controls** with appropriate control limits and monitoring procedures. Document **process capability studies** demonstrating that manufacturing processes consistently produce devices meeting specifications within defined confidence intervals.
### Supplier Management and Contract Manufacturing
Develop robust **supplier qualification** processes including on-site audits, quality agreements, and ongoing monitoring of supplier performance. For **contract manufacturers**, establish clear quality agreements defining responsibilities, specifications, and oversight requirements. Implement **supplier change control** procedures requiring approval before suppliers modify processes, materials, or facilities that could affect your device. Maintain **approved supplier lists** with documented evaluation criteria and re-qualification schedules.
### Manufacturing Site Management
Establish **facility controls** including environmental monitoring, contamination prevention, and equipment maintenance programs appropriate to your device type and risk level. Implement **personnel qualification** programs ensuring manufacturing staff are trained and competent to perform assigned tasks. Create **batch records** or **device history records** that document the manufacturing history of each device or batch including materials used, processes performed, and quality control results.
### Quality Control and Testing
Integrate **in-process quality controls** at critical manufacturing steps to detect and prevent defects before final assembly. Establish **acceptance testing** procedures that verify each device meets specifications before release. Implement **statistical sampling plans** appropriate to your device risk level and production volume. Document **corrective and preventive actions** when manufacturing issues are identified, including root cause analysis and effectiveness verification.
### Post-Market Manufacturing Monitoring
Establish **manufacturing surveillance** processes that monitor production quality trends, customer complaints, and field performance data. Implement **change management** procedures for manufacturing modifications that assess impact on device safety and effectiveness. Create **manufacturing metrics** and key performance indicators that track process capability, defect rates, and customer satisfaction. Maintain **manufacturing records** according to regulatory retention requirements and ensure availability for regulatory inspections.
## Example
### Scenario:
You're transferring production of a mobile health monitoring app from your internal development team to a contract software manufacturer. Your transfer plan includes validation that the contract manufacturer's build environment produces identical software artifacts, verification of code signing and security controls, and demonstration that deployment processes maintain cybersecurity requirements. Process validation includes testing automated build pipelines, validating software bill of materials (SBOM) generation, and confirming that release procedures produce traceable software versions. Quality controls include automated testing suites, security scans, and functional verification before each release. Your Device Master Record specifies exact build configurations, approved third-party libraries, deployment procedures, and quality control checkpoints required for each software release.
### Example Manufacturing Transfer Plan:
**Manufacturing Transfer Plan for Mobile Health Monitoring App**
**1. Transfer Scope and Objectives**
* Transfer software production from internal development to qualified contract manufacturer
* Maintain identical software functionality, security, and performance characteristics
* Ensure regulatory compliance and traceability throughout manufacturing process
**2. Phase I: Transfer Planning**
* Contract manufacturer facility audit and qualification
* Software build environment validation and configuration
* Quality agreement establishment with defined specifications and controls
* Risk assessment of potential manufacturing failure modes
**3. Phase II: Process Transfer and Validation**
* Build environment replication and validation testing
* Automated testing pipeline implementation and verification
* Code signing and security control validation
* Software bill of materials (SBOM) generation and verification
**4. Phase III: Production Implementation**
* Pilot production runs with side-by-side comparison testing
* Full production validation with statistical process control
* Quality control implementation including automated and manual testing
* Regulatory notification and documentation updates
**5. Device Master Record Components**
* Software configuration management procedures
* Build environment specifications and validation requirements
* Automated testing protocols and acceptance criteria
* Release procedures including security scanning and functional verification
* Change control procedures for software components and build processes
**6. Quality Controls and Monitoring**
* Automated build verification and testing protocols
* Security vulnerability scanning and remediation procedures
* Performance testing and regression validation
* Post-release monitoring and feedback integration
## Q\&A
You need a comprehensive Design History File (DHF) containing all design development documentation, a detailed Device Master Record (DMR) specifying manufacturing procedures and specifications, a transfer plan with phases and deliverables, supplier qualification records for all components, process validation documentation including installation/operational/performance qualification, and quality agreements with any contract manufacturers or critical suppliers.
Conduct three-stage process validation: Installation Qualification (IQ) verifying equipment is installed correctly, Operational Qualification (OQ) demonstrating processes operate within specified parameters, and Performance Qualification (PQ) proving consistent production of devices meeting specifications. Use appropriate statistical methods to demonstrate process capability and establish control limits for ongoing monitoring. Document all validation activities and maintain records for regulatory review.
Conduct thorough on-site audits before qualification, establish comprehensive quality agreements defining specifications and responsibilities, implement regular monitoring through supplier scorecards and periodic audits, require notification and approval for any changes affecting your device, and maintain documentation demonstrating ongoing oversight and supplier performance. Ensure contract manufacturers understand and comply with all applicable regulatory requirements.
Implement a formal change control process that evaluates the impact of proposed changes on device safety and effectiveness. Assess whether changes require design controls, process revalidation, or regulatory notification. Document change rationale, risk assessment, validation activities, and approval decisions. For significant changes, consider whether FDA notification, notified body approval, or technical documentation updates are required before implementation.
Maintain Device History Records (DHR) for each device showing materials used, processes performed, and quality control results. Keep complete supplier qualification records, process validation documentation, quality control test results, corrective action records, and manufacturing procedure documentation. Ensure records are legible, traceable to specific devices or batches, and retained according to regulatory requirements (typically 3+ years depending on jurisdiction and device type).
# SOP Nonconformance
Source: https://docs.withdovetail.com/tasks/sop-nonconformance
Control procedures for identifying, evaluating, and managing nonconforming products and processes in medical device QMS.
## Summary
This Standard Operating Procedure (SOP) establishes systematic processes for **identifying, evaluating, and controlling nonconforming products and processes** in medical device manufacturing and software development. It defines clear procedures for handling deviations from specifications, implementing appropriate disposition decisions, and preventing recurrence through integrated **corrective and preventive actions**.
## Why is SOP Nonconformance important?
**Nonconformance control** is fundamental to maintaining medical device quality and patient safety. When products or processes deviate from established specifications, they can potentially compromise device safety, effectiveness, or regulatory compliance. Regulatory authorities require manufacturers to have robust systems for identifying and controlling nonconforming products to prevent defective devices from reaching patients.
This SOP is critical because it provides **systematic decision-making** for handling quality problems. Without proper nonconformance controls, defective products might be released to market, processes might continue producing defects, and quality issues could go unaddressed. The procedure ensures that every deviation is **properly evaluated for safety impact**, appropriately dispositioned, and analyzed for root causes that could lead to broader quality improvements.
**Integration with CAPA** systems ensures that significant nonconformances trigger investigations into systemic causes and implementation of preventive measures, creating a feedback loop that continuously improves your quality management system.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Section **820.90** mandates procedures for controlling nonconforming product
* Nonconforming product must be **identified and controlled** to prevent unintended use or delivery
* **Disposition decisions** must be documented and approved by authorized personnel
* Must evaluate for **rework, repair, accept as-is, or scrap** with appropriate authorization
**Integration with other QSR requirements**:
* Nonconformance data must feed into **CAPA system** under 820.100
* Links to **complaint handling** procedures under 820.198
* Supports **design control** nonconformance evaluation under 820.30
**Special attention required for:**
* Authorization levels for disposition decisions, especially "use as-is"
* Documentation of safety and effectiveness impact evaluation
* Integration with complaint handling for field-discovered nonconformances
* CAPA triggering criteria for significant or recurring nonconformances
Under **EU MDR 2017/745**:
* **Article 10(9)** requires quality management system including nonconformance control
* **ISO 13485 Section 8.3** provides detailed requirements for nonconforming product control
* Nonconformance data must support **post-market surveillance** obligations under Articles 83-86
* Significant nonconformances may trigger **incident reporting** under Article 87
**MDR-specific considerations**:
* Nonconformance control supports **continuous improvement** requirements
* Must maintain **CE marking** validity when handling nonconformances
* **PRRC oversight** required for significant safety-related nonconformances
**Special attention required for:**
* Post-market nonconformances may require competent authority notification
* Nonconformance trends must inform clinical evaluation updates
* Technical file updates may be needed for significant design-related nonconformances
* Notified body notification for certain nonconformances affecting conformity
## Guide
### Establishing Comprehensive Nonconformance Identification
**Proactive identification** of nonconformances requires multiple detection methods throughout your operations. Train personnel to recognize deviations from specifications, established procedures, or expected outcomes. Nonconformances can be discovered during **incoming inspection**, in-process testing, final inspection, customer complaints, or internal audits.
**Clear identification criteria** help ensure consistent detection. Define what constitutes a nonconformance for your specific products and processes, including dimensional tolerances, functional specifications, software requirements, and procedural deviations. Document these criteria in work instructions and training materials.
**Immediate containment** is critical when nonconformances are identified. Physically segregate nonconforming products, stop affected processes, and prevent unintended use or delivery. Use clear labeling or physical barriers to identify nonconforming items.
### Conducting Thorough Nonconformance Evaluation
**Safety impact assessment** is the first priority when evaluating any nonconformance. Determine whether the deviation could affect device safety, effectiveness, or regulatory compliance. Use your **risk management process** to evaluate potential hazards and their severity.
**Root cause analysis** should be proportional to the significance of the nonconformance. Minor deviations might require only basic investigation, while safety-related or recurring nonconformances need comprehensive analysis using tools like fishbone diagrams, 5-why analysis, or failure mode analysis.
**Scope assessment** determines whether the nonconformance affects only specific units or indicates broader systemic issues. Investigate whether similar products, processes, or time periods might be affected. This helps determine the extent of containment actions needed.
### Implementing Appropriate Disposition Strategies
**Disposition decision-making** requires clear authority levels and approval processes. Establish who can authorize different disposition options, with higher authority required for "use as-is" decisions or safety-related evaluations.
**Rework procedures** must ensure that modified products meet all original specifications. Document rework instructions, verify completion through appropriate testing or inspection, and update records to reflect the rework performed.
**Repair decisions** for products that cannot be restored to original specifications require careful evaluation. Ensure repaired products still meet essential safety and performance requirements. Document repair procedures and conduct appropriate verification testing.
**Use as-is decisions** are the most critical and require thorough justification. Demonstrate that despite the nonconformance, the product still meets essential requirements for safety and effectiveness. Higher management authorization is typically required for these decisions.
**Scrap decisions** must ensure proper disposal and prevent inadvertent use of nonconforming products. Follow appropriate disposal procedures, especially for electronic waste or controlled materials.
### Managing Software-Specific Nonconformances
**Software nonconformances** often require different handling than hardware issues. Code defects, logic errors, or performance issues need evaluation for safety impact using your **IEC 62304** software safety classification.
**Version control integration** ensures that software nonconformances are properly tracked and resolved. Use your software development procedures to implement fixes, conduct verification testing, and update documentation appropriately.
**Regression testing** is critical when correcting software nonconformances to ensure fixes don't introduce new problems. The extent of testing should be proportional to the safety classification and scope of changes.
### Documenting and Tracking Nonconformances
**Nonconformance reports** should capture all essential information including description of the deviation, products affected, safety assessment, root cause analysis results, disposition decision, and corrective actions taken.
**Trending and analysis** of nonconformance data helps identify systematic quality issues. Regular review of nonconformance types, frequencies, and root causes can reveal improvement opportunities and trigger preventive actions.
**Records management** must ensure nonconformance documentation is maintained according to your document control procedures and regulatory requirements. These records provide important evidence during audits and regulatory inspections.
### Integrating with CAPA and Continuous Improvement
**CAPA triggering** should be clearly defined for different types of nonconformances. Safety-related issues, recurring problems, or systemic failures typically require formal CAPA investigation and implementation.
**Effectiveness verification** ensures that corrective actions actually resolve the nonconformance causes. Follow up on implemented actions to confirm they're working as intended and haven't created new problems.
**Process improvement** opportunities often emerge from nonconformance analysis. Use this data to update procedures, improve training, enhance inspection methods, or modify product designs to prevent future occurrences.
## Example
### Scenario
During final software testing of your medical device application, you discover that the dosage calculation algorithm produces incorrect results when patient weight exceeds 150kg. The software is classified as IEC 62304 Class B. Here's how you would handle this nonconformance:
**Immediate Identification and Containment**: Stop software release process, quarantine affected software builds, and notify development team. Document the nonconformance in your tracking system with details about the specific calculation error and affected weight ranges.
**Safety Impact Evaluation**: Assess that incorrect dosage calculations could lead to inappropriate treatment recommendations, potentially causing patient harm. Classify as high-priority safety-related nonconformance requiring immediate attention.
**Root Cause Investigation**: Analysis reveals that the algorithm uses integer arithmetic causing overflow errors with large weight values. Code review shows insufficient input validation and edge case testing during development.
**Disposition Decision**: Software cannot be released as-is due to safety implications. Requires rework to fix calculation algorithm and implement proper input validation. No repair or use as-is options are acceptable for safety-critical software.
**Corrective Actions**: Develop software patch with corrected algorithm, implement comprehensive input validation, conduct extended testing with full weight range, and update test procedures to include edge case scenarios.
**Verification**: Complete regression testing confirms algorithm fixes work correctly across all weight ranges without affecting other functionality. Documentation updated to reflect changes and lessons learned.
### Example Nonconformance Report
**NCR Number**: NCR-2024-012\
**Date Identified**: March 8, 2024\
**Product**: MedDevice Software v2.1.3\
**Nonconformance Description**: Dosage calculation algorithm produces incorrect results for patient weights >150kg
**Safety Assessment**: HIGH RISK - Incorrect calculations could lead to inappropriate dosing recommendations
**Root Cause**: Integer overflow in weight calculation function; insufficient edge case testing during development
**Disposition**: REWORK REQUIRED
* Correct calculation algorithm to handle full weight range
* Implement proper input validation
* Enhance test coverage for edge cases
* Update development procedures
**Actions Taken**:
* Algorithm corrected in v2.1.4
* Input validation implemented for weight range 0-300kg
* Extended test suite executed and passed
* Code review process enhanced for calculation functions
**Verification**: Regression testing completed successfully; full weight range validated
**CAPA Required**: Yes - Investigation into development testing procedures to prevent similar issues
**Approved by**: Quality Manager, Software Team Lead\
**Closure Date**: March 20, 2024
## Q\&A
A nonconformance is any **deviation from specified requirements**, documented procedures, or established acceptance criteria. Normal process variation stays within acceptable limits defined by your specifications. If measured values fall outside tolerance ranges, procedures aren't followed as documented, or products don't meet functional requirements, it's a nonconformance requiring formal evaluation and disposition.
**Disposition authority** should be clearly defined in your procedures based on the significance and type of nonconformance. Generally, quality personnel can authorize **rework and scrap** decisions, while **use as-is decisions** require higher management approval. Safety-related nonconformances typically require additional technical review and may need medical or regulatory input for final disposition.
**CAPA triggering criteria** typically include safety-related nonconformances, recurring problems, customer complaints, systemic process failures, or regulatory compliance issues. Define clear criteria in your procedures - some organizations trigger CAPAs for any nonconformance affecting patient safety, while others use frequency or severity thresholds. Single, minor nonconformances may not require formal CAPA if adequately addressed through immediate correction.
**Post-market nonconformances** require immediate risk assessment and may trigger complaint handling, vigilance reporting, or field corrective actions. Evaluate the safety impact, determine if other products are affected, consider customer notification requirements, and assess whether regulatory reporting is needed. Follow your post-market surveillance and complaint handling procedures while conducting the nonconformance process.
Document the **nonconformance description**, affected products/quantities, safety assessment, root cause analysis, disposition decision with justification, corrective actions taken, and verification of effectiveness. Maintain records of who authorized decisions and when actions were completed. This documentation provides audit evidence and supports trend analysis for continuous improvement.
**Software nonconformances** often affect multiple units simultaneously and may require different verification approaches. Use your **IEC 62304** procedures for software problem resolution, ensure version control is maintained, conduct appropriate regression testing, and update software documentation. Software fixes typically require verification testing rather than physical inspection.
If root cause cannot be determined despite reasonable investigation, document the **analysis performed** and implement appropriate **containment measures** to prevent recurrence. Consider whether additional investigation methods, external expertise, or extended monitoring might help identify causes. The inability to find root cause doesn't prevent appropriate disposition, but may influence the level of ongoing monitoring required.
**Effectiveness verification** should demonstrate that corrective actions actually prevent recurrence. This might include follow-up testing, process monitoring, trend analysis, or specific verification activities. Define verification methods when implementing corrective actions and establish timeframes for follow-up assessment. Document verification results as part of your nonconformance closure process.
# SOP Performance Evaluation
Source: https://docs.withdovetail.com/tasks/sop-performance-evaluation
Demonstrate IVD device performance through scientific validity, analytical testing, and clinical performance evaluation.
## Summary
**SOP Performance Evaluation** establishes systematic procedures for conducting comprehensive performance evaluations of in vitro diagnostic (IVD) medical devices according to EU IVDR 2017/746 requirements. This Standard Operating Procedure (SOP) covers scientific validity demonstration, analytical performance assessment, clinical performance evaluation, and continuous post-market performance follow-up to ensure ongoing compliance and device effectiveness.
## Why is SOP Performance Evaluation important?
Performance evaluation represents the **scientific foundation** that demonstrates your IVD device delivers clinically meaningful and reliable results. **Without rigorous performance evaluation**, you cannot demonstrate conformity with IVDR requirements or justify your device's intended purpose claims. This SOP ensures systematic evidence generation that supports both regulatory approval and clinical confidence in your device.
**IVDR compliance mandates performance evaluation** as a cornerstone requirement for market access. Article 56 and Annex XIII establish specific performance evaluation obligations that must be fulfilled before CE marking. **Systematic performance evaluation processes** ensure you generate adequate scientific validity, analytical performance, and clinical performance data proportionate to your device's risk classification and intended use.
The SOP transforms complex regulatory requirements into **actionable procedures** that guide evidence collection, analysis, and documentation. **Well-executed performance evaluation** supports clinical decision-making, strengthens market positioning, and provides the foundation for continuous post-market surveillance and device improvement activities.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and relevant FDA guidance for IVDs:
* **Analytical studies** must demonstrate device performance characteristics including accuracy, precision, and analytical sensitivity/specificity
* **Clinical validation** requirements vary by device classification and intended use
* **Premarket submission** must include clinical and analytical validation data appropriate to device risk
* **Quality System Regulation** requires systematic procedures for design validation and clinical evaluation
**Special attention required for:**
* Clinical Laboratory Improvement Amendments (CLIA) waiver requirements
* Laboratory Developed Test (LDT) oversight considerations
* Software as Medical Device (SaMD) validation requirements for IVD software
* FDA guidance on Statistical Guidance on Reporting Results from Studies Evaluating Diagnostic Tests
Under **EU IVDR 2017/746**:
* **Performance evaluation** is mandatory per Article 56 and detailed in Annex XIII
* **Scientific validity, analytical performance, and clinical performance** must be demonstrated for all device classifications
* **Performance Evaluation Plan (PEP)** and **Performance Evaluation Report (PER)** are required technical documentation components
* **Post-Market Performance Follow-up (PMPF)** must continue throughout device lifecycle
* **Conformity assessment** procedures require performance evaluation evidence proportionate to device risk classification
**Special attention required for:**
* Class C and Class D devices requiring enhanced clinical performance studies
* EU Reference Laboratory consultation requirements for highest-risk devices
* Common Specifications (CS) compliance when available for specific device types
* MDCG guidance implementation for performance evaluation methodologies
## Guide
### Performance Evaluation Planning
**Establish qualified performance evaluation team** with appropriate expertise for your device type and intended use. **Ensure evaluator competencies** include device technology understanding, research methodology knowledge, literature review techniques, IVDR regulatory requirements familiarity, and clinical knowledge relevant to your device's diagnostic area.
**Develop comprehensive Performance Evaluation Plan (PEP)** detailing your systematic approach to performance evaluation. **Define intended purpose clearly** including target population, intended users, indications, and contraindications. **Specify analytes or markers** measured by your device and identify relevant General Safety and Performance Requirements (GSPRs) requiring performance data support.
**Outline development phases systematically** including sequence and methods for demonstrating performance across scientific validity, analytical performance, and clinical performance domains. **Plan performance studies** when literature data proves insufficient, defining study objectives, methodologies, and acceptance criteria.
### Scientific Validity Assessment
**Demonstrate analyte association** with clinical conditions or physiological states relevant to your device's intended purpose. **Conduct comprehensive literature review** of peer-reviewed scientific publications establishing biological relationships between measured analytes and clinical outcomes.
**Evaluate existing scientific evidence** systematically using established appraisal methodologies. **Document evidence quality** including study design strengths, sample sizes, population characteristics, and methodological limitations. **Identify evidence gaps** requiring additional data generation through performance studies or ongoing surveillance.
**Assess biological plausibility** of analyte-condition associations considering established pathophysiological mechanisms. **Consider alternative biomarkers** and comparative approaches to strengthen scientific validity arguments.
### Analytical Performance Evaluation
**Define analytical performance characteristics** appropriate for your device type including accuracy, precision, analytical sensitivity, analytical specificity, limits of detection and quantification, measuring range, and interference assessments. **Establish acceptance criteria** based on intended use requirements and clinical performance expectations.
**Conduct systematic analytical studies** following established protocols and international standards where applicable. **Document study methodologies** including reference materials, calibrators, quality controls, and measurement procedures. **Analyze performance data** using appropriate statistical methods and compare results against predefined acceptance criteria.
**Assess measurement uncertainty** and its impact on clinical interpretation. **Evaluate interference potential** from common substances likely to be present in clinical samples. **Document analytical performance limitations** and their implications for clinical use.
### Clinical Performance Evaluation
**Demonstrate clinical performance** showing your device yields results correlated with clinical conditions or physiological states in target populations. **Define clinical performance parameters** including diagnostic sensitivity, diagnostic specificity, positive predictive value, negative predictive value, and clinical concordance as appropriate for intended use.
**Conduct clinical performance studies** when adequate literature data is unavailable. **Design studies appropriately** considering patient populations, reference methods, clinical endpoints, and statistical power requirements. **Ensure study conduct** follows Good Clinical Practice (GCP) principles and relevant regulatory guidance.
**Analyze clinical data systematically** using appropriate statistical methods for diagnostic accuracy assessments. **Consider clinical utility** beyond analytical performance including impact on patient management, clinical outcomes, and healthcare resource utilization.
### Performance Evaluation Reporting
**Document performance evaluation results** in comprehensive Performance Evaluation Report (PER) including both favorable and unfavorable data. **Structure PER systematically** covering scientific validity evidence, analytical performance results, clinical performance data, and overall benefit-risk assessment.
**Include supporting documentation** such as literature review results, study protocols, study reports, statistical analyses, and expert opinions. **Ensure traceability** between performance claims, supporting evidence, and regulatory requirements.
**Update PER continuously** throughout device lifecycle based on post-market surveillance data, literature updates, and performance follow-up activities.
### Post-Market Performance Follow-up
**Establish Post-Market Performance Follow-up (PMPF) plan** detailing systematic data collection and evaluation procedures for marketed devices. **Define data sources** including routine diagnostic testing, customer feedback, literature monitoring, and dedicated post-market studies.
**Implement systematic data collection** procedures ensuring representative post-market performance assessment. **Monitor performance indicators** continuously and establish trigger criteria for performance evaluation updates.
**Integrate PMPF findings** into ongoing risk management, quality management, and regulatory compliance activities. **Update technical documentation** based on significant performance findings affecting device safety or effectiveness.
## Example
**Scenario:** You develop a point-of-care immunoassay for cardiac biomarker detection to support acute coronary syndrome diagnosis in emergency departments. Your device is classified as Class C under IVDR requiring comprehensive performance evaluation including clinical performance studies.
### Performance Evaluation Planning
You assemble a performance evaluation team including clinical laboratory scientists, cardiologists, biostatisticians, and regulatory specialists. Your PEP defines the device for troponin detection in suspected acute coronary syndrome patients, specifying analytical and clinical performance requirements based on clinical guidelines and regulatory expectations.
### Scientific Validity Assessment
You conduct systematic literature review demonstrating troponin's established association with myocardial injury and acute coronary syndrome diagnosis. Your assessment includes meta-analyses, clinical practice guidelines, and consensus statements supporting troponin's diagnostic utility. You document the biological basis for troponin release during cardiac injury and its temporal relationship to clinical events.
### Analytical Performance Evaluation
You perform analytical studies demonstrating 10 ng/L limit of detection, \<5% imprecision across measuring range, and >95% concordance with laboratory reference methods. Your studies include interference assessments for common medications and endogenous substances. You establish measurement uncertainty and document analytical performance across expected clinical concentration ranges.
### Clinical Performance Evaluation
You conduct prospective clinical performance study in three emergency departments enrolling 1,200 patients with suspected acute coronary syndrome. Your study compares device results against adjudicated clinical diagnoses using established criteria. Results demonstrate 94% diagnostic sensitivity and 92% diagnostic specificity for acute coronary syndrome diagnosis. You analyze performance across relevant patient subgroups and clinical presentation patterns.
### Performance Evaluation Reporting
Your PER documents comprehensive performance evaluation evidence supporting intended use claims. The report includes literature evidence for scientific validity, analytical performance study results, clinical performance study findings, and overall benefit-risk assessment. You address both strengths and limitations in your performance evidence and plan ongoing performance monitoring.
## Q\&A
Analytical performance demonstrates your device's ability to correctly detect or measure analytes (accuracy, precision, sensitivity, specificity). Clinical performance demonstrates your device yields results correlated with clinical conditions in target populations (diagnostic sensitivity/specificity, predictive values). Both are required for IVDR compliance.
Clinical performance studies are not always required if adequate literature data exists demonstrating clinical performance. However, Class C and D devices typically require clinical performance studies due to higher risk profiles. Class A and B devices may rely more heavily on literature evidence and analytical performance data.
Review peer-reviewed literature, clinical practice guidelines, and regulatory guidance for evidence of analyte-condition associations. Consider biological plausibility, quality of existing evidence, and regulatory precedent. Well-established analytes like glucose or cholesterol have extensive scientific validity evidence, while novel biomarkers may require additional evidence generation.
Evaluators should possess relevant qualifications including device technology knowledge, research methodology expertise, literature review skills, IVDR regulatory understanding, and clinical knowledge relevant to the diagnostic area. The expertise level required varies with device complexity and risk classification.
Update your PER whenever new information becomes available that could affect device performance assessment including post-market surveillance findings, literature updates, regulatory guidance changes, or performance studies results. IVDR requires continuous performance evaluation throughout device lifecycle.
Use appropriate statistical methods for diagnostic test evaluation including sensitivity/specificity calculations, confidence intervals, ROC curve analysis, and clinical agreement assessments. Consider consulting biostatisticians and relevant guidance documents (such as STARD guidelines) for study design and analysis methodologies.
Include all relevant data, both favorable and unfavorable, in your performance evaluation. Document limitations honestly and assess their impact on overall benefit-risk determination. Consider if unfavorable findings require device modifications, labeling updates, or use restrictions to maintain acceptable benefit-risk profile.
Performance evaluation and risk management are interdependent processes. Performance data informs risk assessment and risk control effectiveness evaluation. Risk management activities may identify additional performance evaluation needs. Both processes contribute to overall benefit-risk determination and device safety assessment.
# SOP Post-Market Surveillance
Source: https://docs.withdovetail.com/tasks/sop-post-market-surveillance
Monitor real-world device performance through systematic data collection, analysis, and regulatory compliance reporting.
## Summary
Your **Post-Market Surveillance (PMS)** SOP establishes systematic processes for actively collecting, analyzing, and acting on real-world data about your device's safety, performance, and quality throughout its entire lifecycle to support continuous improvement and regulatory compliance.
## Why is SOP Post-Market Surveillance important?
Post-market surveillance exists because regulators recognize that **real-world performance** may differ from controlled study conditions. It demonstrates your commitment to ongoing safety monitoring rather than treating regulatory approval as the end of your responsibility. The systematic collection of field data helps identify previously unknown risks and validates clinical assumptions.
Your PMS system transforms scattered customer feedback into **actionable intelligence** that drives product improvements, informs regulatory decisions, and protects patients. It also provides early warning signals for potential issues before they become serious incidents requiring immediate regulatory action, allowing proactive rather than reactive responses.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Must establish **feedback systems** under Section 820.100(a)
* Medical Device Reporting (MDR) required under **21 CFR Part 803**
* Design controls must include **post-market feedback** integration (820.30)
* Complaint handling required under Section 820.198
* Management review must include **customer feedback** analysis
**Special attention required for:**
* MDR reporting timelines (24 hours for deaths, 10 days for serious injuries)
* 510(k) special controls compliance and post-market studies
* Unique Device Identification (UDI) reporting requirements
* Software maintenance and cybersecurity monitoring
Under **EU MDR 2017/745**:
* **Articles 83-86** mandate comprehensive post-market surveillance
* PMS plan required for **all devices** before market placement
* Periodic Safety Update Reports (PSUR) for higher-risk devices
* **Trend reporting** requirements under Article 88
* Integration with **vigilance system** and clinical evaluation updates
**Special attention required for:**
* PSUR timing requirements: IIa (every 2 years), IIb/III (annually)
* Post-Market Clinical Follow-up (PMCF) integration
* EUDAMED reporting and data sharing requirements
* Notified body submission requirements and assessment readiness
## Guide
Your PMS SOP establishes **proactive monitoring** systems that transform real-world data into actionable insights. Focus on creating sustainable processes that provide meaningful intelligence rather than just compliance documentation.
### PMS Plan Development
Create device-specific **PMS plans** that outline systematic data collection methods, analysis procedures, and decision criteria. Define clear objectives, target populations, data sources, and collection methods appropriate for your device type and risk classification. Include specific indicators and threshold values for triggering actions.
Establish systematic procedures for collecting information from multiple sources including customer complaints, scientific literature, vigilance databases, user feedback, and competitive intelligence. Design collection methods that provide representative and meaningful data rather than overwhelming your team with low-value information.
### Data Collection and Sources
Implement **multi-channel data collection** systems that capture diverse perspectives on device performance. Include direct customer feedback, distributor reports, scientific literature monitoring, regulatory database searches, and social media monitoring where appropriate. Create standardized forms and procedures to ensure consistent data quality.
Establish partnerships with key stakeholders including distributors, healthcare providers, and patient advocacy groups to enhance data collection capabilities. Include procedures for validating and verifying collected information to ensure reliability and accuracy.
### Analysis and Evaluation Methods
Develop **systematic analysis procedures** that transform raw data into meaningful insights. Include trend analysis methodologies, statistical significance testing, and benefit-risk assessment procedures. Establish clear criteria for determining when findings require action versus continued monitoring.
Create analysis workflows that involve appropriate subject matter experts including clinical specialists, risk management personnel, and regulatory affairs professionals. Include procedures for documenting analysis methods and results to support regulatory submissions and audits.
### Integration with Quality System
Connect PMS outputs to **all relevant quality processes** including CAPA, risk management, design controls, and clinical evaluation updates. Establish clear triggers for initiating corrective actions, design changes, or regulatory notifications based on PMS findings.
Include PMS data in management review reporting with trending analysis and performance indicators. Use PMS insights to inform strategic decisions about product improvements, market expansion, and risk management priorities.
### Reporting and Communication
Establish **systematic reporting procedures** that meet regulatory requirements while providing meaningful information to stakeholders. Create templates and workflows for PSUR development, trend reporting, and regulatory submissions that ensure consistency and completeness.
Develop communication procedures for sharing findings with relevant stakeholders including customers, distributors, regulatory authorities, and notified bodies. Include procedures for coordinating with other manufacturers when systemic issues affect multiple devices.
## Example
### Scenario
MedTech Solutions implements post-market surveillance for their diabetes monitoring app, collecting data from user feedback, app store reviews, customer support interactions, and clinical literature to monitor real-world performance and identify improvement opportunities.
### PMS System Implementation
**PMS Plan Development:**
* **Data Sources:** App analytics, customer support tickets, app store reviews, clinical literature, competitive intelligence
* **Collection Methods:** Automated data extraction, customer surveys, healthcare provider feedback forms
* **Analysis Frequency:** Monthly trending analysis, quarterly comprehensive review
* **Threshold Values:** >5% increase in crash reports, >3 complaints about accuracy per month
* **Action Criteria:** Statistical significance testing for trends, severity-based escalation procedures
**Data Collection Implementation:**
1. **Technical Performance Monitoring:** Automated collection of crash reports, performance metrics, usage patterns
2. **Customer Feedback Systems:** In-app feedback portal, quarterly satisfaction surveys, support ticket analysis
3. **Literature Monitoring:** Monthly PubMed searches, regulatory database monitoring, competitor analysis
4. **Healthcare Provider Input:** Semi-annual provider surveys, clinical outcome data collection
5. **Social Media Monitoring:** Automated scanning of relevant platforms for device mentions and issues
**Analysis and Response Example:**
**Finding:** 8% increase in glucose reading accuracy complaints over 3-month period
**Investigation:** Root cause analysis reveals algorithmic performance degradation with specific phone models
**Analysis:** Risk assessment indicates potential for delayed insulin administration decisions
**Actions:**
* Immediate: Customer advisory notice with workaround instructions
* Short-term: Software update addressing compatibility issue
* Long-term: Enhanced device compatibility testing procedures
**Follow-up:** Monitor complaint resolution and customer satisfaction improvement
**PSUR Development Process:**
* **Data Compilation:** Systematic review of all PMS data collected during reporting period
* **Trend Analysis:** Statistical analysis of complaint patterns, performance metrics, usage data
* **Clinical Review:** Assessment of real-world performance versus intended use claims
* **Risk Assessment:** Updated benefit-risk analysis incorporating new field data
* **Action Planning:** Identification of improvement opportunities and regulatory update needs
## Q\&A
Include customer complaints, scientific literature, vigilance databases, user feedback, distributor reports, service records, social media monitoring, and competitive intelligence. Focus on sources that provide representative information about real-world device performance and user experiences. Tailor your data sources to your device type and user population.
Use statistical analysis to identify significant increases in incident frequency or severity compared to expected baseline rates. Consider the clinical significance of trends, not just statistical significance. Document your trending methodology in your PMS plan and apply consistent criteria for determining when trends require reporting or action.
Post-Market Surveillance Reports (PMSR) are required for lower-risk devices (Class I/A/B) and focus on general PMS findings. Periodic Safety Update Reports (PSUR) are required for higher-risk devices with specific timing requirements and must include comprehensive safety analysis, benefit-risk assessment, and trend reporting.
Log all complaints related to device performance or safety and evaluate each for significance and trending patterns. Categorize complaints by type, severity, and potential impact. Use complaint data as a key input for trend analysis and include complaint statistics in your regular PMS reporting and analysis.
Initiate CAPA when PMS findings indicate systematic issues, safety concerns, or performance problems that require root cause investigation and corrective action. Use your established CAPA qualification criteria to evaluate PMS findings systematically. Include PMS trend analysis as a potential CAPA trigger in your procedures.
Establish review frequencies based on device risk classification and data volume. Higher-risk devices typically require more frequent monitoring. Include ongoing trending analysis (monthly/quarterly) and comprehensive periodic reviews (annual/biannual). Adjust frequencies based on device performance and market conditions.
# SOP Product Registration and Certification
Source: https://docs.withdovetail.com/tasks/sop-product-registration-and-certification
Navigate regulatory approval processes from technical file creation through market authorization and UDI registration.
## Summary
**SOP Product Registration and Certification** establishes the systematic processes for taking your medical device from completed development through regulatory approval and market entry. This Standard Operating Procedure (SOP) covers technical file creation, conformity assessment procedures, Unique Device Identification (UDI) registration, declaration of conformity creation, and product release protocols for both European Union (EU) and United States (US) markets.
## Why is SOP Product Registration and Certification important?
Product registration and certification represents the critical gateway between your completed medical device and commercial market access. **Without proper certification, your device cannot be legally marketed or sold** in regulated jurisdictions like the EU or US. This SOP ensures you systematically navigate complex regulatory requirements while avoiding costly delays, rejections, or legal compliance issues.
The certification process validates that your device meets essential safety and performance requirements, protecting both patients and healthcare providers. **Proper documentation and process adherence prevents market withdrawal** due to regulatory non-compliance, safeguards against liability issues, and establishes the foundation for post-market surveillance activities. For software medical devices particularly, this SOP addresses unique challenges around UDI management, version control, and ongoing compliance obligations.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and relevant FDA guidance:
* Medical devices must receive **Premarket Approval (PMA)** or **510(k) clearance** before commercialization
* **Unique Device Identification (UDI)** registration in Global Unique Device Identification Database (GUDID) is mandatory
* Manufacturers must establish **device establishment registration** and **device listing** (21 CFR Part 807)
* **Declaration of Conformity** must document compliance with applicable FDA regulations
**Special attention required for:**
* Software as Medical Device (SaMD) classification and submission requirements
* Cybersecurity documentation per FDA Guidance (2022)
* Quality System Regulation compliance (21 CFR Part 820)
* Post-market reporting obligations under Medical Device Reporting (MDR) regulation
Under **EU MDR 2017/745**:
* **Technical documentation** must comply with Annex II requirements
* **Conformity assessment** procedures according to Annexes IX, X, or XI based on device classification
* **UDI registration** in European Database for Medical Devices (Eudamed) when fully functional
* **EU Declaration of Conformity** following Annex IV format requirements
* **CE marking** affixation requirements per Article 20
**Special attention required for:**
* Notified Body involvement for Class IIa, IIb, and III devices
* Person Responsible for Regulatory Compliance (PRRC) designation
* Post-market surveillance plan implementation
* Software lifecycle processes (MDCG 2019-11 guidance)
* UDI-DI changes for software modifications (MDCG 2018-6)
## Guide
### Creating Technical Documentation
**Compile comprehensive technical documentation** that serves as the foundation for your certification process. Your technical file must demonstrate compliance with essential requirements and include device specifications, design documentation, risk management files, verification and validation reports, clinical evaluation data, and post-market surveillance plans.
**Structure your technical file systematically** following regulatory annexes. Include device descriptions with all variants and accessories, information supplied to users (Instructions for Use, labels, packaging), complete design and manufacturing information, general safety and performance requirements documentation, benefit-risk analysis results, verification and validation evidence, pre-clinical and clinical data where applicable, and post-market surveillance frameworks.
**Maintain document traceability** throughout your technical file. Reference supporting documents clearly and ensure all information is current and accurately reflects your final device design. Your technical file can contain full documentation or executive summaries with appropriate cross-references to detailed supporting documents.
### EU Certification Pathway
**Confirm your device classification** before initiating conformity assessment procedures. Verify your MDR/IVDR classification according to Annex VIII rules and determine the appropriate MDR/IVDR codes following current guidance. **Your classification determines your conformity assessment route** and whether Notified Body involvement is required.
**For Class I devices (non-sterile, non-measuring, non-reusable surgical)**, you can **self-certify** once technical documentation is complete. Draft and sign your EU Declaration of Conformity confirming compliance with all applicable MDR requirements. **No Notified Body assessment is required** for these devices.
**For higher-class devices**, **select and engage an appropriate Notified Body**. Research Notified Bodies designated for your device's MDR/IVDR codes, evaluate their capacity, timelines, and costs, then initiate formal engagement. Provide comprehensive technical documentation and coordinate throughout the conformity assessment process. **Address any non-conformities systematically** with supporting evidence and corrective actions.
**Prepare your EU Declaration of Conformity** following Annex IV requirements. Include manufacturer identification and Single Registration Number (SRN), basic UDI-DI information, complete product identification and traceability data, device risk classification, conformity statements, applicable harmonized standards references, Notified Body details where applicable, and authorized signatory information.
### US Certification Pathway
**Determine your FDA submission pathway** based on device classification and predicate device availability. Class I devices may qualify for exemptions, Class II devices typically require 510(k) clearance, and Class III devices need Premarket Approval (PMA). **Consider pre-submission meetings** with FDA to confirm regulatory strategy and submission requirements.
**Prepare comprehensive submission documentation** including device description and intended use, substantial equivalence comparison for 510(k) submissions, performance testing data, software documentation for software-containing devices, labeling including Instructions for Use, risk analysis documentation, and quality system compliance evidence.
**Create US Declaration of Conformity** following FDA requirements. Document manufacturer information, product identification and traceability, risk classification, FDA regulation compliance statements, and authorized signatory details. **Ensure alignment with your FDA submission** content and approved labeling.
### UDI Creation and Registration
**Generate UDI components systematically** using designated issuing entities (GS1, HIBCC, ICCBBA, or IFA). **Create Basic UDI-DI** from your full UDI-DI using issuing entity calculators. **Assign UDI-PI** reflecting software version or production date following issuing entity guidance.
**Register UDI information in appropriate databases**. For EU market, register in Eudamed once fully functional (use national systems during transition period). For US market, register in FDA's Global Unique Device Identification Database (GUDID) before commercialization.
**Establish UDI change management procedures**. **New UDI-DI required** for changes affecting device identification or traceability including name changes, new features, interoperability modifications, user interface changes, new operating systems, programming language updates, algorithm modifications, and architecture changes. **New UDI-PI required** for version updates, bug fixes, patches, and cosmetic user interface changes.
### Product Release Procedures
**Complete final release verification** through systematic checklist review. **For software medical devices**, verify software release checklist completion, all documentation updates reflecting final software version, UDI-PI assignment matching release version, and change documentation for any modifications since previous release.
**For hardware-containing devices**, complete hardware release checklist verification, manufacturing validation documentation, design transfer confirmation, and supplier qualification verification.
**Authorize final product release** only after confirming technical file completeness, declaration of conformity approval, UDI registration completion, regulatory submission acceptance or approval, and all quality management system requirements fulfillment.
## Example
**Scenario:** You develop a mobile application for diabetes management that connects to a glucose meter via Bluetooth. The software analyzes glucose trends and provides recommendations to users. You're preparing for EU MDR certification as a Class IIa medical device and US FDA 510(k) clearance.
### Technical File Creation
You compile technical documentation including your software development plan, system and software requirements, software architecture documentation, risk management file with cybersecurity analysis, usability evaluation report, clinical evaluation report demonstrating safety and performance, and post-market surveillance plan.
### EU Certification Process
Since your device is Class IIa, you research Notified Bodies designated for software medical devices under MDR codes M0104 (medical device software) and select one based on capacity and expertise. You submit technical documentation and undergo conformity assessment including QMS certification and technical file review. After addressing minor observations about your cybersecurity documentation, you receive your CE certificate.
### UDI Registration
You purchase a GS1 company prefix and generate UDI-DI for your device family. Your Basic UDI-DI becomes the primary identifier for your device across all versions. You assign UDI-PI based on software version (e.g., "1.2.3") and register both in Eudamed and GUDID databases.
### US FDA Process
You submit a 510(k) comparing your device to an FDA-cleared diabetes management app predicate. Your submission includes software documentation, cybersecurity analysis, usability testing results, and clinical validation data. FDA issues clearance after standard review cycle.
### Final Release
You complete software release checklist verifying all documentation accuracy, approve updated Instructions for Use in English and required local languages, finalize EU Declaration of Conformity with CE marking authorization, update device labeling with UDI and regulatory statements, and authorize commercial release following final management review.
## Q\&A
Technical documentation encompasses all documents supporting your device's safety and performance. A technical file is the compiled collection of this documentation organized according to regulatory requirements. The technical file can contain complete documents or summaries with references to detailed supporting documentation stored separately.
Class I devices (non-sterile, non-measuring, non-reusable surgical) can self-certify without Notified Body involvement. All other device classes (Class Is, Im, Ir, IIa, IIb, III for MDR; Class A sterile, B, C, D for IVDR) require Notified Body conformity assessment before placing devices on the EU market.
New UDI-DI is required for changes affecting device identification or traceability: name changes, new features, interoperability modifications, significant user interface changes, new operating systems, programming languages, algorithms, or architecture changes. New UDI-PI is sufficient for bug fixes, patches, minor UI updates, and version increments without functional changes.
Classification changes may require different conformity assessment procedures, additional Notified Body involvement, or modified submission pathways. Document the classification change rationale, update technical documentation accordingly, and consult with your Notified Body or regulatory authority about required procedural modifications.
You can pursue parallel certification pathways with staggered market releases. Ensure UDI registration covers all intended markets, prepare market-specific labeling and Instructions for Use, maintain separate release documentation for each jurisdiction, and implement appropriate post-market surveillance for released markets while completing certification for others.
For GUDID: Obtain FDA establishment registration, create FURLS account, prepare device information including DI/PI and FDA product codes, submit via web interface or HL7 SPL format, and validate submission accuracy. For Eudamed: Obtain SRN registration, access Eudamed portal when fully functional, prepare device information with Basic UDI-DI, submit device registration, and maintain current information throughout device lifecycle.
Document software lifecycle processes following IEC 62304, provide verification and validation evidence demonstrating requirements compliance, include cybersecurity validation per relevant guidance, document usability validation results, maintain software bill of materials (SOUP list), and provide evidence of software quality management system implementation throughout development.
Provide complete technical file per Annex II/III requirements, quality management system documentation, device classification justification, risk management documentation, clinical evaluation or performance evaluation data, post-market surveillance plan, declaration of conformity draft, and any additional information specific to your Notified Body's review procedures.
# SOP Purchasing
Source: https://docs.withdovetail.com/tasks/sop-purchasing
Qualify and manage suppliers ensuring purchased products meet quality requirements and regulatory standards.
## Summary
Your **Purchasing** SOP establishes systematic processes for qualifying, evaluating, and managing suppliers to ensure that all purchased products and services meet quality requirements and do not compromise the safety, performance, or regulatory compliance of your medical devices.
## Why is SOP Purchasing important?
Purchasing controls exist because regulators recognize that **supply chain quality** directly impacts device safety and performance. Poor quality components or services can introduce risks that may not be detected until devices reach patients. The SOP ensures that third-party suppliers meet the same quality standards that apply to your internal processes.
Your purchasing system demonstrates **systematic supplier management** rather than ad-hoc procurement decisions. It provides traceability for quality issues, enables effective corrective actions when supplier problems occur, and ensures consistent quality regardless of personnel changes. This protects both patients and your organization from supply chain-related quality failures.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Purchasing controls **mandatory** under Section 820.50
* Must evaluate and select suppliers based on **ability to meet requirements**
* Purchasing data must adequately describe **product specifications**
* Suppliers must notify of changes that **affect conformance**
* Incoming inspection and testing required under Section 820.80
**Special attention required for:**
* Change notification agreements with critical suppliers
* Incoming inspection requirements for purchased products
* Supplier audit and surveillance documentation
* Traceability requirements for purchased materials
Under **EU MDR 2017/745**:
* Purchasing controls required as part of **quality management system** (Article 10(9))
* Must comply with **EN ISO 13485:2016 Section 7.4**
* Supplier qualification must be **proportionate to risk**
* Critical suppliers require **enhanced controls** and surveillance
* Notified body assessment includes **supplier control** evaluation
**Special attention required for:**
* Risk-based supplier classification and control measures
* Annual supplier evaluation requirements for higher-risk devices
* Notified body expectations for supplier audit documentation
* Material certificates and compliance documentation requirements
## Guide
Your Purchasing SOP establishes **controlled procurement** processes that ensure supply chain quality while maintaining efficiency. Focus on risk-based approaches that apply appropriate controls without creating unnecessary bureaucracy.
### Supplier Classification and Criticality Assessment
Implement **systematic criteria** for determining supplier criticality based on potential impact on device safety, performance, and regulatory compliance. Classify suppliers as critical if their products or services directly affect device characteristics or if no alternative suppliers exist. Apply enhanced controls only where justified by risk.
Create clear definitions for critical versus non-critical suppliers with consistent application across your organization. Document criticality assessments to provide auditors with evidence of your risk-based approach to supplier management.
### Supplier Qualification and Evaluation
Develop **standardized qualification processes** that evaluate supplier capability, quality systems, resources, and performance history. Create qualification checklists and scoring systems that provide objective assessments while allowing flexibility for different supplier types and risk levels.
Establish qualification criteria covering technical capability, quality system maturity, regulatory compliance, and business stability. Include verification methods such as documentation review, facility audits, or sample testing based on supplier criticality and risk assessment.
### Approved Supplier List Management
Maintain an **Approved Supplier List (ASL)** that provides clear status for all qualified suppliers including approval status, criticality classification, and any special requirements or restrictions. Include surveillance requirements and re-evaluation schedules based on supplier performance and risk level.
Implement version control for your ASL with clear approval authority and change control procedures. Include procedures for adding new suppliers, updating existing supplier status, and removing or blocking suppliers when performance issues arise.
### Purchasing Controls and Documentation
Establish **systematic purchasing procedures** that ensure only approved suppliers are used for critical components or services. Create purchasing documentation requirements that adequately describe product specifications, acceptance criteria, and quality requirements.
Include change notification agreements with critical suppliers requiring advance notice of any changes that could affect product conformance. Establish procedures for evaluating supplier-initiated changes and updating your own documentation when necessary.
### Incoming Inspection and Verification
Implement **risk-based incoming inspection** procedures that verify purchased products meet specified requirements. Establish inspection criteria, sampling plans, and acceptance procedures appropriate for different product types and supplier risk levels.
Create nonconformance procedures for handling substandard purchased products including supplier notification, return processes, and impact assessment on your quality system. Include procedures for updating supplier evaluations based on incoming inspection results.
### Supplier Surveillance and Continuous Monitoring
Establish **ongoing surveillance** procedures for monitoring supplier performance including delivery performance, quality metrics, and compliance status. Implement annual supplier reviews that evaluate performance trends and update criticality assessments.
Create procedures for responding to supplier performance issues including corrective action requests, enhanced surveillance measures, and supplier blocking when necessary. Include supplier performance data in management review reporting for trend analysis.
## Example
### Scenario
MedTech Solutions needs to qualify cloud hosting services for their diabetes monitoring app and establish purchasing controls for critical software components and third-party services that could impact device performance or data security.
### Purchasing System Implementation
**Supplier Criticality Assessment:**
* **Cloud Hosting Provider:** Critical (directly affects device availability and data security)
* **Analytics Software:** Critical (affects glucose calculation accuracy)
* **Marketing Agency:** Non-critical (no impact on device performance or safety)
* **Legal Services:** Non-critical (no direct impact on product quality)
**Critical Supplier Qualification Process:**
**Cloud Hosting Provider Evaluation:**
1. **Technical Capability:** Review infrastructure specifications, uptime guarantees, disaster recovery procedures
2. **Quality System:** Evaluate ISO 27001 certification, SOC 2 Type II compliance, change management procedures
3. **Regulatory Compliance:** Verify GDPR compliance, data residency requirements, security certifications
4. **Business Stability:** Review financial statements, customer references, service level agreements
5. **Scoring:** Rate each category 0-3, calculate average score of 2.8 (approved with surveillance)
**Purchasing Documentation Requirements:**
* **Service Specifications:** Detailed SLA requirements, uptime guarantees, data backup procedures
* **Acceptance Criteria:** Performance monitoring thresholds, security audit requirements
* **Change Notification:** 30-day advance notice for infrastructure changes affecting service
* **Quality Requirements:** Compliance with medical device data handling requirements
**Supplier Surveillance Implementation:**
* **Monthly Performance Review:** Uptime monitoring, security incident tracking, SLA compliance
* **Quarterly Business Review:** Service performance discussion, upcoming changes, improvement planning
* **Annual Assessment:** Full re-evaluation of qualification criteria, contract renewal process
* **Continuous Monitoring:** Automated alerting for service disruptions, security notifications
**Approved Supplier List Entry:**
| Supplier | Category | Criticality | Status | Last Evaluation | Next Review | Surveillance |
| --------------- | -------------- | ----------- | -------- | --------------- | ----------- | ------------------ |
| CloudHost Pro | Infrastructure | Critical | Approved | 2024-03-15 | 2025-03-15 | Monthly SLA review |
| DataAnalyze Inc | Software | Critical | Approved | 2024-02-20 | 2025-02-20 | Quarterly audit |
## Q\&A
Classify suppliers as critical if their products or services could directly impact device safety, performance, or regulatory compliance, or if they provide unique capabilities with no alternative suppliers available. Use systematic criteria and document your assessment rationale. Non-critical suppliers have no direct impact on device quality characteristics.
Include product specifications, acceptance criteria, quality requirements, and any special handling or storage requirements. For critical suppliers, add change notification requirements and quality system expectations. Ensure purchasing information adequately describes what you need to verify conformance to requirements.
Re-evaluate critical suppliers at least annually or when significant performance issues occur. Non-critical suppliers can be evaluated less frequently based on risk and performance history. Include supplier performance trends in management review for systematic oversight and continuous improvement.
Follow your nonconforming product control procedures, notify the supplier, and assess impact on your operations. Update the supplier's evaluation score and consider enhanced surveillance or corrective action requirements. Document the nonconformance for trending analysis and supplier performance tracking.
Use risk-based surveillance including incoming inspection, performance monitoring, periodic audits, or quality assurance agreements. Higher-risk suppliers may require on-site audits, while lower-risk suppliers might only need performance monitoring. Tailor surveillance to supplier criticality and performance history.
Require advance notification for any changes that could affect product conformance, especially from critical suppliers. Evaluate each change for impact on your device requirements and update your own documentation as necessary. Include change notification requirements in supplier agreements and purchasing contracts.
# SOP Risk Management
Source: https://docs.withdovetail.com/tasks/sop-risk-management
Manage systematic risk identification, analysis, and control processes ensuring patient safety and regulatory compliance.
## Summary
Your **Risk Management** SOP establishes a systematic process for identifying, analyzing, evaluating, and controlling risks throughout the medical device lifecycle, ensuring patient and user safety while maintaining device functionality and compliance with ISO 14971:2019 requirements.
## Why is SOP Risk Management important?
Risk management exists because medical devices can potentially harm patients or users if risks are not properly identified and controlled. Regulators require **systematic risk management** to demonstrate that manufacturers have proactively considered potential hazards and implemented appropriate controls before devices reach the market.
The SOP ensures **consistent risk assessment** across all development phases and provides a framework for making risk-based decisions about design, testing, and post-market activities. It transforms risk management from reactive problem-solving into **proactive safety engineering** that builds confidence with regulators, customers, and internal stakeholders.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Risk analysis is **required** under Section 820.30(g) for design validation
* Must be conducted throughout **design controls** (820.30)
* Risk management must be **integrated** with design and development activities
* Post-market risk assessment required through **CAPA** and feedback processes
**Special attention required for:**
* Software risk management considerations (IEC 62304 integration)
* Cybersecurity risk assessment for connected devices
* Clinical evaluation risk-benefit analysis
* Post-market surveillance risk monitoring
Under **EU MDR 2017/745**:
* Risk management is **mandatory** under Annex I Essential Requirements
* Must comply with **EN ISO 14971:2019** risk management standard
* Risk-benefit analysis required for **clinical evaluation** (Article 61)
* Risk information must be included in **technical documentation** (Annex II)
**Special attention required for:**
* Risk management integration with clinical evaluation
* Post-market surveillance risk monitoring (Articles 83-86)
* Risk-benefit analysis documentation
* Notified body assessment of risk management process
## Guide
Your Risk Management SOP provides the **foundation** for systematic safety assessment throughout the device lifecycle. Structure the process to be comprehensive yet practical for your organization size and device complexity.
### Risk Management Planning
Establish a **comprehensive risk management plan** that defines scope, responsibilities, risk acceptance criteria, and review requirements. The plan should align with your development timeline and integrate with design controls, validation activities, and post-market surveillance.
Create **risk acceptance criteria** that reflect your device's intended use, patient population, and clinical environment. Use a risk matrix approach that considers both probability and severity, with clear definitions for acceptable, tolerable, and unacceptable risk levels.
Define **responsibilities and authorities** for risk management activities, including who can approve risk assessments, accept residual risks, and authorize risk control measures. Ensure appropriate expertise is assigned to risk management activities.
### Hazard Identification and Risk Analysis
Conduct **systematic hazard identification** that considers all foreseeable hazards including hardware failures, software malfunctions, user errors, environmental factors, and cybersecurity threats. Use structured approaches like fault tree analysis, failure mode analysis, or hazard analysis techniques.
Perform **risk estimation** by evaluating the probability of hazardous situations occurring and the severity of potential harm. Consider factors like device complexity, use environment, user training, and patient vulnerability when estimating risks.
Document **traceability** from hazards through hazardous situations to potential harms, ensuring that risk controls address the complete causal chain. This traceability is critical for regulatory submissions and audit evidence.
### Risk Control Implementation
Implement **risk controls** following the hierarchy of controls: inherently safe design, protective measures, and information for safety. Prioritize design-based controls over user training or warnings whenever possible.
Verify **risk control effectiveness** through testing, analysis, or other objective methods. Ensure that risk controls actually reduce risks to acceptable levels and don't introduce new unacceptable risks.
Conduct **residual risk evaluation** after implementing controls to confirm that remaining risks are acceptable and that the overall benefit-risk balance is positive.
### Risk Management Integration
Connect risk management with **design controls** by using risk assessment outputs to inform design inputs, verification activities, and validation requirements. Risk management should guide development decisions throughout the design process.
Integrate with **post-market activities** by establishing mechanisms to collect and evaluate risk-related information from complaints, adverse events, and performance monitoring. Use this information to reassess risks and implement additional controls if needed.
### Risk Management File Documentation
Maintain a **comprehensive risk management file** that provides traceability from hazard identification through risk control implementation and verification. Include risk management plan, risk assessments, risk control measures, verification evidence, and post-market risk information.
Ensure the risk management file supports **regulatory submissions** with clear documentation of risk management process compliance and evidence of systematic risk assessment and control.
## Example
### Scenario
BioTech Diagnostics develops a portable blood glucose meter for home use by diabetic patients. They implement comprehensive risk management to identify potential hazards, assess risks, and implement controls to ensure patient safety while maintaining device functionality.
### Example Risk Management Implementation
**Risk Management Plan:**
* **Scope:** Complete device lifecycle from design through post-market surveillance
* **Risk Acceptance Criteria:** 5x5 matrix with probability vs. severity levels
* **Responsibilities:** Product team identifies hazards, quality team reviews assessments
* **Review Schedule:** Risk assessment updates at each design phase gate
**Hazard Identification:**
* **Device Component Analysis:** Battery failure, display malfunction, test strip compatibility
* **User Interface Hazards:** Confusing readings, difficult button operation
* **Environmental Factors:** Temperature effects, moisture damage, electromagnetic interference
* **User Error Scenarios:** Wrong test strip insertion, contaminated samples, missed calibration
**Risk Assessment Example:**
* **Hazard:** Incorrect glucose reading due to test strip contamination
* **Hazardous Situation:** Patient receives false low glucose reading
* **Potential Harm:** Patient doesn't treat actual high glucose, leading to diabetic complications
* **Probability:** Occasional (test strips exposed to moisture)
* **Severity:** Serious (delayed treatment of hyperglycemia)
* **Risk Level:** Unacceptable - requires risk control measures
**Risk Controls Implemented:**
1. **Inherent Safety:** Individual foil-sealed test strip packaging
2. **Protective Measures:** Error codes for invalid readings, automatic calibration verification
3. **Information for Safety:** Clear instructions for proper test strip storage and handling
**Verification Activities:**
* Environmental testing confirms moisture protection effectiveness
* User testing validates error message clarity and user response
* Clinical accuracy testing verifies reading reliability under normal and edge conditions
**Residual Risk Evaluation:**
* After controls: Probability reduced to "Remote," Risk level now "Acceptable"
* Benefit-risk analysis confirms positive benefit-risk balance
* Overall residual risk acceptable for intended patient population
## Q\&A
Add more serious risks, particularly around psychological stress, and consider adding "personal harm" as a risk category. Make risk descriptions specific and create test scenarios for each risk. Focus on foreseeable hazards that could realistically occur during device use rather than theoretical scenarios.
If a new risk is identified during vigilance database review, it should be added to the risk assessment to ensure all foreseeable risks are accounted for. Evaluate the risk using your established criteria and implement appropriate controls if the risk is unacceptable.
The general approach is to cover all obvious foreseeable risks. If there are things that are very unlikely to happen or are not thought of, that's acceptable. Auditors look for a robust list of foreseeable risks. If something is missed, a minor update can be done later rather than requiring complete reassessment.
It is recommended to categorize at least one component as medium risk to demonstrate risk assessment capability, even if the software is generally low risk. This shows that you have properly evaluated risk levels rather than assuming everything is low risk.
The risks identified in the risk management process should be used as inputs for clinical evaluation processes. Risk-benefit analysis should consider both the risks identified in risk management and the clinical benefits demonstrated through clinical evaluation activities.
Collect information from customer complaints, adverse event reports, quality control metrics, user feedback, and post-market surveillance activities. This information should be regularly reviewed to identify new hazards or changes in risk levels that may require additional risk controls.
# SOP Sales
Source: https://docs.withdovetail.com/tasks/sop-sales
Market medical devices through controlled processes ensuring validated claims and compliant distribution channels.
## Summary
Your **Sales** SOP establishes controlled processes for marketing, selling, and distributing medical devices while ensuring all promotional claims are validated, regulatory requirements are met, and only certified products reach customers through compliant distribution channels.
## Why is SOP Sales important?
Sales controls exist because regulators need assurance that medical devices are **marketed truthfully** and distributed only to appropriate users. Misleading claims can lead to improper device use, patient harm, and regulatory enforcement actions. The SOP protects patients by ensuring marketing accuracy while protecting your company from regulatory violations and liability.
Your sales process also demonstrates that your organization maintains **traceability** from development through distribution, which is essential for post-market surveillance and field corrective actions. It ensures that only properly certified and released products reach the market, and that customer feedback flows back into your quality system for continuous improvement.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Customer requirements must be **reviewed and approved** under Section 820.30(c)
* Marketing claims must be **substantiated** and accurate
* Distribution controls required under Section 820.160
* Promotional labeling regulated under **21 CFR Part 801**
* Medical Device Reporting (MDR) requirements for customer feedback
**Special attention required for:**
* FDA promotional guidance compliance and off-label promotion restrictions
* 510(k) predicate device claims substantiation
* Distributor agreements and complaint handling procedures
* Social media and digital marketing regulatory requirements
Under **EU MDR 2017/745**:
* **Article 7** prohibits misleading marketing and advertising claims
* Marketing must align with **intended purpose** and conformity assessment
* Claims must be **substantiated** by clinical evidence
* Distance sales restrictions and **authorized representative** requirements
* PRRC oversight of marketing claims and customer communications
**Special attention required for:**
* Clinical evidence substantiation for all performance claims
* IVDR Article 6 restrictions on distance sales for certain device classes
* Language requirements for labeling and instructions for use
* German MPDG requirements for medical device consultants
## Guide
Your Sales SOP establishes **controlled marketing** and distribution processes that protect both patients and your company. Focus on creating systems that ensure accuracy, traceability, and regulatory compliance throughout the customer journey.
### Marketing Material Development and Control
Implement a **systematic review process** for all marketing materials before release. Establish clear criteria for what constitutes a performance or safety claim requiring validation versus general descriptive content. Create approval workflows that involve quality team review for technical accuracy and regulatory compliance.
Maintain version control for all marketing materials with clear approval records. Establish procedures for updating materials when product changes occur through your change management process. Include review timelines and responsible parties to ensure materials remain current and accurate.
### Claim Substantiation and Validation
Develop processes for **substantiating all claims** with appropriate evidence from your technical documentation, clinical evaluations, or performance studies. Avoid making claims that exceed your intended use or go beyond validated performance characteristics.
Create claim libraries that link marketing statements to supporting evidence in your technical files. This provides auditors with clear traceability and helps ensure consistency across all marketing channels. Include processes for reviewing claims when supporting evidence changes.
### Customer Contract Management
Establish **systematic processes** for evaluating customer requirements and ensuring your organization can meet contractual obligations. Include feasibility assessments covering product availability, service capabilities, regulatory compliance, and post-sales support requirements.
Implement contract review procedures that verify customer understanding of device intended use, user requirements, and any usage restrictions. Document customer communications to support post-market surveillance and complaint management processes.
### Distribution Controls and Traceability
Create systems for **tracking device distribution** from release through customer delivery. Implement procedures that ensure only properly released products are distributed and that distribution records support post-market surveillance and field corrective action requirements.
Establish customer onboarding processes that verify appropriate user qualifications where required by regulation. Include procedures for handling specialized distribution requirements such as prescription-only or professional-use-only devices.
### Integration with Quality System
Connect sales processes to **post-market surveillance** through systematic customer feedback collection. Establish procedures for identifying and escalating quality issues discovered through sales interactions. Include customer complaint handling procedures that feed into your CAPA system.
Integrate sales data with management review reporting to track customer satisfaction, complaint trends, and market performance indicators.
## Example
### Scenario
MedTech Solutions launches their diabetes monitoring app in European markets. They need to ensure all marketing claims are substantiated, distribution complies with MDR requirements, and customer feedback flows into their quality system for continuous monitoring and improvement.
### Sales Process Implementation
**Marketing Material Development:**
* **Technical Claims Review:** Quality team validates all app performance claims against clinical evaluation data
* **Intended Use Alignment:** Marketing materials clearly state device is for diabetes self-monitoring, not diagnosis
* **Evidence Mapping:** Each performance claim linked to specific validation study results
* **Regulatory Review:** PRRC reviews materials for MDR Article 7 compliance
* **Approval Workflow:** Marketing manager and quality representative approve materials before release
**Customer Onboarding Process:**
1. **Requirement Assessment:** Evaluate customer technical requirements and intended use alignment
2. **Regulatory Verification:** Confirm customer location permits device marketing under current CE marking
3. **Contract Development:** Standard terms include intended use restrictions and complaint reporting procedures
4. **Distribution Authorization:** Verify device version matches approved technical documentation
5. **Post-Sales Support:** Establish customer service contact for technical support and complaint handling
**Claim Substantiation Example:**
* **Marketing Claim:** "Provides glucose trend analysis with 95% accuracy"
* **Supporting Evidence:** Clinical validation study report demonstrating 95.2% correlation with reference method
* **Documentation Link:** Technical file Section 6.3, Clinical Evaluation Report pages 45-52
* **Review Record:** Quality team approval dated March 15, 2024, approved by Quality Manager
**Distribution Controls:**
* Customer receives device download link only after contract execution
* Distribution records maintained linking customer to specific software version
* Automated system tracks downloads and installation confirmations
* Customer feedback portal integrated with complaint management system
* Quarterly customer satisfaction surveys feed into management review process
## Q\&A
Any claims related to device performance, safety, accuracy, clinical benefits, or comparative effectiveness require validation with supporting evidence from your technical documentation. General descriptive statements about features or user interface elements typically don't require formal validation, but should still be accurate and reviewed for regulatory compliance.
Integrate marketing material review into your change management process. When product modifications occur, include assessment of marketing material impacts in your change control procedures. Maintain a claims database that links marketing statements to supporting evidence, making it easier to identify materials requiring updates.
Customer contracts should include clear statements of intended use, user requirements, any usage restrictions, and complaint reporting procedures. Review customer requirements for feasibility and regulatory compliance before contract execution. Maintain contract records to support post-market surveillance and distribution tracking requirements.
Establish systematic processes for collecting, categorizing, and escalating customer feedback through your complaint management system. Train sales team members to identify quality-related issues and route them appropriately. Include customer satisfaction metrics in management review reporting and trend analysis.
Verify regulatory approvals and marketing authorizations for each target market before initiating sales. Consider language requirements for labeling and instructions for use. Some markets have specific requirements like the German MPDG medical device consultant requirements or IVDR restrictions on distance sales for certain device classes.
Evaluate whether the requested information constitutes new performance or safety claims requiring formal validation. If the information is substantially similar to approved content, it may be provided. If it represents new claims or goes beyond validated performance characteristics, it must go through your claim validation and approval process before sharing.
# SOP Software Problem Resolution
Source: https://docs.withdovetail.com/tasks/sop-software-problem-resolution
Execute systematic frameworks for identifying, investigating, and resolving software problems throughout device lifecycles.
## Summary
This Standard Operating Procedure (SOP) establishes a systematic framework for **identifying, investigating, and resolving software problems** throughout the medical device software lifecycle. It ensures that software issues are properly documented, analyzed for safety impact, and resolved through appropriate change control processes while maintaining compliance with IEC 62304 software lifecycle requirements.
## Why is SOP Software Problem Resolution important?
**Software problems** in medical devices can directly impact patient safety and device effectiveness. The FDA and other regulatory authorities require manufacturers to have robust processes for identifying and resolving software issues, as software defects are a leading cause of medical device recalls and safety incidents.
This SOP is essential because software problems can emerge **at any stage** - during development, testing, or post-market use. Without a systematic approach to problem resolution, critical safety issues might be overlooked, improperly analyzed, or inadequately addressed. The regulation requires that you demonstrate **due diligence** in identifying problems, conducting thorough root cause analysis, and implementing appropriate corrective actions.
For **IEC 62304 compliance**, software problem resolution is mandatory for all safety classification levels, with increasing rigor required for Class B and Class C software that could contribute to hazardous situations.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Section **820.100** requires establishment of procedures for implementing corrective and preventive actions
* **820.198** mandates complaint handling procedures for software-related issues
* Software changes must follow **design control** requirements under 820.30
* Problem resolution must be documented as **quality records** under 820.180
**IEC 62304** (Software Lifecycle Processes):
* Section **9** requires software problem resolution processes for all safety classes
* Problem analysis must consider **safety implications** and update risk analysis
* Software changes require **verification and validation** appropriate to safety classification
**Special attention required for:**
* Safety-related problems require immediate risk assessment
* Software problem resolution must integrate with CAPA system
* Change control processes must maintain design control compliance
* Post-market software problems may trigger FDA reporting requirements
Under **EU MDR 2017/745**:
* **Annex I Section 17.2** requires software lifecycle processes following recognized standards
* Software problems must be evaluated through **risk management** per ISO 14971
* Problem resolution must support **post-market surveillance** obligations under Articles 83-86
* Safety-related software problems may trigger **incident reporting** under Article 87
**IEC 62304** integration with EU requirements:
* Software problem resolution supports **clinical evaluation** maintenance
* Problem trends must inform **benefit-risk analysis** updates
* Resolution processes must maintain **conformity assessment** validity
**Special attention required for:**
* Software problems affecting safety must be reported to competent authorities
* Problem resolution must maintain CE marking validity
* Technical file updates may be required for significant software changes
* PRRC oversight required for safety-related problem resolution
## Guide
### Establishing Problem Identification and Reporting Processes
**Problem identification** must be proactive and comprehensive. Software problems can originate from multiple sources: customer complaints, internal testing, post-market surveillance, vulnerability assessments, or routine software monitoring. Establish clear channels for **reporting problems** from all these sources.
Use a **centralized ticketing system** to track all software problems from identification through resolution. This system should integrate with your complaint handling process, CAPA system, and change control procedures. Each problem report must capture essential information including problem description, affected software versions, safety implications, and steps to reproduce the issue.
**Document problem classification** based on type (corrective, preventive, adaptive), scope (number of devices affected, change complexity), and criticality (safety, performance, security impact). This classification drives the appropriate level of investigation and resolution approach.
### Conducting Thorough Problem Investigation
**Root cause analysis** is mandatory for all software problems, with depth proportional to safety classification and potential impact. For Class A software with no safety impact, basic analysis may suffice. For Class B and C software, conduct comprehensive analysis including:
* **Technical root cause** - What specific code, configuration, or design element caused the problem
* **Process root cause** - What development, verification, or validation process failed to prevent the problem
* **Systemic analysis** - Whether similar problems exist elsewhere in your software or processes
**Safety assessment** is critical for all problems. Use your risk management process to evaluate whether the problem introduces new hazards, changes existing risk levels, or affects risk control measures. Update your risk management file accordingly and consider whether additional risk controls are needed.
**Trend analysis** helps identify systematic issues. Look for patterns in problem types, affected components, or root causes that might indicate broader quality system problems requiring preventive action.
### Implementing Appropriate Resolution Strategies
**Change control integration** is essential for problem resolution. All software changes to resolve problems must follow your design control and change management procedures. The extent of verification and validation required depends on the **safety classification** and scope of changes.
For **safety-related problems**, implement immediate risk controls while developing permanent solutions. This might include software patches, user notifications, or temporary operational constraints. Document these interim measures and verify their effectiveness.
**Verification of problem resolution** must demonstrate that the implemented solution actually resolves the problem without introducing new issues. For Class B and C software, conduct appropriate **regression testing** to ensure existing functionality remains intact.
### Managing Problem Resolution Documentation
**Traceability** between problems, root causes, implemented changes, and verification results is mandatory for regulatory compliance. Your ticketing system should maintain this traceability automatically, but ensure manual documentation captures the complete resolution story.
**Problem closure** requires verification that the solution is effective and complete. This includes technical verification of the fix, confirmation that safety assessments are updated, and documentation that all required change control activities are complete.
### Integrating with Broader Quality Processes
**CAPA integration** ensures that software problems contributing to broader quality issues trigger appropriate corrective and preventive actions. Not all software problems require formal CAPAs, but safety-related issues and systemic problems should.
**Post-market surveillance** must incorporate software problem data to maintain ongoing benefit-risk assessments. Problem trends and resolution effectiveness provide valuable data for clinical evaluation updates and regulatory submissions.
**Annual review** of software problems helps identify improvement opportunities for both your products and processes. Look for recurring problem types, resolution effectiveness, and process improvements that could prevent future issues.
## Example
### Scenario
Your medical device software receives a customer complaint about incorrect calculation results in specific clinical scenarios. The software is classified as IEC 62304 Class C (safety-critical). Here's how you would handle this problem:
**Problem Report Creation**: Customer reports that device displays incorrect values when processing certain patient data ranges. Problem is logged in your ticketing system with high criticality due to potential safety impact.
**Investigation**: Software team reproduces the issue and identifies a calculation error in the algorithm when processing edge-case values. Root cause analysis reveals the development team didn't test extreme value ranges during verification.
**Safety Assessment**: Risk management team evaluates that incorrect calculations could lead to inappropriate clinical decisions, potentially resulting in patient harm. This triggers immediate safety controls and formal change request.
**Resolution Planning**: Develop software patch to fix calculation algorithm, expand test coverage for edge cases, and implement additional verification requirements for calculation-critical code.
**Implementation**: Deploy software update following full design control process including verification testing, validation with clinical scenarios, and user notification of the update.
### Example Problem Ticket Documentation
**Problem ID**: SW-2024-015\
**Date Reported**: March 10, 2024\
**Source**: Customer complaint via support channel\
**Affected Software**: Version 2.3.1, Calculation Module\
**Safety Classification**: Class C - Safety Critical
**Problem Description**: Device displays incorrect calculation results when patient weight >120kg and BMI calculation is performed.
**Root Cause**: Algorithm overflow error in BMI calculation function when processing high weight values. Insufficient input validation and edge case testing during development.
**Safety Impact**: HIGH - Incorrect BMI calculations could lead to inappropriate dosing recommendations.
**Resolution**:
* **Immediate**: User notification about weight limit and manual calculation requirement
* **Permanent**: Software patch v2.3.2 with corrected algorithm and expanded input validation
* **Preventive**: Enhanced verification testing requirements for all calculation functions
**Verification**: Patch tested with full range of weight values (0-200kg), regression testing completed, clinical validation with test scenarios passed.
**Closure Date**: March 25, 2024\
**Closed By**: Software Team Lead
## Q\&A
Any software behavior that deviates from intended functionality, creates safety concerns, or impacts device performance requires formal problem resolution. This includes bugs, security vulnerabilities, performance issues, and user interface problems. However, **normal development issues** discovered and resolved during routine testing don't require formal problem resolution unless they persist to final review stages.
**Development problems** follow your normal development process and only require formal problem resolution if they persist to final review stages. **Post-market problems** always require formal problem resolution through this SOP, integrated with your complaint handling and post-market surveillance processes. Post-market problems may also trigger regulatory reporting requirements.
**Class A** software requires basic analysis to identify and fix the immediate problem. **Class B and C** software require comprehensive root cause analysis including technical causes, process failures, and systemic analysis. Class C problems affecting safety require the most rigorous analysis including failure mode analysis and comprehensive impact assessment.
Software problems with **significant safety impact**, those affecting **multiple device models**, or requiring **substantial code changes** should trigger formal change requests. Minor problems with limited impact can often be resolved through normal maintenance processes, but always follow your change control procedures for any software modifications.
**Safety-related problems** and **recurring issues** should trigger formal CAPAs to address root causes and implement preventive measures. Not every software problem needs a CAPA, but problems indicating **systematic quality issues** or those with **patient safety implications** should follow your CAPA process for comprehensive corrective and preventive action.
Maintain complete **traceability** from problem identification through resolution verification. Document problem reports, root cause analysis, safety assessments, implemented changes, verification results, and closure decisions. Demonstrate integration with risk management, change control, and post-market surveillance processes. **Annual trend analysis** and process effectiveness reviews are also important audit evidence.
Security vulnerabilities require **immediate assessment** for patient safety impact and potential exploitation risk. Follow your cybersecurity incident response plan while conducting formal problem resolution. Security problems often require **coordinated disclosure**, user notifications, and potentially regulatory reporting. Treat high-risk security vulnerabilities as safety-critical problems requiring urgent resolution.
Verification must demonstrate that the problem is **actually resolved** and **no new problems are introduced**. For safety-critical software, conduct comprehensive regression testing. The verification scope should be proportional to the **change complexity** and **safety impact**. Document verification methods, acceptance criteria, and results as part of your problem resolution record.
# SOP Software Validation
Source: https://docs.withdovetail.com/tasks/sop-software-validation
Validate computer system processes ensuring software reliability and compliance throughout lifecycles.
## Summary
This Standard Operating Procedure (SOP) establishes systematic processes for **computer system validation (CSV)** of software systems used within medical device organizations. It defines risk-based approaches to validate software that supports quality management systems, production processes, or regulatory compliance activities, ensuring that computer systems perform reliably and maintain data integrity throughout their lifecycle.
## Why is SOP Software Validation important?
**Computer system validation** is essential because software systems increasingly support critical aspects of medical device quality management, from design controls and CAPA systems to production monitoring and regulatory submissions. When these systems fail or contain errors, they can compromise product quality, regulatory compliance, and patient safety.
This SOP is critical because it provides **systematic evaluation** of software reliability before it becomes integral to your quality management system. Unvalidated software might contain bugs that corrupt data, fail during critical operations, or lack adequate security controls. **21 CFR Part 11** and similar regulations require validation of computer systems that manage electronic records and signatures used in regulatory submissions.
**Risk-based validation** ensures that validation efforts are proportional to the potential impact of system failures, focusing resources on software that could significantly affect product quality or regulatory compliance while applying lighter validation to lower-risk systems.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Section **820.70(i)** requires validation of computer software for production and quality system use
* **21 CFR Part 11** mandates validation of systems managing electronic records and signatures
* Software validation must demonstrate **accuracy, reliability, consistent intended performance**
* Must implement **appropriate controls** for data integrity and system security
**Part 11 specific requirements**:
* **Audit trails** for electronic record creation, modification, and deletion
* **Electronic signature** security and non-repudiation measures
* **Access controls** and user authentication systems
* **Training documentation** for system users and administrators
**Special attention required for:**
* Systems managing FDA submission data or electronic records
* Software with electronic signature capabilities
* Audit trail implementation and data integrity controls
* Validation documentation retention and accessibility
Under **EU MDR 2017/745**:
* **Annex I Section 17** requires appropriate software lifecycle processes
* **ISO 13485 Sections 4.1.6, 7.5.6, and 7.6** specify computer system validation requirements
* Software validation must support **quality management system** effectiveness
* **Data integrity** requirements for systems supporting technical file documentation
**EU-specific considerations**:
* Computer systems must support **GSPR compliance** and conformity assessment
* **PRRC oversight** required for critical quality management software
* Systems must support **post-market surveillance** data collection and analysis
* **GDPR compliance** for systems processing personal data
**Special attention required for:**
* Software supporting CE marking technical file requirements
* Data protection and privacy controls for EU operations
* Integration with UDI and EUDAMED reporting systems
* Validation supporting notified body assessment requirements
## Guide
### Understanding Software Validation Scope and Qualification
**Scope determination** is critical for efficient validation. Not all software requires formal validation - focus on systems that could impact product quality, safety, or regulatory compliance. Apply validation to software that **automates regulatory requirements**, maintains critical quality data, or supports production processes where failures could affect device safety.
**Quality management software** requires validation if system failures could compromise quality management system effectiveness or regulatory compliance. Examples include CAPA tracking systems, document control software, training management platforms, and complaint handling databases.
**Production and service provision software** needs validation when process outputs cannot be verified through subsequent testing and deficiencies would only become apparent after product use. This includes manufacturing control systems, automated testing equipment, and deployment management tools.
**GAMP5 categorization** helps determine appropriate validation rigor. **Category 1** (infrastructure) and **Category 3** (unmodified COTS) require minimal validation. **Category 4** (configured COTS) needs moderate validation focusing on configuration aspects. **Category 5** (bespoke software) requires comprehensive validation including development documentation review.
### Implementing Risk-Based Validation Approaches
**Risk assessment** drives validation depth and rigor. Evaluate software impact on quality management system effectiveness, potential failure consequences, regulatory compliance requirements, and user safety implications. High-risk software requires comprehensive validation while low-risk systems may need only basic verification.
**Impact analysis** considers both direct effects (system provides incorrect results) and indirect effects (system unavailability disrupts critical processes). Consider data integrity risks, security vulnerabilities, and integration points with other critical systems.
**Validation level determination** should be proportional to identified risks:
* **Low risk**: Basic installation and functional testing
* **Medium risk**: Comprehensive functional testing and integration verification
* **High risk**: Full lifecycle validation including design review, comprehensive testing, and ongoing monitoring
### Establishing Systematic Validation Processes
**Define phase** establishes validation scope, requirements, and planning. Document intended use, identify processes being automated, analyze potential failure modes, and create validation plans proportional to identified risks.
**Implement phase** addresses system implementation including architecture review, configuration management, and development oversight for custom systems. Ensure appropriate change control and configuration documentation.
**Test phase** conducts systematic verification of system functionality, performance, and reliability. Include functional testing, integration testing, performance testing, security testing, and user acceptance testing as appropriate to risk level and system complexity.
**Deploy phase** manages controlled system implementation including installation qualification, user training, procedure updates, and operational readiness verification.
**Maintain phase** establishes ongoing system management including change control, periodic review, backup and recovery verification, and performance monitoring.
### Managing Documentation and Records
**Software Validation Form** provides standardized documentation for each validation project. Include system description, risk assessment, validation approach, test results, and approval decisions. Maintain this documentation as quality records throughout system lifecycle.
**Validation protocols** define specific test procedures, acceptance criteria, and verification methods. Ensure protocols are approved before execution and results are documented with appropriate approvals.
**Traceability documentation** connects user requirements through system specifications to test cases and validation results. This traceability supports regulatory inspections and change impact analysis.
### Implementing 21 CFR Part 11 Controls
**Electronic record controls** ensure data integrity through access controls, audit trails, record retention, and backup procedures. Implement appropriate authentication, authorization, and data validation measures.
**Electronic signature implementation** requires unique identification, non-repudiation, and secure linkage to electronic records. Ensure signatures cannot be transferred or reused by unauthorized individuals.
**Audit trail functionality** must capture user actions, timestamps, and data changes in a secure, tamper-evident manner. Audit trails should be retained and accessible for regulatory review.
**Training and competency** requirements ensure users understand system proper use, security requirements, and regulatory significance of electronic records and signatures.
### Managing Software Updates and Changes
**Change control integration** ensures that software updates undergo appropriate validation before implementation. Minor updates may require only impact assessment and regression testing, while major changes might need comprehensive revalidation.
**Version management** maintains clear records of software versions, validation status, and change history. Update the List of Validated Software when new versions are deployed.
**Regression analysis** evaluates whether software changes affect previously validated functionality. Focus revalidation efforts on changed functions and interfaces while leveraging existing validation for unchanged components.
### Planning Software Decommissioning
**Decommissioning assessment** evaluates the impact of software removal on quality management system effectiveness and regulatory compliance. Plan appropriate replacement systems and data migration before removing validated software.
**Data preservation** ensures that records maintained in decommissioned systems remain accessible for required retention periods. Plan appropriate data archival or migration strategies.
**Controlled removal** follows systematic procedures to ensure complete system deactivation while maintaining audit trails and regulatory compliance records.
## Example
### Scenario
You're implementing a new CAPA tracking system to replace manual spreadsheet-based processes. The software will manage nonconformance tracking, root cause analysis documentation, corrective action assignments, and effectiveness verification. Here's how computer system validation applies:
**Risk Assessment**: High-risk system because CAPA data is required for regulatory compliance, system failures could compromise corrective action effectiveness, and incorrect data could affect product quality decisions.
**GAMP5 Classification**: Category 4 (configurable COTS software) - commercial CAPA management system with organization-specific configuration for workflows, user roles, and reporting.
**Validation Approach**: Comprehensive validation including vendor assessment, configuration verification, functional testing, integration testing with other quality systems, user acceptance testing, and 21 CFR Part 11 compliance verification.
**Testing Strategy**: Test all CAPA workflow stages (initiation, investigation, action implementation, effectiveness verification), integration with complaint and nonconformance systems, reporting functionality, audit trail capabilities, and user access controls.
**Part 11 Controls**: Implement electronic signatures for CAPA approvals, audit trails for all data changes, user authentication and authorization, secure data backup and recovery procedures.
### Example Validation Documentation
**Software Validation Form - CAPA Management System**:
**Define Phase**:
* **Intended Use**: Automate CAPA process including initiation, investigation, action tracking, and effectiveness verification
* **Risk Assessment**: HIGH - Critical for regulatory compliance and quality management
* **Validation Approach**: Full validation with comprehensive testing and Part 11 compliance
**Implement Phase**:
* **Configuration Management**: Workflow configurations documented and version controlled
* **Integration Architecture**: Interfaces with complaint system, nonconformance system, and document control
* **Security Implementation**: Role-based access controls, audit trails, electronic signatures
**Test Phase**:
* **Functional Testing**: All CAPA workflow steps verified with test cases
* **Integration Testing**: Data exchange with connected systems validated
* **User Acceptance Testing**: End users verify system meets process requirements
* **Performance Testing**: Response times and data handling capacity verified
**Deploy Phase**:
* **Installation Qualification**: System deployed per specifications with proper configuration
* **User Training**: All users trained on system operation and Part 11 requirements
* **Go-Live Verification**: Initial production use monitored and verified successful
**Validation Results**: PASSED - System meets all requirements and is approved for production use
### Example Test Case
**Test Case ID**: TC-CAPA-001\
**Test Objective**: Verify CAPA initiation and approval workflow\
**Test Steps**:
1. User logs in with appropriate credentials
2. Create new CAPA record from nonconformance report
3. Complete investigation section with root cause analysis
4. Assign corrective actions with due dates and responsible parties
5. Route CAPA for management approval via electronic signature
6. Verify audit trail captures all user actions and approvals
**Expected Results**:
* CAPA record created with unique identifier
* All required fields completed and validated
* Electronic signature properly applied and linked to record
* Audit trail shows complete user action history
* CAPA status updated to "Approved" upon signature
**Test Result**: PASSED - All expected results achieved, audit trail complete
## Q\&A
**Software requiring validation** includes systems that automate regulatory requirements (CAPA, complaints, training records), manage critical quality data, support production processes, or handle electronic records and signatures. **Low-risk software** like general office applications typically don't require formal validation unless they manage quality-critical data.
Use **risk-based assessment** considering impact on quality management system, potential failure consequences, regulatory requirements, and user safety. **High-risk systems** need comprehensive validation including design review and extensive testing. **Low-risk systems** may need only basic functional verification and installation qualification.
Document **risk assessment**, validation approach, test protocols and results, user training, and system approval decisions. For **21 CFR Part 11 systems**, include additional documentation for electronic signature implementation, audit trail verification, and security controls. Maintain documentation as quality records throughout system lifecycle.
**Major updates** affecting functionality, interfaces, or security controls typically require formal revalidation. **Minor updates** (patches, cosmetic changes) may need only **change impact assessment** and regression testing. The key is evaluating whether changes affect previously validated functionality or introduce new risks.
**Cloud systems** require additional considerations for data security, vendor assessment, service level agreements, and data portability. Evaluate vendor validation documentation, assess cloud infrastructure controls, verify data backup and recovery capabilities, and ensure **regulatory compliance** in cloud environments.
**Part 11 compliance** requires validation demonstrating system reliability, audit trails for electronic record changes, electronic signature security and non-repudiation, access controls and user authentication, data backup and recovery, and **user training** on regulatory significance of electronic records and signatures.
**Integration validation** should test data exchange accuracy, interface reliability, error handling, and security controls. Validate each integration point separately, then test **end-to-end workflows** across integrated systems. Consider impact of one system's failure on connected systems and implement appropriate monitoring.
**Ongoing activities** include periodic system review, change control for updates, performance monitoring, backup verification, user training updates, and **audit trail review**. Establish monitoring procedures proportional to system risk and regulatory requirements. Document all maintenance activities as part of validation records.
# SOP Statistical Methods
Source: https://docs.withdovetail.com/tasks/sop-statistical-methods
Apply statistical analysis guidelines for medical device verification, validation, and regulatory compliance testing.
## Summary
The Standard Operating Procedure (SOP) for Statistical Methods establishes guidelines for selecting, applying, and documenting statistical techniques throughout medical device development, verification, and validation activities. This SOP ensures consistent and appropriate use of statistical analysis to demonstrate product safety, effectiveness, and regulatory compliance while maintaining scientific rigor in data interpretation.
## Why is SOP Statistical Methods important?
Statistical methods in medical device development exist because **regulatory agencies require objective, quantifiable evidence** that your device performs safely and effectively. Simply testing a few units and declaring success isn't sufficient - you must demonstrate statistically that your results are reliable and representative of your entire production. Statistical methods help you determine the right sample sizes to detect meaningful differences, calculate confidence levels that satisfy regulatory requirements, and interpret test data in ways that support your safety and performance claims. This SOP is essential for your certification because it ensures your testing approach is scientifically sound and will withstand regulatory scrutiny, preventing costly re-testing or submission rejections.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Section 820.250** requires statistical techniques where appropriate for verification and validation
* Sample size determination must be **statistically justified** for design controls
* **FDA Guidance on Statistical Considerations** mandates appropriate statistical methods for clinical trials
* Risk-based statistical approaches required for **Software as a Medical Device (SaMD)**
**Special attention required for:**
* Software validation requiring confidence/reliability calculations
* Human factors validation with sufficient statistical power
* Biocompatibility testing using appropriate sampling plans
* Performance testing demonstrating substantial equivalence to predicate devices
Under **EU MDR 2017/745**:
* **Annex I GSPR 1** requires statistically sound clinical evidence
* **Article 61** mandates statistical analysis for clinical evaluation
* **ISO 13485:2016** Section 8.2.4 requires statistical techniques for monitoring and measurement
* Statistical methods must support **benefit-risk analysis** for CE marking
**Special attention required for:**
* Clinical evidence requiring statistical significance testing
* Post-market surveillance data analysis with appropriate statistical methods
* Performance evaluation studies with pre-defined statistical endpoints
* Notified body assessment requiring statistical validation of claims
## Guide
### Determining When Statistical Methods Are Required
Identify situations where statistical analysis is necessary rather than optional. **Sample size calculations** are mandatory when you're making claims about device performance, safety, or reliability. Use statistical methods for **design verification testing** where you need to demonstrate that specifications are met consistently. Apply statistical analysis for **process validation** to prove manufacturing processes produce consistent results. Statistical methods are also required for **clinical evaluations** and **post-market surveillance** data analysis.
### Sample Size Determination Methodology
Select appropriate sample sizes based on the **severity of potential hazards** and required confidence levels. For **catastrophic risks** that could cause death, use 95% confidence with 95% reliability requiring larger sample sizes. For **negligible risks** with minimal patient impact, 90% confidence with 90% reliability may be acceptable. Consider the **type of data** you're collecting - attribute data (pass/fail) requires different sample sizes than variable data (measured values). Document your rationale for chosen confidence and reliability levels based on risk assessment outcomes.
### Attribute vs Variable Data Analysis
Understand when to use **attribute sampling** versus **variable data analysis**. Attribute data involves counting successes and failures, such as devices that pass or fail acceptance criteria. Use **zero acceptance sampling plans** when failures are unacceptable, calculating sample sizes that demonstrate compliance with acceptable risk levels. Variable data involves measuring continuous parameters like blood pressure accuracy or response times. Apply **tolerance interval analysis** to ensure specified percentages of your production meet performance requirements within defined confidence levels.
### Statistical Validation of Software Functions
For software medical devices, implement statistical validation approaches appropriate to your **software safety classification**. **Deterministic functions** that always produce identical outputs for identical inputs may require minimal statistical validation. **Non-deterministic functions** involving algorithms, machine learning, or user interfaces require robust statistical testing. Calculate sample sizes sufficient to detect clinically meaningful performance differences and establish **statistical significance** thresholds appropriate to your device's risk profile.
### Risk-Based Statistical Planning
Integrate statistical planning with your **risk management process**. Higher risk functions require more rigorous statistical validation with larger sample sizes and stricter acceptance criteria. Document how statistical parameters relate to **residual risk** acceptance. For each identified hazard, determine appropriate statistical confidence levels that ensure patient safety while remaining practically achievable. Link statistical validation plans to specific risk controls and verify their effectiveness through statistical analysis.
### Documentation and Regulatory Compliance
Maintain comprehensive documentation of all statistical analyses including methodology selection rationale, calculation details, and interpretation of results. Create **statistical analysis plans** before conducting studies, specifying hypotheses, endpoints, and acceptance criteria. Document any deviations from planned analyses and provide scientific justification. Ensure statistical reports include sufficient detail for regulatory reviewers to understand and verify your conclusions.
## Example
### Scenario:
You're developing a blood glucose monitoring app that must achieve ±15% accuracy compared to laboratory reference methods. Your risk assessment identifies incorrect glucose readings as a serious hazard requiring 95% confidence with 90% reliability. You plan attribute testing where readings within ±15% are considered "successes." Using zero acceptance sampling, you need 29 paired measurements with zero failures outside the ±15% range. For variable data analysis, you collect continuous accuracy measurements and calculate that 95% of readings fall within ±12.3% of reference values with 95% confidence. Your statistical validation plan includes power analysis showing your sample size can detect clinically meaningful differences, pre-specified statistical tests for accuracy assessment, and documented procedures for handling outliers or missing data.
### Example Statistical Analysis Plan:
**Statistical Methods Plan for Blood Glucose Monitoring App**
**1. Objectives and Hypotheses**
* Primary objective: Demonstrate ±15% accuracy compared to laboratory reference
* Null hypothesis: Device accuracy differs from reference by >15%
* Alternative hypothesis: Device accuracy is within ±15% of reference values
**2. Sample Size Determination**
* Risk level: Serious hazard (incorrect glucose readings)
* Required confidence: 95%, Required reliability: 90%
* Attribute sampling plan: 29 measurements with zero acceptance number
* Power analysis: 80% power to detect 10% accuracy difference
**3. Statistical Methods**
* Primary analysis: Proportion of readings within ±15% (attribute data)
* Secondary analysis: Mean absolute relative difference (variable data)
* Confidence intervals: 95% confidence intervals for accuracy metrics
* Tolerance intervals: 95% confidence that 90% of readings meet specification
**4. Data Collection Procedures**
* Paired measurements: App reading vs laboratory reference
* Measurement conditions: Fasting and postprandial glucose levels
* Reference method: Laboratory-grade glucose analyzer (±2% accuracy)
* Data recording: Automated data capture with manual verification
**5. Acceptance Criteria**
* Primary endpoint: ≥95% of readings within ±15% of reference (zero failures in 29 measurements)
* Secondary endpoint: Mean absolute relative difference \<10%
* Statistical significance: p\<0.05 for hypothesis testing
* Clinical significance: Differences must not affect treatment decisions
**6. Statistical Analysis Software and Validation**
* Statistical software: R version 4.3.0 with documented validation
* Analysis scripts: Version-controlled and independently reviewed
* Data integrity: Electronic source data with audit trails
* Quality control: 10% independent verification of calculations
## Q\&A
Start by identifying the severity level of risks associated with device failure using your risk assessment. For catastrophic risks (death or serious permanent injury), use 95% confidence with 95% reliability. For serious risks (reversible injury requiring intervention), use 95% confidence with 90% reliability. For marginal risks (temporary effects), 90% confidence with 90% reliability may be acceptable. Then determine if you're collecting attribute data (pass/fail) or variable data (measured values) and use appropriate statistical tables to calculate required sample sizes.
**Confidence** represents how certain you are that your sample results reflect the true population performance - 95% confidence means if you repeated the study 100 times, 95 would give similar results. **Reliability** represents the minimum acceptable performance level of your device - 90% reliability means at least 90% of devices must meet specifications. Higher reliability requirements (like 99%) demand much larger sample sizes to demonstrate compliance with acceptable confidence levels.
Use zero acceptance sampling when any failure could cause serious patient harm or when regulatory standards require 100% compliance (like sterility testing). This approach requires proving that failure rates are extremely low through testing samples with no observed failures. Allow limited failures (1-3 acceptance numbers) when some variability is acceptable and failure consequences are less severe, such as minor performance variations that don't affect clinical outcomes.
For deterministic software functions that always produce identical outputs for identical inputs (like mathematical calculations), smaller sample sizes may be justified. For non-deterministic functions involving user interfaces, algorithms, or AI/ML components, use larger sample sizes appropriate to the risk level. Document your statistical validation approach including power analysis, hypothesis testing, and clinical significance thresholds. Ensure your statistical methods can detect differences that would affect clinical decision-making.
Create a statistical analysis plan before conducting studies, specifying objectives, hypotheses, sample size calculations, and acceptance criteria. Document all statistical methods used, including software validation and version control. Maintain raw data with audit trails, analysis scripts, and detailed statistical reports. Include interpretation of results, clinical significance assessment, and any protocol deviations with scientific justification. Ensure documentation supports regulatory submission requirements and enables independent verification of your conclusions.
# SOP Regulatory Strategy
Source: https://docs.withdovetail.com/tasks/sop-update-of-regulations
Track regulatory changes and develop strategic approaches ensuring continuous compliance across jurisdictions.
## Summary
**SOP Regulatory Strategy** establishes comprehensive procedures for developing regulatory approaches across US and EU markets while systematically monitoring, evaluating, and implementing regulatory changes that impact your organization and medical devices. This Standard Operating Procedure (SOP) ensures proactive regulatory compliance through strategic planning, continuous regulatory intelligence, and structured change management processes.
## Why is SOP Regulatory Strategy important?
Regulatory strategy serves as your **navigational framework** through complex and evolving medical device regulations. **Without a systematic approach**, organizations risk selecting inappropriate regulatory pathways, missing critical requirement changes, or facing costly delays due to inadequate compliance planning. This SOP ensures you make informed regulatory decisions that optimize time-to-market while maintaining robust compliance.
**Proactive regulatory monitoring prevents compliance gaps** when regulations evolve. Medical device regulations frequently change through new guidance documents, standards updates, and regulatory amendments. **Systematic tracking and assessment processes** ensure your organization identifies relevant changes early, evaluates their impact accurately, and implements necessary modifications before they become compliance issues.
The SOP transforms regulatory compliance from reactive crisis management into **strategic competitive advantage**. Well-planned regulatory strategies enable parallel market entry, optimize resource allocation, and support business growth while maintaining the highest safety and quality standards.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and related FDA guidance:
* Organizations must **identify applicable regulatory requirements** and maintain current understanding
* **Quality System Regulation compliance** requires systematic procedures for regulatory monitoring (21 CFR 820.20)
* **Design controls** must consider applicable standards and regulatory requirements (21 CFR 820.30)
* **Management responsibility** includes ensuring regulatory requirement awareness throughout organization
**Special attention required for:**
* Software as Medical Device (SaMD) evolving guidance and regulatory frameworks
* Cybersecurity requirements per FDA's 2023 guidance updates
* Digital Health Center of Excellence emerging policies
* Medical Device User Fee Amendments (MDUFA) program changes
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Management responsibility** requires ensuring applicable regulatory requirements are identified and communicated (ISO 13485 5.6.2)
* **Design and development inputs** must include applicable regulatory requirements (ISO 13485 7.3.3)
* **Regulatory change monitoring** supports continued compliance with evolving MDR implementation
* **Post-market surveillance** must consider regulatory requirement changes affecting device safety
**Special attention required for:**
* MDCG guidance document evolution and implementation
* Notified Body designation changes and capacity constraints
* EUDAMED system implementation milestones and requirements
* Common Specifications (CS) publication and adoption timelines
* Software lifecycle guidance updates (MDCG 2019-11)
## Guide
### Developing Regulatory Strategy
**Establish comprehensive market assessment** for both US and EU jurisdictions. **Determine device classification** according to FDA risk-based classification rules (Class I, II, III) and EU MDR/IVDR classification rules (Class I/A through III/D). **Your classification determines regulatory pathway requirements**, timeline expectations, and resource allocation needs.
**Evaluate regulatory pathway options systematically**. For FDA submissions, assess whether your device qualifies for 510(k) clearance, requires PMA approval, or fits De Novo classification pathway. **Consider pre-submission meetings** to confirm regulatory approach and reduce submission risks. For EU market, determine whether self-certification applies or Notified Body involvement is required based on your device classification.
**Develop parallel regulatory strategies** when targeting multiple markets. **Leverage overlapping requirements** between FDA and EU regulations to optimize documentation development and testing protocols. **Plan submission timing strategically** to maximize regulatory efficiency while meeting business objectives.
**Create detailed regulatory timelines** incorporating submission preparation, regulatory review periods, and potential iteration cycles. **Build contingency planning** for regulatory questions, additional testing requirements, or pathway modifications based on regulatory feedback.
### Systematic Regulatory Monitoring
**Establish comprehensive information sources** for regulatory intelligence gathering. **Monitor primary regulatory authorities** including FDA guidance documents, CDRH communications, EU Commission publications, MDCG guidance documents, and Notified Body updates. **Subscribe to industry publications** from recognized sources like Johner Institute, RQM+, and professional associations.
**Implement structured monitoring schedules**. **Review regulatory sources monthly** for routine updates and **conduct comprehensive annual reviews** before product market entry or during management review cycles. **Assign specific team members** responsibility for monitoring particular regulatory areas aligned with their expertise.
**Document regulatory monitoring activities** systematically. **Maintain logs** of sources reviewed, dates of review, and findings discovered. **Create regulatory change summaries** highlighting potential organizational impacts and required follow-up actions.
### Impact Assessment Process
**Evaluate regulatory changes systematically** against your current quality management system, marketed products, products in development, and organizational processes. **Reference your List of Regulatory Requirements** to identify potential overlaps, conflicts, or enhancement opportunities from regulatory changes.
**Conduct structured gap assessments** when regulatory changes potentially impact your organization. **Document previous requirements, new requirements, planned actions, and implementation results** in standardized gap assessment forms. **Engage cross-functional teams** in gap assessment activities to ensure comprehensive impact evaluation.
**Prioritize regulatory changes** based on compliance criticality, implementation complexity, and business impact. **Classify changes** as immediate compliance requirements, planned improvement opportunities, or long-term strategic considerations.
### Implementation Management
**Develop structured implementation plans** for regulatory changes requiring organizational action. **Define specific tasks, responsible parties, completion timelines, and success criteria** for each implementation activity. **Integrate regulatory change implementation** with existing change management processes to ensure systematic execution.
**Coordinate implementation activities** across affected teams and processes. **For marketed devices**, implement changes through your established SOP Change Management procedures to maintain traceability and regulatory compliance. **For devices in development**, incorporate changes directly into ongoing development processes.
**Validate implementation effectiveness** through systematic review and verification activities. **Confirm regulatory compliance** through internal audits, management reviews, or external assessments as appropriate for the significance of implemented changes.
### Communication and Training
**Communicate regulatory changes** proactively to affected team members and stakeholders. **Provide context** explaining the business rationale, compliance requirements, and implementation expectations for regulatory changes. **Ensure management awareness** through formal reporting during management reviews or immediate escalation for critical regulatory issues.
**Deliver targeted training** when regulatory changes affect team responsibilities or procedures. **Document training completion** to demonstrate organizational competence and regulatory compliance. **Update relevant SOPs and procedures** to reflect regulatory change implementations.
## Example
**Scenario:** You develop a mobile health application for chronic disease management. The FDA publishes new guidance on Software as Medical Device (SaMD) clinical evaluation requirements, and the EU releases updated Common Specifications for digital health technologies. You need to assess and implement these regulatory changes.
### Regulatory Monitoring
Your quality team conducts monthly regulatory monitoring activities. During October review, team members identify the new FDA SaMD guidance and EU Common Specifications publication. The monitoring log documents source locations, publication dates, and preliminary impact assessments.
### Impact Assessment
You review both regulatory changes against your current development processes and marketed device requirements. The FDA guidance introduces new clinical evidence expectations for Class II SaMD devices that may affect your current 510(k) strategy. The EU Common Specifications establish new cybersecurity requirements that impact your technical documentation.
### Gap Assessment
Your cross-functional team completes gap assessment forms comparing current processes with new regulatory expectations. For FDA compliance, you identify needs for additional clinical data collection and modified substantial equivalence arguments. For EU compliance, you determine cybersecurity documentation enhancements and potential technical file updates are required.
### Implementation Planning
You develop implementation plans addressing both regulatory changes. The FDA guidance implementation involves updating your clinical evaluation strategy, engaging additional clinical experts, and modifying your 510(k) submission timeline. The EU Common Specifications implementation requires updating cybersecurity documentation, enhancing risk management processes, and coordinating with your Notified Body regarding technical file modifications.
### Communication and Training
You communicate regulatory changes to affected teams through formal meetings and documentation updates. Clinical team receives training on new FDA clinical evidence expectations. Software development team receives training on enhanced cybersecurity requirements. Management receives summary reports during quarterly management review.
## Q\&A
Start with device classification in your target markets using FDA and EU MDR/IVDR classification rules. Review applicable standards referenced in regulatory guidance for your device type. Consult your List of Regulatory Requirements and consider engaging regulatory consultants for complex classifications or novel device types.
Immediately conduct a gap assessment comparing current device compliance with new regulatory requirements. Document your analysis and determine if changes require implementation through your SOP Change Management process. Consider engaging your Notified Body or FDA contacts for guidance on compliance expectations and implementation timelines.
Conduct routine regulatory monitoring monthly and comprehensive annual reviews before product market entry. Perform additional reviews before major product releases, regulatory submissions, or when significant industry events occur. Adjust monitoring frequency based on your device complexity and market dynamics.
Develop coordinated strategies that leverage overlapping requirements while addressing jurisdiction-specific differences. Consider timing strategies that allow one jurisdiction's approval to support another's submission. Plan for different regulatory pathway requirements while optimizing shared documentation and testing protocols.
Primary sources include official regulatory authority publications (FDA guidance documents, EU Commission communications, MDCG guidance). Secondary sources include reputable industry publications, professional associations, and regulatory consulting organizations. Avoid relying solely on informal sources or social media for regulatory intelligence.
Document specific requirement differences and develop jurisdiction-specific compliance approaches. Consider more stringent requirements as baseline compliance when possible. Engage regulatory experts familiar with both jurisdictions to develop harmonized approaches. Plan for jurisdiction-specific documentation and testing when harmonization isn't feasible.
Document current regulatory requirements, new regulatory requirements, specific gaps identified, planned actions to address gaps, responsible parties, implementation timelines, and verification methods. Include impact assessment on quality management system, marketed devices, devices in development, and organizational processes.
Evaluate regulatory change effective dates, compliance deadlines, and enforcement priorities. Immediate action required for changes affecting marketed device safety, compliance violations, or regulatory submission requirements. Future planning appropriate for guidance documents, recommended practices, or changes with extended implementation periods.
# SOP Usability Engineering
Source: https://docs.withdovetail.com/tasks/sop-usability-engineering
Design systematic usability processes to prevent use errors and ensure patient safety through human factors engineering.
## Summary
This Standard Operating Procedure (SOP) establishes a systematic approach to **usability engineering** throughout the medical device lifecycle, ensuring compliance with **IEC 62366-1** standards. It defines processes for understanding user needs, conducting formative and summative usability evaluations, and integrating usability considerations into design and risk management to prevent use errors that could compromise patient safety.
## Why is SOP Usability Engineering important?
**Use errors** are a significant cause of medical device incidents and patient harm. Regulatory authorities recognize that even well-designed devices can fail if users cannot operate them safely and effectively in real-world conditions. Poor usability can lead to medication errors, misdiagnosis, delayed treatment, or device abandonment when patients and healthcare providers struggle with complex interfaces.
This SOP is essential because it provides **systematic methods** for understanding user needs, identifying potential use errors, and validating that your device can be used safely by its intended users. **IEC 62366-1 compliance** demonstrates that you've conducted appropriate usability engineering activities proportional to the risk associated with potential use errors.
**Integration with risk management** ensures that usability considerations influence design decisions throughout development, rather than being addressed as an afterthought. This proactive approach significantly reduces the likelihood of use-related safety issues reaching the market.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* Design controls under **820.30** must consider human factors and usability
* **IEC 62366-1** is recognized as consensus standard for usability engineering
* FDA guidance requires **human factors validation** for most medical devices
* Usability testing must demonstrate **safe and effective use** by intended users
**FDA-specific requirements**:
* **Human Factors and Usability Engineering** guidance provides detailed expectations
* **Premarket submissions** must include human factors information for most devices
* **Use-related risk analysis** must identify and mitigate critical tasks
* **Summative usability testing** required for devices with significant use-related risks
**Special attention required for:**
* Critical tasks that could result in serious harm if performed incorrectly
* Use environments that could increase likelihood of use errors
* User interface design for complex medical devices
* Validation with representative users in realistic use conditions
Under **EU MDR 2017/745**:
* **Annex I Section 5** requires devices to be designed for safe use by intended users
* **IEC 62366-1** demonstrates compliance with usability requirements
* Usability engineering must support **clinical evaluation** and **benefit-risk analysis**
* **User interface design** must minimize risk of use errors
**MDR integration requirements**:
* Usability data supports **General Safety and Performance Requirements (GSPR)**
* **Post-market surveillance** must monitor use-related issues
* **Clinical evaluation** must consider real-world use effectiveness
* **Person Responsible for Regulatory Compliance (PRRC)** oversight of usability activities
**Special attention required for:**
* Use error potential impacts clinical evaluation requirements
* Usability validation supports CE marking conformity assessment
* Post-market usability monitoring informs ongoing benefit-risk assessment
* Technical file must document comprehensive usability engineering activities
## Guide
### Understanding User-Centered Design Principles
**User identification** forms the foundation of effective usability engineering. Define primary users (those who directly operate the device), secondary users (those who assist or supervise), and tertiary users (those affected by device use). Consider user characteristics including medical training, technical experience, physical capabilities, cognitive abilities, and environmental constraints.
**Use context analysis** examines where, when, and how your device will be used. Emergency situations require different interface approaches than routine clinical procedures. Consider lighting conditions, time pressures, multitasking demands, and potential distractions that could affect user performance.
**Task analysis** breaks down device use into specific steps and decision points. Identify **critical tasks** where use errors could result in serious harm, and focus usability engineering efforts on these high-risk interactions.
### Implementing Systematic Usability Planning
**Usability requirements** should be specific, measurable, and tied to safety outcomes. Rather than vague statements like "easy to use," define requirements such as "95% of users can complete initial setup within 10 minutes with no more than one error."
**Use scenario development** creates realistic contexts for usability evaluation. Scenarios should reflect actual clinical workflows, time pressures, and environmental conditions. Include both normal use and foreseeable misuse situations.
**Risk-based approach** prioritizes usability efforts based on potential harm. Focus most attention on critical tasks and use situations where errors could impact patient safety or treatment effectiveness.
### Conducting Effective Formative Usability Evaluation
**Iterative testing** throughout development identifies usability issues early when they're easier and less expensive to correct. Use low-fidelity prototypes for initial concept evaluation and high-fidelity prototypes for detailed interface testing.
**Representative user recruitment** ensures testing reflects your actual user population. Include users with varying experience levels, physical capabilities, and work environments. Avoid using only expert users or laboratory staff.
**Realistic use conditions** improve the validity of usability findings. Test in simulated clinical environments when possible, include realistic time pressures, and allow multitasking that reflects actual use conditions.
**Use error identification** focuses on safety-critical failures rather than minor usability preferences. Document instances where users perform incorrect actions, misinterpret information, or fail to complete critical tasks.
### Planning and Executing Summative Usability Validation
**Summative testing** validates that your final design can be used safely and effectively by intended users. This testing should use the final user interface design with representative users performing realistic tasks.
**Critical task validation** demonstrates that users can perform safety-critical functions correctly. Define acceptance criteria for each critical task, typically requiring high success rates (e.g., 95-100%) with minimal use errors.
**Use environment simulation** creates realistic testing conditions that reflect actual use environments. Include appropriate lighting, noise levels, time pressures, and workflow interruptions.
**Statistical considerations** ensure adequate sample sizes and appropriate analysis methods. For critical tasks, use confidence intervals and statistical tests appropriate for your acceptance criteria.
### Integrating Usability with Risk Management
**Use-related risk analysis** identifies potential hazards associated with use errors, use omissions, or misuse. Consider both direct effects (incorrect therapy delivered) and indirect effects (delayed treatment due to device abandonment).
**Risk control measures** can include design improvements, protective measures (alarms, confirmations), or user information (training, labeling). Design controls are generally more effective than relying solely on user training.
**Residual risk evaluation** determines whether remaining use-related risks are acceptable given the device's intended benefits. Some use errors may be unavoidable, but their probability and consequences must be acceptable.
### Managing Usability Documentation and Compliance
**Usability Engineering Information File (UEIF)** contains all usability-related documentation including user research, requirements, test plans, test results, and design rationale. Maintain this file throughout the device lifecycle.
**Traceability** connects user needs through usability requirements to design decisions and validation results. This traceability supports regulatory submissions and demonstrates systematic usability engineering.
**Post-market usability surveillance** monitors real-world use errors and usability issues. Integrate usability data collection with your complaint handling and post-market surveillance systems.
### Addressing Software-Specific Usability Considerations
**User interface consistency** across software modules reduces learning burden and error potential. Establish design standards for navigation, terminology, visual design, and interaction patterns.
**Error prevention and recovery** capabilities help users avoid mistakes and recover from errors gracefully. Include input validation, confirmation dialogs for critical actions, and clear error messages with recovery guidance.
**Accessibility considerations** ensure your software can be used by individuals with varying abilities. Consider visual, auditory, motor, and cognitive accessibility requirements relevant to your user population.
## Example
### Scenario
You're developing a mobile application for insulin dose calculation that will be used by diabetes patients for daily dose management. The app calculates insulin doses based on blood glucose readings, carbohydrate intake, and individual patient parameters. Here's how usability engineering applies:
**User Analysis**: Primary users are adults with Type 1 diabetes, ranging from newly diagnosed to experienced patients. Secondary users include caregivers and family members. Consider varying ages (18-80), technology experience levels, and potential visual or dexterity limitations.
**Critical Task Identification**: Calculate correct insulin dose based on inputs, recognize and respond to dose calculation alerts, enter accurate blood glucose and carbohydrate data, and respond appropriately to error conditions.
**Formative Testing**: Test early prototypes with diabetes patients using realistic scenarios like calculating pre-meal doses under time pressure. Identify interface elements that cause confusion, data entry errors, or misinterpretation of dose recommendations.
**Risk-Based Focus**: Prioritize testing scenarios where use errors could lead to hypoglycemia (too much insulin) or hyperglycemia (too little insulin). Test edge cases like very high or low glucose readings, unusual meal patterns, and system error conditions.
**Summative Validation**: Conduct final testing with 15-20 representative users performing realistic dose calculation tasks. Achieve 95% success rate for critical dose calculation tasks with no safety-critical use errors.
### Example Usability Requirements
**Dose Calculation Accuracy**:
* 98% of users can successfully calculate insulin dose for typical meal scenarios within 2 minutes
* Users correctly interpret dose recommendations in 99% of test scenarios
* Zero instances of users administering insulin doses that differ from calculated recommendations by >20%
**Error Recognition and Recovery**:
* 95% of users correctly respond to high/low glucose alerts within 30 seconds
* Users successfully recover from data entry errors in 90% of instances
* No user proceeds with insulin administration when app displays error conditions
**Data Entry Validation**:
* Users enter blood glucose values within ±5% of actual readings in 95% of attempts
* Carbohydrate estimation accuracy within ±10g for 90% of meal entries
* 100% of users successfully use alternative input methods when initial entry fails
### Example Test Protocol
**Participants**: 18 adults with Type 1 diabetes, mixed experience levels (6 newly diagnosed \<6 months, 6 intermediate 6-24 months, 6 experienced >2 years)
**Test Scenarios**:
1. **Routine pre-meal dose**: Calculate insulin for typical breakfast with normal glucose reading
2. **High glucose correction**: Calculate dose when glucose reading is above target range
3. **Low glucose management**: Respond appropriately when glucose reading indicates impending hypoglycemia
4. **System error recovery**: Handle app error during dose calculation process
5. **Complex meal calculation**: Calculate dose for meal with multiple carbohydrate sources
**Success Criteria**:
* Task completion rate >95% for critical tasks
* Zero safety-critical use errors (incorrect dose administration)
* User satisfaction rating >4.0/5.0 for ease of use
* All users demonstrate correct understanding of dose recommendations
## Q\&A
**Summative testing** is generally required when use errors could result in serious harm to patients or users. Devices with **critical tasks**, complex user interfaces, or novel interaction paradigms typically require summative validation. Lower-risk devices with simple interfaces and well-established interaction patterns may rely primarily on **formative testing** and design analysis.
**Sample size** depends on your testing objectives and risk level. **Formative testing** often uses 5-8 users per user group to identify major usability issues. **Summative testing** typically requires 15-20 users per user group to provide statistical confidence for critical task validation. Higher-risk devices or complex user populations may require larger samples.
**Critical tasks** are user interactions where errors could result in **serious harm** to patients or compromise treatment effectiveness. Examples include dose calculations, therapy delivery, alarm response, emergency procedures, or safety-critical configuration settings. Critical tasks require the highest level of usability validation and lowest acceptable error rates.
For **frequently updated software**, establish core **usability requirements** that remain consistent across versions. Conduct comprehensive testing for major interface changes and **regression testing** for minor updates. Use **automated usability metrics** where possible to monitor usability performance continuously. Focus detailed testing on new or modified critical tasks.
**Simulated environments** are acceptable if they realistically represent actual use conditions including physical environment, time pressures, distractions, and workflow context. The key is ensuring simulation **fidelity** matches real-world conditions that could affect usability. Document and justify any simplifications made in your test environment.
**Integration** should occur throughout development phases. Include usability requirements in software specifications, conduct formative testing during prototyping, validate usability during software verification, and monitor usability issues through post-market surveillance. Use **agile methodologies** that incorporate user feedback iteratively rather than only at project end.
Maintain a **Usability Engineering Information File (UEIF)** containing user research, usability requirements, test plans and protocols, test results, use-related risk analysis, and design rationale. For FDA submissions, provide human factors validation data. For EU submissions, demonstrate compliance with **IEC 62366-1** and support for General Safety and Performance Requirements.
**Significant usability issues** discovered during summative testing may require design changes and repeat testing. Minor issues can sometimes be addressed through **risk-benefit analysis** if design changes would introduce other risks. Document all issues, their impact assessment, and disposition decisions. Consider whether issues indicate need for **additional user training** or **labeling improvements**.
# SOP Vigilance
Source: https://docs.withdovetail.com/tasks/sop-vigilance
Report serious incidents and safety events to regulatory authorities through systematic vigilance and field corrective action procedures.
## Summary
Your **Vigilance** SOP establishes systematic processes for identifying, investigating, and reporting serious incidents and safety-related events to regulatory authorities while implementing field safety corrective actions to protect patients and users from device-related risks.
## Why is SOP Vigilance important?
Vigilance exists because regulators require **immediate notification** of serious safety events that could affect public health. It serves as a critical safety net that enables rapid response to device-related incidents, protecting patients from continued exposure to risks while allowing regulatory authorities to coordinate broader safety measures across the healthcare system.
Your vigilance system demonstrates **proactive safety management** rather than reactive incident handling. It ensures that serious events are properly classified, investigated, and reported within strict regulatory timelines. This protects patients through rapid corrective actions while protecting your organization from regulatory enforcement actions and liability exposure.
## Regulatory Context
Under **21 CFR Part 803** (Medical Device Reporting):
* **Mandatory reporting** of deaths, serious injuries, and malfunctions
* **24-hour reporting** for deaths, **10 days** for serious injuries
* Must report **device malfunctions** that could cause serious injury or death
* **Annual certification** of MDR compliance required
* Integration with **CAPA system** for corrective actions
**Special attention required for:**
* Strict reporting timelines with severe penalties for non-compliance
* FDA MedWatch system submission requirements
* Manufacturer and user facility reporting obligations
* Field corrective action notification requirements to FDA
Under **EU MDR 2017/745**:
* **Articles 87-92** mandate comprehensive vigilance system
* **Immediate reporting** for serious public health threats (2 days)
* **10-day reporting** for deaths, **15 days** for serious incidents
* **Field Safety Corrective Actions** require immediate notification
* **EUDAMED reporting** and competent authority coordination
**Special attention required for:**
* Multiple competent authority reporting requirements
* Field Safety Notice (FSN) content and language requirements
* PRRC oversight and notified body notification
* Trend reporting integration with post-market surveillance
## Guide
Your Vigilance SOP establishes **rapid response** systems for safety-critical events. Focus on creating efficient workflows that ensure regulatory compliance while enabling effective corrective actions to protect patients.
### Incident Classification and Assessment
Implement **systematic classification** procedures that distinguish between incidents, serious incidents, and serious public health threats. Create clear criteria and decision trees to ensure consistent classification across your organization. Include specific definitions for serious deterioration in health and causal relationship assessment.
Establish rapid assessment procedures that evaluate potential device-relatedness within hours rather than days. Include escalation criteria for events requiring immediate regulatory notification and procedures for handling uncertainty in classification decisions.
### Causal Relationship Investigation
Develop **structured investigation** methodologies that systematically evaluate the relationship between device use and reported events. Include evidence collection procedures, expert consultation processes, and documentation requirements that support regulatory submissions.
Create investigation timelines that balance thoroughness with regulatory reporting deadlines. Include procedures for submitting initial reports when investigations are incomplete and updating reports as additional information becomes available.
### Regulatory Reporting and Communication
Establish **systematic reporting** procedures for different regulatory jurisdictions with clear responsibility assignments and approval workflows. Create templates and checklists that ensure complete and accurate submissions within required timelines.
Implement tracking systems that monitor reporting deadlines and provide early warnings for approaching submission dates. Include procedures for coordinating with multiple competent authorities and notified bodies when required.
### Field Safety Corrective Actions
Develop **rapid response** procedures for implementing field safety corrective actions when serious incidents require immediate intervention. Include decision criteria for different types of corrective actions and procedures for communicating with customers and users.
Create Field Safety Notice templates and approval workflows that ensure consistent messaging while meeting regulatory content requirements. Include procedures for verifying customer receipt and implementation of corrective actions.
### Integration with Quality System
Connect vigilance activities to **all relevant quality processes** including CAPA, post-market surveillance, risk management, and change control. Establish clear triggers for initiating other quality processes based on vigilance findings.
Include vigilance data in management review reporting and trend analysis. Use vigilance insights to inform product improvements, risk management updates, and regulatory strategy decisions.
## Example
### Scenario
MedTech Solutions receives a report that their diabetes monitoring app provided incorrect glucose readings, leading to inappropriate insulin dosing and a patient hospitalization. They must quickly assess the incident, determine reportability, investigate the cause, and implement corrective actions while meeting strict regulatory reporting timelines.
### Vigilance Process Implementation
**Incident Receipt and Initial Assessment:**
* **Event:** Patient hospitalized due to hypoglycemia after app displayed incorrect high glucose reading
* **Source:** Healthcare provider report through customer support
* **Initial Classification:** Potential serious incident (hospitalization = serious deterioration in health)
* **Timeline:** Quality team notified within 2 hours of receipt
* **PRRC Notification:** Immediate notification to Person Responsible for Regulatory Compliance
**Causal Relationship Investigation:**
**Investigation Team:** Quality manager, software engineer, clinical specialist
**Evidence Collection:**
* Patient device logs and app version information
* Hospital medical records (with patient consent)
* Device performance data from same time period
* Similar complaint pattern analysis
**Findings:** Software bug in glucose calculation algorithm affecting specific phone models
**Causal Assessment:** Direct causal relationship established between device malfunction and patient harm
**Regulatory Reporting Decision:**
* **Classification:** Serious incident (hospitalization due to device malfunction)
* **Reporting Timeline:** 15 calendar days from awareness (EU MDR)
* **Competent Authority:** National authority where incident occurred
* **Report Content:** Incident details, investigation findings, corrective actions planned
**Field Safety Corrective Action Implementation:**
**FSCA Decision:** Immediate software update required to fix calculation bug
**Field Safety Notice Content:**
* UDI numbers for affected app versions
* Clear description of malfunction and patient risks
* Specific actions required by users (immediate app update)
* Contact information for questions and support
**Distribution:** All customers with affected app versions within 24 hours
**Verification:** Customer acknowledgment tracking and update confirmation
**Follow-up and Effectiveness Monitoring:**
* CAPA initiated for root cause analysis and systematic prevention
* Enhanced testing procedures implemented for future releases
* Customer feedback monitoring for similar issues
* Regulatory authority follow-up reporting as required
* Effectiveness verification through complaint monitoring and technical analysis
## Q\&A
A serious incident is any malfunction or deterioration that directly or indirectly led, might have led, or might lead to death, serious deterioration in health, or serious public health threat. Serious deterioration includes life-threatening illness, permanent impairment, hospitalization, or medical intervention to prevent serious harm. When in doubt, report the incident.
For EU MDR: serious public health threats (2 days), deaths/unanticipated serious deterioration (10 days), other serious incidents (15 days). For FDA: deaths (24 hours), serious injuries (10 days), malfunctions (30 days). Field Safety Corrective Actions must be communicated without undue delay in both jurisdictions.
Evaluate whether the incident involved device malfunction, deterioration in performance, inadequate manufacturer information, or undesirable side-effects. Consider temporal relationship, alternative explanations, and device-specific factors. Document your assessment rationale and when uncertain, err on the side of reporting.
Include relevant UDI numbers, manufacturer registration information, clear explanation of the malfunction and associated risks, specific actions required by users, and contact information. Content must be consistent across all markets and submitted to competent authorities for review except in urgent situations.
Initiate CAPA for all serious incidents to address root causes and prevent recurrence. Also consider CAPA for incident trends, systematic issues identified through vigilance, or when Field Safety Corrective Actions reveal broader quality system problems. Use your established CAPA qualification criteria.
Include vigilance data in post-market surveillance trending analysis and reporting. Use incident patterns to inform PMS plan updates and risk management decisions. Coordinate vigilance and PMS reporting to avoid duplication while ensuring comprehensive safety monitoring and regulatory compliance.
# SOUP List
Source: https://docs.withdovetail.com/tasks/soup-list
Document third-party software components with risk assessments ensuring safe integration and regulatory compliance.
## Summary
The Software of Unknown Provenance (SOUP) List documents all third-party software components, libraries, and off-the-shelf software used in your medical device. This document provides risk assessments, version control, and requirements for each SOUP item to ensure safe integration and regulatory compliance.
## Why is SOUP List important?
SOUP components represent potential **points of failure** in your medical device that are outside your direct control. Regulatory authorities require comprehensive documentation of all third-party software because these components can introduce **unknown risks** to patient safety. The SOUP list demonstrates that you have systematically identified, assessed, and controlled risks associated with external software dependencies.
Without proper SOUP documentation, you cannot demonstrate that your device is safe or that you understand all potential failure modes. The SOUP list also enables **ongoing monitoring** for security vulnerabilities and updates that might affect your device's safety and effectiveness throughout its lifecycle.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls) and **IEC 62304:2006**:
* All SOUP must be **identified and documented** with risk assessments
* **Functional and performance requirements** must be specified for medium/high-risk SOUP
* Must demonstrate **systematic evaluation** of SOUP risks
* **Version control** and change management required for all SOUP
**Special attention required for:**
* Cybersecurity vulnerabilities in SOUP components
* FDA Software as Medical Device guidance compliance
* Software Bill of Materials (SBOM) requirements
* Ongoing monitoring and update procedures for SOUP
Under **EU MDR 2017/745** and **IEC 62304:2006**:
* SOUP must be managed according to **IEC 62304** software lifecycle processes
* **Risk management** per ISO 14971 required for all SOUP components
* Must demonstrate **systematic approach** to SOUP identification and control
* **Cybersecurity requirements** per MDR Article 17 apply to SOUP
**Special attention required for:**
* SOUP classification impacts software safety classification
* Data protection requirements (GDPR) for SOUP handling personal data
* Post-market surveillance obligations for SOUP vulnerabilities
* Notified body assessment of SOUP risk management
## Guide
### Understanding SOUP
**Software of Unknown Provenance (SOUP)** is any software that your team did not create or that wasn't created specifically for your medical device but is nonetheless part of your medical device. SOUP includes:
* **Third-party libraries and frameworks** (React, NumPy, TensorFlow)
* **Off-the-shelf software** (operating systems, databases, authentication services)
* **Cloud services** that are integral to your device's medical functionality
* **Open source components** and commercial software packages
### SOUP vs Non-SOUP Determination
Not all third-party software is SOUP. Software is only considered SOUP if it is **used as part of your medical device** to achieve the intended medical purpose. For example:
**SOUP Examples:**
* Authentication service that controls access to patient data
* Machine learning library used for medical diagnosis
* Database storing critical patient information
* Communication protocol for medical device connectivity
**Non-SOUP Examples:**
* Marketing website hosting service
* Development tools not included in the final product
* Administrative software for billing or scheduling
* Non-medical notification systems
### SOUP Risk Classification
Classify each SOUP component based on potential patient impact:
**Low Risk**: SOUP malfunction is unlikely to lead to patient or user harm
* Example: UI styling libraries, non-critical logging components
**Medium Risk**: SOUP malfunction has potential to lead to reversible patient or user harm
* Example: Data validation libraries, communication protocols
**High Risk**: SOUP malfunction has potential to lead to irreversible patient or user harm
* Example: Medical calculation algorithms, critical data storage systems
### Documentation Requirements
For **all SOUP items**, document:
* **SOUP ID**: Unique identifier for tracking
* **Software Item**: Which part of your architecture uses this SOUP
* **Name and Version**: Exact version numbers (must be pinned, not auto-updating)
* **Manufacturer/Source**: Who developed or maintains the SOUP
* **Description**: What the SOUP does in your system
* **Risk Level**: Low, medium, or high based on patient impact
* **License**: Legal terms governing SOUP use
For **medium and high-risk SOUP**, additionally document:
* **Functional Requirements**: What the SOUP must do for your device to function
* **Performance Requirements**: Speed, accuracy, or capacity requirements
* **System Requirements**: Hardware and software needed to support the SOUP
### Version Control and Monitoring
**Pin all SOUP versions** to prevent automatic updates that could introduce unknown risks. Establish monitoring procedures:
* **High-risk SOUP**: Review every 6 months for vulnerabilities and updates
* **Medium-risk SOUP**: Review annually
* **Low-risk SOUP**: Review every 2 years
Monitor security advisories, vulnerability databases, and manufacturer notifications for all SOUP components.
## Example
**Scenario**: You're developing a diabetes management app that processes glucose readings, provides insulin dosing recommendations, and stores patient data. You need to identify and assess all SOUP components used in your system.
### SOUP List
| SOUP ID | Software Item | SOUP Name | Version | Manufacturer | Description | Risk Level | License | Requirements |
| -------- | ------------- | ---------------- | ------- | ----------------------------------- | ----------------------------------- | ---------- | ------------------ | --------------------------------------------------------------------------------------------------------------------- |
| SOUP-001 | Mobile App | React Native | 0.72.4 | Meta | Cross-platform mobile app framework | Low | MIT | UI rendering and navigation functionality |
| SOUP-002 | Backend | Express.js | 4.18.2 | OpenJS Foundation | Web application framework | Medium | MIT | HTTP request handling, API routing, requires Node.js runtime |
| SOUP-003 | Backend | bcrypt | 5.1.0 | Kelvin Sherlock | Password hashing library | High | Apache-2.0 | Secure password hashing for user authentication, must provide cryptographic security equivalent to 256-bit encryption |
| SOUP-004 | Database | PostgreSQL | 15.3 | PostgreSQL Global Development Group | Relational database system | High | PostgreSQL License | Patient data storage with ACID compliance, backup and recovery capabilities, encryption at rest |
| SOUP-005 | Backend | jsonwebtoken | 9.0.2 | Auth0 | JWT token implementation | High | MIT | Secure user session management, token expiration handling, cryptographic signature validation |
| SOUP-006 | Mobile App | React Navigation | 6.1.7 | React Navigation Contributors | Navigation library for React Native | Low | MIT | Screen navigation and routing functionality |
| SOUP-007 | Backend | Helmet.js | 7.0.0 | Adam Baldwin | Security middleware for Express | Medium | MIT | HTTP security headers, XSS protection, requires Express.js compatibility |
### Risk Assessment Summary
**High-Risk SOUP (3 items)**: These components handle critical security functions (authentication, data storage) and medical calculations. Failure could lead to data breaches or incorrect medical recommendations.
**Medium-Risk SOUP (2 items)**: These components handle data processing and security but have lower direct patient impact. Failure could disrupt service but is unlikely to cause direct patient harm.
**Low-Risk SOUP (2 items)**: These components handle user interface functions. Failure would affect usability but not patient safety or data security.
## Q\&A
A SOUP list requires a complete inventory of all third-party dependencies, documenting versions and licenses. Start with your package manager files (package.json, requirements.txt, etc.) to identify dependencies. Include off-the-shelf software and cloud services that are integral to your medical device functionality. Perform a risk assessment for each component based on potential patient impact if the SOUP fails.
Third-party software can be integrated as a medical device system module, listed as a supplier, and added to architecture documentation. Create specific subsystem requirements for third-party components and maintain your current device classification. Document all third-party software in your SOUP list with appropriate risk assessments.
SOUP (Software of Unknown Provenance) is any third-party software used in your medical device, while Off-The-Shelf (OTS) software refers to commercially available software packages. OTS becomes SOUP when it's used as part of your medical device to achieve the intended medical purpose. Not all OTS is SOUP - only the components that contribute to medical functionality.
All SOUP versions must be pinned to prevent automatic updates. When updates are needed, treat them as design changes requiring impact assessment, testing, and documentation updates. Evaluate security patches promptly but implement them through your change control process. High-risk SOUP updates require more extensive verification than low-risk updates.
Document all SOUP components with their **name, version, source, and functional purpose**. Include risk classification based on potential impact if the SOUP fails. For medium and high-risk SOUP, specify functional and performance requirements, system dependencies, and verification approaches. Maintain the SOUP list as a living document updated with each software release.
Establish ongoing monitoring procedures based on risk level. Subscribe to security advisories from SOUP manufacturers, monitor vulnerability databases (CVE, NVD), and use automated scanning tools where appropriate. High-risk SOUP requires quarterly review, medium-risk annual review, and low-risk biannual review. Document all vulnerability assessments and remediation actions.
# Subsystem Requirements List
Source: https://docs.withdovetail.com/tasks/subsystem-requirements-list
Break down system specifications into detailed implementable requirements for individual device components and subsystems.
## Summary
The Subsystem Requirements List breaks down system requirements into detailed, implementable specifications for each subsystem of your medical device. This document provides the technical granularity needed for design teams to build specific components while maintaining traceability to system-level requirements and user needs.
## Why is Subsystem Requirements List important?
Subsystem requirements translate **system-level specifications** into **actionable design inputs** for individual components or subsystems. They provide the detailed technical specifications that engineers need to design, develop, and verify each part of your device. This granular level ensures that every system requirement is fully addressed and that no functionality falls through the cracks during development.
Regulatory authorities require clear traceability from user needs through system requirements down to subsystem implementation. The subsystem requirements also serve as the foundation for your verification and validation activities, ensuring that each component meets its intended function before system integration.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls):
* Subsystem requirements must be **traceable** to system requirements
* Must be **complete, unambiguous, and verifiable**
* Design inputs must be documented and reviewed
* Risk control measures must be incorporated as requirements
**Special attention required for:**
* Software subsystems must follow FDA Software as Medical Device guidance
* Risk control requirements must be clearly specified and verifiable
* Interface requirements between subsystems must be well-defined
* Change control must govern all requirement modifications
Under **EU MDR 2017/745**:
* Must comply with **EN ISO 13485:2016** Section 7.3.3 (Design and development inputs)
* Requirements must address **safety, performance, and functionality**
* Risk management integration per **ISO 14971** is mandatory
* Traceability throughout design process required (Article 10(9))
**Special attention required for:**
* General Safety and Performance Requirements (GSPR) implementation
* Software lifecycle processes per IEC 62304 for software subsystems
* Risk control measures must be integrated into subsystem design
* Post-market surveillance considerations must influence requirements
## Guide
### Understanding Subsystem Requirements
Subsystem requirements define the **specific functions and characteristics** that each component of your device must have. They are more detailed than system requirements and provide the technical specifications needed for implementation. Think of them as **user stories for engineers** - they describe what each subsystem must do to contribute to the overall system function.
### Structuring Your Subsystem Requirements
Your subsystem requirements table should include:
**Subsystem**: The specific component or functional area (e.g., User Interface, Data Processing, Communication Module, Power Management)
**System ID**: Reference to the system requirement this subsystem requirement addresses, maintaining essential traceability
**Subsystem ID**: Unique identifier for each subsystem requirement (e.g., UI-001, DATA-001, COMM-001)
**Description**: Detailed specification of what the subsystem must do, including technical parameters, performance criteria, and constraints
### Writing Effective Subsystem Requirements
Subsystem requirements should be **specific and implementable**. Include technical specifications, performance parameters, and measurable criteria. Consider:
**Functional specifications**: What the subsystem does
**Performance parameters**: Speed, accuracy, capacity, throughput
**Interface definitions**: How it connects with other subsystems
**Environmental constraints**: Operating conditions and limitations
**Safety features**: Risk mitigation measures built into the subsystem
### Risk Control Requirements Integration
The second table addresses **risk control subsystem requirements** - these are specific features or functions that must be implemented to mitigate identified risks. These requirements should:
**Risk ID**: Reference the specific risk from your risk assessment
**Risk Control Requirement ID**: Unique identifier for the control measure
**Subsystem**: Which component will implement the risk control
**Description**: Detailed specification of the risk control feature
### Context Considerations
The configuration specifies that subsystem requirements should consider context from system requirements, shelf-life, and expected lifetime. This means accounting for:
* **System requirements**: Every subsystem requirement must trace to a system requirement
* **Shelf-life factors**: Storage conditions, material degradation, packaging requirements
* **Expected lifetime**: Durability, maintenance intervals, component replacement needs
### Technical Specifications
When writing subsystem requirements, include specific technical details:
**For software subsystems**: Processing speed, memory requirements, data formats, communication protocols
**For hardware subsystems**: Physical dimensions, material specifications, electrical characteristics, environmental tolerances
**For user interface subsystems**: Display specifications, input methods, accessibility features, response times
## Example
**Scenario**: You're developing a portable blood glucose monitor with multiple subsystems. Your system requirements specify that the device must complete analysis within 10 seconds and display results clearly. You need to break these down into specific subsystem requirements that your development teams can implement.
### Subsystem Requirements List
| Subsystem | System ID | Subsystem ID | Description |
| ------------------ | --------- | ------------ | ---------------------------------------------------------------------------------------------- |
| Measurement Engine | SYS-001 | MEAS-001 | The measurement subsystem shall complete glucose analysis within 8 seconds of sample detection |
| Measurement Engine | SYS-002 | MEAS-002 | The measurement subsystem shall provide glucose readings with coefficient of variation ≤5% |
| Sample Interface | SYS-003 | SAMP-001 | The sample interface shall detect blood sample volume ≥0.5 μL within 2 seconds |
| User Interface | SYS-004 | UI-001 | The display subsystem shall show glucose values in 14-point font minimum |
| User Interface | SYS-005 | UI-002 | The display subsystem shall use red backlight for readings >180 mg/dL |
| Data Management | SYS-006 | DATA-001 | The storage subsystem shall save readings with timestamp accurate to ±1 second |
| Power Management | SYS-007 | PWR-001 | The power subsystem shall provide 3.3V ±5% to measurement circuits |
### Risk Control Subsystem Requirements
| Risk ID | Risk Control Requirement ID | Subsystem | Description |
| -------- | --------------------------- | ------------------ | --------------------------------------------------------------------------------------- |
| RISK-003 | RC-001 | User Interface | The display subsystem shall show "ERROR" message when sample volume is insufficient |
| RISK-005 | RC-002 | Measurement Engine | The measurement subsystem shall perform automatic calibration check before each reading |
| RISK-007 | RC-003 | Data Management | The storage subsystem shall encrypt all patient data using AES-256 encryption |
| RISK-009 | RC-004 | Power Management | The power subsystem shall display low battery warning when charge drops below 20% |
## Q\&A
Subsystem requirements should provide enough technical detail for implementation teams to design and build the component. Include specific performance parameters, technical specifications, and measurable criteria. They should be more detailed than system requirements but not so prescriptive that they eliminate design flexibility unnecessarily.
Create a traceability matrix that maps each system requirement to one or more subsystem requirements. Review each system requirement and ask "Which subsystems need to do what to satisfy this requirement?" Ensure no system requirement is left without corresponding subsystem requirements.
Regular subsystem requirements derive from system requirements and define normal functionality. Risk control requirements derive from your risk assessment and specify features needed to mitigate identified risks. Both are essential, but risk control requirements specifically address safety concerns and must be clearly linked to identified risks.
Define interface requirements clearly in both subsystems that need to communicate. Specify data formats, communication protocols, timing requirements, and error handling. Consider creating dedicated interface control documents for complex interactions between subsystems.
Yes, but changes must be controlled through your change management process. Assess the impact of changes on other subsystems, system requirements, and verification activities. Update traceability documentation and consider whether changes affect your risk assessment or require additional risk controls.
For software subsystems, specify functional behavior, performance requirements, data handling, user interactions, and error conditions. Include technical specifications like processing speed, memory usage, and communication protocols. Ensure requirements are testable and consider both normal operation and edge cases.
# Supplier Checklist
Source: https://docs.withdovetail.com/tasks/supplier-checklist
Evaluate supplier capabilities through systematic assessment criteria ensuring quality system compliance and performance.
## Summary
**Supplier Qualification Checklist** provides systematic evaluation framework for assessing suppliers before adding them to the Approved Supplier List, ensuring comprehensive documentation of supplier capabilities, quality systems, and risk factors affecting medical device quality and regulatory compliance. This essential Quality Management System (QMS) record standardizes supplier assessment processes and supports informed procurement decisions.
## Why is Supplier Qualification Checklist important?
Supplier qualification represents the **foundation of supply chain quality assurance** that directly impacts medical device safety, performance, and regulatory compliance. **Without systematic supplier evaluation**, organizations risk selecting suppliers that lack appropriate quality systems, technical capabilities, or regulatory understanding necessary for medical device manufacturing.
**Regulatory requirements mandate** structured supplier control processes. FDA Quality System Regulation (21 CFR 820.50) and ISO 13485:2016 (Section 7.4.1) require organizations to evaluate suppliers based on their ability to provide products meeting specified requirements. **The qualification checklist provides evidence** of systematic supplier assessment and documented decision-making.
The structured approach transforms supplier selection from informal vendor relationships into **strategic quality partnerships**. **Well-executed supplier qualification** reduces supply chain risks, prevents quality issues, and ensures suppliers understand their role in maintaining medical device quality and regulatory compliance.
## Regulatory Context
Under **21 CFR Part 820.50** (Purchasing Controls):
* **Supplier evaluation and selection** based on ability to meet specified requirements including quality system adequacy
* **Purchasing data documentation** including specifications, acceptance criteria, and quality requirements
* **Supplier notification requirements** for changes affecting purchased product specifications
* **Incoming inspection** or verification activities to ensure compliance with purchasing requirements
**Special attention required for:**
* Critical component suppliers requiring enhanced qualification including quality agreements
* Design control supplier qualification when components affect device design specifications
* Contract manufacturer qualification including process validation oversight
* Software supplier assessment for systems affecting design controls or quality management
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Supplier evaluation criteria** must consider supplier ability to provide products meeting organization requirements (ISO 13485 7.4.1)
* **Supplier control documentation** including qualification records and performance monitoring
* **Risk-based supplier management** with oversight proportionate to supplier impact on product quality
* **Critical supplier oversight** including quality agreements and periodic re-evaluation
**Special attention required for:**
* Notified Body expectations for critical supplier qualification documentation
* Supply chain traceability requirements for higher-risk device classifications
* EU GDPR compliance when suppliers process personal data
* Authorized representative qualification for EU market access support
## Guide
### Supplier Information Documentation
**Collect comprehensive supplier identification** including company name, address, contact personnel details, and organizational structure relevant to purchased products/services. **Document contact information** for key personnel including technical contacts, quality representatives, and business relationship managers.
**Verify supplier credentials** including business registration, regulatory certifications, and industry memberships relevant to medical device supply chain. **Assess supplier stability** through financial information, business continuity planning, and market presence evaluation.
**Document supplier location** and geographic considerations affecting supply chain logistics, regulatory compliance, and business continuity. **Consider time zone differences**, language requirements, and cultural factors affecting business relationships.
### Product and Service Description
**Define purchased products/services clearly** including technical specifications, quality requirements, and regulatory considerations. **Specify intended use** of purchased items in medical device manufacturing, quality management, or regulatory activities.
**Document critical characteristics** that affect device performance, safety, or regulatory compliance. **Identify key quality attributes** requiring special attention during incoming inspection or verification activities.
**Establish acceptance criteria** for purchased products/services including performance specifications, quality standards, and delivery requirements. **Link requirements** to device specifications and regulatory obligations.
### Systematic Supplier Evaluation
**Evaluate suppliers systematically** using standardized criteria including quality of products/services, resource adequacy, cooperation/customer service, and payment terms. **Apply consistent scoring methodology** (0=Poor, 1=Fair, 2=Good, 3=Excellent) across all evaluation categories.
**Assess quality management systems** including ISO 13485 certification, FDA registration status, and other relevant quality certifications. **Evaluate technical capabilities** including manufacturing processes, testing equipment, and quality control procedures.
**Review supplier performance history** including delivery reliability, quality metrics, customer references, and complaint handling effectiveness. **Consider supplier innovation capabilities** and continuous improvement commitment.
### Risk-Based Qualification Decisions
**Calculate average evaluation scores** and apply consistent approval criteria based on overall performance assessment. **Suppliers scoring 2.0 or higher** can be approved without restrictions. **Suppliers scoring 1.0-2.0** require approval with enhanced monitoring. **Suppliers scoring below 1.0** should be blocked from use.
**Document qualification rationale** clearly, explaining approval decisions, required surveillance measures, or rejection reasons. **Consider supplier criticality** when determining appropriate oversight levels and monitoring requirements.
**Establish supplier-specific requirements** including quality agreements, certification maintenance, audit schedules, and change notification procedures based on qualification results and risk assessment.
### Additional Qualification Criteria
**Evaluate specialized requirements** including relevant certifications, quality assurance agreements, non-disclosure agreements, and audit accessibility. **Assess supplier willingness** to enter formal agreements supporting quality and regulatory compliance.
**Consider regulatory compliance factors** including supplier understanding of medical device requirements, regulatory change management capabilities, and willingness to support regulatory activities.
**Document any unique supplier characteristics** affecting evaluation including proprietary technologies, geographic advantages, or special capabilities relevant to your medical device requirements.
### Final Qualification Decision
**Document final approval decision** clearly, specifying approved status, required surveillance measures, or blocked status with rationale. **Establish monitoring requirements** proportionate to supplier criticality and evaluation results.
**Define ongoing surveillance activities** including audit schedules, performance monitoring frequencies, and review cycles. **Specify corrective action procedures** for addressing supplier performance issues or non-compliance.
**Plan supplier development activities** when appropriate to support continuous improvement and enhanced capabilities aligned with your quality requirements.
## Example
**Scenario:** You need to qualify a new supplier, TechComponents Inc., for providing critical sensors used in your diagnostic medical device. The sensors directly affect device accuracy and diagnostic performance.
### Supplier Information Collection
You document TechComponents Inc.'s complete information including headquarters in Germany, manufacturing facility in Ireland, quality contact Dr. Sarah Mueller, and technical contact Engineer James Walsh. You verify their ISO 13485:2016 certification and medical device manufacturing experience spanning 15 years.
### Product Description Documentation
You define the sensor specifications including measurement range, accuracy requirements, electrical characteristics, and regulatory standards compliance (IEC 60601-1). You document that sensors are critical components affecting diagnostic accuracy and requiring incoming inspection according to established acceptance criteria.
### Systematic Evaluation Process
You score TechComponents across four categories: Quality of Products/Services (3 - excellent ISO 13485 system and medical device experience), Resources (2 - good technical staff and manufacturing capability), Cooperation/Customer Service (3 - excellent responsiveness and medical device understanding), Payment Terms (2 - competitive pricing with standard terms). Average score: 2.5.
### Additional Criteria Assessment
TechComponents has relevant medical device certifications, agrees to quality assurance agreement, provides comprehensive product documentation, and offers audit access. They demonstrate understanding of medical device regulatory requirements and change control procedures.
### Final Qualification Decision
Based on 2.5 average score and positive additional criteria, you approve TechComponents for critical sensor supply. You establish annual performance reviews, quarterly quality metrics reporting, and quality assurance agreement requiring change notifications for any specification modifications.
## Q\&A
Complete qualification checklists for all suppliers providing materials, components, or services affecting medical device quality or regulatory compliance. Focus on critical suppliers providing components directly impacting device performance, safety, or regulatory requirements. Non-critical suppliers may require abbreviated evaluation depending on organizational procedures.
Use objective criteria for scoring: 3 (Excellent) = exceeds requirements with strong quality systems, 2 (Good) = meets requirements with adequate systems, 1 (Fair) = marginally meets requirements with improvement areas, 0 (Poor) = fails to meet basic requirements. Base scores on evidence including certifications, performance data, and supplier communications.
Implement enhanced surveillance measures including increased incoming inspection, more frequent performance reviews, formal quality agreements, and regular communication requirements. Document specific monitoring activities and establish performance improvement expectations. Consider supplier development activities to address identified weaknesses.
Conduct formal re-evaluation annually for critical suppliers or when significant changes occur in supplier capabilities, quality systems, or provided products/services. Document evaluation updates and maintain qualification currency. Address performance issues through immediate re-evaluation when necessary.
Maintain all supporting documentation including supplier certifications, quality system evidence, reference communications, audit reports, and performance data used in evaluation. Keep qualification checklists as permanent quality records linked to approved supplier list entries.
Document specific reasons for rejection clearly and communicate findings to requesting personnel. Seek alternative suppliers meeting qualification requirements. Consider re-evaluation after suppliers address identified deficiencies and demonstrate improvement. Maintain blocked supplier records for audit trail purposes.
Critical suppliers typically require quality assurance agreements, audit access provisions, change notification procedures, enhanced performance monitoring, and regular business reviews. Consider single-source risk mitigation through qualification of backup suppliers when possible.
Adapt evaluation criteria to focus on service reliability, data security, regulatory compliance understanding, business continuity planning, and technical support capabilities. Consider validation requirements when software supports quality management or production processes. Include service level agreements and data protection considerations in qualification decisions.
# System Requirements List
Source: https://docs.withdovetail.com/tasks/system-requirements-list
Translate user needs into objective testable requirements defining device functionality and performance criteria.
## Summary
The System Requirements List translates user needs into specific, testable technical requirements that define what your medical device must do to meet user expectations. This document serves as the foundation for all subsequent design and development activities, ensuring traceability from user needs through to final verification.
## Why is System Requirements List important?
System requirements bridge the gap between **user needs** and **technical implementation**. They transform high-level user expectations into objective, measurable criteria that your development team can design against. This document ensures that every aspect of your device's functionality is **deliberately planned** and **traceable** back to actual user needs, which is essential for regulatory compliance and successful product development.
The FDA and EU MDR require clear documentation showing how user needs translate into design requirements. Without well-defined system requirements, you cannot demonstrate that your device will actually meet user needs or prove that your verification activities are comprehensive.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls):
* System requirements must be **documented** and derived from user needs
* Requirements must be **objective and testable** to enable verification
* Must demonstrate **traceability** from user needs to system requirements
* Requirements must be **reviewed and approved** before implementation
**Special attention required for:**
* Software medical devices (FDA Guidance on Software as Medical Device)
* Design input requirements must be without ambiguity
* Requirements must enable objective verification of design outputs
* Change control procedures must govern requirement modifications
Under **EU MDR 2017/745**:
* Must comply with **EN ISO 13485:2016** Section 7.3.3 (Design and development inputs)
* Requirements must be **functional, performance, and safety-related**
* Must be **complete, unambiguous, and verifiable**
* Traceability required throughout the design process (Article 10(9))
**Special attention required for:**
* General Safety and Performance Requirements (GSPR) compliance
* Risk management integration per ISO 14971
* Software lifecycle processes per IEC 62304
* Clinical evaluation requirements must be considered in system design
## Guide
### Understanding System Requirements
System requirements define **what your device must do** rather than **how it will do it**. They should be more granular than user needs but not overly technical. Each requirement must be:
* **Objective**: Based on measurable criteria, not subjective opinions
* **Testable**: You must be able to verify whether the requirement is met
* **Traceable**: Clearly linked to one or more user needs
* **Unambiguous**: Written clearly with no room for interpretation
### Structuring Your Requirements
Your system requirements table should include:
**User Need ID**: Reference to the specific user need this requirement addresses. This creates the essential traceability link required by regulations.
**System ID**: Unique identifier for each system requirement (e.g., SYS-001, SYS-002). Use a consistent numbering scheme that allows for future additions.
**Description**: Clear, concise statement of what the system must do. Use active voice and specific language. Avoid vague terms like "user-friendly" or "reliable."
**Relevant Subsystem**: Identify which part of your device will implement this requirement. This helps organize your development work and ensures nothing falls through the cracks.
### Writing Effective Requirements
**Good system requirement examples:**
* "The device shall display measurement results within 5 seconds of completing analysis"
* "The system shall store a minimum of 1000 patient records"
* "The device shall operate continuously for 8 hours on battery power"
**Poor system requirement examples:**
* "The device should be fast" (not measurable)
* "The system must be user-friendly" (subjective)
* "The device will work well" (not testable)
### Requirements Categories
Consider organizing your requirements into categories:
**Functional Requirements**: What the device does (core functions, user interactions, data processing)
**Performance Requirements**: How well it performs (speed, accuracy, capacity, throughput)
**Interface Requirements**: How it connects with other systems (communication protocols, data formats)
**Environmental Requirements**: Operating conditions (temperature, humidity, electromagnetic compatibility)
**Safety Requirements**: Risk mitigation and safety features derived from your risk assessment
### Traceability and Context
The configuration specifies that system requirements should consider context from user needs, shelf-life, and expected lifetime. This means your requirements should account for:
* **User needs**: Every requirement must trace to at least one user need
* **Shelf-life considerations**: Requirements for storage, packaging, and degradation
* **Expected lifetime**: Durability, maintenance, and long-term performance requirements
## Example
**Scenario**: You're developing a portable blood glucose monitor. Your user needs include "Users must quickly obtain accurate blood glucose readings" and "Users must easily understand their results." You need to translate these into specific system requirements that your engineering team can design against.
### System Requirements List
| User Need ID | System ID | Description | Relevant Subsystem |
| ------------ | --------- | ------------------------------------------------------------------------------------------------------ | --------------------- |
| UN-001 | SYS-001 | The device shall complete blood glucose analysis within 10 seconds of sample application | Measurement Engine |
| UN-001 | SYS-002 | The device shall provide glucose readings accurate to ±15% of reference method | Measurement Engine |
| UN-001 | SYS-003 | The device shall require a blood sample volume of no more than 1.0 μL | Sample Interface |
| UN-002 | SYS-004 | The device shall display glucose values in units of mg/dL or mmol/L as selected by user | User Interface |
| UN-002 | SYS-005 | The device shall provide visual indication when glucose reading is outside normal range (70-180 mg/dL) | User Interface |
| UN-003 | SYS-006 | The device shall store minimum 500 glucose readings with date and time stamps | Data Management |
| UN-004 | SYS-007 | The device shall operate for minimum 1000 tests on single battery charge | Power Management |
| UN-005 | SYS-008 | The device shall function in temperature range of 5°C to 45°C | Environmental Control |
## Q\&A
System requirements should be more granular than user needs but not overly technical. They should be objective and testable, allowing for flexibility and traceability as the product evolves. Each requirement must clearly state what the system must do using measurable criteria.
**User needs** describe what users expect from the device from their perspective, while **system requirements** specify what the device must do to meet those needs. User needs are solution-neutral and focus on outcomes (e.g., "Users must quickly understand device status"). System requirements are more technical and specific (e.g., "Device must display status using LED indicators visible from 2 meters"). Each system requirement should trace back to one or more user needs.
System requirements should be detailed enough to be testable and unambiguous, but not so detailed that they constrain design solutions unnecessarily. They should specify **what** the system must do and **how well** it must perform, but generally avoid specifying **how** it will be implemented. Save implementation details for subsystem requirements and design specifications.
Ensure completeness by systematically reviewing each user need and asking "What must the system do to satisfy this need?" Consider all aspects: functional performance, safety, environmental conditions, interfaces, and lifecycle requirements. Use your risk assessment to identify additional safety-related requirements that may not be obvious from user needs alone.
Yes, system requirements can be updated, but changes must be controlled through your change management process. Document the rationale for changes and assess their impact on design, verification activities, and risk management. Update traceability matrices to maintain links between user needs, requirements, and verification activities.
Availability requirements should be kept general, such as "maintain high availability," without specifying exact uptime percentages. This allows for flexibility while ensuring the system remains reliable. Focus on user-relevant outcomes rather than specific technical metrics that may become outdated or unnecessarily constrain implementation approaches.
# Technical File
Source: https://docs.withdovetail.com/tasks/technical-file
Compile comprehensive documentation package demonstrating device compliance with requirements for CE marking.
## Summary
The **Technical File** is the comprehensive documentation package that demonstrates your medical device's compliance with EU MDR requirements. It contains all essential information about your device's design, manufacturing, safety, performance, and clinical evidence, serving as the foundation for your **Declaration of Conformity** and regulatory submissions.
## Why is Technical File important?
The Technical File serves as the **regulatory backbone** of your medical device certification in the EU. It provides regulatory authorities and notified bodies with complete evidence that your device meets all **General Safety and Performance Requirements (GSPR)** under MDR 2017/745. Without a properly structured Technical File, you cannot obtain CE marking or legally market your device in Europe. The document also serves as your **defense mechanism** during regulatory inspections and provides the foundation for **post-market surveillance** activities and **clinical evaluations**.
## Regulatory Context
Under **EU MDR 2017/745**:
* **Annex II** defines Technical File requirements for all device classes
* **Annex III** specifies additional requirements for higher-risk devices
* Must be available **before** placing device on market
* Required for **notified body assessment** for Class Is, Im, Ir, IIa, IIb, and III devices
**Special attention required for:**
* Software lifecycle documentation according to IEC 62304
* Clinical evaluation and post-market clinical follow-up (PMCF) documentation
* Risk management documentation according to ISO 14971
* Unique Device Identification (UDI) and EUDAMED registration requirements
## Guide
Your Technical File must follow the **structured format** defined in Annex II of MDR 2017/745. The document serves as a comprehensive repository that links together all your regulatory documentation and demonstrates systematic compliance with EU requirements.
### Section 1: Device Description and Specifications
**Device Identification**: Document your device's **trade name**, **software version**, and **Basic UDI-DI**. Include a detailed description of your device's **principles of operation** and how it achieves its intended purpose. For software devices, describe the **clinical algorithms**, **data processing methods**, and **user interface functionality**.
**Intended Purpose and Users**: Reference your **Intended Use document** and provide specific details about **indications for use**, **patient population**, **contraindications**, and **intended users**. Include any **clinical claims** that are substantiated through your clinical evaluation process.
**Classification and Codes**: State your device's **MDR classification** with detailed justification according to Annex VIII classification rules. Include your **EMDN code** selection and rationale for choosing the most appropriate nomenclature category.
### Section 2: Information Supplied by the Manufacturer
**Labeling Documentation**: Reference your **Device Label** and **Instructions for Use** documents. For software devices, specify how **electronic IFU (e-IFU)** is provided according to EU 207/2012 requirements. Include the **URL location** where users can access electronic instructions.
**Marketing Materials**: Include copies of all **promotional materials** and marketing content that will be used to promote your device. Ensure all claims made in marketing materials are substantiated by your clinical evidence.
### Section 3: Design and Manufacturing Information
**Design Stages**: Document your **software development lifecycle** according to your SOP for Integrated Software Development. Include evidence of **design reviews**, **verification and validation activities**, and **design transfer** processes.
**Software Architecture**: Reference your **Software Architecture document** and provide details about **software items**, **SOUP (Software of Unknown Provenance)** components, and **cybersecurity measures**. Include your **software bill of materials** and version control information.
**Risk Management**: Reference your **Risk Management Plan**, **Risk Assessment**, and **Risk Management Report**. Demonstrate how you've systematically identified, analyzed, and controlled risks throughout your device lifecycle.
### Section 4: General Safety and Performance Requirements
**GSPR Compliance**: Reference your **GSPR Checklist** that demonstrates compliance with all applicable requirements in Annex I of MDR 2017/745. Address each requirement systematically and provide evidence of compliance through design features, testing, or clinical data.
**Standards Compliance**: List all **harmonized standards** you've applied, such as **EN ISO 13485** for quality management, **ISO 14971** for risk management, and **IEC 62304** for medical device software. Demonstrate how compliance with these standards supports GSPR compliance.
### Section 5: Benefit-Risk Analysis and Risk Management
**Clinical Evidence**: Reference your **Clinical Evaluation Plan** and **Clinical Evaluation Report** that demonstrate your device's **clinical safety and performance**. Include your **benefit-risk analysis** that shows clinical benefits outweigh residual risks.
**Post-Market Surveillance**: Reference your **Post-Market Surveillance Plan** and describe how you'll monitor device performance and safety after market placement. Include your **PMCF activities** and how clinical evidence will be updated.
### Section 6: Product Verification and Validation
**Testing Documentation**: Reference all **verification and validation reports** including software testing, usability evaluation, and any applicable bench testing. Demonstrate that your device meets all specified requirements under normal and fault conditions.
**Traceability**: Include your **Traceability Matrix** that links user needs through system requirements to verification and validation activities. This demonstrates systematic coverage of all requirements.
## Example
### Scenario
You've developed a Class IIa software application for remote cardiac monitoring that analyzes ECG data and alerts healthcare providers to arrhythmias. You need to compile your Technical File for notified body submission and CE marking.
### Technical File Structure Example
**1. Device Description and Specifications**
**Device Trade Name:** CardioWatch Pro\
**Software Version:** v2.1.0\
**Basic UDI-DI:** 4012345678901
**Device Description:** CardioWatch Pro is a software medical device that continuously analyzes ECG data from compatible monitoring devices. The software uses proprietary algorithms to detect cardiac arrhythmias and provides real-time alerts to healthcare professionals through a secure web interface.
**Intended Purpose:** Software for continuous monitoring and analysis of cardiac rhythm patterns in hospital settings for healthcare professionals to aid in the detection of cardiac arrhythmias.
**Classification:** Class IIa according to Rule 11 of Annex VIII - software intended to provide information for decisions with diagnosis or therapeutic purposes.
**2. Information Supplied by the Manufacturer**
**Device Label:** Reference document DL-001-2024\
**Instructions for Use:** Reference document IFU-001-2024\
**Electronic IFU Location:** [https://www.cardiowatch.com/ifu](https://www.cardiowatch.com/ifu)\
**Marketing Content:** Reference document MC-001-2024
**3. Design and Manufacturing Information**
**Software Development Plan:** Reference document SDP-001-2024\
**Software Architecture:** Reference document SA-001-2024\
**Risk Management Plan:** Reference document RMP-001-2024\
**Design Review Records:** Five design reviews completed per SOP-ISD-001
**4. General Safety and Performance Requirements**
**GSPR Checklist:** Reference document GSPR-001-2024 demonstrating compliance with all applicable requirements in Annex I\
**Standards Applied:**
* EN ISO 13485:2016 - Quality management systems
* ISO 14971:2019 - Risk management
* IEC 62304:2006 - Medical device software
* IEC 62366-1:2015 - Usability engineering
**5. Benefit-Risk Analysis**
**Clinical Evaluation Report:** Reference document CER-001-2024\
**Benefit-Risk Analysis:** Clinical benefits of early arrhythmia detection outweigh software-related risks\
**Post-Market Surveillance Plan:** Reference document PMSP-001-2024
**6. Verification and Validation**
**Software System Test Report:** Reference document SSTR-001-2024\
**Usability Evaluation Report:** Reference document UER-001-2024\
**Traceability Matrix:** Reference document TM-001-2024
## Q\&A
Your Technical File must include all documents referenced in Annex II of MDR 2017/745. Key documents include: Intended Use, Device Classification, Risk Management documentation, Clinical Evaluation Report, GSPR Checklist, Instructions for Use, Device Label, Software Architecture (for software devices), and all verification and validation reports. The exact list depends on your device type and classification.
For software devices, your Technical File must include comprehensive software lifecycle documentation according to IEC 62304. This includes software development plan, software architecture, software requirements, verification and validation records, software bill of materials including SOUP components, and cybersecurity documentation. The level of detail should be proportional to your software safety classification.
You must update your Technical File whenever there are significant changes to your device that affect safety, performance, or intended use. This includes major software updates, changes in clinical evidence, new risk assessments, or modifications to manufacturing processes. Minor bug fixes typically don't require Technical File updates, but document the rationale in your change control records.
You must maintain your Technical File for at least 10 years after the last device covered by it has been placed on the market, or 15 years for implantable devices. The file must be readily available for regulatory authorities and notified bodies upon request, and you must keep it updated with post-market surveillance data and clinical evidence.
You can use the same Technical File for multiple software versions if the changes don't affect the device's safety, performance, or intended use. However, you must update relevant sections (like software version, UDI-PI, verification records) and maintain traceability of changes. Significant software updates that affect clinical functionality typically require a new or substantially updated Technical File.
# Traceability Matrix
Source: https://docs.withdovetail.com/tasks/traceability-matrix
Map user needs through requirements to testing ensuring complete coverage and regulatory compliance.
## Summary
The Traceability Matrix provides a comprehensive mapping that demonstrates how your user needs flow through system requirements, subsystem requirements, design outputs, and verification/validation activities, ensuring complete coverage and regulatory compliance.
## Why is Traceability Matrix important?
The Traceability Matrix is essential for demonstrating that your medical device development process is systematic, complete, and traceable from initial user needs to final verification and validation. It provides regulatory authorities with clear evidence that every user need has been addressed through appropriate requirements, design outputs, and testing activities. This document is crucial for proving that nothing has been overlooked in your development process and that your final device actually meets the needs you identified at the beginning. Without proper traceability, you cannot demonstrate that your device development was controlled and that all requirements have been adequately addressed.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **Design Controls**:
* **Design controls** require traceability from user needs through design outputs (820.30)
* **Design verification** must demonstrate that design outputs meet design inputs (820.30(f))
* **Design validation** must demonstrate that devices meet user needs (820.30(g))
* **Design history file** must contain traceability documentation (820.30(j))
**Special attention required for:**
* Class II and III devices requiring comprehensive design control documentation
* Software medical devices requiring traceability through software lifecycle processes
* Combination products requiring coordination between device and drug development traceability
* 510(k) submissions requiring predicate device comparison traceability
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* **Design and development planning** must ensure traceability (ISO 13485 Section 7.3.1)
* **Technical documentation** must demonstrate traceability (Annex II)
* **Risk management** traceability required per **ISO 14971** integration
* **Clinical evaluation** must trace clinical evidence to intended use (Article 61)
**Special attention required for:**
* Notified body assessment of traceability completeness for Class IIa and above
* Post-market surveillance data integration requiring traceability updates
* Clinical evaluation updates requiring traceability to new clinical evidence
* Unique Device Identification (UDI) traceability for device variants
## Guide
Your Traceability Matrix must demonstrate complete and systematic traceability from user needs through verification and validation activities. This document serves as the backbone of your design control process, ensuring nothing is missed and everything is properly tested.
### Requirements Traceability
Your **traceability-matrix** table must map each **User Need ID** to corresponding **System Requirements ID** and **Subsystem Requirements ID**. This demonstrates that every user need has been translated into specific, testable requirements. Each requirement should have clear **Design Output** documentation that shows how the requirement was implemented in your device design.
### Verification and Validation Mapping
For each requirement, document the corresponding **Verification** and **Validation** activities. Verification demonstrates that your design outputs meet your design inputs (requirements), while validation demonstrates that your device meets user needs and intended use. Reference specific test protocols, test reports, or other verification/validation documents that provide evidence of compliance.
### Risk Traceability Integration
Your **risk-traceability-matrix** table must demonstrate how identified risks flow through your risk management process. Map each **Risk ID** to its associated **Hazard**, **Hazardous Situation**, and potential **Harm**. Document the **Risk Acceptability** determination and any **Risk Control ID** implemented to mitigate unacceptable risks.
### Risk Control Implementation Traceability
For risks requiring controls, trace each **Risk Control ID** to specific **Risk Control Requirements ID** that were implemented in your design. Provide a clear **Description** of how the risk control was implemented and reference the **Verification** activities that demonstrate the risk control is effective.
### Completeness Verification
Ensure your traceability matrix has no gaps or blank entries. Every user need should trace through to verification and validation activities. Every unacceptable risk should trace through to implemented and verified risk controls. This completeness is essential for regulatory compliance and demonstrates the thoroughness of your development process.
## Example
**Scenario:** You develop a mobile app for diabetes management that tracks blood glucose levels and provides medication reminders. Your traceability matrix shows how user needs for accurate data tracking and timely reminders flow through system requirements, design implementation, and testing activities. Risk traceability demonstrates how you addressed data security and medication safety concerns.
### Traceability Matrix
**ID:** TM-001
**1. Purpose and Scope**
The purpose of this document is to provide a traceability matrix for DiabetesTracker Mobile App, developed in compliance with ISO 13485 requirements and ISO 14971 requirements. The traceability matrix provides evidence that regulatory, design, and development requirements are systematically traced to corresponding outputs, including risk management, testing, and verification/validation activities.
**2. Traceability Matrix**
| User Need ID | System Requirements ID | Subsystem Requirements ID | Design Output | Verification | Validation |
| ------------ | ---------------------- | ------------------------- | ------------------------------ | ------------------------------ | --------------------------------------- |
| UN-001 | SR-001, SR-002 | SSR-001, SSR-002, SSR-003 | User Interface Design Document | System Test Report Section 3.1 | Usability Evaluation Report Section 4.2 |
| UN-002 | SR-003, SR-004 | SSR-004, SSR-005 | Data Management Architecture | System Test Report Section 3.2 | Clinical Validation Study Report |
| UN-003 | SR-005 | SSR-006, SSR-007 | Notification System Design | System Test Report Section 3.3 | Usability Evaluation Report Section 4.3 |
| UN-004 | SR-006, SR-007 | SSR-008, SSR-009 | Security Architecture Document | Cybersecurity Test Report | Penetration Test Report |
**3. Risk Traceability Matrix**
| Risk ID | Hazard | Hazardous Situation | Harm | Risk Acceptability | Risk Control ID | Risk Control Requirements ID | Description | Verification |
| ------- | ----------------------------- | ------------------------------------------ | ------------------------------------ | ------------------ | --------------- | ---------------------------- | ------------------------------------------- | ------------------------------------- |
| R-001 | Incorrect glucose data entry | User enters wrong glucose value | Inappropriate medication dosing | Unacceptable | RC-001 | SSR-010 | Input validation with range checking | System Test Report Section 5.1 |
| R-002 | Data breach | Unauthorized access to health data | Privacy violation and identity theft | Unacceptable | RC-002 | SSR-011 | End-to-end encryption implementation | Cybersecurity Test Report Section 2.1 |
| R-003 | Missed medication reminder | Notification system failure | Delayed or missed medication | Unacceptable | RC-003 | SSR-012 | Redundant notification mechanisms | System Test Report Section 5.3 |
| R-004 | App crashes during data entry | Software anomaly during critical operation | Loss of glucose data | Acceptable | - | - | Acceptable risk with data recovery features | System Test Report Section 6.1 |
## Q\&A
Gaps in your traceability matrix indicate missing requirements, design outputs, or testing activities. You must address these gaps by either creating the missing elements or justifying why they are not needed. Complete traceability is essential for regulatory compliance.
Your traceability matrix should be detailed enough to demonstrate clear connections between user needs, requirements, design outputs, and testing activities. Each entry should reference specific document sections or test cases that provide evidence of compliance.
Yes, complex user needs often require multiple system and subsystem requirements to fully address them. Similarly, one requirement might contribute to satisfying multiple user needs. The key is ensuring complete coverage without gaps.
Some requirements may derive from regulatory standards, safety considerations, or technical constraints rather than direct user needs. These should still be included in your traceability matrix and clearly identified as regulatory or technical requirements.
Verification demonstrates that your design outputs meet your design inputs (requirements), while validation demonstrates that your device meets user needs and intended use. Both should be clearly documented in your traceability matrix with specific test references.
Update your traceability matrix whenever you add, modify, or remove user needs, requirements, design outputs, or testing activities. The matrix should always reflect the current state of your development and provide accurate traceability throughout the project lifecycle.
# Training Log
Source: https://docs.withdovetail.com/tasks/training-log
Track individual employee training completion and competency development through systematic documentation and records.
## Summary
**Training Log** provides systematic documentation of individual employee training activities, ensuring comprehensive records of competency development and regulatory compliance for each team member. This essential Quality Management System (QMS) record tracks training completion, demonstrates personnel qualifications, and supports regulatory audit requirements across all functional roles within your medical device organization.
## Why is Training Log important?
Training logs serve as **critical evidence** that your organization maintains competent personnel capable of performing assigned tasks that affect product quality and regulatory compliance. **Without documented training records**, you cannot demonstrate to auditors or regulatory authorities that employees possess required competencies or understand their quality responsibilities.
**Regulatory compliance mandates** systematic training documentation. FDA Quality System Regulation (21 CFR 820.25) and ISO 13485:2016 (Section 6.2) require organizations to establish procedures for identifying training needs and ensuring personnel competency. **Training logs provide objective evidence** that these requirements are systematically fulfilled for each employee.
The documentation transforms training from informal knowledge transfer into **systematic competency assurance**. Well-maintained training logs support performance evaluations, identify additional training needs, and provide traceability when investigating quality issues or non-conformities that may relate to personnel competency gaps.
## Regulatory Context
Under **21 CFR Part 820.25** (Personnel):
* Organizations must establish procedures for **identifying training needs** and ensuring personnel competency
* **Training must be documented** with records demonstrating completion and understanding
* Personnel performing verification and validation activities must be **aware of defects and errors** they may encounter
* **Management representative** requires documented authority and competency over quality system requirements
**Special attention required for:**
* Design control personnel training documentation (21 CFR 820.30)
* Software validation training requirements for software medical devices
* Corrective and Preventive Action (CAPA) training when process improvements are implemented
* Management review participation requiring quality system understanding
Under **EU MDR 2017/745** and **ISO 13485:2016**:
* **Competence requirements** must be determined for personnel affecting product quality (ISO 13485 6.2.1)
* **Training documentation** must demonstrate personnel understanding of their work relevance to quality objectives (ISO 13485 6.2.2)
* **Person Responsible for Regulatory Compliance (PRRC)** requires documented qualifications and training
* **Management review** must consider personnel competency and training effectiveness
**Special attention required for:**
* Clinical evaluation team qualifications and training documentation
* Post-market surveillance personnel competency requirements
* Risk management training for personnel involved in risk assessment activities
* Design and development training for technical teams
## Guide
### Individual Training Log Structure
**Create comprehensive individual training records** for each employee documenting their complete training history. **Include employee identification** with name, start date, functional group, and supervisor information to establish training accountability and management oversight.
**Document training systematically** using structured tables capturing training name, initial versus continuous training designation, training delivery method, due dates, completion dates, learning summaries, and participant initials. **Ensure traceability** between training requirements and individual completion records.
**Maintain current training status** by regularly updating records when new SOPs are released, existing procedures are revised, or additional competency development occurs. **Track training effectiveness** through learning summaries that demonstrate understanding rather than mere attendance.
### Training Content Organization
**Align training requirements** with individual functional roles and responsibilities. **Quality team members** typically require comprehensive training across all QMS procedures, while **software team members** focus on development-related SOPs and technical procedures. **Management personnel** need training emphasizing leadership responsibilities and regulatory oversight.
**Include all relevant SOPs** in training logs based on employee responsibilities. **Document both initial training** completed during onboarding and **continuous training** required for SOP updates, role changes, or competency improvements. **Specify training delivery methods** including online review, in-person sessions, mentoring, or external courses.
**Establish training timelines** with realistic due dates considering employee workload and training complexity. **Monitor completion status** systematically and follow up on overdue training to maintain current competency levels across your organization.
### Training Verification and Documentation
**Require documented confirmation** of training completion through employee initials, signatures, or electronic acknowledgment. **Capture learning summaries** where employees briefly describe key takeaways or how training applies to their work responsibilities. **This demonstrates understanding** rather than passive completion.
**Link training records** to specific document versions when training covers SOPs or procedures. **This maintains traceability** when procedures are updated and ensures employees were trained on current requirements. **Document training delivery methods** to support training effectiveness assessments.
**Establish training record retention** following your document control procedures and regulatory requirements. **Maintain training logs** for the device lifetime or as specified by applicable regulations, typically not less than two years from device market release.
### Ongoing Training Management
**Monitor training program effectiveness** through management review processes and quality metrics. **Assess whether training translates** into improved job performance, reduced errors, or enhanced regulatory compliance. **Identify training gaps** through performance evaluations, audit findings, or non-conformity investigations.
**Update training requirements** when new regulations emerge, SOPs are revised, or organizational roles change. **Communicate training updates** clearly to affected employees and establish completion deadlines that ensure competency before new requirements become effective.
**Integrate training management** with your human resources processes including performance evaluations, career development planning, and succession management. **Use training records** to support promotion decisions, role assignments, and competency-based task allocation.
### Training Record Integration
**Connect training logs** with your broader quality management system including management review, internal audits, and corrective action processes. **Reference training records** when investigating quality issues to determine if competency gaps contributed to non-conformities.
**Support external audits** by maintaining readily accessible training documentation that demonstrates systematic competency management. **Prepare training summaries** showing completion rates, overdue training, and training effectiveness metrics for management and auditor review.
**Coordinate training documentation** with supplier management when external personnel perform work affecting product quality. **Ensure contractor and consultant training** is documented and verified according to your training procedures.
## Example
**Scenario:** You hire a new software engineer, Sarah Chen, who joins your development team responsible for implementing cybersecurity features in your medical device software. You need to establish and maintain her training log to ensure regulatory compliance and competency development.
### Initial Training Log Setup
You create Sarah's individual training log documenting her name, start date of March 15, 2024, functional group as Software/Product Development, and supervisor as the Lead Software Engineer. Her initial training plan includes all SOPs relevant to software development roles.
### Required Training Documentation
Sarah's training log includes initial training on Quality Manual, SOP Design Control, SOP Software Development, SOP Risk Management, SOP Cybersecurity, SOP Document and Record Control, SOP Change Management, and SOP Computer System Validation. Each entry specifies "Initial Training" type and "Online review" delivery method with due dates within 30 days of start.
### Training Completion Process
Sarah completes SOP Cybersecurity training on March 22, 2024, documenting her learning summary: "Understood cybersecurity risk assessment procedures, secure coding practices, and vulnerability management requirements for medical device software. Will apply threat modeling techniques in current project development." She initials the completion record.
### Ongoing Training Management
When your organization updates the SOP Software Development in June 2024, Sarah receives continuous training on the revised procedure. Her training log documents completion on June 10, 2024, with learning summary focusing on new automated testing requirements and documentation templates introduced in the updated SOP.
### Training Record Maintenance
Sarah's supervisor regularly reviews her training log during quarterly performance discussions, identifying additional training needs based on project assignments and career development goals. The training log serves as evidence during internal audits and management reviews of training program effectiveness.
## Q\&A
Include all SOPs relevant to the employee's functional role, quality management system training, job-specific procedures, safety training, and any specialized competency development. For software team members, focus on development-related SOPs. For quality team members, include comprehensive QMS procedures. Document both initial onboarding training and continuous training for updates.
Align SOP training with job responsibilities and quality impact. Quality team members typically need training on all SOPs. Software team members require development, validation, and cybersecurity-related SOPs. Management needs SOPs related to oversight responsibilities. Consider which procedures the employee will implement or be affected by in their daily work.
Document training name/SOP version, completion date, training delivery method, learning summary demonstrating understanding, and employee confirmation through initials or signature. Learning summaries should show comprehension rather than mere attendance. Link training to specific document versions for traceability when procedures are updated.
Update training logs immediately when employees complete training activities. Review logs during employee performance evaluations, management reviews, and when new training requirements emerge. Establish regular monitoring for overdue training and ensure logs are current before internal audits or regulatory inspections.
Add continuous training entries to affected employees' training logs specifying the updated SOP version and establishing completion deadlines before the new procedure becomes effective. Document the training delivery method and require learning summaries focusing on changes introduced in the updated procedure.
Training logs provide objective evidence that personnel are competent to perform assigned tasks affecting product quality. They demonstrate systematic training management, competency verification, and compliance with regulatory requirements for personnel qualifications. Auditors review training logs to verify that employees understand their quality responsibilities.
Document specific training methods such as online review, in-person sessions, mentoring, external courses, webinars, self-study materials, or practical demonstrations. Different training methods may be appropriate for different learning objectives. Include trainer information when applicable and training duration for complex topics.
Apply the same training documentation requirements to temporary employees and contractors who perform work affecting product quality. Establish training requirements in contracts and ensure completion before beginning work. Maintain training records according to your document retention procedures and consider training transfer when contracts end.
# UDI Creation
Source: https://docs.withdovetail.com/tasks/udi-creation
Establish unique device identification enabling complete traceability and regulatory compliance.
## Summary
**Unique Device Identification (UDI)** is a mandatory tracking system that assigns a unique identifier to your medical device, consisting of a **UDI Device Identifier (UDI-DI)** and **UDI Production Identifier (UDI-PI)**. You must obtain these identifiers from approved issuing entities and register them in **EUDAMED** before placing your device on the EU market.
## Why is UDI Creation important?
UDI serves as the **digital fingerprint** of your medical device, enabling complete traceability throughout its lifecycle. Regulatory authorities use UDI for **post-market surveillance**, **adverse event reporting**, and **market oversight**. Healthcare providers rely on UDI for **inventory management**, **patient safety**, and **recall management**. Without proper UDI implementation, you cannot legally market your device in the EU, and you'll face significant challenges in **supply chain management** and **regulatory compliance**.
## Regulatory Context
Under **21 CFR Part 830** (UDI Rule):
* **UDI-DI** required from FDA-accredited issuing agencies (GS1, HIBCC, ICCBBA)
* **UDI-PI** must include production identifiers (lot/batch, serial number, expiration date)
* **GUDID database** submission required for device identification
* **Direct marking** required for reusable devices and device packages
**Special attention required for:**
* Software as Medical Device (SaMD) UDI requirements and version control
* Combination products with drug/biologic components
* Kit and system-level UDI assignments
* Direct marking exemptions for certain device types
Under **EU MDR 2017/745**:
* **Article 27** mandates UDI for all medical devices
* **UDI-DI** from EU-recognized issuing entities (GS1, HIBCC, ICCBBA, IFA)
* **EUDAMED registration** required before market placement
* **Basic UDI-DI** required for device families and Declaration of Conformity
**Special attention required for:**
* Single Registration Number (SRN) prerequisite for EUDAMED registration
* European Medical Device Nomenclature (EMDN) code selection
* Software versioning and UDI-PI format requirements
* Custom-made device UDI exemptions and special rules
## Guide
Creating your UDI involves **four essential components** that must be completed in sequence. Each component serves a specific regulatory purpose and requires interaction with different systems and organizations.
### Step 1: Obtain UDI-DI from Issuing Entity
**Choose an Issuing Entity**: Select from four EU-recognized organizations:
* **GS1** (recommended for most manufacturers) - Global standards organization
* **HIBCC** (Health Industry Business Communications Council) - Healthcare-focused
* **ICCBBA** (International Council for Commonality in Blood Banking Automation) - Blood banking focus
* **IFA** (Informationsstelle für Arzneispezialitäten) - German-based entity
**Registration Process**: Contact your chosen entity to purchase a **company prefix** and **UDI-DI allocation**. GS1 offers a "Smart Starter 10" package suitable for small manufacturers. The process typically takes **1-2 weeks** and costs vary by entity and package size.
**UDI-DI Structure**: Your UDI-DI will be a **numeric identifier** that remains constant for your device model. For software devices, the UDI-DI stays the same across software versions, while the UDI-PI changes with each version.
### Step 2: Create UDI-PI for Version Control
**Format Requirements**: Structure your UDI-PI using **Application Identifiers (AI)**:
* **(01)** followed by your UDI-DI
* **(11)** followed by production date in YYMMDD format
* **(10)** followed by software version identifier
**Version Management**: For software medical devices, update the UDI-PI with each **new software version**. Minor bug fixes may not require UDI-PI updates, but any changes affecting **safety or performance** must trigger a new UDI-PI.
**Example Format**: (01)04012345678901(11)240315(10)v2.1.0
### Step 3: Obtain Single Registration Number (SRN)
**EUDAMED Account Creation**: Register at the **EUDAMED portal** ([https://webgate.ec.europa.eu/eudamed/landing-page](https://webgate.ec.europa.eu/eudamed/landing-page)) as a medical device manufacturer. This requires providing detailed company information and regulatory contact details.
**Competent Authority Review**: Submit your manufacturer registration to your chosen **EU competent authority**. The review process typically takes **2-5 business days**, but can extend to **2 weeks** during peak periods.
**SRN Assignment**: Once approved, you'll receive your **unique SRN** that identifies your company in all EU regulatory databases. This number is required for all subsequent EUDAMED registrations.
### Step 4: Select EMDN Code
**Code Research**: Use the **EMDN browser** ([https://webgate.ec.europa.eu/dyna2/emdn/](https://webgate.ec.europa.eu/dyna2/emdn/)) to find the most specific code that accurately describes your device's **primary function**. Avoid selecting codes that are **too broad** or **inaccurate** to your device's actual functionality.
**Accuracy Priority**: Choose precision over convenience. If your software performs electromyography analysis, don't select a general "cardiac monitoring" code just because it's closer to your search terms. The EMDN code affects **regulatory classification** and **post-market surveillance**.
**Documentation**: Record your **code selection rationale** in your technical documentation, including alternative codes considered and reasons for your final selection.
### Integration and Registration
**Basic UDI-DI Creation**: Use the **GS1 Basic UDI-DI calculator** to generate your Basic UDI-DI from your company prefix. This identifier goes into your **Declaration of Conformity** and **technical documentation**.
**EUDAMED Device Registration**: Complete your device registration in EUDAMED using your SRN, UDI-DI, EMDN code, and device classification information. This registration must be **completed before** market placement.
## Example
### Scenario
You've developed a Class IIa software application for remote patient monitoring that analyzes vital signs and alerts healthcare providers to abnormal patterns. You need to create a complete UDI system before launching in Germany and France.
### Step-by-Step UDI Creation
**Step 1: UDI-DI Registration with GS1**
* Purchased GS1 Smart Starter 10 package for €150
* Received company prefix: 401234567
* Assigned UDI-DI: 04012345678901
* Registration completed in 5 business days
**Step 2: UDI-PI Creation**
* Software version: v1.2.3
* Release date: March 15, 2024
* UDI-PI format: (01)04012345678901(11)240315(10)v1.2.3
* Complete UDI: 04012345678901240315v1.2.3
**Step 3: SRN Acquisition**
* Registered company in EUDAMED as "VitalMonitor GmbH"
* Submitted to German competent authority (BfArM)
* Received SRN: DE-MF-000012345 after 3 business days
* Updated company registration with regulatory contact details
**Step 4: EMDN Code Selection**
* Searched for "patient monitoring software"
* Evaluated codes: Z12040201 (Patient monitoring software) vs Z12040301 (Vital signs monitoring)
* Selected Z12040301 as more specific to vital signs analysis
* Documented selection rationale in technical file
**Step 5: Basic UDI-DI and Registration**
* Used GS1 calculator with company prefix 401234567
* Generated Basic UDI-DI: 4012345678901
* Completed EUDAMED device registration
* Updated Declaration of Conformity with Basic UDI-DI
### Final UDI Implementation
**Device Label**:
```
VitalMonitor Pro v1.2.3
UDI: (01)04012345678901(11)240315(10)v1.2.3
```
**EUDAMED Registration Confirmation**: Device successfully registered with all required identifiers linked to SRN DE-MF-000012345.
## Q\&A
Costs vary by issuing entity and package size. GS1's Smart Starter 10 package costs approximately €150-300 and includes 10 UDI-DIs suitable for small manufacturers. GS1 is recommended for most manufacturers due to global recognition and comprehensive support resources. The registration process typically takes 1-2 weeks regardless of the entity chosen.
Use Application Identifiers: (01) for UDI-DI, (11) for release date in YYMMDD format, and (10) for software version. For example: (01)04012345678901(11)240315(10)v2.1.0. Update the UDI-PI with each software version that affects safety or performance, but minor bug fixes may not require updates.
The Basic UDI-DI acts like a barcode for your medical device family, enabling regulatory traceability. Create it using the GS1 Basic UDI-DI calculator with your company prefix. This identifier is required in your Declaration of Conformity and EUDAMED registration, and it links all versions of your device for regulatory tracking.
The complete process involves two steps: first, obtain your SRN (2-5 business days for competent authority review), then register your device (immediate once you have all required information). The total timeline is typically 1-2 weeks, but can extend during peak periods or if additional documentation is requested.
Selecting an incorrect EMDN code can affect your device classification and regulatory requirements. If you discover an error, you can update the code in EUDAMED, but this may require updating other regulatory documents. Choose the most specific code that accurately describes your device's primary function, and document your selection rationale for regulatory inspections.
The UDI-DI remains constant for your device model, but you must update the UDI-PI for each software version that affects safety, performance, or intended use. Minor bug fixes that don't impact device functionality may not require UDI-PI updates, but document your rationale in change control records.
# Usability Evaluation Plan
Source: https://docs.withdovetail.com/tasks/usability-evaluation-plan
Design systematic user testing strategy to identify interface risks and ensure safe device operation.
## Summary
The Usability Evaluation Plan outlines your strategy for evaluating the **human factors and usability** of your medical device. This plan defines both **formative** and **summative usability testing** approaches to ensure users can operate your device safely and effectively without committing **use errors** that could lead to harm.
## Why is Usability Evaluation Plan important?
User errors are among the leading causes of medical device incidents and recalls. Regulators require manufacturers to systematically evaluate how real users interact with devices to identify potential **use-related hazards** before market release. The usability evaluation plan demonstrates your **proactive approach** to user safety by establishing testing methodologies that validate your user interface design. This planning prevents costly post-market issues and ensures your device meets regulatory requirements for **human factors engineering** under both FDA and MDR standards.
## Regulatory Context
Under **FDA Human Factors Guidance** and **21 CFR Part 820.30** (Design Controls):
* **Human factors engineering** required for medical devices per FDA guidance documents
* Usability evaluation must be **risk-based** focusing on use-related hazards
* **Formative and summative testing** required to validate user interface safety
* Must identify **critical tasks** where user errors could cause significant harm
* Testing results must inform **design controls** and risk management processes
**Special attention required for:**
* High-risk devices requiring formal summative usability validation
* Software medical devices with complex user interfaces
* Integration with existing clinical workflows and environments
* Documentation of use-related hazard scenarios in risk assessment
Under **EU MDR 2017/745** and **IEC 62366-1:2015**:
* **Usability engineering** mandatory per Annex I GSPR requirements
* Must comply with **IEC 62366-1:2015** usability engineering standard
* **Use-related hazard scenarios** must be identified and tested
* Usability evaluation required for **technical documentation** (Annex II)
* **Usability engineering file** must demonstrate systematic approach
**Special attention required for:**
* IEC 62366-1 compliance for all device classes
* Integration with risk management per ISO 14971
* Clinical evaluation relationship with usability findings
* Post-market surveillance of use errors and difficulties
## Guide
Your usability evaluation plan establishes a systematic approach to validate that users can operate your device safely and effectively.
### Planning Framework
Begin by defining **use-related hazard scenarios** identified in your risk assessment that involve user interactions. These scenarios form the foundation for your testing strategy since they represent situations where user errors could lead to harm. Your plan should clearly distinguish between **formative evaluation** conducted during development and **summative evaluation** performed on the final device.
Document key definitions including **critical tasks** where user errors could cause significant harm, **hazard-related use scenarios** linking user actions to potential hazards, and **user errors** representing actions that differ from manufacturer intent. These definitions ensure consistent evaluation throughout your development process.
### Formative Usability Evaluation
Plan formative evaluations as ongoing development activities rather than formal validation events. These evaluations help improve your user interface before final design freeze. Include **expert reviews** with medical professionals familiar with your user population, **prototype testing** with representative users, and **design iteration** based on feedback.
Formative evaluation can be conducted informally but should focus on identifying usability problems early when changes are still feasible. Plan to document key insights and design improvements resulting from formative work, as these demonstrate your systematic approach to human factors engineering.
### Summative Usability Evaluation
Design summative evaluation as formal validation of your final user interface against **hazard-related use scenarios**. Plan to test all critical tasks with representative users under conditions that simulate intended use environments. Your summative evaluation must provide **objective evidence** that users can complete safety-critical tasks without committing use errors.
Plan for **adequate sample sizes** typically involving five or more representative users per user group, though complex devices may require larger samples. Ensure testing covers all **user populations** including primary users, secondary users, and any special populations identified in your intended use.
### Testing Environment and Materials
Plan testing environments that **simulate intended use conditions** including lighting, noise levels, time pressures, and workflow interruptions typical of real-world usage. Provide users with **actual labeling and instructions** that will accompany your device, including any required training materials.
Consider **training requirements** as part of your evaluation plan. If user training is a risk control measure, plan for appropriate training delivery and time intervals that account for **learning decay** between training and testing.
### Evaluation Criteria and Outcomes
Define clear **acceptance criteria** for successful task completion including time limits, accuracy requirements, and safety parameters. Plan to capture not only task failures but also **use difficulties** and **close calls** where users nearly commit errors but recover.
Your plan should specify how evaluation results will feed back into your **risk management process** including procedures for identifying new risks, evaluating risk control effectiveness, and updating design requirements based on findings.
## Example
### Scenario
You are developing a mobile ECG monitoring app that patients use at home to record heart rhythms and share data with their cardiologists. The app includes critical tasks like proper electrode placement guidance, rhythm recording, and emergency alert management. Your usability evaluation plan must ensure patients can safely operate the device without errors that could delay critical medical intervention.
### Example Usability Evaluation Plan
**ID:** UEP-001-ECG-Monitor
**Scope:** This Usability Evaluation Plan outlines planned usability evaluation activities for the Mobile ECG Monitor System including patient-facing mobile application and clinical dashboard components.
**Definitions:**
* **Critical Task:** A task where user error could delay emergency medical care or result in missed arrhythmia detection
* **Hazard-Related Use Scenario:** Patient interaction scenarios that could lead to diagnostic delays or inappropriate clinical responses
* **Formative Evaluation:** Development-phase testing to improve user interface design
* **Summative Evaluation:** Final validation testing on production-equivalent device
**Use-Related Hazard Scenarios:**
Hazard-related use scenarios identified in Risk Assessment include: patient failure to properly attach electrodes leading to poor signal quality (Risk ID: R-015), patient confusion about emergency symptoms resulting in delayed care-seeking (Risk ID: R-023), and clinician misinterpretation of patient-reported symptoms due to unclear data presentation (Risk ID: R-031).
**Formative Usability Evaluation:**
During development, we conducted design reviews with cardiologists and emergency medicine physicians to gather feedback on clinical workflow integration. Patient advisory groups reviewed prototype interfaces focusing on clarity of instructions and symptom reporting mechanisms. Iterative testing with five patients identified confusion about electrode placement, leading to enhanced visual guidance features.
Key improvements from formative evaluation included simplified electrode placement animations, clearer emergency symptom descriptions, and streamlined data sharing workflows based on clinician feedback.
**Summative Usability Evaluation:**
Summative evaluation will test the final device interface with 15 patients representing our intended user population: adults aged 45-80 with suspected cardiac arrhythmias and varying technology comfort levels. Testing will cover all hazard-related use scenarios through specific task scenarios.
**Testing Tasks:**
* Task T-001: Initial device setup and account creation (Risk ID: R-015)
* Task T-002: Proper electrode placement using app guidance (Risk ID: R-015)
* Task T-003: Recording ECG during symptom episode (Risk ID: R-023)
* Task T-004: Recognizing and responding to emergency alerts (Risk ID: R-023)
* Task T-005: Sharing symptom diary with clinician (Risk ID: R-031)
**Test Environment:**
Testing conducted in simulated home environment with typical distractions including television, family members, and time pressure scenarios. Patients receive standard instructions for use and 15-minute training session as specified in risk control measures.
**Acceptance Criteria:**
* 100% of patients must successfully complete critical tasks T-003 and T-004 without errors
* 95% of patients must achieve adequate signal quality (>80% clean signal) during 30-second recording
* No patient should require more than two attempts to complete emergency response tasks
* Use difficulties and close calls documented for risk assessment review
**Results Integration:**
Evaluation results will be documented in the Usability Evaluation Report and integrated into risk management files. Any identified use errors will trigger risk assessment updates and potential design modifications. New risks identified during testing will be assessed and controlled according to ISO 14971 processes.
## Q\&A
Usability testing should align with identified use-related risks from your risk assessment. Create specific test scenarios for each hazard-related use scenario, focusing on critical tasks where user errors could cause harm. Use representative users in simulated real-world environments and ensure testing covers the complete user journey including any safety-critical tasks related to device performance.
Usability testing can be conducted with participants representing your intended user population. For broad user profiles, healthy adults can participate, though specific medical conditions may require specialized populations. No mandatory training is required for participants unless training is part of your device's intended use. You can use simulated scenarios for testing emergency situations rather than requiring actual medical emergencies.
The usability testing process involves selecting representative users, having them perform key tasks while being observed, and documenting any issues encountered. The goal is ensuring your product is intuitive and safe to use. Testing should cover critical tasks linked to potential hazards, and you should collect feedback from both users and observers. Focus on task completion, user errors, difficulties, and near-miss situations.
The number of participants depends on your device complexity and user population diversity. Generally, five or more users per user group is recommended, though this can be adjusted based on your specific product and tasks. Consider conducting power analysis for complex devices or when statistical significance is required. Standards and guidance documents may provide specific recommendations for your device type.
Conduct formative usability evaluation throughout development to identify and fix issues early when changes are feasible. Perform summative usability evaluation on your final, production-equivalent device before market release. Avoid conducting formal summative testing on prototypes unless you can justify that differences from the final product don't affect user interaction or safety.
Usability testing results must feed into your risk management process according to ISO 14971. Any new use errors or difficulties identified during testing should be assessed as potential risks. Existing risk controls should be evaluated for effectiveness based on testing outcomes. Update your risk assessment with new risks and modify design or risk controls as needed based on usability findings.
# Usability Evaluation Protocol
Source: https://docs.withdovetail.com/tasks/usability-evaluation-protocol
Execute detailed user testing procedures validating safe interface operation and error prevention.
## Summary
The Usability Evaluation Protocol provides **specific testing procedures** for conducting summative usability evaluation of your medical device. This document translates your usability evaluation plan into **detailed test scenarios**, participant requirements, and data collection methods to systematically validate that users can safely operate your device without **use errors** that could cause harm.
## Why is Usability Evaluation Protocol important?
The protocol serves as your **systematic testing blueprint** that transforms use-related hazard scenarios into measurable test tasks. Regulators require detailed protocols to ensure usability testing is conducted consistently and comprehensively. This document demonstrates your **methodical approach** to human factors validation by specifying exactly how you will test critical user interactions. Without a detailed protocol, your usability testing may miss critical scenarios or lack the rigor needed to satisfy regulatory requirements for **summative usability evaluation**.
## Regulatory Context
Under **FDA Human Factors Guidance** and **21 CFR Part 820.30**:
* Protocol must detail **specific test scenarios** covering all hazard-related use scenarios
* Must specify **participant selection criteria** representing intended user population
* **Critical tasks** must be clearly identified and tested with appropriate rigor
* Data collection methods must capture **use errors, difficulties, and task completion**
* Protocol must support **validation** requirements for design controls
**Special attention required for:**
* High-risk devices requiring formal validation protocols
* Software devices with complex user interactions
* Testing environments that simulate actual use conditions
* Integration with risk management and design control processes
Under **EU MDR 2017/745** and **IEC 62366-1:2015**:
* Protocol must comply with **IEC 62366-1:2015** testing requirements
* Must cover all **hazard-related use scenarios** identified in risk assessment
* **Summative evaluation** protocol required for usability engineering file
* Testing must provide evidence for **Annex I GSPR** compliance
* Results must support **technical documentation** requirements
**Special attention required for:**
* IEC 62366-1 Section 4.3 tailoring requirements
* Integration with clinical evaluation when applicable
* Post-market surveillance planning for use errors
* Notified body review of usability evidence
## Guide
Your usability evaluation protocol converts your high-level usability plan into specific, executable testing procedures that generate regulatory-compliant evidence.
### Protocol Foundation
Begin by documenting your **user interface description** including platform details, interaction methods, authentication requirements, and workflow integration. Specify **training requirements** for participants including any materials that must be reviewed or skills that must be demonstrated before testing begins.
Document **materials provided to users** during testing including instructions for use, training materials, and any supporting documentation that accompanies your device in real-world use. These materials must match what users will receive with the commercial product.
### Hazard-Related Use Scenarios and Tasks
Translate each **hazard-related use scenario** from your risk assessment into specific, testable tasks. Each task should represent a realistic user interaction that could lead to the identified hazardous situation. Clearly identify which tasks are **critical tasks** where user errors could cause significant harm.
Structure tasks to flow logically through typical user workflows while ensuring all hazard-related scenarios are covered. Include both **normal use tasks** and **reasonably foreseeable misuse** scenarios that could occur in real-world environments.
### Participant Selection and Testing Environment
Define **participant criteria** that represent your intended user population including demographic characteristics, medical conditions, technology experience, and any special requirements. Specify minimum sample sizes based on device complexity and regulatory requirements, typically five or more users per user group.
Design **testing environments** that simulate actual use conditions including physical settings, lighting, noise levels, time pressures, and potential distractions. Consider whether testing should occur in clinical settings, home environments, or specialized facilities based on your intended use.
### Data Collection Framework
Establish systematic **data collection methods** that capture task completion status, use errors, use difficulties, and close calls. Design observation forms that allow testers to document not only what users do but also how they think through tasks and where confusion occurs.
Plan **user feedback collection** through structured interviews or questionnaires that gather insights about interface clarity, task difficulty, and improvement suggestions. Design questions that probe both objective performance and subjective user experience.
### Test Execution Procedures
Document **step-by-step procedures** for conducting each test session including participant briefing, task administration, data recording, and session conclusion. Specify how to handle unexpected situations, user questions, and technical difficulties during testing.
Include **safety considerations** for managing situations where users commit errors during testing, especially for critical tasks. Define stopping criteria for tests that might put participants at risk or generate invalid data.
### Results Analysis and Integration
Specify how **test results will be analyzed** including criteria for determining task success, failure, and partial completion. Define how use errors and difficulties will be categorized and how findings will feed back into your risk management and design control processes.
Plan for **iterative testing** if initial results reveal significant usability issues requiring design modifications and retesting.
## Example
### Scenario
You are creating a detailed protocol for testing your mobile ECG monitoring app that will validate whether patients can safely record heart rhythms at home and respond appropriately to emergency alerts. Your protocol must systematically test all hazard-related scenarios identified in your risk assessment through specific user tasks.
### Example Usability Evaluation Protocol
**ID:** UEP-001-ECG-Monitor
**Scope:** This protocol defines summative usability evaluation procedures for the Mobile ECG Monitor System to validate user interface safety and effectiveness for hazard-related use scenarios.
**User Information:**
**Intended Users:** Adults aged 45-80 with suspected cardiac arrhythmias, representing both high and low technology comfort levels. Participants must have basic smartphone experience and be able to read English instructions.
**Use Environment:** Home environment with typical household distractions including television, family members, and varying lighting conditions. Testing simulates real-world scenarios including evening use and time-pressure situations.
**Device Information:**
**User Interface:** Mobile application accessed via iOS or Android smartphone with touch screen interaction, voice prompts for guidance, and Bluetooth connectivity to ECG sensor hardware. Authentication requires PIN or biometric login.
**Training Required:** 15-minute introduction video covering electrode placement, app navigation, and emergency response procedures. No specialized medical training required.
**Materials Provided:** Instructions for Use booklet, quick reference card for electrode placement, emergency contact information card, and device carrying case.
**Hazard-Related Use Scenarios:**
| Risk ID | Risk Type | Hazard | Hazardous Situation | Harm |
| ------- | --------- | ---------------------------- | ------------------------------- | ----------------------------------------- |
| R-015 | Use Error | Poor electrode contact | Undetected arrhythmia | Missed diagnosis leading to cardiac event |
| R-023 | Use Error | Ignoring emergency alert | Delay in seeking emergency care | Serious cardiac complications |
| R-031 | Use Error | Incomplete symptom reporting | Misinterpretation by clinician | Inappropriate treatment decisions |
**Testing Tasks:**
| Task ID | Task | Hazard-Related Use Scenario | Risk ID | Critical Task |
| ------- | ------------------------------------------------------------------------ | ------------------------------------------------------- | ------- | ------------- |
| T-001 | Complete initial app setup and account creation | Poor electrode contact leading to poor recordings | R-015 | No |
| T-002 | Attach electrodes following app guidance and achieve >80% signal quality | Poor electrode contact leading to undetected arrhythmia | R-015 | Yes |
| T-003 | Record 30-second ECG during simulated chest pain episode | Failure to capture arrhythmia during symptoms | R-023 | Yes |
| T-004 | Respond appropriately to high-priority emergency alert within 2 minutes | Ignoring emergency alert leading to delayed care | R-023 | Yes |
| T-005 | Complete symptom diary entry and share with provider | Incomplete reporting leading to misdiagnosis | R-031 | No |
**User Testing Data Collection:**
For each participant (UD1-UD15), collect:
* Demographic information (age, gender, technology experience)
* Task completion status (pass/fail) for each task
* Time to complete each task
* Number of attempts required for successful completion
* Use errors observed during testing
* Use difficulties and close calls
* Critical task performance (must achieve 100% success rate)
* Post-test feedback on interface clarity and difficulty
**Test Session Procedure:**
1. Welcome participant and obtain informed consent
2. Provide 15-minute training session with materials
3. Allow 10-minute practice period with app
4. Conduct tasks T-001 through T-005 in sequence
5. Document all observations in real-time
6. Conduct post-test interview (15 minutes)
7. Review safety considerations and emergency procedures
**User Feedback Questions:**
* How would you describe the ease of using this application?
* What aspects of electrode placement were most challenging?
* How clear were the emergency alert messages and required actions?
* What improvements would make the app safer or easier to use?
* How does this compare to other health apps you've used?
**Impact Assessment:**
Results will be evaluated for impact on:
* Risk management file updates for newly identified use-related risks
* Software requirements modifications for user interface improvements
* User interface design changes to address usability issues
* Instructions for use clarifications based on user confusion
* Training material enhancements to reduce use errors
**Acceptance Criteria:**
* 100% of participants must complete critical tasks T-002, T-003, and T-004 successfully
* No more than 20% of participants should require multiple attempts for critical tasks
* Use difficulties must be documented and assessed for risk impact
* Any use errors leading to potential harm must trigger design review
## Q\&A
Design test tasks that realistically represent how users would interact with your device in scenarios that could lead to hazardous situations. Each hazard-related use scenario from your risk assessment should translate into one or more specific, observable tasks. Focus on critical tasks where user errors could cause significant harm, and ensure tasks flow logically through typical user workflows while capturing both normal use and reasonably foreseeable misuse.
Select participants who represent your intended user population including relevant demographic characteristics, medical conditions, technology experience levels, and any special requirements. Generally test with five or more users per distinct user group, though complex devices may require larger samples. Consider factors like age, education, medical literacy, and familiarity with similar devices when defining selection criteria.
Design testing environments that replicate the conditions where your device will actually be used, including appropriate lighting, noise levels, distractions, and time pressures. For home-use devices, simulate household distractions. For clinical devices, replicate clinical workflow pressures. Include realistic interruptions and multitasking scenarios that users might encounter during actual device operation.
Collect both objective performance data (task completion, time, errors) and subjective user experience data (perceived difficulty, confidence, satisfaction). Document use errors, use difficulties, and close calls where users almost made errors. Record not just what users do but how they think through tasks, where confusion occurs, and what recovery strategies they employ when problems arise.
Critical tasks require more rigorous testing and stricter acceptance criteria since user errors could cause significant harm. Test critical tasks with larger sample sizes if possible, establish clear success criteria (often 100% completion rate), and document any failures or difficulties more thoroughly. Critical task failures typically require design modifications and retesting before proceeding to market.
Systematically review testing results to identify new use-related risks not previously considered, evaluate the effectiveness of existing risk controls, and determine if additional risk control measures are needed. Any use errors or difficulties that could lead to harm should be assessed through your risk management process. Update risk assessments and implement additional controls before final device release if needed.
# Usability Evaluation Report
Source: https://docs.withdovetail.com/tasks/usability-evaluation-report
Document user testing results proving interface safety and regulatory compliance achievement.
## Summary
The Usability Evaluation Report documents the **results and analysis** of your usability testing activities, providing evidence that users can safely operate your medical device. This report analyzes both **formative evaluation** conducted during development and **summative evaluation** performed on the final device, demonstrating compliance with **human factors engineering** requirements and supporting risk management decisions.
## Why is Usability Evaluation Report important?
This report serves as **regulatory evidence** that your device user interface is safe and effective for its intended users. Regulators require documented proof that you systematically evaluated user interactions and addressed any **use-related risks** before market release. The report demonstrates that your usability engineering process is complete and provides **objective data** supporting your device's safety profile. Without this comprehensive documentation, you cannot demonstrate compliance with human factors requirements or justify that your device is safe for user operation.
## Regulatory Context
Under **FDA Human Factors Guidance** and **21 CFR Part 820.30**:
* Report must provide **objective evidence** of user interface safety validation
* Must document **all use errors, difficulties, and task failures** observed during testing
* **Critical task performance** must be thoroughly analyzed and justified
* Results must inform **risk management** and **design control** processes
* Report supports **validation** requirements for design controls
**Special attention required for:**
* High-risk devices requiring formal validation evidence
* Documentation of any critical task failures and corrective actions
* Integration with 510(k) submissions or PMA applications
* Post-market surveillance planning based on usability findings
Under **EU MDR 2017/745** and **IEC 62366-1:2015**:
* Report must comply with **IEC 62366-1:2015** documentation requirements
* Must demonstrate **summative evaluation** completion for usability engineering file
* Results must support **Annex I GSPR** compliance claims
* Report required for **technical documentation** per Annex II
* Must address **use-related hazard scenarios** from risk assessment
**Special attention required for:**
* IEC 62366-1 Section 4.2 usability engineering file requirements
* Integration with clinical evaluation when use errors affect clinical outcomes
* Notified body review of usability evidence and conclusions
* Post-market surveillance system for ongoing use error monitoring
## Guide
Your usability evaluation report transforms raw testing data into regulatory evidence that demonstrates user interface safety and supports risk management decisions.
### Report Structure and Analysis Framework
Begin with **comprehensive documentation** of your formative evaluation activities including expert reviews, prototype testing, and iterative design improvements. Document specific feedback received and how it influenced your final user interface design, demonstrating your systematic approach to human factors engineering.
For summative evaluation, provide **detailed analysis** of all testing data including task completion rates, use errors, use difficulties, and user feedback. Analyze patterns across participants to identify systematic usability issues versus individual user variations.
### Formative Evaluation Documentation
Document all **formative activities** conducted during development including stakeholder consultations, expert reviews, prototype testing, and design iterations. Describe specific **suggestions received** from medical experts, user representatives, and usability specialists and how these informed your design decisions.
Demonstrate the **evolution of your user interface** by documenting key design changes made in response to formative feedback. This shows regulators that you proactively addressed usability concerns before final testing, reducing the likelihood of summative evaluation failures.
### Summative Evaluation Results Analysis
Present **comprehensive test results** including participant demographics, task completion data, time measurements, error rates, and qualitative feedback. Organize results by hazard-related use scenario to demonstrate systematic coverage of safety-critical interactions.
Analyze **use errors and difficulties** by categorizing them by severity, frequency, and potential impact on safety. Distinguish between errors that could lead to harm versus those that only affect user satisfaction or efficiency. Document any **close calls** where users nearly made errors but recovered.
### Critical Task Performance Assessment
Provide **detailed analysis** of critical task performance since these represent scenarios where user errors could cause significant harm. For any critical task failures, document the specific failure mode, contributing factors, and immediate corrective actions taken.
Justify **acceptance of any critical task issues** through risk-benefit analysis, demonstrating that residual risks are acceptable when weighed against device benefits and available risk controls.
### Risk Management Integration
Document how **testing results influenced** your risk management file including newly identified risks, updated risk control measures, and changes to design requirements. Demonstrate that all use-related risks are properly controlled through design features, protective measures, or information for safety.
Specify **post-market surveillance** plans for monitoring use errors and difficulties that may emerge during real-world use, showing your commitment to ongoing safety monitoring.
### Impact Assessment and Conclusions
Analyze **testing impact** on software requirements, user interface design, use specifications, and risk management processes. Document any design changes triggered by testing results and verification that changes address identified issues.
Provide **clear conclusions** about user interface safety and readiness for market release, supported by objective data from your testing activities.
## Example
### Scenario
You have completed usability testing of your mobile ECG monitoring app with 15 patients and need to document the results to demonstrate that users can safely operate the device at home. Your testing revealed one critical task failure and several use difficulties that required analysis and response.
### Example Usability Evaluation Report
**ID:** UER-001-ECG-Monitor
**Scope:** This report summarizes formative and summative usability evaluation results for the Mobile ECG Monitor System, providing evidence of user interface safety and effectiveness.
**Formative Evaluations:**
During development, we conducted design reviews with three cardiologists and two emergency medicine physicians to gather feedback on clinical workflow integration. Five patient advisory group sessions with cardiac patients reviewed prototype interfaces focusing on instruction clarity and symptom reporting mechanisms.
**Formative Evaluation Feedback:**
Expert cardiologists recommended simplified electrode placement guidance after observing confusion during prototype demonstrations. Emergency physicians suggested more prominent emergency alert indicators and clearer action instructions. Patient advisors requested larger text for critical instructions and simplified symptom terminology.
**Design Improvements from Formative Evaluation:**
Based on expert feedback, we implemented animated electrode placement guides with step-by-step verification, enhanced emergency alert visual design with red backgrounds and flashing indicators, increased font sizes for safety-critical instructions, and simplified symptom reporting with plain language descriptions and visual icons.
**Summative Evaluation Results:**
**Participant Demographics:**
Fifteen participants (8 male, 7 female) aged 47-78 years with varying technology experience levels. All participants had basic smartphone experience and suspected cardiac arrhythmias. Technology comfort levels: 6 high, 5 moderate, 4 low.
**Task Performance Summary:**
| Task | Participants | Success Rate | Average Time | Use Errors | Critical Task |
| -------------------------- | ------------ | ------------ | ------------ | ---------- | ------------- |
| T-001: App setup | 15 | 100% | 3.2 min | 0 | No |
| T-002: Electrode placement | 15 | 93% (14/15) | 4.8 min | 1 | Yes |
| T-003: ECG recording | 15 | 100% | 2.1 min | 0 | Yes |
| T-004: Emergency response | 15 | 100% | 1.4 min | 0 | Yes |
| T-005: Symptom reporting | 15 | 87% (13/15) | 5.3 min | 2 | No |
**Critical Task Analysis:**
One participant (UD-012, age 74, low technology experience) initially placed electrodes incorrectly during Task T-002, achieving only 65% signal quality. However, the app's real-time feedback prompted electrode repositioning, ultimately achieving 85% signal quality on the second attempt. This use error did not result in a failed recording but demonstrated the importance of real-time feedback systems.
**Use Difficulties Identified:**
* Three participants initially struggled with Bluetooth pairing but succeeded with app guidance
* Two participants missed symptom severity indicators, leading to incomplete reporting
* Four participants requested confirmation dialogs for emergency actions
* One participant suggested adding a practice mode for first-time users
**User Feedback Summary:**
Participants rated the app as "easy to use" (average 4.2/5.0) with particular praise for electrode placement guidance and clear emergency instructions. Suggested improvements included practice mode availability and larger buttons for emergency functions.
**Risk Management Impact:**
Testing identified one new risk (R-045): "User confusion during initial Bluetooth setup could delay emergency recordings." This risk was assessed as low probability, moderate severity and controlled through enhanced pairing instructions and automatic retry mechanisms.
Updated risk controls for existing risks:
* R-015: Real-time electrode feedback system validated as effective
* R-023: Emergency alert system achieved 100% appropriate response rate
* R-031: Symptom reporting interface required minor improvements for clarity
**Design Changes Implemented:**
Based on testing results, we implemented enhanced Bluetooth pairing instructions with visual indicators, confirmation dialogs for emergency actions, optional practice mode for new users, and improved symptom severity indicators with color coding.
**Post-Market Surveillance Plan:**
We will monitor customer support inquiries for usability issues, track emergency response effectiveness through clinical partners, and conduct annual user satisfaction surveys to identify emerging usability concerns.
**Conclusions:**
Summative usability evaluation demonstrates that users can safely operate the Mobile ECG Monitor System for its intended use. All critical tasks achieved acceptable performance levels with no failures that could lead to patient harm. The one critical task difficulty was successfully mitigated by existing design controls. The device user interface is validated for safe use by the intended user population.
## Q\&A
Analyze use errors by categorizing them by severity (could lead to harm vs. usability issues), frequency across participants, and contributing factors. Document the specific failure modes, user recovery strategies, and potential safety implications. Distinguish between systematic design issues affecting multiple users versus individual user variations. For each error, determine if it represents a new risk requiring control measures or validation of existing risk controls.
Critical task failures require immediate analysis and typically mandate design modifications before market release. Document the specific failure mode, contributing factors, and safety implications. Implement design changes to address the root cause, then conduct additional testing to verify the fix is effective. If critical task failures cannot be eliminated through design, justify acceptance through comprehensive risk-benefit analysis and additional risk controls.
Document all formative activities systematically including expert consultations, prototype testing, user feedback sessions, and design iterations. Describe specific feedback received from stakeholders and how it influenced design decisions. Show the evolution of your user interface by documenting key changes made in response to formative insights. This demonstrates proactive human factors engineering and reduces regulatory concerns about your development process.
Systematically review all testing results to identify new use-related risks, validate existing risk control effectiveness, and determine if additional controls are needed. Document any changes to your risk assessment based on testing findings. Specify how use errors and difficulties will be monitored post-market and what thresholds would trigger additional risk control measures. Update risk management files before final device release.
Provide clear, evidence-based conclusions about user interface safety and readiness for market release. State whether all critical tasks can be performed safely by intended users and whether any residual use-related risks are acceptable. Address any limitations of your testing and how they might affect real-world performance. Conclude with a definitive statement about user interface validation for safe use.
Plan post-market surveillance to monitor use errors and difficulties that may emerge during real-world use beyond your controlled testing environment. Establish methods for collecting user feedback, tracking customer support issues related to usability, and monitoring adverse events potentially related to use errors. Define thresholds that would trigger additional usability evaluation or design modifications based on post-market data.
# User Manual
Source: https://docs.withdovetail.com/tasks/user-manual
Create comprehensive operational guide maximizing device functionality and user experience.
## Summary
The User Manual is a **comprehensive operational guide** that provides detailed instructions for device setup, operation, maintenance, and troubleshooting. Unlike the Instructions for Use which focuses on regulatory compliance and safety, your User Manual offers in-depth guidance for maximizing device functionality and user experience. This document supports users with detailed operational procedures, advanced features, and comprehensive troubleshooting guidance.
## Why is User Manual important?
User Manuals enhance **user competency and satisfaction** by providing detailed operational guidance that goes beyond basic safety requirements. While the Instructions for Use covers regulatory mandates, your User Manual helps users fully utilize device capabilities, reducing support requests and improving user outcomes. A comprehensive manual demonstrates your commitment to user success and product quality.
Well-designed User Manuals **reduce user errors and support costs** by providing clear guidance for complex operations, troubleshooting procedures, and advanced features. They also serve as valuable training resources for healthcare providers and technical staff who need detailed understanding of device capabilities. Your manual can differentiate your product by demonstrating superior user support and comprehensive functionality.
## Regulatory Context
Under **21 CFR Part 820.120** (Device Labeling):
* User manuals are **supplementary labeling** that must be accurate and not misleading
* Must be **consistent with Instructions for Use** and regulatory submissions
* Cannot make **unsupported claims** about device performance or benefits
* Must include **appropriate warnings** for advanced or complex procedures
* Subject to **labeling controls** under Quality System Regulation
**Special attention required for:**
* Consistency with 510(k) submissions and predicate device comparisons
* Software device cybersecurity guidance and user responsibilities
* Training requirements for complex medical devices
* Integration with risk management and usability engineering documentation
Under **EU MDR 2017/745**:
* Must be **consistent with Instructions for Use** and technical documentation
* Cannot contradict **GSPR requirements** or safety information
* Must support **intended purpose** and not expand indications for use
* Subject to **quality management system** controls for document accuracy
* Must align with **usability engineering** and risk management findings
**Special attention required for:**
* Consistency with technical file documentation and clinical evaluation
* Authorized representative contact information for non-EU manufacturers
* Post-market surveillance integration for user feedback and updates
* Translation accuracy for multi-language user manuals
## Guide
### Document Purpose and Scope
Your **User Manual serves as comprehensive operational guidance** that complements your Instructions for Use with detailed procedural information, advanced feature explanations, and extensive troubleshooting support. While the IFU focuses on regulatory compliance and basic safety, your User Manual provides the depth needed for proficient device operation and optimal user experience.
**Scope definition** should clearly establish what your User Manual covers beyond the IFU requirements. Include detailed operational procedures for all device functions, advanced features and customization options, comprehensive troubleshooting and maintenance guidance, integration procedures with other systems or devices, and training materials for different user skill levels. Avoid duplicating basic safety information already covered in your IFU.
### Content Organization and Structure
**Logical organization** enhances user accessibility and learning progression. Structure your manual with clear sections for getting started, basic operations, advanced features, troubleshooting, and maintenance. Use consistent formatting, clear headings, and cross-references to help users navigate efficiently. Consider different user paths based on experience level and specific use cases.
**Visual design elements** significantly improve user comprehension and retention. Include screenshots or photographs for each major operational step, flowcharts for complex decision-making processes, diagrams showing device connections or setup configurations, and visual indicators for important warnings or tips. Ensure all visual elements are clear, current, and accessible to users with visual impairments.
### Operational Procedures
**Detailed setup instructions** should guide users through complete device preparation and configuration. Provide step-by-step procedures for initial installation or setup, account creation and user profile configuration, device calibration and testing procedures, integration with existing systems or workflows, and verification steps to ensure proper operation. Include alternative procedures for different operating environments or user preferences.
**Comprehensive operational guidance** covers all device functions with sufficient detail for confident user operation. Document standard operating procedures for routine tasks, advanced features and customization options, data management and backup procedures, security settings and user access controls, and performance optimization techniques. Organize procedures logically and provide clear success criteria for each step.
### Troubleshooting and Maintenance
**Systematic troubleshooting guidance** helps users resolve common issues independently, reducing support requests and improving user satisfaction. Organize troubleshooting by symptoms or error messages, provide step-by-step diagnostic procedures, include clear resolution steps for identified problems, and specify when to contact technical support. Use decision trees or flowcharts for complex troubleshooting scenarios.
**Maintenance procedures** ensure optimal device performance and longevity. Include routine maintenance schedules and procedures, software update instructions and considerations, data backup and recovery procedures, performance monitoring and optimization guidance, and preventive maintenance recommendations. Specify any maintenance tasks that require professional service or manufacturer support.
### User Training and Support
**Training materials** within your User Manual help users develop proficiency with device operation. Include learning objectives for different user skill levels, practice exercises or scenarios for skill development, competency checklists for training verification, and reference materials for ongoing support. Consider different learning styles and provide multiple approaches to skill development.
**Support resources** connect users with additional help when needed. Provide comprehensive contact information for technical support, links to online resources and video tutorials, user community forums or support groups, and procedures for reporting issues or requesting enhancements. Include escalation procedures for urgent issues or safety concerns.
### Integration and Workflow
**Workflow integration guidance** helps users incorporate your device into existing processes and systems. Document integration procedures with common healthcare information systems, workflow modifications needed for optimal device utilization, staff training requirements for organizational implementation, and change management considerations for process improvement. Address different organizational contexts and use cases.
**Interoperability information** covers device connections and data exchange with other systems. Include supported file formats and data exchange protocols, integration procedures with electronic health records or other software, network configuration and security requirements, and troubleshooting guidance for connectivity issues. Ensure information remains current as systems evolve.
## Example
**Scenario:** You develop a comprehensive User Manual for "PulmoTracker," a smartphone application that monitors respiratory patterns using device microphones and provides breathing exercise guidance for patients with chronic respiratory conditions.
### Getting Started Section
**Initial Setup and Configuration**
Welcome to PulmoTracker - your comprehensive respiratory monitoring and training companion. This manual provides detailed guidance for maximizing your device's capabilities beyond the basic safety information covered in your Instructions for Use.
**Account Setup and Personalization:**
1. Download PulmoTracker from your device's official app store
2. Create your secure account using the email verification process
3. Complete the comprehensive health profile including respiratory history, current medications, and treatment goals
4. Configure personalized alert preferences based on your healthcare provider's recommendations
5. Set up emergency contacts and healthcare provider information for care coordination
6. Customize your dashboard layout to prioritize the information most relevant to your condition
**Device Calibration and Testing:**
1. Position your smartphone in the recommended location (6-12 inches from your mouth)
2. Complete the initial calibration sequence using the guided breathing exercises
3. Test microphone sensitivity in your typical usage environment
4. Verify alert functionality with test notifications
5. Confirm data synchronization with your healthcare provider's system if applicable
### Advanced Features Section
**Comprehensive Monitoring Capabilities**
**Custom Breathing Programs:**
Create personalized breathing exercise routines tailored to your specific respiratory condition and fitness level. Access the Program Builder through Settings > Custom Programs. Select from pre-configured templates for conditions like COPD, asthma, or anxiety management, or build completely custom routines using our exercise library.
**Data Analysis and Trends:**
Your PulmoTracker provides sophisticated analysis of your respiratory patterns over time. Access detailed trend analysis through the Analytics tab, where you can view daily, weekly, and monthly patterns. The application identifies gradual changes in your baseline respiratory function and can alert you and your healthcare provider to significant variations that may indicate condition changes.
**Healthcare Provider Integration:**
Connect directly with your healthcare team through the Provider Portal. Share real-time data, receive customized exercise prescriptions, and participate in remote monitoring programs. Your provider can adjust your treatment plan based on objective data from your daily monitoring activities.
### Troubleshooting Section
**Common Issues and Solutions**
**Microphone Detection Problems:**
If PulmoTracker cannot detect your breathing patterns:
1. Check microphone permissions in your device settings
2. Ensure no other applications are using the microphone
3. Test in a quiet environment to eliminate background noise
4. Clean your device's microphone opening gently with a dry cloth
5. Restart the application and repeat calibration if necessary
**Data Synchronization Issues:**
When data doesn't sync with your healthcare provider:
1. Verify internet connectivity and try again
2. Check that your healthcare provider has activated data sharing
3. Confirm your provider portal credentials are current
4. Contact technical support if issues persist beyond 24 hours
**Alert and Notification Problems:**
If you're not receiving expected alerts:
1. Check notification permissions for PulmoTracker in device settings
2. Verify alert thresholds are set appropriately for your condition
3. Ensure Do Not Disturb settings allow PulmoTracker notifications
4. Test alert functionality using the Settings > Test Alerts feature
### Maintenance and Updates Section
**Keeping Your PulmoTracker Current**
**Software Updates:**
PulmoTracker automatically checks for updates weekly. Enable automatic updates in Settings > App Updates for the latest features and security improvements. Major updates may include new breathing exercise programs, enhanced analytics capabilities, or improved healthcare provider integration features.
**Data Backup and Security:**
Your respiratory data is automatically backed up to secure, HIPAA-compliant cloud storage. Access backup settings through Settings > Data Management to configure backup frequency and retention periods. You can export your data for personal records or healthcare provider review using the Export Data feature.
**Performance Optimization:**
For optimal performance, restart PulmoTracker weekly and ensure adequate device storage space. The application requires approximately 500MB for full functionality including exercise videos and data storage. Clear cache monthly through Settings > Storage Management to maintain optimal performance.
## Q\&A
Your User Manual should provide comprehensive operational detail that goes well beyond the regulatory requirements covered in your Instructions for Use. While the IFU focuses on safety, basic operation, and compliance, your User Manual can include advanced features, detailed troubleshooting, workflow integration guidance, and extensive training materials. The manual should enable users to fully utilize device capabilities and achieve optimal outcomes through detailed procedural guidance and comprehensive support information.
Include screenshots or photographs for each major operational step, flowcharts for complex decision-making processes, diagrams showing device connections or setup configurations, and visual indicators for important tips or warnings. Ensure all visual elements are current, clear, and accessible to users with visual impairments. Use consistent visual design throughout the manual and provide alternative text descriptions for screen readers and accessibility compliance.
Organize troubleshooting by symptoms or error messages that users actually experience, rather than by technical system components. Provide step-by-step diagnostic procedures with clear resolution steps for identified problems. Use decision trees or flowcharts for complex troubleshooting scenarios and specify when users should contact technical support rather than attempting further self-resolution. Include escalation procedures for urgent issues or safety concerns.
Include learning objectives for different user skill levels, practice exercises or scenarios for skill development, competency checklists for training verification, and reference materials for ongoing support. Consider different learning styles and provide multiple approaches to skill development including visual, auditory, and hands-on learning opportunities. Address both individual user training and organizational implementation requirements for healthcare settings.
Structure your manual with clear pathways for different user experience levels, from beginners to advanced users. Use progressive disclosure techniques where basic information is immediately accessible while advanced features are clearly marked and easily found. Provide quick reference guides for experienced users alongside detailed step-by-step instructions for beginners. Consider creating separate sections or appendices for advanced features and administrative functions.
Include routine maintenance schedules and procedures, software update instructions and considerations, data backup and recovery procedures, performance monitoring and optimization guidance, and preventive maintenance recommendations. Specify any maintenance tasks that require professional service or manufacturer support. Provide clear guidance on when and how to contact technical support for issues beyond user resolution capabilities.
# User Needs List
Source: https://docs.withdovetail.com/tasks/user-needs-list
Document user expectations providing design compass and regulatory foundation through solution-neutral requirement capture.
## Summary
The User Needs List captures what your users expect and require from your medical device, serving as the foundational document that drives all design decisions, requirements development, risk management activities, and validation testing throughout your device development process.
## Why is a User Needs List Important?
A comprehensive User Needs List provides the **regulatory foundation** for medical device development by establishing clear user expectations before design begins. Without well-documented user needs, development becomes unfocused and reactive, leading to **feature creep**, **missed requirements**, and **validation failures** that can prevent regulatory approval and market success.
This document transforms abstract user expectations into **concrete development inputs** that guide every subsequent design decision. It establishes the basis for **requirements traceability**, ensuring that every system requirement, software feature, and risk control can be traced back to a specific user need. This traceability is essential for demonstrating regulatory compliance and design rationale.
For medical device development, user needs serve as your **design compass** by defining what success looks like from the user's perspective. They prevent over-engineering by focusing development efforts on features that truly matter to users while ensuring safety and effectiveness requirements are captured early. The document also provides the foundation for **validation activities** that demonstrate your device meets its intended use.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls), the FDA requires:
* **Documented user needs** as design inputs that establish what the device must accomplish
* **Traceability** from user needs through design requirements to verification and validation
* **Design review** of user needs to ensure completeness and accuracy
* **User needs validation** through clinical evaluation or usability testing
* **Change control** for user needs updates throughout development
The FDA expects user needs to be:
* Based on intended use and user research
* Solution-neutral and focused on user outcomes
* Comprehensive enough to guide design decisions
* Traceable to system and software requirements
* Validated through appropriate testing methods
**Special attention required for:**
* Software as Medical Device (SaMD) user needs must address clinical workflow integration and decision-making support
* Combination devices require user needs for both hardware and software components with clear interfaces
* Cybersecurity considerations must be reflected in user needs for connected devices
* Usability engineering per FDA Human Factors guidance requires user needs to address use-related risks
Under **EU MDR 2017/745**, user needs support compliance with:
* **Annex I GSPR 1** requiring devices to achieve intended performance for users
* **EN ISO 13485:2016** Section 7.2.1 for customer-related processes
* **IEC 62366-1:2015** Section 5.2 for identifying user interface characteristics
* **EN ISO 14971:2019** for risk management based on intended use
Key MDR requirements include:
* User needs must reflect intended users and use environments
* Clinical evaluation must demonstrate user needs are met
* Post-market surveillance must monitor user needs fulfillment
* Technical documentation must show user needs traceability
* Usability engineering must address user needs throughout design
**Special attention required for:**
* Clinical evidence requirements may be driven by specific user needs claims about clinical benefits
* Person Responsible for Regulatory Compliance (PRRC) must ensure user needs remain current and accurate
* Post-market surveillance must include monitoring whether user needs continue to be met in real-world use
* AI/ML devices require user needs that address algorithm transparency and clinical decision support
## Guide
Your User Needs List must comprehensively capture what users expect from your device while providing clear guidance for all subsequent development activities.
### User Research and Stakeholder Input
Begin with **comprehensive user research** to understand the problems your device should solve. Conduct interviews with intended users including clinicians, patients, caregivers, and technical staff. Observe current workflows and identify pain points, inefficiencies, and unmet needs. Review complaints about existing devices and analyze competitive products for insights.
Engage **multiple stakeholder groups** throughout the research process. Primary users directly interact with your device and have functional needs. Secondary users may be affected by device use and have different requirements. Technical stakeholders understand integration requirements and system constraints. Regulatory and quality teams provide compliance perspectives.
### User Needs Development
Write **high-level statements** that describe what users expect from your device without specifying how those needs will be met. Focus on user outcomes rather than technical solutions. Each user need should be clear, measurable, and focused on the user's perspective rather than internal technical requirements.
Structure user needs to be **solution-neutral** and broad enough to accommodate future design changes while specific enough to guide development decisions. Avoid technical implementation details or specific feature descriptions. Instead, focus on the fundamental problems users need solved and the outcomes they expect to achieve.
### Categorization and Organization
Organize user needs into **logical categories** that reflect different aspects of device use. Common categories include:
* **Functional needs:** What the device must do or accomplish
* **Performance needs:** How well the device must perform its functions
* **Usability needs:** How easy and intuitive the device must be to use
* **Safety needs:** How the device must protect users from harm
* **Compatibility needs:** How the device must work with other systems
* **Environmental needs:** How the device must perform in its use environment
Assign **unique identifiers** to each user need using a consistent format (e.g., UN001, UN002) that supports traceability throughout development. Include priority levels or criticality ratings to help guide design trade-off decisions when resources are limited.
### Essential vs. Product-Specific Needs
Distinguish between **essential user needs** that apply to all devices of your type and **product-specific needs** unique to your particular device. Essential needs often relate to basic safety, regulatory compliance, and fundamental usability requirements that any device in your category must meet.
Product-specific needs reflect the **unique value proposition** of your device and the specific problems it solves differently than existing solutions. These needs drive innovation and differentiation while ensuring your device provides meaningful benefits to users.
### Validation and Review
Establish **review processes** to ensure user needs are complete, accurate, and achievable. Involve multidisciplinary teams including clinical, technical, quality, and regulatory representatives. Review user needs against intended use statements and ensure consistency with regulatory requirements.
Plan for **user needs validation** through appropriate methods such as user interviews, surveys, usability testing, or clinical evaluation. Validation should confirm that identified needs accurately reflect user expectations and that meeting these needs will result in a successful device.
### Traceability and Change Management
Implement **traceability systems** that link each user need to derived system requirements, software requirements, risk controls, and verification activities. This traceability demonstrates that all user needs are addressed in your design and that all requirements serve a user purpose.
Establish **change control procedures** for user needs updates throughout development. Changes may be driven by new user research, regulatory feedback, or design discoveries. Document the rationale for changes and assess their impact on derived requirements and verification activities.
### Documentation Standards
Document user needs in a **structured format** that supports regulatory review and team communication. Include sufficient detail for team members to understand user expectations while maintaining solution neutrality. Provide context about user environments and constraints that influence how needs should be met.
Ensure **documentation quality** through clear writing, consistent terminology, and logical organization. User needs should be understandable to both technical and non-technical stakeholders while providing sufficient detail to guide design decisions.
## Example
**Scenario:** You're developing a wearable stress monitoring device that helps office workers understand and manage their stress levels throughout the workday. The device collects physiological data and provides personalized recommendations through a mobile app. Users include busy professionals who want objective stress insights without disrupting their workflow.
### User Needs List
**ID:** UNL-StressWear-2024-001
**Device:** StressWear Stress Monitoring System
**Purpose:** To provide office workers with objective stress monitoring and personalized stress management recommendations through a comfortable wearable device and intuitive mobile application.
**User Needs:**
| User Need ID | Type of User Need | Category | Description |
| ------------ | ----------------- | ------------- | ------------------------------------------------------------------------------------ |
| UN001 | Essential | Safety | The device must not cause skin irritation or allergic reactions during extended wear |
| UN002 | Essential | Safety | The device must not pose electrical safety risks to users |
| UN003 | Essential | Usability | The device must be intuitive to use without requiring extensive training |
| UN004 | Essential | Performance | The device must provide accurate and reliable measurements |
| UN005 | Essential | Compatibility | The device must work with common smartphones and operating systems |
| UN006 | Product | Usability | The device must be comfortable for all-day wear during office work |
| UN007 | Product | Performance | The device must accurately detect stress levels through physiological monitoring |
| UN008 | Product | Usability | The mobile app must display stress information in an easily understandable format |
| UN009 | Product | Functionality | The device must provide personalized stress management recommendations |
| UN010 | Product | Performance | The device must operate for a full workday without charging |
| UN011 | Product | Usability | The device must connect to the mobile app automatically without user intervention |
| UN012 | Product | Environmental | The device must be water-resistant for handwashing and light rain exposure |
| UN013 | Product | Usability | The device must be easy to clean and maintain for hygiene |
| UN014 | Product | Performance | The app must provide real-time stress level updates throughout the day |
| UN015 | Product | Functionality | The device must track stress patterns over time to identify trends |
| UN016 | Product | Privacy | The device must protect user health data and maintain privacy |
| UN017 | Product | Usability | The device must be discreet and professional-looking for office environments |
| UN018 | Product | Performance | The device must provide consistent measurements across different users |
| UN019 | Product | Functionality | The app must allow users to log stress-related events and activities |
| UN020 | Product | Usability | The device setup and initial configuration must be simple and quick |
**Expected Lifetime:** 5 years
**Regulatory References:**
* EU MDR 2017/745
* ISO 13485:2016 - Medical devices Quality management systems Requirements for regulatory purposes
* IEC 62366-1:2015 - Medical devices Part 1: Application of usability engineering to medical devices
**Mapping to Standards:**
| ISO 13485:2016 Section | Document Section |
| ---------------------- | ---------------- |
| 7.2.1 | All user needs |
| 7.3.3 | All user needs |
| IEC 62366-1:2015 Section | Title | Document Section |
| ------------------------ | ---------------------------------------------------------------------------------- | ---------------------------------------------- |
| 5.2 | Identify user interface characteristics related to safety and potential use errors | UN001-UN005, UN008, UN011, UN013, UN017, UN020 |
| 5.6 | Establish user interface specification | UN003, UN008, UN011, UN020 |
## Q\&A
Comprehensive user needs should cover **all aspects of device interaction** including functional performance, usability, safety, and environmental requirements. Review your intended use statement and ensure every claimed benefit or function has corresponding user needs. Conduct stakeholder reviews with clinical, technical, and quality teams to identify gaps. Consider the complete user journey from device setup through daily use to maintenance and disposal. If you can't trace a system requirement back to a user need, you may be missing important user expectations.
User needs should be **detailed enough to guide design decisions** but **broad enough to accommodate different implementation approaches**. Include the user's perspective on what outcomes they expect and why those outcomes matter. Avoid specifying technical solutions or implementation details. For example, write "Users must be able to quickly understand their current stress level" rather than "The device must display stress level as a number from 1-10." Provide context about user environments and constraints that affect how needs should be met.
Document **all legitimate user needs** even when they appear to conflict, then use design reviews and risk management to resolve conflicts. Prioritize needs based on safety criticality, regulatory requirements, and primary user impact. Consider whether conflicts reflect different use scenarios or user types that require different solutions. Some conflicts may be resolved through design features that accommodate multiple approaches. Document the rationale for prioritization decisions and ensure all stakeholders understand trade-offs.
Update user needs when **new information changes user expectations** or when **regulatory requirements evolve**. Common triggers include user research findings, usability testing results, clinical feedback, regulatory guidance updates, or competitive analysis insights. Establish change control procedures that assess the impact of user needs changes on derived requirements, design decisions, and verification activities. Minor clarifications may require minimal impact assessment, while new user needs may trigger significant design changes.
Validate user needs through **direct user feedback** using methods appropriate to your development stage and resources. Early validation can use interviews, surveys, or focus groups with representative users. Later validation may include usability testing, clinical evaluation, or pilot studies. Document validation methods and results to demonstrate that user needs accurately capture user expectations. Consider ongoing validation through post-market surveillance to ensure user needs remain current as markets and technologies evolve.
**User needs** describe what users expect from the device from their perspective, while **system requirements** specify what the device must do to meet those needs. User needs are solution-neutral and focus on outcomes (e.g., "Users must quickly understand device status"). System requirements are more technical and specific (e.g., "Device must display status using LED indicators visible from 2 meters"). Each system requirement should trace back to one or more user needs, ensuring all technical specifications serve user purposes.
# Verification and Validation Plan
Source: https://docs.withdovetail.com/tasks/verification-and-validation-plan
Establish comprehensive testing strategy proving device correctness and suitability for intended medical use.
## Summary
The Verification and Validation Plan is a **comprehensive roadmap** that outlines how you will prove your medical device meets its design specifications (verification) and fulfills its intended use (validation). This document serves as the **master plan** for all testing activities, ensuring systematic coverage of hardware, software, and integrated system components while demonstrating regulatory compliance.
## Why is Verification and Validation Planning important?
Verification and validation planning exists because medical devices must demonstrate **two critical aspects** before market entry: that you built the device correctly according to specifications (verification) and that you built the right device for its intended use (validation). This systematic approach prevents costly redesigns, ensures patient safety, and provides regulators with confidence that your device performs as intended.
The planning phase is crucial because it establishes **testing strategies early** in development, allowing you to identify resource requirements, timeline dependencies, and potential technical challenges before they become critical path issues. Without proper V\&V planning, you risk discovering fundamental design flaws late in development or failing to demonstrate essential performance characteristics required for regulatory approval.
## Regulatory Context
Under **21 CFR Part 820.30** (Design Controls):
* **Section 820.30(f)** requires design verification to confirm design outputs meet design inputs
* **Section 820.30(g)** mandates design validation to ensure devices conform to defined user needs and intended uses
* **FDA Guidance "Design Control Guidance for Medical Device Manufacturers"** provides detailed V\&V expectations
* Software devices must comply with **FDA Guidance "General Principles of Software Validation"**
**Special attention required for:**
* Software as Medical Device (SaMD) classification and corresponding validation rigor
* Predicate device comparison and substantial equivalence demonstration
* Clinical validation requirements for novel devices or new indications
* Cybersecurity validation per FDA premarket cybersecurity guidance
Under **EU MDR 2017/745**:
* **Annex II, Section 2** requires comprehensive verification and validation documentation
* Must comply with **EN ISO 13485:2016 Section 7.3.6** for design verification and validation
* **IEC 62304** mandatory for medical device software lifecycle processes
* **IEC 62366-1** required for usability engineering and human factors validation
**Special attention required for:**
* Clinical evaluation requirements under Article 61 and Annex XIV
* Post-market clinical follow-up integration with validation activities
* Notified body assessment of V\&V documentation completeness
* Essential requirements demonstration through verification and validation
## Guide
### Understanding Verification vs. Validation
**Verification** answers "Did we build the device right?" by confirming your design outputs meet design inputs. This includes testing that your software functions according to specifications, hardware meets performance requirements, and all subsystem requirements are satisfied.
**Validation** answers "Did we build the right device?" by confirming the complete device meets user needs and intended use requirements. This includes usability testing, clinical evaluation, and real-world performance assessment.
### Planning Your V\&V Strategy
Your V\&V plan must address **five core testing domains**: performance verification, software verification, hardware verification (electrical, mechanical), biocompatibility evaluation, and usability validation. Each domain requires specific protocols, acceptance criteria, and documentation approaches.
**Performance verification** focuses on demonstrating your device meets its essential performance characteristics. Define measurable performance parameters from your system requirements and establish test methods that can objectively verify these parameters. Consider both normal operating conditions and edge cases that users might encounter.
**Software verification** requires systematic testing of software requirements through unit testing, integration testing, and system testing. Your plan should address how you will verify software requirements, validate software architecture decisions, and ensure Software of Unknown Provenance (SOUP) components are properly qualified.
**Hardware verification** encompasses electrical safety testing (IEC 60601 compliance), mechanical performance testing, and environmental testing. Plan for testing under various operating conditions, including temperature extremes, humidity, vibration, and electromagnetic interference.
**Biocompatibility evaluation** applies when your device contacts patients directly. Plan biological testing according to ISO 10993-1 based on contact type, duration, and tissue exposure. Consider whether existing biocompatibility data for materials can reduce testing requirements.
**Usability validation** ensures your device can be used safely and effectively by intended users. Plan human factors testing that addresses use-related risks identified in your risk management process.
### Establishing Testing Protocols
Each testing domain requires **detailed protocols** that specify test methods, sample sizes, acceptance criteria, and statistical approaches. Your protocols should reference applicable standards (IEC 60601, ISO 10993, IEC 62304) and justify any deviations from standard methods.
**Sample size determination** should follow statistical principles outlined in your Statistical Methods SOP. Consider the risk level of requirements being tested, variability in your device population, and regulatory expectations for your device class.
**Acceptance criteria** must be objective, measurable, and traceable to design inputs. Avoid subjective criteria that could lead to interpretation disputes during regulatory review.
### Managing Testing Dependencies
Your V\&V plan must address **testing sequence dependencies**. Verification testing typically precedes validation testing, as you need confidence in individual components before testing the integrated system. However, some validation activities like usability testing can occur in parallel with verification activities.
**Design freeze requirements** should be clearly defined. Major verification testing should occur on design-frozen devices to avoid retesting costs. However, early verification testing on prototypes can identify design issues before significant development investment.
**Outsourced testing coordination** requires careful planning of testing laboratory schedules, sample preparation, and results integration. Plan for potential testing delays and have contingency approaches for critical path testing.
### Documentation and Traceability
Your V\&V plan establishes the **documentation framework** for all testing activities. Each test must be traceable to specific requirements, and test results must be documented in standardized reports that support regulatory submissions.
**Traceability matrices** should be planned to demonstrate complete coverage of user needs, system requirements, and subsystem requirements through verification and validation activities. Plan how you will maintain traceability as requirements evolve during development.
**Change control integration** ensures that requirement changes trigger appropriate V\&V plan updates. Establish criteria for when requirement changes necessitate additional testing or protocol modifications.
## Example
**Scenario**: You are developing a mobile health app that monitors heart rhythm using smartphone sensors. The app analyzes sensor data, detects potential arrhythmias, and provides users with rhythm assessments and recommendations for medical consultation.
Your V\&V plan addresses software verification through automated testing of signal processing algorithms, user interface testing, and data security verification. Performance verification includes accuracy testing against reference ECG devices and timing validation for real-time processing. Usability validation involves testing with intended users to ensure they can properly position the device, interpret results correctly, and understand when to seek medical attention. Clinical validation demonstrates the app's diagnostic accuracy compared to standard-of-care methods.
### Verification and Validation Plan
**Document ID**: VVP-001\
**Version**: 1.0
#### 1. Purpose
This document outlines the verification and validation plan for the CardioMonitor mobile health application, ensuring the system meets design specifications and regulatory requirements for a Class II medical device software.
#### 2. Scope
This V\&V plan covers the complete CardioMonitor system including mobile application software, cloud-based analysis algorithms, and user interface components.
#### 3. Verification Activities
**3.1 Software Verification**
* **Unit Testing**: Verify individual software modules meet functional requirements
* **Integration Testing**: Confirm proper data flow between app components and cloud services
* **System Testing**: Validate complete software system performance against system requirements
* **SOUP Verification**: Qualify third-party libraries for signal processing and data encryption
**3.2 Performance Verification**
* **Signal Processing Accuracy**: Test algorithm accuracy against reference ECG signals with known arrhythmias
* **Real-time Performance**: Verify processing latency meets \<2 second requirement for rhythm analysis
* **Data Security**: Confirm encryption implementation meets HIPAA and GDPR requirements
**3.3 Cybersecurity Verification**
* **Penetration Testing**: Verify security controls against common attack vectors
* **Data Integrity Testing**: Confirm data cannot be modified during transmission or storage
#### 4. Validation Activities
**4.1 Usability Validation**
* **User Interface Testing**: Validate users can correctly position smartphone and interpret results
* **Use Error Testing**: Confirm critical use errors are prevented or mitigated
* **Training Effectiveness**: Validate user instructions enable safe and effective use
**4.2 Clinical Validation**
* **Diagnostic Accuracy Study**: Compare app results to 12-lead ECG interpretations by cardiologists
* **Real-world Performance**: Validate app performance in typical use environments
#### 5. Acceptance Criteria
* Software verification: All unit tests pass, integration testing demonstrates \<1% data loss
* Performance verification: Sensitivity ≥95%, Specificity ≥90% for atrial fibrillation detection
* Usability validation: \<5% critical use errors in simulated use testing
* Clinical validation: Diagnostic accuracy within 5% of predicate device performance
#### 6. Testing Schedule
* Software verification: Weeks 1-4 of testing phase
* Performance verification: Weeks 3-6 (parallel with software verification)
* Usability validation: Weeks 5-8 (requires near-final software build)
* Clinical validation: Weeks 7-12 (requires completed verification testing)
## Q\&A
Testing should be conducted on a production-equivalent device whenever possible. It's advisable to wait until the design is finalized to avoid costly retesting. However, early prototype testing can identify design issues before significant development investment. If using prototypes, you must justify any differences between the prototype and final product. The closer the prototype is to the manufacturing equivalent, the better regulatory acceptance you'll achieve.
The number of participants is usually recommended in applicable standards and guidance documents. For usability testing, IEC 62366-1 provides guidance on sample sizes. For clinical validation, conduct a power analysis to statistically determine the required sample size based on your study's objectives, expected effect size, and desired statistical power. Consider your device's risk classification when determining sample sizes.
The testing matrix is crucial as it helps confirm the necessary tests for your device, ensuring compliance with regulatory guidelines. It provides a systematic view of how each requirement will be verified or validated, preventing gaps in testing coverage. Spending extra time developing a comprehensive testing matrix during planning will save significant time and resources during actual testing execution.
Software testing serves as both verification and validation depending on what you're testing. Your V\&V plan should specify how test plans will generate tests based on requirements, and how test reports will document pass/fail status with justifications. While extensive automated testing frameworks aren't required, you should plan for systematic testing that covers all software requirements and use-related risks.
It's not mandatory, but it's important to justify any differences between prototypes and the final product. The main consideration is whether the manufacturing process significantly affects the device's safety or functionality. If the prototype closely resembles the final product in critical aspects, it may be acceptable for testing, but comprehensive justification is required. Regulators may require retesting if significant differences exist between test articles and final products.
Usability testing should align with identified use-related risks from your risk management process. Plan specific test scenarios for each identified risk, consider using mock data for safety, and ensure testing covers the complete user journey including critical tasks related to performance or safety. Usability testing can be conducted with healthy adults given a broad user profile, and simulated scenarios can be used for testing emergency situations.
# Verification And Validation Report
Source: https://docs.withdovetail.com/tasks/verification-and-validation-report
Summarize comprehensive testing activities proving device safety effectiveness and market readiness.
## Summary
The Verification and Validation Report provides a comprehensive summary of all verification and validation activities conducted during your medical device development, demonstrating that your device meets both design requirements and user needs.
## Why is Verification and Validation Report important?
The Verification and Validation Report is essential for demonstrating that your medical device development process has been completed successfully and that your device is safe and effective for its intended use. This document provides regulatory authorities with evidence that you have systematically tested your device to ensure it meets all design requirements (verification) and fulfills user needs and intended use (validation). It serves as the culmination of your design control process, proving that your device performs as intended and is ready for market release. Without comprehensive verification and validation documentation, you cannot demonstrate that your device is safe, effective, and compliant with regulatory requirements.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation) and **Design Controls**:
* **Design verification** must demonstrate that design outputs meet design inputs (820.30(f))
* **Design validation** must demonstrate that devices meet user needs and intended use (820.30(g))
* **Design transfer** must ensure design is correctly translated to production (820.30(h))
* **Design history file** must contain all verification and validation records (820.30(j))
**Special attention required for:**
* Class II and III devices requiring extensive verification and validation documentation
* Software medical devices requiring software lifecycle verification and validation
* Combination products requiring coordination between device and drug V\&V activities
* 510(k) submissions requiring substantial equivalence demonstration through V\&V
Under **EU MDR 2017/745** and **EN ISO 13485:2016**:
* **Design verification** must confirm design outputs meet design inputs (ISO 13485 Section 7.3.5)
* **Design validation** must confirm devices meet user needs (ISO 13485 Section 7.3.6)
* **Clinical evaluation** must validate clinical safety and performance (Article 61)
* **Technical documentation** must include complete V\&V evidence (Annex II)
**Special attention required for:**
* Notified body assessment of V\&V completeness for Class IIa and above devices
* Clinical evaluation integration with validation activities
* Post-market clinical follow-up (PMCF) validation data requirements
* Unique Device Identification (UDI) traceability for V\&V activities
## Guide
Your Verification and Validation Report must provide a comprehensive overview of all testing activities conducted to demonstrate that your device meets requirements and user needs. This document should synthesize results from all verification and validation activities into a clear conclusion about device readiness.
### Verification Activities Summary
Document all verification activities that demonstrate your design outputs meet your design inputs. This includes system testing, subsystem testing, software testing, hardware testing, and any other technical verification activities. Reference specific test protocols and test reports that provide evidence of requirement compliance. Summarize pass/fail results and document how any failures were addressed through design changes or additional testing.
### Validation Activities Summary
Document all validation activities that demonstrate your device meets user needs and intended use. This includes usability testing, clinical validation, performance validation, and any other user-focused validation activities. Reference specific validation protocols and validation reports that provide evidence of user need fulfillment. Summarize validation outcomes and document how any issues were addressed.
### Risk Management Integration
Demonstrate how your verification and validation activities address the risks identified in your risk assessment. Show that risk controls have been verified to be effective and that residual risks are acceptable. Reference your Risk Management Report and Traceability Matrix to show complete integration between risk management and V\&V activities.
### Design Transfer Verification
Document verification that your design has been correctly transferred to production. This includes verification of manufacturing processes, quality controls, and any production-specific testing. Demonstrate that the production version of your device maintains the same performance characteristics as the design version used in verification and validation testing.
### Overall Conclusion
Provide a clear conclusion about whether your device is ready for market release based on all verification and validation evidence. Address any outstanding issues or limitations and document how they will be managed. This conclusion should be supported by objective evidence from all V\&V activities.
## Example
**Scenario:** You develop a wearable heart rate monitoring device for fitness tracking. Your verification and validation activities include electrical safety testing, software verification, usability testing with target users, and clinical validation of heart rate accuracy. All testing demonstrates that the device meets requirements and user needs, with only minor usability improvements identified for future versions.
### Verification and Validation Report
**ID:** VVR-001
**1. Executive Summary**
This Verification and Validation Report summarizes all verification and validation activities conducted for the FitHeart Wearable Monitor during the design and development phase. All verification activities have demonstrated that design outputs meet design inputs, and all validation activities have confirmed that the device meets user needs and intended use. The device is ready for market release.
**2. Verification Activities Summary**
**2.1 System Verification**
System-level verification was conducted according to the System Test Plan (STP-001) and documented in the System Test Report (STR-001). All 45 system-level test cases passed, demonstrating compliance with system requirements.
* **Electrical Safety Testing**: Passed all IEC 60601-1 requirements for electrical safety
* **EMC Testing**: Passed all IEC 60601-1-2 requirements for electromagnetic compatibility
* **Software Verification**: All 127 software test cases passed, with 2 minor anomalies documented in List of Known Anomalies
* **Performance Testing**: Heart rate accuracy within ±2 BPM across all test conditions
**2.2 Subsystem Verification**
Individual subsystems were verified according to subsystem test protocols:
* **Heart Rate Sensor Module**: Verified accuracy and response time per SSR-001 through SSR-005
* **Wireless Communication Module**: Verified data transmission reliability per SSR-006 through SSR-008
* **Battery Management System**: Verified power consumption and charging per SSR-009 through SSR-012
* **User Interface Module**: Verified display functionality and user controls per SSR-013 through SSR-015
**3. Validation Activities Summary**
**3.1 Usability Validation**
Usability validation was conducted with 15 representative users according to the Usability Evaluation Protocol (UEP-001). Results documented in Usability Evaluation Report (UER-001) show:
* **Task Success Rate**: 98% across all critical tasks
* **User Satisfaction**: Average score of 4.6/5.0
* **Use Errors**: No use errors that could lead to patient harm identified
* **Minor Improvements**: 3 minor usability improvements identified for future software updates
**3.2 Clinical Validation**
Clinical validation study with 50 participants compared device accuracy against reference standard ECG monitoring. Results documented in Clinical Validation Report (CVR-001) show:
* **Heart Rate Accuracy**: Mean absolute error of 1.2 BPM (within specification of ±2 BPM)
* **Correlation**: R² = 0.98 correlation with reference standard
* **Clinical Performance**: No clinically significant measurement errors identified
**4. Risk Management Integration**
All risks identified in Risk Assessment (RA-001) have been addressed through verification and validation activities:
* **Risk Controls Verified**: All 12 implemented risk controls verified effective through testing
* **Residual Risk Assessment**: All residual risks confirmed acceptable through validation activities
* **Risk Traceability**: Complete traceability demonstrated in Traceability Matrix (TM-001)
**5. Design Transfer Verification**
Design transfer verification confirmed that production units maintain design performance:
* **Production Verification**: First 10 production units tested and confirmed equivalent to design units
* **Manufacturing Process Validation**: All manufacturing processes validated per Manufacturing Validation Report
* **Quality Control Verification**: Production quality controls verified effective
**6. Outstanding Issues**
Three minor issues identified during validation activities:
1. **Battery Life Display**: Minor improvement needed in battery life estimation algorithm (planned for v1.1)
2. **Bluetooth Connectivity**: Occasional connection delays in high-interference environments (acceptable per risk assessment)
3. **User Manual Clarity**: Two sections identified for improvement in next revision
**7. Conclusion**
Based on comprehensive verification and validation activities, the FitHeart Wearable Monitor has been demonstrated to meet all design requirements and user needs. All verification test cases passed, validation activities confirmed user need fulfillment, and risk management activities demonstrate acceptable residual risk. The device is ready for market release with the identified minor improvements planned for future software updates.
## Q\&A
Verification demonstrates that your design outputs meet your design inputs (requirements), while validation demonstrates that your device meets user needs and intended use. Verification asks "did we build it right?" while validation asks "did we build the right thing?"
System testing serves as both verification and validation. Document test plan execution, pass/fail status with justifications, and how any failures were addressed. Reference specific test reports and ensure traceability to requirements.
Document all failures, analyze root causes, implement corrective actions (design changes, additional testing, etc.), and re-test to demonstrate compliance. All failures must be resolved before concluding that V\&V is complete.
The report should provide sufficient detail to demonstrate completeness without repeating all test data. Reference specific test reports and protocols, summarize key results, and provide clear conclusions about device readiness.
Some testing activities can serve both purposes, but you must clearly identify which requirements are being verified and which user needs are being validated. System testing often serves both functions when properly designed.
Document verification that production units perform equivalently to design units used in V\&V testing. Include manufacturing process validation results and confirmation that quality controls maintain design performance.
# Overview
Source: https://docs.withdovetail.com/todo/overview
Stay on top of your tasks with FormlyAI's Todo system.
The Todos is a list of all documents where you have to:
* **Assign** approvers
* **Approve** the document
After you generate a **new** or **revised** document or were **assigned** as an approver the work item will automatically appear in your To-Do list.
# Integrations and MCP Connections
Source: https://docs.withdovetail.com/user-settings/integrations-and-mcp-connections
How to connect integrations and add MCP servers.
Integrations allow the software and agent to work with third-party tools you use.
## Open Integrations
1. In Formly, open **User Settings**.
2. Go to **Integrations**.
3. Review the available built-in integrations and MCP connections.
## Built-In Integrations
Formly currently shows built-in cards for:
1. GitHub
2. Linear
3. Jira
4. Atlassian MCP
5. Slack
Depending on the integration, you can connect, disconnect, test the connection, or control **Agent Access**.
For information on connecting Formly's own first-party MCP server, see [MCP Server](/formly-for-ai/mcp-server).
## Add a Custom MCP Connection
1. Click **Add Integration**.
2. Enter a **Connection Name**.
3. Enter an **MCP Server URL** that starts with `https://`.
4. Leave **Access Token** empty to use OAuth, or provide a token for a manual bearer-token connection. We recommend using OAuth.
## Atlassian MCP Setup
Use the built-in **Atlassian MCP** card when you want to connect to Atlassian's hosted MCP server.
Before you click **Connect** in Formly, make sure your Atlassian admin has allowed our Formly callback domain:
1. Open `https://admin.atlassian.com`
2. Select your Atlassian organization
3. Go to **Apps -> AI settings -> Rovo MCP server**
4. Click **Add domain**
5. Add the Formly domain that receives the OAuth callback: `https://api.formly.ai/**`
## Manage Existing MCP Connections
For each MCP connection card, you can:
1. Run **Test**
2. Disconnect the connection
3. Toggle Agent Access to control whether the third-party system should be available to the agent. This allows you to control the number of tools available to the agent. We generally recommend only enabling the integrations you need for a specific task and disabling them if not needed.
## Troubleshooting
If an MCP connection fails:
1. Confirm the MCP URL is valid and starts with `https://`
2. Retry the OAuth flow and make sure popup windows are not blocked
3. Verify the provider account, permissions, and callback setup
4. For Atlassian MCP, confirm the callback domain is allowed in **Atlassian Administration -> Apps -> AI settings -> Rovo MCP server**
If the OAuth flow succeeds but the card does not update, refresh **User Settings** and retry once.
# Lists
Source: https://docs.withdovetail.com/wizard/lists
How to edit lists in the wizard.
If your task requires a detailed list (e.g. Approved Supplier List) the wizard will create a drop down menu with the required inputs.
## Adding Items
Click the **"Add new item"** button located below your list.
Enter all the required information for your new item.
Click the **"Create"** button to finalize and save your item.
![Create Item]()
If you don't click the **"Create"** button, the item will be lost when you leave the wizard or generate the document.
## Deleting Items
To **delete** an item click the three dots on the right side of the item and select **"Delete"**
# Overview
Source: https://docs.withdovetail.com/wizard/overview
The wizard guides you through each document and offers automatically generated suggestions.
## Suggestions
The controls in the **top right corner** of the Suggestions box allow you to:
* Regenerate the suggestions
* Copy the suggestions to the clipboard
* Upload a csv file
To **edit** the suggestions, you have to **Apply** them first and then conduct your edits in the **Answer box**
## Controls
The **progress bar** in the top left corner of the wizard shows you the **amount of steps** required for this task.
Once you provide an answer or apply the suggestion, the corresponding section of the progress bar will turn **green**.
The progress bar is also helpful to **jump** between sections.
To **navigate back and fourth** between the sections use the navigation arrows in the top right corner
![Navigation]()
# Tables
Source: https://docs.withdovetail.com/wizard/tables
If your task requires a table (e.g. Risk Assessment Table) the wizard will create a table with the required inputs.
## Add Rows
To add an additional row click **"Add new row"** right below your table.
## Remove and Insert Rows
**Right clicking** a row allows you to:
* **Delete** the selected row
* **Insert** row below
## Table Controls
* Undo
* Redo
* Regenerate the table
* Upload a csv file
* Copy the table to the clipboard
## Export and Import
### Export
To export the table click on the **"copy"** icon in the top right corner to copy the table to the **clipboard**. You can then paste the content into you desired **csv editor**.
### Import
To import a table:
* Save your table as a **csv file**
* Click the **"upload"** icon in the top right corner of the table
* Select the csv file
The **number and titles** of the columns in the uploaded file **must match** the table in the wizard.