The military health system's personal health record pilot with Microsoft HealthVault and Google Health

Abstract

Objective

To design, build, implement, and evaluate a personal health record (PHR), tethered to the Military Health System, that leverages Microsoft^® HealthVault and Google^® Health infrastructure based on user preference.

Materials and methods

A pilot project was conducted in 2008–2009 at Madigan Army Medical Center in Tacoma, Washington. Our PHR was architected to a flexible platform that incorporated standards-based models of Continuity of Document and Continuity of Care Record to map Department of Defense-sourced health data, via a secure Veterans Administration data broker, to Microsoft^® HealthVault and Google^® Health based on user preference. The project design and implementation were guided by provider and patient advisory panels with formal user evaluation.

Results

The pilot project included 250 beneficiary users. Approximately 73.2% of users were <65 years of age, and 38.4% were female. Of the users, 169 (67.6%) selected Microsoft^® HealthVault, and 81 (32.4%) selected Google^® Health as their PHR of preference. Sample evaluation of users reflected 100% (n=60) satisfied with convenience of record access and 91.7% (n=55) satisfied with overall functionality of PHR.

Discussion

Key lessons learned related to data-transfer decisions (push vs pull), purposeful delays in reporting sensitive information, understanding and mapping PHR use and clinical workflow, and decisions on information patients may choose to share with their provider.

Conclusion

Currently PHRs are being viewed as empowering tools for patient activation. Design and implementation issues (eg, technical, organizational, information security) are substantial and must be thoughtfully approached. Adopting standards into design can enhance the national goal of portability and interoperability.

Introduction

Like other large healthcare organizations, the Military Health System (MHS) recognizes the potential value of an interoperable personal health record (PHR) in improving efficiency, enhancing quality and safety of care, and increasing consumers' participation in the healthcare process.^{1 2} The PHR also shows promise as a tool to accelerate recent policy and regulatory goals by providing a source of health information exchange. Despite the promise, there are substantial barriers (eg, lack of role definitions, immature interoperability standards) to PHR adoption.^3–6

There are multiple PHR models that have been described in the literature, but most are variations of the stand-alone and the tethered PHR models.^7–12 The stand-alone PHR can be completely freestanding and dependent on self-entered data from patients or as an interconnected third-party PHR that can receive both self-entered and electronic health record (EHR) sourced data. A tethered PHR can be either provider- or payer-tethered. Regardless of model design, implementation challenges are formidable given barriers and debate on key issues such as privacy and security, architecture options, functionalities, and supporting policies.

Background

The Armed Forces Health Longitudinal Technology Application (AHLTA) is the official outpatient EHR of the MHS connecting its medical centers, community hospitals, and clinics globally. As directed by both congressional and executive action, AHLTA, and all future health information systems, incorporates federal interoperability standards and implementation specifications.^13–15 In the FY 2008 National Defense Authorization Bill, the Veterans Affairs (VA) and the Department of Defense (DoD) were charged with the implementation of ‘electronic health record system or capabilities that allow for full interoperability of personal healthcare information for DoD and VA.’¹³ Part of this charge was incorporating a patient focus where beneficiaries will have access to their own medical information.¹⁴ The Military Care (MiCARE) pilot represented an opportunity to advance this goal.

To evaluate the feasibility of delivering an interoperable PHR for its beneficiaries, the MHS decided to pilot recent PHR offerings by Microsoft and Google.¹⁶ The MHS considered a number of government and commercial off-the-shelf products in deciding what would best meet the overall needs of the health system and its beneficiaries. Initial cost and schedule constraints prohibited the delivery of a full complement of PHR functionalities, so a phased approach was used, starting with patients' access to a personal health data repository. Both Microsoft HealthVault and Google Health PHRs met DoD information privacy and security requirements while providing the opportunity for military beneficiaries to access their health information via the internet.

Initiated in the spring of 2008, MiCARE was developed as a pilot project with the objective of expanding MHS beneficiary access to their EHR-based medical information via Google Health or Microsoft HealthVault (or both). MiCARE was created as a portal for users to manage their PHR account and access future PHR functionalities, and for access to other sources of health data. In this manuscript, we describe the design, implementation, and lessons learned from our initial MiCARE pilot.

System description

Pilot study design

