GDPR Article 22 and Automated Appointment Eligibility: When Scheduling Becomes a Decision

cmsapointoo on August 16, 2026

An automated scheduling feature does not fall under GDPR Article 22 merely because software is involved. The threshold asks three questions together: does the system make a decision, is that decision based solely on automated processing, and does it produce legal effects or similarly significantly affect the person? Automated appointment eligibility can cross that threshold when it denies, delays, or diverts access to care without meaningful human involvement, but the result depends on the actual workflow and effect.

Slot sorting, reminders, and administrative suggestions are not automatically Article 22 decisions. A product team needs to trace who or what determines the outcome, whether a person can genuinely change it before it takes effect, what data drives it, and how serious the consequence is for the person seeking care.

The three-part Article 22 threshold

Article 22(1) gives a person the right not to be subject to a decision based solely on automated processing, including profiling, when it produces legal effects concerning that person or similarly significantly affects that person. The Court of Justice described these as cumulative conditions in its SCHUFA judgment.

Start with a decision. Displaying open times may supply information without deciding whether a person can receive care. A rule that labels someone ineligible, blocks suitable times, creates a slower route, or assigns a pathway that determines access is closer to a decision. Labels such as “recommendation” or “triage support” do not settle what the system does.

Next ask whether processing is solely automated. A staff member who merely receives the score and confirms the same outcome may not supply meaningful involvement. Finally, assess the effect. Article 22 does not cover every inconvenience. The legal or similarly significant standard needs a fact-specific account of the person’s circumstances, the service, the delay, available alternatives, and the consequence of the outcome.

Scheduling support versus appointment eligibility

A calendar can automate steps without making an eligibility decision. It can sort slots by location, display clinician availability, send reminders, or detect a duplicate booking. Those functions may involve personal data and other GDPR duties, but Article 22 requires the three-part threshold.

Eligibility logic asks a different question. It may use age, location, symptoms, referral status, payment route, prior interactions, or a generated risk score to decide whether a person can book, which service is available, or how soon a request is considered. Some of those inputs can reveal health information. Some outcomes may have little effect; others may materially limit access.

Map the real outcome rather than the interface. A user who can click “request review” only after an automatic refusal has already experienced an automated decision. A clinician who receives a suggestion and freely assesses the underlying information before any effect may be part of a different workflow. The review must examine authority, timing, information, and actual ability to change the result.

What SCHUFA changes about upstream scores

In Case C-634/21, the Court considered a credit information agency that automatically created a probability value. A third party used that score to establish, implement, or terminate a contractual relationship. The Court held that producing the score could itself constitute automated individual decision-making where the third party drew strongly on it.

The case concerned credit scoring, not healthcare appointments. It should not be presented as a judgment that every health risk score is an Article 22 decision. Its relevant principle is functional: separating score generation from the final system does not necessarily avoid Article 22 when the score strongly determines the downstream result.

For an appointment workflow, test how often staff depart from the score, what information they see, whether they have authority and time to reassess it, and whether the person receives a different outcome before the decision takes effect. A nominal reviewer or an unexplained override button is not evidence by itself.

Exceptions do not remove the safeguards

Article 22(2) lists three circumstances in which paragraph 1 does not apply. The decision may be necessary for entering into or performing a contract, authorized by Union or Member State law that also provides suitable safeguards, or based on the person’s explicit consent. These are defined routes, not a general list of convenient legal bases.

For the contract and explicit-consent routes, Article 22(3) requires suitable measures to protect rights, freedoms, and legitimate interests. At minimum, the controller must provide the right to obtain human intervention, express a point of view, and contest the decision. A team should not assume that scheduling automation is necessary for a contract merely because it is cheaper or already deployed.

The law-authorized route depends on the applicable Union or Member State measure and the safeguards it establishes. National healthcare rules may also affect the service and professional duties. The sources mapped to this article do not answer those jurisdiction-specific questions, so a local legal assessment remains necessary.

Health data creates an additional restriction

Article 22(4) limits decisions covered by the Article 22(2) exceptions when they are based on special categories of personal data under Article 9(1). Health data is one of those categories. Such decisions may be based on special-category data only when Article 9(2)(a) or 9(2)(g) applies and suitable measures protect the person’s rights, freedoms, and legitimate interests.

Article 9(2)(a) concerns explicit consent under its stated conditions. Article 9(2)(g) concerns processing necessary for reasons of substantial public interest based on Union or Member State law that meets the regulation’s requirements. This restriction means a general Article 6 analysis or ordinary consent label does not complete the review.

Consent also needs to remain separate from unrelated permissions. The article on authorization, privacy consent, and platform permission addresses a US advertising context, but its operational lesson still helps: record each permission against its own source, purpose, and scope rather than treating one checkbox as universal approval.

Explanation, intervention, and contest must work in practice

In Case C-203/22, Dun & Bradstreet Austria, the Court interpreted the right to meaningful information about the logic involved under Article 15(1)(h). For automated decision-making within Article 22, the person may require an explanation of the procedure and principles actually applied to use personal data and reach the specific result. The explanation must be concise, transparent, intelligible, and easily accessible.

The judgment says the controller does not satisfy that duty by providing a complex formula alone. It also addresses claimed trade secrets and third-party data: the controller cannot simply refuse all information, although a competent supervisory authority or court may need to balance the interests and determine the scope of access.

For appointment eligibility, connect the explanation to the person’s result. State which categories of information mattered, how the procedure applied, what consequence followed, and how to seek intervention or contest the result. Do not disclose another person’s data or pretend that a generic model description explains a specific outcome.

A product review that preserves the legal boundary

  1. Write the outcome in ordinary language: ranking, suggestion, delay, diversion, refusal, or another result.
  2. Identify the controller, processors, data sources, model or rules, and downstream decision maker.
  3. Test whether a person exercises meaningful control before the outcome takes effect.
  4. Describe the legal or practical consequence for the affected person and available alternatives.
  5. If Article 22 applies, document the exact exception relied on and every required safeguard.
  6. Identify special-category inputs and test Article 22(4) with Article 9 separately.
  7. Prepare a result-specific explanation, intervention route, point-of-view channel, and contest process.
  8. Test the workflow with realistic scenarios, including disagreement, missing data, and an incorrect score.

This is an editorial review sequence, not a substitute for a GDPR assessment. It should sit beside the controller’s broader work on lawful processing, transparency, data quality, security, retention, rights, and any required impact assessment. A narrow Article 22 conclusion does not approve the rest of the processing.

Keep health data inside the approved processing boundary during product testing. Where teams also measure marketing outcomes, the review of health conversion tracking outside HIPAA shows why a non-HIPAA environment can still carry privacy risk. For cloud and advertising boundaries, see why a provider agreement does not follow data into another product.

Frequently asked questions

Does automatically sorting appointment slots trigger Article 22?

Not automatically. The workflow must meet all three conditions: a decision, solely automated processing, and a legal or similarly significant effect. Slot ordering may fall short, while an automatic denial or material delay may require closer review.

Does a staff approval step always prevent the decision from being solely automated?

No. Review the staff member’s authority, information, time, and actual ability to change the outcome before it affects the person. A token confirmation step may not amount to meaningful involvement.

Can explicit consent always authorize automated health eligibility?

No universal conclusion follows. Article 22(2)(c), Article 22(3), Article 22(4), and Article 9 must be applied to the facts. Other GDPR duties and applicable healthcare law also remain.

Must the controller reveal its source code?

The cited Dun & Bradstreet Austria judgment focuses on a concise and understandable explanation of the procedure and principles actually applied. It rejects reliance on a complex formula alone and provides a balancing route for protected information; it does not create a universal source-code disclosure rule.

References

How a HIPAA Business Associate Supports a Patient Access Request

cmsapointoo on August 16, 2026

A HIPAA business associate can help fulfill a patient access request, but the covered entity remains responsible for the individual’s right of access. The current rule gives the covered entity no later than 30 calendar days after receipt to act on a request. Retrieving records from a business associate does not create a second clock.

The business associate agreement should say who receives requests, what records the associate must make available, whether it may send an electronic copy directly, and how it returns the request to the covered entity for decisions outside its assigned role. Software should support that allocation without inventing the designated record set or a reason to deny access.

Who is responsible for the access request?

Section 164.524 places the access duty on the covered entity. Subject to stated exceptions and denial provisions, an individual has a right to inspect and obtain a copy of protected health information about that individual in a designated record set for as long as the information is maintained there. The rule also tells the covered entity how to receive a request, act on it, provide access, handle denials, and retain required documentation.

HHS’s business associate FAQ uses the same allocation. It says covered entities are responsible for Privacy Rule rights, including access, amendment, and accounting. It also says the right includes information in a designated record set held by a business associate unless that information merely duplicates what the covered entity already maintains.

The business associate still has duties. Legal responsibility, contract allocation, and operational work must remain distinct. A covered entity cannot treat the vendor’s queue as a pause button for the request.

What records can the business associate hold?

The question is whether protected health information sits in a designated record set covered by section 164.524. The covered entity must identify those record sets and document who receives and processes access requests.

A health software vendor may hold records that the covered entity uses to make decisions about individuals. The result depends on the system, contract, and record use. A generic product rule should not decide whether logs, derived fields, support notes, duplicates, or metadata belong. The covered entity needs a documented determination that the associate can implement.

