The ArchitectureThe 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 dataeither 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.
Figure 1. Files in Demo Application: These are all the files included in the Google Health demo application.
The application uses a local database to store authentication information and to store some post template information.
The DatabaseThe 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.