Bionic M2M: Are Skin-mounted M2M devices – the future of clinical trials?

There is a lot of hype about wearables.   One of the best ways to correlate patient compliance with patient biometrics is for the patient to wear the sensor on her skin.

I started thinking about skin-mounted devices again after reading the press release about the BioSerenity Series B, so I dug up an essay I wrote 7 years ago on my security blog Cybersecurity for biomed.

BioSerenity, developer of solutions dedicated to personalized patient continuous care, raised €65 million, yesterday including €50 million in Series B equity financing led by Dassault Systèmes (who acquired Medidata for $5.8BN last week). Bioserenity makes textiles equipped with sensors for ECG and EEG.

What would happen if the personal appliance was part of the person?

In the popular American TV series that aired on ABC in the 70s, Steve Austin is the “Six million Dollar Man”, a former astronaut with bionic implants. The show and its spinoff, The Bionic Woman (Lindsay Wagner playing a former tennis player who was rebuilt with bionic parts similar to Austin after a parachuting accident) were hugely successful.

Modern M2M communication has expanded beyond a one-to-one connection and changed into a system of networks that transmits data to personal appliances using wireless data networks.

M2M networks are much much more than remote meter reading.

The fastest growing M2M segment in Germany, with an average annual growth of 47 percent, will be from consumer electronics with over 5 M2M SIM-cards. The main growth driver is “tracking and tracing”. (Research by E-Plus )

The evolution of epidermal electronics as a flexible tattoo-like place-on-the-skin device

Physiological measurement and stimulation techniques that exploit interfaces to the skin have been of interest for over 80 years, beginning in 1929 with electroencephalography from the scalp.

A new class of electronics based on transparent, flexible 50micron silicon film laminates onto the skin with conformal contact and adhesion based on van der Waals interaction. See: Epidermal Electronics John Rogers et al. Science 2011.

This new class of device is mechanically invisible to the user, is accurate compared to traditional electrodes and has RF connectivity.  The thin 50 micron film serve as temporary support for manual mounting of these systems on the skin in an overall construct that is directly analogous to that of a temporary transfer tattoo, as can be seen in the above picture.

Film mounted devices can provide high-quality signals with information on all phases of the heartbeat, EMG (muscle activity) and EEG (brain activity). Using silicon RF diodes, devices can provide short-range RF transmission at 2Ghz.  Note the antenna on the device.

After mounting it onto the skin, one can wash away the PVA and peel the device back with a pair of tweezers.  When completely removed, the system collapses on itself because of its extreme deformability and skin-like physical properties.

Due to their inherent transparent, unguarded, low cost and mass-deployed nature, epidermal mounted medical devices invite new threats that are not mitigated by current security and wireless technologies.

Skin-mounted devices might also become attack vectors themselves, allowing a malicious attacker to apply a device to the spine, and deliver low-power stimuli to the spinal cord.

How do we secure epidermal electronics devices on people?

Let’s start with some definitions:

-Verification means is the device built/configured for its intended use (for example measuring EMG activity and communicating the data to NFC (near field communications) device.

-Validation means the ability to assess the security state of the device, whether or not it has been compromised.

-RIMs (Reference Integrity Measurements) enable vendors/healthcare providers define the desired target configurations of devices, for example, is it configured for RF communications

There are 3 key threats when it comes to epidermal electronics:

1.Physical attacks: Reflashing before application to the skin in order to modify  intended use.

2.Compromise of credentials: brute force attacks as well as malicious cloning of credentials.

3.Protocol attacks against the device: MITM on first network access, DoS, remote reprogramming

What are the security countermeasures against these threats?  We can consider a traditional IT security model and a trusted computing model.

Traditional IT security model?

Very large numbers of low-cost, distributed devices renders an  access-control security model inappropriate. How would a firewall on an epidermal electronics device enforce intended use, and manage access-control policies? What kind of policies would you want to manage? How would you enforce installation of the internal firewall during the manufacturing process?

Trusted computing model?

A “trusted computing model”  may be considered as an alternative security countermeasure to access control and policy management.

An entity can be “trusted” if it predictably and observably behaves in the expected manner for its intended use. But what does “intended use” mean in the case of epidermal electronics that are used for EKG, EEG and EMG measurements on people?

Can the traditional, layered, trusted computing models used in the telecommunications world be used to effectively secure cheap, low-cost, epidermal electronics devices?

In an M2M trusted computing model there are 3 methods:  autonomous validation, remote validation and semi-autonomous validation. We will examine each and try and determine how effective each model is as a security countermeasure for the key threats of epidermal electronics.See: “Security and Trust for M2M Communications” – Inhyok Cha, Yogendra Shah, Andreas U. Schmidt, Andreas Leicher, Mike Meyerstein

Autonomous validation

This is essentially the trust model used for smart cards, where the result of local verification is true or false.

Autonomous validation does not depend on the patient herself or the healthcare provider. Local verification is assumed to have occurred before the skin-mounted device attempts communication or performs a measurement operation.

Autonomous validation makes 3 fundamental assumptions – all 3 are wrong in the case of epidermal electronics:

1.The local verification process is assumed to be perfectly secure since the results are not shared with anyone else, neither the patient nor the healthcare provider.

2.We assume that the device itself is completely trusted in order to enforce security policies.

3.We assume that a device failing self-verification cannot deviate from its “intended use”.

Device-based security can be broken and cheap autonomous skin-mounted devices can be manipulated – probably much easier than cell-phones since for now at least, they are much simpler. Wait until 2015 when we have dual core processors on a film.

In addition, autonomous validation does not mitigate partial compromise attacks (for example – the device continues to measure EMG activity but also delivers mild shocks to the spine).

Remote validation

Remote validation has connectivity, scalability and availability issues. It is a probably a very bad idea to rely on network availability in order to remotely validate a skin-mounted epidermal electronics device.

In addition to the network and server infrastructure required to support remote validation, there would also be a huge database of RIMs, to enable vendors and healthcare providers define the target configurations of devices.

Run-time verification is meaningless if it is not directly followed by validation, which requires frequent handshaking with central service providers, which in turn increases traffic and creates additional vulnerabilities, such as side-channel attacks.

Remote validation of personally-mounted devices compromises privacy since the configuration may be virtually unique for a particular person and interception of validation messages could reveal the identity based on location even without deccrypting payloads.

Discrimination by vendors also becomes possible, as manipulation and control of the RIM databases could lock out other applications/vendors.

Semi-Autonomous Validation

Semi-autonomous validation divides verification and enforcement between the device and the healthcare provider.

In semi-autonomous validation, the device verifies itself locally and then sends the results in a network message to the healthcare provider who can decide if he needs to notify the user/patient if the device has been compromised or does not match the intended use.

Such a system needs to ensure authentication, integrity, and confidentiality of messages sent from epidermal electronics devices to the healthcare provider.

RIM certificates are a key part of semi-autonomous validation and would be signed by a trusted third party/CA.

Semi-autonomous validation also allows for more granular delegation of control to the device itself or the healthcare provider – depending on the functionality.

Summary

Epidermal electronics devices are probably going to play a big part in the future of healthcare for monitoring vital signs in a simple, cheap and non-invasive way.  These are medical devices, used today primarily for measuring vital signs that are directly mounted on the skin and not a Windows PC or Android smart phone that can be rebooted if there is a problem.

As their computing capabilities develop, current trusted computing/security models will be inadequate for epidermal electronics devices and attention needs to be devoted as soon as possible in order to build a security (probably semi-autonomous) model that will mitigate threats by malicious attackers.

 References

1.Security and Trust for M2M Communications – Inhyok Cha, Yogendra Shah, Andreas U. Schmidt, Andreas Leicher, Mike Meyerstein

2.Epidermal Electronics John Rogers et al. Science 2011.

About flaskdata.io

We specialise in shortening time to submission for connected devices.  Our secure fast signal acquisition and automated detection and response platform can save you 6-12 months in your clinical march to market.

 

100X faster to deviation detection in medical device studies.

Automated Patient compliance deviation detection and response on the flaskdata.io platform for a connected medical device clinical trial is 100X faster than manual monitoring. Automated compliance monitoring analytics and real-time alerts let you focus your site monitoring visits on work with the PI and site coordinators to take total ownership and have the right training and tools to meet their patient recruitment and patient compliance goals.

The gap between the proletariat and Medidata (or should I say Dassault)

We need a better UX before [TLA] integration

The sheer number and variety of eClinical software companies and buzzwords confuses me.
There is EDC, CTMS, IWRS, IVRS, IWRS, IRT, eSource, eCOA, ePRO and a bunch of more TLAs.
For the life of me I do not understand the difference between eCOA and ePRO and why we need 2 buzzwords for patient reporting.

Here is marketing collateral from a CRO.   As you will see – they miss the boat on all the things that are important for site coordinators and study monitors.

We adapt responsively to change in your clinical trial to minimize risk and drive quality outcomes. Clinical research is complicated and it’s easy to get off track due to inexperienced project leaders, inflexible workflows, or the failure to identify risks before they become issues. We derive expert insights from evidence-based processes and strategic services to be the driving force behind quality outcomes, including optimized data, patient safety, reduced time-to-market, and operational savings.

What CRCs and CRAs have to say about the leading eClinical solutions

I recently did an informal poll on Facebook of what problems the CRA/CRC proletariat have to deal with on the job.

I want to thank Tsvetina Dencheva for helping me grok and distill people’s complaints
into 3 central themes.

Theme no. 1 – enter data once

Enable administrators to enter data once and have their authorized user lists, sites and metrics update automatically without all kinds of double and triple work and fancy import/export footwork between different systems. Failing a way of managing things in one place –
at least have better integration between the EDC and the CTMS.

The IT guys euphemistically call this problem information silos. I’ve always thought that they used the word silos (which are used to store animal food) as way of identifying with people who farm, without actually having to get their hands dirty by shovelling silage (which is really smelly btw).

I understand the rationale for having a CTMS and an EDC about as much as I understand the difference between eCOA and ePRO.

Here is some raw data from the informal Facebook survey

If I enter specific data, it would be great if there’s an integrated route to all fields connected to the said data. An easy example is – if I enter a visit, it transfers to my time sheet.

Same goes to contact reports. Apps! All sorts of apps, ctms, verified calculators, edc, ixrs, Electronic TMF. The list goes on and on. How could I forget electronic training logs? Electronic all sorts of log.

There are a lot of things we do day to day that are repetitive and can take away from actually moving studies forward. Thinking things like scanning reg docs, auto capturing of reg doc attributes (to a point), and integration to the TMF. Or better system integration, meaning where we enter a single data point (ie CTMS) and flowing to other systems (ie new site in CTMS, create new site in TMF. Enrolment metrics from EDC to CTMS) and so on.

If only the f**ing CTMS would work properly.

Theme number 2 – single sign-on.

The level of frustration with having to login to different systems is very high. The ultimate solution is to use social login – just login to the different systems with your Google Account and let Google/Firebase authenticate your identity.

Theme number 3 – data integrity

EDC edit check development eats up a lot of time and when poorly designed generates thousands of queries. Not good.

There is a vision of an EDC that understands the data semantics from context of the study protocol.

This is a very cool and advanced notion.

One of the study monitors put it like this:

The EDC should be smart enough to identify nonsense without having to develop a bunch of edit checks each time and have to deal with queries.

The EDC should be able to calculate if a visit is in a proper time window, or if imaging is in a proper time window. Also for oncology if RECIST 1.1 is used, then the EDC should be able to calculate: Body Surface Area, correct dosing based on weight and height of a patient, RECIST 1.1 tumor response and many other things that simply can be calculated.

About flaskdata.io

We specialise in faster submission for connected medical devices. We can shorten your
time to market by 9-12 months with automated patient compliance detection and response.

Call us and we’ll show you how. No buzzwords required.

The advantage of speaking softly

Bad feelings and lack of collaboration are a net loss for the clinical team

I started thinking about the constraints on our technology for automating patient compliance detection and response in connected medical device clinical trials.

The best technology for patient compliance automation will not help you get to FDA submission faster if the clinical operations team is dysfunctional.

Our great real-time patient compliance analytics can help a CRA whip through a site audit fast.

When the other CRA on the team is busy bad-mouthing team members and doing one-up stunts, the speed does not matter even if you suck it up and move on.  The bad feelings and lack of collaboration are a net loss.

The advantage of speaking softly

As many of you may know, I am a serious amateur musician. I play saxophones, clarinet and EWI in the JP Big Band.   (The band is appearing this Friday June 21, 2019 at 13:00 at JEMS Modiin – check out the event on Facebook over here).

Experienced wind instrument musicians know that when you play pianissimo, you can play faster. When you play softly, your intonation is better.   If you play softly with good intonation, then you can hear the other musicians in the ensemble.   When you hear the other musicians in the ensemble, then you can play better as a group.   An ensemble that plays softly with good intonation sounds better.   It sounds ‘tight’.     Playing softly with good intonation together as an ensemble, enables a wider dynamic range.   Wider dynamic range means that the entire group can be really pianissimo or totally forte-fortissimo.

The downside of being loud

On the other hand, if you play loud, you do not hear the other musicians.   Playing loud creates stress on your body and brain.  The stress wears you out and causes more stress because you are never sure you will hit that note or make that phrase.   The physical and mental stress caused by playing loud influences everyone around you, not just your own mind and body.

Let’s apply the idea of playing softly to collaborating with other people.

When you speak softly, people listen better.   You can deliver your message more effectively when people listen to you without feeling threatened.    If you speak softly with clear messages, you can hear the other people in your group.     A group that speaks softly sounds better.  It sounds ‘tight’.   A group that speaks softly can achieve a wider dynamic range of response because the group is not challenged by listening issues.

A wider dynamic range enables a group to respond faster and more effectively to problems and changes, because people are all talking at the same time in a cacophony of sound.

The downside of being loud at work

On the other hand, if you talk loud, you do not hear other people.  You only hear yourself.  Talking loud creates stress on your body and brain.  The stress wears you out and causes more stress because you are never sure you explained yourself properly   The physical and mental stress caused by speaking loud influences everyone around you, not just your own mind and body.

Cascade effects of speaking softly at work

Speaking softly goes beyond stress reduction and improved communications.       It enables you to build a much stronger core for the entire business / operation. Speaking softly has additional benefits:

– Makes it easier to confirm facts instead of based on authority and loudness.
– Makes it much easier to debate evidence
– When everyone speaks softly no one is an absolute authority on anything. The boss and the newest sales person on the team have equal input.
– Speaking softly enables the team to generate multiple hypotheses
– You don’t get too attached to an idea and start yelling about how good it is because it is, after all, your idea.

Obsessed with patient compliance

Obsessed with patient compliance

I’m watching a series of short videos done by Techstars founder Brad Feld.

Brad talks about founders needing to be obsessive.

I am totally obsessed with patient compliance.

The key to speed in medical device trials is eliminating non-value-added activities and automating everything else.

There are a lot of smart people working on RWD and RWE and mobile, AI and machine learning.

We are working on automating patient compliance detection and response because we are obsessed with making site coordinators more productive.

We correlate 3 streams of data: patient, device and site coordinator and automated detection and response of patient compliance deviations and then apply some decision trees.

In order to catch high-priority events (like over or under-dosing), the study team can subscribe to real-time alerts.

The patients can be subscribed to adaptive reinforcement messages.

The site coordinator, study monitors and project manger get real-time analytics showing trends of patient compliance sliced and diced by patient, site, cohort, date, time…

So far – the results with customers have been encouraging – with our early adopters achieving 85-95% patient compliance in global multi-centre studies.

Check out my colleague Tigran’s post on the absurd idea of using edit checks to assure patient compliance.

Living in an ideal world where the study nurse isn’t overwhelmed by IT

Tigran examines the idea of using EDC edit checks to assure patient compliance to the protocol.

How should I assure patient compliance to the protocol in a medical device trial?

I get asked sometimes whether automated patient compliance deviation detection and response  is not overkill.

After all, all EDC systems allow comparing input to preset ranges and data types (edit checks). Why not use this, already available off the shelf functionality, to catch non-compliance? As Phileas Fogg put it: “Learn to use what you have got, and you won’t need what you have not”.

Why edit checks are not enough

There are 4 issues with using EDC edit checks to enforce patient compliance:

Individual variations

The original purpose of edit checks is to catch data entry mistakes. As they are generated automatically, they need to be robust enough not to fire indiscriminately. The effect non-compliance has on clinical data can be far less clearcut. This is especially true when taking individual variation between patients into account.

Timing

Even if we were able to reliably catch non-compliance through clinical data alone, there’s the issue of timing.

Each hour of delay between non-compliance event and a prompt to return to compliance devalues the prompt. Delays could come from a) manually entering source data into EDC, b) edit check firing in batch mode rather than during data entry, c) the time needed to process the edit checks.  What’s the benefit of being told you were not compliant one week ago?

