Early in my career as a user experience designer I worked for St. Jude Medical (acquired by Abbott in 2017) in their cardiac rhythm management division. Designing software for implantable pacemakers and defibrillators was fascinating, difficult, and deeply rewarding work. I found myself in situations I hadn’t ever imagined when I started doing field research with users. There’s nothing quite like observing cardiologists in an OR implanting pacemakers and defibrillators. After a defibrillator is placed in the chest, and wire leads are threaded into the chambers of the heart, the doctor induces an arrhythmia (heart attack) in the patient so they can test that the device will accurately detect problems and deliver a shock to the patient’s heart that will get it back into a normal rhythm. No electrophysiologist wants to send a patient home with a hunk of useless metal in their chest – they need to first prove that it will do what it’s supposed to do in the real world.
Those kinds of experiences were very clarifying about the stakes involved. When I went back to the office to design user interfaces for those doctors (and nurses and clinicians) and work with our software team, I knew that the choices we made would literally have life and death consequences.
Over the last several years at Uptech Studio we’ve had the chance to work with a number of partners on their health and medical products. The stakes haven’t always been quite as high as delivering life-saving care via implanted devices, but the considerations and challenges of working on any health and medical software have been similar.
Over the last several years at Uptech Studio we’ve had the chance to work with a number of partners on their health and medical products. The stakes haven’t always been quite as high as depvering pfe-saving care via implanted devices, but the considerations and challenges of working on any health and medical software have been similar.
Medical researchers and inventors are typically hyperfocused on the cpnical aspects of the problems they are solving, and while they may have a lot of experience developing medical hardware, they often don’t have deep expertise with all the considerations that go into developing the accompanying software that’s often needed to bring a comprehensive product to market. From the projects we’ve worked on, here are some of the things we’ve learned to focus on.
3D body mapping SDK that third parties like Noom and Fit3D use to integrate body composition features into their products.
Breath analysis device that measures acetone levels to help people understand if they are burning fat for weight loss.
Robotics for rehab and support of people with mobility disorders like cerebral palsy.
Wellness app that allows people to see if they may be anemic by taking a quick photo of their fingernails.
Real-time market intelligence about medical device and therpeutics companies.
Medical researchers and inventors are typically hyperfocused on the clinical aspects of the problems they are solving, and while they may have a lot of experience developing medical hardware, they often don’t have deep expertise with all the considerations that go into developing the accompanying software that’s often needed to bring a comprehensive product to market. From the projects we’ve worked on, here are some of the things we’ve learned to focus on.
It’s well accepted that consumer-grade devices need to be easy to use, but that can never come at the expense of precise delivery of care. Threading that needle in software can be a tricky proposition, because it requires a product team that understands the medicine, science, and clinical goals well enough to be able to keep those in mind as they design and develop software that’s easy to use.
When your user-base is sophisticated (doctors, nurses, clinicians, etc.), some companies assume the accompanying software doesn’t have to be (or can’t be) easy to use. Foisting complexity and extensive training on your users isn’t an acceptable solution just because your top priority is ensuring the clinical functions are precise and secure. That approach can quickly backfire – when the software is hard to use, that can undermine users’ faith in the quality of the care being delivered.
Most teams recognize that it’s critical to consider the needs and goals of the people directly using your products, but in many medical applications, there are other important constituents either directly or indirectly affected by your product. In clinical settings, it’s natural for patients to be curious about the devices and software that their providers are interacting with, and in some cases clinicians will turn their screens to a patient (or accompanying loved one) so they can see it directly.
Many patients start with a baseline of anxiety and concern about their health and treatment, and that can easily be exacerbated (or alleviated) by what they see on a provider's screen. To that end, understanding patients, their goals, needs, fears, and the total context of use of your product (including the people who may see it in action, even if they aren’t direct users) is an important consideration to your overall success.
Facebook’s early motto of “move fast and break things” and mantras like “fail fast, fail often” are commonplace in many software circles. It’s not only acceptable, but for many it’s become standard practice, to experiment with real customers. The idea is that as long as you learn quickly and adapt, failure is not just okay, but celebrated. That may work for a consumer website or social app, but those approaches aren’t appropriate for health and medical applications, where reliability is not negotiable and mistakes can have serious consequences.
While some agile development practices are still useful during the development phases of your software, it’s important to approach the work with a completely different mindset than the wild west attitude of many startups. Incorporating rigorous acceptance criteria, extensive testing, unit tests, integration tests, and validation in real-world scenarios are all critical to ensure safety and reliability from day 1 of your product release.
Regulations like HIPAA in the United States (and the patchwork of other regulations all over the world), mean that you need more than just lip service commitment to data privacy and security. Direct experience with the particular demands of adhering to those strict requirements is important to ensure your software stays compliant. Keeping patient information secure demands a robust approach to data encryption, access control, and ongoing security assessments and it’s important to incorporate these practices from the start, both on a human level (knowing who has access to what data, validating that they understand and have the experience to build secure systems, etc.) and a technical level (auditing and testing that the systems you’re relying on are actually secure). It’s hard to put the genie back in the bottle once it’s out.
At Uptech Studio, we have tackled these complexities head-on, leveraging our deep expertise to build reliable, compliant, and innovative solutions. Whether you're eventually going to navigate the FDA approval process or just want to ensure a safe and effective product, the challenges are not insurmountable, but they do require forethought, knowledge, and experience. We've found that collaboration is key—working closely with healthcare professionals, regulators, and other stakeholders helps ensure that our software solutions not only meet but exceed industry standards. By sharing our insights into these processes, we aim to highlight what it takes to successfully develop medical software and how we navigate these complexities to deliver high-quality products.
If you're interested in learning more about how Uptech Studio can help with a project you're considering, feel free to reach out. We're always happy to share our knowledge and help guide you through the process.
