EPIC and Microsoft 365: what works, what doesn't

EPIC keeps patient records in its own database, but clinicians need Microsoft 365 file access alongside their EMR session: reference documents, team collaboration files, shift-handover notes, personal OneDrive. On a shared clinical workstation with Imprivata tap-in/tap-out and (usually) a VDI backend, the OneDrive sync client is a poor fit for a stack of specific reasons. This piece walks through what breaks in a clinical setting, why, and how Cloud Drive Mapper provides real-time Microsoft 365 storage access inside an EPIC session without leaving patient information on the endpoint.

What breaks when EPIC clinicians run the OneDrive sync client?

Six patterns come up repeatedly across the healthcare providers we work with. They stack: any two of them together are usually enough to push a clinical team off the OneDrive sync client for good.

Persistent PHI cache violates data-handling policy

OneDrive sync mirrors files locally. On a shared clinical workstation, that means one clinician's OneDrive-cached files persist on disk after they tap out. Clinicians routinely save patient letters, discharge summaries and attachments to OneDrive, and any of that content that ends up cached locally is patient information at rest on a shared device. Most HIPAA-conscious organisations do not accept that arrangement, and rightly so.

Session start is too slow for tap-in workflows

Imprivata OneSign lets a clinician tap onto a workstation with their proximity badge and reach a live desktop in a couple of seconds. OneDrive's session-start sync process is not that fast. First-log-on churn as the sync client discovers changes since the last session (or worse, bootstraps from empty on a wiped session host) can run for minutes. In a busy ward environment, clinicians walk away and start again on the next workstation.

Non-persistent VDI is a permanent maintenance burden

Most EPIC estates run over Citrix, Azure Virtual Desktop or Omnissa Horizon on non-persistent session hosts. Even with FSLogix profile containers, the OneDrive sync client is a known pain point: container growth over time, sync loops on session start, and conflicts across multiple session hosts. See our companion piece OneDrive for Business in Citrix for the deep detail on why.

Multi-user workstations can't have OneDrive sync per user

A nursing station gets used by 20+ nurses across a shift. OneDrive's design assumes one user per Windows machine. On a shared clinical workstation you can have one shared OneDrive account (which loses individual accountability), or nobody gets OneDrive sync (and clinicians work around it, saving files to network drives or emailing themselves). Neither is a clean answer.

Files On-Demand hydration fails during time-sensitive workflows

A clinician tapping in to write up a patient case does not have time to wait for OneDrive to hydrate their reference documents. If the shift-handover template or the ward escalation checklist is a cached stub that needs to download before opening, the workflow stalls at exactly the wrong moment. Users experience this as OneDrive being unreliable, even though nothing is technically broken.

Local search index leaks across users

Windows Search indexes local OneDrive content by default. On a shared clinical workstation, that index can persist across tap-in and tap-out sessions if it is not aggressively wiped. If Nurse A's OneDrive contained files with patient names, Nurse B's Windows search on the same workstation can return hits from those files. Not what any information governance officer wants to hear.

Why the OneDrive sync client isn't built for clinical shared workstations

The mismatch is architectural. The OneDrive sync client assumes a persistent, single-user Windows machine that keeps a local mirror of the user's cloud files. Clinical workstations are the opposite: shared, often non-persistent, rapidly switched between users, and subject to strict rules about what can live on the local disk.

Add the PHI-at-rest concern on top: even where OneDrive works technically, the local caching model is not a fit for environments that need to be sure no patient information persists on a shared endpoint. Careful configuration reduces the risk without eliminating it, and "reduces without eliminates" is not the standard clinical governance operates to.

For the broader take on why sync clients struggle with applications and environments that need real filesystem guarantees, see Desktop applications and real file paths. EPIC clinical workstations are one of the sharpest cases; the same underlying mismatch affects the wider category of shared and kiosk-style clinical devices.

What are the fix options?

Three approaches. The first two are common in the field; the third is what this page is about.

Force clinicians to use the browser for M365 file access

Deny the sync client entirely, tell clinicians to open documents through the SharePoint browser or the Teams client. Works, avoids PHI-at-rest concerns, and produces poor UX. Clinicians work around it by emailing files to themselves or copying to network drives, which reintroduces exactly the governance problem you were trying to solve.

Configure OneDrive extremely carefully with per-workstation controls and FSLogix

Combine per-workstation OneDrive policy, aggressive cache-wipe scripts on tap-out, FSLogix containers for the sync client state, and profile-management controls to keep search indexes clean. Complex, fragile, and does not fully solve the PHI-at-rest problem because the sync client still caches files locally between the wipe cycles.

Use a drive-mapping approach (Cloud Drive Mapper)

Present SharePoint and OneDrive as real Windows drive letters that stream content on demand. No local cache, so no PHI at rest. Per-user mount on tap-in, unmounted cleanly on tap-out. Works on non-persistent VDI because there is nothing to bootstrap. This is the approach the rest of the page is about.

How Cloud Drive Mapper works with EPIC in clinical environments

CDM does not integrate with EPIC directly. What CDM does is make Microsoft 365 storage behave like a network drive inside the same Windows session EPIC is running in. Clinicians see EPIC in front of them, and their SharePoint sites and personal OneDrive as familiar mapped drives alongside it. Five specific things change.

