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

Compare commits

base: compliance:main
Branches Tags
compliance:main
compliance:draft
compliance:pre-move
..
compare: compliance:draft
Branches Tags
compliance:main
compliance:draft
compliance:pre-move

9 Commits
main ... draft

Author SHA1 Message Date
René Herzer
a860d7c972 changed directory structure 2023-02-27 11:31:21 +01:00
René Herzer
4c84e719c1 moved/renamed some docs 2023-02-17 17:56:29 +01:00
René Herzer
134a0ac15f merge 2023-02-17 17:51:15 +01:00
René Herzer
385f6ff946 added 81001 table 2023-02-17 16:09:24 +01:00
René Herzer
c194b45ad4 „IEC 81001“ hinzufügen 2023-02-17 15:06:35 +00:00
René Herzer
3138ea821c „General documents/intended-use.md“ ändern 2023-02-17 09:25:34 +00:00
Markus Thielen
8f1f1d29d8 drafts started 2023-01-31 22:57:05 +01:00
René Herzer
3bd08fcdf0 added MDS2 form for 81001 2023-01-30 13:44:28 +01:00
Markus Thielen
1357c110d0 README formatting 2023-01-26 09:08:05 +01:00
17 changed files with 1668 additions and 18 deletions
Show Stats Expand all files Collapse all files

343
MDS2/mds2.md Normal file
View File

