Missing n-steps parameter in pipeline output

[AKuederle]

Multiple people have reached out asking about the availability of the n_steps parameter in the output of the Mobilise-D pipeline.

Background

This parameter is part of the set of DMOs that we validated successfully in the study and aggregated DMO results of the original pipeline include this value. Further, the Aggregator class still handles the aggregation of n-steps (

mobgap/mobgap/aggregation/_mobilised_aggregator.py

Line 29 in 01bfd5e

class MobilisedAggregator(BaseAggregator):

).
However, the new pipeline does not provide any comparable value.
This has a couple of reasons:

• The n-steps output of the original pipeline was "just" the number of raw initial contacts detected within the WB. The parameter was included in DMO analysis, but does not follow the same level of scrutiny and definitions the other parameters aim to adhere to. Namely, n-steps parameter included all initial contacts and not just the initial contacts that belong to "valid" strides as defined in the project.
• Because of the mismatch in definition, the n-steps and n-strides parameters don't always match (aka n-steps is not 2*n-strides). This is confusing.
• n-steps can be calculated by many systems that track daily activity (from actrigraph to apple health). Therefore, people have compared the sum of all n-steps of all WBs with the expected number of steps for a specific clinical cohort. The Mobilise-D pipeline reported significantly lower amount of steps as expected from literature. This resulted in initial confusion. However, this is in line of what we expect from the pipeline. The pipeline is tuned to ensure we only include valid walking in our final analysis to provide accurate estimates of "micro"-parameters (stride length, walking speed, ...) at the cost of excluding/missing shorter or less defined walking sequences. This means the direct aggregated pipeline output is not a good way to estimate typical macro parameters like "n-steps/strides taken per day".

Therefore, we decided initially to omit this parameter (at least in its old form) from the pipeline.
While the parameter has been shown to full-fill our criteria of a valid DMO at least with its current name and without further context, it is to easy to misinterpret.

Options

We want to include the parameter in the pipeline, given that it was a validated DMO of Mobilise-D and part of the output of the old pipeline. However, we have not decided how. Current options up for discussion are:

1. Include it in the same way it was originally calculated but under a "legacy" flag and a different name to ensure it is clearer on how to interpret the parameter. This would allow for reproducibility and it would still be possible to use the parameter if required.
2. Attempt to provide an estimate of n-steps that would more closely align with the standards and the n-stride value (could be as simple as 2*n-strides). While this would be a more coherent implementation of a n-steps parameter, this would mean that any validation we did for the parameter is not valid anymore.

Open for ideas, opinions and discussions!

[AliMcRoberts]

Thanks for the explanation! I have two comments:

1. Would it be an option to keep track of the count of steps that belong to a valid stride? Since original_gs_id is included in annotated_stride_list_, and we know the number of steps per gs_id, we could determine the number of steps that ultimately contribute to a 'valid' stride. Below is my suggestion to implement this:

wb_original_gs_id = pipe.wba_.annotated_stride_list_.groupby("wb_id")["original_gs_id"].agg(lambda x: x.mode()[0])  # Get most common original_gs_id per wb_id
step_counts = pipe.raw_ic_list_.groupby("gs_id").size()  # Count step_ids per gs_id
per_wb_parameters["n_steps"] = per_wb_parameters.index.map(lambda wb: step_counts.get(wb_original_gs_id.get(wb), 0))

2. Regarding your second point, I don't agree that the number of steps should be exactly double the number of strides based on the definitions. Here's an example:

   Steps: L-R-L-R-L-R-L-R
   Number of steps: 8
   Strides starting with the left foot: 4
   Strides starting with the right foot: 3
   Total strides: 7

As seen here, the number of strides is slightly different from the number of steps. This mainly happens because we count strides separately for left and right foot. Some discrepancy is also expected due to invalid/incomplete strides.

What is your opinion on this?

[AKuederle]

Regarding 1: I don't think the code does exactly what you suggest. But yes, the basic idea of considering steps that belong to valid strides makes sense. I think the easier approach here is to just to consider a unique list of all start and end values of all Strides within a WB

Regarding 2: Yes, I agree. The reality is that the step/stride definitions are difficult in practice due to a bunch of edgecases in particular when you consider that both the initial contact detection and the left right assignment can make errors.

Just to give an example of a biomechanical edgecase: You walk stop with the right foot, then you step the left both feet to parallel, pause for a second, and then continue with the left foot. Even assuming we can detect all of that correctly you now have a foot-contact sequence that goes L-R-L-L-R and is completely valid and we have seen this sequence multiple times in the reference data during the TVS. From an algorithm perspective we can not differentiate, if this is a valid sequence, if we just did not detect a initial contact between the two L ICs or if the left right detection did not work well (which can happen in particular during curved walking).

What I am saying is trying to be to bio-mechanically correct with these definitions is a world of strange edgecases and the influence of correctly handling them is likely dwarfed by the expected amounts of misdetections and other algorithmic errors.

As I would never suggest to use our n-step/n-stride count to be an accurate measure for "all strides/all steps" taken throughout a day, but should only really be used to get an idea of WB length, I think a simple definition might suffice here.

At the moment I think it would not be a good idea to provide the measure on an aggregation level. Aka I am considering replicating the old measure (maybe under the name n_raw_initial_contacts) but not try to overeng. a accurate step count.