MedTech Data

I recently bought a new washing machine from a well-known internet provider of household goods. As the model is Korean, I am confident that it will give very good service and therefore didn’t bother with filling in the warranty. As most of my information with the internet provider is covered by GDPR the manufacturer can only really know that a particular serial number has been sold and that’s it. In this instance then, there is no data relationship.

Now let’s say I decide to manufacture and sell tumble dryers. Knowing the potential dangers, I fit various monitoring sensors and Wi-Fi capability. The machine is tested to the relevant standards and therefore safe to sell. So, let’s be clear, it is safe due to testing and has on board monitoring in case of a random event/failure. Even though the initial testing was rigorous, I now spot a potential problem as a result of large data collection in the real world. The software can be modified, tested and importantly downloaded over the air, making the machine safer. In this instance the data is being used in a straightforward manner to maintain safety. It’s probably worth noting that the effectiveness of a tumble is not ambiguous, ergo “is my t-shirt dry”?

So, why am I worried about Medical Device data?

Complexity

Let’s say you have an insulin pump that knows your basic physiology, what you eat, how active you are and through a link to a continuous glucose sensor, your glucose levels. You now potentially have the capability to offer an artificial pancreas (AP). This must be a prime example of a real time safety critical data relationship. However, if no AP is implemented then all the existing data can still be used to trend against a consumable’s performance, which is complex!

Fuzzy Effectiveness

Clinical effectiveness is not always black and white. In the original clinical trial, if there was one, there should be significant evidence of a beneficial clinical result. But you could now be generating huge amounts of data, some of which may have a subset which falls into a category of sub-standard effectiveness. Think about that category for a moment. At what point does this become unsafe and possibly require a field notice? It is probably worth challenging your device with this scenario or, at least looking for possible candidates in the risk assessments.

Consumable Batch Release

Batches, by definition, are discrete and do represent a potentially useful way to ‘bracket’ quality issues. But even if you can automatically test some consumables from the batch, it is likely, it will be a sample, it will not be for the entire in use time, it will not emulate all the physiology interfaces and therefore the data is less sophisticated. While you hope that batch to batch variation is minimal you now have a new relationship of post batch release field performance. Why is this a problem? Because many cause and effect hypothesis and weak patterns can now undermine confidence in the batch release process. It is therefore messy.

So you have all this post market data, what are you going to do with it? Firstly, the biggest risk with data is that you now have a new mechanism to uncover a safety issue, whereas before it may have been latent. There are already good systems in place to handle this, but it is still important to realise that your post market surveillance is now more complex with the addition of data. Secondly, information related to product effectiveness is much more likely to be discovered. Unfortunately, this can be a grey area. Why and when do you decide to take some intervention and improve the current product?

Do you have a data policy/SOP in place? I'm not talking about GDPR here, but the best way to manage data cadence within the business. Here are a few basic starting points to consider:

Sponsor - Whoever is sponsoring the effectiveness of data within the business should not be ambiguous. This person should have a very good system level view of the product, try hard to suspend bias and importantly have a great working relationship with the design authority. Design authority here meaning the person/s who knows how the thing actually works!

Interpretation - So you have invested in a connected device, maybe invested hundreds of thousands of pounds realising BLE capability. You have a data scientist, right? If the answer is no, then get one. You need someone full time to start extracting, cleaning and analysing the data and more importantly actually own and help the business grow into this new area.

Dissemination - When you present data, is should be clear with a consistent style to avoid confusion. I tend to think that if I can’t understand it after a cuppa, then it’s probably not me. Data communication should be beautiful, I would recommend you read any of Edward Tufte’s books.

Access - Until you understand the data and its relationship to your product and user experience, releasing it to the business can be disruptive. People should be given formal training on the layout and meanings. It’s probably best to do this cross functionally rather than by department as departmental bias can be very unproductive.

Generating and analysing data makes us all less ignorant and provides an evidence based way to improve a medical device’s design and/or production. But, be prepared for all that it will reveal!