Self-hosted file sharing for healthcare

Yes, but external access should be limited to named guest accounts for specific partners, not open self-registration. In Nextcloud, administrators can create guest users and share individual folders with them, so each external person is identifiable in the audit trail. Restrict who can invite guests, require approval for new external accounts, and review guest lists on a schedule. Whether patients should use this path at all is a separate decision, covered in the next question.

Patient-facing exchange often belongs in a dedicated patient portal, and that decision depends on the clinical workflow, which you must confirm with clinical and compliance leads. A file sync and share platform is designed for staff and known partners, not for patient identity proofing, appointment-driven access or patient-facing messaging. If patients must receive results or upload documents, map each exchange to a specific workflow and decide whether it sits in a portal, an EHR feature or a separate application. Involve your privacy officer in that review.

Nextcloud supports public share links that can be protected with a password and given an expiration date, and administrators can set policies that enforce these settings. For ePHI, the policy should require a password and a short expiry on any link to a folder that receives external traffic. Test how the server enforces these rules, since a user interface setting alone is not evidence. Confirm the exact share-link options in the version you run before writing the policy into your procedures.

Yes. The control is to disable public link creation for the groups or folders that hold ePHI, so that only named guests and internal users can receive access. Enforce this through the platform's sharing policies and group settings, then test it with a non-privileged account to confirm the restriction holds. Document the mapping between folder classification and sharing rules so auditors can see how the restriction reaches ePHI locations, which supports the access control expectations in the HIPAA Security Rule at 45 CFR 164.312(a).

Access from untrusted networks can be restricted with access control rules that match client IP ranges, groups or user agents, combined with a reverse proxy or firewall in front of the platform. Define which networks, such as corporate sites, VPN ranges or approved partner addresses, may reach ePHI folders, and deny the rest. Pair this with multi-factor authentication for external accounts. The HIPAA transmission security standard at 45 CFR 164.312(e)(1) expects measures against unauthorized access to ePHI over networks, so network rules should be part of the documented design.

Before a partner receives ePHI, the covered entity must have a written contract that meets 45 CFR 164.314(a). If the partner is a business associate, the contract must require compliance with the Security Rule, flow the same terms to any subcontractor that handles ePHI, and require reporting of security incidents. Onboarding should check the agreement exists, record the named users and the folders they can reach, and set a review date. Ask your counsel whether any partner is a business associate or merely a recipient under another legal basis.

A repeatable process has four steps: confirm the legal basis and agreement, create a named guest account with multi-factor authentication, share only the folders needed for the engagement, and log the approval. Offboarding removes access, revokes active share links, and reviews the audit log for downloads made near the end date. Assign an owner for each partner relationship and review access at a fixed interval. These steps create the records that compliance teams request during an assessment.

DeployOpen plans, implements, customizes, integrates and hardens self-hosted open-source platforms inside your own infrastructure, so it can configure guest access, sharing policies, network rules and audit logging as part of a fixed-scope engagement. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Your legal and compliance teams still own the agreements and the clinical workflow decisions.

Yes, a partner that touches ePHI during implementation, migration, support or backup is a business associate, so it should sign a business associate agreement before access begins. Under 45 CFR 164.314(a)(2)(i), that contract must require compliance with the Security Rule, flow the same terms down to any subcontractor that handles ePHI, and require reporting of security incidents, including breaches of unsecured PHI. Ask for the list of subprocessors (hosting provider, backup vendor, support tooling, offshore staff) and confirm each one is covered by a written downstream agreement. Confirm also who holds the agreement: DeployOpen plans, implements and supports self-hosted platforms inside your infrastructure, so the contract must match the actual access the partner gets to ePHI.

Ask for a written mapping from each technical safeguard standard in 45 CFR 164.312 to a named configuration, log source or procedure in your environment. The mapping should cover unique user identification, emergency access, automatic logoff, audit controls, integrity, person or entity authentication, and transmission security, with the required and addressable status of each implementation specification noted. Ask for examples from past work that show how the partner documented decisions on addressable specifications, because an auditor will ask why a control was chosen or why it was not. Remember that the partner prepares evidence for your assessment; it does not issue a certification, and HHS does not offer a HIPAA certification.

A sound design defines a break-glass account or procedure that is documented, tested and separately logged, and it defines who may invoke it and how access is reviewed afterward. For audit controls under 45 CFR 164.312(b), ask where Nextcloud audit events are written, how they are forwarded to a log store you control, how long they are retained, and how administrators are prevented from editing them. Ask the partner to show the log fields captured for file access, sharing changes and admin actions, and how alerts reach your security team. Confirm that the emergency access procedure and the audit design are both in the written scope and that your own staff own the review step.

Nextcloud does not allow skipping major releases, so each upgrade moves one major version at a time, and administrators must back up before every upgrade and disable third-party apps until they are confirmed compatible. Ask the partner how it tracks the release calendar, how long each version stays supported, and how it stages upgrades in a non-production copy before production. The release schedule currently lists Nextcloud 35 with end of life in September 2027 and Nextcloud 36 scheduled for 17 February 2027, so ask how the partner plans around those dates. Ask who approves each change window and how the maintenance hours and downtime are communicated to clinical staff.

A backup has no value until a restore has been proven, so ask for the restore test plan, the recovery time and data loss targets you approved, and the record of the last successful test. Confirm that the backup covers the database, the data directory and configuration, and that it is stored outside the sync path so that a compromised client cannot delete it. Ask whether the partner uses a tool such as BorgBackup, as bundled in Nextcloud All-in-One, and how encryption keys for backups are held. Ask who performs restore tests, how results are documented as evidence, and what happens when a test fails.

Support scope depends on the software edition and on the partner's own service agreement, so ask for both in writing. If you use Nextcloud Enterprise, the pricing page describes Standard with 1-year maintenance, Premium with a maintenance lifecycle of 5 or more years and extended support hours, and Ultimate with support up to 24/7 and response times down to 1 hour. Ask the partner what response times it commits to for security incidents, whether it provides on-call coverage outside business hours, and how it reports incidents to you in time to meet the business associate contract. Ask also whether a retainer for upgrades, security patching and continuous testing is included or priced separately, and what remains your team's responsibility.

Many hospitals have the skills to run a self-hosted platform, but the work falls into groups: installation, identity integration, hardening, backup design, upgrades, evidence collection and ongoing operations. Ask the partner to split the scope into those groups and say which ones your team would keep. Ask for a written scope with deliverables and timelines before work starts, since most DeployOpen engagements are fixed-scope. Ask how knowledge transfer and runbooks are delivered so that a future staff change does not leave the environment unmanaged.