Do not confuse this determination with permission to reuse the records for another purpose. A BAA defines permitted and required uses and disclosures; it is not a general data license. The review of cross-tenant clinic benchmarking under a BAA explains why contract scope and a separate use remain different questions.

How does the 30-day clock work?

The current text of 45 CFR 164.524 requires the covered entity to act on an access request no later than 30 days after receipt. If the covered entity grants the request, it must inform the individual and provide the requested access under the rule. If it denies the request in whole or in part, it must issue the required written denial.

The rule allows one extension of no more than 30 days when the covered entity cannot act within the initial period. Within the first 30 days, it must give the individual a written statement explaining the delay and the date by which it will complete its action. The extension is not automatic, and only one is available.

A vendor handoff should preserve the original receipt time. An operational record can contain the request ID, received timestamp, due date, assigned action, status, and escalation owner. This editorial workflow does not authorize the associate to grant itself an extension.

What must the business associate agreement cover?

Section 164.504 requires a business associate contract to establish permitted and required uses and disclosures. Among its listed terms, the contract must provide that the associate will make protected health information available in accordance with section 164.524. If the associate carries out a covered entity’s obligation under the Privacy Rule, it must comply with the requirements that apply to the covered entity in performing that obligation.

The HHS FAQ says the parties may agree that the associate will provide access directly to individuals. This can fit a situation where the associate is the only holder of all or part of the designated record set. Direct delivery should not be inferred from technical capability. The agreement and procedure need to say whether the associate sends to the covered entity, the individual, or the individual’s designee.

HHS’s direct-liability fact sheet adds another boundary. It identifies a business associate’s failure to provide a copy of electronic protected health information to the covered entity or to the individual or designee, whichever the BAA specifies, as a matter for which OCR may have direct enforcement authority under the cited provisions. That agency explanation should be presented as guidance about enforcement, alongside the regulation and contract.

What should the software workflow do?

If a request reaches the associate, the system should connect it to the covered entity’s contract-defined process. It should preserve receipt time, requested scope, possible record set, and response owner. Identity checks and communication should follow the approved procedure without creating unreasonable barriers.

The export step should use the requested form and format when readily producible. For electronic records and an electronic-copy request, section 164.524 describes the requested electronic form and format when readily producible, or a readable electronic form and format agreed with the individual when it is not. The associate should not silently substitute a summary. The rule permits a summary or explanation only under its stated agreement and fee conditions.

Keep access records inside the approved health-data boundary. Do not copy request contents into advertising or unrelated analytics systems. The article on health conversion tracking outside HIPAA explains why another product boundary can add risk.

Where should decisions and denials remain?

Section 164.524 contains specific unreviewable and reviewable grounds for denial. It also requires access to other requested protected health information, where possible, after excluding material for which a denial ground exists. A written denial must use plain language and include the basis, applicable review rights, and complaint information.

A software vendor should not translate those provisions into a universal “sensitive record” switch. Some reviewable grounds depend on professional judgment by a licensed healthcare professional. The covered entity must designate the reviewer required by the rule when a review is requested. The associate can present status, collect the approved determination, produce the permitted portion, and preserve an audit record.

When the request is broader than the associate’s holdings, route it back instead of marking it complete. When the covered entity knows another location maintains the requested information, section 164.524 addresses informing the individual where to direct the request. Product behavior should reflect the approved process, not generate legal conclusions from incomplete inventory.

An evidence checklist for covered entities and vendors

  • List the covered entity, business associate, applicable agreement, and current access procedure.
  • Identify designated record sets and the systems that maintain them.
  • Record the original receipt timestamp and current 30-day due date.
  • Assign intake, identity verification, record search, export, delivery, denial, review, and complaint responsibilities.
  • State whether the associate sends records to the covered entity or directly to the individual or designee.
  • Test requested electronic formats with synthetic records and document any format agreement.
  • Prove that duplicate copies are not produced unnecessarily and that partial access remains possible when approved.
  • Escalate missing records, uncertain scope, delivery failure, or a possible denial before the deadline expires.

This checklist is editorial advice, not text from HHS. It makes the contract executable and the request traceable. A signed BAA alone does not prove that the workflow can find, export, and deliver the right records on time. The broader product-boundary review for BAAs applies the same evidence discipline to another vendor context.

Frequently asked questions

Does a business associate have to answer every patient directly?

No universal rule in these sources assigns every request directly to the associate. The covered entity remains responsible. The BAA and procedure may require the associate to provide records to the covered entity or to deliver an electronic copy directly to the individual or designee.

Does asking the vendor for records restart the 30-day clock?

No. The rule gives the covered entity no later than 30 days after receipt to act. Internal retrieval from a business associate should preserve that original deadline.

Can the business associate decide that a record is outside the designated record set?

It should not invent that decision. The covered entity should document its designated record sets and give the associate rules it can implement. Uncertain cases need escalation to the responsible privacy or legal reviewer.

Can the associate send a summary instead of the records?

Not by default. Section 164.524 permits a summary or explanation in place of access only when the individual agrees in advance to it and to any associated fee allowed by the rule.

References

Healthcare Tracking Pixels After American Hospital Association v. Becerra

cmsapointoo on August 16, 2026

The court decision in American Hospital Association v. Becerra did not give healthcare organizations general permission to use tracking pixels. The court vacated one specific position in HHS guidance: that an IP address combined with a visit to an unauthenticated public page about a condition or provider automatically triggers HIPAA obligations because that combination is individually identifiable health information.

The holding does not classify every other page or payload. Authenticated pages, appointment forms, symptom tools, user-entered details, and vendor disclosures need fact-specific review.

What did the district court actually vacate?

The June 20, 2024 opinion came from the United States District Court for the Northern District of Texas. The dispute focused on HHS guidance for online tracking technologies used by HIPAA covered entities and business associates. The court called the challenged part the “Proscribed Combination.” It joined two facts: an individual’s IP address and a visit to an unauthenticated public webpage that addressed a specific health condition or listed healthcare providers.

The court held that this combination fell outside the statutory definition of individually identifiable health information when HHS treated it as sufficient based on the visitor’s unknowable subjective reason for viewing the page. The final order declared that position unlawful because HHS had acted beyond its HIPAA authority. It denied a permanent injunction but granted vacatur of the Proscribed Combination.

The order was precise about scope. A footnote said the vacatur was not intended to limit the legal operation of other guidance in the bulletin. HHS later moved to dismiss its own appeal, and the Fifth Circuit dismissed it on September 4, 2024 under Federal Rule of Appellate Procedure 42(b). That left the district court’s vacatur operative, but the Fifth Circuit issued no merits opinion controlling later tracking disputes.

What the decision did not decide

The court did not hold that IP addresses can never be part of protected health information. It did not decide that every public healthcare page is outside HIPAA. It did not approve a particular pixel, analytics vendor, advertising platform, consent banner, business associate agreement, or data flow.

The opinion also did not erase the definitions in 45 CFR 160.103. Individually identifiable health information still turns on whether information is created or received by a listed actor, relates to health, healthcare, or payment, and identifies the individual or supplies a reasonable basis to identify the individual. Protected health information remains individually identifiable health information transmitted or maintained in a covered form, subject to stated exclusions.

Those definitions make the payload and context decisive. A page view carrying only the vacated combination differs from a request containing an email address, appointment date, selected service, symptom response, patient portal identifier, or other information tied to care. The article on health tracking outside HIPAA explains why falling outside one federal definition does not resolve every privacy or platform question.

How the current HHS bulletin should be read

HHS keeps its online tracking bulletin available and now opens it by describing the court order. The bulletin states that the court vacated the guidance to the extent it treated the Proscribed Combination as triggering HIPAA obligations. It also says HHS is evaluating next steps.

The bulletin separately discusses authenticated pages, public pages, mobile apps, permitted disclosures, business associate agreements, security safeguards, and breach analysis. HHS says trackers on authenticated pages generally have access to protected health information. It also gives appointment and symptom-checker examples involving information entered on public pages.

That material is agency guidance, not the court’s holding. The bulletin itself says its contents do not have the force and effect of law and are intended to clarify existing requirements or agency policy. A careful article should therefore label each proposition. The court’s order controls the vacatur. The regulations supply the underlying legal rules. The HHS bulletin describes OCR’s current guidance and enforcement perspective.

Why page labels alone are unreliable

Calling a page “public” does not describe everything a tracker can receive. A public location page may expose only a URL and ordinary device information. A public appointment page may add a chosen clinician, visit reason, date, contact detail, or confirmation state. Both are unauthenticated, but their payloads are different.

The same problem appears when teams classify a whole website at once. Shared scripts can run on pages with different purposes and inputs. A tag rule may include URL parameters, element text, entered values, or identifiers that a screenshot does not reveal. A server relay can add context later.

Use a page and payload inventory instead. For each route, record whether the person is authenticated, what the page reveals, what the person can enter, which scripts execute, which fields leave, who receives them, and why. This is an editorial control method, not a test prescribed by the court. It gives legal, privacy, and engineering reviewers facts they can evaluate.

How vendor and purpose analysis still applies

