Health and Wellness Web API - Use Cases
With the advent of smartphones and other 'connected' wearable devices hosting various health sensors, a revolution in healthcare is in the making; paving the way for realizing endless possibilities such as real-time patient and doctor interaction, assisted care, at-home disease management etc. Economical, patient-centric solutions can now be easily made available thereby promoting general health and wellness of users.
Albeit most of the services available today are currently limited to the realm of 'native' applications (that interact with the health sensors, collate and classify the information and make it available for further consumption), it is estimated that by 2017, there will be 1.4 billion mobile sensing health and fitness app downloads worldwide [1]. Combine these facts with the growing popularity of Web Apps and the Internet of Things fast becoming a reality, and we are left with a gaping need for Web APIs for dealing with Health and Wellness mobile sensing data.
Following are some of the use-cases or guidelines that can help define Health and Wellness APIs for the Web platform.
A company, perhaps the one manufacturing the health sensor, would like to present the readings to the user via their web page/app. The app could also process the requested data to provide specific services to the user. The web page/app should be able to do so by simply requesting the said data via a Javascript API.
For example, a health band/watch tracks and records a user's various physiological parameters such as number of steps, distance covered, heart rate, etc., throughout the day. It may then process this information to provide a concise chart of the user's activity including the number of calories burnt, most and least active periods etc., to the user via their web account. To thus retrieve such information from the sensor/device web interfaces are required, enabling the web site/app developer to present the information to the user.
If the platform supports hosting a common database for the user's health and wellness statistics, APIs should be made available for setting of
Classification of health data is of utmost importance and involves several aspects. Primarily, the data ought to be classified based on its sensitivity and confidentiality. The process of identifying an object's confidentiality level must also take into consideration evaluation by healthcare organizations of how sensitive the data is and also how the patient perceives the sensitivity of the same. Perhaps the classification of parameters being measured and read off sensors should be carried out by manufacturers themselves with provisions for allowing the user to change the confidentiality level.
Apart from this, data categorization can be based on various other criteria such as accessibility, read-only or read-write data, real-time sensor readings, type of tests etc. For example, a cardiologist may ask for a patient's cardiology test data. If the user gives the required permission, all the data available under cardiology tests should be shared with the cardiologist.
The device should be able to specify in which units it measured the requested data. Provision should also be made for specifying the units in which the data is measured.
A device/sensor should be able to transmit data along with a timestamp (specifying when the reading was taken). This shall be useful in scenarios when a web app wishes to track a specific health metric over a period of time.
It is possible to have multiple sensors measuring and registering similar health data. For example, a device's native heart rate monitor and another connected device, such as a FitBit, could both be measuring the user's heart rate. When such data is queried for, the User Agent may provide the user with an option to select the device from which to read the data.
Provision should be made for querying either pre-recorded data or live/real-time readings with the web page/app. Different APIs can be defined for querying either type of data. However, for sharing real-time readings, the User Agent should be able to turn on the requested device, request for the desired reading, and then transmit the same back to the requesting web page/app. Provision for sending the data asynchronously should be made.
Example, a web page/app requests for the weight metric. The User Agent should be able to turn on the 'connected' device registered for measuring the weight. The user should then be able to take the readings using the connected device. Once done, the readings should then be transmitted back to the calling web page asynchronously.
Also, perhaps this requires a timeout value after which the requesting web page/app should stop polling for/waiting on the data.
Provision should be made for transmitting readings that are spread across a range, such as an ECG reading. A website should be able to continuously poll for such data similar to Geolocation's watchPosition() API.
Devices may advertise a URL for the convenience of users who wish to interact. Launching an advertised URL loads a website with the device already paired and available for communication. For example, syncing of readings from a Gear (smartwatch) after a run.
A web application may register itself as an observer for changes of any health readings. Example, when the user's blood pressure touches any specific level, the registered applications can be notified.
A web application may want to be notified of any health related event. Example, when the user falls asleep, wakes up or starts exercising etc.
1. The Health API must allow access websites access to devices they know how to interact with.
2. The Health API should be able to pair a site with a device based on previous user action linking the two.
3. When requesting for health info, the User Agent must always obtain user's confirmation for the same (unless the specific pairing has previously been granted the permission of 'always share' by the user).
The developer can comply with international law such as HIPAA (Health Insurance Portability and Accountability Act) proposed to protect personal health information. According to the law, personal health information can be provided to a 3rd party only if the information owner has agreed. Also, the owner can request the history of information requests.
The User Agent should seek permission before sharing any health related information with the querying web page/app. Options such as 'always share', 'never share' and provision for session based sharing should be made available to the user.
The User Agent should not allow to register observers/watchers if the resulting absolute url has an origin that differs from the origin of the requesting web app.
[1] ONworld Survey
[2] HIPAA
Feedback is most welcome! Please post any issues or comments regarding this here!