Which Zocdoc Cancellation and Reschedule Changes Trigger a Patient-Booking Webhook?

cmsapointoo on August 16, 2026

Zocdoc’s patient-booking webhooks do not represent every cancellation or reschedule path. In that use case, webhook notifications are sent only for provider-initiated appointment changes. When a developer or patient initiates the action through the API flow, Zocdoc tells the developer to update internal systems from the API response and not wait for a webhook.

Two other checks matter. A reschedule request is accepted only from documented appointment states. The credential used for the original booking controls who may later view or modify it. Keep the API response and any provider-originated webhook attached to the same appointment state record.

Which appointment changes produce a patient-booking webhook?

Zocdoc says its webhooks cover changes to appointment statuses for appointments booked through /v1/appointments/, including cancellations and reschedules. It then narrows the patient-booking use case: webhook notifications are sent only for provider-initiated appointment changes.

For developer- or patient-initiated actions, the instruction is different. Update the internal system from the API response and do not wait for a webhook. A booking integration that waits for every cancellation to return through the webhook channel can leave its own record stale even though the initiating API request already completed.

This is an initiator boundary, not a statement that Zocdoc has no cancellation webhooks. Identify who initiated the change and which flow handled it. Keep that evidence with the appointment state, not in marketing attribution. The article on booking systems versus CRM ownership explains why operational truth should not be reconstructed from downstream marketing records.

What should happen after a developer-initiated change?

When the developer or patient initiates the cancellation or reschedule, use the response from that API operation to update the internal record. Do not create a pending state whose only exit depends on a webhook that the documented patient-booking flow does not promise.

Operational inference: store the action identifier, initiator class, request time, returned appointment data or outcome, and previous local state. Apply the response through an idempotent state transition. The source directs the integration to use the API response; it does not prescribe database columns, queue design, or the exact names of local states.

If the response is ambiguous or the request fails, do not guess that the appointment changed. Re-read the appointment through an authorized path or send the case to reconciliation. Keep availability publication separate until the booking state is known. For the related upstream contract, see how Zocdoc timeslot updates replace a provider day.

What should happen after a provider-initiated change?

A provider-originated cancellation or reschedule in the patient-booking use case is the path for which Zocdoc documents webhook notification. The webhook is an external event, so the receiver must authenticate it, identify the appointment, and apply the status change without assuming delivery occurs exactly once.

Zocdoc supports HTTPS for appointment status webhooks, with HTTP allowed only for sandbox testing. Each webhook request is signed with a shared key. The guide tells clients to verify the signature so they can confirm origin and detect tampering. It also uses a webhook timestamp and recommends checking that it is within a few minutes, with five minutes shown as the default.

Operational inference: acknowledge only after the event has reached durable processing, then make the state transition idempotent. The separate guide on booking webhook idempotency and audit evidence covers that generic implementation problem. Zocdoc’s source establishes the trigger, signature, and retry contract.

Which states can be rescheduled?

Zocdoc’s Appointment Actions guide permits a time change and reschedule request when the appointment is in pending_booking, confirmed, pending_reschedule, or rescheduled. The operation uses POST /v1/appointments/reschedule with the appointment_id and new start_time.

Do not send the operation from an unlisted state merely because the local interface offers an edit button. Validate the current Zocdoc state first. If local state differs, reconcile before retrying. The source lists the states accepted for this action, but it does not authorize an integration to manufacture one locally.

Visit-reason and EHR type mapping is another boundary. A new time does not repair a mismatched clinical scheduling code. Use the documented method for mapping Zocdoc visit reasons to EHR appointment types and validate the rescheduled appointment against the same mapping.

How does cancellation differ from rescheduling?

Cancellation uses POST /v1/appointments/cancel. The documented example sends an appointment_id, a free-text cancellation_reason, and a cancellation_reason_type. Rescheduling uses its own endpoint and supplies a new start time. They are separate actions rather than two labels for the same update.

Keep the local transition and audit record distinct. A cancellation should not silently reopen a slot unless the scheduling source and availability contract establish that result. A reschedule involves the old time and the requested new time, but the cited sources do not define a clinic’s inventory reconciliation algorithm.

Operational inference: reconcile both the appointment and affected availability after the API result or provider webhook is accepted. Do not copy cancellation text into analytics, Ads, or general logs. A reason may contain sensitive context. Store only what the approved booking workflow needs.

How does the original credential affect modification access?

Zocdoc documents the same credential boundary for cancellation and rescheduling. If an appointment was booked with a Zocdoc user credential, only that user can view or modify the appointment. If it was booked with a machine-to-machine credential, any of the developer’s machine-to-machine credentials can view and modify it.

A valid access token is therefore not enough by itself. The integration must know which credential class created the booking and select an authorized credential for the later action. A 401 or 403 should not be translated into an unsupported state change or a second appointment.

Operational inference: retain non-secret provenance that identifies the booking’s credential class and accountable principal. Never store an access token in the appointment audit record. If credential ownership cannot be established, stop the mutation and reconcile through an approved support path.

What retry behavior can surprise a webhook receiver?

Zocdoc says it retries webhook events with exponential backoff for up to 48 hours after the first attempt. Retries occur when a connection cannot be established, when no response arrives within five seconds, or when the connection ends before a response. Zocdoc does not retry based on the status code returned by the webhook endpoint.

A quick HTTP response does not prove durable processing. Returning an error status does not itself request another delivery under the documented rule. Taking longer than five seconds can create a retry even when the original handler continues working. The receiver must tolerate repeated delivery and avoid applying one provider change twice.

The payload signature uses a timestamp and JSON payload, and Zocdoc notes that the schema may change. Validate required fields while allowing compatible additions. Do not disable signature checking to accommodate a parser failure.

What end-to-end test proves the initiator boundary?

Use sandbox appointments and synthetic people only. Book one appointment with the credential class under test. Record its current Zocdoc state. Exercise a developer-initiated cancellation or reschedule, then confirm that the internal system updates from the API response without waiting for a webhook.

Next, use the supported sandbox path for a provider-initiated change and verify the signed webhook. Check that the receiver validates the timestamp and signature, responds within five seconds, and applies a repeated event only once. Test user-credential and machine-to-machine bookings separately because their later modification rights differ.

Pass only when the same final state is reached through the correct evidence path for each initiator. Do not use a webhook absence as proof that an API action failed. Do not use an API success from one credential class as proof that another credential can modify the booking.

Frequently asked questions

Will every Zocdoc cancellation send a webhook?

No. In the patient-booking use case, Zocdoc says webhook notifications are sent only for provider-initiated appointment changes. Developer- or patient-initiated actions should update internal state from the API response.

Which appointment states can the reschedule endpoint modify?

The documented states are pending_booking, confirmed, pending_reschedule, and rescheduled. Reconcile an appointment in any other state before attempting the operation.

Can any valid Zocdoc token cancel a user-booked appointment?

No. If the appointment was booked with a Zocdoc user credential, only that user can view or modify it. Machine-to-machine bookings follow the separate developer credential boundary.

Does returning HTTP 500 make Zocdoc retry a webhook?

Not under the documented retry rule. Zocdoc says retries are based on connection failure, no response within five seconds, or a severed connection, not the returned status code.

References

Why a Google Calendar FreeBusy Error Is Not an Open Provider Slot

cmsapointoo on August 16, 2026

A Google Calendar FreeBusy error is not an open provider slot. The freeBusy.query response can report errors for an individual calendar or an expanded group. When that happens, the integration does not have reliable occupancy data for the affected provider. It should treat the result as indeterminate, not convert the absence of usable busy intervals into availability.

The API also places exact limits on expansion: at most 100 calendar identifiers from one group and at most 50 calendars in one query. Those limits matter in a multi-provider clinic. A request can be structurally valid while one calendar cannot be computed, cannot be found, or exceeds an expansion boundary.

What does a FreeBusy response actually establish?

Google documents POST https://www.googleapis.com/calendar/v3/freeBusy as a query for free and busy information across a set of calendars. The request supplies timeMin, timeMax, an optional response timeZone, expansion limits, and calendar or group identifiers. The returned structure separates group results from calendar results.

For a calendar that was computed successfully, the busy array contains time ranges. Google defines each busy start as inclusive and each end as exclusive. An empty busy array can support a free result only when the calendar result itself is valid for the requested interval. The response shape also permits an errors array on that same calendar.

Operational inference: make result validity a separate field from the busy interval list. A calendar with no busy intervals and no error is different from a calendar whose computation failed. Collapsing both cases into an empty array creates a false opening. Jane has its own calendar coverage boundary, described in why secondary Google calendars do not block Jane online booking.

Which errors must the availability parser inspect?

The official response schema includes groups.(key).errors[] and calendars.(key).errors[]. Google lists groupTooBig, tooManyCalendarsRequested, notFound, and internalError as possible reasons. It also warns that new error types may be added, so a client cannot safely rely on a closed list.

Parse errors before turning intervals into appointment slots. A notFound result means the requested resource was not found and may point to a stale identifier. An internalError is not evidence that the calendar contains no events. Expansion errors show that the requested set was not computed within the stated boundary.

Operational inference: use a small outcome model such as valid, temporarily indeterminate, and configuration error. The Google source does not prescribe those labels. It does establish enough structure to prevent the unsafe shortcut of treating every non-busy result as free. Log the calendar reference, query window, reason, and attempt without copying event details.

How should the 100-member and 50-calendar limits be handled?

groupExpansionMax controls the number of calendar identifiers returned for one group and has a maximum value of 100. calendarExpansionMax controls the number of calendars for which FreeBusy information is provided and has a maximum value of 50. A group larger than the configured group limit returns an error.

Do not solve a limit error by dropping calendars silently. That would make omitted providers appear available if downstream code assumes the request covered everyone. Keep the expected provider set beside the returned set, and require every expected calendar to reach a valid result before publishing its slots.

Operational inference: divide a larger roster into deterministic groups of no more than 50 calendars, then merge only validated results for the same query window. If the clinic uses Google Groups, resolve and compare group membership deliberately rather than assuming one group call proves complete coverage. Chunking is an integration method derived from Google’s cap, not a workflow mandated by Google.

Why do time bounds and time zones need separate checks?

Google requires timeMin and timeMax as RFC3339 date-time values. The optional timeZone controls the zone used in the response and defaults to UTC. These fields describe the query and presentation window. They do not decide the clinic’s appointment duration, buffer rules, provider location, or booking horizon.

Compare the returned timeMin and timeMax with the requested range before generating openings. Normalize intervals to one approved scheduling zone, then apply clinic rules after occupancy is known. A UTC response is not wrong, but displaying or slicing it as local time without conversion can shift a busy interval into the wrong provider day.

Operational inference: test local midnight and local clock changes for every operating zone. The source defines the API fields, not the clinic’s time-zone policy. Keep that policy explicit and avoid browser-derived defaults in server-side availability calculations.

What permission is sufficient for occupancy checks?

