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.

Why medtech companies should ask wrong questions

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.

Are you looking for ways to reduce the amount of paper in your connected 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.

Improving patient compliance to medical device protocols with threat models

To paraphrase Lord Kelvin – “You cannot improve what you cannot measure”.

I have about 10′ before Shabbat and I wanted to offer 2 possible approaches for improving patient compliance to medical device clinical protocols.

One approach considers the patient as an attacker to the study data.  This approach considers social, cost, adverse events, personal, technical and privacy aspects as study data vulnerabilities.  The idea is to construct a prioritised countermeasure plan during the study and refine it with real-world data

The second approach uses a behavioral model as opposed to a threat model.

It assumes that patient compliance to a protocol in a trial will always be better than in real-life but that at the end of the day – people have various reasons sometimes not clearly known to themselves why the do not comply.

In this approach, a cost-effective strategy for assuring compliance post-marketing in the real-world  uses validated machine learning models of what affected patient compliance during the controlled clinical trial.   Reinforcement during the trial also reveals to the model what worked and what didn’t.

In order for a medical device company to decide what model works best for them – they must measure the movement and value of their data, and weigh that in terms of their data model.

4 strategies to get connected medical devices faster to FDA submission

Introduction

Better designs, site-less trials, all-digital data collection and PCM (patient compliance monitoring) can all save time and money in connected medical device clinical trials.  This article will help you choose which strategies will be a good fit to help you validate your connected medical device and its intended use for submission to FDA.

What is the baseline cost? (hint don’t look at the costs of drug studies)

If you want to save, you need to know the price tag. Note that the costs of drug trials, including CRO and regulatory affairs is an order of magnitude higher than for connected medical devices.  A JAMA report from Nov 2018, looked at drug trials and concluded that a mean cost of $19M was cheap compared to the total cost of drug development – $1-2BN.

Findings:  In this study of 59 new therapeutic agents approved by the FDA from 2015 to 2016, the median estimated direct cost of pivotal efficacy trials was $19 million, with half of the trial cost estimates ranging from $12 million to $33 million. At the extremes of the distribution were 100-fold cost differences, and patient enrollment varied from fewer than 15 patients to more than 8000 patients.

By comparison, the estimated cost of medical device clinical trials to support approval by the FDA, ranges from $1 million to $10 million. A report from May 2017 surveyed the costs of medical device clinical trials and the potential of patient registries to save time and money. The report has some interesting numbers:

1.The average cost to bring a low-to-moderate concern device from concept to 510(K) approval is $31 million. 77% of that is spent on FDA-related/regulatory-affairs activities.

2.The average cost for a high-risk PMA device averages $94 million, with $75 million spent on FDA-related/regulatory-affairs activities. Average of 4.5 years from first contact with FDA to device approval.

3.Clinical trials outside the US are 30% to 50% cheaper. Less than 50% of medical device trials are now conducted in the US.

I. Better study designs

Real-world data (RWD) and real-world evidence (RWE) are being used for post-market safety surveillance and for designing studies, but they are not replacements for conducting a randomized trial with a controlled clinical protocol.  FDA recently issued guidance for use of real-world evidence for regulatory decisions.  FDA uses RWD and RWE to monitor post-market safety and adverse events and to make regulatory decisions.

RWD and RWE can be used in 4 ways improve the design of medical device clinical trials when there is a predicate device that is already being used for treating patients.

1.Use RWD/RWE to improve quality and efficiency of device evaluation at study phases (feasibility, pivotal, and post-market), allowing for rapid iteration of devices at a lower cost.

2.Explore new indications for existing devices

3.Cost efficient method to compare a new device to standard of care.

4.Establish best practices for the use of a device in sub-populations or different sub-specialties.

You will need to factor in the cost of obtaining access to the data and cost of data science.

But real-world data may not be reliable or relevant to help design the study.  As FDA notes in their guidance for Using Real-world evidence to support regulatory decision making:

RWD collected using a randomized exposure assignment within a registry can provide a sufficient number of patients for powered subgroup analyses, which could be used to expand the device’s indications for use. However, not all RWD are collected and maintained in a way that provides sufficient reliability. As such, the use of RWE for specific regulatory purposes will be evaluated based on criteria that assess their overall relevance and reliability. If a sponsor is considering using RWE to satisfy a particular FDA regulatory requirement, the sponsor should contact FDA through the pre-submission process.

II. Site-less trial model

Certain kinds of studies for chronic diseases with simple treatment protocols can use the site-less trial model.  The term site-less is actually an oxymoron, since site-less or so-called virtual trials are conducted with a central coordinating site (or a CRO like Science37). Nurses and mobile apps are using to collect data from patients at home.   You still need a PI (principal investigator).

