October 25, 2016
Hot Topics:

Creating a Cloud Client with Adobe AIR, JavaScript, and Google Health

  • October 28, 2009
  • By Razvan Petrescu
  • Send Email »
  • More Articles »

The Architecture

The demo application is a forms-based, single-user desktop application. The client will connect to the cloud using the ClientLogin API. (The cloud as defined in this article is an online service storing data that developers can access via a set of API's. Data storage is abstracted to the user, who has to relinquish a certain amount of control over it, but who ultimately owns the data and has full access control.)

ClientLogin is one of the two Google Data APIs for authenticating to various Google services. The other is the OAuth API. Desktop/installed applications use ClientLogin, while web applications use OAuth. The two have other differences, for example, in the types of operations allowed under each API. More details will follow, and you can click here for a comparison of ClientLogin and OAuth.

When the client connects to the cloud, it will allow the user to read the data—either the full profile or the specific data components previously listed (conditions, medications, allergies, etc.). Google Health will return the data as an XML/Atom stream, which the client will render as received. A production-level application will certainly have to display this data in a more user-friendly format (as noted earlier, however, I focused this demo on the aspects that deal with the communication with the service to keep the size of the code manageable).

You add data to the service by using several template forms. When the user chooses to upload condition data, for example, a conditions form opens with a few fields specific to the Continuity of Care Record (CCR) conditions definition. The CCR specification is potentially large, so you will have to decide which fields you want to build support for. (See "CCR and Health-Care Technology Standards" for a further discussion of the CCR spec.)

When the data has been posted, you can view it in the application or use the Google Health GUI itself (but you will have to refresh it in the browser). Attempting to post the same data twice results in an error, because the protocol requires a different approach for updating data (a further discussion on this shortly).

I used the Aptana Ruby on Rails IDE (with the AIR plugins) to develop the application and manage the source files. I used the SQLite 2009Pro application to manage the SQLite database. The latter has been especially useful when dealing with XML data. For a production application, you probably should use an ETL tool such as Microsoft SQL Server Integration Services, but for this demo, SQLite 2009Pro is more than adequate.

Figure 1 shows the files included in the demo application.

The HTML files are the actual HTML forms that make up the GUI of the application. The AIR environment will load them at run time to populate the native AIR windows. GH_Condition and GH_Medication are the HTML forms used to upload the conditions and medications, respectively. As previously mentioned, their fields correspond to the XML feeds stored in the database (also included in the templates directory). The code for each form is in the corresponding *Codebehind JavaScript file, with some global functions and classes in the application.js file. Application.xml is the AIR application descriptor.

The application uses a local database to store authentication information and to store some post template information.

The Database

The database backend of the demo application is SQLite, which is natively supported by the AIR environment. The database, GoogleHealthAir.db, is included in the source code for this article. It should reside in the Documents folder of the user running the application. It includes only three tables:
  • VariablesVariableName VARCHAR(50), Variable Value VARCHAR(50)—includes session data such as login, password, the authorization token returned by Google Health, and the profile ID of the main profile of the account.
  • TemplatesTemplateType VARCHAR(50), Xml TEXT, HTMLFilePath VARCHAR(50)—includes the templates used to post data. Only two templates are included here, one for medication data and the other for condition data. The HTMLFilePath field points to the HTML form that the application uses to collect the data it will post. The Xml field contains the XML feed (with a subset of the CCR data corresponding to the fields available on the HTML form) that has to be posted to the service, with placeholders in lieu of actual data. You have to be very careful with this XML feed. You can easily make a small mistake that will cause the service to reject the feed. The Google Health documentation offers feed samples online.
  • ConditionsDescription VARCHAR(50), ICD9 VARCHAR(10)—are ailments, diseases, etc., that the healthcare profession handles, and it has a comprehensive standardized record of conditions, the ICD9 international standard. Basically, every medical condition has an identifying code associated with it. I added only two conditions to my table, but you could download the entire standard and load it into the table. Perhaps a better solution would be to create a web service that returns a condition identified by its code, the code for a specific condition, or a subset of conditions starting with a certain letter, etc. The Google Health GUI does a nice job of "intelli-sensing" conditions as you type the name.

Page 2 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel