Who This Guide Is For and How to Use It
This guide is intended for individuals who are looking to publish open-source health hardware or Open Healthware. 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 transparent, and responsible publication of open healthware designs. It focuses on what information should be communicated publicly in addition to what is listed in the definition of open hardware, so that others can understand a device’s design, assembly, and validation, along with metadata like intent, limitations, risks, appropriate contexts for use.
This guide is not a substitute for regulatory compliance documentation and does not certify devices for clinical use. Each section highlights a class of information that should be documented when publishing source for an open healthware project. This guide seeks to answer the question “what are the best practices around the documentation my open healthware project should have”, not with an exhaustive list, but with some of the factors that the healthware community has raised.
However, for more detailed specifics check out our How We Got Here article.
Intended Use Case
Communicating the intent behind your healthware design is a critical step towards fostering trust, ensuring safe and appropriate use, and supporting potential users in making informed decisions about your design. Intended use can be framed as indication + patient population + clinical purpose. When communicating the intended use case, try to distinguish intended use (why) from intended user (who) and indications for use (what condition), and seek to use well-established terminology to classify the intended use (see OSHWA healthware categories).
Examples:
When releasing an open-source diagnostic device, important considerations in communicating its intended use may include the relevant clinical workflow stage when the device is appropriate (screening, triage, diagnosis, monitoring, confirmatory testing), as well as the specimen type and handling assumptions (venous blood, capillary blood, sputum, stool filtrate, swab), and dependencies for use, both upstream (e.g., sample prep) and downstream (e.g., confirmatory PCR). This consideration might also include delineating what the device is not intended to do (e.g., "Not for malaria species differentiation," "Not for neonatal diagnosis").
Detailed intended use information may also include listing safe environmental exposure conditions, including humidity range, lighting requirements, vibration sensitivity, biosafety level constraints, and validated performance limitations (e.g., “validated only for parasitemia ≥0.1%”).
Potential users may also benefit from knowing the intended expertise, training, or skills involved and any PPE needed for safe operation (e.g., <30-min onboarding for healthcare workers, trained microscopist for reading slides).
Communicating hazards related to the intended use (e.g., false-negative triage, reagent misuse, optical misalignment causing diagnostic shifts) can also help build trust.
Consider providing example clinical scenarios where use is appropriate, including linking intended use to known clinical guidelines (CLSI, WHO diagnostic algorithms).
Target Group / User Population
Along with the intended use case, another important feature to consider and communicate with your open healthware design is the intended target group / user population. This may refer to 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.
Key characteristics of target clinical user populations may include physiological or anatomical constraints relevant to device accuracy (skin tone reflectance, limb circumference, RBC morphology variability). Other exclusion criteria that may affect safety or validity could include severe anemia, neonates, patients with implanted devices, intolerances to adhesives or pressure cuffs.
Key characteristics of operator populations (licensed clinician, lab technologist, community health worker, lay caregiver), may include training or competency requirements (e.g., smear-prep experience, ability to recognize device error states), and may require consideration of cognitive load, literacy level, and expected familiarity with medical workflows. It may be important to communicate human-factors constraints including operator capabilities and limitations (vision correction needs, color discrimination issues, hand tremor, low dexterity), as well as features designed for accessibility (screen-reader compatibility, tactile guidance, large-button UIs). You may also consider identifying user-specific error modes (e.g., incorrect slide loading by novices, improper sample volume from healthcare workers).
Potential users can make better informed decisions when the link between the target user population and their typical environment is made explicit (rural healthcare workers vs. hospital lab techs; high-noise field environments vs. controlled benches). Understanding stressors affecting the operator (fatigue, heat, gloves affecting dexterity), and language, cultural, or workflow norms that influence safe interaction may improve adoption and reduce adverse events. Likewise, it is important to account for such factors in the design process, including accounting for older adults, users with reduced dexterity, and visually impaired users where applicable and addressing physiological diversity (darker/lighter skin imaging, pediatric vs. adult geometry, hair density, moisture levels).
Stage of Development
An important factor to consider communicating is the current state of development of the open healthware project. This refers to the level of maturity the completed design has reached, including devices for research, clinical, or personal use, devices in the prototype, or pilot study stage, devices under review for safety and efficacy, and devices formally approved by regulatory agencies like the US FDA. Stating this level can help downstream users understand the reliability of the device and the context in which it is most appropriately used.
The state of development for healthware can also reflect the type and extent of evidence for its ability to impact health. Early-stage designs may show functional feasibility but may not yet have data on repeatability, healthcare worker / operator variability, performance across healthcare environments, or use with real health specimens. More mature designs may have undergone limited or extensive field evaluation, simulated-use studies, or performance checks with representative health contexts. It can be useful to support the stage of development description with the forms of validation that have been completed and which have not. It may also be valuable to specify how the device is intended to be used at its current stage. A healthcare prototype may be suitable for experimentation, teaching, or feasibility studies in medical or biomedical engineering fields. A field-tested design may be appropriate for supervised use or exploratory applications in biomedical laboratory science. A more mature version may be suitable for routine medical procedures when supported by adequate instructions and calibration steps.
Verification and Validation (V&V)
Two complementary elements are useful to address when communicating the reliability of an open healthware project: how the device is expected to perform when functioning correctly, and how its potential failure modes have been considered. Together, these form a practical view of validation and verification that supports safe and informed adoption. The first component involves defining what correct performance looks like. This includes releasing the detailed firmware or embedded software that directly affects device behavior, safety, and measurement validity. Clear documentation of the firmware’s role in the system, including versioning, configuration parameters, update mechanisms, and any safety-critical logic (e.g., thresholds, timing constraints, or interlocks), build environments, dependencies, and toolchains can be specified to support reproducibility. For more information on firmware releases, see Sharing Best Practices. Further, this may include reference outputs such as example images, signal traces, calibration targets, or benchmark values that reflect expected behavior under normal operation. This may also include a preliminary Failure Modes and Effects Analysis (FMEA) early in the design process. This can help clarify intended function, identify safety-critical components, and guide engineering decisions before implementation is complete. A simple table identifying failure modes, causes, effects, severity, and mitigations can meaningfully improve design quality and documentation clarity.
Providing calibration steps, environmental conditions for testing, and representative datasets allows others to compare their results to known baselines. Any acceptable ranges of variation, as well as conditions that are known to distort results, help derivative developers and users understand the robustness of the design. Clear articulation of expected outputs can also guide troubleshooting and prevent misinterpretation during early adoption or reuse.
The second component involves documenting how the project team has thought about risk and potential failure. This may include identifying technical failure modes, user-related errors, environmental stressors, or biological variability that could affect safety or accuracy. Describing the severity and likelihood of these risks, along with any mitigations such as alignment aids, guided workflows, or safety checks, provides a clearer picture of the device’s reliability. It can also be useful to indicate how adverse events or unexpected behaviors should be reported, and to maintain a publicly accessible record of known issues that may affect performance. The rigor of testing can be prioritized and scaled according to the risk associated with a particular component or function; high-risk failures (e.g., in a life-supporting function) require more intensive testing than lower-risk cosmetic issues. This information helps users, researchers, and implementers make more informed decisions about the suitability of the design for their intended context and encourages responsible improvement within the open healthware community. pad this out to include more specific claims about data standards and how experiments and data should be reported.
An important aspect to consider is adoption of recognizable data-reporting conventions. These might include describing measurement repeatability with appropriate summary statistics, reporting limits of detection or resolution using standard analytical methods, and indicating sample sizes used in testing. For image-based devices, specifying the imaging pipeline, preprocessing steps, and key parameters influencing contrast or resolution can clarify how visual outputs should be interpreted. When feasible, making datasets and analysis tools openly available contributes significantly to reproducibility and community evaluation. When reporting testing related to failure modes, it can also be useful to provide structured descriptions of the test conditions, data collection procedures, and criteria used to classify outcomes. This may include filtered versus unfiltered data, environmental monitoring logs, operator training level, or details that clarify how consistent the testing environment was. Including incomplete or negative results, when available, helps prevent other users from repeating conditions known to fail or degrade performance.
For more information, check out our guide for Best Practices on Quality Assurance in Healthware [Coming soon!].
Safe Use and Handling
Documentation around safe use and handling helps to ensure that an open healthware device performs consistently and can be operated without unnecessary risk. Sharing information on how the device should be cleaned, prepared for reuse, maintained, and applied in routine settings gives users a clearer sense of where the device fits and helps reduce the likelihood of harm or inaccurate results. If your device has been approved by a regulatory body, including any pertinent information to the safety of the device that was collected by the regulatory body in the application process is a best practice to include in the source.
Information on sterilization and reprocessing is often especially useful. Devices that come into contact with biological material or rely on clean surfaces for accurate measurements benefit from clear guidance on compatible decontamination methods, such as autoclaving, ethylene oxide treatment, or ultraviolet exposure. Further, communicating details like how to remove and package a device from a print bed that has been sterilized in the printing process is a best practice to be considered. Some components tolerate repeated sterilization, while others may be better treated as single-use to avoid degradation or contamination. If any testing has been done to confirm that cleaning does not alter performance, briefly summarizing those results can help users understand what to expect. It is also helpful to point out known limitations, such as materials that warp with heat or surfaces that break down after repeated chemical cleaning, so users know what to avoid.
Clear usage guidelines contribute to safe operation as well. These can include essential steps such as specimen handling, alignment or calibration checks, device placement, and basic interpretation of outputs. Highlighting behaviors that should be avoided can prevent unsafe practices or misleading readings. Environmental factors, including lighting conditions, temperature range, or sensitivity to vibration, may influence performance and are worth noting when relevant. Patient-specific considerations, such as contraindications or sensitivities, also help users apply the device appropriately in a variety of settings.
Deployment & Legacy Plan
If you intend to manufacture your device at scale here are some best practices. Consider establishing active, stakeholder-driven post-market surveillance, including actively engaging users, including clinicians, patients, and technicians to capture a complete picture of the device's real-world performance. Collecting post-market data can enhance R&D and design, and establish a transparent complaint handling system including Medical Device Reports (MDRs) to build trust and transparency. Regardless of plans to manufacture your device, consider putting a legacy plan in place to ensure that the open healthware project remains transparent, usable, and safe throughout its entire lifecycle even if the original developers are no longer maintaining it. The goal of a legacy plan is to preserve continuity, clarity, and compliance. It communicates to users, collaborators, and regulators: who is responsible for maintaining the project and its documentation, how often maintenance and updates are expected, how community input will be received, reviewed, and integrated, what happens when the project reaches end-of-life or loses active maintainers. This transparency helps prevent “orphaned” medical devices by ensuring that every stage of the device’s existence is responsibly managed.Your legacy plan might not include substantial steps beyond publishing the design documentation. That strategy should still be made clear so that others can make informed decisions. Define the intended operational lifespan of the device and its supporting software. Document the dependencies (e.g., libraries, mechanical components, suppliers) - often called the bill of materials for hardware projects - and the risks associated with obsolescence. Include expected support duration (e.g., “Active maintenance through 2028”), key contributors and responsible organizations. Consider including spec sheets on bill of material parts if available. Finally, outline how to safely retire the device once it reaches the end of its useful life.
