---
tags: Repository Standards
---
# Proposed structure and elements for open source medical device repositories

[ToC]

## Notes
Goals of the repository structure and contents: to contain all information required to efficiently and ergonomically allow:
1) other developers to adapt and contribute to the project
2) other manufacturers to fully replicate the device and the associated processes (quality control, regulatory approval, distribution, post market monitoring, etc.)
3) generation of document packages reguired for regulatory submissions and other common needs

2. commercial companies that develop large numbers of devices probably have a version of this kind of framework built into their project management systems.

## Contents
### General Open Hardware Items (OSHWA guidelines)

### Additional Components
1. Technology Readiness Level tracker (may eventually be an automated indicator based on the content of the archive, with some documents assigned to specific level)
2. A document containing an outline and review of relevant health regulatory and technical standards requirements; document tracking of their fulfilment

## Structure

Open Source Hardware:

Documenatation included in this repository outlines recommendations provided by the [Open Source Hardware Association](https://www.oshwa.org/about/), [Open Source Initiative](https://opensource.org/about), and [GitHub Best Practices](https://resources.github.com/videos/github-best-practices/).

## Hardware/Software Definitions & Criteria

Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design. The hardware’s source, the design from which it is made, is available in the preferred format for making modifications to it. Ideally, open source hardware uses readily-available components and materials, standard processes, open infrastructure, unrestricted content, and open-source design tools to maximize the ability of individuals to make and use hardware.

*For complete description of all criteria use active link provided below.*

> [**Criteria:**](https://www.oshwa.org/definition/)
> 1. Documentation
> 2. Scope
> 3. Necesaary Software
> 4. Derived Works
> 5. Free Distribution
> 6. Attribution
> 7. No Discriminaton Against Persons or Groups
> 8. No Discrimination Against Fields of Endeavour
> 9. Distribution of License
> 10.License Must Not Be Specific to a Product
> 11. License Must Not Restrict Other Hardware or Software
> 12. License Must Be Technology-Neutral
>

Open source software is software whose design is made publicly available so that anyone can study, modify, distribute the software to anyone and for any purpose.

*For complete description of all criteria use active link provided below.*

> [**Criteria:**](https://opensource.org/docs/osd)
> 1. Free Redistribution
> 2. Source Code
> 3. Derived Works
> 4. Integrity of The Author's Source Code
> 5. No Discrimination Against Persons or Groups
> 6. No Discrimination Against Fields of Endeavor
> 7. Distribution of License
> 8. License Must Not Be Specific to a Product
> 9. License Must Not Restrict Other Software
> 10. License Must Be Technology-Neutral

## Open Source Medical Devices

The design composition of modern medical devices adds a level of complexity associated with open source distribution of such devices. Some open spurce medical devices such as the 3d printed stetoscope shared by GLIA rely on simple design that can operate without software, while others, like emergency ventilators can operate only in combination with robust and reliable software system that is integrated with the hardware. In this repository, we attempt to provide a complete summary of best practices relevant to sharing and distribution of open source medical device designs.

## Elements of an Open-Source Medical Device Project

The folwoing checklist is provided as a recommendation. As a designer and distributor, you are not required to share all elements. However, it is important to consider that complete and well described projects are more likely to benefit the community and gain interest of deveopers that may want to adopt it or furtehr better the design.

Checklist Link

Notes:
* Add information about user expereince design principles (i.e. usability manuals, maintenance, transport, etc., etc.)
* Talk about risk assessment relevace