We just finished another fabrication round of an open source pressure sensor, used by a medical doctor and researcher at the Saint Justine Children Hospital in Montreal to help kids suffering from Cystic Fibrosis.
We just created a DIY document that could be turned into a recipe, according to the OKH standards, and be even released using the propagation tools developed by members of IoPA.
Since I was heavenly involved in this small production (as you can see here), I can collaborate with someone knowledgeable in OKH to run this use case. The benefits are mutual: Sensorica gets some practice with these standards and IoPA gets valuable feedback. This example is fresh and pretty rich in context. It also involves two networks that have stood the test of time, Breathing Games and Sensorica.
Then we can produce some content for wide distribution showcasing all this, which will serve as outreach to propagate the OKH standards for a wider adoption.
If you want to collaborate on this let’s start by exchanging here.
Thank you for sharing this @TiberiusB - this is a exciting direction that provides tangible, practical next steps.
Your document is getting a lot closer to where we need to go. The style/approach Instructables has for participatory community development of documentation is a great model; I have leaned heavily on their content in my former classrooms/lab;, both for builds and as a model for development of documentation internally.
It has been identified that there is a dearth of documentation across the board in our work, particularly in the finishing and assembly of component parts from bundled design files - as was once again affirmed during the DAPSI MVP dev and accompanying UX testing. In the report from DAPSI P2 (P2 focusing on design and documentation specifically), the following next steps were identified:
Dissemination of the research findings and prototype development, showcasing the utility
that the OKH-LD manifest, along with the tooling developed of this work, provides
specifically for file and data portability for maker projects.
Recommendation to develop tooling for point-of-need OKH-LD manifest generation, such as
a browser extension.
Continue the development of the OKH-LD ontology for hardware project metadata and align
all involved stakeholders in developing a shared vocabulary for data exchange.
Encourage platforms to enable the automatic generation of OKH-LD manifests to allow for
easier sharing of project data and files.
Enhance the functionality of the OKH Solid App and seek partnerships to develop new
applications based on the OKH-LD data standard within the Solid ecosystem.
I think the DIY document you’ve shared for the Organic Box 3V is a really interesting use case that could help us tackle some of those recommended next steps.
I think the must fruitful conversations would result from talking with @hoijui and @max_w (pls do chime in here, both) as they were the on the DAPSI P1-2, and @hoijui has been continuing some of that work.
And, your offer to have Sensorica serve as the testbed for providing feedback for iterative dev/improvement is just what we need - it is also potentially applicable to the ongoing GOSQAS discussion; a user journey could be developed as part of the testing for this use case, perhaps emphasizing QA, to help build out the (somewhat vague) “provenance in QRs/QA performed” process step. What do you think @max_w
RE: GOSQAS, there is an upcoming meeting - I will post the invitation for the meeting to discuss MVP planning to the forum momentarily.
Thanks @schutton for your input. I am adding new stuff to this thread. Let’s keep this conversation going, Breathing Game project/network/venture is going through an hyperactive phase and we’re going in a direction that requires brainstorming within IoPA and partnership.
For those of you who are not familiar with Breathing Games, BG, in short, this is an open network and venture that engages in peer production of software and hardware used in medical therapy.
We recently filed a grant proposal. One objective in this proposal is to run the BG game and associated hardware through the Canadian regulatory approval process for medical devices. This process will scrutinize the safety and efficiency of the BG software and hardware, but also the data management, since BG includes a computer game and requires storing the patient’s data and data sharing with a care agent and even with the scientific community at large. The intersection between Sensnrica+BG and IoPA is about the requirements for safety and efficiency of the BG device/hardware.
NOTE: a budget has been included in the proposal for this, I reached out to the administrative core of IoPA to get some feedback and an idea about the budget but I did not get any reply, so I included CAD 20K. If we get the grant, this budget will be spent with any member of IoPA, individual and/or organization who can contribute to the work.
From the proposal: Different collaborative platforms help address regulatory issues of OS hardware (ex. Careables.org, Patient Innovation, Makers Making Change, Ubora). They empower patients and OS contributors to share ideas and co-create solutions, adopting design and documentation principles that meet industry standards, offering a curated catalog of designs, guidelines for fabrication, a curated list of makers, legal help, etc. The platform approach increases the level of standardization, provides trust and can offer a legal blanket for developers and makers. Our project will build on the success of platforms and explore novel ways to make OS medical solutions safe, relying on distributed architectures.
Open Know-How becomes critical in this context. Unlike traditional production, where the designer and the fabricator are the same entity, DIY open source hardware dissociates designers from producers and makes producers unknown in advance. We will prototype new ways to prove provenance of design and of recipe for fabrication (a DIY manual), which is only one half of the solution. So we need to standardize documentation in a way that preserves composability of designs and fabrication methods, and in a machine readable way.
As a note, on the data management side, we just hosted a workshop at the Sensorica lab with OPN, digital privacy and security, where we discussed the architecture of medical/therapeutic devices that provide maximum protection and are compatible with the law. Those who are interested in such things ping me, I’ll include you in the conversation.
I wrapped our documentation for the PEP Master (open source DIY medical therapy device) and produced an OKH manifest. I want to share it here and provide some feedback, after going through the process.
We added a field “contributions” and linked to information about how contributed what. We feel that this is important for various reasons.
People can have access to the role structure in this project and find the proper individual to contact for help
People can reward those who have contributed in proportion to their contributions
Contributors’s efforts are publicly recognized
It allows the use of the OVN hardware license, which requires not only attribution, but also a mention of contributors as well as a pie-chart with their relative contributions.
We added “SHA256” fields for all digital resources in order to provide people the possibility to attest the integrity of the information.
In some cases, we took out the field “path”. I recommend implementation of relative paths, since a manifest will point to a bundle of digital resources (documents, files), which can be delivered as a zip file, which contains a folder with all the necessary files inside. Therefore, I also recommend the implementation of a standard file structure.
Thank you for your work on OKH, I’ll continue to provide feedback as we uncover new needs.
NOTE / INVITATION: Anyone interested in joining us in disseminating the PEP Master device? We are pursuing new partnerships and funding opportunities. More on Capacity Building doc.
Integral manifest text:
title: BG Organic Controller 2024
description: A PEP (Positive expiratory pressure) hardware interface, which can be used as a controller for a computer game, used in cystic fibrosis therapy. In essence, this hardware device senses air pressure and communicates that to a computer or a mobile device that hosts a computer game.
intended-use: Medical research
keywords:
- pressure sensor
project-link: https://www.sensorica.co/ventures/scientific-instruments/pep-master
image: https://gitlab.com/breathinggames/bg_device/-/blob/09b0afb61f836bd2d35b0cdd153b025a8342de17/l_organic_enhanced/Photos/20230515_194516.jpg
made: true
made-independently: false
licensor:
name: Tiberius Brastaviceanu
affiliation: Sensorica
email: *****
okh-manifest-version: 1.0.0
date-created: 2025-12-10
date-updated: 2025-12-11
commit-URL: https://gitlab.com/breathinggames/bg_device/-/tree/fbf10a471bd7d9331f909258f32b0ce57663f10e/l_organic_enhanced
manifest-author:
name: Tiberius Brastaviceanu
affiliation: Sensorica
email: *****
manifest-language: en-CA
contact:
name: Tiberius Brastaviceanu
affiliation: Sensorica
email: *****
social:
- platform: Facebook
user-handle: sensorica.co
contributors:
- name: Tiberius Brastaviceanu // Tibi
affiliation: Sensorica
email: *****
- name: Jim Anastassiou
affiliation: Sensorica
- name: Daniel Brastaviceanu
affiliation: Sensorica
- name: Fabio Balli
affiliation: Breathing Games
email: *****
- name: Sacha Pignot
affiliation: Sensorica
- name: Mayssam Daaboul // Mayssam
affiliation: Sensorica
version: Adafruit Feather 32u4 Bluefruit with MP3V5010DP sensor - V3
contributions:
- title: PEP Master CAS - no NRP - Data.csv
SHA256: 86A7146B08677A7E924760217D1689AA689AF9449BCEDCC637E358D8BBEBA503
- title: PEP Master CAS - no NRP - Gouvernance.csv
SHA256: 6F001C9EC0857678AFBCA96AB7364E2A1D3ACB47A247C21D9ACB8FB336EB8E0A
- title: PEP Master CAS - no NRP - Hours per contributor.pdf
SHA256: 8DEB2CC241297BE82573F59274C0C7E94E5B06E29A0A173371A47CD27B53DA86
- title: PEP Master CAS - no NRP - Hours per role.pdf
SHA256: 09FB153098E4DC8E9FCFA32495679F0584ABB835FA22C73C90DCA797E5B2DC49
- title: PEP Master CAS - no NRP - Hours per task.pdf
SHA256: 13035E01FAF8F37DE72C7D2014214927794DD0A344F651D214EC70F82E5EDA63
- title: PEP Master CAS - no NRP - Materials purchases.csv
SHA256: 8654F73CAC6F85E0265342EE4C3FFE2C451641EF81EED1E718A7D8034E429F03
- title: PEP Master CAS - no NRP - Process per contributor.csv
SHA256: 6D8BDE60970DF31420B91A9CF8EE331A17F74C10888DBAE75DB9F866B17CCD69
- title: PEP Master CAS - no NRP - Roles per contributor.csv
SHA256: F35EA69FCC08EF9CBE44C139BC6789B93A8EEFA01DBC18EE0774327BA8A00BD7
- title: PEP Master CAS - no NRP - Volontary contributions.csv
SHA256: F104813A4D082275707AAEFE4449874063188D9223B148B6E2D4AF25928F5456
development-stage: prototype
documentation-home: https://www.sensorica.co/ventures/scientific-instruments/pep-master
live-archive-download: https://gitlab.com/breathinggames/bg_device/-/tree/master/l_organic_enhanced
design-files:
- title: BG+bottom+box++all+components+2024.skp // 3D files for box
SHA256: 1AC33D88C4BDE0BE4409B1B605EDC102883B6E729FFE42873F3420D802A6F887
- title: Firmware_BLE_and_USB_2024.ino // Firmware
SHA256: 714CE4AB37ADD8A9B12B1618F3B1B95F1CAAED9CF042543D1637A8178CF64B0F
- title: PEP_Master_PCB_board_2024.svg // PCB design
SHA256: 12DA439B1FD8D32EF8A1C0B9E6B955BA1B73C35C3026AF483D9290126A678FC8
documentation-language: en-CA
bom: DIY instructables - BG pressure device 2024.pdf
making-instructions:
- title: DIY instructables - BG pressure device 2024.pdf
SHA256: B59851BAB27761616B4896030E6E5F73C01C7E4719A5B9E0327FAAA654742EA4
- title: PEP Master device- R&D doc.pdf
SHA256: 908F028F5D312460086CA48C103604896A518909B6D667AD3A8FCABF2CE92486
operating-instructions:
- path: https://youtu.be/t-KU-gwv6CQ?si=4z7tQ2aQVYqHJti9
title: User tutorial