compliance/tech-file
4
0
Fork 0
Code Pull Requests Packages Projects Releases Wiki Activity

...

Browse Source
This commit is contained in:
René Herzer 2022-12-23 13:43:55 +01:00
parent 9303ed9bad
commit 7e87e51d88
7 changed files with 418 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
DIN EN 62304/checklist-software-release.md Normal file
View File

@ -0,0 +1,52 @@
# Checklist: Software Release
| Classes | IEC 62304:2006 Section | Document Section |
| ------- | ---------------------- | ---------------- |
| A, B, C | 5.8.1 | (All) |
| A, B, C | 5.8.2 | (All) |
| A, B, C | 5.8.3 | (All) |
| A, B, C | 5.8.4 | (All) |
| B, C | 5.8.5 | (All) |
| B, C | 5.8.6 | (All) |
| A, B, C | 5.8.7 | (All) |
## Summary
This checklist is used to verify that documentation and activities are complete before releasing a new version of the product.
> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The main point is that, at minimum, the items below should be checked (and documented) before you release a new version of your software.
> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty much the bare minimum to be 62304-compliant.
## Checklist
The following documents are up to date:
> The table below shows examples only. Add - or reference - a list of all your required TechDoc records.
| Item | Yes | No | Comment |
| ---- | --- | --- | ------- |
| Device Description | | | |
| Clinical Evaluation | | | |
| Declaration of Conformity | | | |
| (...) | | | |
The following activities have been performed:
| Item | Yes | No | Comment |
| ---- | --- | --- | ------- |
| All relevant functionalities of the software have been specified; the Software Requirement List is complete and has been reviewed. | | | |
| All relevant risks (including risks of known anomalies) have been evaluated; the Risk Management Report is complete. | | | |
| Verification (as software system testing) has been completed. | | | |
| Design control traceability is ensured:<br>Stakeholder requirements can be traced to software requirements.<br>Software requirements can be traced to system tests.<br>Software requirements can be traced to software code implementation / software code reviews.<br>Software requirements can be traced to risks and risk control measures.<br>Stakeholder requirements can be traced to usability tests.<br>Hazard-related use scenarios can be traced to usability tests.<br>Hazard-related use scenarios can be traced to risks and risk control measures. | | | |
| A version number as defined in the Software Development Plan has been assigned and added as a tag to git. | | | |
| Software is registered with a Notified Body. | | | |
| If release includes substantial change: Notified Body has been informed. | | | |
| Label is applied correctly including CE marking. | | | |
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

50
DIN EN 62304/checklist-software-requirements-review.md Normal file
View File

@ -0,0 +1,50 @@
# Checklist: Software Requirements Review
| Classes | IEC 62304:2006 Section | Document Section |
|---------|------------------------|------------------|
| A, B, C | 5.2.6 | (All) |
| ISO 13485:2016 Section | Document Section |
|------------------------|------------------|
| 7.3.3 | (All) |
| 7.3.5 | (All) |
## 1. Summary
This checklist is used to review (verify) software requirements prior to implementation.
> As with all regulatory documents, it's more about the content than about the tool. You don't have to fill
> this checklist out every time in Word / GDocs / etc., but could embed it in your Jira / GitHub workflow. The
> main point is that, at minimum, the items below should be filled out before you start implementing software
> requirements.
> Feel free to add further rows in the checklist if they make sense for your company. This template is pretty
> much the bare minimum to be 62304-compliant.
## 2. Checklist
| Software Requirements... | Yes | No | Comment |
|-------------------------------------------------------------------------------|-----|----|---------|
| are traceable to design input or risk control measures. | | | |
| are complete. | | | |
| are understandable, uniquely identifiable and do not contradict each other. | | | |
| include user interface requirements (mockups, wireframes, etc.), if relevant. | | | |
| include IT security requirements, if relevant. | | | |
| are testable and include acceptance criteria. | | | |
# 3. Comments
\<Insert comments if applicable\>
# 4. Result
[ ] Software Requirements passed\
[ ] Software Requirements not passed\
[ ] Software Requirements passed with the following obligations: \<Insert if applicable\>\
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

23
DIN EN 62304/list-of-known-anomalies.md Normal file
View File

