Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Manageable Affordances TF] Digital physical rehabilitation #32

Open
jpcik opened this issue Feb 15, 2024 · 1 comment
Open

[Manageable Affordances TF] Digital physical rehabilitation #32

jpcik opened this issue Feb 15, 2024 · 1 comment
Labels
scenario Scenario motivating a specific feature

Comments

@jpcik
Copy link
Contributor

jpcik commented Feb 15, 2024

Title: Digital rehabilitation

Submitter(s):

Jean-Paul Calbimonte

Motivation:

In the context of physical rehabilitation, traditional practice is based on human observation of exercises and movements, which are often too subjective and difficult to replicate at home, where patients have no practical way of self-assessing correctness of the exercises, leading to potential further injuries or ineffective rehabilitation.
This use case contemplates the usage of wearable devices that can be placed in different parts of the body, connected to a tablet where the patient can get visual and/or audial feedback on the exercises in near-real-time.

Expected Participating Entities:

  • Patient
  • Physiotherapist (for validation)
  • set of wearable motion detection sensors (e.g., Nordic Thingy 52, etc)
  • Tablet (hosting orchestrator + patient app)

Workflow:

  • Physio defines exercise: goals and expected movements to be captured by devices.
  • Orchestrator registers specific role for the wearables and expected outputs.
  • Patient initiates exercise in the Tablet
  • Orchestrator gathers motion information and computes assessment of exercises
  • Audio/visual feedback provided to the Patient
  • Exercise repetitions until the set is finished.
  • Physio receives overall assessment of the exercise set.

Related Use Cases (if any):

  • Multi-patient variant (reporting progress of multiple patients)
  • Self-cofniguration of devices.

Existing solutions:

In progress.

Identified Requirements by the TF:

To be filled after submission. Examples of requirements include usage of specific communication protocols, media types, platforms, security and privacy mechanisms, or accesibility.

Comments:

@jpcik jpcik added the scenario Scenario motivating a specific feature label Feb 15, 2024
@egekorkan
Copy link
Collaborator

@jpcik thank you for the scenario proposal! We are now going to extract the requirements from each use case and we need you to extend your first comment with the types of requirements listed at #34. You can have a look at an example at #24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scenario Scenario motivating a specific feature
Projects
None yet
Development

No branches or pull requests

2 participants