Talk of closing the stable door after the horse has bolted…

By the time the nurse contacts the patient, the damage has already been done. No reinforcement is possible, as a patient could (theoretically) be reminded about the need to be compliant with the interval of several weeks – in which case this will serve as a token reminder, nothing more.

The study nurse may not have spare time on her hands

Let’s assume we live in an ideal world, where the study nurse isn’t overwhelmed by thousands of edit checks firing for no reason, and where data flows into EDC with no delay.

Even if this is true, there’s still the small matter of actually reaching out to the patient. When compliance reaches 90% that’s considered a good result – so in the best case scenario, the nurse would need to reach out to patients in 10% of cases. Edit checks are meant to be resolved immediately. If the EDC used fires edit checks during data entry, then the data entry process will be paralyzed. If edit checks are fired in the background, then the whole data cleaning/query resolution process would stall.

Edit checks are not an operational tool

What would happen in reality, though, is that any edit checks introduced to monitor patient compliance would be overridden by site staff. Together with any legitimate edit checks designed to keep the errors out. Resulting in the same level of compliance and much dirtier database. And that’s best case scenario, if otherwise no data would be entered at all.

Tigran Arzumanov is an experienced business development/sales consultant running BD as a service, a Contract Sales Organization for Healthcare IT and Clinical development.

