In this module, we discuss regulations that apply to medical-use software, applicable legislation, and general principles on the road to legal compliance.

Introduction

Most of our discussion has centered around the physical or academic nuances of medical technology: wearable devices, or the theory of “big data,” for example. Each sits uniquely in its own realm: physical technology is able to impact patients and actively change the outcome of a situation, while academic data and case law sit as passive, intangible entities: useful as a resource, but dependent on active actions of an operator or user to effect any real change. Software, therefore, sits in a unique position: though it lacks the tangibility of a physical device, its position as the controlling force of end-user technology and access to passive data allows it to straddle the line between active and tangible roles.

Software has always held this transitive role, independent of its target field. However, just as medical devices are held to a higher operative standard than general consumer equipment, the FDA regulates “Software as a Medical Device” (henceforth SaMD, as defined by the International Medical Device Regulators Forum¹, a.k.a. IMDRF) to ensure safe medical practice for all. While this module focuses on a United States-centric view of SaMD, similar principles apply to international devices, subject to local legislation and law enforcement. By understanding the underpinning principles of SaMD regulation and testing to avoid compliance issues, tragedies such as the landmark Therac-25 incident (which we will consider as a case study) can be mitigated or avoided completely on the road towards zero deaths.

Scope: the Divide between Software and SaMD

Since the dividing line between ordinary, non-medical software and SaMD can be arbitrarily defined, working definitions must be set in place to limit the scope of harsh regulation. (An overzealous limit, for example, might classify LibreOffice or Microsoft Office as SaMD because “it is used to handle medical data.”) Regulatory bodies do not universally agree on a definition, though they do recognize the need for more concrete legislation. From a European standpoint, Emergo (a UL company) suggests the following definition, summarized here:²

• Any software intended for analysis of patient data output from a medical device, primarily for diagnosis and monitoring, is SaMD.
• Any software intended for patient use to diagnose or treat a physical or medical ailment is SaMD.
• Any software that is a component of or integral to a physical medical device is SaMD.

Emergo further suggests that software dealing with either the design/manufacture of a medical device or handling merely administrative data should not be considered SaMD. The FDA, however, takes a different stance³, holding that software that is “part of a hardware medical device” should be considered as a module of the device, and not SaMD in and of itself. Instead, their guidelines contend that the following scenarios are generally SaMD:

• Software directly interfacing with a medical device.
• Medical-use software running on general-purpose computing hardware.
• Software that connects to and provides optional functionality for a hardware medical device.

Regulation: Current Standards

From a legal perspective, SaMD has surprisingly small amounts of concrete legislation. While the typical requirements of any medical device still apply, software-specific regulations have proven difficult to effectively legislate. This is likely caused by the inherent difficulty of regulating the flexible, myriad world of software design with rigid, enforcable legal boundaries. Instead, regulatory groups have published numerous documents concerning best practices and recommendations for optimal SaMD design. Most notable among these are the FDA’s series of recommendations and the IEC’s published standards.

In partnership with other national health organizations, the FDA has formed the previously-mentioned IMDRF to study the impact of SaMD and create initial recommendations to base future legislation upon.⁴ In the meantime, these same recommendations provide useful benchmarks against which good software can be tested. For example, the below spreadsheet outlines a risk categorization framework developed by IMDRF, weighing the severity of a healthcare situation versus the significance of SaMD’s situational role, providing a classification system that could be used to drive legislation (similarly to how physical medical devices are classified).

The IEC, in contrast, has used its status as “not a governing body” to shift the focus away from legislation and towards establishing a high standard of conduct that, if met, yields a guaranteed measure of trust in the relevant SaMD. Most notably, IEC 62304⁵ presents a “benchmark standard” concerning the development and life cycle of SaMD. In particular, the standard considers SaMD’s journey from inception to development and onward through mass usage, up until its retirement, as well as documenting a requirement for a risk management system and general procedures for hazard-reduction.

Case Study: Therac-25

