Skip to content
bewest edited this page Jul 25, 2012 · 4 revisions

Discussing a variety of ways to get access to medical records,

Discussing immediate access to communication protocols.

This is the wrong avenue to take with the FDA, who I believe wants to help. There are subtle issues where we may be able to collaborate in the future.

Original

Delivered-To: bewest@gmail.com
Received: by 10.112.49.166 with SMTP id v6csp227279lbn;
        Wed, 11 Jul 2012 19:54:02 -0700 (PDT)
Received: by 10.224.213.7 with SMTP id gu7mr991292qab.56.1342061641101;
        Wed, 11 Jul 2012 19:54:01 -0700 (PDT)
Return-Path: <Anthony.Watson@fda.hhs.gov>
Received: from ironport4.fda.gov (fda-ifw-00.fda.gov. [150.148.0.65])
        by mx.google.com with ESMTPS id er6si3800202qab.12.2012.07.11.19.53.59
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 11 Jul 2012 19:54:01 -0700 (PDT)
Received-SPF: neutral (google.com: 150.148.0.65 is neither permitted nor denied by best guess record for domain of Anthony.Watson@fda.hhs.gov) client-ip=150.148.0.65;
Authentication-Results: mx.google.com; spf=neutral (google.com: 150.148.0.65 is neither permitted nor denied by best guess record for domain of Anthony.Watson@fda.hhs.gov) smtp.mail=Anthony.Watson@fda.hhs.gov
X-SBRS: None
X-MID: 48725961
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEAAM8/k8K0CrD/2dsb2JhbABCA7kDghkHAQEDAhogJQkDAQEJAwwCAgIBCA0BAwQBAQEeCQcbBhEUCAEIAQEEDgUIDgMChS5IgW0DF7QrDYlOBIpWZgEZgjOCQWADk2iCA2GEZoUMh32BPAcc
Received: from unknown (HELO FDSWP2195.fda.gov) ([10.208.42.195])
  by ironport4.fda.gov with ESMTP/TLS/AES128-SHA; 11 Jul 2012 22:53:57 -0400
Received: from FDSWV2140.fda.gov ([169.254.2.208]) by FDSWP2195.fda.gov
 ([10.208.42.195]) with mapi; Wed, 11 Jul 2012 22:53:57 -0400
From: "Watson, Anthony" <Anthony.Watson@fda.hhs.gov>
To: 'Benjamin West' <bewest@gmail.com>, "Clayton-Jeter, Helene"
  <Helene.Clayton-Jeter@fda.hhs.gov>
CC: fred trotter <fred.trotter@gmail.com>, Adrian Gropper <agropper@gmail.com>
Date: Wed, 11 Jul 2012 22:53:57 -0400
Subject: RE: FW: insulin pump safety: safety vs intellectual property?
Thread-Topic: FW: insulin pump safety: safety vs intellectual property?
Thread-Index: Ac1fkV6c9voy+yqZSBCN1iUcALWQLwARcZRQ
Message-ID: <9585A295B540774CBC3A8A1CEC4BCD182C58A42390@FDSWV2140.fda.gov>
References: <3417CFB18E6DDD4EB2B64AA258382BA91654CA95B0@FDSWV2150.fda.gov>
 <CAKn9-UwjYAe5MqT1M+X4tFn0Uw=V-OLZ7XWsZALM-1HnPeyX3w@mail.gmail.com>
In-Reply-To: <CAKn9-UwjYAe5MqT1M+X4tFn0Uw=V-OLZ7XWsZALM-1HnPeyX3w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Dear Mr. West,

Please permit me to try to answer some of your questions.  If you still hav=
e further questions, I am happy to talk with you.  As far as accessing data=
 logs, that is an interesting question that has come up in recent standards=
 meetings on infusion pumps.  The focus was more on the types of data that =
should be captured than on who could access the data.  FDA's authority only=
 extends to the review standard known as substantial equivalence, and if th=
e manufacturer consider the data contained within the pump to be proprietar=
y, we cannot compel them to make it available to the public.  However, we c=
an certainly look at that information forensically when we have a valid rea=
son to do so, for example, someone gets injured by  a pump.  Indeed, manufa=
cturers have provided that information to us when available and requested b=
y us.   We actually do not decode it but ask the manufacturers to do that a=
nd provide it to us.  We have other tools to look at the software code but =
not that specific function.  As the standards for these pumps are under con=
sideration again, I would be interested in knowing how you propose to use t=
hat data. Perhaps I can broach the subject at the next meeting to get some =
feedback. The standards are consensus and therefore, not mandated by FDA. T=
hus, they are much more accepted by manufacturers so if that were included =
in a standard, it would be designed into every pump.

