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

cleanup, updated links etc. #1

Merged
markus merged 1 commits from 1.0 into main 2023-11-04 19:57:32 +00:00
Conversation 0 Commits 1 Files Changed 17 +18 -1329
17 changed files with 18 additions and 1329 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit e23d73c372 - Show all commits

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

@ -1,52 +0,0 @@
# 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
View File

@ -1,50 +0,0 @@
# 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.

73
DIN EN 62304/document-roadmap.md
View File

@ -1,73 +0,0 @@
# Document Roadmap TechDoc
This is a proposed roadmap to creating the TechDoc file. The documents are grouped by "Design Phase". To each
document, a responsible person is assigned as the author. Go through the list phase by phase. You can mix up
the order of documents within a phase, but I recommend to finalize documents from one phase before moving on
to the next.
### PHASE 1: Planning & Feasability
| Document | Author | Comment |
|-------------------------------------------------|-------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Intended Use | CEO | This is the most important document of your TechDoc. Business and Regulatory Strategy depend on it. |
| Medical Device Classification | QA/RA Manger | Defining the product's medical device classification acc. to MDR. |
| Product Roadmap | Product Manager | Not an essential document. This is for feasibility assessments and resource planning. Helps to keep track of what's to come. |
| Software Development and Maintenance Plan | Software Developer | Giving product-specific information on the tools, resources and methods to be used for software development. Helpful for developer teams to align regarding the development setup. |
| Change Evaluation List | QA/RA Manger | Listing and assessing gaps between the last and the upcoming software version. Follows criteria from MDCG 2020-3. Not needed for the very first release. |
| Risk Management Plan and Risk Acceptance Matrix | Risk Manager | Specifies the methods for assessing risks to be used for the product at hand. Defines probability and severity categories and acceptable ranges. |
| Clinical Evaluation Plan | Clinician / Scientific Person | Specifying the methodology that shall be used to assess the clinical benefits and risks of the product. |
### PHASE 2: Specification
| Document | Author | Comment |
|--------------------------------------|--------------------------------------|------------------------------------------------------------------------------------------------------------|
| User Needs List | Product Manager | This is a list of high-level requirements. Most of them will be implemented through Software Requirements. |
| User Needs Checklist | QA/RA Manager | Checking if the User Needs List makes sense. |
| Software Requirements List | Developer-adjacent person | Specifying how User Needs will be incorporated in the software. Describing the details of a feature. |
| List of Hazard-Related Use Scenarios | Risk Manager | Identifying scenarios in which users could be prone to hazards. |
| Risk Table | Risk Manager | Anticipating and assessing risks. Gathering input from various channels. |
| Software Requirements Checklist | QA/RA Manager | Checking if the Software Requirements List makes sense. |
| Software Test Plan | Software Developer | Defining tests for every Software Requirement and mapping them to each other. |
| Usability Test Plan | Product Manager / Usability Engineer | Specifying the methodologies to be used to conduct the Usability Test. |
### PHASE 3: Development
| Document | Author | Comment |
|-----------------------|--------------------|-----------------------------------------------------------------------------------------------------------------|
| SOUP List | Software Developer | List of external libraries, frameworks and packages used in the product, incl. their assessment of criticality. |
| Software Architecture | Software Developer | Description/Graphic outlining the software components and their interaction. |
The actual programming work takes place in this phase. It makes sense to create the SOUP list and the software
architecture immediately before programming begins and to adjust them if anything changes during code
creation. These documents should actually be created in advance, but due to the iterative nature of software
development, it will not be possible to plan everything before the actual work begins. Therefore, it makes
sense to create them in parallel with the programming.
### PHASE 4: Verification and Validation
| Document | Author | Comment |
|----------------------------|--------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Software Test Results | QA Tester | Results of the Software Tests: passed or failed? |
| List of Known Anomalies | Software Developer / Product Manager | List of known bugs and failed software tests. Justification why the software can still be released without impacting benefit/safety and a timeline when those bugs will be fixed. |
| Instructions For Use | Person with the best overview | The name says it all. |
| Usability Test Protocol | Product Manager / Usability Engineer | Specifying the actual usability test cases: Testing User Needs, Hazard-Related Use Scenarios and Instructions for Use. |
| Usability Test Report | Product Manager | Summary of the results of the Usability Test. |
| Clinical Evaluation Report | Clinician / Scientific Person | Analysing scientific data to prove the products safety and efficacy. |
| Risk Management Report | Risk Manager | Summary of the Risk Management Activities |
### PHASE 5: Product Release
| Document | Author | Comment |
|----------------------------|---------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| GSPR List | QA/RA Manager | Checking if the "General Safety and Performance Requirements" are fulfilled. |
| PMS (/PMCF) Plan | QA/RA Manager | Planning the product-specific activities for Post-Market Surveillance. If the clinical data is not sufficient, also plan Post-Market Clinical Follow-Up activities. |
| Software Release Checklist | QA/RA Manager | Checking if all the requirements are fulfilled, if the documents are complete and if the product is safe to be used. |
| Release Notes | Product Manager OR Software Developer | Description of new features in the current release. |
| Declaration of Conformity | QA/RA and CEO | Declaring the product's conformity with the regulations and standards. |
---
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.

