• Software Development
• Hardware Development
• Education

Introduction

The VolksEEG project is an open-source project with the goal of creating an electroenchephalogram (EEG) machine, fully cleared by the FDA for standard clinical use. All designs will be freely available for others to manufacture.

The project was founded by Alan Cohen, a medical device systems engineer with an electrical engineering/software (EE/SW) background in Boston, USA, and Dr. Bryan Glezerson, a neurosurgical anaesthesiologist and diagnostic neurophysiologist in Montreal, Canada.

It's based on the TI ADS1299 Low-Noise, 8-Channel, 24-Bit Analog-to-Digital Converter for Biopotential Measurements.

Project links:

• VolksEEG.org
• GitHub repo
• Wiki
• KiCad schematics
• Project Goal and Manifesto
• How is this safe?

One of the goals is to democratize and demystify the medical device process, including the regulatory process. These processes can be a serious barrier to entry simply due to complexity and impenetrability, let alone project technical complexity.

Another goal is to make low-cost EEG devices available for use around the world. One use is to measure depth of anesthesia in order to monitor a patient while under anesthesia.

Regulation

Regulation (in the US, by the FDA) is important for medical devices due to safety. These devices can have serious adverse affects on people's lives, so there's a high bar to be upheld. Active devices placed on or within the human body have obvious safety concerns.

But even a passive external monitoring device has concerns, since not only is it in contact with the body, people are relying on the information it provides to make medical decisions. Bad information risks bad decisions, which risk bad outcomes.

From an engineering perspective, these all tie into proper and safe functionality; robustness in the face of problems; accurate data acquisition, processing, delivery, and presentation; and usability.

Like the flight deck of an aircraft, medical environments are well-known for their complexity due to the multitude of devices that need to be controlled and interpreted, with wires, cables, and alarms that need to be managed; cognitive overload is a risk. Meanwhile, medical decisions need to be made based on the information from those devices.

This is all part of remembering that the systems we build affect people's lives. We want to make their lives better, not ruin them or hurt them. It's good to adopt the principle of "first, do no harm" attributed to Hippocrates.

My Connection

I learned about the project from the Embedded.fm podcast, episode 388: Brains Generate EMF, where Alan was the guest, and volunteered to help out. He had been a previous guest in episode 269: Ultra-Precise Death Ray.

Alan is the author of Prototype to Product: A Practical Guide for Getting to Market, published by O’Reilly (see my Review: Prototype to Product). I consider it a must-read for anyone involved in technical product development, whether in a technical, management, or executive role.

I have 40 years of software development experience, much of it in embedded systems, but no medical device development experience. That makes for a good pair: Alan is the experienced mentor, who knows the ins and outs. I'm the clueless newbie, stumbling into the mysteries for the first time, just like any other beginner in the field. Similarly, the other team members have medical and hardware knowledge that I lack; they're additional mentors and resources.

So I can ask the DSWG (dumb SW guy) questions, and I'll capture whatever Alan and the other team members pass on, and pass it on to you here.

The first tidbit: isolation and isolation voltage. Patient isolation protects against electrical current passing through the patient caused by a voltage difference between the patient and something else.

That reminds me of the old electrician's rule: always have one hand in your pocket when working on a circuit. That way, there's no chance of a current passing through your heart. I don't know if that's truly common practice, but it sounds like good advice.

Galvanic isolation means isolating functional sections of electrical systems to prevent current flow; no direct conduction path is permitted. Isolation voltage is the highest voltage the path can tolerate without causing breakdown of the isolation.

My personal goals are to learn the processes in their many dimensions, learn the many details like the one above, and be a productive contributor to the project.

Team Members

As an open-source project, the team consists of unpaid volunteers. The project is still looking for additional volunteers, although specific needs vary. As of this writing, the current need is for C# developers to work on the PC application that will provide the initial user interface to the device.

In addition to Alan, Bryan, and myself (I just joined in mid-October, in Boston, USA), these are the current volunteers who have given their permission to be listed, in alphabetical order:

• Andrej Andonovski, an embedded software engineer developing medical device firmware in Ontario, Canada.
• Lance Bantoto, an undergrad at Waterloo with an EE background in Toronto, Canada.
• Harry Brown, an electronics engineer in the aerospace industry in Melbourne, Australia.
• Seth Kazarians, an electronics engineer in the medical device industry in California, USA.
• Graham Long, a medical device software engineer, primarily focused on firmware due to his EE background in Wales, UK.
• Rhiannon Tully-Barr, a C# developer in Victoria, Canada.
• K Wong, a mechatronics engineer in Ontario, Canada.

We use a number of online tools for collaboration and meetings. The wide range of time zones makes scheduling complicated, as with any globally-distributed project.

More To Come

This blog series will document the process of carrying out the project, with all its ups and downs, the thrill of victory and the agony of defeat.

I hope to provide enough detail for you to use it as a resource for your own project. So I'll definitely get deep into the weeds on occasion. If I know it, you'll know it, like maintaining a project's bus factor.

I'll be doing a lot of converting the tech-ese to English in layman's terms. That's both part of my learning process, figuring out how to explain something, and part of my teaching process, doing the explaining. That's using the see one, do one, teach one (sodoto) method.

If you're already experienced in the material, you may find those explanations tedious and unnecessary. Remember that it's for the beginners in the room (and everyone is a beginner at first, where everything is a mystery); please feel free to sanity-check my explanations. Getting it right is important!

Engineering is a complex endeavor, with many successes and failures along the path. There are many practical details. There are many technical details. There are many regulatory details. There are many unknowns and unexpected surprises to be rooted out.

Alan's Fundamental Principal of Product Development: "Surprises only get more expensive if discovered later. Putting it another way: product development is largely an exercise in uncovering surprises as soon as possible."

Note that I may revise posts after publication for corrections, style, and content.

Continue to the initial hardware architecture.

Sign in