Skip to main content

Microsoft HealthVault: Twelve Years, One Shutdown Email, and a Lesson Health Care IT Keeps Relearning

A depiction of a Vault opening with XML and data floating out

In early April 2019, people who had signed up for a Microsoft service years earlier got an email that was short, polite, and final. "Data you have in your HealthVault account will be deleted effective November 20, 2019." Export it or lose it. Applications that depended on the platform would stop working. If you used one, Microsoft suggested you contact the developer.

That was the end of Microsoft HealthVault, a personal health record platform that launched with real ambition, real money, and a genuinely good technical design. It ran for twelve years and then went away on a seven month notice period.

It is worth understanding what HealthVault was and why it died, because the specific failure was a consumer product failure, but the general failure is one that shows up in health care IT departments every year. A platform holds data you cannot regenerate. The platform goes away. What happens next depends entirely on decisions you made before you got the email.

The Pitch: A Record the Patient Controlled

Microsoft announced HealthVault on October 4, 2007, at an event in Washington, D.C. (You will occasionally see 2009 given as the launch year, including in some tech press coverage of the shutdown. That appears to reflect the end of the extended beta period, not the launch. Microsoft's own launch materials and contemporaneous coverage are dated October 2007.)

The product came out of Microsoft's Health Solutions Group, led by corporate vice president Peter Neupert. That group built two things: Amalga, a clinical data aggregation platform aimed at hospitals and health systems, and HealthVault, the consumer side.

HealthVault was not an EHR and was not really a personal health record application either. It was a platform. Microsoft ran the account system, the record store, and the authorization model, and third parties built applications on top of it. A patient created an account, and that account could hold multiple records, which meant a parent could manage a child's data or an adult child could manage a parent's. Applications requested access to specific data types, and the patient granted or denied that access at a granular level.

The technical design held up well for its era. Data was stored as typed items with XML schemas rather than as blobs. The platform supported import and export of ASTM Continuity of Care Record and HL7 Continuity of Care Document formats, which were the interoperability standards available before FHIR existed. There was DICOM support for imaging. A piece of Windows software called HealthVault Connection Center handled device connectivity for blood pressure cuffs, scales, and glucose meters, which in 2007 meant plugging the device into a PC. Microsoft published SDKs and ran a developer center and an application registration process.

Privacy was designed in rather than bolted on. Microsoft worked with the Coalition for Patient Privacy during development, prohibited onward transfer of data without explicit consent, and kept the authorization decision with the individual. For a company that was, at the time, not universally trusted with personal data, that was a deliberate and reasonably successful effort.

Launch partners included the American Diabetes Association, the American Heart Association, Allscripts, Johnson & Johnson, and Home Diagnostics, among others.

Building an Ecosystem That Never Reached Critical Mass

Microsoft understood that a platform with no applications is a database nobody uses, and it spent accordingly.

At HIMSS in February 2008, the company announced the HealthVault Be Well Fund, a $3 million grant program for nonprofit research organizations building tools on the platform, capped at $500,000 per proposal. Nearly 200 proposals came in, which Microsoft described as one of the most successful requests for proposals in Microsoft Research history. In May 2008 the company raised the fund to $4.5 million, and in June it named 15 recipients working on medication reconciliation, childhood obesity intervention, family health history capture, remote weight and food intake monitoring, and diabetes management. Recipients included Intermountain Healthcare's Clinical Genetics Institute and the Jean Mayer USDA Human Nutrition Research Center on Aging at Tufts.

Internationally, Canada came online through a partnership with Telus. In January 2010, Microsoft and Siemens signed a licensing agreement making Siemens IT Solutions and Services the exclusive operator of HealthVault in Germany, with data hosted in German datacenters. Germany was the third country and the first in Europe. The German offering launched at Medica in November 2010 under the name Assignio. The United Kingdom followed in June 2010 through MSN Health & Lifestyle.

The U.S. Surgeon General's office integrated its My Family Health Portrait tool with HealthVault in February 2010. That is not a small partner.

None of it was enough.

Why It Failed

Microsoft never published a detailed post-mortem, but the reasons are not mysterious, and the company said some of them out loud while the product was still running.

The revenue model did not work. At launch, Neupert explained that Microsoft expected to fund the free service by growing overall health search activity and monetizing search advertising. By November 2010, that had been abandoned. The Financial Times reported that Microsoft had decided not to charge U.S. users directly and had also decided against pursuing advertising or other third party revenue for HealthVault within the United States, citing the complexity and fragmentation of the U.S. health information market. A high assurance health data platform is expensive to operate. Free plus no advertising plus no direct charges is not a business.

The chicken-and-egg problem never resolved. Providers and EHR vendors had little incentive to build deep bidirectional integration until large numbers of their patients used HealthVault. Patients had little incentive to maintain a separate record that required manual entry and a PC-tethered device sync when the clinical data flow was thin. Standalone utility was modest, and the network effects that would have made it valuable never arrived.

The market moved underneath it. HealthVault was designed for a browser and a desktop PC in 2007. Smartphones, native health apps, and wearables changed what "always available" meant. Meanwhile, Meaningful Use pushed providers into EHRs and provider-tethered patient portals, and portals turned out to be where patients actually went, because that was where their data already was.

Google Health, launched in 2008, hit the same wall faster. Google announced its shutdown in June 2011, retired the service on January 1, 2012, and deleted remaining data a year later. Google's own explanation was that adoption stayed limited to tech-savvy patients, caregivers, and fitness enthusiasts and never became a daily habit for large numbers of people. When Google Health closed, one of the migration options it pointed users toward was HealthVault.

And Microsoft's strategy changed. The company wound down Microsoft Band hardware, ended the Microsoft Health Dashboard and its companion apps on May 31, 2019 with data deletion on that date, and discontinued the HealthVault Insights research apps in January 2018. The center of gravity moved to enterprise cloud, Azure health services, and analytics applied to provider and payer data. HealthVault was the last significant piece of the original consumer health strategy still standing, and then it was not.

The Part That Matters for Compliance: HIPAA Did Not Apply

Here is the detail that gets glossed over in most retrospectives and that is directly relevant to how you evaluate patient-facing technology today.

Microsoft was not a covered entity or a business associate with respect to HealthVault data that patients put there themselves. HealthVault operated under Microsoft's own privacy policy and contractual commitments, not under 45 CFR Part 164. When a patient exercised their right of access under 45 CFR 164.524 and had records sent to their HealthVault account, the protected health information stopped being PHI in the regulatory sense the moment it landed in a record the patient controlled. Microsoft's privacy design was good, but it was voluntary.

The federal backstop for that situation is the FTC Health Breach Notification Rule, created by Congress in the HITECH Act and issued by the FTC in 2009. It applies to vendors of personal health records and related entities that are not covered by HIPAA, and it requires notification to individuals, to the FTC, and in some cases to media outlets after a breach of unsecured PHR identifiable health information. The FTC amended the rule effective July 29, 2024 to make clear that health apps, connected devices, and similar direct-to-consumer technologies fall within scope, and to require FTC notification at the same time as consumer notification for breaches affecting 500 or more records.

This matters right now because of information blocking. Under the 21st Century Cures Act regulations, if a patient directs you to send their electronic health information to a third party app through certified API technology, you generally cannot refuse on the grounds that you have not vetted the app's security. ONC has been explicit about this: security vetting of patient-chosen apps that receive EHI through a certified Standardized API is likely to be interference under the information blocking rules, because those apps are receiving read-only data at the patient's direction and pose little risk to your systems. ONC has also stated that a business associate agreement is not needed for third party apps individuals choose to receive their own EHI, which is worth knowing if someone in your organization has been asking app developers to sign one.

What you can do is give patients factually accurate, unbiased information about an app's privacy and security practices, applied in a non-discriminatory way across all apps rather than selectively. That is the lever you have. Use it, and document that you use it consistently.

What Replaced It

The functional successor to what HealthVault was trying to do is not a product. It is regulation plus standards.

FHIR-based patient access APIs, required through ONC certification criteria, moved the data flow problem from "convince a vendor to build an integration" to "the EHR must expose a standardized API." Apple Health Records demonstrated in 2018 that aggregation works when it rides on those APIs rather than on a separate manual record.

The Trusted Exchange Framework and Common Agreement is the network layer. TEFCA formally launched in 2022, designated its first Qualified Health Information Networks in December 2023, and has scaled quickly. In a June 26, 2026 announcement, ONC reported that exchange volume through the TEFCA network had grown from 10 million records to more than 1 billion in under a year and announced additional compliance reviews of QHINs and their participants.

HealthVault's technical instincts were largely right. Typed data, standards-based interchange, granular patient authorization, and open developer access are all features of the current model. What HealthVault lacked was a legal mandate forcing the data to flow and an economic model that survived the wait.

What This Means for Your Environment

Strip away the consumer product story and HealthVault is a case study in platform exit risk. A vendor holds data. The vendor makes a strategic decision that has nothing to do with you. You get a notice period.

For a 25-bed Critical Access Hospital running a handful of servers with one or two people covering all of IT, the practical work is not complicated, but it does have to actually get done.

Start with an inventory of every system holding data you cannot regenerate from another source. Not every system, just the ones where the vendor's copy is the only copy. Patient engagement platforms, secure messaging archives, telehealth session records, remote monitoring data, credentialing systems, policy management tools, and imaging archives all tend to land on this list. Cloud-hosted departmental systems that a clinical department bought without going through IT belong there too, if you can find them.

For each one, answer three questions. What is the export format, and is it something you could actually read in five years? Who holds the credentials to run the export? When did you last run one and open the file?

That last question is where most organizations fail. Confirming that an export button exists is not the same as confirming that the export works, produces complete data, and yields something usable. Pick one platform per quarter, run a full export, and then actually open the output. Confirm the record types you care about are present, not just that a file downloaded. Pull five records at random and compare them against what the live system shows. Write down the date and what you checked. That is four exports a year and a few hours of work.

The HIPAA Security Rule already asks you to do a version of this exercise. The contingency plan standard at 45 CFR 164.308(a)(7) includes a data backup plan as a Required implementation specification, and the regulatory language is specific: create and maintain retrievable exact copies of electronic protected health information. A SaaS platform where the vendor's tenant is your only copy does not satisfy that on its face. The same standard includes an applications and data criticality analysis at 164.308(a)(7)(ii)(E), which is Addressable. Under 45 CFR 164.306(d)(3), Addressable means you assess whether the specification is a reasonable and appropriate safeguard in your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure if that alternative is reasonable and appropriate. Addressable has never meant optional.

HHS has proposed changes that would eliminate the Addressable designation entirely and make every implementation specification Required. As of this writing that rulemaking (RIN 0945-AA22) is still just a proposal. The NPRM was published in the Federal Register on January 6, 2025, the comment period closed March 7, 2025, and HHS has since moved final action to the Long-Term Actions section of the Unified Agenda with a July 2027 target. A coalition of provider organizations has asked HHS to withdraw it. Unified Agenda dates are planning estimates, not deadlines, and none of the proposed requirements are enforceable today. The current Security Rule is what OCR is enforcing.

Contracts are the other half. The business associate provisions at 45 CFR 164.504(e)(2)(ii)(J) require the business associate, at termination of the contract, to return or destroy all PHI it still maintains and retain no copies. Note the qualifier in the regulation: if feasible. If return or destruction is not feasible, the business associate extends the protections of the contract to the information and limits further uses and disclosures to the purposes that make return or destruction infeasible. That is a real escape hatch, and it is the vendor's to invoke. The provision says nothing about format, nothing about timeline, and nothing about who pays for the extraction. Those terms belong in your contract, not in your assumptions. Ask for them at renewal, when you have leverage, rather than during a wind-down, when you have none.

And keep in mind that your documentation retention obligation does not travel with the vendor. 45 CFR 164.316(b)(2)(i) requires retaining required documentation for six years from creation or from the date it was last in effect, whichever is later. If your risk analysis, policies, or security incident records live in a vendor portal and that vendor shuts down, the six years is still yours to satisfy.

HealthVault gave its users about seven months. That was reasonable by industry standards, and it was still not enough time for anyone who had not thought about it in advance. The vendors in your environment right now are not obligated to do better.

Do This Now
Platform Exit Risk: A One Hour Checklist

Work through this for every system where the vendor's copy of your data is the only copy. If you only have time for one system, start with the one a clinical department bought without telling IT.

  1. Name the data you cannot regenerate. Not every system. Only the ones where losing the vendor means losing the record.
  2. Identify the export format. CSV, PDF, XML, CCDA, FHIR bundle, or proprietary. Ask whether you could open it in five years without the vendor's software.
  3. Confirm who holds the credentials. If the only account with export rights belongs to someone who left in 2023, you do not have an export capability.
  4. Actually run the export. Open the file. Spot check it against what is in the live system. Write down the date you did it.
  5. Read the termination clause. 45 CFR 164.504(e)(2)(ii)(J) requires return or destruction of PHI at contract termination if feasible. It says nothing about format, timeline, or who pays. Those go in your contract.
  6. Put it on a calendar. One platform per quarter. Four exports a year is a realistic target for a one person IT department.

Related Security Rule provisions: 45 CFR 164.308(a)(7)(ii)(A) data backup plan (Required), 164.308(a)(7)(ii)(E) applications and data criticality analysis (Addressable), and 164.316(b)(2)(i) six year documentation retention.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

Primary Microsoft and government announcements

  • Microsoft, "Peter Neupert: Microsoft HealthVault Launch," Washington, D.C., October 4, 2007: https://news.microsoft.com/speeches/peter-neupert-microsoft-healthvault-launch/
  • Microsoft, "Microsoft Launches Fund to Enable Patient-Centric Health Solutions," February 25, 2008: https://news.microsoft.com/source/2008/02/24/microsoft-launches-fund-to-enable-patient-centric-health-solutions/
  • Microsoft, "Microsoft HealthVault Be Well Fund Increased to $4.5 Million," May 28, 2008: https://news.microsoft.com/source/2008/05/28/microsoft-healthvault-be-well-fund-increased-to-4-5-million/
  • Microsoft, "Microsoft HealthVault Be Well Fund Recipients Named," June 10, 2008: https://news.microsoft.com/2008/06/10/microsoft-healthvault-be-well-fund-recipients-named/
  • Microsoft, "Siemens Signs Agreement to License Microsoft HealthVault," January 28, 2010: https://news.microsoft.com/2010/01/28/siemens-signs-agreement-to-license-microsoft-healthvault/
  • Microsoft, "U.S. Surgeon General Announces Connection with Microsoft HealthVault," February 24, 2010: https://blogs.microsoft.com/blog/2010/02/24/u-s-surgeon-general-announces-connection-with-microsoft-healthvault/
  • Microsoft Support, "End of support for the Microsoft Health Dashboard applications and services: FAQ": https://support.microsoft.com/en-us/help/4467073/end-of-support-for-the-microsoft-health-dashboard-applications

Contemporaneous reporting

  • Windows Central, "Microsoft HealthVault service shutting down on November 20," April 5, 2019: https://www.windowscentral.com/microsoft-healthvault-service-shutting-down-november-20
  • MedCity News, "Microsoft HealthVault is officially shutting down in November," April 2019: https://medcitynews.com/2019/04/microsoft-healthvault-is-officially-shutting-down-in-november/
  • IEEE Spectrum, "Microsoft Abandons Hope of Making Profits on HealthVault Personal Health Record Product in US" (summarizing Financial Times reporting): https://spectrum.ieee.org/microsoft-abandons-hope-of-making-profits-on-healthvault-personal-health-record-product-in-us
  • IEEE Spectrum, "Google Health to Shut Down 1 January 2012": https://spectrum.ieee.org/google-health-to-shut-down-1st-of-january-2012
  • TechCrunch, "Google Shuts Down Medical Records And Health Data Platform," June 24, 2011: https://techcrunch.com/2011/06/24/google-shuts-down-medical-records-and-health-data-platform/
  • Digital Health, "Siemens launches Assignio PHR," November 2010: https://www.digitalhealth.net/2010/11/siemens-launches-assignio-phr/

Regulatory and standards materials

  • 45 CFR Part 164, eCFR: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
  • Federal Register, "HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information," January 6, 2025 (RIN 0945-AA22): https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information
  • Clark Hill, "HIPAA Security Rule Update Delayed Until 2027," July 2026: https://www.clarkhill.com/news-events/news/hipaa-security-rule-update-delayed-until-2027/
  • Federal Trade Commission, "FTC Finalizes Changes to the Health Breach Notification Rule," April 26, 2024: https://www.ftc.gov/news-events/news/press-releases/2024/04/ftc-finalizes-changes-health-breach-notification-rule
  • Federal Register, "Health Breach Notification Rule," 16 CFR Part 318, May 30, 2024: https://www.federalregister.gov/documents/2024/05/30/2024-10855/health-breach-notification-rule
  • ONC, Information Blocking FAQ on third-party app vetting: https://www.healthit.gov/faq/if-actor-requires-third-party-applications-apps-be-vetted-them-security-reasons-allowing
  • ONC, "Application Programming Interfaces," Certification Companion Guide: https://www.healthit.gov/condition-ccg/application-programming-interfaces
  • ONC, TEFCA program page: https://healthit.gov/policy/tefca/
  • HHS, "HHS Expands Secure Access to Health Records Through the TEFCA Network, Announces Milestone of One Billion Health Records Exchanged," June 26, 2026: https://www.hhs.gov/press-room/onc-strengthens-tefca-one-billion-health-records-exchanged.html

About the Author

Health Tech Authority Editorial Team

Health Tech Authority is a publication covering the technology side of health care organizations. We exist for the people in the mix - the systems administrators keeping servers online at 2 AM, the network engineers segmenting clinical VLANs on a shoestring budget, the security officers trying to hold the HIPAA line with half the resources a comparably sized non-health care organization would have, and the IT managers and administrators making technology decisions that directly affect patient care.

Content published under this account represents collaborative editorial work produced by the Health Tech Authority team. That includes original reporting, technical analysis, regulatory coverage, and practitioner-focused guidance across our core coverage areas: infrastructure and systems administration, networking, security and compliance, cloud and Microsoft 365 administration, clinical systems and health data, and the broader technology landscape serving health care organizations.

We cover what health care IT professionals actually need to know, written in a way that respects both their time and their intelligence. No fluff, no vendor press release rewrites, no thought leadership buzzword soup - just straightforward coverage of the systems, tools, and decisions that keep health care organizations running.

If you have a topic suggestion, a correction, or want to contribute, reach out through the Contact page.