123
DIN EN 62304/instructions-for-use.md
View File

@ -1,123 +0,0 @@
| ISO 13485:2016 Section | Document Section |
|------------------------|------------------|
| 4.2.3 | (All) |
# User Manual [enter Product Name]
Version: [enter content]
Date: [enter content]
[Placeholder Company Address]
Email: [enter content]
Website: [enter content]
[Placeholder CE Sign]
[Placeholder UDI]
[enter Product Name] is a class [enter content] medical device in accordance with 93/42/EEC (for MDD) // Regulation (EU) 2017/745 (for MDR).
UMDNS Code: [enter content]
Symbols:
Safety Information:
[Placeholder Symbol]
This symbol indicates important safety-related information.
Additional Information:
[Placeholder Symbol]
This symbol indicates supplementary information.
> On your introductory pages, explain the symbols that you use in the following sections. Take into account standards like ISO 15223.
> **General Provisions:** Instructions for use are regulated in Section 13 of the Essential Requirements (MDD) and Chapter 3, Section 23 of the General Safety and Performance Requirements (MDR). You may be able to make a case for why your users must not be provided with instructions for use, based on the exception stated in Section 13.1 (MDD) or Section 23.1.d (MDR):
>
> "By way of exception, no such instructions for use are needed for devices in Class I or IIa if they can be used safely without any such instructions."
>
> **Language Requirements:** Language requirements are regulated on the national level. German Medical Device Law (Medizinprodukte-Durchführungsgesetz (MPDG), Art. 8) typically requires German, but also gives leeway to argue that English may be a language that is easily understood by your users if those are trained professionals. If you follow this route, as a minimum requirement, all safety-related information has to be provided in German nevertheless:
>
> "In begründeten Fällen dürfen die Informationen auch in englischer Sprache oder einer anderen für den Anwender des Medizinproduktes leicht verständlichen Sprache zur Verfügung gestellt werden, wenn diese Informationen ausschließlich für professionelle Anwender bestimmt sind und die sicherheitsbezogenen Informationen auch in deutscher Sprache oder in der Sprache des Anwenders zur Verfügung gestellt werden."
>
> https://www.gesetze-im-internet.de/mpdg/MPDG.pdf
## Product Description
### Intended Medical Indication
> You can basically copy/paste your intended use document here and in the sections below. This paragraph should include high-level information required to get an idea of how your product works.
> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by your software.
> Take into account: clinical benefits to be expected, types of processed data, types of data processing (or machine learning based devices: information about algorithm accuracy).
### Characterization of User Profile
> Describe your users: what level of education can be assumed for your users group? Any pre-existing knowledge of the field that your device is used in?
> What technical proficiency can be assumed, how much time is typically spent using the software?
> If you plan on providing user training prior to product use, make sure to also add a description of that here.
### Characterization of Patient Population
> Describe the patient population your software is intended to be used on. Note that this may overlap with the user profile above, but not necessarily.
> Your software could be used by physicians to diagnose diseases in patients, so in that case, they don’t overlap. Some ideas for characteristics to describe: Age group, weight range, health, condition(s).
### Characterization of Use Environment Including Software / Hardware
> Describe the typical use environment. What sort of devices is this running on? Does the software only run on one device or on multiple devices? Is it loud and chaotic like in an emergency ward? How’s the lighting?
> Also, add other software or hardware which is required by your device. Most commonly, apps require users to have a smartphone with a compatible operating system (iOS / Android).
### Exclusions
> This is an important section for your company liability: make clear the environment your device should NOT be used in, by whom should your device NOT be used?
## Safety Information
### Contraindications
> More exclusions, more specific to safety risks and clinical implications. For example, does your device automate medical diagnoses? If not, you may want to point out that all results must be checked thoroughly by a qualified physician.
### Warning and Remaining Risks
> You can use this section to point out user information as required for risk mitigation measures. For example, specific information that must be checked for accuracy or completeness to operate the device.
## Language
> Self-explanatory: what languages, what language settings are offered for your product?
## System Requirements
### Hardware
> What hardware configuration is required to run your device (e.g. minimum requirements for processor, display, network bandwidth)?
### Software
> What software configuration is required (e.g. latest browser version)?
### IT-security Measures
> What is required to prevent unauthorized access? How do users prevent data loss? Describe for example firewall settings, VPN setup, etc.
## Installation
> Describe: Is any IT integration required prior to use? How is a successful installation verified? How are login credentials dealt with?
## Safety and Maintenance
> Consider multiple sub-sections here: how do you plan to deploy frontend / backend updates? How can users report malfunctions, clinical incidents, lost passwords or a potential security breach?
Other aspects you may want to consider for the section as part of your instructions for use:
* Using the software: walkthrough guide to explain functionalities including screenshots and links to helpful websites
* Description of the algorithm for machine-learning based medical devices
* Description of alternative devices or services
---
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
View File