How to annoy your eClinical platform vendor

Every question is a cry to understand the world. There is no such thing as a dumb question.   Carl Sagan

In this guest post, my colleague Tigran Arzumanov asks questions about questions.  Tigran is an experienced and highly talented business developer for life science companies and he’s been around the block a few times.

What to do when a medical device company  asks the wrong questions?

I am sure we’ve all been there.

You meet the senior management of an innovative medtech company. They’re looking for a contract manufacturing partner or a regulatory consultant or an embedded software developer or a clinical research platform. You know you can deliver.  You’ve done dozens of projects like that.

They’re concerned about quality and on-time delivery.     You want to qualify them and make sure they are a good fit for your offering.

You came in on time, you are prepared. You know you can deliver to the client needs. The greeting is welcoming, genuine and heartfelt, the handshakes are firm. Smiles all around. You sit down and start talking. And, little by little, you start finding out what the client wants.

As you hear more and more, your sunny cheerful mood starts dripping away, little by little.

You realize that that the medtech company’s picture of the project and the conclusions that he’s made are drastically different from yours. That the client is likely to reject what you offer, because they want something you do not sell.

Yet, you’ve seen this a dozen times already and you know what the client wants to do won’t work.

What to do

There’s no point in trying to argue your point. Win an argument – lose a client – I learned that this quote by Peter Drucker is as true today as it was in the 80s.