Our pilot was conducted at Madigan Army Medical Center, a 1.2 M square foot 400 bed tertiary care facility located in Tacoma, Washington. The facility is a designated Level II trauma center for the military and for Pierce County, Washington.¹⁷ The county contains 750 000 residents, of which approximately 100 000 are eligible military beneficiaries enrolled to the facility for care. The facility is home to a variety of graduate medical and nursing education programs and employs approximately 4224 military and civilian staff. In a given year, the facility realizes >1.6 M clinic visits, >1.4 M prescriptions and >1.9 M laboratory procedures.¹⁷ Madigan Army Medical Center was selected as a home for the MiCARE pilot in part due to the facility's size and its developed clinical informatics department.

The MiCARE pilot project was approved and funded in 2008. Primary development occurred between May and November 2008, with recruitment activity focused during the last 2 months of development. The pilot formally began in November 2008, and for 10 months the enrollment was capped at the first 250 users. Recruitment was open to active duty members, active duty family members, retirees, and family members of retirees. The pilot concluded in November 2009 when enrollment was opened to additional beneficiaries and remains so today. As of October 2010, there are >2000 enrollees with approximately 30–40 new users enrolled each month.

The MiCARE pilot was marketed to the target population using several strategies. Between August and November 2008, formal presentations were made to active patient advisory groups and beneficiary support meetings. Print advertisements were placed in the base newspaper and two local community newspapers. Posters were posted in the base department store, grocery store, and large electronic signs at the facility's main gates. Hospital staff members were encouraged to promote enrollment by personal referral. Finally, manned registration booths were established within the facility, and both a registration phone number and email address were created.

MiCARE operations: how it worked

As shown in figure 1, enrollees accessed the secure MiCARE web server located at the American Lake Veterans Administration (VA) Hospital in Lakewood, Washington. This VA-based gateway served as the access point for transfer of patient data. When the participant selected the desired PHR repository via a data broker, Microsoft or Google exchanged a token with MiCARE which was stored in the MiCARE database. This token supported continued sharing of records with the beneficiary's PHR of choice. As the beneficiaries selected PHR data elements (box 1), MiCARE would run a query over the MHS-VA Bi-Directional Health Information Exchange (BHIE) framework to search for similar data types at over 100 MHS sites and the MHS clinical data repository. Data returned from the query were placed into the PHR repository of choice for the beneficiary's access. The MiCARE users had rather comprehensive PHR data elements (eg, laboratory results, physician notes) available to them; many contemporary PHRs do not include all of these elements.¹⁸

Figure 1.

MiCARE architecture BHIE, Bi-Directional Health Information Exchange; DNS, domain name system; MiCare, Military Care; SQL, structured query language; VA, Veterans Affairs.

Box 1. Military Care personal health record data elements.

• Laboratory results^*

• Allergies

• Medications

• Radiology reports

• Appointments

• Medical procedures

• Medical problems list

• Consultation reports

• Inpatient notes

• Outpatient encounter notes

^*Laboratory results were added in October 2009.

MiCARE architecture and design

MiCARE was architected to perform as a flexible platform for transferring data between various DoD data sources and stand-alone PHRs (figure 1). MiCARE incorporated standards-based models including the Continuity of Care Document (CCD) and Continuity of Care Record (CCR) to map DoD-sourced data to standardized formats most commonly supported by healthcare systems.¹⁹ In our pilot, Google Health operated a subset of the CCR to model its PHR data, while Microsoft maintained a custom model that includes support for the CCR as CCD standards. The architecture allowed MiCARE to adopt new data sources and partner with additional PHR systems in the future. The architecture repository was maintained by Microsoft and Google.

Microsoft HealthVault and Google Health utilize Service Oriented Architecture in their system design, providing accessibility of their systems through web services. The web services are implemented using varying technologies, Microsoft uses their standard Simple Object Access Protocol, and Google uses the Atom Publishing Protocol. Both service interfaces are encapsulated in software development kits (SDKs) which provide us with a simplistic means of integrating with the PHR systems using our native development environment, Microsoft.NET. Unfortunately, these two SDKs expose very different application programming interfaces (APIs), and the interfaces accept data in widely dissimilar formats requiring MiCARE to translate between a common set of DoD data types and interfaces, and the varying data and interfaces exposed by the PHR APIs.

The approach used in MiCARE was to define commonly used data types and interfaces for communicating with the disparate PHRs. MiCARE was designed to accommodate the implementations for each PHR by mapping commonly defined schemas and interfaces to and from the PHR-specific services. By virtue of this standardized communication scheme, it is possible to integrate additional DoD data sources and third-party PHR systems more quickly and easily. For a detailed comparison of Google Health and Microsoft HealthVault attributes, see table 1.