When a tracker receives protected health information on behalf of a regulated entity for a covered function or specified service, the business associate question remains. A signed agreement does not create a business associate relationship when the regulatory definition is not met, and the absence of an agreement does not change a vendor’s actual role. The relationship, information, and purpose need to be mapped.

Section 164.502 continues to govern permitted and prohibited uses and disclosures of protected health information. It also applies the minimum necessary standard to many uses, disclosures, and requests, subject to listed exceptions. The court did not replace those rules with a general permission for tracking.

Authorization and product permission remain separate gates as well. A cookie banner is not automatically a HIPAA authorization, and an authorization does not compel an advertising platform to accept health-related conversion data. See HIPAA authorization, privacy consent, and Google Ads permission for that boundary. Hashing also does not settle purpose or eligibility, as explained in the clinic form hashing review.

A practical review sequence after the case

  1. Identify the regulated entity and the exact website, app, or embedded flow under review.
  2. Inventory routes individually instead of assigning one label to the domain.
  3. Capture the actual outbound request with synthetic data and list every field, header, parameter, identifier, and value added by later processing.
  4. Separate the vacated IP plus public-page combination from any additional fact that may relate the visit to a person’s health or care.
  5. Map each recipient, its role, the proposed purpose, and any business associate agreement or other contract.
  6. Review the use or disclosure under the current regulation, then consult current HHS guidance without presenting it as a judicial holding.
  7. Keep delivery disabled while a material fact, permission, contract, or destination remains unresolved.
  8. Retest when page content, tag configuration, vendor behavior, URL structure, or event meaning changes.

This sequence is editorial advice. It prevents two opposite errors: treating the vacated position as if it still controlled every public page, or treating the decision as permission to send any healthcare interaction to a third party.

What evidence should support a deployment decision?

A defensible record connects the legal question to observed behavior. Keep the route inventory, synthetic capture, tag configuration, destination, vendor terms, agreement status, purpose, reviewer, source date, and approval limits together.

Use claim-specific language. A team may document that a request lacked health-related information during a defined test. It should not turn that result into “the website is HIPAA compliant.” A vendor’s promise to remove data later does not answer whether the initial disclosure was permitted.

If the proposed route reaches Google advertising products, remember that a Google Cloud agreement does not extend to Google Ads. The Google Cloud BAA boundary shows why provider, product, and destination evidence must remain separate.

Frequently asked questions

Did the court make healthcare tracking pixels legal?

No. The court vacated one HHS position about a specific combination of information. Whether another tracker use is permitted depends on the actual information, actors, purpose, rule, and facts.

Is an IP address never protected health information after the decision?

The decision does not establish that rule. It rejected automatic treatment of the Proscribed Combination. An IP address can appear with other information and in other contexts that require separate analysis under 45 CFR 160.103.

Can a hospital keep trackers on authenticated pages?

The case did not approve that practice. HHS guidance says authenticated pages generally expose protected health information to tracking technologies. Review the actual disclosure, permission, safeguards, vendor role, and contract before deployment.

Does the HHS bulletin still matter?

Yes, as current agency guidance subject to the court’s vacatur. It is useful evidence of OCR’s published position, but it is not the court’s holding and says it does not have the force and effect of law.

References

How to Map Zocdoc Visit Reason IDs to EHR Appointment Types

cmsapointoo on August 16, 2026

A Zocdoc visit reason and an EHR appointment type solve different scheduling problems. Zocdoc uses a visit_reason_id to describe why a patient wants an appointment and to request eligible availability. An EHR may use its own code to select a template, duration, resource, or internal workflow. Matching labels do not prove that the two records mean the same thing.

Use a versioned, clinic-owned translation. Each admitted Zocdoc visit reason maps to one exact EHR scheduling code and duration for a defined provider, location, and patient type. If no active mapping matches, stop the booking path and send the case for review. Do not guess from the displayed name or fall back to a general appointment type.

Start with the Zocdoc identifiers the API actually defines

Zocdoc’s Reference Data guide says that several API endpoints require Zocdoc-specific IDs for specialties, visit reasons, and insurance plans. It provides endpoints to retrieve visit reasons and their IDs, optionally filtered by specialty_id, and to look up one visit reason by ID. That makes the returned ID the stable integration input. A copied label from a screen or spreadsheet is not an equivalent contract.

The glossary defines a visit reason as the purpose of the appointment. It also distinguishes the default visit reason, which determines duration and calculates availability when a specific reason is not selected. These are Zocdoc concepts. The documentation does not define the code your EHR should receive, so that second half belongs to the clinic and its integration owner.

Keep visit reason, visit type, and EHR type separate

The Zocdoc glossary lists appointment visit types such as in_person, zocdoc_video_service, and third_party_video_service. Those values describe how the appointment occurs. A visit reason describes its purpose. Your EHR appointment type may combine purpose, duration, staffing, or local billing workflow. Treating these three fields as synonyms creates silent errors.

Use distinct columns and names in code. For example, zocdoc_visit_reason_id, zocdoc_visit_type, and ehr_appointment_type_code should never share one generic variable called type. That naming scheme is editorial implementation guidance, not a Zocdoc-required database schema.

Build a versioned translation table

A small table is enough if its scope is explicit. Store only fields needed to decide whether one booking combination is admitted:

Field Purpose
mapping_version Identifies the approved translation used for a booking.
zocdoc_visit_reason_id Uses the ID returned by Zocdoc reference data.
provider_location_id Limits the rule to the provider and practice location represented by that API object.
patient_type Separates new and existing patient paths when the clinic schedules them differently.
ehr_appointment_type_code Names one exact destination code owned by the clinic.
ehr_duration_minutes Records the duration approved for that destination mapping.
state Allows only reviewed mappings to enter the booking path.

The version, EHR code, duration, and approval state are recommended architecture, not Zocdoc API fields. Keep that distinction visible in documentation and logs. It prevents a local operational decision from being misquoted as vendor behavior.

Match the scope used to request availability

The booking guide retrieves availability using a provider_location_id, visit_reason_id, and patient_type. The returned start time then becomes an input to the booking request, together with the visit reason and provider location. Your mapping lookup should use the same decision context rather than translating a visit reason globally.

One visit reason may legitimately map to different EHR codes for two providers or locations. New and existing patients may also follow different templates. Do not invent those differences from the API documentation. Obtain them from the clinic’s approved scheduling rules and represent them as separate rows. If a required scope value is absent, the mapping is unresolved.

This separation also keeps attribution data from changing scheduling meaning. The appointment source and marketing source answer reporting questions. They should not select an EHR appointment type.

Honor allowed and excluded visit reasons

Zocdoc defines allowed visit reason IDs as the reasons that can be scheduled for a given time slot. It defines excluded visit reason IDs as reasons that cannot be scheduled there, and an exclusion takes precedence over an allowance. Treat those fields as a slot-level eligibility check before applying the local translation.

A translation row cannot make an excluded reason bookable. Conversely, an allowed reason does not prove that the clinic has approved an EHR destination for it. Both conditions must hold: the Zocdoc slot permits the reason, and the active clinic mapping resolves the exact destination. If either condition fails, stop the request and record which gate failed.

Reject unresolved mappings without a generic fallback

Fail closed when no active row matches, more than one row matches, the EHR code is blank, the duration is missing, or the mapping version is not approved. Return a controlled unavailable or review state before creating the appointment. Do not silently use the default visit reason, a generic consultation code, the first search result, or a prior mapping from another provider.

The Zocdoc glossary explains what its default visit reason does inside Zocdoc. It does not authorize an integration to use a clinic’s general EHR type as a rescue path. A local fallback would be a new scheduling policy and needs explicit clinic approval. Until then, unresolved means not bookable through this route.

Log identifiers, mapping version, decision result, and an error code without copying patient notes. For downstream reporting, preserve the original booking source as described in the guide to keeping booking source after a reschedule.

Test the availability and booking contracts together

Use the documented sequence in a controlled environment. Retrieve the Zocdoc visit reason ID, select the intended provider location and patient type, request availability, and choose a returned start time. Confirm that the reason is not excluded for that slot. Then resolve the local mapping before sending a booking request with the same Zocdoc context.

The API documentation proves the Zocdoc side of this sequence. A separate clinic-owned test must prove what the integration writes to the EHR. Inspect the resulting appointment and compare its exact type code, duration, provider, location, and patient classification with the approved mapping row. This is a recommended acceptance check, not a promise that every EHR exposes the same fields or write-back behavior.

Include negative tests. Use an unknown visit reason, an excluded reason, a missing provider scope, and two competing active rows. Each case should stop before an EHR appointment is created. When the appointment later changes state, keep the original mapping evidence alongside the operational history. The article on no-show reporting by original booking source shows why stable historical context matters.

Change mappings without rewriting history

Publish a new version when a clinic changes an EHR code, duration, provider scope, location, or patient-type rule. Give the new row an effective point and stop using the old row for new requests. Existing appointments should retain the version used when they were created. That lets support staff explain an older booking after the current configuration has changed.

Refresh Zocdoc reference data on the review schedule defined for the integration. A retrieved ID can be compared with the active table before release. If the source set, provider roster, or clinic scheduling policy changes, rerun both positive and negative checks. Do not infer a vendor change solely from a label difference.

Frequently Asked Questions

Can I map by the displayed visit-reason name?