In some cases, you will have to walk away and hope the medical device company realizes soon enough that they are on the wrong track – and once they do, they will remember who gave them a truthful answer.

Whether you close the prospect on that first meeting, or after a year of  conversation, the key is to get to no.   

Getting to no is a great starting point for you to understand the client needs.   Getting to no is also a great way for the client to understand that there are advanced technologies out there that can help him bring his connected medical device to market faster.

A former colleague had a favorite saying – ‘a good vendor answers a client’s question well, a great vendor tells a client what questions they should be asking”.

Carl Sagan was a physicist.  Physicists are curious people by nature. This saying is a great way to make the client curious.

In my experience, most people will ask ‘so, what questions do you think I should be asking?’ Then you are not pushing your vision and ideas, but keep on answering the questions. The client is still in control. And if this phrase has not triggered their curiosity, perhaps you are better off walking.

Another way to mildly give a version different from the one the client asks is to give an anecdote from your experience. Acknowledge what the client has said, and then say “actually, I had a client in a similar situation”. If the flow of the conversation allows it, make a pause so that the client asks how it turned out – and then deliver the story. Few people will resist the temptation to listen to a story about someone in a similar situation to them – and if they pass, perhaps you had no business being in a meeting with them in the first place.

Tigran Arzumanov is an experienced business development/sales consultant running BD as a service, a Contract Sales Organization for Healthcare IT and Clinical development.

 

 

 

 

 

 

 

 

 

