Every year, many people suffer from impaired physical functions (strength, balance, and movement) because of a variety of reasons including neurological disorders, musculoskeletal pains (highly prevalent), surgeries, aging, unexpected injuries, and so on. This impaired population subsequently requires rehabilitation services (Reference Jurkiewicz, Marzolini and Oh1, Reference Nelson, Layne and Bernstein2). Meanwhile, the social and economic costs of not being at work due to illness and inability to work are also significant (Reference Lewis, Morris and Walsh3, Reference Jakobsen, Sundstrup and Brandt4).
Nowadays, patients go through a period of short-term illness rapidly and are discharged from hospitals faster than in the past. This is mainly due to the time constraints and economic considerations faced by today's healthcare organizations. However, many of these patients still require rehabilitation services to completely recover from illness. Furthermore, such services are often associated with substantial costs and the patients sometimes have to make multiple trips to the rehabilitation center during the treatment process (Reference Ferraris, Nerino, Chimienti, Fortino, Suzuki, Andreopoulos, Yuce, Hao and Gravina5). On the other hand, the capacity of rehabilitation services in primary care is limited due to human resources issues (Reference Miller, Stanley and Moore6). Today, it is very common to continue rehabilitation therapy at home, which is called home-based rehabilitation (HBR).
In recent years, many studies have focused on implementing HBR programs for a wide range of acute and chronic conditions including but not limited to cancer, stroke, cardiovascular disease, diabetes, and musculoskeletal disorders. The main challenge faced by many of the HBR programs is how accurately and adequately do the patients follow the orders and perform prescribed exercises at home in the absence of a therapist. Studies show that two thirds of patients do not properly perform exercises at home. Improper HBR activities may lead to postponed treatment outcomes and could worsen the condition or lead to re-injury over time (Reference Saraee, Singh and Hendron7, Reference Courneya, Friedenreich and Sela8). Fortunately, telerehabilitation systems have so far offered various solutions to overcome such issues.
Telerehabilitation can be broadly defined as the application of information and communication technologies to provide rehabilitation therapy to remote people (Reference Staszuk, Wiatrak, Tadeusiewicz, Karuga-Kuźniewska and Rybak9–Reference Cotelli, Manenti and Brambilla11). In order to address HBR programs, a variety of systems have been designed with different approaches, purposes, and capabilities enhanced with a variety of sensors, virtual reality technologies, robots, and motion detection tools such as Kinect, Lip Motion, Nintendo Wii, and so on. In the current study, all of these systems are briefly called home-based telerehabilitation systems or HBTR systems.
Studying HBTR systems from the technical point of view provides us with better insights and helps to improve such systems in the future. Several reviews have been carried out on the HBTR systems covering different aspects (Reference Reeder, Chung and Stevens-Lapsley12–Reference Miller, Adair and Pearce14). However, to the best of our knowledge, there has been no research that has reviewed functional features of HBTR software systems developed to remotely supervise HBR programs. Remote supervising in this context is referred to as the opportunity of giving/getting feedback to/from patients and to manage rehabilitation therapy from remote.
We aimed to conduct a systematic review of the HBTR software systems designed and used in the literature during the last decade. Specific objectives included: (a) to identify the scope of the HBTR software systems employed by the literature in the recent decade about remotely supervise HBR programs; and (b) to identify functional features of such systems and to outline common functionalities shared among these systems.
Materials and Methods
The review process followed the PRISMA guideline (Reference Moher, Liberati, Tetzlaff and Altman15).
Data Sources and Search Strategy
Searches for papers written in English, from January 2008 to February 2018, were conducted using Scopus, PubMed, EMBASE, ISI Web of Science (Core Collection), Cochrane Library, IEEE Xplore Digital Library, and ProQuest databases. In addition, the reference lists of all included studies were checked. Google Scholar was also searched for additional literature.
We prepared the search terms using the PICO approach (see Supplementary Table 1). As the search aimed to be sensitive and exhaustive, we employed a search strategy combining search terms for population (e.g., home combined with rehabilitation, physiotherapy, exercise therapy, physical therapy, kinesiotherapy, physical activit*, exercise train*) and interventions (e.g., supervis*, telesupervis*, tele supervis*, monitoring, telemonitoring, tele monitoring, telerehabilitation, tele rehabilitation combined with system, software, apps, application, online, on-line, web base*, Internet, mobile, phone, telephone, cellphone, smartphone, tablet, personal digital assistant). We also used MeSH and Emtree indexed keywords in PubMed and EMBASE, respectively (see Supplementary Table 2).
Study Selection
Inclusion criteria:
(1) Given the aim of this study, which was to review HBTR software systems for remote supervision, the target population was considered to be all individuals who remotely receive rehabilitation services through a software system.
(2) According to the aim of this study, in order to comprehensively review functional features of the HBTR software systems for remote supervision reported by the last decade published literature, studies using any design methods and with any outcomes using specified qualitative or quantitative measures (validated or not) were included.
Exclusion criteria:
(1) We considered remote supervision as telecommunication with patients, giving and/or getting therapeutic feedback, and remote control of the HBR program. Therefore, HBTR software systems without telecommunications, remote feedback, and HBR control, were excluded.
(2) A software system is fundamentally different from a hardware system in terms of structure and characteristics, design, implementation, and evaluation processes. Therefore, in the current study, we focused solely on HBTR software systems. The studies that investigated hardware systems such as robots, rehabilitation tools/devices, and sensors were excluded. However, studies that used such systems/technologies alongside an HBTR software system as a part of the system were included.
(3) Because we aimed to review HBTR software systems, general-purpose software including video conferencing tools, games, and health apps available on the market were excluded. This type of software is not only used for HBR programs, but also used for any other purposes. However, studies that used such tools alongside an HBTR software system to improve remote supervision were included.
After removing duplicates, three of the authors independently screened records based on titles and abstracts and then marked irrelevant records. A record would be excluded if it marked by at least two of the reviewers. All remaining papers were further investigated through their full-text for excluding the irrelevant studies. Disagreements were resolved through review team discussion.
Data Extraction and Analysis
All extracted data were entered into the included studies summary table. Demographic data and technical information were extracted from the included studies. Data extracted from each eligible study include study design, sample size, comparison if used by the study, primary outcome, outcome measure, health problem targeted by the study, type of feedback provided by the system, and the system functional features. The data were extracted by a purpose-made electronic form containing all the above-mentioned items.
Data analysis started with an overview of the study and functional features of the HBTR software system followed by the tabulation of extracted data. Due to the heterogeneous nature of the functionalities across the HBTR software systems, a narrative approach was used to synthesize the data. The functional features of an HBTR software system were narratively extracted according to the act of the system. Similar features were put into a category as a representative of the overall functionality. The categories were not pre-existing but the thematic synthesis was undertaken to make each category as follows.
All features that expressed how to manage rehabilitation exercises including creating exercises, changing exercise parameters (e.g., frequency, duration, and speed), adding or removing exercises from the HBR program named “Exercise plan management”; any kind of tasks or activities scheduling in the system considered as “Task scheduling”; any kind of data statistics, reports, and analysis provided by the system titled “Report/statistics generation”; any type of patient training and instructions whether in visual, textual, video, or guideline format called “Patient education”; managing user accounts and the data access rights named “User control”; text/voice messaging titled “Message transferring”; recording rehabilitation activities/exercises by patients in audio, image, or video format to provide a treatment feedback considered as “Exercise recording”; video communication through the system called “videoconferencing”; any type of patient-to-patient communications through the system whether in video, audio, or text messages or sharing/publishing experience and general posts named “Virtual community”; patient's connections with other therapists or therapist-to-therapist communications for treatment purposes considered as “Tele-consultation”; and finally, any kind of therapist recorded notes about the patient treatment process named “Recording clinical notes.”
For an easier referral and analysis of the data, all included studies and reported systems have been numbered separately. Throughout this study, references to the studies and the systems will be made according to these numbers.
Because the aim of this study was to systematically review and comprehensively scope the functional features of the HBTR software systems reported by the literature of the recent decade, the quality assessment of the included studies was not carried out. However, we categorized the studies based on study design into four categories in order to report the types of studies conducted in this field since the last decade (see Supplementary Table 3). In this review, we didn't aim to evaluate the impact/effectiveness of reviewed systems or quality of the included studies or to draw any conclusion or generalization based on these studies. Our main focus was placed on identifying functional features of the HBTR software systems and reporting the status of such systems during the last decade.
Results
The search retrieved 4,172 records initially. After a stepwise process of screening titles, abstract, and then full-text articles against the defined eligibility criteria, we identified forty-seven studies to be included. The included studies reported on twenty-two discrete HBTR software systems (see Figure 1). In most cases, a system was reported by several studies, for example, system 1 was reported by ten out of forty-seven (21 percent) studies (see Table 1).
Figure 1. Study selection (PRISMA diagram).
Table 1. Summary of included studies
N/A, not applicable; SF-36, 36-item short-form; CES-D, Center for Epidemiologic Studies Depression Scale; LEFS, Lower Extremity Functional Scale; YPAS, Yale Physical Activity Survey; CSQ-8, Client Satisfaction Questionnaire; MS, multiple sclerosis; ABI, acquired brain injury; SCI, spinal cord injury; DS, Down's syndrome; MMSE, Mini Mental State Examination; BMI, modified Barthel index; BBS, Berg Balance Scale; T25FW, timed 25-foot walk; 6MWT, 6-min walk test; MOS, medical outcomes study patient adherence measure; LLFDI, Jette Late Life Functional and Disability Instrument; SUS, System Usability Scale; MSWS-12, 12-Item MS Walking Scale; MAS, Modified Ashworth Scale; MSSE, MS Self-Efficacy Scale; FM, Fugl–Meyer; COPD, chronic obstructive pulmonary disease; ARAT, Action Research Arm Test; 6MWD, 6-min walking distance; CAT, COPD assessment test; EQ-5D, EuroQol 5 dimensions; CPX, conventional cardiac exercise; CCR, conventional cardiac rehabilitation; CAD, coronary artery disease; VO2 peak, peak oxygen uptake.
Overview of Included Studies
Overall, the included studies covered 1,139 people. Twenty-four out of forty-seven (51 percent) studies recruited patients; eleven (23 percent) studies addressed healthy people, and five out of forty-seven (11 percent) included both patients and healthy people and reported related outcomes. Testing the system prototype was the most prevalent subject, carried out by 28 percent of the studies. We grouped studies into five categories according to health conditions including musculoskeletal system and connective tissue-related conditions (studies 1–13); nervous system and sense organ-related conditions (studies 14–31); respiratory system-related conditions (studies 32–37); cardiovascular system-related conditions (studies 38–42); and general health-related conditions such as aging people fitness and strengthening exercises (studies 43–47). Nine HBTR software systems (systems 1, and 8–15) reported by twenty-five out of forty-seven studies, were designed for neurological conditions. Of these, system 1 could be used for musculoskeletal (studies 1–6) and strengthening exercises (study 43) as well. Stroke (six out of eighteen studies) and multiple sclerosis (six out of eighteen studies) were the most frequent health problems targeted by two thirds of the systems. All systems in the respiratory conditions category were designed for chronic obstructive pulmonary disease (COPD). Among the systems reported for multiple health problems (e.g., systems 1, 2, 10, and 16), system 1 was the only system that addressed the health conditions of multiple categories. The other systems were mainly used only for the health problems of a specific category.
Study Design and Study Aims
We categorized study designs broadly into four types as follows (see Supplementary Table 3):
• Effectiveness (or efficacy) studies (eight studies, 17 percent) including randomized controlled trials (RCTs) and quasi-experimental studies. These studies aimed to establish the HBTR software systems' effectiveness for patient outcomes comparing to other types of care received (such as usual care and conventional rehabilitation therapy or support) (e.g., studies 14 and 32).
• Evaluation studies (seven studies, 15 percent) including non-randomized, uncontrolled, or single-group before–after studies. These studies tended to pilot-test the HBTR software systems' effectiveness for pre-specified patient outcomes within a group of patients (e.g., studies 6 and 18).
• Feasibility or usability studies (ten studies, 21 percent) including post-use surveys or studies evaluating the usability of the HBTR software system. This group of studies aimed to establish the ease of use and perceived acceptability of the HBTR software systems (e.g., studies 10 and 27).
• Other studies (twenty-two studies, 47 percent) included mixed-method studies that reported documentation of the development process or description and pilot-testing of an HBTR software system or its prototype. Using questionnaires and/or interviews to collect users' feedback were examples of studies commonly employed in this category (e.g., studies 2 and 24).
Study Outcomes and Measures
The outcomes reported by the included studies varied widely and different measures/tools were used as well. The objective of these studies varied across the four main categories of study designs. Regarding the outcome, there were five main types including usability and acceptability (e.g., satisfaction, ease of use, and acceptance), clinical/patient outcomes, performance of the HBTR system, system description/development process documenting, and patients' adherence (e.g., usage rate and/or motivation for using system) which were respectively reported by twenty, twenty, thirteen, eight, and twelve out of forty-seven studies. Although some studies had considered various outcomes, 55 percent of reviewed studies reported only outcomes of a kind such as clinical/patient outcomes (six out of forty-seven studies; e.g., studies 14, 20, and 34), usability and acceptability (four out of forty-seven studies; e.g., studies 10, 17, and 30), performance or function of designed system (eleven out of forty-seven studies; e.g., studies 2, 7, and 26), and development process of or description of the system (five out of forty-seven studies; e.g., studies 9, 29, and 42). However, usability and user satisfaction and clinical/patient outcomes which each established by twenty out of forty-seven studies were the most common outcomes reported by included studies. The data analysis, system analysis, and the system usability scale tool were the most commonly used measures/tools across reviewed studies, addressed by twenty-two, seven, and six out of forty-seven studies, respectively.
Effectiveness/efficacy studies had reported both usability and satisfaction and clinical/patient outcomes almost equally, which were addressed by five and six studies, respectively. Of these, studies 14, 33, and 39 were carried out only on clinical/patient outcomes. The measures used in these studies varied widely and each study used outcome-specific tools. For example, using peak oxygen uptake (VO2peak), EQ5D, and HADS; and Jette Late Life Functional and Disability Instrument (LLFDI) to respectively measure MI (study 44) or stroke (study 16) patient outcomes.
Evaluation studies (e.g., studies 6, 19, and 40) also commonly reported clinical/patient outcomes. Seven studies (1, 6, 18, 20, 25, 37, and 38) reported clinical/patient outcomes. From these studies, five also reported other outcomes such as usability and satisfaction (studies 1, 6, and 18) and patient adherence or usage of the HBTR system (studies 25 and 37).
Feasibility and usability studies had focused more on usability and satisfaction outcomes (eight out of forty-seven studies) compared to the other types of study designs. The pre-intervention/baseline measurements were often not considered in feasibility/usability studies. Instead, these studies primarily aimed to establish the perceived acceptability or user satisfaction in using the HBTR system (eight out of ten feasibility/usability studies) through questionnaires or analysis of usage data (e.g., studies 10, 16, and 35). The questionnaire was commonly used to glean insight into the usability, usefulness, utility, likeability, acceptability of the HBTR system, and how patients used it in a real-life context.
Finally, studies using mixed methods not fitting any of the above categories were grouped into the fourth category called “other studies.” These studies (e.g., studies 2, 7, 19, and 28) had commonly documented the development process, description, and initial testing of the HBTR system (system prototype). In these studies, the most important consideration was the performance of the systems (reported in thirteen out of twenty-two studies). In this sense, the system users were frequently involved in the system development process. Five out of twenty-two studies (23 percent) had merely described or documented the system development process.
HBTR Software Systems
Overall, twenty-two unique HBTR software systems for remote supervision of the HBR programs were reported by the included studies (see Table 2). The majority of these systems provided patients and therapists with real-time (nineteen out of twenty-two systems; systems 1–11, 13–16, 18–20, and 22) and periodic feedback (seventeen out of twenty-two systems; systems 2, 4–8, 10–12, 14–18, and 20–22) respectively. Systems 12, 16, and 21 provided the patients with periodic feedback. Of these, system 16 also addressed real-time feedback. In system 17, the type of feedback provided to the patients was unclear. The only systems that provided therapists with real-time feedback were systems 3 and 18. System 18 could also provide periodic feedback. However, the way in which systems 1, 9, 13, and 19 provided the therapists with feedback was unclear. Twenty-seven percent of the systems were capable of providing reminders and alerts to the users.
Table 2. Features of the included HBTR software systems
N/S, not specified; R, real-time; P, periodic; MS, multiple sclerosis; ABI, acquired brain injury; SCI, spinal cord injuries; DS, Down's syndrome; COPD, chronic obstructive pulmonary disease; CAD, coronary artery disease.
In terms of patient data collection (here we considered questionnaires or video recording as manual and vital signs or movement detectors as automatic data collectors), there were fourteen automatic data collecting systems (systems 1–6, 8, 9, 14, 15, 18, and 20–22) and three were manual (systems 12, 13, and 17). Motion sensors and accelerometers were used in the majority (84 percent) of the automatic data collection systems. Five systems (systems 7, 10, 11, 16, and 19) collected patient data both automatically and manually. In order to check the progress of the HBR program remotely by the therapist, logs of activities recorded by the system (activities performed by the patient using the HBTR system) were used in twenty out of twenty-two systems. Seven of these systems also employed other methods such as system-provided questionnaires or checklists, which were answered by the patients often after each task's completion (systems 7, 10, 16, 19, and 21), video recording or image capturing (system 11), remote (systems 9 and 10), or face-to-face (system 10) visits. However, in systems 12 and 17, this was merely addressed by the system-provided questionnaires.
The type of communication in 23 percent of the systems (five out of twenty-two systems) was store-and-forward, in 36 percent of the systems (eight out of twenty-two systems) communication was online. Approximately 41 percent of the systems (nine out of twenty-two systems) were able to communicate both online and store-and-forward. The transferred data format in 58 percent of the systems was textual (including data from the questionnaire, motion sensors, and vital signs data, logs of the system, and exchanged text messages).
Functional Features of HBTR Software Systems
Overall, eleven functional features were obtained from HBTR software systems reported in the literature of the last decade. This includes exercise plan management, report/statistics generation, patient education, message transferring, task scheduling, user control, clinical note recording, videoconferencing, exercise recoding, teleconsultation, and virtual community.
Although the methods of managing exercises and reporting varied widely across reviewed HBTR software systems, all of these systems had somehow managed the rehabilitation exercises by adding, removing, or changing exercises or modifying the exercise parameters, for example, frequency, duration, and degree of difficulty as well as providing the required statistics and reports. The next most commonly used feature was providing patients with treatment education, employed by fifteen out of twenty-two (68 percent) reviewed systems (systems 1, 3, 5–14, 16, 21, and 22). However, other features were considered by less than one third of the reported systems. Transferring audio/text messages through the system (systems 1, 7, 10, 15, 16, 18, and 21), scheduling tasks (systems 2, 8, 13, 16, 18, 19, and 21), and user control (systems 3, 7, 12–15, and 18) were each used by 32 percent of the systems. Providing video communication was considered in four out of twenty-two systems, three of which (systems 8, 9, and 10) were deployed for neurological conditions and one (system 18) for COPD in the respiratory diseases category (see Table 3). The ability to record clinical notes by the therapists (used by systems 8 and 20) and exercises by the patients (employed by systems 10 and 11) as well as sharing experiences and communicating with other users through the system (systems 20 and 21) were each considered by only 9 percent of the HBTR software systems. The only system that provided teleconsultation was system 16. Two categories, that is, neurologic and respiratory categories were the richest in terms of functional features that respectively 82 percent and 73 percent of the acquired functional features employed by systems were in these two domains.
Table 3. Functional features addressed by the HBTR software systems according to the health problem categories
a One duplicated system (system 1 from musculoskeletal category).
Discussion
To the best of our knowledge, this is the first systematic review about the HBTR software systems for remote supervising focusing on functional features with a broad range of the HBR programs. The conducted search was comprehensive of 4,172 records. We identified and included fifty papers, which reported twenty-two unique HBTR software systems. The number of papers published during the last decade, especially that 64 percent of studies published in the last 5 years suggests that the HBTR software systems for remote supervision of HBR programs are growing rapidly. Overall, eight studies were seeking to test the effectiveness or efficacy of such systems; the remaining studies (83 percent) primarily used uncontrolled designs, investigating on evaluations, feasibility, and acceptability of the HBTR software systems, or descriptions of these systems' development. This all suggests that although fast-evolving, the field is still in its infancy and the main focus of researches placed on system innovation and usability evaluation.
Considering the fact that the HBR programs are an integral part of today's rehabilitation therapy (Reference Horton, Mitchell and Johnson-Warrington62–Reference Turunen, Salpakoski and Edgren64) and given that the treatment is carried out through regular therapeutic exercises (Reference Hageman, Fokkenrood, Gommans, van den Houten and Teijink65, Reference Aytekin, Caglar and Ozgonenel66), which are required to be performed properly (Reference Halic, Kockara, Demirel, Willey and Eichelberger25, Reference Pani, Barabino and Dessì67), the majority of systems reviewed were primarily developed for treatment and education. However, system innovation seems not to be the same in different health areas. For example, in neurological and respiratory rehabilitation fields more complete systems have been introduced compared to other areas. It could be due to the nature of targeted health problems as well as the domain and/or users (e.g., patients and therapists) related requirements. Such requirements are an integral part of software system design and critical to the success of interactive systems (Reference Kujala, Kauppinen, Lehtola and Kojo68, Reference Maguire and Bevan69). There are some differences among reviewed HBTR software systems in terms of employing some functional features. These features were mainly established by less than one third of the systems. This difference may also be concerned with the domain-related issues and/or the user-specific requirements.
In addition to the three most common functional features (exercise plan management, reporting, and patient education), there were also many similarities in systems reviewed in terms of data collection methods (automatically data collection established by more than 85 percent of the systems), recording the progress of patient treatment (using log of activities employed by 90 percent of the systems), and respectively providing therapist and patient with periodic (more than three quarters of the systems) and real-time (more than 85 percent of the systems) feedback. Contrary to the observed differences in reviewed systems, the similarities may be due to the purpose of these systems, which is remotely supervising of the HBR program. In other words, it may be possible to derive a set of functional features from the commonalities seen in the majority of these systems in order to design a general-purpose system capable of supervising a variety of HBR programs.
Automatic patient data collection could be an advantage for an HBTR software system in terms of the accuracy and simplicity of the data gathering process. On the other hand, providing the therapist with periodic feedback could address the time constraints. Concerning patient education, providing patients with real-time feedback could be helpful to avoid possible mistakes made by patients although doing rehabilitation exercises at home. Moreover, using the patient's activities recorded by the system could be fairly good for tracking treatment progress and/or patient's performance. However, this is suggested by the extent to which these features are employed by systems reviewed and further studies are needed in this field.
Strengths and Limitations
This review was conducted according to PRISMA guidelines. We included all study designs in order to comprehensively scope the HBTR software systems for remote supervision of HBR programs. In this review, the main focus was placed on the functional features of these systems, which helps to better understand what such systems do in order to remotely supervise HBR programs. We also synthesized the data in cross tables which facilitates comparison. However, as the review solely included papers written in English, publications in other languages were omitted, which might affect the results. Also, HBTR software systems designed and developed may not have been reported as a scientific study (e.g., systems used in clinical settings). This is a well-known phenomenon in a field, which is driven arguably by commercial or real-world developers as opposed to academic or clinical researchers (Reference Kumar, Nilsen and Abernethy70–Reference Meurk, Leung, Hall, Head and Whiteford72). In this review, we extracted the functional features of the HBTR software systems reported by the literature, highlighting the similarities and differences between these systems. However, the necessity of each of these features could not be explained by this study.
Future Directions
This review extracted functional features of the HBTR software systems and outlined their similarities. However, more research is needed to better understand such systems, their functionalities, and the effectiveness of such functionalities on patient's treatment outcomes. It is therefore recommended that this research is taken to the next level, which could include studying the hardware and device required by an HBTR software system, real-world implemented systems, structure, and effects of these systems in real-world settings. This could be a major step forward in designing a comprehensive HBTR software system incorporating features obtained in such studies, which beyond health issues could be used for a wide variety of patients and scenarios.
Conclusion
Overall, the review of HBTR software systems aiming remote supervising of HBR programs reported by the literature indicates that these systems share more or less common functionalities promising comprehensive HBTR systems. However, research within this field is still in its infancy. A better understanding of such systems could enhance the optimal design of HBTR systems leading to improved HBR programs and facilitated remote supervision.
Supplementary material
The supplementary material for this article can be found at https://doi.org/10.1017/S0266462320000021.
Acknowledgments
The authors wish to acknowledge the clinical research development center of Rofeideh rehabilitation hospital.
Conflict of interest
The authors have nothing to disclose.
