Drupal for healthcare organizations

Why Drupal fits healthcare content, and where the boundary must sit

Healthcare organizations need their public sites, provider directories and patient information to be accurate and accessible, while clinical records stay in systems built for that purpose. Drupal fits the content and directory layer well, provided the build keeps electronic protected health information (ePHI) out of the CMS. The boundary is the design decision that matters most, and it should be set before any content model is drawn. The HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to covered entities, meaning health plans, health care clearinghouses and covered health care providers, and to their business associates, for all ePHI they create, receive, maintain or transmit (eCFR, 45 CFR Part 164 Subpart C). A Drupal site that never holds ePHI sits outside that scope for its data, but a site that collects appointment requests or symptom forms may bring it in.

Drupal is licensed under GPL-2.0-or-later and there is no paid edition of the software itself, so the cost of a healthcare site is the work around it: the content model, custom modules, hosting, identity integration, security patching and ongoing operations. Confirm with your compliance lead which forms, logins and integrations would capture ePHI, because those become the boundary cases. Typical options include handing sensitive intake to a separately hosted form or patient portal, passing only a reference or appointment slot to Drupal, and keeping authentication for staff or patients on a dedicated identity provider. Ask any partner to document each data flow and to show which Drupal modules or hosting components touch that data.

Any vendor or partner that creates, receives, maintains or transmits ePHI for you will need a business associate contract that flows the Security Rule terms down to their subcontractors, as described in 45 CFR 164.314. Note that no HIPAA certification exists, so you should ask for evidence of your own controls and not a certificate. Plan the build so that the boundary, the contracts and the evidence are reviewed together at each release, not once at launch.

Which healthcare requirements shape the Drupal build

This table maps each healthcare requirement in the topic sources to what it asks for and what it means for content modeling, access control, forms or hosting in a Drupal build. Read it as a list of design questions to settle before the build starts, since the HIPAA Security Rule governs the data flows and the Drupal site only carries part of them.

Requirement	What it asks for	What it means for the Drupal build
HIPAA Security Rule scope (45 CFR 164.302)	Applies to covered entities and business associates for all electronic protected health information they create, receive, maintain or transmit	Establish early whether the Drupal site will ever hold ePHI. If it only publishes public information, scope the controls accordingly; if patient data passes through it, the full rule applies to that site.
Administrative, physical and technical standards (Appendix A to Subpart C)	18 standards and 36 implementation specifications, 14 required and 22 addressable	Treat the Appendix A matrix as the checklist for the hosting and operations plan, and record how each addressable specification is met or why it is not applicable.
Technical safeguards (45 CFR 164.312)	Five standards with 7 implementation specifications; unique user identification and emergency access are required, while automatic logoff and both encryption specifications are addressable	Give each editor and administrator a unique account, plan an emergency access procedure, configure session timeouts in Drupal, and encrypt data in transit and at rest in the hosting design.
Business associate contracts (45 CFR 164.314(a)(2)(i))	Vendors handling ePHI must comply with the Security Rule, flow terms to subcontractors and report security incidents	Any agency, hosting provider or DeployOpen-style implementation partner that can reach ePHI needs these terms in its contract. Confirm which team members and subcontractors touch production data.
No HIPAA certification (HHS FAQ 2003)	No standard requires certifying compliance, and private certifications do not bind HHS	Ask any vendor for evidence of its controls, not a HIPAA certificate. DeployOpen prepares systems and evidence for assessments but does not issue attestations.
HIPAA penalties and proposed revision (45 CFR 102.3; 90 FR 898)	Penalties are inflation-adjusted per violation, and HHS proposed a major Security Rule revision in January 2025 that has not been finalized	Keep control evidence current and design for the proposed revision, which the Unified Agenda projects for final action in July 2027. Confirm the final text with counsel before relying on it.
NIS2 health sector listing (Directive (EU) 2022/2555, Annex I)	Lists healthcare providers and certain health manufacturers as sectors of high criticality	For organizations in scope in the EU, incident reporting and security measures apply to the whole organization, so the Drupal site must fit into the wider incident response and access management plan.
GDPR Articles 32 and 34 (CNIL fine, 3 September 2026)	CNIL fined Hopital Prive de la Loire EUR 500,000 for external access to patient records without VPN or multi-factor authentication and for access control that ignored care team need-to-know	Require VPN or strong authentication for any remote editor or clinical-system access, and build role-based access so staff see only what their role needs. Do not store patient records in the CMS to avoid this exposure.
Health data in forms and content (design consequence)	Requirements above apply to any ePHI the site receives, including form submissions	Keep patient-specific data out of Drupal entirely: use appointment or referral forms that hand off to a secure clinical or contact system, and avoid free-text fields that collect symptoms or identifiers.

How forms keep health data out of the CMS

