Personal health information management is closely related to a concept that has been in the U.S. media a lot recently, EHR (Electronic Health Records). Leaving behind the long, convoluted history of EHR both in the US and abroad, suffice it to say that there is a significant governmental push for widespread adoption of this type of technology in healthcare. (See "Health Records in the Cloud" for a further discussion of this issue.)
Both Google and Microsoft offer cloud-based solutions for personal health information management: Google Health and HealthVault, respectively. They provide some of the necessary infrastructure for enabling large-scale adoption of EHR, but the vendors differ in their approaches. For instance, Google Health and HealthVault differ in certain aspects (click here for a detailed comparison), and Microsoft now offers a full range of healthcare and life sciences software (Microsoft Amalga).
- platform independence
- the potential to run on mobile devices (thus, enabling the vision outlined in the beginning of the article)
- intuitive support for database storage (which is an important component of the application architecture)
The ApplicationTo use the demo application, you will need a Google account. You will use the account to link to Google Health (creating a health account and authorizing the storage of personal data in the process). For the purposes of this article, I created a fictitious account for Vincent van Gogh: firstname.lastname@example.org, password vincentvan. You can create your own, but I advise against using your real account to store demo data.
Google Health provides a sandbox environment for testing purposes. The only difference between the sandbox and the real application environment is that the sandbox is referenced using h9 instead of health (i.e., www.google.com/h9). All references in code point to h9 as well (this is documented in the code download).
Notice that you can enter/view data using the Google Health GUI. The application described here replicates the same functionality on a smaller scale. Notice also that you can associate another person's data to your account. That is, you can store his or her data alongside yours. This is a handy feature, perhaps targeted at a parent who will enter and maintain the health data for the entire family. Again, for scope purposes, the application discussed here will allow access to only the primary account data. However, comments in the code show where this limitation is located, and enabling access to all associated accounts is rather trivial.
The Google Health account includes the following types of details:
- Test results
It can also store images (of any kind, but the intent is to store scanned documents or copies of CTI/MRI scans) with one important caveat: medical images tend to be very large. How effective Google Health can be at storing medical images in a real use scenario remains to be seen.
Very importantly, Google Health allows physicians' offices to access and update this data, and Google is negotiating access protocols with a variety of healthcare providers. A list of current medical providers with integrated access to Google Health is available here.
One interesting Google Health feature is the ability to detect possible adverse interactions between drugs. As stated in the Google Health Help section: When you're adding medications to your profile, you may see a warning symbol (either a hexagon or a triangle with an exclamation point) beside the Drug interactions link on the left side of the page. You can click this link to see potential drug interactions, including interactions among drugs, diseases, and allergies.
The demo application will allow a user to authenticate to the account, read data stored in the account, and post (some) data. Because there is a huge variety in the data that a user can post, I have included only a couple of templates (for conditions and medications). Posting other types of data will be similar.
Page 1 of 3