He Published My Life-Saving Heart Algorithm in the New England Journal — Then the FDA Required the Original Validation Dataset

The calibration syringe was a precision instrument — a glass barrel, 10 milliliters, with a plunger ground to tight tolerances. Dr. Grace Kim held it the way she always held it: thumb on the plunger flange, two fingers around the barrel, feeling the slight resistance as the plunger moved through the glass. The resistance was familiar. She had learned it years ago and she would know immediately if it changed — if the seal was wearing, if the barrel had developed a hairline crack, if the lubrication on the plunger needed attention.

The glass was scratched from years of bench work. The scratches were on the outside, not the bore, and they did not affect the precision of the injection. She knew this. She kept using it.

She positioned the syringe at the injection port on the cardiac monitoring device and pressed the plunger at the controlled rate that produced the standard Wolff-Parkinson-White waveform — a specific pattern of electrical current that mimicked the heart rhythm produced by the WPW cardiac pre-excitation condition. The WPW pattern was the target the algorithm had been designed to catch.

The waveform appeared on the device display.

The alert fired.

She recorded the result in the calibration log: Device ID, test number, waveform type, device response, calibration result. PASS.

Mara was at the adjacent bench, documenting the hardware validation protocol — the formal test sequence required by the FDA before a medical device modification could be released. She was 25 and had been the validation technician on the monitoring system project for fourteen months. She was cited in the Design History File as verification witness. She knew every test in the protocol.

“The alert time,” Grace said. “Check the timestamp against the reference.”

Mara checked. “Within tolerance. 0.3 seconds.”

“Log it.”

Mara logged it.

The Wolff-Parkinson-White alert algorithm was Grace’s design. The WPW condition was a cardiac pre-excitation pattern — accessory electrical pathway between the atria and ventricles, bypassing the normal conduction system. It produced a distinctive electrocardiographic signature: a shortened PR interval, a delta wave at the beginning of the QRS complex. Standard single-lead cardiac monitors routinely missed the intermittent WPW pattern because the delta wave was not always present — it appeared when the accessory pathway was conducting and disappeared when it was not. A patient with intermittent WPW could have a normal ECG on a single-lead monitor during the non-conducting phase and a lethal arrhythmia during the conducting phase.

She had solved this with a weighted multi-lead correlation. The algorithm analyzed six leads simultaneously, weighting each lead’s contribution based on the probability that the delta wave would be visible in that lead for a given patient’s cardiac geometry. The weighting was dynamic — it updated as the patient’s baseline was established over the first 24 hours of monitoring. The result was a 94.7% sensitivity for WPW detection across the six-lead configuration.

The 4-lead version had reached 87%. The 6-lead version had reached 94.7%.

She had built the 6-lead version over fourteen months of clinical data training.

—

At the month-eight clinical validation review, she had presented the sensitivity and specificity data to the hospital team. Vance had attended. She had displayed the performance chart on the room’s projector.

He had said: “This is exactly what I envisioned when I defined the clinical requirements.”

She had said: “The 6-lead correlation is what pushes the sensitivity above the 90% threshold. The 4-lead version only reaches 87%.”

He had said: “Right. We got there.”

He had used “we” in a room where only she had gotten there. She had been alone with the 6-lead architecture. She had been alone with the weighted dynamic calibration. She had been alone with the fourteen months of clinical data training that had produced the 94.7% sensitivity number.

He had attended the presentation.

She had presented the next slide.

—

The NEJM case report was published on a Tuesday. She read it at her bench, the calibration syringe in the test fixture.

Abstract: “The Vance Detection Protocol — a novel cardiac monitoring methodology developed under CMO Vance’s clinical leadership — demonstrates 94.7% sensitivity for intermittent Wolff-Parkinson-White syndrome detection in a 6-lead monitoring configuration.”

She read “developed under CMO Vance’s clinical leadership.”

She read “software development support” in the acknowledgments.

She set the syringe in the fixture. She read the case report from the abstract through the supplementary methods. The supplementary methods described the algorithm’s clinical validation — the sensitivity/specificity measurements, the patient cohort, the monitoring duration. The algorithm itself was described as “a multi-lead correlation approach” without the specific architecture.

She picked up the syringe. She ran the calibration test. The waveform appeared. The alert fired. She recorded the result.

