DMCA hearings: medical devices

Copyright Office: Jacqueline Charlesworth

Michelle Choe

Regan Smith

Cy Donnelly

Steve Ruhe

John Riley

John Morris (NTIA)

 

Proposed Class 27: Software – networked medical devices

The proposed class would allow circumvention of TPMs protecting computer programs in medical devices designed for attachment to or implantation in patients and in their corresponding monitoring devices, as well as the outputs generated through those programs. As proposed, the exemption would be limited to cases where circumvention is at the direction of a patient seeking access to information generated by his or her own device, or at the direction of those conducting research into the safety, security, and effectiveness of such devices. The proposal would cover devices such as pacemakers, implantable cardioverter defibrillators, insulin pumps, and continuous glucose monitors.

 

Proponents: Andrew Sellars, Cyberlaw Clinic, Berkman Center for Internet & Society, with

Benjamin West, computer researcher/software engineer

 

Sellars: designed to ensure that ongoing research can continue now that devices, largely at the suggestion of independent researchers, have begun to adopt TPMs.

 

West: Type 1 diabetes; use a variety of medical devices incl. insulin pumps and continuous glucose monitors; they contain a wealth of important info, but that’s delayed or even unavailable to me. So I started investigating how they work. There’s a sensor under my skin for the CGM and a handheld receiving computer that displays current value and trends.  My collaborators and I are likeminded patients or parents of patients who used reverse engineering to analyze data. Vendor’s own software can retrieve up to 3 months; we used hardware and software to create transcripts. Community as a whole obtained valuable info on device that’s not always shown or available to patient. The delta: difference between current and five minutes ago.  We were able to provide that to patients and show it on mobile phones.

 

Q: why is that important/useful to you?

 

A: there is a display w/current number; depending on what that number is, I may need to take action—leave the room, take medicine.  B/c it’s changing all the time, getting a sense of changes is very important. Changing 1 point v. 10 points in five minutes is an important cue for what I need to do; v. “trend” is just up or down, no numerical value. People can now miss less school w/ remote monitoring which required more than the device, it required the mobile display. 

 

You can be ok for the next three hours, but it’s difficult to predict beyond that, so you need action every three hours. Too much insulin could be harmful. Schools aren’t always prepared. The mobile device allows parent to monitor and keep in touch w/people taking care of child.  These are often scenarios where the child might be withheld from school, or walks w/grandparents, or sleepovers. Remote monitoring allows someone to keep track remotely and allow the school or trip.

 

Q: the child has the info too?

 

A: children younger than 14 typically don’t perform the therapy.  They’re usually not monitoring themselves to do it on their own.

 

Q: do they take a phone or device that is the monitor w/them?

 

A: typically: we provide the child a rig, in their bookbag or a belt, and that stays w/them. Someone else then provides the interpretation and tells them what to do and coordinates the care w/someone present. If a child is low during school, parent can call and tell them to pull kid out of gym class to give them sugar if they have too much insulin.

 

Q: specific children who took advantage of this?

 

A: we have a FB group called CHM in the cloud, w/12,000 members. Around 4000 have adopted this kind of system. Very popular.

 

We also want to check the number for being stale or inaccurate; there are a variety of reasons that could happen like a new insertion or dehydration. But device/sensor data is still available. Our research has been able to get the raw data out of the device; otherwise you’d get none at all.  Metadata can be used accurately to estimate glucose. Our research also figured out what could cause inaccurate/false readings, like pressure on the insertion—the raw data can tell you what’s inaccurate or when the device is beginning to fail.

 

Current version is unencrypted, but the next version—already sold overseas and soon to replace our devices in the US—has encryption. I’m asking for this exemption so the work we’ve done to improve quality of life can continue.

 

Q: Is all you’re doing pulling data? Are you changing the software in any way?

 

A: Right now, our design behind all of this is to read only. We are not affecting behavior of device. We’ve gone to great lengths to match exactly what the vendor itself does to monitor the device.

 

Q: so is an exemption necessary if only data is being accessed?

 

