Code You Cannot Read, Patients You Cannot Save: The Closed-Source Crisis Inside American Medicine

In a cardiac intensive care unit, a nurse notices that a patient's implanted pacemaker is transmitting irregular data to the bedside monitor. The attending cardiologist wants to examine the device's firmware logs to determine whether the anomaly is hardware-related or a software artifact. The answer could change the treatment plan entirely. But the manufacturer's licensing agreement prohibits independent inspection of the device's code. The hospital's biomedical engineering team is locked out. The cardiologist must wait—sometimes hours, sometimes longer—for a manufacturer representative to arrive or respond. The patient waits too.

This is not a hypothetical. It is a routine feature of American healthcare in 2024.

A System Built on Opacity

The vast majority of medical devices sold in the United States—from insulin pumps and ventilators to MRI machines and surgical robots—run on proprietary software that manufacturers treat as trade secrets. The Food and Drug Administration requires that devices demonstrate safety and efficacy before reaching market, but it does not require that the underlying code be made available to clinicians, independent researchers, or the hospitals that purchase and operate these systems.

The consequences of this opacity extend well beyond inconvenience. When a ventilator's alarm algorithm behaves unexpectedly, biomedical engineers cannot trace the logic. When a glucose monitor's calibration routine drifts, endocrinologists cannot audit the calculations. When a hospital-grade infusion pump delivers medication at an incorrect rate—a documented and recurring class of incident—the clinical staff responsible for patient safety cannot examine the software pathway that produced the error. They can only report it to the manufacturer and hope for a timely response.

The FDA's Medical Device Reporting database contains thousands of adverse event filings in which software behavior is listed as a contributing factor. Yet in the overwhelming majority of those cases, the source code responsible for the failure remains inaccessible to anyone outside the manufacturing company.

The Right-to-Repair Dimension

The problem is compounded by the medical device industry's aggressive use of intellectual property law to prevent independent repair and maintenance. Much as automotive manufacturers once attempted to restrict third-party mechanics from accessing onboard diagnostic systems, medical device companies routinely use software licenses, digital rights management technology, and proprietary calibration tools to ensure that only their own certified technicians can service equipment.

For large urban hospital systems with robust service contracts, this is an expensive inconvenience. For rural critical-access hospitals operating on thin margins, it can mean that a malfunctioning imaging system sits idle for days while awaiting a manufacturer technician who must travel from a regional service hub. During that window, patients requiring diagnostic imaging are transferred, delayed, or go without.

The pandemic exposed this vulnerability with unusual clarity. As hospitals scrambled to maintain ventilator fleets under unprecedented demand, biomedical engineers reported being unable to perform basic maintenance on devices because the software required for calibration was locked behind manufacturer portals that were themselves overwhelmed or unresponsive. Some facilities turned to improvised solutions. Others simply lost the use of equipment they legally owned.

Who Bears the Burden

The distribution of harm from medical device lock-in is not random. It follows the familiar geography of American inequality. Community hospitals serving low-income and rural populations are less likely to hold premium service contracts, less likely to have on-site manufacturer representatives, and less likely to have the institutional leverage to negotiate favorable licensing terms. When software-dependent devices fail in these settings, the populations already facing the greatest barriers to healthcare access absorb the greatest risk.

Disabled Americans face a distinct dimension of this problem. Individuals who rely on implanted or wearable devices—cochlear implants, neurostimulators, continuous glucose monitors—are frequently unable to access the data their own bodies generate. The software that interprets and transmits physiological information belongs, in a meaningful legal and practical sense, to the manufacturer rather than to the patient. Customization, interoperability with other health tools, and independent troubleshooting are all constrained by proprietary architecture that was never designed with user autonomy in mind.

The Open Alternative Is Already Here

The argument that open-source software is incompatible with the safety standards required for medical devices does not withstand scrutiny. The Linux kernel—open-source software developed collaboratively by thousands of contributors worldwide—powers systems in aviation, nuclear energy management, and financial infrastructure. The OpenAPS and Loop projects, developed by the diabetes patient community, created open-source automated insulin delivery systems years before proprietary manufacturers brought comparable products to market. The FDA has since cleared several of these systems, acknowledging that community-developed, transparent code can meet rigorous safety standards.

A number of academic medical centers and research institutions have begun advocating formally for open-source requirements in publicly funded medical device development. The argument is straightforward: when federal research dollars through the NIH or NSF contribute to the development of a medical technology, the resulting software should be available for public inspection, independent validation, and iterative improvement.

Several European health systems have moved further in this direction, requiring that devices procured for public hospitals include provisions for source code escrow or open licensing. The United States has no comparable federal standard.

What Reform Would Require

Advocates working at the intersection of healthcare policy and open-source technology have outlined a coherent set of demands. First, the FDA should require that software running on life-critical devices be submitted for public review as part of the premarket approval process—not merely evaluated internally, but made available to independent security researchers and clinical informaticists. Second, Congress should extend right-to-repair protections explicitly to medical devices, ensuring that hospitals and biomedical engineers can perform maintenance, diagnostics, and calibration without manufacturer permission. Third, federal procurement standards for devices purchased by VA hospitals, federally qualified health centers, and other publicly funded facilities should include open-source licensing requirements.

None of these measures would eliminate proprietary medical device software overnight. But they would establish a floor of transparency and accountability that currently does not exist—and they would create the conditions under which open alternatives can develop, compete, and ultimately improve care.

The Code Is the Care

Medicine has always understood that the tools clinicians use shape the outcomes they can achieve. A scalpel a surgeon cannot hold, a medication whose chemistry cannot be examined, an imaging protocol whose parameters cannot be adjusted—these would be recognized immediately as failures of the healthcare system. Software that physicians cannot read, audit, or repair is no different in principle. It is only different in the legal and commercial frameworks that have been constructed, largely without public deliberation, to normalize the opacity.

The movement for open medical device software is not an argument against innovation or against the companies that invest in developing life-saving technology. It is an argument that the public interest in transparent, auditable, equitable healthcare must be weighed against the private interest in perpetual code secrecy. In a system where the software is, increasingly, the medicine, that argument is long overdue.