Share via

Security whitepaper

Microsoft is committed to meeting the high security and service continuity demands of our healthcare clients.

Introduction

Microsoft Dragon Copilot brings together the trusted voice dictation capabilities of Dragon Medical One and the ambient listening capabilities of DAX Copilot with fine-tuned generative AI and healthcare-adapted safeguards. This unified experience integrates with EHRs and supports clinicians across all stages of their workflow. Part of Microsoft Cloud for Healthcare, it's an extensible AI workspace that's built on a secure modern architecture and helps promote clinician wellbeing, increase efficiency, enhance the patient experience, and drive meaningful financial impact.

Solution components

  • Dragon Copilot mobile – iOS app to record and review an encounter, surface information and automate tasks.

  • Dragon Copilot desktop – Windows app to record and review an encounter, surface information and automate tasks.

  • Dragon Copilot web – Browser-based app to record and review an encounter, surface information and automate tasks.

  • Dragon Copilot embedded – EMR partners can integrate Dragon Copilot capabilities to record and review an encounter, surface information and automate tasks directly in their EMR.

Built on Azure for security, compliance and resilience

Dragon Copilot provides enhanced security using Microsoft Azure, the world's largest multi-terabit global network, offering 24x7x365 high availability and guaranteed uptime of at least 99.9% by operating through a network of secure, redundant locations. There are 10 such locations within the continental United States, and many more in other regions. In the US, data is replicated between two data centers to keep data current. However, data never leaves a geography.

Azure meets HITRUST requirements. Specifically, the Microsoft Azure environment has been certified by the Health Information Trust Alliance (HITRUST®)1 as meeting the HITRUST Common Security Framework (CSF®), a set of industry-defined, risk-based and compliance-based security standards and controls tailored for the healthcare industry. This environment contains several layers of security and employs rigorous security standards and practices to ensure data privacy and security. These practices include protection against denial of service attacks, intrusion detection, routine penetration testing, and a red team approach to continually strengthen threat detection.

Microsoft Azure supports compliance efforts related to more than 65 national, regional, and industry-specific requirements governing the collection and use of individuals' data, including:

  • Health Information Trust Alliance (HITRUST)

  • Health Insurance Portability and Accountability Act (HIPAA)

  • International Standards including ISO 27001, ISO 27017, and ISO 27018

  • US Federal Risk and Authorization Management Program (FedRAMP)

  • Security Organization Controls (SOC I Type 1; SOC II Type 2, and SOC III Type 3)

  • EU and UK General Data Protection Regulation (GDPR)

  • Cloud Computing Compliance Controls Catalog (C5) - Germany

  • Health Data Hosting (HDS) – France

  • Cyber Essentials Plus - UK

A complete list can be found here: Compliance offerings for Microsoft 365, Azure, and other Microsoft services.

Committed to a high security standard

At Microsoft Healthcare and Life Sciences (HLS), we are deeply committed to maintaining a high security standard across all our operations. Our comprehensive approach encompasses robust governance controls, stringent physical and electronic access measures, and advanced authentication protocols. Here are some key aspects of our security framework:

  • Governance controls. Microsoft HLS has robust governance, risk management, compliance, continuity and recovery, and incident management procedures in place. These are kept under review and where appropriate, externally audited to ensure they meet recognized standards such as ISO27001.

  • Physical access. Microsoft HLS employees do not have or need physical access to Azure data centers. Microsoft uses advanced secure physical access methods, including biometrics, to secure its Azure data centers. We use dedicated hardened workstations for restricted access purposes to provide additional security.

  • Electronic access. Microsoft HLS is compliant with Microsoft privacy, security and compliance standards, which are designed to comply with industry standards and geographic requirements. For example, Microsoft HLS follows the HIPAA requirement of "minimum necessary" when granting electronic access to Microsoft HLS Data Center Operations team members within Microsoft Azure. Production file access in Azure is restricted to the Microsoft HLS Data Center Operations team and the Support Services teams.

  • Two-factor authentication/jump hosts. When electronically accessing the Azure environment, authorized personnel are required to use two-factor authentication for identity verification. Additionally, all production access is conducted via an intermediate jump host to provide an extra level of insulation that separates direct access to servers and prevents unauthorized access.

Dragon Copilot security and controls

Beyond Azure, Microsoft employs specific features and processes for Dragon Copilot components to help protect customer data. These are set out below. Additionally, Microsoft has rigorous controls to ensure AI is deployed responsibly. These are set out in our AI Transparency whitepaper.

Data collection and handling

Dragon Copilot transmits, processes, and stores encounter data, customer recordings, ambient speech recognition (ASR) text, and Natural Language Understanding (NLU) text. Dragon Copilot records the clinician and patient conversation and converts it to a structured patient encounter note.

The structured patient encounter note only documents the medically relevant information within the audio recording. When the clinician or patient says any protected health information (PHI) data elements, those elements are converted into text. Microsoft treats all customer data as though it is PHI, and we have a rigorous approach to handling data and to data privacy, as set out in our Data collection whitepaper and Privacy whitepaper.

Engineered for security

We prioritize the highest security standards. In practice, this means following a mix of industry-standard and Microsoft proprietary security frameworks such as the Microsoft Security Development Lifecycle (Microsoft SDL) and the Building Security in Maturity Model (BSIMM). Our SDL program provides secure design and implementation governance, potential identification and remediation of any security issues before new products are released, and rapid response by development teams should there be security issues discovered after release.