Google’s calendar-sharing documentation defines freeBusyReader as permission to see whether a calendar is free or busy without access to event details. The role can use freeBusy.query. This is narrower than reader, writerWithoutPrivateAccess, writer, or owner.

Use the narrow role when occupancy is the only business need. A scheduling layer does not need meeting titles, descriptions, guest lists, or other event content to subtract busy periods. Domain settings can still restrict the effective access granted to a Google Workspace user, so a configured ACL is not proof that every query will succeed.

Sharing a calendar also does not automatically insert it into a user’s CalendarList. Do not use visibility in the Google interface as the sole test of API access. Verify the exact calendar identifier and the FreeBusy result. For broader booking data boundaries, see minimum necessary fields for a booking integration.

What is a safe slot-generation sequence?

A safe sequence proves coverage before it publishes availability. Start with the expected provider calendars and one explicit RFC3339 interval. Send queries within the documented expansion limits. Inspect group errors, calendar errors, returned identifiers, and interval bounds before reading any busy array.

  1. Resolve the approved calendar identifier for every provider in scope.
  2. Split requests so no query asks for more than 50 calendars.
  3. Send identical time bounds and the approved response time zone.
  4. Reject or quarantine every group or calendar carrying an error.
  5. Subtract busy intervals only for calendars with valid results.
  6. Apply clinic duration, buffer, and booking-window rules afterward.
  7. Publish slots only for providers whose coverage is complete.

This ordering keeps calendar truth ahead of presentation logic. It mirrors the replacement-safety principle in Zocdoc provider-day timeslot updates: unknown upstream state should stop publication rather than erase or invent availability.

How should retries avoid accidental double booking?

The two cited Google pages describe the FreeBusy contract and sharing roles, not a complete retry policy for clinic scheduling. Operational inference: retry transient failures within a bounded window, but keep the affected provider unavailable until a valid response arrives. A cached result may be used only under a documented clinic policy with an explicit age ceiling.

Do not convert a retry timeout into an empty busy array. Return an unavailable or temporarily indeterminate state to the booking interface. Preserve enough evidence to diagnose the failed calendar without storing event content. If the system later publishes a slot, it should use a fresh validated query rather than the failed response.

Reconciliation should compare the provider set requested, the calendars returned, their error arrays, and the slots eventually published. After a booking exists, asynchronous updates need a different check. The guide to idempotent and auditable booking webhooks covers duplicate delivery and state reconciliation.

What acceptance test proves the boundary?

Use synthetic calendars and neutral events. First query a calendar with one known busy interval and confirm that the interval removes the expected opening. Then query an invalid calendar identifier and confirm that the provider becomes indeterminate rather than fully free. Repeat with enough test identifiers to exercise the local chunking path.

Record the request window, response zone, expected identifiers, returned identifiers, error reasons, and publication decision. Do not put patient names, treatment details, or appointment reasons into test events or logs. The test concerns occupancy and error handling, not clinical content.

Pass only when every expected provider has either a valid computed result or an explicit blocked state. A successful HTTP exchange alone is insufficient because the documented response body can carry errors for specific groups or calendars.

Frequently asked questions

Does an empty busy array always mean the provider is free?

No. It supports that conclusion only for a valid calendar result covering the requested interval. If the calendar or its group has an error, availability is indeterminate and should not become an open slot.

Can one FreeBusy request cover 70 provider calendars?

Google documents a maximum calendarExpansionMax of 50. An integration with 70 calendars should split the work into bounded requests and verify that every expected calendar produced a valid result before merging availability.

Do I need permission to read event titles?

No, not when the integration only needs occupancy. Google’s freeBusyReader role reveals whether time is free or busy without granting access to event details.

Should an internal error reopen the provider’s day?

No. internalError means the computation failed. Treating it as a free calendar would be an unsafe operational inference. Keep the provider blocked or indeterminate until a valid result is available.

References

Telefone ou horário da clínica pendente no Perfil da Empresa: isso é rejeição?

cmsapointoo on August 16, 2026

“Pendente” não significa que o Google rejeitou a alteração do telefone ou do horário da clínica. O status informa que a edição ainda está em revisão. Segundo a Ajuda do Perfil da Empresa, a análise costuma levar até 10 minutos, mas alguns casos podem permanecer pendentes por até 30 dias. “Não aprovado” é um estado diferente.

Enquanto a edição está pendente, confirme que a equipe alterou o perfil correto e compare a informação com as fontes públicas da clínica. O Google também pode atualizar campos com dados de usuários e conteúdo licenciado. A mudança só deve ser tratada como concluída depois de aparecer no resultado público esperado.

Qual é a diferença entre Pendente e Não aprovado?

Depois que uma pessoa salva uma edição num Perfil da Empresa verificado, o Google revisa a mudança para conferir se ela segue as diretrizes. A plataforma apresenta três estados documentados: Aceita, Pendente e Não aprovada. Cada estado descreve uma fase ou decisão diferente.

Uma edição pendente ainda está sendo analisada. O prazo normal informado é de até 10 minutos, com possibilidade de chegar a 30 dias em alguns casos. Uma edição não aprovada já recebeu outra decisão porque o Google não conseguiu confirmar sua precisão. A página de ajuda informa que algumas edições não aprovadas podem ser contestadas.

Não apague e reenvie o mesmo valor a cada hora. A documentação não diz que repetições aceleram a análise. Várias tentativas também dificultam saber qual versão foi avaliada. Preserve o valor anterior, o valor enviado, a data, a conta responsável e o status exibido.

Inferência operacional: trate Pendente como estado aberto no fluxo da clínica. Não marque a tarefa como concluída, não anuncie o novo horário como publicado e não descarte o canal antigo antes de confirmar a exibição pública.

Por que telefone e horário exigem uma verificação pública?

Telefone e horário são campos que uma pessoa usa antes de contatar ou visitar a clínica. Uma edição aceita na interface administrativa precisa ser conferida na Pesquisa e no Maps, pois esse é o resultado que o público encontra. O artigo de edição do Google lista telefone e horário entre os dados gerenciáveis do perfil.

Confira o perfil como usuário, de preferência sem depender da sessão administrativa. Teste o botão de chamada com um procedimento aprovado e confirme se o número pertence à unidade. Compare horário regular, períodos especiais e estado aberto ou fechado. Não faça uma ligação que ocupe a recepção sem avisar a equipe.

Uma clínica com várias unidades deve validar o local antes de editar. Nome semelhante não basta. Endereço, URL do perfil e acesso da conta ajudam a distinguir as fichas. A orientação sobre perfis de clínica e profissionais explica por que organização, unidade e médico não são identidades intercambiáveis.

Se a mudança envolver endereço, use o procedimento específico para mudar a clínica sem perder a leitura do perfil histórico. O status de telefone ou horário não responde sozinho ao tratamento de avaliações, duplicatas ou mudança de entidade.

Como fontes externas podem alterar o perfil?

O Google informa que coleta dados de diferentes fontes, incluindo relatos de usuários e conteúdo licenciado. Se essas fontes indicarem que o perfil está incorreto ou desatualizado, a plataforma pode atualizá-lo. Nem toda atualização do Google pode ser gerenciada pelo próprio editor do Perfil da Empresa.

Por isso, uma edição correta pode disputar espaço com informações divergentes publicadas em outros lugares. Revise o site oficial da clínica, páginas da unidade, diretórios que a organização controla e materiais públicos atuais. Corrija primeiro a fonte sob controle direto quando ela ainda mostra telefone ou horário antigo.

Inferência operacional: consistência pública pode ajudar a demonstrar qual informação é atual, mas não há garantia de aprovação automática. As fontes citadas explicam de onde o Google pode obter dados; elas não publicam um peso ou uma ordem de prioridade para cada site ou relato.

Não tente influenciar a revisão com avaliações de pacientes ou detalhes de consultas. Textos de avaliações podem revelar informações pessoais ou de saúde e não são prova apropriada para um campo operacional. Use documentos empresariais e páginas públicas sem dados clínicos quando o suporte solicitar evidência.

Quando a clínica deve esperar e quando deve agir?

Se a edição está Pendente e ainda está dentro da janela documentada, monitore o estado e evite alterações concorrentes. Confirme que o valor enviado está correto. Registre uma verificação pública em horários definidos, sem transformar a espera em dezenas de novas submissões.

Se o status mudar para Não aprovado, leia o motivo apresentado e verifique se a edição pode ser contestada. Compare o telefone ou horário com a documentação atual da empresa e com as fontes públicas. Corrija uma inconsistência real antes de recorrer. Não conteste um valor que a própria clínica não consegue provar.

Se a pendência ultrapassar 30 dias, prepare uma solicitação objetiva ao suporte. Informe URL do perfil, unidade, campo alterado, valor anterior, valor solicitado, data da edição e status atual. Inclua apenas a evidência necessária. Não envie agenda, cadastro, conversa, prontuário ou documento de paciente.

Uma urgência operacional pede um canal alternativo, não uma alegação falsa de publicação. Enquanto o telefone novo não aparece, mantenha o número anterior funcionando quando isso for seguro e autorizado. Se o horário público estiver incorreto, oriente recepção e site para reduzir o impacto até a correção.

Que evidência deve ser guardada sem expor pacientes?

Guarde a URL pública do perfil, identificação interna da unidade, conta gestora, campo alterado, valor anterior, valor novo, data e hora, status e capturas do editor e do resultado público. O registro deve permitir que outra pessoa reconstrua a alteração sem acessar informações de atendimento.

Para telefone, registre o número empresarial público e a unidade a que pertence. Para horário, registre dias e faixas públicas. Não inclua escala nominal, motivo de ausência, nome de profissional afastado ou agenda com pacientes. O perfil precisa comunicar disponibilidade pública, não a causa clínica ou trabalhista por trás dela.

Se o suporte pedir comprovação, envie a menor evidência capaz de confirmar o dado empresarial. Remova notificações, abas e capturas que mostrem pessoas atendidas. A própria página de ajuda alerta contra compartilhar informações pessoais ou comerciais privadas em fórum público.

Registre também quem aprovou a mudança dentro da clínica. A propriedade de outros campos, como o botão de agendamento, pode pertencer a outra fonte. Veja quem controla o link de agendamento antes de atribuir toda diferença à mesma edição.

Como evitar que várias pessoas disputem o mesmo campo?

Defina um responsável por telefone e horário em cada unidade. Recepção pode identificar a mudança; gestão confirma o valor; uma pessoa autorizada edita o perfil e registra o resultado. Agência e fornecedor não devem reenviar valores diferentes sem consultar esse registro.

Use um fluxo curto: solicitado, aprovado internamente, enviado ao Google, pendente, aceito ou não aprovado, verificado publicamente. O Apointoo pode mostrar esses estados operacionais, mas não deve marcar a edição como publicada apenas porque alguém clicou em Salvar.

Separe telefone, horário, endereço e link de agendamento. Uma mudança pode ser aceita enquanto outra permanece pendente. Se um fornecedor antigo continuar no perfil, aplique o processo para remover um link de agendamento de terceiros em vez de editar campos sem relação.

