Why a healthcare open source headless CMS is different
A health system, payer or provider group that wants patient-facing content and apps on a self-hosted headless CMS should start from one fact: the CMS can be built to hold no electronic protected health information (ePHI), but the pages around it often do. Forms for appointment requests, symptom questionnaires, scheduling widgets, portal handoffs and analytics tags can all capture health-related details the moment a visitor interacts with them. Under the HIPAA Security Rule (45 CFR Part 164 Subpart C), that data is ePHI when a covered entity or a business associate creates, receives, maintains or transmits it. The practical question for the architecture team is therefore not whether the CMS stores patient records, but which front-end and integration paths can move health-related data into the CMS, a form tool or a third-party script. Map those paths before choosing a platform, and record who is the business associate for each one.
On platform fit, Strapi, Payload and Directus can each serve a headless content API, and the choice depends on three things: the content model your medical and marketing teams need, the editor roles and approval steps you must enforce, and which paid features you require. Strapi's self-hosted plans, for example, place SSO for administrator login and audit logs and review workflows in tiers that cost more than the Community Edition, so confirm those features against your requirements before you assume they are included. Payload is a Next.js framework and Directus is a data platform with its own licensing terms, so the team that will maintain each system matters as much as the feature list. Ask each candidate partner to show the content model, role matrix and admin login flow running in your own environment, and do not treat any CMS as compliant by default.
Which healthcare requirements shape the CMS build
This table maps each healthcare requirement to what it asks for and what it means for CMS hosting, admin login, form routing and content separation. Read it as a checklist for the scoping conversation: the rows that apply depend on whether your organization is a covered entity, a business associate, serves EU patients or is a public provider.
| Requirement | What it asks for | What it means for the CMS build |
|---|---|---|
| HIPAA Security Rule scope | Applies to covered entities and business associates for all ePHI they create, receive, maintain or transmit (45 CFR 164.302) | Decide early whether the CMS, its forms and its logs will ever hold ePHI. If they might, the hosting and vendor contracts must cover it |
| Unique user identification (164.312) | Each person accessing systems with ePHI has a unique identifier (required) | Editors and admins need individual accounts, never shared logins. Confirm how the CMS admin panel and any patient-facing login map identities |
| Emergency access and automatic logoff (164.312) | A documented emergency access procedure (required), and automatic logoff (addressable) | Plan a break-glass admin path that does not depend on the identity provider. Set session timeouts for the admin panel, especially on shared workstations |
| Encryption (164.312) | Encryption of ePHI at rest and in transit (addressable, so a documented decision is needed) | Encrypt the database, media storage and backups, and enforce TLS on every front end and API call. Record the reasoning if you choose an alternative |
| Business associate contract (45 CFR 164.314) | The vendor must follow the Security Rule, flow the same terms to subcontractors handling ePHI, and report security incidents | If a hosting provider, implementation partner or analytics vendor touches form data, get these terms in writing before go-live. Ask who the subcontractors are |
| GDPR Articles 32 and 34 (CNIL fine, 3 September 2026) | Appropriate security, and notification of individuals after a breach. The CNIL fined Hopital Prive de la Loire EUR 500,000 for external access without VPN or multi-factor authentication and for access control that ignored need to know | Put admin and editor access behind VPN or equivalent controls with multi-factor authentication. Limit clinical staff access to the content they need, and restrict who can view form submissions |
| NIS2 Annex I health sector (EU) | Health providers and some medical device and pharmaceutical manufacturers are high-criticality entities (Directive (EU) 2022/2555) | If your organization falls in scope, the CMS and its hosting become part of your supplier and incident governance. Confirm your national transposition and obligations with counsel |
| ADA Title II, WCAG 2.1 AA (public providers) | State and local government web content and mobile apps must meet WCAG 2.1 Level AA. Compliance dates are 26 April 2027 for entities with 50,000 or more people and 26 April 2028 for smaller entities and special districts (ADA.gov interim final rule, 20 April 2026) | Public hospitals and clinics should test patient-facing templates and form components against WCAG 2.1 AA. Content editors need accessible authoring guidance, not just a theme |
| Content and clinical separation | Keep marketing and educational content apart from clinical records and EHR data (a planning principle, supported by HIPAA minimum necessary thinking) | Do not feed patient records into the CMS. Use the CMS for public content and apps, and send any patient-specific data to the systems that already hold it under controls |
Which data stays out of the CMS and which must be walled off
Clinical records never enter the CMS. A headless CMS holds editorial content, media, and the configuration that feeds your patient-facing front ends. Electronic health record data, lab results, diagnoses, and visit notes belong in the clinical systems that already carry HIPAA safeguards and business associate terms. Treat the CMS as a publishing system with no path to patient records: no content type should hold a patient identifier, and no plugin or custom controller should query the EHR. Where a page needs to show personal status, such as an appointment or a result, link out to the portal rather than rendering the data from the CMS. Confirm this boundary in the content model review before build, and again after any new content type is added.
Forms are the usual leak. A contact or intake form that asks about symptoms, medications, or a condition creates ePHI the moment it is submitted, and the CMS database then stores it in a place outside your clinical controls. Route any form that collects health information to a controlled service, such as your existing patient intake system or a form service your organization has contracted under a business associate agreement where the HIPAA rules apply. Ask the vendor whether it will sign that agreement and whether the business associate contract flows down to its subcontractors. The CMS should receive only a submission reference or a redirect. Tracking pixels and analytics tags also deserve review on any page behind authentication, since they can transmit page paths or query strings that reveal care context.
Authentication needs a precise reading. Strapi SSO covers administrator login to the admin panel through an identity provider, and it does not govern patient accounts. End-user sign-in on a Strapi site is handled by the Users and Permissions plugin, so a patient portal front end needs its own authentication design, multi-factor authentication, session timeouts, and access rules, and your security team should review that design separately. Confirm with Strapi which features you are relying on in the self-hosted plan you select, because the pricing page lists SSO as an add-on for Growth and as included in Enterprise. Document the split between editor identity and patient identity so that an auditor can see which system controls each.
Which headless CMS platforms fit a healthcare build
Three open-source headless CMS products cover most healthcare patient-facing builds, but their license terms, database support and paid features differ in ways that matter for medical content and access control. The cards below set out what each product's license allows, what runtime it needs, and what to confirm about approval workflows and audit logging before you choose.
Strapi Community and Enterprise editions
Strapi's Community Edition is MIT licensed, but code under ee directories belongs to the separately licensed Enterprise Edition, so a build must be checked file by file against the license terms. Strapi 5 supports PostgreSQL 14 or later, MySQL 8.0 or later and MariaDB 10.3 or later, does not support MongoDB, and runs only on Active or Maintenance LTS Node.js versions. Confirm that the review workflows and audit logs your medical sign-off needs sit in the Enterprise plan, because the pricing page lists them as Enterprise features while SSO is an add-on on Growth.
Strapi admin SSO scope
Strapi SSO covers administrator login to the admin panel through an identity provider such as Microsoft Azure Active Directory, with auto-registration, a default role and an optional local login lock-out. It does not authenticate patients or the public. End-user accounts for patient portals or logged-in features are handled by the Users and Permissions plugin, which means a separate authentication design is needed. Map editor roles to clinical and marketing reviewers before go-live, and test the lock-out setting against your break-glass procedure.
Payload under MIT with Next.js
Payload is an open-source Next.js framework usable as a headless CMS and is licensed under MIT, which imposes few restrictions on internal or commercial use. It suits teams with strong TypeScript and Next.js skills, because the data model, access control and admin interface are written in code that your developers own and must test. Confirm how the chosen version handles field-level access, version history and publishing approvals, since these controls are configured in code rather than selected from a paid tier, and document them as part of your evidence.
Directus under MSCL-1.0-GPL
Directus is licensed under the Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL), which permits use for any purpose other than a competing use. The license explicitly includes internal use and professional services to deploy or host the software for a licensee, which fits a partner-delivered build inside a health system's own infrastructure. Have counsel review the license text against your planned use. Directus supports relational databases, so confirm the database engine and version it requires for your hosting pattern, and verify which workflow and audit features your target edition provides.
Matching the CMS to the clinical boundary
Whichever product you choose, the CMS should hold public medical content, not patient records. Its database, admin accounts and form submissions must stay outside the clinical systems that hold ePHI, and any vendor or partner that hosts the CMS for you will need a business associate contract under 45 CFR 164.314 if it handles ePHI. Decide early which features, such as appointment forms or patient-specific messages, would bring the CMS into scope, because that decision changes the controls, hosting and contract terms you need.
Verifying the release line before selection
Version numbers change quickly, so confirm the current stable release and its support window for each product before you commit. Strapi v4 reached end of life on April 30, 2026, which means any healthcare build that starts on that line needs a planned upgrade path to Strapi 5. Ask your implementation partner to document the chosen release, the database and Node.js versions it supports, and the patch cadence you will follow, so your security and change records show what runs in production.
How a healthcare CMS rollout moves from scoping to go-live
The sequence turns a patient-facing content idea into a governed, tested and documented Strapi, Payload or Directus deployment inside your own infrastructure. Each phase closes with a written output, so clinical, security and compliance owners approve the platform before patients use it.
Scope the content and classify the data
The team lists the sites, apps, forms and content types in scope, then classifies every data flow as public content, tracking data, form input or potential ePHI. DeployOpen runs this with your privacy officer, clinical content lead and security team. It is done when a signed data inventory shows which flows could reach ePHI, which must never touch the CMS, and which open questions need legal review.
Set the architecture and trust boundary
The architecture phase decides where the CMS, its database, media storage and preview environment run, and which systems sit on each side of the boundary. It also defines how editors authenticate, how the front end reads published content and which services may receive form or tracking data. DeployOpen produces a reference diagram, a network and identity design, and a list of business associate or processor agreements the chosen hosts require. It is done when your security team signs off the diagram.
Design the content model and medical review workflow
Content types, relationships, locales and reusable components are modeled around what patients read, such as condition pages, medication information and appointment guidance. The review workflow defines stages for clinical accuracy, legal or regulatory checks and accessibility review, with named roles and no single person able to approve their own work. Paid edition features such as review workflows and audit logs are confirmed against the scope here. It is done when a content specification and a role matrix have been approved by the clinical and compliance owners.
Build and integrate the platform
Engineers install the chosen CMS on your infrastructure, configure the database and media storage, build the content models and the front end that reads from the API, and connect the systems that must stay separate, such as scheduling or patient portals, through narrow, documented interfaces. Tracking and form submissions are routed to approved services with the data minimized before it leaves the CMS. It is done when a build record lists versions, configuration, integrations and the data each integration receives.
Test accessibility and security
Accessibility testing checks the front end against WCAG 2.1 Level AA, the standard referenced in the ADA Title II rule for public entities, and the editor interface for keyboard and screen reader use. Security testing covers the CMS, its API, the admin login, the hosting configuration and the form and tracking paths, with findings tracked to closure. DeployOpen delivers test reports and a remediation list. It is done when no open high-severity finding remains without an accepted risk decision signed by your owner.
Launch in a controlled way with monitoring
The launch starts with a limited set of pages or a restricted audience, with monitoring for availability, errors, unusual access to the admin panel and changes to published medical content. Rollback steps are rehearsed before the wider release, and the go or no-go decision is recorded against the test results. It is done when the controlled release has run without open incidents and the owner has approved expansion in writing.
Hand over with runbooks and evidence
The handover package includes runbooks for backup and restore, upgrades, access reviews, incident response, content publishing and key rotation, plus the configuration and evidence your compliance team needs for later assessments. Your staff are trained on the admin panel and the review workflow. DeployOpen prepares the evidence but does not issue audit reports or certifications. It is done when your team has run a restore test and signed the handover document.
What auditors and regulators ask for from the CMS
This table maps the evidence an assessor or OCR investigator is likely to request for a healthcare CMS to the component that produces it. HIPAA has no certification, and HITRUST assessments are optional, so the evidence matters more than any badge. Use the rows to check whether your CMS can produce each record on request.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Access reviews for admin and editor roles | Who holds which role, and that access was reviewed and removed when people changed jobs | Strapi admin roles and permissions, reviewed against the identity provider directory |
| SSO and MFA configuration | Administrator sign-in goes through the organization's identity provider with multi-factor authentication | Strapi SSO for admin login (paid self-hosted add-on or Enterprise), plus the identity provider's MFA policy |
| Audit logs of content changes and approvals | Who edited, published or approved medical content, and when | Strapi audit logs and review workflows (Enterprise edition); confirm equivalent logging for Payload and Directus |
| Business associate agreements and flow-down records | Contracts require the vendor and any subcontractor touching ePHI to meet the Security Rule and report incidents | Legal and procurement records for hosting, DeployOpen and any CMS cloud provider, with subcontractor lists |
| Risk analysis inputs | Assets, threats and likelihoods for the CMS and its integrations, as NIST SP 800-66 Rev. 2 describes for implementing the Security Rule | Asset inventory, data flow diagrams and configuration baselines maintained by the operator |
| Encryption and backup records | Data is encrypted in transit and at rest where the organization has determined this applies, and backups can be restored | Database and media storage settings, TLS configuration, and restore test logs from backup tooling |
| Accessibility test results | Patient-facing front ends meet the accessibility target the organization has adopted | Automated scan and manual audit reports for the front end, kept alongside CMS content releases |
What healthcare teams ask before building a headless CMS
Does a headless CMS fall under HIPAA?
It depends on what the CMS stores and who runs it. The HIPAA Security Rule applies to covered entities and their business associates for all electronic protected health information they create, receive, maintain or transmit (45 CFR 164.302). A public marketing site that holds no patient data may sit outside that scope, but a patient portal, appointment form or symptom checker that stores identifiable health information usually does not. Map each content type, form and tracking tag to its data flow before deciding. If a vendor or implementation partner will touch ePHI, a business associate contract must be in place under 45 CFR 164.314, and it must require security incident reporting. Confirm the scope with your privacy and legal teams.
Which Strapi edition do we need for SSO and review workflows?
On Strapi's self-hosted plans, administrator SSO is an add-on for Growth and included in Enterprise, while audit logs and review workflows are Enterprise features. Content history and releases start at the Growth plan. Strapi's Community Edition is MIT licensed, but code under ee directories belongs to the separately licensed Enterprise Edition, so check which features you are depending on before you commit. Strapi SSO covers administrator login to the admin panel only. Patient or member logins are handled by the Users and Permissions plugin and need their own design. Confirm current plan contents with Strapi before you buy, because plan limits change.
How much does a healthcare headless CMS project cost?
The cost has four parts: the software license, the hosting, the implementation work and the ongoing operation. Strapi's self-hosted Community Edition is free to license, and its Growth plan was listed at 45 US dollars per month including 3 users, with 15 dollars per extra user, according to Strapi's self-hosted pricing page. Strapi Cloud hosting was listed at 35 US dollars per month per project for Starter, 90 for Pro and 450 for Business. The larger costs usually come from the content model, the integrations, the security review and the front-end build. Those scale with the number of content types, locales, editors, form flows and the hosting environment inside your own cloud or data center. Ask any partner for a fixed-scope quote that separates one-time work from recurring hosting and support.
What drives the cost up or down?
Scope drives most of the variance. The main factors are:
- The number of content types, components and locales that the front end must render.
- The number of editors and approval stages, which affects role design and any paid edition needed.
- The number and type of integrations, such as a patient portal, identity provider, CRM or analytics tool.
- Where the platform is hosted, including whether it runs inside your own cloud account, a private data center or an air-gapped network.
- Whether the work includes a migration from an existing CMS or a version upgrade, such as moving from Strapi v4 to v5.
Each factor can be priced separately in a written scope. Ask for those line items in the quote so you can see which choices move the total.
How long does a headless CMS rollout take in healthcare?
The timeline depends on the content model, the number of integrations, the review and sign-off process, and the security evidence you need before launch. Strapi 5 requires PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later, or SQLite 3, and it runs only on Active or Maintenance LTS Node.js versions, so environment preparation is a real step to plan for. If you are migrating from Strapi v4, note that v4 reached end of life on April 30, 2026, and the migration documentation advises backing up the database first because downgrading is not supported. Ask any partner for a phased plan with dated milestones, and agree which phases depend on your security and compliance reviews.
What must our team supply before the build starts?
Your team should provide the content inventory, a data flow map showing where patient data, form submissions and tracking events go, and the list of roles that need access. You should also supply the identity provider details for administrator SSO, the hosting account or environment, database and backup requirements, and the medical review rules that govern which content needs clinical sign-off. Named owners for security, privacy, clinical content and accessibility decisions are essential, because scope changes often trace back to unanswered questions in these areas. Put these inputs into the written scope so responsibilities and dependencies are clear from the start.
Can our internal team run a self-hosted headless CMS?
Yes, many teams can run it, provided they staff the skills the platform needs. Running Strapi, Payload or Directus in your own environment means someone must manage the database, the Node.js runtime, upgrades, backups, access control, patching and monitoring. Upgrades matter in particular, because major versions change APIs and data formats. A practical test is whether your team can restore a backup, apply a version upgrade in a staging environment and explain who approved each change. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the client's own infrastructure, and ongoing support can run as a retainer. Your team can also keep operations in-house and use a partner only for the build.
What to ask an implementation partner for a healthcare CMS
Start with scope, because a partner who cannot say where their responsibility begins and ends is not ready for ePHI. Ask whether they will sign a business associate contract under 45 CFR 164.314(a)(2)(i) before any work starts, and whether that contract flows the same Security Rule terms down to their own subcontractors, such as hosting providers and managed database operators. Ask them to name every system that could touch patient-related data during the build, including preview environments, staging copies of the database and support tooling. Then ask how they will prove the CMS stays outside ePHI scope. A strong answer names specific controls: a content model with no patient identifiers, form submissions routed to a separate system, and tracking tags that do not send appointment or condition details. Ask for the written data flow diagram before design sign-off, and expect them to say which party is responsible for each component.
Ask how the partner keeps form and tracking data away from ePHI in practice. Request a walkthrough of where symptom checker, appointment or contact form submissions are stored, whether the CMS holds them at all, and how analytics and marketing tags are configured so that page URLs and query strings do not carry identifiers. Ask how medical content review is modeled: which roles can draft, which can approve clinical claims, whether approvals are recorded in Strapi's audit logs and review workflows (an Enterprise feature under Strapi's self-hosted plans) or in a separate system, and how scheduled publishing is blocked until sign-off is complete. Ask how admin SSO is configured against the identity provider, including default roles, the local login lock-out option and how leavers are removed. Note that Strapi SSO covers administrator login only, so ask how end-user access is handled through the Users and Permissions plugin.
Ask how accessibility is tested against WCAG 2.1 AA, which is the standard named in the ADA Title II rule for state and local government content. Healthcare organizations that are public providers should confirm their own deadline with counsel, since the rule's compliance dates depend on entity size. Ask who runs the automated and manual checks, which assistive technologies they use, and whether the test plan covers the front end that the CMS feeds, not only the admin panel. Then ask how they will handle a Strapi major upgrade. Strapi v4 reached end of life on April 30, 2026, so any inherited v4 estate needs a plan. Ask for their migration method, including the upgrade codemods, the data migration step, the required database backup, and the fact that downgrades are not supported. Ask which Node.js and database versions they will pin, and how they will test the migrated content model before cutover. Finally, ask what evidence they hand over at the end: architecture and data flow documents, configuration baselines, access reviews, backup and restore test records, accessibility test reports and the signed business associate contract. Confirm that the evidence supports your own assessment work, since HIPAA has no certification and the HHS Office for Civil Rights reviews compliance directly.
Which hosting setup fits a healthcare organization
In this model the organization deploys Strapi, Payload or Directus into its own cloud account, under its own network controls, identity provider and encryption keys. The CMS itself is open source, so the license cost of the software is not the main contract question. The question is which parties touch ePHI and under what terms. If the CMS only holds public content, the cloud provider may not handle ePHI at all. If form submissions, appointment requests or tracking data pass through the CMS, the cloud provider is typically a business associate and needs a business associate agreement under 45 CFR 164.314(a)(2)(i) that flows the same obligations to subcontractors.
- Business associate chain: Confirm whether the cloud provider will sign a business associate agreement for the services you use, and whether its subcontractors are covered.
- Logs: Application logs, database logs and access logs stay in your account. Decide retention, and make sure logs containing form content or identifiers are masked or excluded.
- Media: Uploaded images and documents sit in object storage you configure. Set private access by default and confirm encryption at rest.
- Shared responsibility: Your team owns patching, backups, network rules and the Node.js and database versions that Strapi 5 supports.
- Paid features: SSO for administrators on Strapi is an add-on on the Growth plan, and audit logs are an Enterprise feature, so budget for them if your audit trail needs them.
Before signing, check the cloud provider's current business associate terms and the subprocessors list, and confirm who is accountable for each log source.
Here the CMS runs on servers in a data center you operate or lease, or on a private network that is not reachable from the public internet except through controlled paths. This model suits organizations with existing hosting commitments, strict data residency rules or air-gapped segments. No third-party cloud provider is a business associate for the CMS, but any colocation provider, managed service partner or support vendor that can reach the systems may be. Your partner's access to the environment is a disclosure risk that belongs in the contract.
- Business associate chain: Only parties that create, receive, maintain or transmit ePHI need agreements. A colocation or managed hosting provider with physical or remote access usually falls within scope, so confirm this with counsel.
- Logs: Logs remain on your storage. Plan central log collection, retention and access review as part of the build.
- Media: Store uploads on encrypted volumes or an internal object store with access tied to your identity provider.
- Remote support: Define how an implementation partner gets access, with named accounts, session recording and time-limited credentials.
- Updates: Without a managed cloud service, you must schedule patch windows and test upgrades yourself, including Strapi minor releases that ship roughly weekly.
Confirm your facility agreements, remote access procedures and which staff hold administrative credentials before the environment goes live.
A vendor-hosted option means the CMS vendor operates the environment. Strapi Cloud lists Starter at 35 US dollars per month per project, Pro at 90 and Business at 450, each with API request, storage and bandwidth allowances. Business carries a 99.9% uptime SLA. Those figures come from Strapi's cloud pricing page and may have changed since publication. In this model the vendor is typically the party holding ePHI in its service, so it must sign a business associate agreement before any patient data enters the platform. Treat the vendor's answer to that request as a go or no-go question.
- Business associate relationship: Ask whether the vendor will sign a business associate agreement for the specific plan you select, and whether that covers its hosting provider.
- Logs and media: Confirm where the vendor stores logs, backups and uploads, which region they sit in, and how long they are retained.
- SLA terms: The 99.9% uptime figure applies to the listed Business plan. Read the credit mechanism and exclusions in the contract, not just the pricing page.
- Identity: Check whether admin SSO is available on the plan you need, since the SSO add-on sits on Growth and is included in Enterprise.
- Exit and data return: Confirm export formats and deletion timelines when the contract ends.
Confirm the business associate agreement, the subprocessor list, the data location and the SLA terms in writing before any ePHI is loaded.
How DeployOpen scopes and supports a healthcare CMS
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. For a healthcare CMS, that means the Strapi, Payload or Directus instance, its database, media storage, identity connection and the front-end delivery path can all run where your security team already has controls in place. The same team also runs application and API security testing and prepares systems and evidence for compliance assessments, so the CMS can be reviewed on the same terms as your other systems that touch patient-facing content.
DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. HIPAA has no certification, and any HITRUST assessment is performed by an independent assessor. Ask a partner to state in writing which artifacts it will deliver, such as configuration baselines, data flow diagrams, role matrices, backup and restore test records and the business associate terms it will sign, and which decisions remain with your privacy officer, counsel and assessor. Confirm also whether your organization or the partner will act as the business associate for any ePHI that reaches the CMS, since that determines which contract applies.
Engagements are fixed-scope. Before any work starts, the partner should put the scope, deliverables, responsibilities and timelines in writing, including which content types are in and which clinical systems are out. DeployOpen does not publish a price list, and a quote follows from that written scope. When you request one, ask the partner to separate one-time work (architecture, content modeling, hardening, integrations, testing, migration) from recurring work (upgrades, patching, backups, monitoring and retainers), and to state what changes the quote, such as additional locales, new SSO connections or extra review stages.
