Summary:
OSHWA is hosting a number of strategy and visioning sessions to collect community responses from open hardware health device creators and medical stakeholders. Community participants from the May strategy session were asked about the following topics:
Clarifying the role of Open Healthware Certification
Augmenting the current OSHWA Certification to support Open Healthware
Characterizing the role of a certifying body for Open Healthware
Bolstering trust in Open Healthware
Scoping the full source of Open Healthware
Refining our definition for Open Healthware
We went away from this meeting with a list of source files to include in a certification, the understanding that OSHWA focuses on source files and licenses for the source (and not, for example, the safety of a device). There was a strong desire to hear success stories of existing health-facing open hardware in the world as a mechanism to bolster trust for Open Healthware. And OSHWA is answering that call with a series of 5 stories being published throughout the summer, our first success story is here.
OSHWA is driven to co-create in the ecosystem processes, to be part of our sessions, please fill out this brief survey.
May Open Healthware Strategy Session
Our recent virtual gathering brought together a dynamic community to collectively tackle the promise and complexity of certifying Open Healthware devices. It was not a meeting aimed at definitive answers, but rather a deep dive into the questions shaping our path forward towards certification. Conversations were held in our six breakout rooms, each charged with exploring a distinct, yet deeply interwoven aspect of Open Hardware and the healthcare ecosystem. What emerged was not just a list of action points, but a compelling narrative where openness, trust, and safety intersect with regulatory realities and community ideals.
One of the most resonant themes across all rooms was the recognition that Open Healthware Certification is not just a bureaucratic exercise, it’s a tool for building confidence, visibility, and legitimacy. In discussions around the role of certification, participants emphasized how a structured process can not only boost credibility but also encourage innovation by offering a roadmap for what impactful Open Healthware can look like. There was Mutual agreement that OSHWA isn’t the FDA and should not be the FDA, but having a connection to a regulatory body did provide some ‘endorsement’ and increased trust in Open Healthware products. Participants in several rooms brought up the idea that third party testing for quality validations and having a point of contact to help facilitate connections would be a powerful structure for the certification to provide.
Participants were quick to identify the complexities especially around who holds the responsibility for certification and how many layers the process should entail. The idea emerged of needing a more flexible framework that accommodates a range of device classes, from DIY prototypes to clinically viable solutions.
This brought us to a richer understanding in the second room, where we considered how the current OSHWA certification might evolve along with the OSHWA ecosystem in healthcare. There was consensus that replicability, comprehensive documentation, and alignment with local standards are not “nice-to-haves,” but critical pillars for the Open Healthware certification. What’s clear is that health hardware exists in a context where stakes are high, and variations across geographical standards only deepens the challenge for open hardware and distributed manufacturing. Questions emerged and remain: “How do we ensure equity in global certification? What do we do when regulatory bodies don’t exist or when resources are constrained?”
A group of participants compared and contrasted what a certifying body, like OSHWA, would do for the Open Healthware certification, with existing bodies in the medical industry. As for as Open Healthware went, the mantra for the certification process was one that values transparency and verification, but acknowledges that trust must be earned, not assumed. There was also a thoughtful distinction made between OSHWA’s existing role as a community and hardware source steward and other certifying bodies like FDA, MDEL, CE or ISO, and that they are vastly separate governing roles. While OSHWA would host the Open Healthware certification, ideas of partner governing bodies like GOSQAS or DIN came up as ally organizations. Participants were also interested in a review body for Open Healthware certifications.
Trust, unsurprisingly, became its own breakout topic and rightly so. If Open Healthware is to be adopted meaningfully, it must be trusted by all stakeholders. This trust, participants argued, doesn’t come from branding or persuasion alone; it must be earned through human design, culturally attuned adaptations, peer-reviewed evidence, and tested devices that function well. Concerns were raised around the branding of Open Healthware when devices looked amateurish or unfamiliar. Trust is an aesthetic and emotional question as much as it is a technical one.
As we moved into defining what “full source” means in the Open Healthware context, the conversation became very detailed of our participants' thoughts on full source. It became clear that full source isn't just about sharing files it’s about building a reproducible, traceable, and version archives of everything from clinical benchmarks to supplier lists. But there are limits to transparency too according to our participants. Some elements must remain protected, for example with patient identity safety. Drawing that line thoughtfully between openness and ethical responsibility rose as a central tension that we’ll need to navigate together.
Finally, when defining the term Open Healthware, participants came up with a framework to build a definition from: it must be accessible, utilizing simple language. It must address complications of contributions, and provide examples of success. This definition must be able to bolster confidence and highlight the safety of devices. It should address local resources and best practices, and highlight the importance of expert development.
From this framework, we can infer that the participants are thinking more broadly than a dictionary definition. The existing definition of Open Source Hardware is empowering in its current certification process but falls short of capturing the care, and safety considerations to health technologies. Our community sees an opportunity to add depth to name documentation, safety, expert collaboration, and real world use cases as core to how we define and distinguish Open Healthware. It’s not about making the definition for a dictionary’s sake, but about defining it to resonate with those we need to engage: makers, creators, designers, replicators, clinicians, regulators, and patients.
What we came away with, then, is not a blueprint but a vocabulary.
We now have clearer language to describe what we’re building towards certification and our ecosystem, what it must include, and who it must serve. There’s now items to be defined, blueprinted, piloted, and refined but we are slowly shaping a framework that feels both grounded and aspirational. It’s a vision that invites participation across healthcare ecosystems, and one that understands that openness includes a deep commitment to clarity, transparency, and shared responsibility.
