Over the past year, OSHWA has been working toward a dedicated certification pathway for open source health and medical hardware, otherwise known as an Open Healthware certification. Today, we’re excited to share the story behind the Open Healthware Certification—why it exists, how it was created, and what comes next.
What Did We Do?
In short, we created a new healthware certification that builds upon the existing open hardware certification. More specifically, we developed the Open Healthware Certification to address the unique challenges and responsibilities associated with health and medical technologies. It was determined by our participants that a more robust source was necessary to share for Open Healthware than standard open source hardware. This certification is designed to help people make informed choices, through the creation of a project based database that focuses on strong documentation, replicability, and transparency—qualities that are especially critical when hardware directly impacts people’s health and safety.
Community elements most commonly asked for in a Health label of the Open Hardware Certification is including the BOM in source documents as well as the intent of use. Those pieces of source will be required in the certification. Other pieces of source, such as a hardware’s legacy plan, QMS testing data, and sterilization plans are required if a creator were to have them. Since we are dealing with a broad swath of health hardware, from band-aids to implantable devices, our community is requesting a flexible certification that can cover all device classes and types. The full list of items that are included in the new Open Healthware certification can be found below:
General Open Healthware Source:
Intended use case: Please describe the intended situation(s) of use or use case for this project
Target group: Please describe the intended group of impact for your project and the classification of your project
Risk class, and region-specific compliance expectations reference document (FDA, CE, etc.)
Include state of development aka regulatory intent (e.g: research or end user/product grade device/project)
Critical Design Thinking Notes: Please provide a repository link to documentation about project critical design notes / Useful/important information (E.g: Notes about materials that cannot be replaced, necessary orientation of 3D prints to ensure project success, etc.)
BOM (bill of materials): Provide a link to the bill of materials (BOM) for this project including manufacturer and manufacturer part number
Testing data / Testing Verification: Please provide link that shows what your project should be outputting or doing, if made correctly
Risk assessment / Analysis: Please provide link estimating, assessing, and plans for mitigating the risks and potential points of failure of your project, including:
Adverse outcomes disclaimer
Open issues
Assembly manual for project: Please provide a link to the manual or tutorial for how to construct your project. If your project is not a single use product (e.g. needle, bandaid, etc.) then maintenance documentation is also required
Conditionally Applicable Open Healthware Source (if you have it):
QMS Documentation
Hardware Legacy Plan
Sterilization Plan
Regulatory body approval application (ex: FDA, CE, etc)
Usage guidelines and warnings
Disclosure of Conflicts
While we don’t want to force all creators to include all these pieces of source, the conclusion was a separate certification form with more source necessary for health related hardware. The current certification is always available for creators outside health, or those who would rather not have their hardware labeled in the health category.
Why Did We Do It?
The motivation came from our community but was actualized because of government funding. The COVID 19 pandemic first highlighted the integral role that open source hardware could play in providing others with accessible, life saving technologies and localized manufacturing. From there, years of conversations and informal feedback reinforced the fact that open source medical and health projects needed clear guidance and shared expectations—without compromising the values of openness and accessibility. As a result of this newly articulated community call to action, we were able to receive support from the National Science Foundation (NSF) through a POSE phase 2 grant. This funding gave us the opportunity to move beyond informal discussions and into a structured, community-informed process to design a certification that reflects real-world practices and concerns.
How Did We Do It?
We grounded the development of the Open Healthware Certification in community input. This took several forms:
Workshops: Numerous participants discussed what makes health-related open hardware trustworthy and usable through a series of virtual and in person workshops. The workshops transformed theories into tangible takeaways and from the valuable insights gained in these workshops, we were able to shape the building blocks of the Open Healthware certification. Highlights, summaries, and key takeaways of each workshop can be found here: WS I WS II WS III WS IV
Survey data: We distributed a survey to participants across the globe and received responses from nine countries. From these responses we were able to gather demographic information, validate emerging insights about Open Healthware, and understand priorities for its future. A dedicated section focused on the development of a new Open Healthware standard, where respondents identified what they felt was essential to include. Criteria that received at least 66% agreement were incorporated into the final version of the standard, as long as it met the criteria of adhering to source. We want to continuously recognize that there are standards bodies already available for safety, and OSHWA does not purport to weigh in on safety.
Internal Team Meetings: Over several months, our team met regularly to reflect on insights from a wide range of healthware interactions—from informal conversations to our first annual Open Healthware Conference. Guided by workshop discussions and survey data, we worked to design a certification process that is both globally relevant and widely applicable. We recognize that people engage in open source hardware for many reasons including education, innovation, access, activism, and personal need. While all of these motivations are valid, our discussions—and the data itself—consistently pointed to documentation and replicability as foundational. We found that strong documentation enables accurate replication and empowers others to understand, build, evaluate, and safely improve health-related open source hardware.
Who Was Involved?
This effort was overseen by OSHWA’s Healthware team, Yves Nazon II, Avinash Baskaran, Joey Castillo, Herine Palacios, Lecia Ductan, and OSHWA’s executive director Alicia Seidle. We also received valuable support from Michael Weinberg of NYU Law, and Christopher Wong from the creative firm Objectively, who helped refine and translate the ideas we received into a tangible product. Most importantly, this process was led and guided by the OSHWA community! We thank you for your constant and consistent engagement throughout this process! Members from the community included current open hardware certified projects; health and medical hardware developers, engineers, and manufacturers; researchers, open hardware health and medical companies, and clinicians and staff at hospitals and clinics. If you are interested in helping refine the new Open Healthware certification by participating in activities associated with Year 2 of the POSE grant, please fill out this survey.
When Did This Happen?
Formally, work on the certification began in September 2024. In reality, it builds on data and insights we’ve been gathering throughout the years, culminating with the OSHWA workshops and community events of 2025. The certification is the result of sustained listening, iteration, and reflection—not a single moment or meeting.
What’s Next?
We’re now preparing to roll out a skeleton version of the Open Healthware Certification website, which we refer to as a wireframe. A wireframe is essentially a visual and functional mock-up that looks and feels like the website and allows you to navigate through what the certification experience will be like.
Within this wireframe, you’ll be able to see a full draft version of the Open Healthware Certification, including the actual questions projects will be asked to answer. And most importantly, we want your feedback.
Examples of potential feedback:
“The certification should ask about ___ because it would clarify ___.”
“The certification is missing ___, and adding it would improve ___.”
“Question 5 feels unnecessary or redundant.”
We are planning to host a community session on January 22nd to gather feedback on wireframes and walk through the certification together. If you are interested in participating with this community session or other activities associated with Year 2, please fill out this survey. This certification exists because of the OSHWA community, and it will only improve with your continued input. We’re looking forward to shaping the future of Open Healthware together.
