# Elements of an Open-Source Medical Device Project

Your Open Source Medical Device project should include a general description of the hardware’s identity and purpose, written as much as possible for a general audience. That is, explain what the project is and what it’s for before you get into the technical details. A good photo, renderings or general diagram are of high importance.

Priority:
**High** - absolutely necessary in order for the design to be reproducable by others.
**Medium** - complementary files that make design more accessible and easy to replicate.
**Low** - any additional files or information that can be used to faiclitate design imporvement process and collaboration.

| Element | Description | Importance Level
| -------- | -------- | -------- |
| Design Files |These are the original source files that you would use to make modifications to the hardware’s design. The act of sharing these files is the core practice of Open Source Hardware. For complete list of design files, please visit this page: [OSHWA Best Practices](https://www.oshwa.org/sharing-best-practices/) | High |
| Auxiliary Design Files | Beyond the original design files, it is often helpful to share your design in additional, more accessible formats. For example, best practice open-sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs.| High|
| Bill of Materials| it is important to provide a separate bill of materials. This can be a spreadsheet (e.g. CSV, XLS, Google Doc) or simply a text file with one part per line. If your CAD package has integrated or add-on BOM management tools, those are also a good option. (Examples include the built-in tools in SolidWorks and bom-ex for Eagle.) Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part. Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence.| High|
|Photos/Drawings/Diagrams| help people understand what your project is and how to put it together. It’s good to publish photographs from multiple viewpoints and at various stages of assembly. If you don’t have photos, posting 3D renderings of your design is a good alternative. | High|
| Instructions and Other Explanations | In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:(1) making the hardware, (2) using the hardware, (3) design rationale. If someone wants to modify your design, they’ll want to know why it is the way it is. Explain the overall plan of the hardware’s design and why you made the specific choices you did. The instructions could be in a variety of formats, like a wiki, text file, Google Doc, or PDF. Remember, though, that others might want to modify your instructions as they modify your hardware design, so it’s good to provide the original editable files for your documentation, not just output formats like PDF.| High|
|Hosting the Design Files| | |
| License |Popular copyleft licenses include:(1) Creative Commons Attribution, Share-Alike (BY-SA), (2) GNU General Public License (GPL), (3) Hardware-Specific Licenses: TAPR OHL, CERN OHL. Permissive licenses include:(1) FreeBSD license, (2) MIT license, (3) Creative Commons Attribution (BY). Hardware-Specific License: (1) Solderpad Hardware License. It is good practice to include a copy of the license in the version control repository, and a statement in every file or at least the README specifying the author(s) and year(s) of non-trivial modifications, and the license. |High |
| Distrubution| | |
| Building on Open-Source Hardware| | |