Most verification and validation (V&V) frameworks in medical devices were built on a foundational assumption: the device you ship is the device that gets used. A fixed product, a fixed software version, and a defined validation cycle.
That assumption no longer holds.
Cloud-based connected health platforms operate as continuously evolving systems rather than static devices. Software updates dynamically, data flows bidirectionally between patient and infrastructure, and system boundaries extend beyond the physical device. This shift has exposed a structural mismatch between traditional regulatory expectations and modern system behavior, creating a growing compliance bottleneck for device teams.
Consider a home dialysis platform where treatment data is transmitted to a cloud system for monitoring and analytics. A backend algorithm update, intended to improve alert sensitivity, may not alter the physical device, but it can change clinical decision pathways. Under traditional V&V models, even such indirect changes may trigger re-validation requirements, creating friction that scales with deployment frequency. The legacy V&V approach was primarily written for the hardware (dialysis machine) and contained a lot of overhead. In my 1st month in Fresenius, I reached out to the head of my department to communicate this gap and proposed new strategies to better align with the Software focused approach
The core challenge lies in the regulatory model itself. Frameworks such as 21 CFR Part 820 and FDA software validation guidance were developed around a release-based paradigm: validate a defined version, document extensively, and manage subsequent changes through formal change control. While appropriate for static systems, this model introduces significant operational friction for cloud-based platforms where updates are continuous and system behavior is distributed across device and infrastructure.
The FDA has acknowledged this tension. Its 2019 action plan on Software as a Medical Device and subsequent Digital Health Center of Excellence guidance began outlining a more iterative regulatory posture, but implementation at the device team level is still catching up. The proposed Pre-Determined Change Control Plan (PCCP) framework offers one pathway for managing post-market software changes within a pre-approved scope, but it places significant upfront documentation burden on engineering teams.
Agile complicates this further and also helps, but only if structured carefully.
There’s a common assumption that Agile development and FDA-regulated environments are incompatible. They’re not, but the integration requires deliberate architecture. Sprint-based development can coexist with IEC 62304 software lifecycle requirements if risk classification, traceability, and test coverage are built into each sprint rather than retrofitted at the end. IEC 62304, the international standard governing medical device software development, explicitly accommodates iterative development models — the obligation is traceability and risk management, not waterfall sequencing.
CAPA processes face a similar translation challenge. Corrective and preventive action workflows designed around physical device defects don’t map neatly onto software bugs in a cloud system where root cause might sit in an API layer, a third-party dependency, or a configuration drift that’s difficult to reproduce. Building CAPA frameworks that can handle that complexity without creating compliance theater, documentation that satisfies auditors but doesn’t actually prevent recurrence, is its own discipline.
Cross-functional coordination is where theory meets reality. In practice, a single software release on a connected health platform may require sign-off from engineering, quality assurance, regulatory affairs, product management, and clinical teams, each operating from different risk tolerances and documentation requirements. The coordination overhead is substantial, and when those teams are geographically distributed, the challenge compounds.
There’s also a talent problem sitting underneath all of this. Medical device companies have traditionally hired V&V engineers from clinical or hardware backgrounds. Cloud software companies hire from a completely different talent pool. Connected health platforms need engineers who can read a 510(k) submission, understand clinical risk, and also reason clearly about API behavior, cloud infrastructure, and continuous integration pipelines. That person is genuinely rare, and the industry hasn’t fully developed a pipeline for training them.
Regulatory frameworks will continue to evolve, but they will not close this gap on their own. The responsibility is shifting toward engineering and program teams to operationalize compliance in environments that were never designed for static validation models. The organizations that succeed will not be those that simply adapt legacy V&V processes, but those that redesign them, treating compliance as an integrated system capability rather than a downstream activity. In connected health, this is no longer a regulatory exercise; it is a core engineering discipline.
About Henna Purkait
Heena Purkait is a Senior Engineering Project Manager at Fresenius Medical Care, where she leads engineering programs for cloud-based dialysis and connected health platforms. She is a named inventor on a published U.S. patent for a dialysis treatment file simulation and verification system that strengthens patient safety and regulatory compliance. Over 15 years in medical device engineering, she has guided multiple product releases through FDA-regulated and EMEA environments, moving from hands-on verification and validation into global program leadership.