Faça uma revisão periódica das fontes públicas controladas pela clínica. Isso reduz divergências e torna futuras verificações mais objetivas. A revisão não precisa coletar buscas de pacientes, termos de saúde ou histórico de chamadas. Ela compara apenas os dados empresariais publicados.

Como executar uma verificação segura após a aprovação?

Espere o status sair de Pendente e abra o perfil público correto. Confira o telefone visível, o botão de chamada e o horário em Pesquisa e Maps. Registre a data, a superfície e o resultado. Quando houver diferença entre telas, preserve ambas e continue a investigação sem declarar sucesso parcial como conclusão.

  1. Confirme a unidade pelo nome, endereço e URL do perfil.
  2. Compare o campo público com o valor aprovado internamente.
  3. Teste o telefone empresarial de forma coordenada com a recepção.
  4. Confira horário regular e horário especial aplicável.
  5. Repita a verificação numa segunda superfície relevante.
  6. Feche a tarefa somente quando o resultado público estiver correto.

O teste comprova exibição e funcionamento básico. Ele não prova volume de chamadas, novos pacientes, agendamentos ou receita. Mantenha esses indicadores em relatórios próprios e com definições claras. O Perfil da Empresa é uma superfície pública, não um prontuário nem um sistema de atribuição individual.

Perguntas frequentes

Pendente por 24 horas significa que a edição foi rejeitada?

Não. O Google informa que a revisão costuma levar até 10 minutos, mas alguns casos podem levar até 30 dias. Enquanto o status for Pendente, a edição continua em análise. Não aprovado é outro estado.

Devo reenviar o mesmo telefone todos os dias?

A documentação não diz que reenvios aceleram a revisão. Confirme o valor, registre a submissão e monitore o status. Alterações repetidas dificultam a auditoria e podem criar versões concorrentes sem resolver a causa.

O Google pode mudar o horário sem a clínica editar?

Sim. O Google diz que pode atualizar o perfil com informações de fontes como relatos de usuários e conteúdo licenciado. Revise as atualizações e corrija fontes públicas desatualizadas sob controle da clínica.

Posso enviar uma captura da agenda ao suporte?

Evite. Uma agenda pode revelar nomes, contatos e informações de saúde. Envie apenas evidência empresarial necessária, como o campo público, a unidade, a data da edição e o status, com qualquer dado pessoal removido.

Referências

Por que Rotas vira conversão no Google Ads mesmo após um resultado orgânico?

cmsapointoo on August 16, 2026

“Ações locais: rotas” pode aparecer como conversão mesmo quando o clique em Rotas ocorreu depois, em um resultado orgânico da clínica. O Google Ads documenta essa sequência: a pessoa interage com um anúncio e, mais tarde, acessa o Perfil da Empresa pelo anúncio ou pela busca orgânica e solicita a rota. Dentro da janela de conversão, o Ads atribui essa ação local à interação anterior.

Essa atribuição não prova que a pessoa iniciou o trajeto, chegou à clínica, marcou uma consulta ou gerou receita. Ela prova o clique atribuído no botão de rotas. Relatórios e lances precisam conservar essa definição, enquanto agendamento e comparecimento permanecem no sistema operacional aprovado pela clínica.

Como uma rota orgânica vira conversão atribuída ao anúncio?

O Google descreve duas etapas. Primeiro, a pessoa encontra e interage com um anúncio da empresa na região. Depois, ela clica no botão Rotas para saber como chegar ao local. Esse segundo clique pode acontecer no próprio anúncio ou em um resultado orgânico referente à empresa.

A plataforma conecta a ação posterior à interação publicitária dentro da janela definida para a conversão. A janela de cliques padrão para ações locais é de 30 dias e pode ser consultada ou editada na página de metas. Por isso, a coluna pode registrar Rotas num dia em que o caminho visível da pessoa terminou no Perfil orgânico.

Não há contradição entre “resultado orgânico” e “conversão do Ads” nesse modelo. Orgânico descreve onde ocorreu o clique em Rotas. Conversão atribuída descreve a relação que o Google estabeleceu com uma interação publicitária anterior. A fonte não afirma que todo clique orgânico receberá essa atribuição.

Inferência operacional: ao investigar um aumento, compare a janela de atribuição e o histórico de campanhas antes de procurar uma tag no site. A ação acontece em produtos do Google e pode ser hospedada pela plataforma. Uma auditoria limitada ao código da página da clínica não explica sozinha esse evento.

O que a conversão de Rotas realmente mede?

A documentação chama Rotas de uma conversão de ação local. Ela mede uma interação com a localização física, especificamente o clique usado para pedir instruções de chegada. O material de métricas de pesquisa resume a mesma definição como cliques no botão “Como chegar”.

O evento não contém uma confirmação pública de deslocamento. A pessoa pode cancelar, escolher outro destino, ligar para a clínica ou não sair do lugar. Também não há, nas fontes citadas, vínculo documentado com uma consulta, um paciente novo, um procedimento aceito ou um pagamento.

Use um nome que preserve o fato observado, como “clique em Rotas atribuído pelo Google Ads”. Evite renomear a ação para “visita à clínica”. Visitas à loja são outra categoria de medição do Google e têm regras próprias. Compare ainda com o limite de uma conversão de chamada, que também não confirma agendamento.

Quando o relatório precisa chegar ao comparecimento, faça a ligação em ambiente aprovado e com dados mínimos. O método para medir comparecimento por campanha sem detalhes da consulta mostra por que a plataforma de anúncios e a agenda precisam de fronteiras diferentes.

Por que a meta pode aparecer automaticamente na conta?

O Google informa que configura ações locais automaticamente quando os recursos de local estão corretos e ativos. Depois que a conta recebe pelo menos uma conversão para a ação relevante, a meta é criada automaticamente como meta hospedada pelo Google. Entre os exemplos estão Cliques para ligar e Ações locais: rotas.

Isso explica por que uma equipe pode encontrar a ação sem ter criado uma tag de conversão com esse nome. O gatilho técnico não é um formulário do site. Ele depende dos recursos de local, da interação registrada nos serviços do Google e das regras da conta.

Confira se o Perfil da Empresa correto está vinculado, quais locais estão ativos e quais campanhas usam esses recursos. Uma agência com várias unidades deve confirmar a conta e o estabelecimento antes de interpretar o número. A ação atribuída a um local não prova que a consulta ocorreu naquela unidade.

Inferência operacional: registre a data de ativação ou alteração dos recursos de local. A documentação confirma a criação automática da meta, mas não identifica a mudança específica que causou uma variação em determinada conta. O registro local ajuda a testar essa hipótese sem apresentá-la como fato do Google.

Em qual coluna e campanha essa ação aparece?

O Google informa que as ações locais ficam disponíveis na coluna Todas as conversões. A equipe pode filtrar a tabela por ação de conversão na página de metas ou segmentar a visão da campanha. O relatório de lojas também apresenta métricas relacionadas aos locais.

Para usar Rotas em lances, a documentação orienta incluir a ação como meta nas campanhas compatíveis, incluindo Performance Max, pesquisa e Shopping nas condições descritas. Essa decisão altera o sinal que a estratégia tenta aumentar. Ela não muda o significado do evento.

Antes de tornar a ação principal, confirme se a clínica realmente quer mais solicitações de rota e qual valor relativo esse comportamento tem. Uma unidade que recebe muitos cliques de curiosidade pode mostrar volume sem gerar capacidade ocupada. Trate a escolha de meta como decisão de mídia, não como correção automática de relatório.

Use a mesma disciplina aplicada à configuração de contagem. O guia sobre contar Uma ou Todas as conversões mostra que uma configuração de Ads afeta relatórios e lances futuros, mas não substitui os estados internos do funil.

Como investigar um aumento inesperado em Rotas?

Comece pela definição da métrica, não por uma conclusão sobre pacientes. Escolha o período, segmente por ação de conversão e identifique campanhas, locais, dispositivos e datas envolvidos. Confira a janela de cliques vigente e as alterações recentes nos recursos de local.

  1. Confirme o nome exato da ação e se ela é hospedada pelo Google.
  2. Verifique a janela de conversão usada no período.
  3. Compare as campanhas e os locais que geraram o aumento.
  4. Revise mudanças no Perfil da Empresa e nos recursos de local.
  5. Compare Rotas com chamadas, agendamentos e comparecimentos como séries separadas.
  6. Anote hipóteses sem atribuir identidades ou condições de saúde aos usuários.

Não tente reproduzir a atribuição usando uma busca real feita repetidamente pela equipe. Cliques de teste podem poluir os relatórios e não revelam os critérios internos completos da plataforma. Se um teste for necessário, documente um cenário aprovado e limite-o a dados sintéticos.

Inferência editorial: quando Rotas sobe e os agendamentos não mudam, a diferença pode indicar intenção local sem conclusão do funil, mas também pode refletir janelas, locais ou períodos distintos. Compare definições e coortes antes de chamar isso de perda. A fonte do Google não diagnostica o negócio da clínica.

Como separar Rotas, visita, agendamento e receita?

Crie uma sequência de estados com nomes literais. O Ads registra a ação local Rotas. A agenda registra pedido e confirmação de horário. O sistema da clínica registra comparecimento conforme sua governança. O financeiro registra receita. Nenhum desses estados deve ser promovido automaticamente ao próximo.

A taxonomia de resultados de agendamento para Google Ads ajuda a manter envio, reserva, confirmação, comparecimento e cancelamento como eventos distintos. Rotas deve ficar antes desses estados, como interação local atribuída, sem receber um valor de consulta por conveniência.

Para análise econômica, compare totais agregados e períodos compatíveis. Não use autores de avaliações, consultas pesquisadas ou detalhes da agenda para descobrir quem clicou em Rotas. O modelo publicado é uma métrica de plataforma, não uma lista de pessoas.

O Apointoo pode exibir Rotas ao lado de outras ações, desde que mostre a definição e a origem. O produto não deve rotular o clique como paciente, visita confirmada, consulta ou receita, nem transportar dados de saúde para o Google Ads.

Que evidência deve ficar no relatório da clínica?

Registre o nome da ação, conta, campanha, local, período, janela de conversão e coluna usada. Indique que a ação é hospedada pelo Google e que pode ocorrer após a interação com o anúncio, inclusive em resultado orgânico posterior. Essa nota evita que outra pessoa leia o número como tráfego direto ao site.

Mantenha chamadas e Rotas separadas. O Google informa que Cliques para ligar em ações locais inclui chamadas de qualquer duração e difere de Chamadas a partir de anúncios. Essa diferença reforça a necessidade de usar o nome técnico de cada linha, sem criar um total genérico de “pacientes”.

Se a equipe decidir usar Rotas para lances, registre a data, a campanha e a justificativa. Compare o resultado apenas depois de uma janela adequada e não altere orçamento, meta e valor ao mesmo tempo. Essa sequência é uma recomendação operacional, não uma promessa de desempenho do Google.