No. Retrieve and store the Zocdoc ID. Labels are useful to reviewers, but the documented API contract uses Zocdoc-specific identifiers.

Is an EHR appointment type the same as a Zocdoc visit type?

Not by definition. Zocdoc visit type describes in-person or supported video modes. The EHR destination code remains a clinic-owned value unless the exact integration documentation says otherwise.

Can one visit reason map to more than one EHR code?

Yes, when separate provider, location, or patient-type scopes make the result unambiguous. Two active matches for the same request should be rejected.

What happens when a visit reason is allowed but unmapped?

Stop the booking route and send the configuration for review. Slot eligibility and local destination approval are separate gates.

Should a reschedule use the latest mapping version?

Do not change historical meaning automatically. Preserve the version attached to the original appointment and define any remapping rule as a separate, approved workflow.

References

How to Use Google Ads Data Exclusions After a Clinic Conversion-Tracking Outage

cmsapointoo on August 16, 2026

A Google Ads data exclusion can protect Smart Bidding from a verified conversion-tracking outage. It does not repair the tag, restore missing clinic records, or remove data from reports. The exclusion tells eligible bidding strategies to disregard affected click data when learning and setting bids.

The date range must follow clicks, not only the hours when conversions stopped arriving. Include earlier clicks whose conversions would normally have appeared during the outage. Apply the narrowest accurate campaign and device scope, preserve the incident evidence, and treat reporting backfill as a separate decision.

When does a clinic conversion outage qualify?

Google recommends data exclusions for conversion-data outages, including broken tracking, an incorrectly placed tag, a website outage, or a temporary failure to upload offline conversions. In each case, inaccurate conversion or conversion-value data could distort conversion-based Smart Bidding.

A sudden decline in appointments does not qualify by itself. Neither does a holiday, a normal change in demand, a small sample, or a disputed lead-quality definition. First prove that the measurement system reported incorrect data for a bounded period.

Keep the incident proof outside Google Ads: alert time, affected conversion actions, first bad observation, last known good event, repair time, missing or inflated records, affected devices, and affected campaigns. The conversion audit proof guide helps separate configuration, processing, reporting, and attribution evidence.

What does a data exclusion change?

A data exclusion changes the conversion and conversion-value data that Smart Bidding uses. Google says the tool is available only for conversion-based and value-based Smart Bidding strategies. It supports Search, Display, Shopping, and Performance Max campaigns, while Hotel and Travel campaigns are not supported.

The exclusion does not alter the Conversions columns or erase affected events from reports. Google states that excluded conversions remain visible in reporting. A report can therefore show conversions from the period even though Smart Bidding no longer uses the associated click data.

Describe the action accurately in an incident log: “Excluded affected clicks from Smart Bidding inputs.” Do not write “deleted bad conversions,” “fixed reporting,” or “restored attribution.” Those outcomes are outside what the feature does.

Why must the date range follow clicks and conversion delay?

Google applies data exclusions to clicks. When a click is excluded, conversions associated with it are also excluded from Smart Bidding. A conversion recorded during an outage may belong to a click from an earlier day, so selecting only the visible outage dates can miss affected learning data.

Measure the normal delay between click and reported conversion for the affected action. Then move the exclusion start back far enough to cover clicks whose conversions would have arrived during the broken period. Google recommends covering at least 90% of clicks associated with the affected conversion data.

Google gives a concrete example: if uploads failed from October 15 through October 18 and the conversion delay is five days, the exclusion should cover clicks from October 10 through October 18. Use the clinic account’s observed delay and incident window instead of copying the example dates.

The clinic funnel report by original lead cohort provides a related reporting principle. Later outcomes belong to the acquisition cohort that produced them. The exclusion uses the same temporal discipline because bidding connects reported conversions back to clicks.

How narrow should the exclusion scope be?

Scope should match the proven fault. Google’s setup allows selection of campaigns and devices, or an account-wide exclusion when the evidence supports it. Exclusions can be applied at manager-account or sub-account level. Start and end times use the account’s time zone.

Incident evidence Candidate scope Do not assume
One mobile tag failed Affected campaigns and mobile devices Desktop data was also wrong
One campaign used a broken page That campaign and proven dates Every account campaign was affected
Account-wide import stopped Campaigns using the affected imported action Unrelated conversion actions failed
Scope remains unknown Continue investigation A broad exclusion is safer

A broad exclusion discards more learning data. A narrow exclusion that misses affected clicks leaves bad data in the bidder. Choose the smallest scope supported by incident evidence, which may not be the smallest selectable option.

How should the team apply the exclusion?

Google’s current workflow places data exclusions under Adjustments in Google Ads. Before creating one, record the exact dates, times, time zone, campaigns, devices, conversion actions, and delay assumption. Google warns that exclusions can change bid-strategy performance, so the final review should happen before creation.

  1. Confirm the conversion data is wrong and identify the root measurement fault.
  2. Repair or contain the fault so the outage has a defensible end.
  3. Measure the normal click-to-conversion delay for the affected action.
  4. Translate the outage into an affected click-date range.
  5. Select only the proven campaigns and devices.
  6. Verify the account time zone and manager or sub-account scope.
  7. Save the evidence and approval before creating the exclusion.
  8. Monitor bidding and spend while the strategy stabilizes.

Apply the exclusion quickly once the scope is known. Google says planned outages can be configured in advance and typically take effect within a day. Do not use that guidance to guess at an uncertain incident. A wrong future window still sends the bidder inaccurate instructions.

What happens after the exclusion is applied?

Google advises against removing a data exclusion after application. Past-date exclusions should begin to stabilize after a few days, but an outage affecting a week or more of clicks can produce fluctuations for one or two conversion cycles.

Watch spend, bids, conversion volume, and conversion value without declaring immediate recovery. Google notes that bids and spending can fall temporarily. It also suggests keeping budgets near historical spend for a few cycles and adjusting CPA or ROAS targets when necessary. Any such change needs its own approval and rollback rule.

The value-based bidding readiness checklist explains why delay, mature observation windows, goals, and data quality still matter after the platform accepts a setting. An exclusion reduces one source of bad learning data. It does not make the remaining conversion feed accurate.

Should missing conversions be backfilled?

Google generally advises against backfilling data after an outage because late conversions can affect Search and Shopping bidding performance. If a data exclusion was applied, Google allows a reporting-only backfill after waiting at least five days. It says not to remove the exclusion.

Keep the two purposes separate. The exclusion protects bidding from affected clicks. A backfill may restore reporting completeness. It does not reverse the exclusion or recreate the learning sequence that would have existed if tracking had worked on time.

Before any backfill, reconcile source records, remove duplicates, preserve original conversion times, and document why reporting needs the late events. The offline conversion outbox report shows how to keep local event state, Google request state, Ads reporting, and attribution in separate evidence layers.

What should the incident record contain?

A useful record lets another operator reconstruct the decision without reading patient or appointment data. Include the incident ID, detection time, root cause, repair time, affected conversion actions, account time zone, measured delay, click-date range, campaign and device scope, approval, exclusion identifier, and monitoring window.

Record explicit non-claims as well:

  • the exclusion did not change Ads reporting;
  • the exclusion did not repair the source tracking system;
  • the exclusion did not prove attribution or business recovery;
  • any backfill was reporting-only and happened after the documented wait;
  • patient details and clinical data were not included in the incident artifact.

Review the incident after one or two observed conversion cycles when the affected period was long. Retire temporary target or budget adjustments through a separate approved decision. Do not remove the data exclusion to make a dashboard look consistent.

Frequently asked questions

Do data exclusions remove conversions from reports?

No. Google says data exclusions affect the data used by Smart Bidding, not conversion reporting. The excluded period can remain visible in the account’s conversion columns.

Should the exclusion cover conversion dates or click dates?

Use affected click dates. Extend the start date to account for normal conversion delay, because conversions reported during the outage may be attributed to earlier clicks.

Can the team remove an exclusion after fixing the data?

Google advises against removing an applied exclusion. Preserve it, document the repair separately, and let the strategy stabilize on accurate post-incident data.

Can missing conversions be uploaded later?

Google generally discourages backfills. When an exclusion was applied, a reporting-only backfill can occur after at least five days, without removing the exclusion. Review duplicates and original times first.

References

Google Ads Location Targeting for Clinics: Presence vs Presence or Interest

cmsapointoo on August 16, 2026

Presence and Presence or Interest answer different questions in Google Ads. Presence focuses on people likely to be in or regularly in a targeted area. Presence or Interest also includes people who have shown interest in that area. For a clinic, the right setting depends on where it can actually serve patients.

Neither option proves a person’s precise location. Google describes location targeting as a best-effort system based on several signals and says complete accuracy is not guaranteed. Choose a setting from the clinic’s service boundary, then audit matched locations and qualified booking outcomes instead of judging the decision by reach alone.

What is the difference between the two options?

Google’s advanced location documentation describes Presence or Interest as the default and recommended broad targeting option. It can reach people likely in or regularly in the selected locations and people who have shown interest in those locations. Presence removes the interest branch and retains the likely-in or regularly-in branch.

Option Who may be reached Clinic decision question
Presence or Interest People likely in, regularly in, or interested in the targeted area Can the clinic serve valuable demand from people who are not currently local?
Presence People likely in or regularly in the targeted area Does the clinic want to limit reach to likely local presence?

