diff --git a/DIN EN 62304/checklist-software-release.md b/DIN EN 62304/checklist-software-release.md new file mode 100644 index 0000000..e02ac28 --- /dev/null +++ b/DIN EN 62304/checklist-software-release.md @@ -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:
Stakeholder requirements can be traced to software requirements.
Software requirements can be traced to system tests.
Software requirements can be traced to software code implementation / software code reviews.
Software requirements can be traced to risks and risk control measures.
Stakeholder requirements can be traced to usability tests.
Hazard-related use scenarios can be traced to usability tests.
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. diff --git a/DIN EN 62304/checklist-software-requirements-review.md b/DIN EN 62304/checklist-software-requirements-review.md new file mode 100644 index 0000000..2a9cb55 --- /dev/null +++ b/DIN EN 62304/checklist-software-requirements-review.md @@ -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 + +\ + +# 4. Result + +[ ] Software Requirements passed\ +[ ] Software Requirements not passed\ +[ ] Software Requirements passed with the following obligations: \\ + +--- + +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. diff --git a/DIN EN 62304/list-of-known-anomalies.md b/DIN EN 62304/list-of-known-anomalies.md new file mode 100644 index 0000000..1a68ced --- /dev/null +++ b/DIN EN 62304/list-of-known-anomalies.md @@ -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. diff --git a/DIN EN 62304/software-requirements-list.md b/DIN EN 62304/software-requirements-list.md new file mode 100644 index 0000000..030dd16 --- /dev/null +++ b/DIN EN 62304/software-requirements-list.md @@ -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. diff --git a/DIN EN 62304/software-system-test-plan.md b/DIN EN 62304/software-system-test-plan.md new file mode 100644 index 0000000..41e9255 --- /dev/null +++ b/DIN EN 62304/software-system-test-plan.md @@ -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
2. Enter password atari
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
2. Enter password butterfly
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. diff --git a/DIN EN 62304/sop-deployment.md b/DIN EN 62304/sop-deployment.md new file mode 100644 index 0000000..2d6f8fb --- /dev/null +++ b/DIN EN 62304/sop-deployment.md @@ -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: + +\ 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. diff --git a/DIN EN 62304/soup-list.md b/DIN EN 62304/soup-list.md new file mode 100644 index 0000000..98928e9 --- /dev/null +++ b/DIN EN 62304/soup-list.md @@ -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.