Perguntas frequentes

Um clique orgânico em Rotas pode ser atribuído ao Google Ads?

Sim, quando houve uma interação anterior com o anúncio e a ação ocorreu dentro da janela de conversão aplicável. O Google documenta que o botão pode ser clicado no anúncio ou depois, em um resultado orgânico da empresa.

A janela de Rotas é sempre de 30 dias?

Trinta dias é a janela de cliques padrão informada pelo Google para ações locais. A configuração pode ser consultada e editada na página de metas. Registre a janela vigente no período analisado em vez de presumir o padrão.

Rotas confirma que a pessoa chegou à clínica?

Não. A ação registra o clique para obter instruções. As fontes não afirmam que a pessoa iniciou ou concluiu o trajeto, marcou consulta, compareceu ou gerou receita. Esses resultados exigem outras evidências.

Preciso instalar uma tag no site para criar essa meta?

O Google descreve a ação como meta hospedada e criada automaticamente após a configuração dos recursos de local e a primeira conversão relevante. Confira o vínculo dos locais e a ação na conta antes de procurar uma tag com esse nome.

Referências

Why Does Google Ads Show No Store Visit Conversions for My Clinic?

cmsapointoo on August 16, 2026

A clinic may see no Store visits conversion action in Google Ads even when patients regularly reach its physical location. Google makes this measurement available automatically only to eligible accounts. Eligibility depends on verified locations, active location assets, supported countries, sufficient ad and foot-traffic volume, and Google’s rules for sensitive locations.

For healthcare advertisers, the sensitive-location rule is especially important. Google states that locations related to certain health issues are ineligible for Store visits. More traffic or a different report column cannot override that restriction. Diagnose eligibility first, then decide which privacy-safe operational outcome the clinic can measure independently.

What does Google Ads mean by a Store visit conversion?

Store visits estimate how ad interactions influence later visits to physical locations. Google describes the reported numbers as modeled. It connects eligible ad engagement with later location activity in a privacy-safe process, then uses anonymous, aggregated statistics and extrapolation to represent a broader customer population.

This is different from a click on Directions. A Store visit represents Google’s modeled estimate of visits after eligible ad interactions. A Directions action records an interaction that helps someone find the location. Neither event identifies a patient, confirms a scheduled appointment, or records revenue from care.

The distinction matters in a clinic report. A modeled aggregate can help compare campaigns that influence physical traffic, but it cannot reconcile a reception roster. Conversely, the appointment ledger can count attended visits, but it should not send patient-level health details back to an ad platform.

Teams that need campaign-level attendance should use a separate privacy review and a bounded internal method. The guide to measuring clinic show rate without appointment details keeps operational outcomes separate from sensitive appointment data.

Which eligibility requirements should the clinic check?

Google lists several account and location requirements. The physical locations must be in a country where Store visits measurement is available. The account must use active location assets or affiliate location assets, and campaigns must be opted in to show them. Locations connected through a Business Profile must be set up and verified there.

The account also needs enough ad clicks or impressions and enough foot traffic to pass Google’s privacy thresholds. Google does not publish one universal number because the required volume varies by advertiser. A nearby clinic account with similar campaigns can qualify at a different time, so its status is not proof for another account.

Eligibility is assessed separately by network. Google says an account with multiple campaign types may report Store visits for one network but not another. At manager-account level, each child account still has to meet the requirements on its own. Manager reporting does not transfer eligibility to an ineligible clinic account.

Check the practical setup before assuming a privacy threshold is the only cause. Confirm that the intended Business Profile locations are verified, the link to Google Ads uses the right account, location assets are active, and the campaigns actually run those assets. The article on clinic location-targeting settings covers a different control and should not be used as evidence of Store visits eligibility.

Why can a healthcare location remain ineligible?

Google excludes locations it considers sensitive. Its examples include locations related to religion, sexual interests, children, and certain health issues. This is an eligibility boundary for Store visits, not a technical error the clinic can repair by changing a tag, increasing a bid, or requesting patient records.

The source does not define every healthcare category that Google will classify as sensitive. Do not infer that all clinics qualify or that all clinics fail. Read the account’s actual state and request platform support if the location seems eligible under the published criteria. Describe the business and setup without sending patient names, diagnoses, appointment records, or visit histories.

Editorial inference: a clinic should not rename, recategorize, or misrepresent a location to obtain Store visits reporting. Business Profile and ad assets should describe the real organization. A measurement feature is not worth introducing inaccurate public information or undermining a platform privacy control.

A Google Cloud healthcare agreement does not change this Ads rule. Google Ads and Google Cloud have separate product terms and data boundaries. See why a Google Cloud BAA does not cover Google Ads before treating an infrastructure contract as advertising permission.

Where should the team look for diagnostics?

If the account already has an active Store visits conversion action, open its Diagnostics page from the Goals summary. Google says this page reports current status, linked locations, campaigns running location assets, location verification, data thresholds, conversion-tracking setup, and whether a custom conversion value exists.

The Diagnostics page is unavailable when the account does not have the Store visits conversion action. That absence is itself a boundary. The team should review eligibility and contact its Google representative if it believes every requirement is met. Creating a website conversion with the same name will not create Google’s modeled Store visits measurement.

Capture diagnostics as account-level evidence. Record the review date, affected network, status, whether locations are linked, number of campaigns running location assets, percentage of verified locations, and whether the data-threshold check passes. Do not attach screenshots showing user lists, search terms tied to health concerns, customer uploads, or unrelated account secrets.

Apointoo can surface this eligibility state as a reporting note. It should not present “not eligible” as “zero visits,” because those statements mean different things. One describes unavailable measurement. The other claims a measured count of none.

Could Store visits exist but be missing from the report?

Yes. Google says Store visits are reported under All conversions by default. The standard Conversions column includes them when the Store visits goal is configured as an account-default goal. Store-visit-specific columns are not included in every report by default, so a column choice can hide existing data.

First look for the conversion action, then add the Store visits and All conversions columns at the campaign level. Check the same network and date range used in Diagnostics. Do not compare a manager total with one child account without confirming where conversion tracking is configured and how Google deduplicates visits across child accounts.

Google also says reporting can fluctuate or stop after customer-behavior changes or account-setup changes. Business Profile edits, location assets, conversion status, conversion window, and location targeting can affect results. Use the Diagnostics page to distinguish a setup issue from a seasonal change rather than explaining every drop as campaign performance.

Operational inference: annotate the date of any location-asset, Business Profile, conversion-goal, or tracking-account change in the clinic’s reporting ledger. The official sources list those settings as possible causes, but only a dated record can show which change preceded the local account’s reporting shift.

What should the clinic use when Store visits are unavailable?

Do not relabel Directions clicks, call clicks, website clicks, or booked appointments as Store visits. Each event answers a different question. Local actions can show engagement with a location. The scheduling system can show appointments. Reception or the EHR can show attendance under the clinic’s approved controls.

Build a small measurement ladder. Report ad delivery and clicks first. Report local actions with their platform definition. Report privacy-safe booking outcomes only where the clinic has a lawful and technically bounded path. Keep attended visits and revenue in the internal system unless a separately reviewed aggregation or conversion workflow allows a narrower signal.

When comparing acquisition channels, preserve marketing source independently from booking and attendance states. Appointment source and marketing source are not interchangeable, and neither becomes more accurate because Store visits reporting is missing.

For bidding, use only conversion actions whose meaning the team can defend. If a campaign optimizes toward calls or directions, label those actions exactly. Do not assign them an attended-visit value merely to fill an eligibility gap. A modeled feature’s absence is a measurement limitation, not permission to invent a substitute.

How should Store visits appear in a clinic report?

State the metric as “Google Ads modeled Store visits” and include the reporting window, eligible network, account, and source column. Add an eligibility note when the action is unavailable. Keep modeled visits separate from booked appointments, attended appointments, new patients, treatments, and revenue.

When Store visits are available, avoid patient-level reconciliation. The official method is aggregate and privacy centered. A mismatch between the modeled number and reception count does not reveal which person Google counted. It also does not prove either system is wrong, because the two measures have different definitions and attribution windows.

Use the metric for decisions that fit its scope, such as comparing eligible campaigns on modeled physical-visit influence. Use internal operational data for staffing, capacity, and care delivery. The framework for booking outcome definitions in Google Ads helps prevent one label from carrying several incompatible meanings.

Frequently asked questions

Can I manually enable Store visits for a clinic?

No manual tag creates this conversion action. Google says eligible accounts begin reporting automatically. If the action is absent, check country availability, location sensitivity, verified locations, active location assets, campaign use, and sufficient ad and foot-traffic volume.

Does no Store visits data mean nobody visited?

No. Missing data may mean the account is ineligible, has not passed privacy thresholds, lacks the correct setup, or is viewing the wrong columns. It is not a measured count of zero and should not be reported as one.

Can a Directions click replace a Store visit conversion?

No. Directions is a local engagement action, while Store visits is Google’s modeled estimate of physical visits after eligible ad interactions. A Directions click does not prove arrival, appointment completion, or revenue.

Should patient attendance records be uploaded to fix eligibility?

No. The published Store visits eligibility process does not instruct clinics to upload patient attendance or health information. Review the account and location requirements, use Diagnostics when available, and keep identifiable or sensitive care data out of Ads.

References

Why Did NexHealth v3 Accept an Appointment Outside Working Hours?

cmsapointoo on August 16, 2026

NexHealth v3 can accept an appointment outside a provider’s working hours because POST /appointments no longer performs the working-hours validation used by the legacy API. NexHealth’s migration guide says an out-of-hours booking can be accepted and written back to the EHR. A successful request therefore does not prove that the selected time appeared in the current bookable-slot response.

The safe boundary belongs in the booking flow. Check the requested provider, location, appointment type, operatory, duration, and start time against GET /available_slots before submission. After submission, monitor the appointment insertion result. Keep transport acceptance, EHR completion, and patient attendance as separate states.

What changed in NexHealth v3 appointment creation?

NexHealth documents a specific breaking change in v3.0.0, also published as v20240412. The legacy v2.2.2 endpoint rejected bookings outside a provider’s synced working hours. Version 3 does not run that check. Its migration guide says those bookings are accepted and written back to the EHR.

This change affects the meaning of a successful create response. The endpoint still accepts an appointment body and returns the documented success status, but the server no longer uses working hours as a rejection gate. A client that relied on a 400 response to stop invalid selections has lost that control after migration.

The new behavior does not make working hours irrelevant. NexHealth still uses them when calculating bookable times through GET /available_slots. The difference is where validation happens. The read endpoint computes eligible choices; the write endpoint accepts the selected appointment without repeating the old working-hours check.

That distinction also separates HG074 from the related problem of an empty NexHealth availability response. An empty result asks why no options were returned. An out-of-hours write asks why creation succeeded despite the configured boundary.

How should the selected time be validated before submission?

