388: Brains Generate EMF
Transcript from 388: Brains Generate EMF with Alan Cohen, Elecia White, and Christopher White.
EW (00:00:06):
Welcome to Embedded. I am Elecia White, here with Christopher White. We've asked Alan Cohen, author of "Prototype to Product," to talk about his latest project.
CW (00:00:19):
Him Alan. Thanks for coming back.
AC (00:00:22):
Thanks for having me back.
EW (00:00:24):
It's been something like three years since we had you on the show. Could you tell us about yourself as though we don't remember those three years at all?
AC (00:00:34):
Okay. Well, that makes two of us then. I'm a systems engineer who's worked with medical devices pretty much my entire career. So typically I'm involved in developing medical devices and sort of helping bridge the gap between quality, regulatory, and engineering kinds of issues.
AC (00:00:54):
So basically design for regulatory, right, to make it easy to get things through the FDA. Currently I'm a consultant. I work...primarily for two different customers.
EW (00:01:05):
Okay. And you have a new project. Could you tell us about it briefly, and then we'll get more into it after lightning round?
AC (00:01:13):
Sure. So I've been working with an anesthesiologist in Canada. He was previously in Boston, which was how we met, a fellow named Bryan Glezerson.
AC (00:01:22):
And we are developing what we hope will ultimately be an FDA-cleared, open source medical device, in particular, an electroencephalogram, EEG. And we're calling the project, or the device, the VolksEEG, for people's EEG.
EW (00:01:42):
Okay. So are you ready for lightning round?
AC (00:01:46):
I'm never ready, but I'll try.
CW (00:01:48):
Okay. Here we go. If you could teach a college course, what would you want to teach?
AC (00:01:54):
I would like to teach product development, which is in line, of course, with the book I wrote.
EW (00:01:58):
What is the most important quality for an engineer to have: patience, persistence, or resilience?
AC (00:02:06):
I'd say patience, but that sort of loops in the others as well, at least the way I'm thinking about it.
CW (00:02:15):
As we discovered last week, persistence is just patience with being angry. What is your favorite bird/dinosaur?
AC (00:02:23):
Oh, bird/dinosaur.
CW (00:02:26):
I guess that's an or, the slash, or an and.
AC (00:02:29):
Yeah.
EW (00:02:31):
Could be an and.
AC (00:02:31):
Well,...they're a continuum, right? Sort of.
CW (00:02:38):
Yeah.
EW (00:02:38):
Yeah.
AC (00:02:38):
I would say a Triceratops.
EW (00:02:44):
A Triceratops. Okay.
AC (00:02:45):
Yeah.
EW (00:02:47):
We should maybe make these easier. What is your favorite wavelength of laser?
AC (00:02:54):
Oh. I do not have my wavelengths memorized. I do like blue lasers, so whatever the appropriate wavelength is for that.
CW (00:03:06):
Brains, actual seat of consciousness, or a distraction from the spleen?
AC (00:03:14):
I would say actual seat of consciousness.
EW (00:03:19):
Do you have a tip everyone should know?
AC (00:03:21):
Yes. My favorite tip is the only thing worse than no information is bad information that you think is correct. So be very careful about what you think you know.
EW (00:03:33):
Okay. So VolksEEG, an open source EEG. And an EEG, that's the thing that shows the heart rhythm -
CW (00:03:42):
Nope.
EW (00:03:42):
What's an EEG, Alan?
AC (00:03:46):
Brainwaves.
EW (00:03:47):
Brainwaves.
AC (00:03:47):
Electroencephalogram. Yeah.
EW (00:03:49):
Oh.
AC (00:03:51):
Heart is ECG.
EW (00:03:51):
EKG. That's where I was.
AC (00:03:54):
Or EKG. Yeah.
EW (00:03:54):
Okay. So EEG, looking at brainwaves.
CW (00:03:58):
Hence the question about brains.
EW (00:04:00):
Oh, it's all so clear now. Okay. Okay.
CW (00:04:06):
I'm not cutting any of this.
EW (00:04:10):
So what will your EEG do?
AC (00:04:14):
Well, there's...going to be two outputs, let's say, from this project. So ultimately what we're planning on having is a clinical EEG that's similar to other clinical EEGs that you'll find in any hospital or any neurology office. And those are pretty standard. They're well-accepted. They're well-defined.
AC (00:04:38):
So there are standards that define what an EEG machine does, so that's do everything a normal EEG machine does, which is measure brainwaves for various purposes, like diagnosing epilepsy and things like that. On the way to getting there, we're going to be developing a device that is for research.
AC (00:04:59):
It'll be used to research, measuring depth of anesthesia, right? So when you put somebody under anesthesia, obviously you want to make them unconscious, but you don't necessarily want to make them more unconscious than they need to be.
AC (00:05:14):
So there are devices that will measure depth of anesthesia to help the anesthesiologist understand how much anesthetic to give. There are some non-optimalities, shall we say, about the devices that are on the market.
AC (00:05:31):
So there are some anesthesia researchers who are interested in looking at brainwaves and understanding depth of consciousness, or depth of anesthesia, based on those brainwaves.
CW (00:05:42):
Can you...lay a foundation here, because I know very little about EEGs. I know a lot about EKGs and things like that, but I don't really understand how they work, and what they're measuring, and what's going on in the brain that can be measured in such a way?
EW (00:05:58):
And how many sensors do you need?
CW (00:05:58):
Yeah.
AC (00:05:59):
All very good questions. So in terms of how they're generated,...they're generated by the brain, by neurons, groups of neurons in the brain firing off, and I guess collectively large clumps of them in various parts of the brain generate enough EMF that you can detect it.
AC (00:06:21):
So in terms of number of sensors involved, typically there's a lot of sensors, so there can be up to 24 sensors, right? And I mean, these are very low-amplitude signals, as you might imagine. So there's a lot of effort that goes into cutting the noise, but typically up to 32 sensors, depending on what they're trying to diagnose.
AC (00:06:44):
Now in the case of EEGs that are used for depth of anesthesia monitoring, typically they use somewhere in the two, three, four-electrode range. You're looking at a very specific area, so they can get away with that.
EW (00:07:01):
Do you need really good skin contact? Do you have to shave where the probes go?
AC (00:07:09):
Yeah, that's a good question too. And Bryan, my co-conspirator, would certainly have a lot more to say about this than I do. I think typically, no, you don't have to shave. The contacts are very important, right?
AC (00:07:24):
I was just talking to him about this morning, actually. There are disposable electrodes that you can use...They're disposable, which is nice, but the contact's not as great. And then there's reusable ones which actually put metal on the skin.
AC (00:07:39):
The disposable ones, I think, don't put actual metal on the skin. They have...a silver chloride salt solution. So you do need to be careful about the contacts, but you don't need to shave, I think, typically.
CW (00:07:56):
Is it correct to speculate that the signal level is extremely low and noisy from something like going through -
AC (00:08:08):
Yes.
CW (00:08:08):
- tissue and brain? Yeah. Okay.
AC (00:08:10):
Yeah...Yeah, so it's noisy because it's low-amplitude, -
CW (00:08:17):
Yeah.
AC (00:08:17):
- and because there are different things that interfere with each other in the brain. And then, yeah, it's noisy once you get it...off of the scalp, right, then 60 hertz noise, or just about anything. There's also noise induced by muscle movement.
AC (00:08:33):
So if you blink your eye, for example, that will swamp the EEG signal, right? I mean, that's something you can compensate for, right? The person reading it understands that. And that in some cases can be good information too, but it's just very long amplitude signals.
CW (00:08:50):
And one more question kind of on details. What kind of signals are we talking about? These are very low-frequency, sort of? Are we talking about tens of hertz, or kilohertz, or things like that? Kind of what ballpark are these signals that a doctor is looking at?
AC (00:09:06):
Yeah, so that's a good question too. A lot of interesting questions. You guys ask good questions. And there's just a lot of interesting questions around this stuff. So what's typically looked at is in the hertz region or sub-hertz region.
CW (00:09:17):
Okay.
AC (00:09:18):
But there's a lot of interest in looking at higher frequencies to see what can be seen. And again, this is my understanding.
CW (00:09:24):
Sure.
AC (00:09:24):
Bryan would have better answers for this. So we're going to be sampling up to 256 hertz, which is overkill for traditional applications. But there might be interesting information there.
EW (00:09:38):
You have worked as a consultant in medical device development for a while, right?
AC (00:09:44):
Yes. Too long.
EW (00:09:46):
If a client brought this idea to you, one that needed FDA certification of an EEG machine, what is the minimum time and cost you'd quote them for making this something to bring to market?
AC (00:10:02):
So that's a slightly nuanced question.
EW (00:10:06):
Yes.
AC (00:10:06):
So it's a slightly nuanced answer, right? So the thing about the FDA that is maybe not as well-known is that the FDA doesn't clear a design. They clear a device.
CW (00:10:19):
Right.
AC (00:10:20):
Right? So in order to get a device cleared by the FDA, you need to be in manufacturing or something like that, right? There's, again, some nuances around that. So...getting set up for manufacturing, that requires some capital.
AC (00:10:34):
So...getting through the FDA itself, particularly for something like this, we could talk about why, it's not the development. Design development's not very challenging. It would not cost a lot of money...Off the top of my head, I'd say maybe 200,000 or something like that.
AC (00:10:58):
There's an EEG on a chip that a lot of people use and it just does everything. The more expensive part, then, is really going into manufacturing and getting that going. So I'd say maybe we're talking at least a million or two million dollars.
AC (00:11:13):
And that actually factors into the roadmap for how we're going to move forward on the development. So we could talk about that at some point, if you'd like.
EW (00:11:21):
So you do plan to do manufacturing to get that FDA certification of the whole product?
AC (00:11:29):
Well, maybe not. So we are interested in getting it FDA-cleared and getting it into the market, because we think this is something that should be done for a number of reasons. We think it's just good for humanity. We may want to partner with somebody, or multiple entities, to actually do the manufacturing and the marketing, right?
AC (00:11:52):
So...what we know we're going to do is get it to the point where we've got a reference design, right? Something that we feel that there's a good chance it is FDA-able, and we've got good artifacts that whoever takes this to the FDA and then into market can use for that purpose.
AC (00:12:11):
But we won't necessarily go do the manufacturing ourselves, because...i's a lot of capital. You've really got to build an organization. We're not averse to doing that, but...we don't necessarily need to do that ourselves.
EW (00:12:26):
Do you have project specifications? I mean, when I've done medical development, there's a lot of documentation that goes on with software requirements documents and a whole list of other documents. Are you doing those?
AC (00:12:43):
We will. We're not exactly there yet. Let me explain that a little bit. So I think I mentioned earlier that there's actual standards right, as to...what a EEG machine should do, right? So there's an IEC standard. I forget which one it is.
AC (00:12:58):
There's also a IEEE standard that says, "If you want to be an EEG, here are the things you need to do, and here's how you test those things," right? Particularly in the IEC document, the IEEE one's actually a lot more vague. So to some degree, those are a good chunk of our requirements / specifications.
AC (00:13:17):
I'll say requirements, really. Then there's sort of the product specific requirements and specifications. And those we're going to take an iterative approach to that...I'll take a step back. As you're alluding to, there's a lot of process involved in developing a medical device, as there should be, right?
AC (00:13:41):
You're developing something that can very directly impact people's lives in a good way or a bad way. So there is a lot of documentation that's involved in trace matrices between tests, and requirements, and specifications, and things.
AC (00:13:58):
The challenge of that, I find is that...if you do that sort of high-level process from the beginning, it's very burdensome. And if you guess wrong about what you're developing or how you're developing it, you've got to go back and redo stuff. And you've spent a lot of time dealing with process that you didn't need to deal with.
AC (00:14:19):
And one of the things I talk about in my book is that users typically don't know quite what they want until they have it. So the way I like to develop medical devices is to sort of first go through a discovery phase, right?
AC (00:14:33):
So first...do some de-risking, right, like testing out various concepts, and then getting some things in front of users, and letting them play around with it and whatnot, and get to the point where we're very confident that we know what we're building.
AC (00:14:48):
Then at that point, sort of put the hammer down,...basically go through all the processes that you need to go through ultimately for a medical device.
CW (00:14:59):
The hammer down part is very important. I've been in two places where that almost never happened, where it just got stuck in experiment phase.
CW (00:15:09):
And there was this contradictory period of, "Well, we...haven't quite finished figuring out what we're building, but also the CEO or the founder really wants a date on when we're going to ship this." And also he's the person who's experimenting.
CW (00:15:25):
I don't know if you have a notion for how to encourage companies to move past the lab point, but that was very difficult in my experience.
AC (00:15:38):
So I'll say two things about that. One is that that's actually mostly what I get hired for these days, is exactly that, right? So to transition teams from sort of research-y efforts into something that can go into the SBA. So that's one answer.
AC (00:15:57):
The other answer is that I also think that's the most difficult part of building a medical device, developing a medical device. Because at the beginning when you're starting to design, there's no controls, right? I mean, sort of by definition, you're starting off with a blank sheet of paper.
AC (00:16:14):
I have actually seen organizations that sort of start controlling things from that point, but it doesn't work well. It's just a disaster. But by the end, obviously, you need to have everything very much under control. Any small change needs to go through a change review board, and documented, and all that.
AC (00:16:32):
So yeah, how do you shift from one to the other? And that's challenging. And I think it depends on the different organizations and the engineers. Sometimes engineers have a good understanding of why that's a good thing.
AC (00:16:48):
And I think generally speaking, no process works, or no procedures, or whatever you want to call it, overhead, works unless the people doing it absolutely understand why it's a good idea and why it's going to help them.
AC (00:17:03):
So I think that's a big part of it, is helping people understand the larger picture, and then working to get consensus as to how they're going to get there.
AC (00:17:12):
And also...it's so important for management to understand you can't just do that overnight, right? For a lot of reasons, that's not good. So having the understanding that it's got to get done, but it's not going to get done in a day.
EW (00:17:28):
And so you are in the prototype, "make it work" phase, and haven't started the regulatory process yet. Is that correct?
AC (00:17:41):
You're talking about my work?
EW (00:17:42):
For the VolksEEG.
AC (00:17:44):
Oh, for the VolksEEG. Yes, that's right. We're very much in the prototyping, sort of proof of concept, building something...that some clinical researchers can start using and giving us feedback on. Yes.
EW (00:18:02):
Tell us about the system?
AC (00:18:04):
Sure. Well, it turns out that building a system like this,...EEGs are pretty low-hanging fruit, because...there's actually a few of these. There are EEGs on a chip, right? So the one we're using is made by Texas Instruments, and it basically has everything you need for an EEG on a single chip, a single, very, very expensive chip.
AC (00:18:26):
But still, it all works. And it's used by many of the large commercial EEG makers currently. So it's well-validated for its use. And besides that really you need a microcontroller, some electrical isolation, not a whole heck of a lot of other things.
AC (00:18:46):
So right now...we're in schematic. We're not in layout yet. It's coming soon, I hope, which is going to be this TI chip, the ADS1299, of which I bought the last ten from TI, because apparently there's a chip shortage.
CW (00:19:08):
I've heard that.
AC (00:19:10):
Yeah. Oh, man...Well, it's something. So...yeah, I bought the last ten from TI, and then I found seven in the UK that should be showing up any day now. So it basically consists of that chip and...a microcontroller. We're thinking to use the nRF52480 -
EW (00:19:38):
840.
AC (00:19:38):
840. Thank you. Little numerical dyslexia there. The 52840,...which supports Bluetooth. Although initially we're not looking to support Bluetooth, but we can if we want to.
AC (00:19:48):
And...rather than putting a chip down, we're looking to use, to start with, the Adafruit nRF52840 Feather board, the Feather Sense, I think it's called, sort of as a carrier for that chip, and then put some isolation on it.
AC (00:20:07):
So basically the microcontroller speaks, I think it's SPI, to the ADS chip, and you need to put some modular isolation in there somewhere before the patient. It'll be powered off the USB bus, so basically it'll be a little box that attaches via USB to a PC, and we'll have a Windows application on there.
EW (00:20:25):
Okay. So the Feather isn't FDA-certified, but that's okay, because this is the prototype phase.
AC (00:20:38):
Yeah. It's kind of doubly okay...Well, it may be doubly okay. So...we'll talk about medical devices a little bit. So for the prototype phase, yeah, it should be fine. And even for the research, the clinical research device, right? So clinical research devices very often aren't FDA-cleared.
AC (00:21:00):
They could be used for research if they pass what's called an IRB, or investigational review board, at the facility where they're going to be used.
AC (00:21:09):
So typically the investigator will say to this investigation review board at the hospital, "I want to do some research, and here are the details of the research...Do you find that this is ethical to do and safe?" And the IRB says yes or no.
AC (00:21:24):
And typically they're going to look for just basic safety data. And I've built things that have gone through those IRBs before, and it's not proved difficult in the past. So that's one thing. So in terms of the FDA, everything's based on risk with the FDA in terms of medical device development, or with the equivalent bodies around the world.
AC (00:21:47):
So to the degree that you can show that something doesn't pose a risk, you're okay, right?...I have seen things marketed as FDA or medical device grade components, but in reality, there's kind of not such a thing.
AC (00:22:05):
It's really being able to demonstrate that if you use a Feather board,...it doesn't add undue risk, right? So there's some mitigation, if it could potentially cause some problem, that you have some sort of external mitigation that would prevent it from causing mischief.
CW (00:22:23):
Yeah. And my understanding is you're certifying your whole system.
AC (00:22:27):
Yes.
CW (00:22:27):
And if your system includes common off-the-shelf parts, that's okay, as long as you've certified them as part of your whole system. Because similarly I've shipped things that had...ATI GPUs, and DAC boards from various companies, and common PC architecture stuff running them, and that was never an issue.
EW (00:22:46):
And so -
AC (00:22:48):
Yeah.
EW (00:22:48):
- running on the Windows isn't going to be an issue either.
CW (00:22:51):
Right.
EW (00:22:51):
The Windows.
CW (00:22:54):
The Windows.
AC (00:22:54):
You'd be surprised. I'm sorry, go ahead.
EW (00:22:54):
I'm just wondering about Windows, and how that is -
CW (00:22:57):
Did that too, -
EW (00:22:58):
- FDA -
CW (00:22:58):
- but I'd like to hear what he says.
AC (00:23:00):
You and everybody else. Well,...most people are very, very surprised to hear that a lot of medical devices -
CW (00:23:07):
Yeah.
CW (00:23:07):
- run on Windows. So a lot of bedside monitors and things like that. Yeah, it's actually very common to use as an operating system.
AC (00:23:14):
And...Windows deserves some of the knocks it gets, but there are actually some good things about it that do make it reasonably suitable for medical device development. Now, I wouldn't want to use it for real-time safety critical things, right?
AC (00:23:28):
Or at least if I did, I'd have some sort of a backup system for mitigation, which is not uncommon, some sort of safety system to keep an eye on things and make sure things don't go nuts. But for most uses, Windows is actually fine.
CW (00:23:45):
It comes back to what you said about risk, right?
AC (00:23:47):
Yeah.
CW (00:23:48):
If you evaluate the risk and say, "This is mitigated," then it's okay.
EW (00:23:52):
But if you're using this EEG to determine how deep someone -
CW (00:23:58):
[Aha], yes.
EW (00:23:58):
- is in anesthesia with the anesthesiologist, if it blue screens, or the Nordic chip operating system goes out to lunch, and your data becomes trash, this seems important, like you could give someone too much anesthesia, or not enough.
AC (00:24:18):
Yes, absolutely. So one of the key things around risk for something like this is detectability. So if it goes belly up, it needs to be obvious to the doctor that it's gone belly up, right? Because you can certainly do anesthesia without a device like this. This is just helping you.
AC (00:24:36):
So as long as they know whether it's working properly or not, you should be good. I mean, we haven't done our submission yet, so we don't know for sure,...and we haven't gone through all the risk analysis, but that's typically true.
CW (00:24:48):
Because...I guess they do anesthesia without EEGs all the time, right? Or, yeah.
AC (00:24:52):
...Yeah. In fact, maybe 10%, at a maximum 10% of them are done with EEG at this point.
CW (00:24:59):
Okay.
EW (00:25:01):
But if it was cheap, and it was easy, I could see relying on it.
CW (00:25:05):
The worst question is if it's lying, and they don't know.
EW (00:25:07):
Yes.
AC (00:25:09):
But then it goes back to my tip, right?
CW (00:25:13):
Yes.
AC (00:25:13):
Yeah...So Elecia, you bring up actually a very interesting topic the FDA is very interested in, right? So...for a situation like this, where it's very rare to use a device, it's easier to make an argument that, "Well, they'll know if there's a problem. They're a medical professional, and they'll take action."
AC (00:25:35):
Once something becomes ubiquitous and people rely on it, yeah, it changes things a little bit. And the FDA, I think, has become more aware of that, that in theory, the doctor ought to be able to figure things out, but maybe they won't, right, because they're just assuming this thing works.
AC (00:25:51):
So that actually becomes an interesting issue, but that's kind of a high class issue. I think, as you get closer to 100% market saturation with these devices, that'll become more of a thing.
EW (00:26:01):
So one of the ways to counter that would be to have the Windows program talk to the Feather and say, "Are you okay? Your data good? Are you sure?"...And then you know if the Feather has gone out to lunch and is no longer taking valid data.
AC (00:26:23):
Yes.
EW (00:26:23):
And then for Windows, you could do something similar in that if you fail, you do put up the blue screen of death, or you put up something that says, "Catastrophic failure. Please leave me alone until this patient is off the table."
AC (00:26:35):
Yeah. Right. Or you could have the USB, the front-end device that plugs in by USB, that actually is going to have probably an OLED display, a small one, but that could start flashing and saying, "Hey, I'm not receiving responses from the Windows machine that I am expecting to see," right?
AC (00:26:54):
...Actually, it's interesting. In medical device development generally, I'd say you spend more effort figuring out how to identify and deal with problems than you do creating the sort of positive functionality that you want in the device.
AC (00:27:14):
And there's a lot of different ways to deal with making sure things are safe. So for example,...as part of a sort of volunteer effort, I was working on...what will hopefully be eventually an open source ventilator, right? So people started working on that when COVID hit.
AC (00:27:33):
And those are actually devilishly complex devices and can cause a lot of damage very quickly. So one of the things that we worked on implementing was to have an FPGA that basically monitored what was going on. We had a microcontroller controlling things and doing sophisticated stuff.
AC (00:27:52):
And then we set up sort of a small set of rules..., things that the FPGA could keep an eye on. And if it ever saw deviations from those rules, it would just shut the system down, right? So that way you have sort of a redundancy at least in making sure things are safe.
EW (00:28:13):
I'm not sure you want to shut down the ventilator.
AC (00:28:17):
Oh, actually,...it's okay to shut it down as long as you shut it down safe. So in the case of a ventilator, for every ventilator that's running, there has to be a dedicated person, a medical professional, like a respiratory therapist or something, actually viewing the patient in the ventilator.
AC (00:28:36):
So in that case, it's actually okay to shut down as long as you don't pump compressed air into the patient when it shuts down and you allow them to exhale, right? It's definitely something you don't want to have happen, but it's better than damaging something.
AC (00:28:51):
That said, you could implement, it's called the limp-along mode,...where it does some sort of small subset of functionality. But in that case you still need the FPGA or something, some sort of safety system keeping an eye on things, to make sure things don't go bad.
AC (00:29:05):
Because software, I don't know if you're aware of this, software has bugs sometimes and doesn't work.
CW (00:29:10):
Not mine.
EW (00:29:11):
Really? I've never heard that before. Of course -
AC (00:29:15):
Yeah.
EW (00:29:15):
- I didn't know that brains generate EMF. So what do I know?
AC (00:29:21):
Yeah....I mean,...I hope your brain knows that it generates EMF, otherwise, you know what I mean? Kind of.
EW (00:29:31):
I mean, EMF is electromotive force, right? Because my brain -
AC (00:29:35):
Low voltage.
EW (00:29:35):
- is not moving without me.
CW (00:29:37):
I think it's a shorthand acronym for just electromagnetic radiation.
AC (00:29:41):
Yeah.
EW (00:29:42):
...Okay. Fine. My brain radiates. If I ever go to the FCC, it will be an unintentional radiator.
AC (00:29:51):
Well, actually you are. Yes.
EW (00:29:54):
So back to the Feather and the nRF52840, I looked at your README, and it was a little light on details for firmware. And one of the things it said is that you'll be programming it in the Arduino language, which -
CW (00:30:11):
Now you've done it.
EW (00:30:13):
Yeah. Now you've done. Arduino's not a language. Processing is sort of a language, but it's just C++ with some pretty bells and whistles.
CW (00:30:23):
Processing? Wire.
EW (00:30:25):
No, Processing is -
CW (00:30:26):
Is the Arduino language?
EW (00:30:28):
Yeah.
CW (00:30:28):
Processing is something else...Processing is the thing you make pretty plotter diagrams with, unless they both named it Processing, which would be terrible.
AC (00:30:39):
So, I think -
CW (00:30:40):
Sorry.
EW (00:30:41):
No, you're right actually. I thought that the Arduino, there's something involved with Processing. Okay. So it's not an Arduino language. I'm going back to it's just C++ with some pretty bells and whistles.
AC (00:30:54):
Well, so a couple of comments. One is that the discussion that you guys just had is actually exactly why I just called Arduino, because people know what that means, but referring to it otherwise can be confusing. And in terms of it being C++, yes, it is.
AC (00:31:13):
And it's got some nice bells and whistles, but it's also got some ugly parts too, I think. So, for example, I don't believe you can do object-oriented programming in Arduino, or Processing, or whatever you want to call it.
EW (00:31:25):
No, you totally can. That's one of the great things about it is that you end up with these nice classes and objects so that if you wanted to use the accelerometer on the Feather sensor that you're looking at, you just call accelerometer. And then if you want to set up a callback to get data, it's pretty easy.
EW (00:31:48):
It's very object-oriented, because it treats each hardware peripheral as an object, which I think is a good way to think about object-oriented programming, because I'm an embedded software engineer, and those are actually objects. Wait a minute, you were talking, and I just totally interrupted you. Go ahead.
AC (00:32:05):
No, but so for example, on an Arduino, speaking Arduino, or whatever we want to call it,...can you build a class?
EW (00:32:14):
Oh, yeah.
AC (00:32:14):
And inherit from that class?
EW (00:32:15):
Yeah.
AC (00:32:15):
You can?
EW (00:32:16):
Yeah, yeah.
AC (00:32:16):
Oh, okay. Well then I've been proven wrong. I apologize. So -
EW (00:32:22):
Well, wait a minute. So there's the .INO file, which is still a C++ file...It's handled special. The header files are included when it's compiled. But you can make a CPP file, and if you dig into the Adafruit libraries, those are all CPP files, and they're linked -
AC (00:32:42):
Oh, yeah. I understand that.
EW (00:32:42):
They're not linked together as a library and then parsed later, it's all just compiled to C++ and then C++ objects to a full image.
AC (00:32:52):
Oh, right. Yeah. No, that part I understand, right? So you can jump into the .INO files. I think they just get translated to CPP files, and then they get compiled.
EW (00:33:01):
Yeah, yeah.
AC (00:33:01):
So that part I get...So this is something I'm grappling with a little bit, and maybe you guys have some thoughts on this. C++ is, how can I put this? It's very easy for people to do things with it that end up being bad things.
CW (00:33:22):
Yes.
AC (00:33:23):
This is resonating? Yes.
EW (00:33:25):
What do you mean? The underground volcano layer that I made in C ++ is fine.
CW (00:33:33):
What? Okay.
EW (00:33:33):
Okay, that joke made sense in my head. Let's just go on. Yes. In C++, you can make objects that call objects that you can't see and do some pretty interesting things that make a system confusing.
CW (00:33:45):
And at least in most versions of C++ that aren't super new,...they've added a lot of safety features to it, but C++ is still a descendant of C, which allows you to do whatever you want, which is often bad.
EW (00:34:00):
Yes. Let's point that thing at your foot and then fire it. Pointers.
AC (00:34:06):
Oh, pointers. I love them. But, yeah, I think 80% of debugging I've ever seen has involved pointers.
AC (00:34:14):
So I guess one of the things that I grappled with a little bit is, if we're going to have a volunteer effort around developing the firmware, when we're largely the software on the PC side as well, how much rope do we want to give volunteer developers to hang themselves? You know what I mean?
EW (00:34:35):
I do. And I mean, this Feather, you can run MicroPython instead, although that's another layer of something you'd have to watch. But MicroPython would make the code much easier to develop.
AC (00:34:49):
That's interesting. I don't have experience with MicroPython,...but it sounds like you do.
EW (00:34:55):
A little bit. I mean, it's Python, so it's pretty easy to modify. And as long as you have the drivers, it isn't slow. I don't know if there would be an EEG driver at this point. Probably somebody will tell me that when this airs.
CW (00:35:18):
Yeah. I guess the question is it depends on what your volunteers are working on, right? If they're working on low-level hardware interfacing stuff, then yes, they're going to be probably using C or C++, -
AC (00:35:30):
Right.
CW (00:35:30):
- and that's just the way life is. If they're working on higher level stuff, like signal processing, then that can be abstracted away and done somewhere else.
CW (00:35:38):
And you can still do that in C or C++ by architecting the software in different ways and having things kind of protected against each other, which is harder to do on a microcontroller like an nRF. But I forget, is the nRF, it's a Cortex - ?
EW (00:35:56):
M4.
CW (00:35:56):
It's an M4.
AC (00:35:56):
Yeah.
CW (00:35:56):
I don't know if it has an MPU or not, but -
EW (00:35:58):
It has a floating point acceleration.
CW (00:36:01):
Yeah, but I was asking about the MPU, which is an option. Yeah. Yeah. I get your concern...I mean, Python is a good answer if it could work, but I do have more concerns about performance there than Elecia does.
EW (00:36:17):
I have concerns about performance there. Although...at 256 samples for -
CW (00:36:24):
Yeah, it's probably fine.
EW (00:36:24):
- four or eight channels, that's probably okay. But the other EEGs that I was looking at here were at 20 hertz and 20 hertz at eight samples -
CW (00:36:33):
Yeah.
EW (00:36:33):
That's trivial.
CW (00:36:35):
It's asleep for most of the time.
EW (00:36:35):
Yeah.
AC (00:36:38):
Yeah, that's more typical. More typical is lower sampling rate...but more channels, usually 24, maybe 32 channels for standard EEGs.
EW (00:36:48):
So, I mean, I guess my default would be -
CW (00:36:54):
I mean, you wrote a whole article saying, "Don't use Arduino for professional work" and it might be time to -
EW (00:37:00):
I still believe that for a number of reasons. One is that you are very likely to be including some GPL code, or LGPL code, which just says that you have to make your compiled object available for other people to use in their code.
CW (00:37:21):
But that doesn't apply here, because it's open source anyway.
EW (00:37:23):
That is true. So, okay. I will stop arguing that. Alright. Yeah. I mean, yeah.
AC (00:37:33):
The other consideration here is that we want researchers to be able to muck with things, right? So by definition that's why we're building this. We want them to be able to make the changes they want to the code, and do their research, and then release this code to the rest of the world.
AC (00:37:50):
...Just to take a step back, in a lot of ways, I'm not a fan of the Arduino platform. Sort of in theory, I really shouldn't like it at all for a lot of reasons, but in practice it just seems that...it resonates with people. And it works for some reason which I don't quite understand.
AC (00:38:12):
I guess it's maybe just the right ease of use, safety, I'm not sure what it is, but somehow just seems to be okay. So that's a consideration too. You want something that engineers can kind of muck with, given that they're pretty intelligent end users, but they're not developers necessarily.
EW (00:38:30):
Okay. I mean, there's a really good argument for keeping at least the very top level in the Arduino INO format. That's also an argument for MicroPython, because that's really -
AC (00:38:48):
True.
EW (00:38:48):
- a set it and forget it, sort of, have a file. And then you can do the underlaying bits in C++. And even if you end up wanting to do FDA-style unit tests, and hardware tests, and even bring up tests, you can do those either with a different INO or with straight C++ the whole way through.
AC (00:39:17):
Yeah. So I think whatever goes into the FDA will probably look significantly different in terms of the code, right?... So I mentioned the challenge of needing significant capital to get into manufacturing, right, and to have some sort of organization that can actually go out, and market, and sell something.
AC (00:39:43):
There's another challenge in that...the amount of effort that's needed to get a device into researchers' hands through an IRB is..., well, let's say a lot less effort then getting something put together that will clear FDA.
EW (00:40:03):
Yes.
AC (00:40:05):
So that's going to be quite a bit more work, not a horrific amount of work, but it looks different than what the process and the code is going to look like for research use.
EW (00:40:19):
What does IRB mean?
AC (00:40:22):
Institutional review board, I believe. Yeah, so every -
EW (00:40:26):
And that just means that people can use it for research, but they shouldn't be using it for health and safety.
AC (00:40:33):
Yes, basically. So...any teaching hospital certainly has an IRB, right? Some group of people that vets applications from people who want to do research, right, to make sure they're ethical and safe for the subjects. And...it's certainly helpful if you're FDA-cleared. They have no questions about it at that point.
AC (00:40:57):
But if you're not cleared, at least it has been my experience that as long as you can demonstrate credibly that things are safe, any investigator states that this will function and do what it's intended to do in their research, that's okay. But yeah, that's different than going through the FDA. That's a different process.
EW (00:41:18):
And that's where the software starts to need that traceability matrix and where you start looking at the operating system, which the nRF52, if you run it with Nordic stuff, and you do have BLE, that's going to their operating system, or Zephyr, or something that replaces the BLE.
EW (00:41:37):
With Arduino, you don't really have an operating system, but I'm not sure that the INO magic pixie dust is certifiable, except in a very different form.
AC (00:41:54):
Well, it would come down to risk, but that said, my instinct is to not go with Arduino, anything Arduino...the cleared device, right? I think...no matter how the risk works out, I think it's really harder to control Arduino-type stuff.
AC (00:42:13):
Because...it's mostly intended for hobbyist kind of work. So...things can be a little patchy as to how well things work and this and that.
CW (00:42:26):
...One of my concerns is less about, "Can you certify this," but more about things like, from what I remember, they really want to know what versions of everything goes into your software is.
AC (00:42:39):
Yes.
CW (00:42:39):
And with Arduino, it kind of ramifies into this, "So this library included this one and we downloaded it." It would be very, very difficult to document all of that and kind of lock it down to, "Okay. We're at version 1.6 of this particular Arduino SPI driver." Yeah.
EW (00:42:57):
Oh, you wouldn't do that. You would copy the SPI driver into your subfolder, your INO subfolder, so that you had all of those files -
CW (00:43:08):
Sure. Sure.
EW (00:43:08):
- to commit into your version.
CW (00:43:08):
Sure, but you'd want to know what those were in case you needed to recreate that.
EW (00:43:11):
In case you wanted to update them. Yeah.
CW (00:43:14):
Yeah, anyway.
AC (00:43:15):
Yeah. And then you can get into funky issues. This is a issue with Linux actually, which probably is an issue with Arduino, I haven't thought it through too much, where, let's say in Linux land, you're using a certain version of the kernel.
AC (00:43:29):
And then three years later, there's some sort of nasty bug that gets caught...within the kernel. That'll get fixed in the kernel that's current at the time, but it won't get fixed in the kernel you're using, right?...
AC (00:43:41):
But then you have an obligation often to backport wherever that fix is and put it into your kernel, right? Which becomes a hassle. And then you've got to think about all the dependencies at that point and what's going on. So that could be very challenging.
EW (00:43:59):
Yes. And there are companies that take care of that for you, but -
AC (00:44:04):
Yes.
EW (00:44:04):
- that's not always what you want to do, especially with an open source project. How are you you going to make money?
AC (00:44:11):
I don't know that we have the exact answer, but we have sort of thoughts about that. So our thought is that getting to the point where we've got a research device that's not gone through the FDA, that's something we can handle on our own. We actually got a little bit of money.
AC (00:44:27):
Bryan has a little bit of a grant that we're working off of. And we are now being sponsored by a group called Helpful Engineering, which is a very interesting group. They exist to help open source healthcare products, right? I think they're typically health-oriented products.
AC (00:44:49):
So by helping them with financing, and various sort of infrastructure kinds of things, and process, I mean, I don't think we need too much help on the process side, but we could sure use help with money, and legal stuff, and marketing, and all that kind of stuff. So that'll be very helpful.
AC (00:45:05):
So I think we're good getting to the point where we could do some proto-duction. I don't know if that's a term you've run into. So basically building a small number of research devices to give out to people...The amount of effort involved is probably at the level that volunteers can sustain, right? So the cost shouldn't be very high.
AC (00:45:29):
The next step though, to build something that is a clinical EEG, that's going to require some significant money. So we're sort of grappling a little bit with how to do that.
AC (00:45:39):
I mean, either we could pass over our reference design and say, I mean, reference designs aren't that difficult to do, as long as they don't have to actually pass FDA, pass it to a larger entity...
AC (00:45:51):
We're also working on licensing to keep people from taking advantage of this, like big companies from stealing the design, and just using it, and making lots of money off of it.
AC (00:46:03):
But somehow get another entity to complete the development, start manufacturing, get it through the FDA, that kind of thing,...or we have to do that ourselves. And we'd have to raise a good chunk of money and pay people to do those things.
AC (00:46:22):
Because those are things that I don't think you could have volunteers do. I just don't think that'll work. It requires too much effort.
EW (00:46:27):
We had some listener questions around what you were just talking about, which is, how are you going to protect company assets and IP while open-sourcing the project?
EW (00:46:37):
Are you open sourcing the hardware, the software, the documents, everything?...You said licensing, and I'm not sure how that would work with open sourcing.
AC (00:46:50):
Yeah,...so there's different open source licenses you can use, right? So one model would be something that basically says,...you could do a dual licensing thing, right? You could say for non-commercial purposes, non-profit purposes, NGOs, governments, whatever, you can have it. Good luck.
AC (00:47:13):
And if you're a commercial entity, then you've got to talk to us about it. And we haven't gone through the details of this. We've talked with an attorney who is actually pretty sharp about this stuff and sort of started to think about what's important to us, and then that would get turned into some sort of licensing scheme.
AC (00:47:32):
In terms of what would be open, I mean, our intent certainly is to have all the hardware and software be open at least to people who aren't looking to make a bajillion dollars off of this, right? So not-for-profit entities, countries, say poorer countries, or entities within poorer countries. I want to serve those countries. That kind of thing.
AC (00:48:00):
So that will all be open. That's all going to be sitting on our repo and people will be able to use it. The thing that we're not as certain about is what happens in the next stage, right?
AC (00:48:10):
If we're going to work with people, if there are going to be people who are going to manufacture this and commercialize it, or if we do that ourselves, right, what will that demand in the way of protection of intellectual property?
AC (00:48:26):
So for sure, the electronics, and software, and probably the mechanicals, that gets actually a little interesting. It would be open source. The FDA documentation...we're not as sure of right now, because it would kind of depend on the way we proceed. I'm sure that's a very unsatisfying answer, but that's the best I can do right now.
EW (00:48:48):
I mean, I understand. Although that would be amazing if you documented the entire regulatory approach, even from device classification, why is this a class, whatever, what is the trace matrix, this is the risk mitigations. I mean, -
AC (00:49:14):
Yeah.
EW (00:49:14):
- you never get to see those things. Boy, it would be neat to be able to see them.
AC (00:49:19):
Well, and actually they'll certainly be there to some degree, right? So one of the things that Helpful Engineering is very interested in doing is just what you're saying, right? They want to make this process open, which we agree with highly. So we'll be working with them.
AC (00:49:33):
They're actually going to use our project to sort of help calibrate their processes, and their processes are all open. So a lot of that will be in there. I think what is just a question mark in our minds is what this looks like when...the design moves over to some entity that is well-capitalized.
AC (00:49:57):
So well-capitalized usually means that there are investors in there somewhere who want some sort of return. The hope is to keep it as open as possible.
AC (00:50:07):
But on the other hand, we'll need to do what we need to do to get this out there, right? So I don't have a 100% answer for you, other than a lot of it will be open because of Helpful Engineering.
CW (00:50:19):
Are there prior examples of this kind of hybrid approach with a medical device being open? I don't know of too many. You mentioned the ventilators, which I think there were several attempts at that over the last couple of years.
EW (00:50:32):
And you worked on at least one of those. Do you know of any attempts that were more than successful at a maker level?
AC (00:50:40):
I don't...So basically I work with a number of other people within our sort of hospital organization.
AC (00:50:51):
So there's an organization now called Mass General Brigham, used to be Partners HealthCare, which includes Mass General Hospital, which I do a lot of work with, and Brigham and Women's, and some other sort of Harvard fancy hospitals. So a group of us in that organization were working on a ventilator.
AC (00:51:12):
We were trying to do something quickly, but not just a bag with a motor pumping it, which is what most of these other devices are,...but then it became clear we didn't need all those ventilators right away.
AC (00:51:25):
So we merged with another group called RespiraWorks, which is actually a really great group that was working on their own ventilator. And they're in it for the long haul. So they're trying to build something that can go through the FDA and be a real medical device. And everything they're doing is open also.
AC (00:51:41):
So people can certainly get on their Git repo or get onto their site. It's RespiraWorks. It's respiraworks.org [respira.works], I think...So those aren't systems that are working now, or that's not a system that's actually up and running, but they've got an actually very good prototype.
AC (00:52:02):
I don't know of anything that's made it through the FDA that's open source. I think there's some software that's in to the FDA. There's a group that's doing some software for diabetes management and I forget, Tidepool or something maybe.
AC (00:52:17):
And I think they're in FDA, but I don't think they've gotten out of FDA. And I don't know anybody else who's done that as open source.
CW (00:52:23):
You're on the leading edge of figuring out this path.
AC (00:52:28):
Yeah. It's challenging.
EW (00:52:31):
RespiraWorks is on the Helpful Engineering website. Is that how you found them, or is that how you found Helpful Engineering?
AC (00:52:38):
That's actually a very good question. I think I found them both back when we were working, we called our ventilator BostonVent, I think, and I was aware of both of them.
AC (00:52:50):
And then when it became clear that there wasn't an enormous need for ventilators right away, like we originally thought there was when COVID hit, I contacted both of those to discuss. It was clear that if ventilator development was going to continue that it was going to be a much larger effort, right?
AC (00:53:11):
Because we didn't need emergency devices...We needed devices that were going to be fully FDA-cleared. And that's a much different thing, much larger effort. So I wanted to talk to some people about banding together to support an effort like that.
AC (00:53:27):
And that's how I found both of them. And I contacted both of them and got involved with both of them kind of separately, even though RespiraWorks is sponsored by Helpful Engineering.
EW (00:53:38):
I have a couple of listener questions that I'm going to use directly instead of paraphrasing. From jakeypoo, "Have you ever tried to control something with your mind?"
AC (00:53:50):
My body is often controlled by my mind, but not all the time.
CW (00:53:55):
Why should you be better than the rest of us?
AC (00:53:57):
Well -
EW (00:54:00):
He did clarify with EEG signals, not telekinesis.
CW (00:54:05):
Oh.
EW (00:54:05):
Although he didn't say anything about actually controlling your body.
AC (00:54:09):
Well, it's the EEG signals. I guess, EEG is derivative of other signals, so I guess I lose on that one. I have not.
EW (00:54:18):
You've never tried one of the neurolink or -
CW (00:54:22):
Well, neurolink is the one where they stick things into your brain.
EW (00:54:26):
Oh, no.
AC (00:54:26):
I wouldn't try it out.
EW (00:54:26):
You've never tried one of the, how to meditate better by having lights that tell you if your brain is clogged?
AC (00:54:34):
I've seen video game controller interfaces...with a brain thing that you can train yourself to do.
EW (00:54:41):
Are those bunk?
AC (00:54:42):
Yeah, I haven't used those.
CW (00:54:45):
No, they work.
AC (00:54:45):
...I've meditated with applications that let you know how well that's working. So I have done that. But in terms of moving stuff, yeah, I've seen also the video game controllers that you can drive using EEG, but I have not tried them.
CW (00:55:03):
Could this be adapted into a controller?
AC (00:55:07):
Sure.
EW (00:55:08):
Obviously.
CW (00:55:09):
Alright.
EW (00:55:13):
Sahil asked about the unique challenges that are faced in designing embedded medical devices. And that's a broad question that we've kind of touched on in certain places, but I know it's kind of near and dear to your heart.
EW (00:55:25):
So how would you describe the unique challenges faced when designing embedded medical devices? Sum up 20 years in maybe two minutes.
CW (00:55:38):
We've got a few minutes here.
AC (00:55:41):
Well, I'd say at the highest level, you might say...there's no unique challenges. I mean, I'm sure that's not true. But basically it's just doing product development, and really understanding what your constraints are, and your requirements, and not cutting corners, right?
AC (00:56:01):
Because...if you're building consumer products, typically it's easier to cut corners on things. You don't have a regulatory agency looking over your shoulder quite the way the FDA can. Although actually for a lot of consumer things, the lawsuit issue becomes big, right?
AC (00:56:19):
If you cut corners and screw something up, you hurt a lot of people, and you get sued for a lot of money. So in a lot of ways, it's not so much different. The ways it's different, well, one is the FDA...You have to appease them as a stakeholder, right?
AC (00:56:36):
They've got regulations that you need to actually understand and understand how to deal with. And then there's lots of standards, which is kind of secondary to dealing with the FDA or other agencies like that...A typical medical device has probably a dozen standards that you need to deal with.
AC (00:56:53):
And for some, like ventilators or proton therapy systems, there's dozens of standards. So you really need to get comfortable with those standards and understand practically how to conform to them. The other thing I think is interesting is that everything's risk-based, as we discussed a little bit before.
AC (00:57:14):
So that means, I guess, first of all, you need to really consider risk in the work that you're doing. So typically you need to do risk analysis before you start working and then keep doing it while you're working so it will help you to understand what you should be putting your efforts into, right?
AC (00:57:29):
Because if you can show something's not a high risk,...you could put effort into it, but it may not be as important as putting that effort in something that's higher risk. It also comes into play when you're designing something.
AC (00:57:40):
And...actually, I do this a reasonable amount...If you understand sort of how to look at risk, it'll inform your decisions about architecture in particular, and it'll make things easier to derisk, to take the risk out of, right?
AC (00:58:00):
So for example, if you only have one subsystem in a system, if you can just get to the point where there's only one subsystem that can add a lot of risk, it's easier to mitigate that situation than if all your subsystems can add a lot of risk.
AC (00:58:16):
Then you've got to mitigate all these subsystems, which becomes a lot more work. So that kind of thing.
EW (00:58:23):
And are you looking for volunteers to help with the VolksEEG project?
AC (00:58:31):
Yes, absolutely. So it would be good to have somebody on the firmware side. We have, I think, an API defined, right? So basically the firmware,...on the one side, it's going to have USB. On the other side, it's going to have the ADS1299 chip. So there are actually existing libraries.
AC (00:58:51):
So a number of people will have interfaced Arduinos, Teensys and whatnot, ADS1299s, not at a level where they'd be okay for clinical use, right, but sort of as experiments. But because of that, there's software that exists that seems to do what we need. So, it's basically, you'd be porting it into this system.
AC (00:59:15):
And then on the software side, on the PC side, I'm going to say another language that tends to draw out passions, C#. I'm a big fan of C#. So it would be great to find a C# developer, particularly somebody who's had some experience with graphics, right?
AC (00:59:35):
Because we're putting up real-time waveforms. Although we have done a proof of concept on doing that in C#, and it works pretty well.
EW (00:59:41):
And if somebody wants to learn more about the medical regulatory part, is there a good way they can help on this project?
AC (00:59:52):
That's a good question. Yeah, it would be useful. So in terms of the regulatory aspect,...I think we know what to do, but...if there were somebody who was really interested in learning regulatory, the regulatory side of this, who wanted to write up documentation and whatnot, that would certainly be welcome.
EW (01:00:13):
Alright. Alan, it's been really great to talk with you. Do you have any final thoughts for us?
AC (01:00:21):
This is something I've wanted to do. So this is an idea I've had for about 20 years now, to build open source medical devices, because I think that there's a lot of great advantages to them. And if people go to our Git repo, they'll see a little bit of a writeup about this.
AC (01:00:33):
But I guess I would urge all engineers,...all people generally..., if you can try to figure out how to use your superpowers to help people out, even if it's on the side, the world will be a better place. So go forth and make the world a better place.
EW (01:00:54):
Our guest has been Alan Cohen, author of "Prototype to Product: A Practical Guide for Getting to Market," and consultant in medical device development. He's co-founder of the VolksEEG project, and there will be links in the show notes.
CW (01:01:10):
Thanks, Alan.
AC (01:01:12):
Right. Thank you guys. Good to talk with you again.
EW (01:01:14):
Thank you to Christopher for producing and co-hosting, and thank you for listening. You can always contact us at show@embedded.fm or hit the contact link on embedded.fm.
EW (01:01:26):
And I don't really have a quote for you. Although looking at the Helpful Engineering website, their vision is pretty cool. They have a vision of a world where improved access to resources and opportunity increases innovation, stability, and prosperity. It's a little markety, but I don't know. I could live in that world.