Adds regulations documents

documentation/regulatory/.gitignore

@@ -0,0 +1,2 @@
+tmp
+release

documentation/regulatory/Makefile

@@ -0,0 +1,42 @@
+SHELL := /bin/bash -o pipefail -e
+.SUFFIXES:
+.SECONDARY:
+.DELETE_ON_ERROR:
+
+CONFIG := config.yml
+DATA_FILES := $(wildcard data/*.yml)
+SRC_MDS := $(wildcard documents/**/*.md documents/*.md)
+RELEASE_MDS := $(patsubst documents/%.md,release/%.md,$(SRC_MDS))
+RELEASE_PDFS := $(patsubst documents/%.md,release/%.pdf,$(SRC_MDS))
+RELEASE_DOCS := $(patsubst documents/%.md,release/%.docx,$(SRC_MDS))
+
+all: $(RELEASE_MDS)
+
+pdfs: $(RELEASE_PDFS)
+
+docs: $(RELEASE_DOCS)
+
+release/%.md: documents/%.md $(CONFIG) $(DATA_FILES)
+	@mkdir -p $(@D)
+	rdm render $< $(CONFIG) $(DATA_FILES) > $@
+
+release/%.pdf: release/%.md pandoc_pdf.yml template.tex
+	@mkdir -p $(@D)
+	pandoc --defaults=./pandoc_pdf.yml $< -o $@
+
+release/%.docx: release/%.md pandoc_docx.yml
+	@mkdir -p $(@D)
+	pandoc --defaults=./pandoc_docx.yml $< -o $@
+
+# useful for debugging
+release/%.tex: release/%.md pandoc_pdf.yml template.tex
+	@mkdir -p $(@D)
+	pandoc --defaults=./pandoc_pdf.yml -t latex $< -o $@
+
+# Manually call recipe to pull down your development history
+data/history.yml:
+	rdm pull $< > $@
+
+.PHONY:
+clean:
+	rm -rf tmp release

documentation/regulatory/config.yml

@@ -0,0 +1,11 @@
+md_extensions:
+  - 'rdm.md_extensions.SectionNumberExtension'
+  - 'rdm.md_extensions.VocabularyExtension'
+    #- 'rdm.md_extensions.AuditNoteExclusionExtension'
+
+# The repository location within the project management tool
+repository: user/repository
+
+project_management_backend: 'rdm.project_management.GitHubIssueBackend'
+
+reviews_required: True

documentation/regulatory/data/definitions.yml

@@ -0,0 +1,19 @@
+Activity: A set of one or more interrelated or interacting tasks. An activity has an input, an output, and often an explicit verification task. Records of activity outputs must be available in case of an audit.
+Software System: All of the software in the project.  The software system is decomposed into **software items**.
+Software Item: >-
+  A module within the software system which may further decomposed into smaller
+  software items. The **software system** is itself a software item, and thus
+  the software items for a hierarchy. See the software design specification for
+  a description of how the software system is decomposed into smaller software
+  items.
+Software Unit: A software item which is not further subdivided.
+SOUP: >-
+  **Software of unknown provenance**, also known as "off-the-shelf software",
+  is a **software item** that has not been developed for the purpose of being
+  incorporated into the medical device and for which adequate records of the
+  development processes are not available.
+Problem Report: A record of actual or potential behavior of a software product that a user or other interested person believes to be unsafe, inappropriate for the intended use or contrary to specification.
+Known Anomaly: A problem report that we do not plan on addressing.
+Change Request: A documented specification of a change to be made to the software system.
+Software Requirement: A particular function that the software must support, or some other constraint that the software must fulfill.  Requirements describe the *what*, while specifications and designs describe the *how*.
+Record: A special type of document that states the results achieved or provides evidence that activities were performed. Unlike other documents---such as this software plan---records are not usually revised after being approved.

documentation/regulatory/data/device.yml

@@ -0,0 +1,35 @@
+# This data file contains details about your medical device.
+
+# The trade name of the device
+name: "Device Name"
+
+# The legal name of the device's manufacturer
+manufacturer: "Manufacturer, Inc."
+
+# The current release number for the device
+version: "v0.1.0"
+
+# What is the FDA's software Level of Concern?
+# "Minor" - Failures or latent design flaws are unlikely to cause any injury to
+#    the patient or operator.
+# "Moderate" - A failure or latent design flaw could directly
+#    result in minor in jury to the patient or operator.  The level of concern
+#    is also Moderate if a failure or latent flaw could indirectly result in
+#    minor injury to the patient or operator through incorrect or delayed
+#    information or through the action of a care provider.
+# "Major" - A failure or latent flaw could directly result in
+#    death or serious in jury to the patient or operator. The level of concern
+#    is also Major if a failure or latent flaw could indirectly result in death
+#    or serious injury of the patient or operator through incorrect or delayed
+#    information or through the action of a care provider.
+level_of_concern: Moderate
+
+# What is the IEC62304 safety classification of the entire system?
+# "A" - No injury or damage to health is possible
+# "B" - Non-serious injury is possible
+# "C" - Death or serious injury is possible
+safety_class: B
+
+# Is this software part of a medical device or is it Software as a Medical
+# Device (i.e., SaMD)?
+samd: true

documentation/regulatory/data/history.yml

@@ -0,0 +1,35 @@
+change_requests:
+- id: '1'
+  title: Feature Change Request
+  content: A description of the requested changes should go here.  Usually,
+    this data is periodically pulled out of a separate project management tool,
+    such as github
+  is_problem_report: false
+  change_ids:
+  - '1'
+- id: '2'
+  title: Problem Report
+  content: A problem report may or may not also be a change request.  If the
+    reported problem doesn't require changes, then it is just a "known anomaly"
+    that won't be addressed.  If it does require changes, it also acts as a
+    change request.
+  is_problem_report: true
+  change_ids: []
+changes:
+- id: '1'
+  content: Implement Feature Request
+  approvals:
+  - id: '100'
+    reviewer:
+      name: David Giese
+      id: '400'
+    content: '
+      - [x] Implements change request
+      - [x] Consistent with software system design
+      - [x] Documentation: N/A
+      - [x] Unit tests
+      - [x] Risk assessment: added appropriate risks
+      - [x] Integration tests: N/A'
+  authors:
+  - name: Yujan Shreshta
+    id: '401'

documentation/regulatory/data/integration_test_record.yml

@@ -0,0 +1,20 @@
+# rdm translate utility can be used to generate YANL files from gtest, xunit or qttest xml output files.
+TestClass.TestName100:
+  message: null
+  name: TestClass.TestName1
+  result: pass
+  req_ids: [SR-13, SR-14]
+TestClass.TestName200:
+  message: "Assertion failed: 127 != 0"
+  name: TestClass.TestName1
+  result: fail
+  req_ids: [SR-17]
+  note: 'It is okay that this test failed because of XYZ'
+TestClass.TestName300:
+  message: null
+  name: TestClass.TestName1
+  result: pass
+  req_ids: [SR-17]
+
+
+

documentation/regulatory/data/manual_tests.yml

@@ -0,0 +1,14 @@
+- name: ManualTest1
+  steps:
+    - step: 5
+      result: pass
+      req_ids: [SR-18]
+    - step: 6
+      req_ids: [SR-19]
+      result: fail
+      note: 'Allowed because of XYZ'
+- name: ManualTest2
+  steps:
+    - step: 1
+      result: pass
+      req_ids: [SR-11, SR-12]

documentation/regulatory/data/predicate.yml

@@ -0,0 +1,20 @@
+# This data file contains details about your predicate device.
+# It is only relevant if you're planning on filing a 510(k) with the US FDA.
+
+# The tradename of the predicate device
+name: "Predicate Device Tradename"
+
+# The 510(k) number
+number: "Kxxxxxx"
+
+# The legal manufacturer of the device
+manufacturer: "Predicate Device Manufacturer"
+
+# The model number of the device
+model: "Predicate Device Model Number"
+
+# The FDA product code
+product_code: "XYZ"
+
+# The related FDA regulation number
+regulation_number: "21 CFR XXX.XXXX"

documentation/regulatory/data/requirements.yml

@@ -0,0 +1,22 @@
+- id: r-1
+  title: First Example Requirement
+  system_requirements: [SR-6]
+  description: A brief description of the requirement; should use the world "shall".  If the software is a "software only device", then no "system_requirements" are necessary---you can remove these keys completely.  They are only necessary for medical devices with a hardware component.
+  specifications: |
+      The specification should describe *how* the requirement is met.  Thus, the requirement is the *what* and the specification is the *how*.
+
+      Specifications are written using github-flavored markdown.
+- id: r-2
+  title: Second Example Requirement
+  system_requirements: [SR-6, SR-11]
+  description: Requirements describe what the software needs to do, and not how.
+  specifications: |
+      Another specification goes here.
+- id: r-3-1
+  title: Third Example Requirement Nested Id First Item
+  system_requirements: [SR-4]
+  description: Requirements should be verifiable (e.g., testable).
+- id: r-3-2
+  title: Fourth Example Requirement Nested Id Second Item
+  system_requirements: [SR-4, SR-7]
+  description: Requirements can be written using markdown.

documentation/regulatory/data/risk.yml

@@ -0,0 +1,48 @@
+risk_levels:
+    - label: Low
+      description: Acceptable
+    - label: Medium
+      description: Investigate further risk reduction
+    - label: High
+      description: Unacceptable
+risk_probability_levels:
+    - label: Low
+      description: Unlikely
+    - label: Medium
+      description: Somewhat likely
+    - label: High
+      description: Likely
+risk_severity_levels:
+    - label: Negligible
+      description: Inconvenience or temporary discomfort
+    - label: Minor
+      description: Results in temporary injury or impairment not requiring professional medical intervention
+    - label: Serious
+      description: Results in injury or impairment requiring professional medical intervention
+    - label: Critical
+      description: Results in permanent impairment or life-threatening injury
+    - label: Catastrophic
+      description: Results in patient death
+risk_acceptability_matrix:
+    - [Low, Low, Low, Low, Low]
+    - [Low, Low, Low, Low, Medium]
+    - [Low, Low, Low, Medium, Medium]
+    - [Low, Low, Medium, Medium, High]
+    - [Low, Medium, Medium, High, High]
+risks:
+    - hazard: Incorrect information
+      software_item: Annotation Metric Calculator
+      events: |
+          - A software defect in the Annotation Metric Calculator causes the
+            size an annotated tumor to be significantly under-estimated
+          - The radiologist fails to notice the discrepancy
+      hazardous_situation: The oncologist is presented with incorrect tumor sizes
+      harm: An inappropriate therapy is given to the patient
+      severity: Catastrophic
+      probability: Low
+      control_measures: null
+      residual_severity: null
+      residual_probability: null
+      notes: Although it is not possible to estimate the probability of the
+          software defect occurring, it is unlikely that the radiologist would not
+          noticed the discrepancy.

documentation/regulatory/data/soup.yml

@@ -0,0 +1,13 @@
+- title: Example Camera SDK
+  manufacturer: Basler AG
+  version: "5.3.1"
+  purpose: |
+      To allow us to configure, control, and retrieve images from our cameras.
+  requirements: |
+      Linux kernel version 3.x or higher
+  anomaly_reference: https://example.url/pointing/to/issue/list
+- title: FFTW
+  version: "3.3.5"
+  purpose: |
+      To calculate the Fast Fourier Transform.
+  anomaly_reference: https://github.com/FFTW/fftw3/issues

documentation/regulatory/data/unit_test_record.yml

@@ -0,0 +1,14 @@
+# rdm translate utility can be used to generate YANL files from gtest, xunit or qttest xml output files.
+TestClass.TestName1:
+  message: null
+  name: TestClass.TestName1
+  result: pass
+  req_ids: [SR-12]
+TestClass.TestName2:
+  message: null
+  name: TestClass.TestName1
+  result: fail
+  req_ids: [SR-12]
+  note: 'It is okay that this test failed because of XYZ'
+
+

documentation/regulatory/data/versions.yml

@@ -0,0 +1,12 @@
+- date: 1-1-2040
+  release_id: v1.0
+  changes:
+      - Add major new feature X.
+      - Add major new feature Y.
+      - Several bug fixes related to ZZZ.
+- date: 5-5-2039
+  release_id: v0.1
+  changes:
+      - Add major new feature A.
+      - Add major new feature B.
+      - Several bug fixes related to CDE.

documentation/regulatory/data/workflow.yml

@@ -0,0 +1,15 @@
+# The IEC62304 standard version
+version_of_62304: "IEC62304:2006+A1:2015"
+
+# The location where the system requirements are stored; only used if
+# `device.samd` is false.
+system_requirements_location: "SYSTEM REQUIREMENTS SOFTWARE"
+
+# The location where risk analysis outputs are stored
+risk_management_file: 'RISK MANAGEMENT FILE LOCATION'
+
+# The location where user feedback is stored, e.g. "GitHub Issues".
+feedback_location: "USER FEEDBACK LOCATION"
+
+# Your Git host (e.g., "GitHub", "GitLab", or "BitBucket")
+git_host: "GitHub"

documentation/regulatory/documents/architecture_design_chart.md

@@ -0,0 +1,12 @@
+---
+id: ADC-001
+revision: 1
+title: Architecture Design Chart
+---
+![CSC Logo](./images/CSC-logo.png)
+
+# Note
+
+Our architecture design chart is included within our Software Design Specification.
+
+[[:This is required by the FDAGeneralSoftwareGuidance]]

documentation/regulatory/documents/hazard_analysis.md

@@ -0,0 +1,20 @@
+---
+id: HA-001
+revision: 1
+title: Device Hazard Analysis
+---
+![CSC Logo](./images/CSC-logo.png)
+
+# Purpose
+
+This document presents our hazard analysis for {{ device.name }}.
+
+[[FDA-CPSSCMD:device-hazard-analysis]]
+
+# Scope
+
+This document applies to {{ device.name }} release {{ device.version }}.
+
+# Hazard Analysis
+
+TODO: pull in risk analysis data and present it in a table here

documentation/regulatory/documents/known_anomalies.md

@@ -0,0 +1,12 @@
+---
+id: KNANOM-001
+revision: 1
+title: Known Anomalies
+---
+![CSC Logo](./images/CSC-logo.png)
+
+# Note
+
+Our unresolved anomalies are included within our Release History.
+
+[[:This is required by the FDAGeneralSoftwareGuidance]]