Strategy Session 3 Summary
The NYC OSHWA meeting marked the first in-person gathering focused on refining the scope and structure of the open source healthware certification process. The workshop began by reviewing the current “state of play,” summarizing insights gathered to date and highlighting remaining questions. Following this orientation, breakout sessions shifted to deeper conversations, particularly around terminology. Participants emphasized that OSHWA’s role within the ecosystem should center on principles of transparency, openness, and meaningful community engagement. In particular, participants wanted OSHWA to offer designers and replicators robust support through documentation standards, enabling practices, and liability guidance. However, through further conversations, it was determined that liability is actually best done by a lawyer and not OSHWA as OSHWA does not give legal advice. Key themes emerged around cultivating user trust, engaging in culturally responsive communication, and promoting safe replication practices (with the understanding that community’s goals are safe devices, but the proposed open healthware ecosystem framework exists only to review source and not safety.) These conversations evolved organically, particularly on Day 2, as participants shaped the dialogue and explored new directions. A broad range of topics were addressed during the workshop including:
Community building
Accessibility of the open healthware ecosystem
Governance structures
Risk accountability
Strategies for bolstering the credibility of open-source healthware
Breakout room discussions surfaced strategic priorities such as refining key terminology, building a strong and adaptable platform for open healthware development, and establishing partnerships with organizations such as IEEE, NIH, and UNICEF. The use of the term “certification” was critically examined, as it carries a multitude of meanings to various groups of people. Looking ahead, OSHWA plans to continue gathering feedback through workshops and our Open Healthware Conference, ensuring the certification process is grounded in the needs and insights of the wider community.
Certification Process Takeaways
The envisioned OSHWA healthware certification process is intended to be modular, with a flexible but well-defined progression. To test underlying assumptions, participants engaged in a mock certification exercise and provided feedback on the experience. Key recommendations included making certification criteria and review processes fully transparent and publicly accessible, clearly defining the stages of certification, and reducing the amount of information required from applicants. Based on these insights, a new multi-step certification pathway was outlined. Strong emphasis was placed on clarifying what is being certified and communicating the limitations of certification, especially that it does not imply clinical validation or guarantee safety. These revisions will be iterated upon and presented to the broader OSHWA community for input and validation. Additionally, the need to distinguish clearly between general open hardware certification and healthware certification was highlighted, as the latter requires enhanced documentation, material clarity, and regulatory awareness.
Guiding Principles for Creating Replicable Devices
Transparent, well-documented designs were consistently identified as critical indicators of successful certification. Comprehensive documentation including metadata, bills of materials (BOM), and safety testing records was deemed essential for building trust and facilitating global accessibility. Metadata was defined as additional context that clarifies device use, maturity, and limitations. Participants supported the idea of optional metadata fields that could enhance credibility without placing unnecessary burdens on applicants. Such structured documentation is especially important in healthware contexts where biocompatibility and safety are important. We recognize that documentation can be vastly different depending on the complexity of the device, so OSHWA has been careful to keep structure around documentation broad in the past. Groups, such as DIN Spec 3105, have addressed documentation structure for open hardware in the past but not in a health specific context. We plan to use community feedback and these existing structures to inform future replicability formatting decisions.
Governance & Legal Reflections
Participants named OSHWA as the governing body for this ecosystem. Liability in the open-source healthware domain is inherently complex and may be distributed across various stakeholders, including designers, reproducers, and end-users, depending on the circumstances. Participants advocated for the inclusion of visible and prominent disclaimers to reduce legal ambiguity and manage liability. Additional suggestions included requiring insurance, developing legal frameworks for addressing negligence, and clarifying the distinction between OSHWA’s role and that of regulatory bodies such as the FDA. It is important to note that OSHWA is not the FDA and has no intention of addressing standards that the FDA addresses including safety. The desire for OSHWA to NOT become the FDA has been reflected by our community in previous meetings, and as OSHWA, we couldn't agree more!
On governance, attendees called for the development of a formalized structure that incorporates industry experts, community ambassadors, and possibly the establishment of an ethical “oath” or commitment to safe and responsible innovation. After additional conversations, attendees decided an oath has no real teeth to it and determined if we wanted something people had to adhere to, the current certification structure served that better because there is an opportunity to get certifications revoked. Governance efforts should enhance public trust while avoiding overreach into regulatory or legal enforcement. Oversight mechanisms such as adverse event tracking were recommended to reinforce responsible certification practices and community accountability.
Adoption Pathways & Barriers
It became clear that any certification or validation process must be inclusive to the diverse cultural, regulatory, and regional contexts in which open healthware is used. Participants acknowledged that adoption pathways may differ significantly depending on local healthcare infrastructure, trust in open-source tools, and cultural norms. Certification labels were identified as potentially valuable trust signals, particularly in institutional settings like hospitals, where full regulatory approval may not be feasible. To maximize impact and accessibility, the certification process should remain simple, collaborative, and well-supported. Recommended strategies for encouraging participation included offering templates, maintaining a public directory of certified devices, and establishing channels for ongoing community feedback. Barriers such as process complexity, lack of transparency, and reproducibility concerns were flagged as obstacles requiring ongoing attention and simplification.
Implementation Support
Ongoing support for designers throughout the certification process was seen as essential for expanding participation. Attendees recommended that future certification resources include guidance on material testing, design decision-making, and safety parameters. The safety discussions were held with the reminder that while OSHWA could recommend creators include safety parameters, this is better done by your government's regulatory body because OSHWA cannot make safety guarantees. These resources would not only streamline compliance but also reduce confusion among applicants. Participants also stressed the importance of creating inclusive, feedback-rich spaces where designers can share progress, ask questions, and receive collaborative support, ensuring that the open healthware movement remains both technically rigorous and socially welcoming. We at OSHWA agree and strongly encourage people to leverage existing forums and platforms with these modalities to ensure people receive the help and support they are seeking.
Project-Specific Certification Feedback
Day 2 opened with a role-playing exercise involving real-world open healthware projects simulating the certification process. These exercises were straightforward for some creators, but for others revealed key challenges related to version control, safety risks, transparency, and community trust. Participants discussed how various stages of development impact a project’s certification readiness, and how to manage multiple design versions. Feedback mechanisms, accessible documentation, and detailed user guidance were all identified as critical to establishing product credibility and safety. The experience highlighted the need for a flexible, yet standards-based, certification process that accommodates a range of project complexities while maintaining transparency.
Maintaining and Growing Community
A central theme throughout the workshop was the need to root certification in a broader purpose: advancing open-source healthware that is globally accessible and community-driven. Participants were asked to reflect on what they wished the world better understood about open healthware. Discussions focused on growing the global network by including researchers, designers, healthcare professionals, funders, and newcomers to the open-source space. Special emphasis was placed on connecting diverse users and makers across geographies to build a technically skilled, inclusive, and collaborative community.
Certification vs. Registry
Participants engaged in substantial discussion around whether “certification” is the appropriate term to describe OSHWA’s healthware process. Alternatives such as “registry,” “specification,” or “community validation” were actively discussed. Concerns were raised that the term certification may misleadingly imply regulatory approval or clinical validation, which OSHWA is not positioned to provide. Alternatives such as “registry,” “community validation,” “specification,” or “knowledge base” were proposed as more accurate descriptors. Some participants suggested implementing a tiered or symbolic system, similar to martial arts belt colors, to indicate project maturity, transparency, and openness without making unverified claims about safety. While interest in alternative terminology was strong, support for retaining the term “certification” also remained. These discussions will inform future iterations of OSHWA’s process and messaging.
After the meeting, OSHWA researched current practices around certifications. The ISO considers a certification “the provision by an independent body of written assurance (a certificate) that the product, service or system in question meets specific requirements.” (https://www.iso.org/certification.html). In our research, we also found ISO/IEC 5230 which is a certification for open source licenses. This certification is a self certification and there is no governing body otherwise checking or validating that the complete source is available, which is OSHWA’s current certification system. In a post-meeting conversation, the legal minds at OSHWA did not have concerns over the term ‘certification’.
Trust, Risk, and Safety
Multiple sessions focused on managing risk and building trust without overstating OSHWA’s authority. Participants highlighted concerns related to outdated documentation, improper use, and insufficient change tracking. Clear disclaimers, robust fault reporting mechanisms, and contextual metadata were all identified as essential components of a trustworthy system. Participants reiterated that trust must be built through transparency and community validation, not implied through misleading or misunderstood labels. A clear distinction between OSHWA’s role and that of regulatory authorities like the FDA was emphasized.
Exploring Designer & Replicator Needs
An emerging theme was the importance of serving both designers and replicators. Designers seek recognition, community credibility, and assurance that being transparent will not expose them to undue legal or reputational risk. Replicators, meanwhile, require detailed documentation, version histories, and tools to avoid outdated or incorrect builds. Participants proposed maintaining version-controlled histories of certified designs, which is already an aspect of OSHWA’s current certification, and requiring process-level documentation to mitigate risk. Social norms around openness and credibility were seen as potentially powerful motivators to reinforce ethical and high-quality practices.
Global and Structural Considerations
This workshop as an in-person exercise, gathered participants largely from the US population. Such a monolithic context was not OSHWA’s intention in setting these up, but should be recognized as a limitation. As a result, truly comprehensive global conversations were limited. However, there was some time dedicated to addressing how the language and structure of certification processes may conflict with global expectations, particularly in the US. Emphasis was placed on making the certification process linguistically and culturally accessible. Participants recommended that OSHWA collaborate with respected organizations such as IEEE, NIH, UNICEF, and ACM to expand legitimacy and reach. Humanitarian procurement systems and NGOs were also identified as crucial audiences that would benefit from greater awareness and access to open-source healthware tools.
What We Know vs. What Needs Work
Throughout the workshop, participant questions were integrated into breakout sessions and strategic discussions. In the final session, attendees summarized both their insights and outstanding challenges. “Community validation” was positively framed as more accurate and beneficial than “certification,” and that reframing the process would help build trust; though support for retaining the term “certification” also remained. Progress was made in clarifying concepts like credibility, certification scope, and public messaging. However, several unresolved issues remain, such as how to communicate risk, ensure replicability, and define OSHWA’s evolving role. Key priorities moving forward include refining language, building trust, strengthening participation pipelines, and expanding global inclusivity.
