Microsoft's global outage on November 12 and 13, 2026 left millions of organizations without email, collaboration or administration tools for about 18 hours. For the health sector the lesson is straightforward: if continuity of care depends on a single provider, or worse, on a mailbox, care stops when that provider stops.

This article summarizes what happened, how an event like this affects interoperability platforms, why email is not a valid channel for sharing clinical information, and which contingency strategies should be ready before the next incident.

What happened

On Thursday, November 12, at around 17:30 UTC (11:30 a.m. Costa Rica time), users around the world lost access to Outlook. Al Jazeera counted disruptions in 74 countries and territories. What began as an email and Teams failure escalated into a cloud crisis: consumer and business email, cloud files and documents, Copilot, Defender, the Intune admin consoles and some cloud-hosted Windows computers were all affected, according to TechCrunch.

ItemDetail
StartThursday 11/12/2026, around 17:30 UTC (11:30 a.m. Costa Rica time)
DurationAbout 18 hours until traffic began to return, according to Doug Madory of Kentik
Reach74 countries and territories. Microsoft has not confirmed how many users were affected
ServicesOutlook, Teams, Copilot, cloud files and documents, Defender, Intune and cloud-hosted Windows computers
CauseNo root cause report yet. Microsoft first pointed to a network update and later to a large number of servers becoming unavailable and overloading the rest
CyberattackMicrosoft says there is no evidence of malicious activity
Estimated economic impactUp to USD 7 billion in lost productivity, according to Anderson Economic Group, as cited by CNN

It is not an isolated case. Microsoft 365 had already suffered significant outages this year: on January 22 and 23, lasting about 10 hours in North America (The Register), and in late August and early September, lasting several days, which Microsoft attributed to a problem with its "core authentication configuration" (TechCrunch).

A health network whose dependencies live in a single cloud: when the cloud goes down, the hospital, laboratory, imaging center and pharmacy lose the patient's context
A health network whose dependencies live in a single cloud: when the cloud goes down, the hospital, laboratory, imaging center and pharmacy lose the patient's context

How it affects interoperability platforms

An interoperability platform (an HIE, a FHIR server, an enterprise master patient index or EMPI, a record locator service or RLS) can go down even while its own servers keep running, if any of its critical dependencies lives with the affected provider. The most common points of failure are these:

  • Identity and authorization. If the OAuth 2.0 / OpenID Connect authorization server, SMART on FHIR or the user directory depends on Microsoft Entra ID and Entra ID fails, no system can obtain tokens and every FHIR call returns 401, even though the FHIR server is up. The September outage, tied to authentication, showed exactly this pattern.
  • Infrastructure hosted in a single cloud. A FHIR server, database or message bus deployed in a single region or with a single provider inherits all of its outages, including DNS and network failures.
  • Shared support services. Terminologies (SNOMED CT, LOINC, ICD-10) served from a single endpoint, key and certificate managers, digital signatures, queues and monitoring. If the terminology server fails, resource validation and code mapping fail too.
  • Notifications and workflows. FHIR subscriptions, critical result alerts or referrals notified by email or Teams are lost silently: the data arrives, but nobody finds out.
  • Operations and security. Without the admin consoles (Intune, Defender) the technical team cannot see, isolate or recover devices; it works blind exactly when it most needs visibility.
  • Parallel processes on office tools. Patient lists, shift sheets, results in Excel or SharePoint and clinical coordination meetings become unavailable.

The clinical effect is the loss of the patient's context at the point of care: allergies, medications, recent results and pending referrals. In a care network, an 18-hour outage covers more than two full shifts.

Why email does not work for continuity of care

Email is a channel for communication between people, not a mechanism for exchanging clinical data. This outage made that clear: organizations that sent discharge summaries, results or referrals through Outlook had no access to that information while the failure lasted. Microsoft extended its retry window to 48 hours to preserve delayed mail, but preserving it is not the same as having it available when the care team needs it. The underlying reasons are these:

  1. Availability. The data is trapped in a mailbox. If the provider goes down, the data does not exist for the care team: there is no alternative route to retrieve it.
  2. Unstructured data. A PDF of laboratory results or a free-text imaging report is not integrated into the record, is not validated against a FHIR profile and does not use terminologies such as SNOMED CT or LOINC. It does not feed allergy or interaction alerts, and someone has to transcribe it, with all the risk of error that implies.
  3. Patient identification. There is no EMPI and no unique identifier: the attachment depends on the sender and the recipient typing the name and national ID number correctly. An identity error here is a patient safety risk.
  4. Security and privacy. An email gets forwarded, downloaded to personal devices and copied many times over. There is no role-based access control, no consent management and no log (AuditEvent) of who saw what, which is hard to reconcile with Costa Rica's Law 8968 on personal data protection and with the Health Interoperability Regulation.
  5. Traceability and integrity. There is no clinical acknowledgment of receipt, no versioning, no verifiable signature and no provenance (Provenance). It is impossible to prove which version of a result was used to make a decision.
  6. Discoverability. No other provider can find out that the document exists. Without an RLS or a document index, only the people copied on the email have the information.
  7. Concentration of risk. Email, chat, files and identity usually sit with the same provider. A single outage takes down the primary channel and the backup channel at the same time.

Email can be used as a notice ("a new result is available"), but clinical data must travel through standard channels (HL7 FHIR REST and IHE profiles such as MHD, XDS, PIXm or PDQm) to repositories with identity, consent and auditing.