Validate the proposed start time against a fresh GET /available_slots response for the same booking context. NexHealth says this endpoint returns bookable slots for the requested locations and date range, computed from provider availabilities and existing appointments. It requires the institution subdomain, start date, number of days, and location IDs, plus provider IDs or an appointment type.

Match more than the displayed clock time. Confirm the returned location ID, provider ID, operatory ID when applicable, and local start and end time. Separately confirm that the request used the intended appointment type and its configured duration. A 10:00 slot for one provider or operatory does not authorize 10:00 for another.

Operational inference: perform the availability check as close as practical to the create request. The official documentation says to validate against /available_slots before booking, but it does not promise to reserve a slot between the read and write. A later appointment or calendar change can make an earlier response stale.

Do not solve this by copying clinical details into the request log. A sanitized record needs the API version, institution alias, location ID, provider ID, operatory ID, appointment type ID, requested time, response status, and correlation ID. It does not need a patient’s name, phone number, reason for visit, treatment notes, or insurance information.

Why is a successful API response not the final booking state?

NexHealth describes appointment creation as asynchronous. Its Appointments reference recommends subscribing to the appointment insertion webhook, which reports complete or failed when the integration inserts the appointment into the EHR. The initial create response and the downstream EHR result therefore answer different questions.

A practical state model has at least four values: selected from current availability, accepted by the API, completed in the EHR, and later attended or not attended. The first three are technical or operational events. Attendance belongs to the clinic’s later workflow. Collapsing them into one “booked” flag hides failures and inflates acquisition reporting.

Apointoo should preserve the returned appointment identifier and a non-sensitive correlation key, then update the operational state from the insertion webhook. It should not send the appointment type, notes, patient identity, or other health context to advertising platforms. The guide to clinic booking outcome taxonomy explains why internal outcomes and ad-platform payloads need different detail.

If the insertion fails, keep the error category and timestamp without storing the raw patient payload in general logs. Route the case to the approved operational queue. Do not tell the patient or reception team that the EHR booking exists until the integration has reported completion or the practice has verified it directly.

Can availability change between the check and the create request?

Yes, that is a reasonable operational risk even though NexHealth does not document a temporary reservation created by GET /available_slots. The endpoint computes bookable time from provider availability and existing appointments. Another booking or schedule update can occur after the response and before the create request.

Operational inference: treat each slot response as a current observation, not a lock. Keep the interval between selection and submission short. When the user returns to an old browser tab, changes provider, changes appointment type, or resumes after a long pause, request availability again instead of trusting cached options.

Do not retry a create request blindly after a timeout. First determine whether NexHealth accepted the original request and whether the insertion webhook later completed it. An automatic retry without an idempotency decision can create duplicate operational work or competing appointment records. The general process for preventing duplicate appointment reminders uses the same ownership principle: one event needs one authoritative state and one controlled retry path.

If the selected slot is no longer available, return the user to a new availability result. Do not silently move the appointment to a nearby time. A different time is a different choice and may require renewed confirmation from the person booking.

What evidence should a booking integration retain?

Retain enough evidence to reconstruct the technical decision without creating a shadow patient record. For the availability check, keep the request time, API version, sanitized booking scope, and the selected returned slot. For creation, keep the correlation ID, response code, returned appointment ID, and insertion status. Apply normal retention and access controls to this operational record.

Use structured fields rather than dumping full requests and responses. Full payloads may contain patient identity, contact details, notes, or other data that belongs in the approved scheduling system. Redaction after collection is weaker than never collecting the unnecessary field. Support screenshots should also use a sandbox or synthetic appointment.

Separate the booking system’s source from the marketing source. A successful NexHealth write should not replace the campaign or channel that originally influenced the request. The article on appointment source versus marketing source gives a durable model for that distinction.

For an escalation, provide the endpoint, sanitized parameters, API version, timestamps, correlation ID, expected slot, observed status, and webhook result. State whether the time appeared in the immediately preceding availability response. That packet helps an integration team diagnose the path without exposing patient information.

How should a team test the v3 booking boundary?

Use a sandbox when available. Otherwise, obtain clinic approval for a future synthetic window that cannot displace real care. Create no patient record with a real person’s identity. Keep the test outside advertising systems and remove synthetic records through the practice’s approved cleanup process.

  1. Send every request with the intended Nex-Api-Version header.
  2. Query /available_slots for one verified provider, location, appointment type, and date.
  3. Choose a returned slot and save only sanitized request evidence.
  4. Submit the appointment once and record its response and identifier.
  5. Wait for the insertion webhook and record complete or failed.
  6. Verify the synthetic appointment in the correct EHR calendar.
  7. Test an out-of-hours time only in a controlled environment where an accepted write cannot affect a real schedule.

The pass condition is precise: the interface offers only current returned slots, submission uses the same scope, and the system does not claim EHR completion before the webhook or direct verification. A separate test should confirm that rescheduling keeps the original acquisition lineage, as described in preserving booking source after a reschedule.

Frequently asked questions

Does NexHealth v3 reject appointments outside working hours?

No. NexHealth’s migration guide says v3 removed the working-hours validation performed by v2.2.2. Out-of-hours bookings can be accepted and written to the EHR. Validate the selected time against GET /available_slots before creating the appointment.

Does HTTP 201 mean the appointment reached the EHR?

Not by itself. NexHealth describes appointment creation as asynchronous and recommends the appointment insertion webhook. Treat the create response as API acceptance, then use the webhook’s complete or failed result to track EHR insertion.

Should the integration cache available slots?

NexHealth documents available slots as bookable times computed from availability and existing appointments, but it does not document a reservation created by reading them. If the booking context or time has changed, request current availability again. This refresh rule is an operational inference, not a vendor guarantee.

Can the booking event be sent to Google Ads?

Only a separately approved, privacy-safe conversion event should enter an advertising workflow. Do not send patient identity, appointment type, reason for visit, notes, or other health data. API acceptance also should not be labeled as attendance or revenue.

References

Does a Regional Healthcare Workload Keep Google Cloud Logs in the Same Region?

cmsapointoo on August 16, 2026

No. Deploying a healthcare workload in one Google Cloud region does not place its Cloud Logging data in that region. Workload placement, log-bucket location, sink destination, and saved-query location are separate controls. A regional application can therefore write logs to system buckets whose location does not match the application.

Cloud Logging creates _Default and _Required buckets for projects and other resource types. Without a preconfigured organization or folder default, Google documents these system buckets in the global location. Default settings can choose their storage location in new child resources, but they are prospective. They do not relocate buckets that already exist, and an existing log bucket’s location cannot be changed.

Workload location and log location are different facts

A service deployed in a named region has a workload-location fact. Cloud Logging stores log entries in log buckets, and each bucket has its own location. Google describes log buckets as regional resources because the infrastructure that stores, indexes, and searches those entries is located in a specific geographical location.

The source application does not confer its region on the destination bucket. The Log Router evaluates log entries and sends them according to sink definitions. It processes an entry in the region where it is received, may buffer it temporarily, and may route it to another region. Sharing log data with another service can also introduce another location decision.

The guide to single-region Pub/Sub message storage has a related service boundary. A region setting controls only what the product documentation assigns to it. Architecture records should name the resource, property, scope, and exceptions instead of saying that the whole project is regional.

What the two system buckets contain

Cloud Logging creates a _Required bucket and a _Default bucket for each project, billing account, folder, and organization. They have correspondingly named sinks. The two buckets serve different log classes and cannot be treated as interchangeable copies.

The _Required bucket receives logs that Google retains for compliance or auditing purposes, including Admin Activity and System Event audit logs. Its routing is constrained: redirecting the _Default sink does not redirect the _Required sink. The _Default bucket receives logs not automatically placed in _Required, including application logs and some audit-log categories depending on configuration.

A review that inspects only _Default can miss the location of required audit evidence. A review that inspects only _Required can miss application logs containing resource metadata or sensitive values. Inventory both buckets, their locations, included log classes, readers, retention, and downstream sinks.

Why default storage settings must come before project creation

Organizations and folders can define default Cloud Logging settings inherited by new child resources. A storage-location setting controls where new system-created _Default and _Required buckets are created. It can also control the location used for new and recent queries in Logs Explorer or Observability Analytics.

Google states that changed defaults apply only to resources created after configuration. Existing resources do not inherit the new location retroactively. If a team sets an organization default today, projects created yesterday keep their existing bucket locations. The console may show a desired organization setting while old projects retain a different reality.

The order of operations matters: approve the location, set the organization or folder default, verify inheritance, then create the project. Preserve the output that shows the effective settings and the bucket locations. A policy document without resource evidence cannot prove where existing logs are stored.

Existing buckets cannot be relocated

Cloud Logging fixes a bucket’s location at creation. Google says the location of an existing bucket cannot be changed. Updating a label, retention period, sink, or organization default does not turn that bucket into a bucket in another region.

For logs routed through _Default, a team can create a user-defined bucket in the approved location and update the _Default sink to send future matching entries there. That changes the future destination. It does not move entries already stored in the old bucket, and it does not change the separate _Required path.

A migration plan should therefore distinguish old records, future records, and required logs. Record the cutover time, test a synthetic log entry, query the intended bucket, and confirm that exclusions do not create a silent gap. The review of AWS CloudTrail multi-Region routing uses the same discipline on another provider: collection topology and destination location need their own evidence.

Redirecting _Default leaves _Required as a separate gate

Google’s regionalization guide shows how to create a bucket in a selected region and update the _Default sink. The guide also warns that the _Required sink cannot be changed in that existing setup. Required logs continue to their own system bucket.

A _Default redirect supports a narrow claim about the log classes it matches after cutover. It does not prove that all logs are regional. The evidence says nothing about excluded entries, logs already retained elsewhere, required audit logs, or copies sent to other destinations.

If _Required must start in a chosen location, use the documented organization or folder default before creating the child resource. For an existing project, assess the fixed bucket location and available architecture options rather than presenting a _Default redirect as a relocation.

Queries, connected services, and names can widen the boundary

Bucket storage is not the only location fact. Default settings can affect where Logs Explorer and Observability Analytics store new and recent queries. Google also warns that services which query log data may store query results in a global location. A regional bucket does not automatically regionalize every tool that reads from it.

Sinks can route entries to other projects or supported destinations. Security services can consume log data. Exports for archives or analysis introduce their own storage, access, key, and retention decisions. Each downstream path needs a location and contract review.

Google’s HIPAA guide advises customers to avoid putting protected health information or security credentials in resource metadata because metadata can appear in logs. Keep patient identifiers, conditions, appointment details, and treatment names out of resource names and free-form log messages. That advice reduces exposure, but it does not replace bucket controls or access review.

BAA coverage is not configuration validation

Google lists Cloud Logging among products covered by its Cloud BAA and says the agreement covers its infrastructure. The same guide describes HIPAA compliance as a shared responsibility. The customer remains responsible for deciding whether a BAA is required, accepting it where necessary, using covered services, and configuring and securing the application.