The wording matters. Presence does not mean confirmed residence, and Presence or Interest does not mean the user intends to travel. Both are platform classifications. The clinic still needs an operational definition of its service area and a separate way to measure whether enquiries become eligible bookings.

When does Presence fit a clinic’s service boundary?

Google says advertisers should consider Presence when they only want users in specific locations, or when the business is in a sensitive vertical with strict targeting limits. A clinic with a fixed in-person service area may therefore prefer the narrower option after checking the actual campaign and current policy.

This is not a universal prescription. A regional specialist, a clinic serving travellers, or an organization offering permitted remote services may have a reason to evaluate location interest. Write the service scenario first rather than copying a setting from another account.

Document every included location, excluded location, radius, and location option. Record why a person outside the immediate area can or cannot become an eligible patient. If the answer depends on the service, campaign, or location, separate those campaigns instead of relying on one broad rule.

When can Presence or Interest be useful?

Presence or Interest can reach someone outside the target area whose searches, past activity, visited locations, or viewed content indicate an interest in that place. Google notes that location of interest is not limited by the user’s country or the Google domain used for the search.

That broader reach is useful only when out-of-area interest has a credible path to service. For example, someone may plan care before moving to a new city or arrange an appointment for a future visit. Test those scenarios against the clinic’s booking process rather than inferring them from a search term.

Do not reuse Google’s conversion example for travel, real estate, and education as a clinic benchmark. The advanced-options page limits that result to named verticals and dates. It does not establish that broader targeting improves qualified patient acquisition for healthcare advertisers.

Why is neither option exact location proof?

Google uses signals such as IP addresses, device information, user settings, behavior, search terms, past locations, Maps activity, and page context to estimate physical location or location interest. Signal availability varies. The platform says location targeting is its best effort and does not guarantee full accuracy.

Google also documents related areas. Ads may show in nearby places that could not be targeted directly because of population, available data, or targeting granularity. A radius or city target is therefore a campaign setting, not a geometric proof of where every click occurred.

Do not classify a click associated with another place as invalid traffic automatically. It may reflect the selected Presence or Interest option, an estimated location, a related area, or a reporting limitation. Inspect the campaign and evidence before assigning a cause.

Which geographic reports should the clinic review?

Google’s geographic performance guide separates Targeted locations from Matched locations. Targeted locations shows performance for the areas configured in the campaign. Matched locations shows where ads appeared based on either a user’s physical location or a location of interest.

Start with the Matched locations view when investigating reach beyond the expected service area. Then compare it with the exact advanced location option, exclusions, campaign type, and date range. The report is aggregated, and Google notes that some rows can remain unspecified.

Distance reports add another perspective when location assets are present. Google warns that the displayed distance can be based on a place of interest rather than precise physical distance. Treat distance as a reporting dimension, not a patient-address field or evidence about an individual.

How should location data connect to clinic outcomes?

Google’s reports describe ad delivery and platform conversions. The clinic must define an eligible enquiry or booking in its own system. Join those layers only through an approved, minimized reporting process, then aggregate by a useful geographic level before sharing results.

A practical internal review separates:

  • targeted location and selected location option;
  • matched location category reported by Google;
  • valid form submissions or calls under a written rule;
  • eligible bookings recorded by the clinic’s source of truth;
  • cost and outcome rate for a mature period.

The clinic booking outcome taxonomy keeps form, booking, attendance, and later outcomes distinct. The guide to show rate by campaign explains how to use aggregate outcomes without turning appointment details into advertising payloads.

How should a clinic test a change?

Change one location option at a time and preserve the prior setting. Record the affected campaigns, locations, exclusions, date, approver, reason, and rollback condition. Avoid changing keywords, landing pages, bidding, and geographic settings together because the result will be hard to interpret.

  1. Write the service boundary and acceptable out-of-area scenarios.
  2. Capture the current targeted locations, exclusions, and advanced option.
  3. Review Matched locations for a mature period.
  4. Compare valid enquiries and qualified bookings under clinic-owned definitions.
  5. Choose Presence or Presence or Interest for the documented scenario.
  6. Monitor reach, cost, and outcome quality over the same reporting window.
  7. Revert if the agreed stop condition is met.

Do not promise that Presence will remove every out-of-area interaction. Google explicitly describes the system as best effort. The test should ask whether the narrower setting improves the clinic’s observed mix within acceptable reach, not whether every user appears inside a perfect boundary.

What should the decision record say?

The record should state the clinic’s service constraint before the chosen setting. It should also name what counts as a qualified booking, which report supplies location data, how unspecified rows are handled, and when the team will review the decision again.

Decision field Required entry
Service boundary Where and how the clinic can provide the advertised service
Google option Presence or Presence or Interest
Campaign scope Exact campaigns, locations, exclusions, and devices
Evidence Matched locations plus clinic-owned qualified outcomes
Review rule Date, owner, rollback threshold, and known limitations

Keep location targeting separate from acquisition attribution. The appointment source versus marketing source guide shows why the scheduler entry point and the campaign that influenced demand need different fields. Location is another dimension, not a replacement for either one.

Frequently asked questions

Is Presence always better for a local clinic?

No. It is narrower and may fit a fixed local service boundary, but Google recommends assessing the advertiser’s goals. A clinic that can legitimately serve some out-of-area demand may test the broader option with qualified booking evidence.

Does Presence guarantee every user is physically inside the target?

No. Google estimates location from several signals and calls its targeting best effort. It does not guarantee complete accuracy. Related areas and unspecified report rows also require review.

Does an out-of-area click prove invalid traffic?

No. Check the advanced location option, matched-location type, exclusions, related areas, and available signals first. Invalid traffic is a separate classification and needs its own evidence.

Should a clinic judge the setting by conversion count?

Not alone. Compare reach and cost with valid enquiries and eligible bookings under written clinic definitions. A larger platform conversion count may still include demand the clinic cannot serve.

References

Google Ads New Customer Acquisition Goal vs a Clinic’s New-Patient Definition

cmsapointoo on August 16, 2026

Google Ads can label someone a new customer without proving that the person is a new patient under a clinic’s operating rules. The platform label belongs to a bidding system. The clinic definition belongs to its appointment or patient system. They can inform the same review, but they are not interchangeable.

Before activating a customer lifecycle goal, review the acquisition mode, detection method, and campaign requirements. Google also restricts advertiser-curated audiences when ads promote content within a sensitive health category. A clinic should test eligibility first and keep its patient definition in the approved operational system.

What are the two definitions?

Google Ads uses customer lifecycle goals to change how campaigns bid toward new, high-value, existing, or lapsed customers. Its documentation describes the platform modes, eligible campaign types, bidding strategies, and signals used to detect customer segments. The resulting label answers a Google Ads optimization question.

A clinic’s new-patient definition answers an operational question. The clinic might need to distinguish a first recorded appointment, a first completed visit, a returning person after a chosen interval, or an existing patient visiting another location. Those are examples of definitions a clinic may choose, not definitions published by Google.

Write the clinic rule before comparing the two systems. Name the qualifying event, lookback period, source of truth, exclusions, effective date, and owner. The clinic booking outcome taxonomy shows why a form submission, booking, and attended visit require separate names.

How does Google Ads identify a new customer?

Google documents three broad signal paths for customer detection: Google autodetection, designated audience lists, and supported conversion-tag information. The exact path depends on the lifecycle mode and conversion setup. A user classified as new by one of those paths has met the platform’s detection logic, not the clinic’s patient-record rule.

Autodetection is activated for new customer acquisition when the advertiser tracks Google Ads purchase conversions. Google says it can build from up to 540 days of campaign activity and tracked purchases. The same documentation calls this method less comprehensive because users can delete cookies or opt out.

Audience lists can help Google identify existing customers, but access and policy eligibility are separate gates. A visible list control does not prove that a clinic may populate it with patient information. Even accurate platform detection would not establish clinical or billing status.

Why does the selected lifecycle mode matter?

The phrase “new customer acquisition goal” covers modes with different requirements. Google’s current lifecycle overview says New Customer Value mode and High-Value New Customer mode require at least one purchase conversion goal and use value-based bidding. New Customer Only mode can work without a purchase goal, although Google recommends one for more accurate new-versus-returning reporting.

New Customer Value mode bids higher for new customers while continuing to engage potential returning customers. New Customer Only mode bids only for customers the platform treats as new. A team must record which mode it means. Saying only “new customer goal is enabled” is too vague for review.

For a broader readiness check, use the clinic value-based bidding checklist. It separates business purpose, conversion goal, value quality, delay, and observation window rather than treating a switch in Google Ads as evidence that the underlying data is ready.

Where should the clinic define a new patient?

The clinic should define new-patient status in the system that owns the relevant appointment or patient history. That rule can then support internal acquisition reporting. It should not be rewritten around what Google happens to detect, because cookie loss, opt-out, list coverage, and conversion configuration can all change the platform result.

Use a small decision record with the following fields:

  • the event that qualifies a person, such as created booking or completed first visit;
  • the lookback period and whether it applies across locations;
  • the source system and stable internal identifier;
  • test, duplicate, cancelled, and migrated-record rules;
  • the owner, effective date, and change history.