She opened the Design History File on her workstation. FDA-RSE-2021-GK — her regulatory submissions ID — was in the header of every document in the file. Fourteen months of design decisions, each one dated and documented under her ID. She looked at the file for two minutes.

She closed it.

She opened the next test in the calibration protocol.

She had built the Design History File from the first day of the project.

The DHF was the regulatory requirement — the living documentation of every design decision, from the initial requirements specification through the final validation. Under 21 CFR Part 820, the FDA’s Quality System Regulation, the DHF had to be maintained throughout the development process, not compiled at the end. Every time she made a design decision, she documented it in the DHF. Every time she ran a validation test, she recorded the results in the DHF. Every time she modified the algorithm, she documented the rationale, the change, and the re-validation data.

Fourteen months of decisions. The DHF was 847 pages.

She had started the file on the day the project began, opened it under FDA-RSE-2021-GK, and documented every subsequent decision the same way. The WPW detection requirement had been specified by Vance’s clinical team in the initial requirements document: “The monitoring system shall detect intermittent Wolff-Parkinson-White syndrome with sufficient sensitivity to alert clinical staff before a lethal arrhythmia event.” That was the requirement. The requirement was clinical. The implementation — how to achieve “sufficient sensitivity” — was an engineering question she had spent fourteen months answering.

The 6-lead weighted dynamic calibration was her answer.

She had not told Vance about the 4-lead-to-6-lead architectural decision when she made it in month nine. She had documented it in the DHF and continued working. When the month-eleven data showed 94.7%, she had sent him the performance summary. He had been very satisfied with 94.7%. He had scheduled the NEJM paper submission that week.

He had not asked why the architecture had changed from the initial 4-lead design. He had seen the outcome.

She had built the outcome.

The cardiology conference had a standing-room crowd for Vance’s session.

He presented the monitoring system’s performance data. He showed Grace’s clinical sensitivity/specificity charts — the waterfall plot she had designed to display the algorithm’s performance across different patient subgroups. He described “our detection methodology’s” clinical superiority in WPW identification. He showed the 94.7% sensitivity number. He showed the comparison to the previous generation of monitoring devices, which had missed the WPW pattern in four patients in the same cohort.

He did not show the algorithm architecture. He did not describe how the 6-lead correlation worked. He described the clinical outcome — the patients who had not had events because the algorithm had caught the pattern — without describing the mechanism that had caught them.

Grace was not in the room.

She was at the testing lab, running validation tests on a second-generation hardware revision — the same algorithm, new sensor configuration. The new sensors had a slightly different impedance characteristic, which had required her to recalibrate the lead-weighting parameters. The recalibration had taken three weeks. The algorithm’s sensitivity on the new hardware was 94.9%.

She had sent Vance the updated performance data that morning.

The FDA audit notice arrived by email at 7:30 AM, addressed to the FDA-registered software developer on file.

That was her. FDA-RSE-2021-GK. The FDA’s registration system for software developers tied the registration to the submission record — every 510(k) clearance application she had submitted under FDA-RSE-2021-GK was linked to her registration. The monitoring system’s 510(k) clearance had been submitted under FDA-RSE-2021-GK.

The audit was triggered by an unrelated adverse event at a different hospital using a different cardiac monitoring device from a different manufacturer. The FDA had initiated a review of similar device types. The audit required the Design History File — the complete documentation of every software design decision from requirement to release — signed by the FDA-registered software developer.

She opened the DHF portal. FDA-RSE-2021-GK in the portal header. The developer field in every DHF document: Grace Kim, FDA-RSE-2021-GK. Fourteen months of entries, each one dated, each one in her notation — a specific documentation style she had developed for regulatory submissions, with a particular format for the requirement traceability matrix and the verification test records.

She looked at the calibration syringe on her bench.

She did not call Vance. She opened the DHF and began reviewing it for the audit response. The FDA’s audit request had a 30-day response deadline. She had 30 days to prepare the documentation package and the technical response.

She had built the DHF. She knew every entry.

She kept working.

Vance read the FDA audit notice in his morning email and forwarded it to his compliance officer with the note: “Routine regulatory review — please prepare the standard documentation package.” He had managed FDA interactions in his clinical capacity before. The compliance office would handle it.