Sellars: on many devices on the market, and on more coming out, even accessing data requires circumventing a TPM. Some of these devices have protectable and unprotectable outputs; largely depends on selection of info.  Also, West is one of four types of researchers analyzing source code/outputs. Some is personal safety/monitoring.  Sometimes cardiac event symptoms can be indistinguishable from day to day events like fatigue or dizziness. My device knows but wouldn’t necessarily let me know.

Q: is West’s device about cardiac symptoms? Is the info West is addressing the sort of data that anyone has asserted © of?

 

A: statements of Advamed and manufacturers have asserted rights over SQL databases and the like. Also, some data is batched; which leaves greater room for claims about selection/arrangement. 

 

Q: is there any detail on this?

 

A: Advamed asserts © on West’s device. In many cases it’s not clear whether the data would be protected. Where a court could find a work, the exemption is appropriate.

 

Q: are you accessing data off the sensor only or the vendor’s monitor/data there?

 

West: it’s both. Several projects.

 

C: Are you able to audit your device?  Are you printing out a report?  How are the data presented? [Excellent use of plural!]

 

West: Glanceable data—I have a watch I use.  We also store all the information in a database, owned and controlled by the user.  The device has a database in it already. We’re pulling out the records from that, then duplicating and storing in our own DB.  Our DB is off the shelf open source.

 

Sellars: let’s point out that extracting data is fair use/noninfringing use—copy made to perform extraction in house is fair use.

 

Some of the other uses in the coalition: Radcliffe, researching security of these systems, particularly insulin pumps/continuous glucose monitors. Opponents stipulate his research spurred reform.  Heart monitors that often don’t share data w/patients except for 60-90 days later.  If I told you you shouldn’t eat what you ate for lunch on Feb. 28, you would probably not be able to figure out what went wrong.  Researchers can get info more regularly, often daily, to figure out effects of what you eat and do.  Karen Sandler: research into security at software level.  She published a study, “Killed by Code,” which goes into vulnerabilities and reform.  Something often missed in the discussion of medical device security: while we always look to espionage/hackers for romantic reasons, what Sandler & Moy showed is that what affects patient lives most is bad code, design flaws, power management issues, restart that doesn’t tell anyone and thus doesn’t function right.  Recall history: hundreds of recalls per year for software issues on medical devices, w/deaths attributable in the 100s. While attention has been given to vulnerability intrusion, the more fundamental concern is the devices not working properly. Having more people studying and testing and simulating environments always tends to improve health.

 

We are also in an area of regulatory overlap. FCC, FDA, Homeland Security all have regulatory roles.  As has been said many times by this Office and as a matter of good practice, primary responsibility here should be about noninfringing uses. On the questions of copyright and piracy, the opposition commenters offer next to nothing on whether there’d be piracy. Software can’t replace the need for the device itself—the source code of a pacemaker is not a pacemaker.

C: regulatory compliance isn’t a copyright issue, but isn’t it a bigger concern?  [For the FCC/FDA?]

 

Sellars: While I agree that the opposition said that, they offered no substantiation. Opposition misses that the research is happening now, it’s standard, and the FDA not only tolerates it but promotes it—holds hearings inviting independent researchers to improve their regulations. When a person discovers a vulnerability, there’s a FDA reporting mechanism, and there’s also a reporting mechanism for Homeland Security.  The history of the research completely refutes the suggestions of opponents.

 

Q: would you accept a reporting requirement limiting the exemption?

 

A: Disclosure has been suggested. While I agree that the standard course is vendor-first, there are times when it’s appropriate to go to someone else, to an agency or to the press, for example when a vulnerability isn’t related to something a hacker could use but just a design flaw: tell the world there’s a problem w/the device. We also have a sad tradition of medical companies knowing about problems and not telling the public until after a tragedy.  Cited in the record.  Hardware problem known for 3 years but they didn’t tell people there was a problem until a 21-year-old man died and the NYT uncovered knowledge. Wired stories about Hospira pumps w/known vulnerabilities, not addressed until Wired was ready to publish.  While the medical companies wish to be proactive, they are at times unfortunately reactive. It would be a bad policy, and also raise serious concerns of unconstitutional conditions if a benefit, even a discretionary one, is premised on a speech based restriction—and restricting the audience is a serious content based restriction as 10^th Circuit said in US v. West.

 