@ -1,23 +0,0 @@
# 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.

169
DIN EN 62304/post-market-surveillance-plan.md
View File

@ -1,169 +0,0 @@
# Post-Market Surveillance Plan
This plan describes product-specific post-market surveillance activities. The general process of how to do
post-market surveillance is described in SOP Post-Market Surveillance. Its outputs are saved to the
Post-Market Surveillance Report.
## Product
| Product Name | Version | Surveillance Period |
|-------------------------|---------------|----------------------------|
| *\<your product name\>* | *\<version\>* | *\<e.g. 10/2020-10/2021\>* |
## 1. General Considerations
> Note: Whatever kind of post-market surveillance activities you define for your product, make sure to map at
> minimum all of these actions required by the MDR to one activity in section 2 below.
According to Annex III section 1.1 (b) MDR, the post-market surveillance plan shall cover:
| MDR Requirement | Activity |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|
| A proactive and systematic process to collect any information referred to in point (a). The process shall allow a correct characterisation of the performance of the devices and shall also allow a comparison to be made between the device and similar products available on the market | |
| Effective and appropriate methods and processes to assess the collected data; | |
| Suitable indicators and threshold values that shall be used in the continuous reassessment of the benefit-risk analysis and of the risk management as referred to in Section 3 of Annex I; | |
| Effective and appropriate methods and tools to investigate complaints and analyze market-related experience collected in the field; | |
| Methods and protocols to manage the events subject to the trend report as provided for in Article 88, including the methods and protocols to be used to establish any statistically significant increase in the frequency or severity of incidents as well as the observation period; | |
| Methods and protocols to communicate effectively with competent authorities, notified bodies, economic operators and users; | |
| Reference to procedures to fulfill the manufacturers obligations laid down in Articles 83, 84 and 86; | |
| Systematic procedures to identify and initiate appropriate measures including corrective actions; | |
| Effective tools to trace and identify devices for which corrective actions might be necessary; | |
| A PMCF plan as referred to in Part B of Annex XIV, or a justification as to why a PMCF is not applicable. | |
## 2. Data Collection Activities
> Note: In the "Metric / Threshold" column there's a placeholder "(define)". Replace this with the metric and
> threshold you've decided upon.
| Activity | Assigned To | Metric / Threshold | How Often? |
|--------------------------------------------------------------------------------------------------------------|------------------------------|--------------------|-------------------------------|
| Incident documentation and analysis of undesirable side effects | QMO | (define) | 1/year on Jan 1st |
| Assess feedback (customer complaints, sales feedback) | Head of Product | (define) | 1/year on Jan 1st |
| Check SOUP for new published issues | Head of Software Development | N/A | 2/year on Jan 1st and Aug 1st |
| Research data about similar products in the market | QMO | (define) | 1/year on Jan 1st |
| Conduct post-market clinical follow-up activities as planned | Head of Medical Team | | |
| Research scientific publications | Head of Product | | |
| Research updates of standards and legislation | QMO | | |
| Analyze trends, decide on necessary measures and implement them | QMO | | 1 /year |
| Update risk management file | QMO | | |
| Compile post-market clinical follow-up report | Head of Medical Team | | |
| Compile Periodic Safety Update Report | Head of Product | | |
| Upload PSUR to Eudamed database | | | |
| Compile post-market surveillance plan and post-market clinical follow-up plan for next surveillance interval | | | |
## 3. Data Collection Categories
At minimum, the information required by the process for post-market surveillance is collected. For (enter
product name), the following categories of data will be collected specifically:
### Information about other devices*
* [BfArM Field Corrective Actions][bfarm-fca]
* Keywords:
* Filter:
* Time span:
* [BfArM Recommendations][bfarm-rec]
* Keywords:
* Time span:
* [MHRA][mhra]
* Keywords:
* Filter:
* Time span:
* [Swissmedic: List of recalls and other field corrective actions][swissmedic]
* Keywords:
* Time span:
* [FDA Recalls: medical device recalls][fda-recalls]
* Keywords:
* Time span:
* [FDA Maude][fda-maude]
* Keywords:
* Time span:
* SOUP Incident Reports
* Go through SOUP list
* Research public incident reports of the last (enter time span) months
> Make sure to not just update your clinical evaluation here and enter the same keywords as for the literature review.
> Also add keywords for the equivalent / similar devices you compare (such as their brand names).
### Other information about similar devices
* Google News Search
* Filter: (define)
* Time span:
* (...)
### Specialist literature / technical databases
> Note: This chapter should analyze other publications applicable to our product which are not considered
> already (or typically) as part of the post-market clinical follow-up.
* Pubmed
* Filter: (define)
* Time span: last 12 months
* (...)
### Serious incidents of our medical device
* Incident documentation
* Was the device involved in any event that caused, directly or indirectly, death of a patient, user or
other person or to a serious deterioration in their state of health? Did the company issue a recall of
the device?
* If so, attach respective documentation (e.g. field safety notices)
* Time span:
### Non-serious incidents and undesirable side effects of our own medical device
* Feedback and customer complaints
* Filter: hazard-related feedback, usability issues
* Time span:
### Feedback we collect from our partners, users, distributors, importers
* Feedback and customer complaints
* Filter: not hazard-related feedback, feedback on performance, safety or processes
* Time span:
The overall complaint rate is deemed acceptable if:
* Less than 10% of complaints are associated with moderate severity of harm or higher
* Overall number of complaints does not exceed 10% of total active users
* (...)
> Note: customize the acceptance criteria for the overall complaint rate to your setup
### Trends
* Compile a list of trends as described in the section below.
## 4. Trend Analysis
Trend analysis is performed with a focus on undesirable side-effects and non-serious incidents. These will be
monitored if they impact the benefit-risk ratio in a negative way.
Hazards in the risk table are compared to post-market surveillance results:
* If post-market surveillance leads to the finding that the estimated **probability** was too low (= event
happened more often in post-market surveillance), actions are initiated as described in the SOP Post-Market
Surveillance.
* If post-market surveillance leads to the finding that the estimated **severity** was too low (= event
happened led to more serious harm in post-market surveillance), a CAPA is initiated.
<!-- Links -->
[bfarm-fca]: https://www.bfarm.de/SiteGlobals/Forms/Suche/EN/kundeninfo_Filtersuche_Formular_en.html?nn=4527724
[bfarm-rec]: https://www.bfarm.de/EN/MedicalDevices/RiskInformation/Recommendations/_functions/_node.html
[mhra]: https://www.gov.uk/drug-device-alerts
[swissmedic]: https://fsca.swissmedic.ch/mep/
<!-- This is a great link -->
[fda-recalls]: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRES/res.cfm?start_search=1&event_id=&productdescriptiontxt=&productcode=&IVDProducts=&rootCauseText=&recallstatus=&centerclassificationtypetext=&recallnumber=&postdatefrom=&postdateto=&productshortreasontxt=&firmlegalnam=&PMA_510K_Num=&pnumber=&knumber=&PAGENUM=100
[fda-maude]: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm
---
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.