He went to his next meeting.

She had been building the audit response package before the FDA notice arrived.

Not specifically for this audit — the notice had come on a Tuesday and she had begun the response on the same day. But the audit readiness had been ongoing. She maintained the DHF in audit-ready condition as a standard practice: current, complete, organized to the FDA’s expected format, with no gaps in the requirement traceability.

This was not unique to her. Every FDA-registered software developer who maintained a DHF correctly should be able to respond to a routine audit. The DHF was the response. You had either documented your design decisions or you had not.

She had documented every design decision for fourteen months.

The 30-day audit response window was sufficient. She had reviewed the DHF and found no documentation gaps. The requirement traceability matrix was complete — 48 clinical requirements, each traced to the specific software implementation that addressed it, each verified by the corresponding test record. The tests had been conducted by her and Mara, with Mara as the verification witness.

The compliance officer would coordinate the logistics — the meeting scheduling, the document production, the formal correspondence with the FDA investigator. She would prepare the technical documentation and respond to the substantive questions.

She knew what the FDA investigator would ask. She had built the DHF. She had the rationale for every decision in her memory, in addition to the documentation.

She kept working.

The compliance officer had found the answer in twenty minutes.

Under 21 CFR Part 820, the Quality System Regulation, the Design History File must be maintained by the responsible software developer. In a regulatory audit, the FDA required the developer to be able to respond to technical questions about the design decisions documented in the DHF — not in general terms, but specifically, with knowledge of the underlying engineering choices and their rationale.

The compliance officer had looked at the DHF. Every entry was in Grace’s notation. The requirement traceability matrix — the document that traced each clinical requirement to the specific software design decision that addressed it — was in her handwriting and her document format. The verification test records were signed by her as the responsible developer.

The compliance officer had then looked at Vance’s credentials. He was a board-certified cardiologist with a CMO appointment. He was not FDA-registered as a software developer. FDA-RSE-2021-GK was not his registration. He had no regulatory submissions ID in the FDA’s database.

The compliance officer had gone to Vance’s office and explained the situation.

Vance had asked: “Can I respond to the audit as the clinical director responsible for the device’s deployment?”

The compliance officer had said: “The FDA audit is specifically about the software design decisions. Those are in the DHF. The DHF is attributed to FDA-RSE-2021-GK.”

He had read the DHF for the first time.

The entries were in a notation he did not recognize — a systematic documentation format with specific codes for each type of design decision, each type of test, each type of traceability record. He had been in the room during the clinical validation review. He had seen the performance numbers. He had not seen the engineering behind the numbers. The engineering was in the DHF. The DHF was fourteen months long.

He thought about “we got there.” He had been in the room. He had attended the presentation. He had seen the 94.7% number on the screen. He had understood “we got there” as accurate because he had defined the clinical requirements and she had implemented them. The implementation was the algorithm. The algorithm was in the DHF. He had not read the DHF. He had read the performance summary.

“We” had not gotten there. She had gotten there. He had been told about it afterward.

He called Grace.

She was at the bench, reviewing the DHF for the audit response, the calibration syringe in the test fixture.

She had been through the DHF three times in two days. She knew every entry. The requirement traceability matrix was complete — every clinical requirement Vance had defined was traced to the specific design decision that addressed it. The 6-lead correlation requirement was traced to the weighted dynamic calibration implementation, with the validation test records showing the sensitivity improvement from 87% to 94.7%.

She had documented the improvement as a design decision in month eleven, when she had determined that the standard 4-lead implementation was insufficient for the clinical goal.

He said: “The FDA audit requires the DHF and a technical response from the registered developer. Your ID is on the file.”

She said: “Yes.”

He said: “I need you to lead the audit response.”

She said: “I’ll prepare the documentation.”

She put the phone down. She kept working. She had the audit response package to build.

She had anticipated the audit documentation requirements before the FDA notice arrived.

Specifically: she had known that if a regulatory action ever required the DHF to be produced and defended, the defense would require the software developer who had made the documented decisions to explain them. The documentation was not self-explanatory to a non-developer. It required interpretation by the person who had made the choices.

