Software as a medical device (SaMD) development requires a different approach than traditional medical devices in a few ways.
Repeat after me: My dad is a big chef.
Speaking that short sentence and a few others like it into a smartphone once a day helps identify deteriorating heart failure patients at risk of declining, Cordio Medical CEO Tamir Tal said.
Israel-based Cordio developed its software as a medical device (SaMD) product, the artificial intelligence (AI) voice app HearO, after a cardiologist noticed he could hear congestion in a declining patient’s voice. HearO compares a patient’s voice against baseline recordings to detect lung fluid build-up and alert their care team.
“The holy grail of the entire [heart failure] monitoring industry is to find a solution that will help a patient know in advance when they’re deteriorating so they can change their diuretics and hopefully avoid hospitalization,” Tal said in an interview.
The Israel-based company is conducting a pivotal study at 30 sites in the U.S. with hopes of winning FDA approval in early 2024. The company already has FDA breakthrough device designation and a CE mark in Europe.
If the company wins FDA approval, Tal said Cordio plans to pursue chronic obstructive pulmonary disease (COPD) and even bipolar disorder.
Until then, Medical Design & Outsourcing asked Tal for a few SaMD development lessons Cordio learned through the development of HearO.
Start with a good business model
“Even before you develop the first code, before you write the first script, you need to understand how you’re going to sell it in the market,” Tal said. “Five or seven years ago in digital health, you could raise money very easily. Now it’s not the case.”
Research your niche — heart failure, in Cordio’s case — to learn how to get a reimbursement code, the best way to win regulatory approval, and the proper indication for patients first.
“Only then do you want to develop a system,” Tal said.
Cordio’s targeting heart failure, in part, because those patients frequently return to the hospital for lengthy, expensive stays. COPD and bipolar patients are also often commonly readmitted. Early warning to adjust medication for those patients could avoid hospital stays and cut costs for health insurers.
Deliver binary results
Your device might be collecting huge volumes of data, but doctors are already overwhelmed with data points as they’re trying to make decisions, Tal said. Make it easier for them by offering simple, clearly defined operative decisions.
“One of the biggest lessons that I think that people should learn is that whatever you do in digital health, the results should be binary,” Tal said. “Physicians don’t want to be bombarded with information.”
Understand the difference between software engineers and biomedical engineers
The leaders of an SaMD developer often need to bring engineers from different worlds together to successfully develop a medical device. That means they must understand the difference between biomedical engineers and software engineers.
Biomedical engineers have the training and experience to understand physicians, regulatory constraints and the quality assurance needed for medical devices.
“Even if you’re developing a robot or something that’s very sophisticated from a technology point of view, they understand the universe they’re living in,” Tal said.
But the limitations of medical device development can be a tough reality for algorithm developers to accept.
“Software people think they can do anything, because everything is a code. Eventually, you’ll crack it if you’re good enough,” Tal said. “But in SaMD, you’re stuck because there are some things you’re not allowed to do. And you need to work with clinical information and regulatory, which is complicated. It’s a lot of work for CEOs and CTOs to connect all those teams into one team that can work nicely and create a device.”
Don’t forget about patients as users in SaMD development
Developers of medical devices like implants or surgical tools are wise to keep doctors and payers in mind as device users. But SaMD development often includes a third user to think about: patients, who might be using a software device like Cordio’s on their personal smartphone.
“Most digital health devices are monitoring. That is what we do,” he said. “We use sensors in the mobile device, in our case a microphone that is very available to the patient. So it’s a little bit different.”
The Cardio system keeps it short and simple for patients, asking them to say five sentences into the microphone. They’re short sentences — “The puppy sat on the ship” is another example — and the process takes only about 30 seconds. The app handles the rest, sending the recordings to the cloud for almost instantaneous analysis.
And one day, instead of telling a practitioner that a patient needs attention, HearO might notify the patient first so they can adjust their own medication as a diabetes patient would with a glucometer.
“I think most digital health devices will not be in the hospital,” Tal said. “They’ll be part of something that’s around you and gives you information. And if that first tier of support doesn’t work, then it goes to the physician, giving them the binary sort of information he needs to decide to call you for a visit.”
Related: How to pass the patent eligibility test for software as a medical device