A BAA does not inspect bucket locations, sink filters, IAM roles, exported copies, log contents, or saved-query behavior. It also does not turn a regional design into a HIPAA requirement. Contract coverage and configuration evidence answer different questions.

The article on why a Google Cloud BAA does not cover Google Ads explains this product boundary. Even inside covered Google Cloud services, the customer must validate the actual path. Agreement scope is necessary where applicable, but it is not proof that the path meets the organization’s legal, contractual, security, and residency decisions.

A practical evidence checklist

  1. Record the workload’s region separately from every log bucket location.
  2. Describe effective Cloud Logging defaults at the organization and folder.
  3. List _Default, _Required, and user-defined buckets for each resource.
  4. Capture bucket locations from the service, not from the architecture diagram alone.
  5. Map every sink, filter, exclusion, destination, and cutover timestamp.
  6. Test future routing with synthetic log entries that contain no health information.
  7. Check saved-query location and any service that consumes or exports logs.
  8. Review IAM readers, retention, encryption decisions, and downstream copies.
  9. Keep BAA evidence separate from configuration and compliance approval.

State only what the evidence shows: named log classes generated after a recorded time were routed to a verified bucket location under the captured configuration. Do not upgrade that finding into “all project data stays in region.” That broader claim includes services and paths this logging review did not test.

Common failure modes during regionalization

One failure starts with timing: the default is configured after project creation, so the project keeps old bucket locations. Another changes _Default and forgets _Required. A third validates the bucket but ignores an export sink or globally stored query result.

Teams also confuse an empty regional bucket with successful routing. Send a synthetic event and verify it in the intended log view. Confirm that required logs remain accounted for and that no exclusion filter suppresses evidence needed for operations or investigation.

A regional logging decision also affects incident work. Responders need access to the approved buckets without copying entries into an unreviewed workspace. Preserve a tested query and escalation process. Region controls should survive an incident instead of being bypassed when evidence is needed quickly.

Frequently asked questions

If Cloud Run is regional, are its logs regional too?

Not by that fact alone. Cloud Run resource location and Cloud Logging bucket location are separate. Inspect the project’s system buckets, effective defaults, sinks, and downstream destinations.

Can changing the organization default move existing log buckets?

No. Google says changed default settings apply to resources created afterward, and existing bucket locations cannot be changed. The team must assess existing data and future-routing options separately.

Does redirecting _Default regionalize every audit log?

No. The _Required sink and bucket are separate. Redirecting _Default covers only future entries matched by that sink and does not relocate existing entries.

Does Google’s BAA make the logging design HIPAA compliant?

No. Google describes compliance as shared responsibility. BAA coverage is a contract fact; bucket locations, access, log contents, retention, exports, application controls, and the customer’s compliance assessment remain separate.

References

Pedido LGPD de acesso à agenda da clínica: a resposta vence imediatamente, em 15 ou em 30 dias?

cmsapointoo on August 16, 2026

Um pedido LGPD de acesso à agenda da clínica não tem um único prazo. Para o regime comum, confirmação de existência ou acesso em formato simplificado deve ser providenciado imediatamente. A declaração clara e completa, com origem dos dados, inexistência de registro, critérios utilizados e finalidade do tratamento, pode ser fornecida em até 15 dias.

Um agente de tratamento de pequeno porte que possa usar o regime diferenciado recebe outra janela: até 15 dias para a declaração simplificada e prazo dobrado para a declaração completa. Como o prazo comum completo é 15 dias, o resultado de 30 dias é aritmética derivada de 15 multiplicado por dois. Nem a LGPD nem a resolução dizem que toda clínica tem 30 dias.

O que “imediatamente” cobre

O artigo 19, I da LGPD trata da confirmação de existência ou do acesso em formato simplificado. Essa é a resposta que deve ser providenciada imediatamente no regime comum. Ela pode confirmar que há tratamento e entregar uma visão simples dos dados do titular, conforme o conteúdo efetivamente pedido e a capacidade de validar a identidade com segurança.

“Imediatamente” não ganha um número de horas no artigo 19. A clínica não deve inventar um limite oficial de 24, 48 ou 72 horas. Operacionalmente, pode definir uma meta interna mensurável, desde que essa meta ajude a cumprir a exigência e não seja apresentada como texto da lei.

Uma resposta automática dizendo apenas “recebemos seu contato” também não é necessariamente a confirmação ou o acesso solicitado. Ela prova recebimento. A equipe ainda precisa entender se o titular pediu confirmação, cópia simples, declaração completa, correção ou outro direito do artigo 18.

Quando vale o prazo de até 15 dias

O artigo 19, II prevê declaração clara e completa em até 15 dias, contados da data do requerimento. Essa declaração indica origem dos dados, eventual inexistência de registro, critérios utilizados e finalidade do tratamento, respeitados os segredos comercial e industrial. A página da ANPD sobre direitos dos titulares repete a divisão entre resposta imediata e informações completas em 15 dias.

O pedido pode alcançar identificação, contato, solicitações, horários, status e outros registros da agenda. O escopo depende dos dados que a clínica trata sobre o titular. Estar num sistema ou integração não os retira do mapa.

A resposta deve usar meio eletrônico seguro e idôneo ou forma impressa, conforme a opção prevista na lei. A clínica precisa evitar que o processo de acesso exponha dados a outra pessoa. Verificação de identidade, registro da entrega e limitação de permissões são controles operacionais. Eles não autorizam criar obstáculos desproporcionais ao exercício gratuito do direito.

Por que alguns agentes chegam a 15 e 30 dias

A Resolução CD/ANPD nº 2 concede prazos diferenciados a agentes de tratamento de pequeno porte elegíveis. Seu artigo 15 permite fornecer a declaração simplificada em até 15 dias desde o requerimento. O artigo 14 concede prazo em dobro para a declaração clara e completa prevista no artigo 19, II da LGPD.

O cálculo da forma completa é direto: duas vezes o prazo legal de 15 dias resulta em 30 dias. Esse número é uma inferência aritmética das duas normas. Deve ser rotulado assim em política, treinamento e conteúdo, em vez de atribuído a uma passagem que diga literalmente “30 dias”.

A extensão não pertence a toda empresa que se considera pequena. Receita, grupo econômico e tratamento de alto risco podem excluir o benefício. O teste de alto risco da resolução exige cumulativamente um critério geral e um específico. Dados de saúde cumprem um critério específico, mas ainda é necessário avaliar escala ou impacto significativo. A clínica deve registrar seu enquadramento antes de aplicar prazo diferenciado.

Clínica controladora e SaaS operador não respondem pelo mesmo papel

A LGPD define controlador como quem toma decisões referentes ao tratamento e operador como quem trata dados em nome do controlador. Numa configuração comum, a clínica decide finalidade, campos, retenção e atendimento do titular; a plataforma executa instruções e fornece recursos para localizar, exportar, corrigir ou eliminar dados. Os fatos podem atribuir papéis diferentes em outra atividade.

O titular pode apresentar requerimento a agente de tratamento, mas a clínica não deve presumir que encaminhar o email ao fornecedor transfere sua responsabilidade. O operador precisa responder com rapidez suficiente para que o controlador cumpra o prazo aplicável. O conteúdo sobre BAA, DPA e contrato de operador LGPD ajuda a alinhar contrato com essa divisão real.

O fluxo deve ter responsável, canal, identificação do tenant, busca restrita, revisão e entrega. O operador não deve pesquisar outras clínicas para completar uma resposta. A exportação fica limitada ao titular e ao controlador corretos, com logs de quem executou cada etapa.

Como separar confirmação, acesso e declaração completa

O primeiro passo é classificar o pedido pelo resultado solicitado. Confirmação responde se existe tratamento. Acesso simplificado fornece os dados de forma simples. Declaração completa acrescenta origem, critérios e finalidade. Correção, eliminação, bloqueio, portabilidade e informação sobre compartilhamento têm objetos próprios e podem exigir outro fluxo.

Não presuma que toda mensagem com a palavra “dados” exige a exportação máxima. Peça esclarecimento quando o objeto estiver realmente ambíguo, sem usar a pergunta para reiniciar artificialmente o relógio. Se a adoção imediata da providência for impossível, o artigo 18 exige resposta que indique que a organização não é o agente responsável ou apresente as razões de fato ou de direito que impedem a medida.

Uma matriz evita misturar saídas: tipo de direito, data de entrada, identidade validada, sistemas pesquisados, formato, prazo, responsável e evidência da entrega. Use dados sintéticos para testar o processo. O artigo sobre origem de agendamento e origem de marketing mostra por que sistemas podem guardar fatos relacionados sem terem a mesma finalidade.

Um fluxo operacional que não perde o prazo

  1. Registre a data e o canal de entrada sem copiar o pedido para ferramentas não aprovadas.
  2. Valide a identidade por método proporcional ao risco dos dados.
  3. Classifique o direito e confirme se a resposta pedida é simplificada ou completa.
  4. Identifique a clínica controladora, o tenant e os sistemas que tratam dados daquele titular.
  5. Confirme se existe enquadramento documentado para prazo de pequeno porte.
  6. Calcule a data interna sem apresentar a meta operacional como prazo legal diferente.
  7. Exporte somente registros pertencentes ao titular validado.
  8. Revise conteúdo, destinatário e meio antes da entrega.
  9. Registre resposta, data, escopo, responsável e falhas encontradas.

O sistema pode alertar antes do limite, mas a automação não decide sozinha se a extensão de pequeno porte se aplica. Também não deve enviar exportação sensível apenas porque alguém controlou o endereço de email. A revisão humana continua necessária onde identidade, escopo ou papel estejam em dúvida.

Pedidos que revelam falhas ou incidentes

Uma solicitação pode mostrar que dados estão associados à pessoa errada, que outra unidade consegue vê-los ou que uma integração manteve cópia inesperada. O atendimento do direito e a avaliação de segurança passam a correr em trilhas coordenadas. Um não deve ser encerrado apenas porque o outro foi aberto.

Se houver suspeita de incidente, preserve evidências e acione o processo apropriado. O guia sobre incidente com dados de saúde e comunicação à ANPD explica papéis e prazos desse fluxo. Não use a investigação como justificativa genérica para ignorar o pedido de acesso.

Dados de crianças ou adolescentes exigem cuidado com representante, identidade e melhor interesse. O conteúdo sobre agendamento pediátrico ajuda a mapear essa camada, sem produzir uma resposta universal para toda relação familiar.

Como comunicar o prazo sem criar uma promessa errada

A confirmação ao titular pode identificar o pedido, o canal seguro e a próxima etapa. Se a resposta for simplificada e o regime comum se aplicar, trate a obrigação imediata como tal. Se a pessoa pediu declaração completa, informe a data correspondente ao prazo de até 15 dias, sem sugerir que a clínica sempre consumirá todo o período.

