Who This Guide Is For and How to Use It
This guide is intended for individuals who are looking to replicate Open Healthware. It assumes general technical competence but does not assume formal training beyond what is specified by the specific documentation for an Open Healthware project.
The goal of this document is to aid reproducers of open healthware in making best use of available documentation. It focuses on what relevant information might be communicated publicly including metadata like intent, limitations, risks, appropriate contexts for use.
This is part of our Best Practices Guides for Open Healthware. You can also explore:
Best Practices for Source of Open Healthware Designs
Best Practices for Contributing to Open Healthware Designs
This guide is not a substitute for regulatory compliance documentation and does not certify devices for clinical use. This guide seeks to answer the question “what are the best practices I should consider if I decide to reproduce an open healthware project”.
Intended Use
Replicating open healthware can play an important role in responding to health emergencies, supporting research, and strengthening local and global supply chains. Open designs make it possible for people in many settings to build, adapt, and deploy medical technologies that might otherwise be inaccessible. At the same time, reproducing healthware is not the same as copying general-purpose hardware. Small mistakes in fabrication, assembly, or interpretation can have real consequences for safety, reliability, and clinical trust. For this reason, replication benefits from being done thoughtfully and with a clear understanding of context.
For example, it is important that replicators clearly understand the intended use and constraints of the device, which can be framed as indication + patient population + clinical purpose. The device may be more appropriate for specific stages of clinical workflows, or have specific sample compatibility constraints, or may have dependencies with other technologies or operator proficiencies that may be important to consider.
For more information on what to look for in the intended use case, intended compatible users, and intended scope of use (i.e., stage of development), check out the corresponding sections in our best practices for designers guide.
Documentation
Selecting well-documented open-source hardware (OSHW) fit for the intended use can mitigate common challenges like ambiguous bills of materials, hidden fabrication assumptions, unsafe material substitutions, undocumented performance limitations, and replication errors that increase cost, delay deployment, or compromise safety. In all use cases (research, self-use, and clinical use). Consider first checking that the Bill of Materials (BOM) is comprehensive and precise, listing all components with specific part numbers, manufacturers, and quantities. Consider that project documentation includes methods for verifying that the replicated device works correctly (i.e., aligns with the OSHWA definition of open source hardware). Consider evaluating whether critical steps are tracked centrally and that revisions are not fragmented (i.e., that you are reproducing the correct and canonical verison of the project).
The level of rigor for evaluation depends on the intended use; a higher-stakes application, like clinical use, requires more stringent vetting (e.g., parts meeting biosafety, sterility, and performance constraints) than lower-stakes applications.
In our guide, we assume that most people will be reproducing projects that require 3D printing, laser cutters, or other typical tools. Consider that certain uses of devices may benefit from regulatory oversight, device approvals, and manufacturing standards as necessary.
Compatibility
Compatibility refers to how well an open healthware design aligns with the intended context of use, available resources, user expertise, and downstream requirements. Even well-documented projects may not be appropriate for every setting, and mismatches between a design and its deployment context are a common source of replication failure or misuse.
For self-use contexts (for example, personal health monitoring or exploratory builds), compatibility often depends on simplicity, transparency, and tolerance to variation. Designs that emphasize ease of assembly, minimal calibration, and clear operating boundaries are generally better suited for these settings. Indicators of good compatibility include a high number of successful independent replications and clear explanations of limitations. In these cases, modifiability may be beneficial, but only when changes do not affect safety-critical functions.
For research use, compatibility extends beyond physical assembly to include reproducibility of measurements and comparability of results. Replicators may consider whether the device has been independently assembled or evaluated by other groups, whether test procedures and calibration methods are documented, and whether performance claims are supported by data. It might be desired that hardware intended for research supports verification and repeatability, including consistent component sourcing, stable interfaces, and documented assumptions. Alignment with FAIR principles (Findable, Accessible, Interoperable, Reusable) is especially important when devices are used to generate publishable or shared datasets.
For clinical or patient-facing use, compatibility requirements are significantly higher. Designs that clearly state their stage of development and whether they are intended for clinical deployment, evaluation, or demonstration can help establish healthy barriers to entry. Replicators can consider looking for evidence of validation testing, risk analysis, and consideration of biosafety, sterility, electrical safety, and failure modes. Regulatory status, such as prior filings or approvals (e.g., FDA, CE marking, MHRA), can provide additional context, but may require careful interpretation, as approvals are jurisdiction- and configuration-specific and may not transfer to replicated builds or modified designs.
Across all contexts, compatibility also includes practical considerations such as availability of materials, fabrication methods, tools, and maintenance requirements. Designs that rely on uncommon materials, tightly controlled environments, or specialized expertise may be less compatible with distributed or resource-constrained settings, even if they are technically open. Assessing compatibility early helps replicators choose projects that align with their capabilities and constraints, reducing the risk of incomplete builds, unsafe adaptations, or inappropriate use.
Substitutions, Modifications, and Adaptations
Sourcing verified components from specified and reputable vendors can preserve intended device performance. Whenever possible, consider prioritizing components explicitly listed in the project’s Bill of Materials (BOM), as these selections often reflect implicit design constraints related to material properties, tolerances, biocompatibility, electrical ratings, or mechanical strength. Deviating from the BOM without understanding these constraints can unintentionally alter device behavior or invalidate validation. Seek to ensure that substitutions demonstrably match original part specifications.
This includes not just nominal values, but relevant ratings such as voltage, thermal limits, mechanical load, chemical compatibility, or sterilization tolerance. Documenting substitutions clearly, including the rationale for the change and any assumptions made can help clarify expectations of performance.
Even seemingly minor substitutions can accumulate into meaningful differences.
Consider verifying access to tools capable of meeting the required precision and repeatability, such as properly calibrated soldering equipment, multimeters, 3D printers, laser cutters, or CNC machines. Replicators can look for well documented tolerances. Inadequate tooling can lead to subtle defects that are difficult to detect but may affect safety or reliability. When a project requires advanced techniques, such as PCB reflow, microfluidics, or precision machining, it may be necessary to seek training, collaborate with experienced practitioners, or use shared facilities rather than attempting improvised solutions. When setting a budget for the replication, consider accounting not only for parts, but also for tools, consumables, maintenance, failed builds, and iteration time.
Community-generated resources, such as forums, issue trackers, and build videos, can provide valuable contextual knowledge and help bridge gaps in formal documentation, especially for replicators working outside institutional or laboratory settings.
The implications of substitutions and adaptations vary by use context.
For research use, consistency of materials and components is particularly important for calibration, repeatability, and long-term reproducibility. Replicators can ensure that reagents, sensors, and other critical elements can be sourced reliably over time and document vendor details to support future replication or comparison. Consider that some vendors might not be available due to supply chain constraints. Leveraging shared research infrastructure, such as clean rooms or precision instrumentation, can improve quality while reducing individual costs but may invoke relevant Institutional safety protocols.
For clinical or patient-facing use, the tolerance for substitution and informal adaptation is much lower. Materials and components can be sourced from suppliers with documented quality systems, such as ISO 13485 compliance, to reduce the risk of counterfeit or substandard parts. Fabrication and inspection tools may need to be properly calibrated, and clinical builds may need to be undertaken only by qualified personnel, often in collaboration with certified manufacturers or laboratories. In these contexts, substitutions or modifications may require formal review and revalidation before use.
Across contexts, documenting the assembly process is essential. Maintaining a transparent record of how a device was built, including deviations from the original design, supports traceability, reduces the risk of error, and enables others to learn from and improve upon the work.
For research environments, this may take the form of dated build logs or assigned roles and sign-offs. For clinical contexts, more formal records, such as Device History Records (DHRs), may be required, potentially including independent review or approval to ensure compliance with applicable standards.
Testing and Quality Assurance
Once assembled, an essential practice is testing the device to ensure it works as intended. If provided, documentation around testing, validation, and quality assurance (e.g., checking voltages, calibrating sensors) can be followed to verify expected outputs. Testing frequency and intensity can follow documentation, or industry standards for the device. Consider publishing results of testing, and documenting the need for additional appropriate testing documentation publicly so that others may benefit.
