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

SOLUTION GUIDE

MEDITECH keeps patient records in its own database, but clinicians need Microsoft 365 file access alongside the EHR: reference documents, team collaboration files, shift-handover notes, personal OneDrive. On a shared clinical workstation with rapid tap-in/tap-out and (usually) a Citrix or wider VDI backend, the OneDrive sync client is a poor fit for a stack of specific reasons. This piece walks through what breaks in a MEDITECH-hosted environment, why, and how Cloud Drive Mapper provides real-time Microsoft 365 storage access alongside MEDITECH Expanse or MEDITECH 6.x without leaving patient information on the endpoint.

What breaks when MEDITECH clinicians run the OneDrive sync client?

Six patterns come up across community and mid-size hospitals running MEDITECH. Any two of them together are usually enough to push a clinical IT team off the OneDrive sync client for good, and the constrained IT resource typical of MEDITECH-era hospitals makes the maintenance overhead of trying to make it work particularly hard to justify.

Persistent PHI cache on shared workstations

OneDrive sync mirrors files locally. On a shared clinical workstation, one clinician's OneDrive-cached files persist on disk after they log out or 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. Community hospitals with tighter information-governance resource are the ones most exposed to this risk.

Session start is too slow for tap-in workflows

Where Imprivata OneSign or similar rapid-context-switching is in play, a clinician taps onto a workstation with their proximity badge and reaches 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. Clinicians walk away and start again on the next available workstation.

Non-persistent VDI is a permanent maintenance burden

MEDITECH 6.x over Citrix Virtual Apps and Desktops is a very common deployment; MEDITECH Expanse is more browser-based but the wider VDI estate a hospital runs around it is not. 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, conflicts across multiple session hosts. See our companion piece OneDrive for Business in Citrix for the deep detail.

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

A reception desk at an ambulatory clinic, or a nursing station on a ward, gets used by dozens of people 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 staff 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 encounter 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.

Local search index leaks across users

Windows Search indexes local OneDrive content by default. On a shared clinical workstation, that index can persist across sessions if it is not aggressively wiped. If the previous user's OneDrive contained files with patient names, the next user's Windows search on the same workstation can return hits from those files. Not something 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, whether MEDITECH Expanse over browser or MEDITECH 6.x over Citrix, 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. MEDITECH clinical workstations sit in the same underlying pattern as our companion EPIC and Microsoft 365 piece; both EHRs face the same shared-workstation, VDI-heavy, PHI-conscious environment.

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 or log-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. In community-hospital IT teams with constrained resource, this is a maintenance load that quickly overruns capacity.

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 MEDITECH in clinical environments

CDM does not integrate with MEDITECH directly. What CDM does is make Microsoft 365 storage behave like a network drive inside the same Windows session MEDITECH is running in. Clinicians see their EHR 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 or logs off, there is no cached OneDrive folder waiting to be discovered by the next user. For MEDITECH-hosted community hospitals this is often the deciding factor.

Instant mount on tap-in or log-in

CDM mounts per-user at session start. Clinicians' 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, workstations on wheels and ambulatory clinic workstations.

Works on non-persistent VDI

No local cache means nothing to bootstrap or reconcile across session resets. Whether MEDITECH 6.x runs over Citrix Virtual Apps and Desktops, or the wider hospital estate runs on 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 MEDITECH dialogs

MEDITECH's document upload dialogs, its Excel and Word integration for reporting, its exports for downstream analysis: all 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.

Multi-user workstation supported natively

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

MEDITECH-specific configuration notes

CDM does not sit inside MEDITECH and requires no changes to the MEDITECH 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.
Where Imprivata OneSign or similar SSO is in use, configure CDM to trigger its mount at tap-in so drive letters 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 MEDITECH'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 MEDITECH-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 community and mid-size hospitals to give MEDITECH clinicians clean Microsoft 365 file access without leaving patient information on the endpoint.

Start a 30-day free trial How Cloud Drive Mapper works →

Frequently asked questions

Does Cloud Drive Mapper work with MEDITECH Expanse and MEDITECH 6.x (Client/Server)?

Yes. CDM does not integrate with MEDITECH directly and does not touch MEDITECH's local components or its MDBMS backend. It provides mapped drive letters for Microsoft 365 storage on the same Windows session that MEDITECH Expanse (via browser or thick client) or MEDITECH 6.x (via Citrix or direct) is running in. The two run side by side.

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. For MEDITECH-hosted community and mid-size hospitals, that is the single largest reason to move off the OneDrive sync client on shared clinical workstations: no cached patient information waiting to be discovered by the next user or by a lost-laptop scenario.

Does CDM work with Imprivata tap-in and tap-out on MEDITECH-hosted 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 across the ward PCs, workstations on wheels and reception stations common in MEDITECH environments.

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. This matters most for MEDITECH 6.x deployments over Citrix, which is a very common pattern; the same behaviour applies to Azure Virtual Desktop, Windows 365 Cloud PC and Omnissa Horizon.

Does CDM cause any changes to how MEDITECH itself is deployed?

No. CDM sits alongside MEDITECH on the same Windows endpoint. It does not require changes to the MEDITECH deployment, its database configuration, its identity model, or its patient-portal integration. Adding CDM to an existing MEDITECH estate is an endpoint-side change, not an EHR-side change.

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.

Get started with Cloud Drive Mapper

The fastest way to see if CDM fits your MEDITECH clinical workstations is to try it for 30 days, free. Deploy to a single test session host, prove the tap-in mount behaviour, then roll out.

Start a free trial Request a demo