Curious about how cloud technologies and AI can help you get your medtech product faster to market?

100X faster to deviation detection in medical device studies.

Automated Patient compliance deviation detection and response on the flaskdata.io platform for a connected medical device clinical trial is 100X faster than manual monitoring. Automated compliance monitoring analytics and real-time alerts let you focus your site monitoring visits on work with the PI and site coordinators to take total ownership and have the right training and tools to meet their patient recruitment and patient compliance goals.

Good strategy bad strategy for study monitors in connected device studies

Friday is an off-day in Israel and I try to work on projects or read.

I am now reading Richard Rumelt’s book Good strategy Bad strategy: The difference and why it matters. 

The core content of a strategy is a diagnosis of the situation at hand, creation or identification of a guiding policy for dealing with the critical difficulties and a set of coherent actions.

For starters, strategy is not pie-in-the-sky visualisation of a better world/better product/better process.  Strategy is not about wanting  something bad enough and boom it  happens. It won’t.     The essence of a good strategy is a set of coherent actions. If we perform a diagnosis of EDC operations for connected medical devices, we often see strange things going on.  As a result of the diagnosis, you can formulate a set of coherent actions to fix the problem.

EDC work flow in a connected device study

1. We see sites doing SDV on device and patient-reported outcome data in the EDC.   When the source data is digital, there is no point in performing source document verification.

2.Then you see valid EDC inclusion/exclusion with queries that the source was not filled out. (Right now,  I see 40 queries with valid EDC data but missing questions in the paper source questionnaire).  There was a site monitoring visit June 6 and the CRA raised queries related to data entered on 19-Apr-2019. These are queries 49 days after the data was captured.

I happen to know the CRA and she is great.  No questions there at all.

But why fix paper source 49 days after the patient was found to be eligible for the study and is already in treatment?  Something seems wrong with the process.    What’s going on, is that we are fixing paper source over 6 weeks after the fact. That sucks.

You don’t need deep technology to reduce the data cycle by 98%

Let’s apply Rumelt’s strategy method to EDC for connected medical device studies. We create a guiding policy:

Reduce the data cycle to 1 day from 49 days

The set of coherent actions to execute the guiding policy is:

1.Do not SDV connected device and ePRO data. There is not point in validating electronic source against itself.

2.Improve GCP compliance and save time retroactively fixing paper documents.  Just enter the Inclusion/Exclusion criteria directly into the EDC and make the EDC the electronic source according to the FDA Guidelines on electronic source

If there is a connectivity issue in the treatment room, you can use Flask Forms on your phone to enter the IE CRF directly into the EDC.

It is easy to improve the process. All you need is a good strategy.

How to improve patient compliance in your medical device study