Table 1.

Comparison of Google Health and Microsoft HealthVault attributes during pilot

Attribute	Microsoft Health Vault	Google Health
Patient control	Patient selects desired data/document elements for import and sharing; selects who to share with by email invitation as well as duration of access	Patient selects import source, available data/documents are imported, and patient chooses who to share (eg, provider, case manager) by email invitation; valid until user rescinds. Military Care added a filter to control content import.
Dashboard links to stored information (data and document types)	Granular; easy to store and retrieve data by category. Many partners referenced for information support.	Stored similar to email inbox for all data and document types. Reference material link on primary PHR page.
Sharing	Determine who, how long (eg, day, week, month, indefinite), and what information to share	All or nothing sharing with permission granted until specifically rescinded
Standards	Supports Continuity of Document and Continuity of Care Record formats as well as imported documents and manually entered data	Capable of Continuity of Care Record format and manually entered data
Authentication	Modifications (added comments only) are attributed to the author—patient, provider, manager, etc	No modifications of documents are allowed
Upload capability	Primary user, all others allowed access to the file; history shows any activity (upload, comments, deletions) by the authorized users	Patient can generate information and add documents
Device-monitor interactions	Partnership with many vendors to allow upload of health data (eg, glucose monitor, pedometers, blood pressure monitors)	Some device/monitor/source; upload capability based on user response plans for extended capability
Security/privacy	Primary goal to establish patient (user) and provider confidence in information that is presented in PHR	Primary goal to establish patient (user) and provider confidence in information that is presented in PHR
Laboratory results display	Provides readable display of laboratory information for user	Provides graphing of laboratory information

PHR, personal health record.

Health system organizational issues

Although some health organizations make available all data for the patient when available in the EHR, clinicians at our pilot site elected a 7-day wait period for clinical studies and excluded results related to sexually transmitted disease, pregnancy tests, and pathology reports. The delay provided the provider with an opportunity to contact the patient to interpret the results before viewing in the PHR and is adopted by other health systems with PHR capabilities.^{20 21}

For consumer control, a MiCARE enrollment module provided MHS beneficiaries the ability to self-register, initiate, or stop the transfer of their electronic health information. The module also enabled the patients to share their data. Exactly what data to share and whom to share them with was facilitated through the PHR of choice (ie, Microsoft HealthVault or Google Health). With Google Health, the sharing was at the ‘all or none’ level. With Microsoft HealthVault, data sharing granularity was at the ‘individual data element’ level. Sharing decisions would be selected by the beneficiary as permanent or temporary. Access to the beneficiary PHR account was retained regardless of election to change provider or departure from beneficiary eligibility (eg, left military).

Data credibility is critical for system adoption by providers.^{9 22} Microsoft and Google both identify sources for data received. Both products display the source as an institution such as ‘Madigan Army Medical Center’ or person such as ‘John Doe.’ In the case of Google Health, the source name remains constant with the addition or deletion of data. With Microsoft HealthVault, data may be edited or redacted, but when performed the source name is modified to reflect the institution or individual initiating change. In our pilot, beneficiaries were prohibited from directly editing or deleting their official medical record; necessary changes were performed instead through an administrative office. While our pilot allowed patients to be in full control of compiling and releasing their available medical record, it also provided the integrity of the unaltered data from the official medical record, necessary for provider confidence in the system.

Keeping medical information secure is of utmost importance to sustain the provider's and patient's trust. In our pilot, we established responsibilities for the MHS, the PHR vendors, and the patient participants. Data were generated from a Health Insurance Portability and Accountability Act (HIPAA) covered entity with a copy stored in the patient selected PHR repository (ie, Google and Microsoft); the PHRs were neither HIPAA covered entities nor linked to the MHS via Business Associate Agreement. Due to the sensitive and personal nature of the data stored in the PHR, Google and Microsoft relinquished complete control of the data to the patient, which in effect elevated the protective level beyond HIPAA requirements. While HIPAA allows disclosure of patient information without patient consent under certain criteria (eg, billing, quality improvement), Google Health and Microsoft HealthVault privacy policies did not.

The MHS Privacy Office extensively reviewed Microsoft and Google's privacy policies requesting multiple revisions and provisions related to our pilot. Revisions and accommodations related to specific requirements for physical location of PHR servers on US soil, physical security for servers and access procedures, and liability issues in event of breach. Both Google and Microsoft had well-established established policies in the event of security breaches. Both Microsoft and Google agreed to cover cost associated with any realized breach (eg, patient notification, individual credit reports) with liability capped at $1000 per user.