The importance of careful regulation during the development and testing of medical software is highlighted by the Therac-25 scandal: in brief, the Therac-25 was a poorly-designed machine capable of delivering both direct low-intensity radiation therapy and, using a protective filtration system, high-intensity X-ray therapy. Due to numerous errors in the machine’s design and operation, high-intensity doses of radiation were erroneously emitted directly at patients prescribed low-intensity doses, resulting in high-dose X-rays contacting the patient without protective filtration in place. (Wikipedia provides a more in-depth historical summary, with links to further resources.)

As highlighted in David A. Vogel’s textbook on SaMD validation⁶, a combination of key failures are to blame for the failure incident, each demonstrating a different focus of importance during software development:

• Overconfidence in software: hardware was initially blamed for the failure, stalling failure-analysis by wrongfully considering code as infallible.
• Lack of defensive design: lacking service logs, hardware interlocks, and adequate software checks, no complete system existed to provide redundancy in case a subsystem failed.
• Symptom mitigation (as opposed to root-cause analysis): one procedure that could trigger radiation overdose involved repeatedly pressing the “proceed” and “up-arrow” keys on the user-input terminal. The Therac’s developers official solutions involved inhibiting the “proceed” functionality and physically removing the “up-arrow” keys: mitigating the symptom, but not addressing the root cause.
• Lazy software development: proper softare development practices were not implemented: testing was limited, documentation was not given priority, quality assurance (a.k.a. QA) testing was absent, user interface was poorly designed, the fundamental architecture was potentially overly complex, and software from previous systems (notably, with hardware interlocks) was reused without extensive refactoring and/or full understanding of its operation.
• Poor failure handling: overconfidence from reliable previous designs led the Therac’s support team to erroneously attribute failures to operator error, and responses to failure reports were neither timely nor thorough.

From this, key design principles can be derived:

• Distrustful design: by assuming nothing about a system without first verifying it, time spent chasing nonexistent failure causes can be mitigated and eliminated.
• Defensive design: in a similar vein, if each submodule of a system assumes that other modules (or itself) are subject to failure, design choices can be made to constantly verify safe operation. Similar to the extensive work required to ensure the security of sensitive data, SaMD design should ensure the safety of patients and operators at every step of operation.
• Root-cause analysis: Similar to the process of medical diagnosis from initial symptoms, failures in medical devices should be analyzed thoroughly to determine the root cause. Fixing symptoms will inhibit functionality and can leave the root issue prone to causing other failures; fixing the root issue directly almost always takes more time, but ensures thorough, consistent operation.
• Good software development practices: Like development of non-medical software, SaMD should always be tested thoroughly, completely documented, intuitive to use (while not inhibiting safety checks), and validated at every step, from supporting libraries to integration with final hardware (in the case of SaMD controlling a physical device).
• Aggressive failure-response: any SaMD failure can lead to further problems, possibly life-threatening. Failure response should be swift and thorough, distributing immediate emergency measures if needed while time is taken for a proper solution.

Prevention: Ensuring Compliance

As demonstrated, software is by nature a wildly flexible beast, difficult to pin down with precise, unmoving legislation; as such, definitions and regulations surrounding SaMD consist mostly of nonbinding recommendations and guidelines, with definitions that vary between regulatory bodies. The onus, then, is on the software’s developer to ensure that any piece of SaMD is reliably safe to use in critical medical environments. Beyond standard measures of “good development” inherent to any product’s creation, developers should carefully reference the relevant SaMD definitions and guidelines as necessary, selecting standards based upon the target region and market. When in doubt, the IEC’s position as an international standards organization gives its guidelines and standards requirements a measure of merit to worldwide audiences: IEC standards-compliance provides a useful benchmark that is meaningful no matter the local regulatory body. In the end, like anything, knowledge is the key to ensuring safety through standards compliance: knowledge of past pitfalls, knowledge of current standards, and knowledge of leading design principles, culminating in a useful pinnacle of information that guides the path towards developing safe SaMDs.

---

References and External Links