Quando houver pequeno porte elegível, explique que a forma simplificada pode ser entregue em até 15 dias e que o prazo da declaração completa é dobrado pela resolução. Se mencionar 30 dias, diga expressamente que é resultado de duplicar os 15 dias do artigo 19. Registre a base do enquadramento para que suporte, privacidade e jurídico comuniquem a mesma regra.

Setores específicos, Poder Público, outras leis e fatos do caso podem alterar procedimento ou prazo. A política deve indicar essas fronteiras e exigir revisão qualificada quando o pedido sair do fluxo padrão.

Perguntas frequentes

Toda solicitação de acesso pode esperar 15 dias?

Não. No regime comum, confirmação ou acesso simplificado deve ser providenciado imediatamente. O prazo de até 15 dias se refere à declaração clara e completa descrita no artigo 19, II.

Onde a LGPD diz literalmente que uma clínica pequena tem 30 dias?

Ela não traz essa frase. Trinta dias é cálculo derivado: o artigo 19 fixa até 15 dias para a declaração completa e a Resolução nº 2 concede prazo em dobro ao agente de pequeno porte elegível.

O fornecedor da agenda pode responder diretamente ao paciente?

Depende dos papéis, das instruções e do canal aprovado. O operador deve apoiar o controlador e proteger o tenant correto. Ele não assume automaticamente a decisão jurídica da clínica por hospedar ou exportar os dados.

Um pedido de agenda é sempre igual a um pedido de prontuário?

Não. Este artigo trata do acesso a dados pessoais sob a LGPD no fluxo de agenda. Conteúdo, guarda e acesso a prontuário podem envolver outras normas e fatos, que precisam de análise própria.

Referências

Clínica pequena que trata dados de saúde precisa nomear encarregado pela LGPD?

cmsapointoo on August 16, 2026

Uma clínica pequena pode ficar dispensada de nomear encarregado pela LGPD, mas o número de funcionários ou o tamanho do consultório não decide isso sozinho. A dispensa da Resolução CD/ANPD nº 2 vale para quem se enquadra como agente de tratamento de pequeno porte e não cai nas exclusões do próprio regulamento. Mesmo quando a dispensa se aplica, a clínica precisa manter um canal de comunicação com titulares.

Tratar dados de saúde também não encerra a análise. Dados sensíveis são um critério específico de alto risco. Para o tratamento ser classificado como alto risco nesse regulamento, deve existir, cumulativamente, pelo menos um critério geral e um critério específico. Portanto, dado de saúde não retira automaticamente o regime diferenciado, mas pode retirá-lo quando aparece junto de larga escala ou de impacto significativo sobre interesses e direitos fundamentais.

A regra geral e a exceção para pequeno porte

O artigo 41 da LGPD estabelece que o controlador deve indicar encarregado pelo tratamento de dados pessoais. A lei permite que a ANPD defina hipóteses de dispensa conforme natureza, porte ou volume das operações. A Resolução CD/ANPD nº 2 usa essa competência para dar tratamento diferenciado a determinados agentes de pequeno porte.

O artigo 2º do regulamento inclui microempresas, empresas de pequeno porte, startups, pessoas jurídicas de direito privado, inclusive sem fins lucrativos, pessoas naturais e entes privados despersonalizados que assumem obrigações de controlador ou operador, desde que atendam às condições legais aplicáveis. O enquadramento empresarial precisa ser comprovável. Uma clínica com poucos profissionais não deve presumir que pertence à categoria apenas porque sua operação parece modesta.

Há também exclusões ligadas a receita e grupo econômico. Se a receita supera o limite referido pelo regulamento, ou se o grupo econômico ultrapassa esse limite globalmente, o tratamento diferenciado não se aplica. A decisão começa com documentos societários e financeiros, não com uma descrição informal do negócio.

O teste de alto risco tem duas partes cumulativas

O artigo 3º impede o uso do regime diferenciado quando o agente realiza tratamento de alto risco, salvo uma hipótese restrita de organização coletiva prevista no artigo 8º. O artigo 4º define alto risco por uma combinação: ao menos um critério geral e ao menos um critério específico. As duas partes são obrigatórias.

Os critérios gerais são tratamento em larga escala ou tratamento que possa afetar significativamente interesses e direitos fundamentais dos titulares. A resolução orienta a avaliação de larga escala pelo número significativo de titulares, pelo volume, pela duração, pela frequência e pela extensão geográfica. Impacto significativo pode existir quando o tratamento impede direitos ou uso de um serviço, ou pode causar danos materiais ou morais, discriminação, fraude, roubo de identidade ou outras consequências descritas no regulamento.

Entre os critérios específicos estão uso de tecnologia emergente, vigilância de zonas públicas, certas decisões exclusivamente automatizadas e uso de dados sensíveis ou de dados de crianças, adolescentes e idosos. Dado referente à saúde é dado pessoal sensível sob o artigo 5º da LGPD. Isso satisfaz o lado específico. Ainda é preciso testar o lado geral.

Como aplicar o teste a uma clínica sem automatizar a conclusão

Uma agenda que recebe nome, contato, horário e uma informação sobre o serviço procurado pode tratar dado de saúde, dependendo do que o conjunto revela. O conteúdo sobre legítimo interesse e dados de saúde no formulário explica por que campo e finalidade precisam ser avaliados separadamente.

Depois de identificar dados sensíveis, a clínica deve medir o critério geral com fatos. Quantas pessoas estão incluídas? Qual volume fica retido? O tratamento é contínuo ou ocasional? Abrange uma unidade local ou uma rede? Uma falha poderia impedir atendimento, expor condição de saúde ou produzir discriminação? Essas perguntas ajudam a aplicar os fatores do regulamento sem transformar um único número em regra universal.

Dois consultórios com a mesma receita podem chegar a resultados diferentes. Um pode manter uma agenda limitada e com pouca retenção. Outro pode integrar várias unidades, perfis sensíveis, automações decisórias e histórico amplo. A análise pertence a cada operação de tratamento. O porte da empresa não apaga a natureza, escala ou consequência do fluxo.

Dispensa de encarregado não significa ausência de contato

O artigo 11 da Resolução nº 2 dispensa os agentes de pequeno porte elegíveis de indicar encarregado. O parágrafo seguinte impõe uma condição operacional: quem não indicar encarregado deve disponibilizar canal de comunicação com o titular para cumprir a função de aceitar reclamações e comunicações, prestar esclarecimentos e adotar providências.

Esse canal precisa existir na prática. A clínica deve publicar um meio acessível, atribuir responsabilidade interna, registrar solicitações e impedir que mensagens fiquem esquecidas numa caixa sem acompanhamento. A lei não exige que o nome público do canal seja “encarregado” quando a dispensa é válida. Também não basta publicar um endereço que ninguém monitora.

Nomear voluntariamente um encarregado continua possível. A resolução considera isso uma política de boas práticas e governança. A escolha pode fazer sentido quando há muitos fornecedores, contratos empresariais, solicitações frequentes ou necessidade de coordenação. Ela não substitui a análise de enquadramento nem transforma uma pessoa em garantia de conformidade.

Quais obrigações permanecem mesmo com a dispensa?

O artigo 6º da resolução afirma que flexibilizações não isentam o agente dos demais dispositivos da LGPD, de outras normas aplicáveis nem de obrigações contratuais. A clínica ainda precisa definir hipóteses legais, respeitar finalidade e necessidade, atender direitos e proteger os dados. O artigo sobre BAA, DPA e contrato de operador LGPD mostra por que documento e papel real precisam continuar alinhados.

O regulamento também exige medidas administrativas e técnicas essenciais, considerando risco e realidade do agente. Uma política de segurança pode ser simplificada, mas deve proteger contra acesso não autorizado, perda, destruição, alteração ou tratamento inadequado. Simplificada descreve a forma do documento. Não reduz o dever de enfrentar riscos previsíveis do fluxo.

As regras sobre base legal de dados sensíveis continuam separadas. A eventual dispensa de encarregado não autoriza coleta excessiva, reaproveitamento para marketing ou acesso amplo. Para dados pediátricos, a análise ainda deve considerar o melhor interesse e as regras aplicáveis, como detalha o guia sobre agendamento pediátrico, LGPD e ECA Digital.

Que evidência sustenta a decisão?

A clínica deve conseguir reconstruir por que aplicou ou rejeitou a dispensa. Um registro curto pode reunir categoria empresarial, receita considerada, composição do grupo econômico, operações avaliadas, volume, frequência, extensão, categorias de titulares e possíveis impactos. Para cada operação com dado sensível, registre qual critério específico existe e se algum critério geral também foi satisfeito.

Guarde a versão do regulamento usada, a data da revisão, o responsável pela decisão e o canal publicado para titulares. Não inclua dados reais de pacientes nessa evidência. Use inventários, contagens agregadas e fluxos sintéticos. A documentação precisa demonstrar a análise sem criar uma nova base sensível.

A ANPD pode pedir comprovação do enquadramento e pode determinar o cumprimento de obrigações dispensadas ou flexibilizadas conforme natureza, volume e risco. Por isso, a conclusão deve ser revisável, não uma declaração permanente feita na abertura da empresa.

Como dividir responsabilidades entre clínica e plataforma

A clínica costuma decidir as finalidades e os campos de seu agendamento, enquanto a plataforma pode executar tratamento conforme instruções. Esses papéis dependem das atividades reais. O fornecedor não deve declarar que toda clínica está dispensada, pois não conhece sozinho receita, grupo econômico, escala, impacto e outras operações do cliente.

A plataforma pode oferecer canal configurável, exportação de solicitações, permissões, registros de acesso e documentação dos subprocessadores. A clínica conserva a decisão jurídica sobre seu enquadramento. Se ocorrer incidente, os papéis e o fluxo de comunicação precisam estar definidos antes da crise; o artigo sobre incidentes com dados de saúde trata dessa divisão.

Contrato, interface e processo interno devem contar a mesma história. Se o aviso público indica um canal, o suporte precisa saber encaminhar a solicitação. Se a clínica nomeia encarregado voluntariamente, seus dados de contato precisam permanecer atuais. Se usa a dispensa, alguém ainda deve responder pelo funcionamento do canal.

Quando revisar o enquadramento

Revise a análise quando houver crescimento relevante, entrada num grupo econômico, nova unidade, mudança de fornecedor, retenção maior, integração de bases, automação decisória ou inclusão de novos grupos vulneráveis. A revisão também é necessária quando a ANPD altera normas ou quando o fluxo real deixa de coincidir com o inventário.

Uma verificação anual pode ser suficiente para uma operação estável, mas não substitui revisão orientada por mudança. O gatilho deve acompanhar fatos que alterem porte ou risco. Até a conclusão da nova análise, evite ampliar coleta e acesso com base numa dispensa antiga.

Perguntas frequentes

Todo consultório individual está dispensado de encarregado?

Não automaticamente. É preciso confirmar o enquadramento como agente de pequeno porte e verificar as exclusões de receita, grupo econômico e tratamento de alto risco. A forma individual da atividade é um dado da análise, não a conclusão completa.

