Open source intranet for healthcare

Why an open source intranet for healthcare starts with patient data boundaries

An intranet for a hospital or care group has to be designed around the boundaries of electronic protected health information (ePHI) from day one, because the posts, files and wiki pages it holds can drift into patient information without anyone intending it. Shift staff who work without desks or corporate email still need policies, clinical guidelines and rota news in one place, and HumHub, XWiki and Nextcloud each fit a different part of that need: HumHub for news and social interaction, XWiki for structured clinical and policy content, and Nextcloud for controlled file exchange. The design question is which of these tools carries which content, and which content never enters them at all.

This differs from a generic intranet because the HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to covered entities and their business associates for all ePHI they create, receive, maintain or transmit. A ward huddle thread that quotes a patient's name, or a shared folder holding discharge letters, makes the intranet itself a system containing ePHI, which brings in the access, audit and transmission safeguards of the rule. The practical step is to write a scope statement listing which content types are prohibited, then map each space, file library and group to that statement before any staff are onboarded. Confirm with your privacy and compliance leads whether any business associate contract under 45 CFR 164.314 covers the hosting partner.

DeployOpen implements these platforms inside your own infrastructure, whether that is your cloud accounts, data centers or an isolated network, so the boundary rules are enforced by your directory, your network controls and your logging rather than by a vendor's shared service. Before a pilot, ask your implementation partner to show where audit logs are stored, who can read them, and how a space is restricted to a named care team.

Which healthcare requirements shape the intranet build

This table maps each healthcare requirement to its source and the concrete build decision it forces on an intranet. Read each row as a question to settle before configuration starts, not as a compliance finding. The main takeaway is that access control, logging and vendor terms shape the intranet as much as the feature list does.

Requirement	What it asks for	Build consequence
Unique user identification (164.312(a)(2)(i), required)	Each user must have a unique identifier, so that activity can be tied to one person. Shared logins on ward terminals are the common failure.	Require named accounts tied to the hospital directory, and prohibit generic ward logins for intranet access. Confirm how shared kiosks in nursing stations will authenticate.
Automatic logoff (164.312(a)(2)(iii), addressable)	Sessions must end after a period of inactivity, which matters on shared workstations and handheld devices used across shifts.	Set idle timeouts in the platform and on the browser or app. Document the chosen value and the reason, since an addressable specification still requires a documented decision.
Encryption and transmission security (164.312(e)(1), with addressable encryption specifications)	Guard against unauthorized access to ePHI sent over networks, including remote access and mobile connections.	Enforce TLS for all web, mobile and API traffic, and keep patient-related content out of intranet posts altogether. Confirm encryption at rest for file storage and backups.
Audit controls (164.312(b))	Record and examine activity in systems that contain ePHI, so that access to sensitive spaces can be reviewed.	Enable audit logging for logins, file access and space membership changes, forward logs to a central store, and assign a named owner for periodic review.
Role-based access and need to know (GDPR Articles 32 and 34, as applied in the CNIL fine against Hopital Prive de la Loire on 3 September 2026)	The CNIL found that access control ignored the care team's need to know. Access must follow role and assignment, not general directory membership.	Build spaces by department and role, restrict clinical guideline spaces to relevant staff, and review membership on a schedule tied to HR changes.
MFA and VPN for remote and external access (same CNIL decision)	The fine cited external access to patient record systems without VPN or multi-factor authentication.	Require multi-factor authentication for any remote or contractor access to the intranet, and route it through a VPN or equivalent controlled path. Confirm which staff groups work off-site.
Business associate contract terms (45 CFR 164.314(a)(2)(i))	Hosting, support and implementation vendors that handle ePHI must agree to the Security Rule, flow terms to subcontractors and report security incidents.	Before any vendor accesses the intranet, confirm a signed business associate contract covers hosting, remote support and any subcontractors. Ask each partner to show how it handles incident notification.
NIS2 Annex I (health as a high criticality sector)	Healthcare providers and certain health manufacturers in the EU fall under NIS2 Annex I, which sets security and incident handling duties.	Confirm with counsel whether the organization is in scope. If it is, plan incident reporting paths, supplier security requirements and documented access control inside the intranet design.