This was not a strategic calculation. It was a description of what a Design History File was. The DHF documented the decisions. The developer who had made the decisions could explain them. Someone who had not made the decisions could not explain them — they could read the entries, but they could not answer the follow-up questions about why the design had gone in a particular direction at a particular time.

She had made the decision to redesign the lead configuration in month nine because the clinical validation data from month seven had shown that the 4-lead architecture had a systematic gap in sensitivity for patients with specific cardiac geometries — geometries where the delta wave was primarily visible in leads 5 and 6, which the 4-lead configuration did not include. She had identified the gap by analyzing the false-negative cases from the month-seven validation. Seven patients had WPW that the 4-lead algorithm had not flagged. Six of those seven had cardiac geometries where lead 5 and lead 6 were the primary delta-wave leads.

She had documented this in DHF section 3.7: the false-negative analysis, the cardiac geometry data, the rationale for the lead expansion, the expected sensitivity improvement.

Section 3.7 was 42 pages long.

No one else had written those 42 pages.

She kept reviewing the DHF.

Vance came to the testing lab the morning of the FDA audit session.

He said: “Dr. Kim is the software developer of record. I’ll be present but all software technical questions go to her.” He sat down at the conference table.

FDA Investigator Dr. Sung Park worked through the DHF systematically. He began with the device description, then moved to the software architecture, then to the requirement traceability matrix, then to the verification and validation records.

He addressed every technical question to Grace.

She had the DHF open on her laptop. She answered from the entries, referencing the specific document section and the design rationale she had recorded at the time of each decision. The 6-lead correlation: she had documented the rationale in month three, when she had determined that the single-lead approach was architecturally insufficient for intermittent WPW detection. The dynamic calibration weighting: she had documented the specific weighting algorithm in month seven, with the clinical validation data that justified the weighting parameters. The 87%-to-94.7% sensitivity improvement: she had documented it in month eleven as a design decision — the shift from 4-lead to 6-lead configuration with the updated weighting.

Park asked: “Was the decision to move from 4-lead to 6-lead configuration made before or after the clinical validation data showed the 87% sensitivity?”

She said: “After. The month-seven data showed 87% on the 4-lead configuration. I made the architectural decision in month nine to redesign the lead configuration.”

He said: “Is the redesign documented?”

She said: “Yes. DHF section 4.3, dated month nine. The rationale, the implementation approach, and the clinical justification are all in that section.”

He reviewed section 4.3. He asked three more questions about the weighting algorithm.

She answered each one from the DHF.

At the end of the audit session, Park said: “Dr. Kim, the audit is closed without finding. Your Design History File is thorough and compliant. FDA-RSE-2021-GK will be cited in the audit closure report as the software developer of record. You should expect to receive the closure notice by end of week.”

She received it Thursday.

Mara saw the closure notice on Grace’s screen that afternoon.

She said: “Your ID in the FDA record.”

Grace said: “Yes.”

She said: “14 months in that file.”

Grace said: “Yes.” She picked up the syringe. She ran the next calibration test.

Vance found her after the audit closure. “Good outcome. Your DHF was clean.” She said: “The documentation is complete.” He said: “I’m going to propose a follow-up paper. You as first author.” She said: “Okay.” He said: “Good work, Grace.” She said: “Thank you.”

She set the syringe in the fixture. She ran the test.

The closure report was filed the following week: “Software Developer of Record: Dr. Grace Kim, FDA-RSE-2021-GK.” The NEJM correction was issued: “The cardiac alert algorithm was designed by Dr. Grace Kim, Medical Device Software Engineer, FDA-RSE-2021-GK.” She received the correction proof from Vance. She filed it in the regulatory folder.

The follow-up NEJM letter was submitted three weeks later: Grace Kim as first author, Vance as co-author, describing the algorithm’s clinical impact on WPW detection in the hospital cohort. She wrote the methods section from the DHF. It was the first time the algorithm architecture had appeared in a published document.

The FDA audit closure report was a formal regulatory document.

“Audit Closure: Medical Device Software — Cardiac Monitoring System. Date: [audit date]. Device: Vance Memorial Hospital Cardiac Monitoring System, Model VH-CM-2021. Software Developer of Record: Dr. Grace Kim, FDA-RSE-2021-GK, registered software developer, 21 CFR Part 820 compliance verified. Audit result: CLOSED WITHOUT FINDING. All Design History File documentation is complete and compliant. The responsible developer has demonstrated thorough knowledge of all design decisions documented in the DHF.”