41
DIN EN 62304/software-architecture-checklist.md
View File

@ -1,41 +0,0 @@
# Software Architecture Checklist
**Regulatory references:**
IEC 62304, para. 5.3.6 [class B, C]
**Relevant other documentation:**
* SOP Software Development
* User needs / stakeholder requirements
* Design input / software requirements
* Software architecture description
* (...)
# 1. Checklist
| Criteria | Pass / Fail |
|----------------------------------------------------------------------------------------------------------|-------------------------|
| The software architecture is in agreement with the software requirements. | ( ) Yes<br>( ) Improve: |
| All software systems are listed and their respective safety class is stated. | ( ) Yes<br>( ) Improve: |
| All software components are listed and described, including interfaces. | ( ) Yes<br>( ) Improve: |
| All software units are listed and described. | ( ) Yes<br>( ) Improve: |
| (Optional) Further architecture is described, e.g. databases, security and data protection requirements. | ( ) Yes<br>( ) Improve: |
| The software architecture can be implemented with our given resources. | ( ) Yes<br>( ) Improve: |
# 2. Comments
\<Insert comments if applicable\>
# 3. Results
( ) Software Architecture passed\
( ) Software Architecture not passed\
( ) Software Architecture 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.

94
DIN EN 62304/software-architecture-description.md
View File