The considerable savings accrued by eliminating site costs, need to be balanced with the costs of technology, customer support, data security and salaries and travel expenses of nurses visiting patients at homes.

III. Mostly-digital data collection

For a connected medical device, mostly-digital data collection means 3 things:

1.Collect patient reported outcome data using a mobile app or text messaging

2.Collect data from the connected medical device using a REST API

3.Enable the CRC (clinical research coordinator) to collect data from patients (IE, ICF for example) using a Web or mobile interface (so-called eSource) and skip the still-traditional paper-transcription step. In drug studies, this is currently impossible because hospital source documents are paper or they are locked away in an enterprise EMR system. For connected medical device studies in pain, cannabis and chronic diseases, most of the source data can be collected by the CRC with direct patient interviews. Blood tests will still need to be transcribed from paper. Mostly-digital means mostly-fast. Data latency for the paper source should be 24 hours and data latency for the digital feeds should be zero.

There are a number of companies like Litmus Health moving into the space of digital data collection from mobile devices, ePRO and wearables. However, unlike validating a connected medical device for a well-defined intended use, Litmus Health is focused on clinical data science for health-related quality of life.

IV. PCM (patient compliance monitoring)

Once the data is in the system, you are almost there.  Fast (low-latency) data from patients, your connected device and the CRC (which may be nurses in a site-less trial) are 3 digital sources which can be correlated in order to create patient compliance metrics.  But that is a story for another essay.

Summary

We have seen that new business models and advanced technologies can help sponsors conduct connected medical device trials cheaper and faster. It may not be a good fit for your product.  Contact us and we will help you evaluate your options.

For more information read Gail Norman’s excellent article  Drugs, Devices, and the FDA: An overview of the approval process

 

 

 

 

 

 

 

 

How to become an insights-driven clinical operations manager

In my post Putting lipstick on a pig of eCRF I noted that good online systems do not use paper paradigms. In this post – I will develop the idea of using digital / mobile /automation to become an insights-driven clinical operations manager.

Insights-driven clinical operations practices are more important than ever if you want to operate a global multi-center medical device trial with speed at scale.

I’ll show you how the democratization of data insights with a comprehensive patient compliance monitoring (PCM) platform can help you improve:

1.Medtech Developer and clinical trial operations productivit

2.Site coordinator experiences

3.Treatment and patient reported outcome compliance

Democratization of data insights

In the old world of legacy clinical operations, you waited for site monitoring visits to get feedback on deviations. Remote monitoring and modern EDC systems have enabled us to take a big step forward, although it seems that CRO central monitoring activities move the analytics and deviation detection and response further away from the site operations team and sponsor project manager.  Central monitoring for clinical trials is like the old Soviet central planning committees.   The exact opposite of democratization. Medidata purchased Shyft Analytics last year.  The Shyft platform combines different data sources and a data preparation pipeline of data cleaning, data transformation, normalization, metadata. The idea as I understand it, is to use both clinical trial and real-world commercial data to share data and insights in pharma clinical development and commercial teams. It seems that the system is not appropriate for neither medtech developers nor site operations teams.

Shyft Analytics is a beautiful example of democratization of data insights inside a pharmaceutical company but it is several levels removed from site clinical operations.

Medtech Developer and clinical trial operations productivity

The medtech engineering teams are often bit actors in the medical device clinical trial. For connected devices, this is a mistake in our experience.   A connected medical device, software medical device app or home device uses APIs to external systems (which may fail) and embedded hardware and software (which may fail).     Feedback from the sites in real-time to the device engineers will help fix issues and improve availability and performance of the device or enable swapping out faulty devices.

Here is a screen shot from a Flaskdata instance clearly showing 2 patients and 2 different sites with device failure issues.

Site coordinator experiences

Here is another example of how integrating the device logs with the PCM platform helps the site understand quickly why the patient is having treatment compliance issues.

The site coordinator, study monitor and study PM can now see the big picture for this patient – in this case, the patient has a device issue which impacts treatment compliance and reporting issues.

Treatment and patient reported outcome compliance

The data is then aggregated using a generalized patient compliance model to provide an overview and comparison of how the sites are performing on their patient compliance metrics. The site coordinator can drill down to individual patients as we saw above and run a playbook response to resolve the deviations. In a glance, we see that PRO compliance is very high at almost all the sites while the treatment compliance is at 71%.

People time is real-time

The word “democracy” (Greek: δημοκρατία) combines the elements dêmos (δῆμος, which means “people”) and krátos (κράτος, which means “force” or “power”), and thus means literally “people power”.  With real-time PCM that is always accessible to all the members of the extended medical device clinical trial, we can achieve true democratization of data insights.