This is an editorial governance model. Google does not prescribe a clinic’s patient definition. The guide to appointment source versus marketing source provides a related boundary: operational scheduling facts and advertising context answer different questions and should stay in separate fields.

What changes when the advertising falls into a sensitive health category?

Google’s health policy classifies personal health content as a sensitive interest category. Its examples include health conditions, treatments, invasive procedures, medical devices, pregnancy, infertility, and mental-health services. Whether a specific ad, site, or app falls within the policy requires review of the actual content.

When that sensitive-interest restriction applies, Google’s current policy says advertiser-curated audiences are not supported. The listed unsupported features include Customer Match, advertiser data segments, audience expansion, and lookalike segments. Predefined Google audiences and location targeting appear on the supported side of the policy table, subject to their own rules.

Do not respond by uploading a patient list under a broader label, hashing it, or turning an appointment outcome into an audience. This article does not recommend any health-data upload. If the chosen lifecycle mode depends on a customer signal that the policy does not support for the advertised content, stop the implementation and keep the new-patient analysis internal.

The enhanced-conversions audit proof guide applies the same evidence discipline to another Google feature: configuration, request processing, Ads reporting, and business outcomes remain separate proof layers.

How should a clinic decide whether to activate the goal?

Start with the advertised content, proposed campaign, lifecycle mode, conversion goal, and signal path. Do not start with a patient export. The team should be able to describe the full configuration without exposing names, contact details, appointment information, or medical context.

  1. Define the clinic’s new-patient rule in the operational system.
  2. Identify the exact Google lifecycle mode and eligible campaign type.
  3. List the conversion goal and detection signals the mode would use.
  4. Review whether the ads, site, or app fall within Google’s sensitive health category.
  5. Confirm each required signal is permitted under the current policy.
  6. Stop if activation would require an unsupported audience or patient-data upload.
  7. Document the approval, scope, owner, rollback step, and review date.

New Customer Only creates a specific conflict. Google’s configuration guide says advertisers using offline events need to upload existing customers through Customer Match because autodetection does not work with offline conversions. That instruction does not override the health-policy restriction. For sensitive health advertising, stop rather than upload the list anyway.

How should reporting keep the labels separate?

Use two columns with two sources. One column records the Google Ads lifecycle classification reported for the campaign. Another records whether the clinic’s written new-patient rule was satisfied in its approved system. Never fill the second column by copying the first.

Field Source What it proves What it does not prove
Google new-customer classification Google Ads Platform classification under the selected mode and available signals First appointment or completed visit
Clinic new-patient status Approved clinic system The clinic’s documented operational rule was met How Google classified the user
Original marketing source Approved attribution record Recorded acquisition context Patient status or appointment outcome

Compare counts only after stating each denominator, date basis, and maturity window. A difference is not automatically a tracking defect. It may follow from different definitions or incomplete platform signals. Investigate the rows without exporting the patient record to the advertising platform.

Which mistakes create the most risk?

Renaming a Google segment “new patients” overstates what the platform proves. Building an existing-customer list from patient data before checking sensitive-interest restrictions creates a separate policy risk.

New Customer Value and New Customer Only do not work the same way. Their conversion-goal requirements differ. Changing the clinic definition until it matches the Google count also destroys a stable operational metric and hides the disagreement that needs investigation.

Keep every decision reversible. Record screenshots without patient data, the source pages reviewed, the campaign and goal identifiers, and the reason for approval or rejection. Review the setup again when Google changes lifecycle features, the clinic changes its definition, or campaign content enters a different policy category.

Frequently asked questions

Does Google Ads know whether someone is a first-time patient?

Not from the new-customer label alone. Google classifies customers through the selected lifecycle mode and available platform signals. First-time patient status requires the clinic’s own documented rule and approved operational record.

Can a clinic upload its patient list to improve new-customer detection?

This article does not recommend that upload. When ads promote content within Google’s sensitive health category, Customer Match and other advertiser-curated audiences are unsupported. Review the actual content and current policy before any implementation.

Can New Customer Only mode use a non-purchase conversion?

Google’s current lifecycle documentation says a purchase goal is not required for New Customer Only mode, although it is recommended for reporting accuracy. Signal and policy eligibility still require separate review.

What should the clinic report if the two counts differ?

Report both counts with their definitions, sources, and date bases. Do not force them to match. Investigate configuration and coverage while keeping patient status in the clinic’s approved system.

References

Outside HIPAA Does Not Make Health Conversion Tracking Low Risk

cmsapointoo on August 16, 2026

A finding that HIPAA does not apply to a particular actor or activity answers only the HIPAA question. It does not establish that health conversion tracking is low risk. The same flow may still require a separate assessment under the FTC Health Breach Notification Rule, a state consumer health law such as Washington’s My Health My Data Act, and the policy for the specific Google Ads feature receiving the data.

Each test has its own definitions, exemptions, and duties. Do not turn “not a HIPAA covered entity” into a release gate. Map actor, data, action, recipient, jurisdiction, and advertising product, then record evidence and an owner for each branch.

Build four gates, not one compliance label

A conversion flow can begin with a booking form, pass through a CRM or server, and end in an advertising product. Each step can change the relevant actor, purpose, and disclosure. A clinic, wellness app, software vendor, agency, and ad platform should not be grouped under one label. Nor should every value called a “conversion” be treated alike.

Create one record per flow: source, fields, identifiers, transformations, recipients, purpose, retention, population, jurisdiction, and exact destination feature. A generic destination like “Google” is too broad for a policy decision. A branch may be applicable, exempt, prohibited, conditional, or unresolved, but evidence from one branch does not prove another.

Gate 1: HIPAA asks who is acting and in what role

45 CFR 160.103 defines covered entities through categories including health plans, clearinghouses, and providers that transmit health information electronically in covered transactions. It defines business associate through specified functions and services involving protected health information on behalf of a covered entity or another business associate, with stated exceptions.

A company outside the covered-entity definition for one product may be a business associate elsewhere. A provider can also have activities outside a HIPAA-regulated flow. Assess the specific actor, service, activity, and information. Medical vocabulary or a health-related audience does not decide status.

If HIPAA does not govern the examined flow, record that narrow scope. Do not write “HIPAA does not apply to the company” when the analysis covered one app or marketing pathway, and do not infer that the data is safe to disclose.

When a cloud product is involved, remember that contract coverage is also product specific. The article on why a Google Cloud BAA does not cover Google Ads illustrates why a contract for one service cannot authorize a separate advertising use.

Gate 2: FTC HBNR has its own coverage and breach analysis

The FTC Health Breach Notification Rule appears in 16 CFR Part 318. It applies to covered vendors of personal health records, PHR related entities, and third-party service providers rather than using the HIPAA covered-entity test. The current rule and the 2024 final rule define key terms, including PHR identifiable health information, personal health record, covered health care provider, and breach of security.

The 2024 rulemaking clarified the FTC’s view of health apps and similar technologies, including certain unauthorized disclosures. That does not make every tracking event a reportable breach. Coverage, authorization, recipient, event, and exceptions still require fact-specific review.

Ask whether the product offers a personal health record under the rule, whether it has the technical capacity to draw information from multiple sources, what role each vendor plays, and whether an acquisition or disclosure was unauthorized. Assess notice duties only if the preceding elements hold. Use the Federal Register preamble for agency interpretation and the eCFR for current regulatory text.

Do not close this branch with “outside HIPAA.” The HBNR was designed for a different coverage boundary. Conversely, do not assume that using a health app proves HBNR applicability. Document the definition analysis.

Gate 3: Washington consumer health data law is a separate test

Washington RCW 19.373, commonly associated with the My Health My Data Act, defines consumer health data, regulated entities, processors, consumers, collection, sharing, and sale for its own purposes. It contains jurisdictional provisions and exemptions that must be reviewed before applying an obligation to a particular organization or dataset.

Where the law applies, its requirements include a consumer health data privacy policy and specific rules for collection, sharing, sale, access, deletion, processors, and security. Consent for collection or sharing and a separate signed authorization for sale are distinct concepts in the statute. An ordinary cookie banner should not be assumed to satisfy either without comparing its wording and interaction to the applicable requirement.

Start with person and geography, then classify entity and data. Check statutory exemptions. Determine whether the flow is collection, sharing, or sale under the statute, then test the matching notice, consent or authorization, processor, rights, and security provisions.

Neither “the user lives in Washington” nor “the company is a clinic” completes the statutory analysis. Preserve the facts and section supporting the conclusion.

Gate 4: Google policies depend on the exact advertising feature

Google’s Customer Data policies apply to enhanced conversions for web, enhanced conversions for leads, store sales uploads, and Google-engaged audiences. The policy prohibits uploading conversion information related to sensitive categories, including health or medical information, for the covered Customer Data products. This is a product-policy test, not a HIPAA definition or a determination that every health advertiser is prohibited from measuring any result.

Google’s personalized advertising policy separately treats health as a sensitive interest category and limits advertiser-curated audiences for that content. Customer Match belongs in this separate personalized-advertising and Customer Match policy branch, not in the four-product scope stated above. This policy does not ban all health advertising, but consent, hashing, or a lawful source cannot be assumed to make an audience or upload eligible.