Q: will the exemption be able to pull data from devices that could otherwise be subject to test/exclusivity laws that would be submitted to regulatory agencies? Where it’s pending approval?

 

A: experience shows there are postmarket and premarket issues. FDA has a couple of options for a new device, from notification to premarket approval.  Often at funding of mfgrs, and studies show that industry-funded studies have an industry bias. A lot of issues found are on devices already in the market.

 

Q: You are asking for data readouts from actual patients as well as security/vulnerability testing: explanted devices for the latter that wouldn’t be used again?

 

A: that is our proposal, but the two exemptions are linked, as West’s comments noted. When you’re accessing device data from a patients, you often learn how the device functions, for example the CGM error related to pressure. 

 

Q: I see them as distinct but blended requests. Scope in one case is in use by patients, and not in use in another.  Concern over fact that tested devices shouldn’t go back into clinical use.

 

Sellars: my understanding is that tests out of package make device unsterile. 

 

Sherwin Siy, Public Knowledge: Copyrightability—Advamed/opponents have made © claims; our uses would be fair uses/uses of uncopyrightable elements. © works are contained in software and those works will be accessed, if not necessarily copied, through these uses.  Copies may be made in RAM for testing, and modifications might be made in the course of testing.

 

C: what are the other sources of law relying on to access those works or data compilations?

 

Siy: access isn’t itself an infringing use.  Essential step copies would be §117, as would modifications in use.  Even if the software itself isn’t “owned” by the patient, fair use applies incredibly strongly.

 

C: do you know what the practice is in terms of what mfgrs say?

 

Sellars: they own the software ©; we have no evidence suggesting anything other than the patient being the owner of the chattel device. There is no license. That speaks to the lack of an aftermarket as well.  There is no reasonable way to lose ownership of a pacemaker [if a so-called ‘license’ were revoked].

 

Siy: written submission covers issues of reverse engineering. The existing statutory exemptions might apply, but they don’t cover the field.

 

Laura Moy, New America’s Open Technology Institute: Record from multiple parties: vulnerabilities need to be discovered to fix them; there’s no other way to do it. We know there are serious bugs and other vulnerabilities. Code inevitably has bugs; eliminating them before going on the market is almost impossible.  Bugs can lead to death.

 

C: Inappropriate third party access?  If you circumvent can you get into other patients’ records? Is that a real possibility, and how would we address that?

 

A: I’ve seen nothing to suggest that researchers are looking somehow at mfgr’s multiple-patient database records.

Sellars: Best paper on these concerns is Daniel Halperin & Kevin Foo & others addressing pacemaker vulnerabilities. He noted privacy concerns—my understanding was that the data is unidirectional, going to the server. He didn’t uncover any way in which you could use a device to access the servers of Medtronic etc., and oppositions didn’t suggest any way this could happen. Anyway this is regulatory overlap, with CFAA. That’s not a copyright problem.

 

C: Are you saying it’s not possible to access a central server with an individual medical device? Is that a possibility? Could circumvention allow you to do that?

 

A: I haven’t found a situation where that’s possible. Unidirectional.

 

Moy: also the result of my research. Where info is broadcast in the clear, the reason is so the hospital can get it easily. That’s how sensitive patient info goes.

 

Q: could you configure devices to transmit only data transmitted by design?  Could we bar something like battery drainage from triggering transmission of data beyond ways mfgr designed it to transmit?

 

Moy: security research w/individual devices typically done on explanted device, so drainage is not typically a concern. Performing vulnerability research is something that can prevent battery drainage/other vulnerability from exploitation in the future. 

 

C: but there was another claim that pinging a device a lot could drain a battery. [© Office as design engineers.]

 

