Who This Guide Is For and How to Use It
This guide is intended for individuals who are looking to contribute to existing Open Healthware projects. It assumes general technical competence but does not assume formal training in medical device regulatory processes or quality systems. The goal of this document is to support community engagement and foster productive collaboration over open healthware designs. It focuses on what contributors should be aware of when engaging with Open Healthware projects. This guide is not a substitute for regulatory compliance documentation and does not certify devices for clinical use.
For more detailed specifics on the Healthware Certification check out this post
You can find out Best Practices for Source of Open Healthware Designs Guide here
Project Selection
In this guide, we outline strategies that help maintainers and contributors responsibly contribute and help sustain the OSH ecosystem. People contribute to open source healthware (OSH) for different reasons. Some contribute to help solve a health or medical problem they personally face or encounter in their community. Others contribute through professional roles, such as researchers, clinicians, or engineers advancing scientific knowledge or practice. A third group consists of students and early-career contributors focused on learning, skill development, and demonstrating impact.
Contributors motivated by personal or community health needs may prioritize projects with clearly defined use cases, documented validation or verification protocols, and evidence of real-world testing or deployment. One strategy researchers, clinicians, and professional developers may use to identify projects is literature review, focusing on areas where open tools could address known gaps.
Projects with high potential impact but limited development or maintenance, including early-stage or archived efforts, often present valuable opportunities for meaningful contributions. Students and early-career contributors benefit from projects with clear onboarding paths, accessible technical requirements, and visible real-world relevance. Selecting projects that allow for sustained, long-term involvement helps build skills while contributing to outcomes that matter.
Review the Documentation
Several key features of OSH documentation can help direct and enhance contributions.
The intended use case, possibly framed as indication + patient population + clinical purpose, (e.g., "Not for malaria species differentiation," "Not for neonatal diagnosis") can direct appropriate and contextualized contributions. Contributions may then be grounded in the intended expertise, training, or skills involved, any PPE needed for safe operation, hazards related to the intended use (e.g., false-negative triage, reagent misuse, optical misalignment causing diagnostic shifts)..
The intended target group / user population of clinical user populations (symptoms, age ranges, comorbidities), and/or to the operator categories of clinicians or practitioners for whom the device is intended for optimal use can likewise be of assistance. Physiological or anatomical constraints may be relevant to device accuracy (skin tone reflectance, limb circumference, RBC morphology variability), and exclusion criteria may affect safety.
The stage of development, referring to the level of maturity the completed design has reached (e.g., research, clinical, or personal use, devices in the prototype, pilot study, or regulatory review stage) can communicate what kinds of contributions have the potential for highest impact. Well-established devices may benefit most from clarifying contributions, whereas incomplete or archived devices may benefit from re-design. Also, consider reporting the stage of development of your fork or branch of the device, to similarly help others.
Following Validation protocols, and data-reporting conventions reported in the device repository can help contextualize your contributions, so that users can quickly understand if your contribution represents a significant deviation in the function of the device. Consider reporting any changes around safe use and handling that are introduced by your contributions, so users can make informed decisions and reduce risk.
Engaging with Original Healthware Designers
Engaging with original designers gracefully can help to understand where contributions are most needed. This can include observing or participating in the project's communication channels, (e.g., GitHub Discussions, Slack, or mailing list), studying the README.md, and reviewing documentation. It can also help to drive discussion, feedback, and acknowledgement of your contributions. Presence of a CONTRIBUTING.md file indicates that the project has a documented process for on-boarding new contributors.
Some open-source healthware may adhere to a "design freeze", where the design is finalized and “frozen” - this is done to ensure safety through reliability and repeatability, and may be relevant for groups seeking formal validation and regulatory submissions. The design freeze process is crucial for patient safety and regulatory compliance; A design freeze is similar to a stable version or release, where modifications, derivatives, and updates result in a new version with separate documentation needs.
This concept is similar to how the US FDA addresses new and “substantially equivalent” designs, which have unique reporting requirements for approval to market and distribute the device for human use but are not required to undergo an initial pre-market approval analysis. Important contributions before design freeze include adding to the risk management plan, suggesting tests or practices to catch failures early in production, helping define or clarify user needs (especially if you can speak to the needs of the affected community credibly), testing early stage designs with production materials and processes, or suggesting clarifications or revisions to contribution guidelines in a CONTRIBUTING.md file.
After the design freeze, contribute by suggesting revisions via communication channels, or following the formal design change control process possibly outlined in the project's CONTRIBUTING.md file.Consider shifting to formal validation of whether the device meets user needs and intended use in its final form. This may involve benchtop testing, simulated use, or clinical studies.