The legal exposure of providers who intentionally or unintentionally did not review patient-authored PHR health information was evaluated and cleared by MHS legal prior to pilot implementation.

Planned evaluation of MiCARE

There have been a number of attempts at evaluating the utility and usability of PHR functionalities.^{7 8 18 21 23–25} While there seems to be some agreement across studies on PHR functionality, implementation choices appear somewhat dependent on the home institution's beneficiary and provider preferences. When designing our pilot, we opted for a two-pronged approach to evaluation. Specifically, we administered telephonic surveys of users in April 2009 and received ongoing feedback from advisory panels (providers and patients) on functionality and usability of MiCARE.

Status report and results

Aggregate pilot study data

The pilot study user group included 250 MiCARE users enrolled between November 2008 and November 2009. Of the MiCARE users, 169 (67.6%) users selected Microsoft HealthVault, and 81 (32.4%) selected Google Health as their PHR of preference. Formal agreement with MHS leadership limited the amount of demographic information (ie, gender, age, and beneficiary category) that our MiCARE team was permitted to collect and report (table 2). The MiCARE pilot user group included 96 (38.4%) females and 154 (61.6%) males. When compared to facility and MHS beneficiary demographics, our pilot included slightly fewer females than represented in the population. With respect to beneficiary category, 60 (24%) were active duty members, 79 (55.6%) were family of active duty members, and 111 (44.4%) were retirees and their family members. In comparison, the MiCARE pilot included a better representation of active duty family members and retirees than active duty members. This might be explained by the substantial deployment requirements currently being imposed on the active duty members. With respect to age of the MiCARE users, the mean age was 53.14 (SD 1.5) years. During the pilot, 73.2% of users were <65 years of age, which compares well to MHS beneficiary-wide data, which were 79% for the same age parameter.^{26 27} To our knowledge, only one (0.4%) of the 250 MiCARE enrollees withdrew during the pilot period.

Table 2.

Military Care pilot group users: demographics

	Military Care Pilot Group n (%)	Madigan Army Medical Center, WA—enrolled beneficiaries, n (%)	Military Health System beneficiaries stationed in USA26, n (%)
Female	96 (38.4%)	43.8 K (43.8%)	4.55 M (48.5%)
Male	154 (61.6%)	56.3 K (56.2%)	4.83 M (51.5%)
Total	250 (100%)	100.1 K (100%)	9.39 M (100%)
Active duty members	60 (24%)	33.8 K (33.8%)	1.99 M (21.20%)
Family of active duty members	79 (31.6%)	34.5 K (34.4%)	1.47 M (15.65%)
Retirees and their family members (and others)	111 (44.4%)	31.8 K (31.8%)	5.93 m (63.15%)

The MiCARE team began tracking usage statistics, using Google Analytics beginning in April 15, 2009. Table 3 provides overview statistics trended over time. The usage rate approximately doubled in the last two periods that is explained by the introduction of laboratory results into MiCARE. While originally planned from the onset of the pilot, the provider 7-day wait period in release of laboratory results (mentioned previously) resulted in a delay in adding the highly desired feature by MiCARE users. This policy-imposed mandate was time-consuming to implement, as over 3000 laboratory result types were modified to accommodate the delay.

Table 3.

Military Care usage statistics—trended

Measurement category	April 15–June 11, 2009	June 12–August 7, 2009	August 8–October 3, 2009	October 4–November 30, 2009	Total
Visits (count)	451	582	1113	1158	3304
Page views (count)	4486	5538	12 557	12 821	35 402
Page views (mean)	9.95	9.52	11.28	11.07	10.71
Time on site, min:s (mean)	08:33	07:45	08:56	09:02	08:43

Data were calculated from Military Care portal using Google Analytics.

Telephone interviews of MiCARE users

The MiCARE team conducted telephone user interviews as planned in April 2009 by selecting a convenience sample from the 250 users stratified by user type (ie, active duty members (n=20), family members of active duty members (n=20), and retirees (n=20)). The team members called on MiCARE users and continued calling from a stratified list until they had achieved their 60 participant target. Survey results are recorded in table 4. As expected, the majority of users conveyed satisfaction with MiCARE access to their PHR. The respondents were consistent in their desire for additional functionality (eg, secure messaging, appointment function) and offered additional unscripted feedback on system improvement (see table 4).

Table 4.

Results of telephonic survey of Military Care (MiCARE) users (n=60)

