introlab / opentera

OpenTera - Open TeleRehabilitation Server and Micro-Services

About OpenTera

OpenTera is a micro-services based backend primarily built to support research projects. Focusing on years in the research field, common features between the different projects emerged:

• Data structure: The need to store data in a structured way to ease data analysis
• Ecological data capture: The need to collect data not only in a laboratory or controlled environment, but also in the home
• Project adaptability: The need to develop projects specific dashboards while reusing as much as possible of what was done before to reduce development time
• Security: The need to store and transfer data in a secure and controlled way

To address those common features, OpenTera was designed with an architecture based as much as possible on recognized standards and best practices.

Documentation

• https://introlab.github.io/opentera/

What can OpenTera do for you?

In its essence, OpenTera provides an adaptable data structure on which you can base your developments. With its modular and service-based design, it is possible to tailor specific needs based on the OpenTera framework.

Applications of the OpenTera backend are not limited to research projects, and could also be applied in a clinical environment, where clinicians have to communicate with patients. Such fields include but are not limited to: tele-rehabilibation (physical, social, mental), robotic tele-operation and remote activity monitoring.

The OpenTera micro-services structure allows:

• Management of several sites, users, projects, participants, groups of participants, connected devices, sessions, data sources, assets in a structured manner.
  • We developed a Qt management tool called OpenTeraPlus, which is also under developement.
  • A web management interface will be developed in the future.
• Easy and secure deployment on any cloud, dedicated or embedded platform(such as a Raspberry Pi, AWS, Azure)
• Easy to use for elderly participants (no configuration, interfaces adapted to clients needs).
• Better collaboration / dissemination for open code.
• Support for several current and future research projects:
  • INTER - Tele-Actimetry: connected watches, portable capture devices.
  • INTER - Tele-Rehabilitation: videoconference, management of rehabilitation sessions for participants using tele-rehabilitation.
  • INTER - Active desk: Management of active desks and data visualization in the form of a dashboard.
  • INTER - OpenIMU, OpenIMU-MiniLogger: Capture, visualization and analysis of data from inertial measurement units.
  • AGEWELL (SMART, MOvIT+): Tele-presence and assistance of elderly people at home by a mobile robot, and power wheelchairs instrumentation and usage monitoring.

You are welcome to participate in this effort. Leave us comments or report Issues.

Authors

• Dominic Létourneau, ing. M.Sc.A., IntRoLab, Université de Sherbrooke (@doumdi)
• Simon Brière, ing. M.Sc.A., CDRV, Université de Sherbrooke (@sbriere)
• François Michaud, ing. Ph.D., IntRoLab, Université de Sherbrooke
• Michel Tousignant, pht, Ph.D., CDRV, Université de Sherbrooke

Contributors

• Philippe Arsenault
• Cédric Godin
• Marc-Antoine Maheux
• Cynthia Vilanova

Publication(s)

• Létourneau, D., Brière , S., et al., OpenTera: A Framework for Telehealth Applications, Journal of Open Source Software, vol. 8, no 91, p. 5497 (2023)
• Panchea, A.M., Létourneau, D., Brière, S. et al., OpenTera: A microservice architecture solution for rapid prototyping of robotic solutions to COVID-19 challenges in care facilities, Health Technol. 12, 583–596 (2022)

Videos

OpenTera Telehealth Platform

OpenTera+ Clinical Telehealth Software

Documentation and getting started

Detailled information is available in the docs

License

OpenTera is licensed under Apache License 2.0 .

Related Open Source Projects

General

• OpenTeraPlus Desktop Application
• OpenTera WebPortal Service

Robots

• WebRTC Native Libraries
• OpenTera WebRTC Libraries
• OpenTera WebRTC ROS Client and Nodes
• OpenTera Teleoperation Service
• OpenTera WebRTC Teleoperation Frontend

Dependencies

OpenTera is based or uses the following Open Source technologies :

• Python 3.8+, PSFL (BSD like)
• Flask, BSD
• Redis, BSD
• txredisapi, Apache License 2.0
• SQLAlchemy, MIT
• Twisted, MIT
• PostgreSQL, PostgreSQL License(MIT/BSD like)
• Node.js, Node license

