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
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
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
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
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
Q: would you accept a reporting requirement limiting the
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 10th Circuit said in US v.
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
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
C: do you know what the practice is in terms of what mfgrs
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.
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
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
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

from Blogger

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s