Regarding the medical records issue you raise, that is not within our purvi=
ew.  I also want to point out that we have some efforts within the Center t=
o explore more user friendly functions for infusion pumps, such as talking =
pumps.  In addition, as you probably read in the link you provided, human f=
actors is a major focus of our efforts around infusion pumps.   We have alr=
eady seen some potential exciting solutions being proposed.

Please let me know if I can help further.

Anthony D. Watson
Director
Division of Anesthesiology, General Hospital, Infection Control, and Dental=
 Devices
Office of Device Evaluation
Center for Devices and Radiological Health
P: (301) 796-6296

-----Original Message-----
From: Benjamin West [mailto:bewest@gmail.com]
Sent: Wednesday, July 11, 2012 2:17 PM
To: Clayton-Jeter, Helene
Cc: Watson, Anthony; fred trotter; Adrian Gropper
Subject: Re: FW: insulin pump safety: safety vs intellectual property?

Hi Helene,

You are correct, somehow I missed your earlier email.  Thank you for the in=
troduction!

Mr. Watson, I've googled your name to try to find some perspective and foun=
d http://www.fda.gov/NewsEvents/Testimony/ucm253067.htm and http://www.fda.=
gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSu=
pplies/InfusionPumps/ucm206000.htm

I'm a big fan of the work you've both done researching pump use, where can =
I find more detailed discussion?  There are some flaws such as hardcoding i=
nsulin lifetime that have been fixed by vendors, but there are undoubtably =
other issues that I can help ameliorate if I had access to my data and to t=
he remote control protocol, and without modifying the pump.

For one thing, just being able to audit logs of pump behavior independently=
 would make it easier to assess whether or not I've received the correct am=
ount of insulin, consequently making it easier for me to intervene correctl=
y, and for me to discuss progress with my doctor.  There are no changes nee=
ded to any production pumps needed to make this happen, I just need a short=
 technical document describing the remote communication protocol currently =
in use.  I can already download my data using my own open source library, b=
ut I cannot decode it in order to parse out the historical details, such as=
 how much insulin was given and stored test results, without knowledge of h=
ow Medtronic has encoded that data.  I, perhaps erroneously, believe the FD=
A knows how to decode this data?

Is there any way the FDA can help me get a faithful copy of my medical reco=
rds, or is this part of OCR?  From what I understand, part of the regulator=
y process involves the FDA reviewing the documentation I need.  Does the FD=
A also submit subpoenas to get access to medical data, or is this only hand=
led by courts?  I'm very interested in learning more about crafting open st=
andards for manufacturers to help validate safety, but my immediate concern=
 is for obtaining my own medical records.

I apologize if my earlier messages were overly ardent.  I'm available to ch=
at on an informal basis: I would love to better understand the FDA's perspe=
ctive and abilities in order to better suggest productive solutions.

-bewest
Ben West

Exchange

MIME-Version: 1.0
Received: by 10.180.24.135 with HTTP; Thu, 12 Jul 2012 12:38:15 -0700 (PDT)
In-Reply-To: <9585A295B540774CBC3A8A1CEC4BCD182C58A42390@FDSWV2140.fda.gov>
References: <3417CFB18E6DDD4EB2B64AA258382BA91654CA95B0@FDSWV2150.fda.gov>
  <CAKn9-UwjYAe5MqT1M+X4tFn0Uw=V-OLZ7XWsZALM-1HnPeyX3w@mail.gmail.com>
  <9585A295B540774CBC3A8A1CEC4BCD182C58A42390@FDSWV2140.fda.gov>
Date: Thu, 12 Jul 2012 12:38:15 -0700
Delivered-To: bewest@gmail.com
Message-ID: <CAKn9-UzNi7y_G+OC3u4d==ETjJKO2_w-H-j+tDcGQ--oMEtAXw@mail.gmail.com>
Subject: Re: FW: insulin pump safety: safety vs intellectual property?
From: Benjamin West <bewest@gmail.com>
To: "Watson, Anthony" <Anthony.Watson@fda.hhs.gov>
Cc: "Clayton-Jeter, Helene" <Helene.Clayton-Jeter@fda.hhs.gov>, fred trotter <fred.trotter@gmail.com>, 
  Adrian Gropper <agropper@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Howdy Mr. Watson,

> Dear Mr. West,
>
> Please permit me to try to answer some of your questions.  If you still h=
ave
> further questions, I am happy to talk with you.

Thanks for your response!
On Wed, Jul 11, 2012 at 7:53 PM, Watson, Anthony
<Anthony.Watson@fda.hhs.gov> wrote:

I would love to know more about the standard process you
are undergoing.  Who are the participants, are there
technical reports or similar deliverables?  How will the
technology discussed be licensed?  How will it affect
labelling?  I'm familiar with consensus based standard
processes.  The W3 and WHATWG are currently using this to
develop several technologies for the web.  The technology
they develop is protected and patent-free so that anyone
is free to bring it to market.  The standards process
itself is also open to the public.  What kind of policies
is your working group using?  Is there a schedule of
deliverables?  I'd love to read more about this.

> As far as accessing data logs, that is an interesting
> question that has come up in recent standards meetings
> on infusion pumps.  The focus was more on the types of
> data that should be captured than on who could access
> the data.
The world is big enough that some users of any technology
will also have the skills to improve it and make it safer.
I understand that the technology seems daunting to the
uninitiated, however, I've seen videos of 13 year olds
implementing similar solutions to what I'm advocating with
parts available on amazon.com.

The pump keeps a log of its behavior including how much
insulin was given, the inputs used for various algorithms,
the pumping schedule and lots of other details fundamental
to my ongoing therapy.  I need to be able to independently
audit these medical records to the best of my ability.  I
write programs that do all kinds of things all the time.
I write programs like a musician plays music and like a
painter paints.  Would you ask a musician what song he
would sing as a precondition for handing him his
instrument?
In the world I live in this is child's play.  I know teams
of mathematicians who would love to try out their machine
learning algorithms to simulate and observe metabolic
processes, and I can potentially provide them with a
framework to simulate thousands if not millions of
participants.  Helene's report struck a deep chord with
me, I've personally experienced many of the issues she
wrote about, and I believe I can prevent them with access
to the communication protocol.

But for now I'm after modest goals: is this thing even
working?  So, I think a way to bring it up with vendors
would be to call it "independent access to pump
primitives" so that I can control and monitor it when and
however is most convenient for me.  This means that
because I happen to be an engineer and a patient, I can
write a program to download my logs directly from my
device.  My perspective is that all devices need to
support this "feature."  They already are capable of this,
but the data is secret, which is why I chose the original
subject of my email.  In fact, most manufacturers of
glucometers publish their protocols so that anyone can get
their data.  There is only benefit to be had for the
vendors that do this, so it is exceedingly puzzling to see
pump manufacturers refuse.

I would love to engage with you on emerging standards and
better understand the process and provide you with useful
input.  I think Adrian Gropper has some additional questions to
help me shape the discussion here.  I'm curious if
"independent access to pump primitives" is a concept that
makes sense?

> FDA's authority only extends to the review standard
> known as substantial equivalence, and if the
> manufacturer consider the data contained within the pump
> to be proprietary, we cannot compel them to make it
> available to the public.  However, we can certainly look
> at that information forensically when we have a valid
> reason to do so, for example, someone gets injured by  a
> pump.

This is the part that has confused me in the past I think.
It sounds like I have at least two concerns.  My primary
concern is my ability to independently audit my own
medical records.  I can't always rely on a third party to
get access to data from something in my body.  I don't
understand why a vendor argument for proprietary data is
relevant when it comes to inspecting my medical device for
my records.  I'm googling "substantial equivalence" and
reading up now.

The interventions I've been instructed to participate in
are of a manual nature and highly error-prone, making
adverse events a constant threat to my safety.
I'm certain that analysis of the data will show dangerous
situations caused by suggestions from the therapeutic
software (I *often* need to adjust this), basal rates, and
mysterious over, or under deliveries of insulin in any
given 12 hour window.  Mostly I've learned enough of the
folk lore to learn how to avoid adverse events by a 4 hour
window, but because this requires constant monitoring and
ongoing action, and it is quite easy to make mistakes.  I
end up living life according to the demands of my pump
instead of being able to control my pump to the best of my
ability.  Does this make sense?

> Indeed, manufacturers have provided that information to
> us when available and requested by us.   We actually do
> not decode it but ask the manufacturers to do that and
> provide it to us.  We have other tools to look at the
> software code but not that specific function.
I see, I think I understand.  The approval process hasn't
included a step where you independently review the
technology or inspect the behavior of the pump?  Eg, the
FDA doesn't have a process to observe and verify that the
technology is working?  I'm still a bit confused.  If the
FDA looked at the code, the code should contain
instructions on how to read and write data.  This
knowledge can be extracted re-used by other programs like
mine to audit my medical records.