Sponsors

opentera's Issues

BureauActif sample importer

Import sample data from bureau actif Raspberry Pi files for tests. Import using device API.

Implement device subtype in POST: user/devices

To add a subtype to a device, a specific API must currently be used.

It would be interesting to manage an id_subtype (or the whole device subtype) in a POST request at the user/devices API.

User API for TeraDeviceType

Currently, TeraDeviceType are hardcoded and there's no way to directly access or create new DeviceType.

A user API allowing to get, post and delete TeraDeviceType should be created.

API to get logged user information

Add /api/user/users?self that returns information on the current user.

VideoRehabService

Implementation of first VideoRehabService.

Attach devices to projects

Add an optional link between devices and projects allowing to filter devices / project.
Also attached to that is access to devices according to projects.

Create configuration tables for services (users, participants, devices)

• Might need to store configs for services also.
• optional : id_user, id_participant, id_device
• required: id_service
• JSON format
• optional date?
• local VS remote ?
• per PC?
• GUI for configuration, how to describe fields, scope ?

Update Device API for Assets and Devices

Add Assets and Devices in API.

Update Service API

Re-send invitation when user/participant/device is reconnected

VideoRehabService should re-send an invitation when a user/participant/device reconnects to the server if a session is active and part of the session.

Create user groups for access

Right now, site and project access are based on each users. That's fine when managing small-scale systems.

In larger scale systems, a user group level would be useful to quickly assign access to users when creating a new one, or to quickly change access to multiple users.

Make participant groups optional

Currently, participant groups are mandatory. However, in some projects, it might not be useful not to have to group participants.

This involves mainly setting the nullable flag to true and managing properly requests and access.

Update / insert participant doesn't encrypt password

When creating a new participant password or updating an existing password, the password isn't stored in an encrypted format in the database, causing problem when that participant tries to log in (and, of course, security issue).

Allow users to upload data in a session without a device

In the current implementation, data can be attached to a session only if related to a device.

However, in some use cases, it will be necessary that a user uploads data directly to a session without being related to a device (to upload data collected manually in a lab, for example).

An implementation should be provided for that, maybe by constructing a new database model (TeraUserData) and related API?

Add tables and APIs to trace users/participants/devices login attempts

At the moment, we only have a date in the TeraUser model for the last login. We should be able to view all login attempts from every users/participants/devices. This should be stored in a new table.

Service: Video Dispatch

Service to allow videoconference sessions between users and participants, where the participants are in a waiting room and where the user connects with the next user in line.

Event handling in websockets

Filter events before sending back to clients according to access level.

Refresh Token APIs

Add APIs to refresh tokens for user, device and participant without having to provide user - password.

Service Launcher

To simplify the launch of the server and to prevent timing issues, a service launcher should be implemented.
More specifically:

• System services should be automatically launched
• Services specified in the server config file (using TeraService.service_key) should be started as standalone processes.

Rework project and site access for TeraServer

Replace TeraProjectAccess and TeraSiteAccess with TeraServiceAccess with a "special" service TeraServer
Add roles when creating projects - sites
Add id_site, id_project in TeraServiceRole
Refactor TeraServiceProjectAccess to TeraServiceAccess

Participant should have dynamic tokens, limited permissions otherwise.

Add support for devices in session without associated participants

Manage shared devices (kits, robots) with multiple participants. Assets must have an id_participant and id_user fields to make sure we can track the associated assets when the device is unassigned.

Users can access devices associated to projects.

Participant API