End-to-end data encryption

We apply many methods to ensure the highest level of data security. All recordings, documents, and other sensitive data are always encrypted both at rest and in transit. Here are the key additional measures related to data security:

  • Data in transit:

    • Transmitted securely via HTTPS using TLS 1.3 with an AES 256-bit cipher algorithm.

    • Data in the Dragon Copilot system - only the original clinician has access.

  • Audio capture and transmission:

    • Encrypted at the time of capture using standard public key cryptography before being sent to the secure Microsoft documentation service in the cloud with a standard RSA key (at least 4096 bits).

    • Private keys used to decrypt the data are known only to Microsoft HLS and are stored securely within the Microsoft environment.

    • During transit, audio is encrypted with a second layer of transport-layer encryption (TLS), using an AES block cipher (at least 256 bits).

  • Data in the Azure cloud:

    • Encrypted at rest using 256-bit AES encryption.

    • Encryption keys are managed by Microsoft.

  • Dragon Copilot mobile:

    • Audio data is encrypted per packet using libsodium secret stream (XChaCha20 with Poly1305 MAC) and stored on disk.

    • During upload, data is decrypted per packet in memory and uploaded over TLS 1.3 to DAX Core. Audio data is deleted after upload.

    • Metadata is encrypted using libsodium secret box (XSalsa20 stream cipher with Poly1305 MAC).

    • If upload connectivity is unavailable, recordings are encrypted locally and automatically uploaded, and deleted from the end user device, once connectivity is restored.

  • Dragon Copilot desktop and web:

    • Do not persist data.

These measures ensure that all sensitive data remains secure throughout its lifecycle.

Authentication and re-authentication

Dragon Copilot authenticates against the customer Entra ID (Azure AD) tenant using the OpenID Connect protocol.

For Dragon Copilot mobile, the screen 'black out' time will match whatever is set for all apps on the iOS device. For Dragon Copilot desktop and Dragon Copilot web, the screen "black out" time is determined by the operating system settings.

Audit

Audit logging includes details of date, time, user account (when applicable), event type, IP address and success or failure. Dragon Copilot system logs are protected against unauthorized access, modification and deletion, and Dragon Copilot systems log all authorized and unauthorized access attempts. Logs are read-only. Audit logs are stored in Azure application insights as well as ingested into the Azure Sentinel SIEM for security audit and review.

Data management

Dragon Copilot uses shared compute resources and dedicated storage. Customer data is stored in a customer-specific storage container inside a shared storage account, so each customer's data is segregated.

Data retention and usage

Consistent with secure data handling practices, data acquired during an exam is used for recognition purposes in-memory and is never stored in any unencrypted manner.

For more informaion on how Dragon Copilot manages data, see: Privacy whitepaper.

Scanning, vulnerability testing and perimeter security

Microsoft HLS uses a third-party service to conduct periodic penetration testing, and conducts internal and external scans to identify and address potential vulnerabilities.

Additionally, the Dragon Copilot system uses software firewalls to segment data, prevent unauthorized access, and monitor traffic for denial-of-service (DOS) attacks.

Restricted access

All Dragon Copilot end users have their own unique account. Dragon Copilot authenticates against the customer Entra ID (Azure AD) tenant using the OpenID Connect protocol.

The Microsoft HLS Data Center Operations team's access to data is based on the minimum necessary level and amount required to carry out job responsibilities.

High availability and service continuity

Dragon Copilot services are deployed in an active/active configuration, with continuous data replication between the Azure data centers. In the unlikely event of a data center failure, operations are rerouted to the alternate data center.

Within each data center, the system architecture of Dragon Copilot provides the following high-availability features:

  • Fully redundant network infrastructure, including load balancers and switches

  • Multiple clustered application servers

  • High-availability network storage with fiber-optic connections

  • Clustered backend servers

Customer responsibilities

While Microsoft makes every effort to secure its services, security is always a partnership. Customers are responsible for:

  • Maintaining secure devices (mobile and desktop)

  • Ensuring reliable connectivity (including wireless connectivity for mobile devices)

  • Installing OS updates in a timely fashion, especially critical security updates

  • Installing Dragon Copilot updates in a timely fashion

  • Deciding whether to use MDM to manage Dragon Copilot mobile, and if the customer chooses to do so, configuring the MDM settings for mobile devices, whether the devices are customer-supplied or clinician-owned. Microsoft suggests that clinicians do not share mobile devices but instead use their own or customer-provided device. The customer is responsible for device management.

Determining whether to grant Microsoft access to customer products or environments is not required but recommended for analysis and to support administrators and clinicians if needed. Microsoft may require remote access for troubleshooting and support purposes. We do not require ongoing access to the customer's system and no persistent connections are established. Customers are responsible for establishing and controlling remote access and support connections as needed.

Conclusion

At Microsoft, we are fully committed to an ever-advancing, defense-in-depth security strategy and corresponding controls intended to ensure that the healthcare data you entrust to us is kept private and protected. Our security practices, combined with a highly available and redundant infrastructure, are designed to provide your clinicians with the fast, secure, and uninterrupted service they expect—and your patients deserve.