Question	Yes	No
Indicated challenges with using PHR	10 (16.7%)	50 (83.3%)
Most commonly cited issues:
Complex clinical terms
Some appointment dates seemed wrong
Missing clinical notes
Double entry (by user)
Cannot sort by date ranges
Satisfied with convenience of record access	60 (100%)	0
Satisfied with overall functionality of MiCARE	55 (91.7%)	5 (8.3%)
User has special or complex medical conditions (self-reported)	25 (41.7%)	35 (58.3%)
Desires secure messaging feature in MiCARE	60 (100%)	0
Desire for appointment function in MiCARE	60 (100%)	0
Desire for medication renewal function in MiCARE	60 (100%)	0
Desire for health reminders (eg, immunizations, preventive care) in MiCARE	55 (91.7%)	5 (8.3%)
Additional feedback, users desired:
Improved ability to search clinical notes
On-line tutorials on PHR use
User-friendly clinical notes in PHR
Access to nurse or guidance on when to see physician
Ability to request medication refills
Ability to correct medication list when wrong
Medical terminology translated into plain English
Nutritional information be included
Interactive blogs on important and current health topics
Ability to easily trend laboratory results (eg, HbA1c)
More rapid release of laboratory findings

PHR, personal health record.

Provider and patient panel feedback

Our provider and patient panels met on a monthly basis during the first phase of work (May to November 2008) and bi-monthly during the actual pilot (November 2008 to November 2009). These panels proved useful to the MiCARE team, especially in understanding clinical workflow of participating providers and clinics. The panels also served as a platform for providing feedback on the usability of initial and add-on applications throughout the pilot (table 5). The panels initially comprised 10 participants each, but the composition and number of participants changed over time as additional participants joined early efforts.

Table 5.

Salient feedback from Military Care provider and patient advisory panels

	Patient panel (n=10)	Provider panel (n=10)
Availability of laboratory results	Ready access whenever available (n=10)	Provide 7-day wait period for results to allow for provider contact with patient (n=9)
Availability of sensitive lab results (ie, sexually transmitted disease, pregnancy, and positive cancer findings)	Ready access whenever available regardless of sensitivity of information (n=9)	Exclude results from Military Care; add only with permission of patient and provider concurrence (n=8)
Availability to upload radiology images and reports	Interested in radiology reports; less interest in actual image (n=7)	Interested in radiology report; less interest in actual image (n=5)
Ability to upload digital photographs	Desirable characteristic (n=8)	Desirable characteristic (n=5)
How much information should be included	Access to all information a good thing (n=10)	Concerned about time to review all included information (n=7)
Patient control of access to information	Patients decide what to share with others (including providers) (n=9)	Providers concerned about incomplete information should patient elect to exclude provider access to data (n=8)
Secure messaging function	Desired but not available in pilot (n=10)	Desired but not available in pilot (n=10)
Outcome dashboard function	Desired but not available in pilot (n=7)	Desired but not available in pilot (n=5)
Appointment function	Desired but not available in pilot (n=9)	Desired but not available in pilot (n=6)
Medication renewal function	Desired but not available in pilot (n=10)	Desired but not available in pilot (n=9)

Technical issues

During our pilot, Google implemented seven of 17 XML-based CCR standards (ie, allergies, conditions, immunizations, medications, procedures, test results, demographics). While these sections were useful, researchers have noted that radiology reports and physicians' notes are among the most often requested information by patients for the PHR.¹⁸

Adding data to Google Health involved specifying two pieces of information, a Notice and an attached CCR payload. The Notice could be compared to an email message. In our pilot, MiCARE sent an empty Notice with a subject (eg, new medication) and attached a related CCR (eg, medication information). When Google Health received the notice it parsed the medications from the CCR and stored the records discretely in the PHR. Any data elements not in the seven CCR categories that Google had implemented such as clinical notes, radiology reports, and appointments were transformed into HTML and stored as Notices. The latter created a challenge for patients or providers to quickly identify, search, or retrieve information stored in Notices.