The safest pattern for symptom checkers, appointment requests and patient intake is to keep the clinical data out of Drupal altogether. The form's submission handler posts the answers directly to the external system of record or patient portal, and the Drupal site keeps only what it needs to render the page: the form structure, routing to the destination, the consent wording and the confirmation message. Under this design, a Webform submission entity is never created for a health-related answer, so there is no submission table row, no revision, and nothing for the search index to pick up. Decide this at the design stage, because retrofitting it after content editors have started reading submission reports is much harder. Record the chosen destination, the transport and the fields that cross the boundary in the data flow document.

Several Drupal surfaces still need to be checked, because they can capture form input even when the submission itself is not stored. Webform's own settings govern whether results are saved, whether the handler logs the payload, and whether debug output is shown to editors. Watchdog and any external logging service can record request bodies or exception messages that include field values, so confirm that error handling logs only a reference ID. Entity revisions, cached render output and the search index should be tested with a dummy submission containing a clearly fake value, then searched for that value across the database, log storage, cache bins and the Search API index. Repeat the test after each release of the handler module, because logging defaults change over time.

Treat the consent text, the routing rules and the list of fields as clinical and privacy decisions, not web design decisions. Ask the covered entity's compliance lead to confirm which information the public form may collect, what the consent statement must say, whether the destination is covered by a business associate agreement under 45 CFR 164.314(a)(2)(i), and which incidents must be reported. The Drupal team can produce the test evidence, but the compliance lead decides whether the design meets the organization's obligations under the HIPAA Security Rule, which DeployOpen does not assess or certify. Keep the signed decision and the test results together so that a future reviewer can see who approved the boundary and when it was last tested.

Modules and settings that matter for hospitals

Hospital Drupal sites are shaped less by the number of modules than by a few decisions: how service lines and clinicians are modeled, how location search behaves, how intake stays free of health data, who may edit what, and how staff sign in. Each card names a capability to evaluate, and every contributed module needs confirming against the Drupal version you choose.

Content model for service lines and clinicians

Paragraphs lets editors compose service line pages from reusable blocks, such as conditions treated, referral instructions and clinician profiles, without free-form HTML that drifts from accessibility rules. Decide early which fields are shared (for example, a clinician listed under several locations) and which belong to one page. Confirm that the Paragraphs release you select supports your Drupal version, and test how revisions and translations behave for bilingual patient information.

Location and provider search with Search API and Solr

Search API with Solr is the capability to evaluate for provider directories and location search, where visitors filter by specialty, site, language and distance. Plan the index fields and facets against the data your directory actually holds, and decide how opening hours and accepting-new-patients flags are kept current. Confirm the Solr version and connector support for your Drupal release before design begins, and load-test the index with realistic query volumes.

Non-PHI intake with Webform and handoff

Webform can handle general enquiries, callback requests and feedback forms that collect no clinical details. The design question is the handoff: where submissions go, and whether they reach a clinical system or a contact centre tool outside Drupal. Keep free-text fields with health content out of the CMS, add clear on-page warnings, and confirm which Webform handler and encryption options fit your hosting. Forms that collect health data belong in a system built for that purpose.

Role-based editorial workflow with Group

Editorial control in a hospital usually spans central communications, service line owners and clinical reviewers. Role-based workflows, or the Group module for scoped content ownership, let a cardiology editor change cardiology pages without touching emergency pages. Map who may publish, who must approve clinical content, and how archived pages are retired. Confirm the workflow and moderation modules you select support your Drupal version and the revision model you need for audit trails.

Staff and partner sign-in with samlauth and OpenID Connect

The samlauth module lets Drupal act as a SAML service provider for hospital staff directories, and the OpenID Connect module handles OIDC providers, including partner accounts. Decide which roles may be provisioned on first sign-in and which need manual approval, since account creation on first login can grant more access than intended. Confirm the samlauth release and OpenID Connect client support against your Drupal version, and test logout and session timeout behavior.

Accessibility checking as a release gate

Patient information must be usable by people with disabilities, so accessibility checks belong in the build pipeline as well as in editorial review. Automated scanners catch only part of the problems, such as missing alternative text, low contrast and broken heading order, so pair them with manual testing by screen reader users on key journeys like booking and finding a clinic. Name the scanner, the pages it covers and the owner of each defect before the first release, and confirm the tool works with your chosen Drupal version.

Where integrations with clinical systems start and stop

Provider directories usually draw from credentialing, HR or the scheduling system, and Drupal publishes the public subset as profiles, locations and specialties. The integration should be one-way where possible, so the source system stays authoritative and Drupal never becomes the place where credentials are maintained. Field mapping is where most errors start, because a clinician's internal record often holds fields that should never reach a public page.

