Advertisement

When the Wall Street Journal, New York Times, Business Week, and USA Today all have articles discussing the most recent entrant to the Personal Health Record (PHR) space, then something significant might be happening. Regardless of Google’s success in its launch earlier this year of Google Health, the popularity of Google as a search engine, email service, calendar product, and now PHR service means that it is worth a look at how these rapidly emerging and evolving services impact developers of medical device companies and associated software applications.

According to a November 2007 Wall Street Journal poll, three-quarters of respondents agreed that they would receive better care if their providers were able to share information more easily across electronic systems. While at that time only 2% used some form of PHR, over 90% expressed a desire to access to their own electronic records maintained by their physician.

What Is Google Health?

Enter Google Health. Promoted as an alternative to existing services such as WebMD from which individuals can learn about health issues and find helpful resources, search for doctors and hospitals, build online health profiles, and – significantly – import medical records from hospitals, clinics and pharmacies. Google Health initially launched in partnership with the Cleveland Clinic earlier this year, and now has numerous well-known partners.

Implications for Device and Software Developers

As health providers increasingly use electronic medical records (EMRs) and as patients slowly acquire personal health records, the necessity for device developers is to keep pace with interoperability. Medical device and software developers should be familiar with Health Insurance Portability and Accountability Act (HIPAA) Security Rule as a set of guidelines for protecting an individual’s electronic personal health information. While typically neither a Covered Entity nor Business Associate as defined by HIPAA, medical device developers who fail to enable their provider-customers to comply with such requirements will not be successful.

The likely data path for patient information will be from medical device, to provider, to Google Health, although home-based devices may eventually have their data uploaded directly by the patient. In either event, the data elements and structures within such devices should reflect design considerations using the most broadly applicable standards. In the case of Google Health, this means the ability to produce data conforming to the eXtensible Markup Language (XML) standard, increasingly common for Internet and data manipulation.

To the extent that Google Health becomes a successful brand in the PHR space, there is the possibility of manufacturers and service providers to become designated as “compatible” with Google Health.   

Design Considerations

XML is an international technology standard, developed and maintained by the World Wide Web Consortium, W3C. XML permits data to be structured and embedded within XML files so that software applications can adapt the content and display it in a variety of formats. While device developers in the past may not have coded data for the Web, the onset of EMR and PHR all but dictate such.

Google Health has published third-party developer policies as well as details of the Google Data (GData) application programming interfaces, which are available online. The GData API’s use one of two XML-based syndication formats for reading and writing data to the Web, thus allowing medical device data to interact with the Google Health service. 

The Continuing Challenge of Standards

Until this spring, device makers found themselves in a bit of a predicament as various electronic record platforms and services sprout. Google Health, the industry consortium Dossia, WebMD, and Microsoft’s HealthVault each claim a role in this rapidly evolving area.

Google Health is distinct from Microsoft’s HealthVault, which is more of a platform for healthcare providers and other professionals to move personal health information online in the first place. In theory, a hospital or clinic would build a system to push data from a blood pressure monitor or IV pump and share it electronically with other authorized providers. That system might then help an individual move the data to Google Health.

All of this means that the standardization of electronic health information is becoming more important, and this is where the coordination efforts of the Markle Foundation have been so important. Google Health has been designed to meet the Continuity of Care Record (CCR), which is an ANSI-accredited health information technology standard. The CCR output of the CCR standard is a CCR digital file with seventeen potential data elements, ranging from diagnosis to vital signs and medical equipment to results. In late June of this year, the Markle Foundation (in conjunction with Google Health, AARP, Blue Cross Blue Shield, and many others) formulated Connecting for Health to develop just such standards. Connecting for Health has initiated a series of working groups to develop common approaches to fundamental issues such as consumer authentication and consumer access policies. More significantly for medical device developers and health care providers, Connecting for Health has released a common framework with source code and testing interfaces, which are available from http://www.connectingforhealth.org/commonframework/index.html. While development of the common framework predates the addition of Google Health, Microsoft Vault, Dossia and others to the Markle Foundation’s standardization effort, the implication is that all of the current participants will be endorsing an interoperable approach.

The development and maturation of industry standards requires more than simply joining a team, and while it is positive news for device developers that standards are converging, the proof will be in uptake by both consumers as well as providers and device developers. There have been times in the past when a technologically superior product did not necessarily win the race, so developers would be well served by remaining flexible for now.

Peter McLaughlin is Senior Counsel for Foley & Lardner, LLP

Advertisement
Advertisement