Tratar dados de saúde sempre torna a operação de alto risco?

Não para fins da Resolução nº 2. Dados de saúde cumprem um critério específico. O teste de alto risco também exige, cumulativamente, larga escala ou possibilidade de impacto significativo sobre interesses e direitos fundamentais.

A clínica dispensada pode deixar de publicar contato de privacidade?

Não. O artigo 11 exige canal de comunicação com o titular quando o agente elegível não indica encarregado. O canal deve permitir que reclamações, comunicações e pedidos recebam tratamento efetivo.

Nomear encarregado voluntariamente prova conformidade com a LGPD?

Não. A resolução trata a nomeação voluntária como boa prática, mas bases legais, segurança, direitos, contratos e controles continuam separados. A conformidade depende das operações reais e das regras aplicáveis a cada uma.

Referências

Por que um horário bloqueado no Feegow ainda aceita encaixe?

cmsapointoo on August 16, 2026

Um horário bloqueado no Feegow ainda pode aceitar encaixe porque o sistema trata o encaixe como um fluxo separado do agendamento padrão. A documentação do fornecedor diz expressamente que é possível encaixar em horário bloqueado. Para impedir também esse tipo de marcação, a clínica precisa ativar a configuração BLOQUEAR ENCAIXE EM HORÁRIOS BLOQUEADOS.

O bloqueio, sozinho, impede a seleção normal dos horários indicados. Ele não equivale a uma proibição universal de qualquer ação administrativa na agenda. Essa diferença explica por que a recepção pode ver a faixa bloqueada e, ainda assim, conseguir salvar um encaixe. O diagnóstico deve confirmar qual botão foi usado, qual regra está ativa e qual profissional e unidade receberam o bloqueio.

Por que o bloqueio não impede o encaixe automaticamente?

O guia de bloqueios informa duas regras que parecem contraditórias quando lidas fora de contexto. Depois de salvar o bloqueio, os horários indicados deixam de ser selecionáveis para agendamentos. O mesmo guia acrescenta que ainda é possível encaixar em horário bloqueado. A primeira regra descreve a seleção normal; a segunda preserva o fluxo administrativo de encaixe.

O guia de agendamento define encaixe como uma marcação fora dos horários padrões da grade. Nesse fluxo, o usuário informa o horário manualmente. O exemplo do fornecedor mostra que o encaixe pode ficar dentro do período de atendimento, mas fora dos intervalos normais, ou até fora da grade. Por isso, a cor de bloqueio na agenda não encerra sozinha todas as possibilidades administrativas.

Essa é uma fronteira documentada do produto, não prova de erro de permissão ou defeito da agenda. Inferência operacional: antes de alterar qualquer regra, confirme se o registro veio do horário normal, de Encaixe ou de outra integração. O caminho usado determina qual controle deve ser verificado.

Qual configuração impede encaixe em horário bloqueado?

O Feegow orienta ativar BLOQUEAR ENCAIXE EM HORÁRIOS BLOQUEADOS quando a clínica não quer nenhum tipo de agendamento nessas faixas. O caminho publicado é Configurações > outras Configurações > Outras Configurações. A grafia repetida faz parte da rota descrita no artigo de ajuda.

Ative a regra de forma controlada e registre o estado anterior. A documentação citada não informa efeitos retroativos sobre encaixes já salvos, não descreve aprovação por perfil e não promete como outras integrações interpretarão o bloqueio. Portanto, não use a ativação como motivo para apagar, mover ou cancelar registros existentes sem uma revisão separada.

Inferência operacional: após salvar, abra a tela novamente e confirme o estado persistido. Em seguida, teste uma data futura sem pacientes reais. O encaixe deve deixar de salvar dentro da faixa bloqueada. Se a interface apresentar outra mensagem, capture o texto exato sem dados identificáveis.

A regra também não substitui os controles de disponibilidade por convênio. Se a clínica usa blocos separados para diferentes operadoras, preserve a estrutura descrita em horários exclusivos por convênio no Feegow. Um bloqueio geral e uma grade restrita respondem a necessidades distintas.

Como confirmar que o bloqueio foi criado na agenda correta?

O Feegow permite criar bloqueios nas agendas diária, semanal, múltipla e de equipamentos alocados. O usuário escolhe o profissional ou equipamento, a data e o comando de bloqueio. Quando o profissional está ligado a mais de uma unidade, o guia exige selecionar a unidade vinculada na grade. Um bloqueio na unidade errada não prova que a regra de encaixe falhou.

A agenda múltipla permite aplicar o bloqueio a mais de um profissional e unidade. Ela é útil quando a clínica inteira não abrirá, mas amplia o alcance da alteração. Liste previamente os profissionais, unidades, data, início, fim e motivo operacional. Depois de salvar, confira cada agenda que deveria receber a faixa, em vez de presumir que uma tela representa todas.

Também é possível iniciar o bloqueio a partir de um horário livre. Nesse caminho, início e fim vêm preenchidos. Confira ambos. Um intervalo curto demais pode deixar parte da grade disponível; um intervalo amplo demais pode retirar capacidade que a clínica pretendia manter.

Bloqueios de feriado têm outra fronteira quando existe agenda externa. O guia sobre bloqueio de feriado no Feegow e disponibilidade na Doctoralia explica por que o fechamento interno não deve ser tomado como prova de que uma agenda integrada também foi atualizada.

Como distinguir agendamento padrão, encaixe e repetição?

No agendamento padrão, o usuário escolhe um horário livre na grade do profissional. No encaixe, seleciona a data, clica em Encaixe e informa o horário. O Feegow também oferece a opção Repetir a partir de um agendamento existente. Esses caminhos podem parecer semelhantes no resultado final, mas não passam pela mesma seleção inicial.

Abra o registro de teste e confirme o indicador de encaixe quando a interface o apresentar. O guia informa que a caixa de encaixe fica marcada nesse fluxo. Registre também data, profissional, unidade, horário do bloqueio e usuário de teste. Não copie nome, telefone, documento, procedimento ou observação de uma pessoa real para demonstrar o problema.

Se o encaixe não puder ser salvo, o artigo de agendamento orienta verificar o limite de encaixes na grade do profissional. Essa é outra regra, diferente da proibição em horários bloqueados. Um limite atingido pode produzir a conclusão correta de que o encaixe falhou, mas não comprova que BLOQUEAR ENCAIXE EM HORÁRIOS BLOQUEADOS foi aplicado.

Da mesma forma, uma remarcação não deve apagar a origem inicial do registro. Consulte como preservar a origem após uma remarcação e guarde a ação administrativa mais recente em campo separado.

Como executar um teste seguro após ativar a regra?

O teste deve verificar primeiro o bloqueio e depois o encaixe, na mesma agenda e faixa. Escolha uma data futura autorizada pela clínica, sem atendimento real no intervalo. Use um cadastro sintético aprovado ou pare antes de salvar se a política interna não permitir registros de teste. O objetivo é provar a regra sem afetar pacientes ou capacidade legítima.

  1. Registre o profissional, a unidade, a data e o intervalo escolhidos.
  2. Crie o bloqueio e confirme que a faixa aparece bloqueada.
  3. Verifique que o agendamento padrão não permite selecionar o horário.
  4. Antes da ativação, documente se o fluxo de encaixe aceita a faixa.
  5. Ative BLOQUEAR ENCAIXE EM HORÁRIOS BLOQUEADOS.
  6. Repita o mesmo encaixe e registre o resultado apresentado.
  7. Remova apenas os dados sintéticos pelo processo aprovado.

Altere uma variável por vez. Não mude grade, unidade, duração, profissional e configuração no mesmo teste. Se o resultado continuar diferente do esperado, guarde captura da faixa, estado da configuração, horário do teste e sequência de ações. O suporte consegue analisar melhor um caso reproduzível do que uma descrição genérica de que a agenda “continua aberta”.

O bloqueio interno também fecha horários na Doctoralia?

Não use este procedimento para concluir que uma integração externa removeu disponibilidade. Os dois artigos citados do Feegow estabelecem como bloqueio e encaixe funcionam dentro do sistema. Eles não garantem propagação para a Doctoralia nem descrevem todos os caminhos pelos quais um horário externo pode ter sido criado.

Depois de validar o comportamento interno, abra a agenda externa e compare profissional, unidade, serviço, data e hora. Se houver disponibilidade manual criada fora da integração, siga o processo para identificar horários manuais na Doctoralia. Não desative uma vaga externa até confirmar sua origem e seu alcance.

Inferência operacional: mantenha duas evidências separadas. A primeira mostra que o Feegow impediu o encaixe administrativo. A segunda mostra o que foi publicado no canal externo. Um resultado correto no primeiro teste não substitui o segundo.

Que procedimento a recepção deve registrar?

O procedimento deve dizer quando usar bloqueio, quando um encaixe é permitido e quem aprova uma exceção. Inclua a rota exata da configuração, o profissional e a unidade que devem ser conferidos, o teste posterior e o caminho de escalonamento. Não transforme uma escolha local de governança em recurso garantido pelo fornecedor.

Registre cada exceção com dados mínimos: data, faixa, motivo operacional, aprovador e ação executada. Evite detalhes clínicos no log de agenda. Se uma vaga for liberada depois de cancelamento, trate a recuperação de capacidade como outro processo. O guia sobre lembretes e lista de espera ajuda a separar prevenção de conflito e preenchimento de vagas.

Revise o procedimento quando o Feegow mudar telas, nomes de configuração ou regras de agenda. A documentação consultada foi modificada em maio e junho de 2025, e o registro editorial exige nova revisão em setembro de 2026. Até lá, qualquer diferença reproduzível deve ser comparada com a documentação atual antes de virar regra permanente.

Perguntas frequentes

O bloqueio comum impede agendamento padrão?

Sim. O Feegow informa que, após salvar o bloqueio, os horários indicados deixam de ser selecionáveis para agendamentos. A mesma documentação ressalva que o encaixe continua possível, salvo quando a configuração específica para bloquear encaixes em horários bloqueados estiver ativa.

Onde ativo o bloqueio de encaixe em horário bloqueado?

O caminho documentado é Configurações > outras Configurações > Outras Configurações. Nesse local, ative BLOQUEAR ENCAIXE EM HORÁRIOS BLOQUEADOS, salve e faça um teste sintético na mesma agenda, unidade, data e faixa.

Um encaixe pode ficar fora da grade do profissional?

Sim. O guia do Feegow define encaixe como agendamento fora dos horários padrões e permite informar um horário manual, inclusive fora da grade. A clínica ainda pode ter um limite de encaixes configurado para o profissional, que deve ser verificado quando o salvamento falhar.

Ativar a regra cancela encaixes que já existem?

Os dois artigos citados não afirmam que a configuração cancela registros anteriores. Trate a regra como controle para novos testes e confirme qualquer efeito retroativo com a documentação atual ou com o suporte. Não cancele nem mova um agendamento existente sem revisão operacional.

Referências