The Oura Ring - Sync Delays and Limited Developer Interface
In the landscape of wearable technology, the Oura Ring has emerged as a compact and sophisticated device, offering a range of health monitoring features. However, its application in emergency monitoring and death detection is limited. Here, we explore the pros and cons of using the Oura Ring for these critical applications. The Oura developer documentation can be found here.
Pros of the Oura Ring
1. Ease of Wear: The Oura Ring's sleek and minimalist design makes it an unobtrusive wearable. Unlike bulkier devices, it can be worn continuously without discomfort, making it ideal for long-term health monitoring.
2. Long Battery Life: One of the significant advantages of the Oura Ring is its extended battery life. With normal use it lasts at least 3 days.
3. Accuracy in Health Data: The ring is lauded for its precision in tracking health metrics, especially in sleep tracking. It also has high accuracy on heart rate, temperature, and activity levels. Reliable data is paramount in emergency situations for making informed decisions.
4. Multiple Types of Health Data: Beyond basic metrics, the Oura Ring provides a comprehensive overview of the user's health, including sleep patterns and readiness scores, offering a holistic view crucial in emergency health scenarios.
Cons of the Oura Ring (For Monitoring)
1. Limited Developer Interface
For developers, the limited access to data is a significant drawback. Short-comings include: lack of raw data access, inability to determine if the ring is within bluetooth range, and the absence of power status indicators. These limitations yield false positive and in some cases false negative alarms.
Something that needs to be pointed out is that wearable systems generally, including Oura in particular, do not create entries that say “pulse: 0” or “bpm: 0” when they cannot read a heart rate. Instead, they just don’t add an entry to the list of heart rates that have been read. A problem arises because the absence of a reading can occur for multiple reasons other than the user being dead. API responses also do not indicate when the ring last updated the phone, and so as the last datapoint becomes more and more stale, we don’t know if:
1. The ring is out of bluetooth range
2. The phone is dead
3. The ring is dead
4. Too much movement to get a reading
5. The user is dead
Do we sound the alarm? If so, after how long?
As a demonstration, I call the API endpoint ‘https://api.ouraring.com/v2/usercollection/heartrate’ for my own data. I receive a response:
The last heart rate entry is 83 bpm at 1:24 AM UTC (5:24 PM PST)
I now take my phone (which the Oura requires to sync) to the other room, where it will be out of bluetooth range and not able to update the data. I call the endpoint again in 1hr. As we can see in the screenshot below, the last entry is still at timestamp 1:24 AM UTC.
From the point of view of a monitoring application, am I dead? There are no heart rate entries. The point is that given that the system does not enter “bpm: 0” when no heart rate can be measured, and a lack of entries can occur for a number of reasons, we don’t know what’s really happening.
2. Sync Delays at Night
The Oura Ring is designed to sync data with its paired smartphone primarily during the day. During the night, especially when it assumes the user is sleeping, data syncing is paused. This delay can lead to a lack of immediate data availability, which is a critical limitation in emergency monitoring or death detection scenarios. The image below depicts the delays in data freshness on the API endpoints during the night. Furthermore, if syncing generally doesn’t occur until you display signs of awakeness or open the app, that sync will potentially never happen. In this case, from the standpoint of the data we do have available, is the user’s ring dead? Their phone dead? Are they dead? You get the idea.
Conclusion
The Oura Ring stands out in the realm of health wearables for its user-friendly design and the breadth of health data it provides. Its limitations, particularly concerning data accessibility and syncing delays, pose challenges for detecting the user may have passed away. A solution built around the Oura developer interface will have to choose between false alarms or delayed alarms. Too many false alarms, and the user is less likely to continue using the system. Furthermore, the sync delays at night prevent monitoring at night, meaning that monitoring would be paused for the 8 or so hours that the user is sleeping, meaning delays as long as 8 hours would be possible with a system like this.
Simple changes to the API endpoints as well as sync behavior could eliminate these problems, but given Oura is not attempting to be eminently usable for medical emergency monitoring or death detection, these are unlikely to be realized. See the data flow diagram below for a summary of the main issues:
