The Software Interface Behind The Hardware Devices – μVEMP

A common theme of the projects I’ve worked on is to use novel solutions to solve complex problems. In the medical field, with some testing equipment costing well into the six-figure range, a point of focus is to develop innovative ways to solve complex problems that also reduce cost.

The μVEMP (μ as in “micro-VEMP” or “you-VEMP”) is a portable device to measure Vestibular Evoked Myogenic Potentials (VEMPs). In layman’s terms, it’s another device a clinician can use in diagnosing a patient with balance issues – more on this later.

The general concept is to measure vestibular function using very weak electrical signals through electrodes placed on the patient. There are some similarities with an electrocardiogram (ECG), although with an ECG the signals are very strong in comparison, and the test is relatively old compared to VEMPs. So given this, the VEMPs test takes careful thought and high precision to pull off – this is one reason why commercial options are so expensive.

Lab grade equipment in your pocket

To approach many of these highly complex research and medical tests, we utilise the power of smartphone technology to lower the testing costs involved. Based on recent data¹ there over 3.5 billion smartphones users in the world. Smartphones are also great for those who don’t have access to a computer and of course, provide great convenience and portability. Given this, smartphones offer a great solution for making these incredibly important tests highly accessible.

Our implementation, called μVEMP, comprises two components: a small low-cost hardware device, which interfaces with electrodes and stimulus devices, and a device like a smartphone, tablet or PC to log the data. With the hardware side sorted and a PC test application verifying that our test worked² the next big step was to develop the smartphone application.

Originally our smartphone applications were designed for iOS devices as many medical folks like to use these devices. Unfortunately, we reached a point where it was becoming impossible to develop on this platform. This problem started when we wanted to develop several Bluetooth applications, but due to arbitrary restrictions on Apple devices we had to jailbreak our phones to allow for the Bluetooth functionality we needed. This created a problem for distributing the application, because the end-user couldn’t do the jailbreak, so for a while we actually resorted to mailing out Apple iPhones that were already jailbroken.

To solve this issue, I helped advocate for and migrate our applications to Android. This was a good solution for us, as the open-source nature of Android allowed us to fully utilise the potential of the smartphone. It also meant a wider range of devices were supported and made lower-cost devices available to the end-user. In the case of μVEMP, developing an iOS application would have been practically impossible as μVEMP requires USB serial support which, without special tools (think $$$) from Apple, is impossible. Also for the reasons above, we wanted to move away from jailbreaking, as that wasn’t a good option either.

Application design – context matters

When designing applications it is important that you design them with a context in mind. As a developer, it is all too easy to fall into the trap of thinking that you are building the application for yourself, making decisions that appeal to the developer rather than the end-user. This may seem obvious, but it is harder to create a user experience that is congruent with their work context.

In application design, contextual choices are made by observing how the application is used in practice. In my case, I follow this practice by assuming the role of the patient. The clinician then conducts the test on me. This allows me to record valuable data that is used to make critical design decisions. Plus being the guinea pig sensitises you to potential ethical (or pain) issues.

Subject entry screen

In the μVEMP smartphone application we divide the test into three parts; enter, test and analysis. When the clinician starts the application they begin on the subject entry screen where they can enter the subject’s information and specify the test they want to conduct. In later apps I designed a sophisticated database that allows the app to remember patients and manage test history. One design choice made on this screen is the “Max sweeps” field which prevents the clinician from accidentally delivering too much of the stimulus to a patient. Another noteworthy mention is that the “Subject ID” field is a string not an int. This is done because clinicians often want to enter their own unique identifier.

Interestingly enough, on the applications that I developed database systems for, there are actually two subject IDs, one for the clinician to use and a second for the database entry.

This is a good example of contextual design. Any database designer will tell you that unique identifiers have to be unique! But we are not designing our app for the database designer, we are developing our app for the clinician and the clinician will find a reason why they want to use the same subject ID twice.

Having two subject IDs solves this problem as the application has the required unique ID to store subjects in the database (which is autogenerated and the clinician never sees) and the clinician gets their own ID with which they can insert whatever they please.

Clinical Testing

In the clinical setting, μVEMP is used to measure a patient’s VEMP responses. VEMPs (Vestibular-evoked myogenic potentials) are small impulses detectable by surface electrodes positioned on the patient beneath the eye. The μVEMP uses custom hardware to take biopotential measurements. This device is powered from smartphones’ USB-OTG capabilities and thus requires no internal battery.

Before testing can begin, the clinician needs to place the electrodes on the patient. There is a special ohms mode in the app that allows the clinician to ensure the electrodes are making good contact.

Subject test screen showing background noise

The test can only be started after the hardware device is detected by the app. Once on the test screen, the test settings from the entry screen are used to determine what test the clinician wants to perform. On the bottom of the test screen we display the test currently active to help remind the clinician which test they are on. We do this as we found it was easy for them to lose track.

The hardware device samples at 4 KHz per channel and records 100ms of data. The trace is displayed live and constantly stores 20ms of data, retaining the last 20ms prior to the stimulus delivery, and then adding 80ms of data post stimulus.

The test includes two methods for delivering the stimulus: Air-conducted sound (ACS) delivered via headphones, and bone-conducted vibration (BCV) delivered via a modified tendon hammer. Each stimulus is repeated multiple times and the resulting traces are processed and combined into a single trace to remove noise and yield a signal that can be interpreted by the clinician to assess the function of the otolithic organs.

The tendon hammer is modified to include an accelerometer to provide feedback in the form of a green light to ensure the force of the taps is of appropriate magnitude.

Analysis in your pocket

Analysis screen showing background noise

The power of this system is that all analyses can be performed on the clinician’s smartphone and a pdf report generated. In the analysis screen the average traces for the two channels are displayed along with markers for the peak and trough and a table displaying calculations. The clinician uses these results to help diagnose vestibular problems.

Note that the traces displayed in these screenshots are just background noise as I did not have any electrodes attached. if you’re interested in the clinical aspects, see MacDougall et al², which provides data from patients used in the validation study.

For the pdf generation on Android applications, the approach used by many programmers to insert figures (e.g., graphs) is to paste a bitmap image into the pdf. For projects like this that use graphing libraries, it is quickly clear that there is no easy way to generate a bitmap of the graph. The hot-fix solution that is often used is to just screenshot the portion of the UI in the app that contains the graph and insert this into the pdf. However, that leads to blurry images and with changes in screen resolution and aspect ratio the image doesn’t get cropped correctly (i.e., it is cut off).

Eventually, I ended up rolling my own solution which uses vector graphics to recreate the graph in the pdf. The benefit of this is you can zoom into the pdf as far as you want and the graphs still look amazingly sharp.

Final Thoughts

Building the μVEMP android application was really satisfying for me. As this application had to interface with our own inhouse developed and built hardware we did have those early challenges getting everything to play nice together. This is something that you don’t appreciate much until you’ve worked on a lot of hardware/software interface projects.

The most gratifying part of projects like this is seeing them improve the lives of patients. Reflecting on this project the only thing I would change is to implement the database system I had later envisaged. This is mainly because it allows us to do further research using data collected from different clinics. And also the way I built the database is just really cool.


²MacDougall HG, Holden J, Rosengren SM, Chiarovano E. μVEMP: A Portable Interface to Record Vestibular Evoked Myogenic Potentials (VEMPs) With a Smart Phone or Tablet. Front Neurol. 2018;9:543. Published 2018 Jul 5. doi:10.3389/fneur.2018.00543

Leave a Reply