Sellars: that’s an implant v. attached device issue.  Batteries for outside devices are replaceable. Ways in which getting info can be quite relevant to patient care. Turning to pacemakers, the research to date largely concerns passive interception.  There are devices called interrogators [yikes!] in hospital environments.

 

C: I’m not a medical device researcher, but I don’t feel like that answered my question.  Pacemakers have limited battery life, hard to replace: you circumvent a TPM and you are making your own interrogator much more frequently than contemplated by manufacturer—could drain battery in unexpected way. How would you address that concern?  [Um, not with ©?]

 

Sellars: hard to figure out what the concern is. Repeated/continuous interrogation can drain battery, but these sorts of experiments for better access are often done in collaboration w/a doctor: informed consent and the judgment of the doctor is part of our proposed language.

 

C: but one of the pitches was immediate access to the data? [depends on what it is you want to do!]

 

Sellars: that’s a distinction b/t types of projects.  People concerned about cardiac events/better data access would consult w/doctors.

West: you can’t build an interrogator by accident. 

 

C: You might know that, but a naïve person might not.

 

West: to create that device, they have to build it to drain the battery.

 

C: but the opposition’s concern is that some heart patient might not know about their home interrogator’s negative functions. That person might not realize that reading their data frequently could drain their battery in a dangerous way. We’re not the FDA here, obviously, but we’re trying to understand the parameters of the exemption.

 

West: it seems like informed consent would be important there.

 

C: who would be doing the informing?

 

West: the installer?

 

Sellars: note that there are no TPMs preventing this today, and it is not happening. Instead we see passive interception.  Siy said: the device is often accompanied w/monitor and base station. I’d find the concerns completely unfounded. They’re pretending like this activity isn’t happening yet and TPMs are the only barrier, but there are lots of unencrypted devices now.

 

Q: would it be appropriate to limit exemption to passive monitoring for implanted devices?

 

Siy: No. Oppositions suggest hypothetical drain in certain uses; drawing a bright line rule based upon what’s being transmitted rather than characteristics of battery seems a poor fit. Many of the problems we’re seeking to address come from insufficient information received through existing process dictated by manufacturer.

 

Q: is there are scenario where there is an implanted glucose monitor w/ a ten year battery life expected, but using your technique to gather additional data, it might only have an eight year battery life, requiring extra surgeries?  Could a patient decide the extra information is worth having that more regular surgery? Are there scenarios where the additional information would be a decision the patient would want to make for themselves?

 

West: absolutely conceivable. You could also come up with an auditing technique that would make the device last longer—that’s an equally probable alternative.  Or you could provide much better value.

 

Sellars: Personalizing and customizing care is in accordance w/national policy. Consider patient more as individual—better health outcomes.

 

Moy: Doctors and patients should be able to weigh concerns about device vulnerability in their decisions. They have a right to know, especially for implantation, and disclosure helps informed choice. Info about security research could affect cost/benefit analysis, says one opponent—but that’s precisely as it should be! One of the researchers in this area got into it precisely to engage in her own cost benefit analysis for her medical decision.

 

Other agencies like this: FDA is informed by security research. FDA’s additional security steps respond to important work of independent device researchers.

 

C: record suggested that a lot of devices don’t currently have TPMs, and FDA has stepped up its interest. Can you say how many devices currently have TPMs?

 

Sellars: pp. 6-8, citing vendors themselves. We often have to rely on vendors.  Some appendices disclose others.  FDA issued new guidance for devices in October strongly encouraging encryption.  When the FDA strongly encourages something, that’s de facto law. It’s not conjecture; the FDA now wants it as part of approval.

 

West: Medtronic’s pump is what I use; my next pump will have encryption and I will lose access to the data.

Siy: to the extent the Office is concerned w/overlapping jurisdiction, this research is already happening and TPMs are coming, altering the status quo. What’s changing is that the FDA’s exclusive jurisdiction is now suddenly being shared with the © Office and we just want to maintain the status quo research environment.