Calendly alternative for HIPAA and patient scheduling

The form fields define your ePHI footprint more than the software does. A booking record that holds a name, phone number, email address, service type and provider can become electronic protected health information as soon as it is linked to a patient visit, because the fact that a named person is seeing a named clinician for a specific service is itself health information. Treat every field in an Easy!Appointments booking form as in scope for the Security Rule until your analysis shows otherwise. Start by listing each field, the service it maps to and the systems that receive it, including reminder emails, the calendar sync to Google Calendar and any database export.

Apply minimum necessary collection to the form itself. Ask only for the contact details needed to confirm and reschedule an appointment, use generic service names where a specific diagnosis or procedure would otherwise appear, and do not provide a free-text box that invites clinical reasons for the visit. Intake questionnaires, medical history, insurance details and symptom descriptions belong in a separate, access-controlled clinical system, not in the scheduler. Confirm with the service's owner which fields a patient must complete before the visit and which can be collected later, and document that decision. Decide these questions with your privacy counsel and compliance lead, because the answer depends on your covered entity or business associate status and on any state or national rules that apply to you.

Access control matters as much as field design. The CNIL fine of EUR 500,000 against Hopital Prive de la Loire on 3 September 2026 under GDPR Articles 32 and 34 found that external access to patient records lacked VPN and multi-factor authentication, and that access rights ignored the care team's need to know. The lesson for a scheduler is that staff who manage bookings should see only the scheduling fields they need, not the full patient record, and that remote administration of the server must sit behind strong authentication. Before go-live, review who holds administrator and provider roles in Easy!Appointments and confirm that the database and any API credentials are reachable only from approved networks.

The covered entity signs the business associate contract, and that contract travels down the chain. Under 45 CFR 164.314(a)(2)(i), the business associate must comply with the Security Rule, flow the same terms down to any subcontractor that handles ePHI, and report security incidents, including breaches of unsecured PHI, to the covered entity. For a clinic running Easy!Appointments, the parties that may touch ePHI include the hosting provider, any managed service or backup provider, and DeployOpen if it installs, configures or operates the system. Each of them needs a written contract with the clinic, and each subcontractor that stores or accesses the data needs the same terms from the party above it. Ask every vendor for its BAA template and confirm that its subcontractor list is current.

Easy!Appointments has no vendor BAA because it is GPL software, not a hosted service. The code is licensed under GPL v3.0 and the project does not sign agreements with the clinics that use it. The BAA therefore sits with whoever hosts or operates the instance: the infrastructure provider in a HIPAA-eligible environment, and any implementation or support firm with administrative access. Calendly cannot serve as the BAA route for the same reason its customer terms matter: under Section 13(d), the customer warrants that Customer Data does not contain protected health information, so no clinic can rely on Calendly to hold patient data under a BAA. Confirm with your counsel that no booking flow in your current Calendly setup has already sent PHI to Calendly.

Plan for incident reporting before go-live, because the contract sets the clock. The business associate must report security incidents, including breaches of unsecured PHI, to the covered entity, and the contract should name the channel, the contact and the time frame the parties agreed to. Write these into the operating runbook: who reviews server and database logs, who decides whether an event is reportable, and who notifies the clinic's privacy officer. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, and no certification substitutes for a signed BAA and documented incident handling.

DeployOpen is a Chainscore Labs company. We plan, implement, harden, back up, document and support self-hosted platforms inside the client's own infrastructure, which for a clinic means its own cloud account, data center or private network. For a HIPAA-scoped Easy!Appointments deployment, that work typically covers the PHP and MySQL hosting, the web server and TLS configuration, the separation of the booking form from the internal provider calendar, backup and restore testing, and the written procedures the covered entity and its business associates will rely on. Engagements are fixed-scope, so the systems, configuration baselines, deliverables and timelines are agreed in writing before work starts, and the covered entity can check each deliverable against that document.

DeployOpen prepares systems, controls and evidence for compliance assessments. We do not issue audit reports, attestations or certifications, and there is no HIPAA certification to obtain. Whether the deployment meets the Security Rule, and whether the business associate contracts are sufficient, is decided by the covered entity with its counsel and any independent assessor it chooses. Ask any implementation partner, including us, to state this boundary in the statement of work. Before scoping, confirm with your privacy officer which booking fields will be treated as ePHI, since that determines which safeguards and agreements apply.

Security testing of the public booking form, its API surface and the underlying hosting is available as a separate fixed-scope engagement, and ongoing support, upgrades and continuous testing can be covered by a retainer. A quote follows from the written scope, so the inputs that move it are the number of environments, the integrations you need (for example, SMS reminders or payment handling), the hosting model and the level of ongoing support you want. Ask for each of these items to be listed as its own deliverable so you can see what is one-time work and what recurs.