Here’s an idea that will make you slap your forehead.

You can just stop transcribing case reports on paper.

FDA eSource guidance recommends direct data entry into your EDC.  The eCRF becomes electronic source and you eliminate source document verification.

You save money, systems, time and you get to go home early.

Don’t let people confuse you with all kinds of complicated scenarios just because they’re selling systems.

Check out my blog post on Why merging medical records and clinical trial data is a very bad idea and see how merging EMR and clinical trial data can expose you to data breaches and endanger your clinical trial success.

Just keep it simple.

Do you  have 15 minutes for a quick call  with me?

– Tuesday @10 AM
– Wed @ 12AM
– Thur @ 2PM
Schedule a call with me  https://calendly.com/dannyl/15min

Treating EDC Induced Dissociative Panic Disorder

There is considerable online discussion about real-world data in clinical trials, virtual trials, digital trials, medical IoT, wearables, AI, machine learning for finding best candidates for treatment and digital therapeutics.   From the EDC vendors’ web sites – everything is perfect in a perfect world. Medidata Rave – for example:

Run Your Entire Study On A Unified, Intelligent Platform, Built On Life Science’s Largest Database.

But what happens when the EDC generates 2011 new erroneous queries?

I’m pretty sure that all the hi-fangled buzzwords don’t mean much at this point.

Why EDC queries are bad

There are 6 reasons why EDC queries are bad:

1.EDC queries push workload deeper and later into the clinical trial process.   Deeper and later creates a traffic jam of work.

2.EDC queries are a vestige of paper processing and do not belong in a modern online transaction processing system. If you are not sure about this – ask yourself if AirBnB, Lufthansa and Booking require you to use queries to fix data entry mistakes.

3. EDC queries are resolved in a separate work-flow from data capture.   This creates a work-flow context switch which slows down the site from fast and accurate data collection.    It’s like driving and texting at the same time.  But the work-flow context switch is even worse with queries – see point 4.

4.EDC queries are often resolved days or weeks after the data capture.   Most people can remember what they did this morning but 3 weeks ago? How is this an effective process.

5.When EDC systems like Rave generate large numbers of erroneous automated queries – Moonshine is called for.

6.When we look at the number of automated EDC queries generated by edit checks versus discrepancy notes generated by study monitors we see that there are perhaps 500-1000X more automated queries than the high-value notes generated by a CRA.    This is bad.    The high-quality signals from the CRA get lost in the noise of automated EDC queries.

3 things we can do to improve study productivity

1.Turn off automated EDC queries completely

2.Resolve data issues during data entry. Don’t delay resolution more than a work-day.

3. Trace your query close rate. With a small number of high value notes from the CRA – you can do it on your fingers.

 

Killed by code in your connected medical device

patient compliance in medical clinical device trials

Are we more concerned with politicians with pacemakers or families with large numbers of connected medical devices?

Back in 2011, I thought it would only be a question of time before we have a drive by execution of a politician with an ICD (implanted cardiac device). May 2019, with mushrooming growth in connected medical devices (and after the Israeli 2019 elections), I am rethinking my risk analysis.

Consider this: If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable that this number will double with medical IoT and software as devices for diabetes management, asthma monitoring, fetal monitoring, remote diagnosis of children, home-based urine testing and more.

So far, it seems the politicians are still around, but the cybersecurity vulnerabilities for medical devices are growing in frequency and impacting big medical device vendors like Medtronic as reported by FDA in March 2019 – Cybersecurity Vulnerabilities Affecting Medtronic Implantable Cardiac Devices, Programmers, and Home Monitors

Audience: Patients with a Medtronic cardiac implantable cardioverter defibrillators (ICDs) or cardiac resynchronization therapy defibrillators (CRT-Ds)

-Caregivers of patients with a Medtronic ICD or CRT-D

-Cardiologists, electrophysiologists, cardiac surgeons, and primary care physicians treating or managing patients with heart failure or heart rhythm problems using a Medtronic ICD or CRT-D

-Medical Specialties