Which intranet platform fits which healthcare audience

A hospital with thousands of employees across wards, outpatient clinics and support services usually needs a broad staff audience first: daily news, shift notices, recognition and a place for teams to talk. HumHub fits this pattern because its core model is a social network of spaces, profiles and streams, so departments can publish updates and comment without a central web team editing every page.

Feed-first design: Staff see posts from the spaces they follow, which suits daily communication more than formal policy text.
Department spaces: Each ward, theatre or service can own a space with its own moderators and membership.
Directory alignment: Profiles and group membership should follow the hospital directory so new starters land in the right spaces without manual work.
Edition-dependent news tools: Advanced news targeting and mandatory read notices may depend on a commercial edition, so confirm this with the vendor before the design is fixed.
Patient data boundary: Set posting rules that bar patient identifiers, admission details and clinical images from every space. The HIPAA Security Rule covers ePHI a covered entity creates, receives, maintains or transmits, so a post that contains it is in scope.

Check the moderator model, who can create spaces, and whether your licensed edition supports the notice and targeting features your communications team expects.

Which platforms to shortlist for a healthcare intranet

A healthcare intranet usually combines a news and social layer, a policy and guideline wiki, office editing and shift messaging. Each platform below solves one part well, and each carries a specific risk for patient data that the shortlist has to account for. None of them makes a hospital compliant on its own.

HumHub for staff news and social spaces

HumHub fits the social layer of a care group intranet: news streams, space-based communities per ward or department, and comments. Its AGPL license obliges you to publish changes if you offer a modified version to users over a network, which your legal team should review. The main risk is that posts are free text, so nursing staff can paste patient details into a comment within seconds. Plan moderation rules, space-level permissions and clear guidance on what never goes into a post before rollout.

XWiki for policies and clinical guidelines

XWiki suits controlled documents such as policies, procedures and guideline libraries because it supports structured pages, rights per space and page history. It is LGPL 2.1 licensed, and its official Docker images run on Tomcat with MySQL, PostgreSQL or MariaDB. Confirm which branch fits your upgrade policy: the stable line, the long term support line or the intermediate LTS line. Check that version history and approval workflows meet your document control procedures.

Nextcloud with office editing

Nextcloud Server provides the shared file area for policy attachments, rotas and training material, and it is AGPL-3.0 licensed. For browser-based editing of Office files, pair it with ONLYOFFICE Docs under AGPL-3.0 or Collabora Online under MPL 2.0, and confirm which license terms your legal team accepts for each component. Document editing sends file content to the document server, so place that service inside your network and confirm that access to the shared folders follows the same need-to-know rules as your record systems.

Mattermost or Rocket.Chat for shift messaging

Shift coordination needs fast, channel-based messaging across wards and sites. Mattermost compiled releases are MIT licensed while the source is available under AGPL-3.0 with listed exceptions, and Rocket.Chat is MIT except for content in its ee directories under a separate enterprise license. Chat generates records that may need retention and legal hold, so define retention periods, export procedures and channel access reviews before use. Confirm which edition contains the features you need, because license boundaries decide what you can run without extra terms.

Compliance is not a platform feature

No platform in this shortlist is a compliance product, and no HIPAA certification exists for an intranet. The HIPAA Security Rule requires transmission security for ePHI and audit controls that record and examine activity in systems containing ePHI. Those controls come from configuration, logging, identity integration and written procedures that you own. Ask each shortlisted vendor and implementation partner to show how audit logs, access reviews and encryption in transit are configured in your environment.

Integration points for a hospital intranet

A hospital intranet touches the directory, remote access, document systems and audit tooling, and each link is a place where access can drift or evidence can go missing. The cards below cover the integration points that matter most for a self-hosted HumHub, XWiki or Nextcloud deployment, and what to confirm with the vendor and your own teams before design starts.

