What is a gait analysis API and how can it be integrated into a digital health product?

What a gait analysis API is

A gait analysis API is a programming interface that accepts movement data captured from a device and returns calculated movement measures. It does the hard measurement science so that a product team does not have to build signal processing, gait-event detection and validation from scratch.

It is a component, not a product. It has no user interface, no patient experience and no clinical workflow of its own — those are the responsibility of whatever calls it.

The five stages: capture, submit, analyse, return, use

1. 1Capture — the person performs the movement while a device records it: smartphone inertial sensor data for gait, or video for camera-based assessment. Protocol and placement are fixed at this point and cannot be corrected later.
2. 2Submit — the captured data is sent to the analysis service over an authenticated, encrypted request, together with the context needed to interpret it, such as which assessment type was performed.
3. 3Analyse — the service processes the signal: filtering, detecting movement events, deriving measures, and applying quality checks that can flag a capture as unreliable.
4. 4Return — structured results come back as data: named measures with values and units, plus quality or confidence information where relevant.
5. 5Use — the calling product stores, displays and interprets those results inside its own record, dashboard, report or research dataset.

Three different things that get called ‘an API’

Confusing these three is the most common source of mismatched expectations in integration conversations.

• Choose an analysis API when you already own the patient relationship and interface, and only need trustworthy measurement.
• Choose an assessment runner when you want to keep your product but not build and maintain a sensor-capture experience.
• Choose a hosted platform when the goal is to start measuring rather than to build software.

What integration involves in practice

1. 1Authenticate your product to the service using credentials issued to you, kept server-side and never embedded in a mobile or web client.
2. 2Trigger an assessment for a specific person or study participant, using your own identifier rather than sending identifiable personal data where that can be avoided.
3. 3Handle the returned measures as structured data in your own model, so you are not parsing display text.
4. 4Decide how results are presented and who is allowed to see them.
5. 5Handle failure explicitly: an incomplete capture, a declined permission, a flagged quality problem.
6. 6Agree data-processing responsibilities, retention and lawful basis before going live with real people.

The MoveLab Engine at a high level

The MoveLab Engine is the measurement layer behind everything MoveLab does. It takes movement data captured on everyday devices — smartphone inertial sensor data, camera video, and wearable activity data as context — and produces movement measures such as gait parameters, joint angles and range of motion, and functional mobility scores.

• One measurement layer, several delivery routes: the same Engine sits behind the MoveLab Platform and behind partner integrations.
• Modality chosen to suit the measurement: inertial sensing for gait and temporal measures, camera-based analysis for joint position and range of motion.
• Quality signalling, so a capture that does not meet the protocol can be identified rather than silently reported.
• Results returned as structured measures that a calling product can store and display.

The internal algorithms, models and processing steps are proprietary and not documented publicly. What is documented is the interface, the measures returned, and the evidence base for those measures.

Questions worth asking any provider

• Which specific measures are returned, and for which movement protocols?
• What peer-reviewed validation exists, in which population, against which reference standard, and under what capture conditions?
• What results were reported for each measure?
• What happens when a capture is poor — is it flagged, or silently reported?
• Which devices, browsers and placements the evidence actually covers.
• Who is data controller and who is processor, and where data is processed and retained.
• What regulatory status the product holds, and what intended use that status covers.

Where the evidence sits

For MoveLab, the gait and functional-mobility measures returned by the Engine rest on peer-reviewed validation against marker-based 3D motion capture and clinical-standard assessment. That study was conducted in 25 healthy adults, in a controlled laboratory, with the smartphone secured at the waist, and its agreement varied by parameter.

The publication page sets out the tested population, reference methods and parameter-by-parameter results in full.