Why a healthcare workplace suite is different from a generic rollout
A hospital or health authority that wants a self-hosted workplace should first define the boundary that ePHI must stay inside, then choose platforms that can be placed within it. The boundary comes before the product. Under the HIPAA Security Rule (45 CFR Part 164 Subpart C), covered entities (health plans, health care clearinghouses and covered health care providers) and their business associates must protect all electronic protected health information they create, receive, maintain or transmit. That reaches files synced to laptops, mail with patient details, chat threads about a referral and wiki pages with care pathways. In the EU, the picture adds GDPR and NIS2, where Annex I lists health as a sector of high criticality. In Germany, the TI-Messenger rollout is a separate integration decision for any chat tool that touches the telematics infrastructure. Confirm with your data protection officer and, where it applies, your national health authority which of these regimes covers each data flow before you select components.
On platforms, the short answer is this. For an integrated public-health workplace in Germany or the EU, openDesk bundles Nextcloud, Element, OpenProject, Collabora, Jitsi and other components under one identity layer, and it is the natural starting point. Where files and office documents dominate, a Nextcloud-centred stack is often simpler to scope, with mail, chat, video and wiki selected per boundary rather than as a bundle. Expect to test each component against the same questions: where data is stored, which identity source authenticates users, what audit records it produces, and who can administer it. Note that there is no HIPAA certification. HHS states that no Security Rule standard requires certifying compliance, so this page prepares the systems, controls and evidence that an auditor or assessor will examine. It does not issue attestations, and an independent assessor or certification body must judge the result.
Which healthcare rules shape the build
This table maps each healthcare rule to what it asks for in a self-hosted workplace suite and the build decision it drives. Read each row as a design input to settle before tenant layout, identity and logging are fixed. The main takeaway is that most obligations land on identity, transport, logging and vendor contracts rather than on the software choice alone.
| Rule or requirement | What it asks for | What it means for the build |
|---|---|---|
| HIPAA Security Rule scope (45 CFR 164.302) | Applies to covered entities and business associates for all ePHI they create, receive, maintain or transmit | Map which files, mail and chat channels carry ePHI and decide whether they sit in a separate tenant, instance or storage zone |
| Transmission security (45 CFR 164.312(e)(1)) | Technical measures guarding against unauthorized access to ePHI sent over electronic networks | Enforce TLS on mail, chat, file sync and office links, and confirm that federation and external sharing paths are covered |
| Audit controls (45 CFR 164.312(b)) | Mechanisms that record and examine activity in systems holding ePHI | Decide which file, chat and admin events are logged, where logs are stored and who reviews them |
| Unique user identification (required implementation specification) | Each user is tracked with a unique identifier | Use one identity provider with no shared accounts, and confirm clinical staff and contractors each get a traceable identity |
| Emergency access procedure (required implementation specification) | A documented way to reach ePHI during an emergency | Define break-glass administrator accounts, their monitoring and how access is revoked after use |
| Automatic logoff and encryption (addressable specifications) | Session timeout and encryption at rest and in transit, applied where reasonable and appropriate | Set session timeouts for shared workstations and document the encryption choice for each storage backend, or the reason for an alternative |
| Business associate contracts (45 CFR 164.314(a)(2)(i)) | Vendor must comply with the Security Rule, flow terms to subcontractors handling ePHI, and report incidents | Ask the implementation partner and any hosting or support vendor to sign terms that cover the full subcontractor chain, including backup and SMTP relays |
| Pending Security Rule revision (90 FR 898) | Proposed stronger cybersecurity requirements; no final rule as of October 2026, final action projected July 2027 | Design controls such as MFA, asset inventory and backup testing so they can be evidenced under either the current or revised rule |
| NIS2 Annex I, health sector | Healthcare providers and certain health manufacturers are listed as sectors of high criticality | Check with counsel whether your organization falls in scope and plan supply chain, access control and incident handling evidence |
| GDPR Articles 32 and 34 (CNIL fine, 3 September 2026) | Appropriate security of processing and notification of data subjects; the CNIL fined Hopital Prive de la Loire EUR 500,000 for external access without VPN or MFA and access ignoring need to know | Enforce VPN and MFA for remote clinicians and limit access to patient-related content by care team membership |
| EHDS, Regulation (EU) 2025/327 | Framework for health data access, exchange and use across the EU | Confirm with your health authority which data exchange interfaces apply and keep them separable from general workplace collaboration |
Where ePHI enters the workplace suite
Patient information reaches a workplace suite through ordinary work, not through one obvious system. A clinician attaches a discharge letter to an email, drops a referral into a shared folder, mentions a patient by name in a chat thread, records a case conference in a meeting, or copies a clinical protocol into a wiki page that happens to include a worked example. Under the HIPAA Security Rule, every one of those flows is ePHI the moment it is created, received, maintained or transmitted by a covered entity or business associate (45 CFR 164.302). The first task is to list these flows for your organization, because the Security Rule applies to the data wherever it lands, not to the application that carried it.
The larger risk sits in copies, notifications and external guests rather than in any single component. A file shared with a link becomes a second copy in a sync client, a preview cache and a mobile device. A chat notification can show a patient name on a lock screen. A recording stored in a meeting tool can outlive the clinical reason for the call. An external consultant or lab invited as a guest may hold access that nobody reviews. The HIPAA technical safeguards in 45 CFR 164.312 require transmission security and audit controls that record and examine activity in systems containing ePHI (164.312(e)(1) and 164.312(b)), so each copy path needs an owner, a retention rule and a log. Confirm with your privacy office which of these copies you are willing to keep.
The design decision is to classify each space before users fill it. Declare which Nextcloud or openDesk spaces, mailboxes, Mattermost or Matrix channels, BigBlueButton rooms and BookStack or XWiki books may hold ePHI, which must hold only de-identified or generic clinical content, and which are closed to guests. Then enforce the split with group membership, guest policies, retention settings, notification content rules and separate hosting where needed. Ask your implementation partner to show how each component records access and what the audit trail looks like for a shared file. Your business associate and covered entity terms under 45 CFR 164.314(a)(2)(i) should match the spaces you approve, so that the contract, the configuration and the evidence describe the same boundary.
Which platforms fit healthcare and why
openDesk is a Kubernetes-based, open-source digital workplace suite for public administration, provided by ZenDiS GmbH, a federally owned German company that took over development in January 2024. It bundles chat, files, groupware, wiki, project management, video and web office under one identity layer, which makes it a candidate for a hospital group or health authority that wants a single self-hosted workplace inside its own data boundary. Each bundled component keeps its own license, so the compliance review has to cover every one of them.
- Bundled components: Element with Nordeck widgets for chat, Nextcloud for files, OX App Suite for groupware, XWiki for wiki, OpenProject, Jitsi and Collabora as the web office.
- Licenses: The deployment automation is Apache-2.0, while Nextcloud and Nubus are AGPL-3.0, OpenProject is GPL-3.0 and Collabora is MPL-2.0.
- Platform prerequisites: A CNCF-certified Kubernetes cluster at v1.33 or later, cert-manager, an ingress controller and external PostgreSQL, Redis, object storage, SMTP, ClamAV and TURN services for production.
- Enterprise Edition: ZenDiS recommends Enterprise Edition for production, which adds SLA-backed support and patches for the components listed in its documentation.
- Release cadence: Minor releases arrive monthly, and in-place upgrades between majors are not guaranteed, so plan upgrade rehearsals.
Confirm with ZenDiS and your own security team whether audit logging and encryption at rest and in transit for each bundled component meet your HIPAA or national health data mapping.
A Nextcloud-centred stack starts from Nextcloud Server, which is licensed under AGPL-3.0, and adds office, chat and video components selected to match your environment. It suits health systems that want to choose each component, or that already run Nextcloud for files. Its strength in healthcare is the ability to keep document storage and sharing inside your network, but the stack is only as compliant as the sum of its apps, so each app needs its own review.
- Community or Enterprise: Nextcloud GmbH sells Enterprise in Standard, Premium and Ultimate tiers with a 100-user minimum, and the Premium tier adds a maintenance lifecycle of 5 or more years.
- Upgrade discipline: Nextcloud does not allow skipping major releases, so you must move one major version at a time, back up before each upgrade and disable third-party apps until they are confirmed compatible.
- Identity: The LDAP app lets Active Directory users sign in with directory credentials, and OpenID Connect and SAML backends are documented.
- Installation: Nextcloud All-in-One is the official installation method and bundles Redis, PostgreSQL, BorgBackup, ClamAV and full-text search, with a Helm chart for Kubernetes.
- Support path: Enterprise support levels differ by tier, so confirm response times and patch coverage for your clinical availability needs.
Confirm the audit log and encryption options for each app you enable, and map them to your HIPAA technical safeguards before you approve the app list.
Mail and chat carry the most ePHI in daily use, so they need the tightest review. Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV under AGPL-3.0, with an optional Enterprise License from Stalwart Labs. mailcow is a GPL-3.0 mail stack built on Docker. For chat, Mattermost, Rocket.Chat and Synapse each suit different federation and licensing needs.
- Mattermost: Compiled releases are MIT-licensed, while the source may be used under AGPL-3.0 subject to listed exceptions, so read the license terms that apply to your build.
- Rocket.Chat: The project is MIT-licensed except for content in its ee directories, which uses a separate enterprise license. Do not deploy those directories without a license that covers them.
- Synapse with Element: Synapse is the AGPL-3.0 Matrix homeserver maintained by Element and suits Matrix-based federation between health organizations.
- Mail retention: Plan archiving separately from the mail server, since the HIPAA Security Rule requires audit controls, and the retention rules that apply to your organization are set by your own policies and any other regulation that applies.
- Transport security: Enforce TLS for mail and chat connections, since 45 CFR 164.312(e)(1) addresses protection of ePHI transmitted over networks.
Confirm message-level encryption, audit export and deletion behavior for each product with the vendor before you map it to your controls.
Wiki and project tools hold clinical policy, incident notes, and operational plans, which often contain ePHI by accident. The choice here depends mainly on license terms and whether the tool can run in your network without a commercial service document restriction. BookStack and OpenProject cover the most common needs, and the license of the wiki matters more than its feature list.
- BookStack: MIT-licensed wiki that is simple to self-host, suitable for procedure libraries and clinical policy documents.
- Outline: Licensed under the Business Source License 1.1, whose additional use grant forbids using it to offer a commercial Document Service. Review that restriction with counsel before choosing it for a health authority that may offer services to others.
- OpenProject: GPL-3.0 project and portfolio management, available on premises, suitable for IT change programs and migration projects.
- Access control: Restrict wiki spaces and project boards to the care teams that need them, which reflects the need-to-know principle in GDPR Article 32 for European organizations.
- Content hygiene: Set rules that clinical data stays in the patient record system and not in wiki pages.
Confirm each tool's audit log, export and permission model against your access control and audit requirements before rollout.
Deployment patterns that keep ePHI inside the boundary
Each pattern below answers one question: where ePHI sits, who can reach it, and who keeps the evidence. The HIPAA Security Rule does not prescribe a topology, so the choice is yours, but it must still protect ePHI in transit, record activity in systems that hold it, and bind every business associate with a contract. Confirm each pattern against your own legal and hosting constraints before you commit.
Single-tenant cluster in the hospital data center
A dedicated Kubernetes cluster in your own data center keeps files, mail and chat storage under your physical and administrative control, with no shared tenancy. This pattern suits organizations that must show where ePHI is stored at all times. openDesk expects a CNCF-certified Kubernetes cluster at v1.33 or later, plus external PostgreSQL, Redis, object storage and an SMTP relay, so the data center must host those services too. Confirm which of these services you will run yourselves and who patches them.
Health authority private cloud
A regional health authority can host the suite in a private cloud that serves several hospitals while keeping each facility's data logically separated. The shared model lowers the operating burden per site but makes tenant isolation, role boundaries and audit scope central design questions. Ask the provider how administrative access to the platform is logged and who can see one hospital's ePHI from another's tenant. Confirm the health data boundary that applies in your country before choosing this model.
Separate zones for ePHI and administrative content
Placing clinical records and patient-linked files in a restricted zone, separate from general office content such as policies and project plans, limits how many users can reach ePHI. Each zone needs its own access groups, sharing rules and retention settings, which the identity layer and the file platform must enforce. Plan for users who work in both zones, because copying a patient document into a general channel is the most common leak path. Confirm that your file and chat platform can apply per-space sharing restrictions and block external links on the restricted zone.
Secure external access for affiliated clinicians
Visiting specialists, locum staff and affiliated practices often need access from outside the hospital network. The CNIL's September 2026 fine against Hopital Prive de la Loire cited external access to a patient record system without VPN or multi-factor authentication, and access control that ignored the care team's need to know. Route external sessions through a VPN or zero-trust gateway, require strong authentication, and limit each external account to the patients and spaces it needs. Confirm how the platform records external logins.
Clinical identity and directory integration
Clinical staff rarely sit in one directory, so the suite must map hospital directory accounts, clinical role registries and affiliate identities to one set of permissions. Nextcloud's LDAP app lets directory users log in with their directory credentials, and it also documents OpenID Connect and SAML backends. Decide which system is the source of truth for leavers, because a deprovisioning gap leaves former staff with access to ePHI. Confirm how group and role attributes flow from the clinical directory before go-live.
Backup and audit-log retention
Backups hold copies of ePHI, so they inherit the same access controls, encryption and deletion obligations as the live system. Audit logs must record and let you examine activity in systems that contain ePHI, as 45 CFR 164.312(b) requires, and they must be retained long enough to support investigations. Agree the retention period with your compliance office and your legal team, since no supplied fact sets it for healthcare. Ask the implementation partner how backups are encrypted, where they are stored and how a restore is tested.
How a healthcare rollout runs in phases
The sequence keeps ePHI out of the platform until the boundary, identity, contracts and logging have been checked, so each later phase builds on evidence from the one before. Each phase closes with a named output that the next phase depends on.
Classify data and define the boundary
The security lead, privacy officer and clinical informatics representatives list every data type the workplace will hold, including ePHI in files, mail attachments and chat threads, and mark which systems fall inside the HIPAA or national health data boundary. The team then decides which hosting locations, network zones and administrator groups sit inside that boundary. The phase closes with a signed data classification register and a boundary diagram that names every component and where it runs.
Design identity and clinical directory mapping
The identity team maps which clinical directory, such as an LDAP or Active Directory source, supplies users, roles and department attributes, and decides how those attributes control access to shared folders, team sites and chat channels. They also define how clinicians who work across several sites are represented, and how accounts are removed when staff leave. The phase closes with an attribute mapping document and a tested sign-in path through a single identity provider, with multi-factor authentication enforced for remote access.
Review business associate and processor terms
Legal and compliance teams review the contracts with every party that will host, administer or support the platform. For a covered entity, the business associate contract must require Security Rule compliance, flow the same terms to subcontractors that handle ePHI, and require reporting of security incidents. Teams should also confirm with each vendor which components process personal data outside the chosen hosting region. The phase closes with executed agreements and a subcontractor list that matches the boundary diagram.
Pilot in spaces without ePHI
A small group of administrators and volunteer staff use the suite in spaces that hold no patient information, such as facilities, scheduling templates and internal policy libraries. The team tests sign-in, sharing, mail flow, chat retention settings, video meetings and the mobile apps, and records every defect in a tracked backlog. Success is a closed backlog of blocking issues and a written sign-off that the configuration matches the classification from the first phase.
Run a controlled ePHI pilot with logging verified
A limited clinical or administrative group works with real ePHI under the approved boundary, with audit logging, access reviews and emergency access procedures switched on. The team checks that the logs record access to ePHI in files, mail and chat, that they reach the central log store, and that someone reviews them on a set schedule. Testers also rehearse the emergency access and automatic logoff settings. The phase closes when the audit trail for the pilot group can be reproduced end to end and the privacy officer accepts the results.
Roll out in stages by department
Departments move onto the platform in an order agreed with clinical leaders, one group at a time, with the same access model and training used in the pilot. Each wave has an entry checklist covering identity mapping, retention settings, sharing rules for external parties and migration of existing shared folders. Support staff track adoption and access exceptions for every wave. The wave closes when its checklist is signed and the exceptions log has an owner for each open item.
Hand over operations and rehearse upgrades
The implementation partner transfers runbooks, monitoring, backup restore procedures and the security configuration baseline to the internal operations team. The team rehearses one upgrade in a non-production copy, including the database, cache and third-party app checks that each component's upgrade guidance requires, before doing the same in production. Upgrade cadence and support terms are confirmed in writing with each vendor. The phase closes with a completed restore test, an accepted upgrade rehearsal report and a named owner for every component.
Evidence auditors and regulators ask for
This table maps each evidence item an assessor or HHS reviewer may ask for to the workplace component that produces it and the question to settle with your team. Read it as a preparation checklist: DeployOpen prepares the evidence, but independent auditors, HHS or other regulators decide whether your organization complies.
| Evidence item | Component that produces it | What to prepare |
|---|---|---|
| Access control records and unique user IDs | Identity provider (Keycloak or Nubus in openDesk, or the directory you federate), with per-user accounts in Nextcloud, Mattermost or Matrix | Confirm that no shared accounts exist, export user lists with joiner and leaver dates, and document role mappings to care team roles |
| Transmission encryption configuration | Reverse proxy or ingress with TLS, mail transport settings in Stalwart or mailcow, and TLS settings in each application | Keep configuration exports and certificate inventory, and record which encryption specifications your risk analysis treats as addressable and why |
| Audit logs of ePHI access | Nextcloud activity and audit logging, mail server logs, chat server logs, and the identity provider's login events, all sent to a central log store | Confirm retention periods, time synchronization, and who reviews logs and how often; test that file access by staff is actually recorded |
| Emergency access procedure | Break-glass accounts in the identity provider and documented runbooks for the workplace platform | Keep a written procedure, the list of holders, sealed credential storage, and records of each test or use |
| Business associate agreements and subprocessor list | Contracts held by your legal team, plus the list of hosting, SMTP, antivirus, TURN and backup providers from your deployment | Confirm that every vendor or service that handles ePHI is covered by a business associate contract that flows down the same terms, and keep the list current |
| Risk analysis record | Risk register maintained by your security team, using the component inventory produced by the deployment | Map each component to the systems that hold ePHI, record threats and likelihood, and link each mitigation to a control or open item |
| Incident response records | Ticketing or ITSM tools such as GLPI, iTop or Zammad, plus logs from the workplace components | Keep incident runbooks, breach assessment steps, notification decision records and post-incident reviews, with timelines |
| Patch and upgrade records | Change records and deployment version history (for example, Nextcloud major and maintenance releases, or openDesk release notes applied to your environment) | Record each version applied, test results, rollback plans and dates; confirm that the vendor version you run is still supported |
Questions healthcare teams ask before hiring a partner
Is there a HIPAA certification for a self-hosted workplace suite?
No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Your evidence should show how the Security Rule safeguards in 45 CFR 164.312 are implemented for the suite, including unique user identification, automatic logoff, encryption and audit controls. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask your partner which evidence they will produce and how it maps to your risk analysis.
What drives the cost of a healthcare workplace suite?
Cost splits into one-time work and recurring spend. One-time work covers design, implementation, identity integration, migration and hardening. Recurring spend covers Kubernetes and external services, staff time for operations and, if you choose them, subscriptions. Nextcloud Enterprise list prices, according to Nextcloud's pricing page, start at 71.29 euros per user per year for the Standard tier, 104.99 euros for Premium and 204.75 euros for Ultimate, for 100 or more users, with a 100-user minimum and lower rates from 200 users. Premium adds a maintenance lifecycle of 5 or more years, and Ultimate adds support up to 24/7 with response times down to 1 hour. Ask for a quote that separates each component, its license, support tier and the external services it needs.
How long does a healthcare workplace rollout take?
The duration depends on scope, identity integration, data migration and the number of user groups, and no fixed timeline applies to every organization. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The main drivers are the number of components in scope, how many directories and identity sources must be federated, whether mail and file archives must be migrated, and how many clinical or administrative workflows need validation. Clinical sign-off, change approval and the Kubernetes platform readiness often set the critical path. Ask your partner for a written schedule that lists each dependency and the owner who approves it.
Can our internal team operate a self-hosted healthcare suite?
It depends on your Kubernetes skills, on-call coverage and upgrade capacity. openDesk releases major versions annually, minor versions monthly and patches on demand, and only the latest minor version is supported. Nextcloud publishes a new major version every four months and requires one major upgrade at a time, with a backup before every upgrade. A small team may run the platform with a retainer for upgrades, testing and support, while keeping ownership of data, identity and access decisions. Ask the partner to define which tasks it performs, which your staff performs and how the handover is documented and tested.
What does TI-Messenger mean for German hospitals?
TI-Messenger is a telematics infrastructure messaging service used in the German health system, and its requirements apply to hospitals and practices connected to that infrastructure. Before you pick a chat component, confirm with your health IT provider, data protection officer and the gematik specifications which requirements apply to your organization. A general-purpose chat server does not become compliant by being self-hosted, so the architecture, federation settings and identity model must be checked against those requirements. Matrix-based options such as Synapse, which is licensed under AGPL-3.0, and openDesk's Element component are candidates to evaluate, and each needs a documented assessment. Ask your partner to explain how they would validate the chosen design against the current requirements.
Does a business associate contract apply to a self-hosted vendor?
A business associate contract applies when a vendor creates, receives, maintains or transmits ePHI on your behalf. Under 45 CFR 164.314(a)(2)(i), the contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors handling ePHI and report security incidents, including breaches of unsecured PHI. If your staff operate the platform entirely inside your own infrastructure and the implementation partner has no access to ePHI, the analysis changes. If the partner accesses production data during migration, support or troubleshooting, it likely needs a business associate agreement. Have counsel review the access model and document it before any work starts.
What does openDesk require from Kubernetes and external services?
openDesk requires a CNCF-certified Kubernetes cluster at version 1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. It is tested on kubespray clusters and not on OpenShift. The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk. Production expects external services, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each service needs backup, patching, monitoring and an owner. Ask your partner to confirm the version support for each component against your platform standards before you commit.
Which safeguards should our evidence cover first?
Start with the technical safeguards in 45 CFR 164.312. The standard requires controls against unauthorized access to ePHI sent over electronic networks, and audit controls that record and examine activity in systems containing ePHI. Unique user identification and emergency access procedures are required implementation specifications, while automatic logoff and encryption are addressable. Map each safeguard to a component, a configuration and a log source before the pilot. For a workplace suite, that usually means identity federation with multi-factor authentication, role-based access to files and chat channels, encryption in transit and at rest, and centralized audit logs. Ask the partner to show where each evidence artifact is produced and retained.
What to ask an implementation partner for a clinical environment
Ask every partner to show, in writing, where ePHI can sit inside the workplace suite before any build starts. The question is not only whether files, mail and chat are encrypted, but which components store, cache, index or relay clinical content: Nextcloud file storage and previews, the Synapse or Mattermost message store, the SMTP relay that carries clinical mail, ClamAV scanning of uploads and the object storage behind them. Ask for a data flow diagram that names each component, its hosting location and its backups, and ask how the partner will prove that no component sends content to a service outside the agreed boundary. Ask also for experience with health data specifically: how many healthcare or public health workplace deployments they have run, which HIPAA or national health data rules shaped those designs, and who on their team has worked with the Security Rule's technical safeguards in 45 CFR 164.312. Confirm that these references can be discussed under a non-disclosure agreement.
Test the partner on identity and audit. Ask how they will connect the suite to the clinical identity source and which attributes drive role assignment, since access must follow the care team's need to know rather than group membership alone. Ask how they will enforce unique user identification and emergency access procedures, and how multi-factor authentication and VPN access will apply to remote clinicians. For audit, ask which logs each component produces (Nextcloud activity and audit logging, mail and chat access records, Keycloak or other IdP sign-in events), how those logs are exported to the hospital SIEM, what retention they will configure, and whether they will test that an audit record can be reconstructed end to end. Under 45 CFR 164.312(b), audit controls must record and examine activity in systems containing ePHI, so the export path is part of the design, not an afterthought.
Finish with operations and contracts. Ask the partner to rehearse a full backup and restore of files, databases and object storage, and to record the measured recovery time and any data gaps. Ask how they will handle openDesk minor releases, which arrive monthly, and Nextcloud majors, which must be applied one at a time with no skipping, and whether they will test each upgrade in a non-production copy first. Ask whether they will sign a business associate agreement under 45 CFR 164.314(a)(2)(i) if they will create, receive, maintain or transmit ePHI for you, and whether that agreement flows the same terms to their subcontractors. Where the partner will not handle ePHI at all, ask them to confirm that in writing and describe how access to production data is restricted during the project.