@ -0,0 +1,23 @@
# List of Known Anomalies
> This template is supposed to give you an idea of the structure. Don't use Microsoft Word - this is thought
> as an excel / sheets file.
This list shows technical errors ("bugs") of the current device which were decided not to be corrected before the
release of the latest version.
It, therefore, serves as an overview and as a documentation of reasoning for non-correction.
## Anomalies
| Title | Description | Impact / Hazard | Discovery (Date, How, By Whom) | Proposed Correction | Justification for Delay | Timeline |
|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|------------------------------------|-----------------------------------------------------------------------------------------------------------------|----------------------|
| Default language | If the app is installed on a smartphone with unsupported language, the default language is German. Users then have to navigate to the language settings for changes. | Users in countries with unsupported language are likely not German-speaking and may not be able to use the app without changing language settings. | 2022-04-01 during usability testing by Product Manager | Change default language to English | Per appstore setting, the app is currently only available in countries whose predominant language is supported. | Next version release |
| (...) | (...) | (...) | (...) | (...) | (...) | (...) |
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

56
DIN EN 62304/software-requirements-list.md Normal file
View File

@ -0,0 +1,56 @@
# Software Requirements List
> This document is related to your product. You somehow need to associate it with it. The easiest way would be
> to just put all product-related documents into a folder in your QMS so that the association is
> clear. Alternatively, you could mention the related product and version here, but then you'd have to update
> the version here any time you do a new release. Painful!
> This is a list of your software requirements. If you have multiple software systems (you probably have a
> backend and a frontend), you can use the "Software System" column. The categories are the 62304 categories
> from section 5.2.2. *Risk Control Measure?* is just a yes/no field. And the related risk IDs refer to the
> risk IDs from your risk table.
> Of course, you could also use your own tool like Jira or GitHub issues. Just ensure that the content (i.e.,
> the columns shown here) is roughly the same.
## Mapping of Standard Requirements to Document Sections
| Classes | IEC 62304:2006 Section | Document Section |
|---------|------------------------|------------------|
| A, B, C | 5.2.1, 5.2.2, 5.2.3 | 1 |
| ISO 13485:2016 Section | Document Section |
|------------------------|------------------|
| 7.2.1 | (All) |
| 7.3.3 | (All) |
| IEC 62366-1:2015 Section | Title | Document Section |
|--------------------------|------------------------------------------------------------------------------------|------------------|
| 5.2 | Identify User Interface characteristics related to Safety and potential Use Errors | 1 |
| 5.6 | Establish User Interface Specification | 1 |
## 1. Software Requirements
> While the 62034 "only" requires you to document Software Requirements, the 13485 also wants you to document
> higher-level customer requirements. You could solve that by having a two-stage hierarchy of requirements: On
> the first level, you'd have user stories (= the 13485 customer requirements), and beneath that, for each
> user story, you'd have more technical specifications (= 62304 software requirements).
> There's no great way to display this in a table, so for now, this table only solves the problem of defining
> software requirements. Feel free to create a second table for user stories, or just cram them into this one
> (good luck).
| ID | Software System | Category | Description | Risk Control Measure? | Related Risk IDs |
|----|-----------------|----------------|------------------------------------|-----------------------|------------------|
| 1 | App | Functional | On first launch, show introduction | No | |
| 2 | App | User Interface | Use user locale (language) | No | 1 (Risk ID) |
| 3 | App | Functional | Average CPU usage < 2% | No | |
| 4 | Backend | Security | Store passwords as hashes | Yes | |
| 5 | Backend | Interface | Expose a REST API, handle JSON | No | |
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

23
DIN EN 62304/software-system-test-plan.md Normal file
View File

@ -0,0 +1,23 @@
# Software System Test Plan
> `SR ID` refers to the ID of the software requirement which is tested by this test.
> Note that this is, strictly speaking, not a "plan" because it already includes the results (columns "Actual"
> and "Pass?"). To keep things clean, I'd suggest splitting this table up into a "plan" and a "protocol"
> (suggestion by a friendly auditor). The plan contains all columns below except "Actual" and
> "Pass?". The protocol contains all columns. The idea is this: It makes sense to write the plan before
> actually doing the testing. You don't want to be changing the test steps when you notice your tests are
> failing (surely nobody would do that). So you write the plan first, finalize it, then copy-paste it to a
> protocol in which you enter the results after you've done your tests.
| ID | SR ID | Description | Steps | Expected | Actual | Pass? |
|----|-------|------------------------------------------------|--------------------------------------------------------------------------------|---------------------------------------|-----------------------------|-------|
| 1 | 1 | Login with correct email and password succeeds | 1. Enter email steve@apple.com<br>2. Enter password atari<br>3. Click login | Redirect to account page | Redirect to account page | Pass |
| 2 | 1 | Login with incorrect email and password fails | 1. Enter email jony@apple.com<br>2. Enter password butterfly<br>3. Click login | Error "invalid credentials" displayed | Error "invalid credentials" | Pass |
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