@ -1,94 +0,0 @@
# 1. Regulatory References
**Regulatory references:**
IEC 62304, para. 5.3.1 and 5.3.2 [class B, C]
**Relevant other documentation:**
* SOP Software Development
* User needs / stakeholder requirements
* Design input / software requirements
* (...)
# 2. Software Systems
In compliance with DIN EN 62304, we subdivide our software on three levels: software systems, software
components and software units.
> Here, describe your internal software systems. The IEC 62304 defines those as an “integrated collection of
> software items organized to accomplish a specific function or set of functions.”
>
> NOTE: Ideally, you would add an illustrating diagram to the Annex and reference it here.
## 4.1. Frontend
> Enter description, for example:
>
> * Function: user interface display
> * Software safety classification and rationale
> * Runtime
> * Deployment
> * User groups
## 4.2. Backend
> Enter description, for example:
>
> * Function: managing patient data and medical images.
> * Software safety classification and rationale
> * Runtime (e.g. JVM)
> * Deployment (e.g. Docker container)
> * User group
## 4.3. Algorithm
> Enter description, for example:
>
> * Function: taking medical images as input and output a prediction.
> * Software safety classification and rationale
> * Runtime (e.g. JVM)
> * Deployment (e.g. Docker container)
> * User group
# 6. Software Units
> Describe your internal software units. The IEC 62304 defines those as a “software item [any identifiable
> part of a program, i.e. source code, object code, control code, control data, etc.] that cannot be
> subdivided into other items”. For example:
>
> * Wearable device poller (regularly checks whether wearable device has new data and downloads it)
> * Notification service (sends messages to Apple / Google for push notifications of mobile apps)
> * (...)
# 7. Database
> Describe your databases. For example:
>
> * Relational database: Postgres v14
# 8. IT Security
## 8.1. Encryption of data
\<enter content\>
### 8.1.1. Data at rest
\<enter content\>
### 8.1.2. Data in transit
> Example content:
>
> * Data in transit is encrypted with state-of-the-art encryption, e.g. SSL, TLS.
> * Additionally, we create a Virtual Private Network (VPC) which prevents the Compute Instances from being
> exposed to the public internet. The algorithm and the database are therefore not publicly reachable; they
> are only reachable by the backend.
---
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.

182
DIN EN 62304/software-development-maintenance-plan.md
View File

