The following is the third of a three-blog series on the Validated State. This content builds on ideas first presented by Randy Horton, Bernhard Kappe and Pat Baird of Philips at the AAMI ISC 2021 conference. Orthogonal and industry partners will continue to present on this subject at conferences in 2022. For more details, visit our Events page.
Links to each blog:
During the discussions of the AAMI CR:510:2021 Task Group, something unexpected happened. The group was formed to create preliminary guidance on cloud computing for medical devices and quality systems. As Orthogonal and the other members of the Task Group solidified their six key recommendations, they had a fundamental insight: The validation of software in a computing environment that you don’t have full control over was a concept not limited to the cloud. It was much bigger.
Exciting innovations and advances in hardware, software, data and networking have brought about an age of interoperability. Examples include AI/ML algorithms, web services, consumer mobile phones and tablets. Software developers, device manufacturers and other professionals can plug in and swap out different components without compromising the whole system. It’s a trade-off; you gain a tremendous amount of functionality in a very cost-effective way, but in return, you give up a degree of control over how your device operates. Just as third-party cloud vendors can swap in new servers, new code and new features that challenge our validated state, so too does interoperability challenge what we do in the medical device industry.
Software as a Medical Device (SaMD), Digital Therapeutics (DTx) and connected medical device systems do not operate in a completely isolated environment. These trusted systems for diagnosis, monitoring and therapeutics combine third-party data, software, APIs, Software Development Kits (SDKs) and interoperability protocols to enable patients and clinicians to address health issues in novel ways. All of these third-party solutions make the creation of a powerful and effective medical device a reality. Patients today use them to manage their symptoms, gain more control over their day-to-day lives and support healthier behaviors.
But just as we relinquish control in the cloud, we are inviting uncertainty when we use third-party solutions. We add risk by relying on data from a third-party API, for example. If a device uses real-time weather data from a weather API to aid in forecasting symptom onset, what happens if that API goes down? Does a major outage put our patients’ health at risk?
We add in another layer of uncertainty when we deliver SaMD and DTx through mobile phone apps. ScientiaMobile estimates that there are over 88,000 combinations of smartphones and operating systems on the market today in the US alone. It’s a staggering number, but even if we were dealing with just a fraction of that amount, it would still be too much to control for.
The six key recommendations from the AAMI Consensus Report are a great first step, and the Task Group acknowledges that more guidance is needed for specific use cases. Though we may visualize it as such, the cloud is not a single monolithic computing structure.
Pat Baird of Philips calls it the “Cloud of Clouds.” There are multiple clouds, hosted in a variety of locations and governed by different regulations. Take, for example, multi-cloud data center deployments. Medical device software may need to run in data centers in two different countries for regulatory reasons or for proximity to the user base.
Those data centers aren’t necessarily running the same version of the cloud – they’re upgraded at different times. Even if both data centers are owned by the same provider, the environments aren’t guaranteed to be identical. Now imagine running software on clouds from multiple different providers. As the flexibility goes up, so does the complexity.
The situation can start to get comically complex when you take into account how all of the third-party solutions your software relies on are run on different clouds hosted in different places by different cloud vendors.
All of this complexity is part and parcel of the interconnected world we live in. Third-party solutions have made a tremendous impact in our industry, but they pose a greater risk to our software than may be obvious at first glance. The question isn’t so much, “How do we host medical devices on the cloud responsibly?” but rather, “How do we manage interoperability in the operation of medical devices responsibly?”
Which is how we circle back to the novel concept raised in the AAMI consensus report, the intermittently validated state. An intermittently validated state is achievable as long as its transient nature is understood and managed by developers of any kind of modern software and computing technology.
Orthogonal’s VP of Solutions and Partnerships Randy Horton has dubbed this idea “This Is Not Your Grandmother’s Validated State” – which Pat Baird from Philips picked up on and then created the acronym TINY GVS (pronounced “tiny gives”). The world of software and computing is constantly evolving, so our concept of the validated state must evolve alongside it.
TINY GVS isn’t relevant to just the MedTech industry. This same concept is relevant to software in any form of critical infrastructure, such as oil rigs, public transportation and self-driving cars. They may not be regulated in the way we are in that they’re forced to prove a validated state, but validation is still important to their operation.
There’s a lot we can learn beyond the medical software development world, too. Adjacent technology sectors like AI/Machine Learning and Cybersecurity deal with shifts, emerging risks and unpredictable changes on a daily basis. We can take lessons from them and incorporate it into guidance relevant to MedTech.
TINY GVS could positively impact our work and our processes. Because of that, Orthogonal is planning as part of our work with AAMI to further advance the idea of guidance related to TINY GVS, possibly in the form of a new Consensus Report. Such a report could identify best and worst practices, as well as look for recommendations that could be applied across a variety of challenges that we face in our industry.
Orthogonal seeks to spark debate and conversations that further develop the concept of TINY GVS. If you believe TINY GVS has value to your work, we want to hear from you. Please reach out to Randy Horton or Pat Baird with your thoughts, opinions and critiques. Together, we can continue to evolve our industry and impact the larger computing world.
This blog was the third of a three-blog series on the Validated State. Links to each blog:
Bernhard Kappe, CEO and Founder
Randy Horton, VP of Solutions & Partnerships
Pat Baird, Head of Global Software Standards, Philips