160
DIN EN 62304/sop-deployment.md Normal file
View File

@ -0,0 +1,160 @@
# 1. General Information
This SOP describes how we support the initial integration and update of integrations of our medical devices
into the IT systems of our customers. Furthermore, it covers user management and user training. By following
this process, we want to make sure that our customers receive our medical devices or services the intended
way.
> Obvious disclaimer!
>
> The deployment process should be very much customized to the context of your specific product. Are you
> deploying your product web-based? Are you integrating with local healthcare providers' IT systems? Depending
> on those questions, you will have to write each single process step of this template. Sorry to disappoint
> you! Hope the structure helps you at least to get an idea of the regulatory requirements.
**Regulatory references:**
* ISO 13485:2016 Chapter 7.5
**Relevant other documentation:**
* Integration Evaluation Checklist (IECL)
* Integration Validation Checklist (IVCL)
* Software Requirement Specifications
* List of Medical Devices (PROD)
* User Training Strategy
* Template User Training Record
* User Consent Form (if applicable)
## 1.1. Integration Specifications
Integration Specifications are the technical requirements defined in the instructions for use as part of the
technical documentation of medical devices.
## 1.2. Integration Checklists
The Integration Specifications are used to compile the Integration Evaluation Checklist. It is ensured that we
do not offer medical devices or services which cannot be delivered by filling out this checklist, for which
the Operations Team Representative is responsible. We fill out the Integration Validation Checklist after
concluding integration work in order to validate if all technical requirements for successful integration have
been completed.
## 1.3. Device Traceability
The operations team ensures that only released device versions are deployed to the customer
environment. Deployment of device versions is documented as part of the medical device list. This file must
contain at minimum:
* Use description (e.g. clinical use, test, etc.)
* Device description (e.g. device version, UDI, release date, identification number of the NB acc. to CE
certificate)
* Company and contact data to a responsible person, deployment location
## 1.4. Project Management Tool
Optional:
\<enter name\> is used as the project management tool to coordinate integration work.
# 2. Process Overview
## 2.1. Evaluation of Integration Requirements per Customer
> Possible contents of this process step:
>
> * Following the draft of an offer / contract with a customer, the sales team reaches out to the technical
> operations team to evaluate if technical requirements are met.
> * In coordination with competent staff on the customer’s side, the technical operations team gathers
> relevant information to fill out the integration evaluation checklist.
> * If evaluation output does not allow for integration, the Operations team assesses other integration
> possibilities or recommends to not further pursue the customer contract.
> * The operations team communicates the result of the evaluation to the sales team.
(...)
## 2.2. Integration Coordination
> Possible contents of this process step:
>
> * Following integration evaluation and the conclusion of a new customer contract, the operations team is
> responsible to coordinate overall integration efforts.
> * The operations team communicates to the customer (technical department) appropriate technical information
> and guidance for the integration.
> * If integration problems occur, the operations team is responsible to (a) amend the integration evaluation
> checklist in order to prevent similar problems with future customers. (b) initiate the change management
> process in case the medical device itself needs to be changed.
> * Successful integration is validated by filling out the integration validation checklist. The operations
> team obtains written confirmation of the customer setup after integration.
> * The operations team informs the sales team once integration is complete. It documents the deployment date,
> deployed version of the device and customer information as part of the medical device list.
(...)
## 2.3. Algorithm Deployment and Configuration
> Optional for ML-driven devices: after integration and before go-live, test the algorithm on
> customer-specific live data (e.g. in the form of a “shadow mode” where algorithm results are not used in the
> clinical setting yet). Evaluate the results together with users.
(...)
## 2.4. User Administration
> Possible contents of this process step:
>
> * The operations team is responsible to activate users accounts according to the customer contract.
> * No user account is activated without / before
> * Specification in the customer contract (e.g. number of seats?)
> * Full completion of previous process steps (e.g. algorithm test)
> * Optional to add here: user consent according to GDPR?
(...)
## 2.5. User Training
> Possible contents of this process step:
>
> * The operations team is responsible to provide users with the instructions for use / user manual. If not
> part of the device, provision via email is sufficient.
> * The operations team conducts user training as defined in the user training strategy and documents every
> training in the template for user training records.
> * The operations team informs the sales and regulatory team about successfully completed training.
(...)
## 2.6. Handling of Feedback
In case the operations team receives feedback (questions, complaints, praise, etc.) regarding the
organization’s medical devices and services, it proceeds as outlined in the SOP feedback management.
## 2.7. Handling of Updates
> Possible contents of this process step:
>
> * In case of a version update, the operations team verifies if the integration requirements change due to
> the update and, if necessary, implements changes accordingly.
> * The operations team coordinates updates with the customer prior to deployment and, if applicable, notifies
> the customer of potential product downtime according to the timeframe stated in customer contracts.
> * After deployment, the latest deployed version is documented in the medical device list.
(...)
## 2.8. Handling of Terminated Contracts
> Possible contents of this process step:
>
> * The sales team notifies the operations team in case of a terminated contract. Thereafter, the operations
> team is responsible for deactivating respective user accounts.
> * The medical device list is updated accordingly.
> * If required, the operations team is responsible to support the customer with necessary data migration and
> archives data related to the respective customer according to GDPR requirements (reference privacy policy
> or similar here).
(...)
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.

