Apple HealthKit Pitfalls

Almost ten years ago, Apple introduced the HealthKit. It provides an elegant way of getting users’ medical data. It covers integration with 3rd party wearables and even hospitals which could provide you with personal health records via FHIR API. It is 100% production ready, but you should use it wisely. Today I am going to share the lessons we learned.

Let’s see what issues you will encounter while loading hospital data. Apple Health loads the medical data into the smartphone in FHIR format. For security reasons, Apple doesn’t have access to the data. So they can’t validate it. The hospital is self-declaring that data is stored in FHIR format, but there is no way to check that the data is correct. So you can get incorrect FHIR resources. Some required fields may be missing. You can even get FHIR resources with typos in attribute names. The references may point to FHIR resources you don’t have access to. It could be Practitioner, Organization, or any other resources used in the clinic internally. Finally, there are multiple versions of the FHIR standard so that you can get data from the old version. In this case, you have to normalize and transform the data. To sum up, please keep in mind that you can’t use this data as it is. You have to implement the validation and normalization before using the data.

Let’s keep digging deeper and see how integration with wearables works. Apple HealthKit data may be gathered across different sources and contain duplications. HealthKit provides granular access to the data. You will get all metrics from all devices that will be a massive amount of data you may not need. Also, this data could contain duplications you would like to eliminate. Likely, HealthKit provides aggregation API, but it is limited. You can aggregate by a period of time and data type and apply ordering on top of it. In some cases, the same data type could be loaded from different sources. You can’t do such aggregation with the API. So, you need to load the data into your app runtime and implement aggregation on your own. It is not obvious and may cause different errors.

Finally, I want to show one example demonstrating how complex a simple task of sleep time tracking may be. There are multiple ways how you can track sleep time. The iPhone itself can track bedtime. It doesn’t mean that you are really sleeping. However, if it is the only metric, it is used as sleep time. Things get sophisticated when you use an Apple Watch or any other devices and applications that can track sleep. If HealthKit gets this extra data from the device, it will use it instead of the default bedtime metric.

Furthermore, starting from iOS 16, more sleep metrics like deep sleep and core sleep were added. As a result, debugging becomes a big challenge. In development, it is common to use a simulator. Apple Health app provides you with UI to add all types of data into HealthKit. Unfortunately, it is a manual process, and data that were entered manually differ from real-life data. As a result, sleep time in apple health and your app may be different. And you may struggle a lot with debugging it on the simulator. You have to be aware of such details and implement them properly. And always use real devices and real data for application development.