Test the current product and configuration. Review every field and derived value, including URL parameters, event labels, list names, variables, and free text. A neutral event name can carry sensitive meaning when combined with its page or source. Hashing changes representation, not the underlying category or product rule.

For a narrower data design, see the clinic booking outcome taxonomy. If the proposed route uses a server or data manager, the Google Ads Data Manager clinic-form architecture helps identify boundaries, but architecture alone cannot make a prohibited payload eligible.

Consent is not a bridge across independent gates

Consent is not a universal override. The FTC branch may ask whether an acquisition or disclosure was authorized. Washington law specifies consent and sale authorization for covered activities. Google policy can prohibit a use even when the advertiser believes it has valid consent.

Keep booking consent separate from advertising choices. A person may request care without agreeing to a health-related conversion upload. Preserve notice, choice, version, time, and purpose instead of only a boolean called consent.

This is an editorial implementation recommendation. Determine the relevant consent standard under each law; this does not replace legal review or current platform terms.

A safer implementation review for health conversions

After the four gates, review the data path. Many reports can measure booking requested, confirmed, attended, or canceled without diagnosis, treatment, clinician notes, page titles, or free text. The internal treatment-value model explains why internal value and an advertising payload should remain separate.

  • Allowlist fields: reject unexpected values instead of forwarding the full form.
  • Separate destinations: do not reuse a clinical event object as an advertising event object.
  • Remove free text: keep symptoms, procedures, notes, and detailed URLs out of marketing connectors.
  • Log decisions: store gate results, policy version, owner, and evidence without logging health content.
  • Fail closed: pause transmission when classification, consent evidence, or product eligibility is unresolved.
  • Recheck changes: review new fields, destinations, jurisdictions, and policy revisions before release.

A clean technical payload does not cure an inapplicable consent or an unauthorized disclosure. Equally, a valid legal basis does not cure a product-policy prohibition. The implementation review reduces exposure after the independent decisions; it does not merge them.

Document a decision matrix that can be audited

For each flow, create four rows: HIPAA, FTC HBNR, Washington law, and Google policy. Record definitions, facts, conclusion, unresolved questions, source version, approver, and review date. Add other states when needed. “Compliant” alone is not an auditable result.

Require every relevant row to be resolved. HIPAA can be out of scope while HBNR remains open. Law may permit an activity that Google policy prohibits, or policy may allow an approach that lacks required legal authorization. In each case, keep the upload blocked.

Frequently Asked Questions

If a clinic is not a HIPAA covered entity, can it send health conversions to Google Ads?

That conclusion is insufficient. Test FTC HBNR, applicable state consumer health laws, other duties, and the exact Google Ads policy. Any one branch can stop or change the proposed flow.

Does hashing make a health conversion non-sensitive?

No general conclusion follows from hashing. It can transform an identifier, but the event, source, and combination may still relate to health, remain identifiable, or be prohibited by the selected product policy.

Does the FTC HBNR apply to every health app?

No. Apply the rule’s definitions to the product, data sources, actors, and event. The 2024 final rule provides relevant interpretation, but the facts still determine coverage and duties.

Is Washington consent the same as a cookie banner choice?

Do not assume so. Compare the interaction to the statute’s requirements for the classified collection, sharing, or sale, including the separate authorization provisions where applicable.

Does Google’s sensitive-interest policy ban all healthcare ads?

No. It restricts specified personalized advertising uses and targeting for sensitive interests. The Customer Data policy separately governs covered uploads. Review the exact feature and current policy.

References

HIPAA Authorization, Privacy Consent, and Google Ads Permission Are Different Gates

cmsapointoo on August 16, 2026

HIPAA Authorization, Privacy Consent, and Google Ads Permission Are Different Gates. A clinic can satisfy one gate and still fail another. A HIPAA authorization addresses a use or disclosure of protected health information under a specific federal rule. A privacy consent may address a separate purpose or legal duty. Google Ads then applies its own product policies to the proposed data use.

Review each gate independently. Do not treat a checkbox, signed authorization, privacy notice, vendor contract, or tag as universal approval. The official sources document different questions, and none says that one answer settles the others.

Why do these permissions need separate decisions?

Each permission answers a different question. HIPAA governs whether a covered entity may use or disclose protected health information for a defined purpose. Other privacy rules may require notice or a valid choice. Google decides whether its advertising product accepts the proposed data and use.

A single form can touch all three questions without producing the same answer. The clinic might have authority to keep information for treatment while lacking authority for a marketing disclosure. It might have a legally valid authorization while Google policy still excludes the conversion from a specific measurement product.

This separation also prevents a technical test from becoming a policy decision. A tag that fires or an interface that accepts a field proves only that a technical step occurred. The enhanced conversions audit proof guide explains why configuration, processing, reporting, and business outcomes are different proof layers.

What does 45 CFR 164.506 document about consent?

Section 164.506 permits covered entities to use or disclose protected health information for treatment, payment, or health care operations under the conditions stated in the rule. It also says a covered entity may obtain an individual’s consent for those permitted uses and disclosures. The word “may” matters because this is not a general authorization form for every purpose.

The same section states that this consent is not effective when section 164.508 requires an authorization or when another condition must be met. In other words, consent under 164.506 cannot be stretched to cover a use or disclosure that belongs behind another gate.

That is the documented rule. An editorial recommendation follows from it: label any 164.506 consent by its actual treatment, payment, or operations purpose. Do not name it “marketing consent” or “Google Ads consent” unless a qualified review has established a separate basis and the label accurately describes the choice.

When does 45 CFR 164.508 require authorization?

Section 164.508 provides the general rule for uses and disclosures that require authorization. It states that, unless another provision permits or requires the action, a covered entity may not use or disclose protected health information without a valid authorization. When authorization exists, the use or disclosure must remain consistent with it.

The section also addresses marketing uses of protected health information, with stated exceptions for certain face-to-face communications and promotional gifts of nominal value. It lists core authorization elements, including a meaningful description of the information, the authorized sender and recipient, the purpose, an expiration date or event, and a signature with date.

A valid authorization must also contain required statements, use plain language, and be copied to the individual when the covered entity seeks it. These requirements make authorization a defined document and process. A generic website checkbox or an acceptance of advertising cookies should not be relabeled as a HIPAA authorization without a qualified review against the rule.

Editorial recommendation: keep the signed authorization, its scope, revocation status, and disclosure record in the clinic’s approved environment. Do not copy the authorization, its text, or the underlying protected information into advertising fields.

Where does purpose-specific privacy consent fit?

“Privacy consent” is not a substitute term for either HIPAA provision. It can describe a choice required by another law, a website consent mechanism, or a clinic’s own permission workflow. The three registry sources do not define every state, federal, or international privacy requirement, so the exact duty must be assessed for the clinic’s jurisdiction and proposed use.

Separate every consent record by purpose. A choice about analytics does not automatically cover advertising. A choice about receiving messages does not automatically authorize disclosure of protected health information. A HIPAA authorization does not erase separate notice, consent, contract, or platform obligations.

Document the privacy gate in plain language: what data is involved, who receives it, why it is used, what choice the person has, and which rule or policy supports the decision. If the team cannot answer those points, pause the external use instead of borrowing approval from another checkbox.

What permission does Google Ads require?

Google’s Customer data policies apply to enhanced conversions for web, enhanced conversions for leads, store sales uploads, and Google-engaged audiences. They require advertisers to disclose relevant third-party sharing, obtain consent where legally required, comply with applicable laws, and use approved upload methods. Those requirements do not create eligibility by themselves.

The policy separately says advertisers may not upload conversion information related to sensitive categories. It identifies health or medical information as sensitive and says conversions related to sensitive categories cannot be measured through enhanced conversions or store sales uploads. A signed HIPAA authorization does not appear as an exception to that product restriction.

This is a documented platform fact, not an editorial preference. For a health-related clinic conversion within the stated policy scope, do not proceed because the patient signed a form. The article on why hashing does not establish eligibility applies the same policy boundary to clinic forms.

Google permission must be evaluated for the exact product and use. A customer-data policy for enhanced conversions does not answer every question about ordinary aggregate campaign reporting. Likewise, a successful API request does not grant permission. The clinic form Data Manager architecture keeps collection and delivery as separate decisions.

How should a clinic record the four gates?

The following table is an editorial control model. It is not language taken from the regulations or Google, and it is not a claim that every clinic faces the same legal duties. Its purpose is to stop one approval from silently standing in for another.

Gate Question to record Evidence What it cannot prove
HIPAA treatment, payment, or operations consent Does 45 CFR 164.506 apply to this use or disclosure? Scoped review and consent record, if used Authorization for a use that requires 164.508
HIPAA authorization Does the authorization meet 164.508 and cover this exact use? Valid, current authorization and disclosure scope Eligibility for a Google product
Other privacy consent What separate notice or choice applies to this purpose? Applicable rule, notice, choice, and timestamp HIPAA authorization or platform approval
Google Ads permission Does the current policy permit this data and use? Product, policy version, event classification, reviewer Compliance with HIPAA or another law

Give each row an owner and review date. Legal counsel assesses the relevant law. Privacy staff assess purpose and notice. Advertising and engineering teams describe the product, payload, and technical route. A completed implementation ticket does not record every approval.