“Demonstrated thorough knowledge.”

She had answered twenty-three questions from Dr. Park over the two-hour audit session. She had referenced the specific DHF section for each answer. She had explained the engineering rationale behind three design decisions that required follow-up technical questions.

The audit closure report was in the FDA’s public regulatory database — a permanent federal record. FDA-RSE-2021-GK and Grace Kim appeared in it eleven times. She had the database entry number saved.

The hospital had received a copy of the closure report. The Board of Trustees had approved a named endowment for “the Vance Detection Protocol” the previous year. She did not know whether the endowment name would be revised. She had not been informed about the endowment. She had heard about it from Mara.

She had not opened the endowment announcement. She had her DHF to maintain.

The NEJM correction was appended to the case report in the journal’s online system that Thursday. She received a notification email. She filed it in the regulatory folder.

She picked up the calibration syringe. She ran the next test. The alert fired. She recorded the result.

She drew the calibration syringe from the fixture and held it the way she always did — thumb on the plunger flange, fingers around the barrel, feeling the slight resistance she had learned years ago. The scratched glass was warm from the lab temperature. The new device was on the bench — a revised hardware revision, same algorithm, different sensor configuration. She positioned the syringe at the injection port and pressed the plunger at the rate that produced the standard Wolff-Parkinson-White waveform. The resistance was exactly what she expected. The waveform appeared on the device display. The alert fired — the weighted multi-lead correlation, the one that caught what other devices missed. The FDA audit closure report was in the regulatory archive: “Software Developer of Record: Dr. Grace Kim, FDA-RSE-2021-GK.” Mara was documenting the calibration log. Grace recorded the result. She moved to the next test.

The new hardware revision had required a recalibration of the lead-weighting parameters — the third recalibration she had done since the original 510(k) clearance. Each recalibration was documented in the DHF, under the same FDA-RSE-2021-GK registration, with the updated validation data. The sensitivity on the new hardware was 95.1%.

She had sent the updated data to Vance that morning.

He had replied: “Excellent. This is the kind of incremental improvement the clinical team needs. Let’s discuss the follow-up study design.”

She had replied: “I’ll have a draft design for your review by Thursday.”

She had the second NEJM paper partially drafted. It was being written differently from the first paper — this one led with the algorithm’s architectural evolution, the progression from 4-lead to 6-lead to the current implementation with the third-generation sensor configuration. The clinical outcomes were the result of that evolution, not the headline.

She was the corresponding author.

The NEJM case report — “Vance Detection Protocol,” sole CMO attribution — had been cited in 14 subsequent cardiology papers. The correction notice was appended to the online version of the original case report. The 14 citing papers referenced the original. They had been published. They would not be corrected. She had the citation count from Google Scholar.

She had stopped checking when it reached 14. She knew the citations existed. She had not opened Google Scholar since.

The follow-up letter — Grace Kim, first author — had been cited in 3 papers in its first month of publication.

She positioned the syringe at the injection port.

The alert fired.

She recorded the result.

The second NEJM paper was submitted at the end of the month.

Grace Kim, corresponding author. Vance was third author, after Mara, who had been the verification witness for 14 months of validation testing. She had asked Vance about the authorship order before submission. He had said: “The right order. You should be corresponding.”

She had submitted it.

The paper led with the algorithm architecture — the first published description of the weighted multi-lead correlation approach, with the mathematical framework of the dynamic calibration. The supplementary material included the full 6-lead weighting algorithm specification. The clinical outcomes section came after the methods.

The paper’s abstract began: “We describe the design and clinical validation of a weighted multi-lead correlation algorithm for intermittent Wolff-Parkinson-White syndrome detection.” The algorithm was the subject. The outcomes were the evidence.

Mara was at the adjacent bench, running the calibration log for the third-generation hardware. The syringe resistance was exactly what Grace expected. The alert fired on each WPW calibration test. 95.1%. The new hardware was performing as designed.

She recorded the result. She moved to the next test. She had a validation protocol to complete before the hardware revision could be submitted for 510(k) clearance.

The clearance would be under FDA-RSE-2021-GK.

The alert fired. She recorded the result.