The DetailsThe entry point into the application is the GH_Main form. Clicking the Connect button saves the password and login that the user types in the local database (after truncating the Variables table) and opens the GH_Choose form. Here, the user has the option to view or add data to a profile.
Things start to get interesting in the onLoad event handler of the form (implemented in the doLoad function in the ChooseCodebehind.js file). Here, a XMLHttpRequest is posted to ClientLogin to get an authorization token that will be used to send further requests. When the authorization token is received, the application queries the service for the profiles associated with the account. (Remember, you can add several profiles' data to the main account.)
The application does this by posting a GET request to https://www.google.com/health/feeds/profile/list with a GoogleLogin auth parameter set to the authorization token received. The response is a XML stream from which the coded identifier for the profile has to be extracted (implemented in the process function in the application.js file). When extracted, the identifier is saved in the Variables table too, as it will be used for further requests.
Reading DataAt this point, you have all that you need to read or write data. Reading is simpler; you can start with the GH_ReadData form. From here, the user can access the entire profile feed or query for specific categories such as medications, conditions, immunizations, allergies, procedures, results, insurance, and demographics data.
The entire profile query (implemented in the getProfile function) sends a GET request to the https://www.google.com/health/feeds/register/ui/profileid service, where profileid is the code for the profile retrieved earlier. The authorization token must also be provided in the request. The service will return all the data associated with the profile, as CCR-compliant information. The request endpoints will differ depending on whether you use ClientLogin or OAuth as your authentication API.
To read specific categories, you need to send another GET request to https://www.google.com/health/feeds/register/ui/profileid with a special format. Basically, the address where the request is sent must also include a pointer to the specific category (e.g., /-/medication). The format can be more complex and it can include querying for several types of categories, requesting a limited number of responses, etc. (the complete query syntax is available here). In both cases, the response will be an XML/Atom feed, which you will need to parse to extract the interesting data.
Writing DataWriting data is more complex because of the payload that you must send with the requests. As mentioned previously, the process for adding data uses the GH_AddData form as a shell from which to launch forms specific to each category being written (medications, conditions, etc.). For example, for the conditions category (one of the two categories implemented in this demo), clicking the Add Item button will result in the code-behind GH_AddData launching the GH_Condition form. This form has its own event handlers, implemented in the ConditionCodebehind.js file. When the form is loaded, the (very limited range of) conditions dropdown box is populated from the database. The doPost function performs the actual posting of a new condition notice by reading the formatted XML post feed from the database and populating it with the data entered by the user from the screen.
To add a new notice, a POST request must be sent to https://www.google.com/health/feeds/register/ui/profileid. The XML feed is the actual message to be posted, and this action is performed by the postNotice function in the application.js file.
Updating an EntryUpdating an existing entry is possible only when ClientLogin is used to authenticate. OAuth allows for only new entries to be inserted. A PUT request has to be sent to https://www.google.com//health/feeds/register/ui/profileID/entryID, where entryID identifies the profile element to be updated. The GH_Medication form and MedicationCodebehind.js file implement the same functionality for the medication category.
All of the above seems (and is) very straightforward, but getting all the needed information together is not as simple as it should be, given the way the Google documentation is organized and the size of some of the samples provided.
An Early Exploration into an Emerging FieldGoogle Health's somewhat confusing documentation and its limited range of examples, sample code, and SDKs show that this is indeed an evolving product. I suspect that the current range of potential applications is relatively narrow, but it seems likely that the platform will grow and its adoption will generate much more developer interest in the future. A potentially interesting development is in the area of medical devices, which could be made to interact directly with the service (something that Microsoft is already offering).
The potential of the service notwithstanding, I think the programming model and the concept demonstrated in the demo here are very useful, as you can expect similar services in various industry verticals to emerge in the future. AIR proves to be a versatile tool, capable of handling the client side of this type of distributed applications with sufficient ease and power. Learning to leverage it within a cloud type of application scenario might be something more developers wish to do.
For Further Reading
About the AuthorRazvan Julian Petrescu is a developer with a background in healthcare. The difficulties he encountered when trying to have eye examination records transferred to another optometrist are the inspiration behind this article. Reach him at firstname.lastname@example.org.
Page 3 of 3