Open source CMS for healthcare

Directory pages, provider profiles and location pages are usually public content, and a page that lists a clinic's hours, address or a physician's specialties does not by itself contain ePHI. The risk appears when the page is personalized or when a visitor's browsing reveals a health relationship. A page for a cardiology clinic that is opened from a patient portal message, or a URL that identifies a specific patient's appointment location, can shift the context. Under the HIPAA Security Rule, ePHI is individually identifiable health information the covered entity creates, receives, maintains or transmits, so the question is whether the site connects a visitor to care.

• Static directory content: Provider bios and location data published to everyone generally sit outside ePHI scope, but they still need integrity controls so the published information stays accurate.
• Filtered or personalized views: Search results or pages that reflect a visitor's condition, insurance plan or referral status may create ePHI if the input is stored or linked to an identity.
• Campaign and deep links: Landing pages generated for specific patient populations can reveal health interests through the URL, referrer or query string.
• Server and access logs: Logs that record which pages were requested from which addresses can become ePHI when tied to a care context, so retention and access rules matter.
• Hosting boundary: Public content and protected content should be separated in the architecture so that the controls for one do not weaken the other.

Confirm with privacy counsel which pages, query parameters and log fields are in scope before you set access and retention rules.

Forms that collect a name, date of birth, reason for visit or insurance details are the clearest case where website data becomes ePHI. Once a submission is linked to a care request, it is individually identifiable health information that the covered entity receives and maintains, so the Security Rule applies to the form, its transmission, storage and any notification emails. The form plugin, mail relay and any integration that forwards submissions to a scheduling system all become part of the ePHI path.

• Encryption in transit and at rest: Submissions should travel over encrypted connections and sit in encrypted storage, and the encryption choices should be documented as part of the risk analysis.
• Minimal fields: Collecting only what the scheduling team needs reduces the amount of ePHI the website holds and the number of systems that must be protected.
• Notification content: Confirmation emails should avoid including clinical detail in the subject line or body, since email is often transmitted and stored outside the controlled environment.
• Business associate agreements: Form hosts, email providers and scheduling vendors that receive submissions typically need a business associate contract under 45 CFR 164.314 before any data flows.
• Retention and deletion: Stored submissions need a defined retention period and a deletion process that covers backups.

Check the form data map with your privacy counsel and confirm that each vendor in the path will sign the required terms.

Links from the public website into a patient portal are a common boundary point. The link itself is generally not ePHI, but the moment a visitor is authenticated, the session, the portal page and any data passed in the URL or cookies can be ePHI. The website team and the portal team often own different parts of this path, so responsibility for the handoff needs to be written down. This is also where identity controls such as unique user identification and automatic logoff are most visible to patients and staff.

• Link destinations: Links should point to the portal domain without patient identifiers, session tokens or diagnosis codes in the query string.
• Session handling: Automatic logoff and session timeouts are addressable specifications under the technical safeguards, so the choice and its rationale should be recorded.
• Single sign-on: If the CMS editors and portal staff share an identity provider, the access model must keep patient and editor roles separate.
• Referrer leakage: Third-party resources on the portal page can receive the referring URL, so the boundary page should carry no sensitive parameters.
• Emergency access: Procedures for access during an outage should be defined for the portal path, since the HIPAA technical safeguards include an emergency access procedure as a required specification.

Confirm with your security and privacy teams where the portal boundary sits and who signs off on changes to the handoff.

Analytics pixels, advertising tags and tag managers are the most common source of unexpected disclosure on hospital websites. A tag that fires on a page about a specific condition, a form confirmation or a portal link can send the page URL, referrer and visitor identifiers to a third party. If the tag provider is not a business associate and the data identifies a health relationship, the disclosure may be impermissible. Tag managers add risk because the set of scripts can change without a code release, so the tag inventory is a moving control.

• Third-party disclosure: Each tag that receives page URLs or form values should be reviewed for whether it receives ePHI and whether a business associate contract exists.
• Tag manager governance: Restrict who can publish tags, require review of new tags, and log every change.
• Consent and cookies: Consent settings should control tags that set identifiers, and the consent record should be retained as evidence.
• Self-hosted analytics: Running analytics on infrastructure you control keeps the data inside the hosting boundary but still needs the same risk analysis for its logs.
• Enforcement context: Regulators have treated weak controls around external access to patient systems as a serious failure, so tracking decisions should be documented alongside access controls.

Confirm with privacy counsel which tags are allowed on which pages and obtain written terms from every vendor that could receive ePHI.

Editor accounts do not hold patient data by design, but they control the content and the code that every visitor receives. An editor who can change a form, add a script or edit a page that collects data can alter how ePHI moves. Editor accounts also appear in audit logs, and a compromised editor login can be used to inject tags or skim form submissions. For this reason, editor access belongs in the risk analysis even when the content itself is not ePHI.

• Unique identification: Each editor should have an individual account, since unique user identification is a required specification under the technical safeguards.
• Role separation: Separate roles for content, script publishing and form configuration reduce the number of people who can change data collection.
• Multi-factor authentication: Strong authentication for editors protects the most privileged path into the public site, and the choice should be documented.
• Audit trails: Logs of publishing, script changes and form edits support investigations and the evidence an auditor will request.
• Offboarding: Access removal for former staff and contractors should be part of the standard process.

Confirm with your security team how editor roles map to the data classes above and who approves changes to tags and forms.