The same laboratory result sent as an email attachment and as a structured FHIR resource: availability, identity, coding, auditing and signature
The same laboratory result sent as an email attachment and as a structured FHIR resource: availability, identity, coding, auditing and signature

Contingency strategies

The goal is not to prevent every outage, but to keep care going when one happens. It pays to work on four fronts at once.

Architecture

  • Decouple identity. A network-owned authorization server (OpenID Connect, SMART on FHIR) that federates with Entra ID or other identity providers but does not depend on them to issue tokens. That way, an outage at the corporate identity provider does not block the FHIR APIs.
  • Real redundancy. Multi-region or multi-cloud deployment, or a hybrid model with a local node of the FHIR server and the EMPI, with replication. One provider's outage must not take down the exchange.
  • Cache at the point of care. An International Patient Summary (IPS) or a minimal clinical summary of active patients, refreshed periodically, so allergies, medications and problems are available even without a network.
  • Asynchronous messaging. Persistent queues with retries (*store-and-forward*) and idempotent FHIR transactions, so nothing is lost and everything is reconciled when service returns.
  • Replicated terminology. A replicated terminology server and local terminology packages, to validate and code without depending on an external endpoint.

Operations

  • Out-of-band notification channels. SMS, messaging with another provider, telephone and status pages hosted outside the main cloud, to alert clinicians and technical staff when the usual channel is down.
  • **Emergency (*break-glass*) accounts.** Administrative access that does not depend on the same cloud, to operate and recover even when the consoles are down.
  • Synthetic monitoring and drills. Monitor clinical workflows end to end, not just servers, and practice the plan regularly.

Governance

  • Dependency map and business impact analysis (BIA). Recovery time and recovery point objectives (RTO/RPO) per clinical workflow and a continuity plan aligned with ISO 22301: know what goes down with which provider and how much can be tolerated.
  • Contracts. SLAs with compensation, root cause reports, and exit and data portability clauses, to reduce dependence on a single provider.
  • Institutional policy. Apply the Health Interoperability Regulation and the National Implementation Guides, and state in writing that email is not a channel for clinical data.

Clinical

  • Contingency procedures. Paper or offline forms for referrals, orders and results; critical results are communicated by phone with read-back verification.
  • Reconciliation afterwards. Enter into the system everything recorded during the contingency, with its provenance, so the record is complete and traceable.
The first three steps for a health network: separate identity, keep a backup node and practice the plan
The first three steps for a health network: separate identity, keep a backup node and practice the plan

For a national or regional network, the three first steps with the highest return are separating identity from the office-suite provider, keeping a backup node of the FHIR server and the EMPI outside the main cloud, and practicing the contingency plan with clinical teams at least twice a year.

Conclusion

The Microsoft outage was not a health problem, but it exposed a health risk: when clinical information depends on a mailbox or a single provider, continuity of care depends on that provider's availability. Standards-based interoperability (HL7 FHIR, IHE and shared terminologies) does more than let us share data; it also makes it possible to design networks that withstand failures, with their own identity, redundancy, queues and clinical backup procedures.

With PRIS+ under way, Costa Rica is defining how its institutions will connect. This is the moment to make resilience part of that design from the start.

The question for every institution and every care network is concrete: if the main provider goes down for 18 hours tomorrow, what clinical information remains available at the point of care, and how will what is recorded in the meantime be recovered? Answering it before the next incident is part of quality and patient safety.

How Meddyg can help

At Meddyg we help health institutions, laboratories and imaging centers stop using email as a channel for clinical data and build interoperability that keeps working when a provider fails. We work with HL7 FHIR, IHE profiles, OpenHIE and terminologies such as SNOMED CT, LOINC and ICD-10, aligned with Costa Rica's national implementation guides.

  • Continuity assessment. We map the dependencies of your clinical workflows (identity, email, cloud, terminologies), identify single points of failure and propose a contingency plan with recovery objectives for each workflow. It is part of our interoperability assessment.
  • Laboratory results without email. We turn the laboratory report into a structured FHIR document, coded with LOINC and digitally signed with Costa Rica's national digital signature (Firma Digital de Costa Rica) through Kivú eSignature before it is stored. The result reaches the record and the care team with verifiable integrity, instead of a PDF attachment that someone has to transcribe. We also map test catalogs to LOINC with Kivú Terminology.
  • Interoperable medical imaging reports. We take part in building the HL7 FHIR guide for medical imaging reports in Costa Rica and offer Kivú RIS and Kivú PACS, which integrate DICOM and FHIR so the study and its report are available to the care network, not in an email or on a disc.
  • Resilient exchange platform. Our health information exchange platform, built on Kivú FHIR, includes a FHIR server, an enterprise master patient index (EMPI with PIXm, PDQm and PMIR), a record locator service (RLS) and a community-owned authorization server (OAuth 2.0 / OpenID Connect, IHE IUA) that does not depend on the office-suite provider to grant access. It can be deployed in the cloud, on premises or in a hybrid model. See our HIE integration service.
  • Auditing, consent and provenance. Every access and every document is recorded with AuditEvent and Provenance, with patient consent management.
  • Support and drills. We train technical and clinical teams and help them practice the contingency plan.

If your institution currently shares results, reports or referrals by email, let's talk. Write to us and we will review together where to start.

Sources