@ -0,0 +1,343 @@
| Manufacturer Disclosure Statement for Medical Device Security -- MDS2 | | | | | | |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ----------------------------------- | -------- | ---------------------- | ---------------------- | ------------------------------------------------------------ |
| ______ | ______ | ______ | ______ | | | |
| | | | | | | |
| Question ID | Question | | See note | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| DOC-1 | Manufacturer Name | ______ | __ | | | |
| DOC-2 | Device Description | ______ | __ | | | |
| DOC-3 | Device Model | ______ | __ | | | |
| DOC-4 | Document ID | ______ | __ | | | |
| DOC-5 | Manufacturer Contact Information | ______ | __ | | | |
| DOC-6 | Intended use of device in network-connected environment: | ______ | __ | | | |
| DOC-7 | Document Release Date | ______ | __ | | | |
| DOC-8 | Coordinated Vulnerability Disclosure: Does the manufacturer have a vulnerability disclosure program for this device? | ______ | __ | | | |
| DOC-9 | ISAO: Is the manufacturer part of an Information Sharing and Analysis Organization? | ______ | __ | | | |
| DOC-10 | Diagram: Is a network or data flow diagram available that indicates connections to other system components or expected external resources? | | __ | | | |
| DOC-11 | SaMD: Is the device Software as a Medical Device (i.e. software-only, no hardware)? | ______ | __ | | | |
| DOC-11.1 | Does the SaMD contain an operating system? | ______ | __ | | | |
| DOC-11.2 | Does the SaMD rely on an owner/operator provided operating system? | ______ | __ | | | |
| DOC-11.3 | Is the SaMD hosted by the manufacturer? | ______ | | | | |
| DOC-11.4 | Is the SaMD hosted by the customer? | ______ | __ | | | |
| | | | | | | |
| | | Yes, No, N/A, or See Note | Note # | | | |
| | MANAGEMENT OF PERSONALLY IDENTIFIABLE INFORMATION | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| MPII-1 | Can this device display, transmit, store, or modify personally identifiable information (e.g. electronic Protected Health Information (ePHI))? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2 | Does the device maintain personally identifiable information? | ______ | | | AR-2 | A.15.1.4 |
| MPII-2.1 | Does the device maintain personally identifiable information temporarily in volatile memory (i.e., until cleared by power-off or reset)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.2 | Does the device store personally identifiable information persistently on internal media? | ______ | __ | | | |
| MPII-2.3 | Is personally identifiable information preserved in the device’s non-volatile memory until explicitly erased? | ______ | __ | | | |
| MPII-2.4 | Does the device store personally identifiable information in a database? | ______ | __ | | | |
| MPII-2.5 | Does the device allow configuration to automatically delete local personally identifiable information after it is stored to a long term solution? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.6 | Does the device import/export personally identifiable information with other systems (e.g., a wearable monitoring device might export personally identifiable information to a server)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.7 | Does the device maintain personally identifiable information when powered off, or during power service interruptions? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-2.8 | Does the device allow the internal media to be removed by a service technician (e.g., for separate destruction or customer retention)? | ______ | __ | | | |
| MPII-2.9 | Does the device allow personally identifiable information records be stored in a separate location from the device’s operating system (i.e. secondary internal drive, alternate drive partition, or remote storage location)? | ______ | | | AR-2 | A.15.1.4 |
| MPII-3 | Does the device have mechanisms used for the transmitting, importing/exporting of personally identifiable information? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.1 | Does the device display personally identifiable information (e.g., video display, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.2 | Does the device generate hardcopy reports or images containing personally identifiable information? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.3 | Does the device retrieve personally identifiable information from or record personally identifiable information to removable media (e.g., removable-HDD, USB memory, DVD-R/RW,CD-R/RW, tape, CF/SD card, memory stick, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.4 | Does the device transmit/receive or import/export personally identifiable information via dedicated cable connection (e.g., RS-232, RS-423, USB, FireWire, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.5 | Does the device transmit/receive personally identifiable information via a wired network connection (e.g., RJ45, fiber optic, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.6 | Does the device transmit/receive personally identifiable information via a wireless network connection (e.g., WiFi, Bluetooth, NFC, infrared, cellular, etc.)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.7 | Does the device transmit/receive personally identifiable information over an external network (e.g., Internet)? | ______ | __ | | AR-2 | A.15.1.4 |
| MPII-3.8 | Does the device import personally identifiable information via scanning a document? | ______ | | | | |
| MPII-3.9 | Does the device transmit/receive personally identifiable information via a proprietary protocol? | ______ | | | | |
| MPII-3.10 | Does the device use any other mechanism to transmit, import or export personally identifiable information? | ______ | __ | | AR-2 | A.15.1.4 |
| Management of Private Data notes: | | | | AR-2 | A.15.1.4 | |
| | | | | | | |
| | | | | | | |
| | AUTOMATIC LOGOFF (ALOF) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The device's ability to prevent access and misuse by unauthorized users if device is left idle for a period of time. | | | | | |
| ALOF-1 | Can the device be configured to force reauthorization of logged-in user(s) after a predetermined length of inactivity (e.g., auto-logoff, session lock, password protected screen saver)? | ______ | __ | Section 5.1, ALOF | AC-12 | None |
| ALOF-2 | Is the length of inactivity time before auto-logoff/screen lock user or administrator configurable? | ______ | __ | Section 5.1, ALOF | AC-11 | A.11.2.8, A.11.2.9 |
| | | | | | | |
| | | | | | | |
| | AUDIT CONTROLS (AUDT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability to reliably audit activity on the device. | | | | | |
| AUDT-1 | Can the medical device create additional audit logs or reports beyond standard operating system logs? | ______ | __ | Section 5.2, AUDT | AU-1 | A.5.1.1, A.5.1.2, A.6.1.1, A.12.1.1, A.18.1.1, A.18.2.2 |
| AUDT-1.1 | Does the audit log record a USER ID? | ______ | __ | | | |
| AUDT-1.2 | Does other personally identifiable information exist in the audit trail? | | | Section 5.2, AUDT | AU-2 | None |
| AUDT-2 | Are events recorded in an audit log? If yes, indicate which of the following events are recorded in the audit log: | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.1 | Successful login/logout attempts? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.2 | Unsuccessful login/logout attempts? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.3 | Modification of user privileges? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.4 | Creation/modification/deletion of users? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.5 | Presentation of clinical or PII data (e.g. display, print)? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.6 | Creation/modification/deletion of data? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.7 | Import/export of data from removable media (e.g. USB drive, external hard drive, DVD)? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.8 | Receipt/transmission of data or commands over a network or point-to-point connection? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.8.1 | Remote or on-site support? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.8.2 | Application Programming Interface (API) and similar activity? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.9 | Emergency access? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.10 | Other events (e.g., software updates)? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-2.11 | Is the audit capability documented in more detail? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-3 | Can the owner/operator define or select which events are recorded in the audit log? | | | Section 5.2, AUDT | AU-2 | None |
| AUDT-4 | Is a list of data attributes that are captured in the audit log for an event available? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-4.1 | Does the audit log record date/time? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-4.1.1 | Can date and time be synchronized by Network Time Protocol (NTP) or equivalent time source? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-5 | Can audit log content be exported? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-5.1 | Via physical media? | ______ | __ | | | |
| AUDT-5.2 | Via IHE Audit Trail and Node Authentication (ATNA) profile to SIEM? | ______ | __ | | | |
| AUDT-5.3 | Via Other communications (e.g., external service device, mobile applications)? | ______ | __ | | | |
| AUDT-5.4 | Are audit logs encrypted in transit or on storage media? | ______ | __ | | | |
| AUDT-6 | Can audit logs be monitored/reviewed by owner/operator? | ______ | __ | | | |
| AUDT-7 | Are audit logs protected from modification? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| AUDT-7.1 | Are audit logs protected from access? | | | | | |
| AUDT-8 | Can audit logs be analyzed by the device? | ______ | __ | Section 5.2, AUDT | AU-2 | None |
| | | | | | | |
| | | | | | | |
| | AUTHORIZATION (AUTH) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to determine the authorization of users. | | | | | |
| AUTH-1 | Does the device prevent access to unauthorized users through user login requirements or other mechanism? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-1.1 | Can the device be configured to use federated credentials management of users for authorization (e.g., LDAP, OAuth)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-1.2 | Can the customer push group policies to the device (e.g., Active Directory)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-1.3 | Are any special groups, organizational units, or group policies required? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-2 | Can users be assigned different privilege levels based on 'role' (e.g., user, administrator, and/or service, etc.)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-3 | Can the device owner/operator grant themselves unrestricted administrative privileges (e.g., access operating system or application via local root or administrator account)? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-4 | Does the device authorize or control all API access requests? | ______ | __ | Section 5.3, AUTH | IA-2 | A.9.2.1 |
| AUTH-5 | Does the device run in a restricted access mode, or ‘kiosk mode’, by default? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | CYBER SECURITY PRODUCT UPGRADES (CSUP) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of on-site service staff, remote service staff, or authorized customer staff to install/upgrade device's security patches. | | | | | |
| CSUP-1 | Does the device contain any software or firmware which may require security updates during its operational life, either from the device manufacturer or from a third-party manufacturer of the software/firmware? If no, answer “N/A” to questions in this section. | ______ | __ | | | |
| CSUP-2 | Does the device contain an Operating System? If yes, complete 2.1-2.4. | ______ | __ | | | |
| CSUP-2.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-2.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-2.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-2.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-3 | Does the device contain Drivers and Firmware? If yes, complete 3.1-3.4. | ______ | __ | | | |
| CSUP-3.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-3.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-3.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-3.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-4 | Does the device contain Anti-Malware Software? If yes, complete 4.1-4.4. | ______ | __ | | | |
| CSUP-4.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-4.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-4.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-4.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-5 | Does the device contain Non-Operating System commercial off-the-shelf components? If yes, complete 5.1-5.4. | ______ | __ | | | |
| CSUP-5.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-5.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-5.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-5.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-6 | Does the device contain other software components (e.g., asset management software, license management)? If yes, please provide details or refernce in notes and complete 6.1-6.4. | ______ | __ | | | |
| CSUP-6.1 | Does the device documentation provide instructions for owner/operator installation of patches or software updates? | ______ | __ | | | |
| CSUP-6.2 | Does the device require vendor or vendor-authorized service to install patches or software updates? | ______ | __ | | | |
| CSUP-6.3 | Does the device have the capability to receive remote installation of patches or software updates? | ______ | __ | | | |
| CSUP-6.4 | Does the medical device manufacturer allow security updates from any third-party manufacturers (e.g., Microsoft) to be installed without approval from the manufacturer? | ______ | __ | | | |
| CSUP-7 | Does the manufacturer notify the customer when updates are approved for installation? | ______ | __ | | | |
| CSUP-8 | Does the device perform automatic installation of software updates? | ______ | __ | | | |
| CSUP-9 | Does the manufacturer have an approved list of third-party software that can be installed on the device? | ______ | __ | | | |
| CSUP-10 | Can the owner/operator install manufacturer-approved third-party software on the device themselves? | ______ | __ | | | |
| CSUP-10.1 | Does the system have mechanism in place to prevent installation of unapproved software? | ______ | __ | | | |
| CSUP-11 | Does the manufacturer have a process in place to assess device vulnerabilities and updates? | ______ | __ | | | |
| CSUP-11.1 | Does the manufacturer provide customers with review and approval status of updates? | ______ | __ | | | |
| CSUP-11.2 | Is there an update review cycle for the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | HEALTH DATA DE-IDENTIFICATION (DIDT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to directly remove information that allows identification of a person. | | | | | |
| DIDT-1 | Does the device provide an integral capability to de-identify personally identifiable information? | ______ | __ | Section 5.6, DIDT | None | ISO 27038 |
| DIDT-1.1 | Does the device support de-identification profiles that comply with the DICOM standard for de-identification? | ______ | __ | Section 5.6, DIDT | None | ISO 27038 |
| | | | | | | |
| | | | | | | |
| | DATA BACKUP AND DISASTER RECOVERY (DTBK) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability to recover after damage or destruction of device data, hardware, software, or site configuration information. | | | | | |
| DTBK-1 | Does the device maintain long term primary storage of personally identifiable information / patient information (e.g. PACS)? | ______ | __ | | | |
| DTBK-2 | Does the device have a “factory reset” function to restore the original device settings as provided by the manufacturer? | ______ | __ | Section 5.7, DTBK | CP-9 | A.12.3.1 |
| DTBK-3 | Does the device have an integral data backup capability to removable media? | ______ | __ | Section 5.7, DTBK | CP-9 | A.12.3.1 |
| DTBK-4 | Does the device have an integral data backup capability to remote storage? | | | | | |
| DTBK-5 | Does the device have a backup capability for system configuration information, patch restoration, and software restoration? | | | | | |
| DTBK-6 | Does the device provide the capability to check the integrity and authenticity of a backup? | ______ | __ | Section 5.7, DTBK | CP-9 | A.12.3.1 |
| | | | | | | |
| | | | | | | |
| | EMERGENCY ACCESS (EMRG) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device user to access personally identifiable information in case of a medical emergency situation that requires immediate access to stored personally identifiable information. | | | | | |
| EMRG-1 | Does the device incorporate an emergency access (i.e. “break-glass”) feature? | ______ | __ | Section 5.8, EMRG | SI-17 | None |
| | | | | | | |
| | | | | | | |
| | HEALTH DATA INTEGRITY AND AUTHENTICITY (IGAU) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | How the device ensures that the stored data on the device has not been altered or destroyed in a non-authorized manner and is from the originator. | | | | | |
| IGAU-1 | Does the device provide data integrity checking mechanisms of stored health data (e.g., hash or digital signature)? | ______ | __ | Section 5.9, IGAU | SC-28 | A.18.1.3 |
| IGAU-2 | Does the device provide error/failure protection and recovery mechanisms for stored health data (e.g., RAID-5)? | ______ | __ | Section 5.9, IGAU | SC-28 | A.18.1.3 |
| | | | | | | |
| | | | | | | |
| | MALWARE DETECTION/PROTECTION (MLDP) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to effectively prevent, detect and remove malicious software (malware). | | | | | |
| MLDP-1 | Is the device capable of hosting executable software? | ______ | __ | Section 5.10, MLDP | | |
| MLDP-2 | Does the device support the use of anti-malware software (or other anti-malware mechanism)? Provide details or reference in notes. | ______ | __ | Section 5.10, MLDP | SI-3 | A.12.2.1 |
| MLDP-2.1 | Does the device include anti-malware software by default? | ______ | __ | Section 5.10, MLDP | CM-5 | A.9.2.3, A.9.4.5, A.12.1.2, A.12.1.4, A.12.5.1 |
| MLDP-2.2 | Does the device have anti-malware software available as an option? | ______ | __ | Section 5.10, MLDP | AU-6 | A.12.4.1, A.16.1.2, A.16.1.4 |
| MLDP-2.3 | Does the device documentation allow the owner/operator to install or update anti-malware software? | ______ | __ | Section 5.10, MLDP | CP-10 | A.17.1.2 |
| MLDP-2.4 | Can the device owner/operator independently (re-)configure anti-malware settings? | ______ | __ | Section 5.10, MLDP | AU-2 | None |
| MLDP-2.5 | Does notification of malware detection occur in the device user interface? | ______ | | | | |
| MLDP-2.6 | Can only manufacturer-authorized persons repair systems when malware has been detected? | ______ | | | | |
| MLDP-2.7 | Are malware notifications written to a log? | ______ | | | | |
| MLDP-2.8 | Are there any restrictions on anti-malware (e.g., purchase, installation, configuration, scheduling)? | ______ | | | | |
| MLDP-3 | If the answer to MLDP-2 is NO, and anti-malware cannot be installed on the device, are other compensating controls in place or available? | ______ | __ | Section 5.10, MLDP | SI-2 | A.12.6.1, A.14.2.2, A.14.2.3, A.16.1.3 |
| MLDP-4 | Does the device employ application whitelisting that restricts the software and services that are permitted to be run on the device? | ______ | __ | Section 5.10, MLDP | SI-3 | A.12.2.1 |
| MLDP-5 | Does the device employ a host-based intrusion detection/prevention system? | ______ | __ | Section 5.10, MLDP | SI-4 | None |
| MLDP-5.1 | Can the host-based intrusion detection/prevention system be configured by the customer? | ______ | __ | Section 5.10, MLDP | CM-7 | A.12.5.1 |
| MLDP-5.2 | Can a host-based intrusion detection/prevention system be installed by the customer? | ______ | __ | Section 5.10, MLDP | | |
| | | | | | | |
| | | | | | | |
| | NODE AUTHENTICATION (NAUT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to authenticate communication partners/nodes. | | | | | |
| NAUT-1 | Does the device provide/support any means of node authentication that assures both the sender and the recipient of data are known to each other and are authorized to receive transferred information (e.g. Web APIs, SMTP, SNMP)? | ______ | __ | Section 5.11, NAUT | SC-23 | None |
| NAUT-2 | Are network access control mechanisms supported (E.g., does the device have an internal firewall, or use a network connection white list)? | ______ | __ | Section 5.11, NAUT | SC-7 | A.13.1.1, A.13.1.3, A.13.2.1,A.14.1.3 |
| NAUT-2.1 | Is the firewall ruleset documented and available for review? | ______ | __ | | | |
| NAUT-3 | Does the device use certificate-based network connection authentication? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | CONNECTIVITY CAPABILITIES (CONN) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | All network and removable media connections must be considered in determining appropriate security controls. This section lists connectivity capabilities that may be present on the device. | | | | | |
| CONN-1 | Does the device have hardware connectivity capabilities? | ______ | __ | | | |
| CONN-1.1 | Does the device support wireless connections? | ______ | __ | | | |
| CONN-1.1.1 | Does the device support Wi-Fi? | ______ | __ | | | |
| CONN-1.1.2 | Does the device support Bluetooth? | ______ | __ | | | |
| CONN-1.1.3 | Does the device support other wireless network connectivity (e.g. LTE, Zigbee, proprietary)? | ______ | __ | | | |
| CONN-1.1.4 | Does the device support other wireless connections (e.g., custom RF controls, wireless detectors)? | ______ | __ | | | |
| CONN-1.2 | Does the device support physical connections? | ______ | __ | | | |
| CONN-1.2.1 | Does the device have available RJ45 Ethernet ports? | ______ | __ | | | |
| CONN-1.2.2 | Does the device have available USB ports? | ______ | __ | | | |
| CONN-1.2.3 | Does the device require, use, or support removable memory devices? | ______ | __ | | | |
| CONN-1.2.4 | Does the device support other physical connectivity? | ______ | __ | | | |
| CONN-2 | Does the manufacturer provide a list of network ports and protocols that are used or may be used on the device? | ______ | __ | | | |
| CONN-3 | Can the device communicate with other systems within the customer environment? | ______ | __ | | | |
| CONN-4 | Can the device communicate with other systems external to the customer environment (e.g., a service host)? | ______ | __ | | | |
| CONN-5 | Does the device make or receive API calls? | ______ | __ | | | |
| CONN-6 | Does the device require an internet connection for its intended use? | ______ | __ | | | |
| CONN-7 | Does the device support Transport Layer Security (TLS)? | ______ | __ | | | |
| CONN-7.1 | Is TLS configurable? | | | | | |
| CONN-8 | Does the device provide operator control functionality from a separate device (e.g., telemedicine)? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | PERSON AUTHENTICATION (PAUT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability to configure the device to authenticate users. | | | | | |
| PAUT-1 | Does the device support and enforce unique IDs and passwords for all users and roles (including service accounts)? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-1.1 | Does the device enforce authentication of unique IDs and passwords for all users and roles (including service accounts)? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-2 | Is the device configurable to authenticate users through an external authentication service (e.g., MS Active Directory, NDS, LDAP, OAuth, etc.)? | ______ | __ | Section 5.12, PAUT | IA-5 | A.9.2.1 |
| PAUT-3 | Is the device configurable to lock out a user after a certain number of unsuccessful logon attempts? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-4 | Are all default accounts (e.g., technician service accounts, administrator accounts) listed in the documentation? | ______ | __ | Section 5.12, PAUT | SA-4(5) | A.14.1.1, A.14.2.7, A.14.2.9, A.15.1.2 |
| PAUT-5 | Can all passwords be changed? | ______ | __ | Section 5.12, PAUT | | |
| PAUT-6 | Is the device configurable to enforce creation of user account passwords that meet established (organization specific) complexity rules? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-7 | Does the device support account passwords that expire periodically? | ______ | __ | | | |
| PAUT-8 | Does the device support multi-factor authentication? | ______ | __ | | | |
| PAUT-9 | Does the device support single sign-on (SSO)? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-10 | Can user accounts be disabled/locked on the device? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-11 | Does the device support biometric controls? | ______ | __ | Section 5.12, PAUT | IA-2 | A.9.2.1 |
| PAUT-12 | Does the device support physical tokens (e.g. badge access)? | ______ | __ | | | |
| PAUT-13 | Does the device support group authentication (e.g. hospital teams)? | ______ | __ | | | |
| PAUT-14 | Does the application or device store or manage authentication credentials? | ______ | __ | | | |
| PAUT-14.1 | Are credentials stored using a secure method? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | PHYSICAL LOCKS (PLOK) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Physical locks can prevent unauthorized users with physical access to the device from compromising the integrity and confidentiality of personally identifiable information stored on the device or on removable media | | | | | |
| PLOK-1 | Is the device software only? If yes, answer “N/A” to remaining questions in this section. | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| PLOK-2 | Are all device components maintaining personally identifiable information (other than removable media) physically secure (i.e., cannot remove without tools)? | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| PLOK-3 | Are all device components maintaining personally identifiable information (other than removable media) physically secured behind an individually keyed locking device? | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| PLOK-4 | Does the device have an option for the customer to attach a physical lock to restrict access to removable media? | ______ | __ | Section 5.13, PLOK | PE- 3(4) | A.11.1.1, A.11.1.2, A.11.1.3 |
| | | | | | | |
| | | | | | | |
| | ROADMAP FOR THIRD PARTY COMPONENTS IN DEVICE LIFE CYCLE (RDMP) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Manufacturer’s plans for security support of third-party components within the device’s life cycle. | | | | | |
| RDMP-1 | Was a secure software development process, such as ISO/IEC 27034 or IEC 62304, followed during product development? | ______ | __ | Section 5.14, RDMP | CM-2 | None |
| RDMP-2 | Does the manufacturer evaluate third-party applications and software components included in the device for secure development practices? | ______ | __ | Section 5.14, RDMP | CM-8 | A.8.1.1, A.8.1.2 |
| RDMP-3 | Does the manufacturer maintain a web page or other source of information on software support dates and updates? | ______ | __ | Section 5.14, RDMP | CM-8 | A.8.1.1, A.8.1.2 |
| RDMP-4 | Does the manufacturer have a plan for managing third-party component end-of-life? | ______ | __ | Section 5.14, RDMP | CM-8 | A.8.1.1, A.8.1.2 |
| | | | | | | |
| | | | | | | |
| | SOFTWARE BILL OF MATERIALS (SBoM) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | A Software Bill of Material (SBoM) lists all the software components that are incorporated into the device being described for the purpose of operational security planning by the healthcare delivery organization. This section supports controls in the RDMP section. | | | | | |
| SBOM-1 | Is the SBoM for this product available? | ______ | __ | | | |
| SBOM-2 | Does the SBoM follow a standard or common method in describing software components? | ______ | __ | | | |
| SBOM-2.1 | Are the software components identified? | ______ | __ | | | |
| SBOM-2.2 | Are the developers/manufacturers of the software components identified? | ______ | __ | | | |
| SBOM-2.3 | Are the major version numbers of the software components identified? | ______ | __ | | | |
| SBOM-2.4 | Are any additional descriptive elements identified? | ______ | __ | | | |
| SBOM-3 | Does the device include a command or process method available to generate a list of software components installed on the device? | ______ | __ | | | |
| SBOM-4 | Is there an update process for the SBoM? | ______ | __ | | | |
| | | | | | | |
| | SYSTEM AND APPLICATION HARDENING (SAHD) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The device's inherent resistance to cyber attacks and malware. | | | | CM-7 | A.12.5.1* |
| SAHD-1 | Is the device hardened in accordance with any industry standards? | ______ | __ | Section 5.15, SAHD | AC-17(2)/IA-3 | A.6.2.1, A.6.2.2, A.13.1.1, A.13.2.1, A.14.1.2/None |
| SAHD-2 | Has the device received any cybersecurity certifications? | ______ | __ | Section 5.15, SAHD | SA-12(10) | A.14.2.7, A.15.1.1, A.15.1.2, A.15.1.3 |
| SAHD-3 | Does the device employ any mechanisms for software integrity checking | ______ | __ | | | |
| SAHD-3.1 | Does the device employ any mechanism (e.g., release-specific hash key, checksums, digital signature, etc.) to ensure the installed software is manufacturer-authorized? | ______ | __ | | | |
| SAHD-3.2 | Does the device employ any mechanism (e.g., release-specific hash key, checksums, digital signature, etc.) to ensure the software updates are the manufacturer-authorized updates? | ______ | __ | Section 5.15, SAHD | CM-8 | A.8.1.1, A.8.1.2 |
| SAHD-4 | Can the owner/operator perform software integrity checks (i.e., verify that the system has not been modified or tampered with)? | ______ | __ | Section 5.15, SAHD | AC-3 | A.6.2.2, A.9.1.2, A.9.4.1, A.9.4.4, A.9.4.5, A.13.1.1, A.14.1.2, A.14.1.3, A.18.1.3 |
| SAHD-5 | Is the system configurable to allow the implementation of file-level, patient level, or other types of access controls? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-5.1 | Does the device provide role-based access controls? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-6 | Are any system or user accounts restricted or disabled by the manufacturer at system delivery? | ______ | __ | Section 5.15, SAHD | CM-8 | A.8.1.1, A.8.1.2 |
| SAHD-6.1 | Are any system or user accounts configurable by the end user after initial configuration? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-6.2 | Does this include restricting certain system or user accounts, such as service technicians, to least privileged access? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-7 | Are all shared resources (e.g., file shares) which are not required for the intended use of the device disabled? | ______ | __ | Section 5.15, SAHD | CM-7 | A.12.5.1* |
| SAHD-8 | Are all communication ports and protocols that are not required for the intended use of the device disabled? | ______ | __ | Section 5.15, SAHD | SA-18 | None |
| SAHD-9 | Are all services (e.g., telnet, file transfer protocol [FTP], internet information server [IIS], etc.), which are not required for the intended use of the device deleted/disabled? | ______ | __ | Section 5.15, SAHD | CM-6 | None |
| SAHD-10 | Are all applications (COTS applications as well as OS-included applications, e.g., MS Internet Explorer, etc.) which are not required for the intended use of the device deleted/disabled? | ______ | __ | Section 5.15, SAHD | SI-2 | A.12.6.1, A.14.2.2, A.14.2.3, A.16.1.3 |
| SAHD-11 | Can the device prohibit boot from uncontrolled or removable media (i.e., a source other than an internal drive or memory component)? | ______ | __ | | | |
| SAHD-12 | Can unauthorized software or hardware be installed on the device without the use of physical tools? | ______ | __ | | | |
| SAHD-13 | Does the product documentation include information on operational network security scanning by users? | ______ | __ | | | |
| SAHD-14 | Can the device be hardened beyond the default provided state? | ______ | __ | | | |
| SAHD-14.1 | Are instructions available from vendor for increased hardening? | | | | | |
| SHAD-15 | Can the system prevent access to BIOS or other bootloaders during boot? | | | | | |
| SAHD-16 | Have additional hardening methods not included in 2.3.19 been used to harden the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | SECURITY GUIDANCE (SGUD) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Availability of security guidance for operator and administrator of the device and manufacturer sales and service. | | | | | |
| SGUD-1 | Does the device include security documentation for the owner/operator? | ______ | __ | Section 5.16, SGUD | AT-2/PL-2 | A.7.2.2, A.12.2.1/A.14.1.1 |
| SGUD-2 | Does the device have the capability, and provide instructions, for the permanent deletion of data from the device or media? | ______ | __ | Section 5.16, SGUD | MP-6 | A.8.2.3, A.8.3.1, A.8.3.2, A.11.2.7 |
| SGUD-3 | Are all access accounts documented? | ______ | __ | Section 5.16, SGUD | AC-6,IA-2 | A.9.1.2, A.9.2.3, A.9.4.4, A.9.4.5/A.9.2.1 |
| SGUD-3.1 | Can the owner/operator manage password control for all accounts? | ______ | __ | | | |
| SGUD-4 | Does the product include documentation on recommended compensating controls for the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | HEALTH DATA STORAGE CONFIDENTIALITY (STCF) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to ensure unauthorized access does not compromise the integrity and confidentiality of personally identifiable information stored on the device or removable media. | | | | | |
| STCF-1 | Can the device encrypt data at rest? | ______ | __ | Section 5.17, STCF | SC-28 | A.8.2.3 |
| STCF-1.1 | Is all data encrypted or otherwise protected? | | | | | |
| STCF-1.2 | Is the data encryption capability configured by default? | | | | | |
| STCF-1.3 | Are instructions available to the customer to configure encryption? | | | | | |
| STCF-2 | Can the encryption keys be changed or configured? | ______ | __ | Section 5.17, STCF | SC-28 | A.8.2.3 |
| STCF-3 | Is the data stored in a database located on the device? | ______ | __ | | | |
| STCF-4 | Is the data stored in a database external to the device? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | TRANSMISSION CONFIDENTIALITY (TXCF) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to ensure the confidentiality of transmitted personally identifiable information. | | | | | |
| TXCF-1 | Can personally identifiable information be transmitted only via a point-to-point dedicated cable? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-2 | Is personally identifiable information encrypted prior to transmission via a network or removable media? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-2.1 | If data is not encrypted by default, can the customer configure encryption options? | ______ | __ | | | |
| TXCF-3 | Is personally identifiable information transmission restricted to a fixed list of network destinations? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-4 | Are connections limited to authenticated systems? | ______ | __ | Section 5.18, TXCF | CM-7 | A.12.5.1 |
| TXCF-5 | Are secure transmission methods supported/implemented (DICOM, HL7, IEEE 11073)? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | TRANSMISSION INTEGRITY (TXIG) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | The ability of the device to ensure the integrity of transmitted data. | | | | | |
| TXIG-1 | Does the device support any mechanism (e.g., digital signatures) intended to ensure data is not modified during transmission? | ______ | __ | Section 5.19, TXIG | SC-8 | A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3 |
| TXIG-2 | Does the device include multiple sub-components connected by external cables? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | REMOTE SERVICE (RMOT) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | Remote service refers to all kinds of device maintenance activities performed by a service person via network or other remote connection. | | | | | |
| RMOT-1 | Does the device permit remote service connections for device analysis or repair? | ______ | __ | | AC-17 | A.6.2.1, A.6.2.2, A.13.1.1, A.13.2.1, A.14.1.2 |
| RMOT-1.1 | Does the device allow the owner/operator to initiative remote service sessions for device analysis or repair? | ______ | __ | | | |
| RMOT-1.2 | Is there an indicator for an enabled and active remote session? | ______ | __ | | | |
| RMOT-1.3 | Can patient data be accessed or viewed from the device during the remote session? | ______ | __ | | AC-17 | A.6.2.1, A.6.2.2, A.13.1.1, A.13.2.1, A.14.1.2 |
| RMOT-2 | Does the device permit or use remote service connections for predictive maintenance data? | ______ | __ | | | |
| RMOT-3 | Does the device have any other remotely accessible functionality (e.g. software updates, remote training)? | ______ | __ | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | OTHER SECURITY CONSIDERATIONS (OTHR) | | | IEC TR 80001-2-2:2012 | NIST SP 800-53 Rev. 4 | ISO 27002:2013 |
| | NONE | | | | | |
| | | | | | | |
| | Notes: | | | | | |
| | | | | | | |
| Note 1 | Example note. Please keep individual notes to one cell. Please use separate notes for separate information | | | | | Manufacturer Disclosure Statement for Medical Device Security -- MDS2 |

33
README.md
View File

@ -1,32 +1,29 @@
# Submission / Technical Documenation for basebox # Regulation
Our submission/compliance docs can be found on our [Documentation Site](https://docs.basebox.io). 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).
The relevance of these documents depends on the project that uses basebox.
## What is basebox? For more information, please visit:
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. * https://basebox.tech/why-basebox/regulatory-compliant
* https://openregulatory.com/
For more information about basebox, see basebox' website at [basebox.io](https://basebox.io). <p align="center">
<br><br><br>
<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"> <img src="img/basebox_logo.svg">
</a> </a>
<br><br><br>
</p> </p>
## What is Submission Documentation?
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. ## License and Conditions of Use
The documents we provide for basebox are (among others): 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.
* Software Requirements Specification 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.
* Architecture Description
* Intended Use 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#).
* 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.

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

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

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

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

73
iec-62304/document-roadmap.md Normal file
View File

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

125
iec-62304/instructions-for-use.md Normal file
View File

@ -0,0 +1,125 @@
| ISO 13485:2016 Section | Document Section |
|------------------------|------------------|
| 4.2.3 | (All) |
# User Manual [enter Product Name]
**Document Change History**
| Version | Date | Author | Change Comment |
| ------- | ---------- | -------------- | -------------- |
| 0.1 | 2023-02-01 | Markus Thielen | Draft |
[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.

98
iec-62304/intended-use.md Normal file
View File

@ -0,0 +1,98 @@
# Intended Use
**Document Change History**
| Version | Date | Author | Change Comment |
|---------|------------|----------------|----------------|
| 0.1 | 2023-02-01 | Markus Thielen | Draft |
## 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: basebox
* Version: Applies to all versions
* Basic UDI-DI: Applicable for the medical device which integrates basebox.
## 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.
The following characteristics of an intended use have to be defined by the medical device manufacturer using basebox.
## Intended Medical Indication
N/A. See above.
## 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.

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

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

169
iec-62304/post-market-surveillance-plan.md Normal file
View File

@ -0,0 +1,169 @@
# 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
iec-62304/software-architecture-checklist.md Normal file
View File

@ -0,0 +1,41 @@
# 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
iec-62304/software-architecture-description.md Normal file
View File

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

188
iec-62304/software-development-maintenance-plan.md Normal file
View File

@ -0,0 +1,188 @@
# Software Development and Maintenance Plan
**Document Change History**
| Version | Date | Author | Change Comment |
|---------|------------|----------------|----------------|
| 0.1 | 2023-02-01 | Markus Thielen | Draft |
> 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
iec-62304/software-requirements-list.md Normal file
View File

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

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

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

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

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

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

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

104
iec-81001-5-1/iec-81001-5-1.md Normal file
View File

@ -0,0 +1,104 @@
Basebox Compliance Conformity Assessment against: IEC 81001-5-1:2021 - Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product life cycle, (2021-12)
**bold** = TBD
| Chapt | Requirements | How basebox Rel 1 development fulfilled the IEC 81001-5-1 requirements | References |
| ------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| | Introduction - The scope of the standard is limited to HEALTH SOFTWARE and its connectivity to its INTENDED ENVIRONMENT OF USE, based on IEC 62304, but with emphasis on CYBERSECURITY. | Introduction - Basebox is an Off-the-Shelf (OTS) DB component which can be integrated in any device which needs data base functionalility. Basebox has no specific intended use and is not a Medical Device. | |
| 1 | This document defines the LIFE CYCLE requirements for development and maintenance of HEALTH SOFTWARE needed to support conformance to IEC 62443-4-1[11] – taking the specific needs for HEALTH SOFTWARE into account | In order to apply best practices for security and privacy engineering for the basebox component the requirements from IEC 81001-5-1 were followed as applicable. | |
| 2 | Normative references | The following sections exlain how the requirements from the standard were applied during the design and devopment of basebox Revision 1. | |
| 3 | Terms and definitions | Any requirements which were not applicable to the basebox development have an according rational. | |
| 4 | General requirements | Many of the design and development documentation contain security and some confidential information. Those documents are not to be published herein. An according note is provided where applicable. | |
| 4.1 | Quality management | But these design and development documents could be reviewed during any on site audit. | |
| 4.1.1 | Quality management system | The establishment of an basebox adequate Quality Management System which comprises the complete life-cycle of basebox and which is based upon ISO 13485 is in preparation | |
| 4.1.2 | Identification of responsibilities | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 4.1.3 | Identification of applicability | Performed for basebox. (Note: not to be published) | |
| 4.1.4 | SECURITY expertise | Security expertise was established by hiring experienced SW engineers during the start of the company but also by acquiring independent consultation from specialized external experts like the Johner Institute. | |
| 4.1.5 | SOFTWARE ITEMS from third-party suppliers | These items are covered by basebox in the SBoM (Software Bill of Materials). | |
| 4.1.6 | Continuous improvement | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 4.1.7 | Disclosing SECURITY-related issues | Not applicable for basebox (since basebox is not a medical device). Any medical device company which is integrating basebox has to establish this activity. | |
| 4.1.8 | Periodic review of SECURITY defect management | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 4.1.9 | ACCOMPANYING DOCUMENTATION review | Peer Reviews were performed to ensure the completeness and correctness of any basebox accompanying documentation | |
| 4.2 | SECURITY RISK MANAGEMENT | Threat modelling was perfomed for basebox. All identified threat mitigation controls were implemented and verified. Testing comprised a penetration test which was executed by an independent test house. (Note: threat model not to be published) | |
| 4.3 | SOFTWARE ITEM classification relating to risk transfer | Shall be documented by any medical device manufacturer which integrates basebox. | |
| 5 | Software development PROCESS | | |
| 5.1 | Software development planning | | |
| 5.1.1 | ACTIVITIES in the LIFE CYCLE PROCESS | **Basebox was developed based upon state-of-the art software engineering methodologies and practices. A formalized software development process which is in compliance with IEC 62304 standard will be part of the upcoming holistic Quality Management system.** | |
| 5.1.2 | Development environment SECURITY | The development environment is secured according to existing security standards. E.e. by 2FA, backups, ssl and other measures. (Note: not to be published) | |
| 5.1.3 | Secure coding standards | basebox was implementd by using the following public coding standard: LIST HERE. In addition, basebox has defined its own coding standards. These are: LIST HERE. | |
| 5.2 | HEALTH SOFTWARE requirements analysis | | |
| 5.2.1 | HEALTH SOFTWARE SECURITY requirements | The Manufacturer Disclosure Statement for Medical Device Security (MDS2) form provides an overview of the standard based security requirements and capabilities which were specified and implemented for basebox. | |
| 5.2.2 | SECURITY requirements review | The security requirements for basebox have been reviewed by an external and independent expert from the Johner Institute. (Note: the review results are not to be published) | |
| 5.2.3 | SECURITY risks for REQUIRED SOFTWARE | **tbd.** | |
| 5.3 | Software architectural design | | |
| 5.3.1 | DEFENSE-IN-DEPTH ARCHITECTURE/design | **The basebox architecture and design was developed by having the defense-in-depth-strategy in mind. Security requirements were identified in lockstep with the development of the componenent and identification of its defense layers. (Note: the review results are not to be published)** | |
| 5.3.2 | Secure design best practices | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to identify, enforce and maintain secure design practices. The MANUFACTURER shall document secure design best practices, which should include but are not limited to: a) documenting all TRUST BOUNDARIES as part of the design; b) least privilege (granting only the privileges to users/software necessary to perform intended operations); c) using proven secure SOFTWARE ITEMS/designs where possible; d) economy of mechanism (striving for simple designs); e) using secure design patterns; f) ATTACK SURFACE reduction; g) removing backdoors, debug access and debug information used during development or documenting their presence and the need to protect them from unauthorized access; and h) protecting any remaining debug information from unauthorized access. The MANUFACTURER shall define a SECURITY ARCHITECTURE as part of DEFENSE-IN-DEPTH, including the practices listed above as appropriate. | The basebox architecture and design does consider secure design best practices like (non-exhaustive list): trust boundaries, economy of mechanism, attack surface reduction, removing backdoors, protecting any remaining debug information from unauthorized access. (Note: secure design best practices are not to be published) | |
| 5.3.3 | SECURITY architectural design review | The architectural design review was performed by an external and independent expert from the Johner Institute. (Note: the review results are not to be published) | |
| 5.4 | Software design | | |
| 5.4.1 | Software design best practices | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to develop and document a secure HEALTH SOFTWARE design and maintain the use of best practices for the secure design, taking into account: <br />a) software technology at application level (for examples algorithms, methods);<br />b) the programming technology used, (for example programming language);<br />c) the secure design best practices in 5.3.2. | **TBD inkl. 5.3.2** | |
| 5.4.2 | Secure design | Threat modelling comprised the identification of threats and efefctive mitigation-measures (also called security controls). These security controls were considered during the basebox design and implementation. (Note: the secure designs are not to be published) | |
| 5.4.3 | Secure HEALTH SOFTWARE interfaces | **Specification of Security settings** | |
| | The HEALTH SOFTWARE design shall identify and characterize each interface of the HEALTH SOFTWARE including physical and logical interfaces. As appropriate, the MANUFACTURER identifies as part of the design: a) whether the interface is externally accessible (by other PRODUCTS) or internally accessible – between SOFTWARE ITEMS of the HEALTH SOFTWARE- or both; b) SECURITY implications of the HEALTH SOFTWARE SECURITY CONTEXT on the external interface; c) potential users of the interface and the ASSETS that can be accessed through the interfaces (directly or indirectly); d) whether the static design includes access to interfaces across TRUST BOUNDARIES; e) SECURITY considerations, assumptions and/or constraints associated with the use of the interface within the HEALTH SOFTWARE SECURITY CONTEXT; including applicable THREATS; f) the SECURITY roles, privileges/rights and access control permissions needed to use the interface and to access the ASSETS defined in c); g) the SECURITY CAPABILITIES and/or compensating mechanisms used to safeguard the interface and the ASSETS identified in c) including run-time VALIDATION of inputs as well as handling outputs and errors; h) the use of third-party SOFTWARE ITEMS to implement the interface and their SECURITY CAPABILITIES; i) documentation that describes how to use the interface if it is externally accessible; and j) description of how the design mitigates the THREATS identified in the THREAT MODEL. | | |
| 5.4.4 | Detailed design VERIFICATION for SECURITY | **Describe Peer reviews . What is documented and what was tested exactly?** | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for conducting design reviews to identify, characterize and track to closure WEAKNESSES associated with each significant revision of the secure design including but not limited to: a) SECURITY requirements that were not adequately addressed by the design; b) THREATS and their ability to exploit VULNERABILITIES in PRODUCT interfaces, TRUST BOUNDARIES and ASSETS; c) identification, documentation and characterization of detailed design best-practices that were not followed (5.3.2 and 5.4.1). | | |
| 5.5 | Software unit implementation and VERIFICATION | | |
| 5.5.1 | Secure coding standards | The coding standards from 5.1.3 were applied during the coding activties | |
| 5.5.2 | SECURITY implementation review | Peer review activties ensured:<br />a) the adquate implementation of security requirements and design<br />b) all security requirements and designs were implemented and can be traced down to code<br />c) the coding standards (ref. 5.5.1) were applied Additionally static code analyses (SCA) was performed using **TOOL**<br />D) to determine remaining secure coding errors | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that implementation reviews are performed for identifying, characterizing and feeding into the problem resolution PROCESS all SECURITY-related issues associated with the implementation of the secure design including: a) identification of SECURITY requirements (see 5.2) that were not adequately addressed by the implementation; NOTE Requirements allocation, including SECURITY requirements, is part of typical design PROCESSES. b) identify secure coding standards used and document any parts of the secure coding standards that were not followed (for example, use of banned functions or failure to apply the principle of least privilege); c) Static Code Analysis (SCA) for source code to determine secure coding errors using the secure coding standard for the supported programming language, as established in 5.1.3. SCA is often supported by tools, but it can be done through code inspections and codewalkthroughs. d) review of the implementation and its TRACEABILITY to the SECURITY CAPABILITIES defined to support the SECURITY design (see 5.3 and 5.4); and e) examination of THREATS and their ability to exploit implementation interfaces, TRUST BOUNDARIES and ASSETS (see 5.3 and 5.4). | | |
| 5.6 | Software integration testing | **Integration testing was done in combination with penetration testing since basebox has to be integrated in some applications in order to perfrom those test activties. (Note: the test plan and results are not to be published)** | **correct?** |
| 5.7 | Software system testing | | |
| 5.7.1 | SECURITY requirements testing | **Since basebox is a sw component the comprehensive system testing shall be perfomed by the customer who is integrating basebox. But basebox is providing the list of security requirements (controls) to customers which are relevant for a secure integration of basebox in any system (medical device) and shall be considered therefore during integration and system testing activities perfomed by the customers.** | **correct?** |
| 5.7.2 | THREAT mitigation testing | **Welche verschlüsselungsmaßnahmen und andere spezifische Sicherheitsmassnahmen sind implementiert und wie sind diese getestet** | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for testing the effectiveness of the mitigation for the THREATS identified and assessed in the THREAT MODEL. ACTIVITIES shall include: a) creating and executing adequate testing for each mitigation implemented to address a specific THREAT, in order to ensure that the mitigation works as designed; b) creating and executing plans for attempting to thwart each mitigation; and c) ensuring that the mitigation does not introduce other VULNERABILITIES to the design. | | |
| 5.7.3 | VULNERABILITY testing | **Write list of OTS Components used in basebox (= SBoM) and check vulnarabilities of each one in public libraries and set reference link. Define relevance of each vulnarability for basebox.** | [Hier die Freitext Suche der cve / Mitre Web Seite. Geben Sie z.B. Windos 11 ein erhalten Sie eine lange Liste pot. Vulnerabilties, die dann auf ihre Relevenaz hin analysiert werden müssen](https://cve.mitre.org/cve/search_cve_list.html) |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for performing tests that focus on identifying and characterizing potential SECURITY VULNERABILITIES in the HEALTH SOFTWARE. Known VULNERABILITY testing shall be based upon, at a minimum, recent contents of an established, industry-recognized, public source for known VULNERABILITIES. As appropriate testing shall include: a) abuse case for malformed or unexpected input testing focused on uncovering SECURITY issues. This shall include manual or automated abuse case testing and specialized types of abuse case testing on all external interfaces and protocols. Examples include fuzz testing and network traffic load testing and capacity testing; b) ATTACK SURFACE testing to determine all avenues of ingress and egress to and from the system, common VULNERABILITIES including but not limited to weak access-control-lists (ACLs), exposed ports and services running with elevated privileges; c) “closed box” known VULNERABILITY scanning focused on detecting known VULNERABILITIES in (if applicable) hardware, host, interfaces or SOFTWARE ITEMS; NOTE 1 For example, this could be a network based known VULNERABILITY scan. d) SOFTWARE COMPOSITION ANALYSIS on all binary executable files including embedded firmware, to be used with HEALTH SOFTWARE and delivered by a third-party supplier. This analysis can be used to detect: 1) known VULNERABILITIES in the SOFTWARE ITEMS; 2) linking to vulnerable libraries; 3) SECURITY rule violations; 4) compiler settings that can lead to VULNERABILITIES; and 5) comparison of the software encountered to the software bill of materials. NOTE 2 Tools can support SOFTWARE COMPOSITION ANALYSIS by generating a list of software packages included. e) dynamic SECURITY testing – like e.g. fuzz testing, that detects flaws not visible under static code analysis, including but not limited to denial of service conditions due to failing to release runtime handles, memory leaks and accesses made to shared memory without authentication. This testing shall be applied if such tools are available. | | |
| 5.7.4 | Penetration testing | An independent pentest **which did comprise fuzz testing** was executed by the test lab of the Johner Institute. As mentioned above an integration of basebox in sample applications or systems were done in order to be able to perform the pen testing activities. | |
| 5.7.5 | Managing conflicts of interest between testers and developers | In order to avoid the conflicts of interests between developer and tester in a small team the mentioned external and independent expertise from the Johner Institute and other security experts were consulted. | |
| 5.8.2 | Release documentation | **To be checked by GD when published** | |
| 5.8.3 | File INTEGRITY | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to provide an INTEGRITY VERIFICATION mechanism for all scripts, executables and other SECURITY-relevant files used with a HEALTH SOFTWARE. This ACTIVITY (or ACTIVITIES) is required to ensure that PRODUCT users can verify that executables, scripts, and other important files received from the MANUFACTURER have not been altered. Common methods of meeting this requirement include cryptographic hashes and digital signatures (which also provide proof of origin). | **tbd.** | |
| 5.8.4 | Controls for private keys | **tbd.** | |
| | The MANUFACTURER shall have procedural and technical controls in place to protect private keys used for code signing from unauthorized access or modification. | **tbd.** | |
| 5.8.5 | Assessing and addressing SECURITY-related issues | **tbd.** | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) for verifying that a HEALTH SOFTWARE or an update is not released until its SECURITY-related issues have been addressed and tracked to closure (see 9.5). This includes issues associated with: a) requirements (see 5.2); b) SECURITY by design (see 5.3 and 5.4); c) implementation (see 5.5); d) VERIFICATION / VALIDATION (see 5.5, 5.6 and 5.7); and e) SECURITY defect management (see 9.4). | **tbd.** | |
| 5.8.6 | ACTIVITY completion | Will be part of the basebox adequate Quality Management System based upon ISO 13485 | |
| 5.8.7 | SECURE decommissioning guidelines for HEALTH SOFTWARE | | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to create PRODUCT user documentation that includes guidelines for removing the HEALTH SOFTWARE from use. | **tbd.** | |
| 6 | SOFTWARE MAINTENANCE PROCESS | **A formalized software maintenance process which is in compliance with the IEC 62304 standard will be part of the upcoming basebox adequate Quality Management system. The formalized software maintenance process will consider and establish the security requirements from this standard** | |
| 6.1 | Establish SOFTWARE MAINTENANCE plan | | |
| 6.1.1 | Timely delivery of SECURITY updates | Statement in section 6 applies | |
| 6.2 | Problem and modification analysis | | |
| 6.2.1 | Monitoring public incident reports | Statement in section 6 applies | |
| 6.2.2 | SECURITY update VERIFICATION | Statement in section 6 applies | |
| 6.3 | Modification implementation | | |
| 6.3.1 | SUPPORTED SOFTWARE SECURITY update documentation | Statement in section 6 applies | |
| 6.3.2 | MAINTAINED SOFTWARE SECURITY update delivery | Statement in section 6 applies | |
| 6.3.3 | MAINTAINED SOFTWARE SECURITY update INTEGRITY | Statement in section 6 applies | |
| 7 | SECURITY RISK MANAGEMENT PROCESS | | |
| 7.1 | RISK MANAGEMENT context | | |
| 7.1.1 | General | Basebox is an Off-the-Shelf (OTS) DB component which can be integrated in any device which needs data base functionalility. Basebox has no specific intended use and is not a Medical Device. | |
| 7.1.2 | PRODUCT SECURITY CONTEXT | For that reoson the ISO 14971 requirements are not applicable for basebox. | |
| | The MANUFACTURER shall establish an ACTIVITY (or ACTIVITIES) to ensure that the intended PRODUCT SECURITY CONTEXT is documented. This ACTIVITY (or ACTIVITIES) is required to ensure that the minimum requirements of the environment and the assumptions about that environment are documented in order to achieve the SECURITY level for which the PRODUCT was designed. The purpose of defining this information is so that both the developers of the HEALTH SOFTWARE and the PRODUCT users have the same understanding about how the PRODUCT is intended to be used. This will help the developers make appropriate design decisions and the users to use the PRODUCT as it was intended. The SECURITY CONTEXT could include: a) location in the network; b) physical SECURITY or CYBERSECURITY provided by the environment where the PRODUCT will be deployed; c) isolation (from a network perspective); d) if known, potential impact to SAFETY caused by degradation of SECURITY; e) SECURITY controls implemented in dedicated hardware with which the HEALTH SOFTWARE is intended to be used. For example, it is important to document whether physical SECURITY is required. If no physical SECURITY is expected to be present, then that can add a number of related requirements such as not allowing push-button configuration on the PRODUCT. Another example is if the PRODUCT cannot feasibly (i.e. without reducing SAFETY or performance) implement a firewall of its own, it can be expected to be protected by a user-supplied firewall that connects it to the health-ITnetwork. Documenting these external SECURITY features for the PRODUCT (its SECURITY CONTEXT) allows developers to design a DEFENSE-IN-DEPTH strategy that complements this SECURITY CONTEXT and testers to validate and verify the SECURITY of a PRODUCT in an environment similar to how it is intended to be deployed. Having this PROCESS means that the deployment environment in which the PRODUCT is intended to be used is correctly represented in all PROCESSES involved in the development and testing of this PRODUCT and are documented. | But as oulined along the requirements in the previous sections of this list basebox was developed by applying state-of-the-art practices for security and privacy by design which comprises the complete life cycle of the component. Applying state-of-the-art practices for security and privacy shall help to reduce any cyber risk which might have an impact on health risk once the component ist integrated in a medical device. The referenced information may serve as input to the risk management process which has to be performed by customers: The referenced < document > describes the security context of basebox and provides security rules and controles which shall be applied by customer before integrating basebox in any customer application. | Risk Management inputs: - List of known bugs - SBoM, including the list of evaluated vulnerabilities (cve's) Security rules |
| 7.2 | Identification of VULNERABILITIES, THREATS and associated adverse impacts | Statements in section 7.1 and 7.2 apply | |
| 7.3 | Estimation and evaluation of SECURITY risk | Statements in section 7.1 and 7.2 apply | |
| 7.4 | Controlling SECURITY risks | Statements in section 7.1 and 7.2 apply | |
| 7.5 | Monitoring the effectiveness of RISK CONTROLS | Statements in section 7.1 and 7.2 apply | |
| 8 | Software CONFIGURATION MANAGEMENT PROCESS | **Generic description of CI process here** | |
| | The MANUFACTURER shall establish a general PRODUCT development/maintenance/support PROCESS that includes CONFIGURATION MANAGEMENT with change controls and change history. For SECURITY obligations with HEALTH SOFTWARE already released or in the market, CONFIGURATION MANAGEMENT shall provide the capability to reproduce a list of included external components that are or could become susceptible to VULNERABILITIES. | | |
| 9 | Software problem resolution PROCESS | | |
| 9.1 | Overview | The establishment of an basebox adequate Quality Management System which comprises the post-market activties for basebox is in preparation | |
| 9.2 | Receiving notifications about VULNERABILITIES | The post-market activties will comprise requirements for the sw problem resolution process which will be aligned with the following processes and activties: - receiving customer complaints - performing root cause analysis, also for potential vulenerabilties and, if required, in cooperation with customers - maintaing the threat model - performing corrective and preventive action - informing customers about known vulnerabilties | |
| 9.3 | Reviewing VULNERABILITIES | Statements in section 9.1 and 9.2 apply | |
| 9.4 | Analysing VULNERABILITIES | Statements in section 9.1 and 9.2 apply | |
| 9.5 | Addressing SECURITY-related issues | Statements in section 9.1 and 9.2 apply | |
| Annex A | Informative: Comprises: Relationship to IEC 62443 and IEC 62304, Risk Transfer, Secure coding best practices | | |
| Annex B | Informative: Guidance on implementation of SECURITY LIFE CYCLE ACTIVITIES | | |
| Annex C | Informative: THREAT MODELLING | | |
| Annex D | Informative: Relation to practices in IEC 62443-4-1:2018, Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements | | |
| Annex E | Informative: Documents specified in IEC 62443-4-1 | | |
| Annex F | Normative: TRANSITIONAL HEALTH SOFTWARE | | |