Connected devices are devices that may or may not be approved/cleared medical devices. They can be used in multiple places, e.g., a device that is under investigation itself, or you can be using medical devices that are feeding data into informal study informing different endpoints (primary, secondary, exploratory) that you’re using. Effectively, we’re providing patient data in a digital format and there are different ways of bringing in that data, such as: continuous data, periodic data (e.g., once a day, for body weight measurement in a heart failure study), or one-time data.
Connected devices in general support all sorts of studies: drug, biological, cosmeceutical, nutraceutical, and medical device clinical studies and investigations.
When speaking of connected devices, there is a bit of a difference in terminology. In the US, the FDA has set some guidance around connected devices, and are referring to them as ‘’digital health technologies’’ (DHT). The term ‘’digital health technologies'' goes beyond medical devices, as it encompasses products such as Fitbit, or Apple Watch. Although these devices have features that inform about personal health, they are not necessarily medical devices.
‘’Digital health technologies use computing platforms, connectivity, software, and sensors for health care and related uses. These technologies span a wide range of uses, from applications in general wellness to applications as a medical device.’’ – as defined by the FDA
DHTs may be physical devices or, in the traditional sense, software, but very often they’re a combination of both. As mentioned before, they may provide continuous, periodic, or one-time data.
Listed below are some of the key considerations for why collecting and using connected device data is advantageous in clinical areas.
Connected devices have the capacity to collect real world ‘’in-situ’’ data, meaning in situations where it’s happening, as it’s happening. This in turn provides the ability to monitor the data and react to outcomes as they’re happening, as well as see what’s happening with the patient in real-time.
Another point to consider is that data provenance is easier to establish and harder to fabricate. The data coming in from a connected device is factual and cannot be refuted or interpreted, which is appreciated by regulators.
What we get from continuous data is evidence of episodic data vs. random data. There may be a time aspect or causal effect to this, there may also be all sorts of reasons why it happens at a certain time and the chances are that this certain time doesn’t happen when a person has an appointment with the doctor at 10 am in the morning. So, it is important to be able to collect that data on a periodic basis, be it over a few hours/days/weeks.
Lastly, real-time monitoring and the safety evaluation of data highly improves the quality and the safety aspects of a clinical study.
In Europe, devices need to be CE marked to inform an outcome of a clinical study. In contrast, in the US one can use DHT’s which have not received marketing clearance, to provide continuous data in clinical trials. This is mentioned specifically in the FDA draft guidance ‘’Digital health technologies for remote data acquisitions and clinical investigations’’ which came out on the 20th of December 2021.
‘’Devices intended for use in clinical investigations are exempt from most requirements applicable to devices, including premarket clearance or approval, as long as the investigation complies with applicable requirements under 21 CFR part 812.14 Therefore, DHTs used in clinical investigations of medical products typically would be exempt from applicable requirements to obtain marketing authorization and other device requirements, as long as the clinical investigation is compliant with part 812.'' – page 7, III. Regulatory Considerations and Engagement with the Agency
Read and download the FDA draft guidance.
While the European regulations don’t specifically address digital healthcare directly, the FDA has issued a specific draft guidance and on top of this, established the CDRH digital health care center of excellence.
Although many in the industry have disregarded this guidance, it provides some standard for how digital health, connected and medical devices should be implemented in the use of clinical investigations. This could be useful particularly for medical devices in Europe, where there is no governing body overseeing digital technologies in clinical studies.
DHT’s which have not received marketing clearance, don’t have to have received 510k (pre-market notification) or a PMA (pre-market approval), can be used to collect continuous data in a clinical environment. However, they must still meet the requirements on using investigational devices, set forth by the FDA regulations. If the device is not classified as serious risk, then you would still need to get IRB approval to use that device. If it is an IRB investigation you would need to make sure that that specific device has got an IDE to be allowed to be used in a study.
For example, if you were to conduct a drug study using a non-approved, non-cleared device to bring in continuous data you would still need to submit an IDE to be able to use that.
It is important to note that you cannot just use non-cleared devices that may or may not work. You must still do verification and validation work to be able to demonstrate to the agency that the device provides data that you would expect it to provide.
If you’re late on in your process and you’re expecting to have that device cleared soon, and by the time you submit to the FDA it has been cleared, or PMA has been approved depending on what the device requires, then you’re in pretty good shape. If you have any real concerns whether that device is going to meet the marketing requirements, you may want to think about where you put your endpoint (primary, secondary, exploratory).
Lastly, the device must meet all applicable standards: ISO, IEC, etc.
There are two types of data: high-frequency sampling, and low frequency sampling of data. The difference between the two is primarily the type of data that is collected from connected devices.
High-frequency sampling usually refers to physiological parameters that are continuously changing, where observation and monitoring of these parameters over a long period of time, down to the minor detail, is very important. E.g., heart rate, or pulse.
Low-frequency sampling refers to general outcomes that are less time sensitive, sometimes collected at random, but determined clinically wise to not be important or needed to be collected over a continuous period. That is because the physiological parameter or the outcome endpoint is known to not have a great impact on the outcome of the study if only collected occasionally.
So, when we’re talking about high-frequency sampling data that is what we call ‘’continuous data’’, as this data is collected continuously.
Continuous data is usually some kind of number, not text provided by some machine although it can be an alphanumeric result.
Continuous data is usually always linked to a timestamp. That is because one way of identifying a certain result is to read the timestamp which tells you exactly when this specific parameter was measured.
The difference between how often the sampling is done depends on the device and the details of the measurement that you’re making.
There is no defined standard for when data starts or stops being continuous. But essentially, if you’re collecting data at least once per hour or so, it can be considered continuous.
Periodic or random data collection measurements are usually done through eCRFs or ePROs using digital technologies once or multiple times a day, over the course of several weeks or months during visits. In reality, they don’t span much in volume. If we look at databases in SMART-TRIAL for example, it’s not uncommon to see databases below 100 MBs / GBs in size. The reason is that usually the actual data volume stored by the SMART-TRIAL platform, in cases where for example people are using our eCRF or ePRO solutions, is from a technical perspective not big in terms of storage size.
On the other hand, when we start looking into continuous data (e.g., collected 100 times per second), the volumes of data start to become quite extensive. This in turn leads to difficulties not only when it comes to storing and transferring, but also in terms of monitoring this data.
Data can sometimes be accumulated via a device on a patient and may require someone to come in every other day, or every three days, to unload said data. Most often, this data is unloaded into a text, or .csv format, but more and more companies use APIs to store the data in a cloud-based environment.
When you’re collecting data in a clinical investigation using electronic case support forms (eCRF) or electronic patient reported outcomes (ePRO) and gathering continuous data from a device, that data needs to be migrated sooner or later.
If you’re approaching a clinical investigation and you want to include a connected device as a primary or supportive endpoint in a study, start by identifying your parameters very specifically and why you would include them in the study. The rule of thumb is that too much data returns inferior data. You should be very selective as to what kind of information you’re trying to collect and how you want to collect it.
If the data cannot be collected discreetly or at random, and it doesn’t need to be collected continuously, you might not have to implement a continuous device.
You need to determine whether your product, as is, supports the application of continuous data collection. Verify whether the design allows or disallows the possibility to collect data continuously from the device, otherwise you may need a third-party solution to be able to achieve that. More and more new start-ups that focus on digital health (e.g., wearables, connected devices) are already implementing solutions that ensure their device data is streamed continuously from the beginning.
This is good news, because this enables the medical device market to include their device data with the rest of the clinical data in a clinical investigation. However, for older devices this may prove to be more difficult.
If you’re planning a clinical investigation and you’d like to include variables or connected devices, you need to take the stakeholders into consideration. How is this going to affect the patients/physicians? Are there any additional tasks that I will have to ask healthcare professionals to take upon? Can any of these tasks be automated, or standardized? This is all going to affect how you apply and implement this in practice.
Getting the data from a device into, for example, a centralized EDC can be a little tricky. There are a few specific integration touchpoints that you need to be aware of that you want to use, because they can differ from one solution to another.
There are several connected devices out there that have the possibility to bring data directly from the device into, for example, your electronic data capture system (includes eCRF, ePRO, outcomes). This scenario can be streamlined quite efficiently with a new solution, brought by SMART-TRIAL.
Another example is a device that is connected to a ‘’middle-man device’’ (e.g., smartphone) which is in turn connected to a centralized database (e.g., third-party back end, or third-party storage service provider). In this case, the integration will be a little more complex, due to there being more partners in between your centralized EDC or eCRF, and the actual connected device. It’s important to note that there are different integration touchpoints for different devices, which can introduce different complexities. There might be, for example, licensing issues involved, or payments required for use, or integration, or transfer of data.
Make sure that you are at least aware of these touchpoints, and where they are, so when you start the discussion of how to apply this, you can answer and address questions that might come from the technical side of things.
SMART-TRIAL has previously been able to support medical device manufacturers around the world, that use connected devices with low-frequency sampling, where the eCRF and ePRO data is collected via SMART-TRIAL’s interface. On top of that, we provide what we call ‘’SMART-TRIAL API” that can be used to gather data from any sources, whether it’s connected devices or other sources, and then feed that data into the SMART-TRIAL platform.
However, when it comes to continuous data, there’s a need for a completely different solution.
Whether the device is continuous or non-continuous, 200 Hertz/sec or 10 Hertz/sec, or 1 data point per second, etc., we have now made it possible to stream data directly into SMART-TRIAL, in any format or structure you like. This will enable you to bring your connected device data directly into your centralized clinical data management system, in a compliant, secure, and simple manner.
We have in other words, created a gateway for any connected device manufacturer to establish a very simple data structure that can then support any data coming from any connected device(s).
For help on implementing this new approach, contact us.
One of the most important things is to start off by defining your needs, data points, and their naming conventions.
Next, you would create a data schema / structure. Every single patient in the study can be given a watch that will collect steps and calories, every second. You can call this schema and study ‘’John’s watch’’ with steps, or calories as timestamps. You can also have multiple devices, e.g., ‘’John’s watch’’, ‘’John’s (continuous) glucose monitor’’, continuous active blood pressure, etc. Each one of these devices needs their own data structure, which can be easily created in SMART-TRIAL.
When the study is finished and completed, you can export all the data together in one data set, which is a structured format that enables you to analyze everything together. That is always linked with the subject id of choice.
If you want to better understand how you can use SMART-TRIAL with your connected devices in your specific studies / investigations, we encourage you to book a free, non-committal demo.
Let’s look at an investigational device used in a clinical investigation. This is a new SpO2 measurement device, and one of the ways that this needs to be tested in clinical investigations is to have a patient wearing the SpO2 measurement device throughout the course of a couple of weeks. Data can be streamed directly to a patient app which is usually on a smartphone, for example, and from there directly to SMART-TRIAL EDC, by simply inputting a potential 50-line code statement into the application.
The result is that every single time the SpO2 measurement device records data, it shifts it then to the patient app which provides the patient with certain end-experiences. The data can then be fed directly to SMART-TRIAL to be used as a data management source for clinical investigations.
This could also be potentially implemented in a PMCF context. If this is already established in a clinical investigation for pre-market approval, you could also continue to use this in a post-market surveillance context. This means that continuous data can be delivered through a centralized source (e.g., SMART-TRIAL EDC) without having to introduce necessary upload or download phases. It would then no longer be necessary for the patient to come into the clinic where a physician would unload data from the device and then upload it to a third source.
Another example is a medical device or digital health technology / connected device which is used as a supportive data tool in a clinical trial/ investigation. We could be looking at a continuous glucose monitoring device and step counting, where data might be streamed to two different cloud back-ends, because there might be two different products coming from two different vendors. These devices would have to collect data together and accumulate it to forward it to SMART-TRIAL.
SMART-TRIAL is offering a common gateway for all vendors that have such a setup, that allows them to feed data directly into SMART-TRIAL, if needed with our help. This approach reduces the burden of having to integrate different vendors and sources, and exporting data from different vendors in different formats, that doesn’t even suit the purpose of a clinical trial investigation. It also ensures that you can follow and observe that all data is coming in from all sources at the same time. So, during the clinical investigation you could see that there is data coming in from the glucose and the step counter for this and that subject. In this way you can clearly identify non-compliances during the study.
You are welcome to contact us if you are unsure about how to link your connected device to SMART-TRIAL EDC. You are also encouraged to watch our webinar ''Integrating Connected Devices Into Your Clinical Study'' on-demand.
Oops! Something went wrong while submitting the form