@ -1,182 +0,0 @@
# Software Development and Maintenance Plan
> 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 document summarizes development and maintenance activities.
## Mapping of Standard Requirements to Document Sections
| ISO 13485:2016 Section | Document Section |
|---------------------------------------|------------------|
| 7.3.2 Design and Development Planning | 1, 2, 3, 7 |
| Classes | IEC 62304:2006 Section | Document Section |
|---------|----------------------------------------------------------------------------|------------------|
| A, B, C | 4.4.2 Risk Management Activities | 1 |
| A, B, C | 5.1.1 a) (Processes) | 1 |
| A, B, C | 5.1.1 b) (Deliverables) | 1 |
| A, B, C | 5.1.1 c) (Traceability) | 1 |
| A, B, C | 5.1.1 d) (Configuration and Change Management) | 1, 5 |
| A, B, C | 5.1.1 e) (Problem Resolution) | 1 |
| A, B, C | 5.1.2 Keep Software Development Plan Updated | 1 |
| A, B, C | 5.1.3 Software Development Plan Reference to System Design and Development | 2 |
| C | 5.1.4 Software Development Standards, Methods and Tools Planning | |
| B, C | 5.1.5 Software Integration and Integration Test Planning | 3, 8 |
| A, B, C | 5.1.6 Software Verification Planning | 7 |
| A, B, C | 5.1.7 Software Risk Management Planning | 1 |
| A, B, C | 5.1.8 Documentation Planning | 6 |
| A, B, C | 5.1.9 Software Configuration Management Planning | 5 |
| B, C | 5.1.10 Supporting Items to be Controlled | 5 |
| B, C | 5.1.11 Software Configuration Item Control Before Verification | 5 |
| B, C | 5.1.12 Identification and Avoidance of Common Software Defects | 4 |
| A, B, C | 6.1 Software Maintenance Plan. | 9 |
## 1 Relevant Processes and Documents
Please see the relevant processes for the following activities:
* Risk management activities incl. SOUP risks: SOP Integrated Software Development
* Problem resolution: SOP Problem Resolution
* Software development incl. deliverables, traceability, regular update of software development plan: SOP
Integrated Software Development
* Change management: SOP Change Management
* SOUP List
* SOP Usability Engineering
## 2. Required Resources
### 2.1 Team
| Role | Count | Names |
|--------------------|-------|--------------------------|
| Frontend Developer | 2 | Ada Lovelace, Steve Jobs |
| Backend Developer | 1 | Alan Turing |
### 2.2 Software
Describe your device's software safety class according to IEC 62304 and your reasoning behind the classification.
#### Programming Languages
> List the languages you’ll be using, including compiler and language versions.
| Name | Version |
|--------|---------|
| Python | 3.8 |
#### Development Software
> List software used to support development, e.g., IDEs.
| Name | Version |
|---------|----------|
| PyCharm | 2020.1.4 |
### 2.3 System Requirement / Target Runtime
> List your target runtime(s).
| Name | Version |
|---------|---------|
| CPython | 3.8 |
> Specify system requirements, e.g., the minimum specifications of the server / compute instance you'll be
> running your software on
*Minimum system requirements:*
* *Server-grade dual-core CPU, e.g., Intel Xeon E3-1230 v5 or higher*
* *4 GB of RAM*
* *1 GBit/s up- and downlink*
* *20GB SSD storage*
## 3 Design Phases
> The 13485 requires you to specify "Design Phases". Here are some suggestions which you could use.
| Title | Date | Description |
|----------------|------|-------------|
| Specification | | |
| Implementation | | |
| Testing | | |
| Validation | | |
| Release | | |
## 4 Avoiding Common Software Defects Based on Selected Programming Technology
> Discuss how your selected programming technology may introduce risks and how you plan to avoid them. With
> modern, dynamically-typed languages, an obvious risk is that you encounter runtime exceptions. So you could
> argue that your test coverage is great and compensates for that. You could also link to your risk analysis
> here if you analyse those risks further.
## 5 Configuration Management and Version Control
> Describe which version control software you're using (probably git, like all human beings on this planet
> right now, except enterprise developers). Also describe your branching model, i.e., how your developers
> create branches during development, how you name them and how you merge them (pull requests? merge commits?
> squash before?). Your code review will be described in the next section.
>
> Importantly, describe which things (code, build files, etc.) are put in version control. Describe how you
> name versions and how you tag them. Your goal should be that you can retrieve an old version and build
> it. Why? Something with a newer version may go wrong (harm patients) and you may need to roll back.
*git is used as version control software. All source code and build files are committed to version control.*
*When implementing software requirements, developers create a new branch starting at master. During
development, developers may create intermediate commits on this development branch.*
*When implementation is completed, a new merge commit to master is created.*
***This is also the activity which constitutes integration of software units.***
*For each release, the goal is to be able to uniquely identify it and retrieve all relevant files (code,
configuration files like build scripts, SOUPs, etc.) at any time in the future.*
*When a new software version is released, its commit is tagged in git. The tag is constructed by adhering to
semver ([semver.org](https://semver.org)) 2.0.0 which results in a version of format MAJOR.MINOR.PATCH,
e.g., 1.0.0.*
## 6 Documentation Activities
> Describe your policy on what should be documented while you develop software. Maybe you want to require
> your developers to document all methods which are private. Maybe you want to keep an up-to-date software
> architecture diagram in the repository, etc.
## 7 Implementation Verification Activities
> Describe verification activities, e.g. code review.
*For each pull request, a code review is performed by a team member who was not the main author of the code
under review. The code review is only marked as "approved" if the code complies with the code review
criteria. This is:*
* *Code fulfils the software requirements*
* *Adherence to [PEP8 Style Guide](https://www.python.org/dev/peps/pep-0008/)*
## 8 Software System Test Activities
> Describe software system test activities. This could be continuous integration which is triggered by opening
> a pull request (e.g. Travis CI, Circle CI). Describe what is tested and how that automated system works.
*Integration tests are included in software system tests.*
## 9 Validation Activities
Validation is carried out as formative and summative usability evaluation as described in the software development process. A usability evaluation file (plan, protocol and report) will be prepared.
## 10 Maintenance Activities
> Describe how often you check SOUP issue trackers and how you document them.
*SOUP issue trackers are checked at least once every 6 months. The verification date is updated in the SOUP
list accordingly.*
---
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
View File

@ -1,56 +0,0 @@
# 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
View File

@ -1,23 +0,0 @@
# 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
View File

@ -1,160 +0,0 @@
# 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
View File

@ -1,54 +0,0 @@
# 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.

2
DIN EN 62304/teschd.md
View File

@ -1,2 +0,0 @@
# Regulation

123
General documents/instructions-for-use.md
View File

@ -1,123 +0,0 @@
| ISO 13485:2016 Section | Document Section |
|------------------------|------------------|
| 4.2.3 | (All) |
# User Manual [enter Product Name]
Version: [enter content]
Date: [enter content]
[Placeholder Company Address]
Email: [enter content]
Website: [enter content]
[Placeholder CE Sign]
[Placeholder UDI]
[enter Product Name] is a class [enter content] medical device in accordance with 93/42/EEC (for MDD) // Regulation (EU) 2017/745 (for MDR).
UMDNS Code: [enter content]
Symbols:
Safety Information:
[Placeholder Symbol]
This symbol indicates important safety-related information.
Additional Information:
[Placeholder Symbol]
This symbol indicates supplementary information.
> On your introductory pages, explain the symbols that you use in the following sections. Take into account standards like ISO 15223.
> **General Provisions:** Instructions for use are regulated in Section 13 of the Essential Requirements (MDD) and Chapter 3, Section 23 of the General Safety and Performance Requirements (MDR). You may be able to make a case for why your users must not be provided with instructions for use, based on the exception stated in Section 13.1 (MDD) or Section 23.1.d (MDR):
>
> "By way of exception, no such instructions for use are needed for devices in Class I or IIa if they can be used safely without any such instructions."
>
> **Language Requirements:** Language requirements are regulated on the national level. German Medical Device Law (Medizinprodukte-Durchführungsgesetz (MPDG), Art. 8) typically requires German, but also gives leeway to argue that English may be a language that is easily understood by your users if those are trained professionals. If you follow this route, as a minimum requirement, all safety-related information has to be provided in German nevertheless:
>
> "In begründeten Fällen dürfen die Informationen auch in englischer Sprache oder einer anderen für den Anwender des Medizinproduktes leicht verständlichen Sprache zur Verfügung gestellt werden, wenn diese Informationen ausschließlich für professionelle Anwender bestimmt sind und die sicherheitsbezogenen Informationen auch in deutscher Sprache oder in der Sprache des Anwenders zur Verfügung gestellt werden."
>
> https://www.gesetze-im-internet.de/mpdg/MPDG.pdf
## Product Description
### Intended Medical Indication
> You can basically copy/paste your intended use document here and in the sections below. This paragraph should include high-level information required to get an idea of how your product works.
> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by your software.
> Take into account: clinical benefits to be expected, types of processed data, types of data processing (or machine learning based devices: information about algorithm accuracy).
### Characterization of User Profile
> Describe your users: what level of education can be assumed for your users group? Any pre-existing knowledge of the field that your device is used in?
> What technical proficiency can be assumed, how much time is typically spent using the software?
> If you plan on providing user training prior to product use, make sure to also add a description of that here.
### Characterization of Patient Population
> Describe the patient population your software is intended to be used on. Note that this may overlap with the user profile above, but not necessarily.
> Your software could be used by physicians to diagnose diseases in patients, so in that case, they don’t overlap. Some ideas for characteristics to describe: Age group, weight range, health, condition(s).
### Characterization of Use Environment Including Software / Hardware
> Describe the typical use environment. What sort of devices is this running on? Does the software only run on one device or on multiple devices? Is it loud and chaotic like in an emergency ward? How’s the lighting?
> Also, add other software or hardware which is required by your device. Most commonly, apps require users to have a smartphone with a compatible operating system (iOS / Android).
### Exclusions
> This is an important section for your company liability: make clear the environment your device should NOT be used in, by whom should your device NOT be used?
## Safety Information
### Contraindications
> More exclusions, more specific to safety risks and clinical implications. For example, does your device automate medical diagnoses? If not, you may want to point out that all results must be checked thoroughly by a qualified physician.
### Warning and Remaining Risks
> You can use this section to point out user information as required for risk mitigation measures. For example, specific information that must be checked for accuracy or completeness to operate the device.
## Language
> Self-explanatory: what languages, what language settings are offered for your product?
## System Requirements
### Hardware
> What hardware configuration is required to run your device (e.g. minimum requirements for processor, display, network bandwidth)?
### Software
> What software configuration is required (e.g. latest browser version)?
### IT-security Measures
> What is required to prevent unauthorized access? How do users prevent data loss? Describe for example firewall settings, VPN setup, etc.
## Installation
> Describe: Is any IT integration required prior to use? How is a successful installation verified? How are login credentials dealt with?
## Safety and Maintenance
> Consider multiple sub-sections here: how do you plan to deploy frontend / backend updates? How can users report malfunctions, clinical incidents, lost passwords or a potential security breach?
Other aspects you may want to consider for the section as part of your instructions for use:
* Using the software: walkthrough guide to explain functionalities including screenshots and links to helpful websites
* Description of the algorithm for machine-learning based medical devices
* Description of alternative devices or services
---
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.

92
General documents/intended-use.md
View File

@ -1,92 +0,0 @@
# Intended Use
## Mapping of Requirements to Document Sections
> Only relevant if you're aiming for MDD (and not MDR) compliance:
| MDD Class | MDD Section | Document Section |
|---------------|------------------|------------------|
| IIa, IIb, III | Annex II, 3.2 c) | (All) |
| I | Annex VII, 3 | (All) |
> And vice-versa, only relevant if you're aiming for MDR (not MDD) compliance:
| MDR Class | MDR Section | Document Section |
|-----------|-------------------------------|------------------|
| (All) | Annex II, 1.1 a) - d), h), i) | (All) |
> Always relevant:
| ISO 14971:2019 Section | Document Section |
|------------------------|------------------|
| 5.2 | (All) |
| IEC 62366-1:2015 Section | Document Section |
|--------------------------|------------------|
| 5.1 | (All) |
## Product
* Name: *\<product name\>*
* Version: *\<product version\>*
* Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
## Intended Use
> Describe the core medical functionality of your device and how it treats, diagnoses or alleviates a disease.
> Keep it high-level so that this description is true for as long as possible even when the device is updated.
## Intended Medical Indication
> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by
> your software. Importantly, also list exclusion criteria: Maybe patients with a certain diagnosis should not
> be using your device.
## Contraindications
> List anything that you want to explicitly exclude from your intended use.
## Patient Population
> Describe the patient population your software is intended to be used on. Note that this may overlap with the
> user profile (section below), but not necessarily. Your software could be used by physicians to diagnose
> diseases in patients, so in that case, they don't overlap. Some ideas for characteristics to describe: Age
> group, weight range, health, condition(s).
## User Profile
> Describe the typical user of the software. Some ideas could be: Qualifications, prior training (for your
> software), technical proficiency, time spent using the software.
## Use Environment Including Software/Hardware
> Describe the typical use environment. What sort of devices is this running on? Does the software only run on
> one device or multiple devices? Is it loud and chaotic like in an emergency ward? How's the lighting?
>
> Also, add other software or hardware which is required by your device. Most commonly, apps require users to
> have a smartphone with a compatible operating system (iOS / Android).
## Operating Principle
> It's kind of a stretch to describe the "operating principle" of software. I guess this makes more sense for
> hardware devices. In any case, I'd just generally state what sort of input goes in and what output comes
> out, e.g. you could be processing images and returning diagnoses.
The device is stand-alone software. It receives input from the user and outputs information.
## Part of the Body / Type of Tissue Interacted With
The device is stand-alone software. It receives input from the user and outputs information. It doesn't come
in contact with tissue or bodily fluids.
## Variants / Accessories
> Describe variants and/or accessories of/to this device, if applicable. For typical stand-alone software of
> startups, this shouldn't be 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.