Crossing the boundary: name, professional title, specialty, practice location, accepting-patient status and public contact route, as agreed with the data owner.
Staying out: license numbers beyond what is published by the regulator, home addresses, personnel and payroll identifiers, disciplinary history and any internal notes.
Update cadence: whether the feed is full or incremental, how deletions and location changes propagate, and how Drupal handles a record that disappears from the source.
Validation: rejecting or quarantining records that fail required-field checks instead of publishing partial profiles.
Ownership: who signs off on each published field and who responds when a directory entry is wrong.

Before design starts, ask the credentialing or HR owner which export formats and interfaces they support, whether they can provide a change log, and which fields they are permitted to share. Do not assume a standard interface exists until the owner confirms it in writing.

How a healthcare Drupal rollout runs in phases

The sequence moves from classifying the data to launching and operating the site, so health information stays out of the CMS and each phase closes with evidence the organization can review. The plan is agreed in writing as a fixed-scope plan before build work starts.

Classify data and define scope
DeployOpen works with your compliance, privacy and clinical informatics leads to list every content type, form and integration the site needs, and to label each data element as public content, operational data, or protected health information. The output is a written data classification and a scope document that states which data may enter Drupal and which must stay in clinical or patient systems. The step closes when those owners sign off on the classification and the scope is agreed as a fixed-scope plan.
Design the content model and directory
Using the agreed classification, the team designs content types for service pages, patient information, clinician and location records, and the provider directory, including the fields needed for location search and the taxonomies that drive filtering. Editors and the web governance group review the model against real page workflows so that no field is added to capture data the classification excluded. The step closes with an approved content model, a field inventory and a sample set of location records that the team can test against.
Review accessibility and security
The team tests templates, the directory and each planned form against accessibility requirements and checks the design of authentication, roles, logging, backups and hosting against the safeguards your security and privacy teams expect. Findings are logged with severity, owner and a fix or accepted-risk decision. The step closes when open findings are resolved or formally accepted, and the review record is stored with the project documentation for your own compliance assessment.
Build integrations against test interfaces
Integrations with scheduling, identity, CRM or clinical-adjacent systems are built first against test or sandbox endpoints supplied by the owning team, with the data contract agreed in writing before code is written. Where a form would otherwise carry health details, the design routes that data to the approved system and the site only handles the non-clinical part. The step closes when integration tests pass against the test interfaces, error handling and retries are documented, and the owning teams confirm the contract.
Launch in a controlled release
Before go-live, DeployOpen runs a staged release in your hosting environment, with a rollback plan, a backup taken immediately before cutover and a checklist that confirms roles, logging, cache behavior and redirects. Content migration, where it applies, is reconciled against the classification so nothing sensitive is copied across. The step closes when the release checklist is signed by your owners and the site is live with the rollback path tested.
Operate and maintain after launch
After launch, the site moves to a documented operations routine covering security advisory response, updates, backups, monitoring and periodic review of the data classification as services change. Responsibilities for each recurring task are assigned in the support agreement, which can be a retainer. The step closes when the first operating review confirms that the runbook, alerts and ownership are working, and the classification is reviewed on the schedule your organization sets.

Compliance considerations and what Drupal evidence can show

Healthcare compliance rarely comes down to one platform setting. The cards below separate contractual obligations, enforcement, pending rule changes, voluntary assessments and regional law, so each control you configure in Drupal is mapped to the right question. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue any attestation or certification.

Business associate agreements and flow-down

Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the vendor to follow the Security Rule, pass the same terms to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. Map every hosting provider, managed service, email relay and analytics tool that could touch patient data in the Drupal stack, and check each one against that list. Confirm which party holds the contract with each hosting provider before the build starts.

No HIPAA certification, enforcement by complaint

HHS states that no Security Rule standard requires certification, and a private certificate does not stop HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Your evidence therefore needs to show how controls were designed, configured and operated over time, such as access reviews, patch records and backup restore tests, rather than a single badge.

Pending Security Rule revision

HHS proposed a major Security Rule revision on 6 January 2025. As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. Ask your counsel which proposed requirements, such as asset inventories and stricter recovery and encryption expectations, you would meet early, and keep those records in a form that a future review can read. Re-check the rule status before each phase gate.

HITRUST as a voluntary assessment

HITRUST CSF is a voluntary framework that some health systems and their vendors request in contracts. Its certifications carry their own terms: e1 and i1 certifications last one year and r2 certifications last two years, and the assessment is performed by an authorized assessor, not by DeployOpen. Decide whether a HITRUST scope is needed before the architecture is fixed, because the CSF version in force, such as v11.9.0 from 24 September 2026, determines which control specifications apply.

GDPR and the European Health Data Space