54
DIN EN 62304/soup-list.md Normal file
View File

@ -0,0 +1,54 @@
# SOUP List (Software of Unknown Provenance)
> The 62304 requires you to document your SOUP, which is short for Software of Unknown Provenance. In human
> language, those are the third-party libraries you're using in your code, typically in your
> `requirements.txt` or `Gemfile`.
| Classes | IEC 62304:2006 Section | Document Section |
|---------|-------------------------------------------------|------------------|
| B, C | 5.3.3 (Functional and Performance Requirements) | 2 |
| B, C | 5.3.4 (Hardware and Software Requirements) | 2 |
| B, C | 7.1.2 (Hazardous Situations) | 2 |
| B, C | 7.1.3 (SOUP Anomaly Lists) | 2 |
| A, B, C | 8.1.2 (Identify SOUP) | 2 |
## 1 Risk Level Definitions
> The 62304 requires you to assess risks associated with SOUP. The simplest way to do this is to classify each
> SOUP as a certain risk level. Unless you're developing software which shoots radiation at patients, it's
> likely that your SOUP risk levels remain "low" or "medium".
| Risk Level | Definition |
|------------|------------------------------------------------------------|
| Low | Malfunction in SOUP can't lead to patient harm. |
| Medium | Malfunction in SOUP can lead to reversible patient harm. |
| High | Malfunction in SOUP can lead to irreversible patient harm. |
## 2 SOUP List
> This is the actual SOUP list. For each third-party library you use, add an entry in the table below. The
> idea is to only have one "global" SOUP list for your medical device even though the code may actually live
> in multiple repositories. That's what the "software system" column is for; you could also mention your (git)
> repository there.
> When specifying requirements, the 62304 requires you to mention functional, performance, hard- and software
> requirements. However, you may not have to re-state certain requirements if they apply to all SOUP,
> e.g., "runs on Linux". So prefer to keep the requirements simple, in a way in which you would communicate them
> to colleagues on your development team when answering the question "why did we import this library?".
> As with all templates: It's more about the content (i.e., the columns you see below) than the tool (filling
> this out in Google sheets / markdown / wherever). Nobody says that you have to maintain this as a Google
> sheet. If you can find a way to integrate this in your workflow in a better way, e.g., in a markdown file in
> your git repository, go for it! Just keep in mind that you need to be able to export it to send it to
> auditors.
| ID | Software System | Package Name | Programming Language | Version | Website | Last verified at | Risk Level | Requirements | Verification Reasoning |
|----|-----------------|--------------|----------------------|---------|--------------------------------------------------|------------------|------------|----------------------------|---------------------------------------------------------------------------|
| 1 | Mobile App | react-native | JavaScript | 0.61 | [Link](https://facebook.github.io/react-native/) | 23.10.2020 | Low | * Runs JS on Android / iOS | Commonly used, maintained by a large organisation, sufficient test coverage |
---
Template Copyright [openregulatory.com](https://openregulatory.com). See [template
license](https://openregulatory.com/template-license).
Please don't remove this notice even if you've modified contents of this template.