Directory sync and deprovisioning

Staff identity should come from the hospital directory, not from a separate user list maintained by the intranet team. Decide which attribute marks an active employee, how bank and locum staff are represented, and how leave, transfers and terminations remove access. Confirm with your chosen platform whether it supports LDAP or Active Directory sync, which edition that requires, and whether group membership can drive space access. Test a leaver case end to end before go-live, including sessions and API tokens that outlive the directory account.

SSO and MFA for remote and shift access

Nurses and allied staff often reach the intranet from hospital workstations, shared kiosks, personal phones and home offices. Single sign-on should enforce multi-factor authentication for off-network sessions, and the design should define what happens on shared devices, including session timeout and forced logoff. The HIPAA Security Rule treats automatic logoff and encryption as addressable specifications, so document the decision you make and why. Confirm which SSO protocols each platform edition supports before you commit to a design.

Linking document and EHR-adjacent systems

Policies, clinical guidelines and forms usually live in a document management system or an EHR-adjacent repository with its own access rules. Link to those sources rather than copying content into the intranet, so the owner remains the system of record and access follows the source. Ask each platform which connectors or embed methods it supports and whether the embedded view respects the source permissions. Anything that would place patient-identifiable content in a wiki page or post should be treated as a design defect, not a configuration detail.

Audit log forwarding for 164.312(b)

The HIPAA Security Rule requires audit controls that record and examine activity in systems containing ePHI. If the intranet can hold any ePHI, including a photo or name in a clinical context, its logs need to reach your central logging platform with retention matched to your policy. Confirm which events each platform logs (logins, permission changes, file downloads, admin actions), whether logs can be exported in a standard format, and how log integrity is protected. Map the log sources to your audit review process, not just to storage.

Deployment inside your own environment

Hosting the intranet in the hospital data center or in a cloud account the hospital controls keeps directory data, logs and any incidental ePHI under the same governance as the EHR. Decide early whether the platform needs outbound connections for updates, mail or push notifications, and whether those paths are allowed by your network policy. Use a business associate agreement with any partner who can access the environment, and confirm the subcontractor terms in writing. Keep backup and restore for the intranet on the same schedule as your other clinical-adjacent systems.

How a healthcare intranet rollout moves from scope to support

The sequence turns a healthcare intranet from an idea into a governed service: it fixes what may never be posted, connects the hospital directory, proves access with a pilot that includes shift staff, and ends with a run model for upgrades and moderation.

