Blog 17 - Monitoring Wear Compliance with Verisense

Blog 17 explains the tools and features available within the Verisense system for monitoring wear compliance among study participants

When speaking with sponsors and other stakeholders that design trials incorporating wearable sensors, the topic of wear compliance is frequently one of their main concerns. In Blog 10, we outlined how the Verisense hardware and communications architecture reduces many of the burdens to wear compliance. In this blog, we will detail how the Verisense software portal aids trial managers in monitoring and understanding if wear compliance criteria is being met or not.

Determining Now-Wear

The Verisense system has embedded the GGIR algorithm to allow for metrics on activity and sleep to be easily retrieved and understood. GGIR is a public domain R package to process multi-day raw accelerometer data and is highly validated, having been used in over 90 peer-reviewed journal publications. GGIR contains a non-wear detection algorithm that is explained in more detail here.

Trial sponsors have the option to determine an acceptable level of non-wear within a day. For example, most studies that Verisense is involved in have set this threshold at 2 hours. This allows participants to take the sensor off for activities, such as bathing or washing dishes, should they prefer not to wear the sensor at these times and not be classed an non-wear.

Monitoring Non-Wear Daily

With Verisense’s ability to automatically upload data on a daily basis, we are able to get a near real-time understanding of whether the participant is wearing the sensor or not.

Logging into the Verisense web portal, site managers can get an in-depth look at how the sites and participants they’ve been assigned to are performing. In the example below, we can see the green color indicator in the Non-Wear column that shows this participant wore the sensor to meet the ‘wear’ criteria over the previous 24 hours.

In the below example, we can see the red color indicator in the Non-Wear column that indicates this participant did not wear the sensor to meet the ‘wear’ criteria over the previous 24 hours.

To further compliment this, the Verisense system can also be configured to send an email alert to the site manager notifying them of non-wear for a participant. These tools allow the site manager to intervene and remind the participant’s to wear the sensor where necessary.

Using Analysis Periods

Different study protocols have different requirements when it comes to wear compliance. Some studies ask for continuous 24/7 wearing of the sensor, while others have criteria such as requiring “x” amount of days of wear in the period between site visits. For example, 10 days of wear in the 28 days between site visits is similar to many protocols we’ve been involved in. Verisense has a built-in feature that allows site managers to review the participant’s wear compliance over the previous period between site visits and see if they met the wear criteria or not.

In the trial settings, the Analysis Goal, the number of days of wear required, Analysis period and the number of days between site visits is set. See screen below.

Within the Verisense portal for a participant, the trial manager can set up the analysis period and select the appropriate start and end dates for the site visit. The analysis period(s) created are then visible to the trial manager and they can quickly see if the analysis goal for days worn was met (green indicator), is in progress (blue indicator), or was not met (red indicator).

In addition, the trial manger can generate a report for a participant that will give a day-by-day status of their wear activity. See example email below.

As the above tools and measures were outlined in Blog 10, facilitating the long-term wearing of the sensor for the participant and being able to monitor this in near real-time are core features of the Verisense system. We are very pleased to see that in the studies Verisense has been used in to date we are consistently seeing over 90% wear compliance to the protocol requirements.

Previous
Previous

Blog 18 - Regulatory Standards & Data Protection

Next
Next

Blog 16 - Self reported outcomes versus sensor generated outcomes