If it would help you can use me to request access to
technical details from my vendor.  Please understand that
these influences make this a pressing health issue for me.
I believe I can solve many of these safety issues with the
help of the open source community.  I'm sure that my own
logs contain plentiful and ongoing evidence of a variety
of adverse events.   I could download a bunch of arbitrary
data and hand it to you, and then you could ask Medtronic
for documentation to the algorithm to decode the data so
that we can inspect it properly.  Just being able to audit
my logs independently would allow me to answer the basic
question: "how do I know this thing is working?" If I also
had access to the therapeutic commands in the
communication protocol I could also create highly peer
reviewed programs to intervene on user demand to work
around a variety of flaws in the pump design and
ameliorate "user error." However, it sounds like in order
to make progress on this front I will need to contact the
OCR.  Is this correct?

> As the standards for these pumps are under consideration
> again, I would be interested in knowing how you propose
> to use that data. Perhaps I can broach the subject at
> the next meeting to get some feedback. The standards are
> consensus and therefore, not mandated by FDA. Thus, they
> are much more accepted by manufacturers so if that were
> included in a standard, it would be designed into every
> pump.
I'd be happy to brainstorm ideas with you, but there are a
couple of first principles we need to consider.
1.) A top down design process where the makers of
    technology do not experience the same kind of use as most
    users will always leave users with needs unmet.
2.) The only way to ensure a safe and effective design is
    by allowing users of a technology to review and modify
    it empirically.  This solves a slew of epistemic
    problems that affect safety, and helps ensure a
    scientific approach.

I have a dozen years of professional software development
experience creating real-time management dashboards that
can be used to contrast expected results with past
observations, a core tenant of the scientific method.
I also am developing MIT and Apache licensed technology,
similar to the fitbit, to allow zero-touch upload of data
to a variety of sources, which include MAUDE, and other
FDA systems.  For now you can think of a system like
fitbit mashed up with 3G cell technology, mashed up with
websites like http://glucosurfer.com/ and
http://meraki.com/.  From there, I can offload more work
to the mathematicians and data-miners eager to try out
their theories.  When you ask me to demonstrate what is
possible, you ask me to demonstrate something I'm actively
prevented from doing, making this conversation much more
difficult for me.

So to translate this into requirements, I would suggest
that the pumps need to keep detailed logs of their ongoing
operation, and need to allow *independent access* to those
logs.  For other features, like the remote control
clicker, those details need to be made available as well
so that I and the open source community can best consider
how to use them safely.  This is not really a technical
issue since pumps already do these things.

>
> Regarding the medical records issue you raise, that is
> not within our purview.  I also want to point out that
> we have some efforts within the Center to explore more
> user friendly functions for infusion pumps, such as
> talking pumps.  In addition, as you probably read in the
> link you provided, human factors is a major focus of our
> efforts around infusion pumps.   We have already seen
> some potential exciting solutions being proposed.

> Please let me know if I can help further.
> Anthony D. Watson

Thanks again for your very helpful response.  I've tried
to impart a little more perspective from my end.  It's
important to note that I'm not asking for new features, I
simply need access to the data that already exists and
contains evidence of harm I've received and *continue to
receive without constant error-prone vigilance*.  I'm
interested in how I can better understand your process and
provide useful feedback.  Hopefully Adrian Gropper will
have some useful talking points.  I will try bringing up
my access to my own medical records with the OCR.  Can you
perhaps provide me with another introduction?  What would
be the best way to approach them?

Thanks very much!  I look forward to further discussions!

-bewest
Ben West

P.S. BTW, I'm available to talk on an
     informal basis as well, just to gather perspective, if
     that would be helpful.

Final

Delivered-To: bewest@gmail.com
Received: by 10.180.24.135 with SMTP id u7csp253431wif;
        Tue, 24 Jul 2012 12:45:52 -0700 (PDT)
Received: by 10.229.135.70 with SMTP id m6mr9736359qct.104.1343159151533;
        Tue, 24 Jul 2012 12:45:51 -0700 (PDT)
Return-Path: <Helene.Clayton-Jeter@fda.hhs.gov>
Received: from ironport5.fda.gov (fda-ifw-00.fda.gov. [150.148.0.65])
        by mx.google.com with ESMTPS id k5si5251896qct.136.2012.07.24.12.45.50
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 24 Jul 2012 12:45:51 -0700 (PDT)
Received-SPF: neutral (google.com: 150.148.0.65 is neither permitted nor denied by best guess record for domain of Helene.Clayton-Jeter@fda.hhs.gov) client-ip=150.148.0.65;
Authentication-Results: mx.google.com; spf=neutral (google.com: 150.148.0.65 is neither permitted nor denied by best guess record for domain of Helene.Clayton-Jeter@fda.hhs.gov) smtp.mail=Helene.Clayton-Jeter@fda.hhs.gov
X-SBRS: None
X-MID: 278845444
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApgGAGn6DlAK0CrC/2dsb2JhbABFgkqmFwGQEoIQgictIBIMDhINCmoZBgICAwEEDg2GCb0kkV9gA6hRgUM
Received: from fdswp2194.fda.gov ([10.208.42.194])
  by ironport5.fda.gov with ESMTP/TLS/AES128-SHA; 24 Jul 2012 15:45:50 -0400