Classify data and set posting boundaries
The project lead, privacy officer, information security lead and clinical governance representative agree what the intranet may hold and what it must never hold, such as patient identifiers, clinical case details, staff health information and unpublished incident data. DeployOpen drafts the classification with you, mapping each content type to a sensitivity level and an allowed audience. The output is a signed data classification standard with a short list of prohibited content, which becomes the reference for every space owner and moderator. Confirm with your legal team how the standard relates to your HIPAA obligations and any GDPR or regional rules that apply to your organization.
Integrate identity and the hospital directory
The identity team connects the intranet to the hospital directory so that users, groups, departments and roles come from the system of record rather than manual lists. DeployOpen configures single sign-on and group mapping in a test environment, and the team confirms which protocol your chosen edition supports, since directory and SAML features can depend on the edition. Multi-factor authentication and remote access rules should match your existing policy for external and off-site staff. The output is a tested SSO flow with documented attribute mapping, plus a list of leavers and joiners checks that run against the directory.
Design spaces and the access matrix
Working with HR, nursing, clinical leadership and facilities, you define the spaces that match how care teams actually work: organization-wide news, ward or unit spaces, shift handover notices, policy libraries and project areas. Each space gets an owner, a read and write group, and a rule on whether it is visible to contractors or affiliated staff. The access matrix records who can see clinical guideline spaces and who can post to them, so that the need-to-know principle reflected in regulator findings is visible in the design. The output is an approved access matrix and a space catalog that the pilot tests.
Pilot with selected units including shift staff
A small set of units runs the intranet for a defined period, and the group includes at least one shift-based team that has no desk or corporate mailbox. DeployOpen supports the pilot with mobile access checks, shared-device login tests and a short training path written for staff who work in short sessions. Pilot users report issues against the access matrix and the data classification standard, and each finding is logged with an owner. The output is a pilot report with resolved defects, a list of accepted risks signed by the information security lead, and a go or no-go decision recorded in writing.
Migrate policies and clinical guidelines with approval
Policies and clinical guidelines move into the intranet only after they pass a content inventory and an approval workflow. Document owners confirm the current version, the approving committee signs off, and the migration team removes duplicates and superseded versions before import. Each guideline page shows its owner, version and review date, and the source system remains the authority where your document management system already governs records. The output is a migrated policy library with an approval record for each document, plus a retirement list for legacy copies that must no longer be reachable.
Go live with moderation rules and a runbook
Before go-live, the communications team and clinical governance agree moderation rules: who may post to organization-wide spaces, how posts that include patient information are removed, how comments are reviewed, and how urgent notices are escalated. DeployOpen prepares a moderation runbook with steps, contacts and the audit logging you configured, so that removals and access changes can be shown to an assessor. The rollout is staged by unit, and each stage has a rollback decision point. The output is a live intranet with a moderation runbook, an escalation path and an audit trail that records significant activity.
Run upgrades, backups and ongoing support
After go-live, the platform needs a regular operating cycle: applying vendor releases and security updates in a test environment first, verifying SSO and directory sync after each change, restoring backups on a schedule, and reviewing the access matrix when units reorganize. DeployOpen can provide this as a support retainer, and the terms, response expectations and upgrade scope are agreed in writing. Your team owns the content and moderation decisions, while the operator owns the platform. The output is an operating calendar, a tested restore record and a quarterly access review that feeds your compliance evidence file.

Evidence auditors and regulators ask for from the intranet

This table maps each piece of evidence an assessor is likely to request to the regulatory hook behind it and the intranet component that produces it. Read it as a checklist to settle before go-live, not as a list of certifications. DeployOpen prepares this evidence for assessments, but independent auditors and certification bodies issue any audit report, and HIPAA itself has no certification.

Evidence item	Regulatory hook	Component that produces it
Access reviews from directory groups	Unique user identification and access control under the HIPAA Security Rule technical safeguards (45 CFR 164.312)	Directory (LDAP or SSO) group exports, reviewed on a set schedule against the staff roster and care team membership
Audit logs from the intranet and its database	Audit controls under 45 CFR 164.312(b) that record and examine activity in systems holding ePHI	Intranet application logs, web server logs and database query or login logs, retained and reviewed under a documented procedure
Configuration baselines and change records for upgrades	Security Rule change and configuration management expectations, reviewed in the NIST SP 800-66 Rev. 2 guidance for implementing the rule	Version-controlled configuration files, a dated upgrade log, test results from staging and a rollback record for each release
Business associate agreements and vendor evidence	Business associate contract terms under 45 CFR 164.314(a)(2)(i), including flow-down to subcontractors that handle ePHI	Signed agreements with the hosting provider, the implementation partner and any support vendor, plus subprocessor lists
Training acknowledgments for policies	Security awareness and training standards in the administrative safeguards (45 CFR 164.308)	Acknowledgment records for clinical guidelines and privacy policies, stored with timestamps and linked to the policy version
Encryption and transmission evidence	Transmission security under 45 CFR 164.312(e)(1)	TLS configuration reports, certificate inventory and proof that remote access to the intranet uses approved, encrypted channels
Assessment readiness and HITRUST timing	No HIPAA certification exists; HITRUST is a private assessment some organizations choose, and its timing depends on the assessment scope and assessor	Evidence package prepared by the organization and its partner; any audit report or certification is issued by an independent assessor, not by DeployOpen

How to keep patient data out of social posts and shared spaces