No PHI on the endpoint

CDM streams file content on demand from Microsoft 365 and releases it after close. Nothing persists on the local disk. When a clinician taps out, there is no cached OneDrive folder waiting to be discovered by the next user or by a lost-laptop scenario. This is the single largest reason healthcare providers move to CDM.

Instant mount on tap-in

CDM mounts per-user at session start. When a clinician taps onto a workstation, their drive letters appear along with their desktop. When they tap out, the mount goes with the session. Compatible with Imprivata OneSign and similar rapid-context-switching workflows on ward PCs and workstations on wheels.

Works on non-persistent VDI

No local cache means nothing to bootstrap or reconcile across session resets. Whether the estate runs on Citrix Virtual Apps and Desktops, Azure Virtual Desktop, Windows 365 Cloud PC, or Omnissa Horizon, CDM behaves the same way: mount on login, release on logout, no growing container to manage.

Real drive letters visible from EPIC dialogs

EPIC's document upload dialogs, its Excel and Word integration, its report exports: all of these see Microsoft 365 storage as a real network drive when CDM is present. Clinicians attach a scanned consent form or export a report to SharePoint the same way they would to a traditional network share. No browser detours, no copy-and-paste workarounds.

Multi-user workstation supported natively

Each user's mount is per-user, per-session, per-credentials. Twenty nurses over a shift means twenty discrete sessions, each with its own mount, its own view of Microsoft 365 content, and no cross-user leakage between them.

EPIC-specific configuration notes

CDM does not sit inside EPIC and requires no changes to the EPIC deployment. What matters is the Windows session CDM lives in. A few things worth setting up correctly:

• Deploy CDM per Windows session, not per machine, so each user gets their own mount.
• Configure CDM to trigger its mount at Imprivata tap-in so the drives are ready when the clinician needs them.
• Map SharePoint document libraries to consistent drive letters (typically M:, N:, P:) so clinicians can find things across workstations.
• Verify EPIC's file dialogs see the mapped drives; test the document-upload and export paths as part of go-live.
• For information governance sign-off, walk stakeholders through the zero-access architecture underpinning CDM: no local cache, delegated permissions to the customer tenant, no IAM Cloud staff access to customer content by design.

CDM supports EPIC-adjacent workflows in the following deployment models:

• Windows desktops (direct)
• Citrix Virtual Apps and Desktops
• Citrix DaaS
• Azure Virtual Desktop (AVD)
• Windows 365 Cloud PC
• Omnissa Horizon (formerly VMware Horizon)

Cloud Drive Mapper is used across hospitals and healthcare providers to give EPIC clinicians clean Microsoft 365 file access without leaving patient information on the endpoint.

Frequently asked questions

Does Cloud Drive Mapper store patient information on the local device?

No. CDM streams file content on demand from Microsoft 365 and releases it after close. Nothing persists on the local disk. This is the design, and it is the primary reason healthcare providers choose CDM over the OneDrive sync client for shared clinical workstations.

Does CDM work with Imprivata tap-in and tap-out on shared clinical workstations?

Yes. CDM mounts per-user at session start. When one clinician taps out and another taps in, the previous user's mount unmounts and the new user gets their own. Compatible with Imprivata OneSign and similar rapid-context-switching workflows on ward PCs and workstations on wheels.

Does CDM interfere with EPIC Hyperspace or Hyperdrive?

No. CDM does not touch EPIC's local components, its Cache or IRIS database connection, or its browser-based Hyperdrive session. CDM provides mapped drive letters for Microsoft 365 storage on the same Windows session; EPIC operates against its own backend as it always has. The two run side by side.

Does CDM work on non-persistent Citrix, Azure Virtual Desktop, or Omnissa Horizon session hosts?

Yes. Because CDM does not maintain a persistent local cache, there is nothing to bootstrap or reconcile across session resets. Mounting is immediate at session start, which matters on non-persistent VDI where every login is effectively fresh. Most EPIC estates over Citrix, AVD or Horizon run CDM this way.

Can clinicians access their personal OneDrive as well as SharePoint sites through CDM?

Yes. CDM presents both a clinician's OneDrive for Business and any SharePoint document libraries they have access to as mapped drive letters. Clinicians typically get their personal OneDrive as one drive letter and shared team or ward sites as others, matching how they already think about the content.

Does CDM support HIPAA-conscious deployments?

CDM's architecture supports HIPAA data-handling requirements: no PHI at rest on the endpoint, delegated permissions to the customer tenant, no IAM Cloud staff access to customer content by design. HIPAA compliance for the operating organisation is always the operating organisation's responsibility; CDM does not sit outside the customer's tenant boundary in a way that would change that. See zero-access architecture for the design detail.

Related solutions

• Desktop applications and real file paths (the underlying problem class)
• OneDrive for Business in Citrix (many EPIC estates run over Citrix)
• Copilot readiness in VDI environments
• Zero-access architecture in Cloud Drive Mapper
• Cloud Drive Mapper for healthcare
• Case study: Respiratory Health Association

← Back to all solutions