Received: from FDSWV2150.fda.gov ([169.254.2.227]) by FDSWP2194.fda.gov
 ([10.208.42.194]) with mapi; Tue, 24 Jul 2012 15:45:49 -0400
From: "Clayton-Jeter, Helene" <Helene.Clayton-Jeter@fda.hhs.gov>
To: 'Benjamin West' <bewest@gmail.com>
CC: "Chapman, Richard" <Richard.Chapman@fda.hhs.gov>, "fred.trotter@gmail.com"
  <fred.trotter@gmail.com>, "Watson, Anthony" <Anthony.Watson@fda.hhs.gov>
Date: Tue, 24 Jul 2012 15:45:48 -0400
Subject:
Thread-Index: Ac1p1Oyzq4hvVsqoSUCPVqm0qSvCaQ==
Message-ID: <3417CFB18E6DDD4EB2B64AA258382BA916560C4D2F@FDSWV2150.fda.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative;
  boundary="_000_3417CFB18E6DDD4EB2B64AA258382BA916560C4D2FFDSWV2150fdag_"
MIME-Version: 1.0

--_000_3417CFB18E6DDD4EB2B64AA258382BA916560C4D2FFDSWV2150fdag_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ben et al,

Your queries have been vetted through subject matter experts in the Center =
for Devices and Radiological Health, in addition to Mr. Watson. It has been=
 determined that your request for information may be best fulfilled through=
 CMS (Centers for Medicaid and Medicare Services) , ONC (Health and Human S=
ervices Office of the National Coordinator for Health Information Technolog=
y) and OS (Health and Human Services Office of the Secretary) who handles d=
ata issues relative to access, security and privacy, for FDA does not regul=
ate patient access to medical records.  However, when the time arises your =
inquiry may allow the FDA to express its opinion about the importance of pa=
tient-centric care, which begins with patients having access to information=
 about themselves. Even though we are not the driver for the specific area =
of patient data access, we can take advantage of the opportunity your inqui=
ry has presented us to have the discussion with our HHS counterparts.

At this time we will not schedule a face-to-face meeting but are open for d=
iscussions on topics within our purview.

Thank you for contacting OSHI (Office of Special Health Issues) and feel fr=
ee to contact me if you desire anything further.

Best regards,


Helene




--_000_3417CFB18E6DDD4EB2B64AA258382BA916560C4D2FFDSWV2150fdag_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Times New Roman, serif" size=3D"3">
<div style=3D"margin-top: 5pt; margin-bottom: 5pt; ">Ben et al,<br>

<br>

Your queries have been vetted through subject matter experts in the Center =
for Devices and Radiological Health, in addition to Mr. Watson. It has been=
 determined that your request for information may be best fulfilled through=
 CMS (Centers for Medicaid and Medicare
Services) , ONC (Health and Human Services Office of the National Coordinat=
or for Health Information Technology) and OS (Health and Human Services Off=
ice of the Secretary) who handles data issues relative to access, security =
and privacy, for FDA does not regulate
patient access to medical records.&nbsp; However, when the time arises your=
 inquiry may allow the FDA to express its opinion about the importance of p=
atient-centric care, which begins with patients having access to informatio=
n about themselves. Even though we are
not the driver for the specific area of patient data access, we can take ad=
vantage of the opportunity your inquiry has presented us to have the discus=
sion with our HHS counterparts.<br>

<br>

At this time we will not schedule a face-to-face meeting but are open for d=
iscussions on topics within our purview.<br>

<br>

Thank you for contacting OSHI (Office of Special Health Issues) and feel fr=
ee to contact me if you desire anything further.<br>

<br>

Best regards,<br>

</div>
<div style=3D"margin-top: 5pt; margin-bottom: 5pt; "><br>

Helene<br>

</div>
<div>&nbsp;</div>
<div><font face=3D"Arial, sans-serif" size=3D"2">&nbsp;</font></div>
</font>
</body>
</html>

--_000_3417CFB18E6DDD4EB2B64AA258382BA916560C4D2FFDSWV2150fdag_--