The first control is a written rule on what may not be posted to the intranet, and it has to be specific enough for a nurse or ward clerk to apply it at the moment of writing. The rule should name identifiers that never belong in a feed or wiki page (patient names, record numbers, dates of birth, room numbers linked to a diagnosis, photographs of patients or whiteboards) and say where the right place for such information is, which is the clinical record system. Under the HIPAA Security Rule, technical safeguards for ePHI in transit and audit controls for systems that hold it (45 CFR 164.312(e)(1) and 164.312(b)) apply to the intranet only if it actually holds or transmits ePHI, so the first decision is whether it will. Settle that answer in writing before you configure anything, and have compliance review the rule.

Then translate the rule into structure. Clinical content belongs in restricted spaces whose membership follows the care team, not a broad hospital-wide space, and the access model should be tested against the need-to-know principle that the CNIL applied to Hopital Prive de la Loire in its 3 September 2026 decision. HumHub feeds, comments and profile posts need stricter moderation than XWiki or BookStack pages, because a comment is created in seconds and read by everyone in the space, so plan for a reporting path, a named moderator per space and a tested takedown procedure, and set retention rules for deleted and archived content. The boundary must be tested with scripted attempts: a staff member outside the ward should not be able to find a clinical post through search, and a deliberately planted test identifier should be caught by the moderation process. Train the people who write news and feed posts, and repeat that training when the rule changes.

The proposed Security Rule revision was published on 6 January 2025 (90 FR 898), and as of October 2026 no final rule exists. The Unified Agenda entry for RIN 0945-AA22 projects final action for July 2027, so treat the current requirements as the baseline and the revision as a likely change to plan for. Build the posting rule, space model and moderation settings as configuration and documentation that can be revised without rebuilding the platform, and ask your compliance lead to confirm which parts of the proposal would change your controls, since the final text may differ from the proposal.

What hospitals ask about cost, time and effort for an open source intranet

What drives the cost of a self-hosted intranet for a hospital?

The main cost drivers are hosting, the edition or subscription you choose, integration with your directory and document systems, content migration, and the moderation effort that continues after launch. Hosting and infrastructure are usually recurring, while onboarding, integration and migration are mostly one-time. Open-source licenses for HumHub, XWiki and Nextcloud are not the expensive part; the labor around them is. Ask any implementation partner for a quote that separates one-time work from recurring work, names who is paid for each item, and states which edition features (such as directory connectors or single sign-on) are included in the price. The XWiki Pro licensing tiers and support plans are priced by user band and are the same for cloud and on-premises, so the user count in your directory matters as much as the feature list.

Can our own IT team run a hospital intranet without an outside partner?

Yes, if your team already operates web applications, databases and identity integration, and has capacity for patching and upgrades. Open-source intranet platforms are installed and run inside your own infrastructure, so the operating model is yours to set. The questions to answer honestly are who applies security updates, who tests upgrades before they reach production, who handles directory changes when staff join or leave, and who moderates content around the clock. Many hospitals split the work: internal staff own operations and content, while a partner handles initial setup, hardening, integration and documentation under a written scope. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms in your environment, and ongoing support is available as a retainer.

How long does a hospital intranet rollout take?

The duration depends on scope rather than on the platform alone. The variables that matter most are the number of audiences and spaces, how many directory sources must be connected, whether existing policy and guideline libraries must be migrated, how many clinical and administrative sites are involved, and whether mobile access is needed for shift staff. A narrow pilot for one care group can move much faster than a multi-site rollout with migrated content and formal change control. No standard duration applies to every hospital, so ask a partner for a phased plan with milestones, a written scope and a clear list of what the client must provide. Fixed-scope engagements agree deliverables and timelines in writing before work starts.

How much time do clinical and HR staff need to give the project?