During our pilot, Microsoft HealthVault accepted both the CCR and CCD. The CCD's primary use case was also the sharing of summary data by constraining the Clinical Document Architecture (CDA) with the data set from the CCR.²⁸ Like the CCR, the CDA can be used to collect data from multiple sources and multiple encounters. Unlike the CCR, the CCD has an information model based on the HL7 Reference Information Model and is extensible, while CCR is fixed.²⁹ During the pilot, we found that the amount of resources and time required to assemble non-document data types, such as laboratory results, into the CCD was not acceptable, and so the HealthVault API was used for all laboratory results, medications, and allergies. For documents, the MHS has standardized sharing of clinical documents using the CDA. Currently, clinical documents such as discharge summary are out of scope for the CCR.¹⁹ Despite the richness of the CDA metadata in describing document type and origin, Microsoft HealthVault did not capitalize on the metadata in managing clinical documents. The end result was a user experience similar to Google Health where the beneficiary was required to scan and click through a potentially long list of documents to find the information of interest. During the pilot, we discovered a number of clinical documents stored within our system of record that failed to validate against Microsoft HealthVault CCD schema. We designed MiCARE to convert these documents to PDFs and store them in HealthVault's ‘Documents (File)’ type. This too placed limitations on the user's ability to search and retrieve effectively.

Both CCR and CCD attempted to serve the same purpose of capturing a periodic episode of care. Google and Microsoft adopted two different approaches to constructing a longitudinal record from summary records. With Google Health, each incoming CCR was automatically parsed into discrete data elements. In Microsoft HealthVault, the user was required to manually select which data element, from the CCR or CCD, to store in the record by using a ‘reconcile’ process in the HealthVault user interface known as the HealthVault Shell.

Discussion

Lessons learned

In the development and implementation of the MiCARE pilot, we realized four lessons learned which may be useful to others considering PHR adoption.

Lesson #1

Data-transfer decisions (eg, push vs pull) are important and may influence system performance. We found that most of our MiCARE beneficiaries elected to transfer all of their health data into the PHR. Initially, the transfer of data occurred automatically as the data became available in the source system. However, the impact of substantial data transfer had a negative effect on the speed of the system which was not acceptable for the users. We made a decision during the pilot to eliminate automatic data transfer in favor of data transfer at the patient's request.

Lesson #2

Issues surrounding purposeful delays in reporting and the sensitive nature of some clinical data in PHRs should be thoughtfully considered and discussed with key stakeholders. Some healthcare organizations, for example, provide laboratory results in the PHR as soon as they are available. In MiCARE, our provider panel requested a 7-day delay in the release of clinical results to facilitate sufficient time for the provider to contact the patient and explain the results prior to publication. While this policy was in conflict with the beneficiary panel request for instant access to their health data, we perceived that by not adopting the wait period, we would negatively affect provider acceptance and adoption. Additionally, in the absence of state or federal regulation, our provider panel decided that lab results related to sexually transmitted diseases findings, pregnancy results, and positive cancer findings would require contact from the provider and not be released into MiCARE without the request of patient and provider concurrence.

Lesson #3

It is important to understand and map how the PHR may affect the providers' clinical workflow. Providers in our pilot found accessing the PHR to be a little disruptive in their clinical workflow. Feedback received from our provider panel included a recommendation to better integrate data from the MHS central data repository with PHR data to give a more complete view of individual patient records and a dashboard view of their patient panels for use in the provider's clinical workflow.

Lesson #4

Decisions on what a patient may choose to share with their provider in their PHR is worthy of consideration and debate. The ability of a patient to exclude PHR information from their provider may result in the participating provider making clinical judgments with incomplete information which could result in negative unintended consequences. For example, there could be serious cardiac complications if a patient who is on an antipsychotic agent decides to hold that information from their cardiologist prescribing treatment with an antiarrhythmic agent. This can create a tension between patient control of health information and patient safety, which in turn may have an unintended consequence of lower provider acceptance of the PHR as a useful tool.

Conclusion

Although the PHR is being viewed as an empowering tool for patients, adoption is limited in part due to implementation barriers. We have adopted a third-party interconnected PHR model that incorporates national CCD and CCR standards. By adopting these standards, MiCARE and similar PHRs can move closer toward realizing a national goal of a portability and interoperability. Additional work remains in the full implementation of standards by both Google and Microsoft in improving the usability for both patients and providers.

By leveraging Microsoft and Google storage and infrastructure, our MiCARE pilot offered beneficiaries readily available access to their health information and use of PHR functionalities in Google Health and Microsoft HealthVault, or from optional third-party applications (eg, data import from medical devices, health-risk assessment tools) provided by Microsoft and Google's partners. While our providers and patients agreed on the desirability of various PHR functionalities, they were conflicted with respect to certain implementation choices. A central challenge faced when moving beyond pilot to full-system implementation is the emerging tension between access to health information and organizationally adopted business practices.