Students build medical devices and apps in this class, but making them work is only half the lesson
They didn’t just get up and give a pitch, Shark Tank-style. No, this group had to have a real product—working demos of a medical device and iPad app that they were trying to sell to the owners of Jumbo Medical, a firm they were told had missed the mobile boom and was trying to play catch-up at an upcoming trade show.
That was the challenge for the 19 students in Ron Lasser and Ming Chow’s engineering class, Mobile Medical Devices and Apps, heading into the first week of December. They had spent the semester working in teams to develop thermometers, pulse detectors and EKG monitors capable of sending wireless data to an iPad app that displayed patient information in real time.
The assignment was a formidable one. The students had to understand signal processing, iOS app programming and how to make hardware communicate with the app. The problem was, of course, that not a single student coming into the class knew everything that was required to succeed. They had to learn new skills on their own—no lectures here. Probably hardest of all, they had to focus on the customer—the doctors and nurses—all the while making sure the technology they developed would work.
As they got up in front of their classmates and professors in Halligan Hall, the first team gave its pitch, sounding assured. With a minor glitch—waiting for the iPad to connect to the Wi-Fi—they got through the presentation and nodded to the polite applause.
Then came the questions. Why were the app buttons on the bottom of the screen so small—wouldn’t a busy nurse not see them? How exactly would the device hook up to a patient? Why would a hospital want to use this instead of what they were already using? And those were just the queries from fellow students. Lasser, a professor of the practice of electrical engineering, and Chow, E02, E04, a lecturer in computer science, asked more pointed questions. Did the team think about how the wireless patient data would be secured? How would they identify each patient on the display?
Learning How to Learn
Throughout the fall, the student teams had assignments building up to the end-of-semester project. They had to give presentations, just like they would for a design review at an engineering firm.
In early October, the teams presented their first products: devices to continually measure patients’ temperatures, along with their first stab at an iPad app. Three teams in succession presented one day, all making the assumption that patients would be able to keep the thermometer under their arms.
Throughout the class, the other students had asked plenty of questions about the technology and the app, but it wasn’t until after the third team gave its presentation that one student raised her hand and pointed out the real-world usability problem: patients can’t be expected to hold their thermometers in a hospital setting.
Lasser and Chow nodded, and added their own critiques. The students were not incorporating ideas from other teams that had presented the previous week, and Lasser was disappointed. “You’re too polite,” he told one team. “The world is not polite.”
“One of the students came up to me after a class and said, ‘Every week we do a presentation, and you guys rip us apart,’” reports Lasser, who has 25 years of experience as an engineer in the private sector. The class, he says, tries to model a design review in industry, and that involves feedback. “They were so wrapped up in the technology that they didn’t realize that the customer came first,” says Lasser. “Our questioning made them realize that there’s more than the technology. We kept asking, ‘Who’s the customer?’”
A design review, he says, “is where you bring your circuit to the table, and we hack it to pieces to make sure it’s robust, reliable. In industry it’s very important to not hide a flaw—it’s a lot cheaper when it’s a schematic on a piece of paper than after there are a million pieces of hardware out there.”
With the help of visiting lecturers—a former president of a hospital, a founder of a mobile medical company, a cardiologist and hospital information officer—the professors tried to get the customer-centric message across. “It’s been a struggle all semester to get [the students] out of the technology; they are just in love with the technology,” says Lasser.
Real Life Lessons
In the engineering world, the only constant is change, Lasser notes. “The tools are changing; the computer languages are changing—you better be learning for the rest of your life. And if you haven’t learned how to learn before you leave here, you’re in trouble.”
Such a lesson will be valuable once students are out in the world. “I don’t think that the students will appreciate what Ron and I are doing until two or three years later, when they are out there doing this professionally,” Chow says. “One of the problems we both see is that they are worried about a grade. That’s just painful for us.”
Back in his office, Lasser nods. “Students are afraid to fail.” He points to the top of his whiteboard. It reads: “Fail. Realize your failure. Fail forward, recover quickly and get back on track.”
“This class gives them a flavor for real engineering problems—we’re trying to simulate the engineering design experience,” says Lasser.
At the semester’s end, the students seem to be getting the point. “This class is very different,” says Alex Henry, E15. “It’s teaching the engineering process. The focus is on why you’re building what you’re building.”
“In normal classes, there are problems where we know there is a solution, but with this, even the problem is not well defined,” says Sam Bronner, E16.
At the end of one group’s final presentation in December, Chow asks the team to tell the class what they learned. “For me one of the biggest lessons was the trade-offs,” says Brad Frizzell, E15. “You can always keep thinking of more things to do, but at some point, you have to cap it and say, I’m going to go with these things and do what I can.”
Chow and Lasser glance approvingly at each other. The lesson is being learned.
Taylor McNeil can be reached at firstname.lastname@example.org.