Authors: Kalpana S Mair (B.P.T), Sushrut J Mair.

In these series of articles we would like to present and discuss a modular physical therapy biofeedback platform developed by us, which, in our opinion, can be an invaluable daily practice tool for therapists. The platform has been prototyped using the latest mature and proven technologies in the field of electronics and mobile device software. This is the fourth article where we discuss feedback by users received from the field and new features we brought in to address those.

Other articles in this series: Article 1, Article 2, Article 3.

It is emerging that (at least as of now), there are two major classes of users for this platform. One group is physical therapists who have their own setup (clinical as well as home care) — we can bundle them into private practice. Another major group is academia — medical education institutions who would want to use the system to gather data for research, invest into analysis of that data resulting into more refined protocols for treatment.

We’ve been collecting a lot of feedback from both set’s of user groups for a while now and have a nice refined list of changes that would help them do their job more effectively. We had an exercise with the users to prioritize this list to understand what’s most important and targeted those for inclusion in refining the overall system prototype. We discuss these new features below:

Faster ( ‘real-time’ ) live updates on the therapy screen graphs — this has, admittedly, been on our own radar for sometime now. The issue was that there was a discernable delay between the patient acting on the sensor, and then the live therapy screen graph being able to show the change in reading following that patient action. The typical human sense in such situations is that any delay of more than a few hundred milliseconds is visible and can result in a jarring experience. Let’s look at what happens when the patient acts on any sensor connected to the base system. First, the base box detects the sensor’s change from its steady state. Internally, in the base box, the embedded software maintains a moving average of the sensor’s readings and sends the moving average via Bluetooth to the SVPT app on the mobile phone at an extremely fast rate. The app in turn grabs these readings and sends them to the live graph for updation. Before updation, though, the app buffers a few readings in order to limit the UI update frequency. Too frequent redraws of the UI can cause other problems. It was this buffering and time taken to pass the buffered sensor data to the UI update component that contributed to the delay. The fix was to remove the buffering and put in a more robust messaging infrastructure between the non-UI and UI components. After extensive testing, the fix was validated and now the delay is down to a reasonable level and is ‘real-time’ enough so that the viewers have no jarring experiences.

— this has, admittedly, been on our own radar for sometime now. The issue was that there was a discernable delay between the patient acting on the sensor, and then the live therapy screen graph being able to show the change in reading following that patient action. The typical human sense in such situations is that any delay of more than a few hundred milliseconds is visible and can result in a jarring experience. Let’s look at what happens when the patient acts on any sensor connected to the base system. First, the base box detects the sensor’s change from its steady state. Internally, in the base box, the embedded software maintains a moving average of the sensor’s readings and sends the moving average via Bluetooth to the SVPT app on the mobile phone at an extremely fast rate. The app in turn grabs these readings and sends them to the live graph for updation. Before updation, though, the app buffers a few readings in order to limit the UI update frequency. Too frequent redraws of the UI can cause other problems. It was this buffering and time taken to pass the buffered sensor data to the UI update component that contributed to the delay. The fix was to remove the buffering and put in a more robust messaging infrastructure between the non-UI and UI components. After extensive testing, the fix was validated and now the delay is down to a reasonable level and is ‘real-time’ enough so that the viewers have no jarring experiences. In place single bar graph for live therapy screen — As you may have seen in the videos posted on earlier articles, a live therapy screen showed upto 10 individual bars in a single graph window. Here is the earlier graph (to see the live therapy graph, jump to 41 seconds if the video starts from the beginning):

The concern from users here was that while it was decent enough, too many data points in the graph may end confusing patients and even physical therapists who weren’t used to it. The request was to have a single bar in the graph and have it update in-place so that the experience is more tuned to usability norms. This change was brought in and the new in therapy live graph now is shown in the embedded video below. We too feel that this is much more intuitive and understandable than the earlier version.

Cloud integration for recorded data and settings — We’ve touched upon the centrality and importance of the data generated by SVPT in previous articles. A future article is going to discuss the possibilities that open up due to such data being available. But, in order for anything to be practically possible, the data needs to be available in a central location. Only then can analytics be run on it. And only after the analytics are done, can the benefits be pushed back to the physical therapists. As an added benefit, cloud integration can also offer backup functionality for users. If they lose their data, the cloud integration ensures that a backup is available for them to go back to. So, we built in cloud integration and it is working well in functional testing right now. We are in the middle of running persistence and performance tests to ensure that it survives the rigors of the field. The cloud integration follows the typical guidelines given in most quality IoT (Internet of Things) architectures. Here is a pictorial view of the integration:

The cloud integration requires absolutely no intervention by the users and runs silently in the background. It is highly secure, sensitive to optimal data usage and is not intrusive in any way. This feature now allows us to view data from various endpoints in the field and also use the integration as a remote system diagnosis mechanism, if needed.

This post was focussed on providing an update of the new features and thus has very little technical depth. Future posts will delve into deep technical discussions for readers who are interested and the above changes shall also be discussed. We hope you have enjoyed following with us so far — please do leave your comments and queries and let us know what you think! There are more articles coming up that talk about other and more internal aspects of the SVPT platform. Stay tuned!