RespiraWorks concept

ICS Joins RespiraWorks on Open Source Ventilator Project

By Peter Winston

This ongoing series provides a close-up look at the creation of a low-cost ventilator, an open source project ICS has embarked upon with RespiraWorks. Progress reports will be posted regularly. Check out our project page for more details.

May 20, 2020

We just had the design review and hit our first major snag.

ICS has tools to convert UX to a working prototype so we like to spend time getting the UX just right, and then generate code and encourage users and stakeholders to try it. You can try it yourself! Here’s the link to the prototype.

The prototype is written in Qt/QML but it’s being compiled for and running with WebAssembly. While WebAssembly is slower than the native code and has serious memory restrictions, we find that getting the prototype into people's hands quickly is really important. By doing it this way, we don’t have to wait while we install the software or lose time while getting a prototype board.

So, in the design review several people made comments about the "mode" that defines the job the ventilator is performing. It is the button labeled AC/P in the screen below. When you click it, other options are presented. Several reviewers asked us to add an OK/Cancel button.

RespiraWorks UI

There also were several additional change requests. Some easy to address, some more difficult. None out of the ordinary. But none of those were the snag I mentioned. The snag was related to code review. 

When we generated code from the Figma file it was 40K LOC. The RespiraWorks 62304 process requires a code review. For us, this isn’t a big problem because we’re used to reading machine-generated code. But not everyone is. I’ve worked on plenty of open source projects, and they only work if everyone works together. That means, we can’t just adhere to our process; we have to conform to RespiraWorks’ process. To that end, we developed a process of breaking the Figma into parts so the code drops would be small and manageable. 

Here’s the snag: I hate working in multiple branches. I worry that the effort to break the UX up into parts so we can generate small code reviews, and the simultaneous effort to update the UX to incorporate changes may somehow step on one another. It hasn’t happened yet, but this is the type of thing to look out for.

It’s OK for a project to have many moving parts. Most do. The issue here is that the critical path is the code review. So we want that to start, but changes to the UX will inevitably result in changes to the code leading to more work.

Our job now is to figure it out and minimize the impact


May 12, 2020

When we develop a device, we often create a simulator. The simulator is used to exercise the user interface (UI) so that each aspect can be used and tested. The simulator is first used for software development. In addition to confirming settings, it triggers options in the UI that can’t be seen without it.

In an FDA-regulated project, designing the UI and exercising it with simulators can be done before turning on Design Controls. This form of the UI is considered a prototype. It can be aligned with product requirements later in the project after formative studies have ironed out the kinks. The simulator helps create a 'live' experience that allows UI issues to be refined at a much higher level than might be possible with wireframes. This is a massive product design accelerator that reduces downstream changes when working with processes like IEC-62304 and ISO-13485.

In our ventilator project, the simulator can generate an alert, enabling the testing of the alert system. Eventually, the simulator will evolve and ultimately it is essential for formative studies and integration testing. In this way, we first conduct a simple unit test, then a more complex unit test, and then an overall system test.

While it may seem simplistic to show that a value set in the ventilator UI is indeed the same value in the simulator, this is an important step in confirming that this code was created correctly and has been verified. Using our GreenHouse process and tools means some of these steps can be automated, but verification and validation are always done manually.

Ventilator Simulator - UX design

Ventilator simulator - ux design

Notice that every input field in the ventilator is an output field in the simulator, and vice versa.

Ventilator Main Screen - UX design

Ventilar simulator - UX design

Notice that all of the icons now have ways of controlling their state and can be tested - that is, once the UX is turned into code.


May 8, 2020

We presented the UX to the Respira team. We ultimately combined the best design elements from the various concepts, as well as incorporated everyone’s feedback into the updated UX. We started to talk about exactly how the device works. By going over the UX in detail, we find that we can flush out many details early. I find this UX-first approach to be much better than pure agile because of the way it helps get us all on the same page, and it allows us to find problems early.

Now that the design is moving along, the project can accelerate. Here are the next steps:

  1. Get the visual portion of the HMI working
  2. Create a simulator that mimics the hardware and test the HMI
  3. Devise a plan for the waveform graphs

Our GreenHouse tools and processes will quickly generate a C++/Qt working prototype.

It looks like we’ll be building for Raspbian. It’s a solid choice. The code will be hosted on GitHUB. I don't yet know what build system or continuous integration we’re using, though. We  had a conversation about open source licensing. I had assumed we were going to use a GPL and they had assumed a Berkley/Apache/MIT license, so we still have things to work out. I like the GPL because it helps the open source community grow. What starts open stays open.

Have an opinion on licensing? I’d love to hear from you. Please post your comments on social media. In the meanwhile, check out a few of the screens we’ve designed thus far:

Startup Screen

Main screen

This is the startup screen, as well as the restart screen. The UI shows the "start test" button and message if it’s a restart. Otherwise, it goes straight to a diagnostic test and then opens the main window.

Main Screen

Main screen

This is the main screen. The waveforms will be added later, once they’ve been designed.

Alert Screen

Alert screen

This is the alert screen, which is activated when an alert condition occurs.

Setting Popup

Settings popup

This is a detail of a setting popup that lets the user change a value on the bottom row.

RespireWorks

This is what we anticipate the final device will look like once complete.


May 4, 2020

Last Friday, I blogged about the wireframes. Today I’m showing off the visual design concepts. We asked two of our designers to come up with concepts: a light theme and a dark theme. (See below for the themes for the main screen.) Typically, medical devices feature a dark theme so they can be used most unobtrusively in a dimly lit patient room but we still wanted to explore a light theme for comparison.

Main motor screen

Main motor screen

Note that it’s not just "dark vs light." For instance, the designers have offered two options for fonts. Which do you think is easier to read? What about the shape of the buttons on the bottom, and their labels? Which option is easiest to read? What about the labels on the measurements panel? How about the battery icon? Do you prefer horizontal or vertical? Which option offers the best usability? Choose the details you like and let me know in the comments on social media.

In addition to the basic screens, we also have to think about the graphs showing the waveforms. At this point, I’m not sure whether this should be done in QML or OpenGL. There’s also a question of whether the waveforms need some preprocessing before putting the pixels on the screen. ICS has a similar project that we can use as a proxy, and try on the RPi. This way we can evaluate the performance before writing new code.

Tomorrow we present our work. There are lots of questions about exactly how it needs to work. Also, I wish we could do some user testing. At this point in a typical project we would use the drawing to solicit feedback from users. In this case, I’m not sure how that’s going to be accomplished. Stay tuned.


May 1, 2020

I received the background information. Nothing surprising. Almost all medical devices have the HMI separated from the rest of the system so that if one part fails the other part can warn the user. In this case, it’s a RaspberryPi running the HMI and a microcontroller on the backend.

Our job at ICS is going to be getting the HMI on the RPi. At first view it looks like a job for C++/Qt and Linux, probably Yocto. But our team doesn't yet know if there are real-time requirements.

Speaking of requirements, writing the code seems like it should be pretty straightforward. The hard part is going to be adhering to the 62304 process, and creating documentation. Sometimes this can represent as much as 80% of the total effort. Developing code with a quality management system (QMS) is a bit like going to the gym. It’s uncomfortable until you get into the groove. But in the end, you feel better all around.

RespiraWorks shared a nice rendering of the device they aim to build. Here’s a look at initial sketches of the device’s UI. These screenshots are from April 22.

Main Screen

This is the main screen. We brought it into Figma and started asking lots of questions, like what items were off screen on the carousel? Could you swipe it or only use the arrows? What areas are clickable? And, what’s that funny icon next to the power and battery?

On just five screens, we had to go over 30 or 40 details. But, this exercise is very helpful. We like to dig into the UX and use it to uncover as many details as possible. On a typical project, we might go through five or six rounds of revisions with a client to refine the workflow and details. At this point we often move on to user testing. But, on this particular project I expect we’ll move onto visual design soon.

My main concern right now are the waveforms. They’re easy to draw by hand but I wonder whether there will be significant challenges keeping them in real time or during rendering. We’ll address those issues if they arise.

Here are the other screens:

Setting Adjustment Pop-up

Boot/Startup 

Alerts Pop-Up

Alerts Log


April 29, 2020

ICS recently received a request to help develop an open source ventilator. The request came from RespiraWorks, an organization made up of dozens of engineers, healthcare workers and other professionals around the world. Their goal is to create a ventilator that can be built and deployed globally.

I was initially hesitant because though ventilators were big in the news a couple of weeks ago, by now I’ve heard of dozens of projects. When I learned more about the team and their goals, I was impressed. They aren’t trying to rush a product out the door for a crisis. Rather, they're aiming to solve the second wave, and in particular help people in economically disadvantaged countries.

If you read the news about other ventilator projects, most of them are not dealing with FDA approval. Or, they're just trying to get certified for an emergency. Respira is working toward a full medical-grade product that can be assembled with available parts for under $500. 

It became clear to me that ICS needed to devote resources to this project because we're all in this together. I feel strongly that if you're in a position to help, you should help. So we are.

Unlike every other project ICS works on, the Respira project is not under NDA so I'm free to share details. I thought you might find this interesting so I'm planning to blog about it regularly. I’ll keep posting progress updates every few days as the project develops so check back often.