Clinical leads and HR staff are needed for decisions, not for building the platform. Clinical leads typically define which spaces exist, who may read clinical guidelines, which content must never be posted in open channels, and how policy owners approve updates. HR and the directory team confirm which employee attributes are authoritative, how joiners, movers and leavers are handled, and how shift-based staff without corporate email get accounts. Expect a series of short review sessions during requirements and acceptance testing, plus a named content owner for each policy area after launch. The exact hours depend on the number of policy areas and the existing governance model, so ask any partner to list these roles and meeting points in the written scope.

Do we need a business associate agreement for a self-hosted intranet?

It depends on who handles electronic protected health information. If you host the intranet entirely inside your own infrastructure and no outside party creates, receives, maintains or transmits ePHI on your behalf, a business associate contract with that party may not be required for the hosting itself. If a partner has access to systems that contain ePHI during implementation, support or backup, or if a cloud or SaaS provider stores that data, a business associate contract under 45 CFR 164.314(a)(2)(i) is the expected starting point. That contract must require Security Rule compliance, flow the same terms to subcontractors that handle ePHI, and require reporting of security incidents. Confirm the data flows and access paths with your privacy officer and counsel before signing any statement of work.

Is there a HIPAA certification for an intranet platform or for our hospital?

No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and 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. Be cautious with any vendor or partner that claims HIPAA certification. What you can ask for is evidence: a documented risk analysis, access control and audit log configuration aligned with 45 CFR 164.312, unique user identification, automatic logoff settings, encryption in transit, and business associate paperwork where it applies. Some organizations also use HITRUST assessments as an independent framework, which is a separate decision with its own cost and timeline. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications.

What do XWiki consulting and training rates mean if we choose that path?

If you choose XWiki and buy its consulting directly, XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day. These rates apply only to XWiki SAS services, not to work by other partners. Treat them as one input to your budget: a day rate multiplied by the number of days in a written scope gives an indicative vendor-side figure, but the total also includes your internal staff time, hosting and any migration tooling. XWiki Pro subscriptions are tiered by user count, and XWiki SAS states that cloud and on-premises pricing is the same. Confirm with XWiki which tier covers your directory connectors and single sign-on before you compare it with a partner quote.

What ongoing effort should we budget after the intranet goes live?

The recurring effort falls into four areas: patching and upgrades, directory and access maintenance, content moderation and governance, and backup and restore testing. Patches and upgrades need a test environment and a change window, so budget for them as a standing task rather than a one-off project. Access maintenance is continuous because clinical and administrative roles change often, and shift staff may enter or leave the directory faster than office staff. Moderation and policy ownership require named owners who review guidelines on a schedule. Ask your partner whether a support retainer covers upgrades, security testing and documentation, and ask for the service levels in writing, since none should be assumed.

How DeployOpen scopes and supports a healthcare intranet

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including hospital and care group networks. For a healthcare intranet, the work starts with written scope that separates general staff content from clinical and patient-adjacent material, so access rules are settled before anything is built.

How we scope

Written scope lists the spaces, audiences and shift groups that the intranet must serve before build begins.
Scope records which directory, single sign-on and document systems the intranet must connect to.
Scope sets the rules for keeping patient data and identifiable clinical detail out of social posts and comments.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Deployment runs in your own cloud accounts, data centers or air-gapped networks, under your hosting controls.
Configuration covers role-based access, directory integration and audit logging for the intranet's administrative actions.
Testing includes access checks for each audience, so policy and clinical guideline spaces are restricted as designed.
Hardening covers transport encryption, backups and the upgrade path for the chosen HumHub, XWiki or Nextcloud platform.

How we hand over

Handover documentation describes the architecture, access model, backup procedures and upgrade steps for your team.
Compliance evidence packs record configuration, access and logging settings for your assessors to review.
Administrators receive training on moderation, space ownership and the rules for posting clinical or patient information.
We prepare systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Security testing of the intranet, its integrations and its APIs can be scoped as a separate engagement.
Before any engagement, confirm with your compliance team which HIPAA or regional obligations apply to your organization.
Ask any partner for the exact support tier, response expectations and upgrade cadence in the written quote.