30
README.md
View File

@ -1,27 +1,33 @@
# Regulation
# Submission / Technical Documenation for basebox
This repository contains compliance documents for [basebox](https://basebox.tech). They are intended to help users of [basebox](https://basebox.tech) getting their compliance certification done (e.g. for medical device software).
This repository used to contain draft versions of our submission/technical documentation.
The relevance of these documents depends on the project that uses basebox.
We are about to make our first release (along with the long awaited basebox version 1.0.0) ,which will be published on our [Documentation Site](https://docs.basebox.io).
For more information, please visit:
## What is basebox?
* https://basebox.tech/why-basebox/regulatory-compliant
* https://openregulatory.com/
basebox is an API Server and data management system written in 100% [Rust](https://rust-lang.org). It features a unique GraphQL to SQL compiler that supports automatic joins and other cool features and enables frontend developers to create an API backend by simply describing it in a single GraphQL schema file.
For more information about basebox, see basebox' website at [basebox.io](https://basebox.io).
<p style="text-align: center; margin: 60px auto;" align="center">
<a href="https://basebox.tech">
<a href="https://basebox.io">
<img src="img/basebox_logo.svg">
</a>
</p>
## What is Submission Documentation?
## License and Conditions of Use
basebox was developed according to the rules of ISO 13485 and IEC 62304, making it suitable for use in regulated areas, especially for medical appliances. We deliver extensive documentation for basebox that helps in getting your basebox-based product certified.
Contents in this repository are available under the [Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/) license.
The documents we provide for basebox are (among others):
All documents in this repository are provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the documents in this repository or the use or other dealings in the content of this repository.
Most (if not all) documents in this repository are based on templates by [OpenRegulatory](https://openregulatory.com), licensed under [CC-BY 4.0]([https://openregulatory.com/template-license#).
* Software Requirements Specification
* Architecture Description
* Intended Use
* User Needs
* ...
If you are developing an API controlled medical device or a device for some other regulated area, you probably know what this is all about. All others can be sure that we develop basebox to meet the highest software development standards.