For European operations, GDPR Articles 32 and 34 shape how security and breach notification work in practice. In September 2026 the French CNIL fined Hopital Prive de la Loire EUR 500,000 after finding that external access to a patient record system lacked VPN and multi-factor authentication and that access ignored care team need-to-know. Regulation (EU) 2025/327 on the European Health Data Space adds rules for health data use. Check whether your Drupal forms and portals carry health data, and where those records are stored.

21 CFR Part 11 for regulated research records

21 CFR Part 11 governs electronic records and electronic signatures in FDA-regulated work, such as clinical research records. It does not apply to ordinary patient information pages or appointment forms. If a Drupal site collects research data or captures signatures for regulated studies, confirm with your quality team which audit trail, identity and signature controls apply, and keep that workflow separate from general content editing.

What healthcare teams ask before hiring a Drupal partner

What drives the cost of a Drupal project for a health system?

Cost follows the written scope, and the biggest drivers are the number of integrations, the content model, the accessibility and forms work, and how many sites or languages are involved. Each integration with a clinical, identity or CRM system adds analysis, build and testing effort, and each custom module adds code that must be maintained later. Ask for a quote that separates one-time build work from recurring items such as hosting, security updates and support. DeployOpen does not publish prices, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How long does a Drupal build for a hospital take?

Duration depends mainly on how many integrations the site needs, how much content must be migrated, and how many approval steps the content goes through. A directory with a single data feed and a small content model is a much smaller piece of work than a patient-facing portal that depends on identity federation and forms that must keep health data out of the CMS. Ask for a timeline tied to named milestones and to the decisions your team must make, such as which clinical system is the source of record for provider data. Scheduling also depends on your change-control and security review windows, which are set by your organization.

What does the health system's own staff need to contribute?

Your staff need to supply decisions and access rather than write the code. Typical inputs include a named content owner for each section, a clinical or compliance reviewer for patient information, technical contacts for identity and integration endpoints, and a test environment that mirrors production. Expect them to approve the content model, sign off on accessibility testing results and review the data flow for any form that collects patient details. Ask the partner to list these inputs in the statement of work so that delays can be traced to a specific owner.

Can our internal team run the Drupal site after launch?

Yes, if the site is built with documented configuration, custom code that follows standard Drupal practices and a clear operating routine. Your team will need to apply core and contributed module updates, monitor the site, manage backups and handle access reviews. Ask for handover material that covers deployment steps, the module inventory, runbooks for common incidents and the security advisory process. Drupal core security releases are published on the third Wednesday of the month, and bugfix releases on the first Wednesday, so your team needs a rota that can respond on those dates. Support and continuous testing can also be arranged as a retainer if your team prefers a shared model.

What happens to our Drupal 7 site, and how long can we stay on it?

A Drupal 7 site cannot be updated in place to Drupal 10 or later. It must be migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and its themes must be rebuilt because they cannot be migrated. Drupal 7 security support ended on January 5, 2025, according to Drupal.org. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet, so ask whether that interim cover is needed while the migration is planned. Confirm current PHP and database support for the target version before you commit to a date.

What should a business associate agreement with a Drupal partner cover?

Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the HIPAA Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. Ask counsel to confirm which parts of the engagement touch ePHI, such as hosting, support access and test data, and whether the partner will ever see it. Note that there is no HIPAA certification: HHS states that no Security Rule standard requires certifying compliance, so ask for evidence of controls rather than a certificate. The full rule is set out in 45 CFR Part 164 Subpart C.

Will a Drupal partner handle HIPAA compliance for us?

No partner can make a health system compliant on its own. Covered entities and business associates remain responsible for their own compliance, and the HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask your compliance lead to define which controls the Drupal site must support, such as unique user identification and automatic logoff, and to confirm the relevant requirements with counsel before work starts.

How DeployOpen scopes and supports healthcare Drupal work

DeployOpen plans, builds, hardens, documents and supports Drupal inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For healthcare organizations, the work starts with a written scope that separates public content from any system that touches patient or health data, so the boundaries are agreed before the build begins.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists which sites, directories, forms and integrations are in and which clinical systems stay out.
Scoping records the data each form collects so privacy and security reviews have a clear starting point.

How we build

Custom modules for provider directories and location search are built, tested and reviewed against the agreed content model.
Accessibility checks run during build on templates, navigation, forms and patient information pages.
Integrations with identity and clinical-adjacent systems use the agreed data contract, with test data kept separate from live records.

How we hand over

Handover includes configuration records, architecture notes, integration boundaries and a list of data flows.
Runbooks cover content workflows, deployment steps, backups and restore testing in your environment.
Your team receives documented decisions on what data the CMS holds and what it must never store.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers.
Security advisories for Drupal core and contributed modules are reviewed and applied on a schedule you agree.
Confirm with your compliance and legal teams which controls your organization needs before going live, since DeployOpen prepares evidence but does not issue audit reports or certifications.