A Flexible Personal Health Record Library

After spending the last few months working on accessing four different health record apis from Android devices, I thought it would be an interesting idea to create a library that obfuscates the individual differences found in each api.

I imagined it like this:

You read a measurement from one record, lets say it was weight for example.

You use the returned weight measurement and immediately upload it to a different record.

No formatting changes, new object creation or individualized method calls. Just a simple, flexible way for developers to access multiple different health record apis using the exact same interface.

How will this work? Let’s continue using the weight measurement example.

By taking the values that every weight measurement has in common throughout the web api, an object can be created that can be used by every record. It could look something like:

public class WeightMeasurement{
private double weight;
private String unit;
private Calendar date;
}

This is where the more difficult part arises. Each web api expects its requests to be formatted in different ways. This object needs to be transformed by each individual api implementation when it is being pushed or pulled to/from the respective health record.
This of course would all be done behind the scenes, hidden from the interface that a developer would be using, so they may continue to do things like:

WeightMeasurement weight = fitbit.pull(MeasurementType.WEIGHT);
withings.push(weight);

This also serves another purpose; allowing extensibility in the library.
If a new api needs to be implemented, only the formatting changes for the Measurement objects would need to be written. The interface that is used by a developer would remain exactly the same.

There is however one problem I have yet to find an elegant solution for : application authorization.

Each api that I have worked with has employed different methods for authorizing an application to access a user’s personal information.

Some require the user to sign in through a webview, others only require a request be sent with the necessary credentials.

Creating a common interface for this process may prove difficult, however I believe it to be possible.

For now let me wrap this up until I have more concrete ideas to share.

I believe a flexible library such as this, which has the potential to provide a common interface for developers to access multiple health record apis would not only prove to be a valuable development tool for anyone trying to work with multiple apis, but also prove to be extensible enough to stay relevant with future health record api development and creation.