Create /api/participant/* with the following basic requests (Get, post and delete, where appropriate):

• login
• logout
• devices
• sessions
• devices data
• participant (limited to self)

Translations (FR / EN)

Restrict cascade deletes instead of deleting

Currently, there's no restriction when deleting a participant, a session type, a device, a project, etc. This cause could issues as deletion are cascaded: everything related to that element will be deleted.

Instead of cascade deleting, deletion should be prevented:

• Adjust database models
• Adjust return values of API to provide more information why the deletion can't occur

API to query admins for projects / sites

Add an API request to query all admins for a specific site or a specific project, limited by user accessible.

Device Type Config and JSON Schema

A pattern similar to Service Configs should be implemented with device configs:

• Add a config_schema pattern in TeraDeviceType
• Check for valid configs when creating / updating device_config in TeraDevice

Download data (assets) by site and project

It is now possible to download data by session and participants. It would be useful to make backups or to archive data to directly download those assets by project and by site.

User preferences

Add the required database structure to handle user preferences by application.
Add the required API to create/update/delete user preferences.

SQLAlchemy error on POST: user/projectaccess when access = null

A SQLAlchemy occurs when posting a request to user/projectaccess when access is null, seemingly related to a badly formed relationship in the model (with session).

Allow devices to query associated participants (full info) via QueryDeviceParticipant API

If a device is onlineable and has associated participants, it can access the information of them (including token).

Service Management in OpenTera

Implement proper service management in OpenTera:

• Database support for service configuration
• Redis communication to set an uuid to a service using a specific key
• Custom access roles defined by services but managed in OpenTera

Make sure files are deleted when TeraSession/TeraDeviceData are deleted

Query on user/devices with an id_site not working

When querying devices for a specific site on the user API, id_site doesn't seem to have any effect on the returned data.

Pack session files in a directory with the session name when creating a zip file of the whole content of the session.

Use Flask-CORS for Cross-Origin Requests

Currently, CORS are managed by trapping the @after_request in an http request.

A Flask module (Flask-CORS) seems to manage that in a more clean way. Investigate and implement.

Create BureauActif simple service

With stand alone DB and API.

Server Version API

Implement an API call to get the current server version.
Also include OpenTeraPlus current version and the URL to download the latest version?

Allow admins to view active sessions

Admins should be able to "see" active sessions (and stop them?).

Remove Device-Type / Session-Type association

Review device API with that modification.
Default session type for a specific device type should be specified in the device config itself.

Add API UserQueryDeviceTypes + Tests

Device types are hard coded at the moment. We should be able to add any device type from the API (and the clients).

Tests should be added in tests/modules/FlaskModule/user.

Create FileTransferService

Need a service to manage files and assets.

User stats API

Make an API for users to allow querying of various stats by project, site, participant group, participants and sessions.

Add device subtype

Currently, "Device" is only defined by its type.

It could be useful to differentiate devices by models or specific type, in the case of a multi-device deployment. Since creating a different type each type could be less portable, a sub-type could implemented.

This could be stored in a table, allowing to create new device subtype. Or maybe simply a "device_infos" field in the t_devices table?

Add "system service" flag in TeraService and manage in API

Services with "system service" flag should not be queried or modified with the API.
Also add tests for user/service API.

Server events log

Events occurring on the server should be logged in the database and made user-accessible, to help debug and support a production server.

Allow users with project admin access to modify a device config

In the current implementation, to modify any device, user must have site admin access.

However, in the case where only the device config is modified, a user with project admin access should be allowed to execute that modification.

Investigate if it would be better to simply give full access to device modifications to a user with project admin access instead of site admin access.

Store date and time in UTC format in database

Currently, dates and times are not always stored in UTC in the database fields.
This could cause issues with timezones, as some of those times are set by the server, and not adjusted by the clients, thus always displayed with the server's timezone.
It should be client responsibility to adjust UTC times to local time.

Review multiple parameters management in all APIs

Initial design decision was made in all of the APIs so that only one "id" parameter could be used at once. However, some situations need to have more ids specified at the same time to have more specific data.

Currently, the parameters management are done using a simple "if...else" structure. This doesn't easily allow to cascade parameters.

A better implementation would be to use direct filters according to the parameters in the database, or to manage multiple lists, resulting in a cleaner implementation.

Implement DELETE in User: SiteAccess / ProjectAccess API

Currently, to remove an access to a user, we need to send a POST query with a "null" access into it.

It would be better to implement the DELETE query to remove an access.