What is a safe review sequence?

  1. Describe the proposed use or disclosure in ordinary language.
  2. Identify whether protected health information or health-related conversion information is involved.
  3. Review 45 CFR 164.506 and 164.508 separately where HIPAA applies.
  4. Identify any other purpose-specific privacy requirement without assuming it duplicates HIPAA.
  5. Classify the exact Google Ads product, data, destination, and intended use.
  6. Stop when any required gate fails or remains unresolved.
  7. Record the decision, source date, owner, and conditions for another review.

This sequence is an editorial recommendation. The regulations and Google policy supply the rules described above, but they do not prescribe this seven-step clinic workflow. The workflow makes the reasoning inspectable and keeps ambiguous health data out of advertising while the answer remains unresolved.

Internal analysis can continue without turning every clinic record into an advertising event. Aggregate reporting and clinic-owned outcome models can answer operational questions inside an approved boundary. See the internal treatment-acceptance value model for a related separation between internal economics and an external payload.

Frequently asked questions

Does a HIPAA authorization permit an enhanced conversion for a clinic?

Not by itself. A valid authorization addresses the use or disclosure described under 45 CFR 164.508. Google separately prohibits health-related conversion information in the enhanced-conversion measurement covered by its Customer data policies. Both gates must be evaluated, and a failure at either gate stops that use.

Is consent under 45 CFR 164.506 the same as authorization?

No. Section 164.506 says a covered entity may obtain consent for treatment, payment, or health care operations. It also says that consent is ineffective where 164.508 requires authorization or another condition remains unmet.

Can a website privacy checkbox serve as a HIPAA authorization?

Do not assume so. Section 164.508 requires specific elements and statements, plain language, a signature and date, and a copy for the individual when the covered entity seeks authorization. A qualified reviewer must assess the actual mechanism and proposed disclosure.

Can one approval record cover all four gates?

Do not assume it can. One record may hold links to separate decisions, but each gate still needs its own purpose, governing source, scope, owner, and outcome. A combined record must not blur a failed or unresolved gate.

References

How to Prevent Duplicate Appointment Reminders Across Your EHR and Booking Platform

cmsapointoo on August 16, 2026

Two scheduling systems can each have appointment reminder capabilities, but that does not prove a clinic is sending duplicate messages. Duplicate prevention begins with evidence: inventory every possible sender, inspect the live settings, and test the paths that create, reschedule, and cancel appointments.

Healthie and DrChrono both document configurable appointment reminders. Their documentation establishes independent capabilities, not the configuration of a particular stack. A practice should assign one owner for each message purpose, change one controlled setting at a time, and verify the result before saying duplicates have been prevented.

What the vendor documentation does and does not establish

Healthie’s appointment settings documentation describes automatic email and SMS alerts after booking, plus configurable client email and text appointment reminders. DrChrono documents appointment reminders set directly on an appointment or through reminder profiles, with email, text, and phone options. It also documents timing controls and spacing rules for reminders of the same type.

Those sources show that each product can participate in reminder delivery. They do not show that a clinic uses both products, that an integration copies appointments between them, that both reminder features are enabled, or that two messages with similar content were sent. Even when two systems are present, one may hold a read-only schedule, one may have reminders disabled, or the messages may serve different purposes.

Begin with the current account configuration and message records. Do not infer a duplicate from the vendor names alone. Product behavior and settings can change, so confirm the current documentation and live account before each rollout.

Define what counts as a duplicate

A useful duplicate definition needs more than “two messages arrived.” Define the intended rule for a single appointment, purpose, recipient, channel, and time window. Two messages are candidates for review when they refer to the same active appointment, have the same operational purpose, target the same destination, and were not expected under the approved cadence.

Do not automatically classify these cases as duplicates:

  • a booking confirmation and a later appointment reminder;
  • an appointment reminder and an intake-form reminder;
  • a reschedule confirmation that replaces an earlier appointment time;
  • a staff message sent after a documented delivery failure;
  • messages for two distinct appointments on the same day.

The purpose field is crucial. Appointment reminders versus intake reminders need separate eligibility and outcome rules. Similar wording does not make their jobs identical.

Inventory every possible sender

List each system that can generate patient-facing appointment communication. This may include the EHR, practice management system, booking marketplace, scheduling layer, contact center, messaging service, and a manual staff workflow. Include inactive or legacy integrations until their current state is verified.

Inventory field Question to answer Evidence
System and owner Who can change its reminder settings? Current account access and named role
Message purpose Is it confirmation, attendance, intake, or another approved purpose? Template and workflow rule
Trigger Which booking or status event queues it? Live setting and event record
Timing and channel When and how can it be sent? Configuration and attempted-send log
State-change behavior What happens after reschedule or cancellation? Synthetic path test
Retry behavior Can a failed or delayed job attempt again? Queue or vendor event history

Capture screenshots or exports according to clinic security policy, along with the date reviewed. Do not place patient details in a general configuration worksheet. The goal is a reproducible map of senders, not a copy of clinical records.

Assign one owner per message purpose

Once the inventory is complete, assign a primary system for each approved purpose. One system might own booking confirmations, another appointment reminders, and another incomplete-intake notices. The choice should follow data quality, state-change handling, auditability, and operational ownership rather than vendor preference alone.

Write the decision as a routing rule: purpose, eligible appointment states, source system, channel, cadence, stop conditions, fallback owner, and approval date. Mark every other sender for that same purpose as disabled, not applicable, or retained for a documented exception.

Do not switch off a broad notification category until the team confirms which messages it includes. A label such as “appointment alerts” may cover a booking confirmation that the clinic still needs. Review template and trigger details before changing the toggle.

If a marketplace supplies bookings while the practice owns ongoing scheduling, keep acquisition and operations distinct. Comparing Zocdoc alternatives for existing demand provides context for that boundary. It does not decide which reminder sender is correct for a particular stack.

Test booking, reschedule, and cancellation paths

Use synthetic records created under the clinic’s approved testing process. Do not use a real patient’s appointment as a test. Select a non-deliverable test destination or an approved staff-controlled destination so no unintended person receives a message.

Run at least these paths:

  1. Create a new appointment through each active booking entry point.
  2. Observe which systems receive or create the appointment and which messages become queued.
  3. Reschedule the appointment and confirm the old-time message is cancelled or updated according to the approved rule.
  4. Cancel the replacement appointment and confirm pending reminders stop.
  5. Repeat a save or integration sync to see whether the same event is processed twice.
  6. Where safe and supported, test a failed delivery or retry state without contacting an unintended recipient.

Record the original appointment identifier and any replacement identifier. The method for preserving booking source after reschedule also helps maintain lineage across this test. A new identifier should not make the old reminder invisible during review.

Compare intended messages with event evidence

Create a compact ledger for the test cohort. Include appointment lineage, purpose, sender, template version, channel, scheduled time, attempt identifier, delivery state if supplied, and cancellation state. Compare the ledger with the approved routing rule.

An attempted-send event and a delivered-message event are not interchangeable. Some systems expose only part of the delivery chain. Use the most precise label supported by the evidence. If two attempts exist but delivery is unknown, report two attempts, not two delivered reminders.

Check whether the apparent duplicate came from two senders, one sender with two rules, a retry, a staff action, or a reschedule that left an old job queued. Each cause has a different fix. Avoid changing the EHR when the evidence points to a booking platform rule, and avoid disabling a platform when one local profile is responsible.

Make one controlled change

Choose the narrowest setting that removes the overlapping purpose while preserving the intended message. Record the previous value, new value, approver, time, affected appointment types, and rollback step. If the setting’s scope is unclear, pause and ask the vendor or integration owner before changing it.

Repeat the same synthetic paths after the change. A settings page that displays “off” is not sufficient proof if another profile, location, or account can still send. Likewise, absence of a message in one quick test does not prove every channel and appointment type is covered.

Keep the change reversible until the test set and a bounded monitoring period pass. Do not add a new integration or custom deduplication service if existing sender ownership and configuration solve the problem. A new component adds another queue, failure mode, and audit surface.

Monitor without overstating the result

After rollout, review candidate duplicate events by appointment lineage and purpose. Track unresolved records separately. A zero count in the reviewed cohort means no candidate duplicates were observed under those tested rules and data sources. It does not prove duplicates can never occur.

Review changes after vendor releases, new locations, new reminder profiles, and integration updates. Also check new booking sources. The distinction between appointment source and marketing source helps keep scheduling configuration from being confused with acquisition attribution.

For operational reporting, pair reminder evidence with a stable outcome taxonomy rather than claiming reminder changes produced attendance changes. The no-show rate by booking source guide explains denominator and final-status controls. Duplicate prevention is a message-governance result, not proof of lower no-shows.

FAQ

If both vendors offer reminders, are duplicates likely?

The documentation establishes that both products have reminder capabilities. It does not establish the clinic’s live settings, integrations, or message history. Inventory and test the specific stack before making that claim.

Should the EHR always own appointment reminders?

Not automatically. Choose the owner that reliably receives appointment state changes, applies the approved communication rules, and leaves useful event evidence. Document exceptions and stop conditions.

When can a practice say duplicates are prevented?

After the sender inventory is complete, one owner is assigned per purpose, synthetic booking, reschedule, cancellation, and relevant retry paths pass, and a bounded review finds only the intended messages. State the tested scope and avoid an absolute guarantee.

References