-Cardiac Electrophysiology, Cardiology, Cardiothoracic Surgery, Heart Failure

Purpose: The U.S. Food and Drug Administration (FDA) is issuing this safety communication to alert health care providers and patients about cybersecurity vulnerabilities identified in a wireless telemetry technology used for communication between Medtronic’s implantable cardiac devices, clinic programmers, and home monitors. The FDA recommends that health care providers and patients continue to use these devices as intended and follow device labeling.

Although the system’s overall design features help safeguard patients, Medtronic is developing updates to further mitigate these cybersecurity vulnerabilities. To date, the FDA is not aware of any reports of patient harm related to these cybersecurity vulnerabilities.

In Jan 9, 2017 FDA reported in a FDA Safety Communication on “Cybersecurity Vulnerabilities Identified in St. Jude Medical’s Implantable Cardiac Devices and Merlin@home Transmitter.

At risk:

-Patients with a radio frequency (RF)-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

-Caregivers of patients with an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

-Cardiologists, electrophysiologists, cardiothoracic surgeons, and primary care physicians treating patients with heart failure or heart rhythm problems using an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

Different classes of device. Different threat scenarios. A wellness app does not have the same threat model as implanted devices

I’ve been talking to our medical device customers about mobile security of implanted devices for over 7 years now.

I  gave a talk on mobile medical device security at the Logtel Mobile security conference in Herzliya in 2012 and discussed proof of concept attacks on implanted cardiac devices with mobile connectivity.

But – ICD are the edge, the corner case of mobile medical devices.

If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable scenario that this number will double withe devices for fetal monitoring, remote diagnosis of children, home-based urine testing and more.

Mobile medical devices are becoming a pervasive part of the Internet of things; a space of  devices that already outnumber workstations on the Internet by about five to one, representing a $900 billion market that’s growing twice as fast as the PC market.

There are 3 dimensions to medical device security – regulatory (FDA), political (Congress) and cyber (vendors implementing the right cyber security countermeasures)

The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that the software as a device mobile apps:

-are intended to be used as an accessory to a regulated medical device, or

-transform a mobile platform into a regulated medical device.

Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review. The FDA guidance document  provides examples of how the FDA might regulate certain moderate-risk (Class II) and high-risk (Class III) mobile medical apps. The guidance also provides examples of mobile apps that are not medical devices, mobile apps that the FDA intends to exercise enforcement discretion and mobile medical apps that the FDA will regulate in Appendix AAppendix B and Appendix C.

Mobile and medical and regulatory is a pretty sexy area and I’m not surprised that politicians are picking up on the issues. After all, there was an episode of CSI New York  that used the concept of an EMP to kill a person with an ICD, although I imagine that a radio exploit of  an ICD or embedded insulin pump might be hard to identify unless the device itself was logging external commands.

See my presentation ‘Killed by code’

Congress is I believe, more concerned about the regulatory issues than the patient safety and security issues:

Representatives Anna Eshoo (D-CA) and Ed Markey (D-MA), both members of the House Energy and Commerce Committee sent a letter last August asking the GAO to Study Safety, Reliability of Wireless Healthcare Tech and report on the extent to which FCC is:

Identifying the challenges and risks posed by the proliferation of medical implants and other devices that make use of broadband and wireless technology.
Taking steps to improve the efficiency of the regulatory processes applicable to broadband and wireless enabled medical devices.
Ensuring wireless enabled medical devices will not cause harmful interference to other equipment.
Overseeing such devices to ensure they are safe, reliable, and secure.Coordinating its activities with the Food and Drug Administration.

At  Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin pumps.

Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary food).

The FDA position that it is sufficient for them to warn medical device makers that they are responsible for updating equipment after it’s sold and the downplaying of  the threat by industry groups like The Advanced Medical Technology Association is not constructive.

Following the proof of concept attack on ICDs by Daniel Halperin from the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Defibrillators:Software Radio Attacks and Zero-Power Defenses”  this is a strident wakeup call to medical device vendors  to  implement more robust protocols  and tighten up software security of their devices.