Why a Zocdoc Timeslot Update Must Send the Complete Provider Day

cmsapointoo on August 16, 2026

A Zocdoc timeslot update is a full replacement for one provider and date. The documented PUT /v1/providers/{provider_id}/calendar/timeslots operation does not append the submitted slots to existing availability. Each request must contain every open timeslot that should remain published for that provider-day.

Any existing slot omitted from a later request is removed from that date. An empty timeslots array removes all slots for the provider-day. Build one complete, validated snapshot before sending the request. Use a valid IANA time-zone identifier for every slot, respect the documented 1,500-item limit, and retry HTTP 429 responses with exponential backoff.

What does the Zocdoc timeslot PUT replace?

The Create Timeslots guide says the endpoint sets all slots for a given provider and date, replacing any existing slots. The provider_id is in the path and the date is supplied as the date query parameter. Together they define the availability slice replaced by that request.

This contract is different from an event stream or an append operation. Sending one newly opened 2:00 PM slot does not mean “add 2:00 PM.” It means “the complete open set for this provider and date is the array in this request.” If 9:00 AM existed before and is absent now, the new snapshot no longer contains it.

Keep this availability operation separate from appointment-type translation. The guide to mapping Zocdoc visit reasons to EHR appointment types covers destination codes and durations. It does not change the provider-day replacement boundary.

Why must the request contain the complete provider day?

Zocdoc explicitly instructs developers to include all open timeslots in the array for each date and request. Subsequent requests for one date override the previous data. The safe unit of publication is therefore the complete current provider-day, built from the scheduling source that owns availability.

Start with a consistent source snapshot. Select one provider and local date, apply the clinic’s approved availability rules, remove occupied or blocked times, and then serialize every slot that should remain open. Do not create independent requests from separate departments or appointment categories unless one process merges them before the PUT.

A single writer is operational guidance, not a Zocdoc requirement stated in these sources. It follows from replacement semantics: two writers can each submit a valid but incomplete view and the later one will replace the earlier result. If multiple systems contribute availability, combine their approved output before publishing.

What happens to omitted slots and empty arrays?

An omitted existing slot disappears when the new full-day array replaces the old one. An empty timeslots array removes every slot for that provider and date. Those behaviors are useful when availability closes, but dangerous when a partial calculation is mistaken for a patch.

Request body Resulting provider-day
All current open slots Exactly those slots remain published
Only one newly opened slot That slot replaces the earlier set
Earlier set minus one closed slot The omitted slot is removed and the rest remain
Empty timeslots array All slots for the date are removed

Treat an empty result as a deliberate state. Require the upstream schedule calculation to complete successfully before it can publish zero slots. If the source read failed, the request should stop rather than convert an unknown day into a closed day. This is a recommended data-loss guard based on the documented empty-array behavior.

How should you build the replacement payload?

Build the array from a provider-day snapshot, then validate every item before the request. The documented timeslot object includes provider_id, location_id, start_time, time_zone, and patient_type. It can also include allowed and excluded visit-reason IDs.

  1. Resolve the provider and target local date.
  2. Read the complete current availability from its approved source.
  3. Apply location, patient-type, and visit-reason eligibility.
  4. Validate identifiers, local start times, and IANA zones.
  5. Reject accidental empty output or an array above the documented limit.
  6. Send one complete replacement request for the provider-day.

Do not let marketing attribution decide which slots exist. The distinction between appointment source and marketing source protects scheduling facts from campaign fields. Availability should come from the approved calendar logic, while attribution remains downstream context.

How do local start times and IANA zones work together?

The guide defines start_time as the local date and time within the supplied zone. It requires time_zone to be a valid IANA time-zone identifier, with America/New_York shown as an example. Seconds may be omitted from the local date-time value.

Send the actual IANA zone for the appointment location or approved scheduling context. Do not send a display abbreviation such as EST, and do not attach a browser’s current zone without confirming that it is the scheduling zone. The source requires a valid IANA identifier; the clinic still owns the rule that selects the correct one.

Test dates around local clock changes when a zone observes them. The mapped documentation does not specify a daylight-saving test procedure, so this is an integration acceptance recommendation. Confirm that the local time intended by the clinic appears on the expected provider date after serialization.

How should the 1,500-timeslot limit be handled?

Zocdoc documents the timeslots array as containing from zero through 1,500 items. Validate the final array length before sending it. A count above 1,500 is not a reason to send the day in independent partial PUT requests because each later request would replace the earlier one.

If one provider-day calculation exceeds the limit, stop publication for that slice and review the slot-generation rules. Check for duplicates, unexpectedly small increments, repeated locations, or an expanded input window. Do not truncate the array silently. Truncation would publish an incomplete day while presenting the request as successful.

The source set does not document a chunking method that preserves more than 1,500 slots for one provider-date. Escalate that requirement to Zocdoc rather than inventing one. Record the provider, date, generated count, and rule version without patient information.

How should HTTP 429 responses be retried?

Zocdoc’s Performance guide says rate-limited requests fail with HTTP status 429 and developers should use exponential backoff. Pause according to a bounded backoff policy, then retry the validated full-day request. Do not react to a rate limit by splitting the provider-day into partial replacement calls.

Keep the payload associated with the attempt. If the scheduling source changes before the retry, choose one clear policy: retry the same validated snapshot or rebuild a new complete snapshot and treat it as a new publication. Never merge fragments from two calculation times. The exact policy is local implementation guidance, not a vendor guarantee.

Track provider, date, attempt number, response status, payload count, and a non-sensitive snapshot identifier. Avoid logging patient details. When a retry eventually succeeds, the log should show which complete snapshot was published and which earlier attempt received the 429.

What tests prove replacement behavior safely?

Use Zocdoc’s sandbox environment and tokens that match that environment, as described in the API FAQ. Start with a provider-day containing three synthetic slots. Send a second array with two of them and confirm the omitted slot no longer appears. Then restore the three-slot set before testing an empty array.

Cover failure cases without touching live availability:

  • A partial array must be recognized as a complete replacement.
  • An empty array must require an intentional closed-day state.
  • An invalid or missing IANA zone must fail local validation.
  • An array above 1,500 items must stop before the request.
  • A simulated 429 must trigger backoff and a full-payload retry.

After appointment actions, keep historical reporting separate from current availability. The guide on preserving original booking source after rescheduling explains why a changed appointment should not rewrite acquisition history.

How do you monitor a full-day publication?

Measure the replacement unit, not individual additions. For each attempt, record the provider, date, expected slot count, payload count, source-snapshot identifier, response status, and completion time. Alert when the expected count changes sharply, the payload becomes unexpectedly empty, validation rejects a zone, or retries exhaust their limit.

A response alone does not prove the input represented the clinic’s intended schedule. Reconcile a sample of provider-days against the scheduling source after changes to slot generation, location rules, patient types, or visit-reason restrictions. Keep that reconciliation free of patient records because the timeslot payload describes open availability.

If the practice is evaluating another scheduling product, do not reduce the comparison to endpoint names. The article on Zocdoc alternatives for practices with existing demand separates marketplace acquisition from owned scheduling. Replacement behavior is one integration acceptance criterion within that broader decision.

Frequently Asked Questions

Can I send only the slot that changed?

No. The PUT replaces all slots for the provider and date. Include every open slot that should remain after the update.

What does an empty timeslots array do?

It removes all slots for the specified provider-day. Treat empty output as an intentional closed-day instruction, not a fallback after a failed source read.

Can I split more than 1,500 slots into several PUT requests?

The mapped documentation does not define chunking for one provider-date. Later requests override earlier data, so partial PUTs would not safely combine. Stop and confirm the requirement with Zocdoc.

What should happen after a 429 response?

Use exponential backoff, then retry a complete validated provider-day payload. Do not convert the retry into smaller replacement fragments.

References

Notificações da Doctoralia desativadas, mas o paciente remarcado ainda recebe mensagens: o que verificar?

cmsapointoo on August 16, 2026

Desativar as notificações de confirmação da Doctoralia não impede sozinho toda mensagem associada a uma remarcação. A documentação Feegow e Doctoralia orienta verificar também a opção separada Notificar paciente. Se ela permanecer ativa durante a ação, o sistema continua enviando a mensagem automaticamente.

Há ainda uma diferença entre impedir notificações futuras e inativar mensagens já programadas. A configuração de notificações permite escolher o alcance da desativação por local integrado. Para saber se uma mensagem específica saiu, a verificação disponível é individual no histórico de eventos da consulta. A documentação informa que não existe relatório automático consolidado com todos os envios.

Por que a mensagem continua depois da remarcação?

A causa documentada é a opção Notificar paciente ainda ativa. O guia de dúvidas descreve exatamente o caso em que as notificações de confirmação estão inativas, mas pacientes remarcados continuam recebendo mensagens. Desligar uma categoria programada não altera automaticamente esse controle ligado à ação de remarcação.

Comece pela consulta afetada e pelo momento em que ela foi alterada. Confirme se a mensagem ocorreu após uma remarcação e se a opção estava marcada. Evite concluir que existe um segundo remetente antes de revisar esse caminho. A documentação fornece uma explicação direta dentro do próprio fluxo Doctoralia.

Se a clínica também usa lembretes do EHR ou de outra plataforma, investigue cada remetente separadamente. A comparação entre alternativas de agenda e lembretes ajuda a listar os canais, mas não substitui a checagem da opção Notificar paciente.

Quais controles de notificação ficam na configuração geral?

No Feegow Clinic, o usuário Master acessa o perfil, entra em Doctoralia e abre Notificações. A página lista categorias como confirmação de consulta, lembrete, permissão para confirmar presença, solicitação de opinião e convite para novo agendamento. Cada categoria pode ser configurada para os locais integrados.

O artigo informa que desmarcar o local desativa o envio daquela configuração. Ao inativar, a interface permite interromper as próximas notificações ou incluir também as que já estão programadas. Essa escolha de alcance importa quando uma consulta já tinha mensagens agendadas antes da mudança.

Registre categoria, local e opção escolhida. A frase “desativamos as mensagens” é insuficiente porque não mostra qual categoria mudou nem se os envios já programados foram incluídos. Não suponha que uma alteração aplicada em um local cobre todas as unidades integradas.

Onde entra a opção Notificar paciente?

Notificar paciente é o controle separado destacado para a remarcação. Mesmo com notificações de confirmação inativas, essa opção precisa estar desligada quando a clínica não pretende enviar a mensagem da ação. Se permanecer ativa, o sistema continuará o envio automático descrito pelo fornecedor.

Trate essa opção como parte do procedimento da recepção. Antes de concluir uma remarcação, a pessoa responsável verifica se o paciente deve ser notificado naquele caso. A decisão sobre comunicar ou não pertence à clínica, enquanto o comportamento da opção vem da documentação do sistema.

Não troque remarcação por simples alteração de status para evitar mensagem. A página publicada sobre horários manuais fora da integração registra que o fluxo integrado exige o botão de remarcar, pois alterar apenas o status não reflete na integração. Resolva a notificação no controle correto.

Quem pode alterar essas configurações?

O guia de gerenciamento afirma que apenas o usuário Master pode configurar notificações da Doctoralia pelo Feegow Clinic. Isso limita a alteração geral, mas não elimina a necessidade de orientar quem executa a remarcação. Uma pessoa pode não ter permissão para mudar categorias e ainda assim operar o fluxo onde aparece Notificar paciente.

Defina um responsável Master por revisar categorias, locais e alcance da desativação. Defina também o procedimento da recepção para cada remarcação. Essas responsabilidades não devem ser confundidas. O Master cuida da configuração persistente; o operador confirma a escolha aplicada à ação concreta.

Se a opção esperada não aparece para um usuário, registre o perfil de acesso e peça revisão ao responsável. Não compartilhe credenciais para contornar permissões. As fontes mapeadas descrevem a restrição a Master, mas não autorizam ampliar acesso nem fornecem uma matriz completa de funções.

Como verificar se uma mensagem foi enviada?

A auditoria documentada fica nos detalhes da consulta. No acesso do profissional, abra o calendário, localize a data, selecione o paciente, abra o menu de três pontos e escolha Ver histórico de eventos. O histórico mostra se e quando notificações, confirmações e lembretes foram enviados.

No perfil da clínica Premium, o caminho é semelhante, mas a agenda aparece em formato múltiplo com os profissionais da clínica. Localize o profissional e a consulta antes de abrir o histórico. Em ambos os casos, a verificação está ligada a uma consulta específica.

Registre somente o necessário para resolver o incidente: identificador interno permitido, data da consulta, categoria de mensagem, horário do evento e configuração revisada. Evite copiar conteúdo clínico para uma planilha de suporte. Para separar comunicação de comparecimento, veja lembretes versus lista de espera.

O que significa não existir relatório consolidado?

A documentação informa que não há relatório automático com a relação completa das notificações enviadas. A verificação deve ser manual e individual, paciente por paciente. Portanto, uma busca em uma única consulta pode confirmar aquele envio, mas não demonstra que nenhuma outra mensagem saiu no mesmo período.

Delimite a auditoria antes de começar. Liste as consultas remarcadas no intervalo relevante pelos meios permitidos pela clínica e revise o histórico de cada uma. Marque quais casos tinham mensagem, qual controle estava ativo e qual ação corretiva foi tomada. Não apresente uma amostra como se fosse cobertura total.

Essa limitação também muda a linguagem do resultado. Diga “as consultas revisadas não mostram novos envios” em vez de “nenhum paciente recebeu mensagem” quando a equipe não verificou toda a população. A evidência disponível deve definir o alcance da conclusão.

Como testar a correção sem envolver pacientes reais?

Use uma consulta sintética aprovada para o local integrado. Registre o estado inicial das categorias, incluindo se as mensagens já programadas foram inativadas. Execute uma remarcação com Notificar paciente desativado e depois abra o histórico de eventos. O resultado esperado é não encontrar o envio que essa opção controlaria.

Faça um segundo teste apenas se a clínica autorizar uma mensagem para um contato de teste. Com a opção ativa, confirme o evento no histórico. Isso demonstra a diferença entre os dois estados sem usar um paciente real. Remova ou encerre os registros sintéticos conforme o procedimento interno.

Etapa Evidência
Configuração geral Categoria, local e alcance da desativação
Remarcação Estado de Notificar paciente
Histórico Evento de envio presente ou ausente
Conclusão Consulta e cenário efetivamente testados

Como investigar quando o histórico ainda mostra envio?

Confirme primeiro a sequência temporal. Uma mensagem já programada pode ter sido mantida quando a equipe escolheu desativar somente as próximas. Depois, revise a categoria, o local integrado e o estado de Notificar paciente na remarcação. Compare o horário da alteração com o horário registrado no histórico.

  1. Identifique a consulta e o evento exato.
  2. Confirme qual categoria estava configurada para o local.
  3. Veja se mensagens já programadas foram incluídas na desativação.
  4. Revise a opção Notificar paciente usada na remarcação.
  5. Verifique outros remetentes somente após concluir essas etapas.

Se a evidência contradizer os controles documentados, preserve capturas sem dados desnecessários e encaminhe ao suporte. Não atribua a mensagem a uma falha de integração sem essa confirmação. Se o caso também afeta relatórios, mantenha a origem original após a remarcação separada do canal da mensagem.

Como evitar que o problema volte?

Inclua dois pontos no procedimento de remarcação: a escolha consciente de Notificar paciente e a consulta ao histórico quando houver reclamação. No procedimento do usuário Master, registre categorias ativas, locais cobertos e tratamento de mensagens já programadas. Assim, cada controle tem um responsável e uma evidência.

Revise o processo sempre que um local integrado for adicionado ou quando a clínica mudar canais de lembrete. Execute um teste sintético após a alteração. Não dependa de memória da equipe para saber se uma caixa estava marcada; o histórico e a configuração atual devem sustentar a resposta.

Evite prometer uma auditoria consolidada que o produto não oferece na documentação atual. Se a clínica precisa desse relatório como requisito operacional, registre a lacuna e confirme com o fornecedor se existe outra função contratada. Até lá, o fluxo publicado continua individual.

Perguntas frequentes

Desativar confirmação impede toda mensagem de remarcação?

Não. A documentação orienta desativar também a opção separada Notificar paciente no fluxo de remarcação.

Quem pode configurar notificações no Feegow Clinic?

O artigo de gerenciamento informa que apenas usuário Master pode fazer essa configuração para os locais integrados.

Onde vejo se a mensagem saiu?

Abra a consulta no calendário, acesse o menu de três pontos e selecione Ver histórico de eventos. A página mostra se e quando a notificação foi enviada.

Existe relatório com todas as notificações enviadas?

A documentação informa que não existe relatório automático consolidado. A verificação disponível é manual e individual, consulta por consulta.

Referências

Por que o bloqueio automático de feriado do Feegow não fecha a agenda na Doctoralia?

cmsapointoo on August 16, 2026

O bloqueio automático de feriado do Feegow não fecha a agenda online integrada à Doctoralia. A documentação da integração classifica esse comportamento como uma funcionalidade não disponível. Para retirar os horários externos, a clínica precisa criar um bloqueio manual, selecionar profissional e unidade corretos e depois conferir a disponibilidade publicada.

Em clínicas com várias unidades, o escopo merece atenção. A opção de bloquear ao cadastrar um feriado pode atingir todos os profissionais e unidades no Feegow. Para um feriado municipal ou fechamento localizado, a própria documentação orienta usar a agenda múltipla e selecionar somente a unidade aplicável. O cadastro do feriado, o bloqueio interno e o resultado online são três verificações distintas.

Por que o feriado cadastrado não fecha a Doctoralia?

O Feegow permite cadastrar feriados nacionais, estaduais e municipais. A data aparece em laranja no calendário e pode ser vinculada a um bloqueio. Porém, o guia da integração Feegow e Doctoralia informa que o bloqueio automático de feriado não reflete na agenda online. Um feriado visível internamente não comprova que os horários externos foram retirados.

Essa limitação explica a diferença entre duas telas sem exigir uma causa inventada. A agenda interna pode mostrar o feriado e até aplicar um bloqueio automático, enquanto a Doctoralia continua exibindo disponibilidade. A resposta documentada é criar o bloqueio manual. Não espere que uma nova sincronização transforme o bloqueio automático em um recurso suportado.

Também não confunda esse caso com horários criados diretamente no marketplace. Se a divergência continuar fora da data do feriado, use o processo para encontrar horários manuais fora da integração. São problemas diferentes e pedem evidências diferentes.

O que deve ser definido antes do bloqueio manual?

Registre a data, o intervalo fechado, os profissionais afetados e cada unidade incluída. Defina se o fechamento vale o dia inteiro ou apenas parte do expediente. Quando a clínica mantém uma unidade aberta, não use um escopo global por conveniência. A lista deve representar a decisão operacional aprovada.

Confira ainda se o profissional tem grade em mais de uma unidade. O guia de bloqueios do Feegow diz que, nesse caso, é necessário selecionar a unidade vinculada à grade. O mesmo nome de profissional em duas localidades não torna o bloqueio automaticamente equivalente nos dois locais.

Campo Decisão a registrar
Data e período Dia inteiro ou intervalo específico
Profissional Quem não atenderá naquele período
Unidade Local fechado ou mantido em operação
Motivo Feriado relacionado ao bloqueio
Validação externa Combinação que será conferida na Doctoralia

Como criar o bloqueio manual no Feegow?

No Feegow, acesse uma agenda diária, semanal, múltipla ou de equipamentos alocados. Para este fluxo integrado, trabalhe com a agenda do profissional. Selecione o profissional, a data e a opção de bloqueio. Preencha início, fim e demais informações. O formulário permite vincular o bloqueio ao feriado cadastrado.

Salve e volte à agenda para confirmar que os horários previstos aparecem bloqueados. O guia informa que os horários bloqueados não podem ser selecionados para agendamentos comuns. Ele também avisa que o sistema pode permitir encaixe em horário bloqueado, salvo quando a configuração específica para bloquear encaixes estiver ativa.

O controle de encaixe é uma regra interna adicional. Não o trate como prova de que a Doctoralia retirou os horários. A integração exige o bloqueio manual, e a validação externa continua necessária. Se a clínica usa blocos por convênio, preserve a estrutura descrita no guia de horários exclusivos por convênio.

Quando usar a agenda múltipla?

A agenda múltipla permite configurar o bloqueio para mais de um profissional e unidade na mesma operação. O guia do Feegow apresenta essa opção para situações em que a clínica não abrirá e não quer repetir o bloqueio agenda por agenda. Ela também é a orientação documentada para delimitar um feriado municipal quando existem unidades fora do município.

Use a seleção múltipla para reduzir repetição, não para ampliar o escopo. Revise a lista de profissionais e unidades antes de salvar. Uma clínica pode fechar duas unidades e manter uma terceira aberta, ou bloquear apenas profissionais vinculados ao município do feriado. O conjunto selecionado deve corresponder a essa decisão.

Depois de salvar, examine cada combinação relevante. Um bloqueio visto na agenda múltipla não prova sozinho que todas as grades externas esperadas mudaram. A recepção precisa saber quais unidades foram incluídas, quais ficaram abertas e quem confere cada perfil publicado.

Como tratar feriados municipais em clínicas com várias unidades?

O artigo de configuração de feriados faz um alerta direto: se o feriado for municipal e a clínica tiver unidades fora daquele município, a opção geral de bloquear agenda não deve ser selecionada. Essa opção bloquearia todos os profissionais e unidades. O caminho indicado é criar o bloqueio pela agenda múltipla, selecionar somente a unidade e vinculá-lo ao feriado.

Isso separa a classificação do calendário do alcance operacional. O feriado pode ser recorrente no cadastro, mas cada fechamento ainda precisa representar a unidade certa. Antes de repetir o bloqueio em outro ano, confirme se unidades, profissionais e horários continuam iguais. A recorrência do feriado não garante que o escopo da clínica permaneceu estável.

Documente também exceções. Um profissional pode atender remotamente ou em outra unidade, mas as fontes não definem como a clínica deve decidir esses casos. Registre a decisão interna e bloqueie somente a grade que de fato ficará indisponível.

Como validar a agenda publicada na Doctoralia?

Abra a jornada externa usada por pacientes e procure o mesmo profissional, unidade e data bloqueados. Confira o período inteiro, não apenas o primeiro horário. Se parte do expediente permanecer aberta, confirme que somente os intervalos corretos continuam disponíveis. Repita a verificação para cada unidade com uma decisão diferente.

Registre data, hora e combinação testada. Uma captura da agenda interna prova o bloqueio no Feegow, enquanto uma captura da jornada externa prova o que foi publicado naquele momento. Guarde as duas evidências sem dados de paciente. Se for necessário um teste de reserva, use um cadastro sintético autorizado e siga o procedimento da clínica para removê-lo.

A disponibilidade externa não define a origem de marketing nem o resultado final da consulta. Mantenha esse assunto separado com a distinção entre origem do agendamento e origem de marketing. O teste aqui responde apenas se a vaga continuou exposta.

O que fazer quando o horário ainda aparece?

Volte ao escopo do bloqueio. Confirme data, início, fim, profissional, unidade e vínculo com a grade correta. Verifique se o bloqueio foi salvo e permanece listado. Depois, confirme se a disponibilidade externa pertence à mesma unidade integrada ou se foi criada diretamente na Doctoralia.

Não apague horários externos em massa sem identificar sua origem. O artigo da integração diz que a criação de horários destinados ao agendamento externo deve ocorrer no Feegow. Já a documentação de dúvidas da Doctoralia descreve horários manuais sem vínculo como outro caso. Preserve as duas hipóteses até a evidência apontar qual delas explica a vaga.

Se o bloqueio manual correto continuar sem refletir, reúna as evidências e encaminhe o caso ao suporte. Informe profissional, unidade, data, intervalo e resultado externo. Não envie dados clínicos ou detalhes de pacientes para demonstrar uma falha de disponibilidade.

Quais erros tornam o fechamento pouco confiável?

O erro mais direto é parar depois de cadastrar o feriado. A cor laranja ajuda a leitura interna, mas não fecha a Doctoralia. Outro erro é usar o bloqueio global para um feriado municipal e fechar unidades que deveriam operar. Também é comum validar o profissional certo na unidade errada.

  • Tratar feriado cadastrado como confirmação de bloqueio externo.
  • Criar o bloqueio na agenda de um profissional sem escolher a unidade vinculada.
  • Usar seleção múltipla sem revisar todos os profissionais e locais marcados.
  • Conferir somente o Feegow e não a jornada publicada.
  • Remover horários manuais sem provar que estão fora da integração.

Uma agenda fechada também afeta comunicação e capacidade. O guia sobre lembretes e lista de espera ajuda a separar a retirada preventiva de disponibilidade da recuperação de uma vaga cancelada. Não use a mesma métrica para os dois processos.

Como registrar o processo para a recepção?

Crie um checklist curto por feriado. Ele deve conter a decisão de funcionamento, o escopo por unidade, os profissionais afetados, os intervalos, o responsável pelo bloqueio e o responsável pela conferência externa. Use a configuração real do Feegow como fonte operacional, não uma planilha paralela que substitua a agenda.

Na conclusão, marque separadamente: feriado cadastrado, bloqueio manual salvo, agenda interna conferida e disponibilidade externa conferida. Essa divisão mostra onde o processo parou. Também evita a frase vaga “o feriado foi configurado” quando apenas uma das etapas ocorreu.

Revise o checklist se a documentação da integração mudar. Uma alteração futura deve ser confirmada nas fontes antes de eliminar o bloqueio manual.

Perguntas frequentes

Cadastrar o feriado em Configurações fecha a Doctoralia?

Não. A Feegow informa que o bloqueio automático de feriado não reflete na agenda online integrada. Crie e valide um bloqueio manual.

Posso bloquear todos os profissionais de uma vez?

A agenda múltipla permite selecionar vários profissionais e unidades. Revise o escopo antes de salvar, principalmente quando o feriado vale somente para um município.

O bloqueio manual cancela consultas que já existem?

As fontes mapeadas explicam como impedir novos agendamentos em horários bloqueados, mas não documentam cancelamento automático de consultas existentes. Revise compromissos já marcados pelo processo da clínica.

Como provar que o fechamento funcionou?

Confirme o bloqueio no Feegow e procure a mesma combinação de profissional, unidade, data e período na jornada externa da Doctoralia. Registre os dois resultados.

Referências

Clínica pode oferecer desconto ou pedir avaliação só a pacientes satisfeitos no Google?

cmsapointoo on August 16, 2026

Não. A clínica não pode oferecer desconto, brinde, serviço gratuito ou pagamento em troca de uma avaliação no Google. Também não pode pedir avaliações somente a pacientes satisfeitos. Ela pode fazer um pedido neutro de opinião genuína, sem incentivo, sem tentar influenciar a nota ou o conteúdo e sem desestimular críticas.

A política também proíbe pressionar alguém a avaliar enquanto está no local ou determinar o que deve ser escrito, inclusive pedir menção a um funcionário. Em saúde, há um cuidado adicional: o convite não deve estimular a publicação de diagnóstico, tratamento, consulta ou outra informação médica ou pessoal.

O que é um pedido neutro de avaliação?

É um convite para relatar uma experiência real, feito sem recompensa e sem orientar a nota, o tom ou as palavras. O Google permite que empresas solicitem conteúdo baseado em experiência genuína quando não oferecem incentivos nem tentam influenciar a avaliação.

Uma mensagem neutra convida a pessoa a compartilhar sua experiência com a clínica no Google, se quiser. Ela não promete vantagem, não pede cinco estrelas e não condiciona atendimento futuro. O texto deve ser igual para experiências positivas e negativas, dentro de uma regra operacional definida antes de saber a satisfação da pessoa.

A clínica pode usar o link ou QR code fornecido pelo Perfil da Empresa. O pedido deve levar à página correta da unidade e deixar a decisão com o usuário. Ausência de resposta não deve gerar cobrança, insistência ou mudança no tratamento recebido.

Por que desconto ou brinde não pode financiar uma avaliação?

O Google classifica como engajamento falso avaliações pagas direta ou indiretamente. A proibição inclui pagamento, desconto, produto gratuito e serviço sem custo oferecidos em troca de publicar uma avaliação. Também alcança incentivo para alterar uma avaliação ou remover uma crítica.

Não importa se a clínica pede uma opinião “honesta” ou aceita qualquer nota. Se existe recompensa vinculada à publicação, o incentivo continua presente. Sorteio, cupom, retorno com condição especial ou benefício prometido depois da captura de tela criam o mesmo problema quando dependem da avaliação.

Uma promoção comercial pode existir por outra finalidade, com regras próprias. Ela não deve depender de avaliar, revisar ou apagar conteúdo no Google. Separe claramente campanha promocional e programa de feedback público.

Por que pedir somente a pacientes satisfeitos é review gating?

O Google não permite desencorajar avaliações negativas nem solicitar seletivamente avaliações positivas. Perguntar primeiro se a pessoa está satisfeita e mostrar o link público apenas para quem responde “sim” cria um filtro. Quem teve problema é desviado; quem aprovou é levado ao Google. Essa seleção tenta alterar a distribuição das notas.

A clínica pode manter um canal privado para reclamações, mas ele não deve bloquear o acesso à avaliação pública. Uma pesquisa interna também pode existir, desde que a resposta não determine quem recebe o link. O processo neutro usa critério independente da satisfação, como uma etapa padronizada após uma interação concluída.

Não instrua a recepção a escolher “os melhores pacientes” ou evitar quem reclamou. A regra precisa ser verificável e consistente. O objetivo é ouvir experiências genuínas, não fabricar uma amostra favorável.

Quais formas de pressão e conteúdo prescrito são proibidas?

Ao solicitar avaliações, a empresa não deve exigir nem pressionar usuários a dar nota ou escrever enquanto ainda estão no estabelecimento. O pedido pode ser apresentado, mas a pessoa precisa decidir se, quando e onde responder. Ficar ao lado do celular, insistir até a publicação ou condicionar uma etapa administrativa transforma o convite em pressão.

A empresa também não deve pedir conteúdo específico. Isso inclui roteiro pronto, palavras obrigatórias, uma nota definida ou menção nominal a um funcionário. Metas internas que mandam cada colaborador obter determinado número de avaliações também aparecem entre os exemplos de manipulação da política.

Treine a equipe com limites simples: informar o canal, não observar a resposta, não sugerir elogio e não acompanhar quem não publicou. O desempenho da recepção não deve depender de avaliações que identifiquem seus integrantes.

Como usar link e QR code sem criar um filtro?

O Perfil da Empresa permite copiar um link de avaliação ou gerar um QR code. O Google sugere compartilhar o convite em comprovantes, mensagens de agradecimento, depois de uma conversa por chat ou no estabelecimento. Também cita e-mail, WhatsApp e Facebook como canais possíveis. O QR code é gerado em navegador de computador.

Esses canais não mudam a regra de neutralidade. Defina qual unidade será avaliada, qual evento dispara o convite e quantas tentativas são aceitáveis. Não use a resposta de uma pesquisa de satisfação para decidir se o link aparece. Não peça fotografia ou captura da avaliação como prova.

O Perfil da Empresa reúne outras superfícies públicas. Uma boa governança começa por saber quem controla os links do perfil, quais contas têm acesso e quem responde por mudanças.

Como evitar detalhes médicos e pessoais nas avaliações?

A política de conteúdo do Maps proíbe publicar informações pessoais sem consentimento e inclui informação médica entre os exemplos. Uma avaliação de clínica pode revelar mais do que uma opinião: pode associar uma pessoa a uma condição, procedimento, profissional ou data de atendimento.

Por isso, o convite não deve sugerir frases como “conte qual tratamento fez” ou “explique seu diagnóstico”. Peça apenas uma experiência geral e avise, de forma breve, para não incluir dados médicos ou pessoais. Esse cuidado não transforma a avaliação em canal clínico nem transfere à pessoa a responsabilidade integral pelo desenho do processo.

Se aparecer conteúdo sensível, não o repita na resposta pública. Encaminhe a análise para o procedimento interno aprovado e use as ferramentas do Google quando a contribuição violar a política.

Como a clínica deve responder sem confirmar relação de atendimento?

Respostas do Perfil da Empresa são públicas. O Google orienta proteger a privacidade e não compartilhar informações particulares. Em situações complexas, a recomendação é pedir que a pessoa entre em contato por telefone ou e-mail para resolver o assunto em ambiente privado.

Uma resposta segura agradece o comentário, informa um canal geral e evita confirmar que a pessoa é paciente, esteve na unidade, recebeu determinado serviço ou falou com um profissional. Não corrija publicamente datas, diagnóstico, cobrança, conduta clínica ou histórico. Mesmo quando a própria avaliação menciona esses pontos, a clínica não precisa ampliá-los.

Se houver crítica, não ofereça vantagem para apagá-la nem pressione por mudança. Responda com educação, trate o caso em canal privado e separe melhoria operacional de disputa pública.

Qual processo interno mantém a solicitação neutra?

  1. Defina um evento neutro para o convite, sem usar nota prévia de satisfação.
  2. Use a mesma mensagem para todas as pessoas que atendam ao critério operacional.
  3. Remova desconto, brinde, pagamento, sorteio ou benefício ligado à publicação.
  4. Não peça nota, texto, palavra-chave ou nome de funcionário.
  5. Permita que a pessoa responda depois, sem supervisão ou cobrança.
  6. Inclua um lembrete breve para não publicar detalhes médicos ou pessoais.
  7. Restrinja respostas públicas a conteúdo geral e leve casos complexos a canal privado.
  8. Revise periodicamente acessos, links, templates e registros de reclamação.

A revisão do perfil pode aproveitar controles já usados no agendamento. Verifique se existe algum link de terceiro que precisa ser removido e se a equipe entende os limites dos dados de performance no Perfil da Empresa. Avaliações, agendamentos e relatórios são superfícies distintas, mas compartilham a mesma responsabilidade de representação fiel.

Perguntas frequentes

A clínica pode dar desconto por uma avaliação honesta?

Não. A proibição vale mesmo quando a clínica diz aceitar qualquer nota. Desconto, pagamento, produto ou serviço gratuito em troca de publicar, mudar ou remover uma avaliação é incentivo e pode ser tratado como engajamento falso.

Pode enviar o link somente para quem marcou nota alta na pesquisa interna?

Não. Isso seleciona avaliações positivas e exclui pessoas insatisfeitas, prática proibida pela política. A pesquisa privada pode existir, mas não deve decidir quem recebe acesso ao link público. Use um critério neutro definido antes da resposta.

A recepção pode pedir cinco estrelas ou menção ao médico?

Não. A empresa não deve influenciar a nota nem solicitar conteúdo específico, inclusive identificação de um funcionário. A mensagem pode pedir uma experiência genuína, sem roteiro, sem palavras obrigatórias e sem pressão para responder no local.

Como responder quando a avaliação revela tratamento ou diagnóstico?

Não confirme nem repita a informação médica na resposta pública. Agradeça de modo geral e ofereça telefone ou e-mail para contato privado. Se o conteúdo violar a política, siga o processo de denúncia do Google e o procedimento interno da clínica.

Referências

Clínica com vários médicos: um Perfil da Empresa por unidade ou também por profissional?

cmsapointoo on August 16, 2026

Uma clínica com vários médicos deve manter um Perfil da Empresa da organização para cada local público elegível. Além disso, cada médico ou dentista pode ter um perfil individual quando atua diante do público e pode ser contatado diretamente naquele local verificado durante o horário informado. O perfil profissional não substitui o perfil da unidade.

A estrutura muda em dois casos. Se houver um único profissional público representando uma organização de marca no local, o Google recomenda um só perfil combinado. Um departamento só deve ganhar perfil próprio quando atende o público e opera como entidade distinta. Criar páginas por especialidade, sala ou conveniência administrativa não atende esses critérios.

Qual é a estrutura-base para uma clínica com vários médicos?

A estrutura-base tem um perfil da organização para o local e, quando os critérios forem atendidos, perfis separados dos profissionais que trabalham ali. A orientação do Google para vários profissionais no mesmo endereço preserva as duas entidades: a clínica como organização e o médico ou dentista como profissional público.

Isso não significa criar um perfil para cada pessoa cadastrada na agenda. O profissional individual precisa atuar diante do público e ser contatável diretamente no local verificado durante o horário declarado. Equipe de suporte não deve criar perfil próprio. A existência de uma página no site ou de uma especialidade não substitui esses requisitos.

Antes de alterar o perfil, registre quem representa a unidade, quem atende o público e qual contato pertence a cada entidade. A mesma disciplina vale para quem controla o link de agendamento exibido no perfil.

O local da clínica é elegível para um Perfil da Empresa?

A primeira pergunta não é quantos médicos trabalham ali. É se a empresa mantém contato presencial com clientes durante o horário informado. O Google descreve o Perfil da Empresa como recurso para negócios com localização física fixa que clientes podem visitar ou que encontram clientes em uma área local.

Uma clínica presencial, com endereço real e atendimento ao público, pode avaliar a elegibilidade do local. Um endereço usado apenas para correspondência, uma página somente online ou uma presença que não recebe clientes não deve ser convertido em perfil local por conveniência. A representação precisa corresponder ao negócio no mundo real.

Para mais de uma unidade, analise cada local separadamente. Nome, endereço, telefone, horário e categoria devem refletir aquela operação. Não duplique o mesmo local em contas diferentes. Um perfil por unidade elegível é diferente de várias cópias da mesma unidade.

Quando médico ou dentista pode ter perfil individual?

O Google trata médicos e dentistas como exemplos de profissionais individuais. O perfil próprio cabe quando o profissional exerce função pública e pode ser contatado diretamente na localização verificada durante o horário declarado. A decisão depende do trabalho real no local, não apenas de currículo, vínculo contratual ou presença no corpo clínico.

O profissional não deve criar vários perfis para cobrir todas as especializações. Um único médico com duas áreas de atuação continua sendo uma pessoa. Categorias e serviços podem representar sua atividade dentro das opções permitidas, mas não justificam duplicar a entidade no mesmo local.

O título ou grau profissional pode constar no perfil individual conforme a orientação da plataforma. Evite acrescentar termos promocionais, nomes de serviços ou palavras de busca que não façam parte da identificação real. A regra central é representar com precisão quem o público encontrará.

Como ficam os nomes quando vários profissionais dividem o local?

Quando há vários profissionais públicos no mesmo local, o perfil da organização deve existir separado dos perfis individuais elegíveis. O nome do perfil do profissional deve incluir somente o nome dele, sem o nome da organização. Essa distinção evita transformar cada médico em uma cópia da clínica.

Entidade Perfil Nome esperado
Clínica no local Perfil da organização Nome real da clínica
Profissional elegível entre vários Perfil individual separado Somente nome do profissional
Equipe administrativa Sem perfil individual Não se aplica

O telefone e o site também devem conduzir à entidade representada. Se a pessoa só consegue falar com uma central genérica que não permite contato direto com o profissional, volte ao critério de elegibilidade antes de criar o perfil individual.

O que muda quando há um único profissional de uma marca?

Se o profissional é a única pessoa pública no local e representa uma organização de marca, o Google recomenda compartilhar um único Perfil da Empresa entre profissional e organização. O formato documentado é [marca/empresa]: [nome do profissional]. Essa é uma exceção importante à estrutura usada quando vários profissionais dividem a unidade.

Não aplique o perfil combinado apenas porque uma clínica quer destacar um médico. Primeiro confirme que ele é o único profissional público naquele local e que representa a organização de marca. Se outro profissional também atende o público ali, a lógica volta a ser perfil da organização separado de cada perfil individual elegível.

Uma mudança de equipe pode alterar a estrutura correta. Quando a unidade deixa de ter um único profissional público, revise nome, propriedade, categorias, site e contatos antes de criar ou separar perfis.

Quando um departamento da clínica pode ter perfil próprio?

Um departamento pode ter perfil separado quando atende o público e funciona como entidade distinta. A documentação informa que seu nome exato deve ser diferente do nome da empresa principal e dos demais departamentos. Em geral, ele tem entrada própria para clientes, categoria distinta e, em alguns casos, horários diferentes.

Uma linha de serviço, uma sala interna ou uma especialidade listada no site não vira departamento automaticamente. A unidade precisa demonstrar a distinção no funcionamento e na representação pública. Para cada departamento, a categoria mais representativa deve ser diferente da categoria principal e das categorias dos outros departamentos.

Hospitais aparecem expressamente na orientação sobre departamentos, mas o teste continua sendo operacional. Antes de criar um perfil, documente nome público, entrada, categoria, horário, contato e responsabilidade pela página. Se esses elementos não separam a entidade, mantenha o serviço dentro do perfil da organização.

Como decidir entre unidade, profissional e departamento?

Situação real Estrutura indicada Teste decisivo
Local público elegível com vários profissionais Perfil da organização, mais perfis individuais elegíveis Cada profissional é público e contatável diretamente?
Único profissional público de organização de marca Um perfil combinado Ele é realmente o único profissional público no local?
Departamento público independente Perfil próprio do departamento Opera como entidade distinta, com nome e categoria diferentes?
Especialidade do mesmo profissional Sem perfil adicional É apenas outra especialização da mesma pessoa?
Equipe de suporte Sem perfil individual A função não atende o público como profissional independente?

Use essa matriz como triagem, não como licença automática. A configuração deve seguir a operação comprovável. Se o cenário não cabe claramente em uma linha, reúna evidências do local e confirme a orientação atual antes de publicar outra página.

Que controle evita perfis duplicados ou incoerentes?

  1. Faça um inventário de unidades, profissionais e departamentos já visíveis na Pesquisa e no Maps.
  2. Associe cada perfil a uma entidade real, um responsável e uma conta proprietária.
  3. Confirme atendimento público, contato, nome, categoria, endereço e horário.
  4. Marque duplicações por local, profissional ou especialidade para revisão.
  5. Teste site, telefone e agendamento de cada perfil que permanecer ativo.
  6. Revise a estrutura quando um profissional entra, sai ou passa a ser o único do local.

Não trate links públicos como detalhe secundário. Confira se a unidade correta recebe o agendamento e se um fornecedor ainda autorizado aparece. Há um fluxo próprio para remover um link de agendamento de terceiros.

Separe presença local de relatório operacional. O artigo sobre link personalizado e Reservar com o Google mostra por que uma ação no perfil não comprova comparecimento, receita ou atribuição completa.

Perguntas frequentes

Cada médico da clínica pode ter um perfil?

Somente quando cada profissional atua diante do público e pode ser contatado diretamente no local verificado durante o horário informado. Com vários profissionais, a organização mantém seu perfil separado. Pessoas da equipe de suporte não são elegíveis como profissionais individuais.

O nome do médico pode incluir o nome da clínica?

Quando o médico é um entre vários profissionais do local, o perfil individual deve usar apenas o nome dele. Se for o único profissional público de uma organização de marca, o Google recomenda um perfil combinado no formato [marca/empresa]: [nome do profissional].

É possível criar um perfil para cada especialidade?

Não para multiplicar os perfis do mesmo profissional. A orientação diz que um profissional não deve ter vários Perfis da Empresa para cobrir suas especializações. Um departamento público distinto segue outro teste e não deve ser confundido com especialidade.

Cada unidade da clínica precisa de perfil próprio?

Cada local real e elegível pode ter o perfil da organização correspondente. Verifique atendimento presencial, endereço, horário, telefone e representação pública de cada unidade. Não crie várias páginas para a mesma localização em contas diferentes.

Referências

Google Ads para clínicas: contar Uma ou Todas as conversões de formulário e agendamento?

cmsapointoo on August 16, 2026

Configure a contagem separadamente para cada ação de conversão. Em clínicas, Uma costuma ser a escolha coerente para um formulário de lead quando repetições após a mesma interação representam uma única aquisição. Use Todas apenas quando cada conclusão distinta daquela ação tiver valor próprio. A regra não deve ser copiada automaticamente de formulário para agendamento.

A mudança afeta somente relatórios futuros. Ela também pode alterar os sinais usados para lances quando a ação entra na coluna Conversões, mas não corrige o histórico, não prova que houve consulta e não substitui os estados internos da agenda. Escolher Uma ou Todas também não autoriza enviar dados de saúde ao Google.

A decisão deve ser tomada por ação de conversão

O Google Ads permite escolher um método de contagem diferente para cada ação. A clínica pode, portanto, usar Uma no envio de formulário e outra configuração em uma ação de agendamento, desde que consiga explicar o valor empresarial de cada repetição. Não existe obrigação de aplicar a mesma resposta a todas as metas da conta.

Comece pelo significado da ação, não pelo nome que aparece no painel. “Formulário enviado” descreve uma conclusão técnica. “Agendamento confirmado” descreve outro ponto do processo. A taxonomia de resultados de agendamento ajuda a manter enviados, agendados, comparecidos, cancelados e aceitos como estados internos separados.

Para decidir, escreva uma frase verificável: “Após a mesma interação com o anúncio, uma segunda conclusão desta ação representa novo valor ou repetição do mesmo interesse?”. Se a resposta não estiver clara, ainda falta definir a ação antes de escolher a contagem.

O que Uma e Todas realmente contam?

Na configuração Uma, o Google Ads contabiliza uma conversão daquela ação por clique no anúncio. A documentação apresenta essa opção como adequada quando o objetivo é gerar determinado tipo de lead e repetições não acrescentam valor independente. Em Todas, a plataforma contabiliza todas as conversões da ação acompanhada que ocorrem após a interação.

Configuração Pergunta operacional Uso coerente Risco de interpretação
Uma Uma repetição ainda representa a mesma aquisição? Lead repetido sem valor próprio Ocultar resultados distintos quando a ação foi definida de forma ampla demais
Todas Cada conclusão tem valor independente? Resultados distintos e verificáveis Inflar o indicador com reenvios ou duplicações tratadas como resultado

Essas opções não são as colunas Conversões e Todas as conversões. A configuração define quantas ocorrências de uma ação serão contabilizadas. As colunas organizam quais ações aparecem no relatório. Confundir os dois controles produz diagnósticos errados.

Quando contar Uma em um formulário de clínica?

Use Uma quando vários envios após o mesmo clique continuarem representando um único lead para aquela ação. Isso pode ocorrer quando alguém repete o formulário porque não viu a confirmação, corrige um telefone ou tenta novamente depois de uma falha. A opção limita a contagem no Google Ads, mas a clínica ainda deve tratar cada registro recebido com segurança no sistema interno.

O critério não é “formulário sempre conta Uma”. Um formulário pode representar pedidos diferentes, mas isso precisa estar refletido em ações claramente separadas e em uma definição aprovada. Se a equipe não consegue demonstrar por que cada novo envio tem valor independente, Todas cria um número mais alto sem melhorar a qualidade da medição.

Compare o total publicitário com o registro operacional, sem esperar igualdade automática. A ação informa o que o Google atribuiu depois da interação. A recepção informa se o contato foi válido, duplicado, desqualificado ou convertido em agendamento.

Quando Todas pode fazer sentido para um agendamento?

Todas pode fazer sentido quando cada conclusão da ação representa um agendamento distinto, aceito pelo fluxo da clínica e com valor próprio. Essa decisão exige que a ação tenha um significado estreito. Se o evento dispara ao recarregar uma página, repetir uma confirmação ou remarcar a mesma consulta, a contagem deixa de representar o resultado pretendido.

O Google apresenta Todas como apropriada quando cada conversão acrescenta valor, usando vendas como exemplo. Aplicar essa lógica a agendamentos é uma decisão interna da clínica, não uma classificação automática da plataforma. Registre o que torna duas conclusões independentes e como a agenda confirma essa diferença.

Um clique pode originar mais de um resultado, mas o painel não demonstra comparecimento. O mesmo limite aparece nas chamadas: uma conversão de chamada não prova um agendamento. Em ambos os casos, o resultado final pertence ao sistema operacional.

Por que formulário e agendamento não devem compartilhar a mesma regra?

As duas ações representam etapas diferentes. O formulário registra uma manifestação de interesse. O agendamento registra uma reserva criada ou confirmada conforme a definição interna. Quando ambas recebem a mesma regra por conveniência, a equipe perde a capacidade de explicar o que uma repetição significa em cada etapa.

Uma configuração mais fiel pode ser Uma para o formulário e Todas para uma ação de agendamento bem definida. Outra clínica pode usar Uma nas duas porque repetições após o mesmo clique não têm valor adicional para seu modelo. O Google permite essa combinação por ação; a operação determina qual combinação é defensável.

Não una formulário e agendamento em uma ação genérica chamada “lead”. Esse atalho mistura intenção e resultado. Mantenha nomes, proprietários e critérios de validação próprios, mesmo quando apenas uma das ações participa da otimização.

Como a mudança afeta relatórios e lances?

Alterar Uma para Todas, ou o caminho inverso, vale para conversões futuras daquela ação. A documentação do Google afirma que os dados anteriores não são recalculados. Por isso, anote data, hora, ação alterada, configuração anterior, nova configuração e motivo. Sem esse marco, uma variação de volume pode parecer mudança de campanha quando foi apenas mudança de medição.

A coluna Conversões mostra as ações principais e costuma ser usada para otimização de lances. A coluna Todas as conversões oferece uma visão mais ampla, incluindo ações principais e secundárias. Assim, a contagem e a classificação da ação trabalham juntas: mudar a contagem de uma ação principal pode mudar o volume futuro que chega à coluna usada pelos lances.

Não altere meta, contagem e definição da ação ao mesmo tempo. Faça uma mudança controlada, registre a data e acompanhe a transição. Isso preserva uma explicação simples para o que o relatório passou a mostrar.

O que precisa continuar fora do Google Ads?

O Google Ads não deve virar prontuário, agenda clínica ou sistema de qualificação. Diagnóstico, queixa, especialidade associada a uma pessoa, observação da recepção e detalhes do atendimento não são necessários para escolher Uma ou Todas. A decisão pode ser tomada com o significado genérico da ação e com resultados agregados.

Mantenha no sistema aprovado os estados enviados, agendados, comparecidos, cancelados e aceitos. No Google, use somente uma ação genérica previamente aprovada quando houver base operacional e de privacidade. A configuração de contagem não concede permissão adicional, não torna um campo sensível aceitável e não reduz a obrigação de revisar consentimento e políticas aplicáveis.

Quando há integração offline, acompanhe a entrega separadamente. O relatório de outbox de conversões mostra por que fila, envio, diagnóstico da plataforma e atribuição são provas diferentes.

Como validar a escolha antes e depois da alteração?

  1. Liste cada ação de conversão e escreva o resultado que ela representa.
  2. Defina se uma repetição após a mesma interação tem valor próprio.
  3. Confirme se a ação é principal ou secundária e onde aparece no relatório.
  4. Compare a definição com os estados reais mantidos pela agenda.
  5. Revise o fluxo para impedir que conteúdo clínico ou identificadores de pacientes cheguem ao destino publicitário.
  6. Registre a data da alteração, pois ela afeta somente relatórios futuros.
  7. Monitore separadamente volume da ação, agendamentos confirmados e comparecimentos.

O controle termina com uma reconciliação, não com o clique em Salvar. Se o volume publicitário subir e o número de resultados internos permanecer estável, investigue repetição, disparo e definição da ação. Se a qualidade dos leads mudar, separe esse diagnóstico da contagem. Clique inválido e lead desqualificado também são evidências diferentes.

Perguntas frequentes

Formulário de clínica deve sempre usar Uma?

Não. Uma é coerente quando repetições daquela ação após o mesmo clique representam uma única aquisição. Se cada conclusão for realmente distinta e tiver valor próprio, Todas pode ser defensável. A clínica precisa documentar o significado da ação e validar o resultado no sistema interno.

Agendamento deve sempre usar Todas?

Não. Use Todas somente quando cada conclusão atribuída representar um resultado independente. Se a mesma reserva puder gerar repetições, a escolha pode superestimar o indicador. A agenda, e não o contador publicitário, confirma quantos agendamentos válidos existem.

A alteração corrige os relatórios antigos?

Não. Segundo o Google, mudanças na configuração de contagem são aplicadas somente aos relatórios futuros daquela ação. Registre a data da troca e evite comparar períodos anteriores e posteriores como se a regra tivesse permanecido igual.

Escolher Uma torna seguro enviar dados de saúde?

Não. Uma e Todas controlam a quantidade de conversões contabilizadas. Nenhuma opção autoriza dados de saúde, detalhes de consulta ou identificadores de pacientes. A aprovação de campos, finalidade, consentimento e produto precisa ocorrer em uma revisão separada.

Referências

How DrChrono Chooses the Time Zone for Appointment Reminders

cmsapointoo on August 16, 2026

DrChrono appointment reminders use a defined time-zone precedence. The practice group supplies the default reminder source, but an individual provider can override that setting. At provider level, the reminder source can be Provider or Patient. This choice affects how reminder timing is calculated. It does not change the provider time zone used for text and phone quiet hours.

The calendar’s local time-zone dropdown is another control. It changes how appointments appear in the calendar view and does not change reminder timing. For a multi-time-zone or telehealth practice, these settings must be reviewed separately. Changing the visible calendar is not a fix for a reminder sent at an unexpected local time.

What is the time-zone precedence for DrChrono reminders?

DrChrono documents a two-level order. The practice group chooses a default time-zone source for appointment reminders. If a provider selects a different reminder source in Account Settings, that provider choice takes priority. The result is a group baseline with an individual override, not two equal settings that the system tries to combine.

DrChrono says reminders use the provider’s time zone by default. Its example starts with a group that uses Provider, followed by one provider who selects Patient. Reminders for that provider then use the provider-level Patient choice. Other providers remain governed by their own setting or the group default.

This hierarchy matters when one clinician reports different timing from colleagues in the same practice group. Compare the provider’s Account Settings with the group default before changing reminder profiles. A shared reminder schedule can still produce different local results when providers use different time-zone sources.

How does the practice-group default work?

The practice-group setting is the starting point for providers who have not chosen a different source. DrChrono’s current instructions say the practice must open a support case to update the group’s reminder time-zone source. The documentation does not describe a self-service group control in the same path used for a provider.

Treat the support-confirmed group choice as configuration evidence. Record the group, requested source, confirmation date, and providers expected to inherit it. Do not assume that a support change removed existing provider overrides. The documented precedence says a provider preference remains stronger than the group setting.

After a group change, test at least one provider expected to inherit the default and one provider known to have an override. This operational check separates a failed group update from a valid provider exception. If several reminder systems are active, also review the process for preventing duplicate appointment reminders before blaming time-zone precedence.

How does a provider override the group?

The provider path is Account > Account Settings > General. In the Communications section, the provider uses the Reminder timezone source dropdown and selects Provider or Patient. Provider is the documented default. The change is saved with Update Entire Profile.

A provider override should be intentional. Record which providers need Patient because they routinely serve people outside the provider’s local zone. Keep Provider where the practice wants reminder timing anchored to the clinician’s time zone. These are operational choices; DrChrono documents the controls but does not prescribe one choice for every telehealth practice.

When troubleshooting, inspect the affected provider’s setting directly. A screenshot of the group request cannot prove the provider inherited it. Likewise, a staff member’s browser zone does not prove which reminder source the provider selected. The deciding evidence is the configured provider preference together with the confirmed group default.

What changes when the source is Provider or Patient?

The selected source tells DrChrono which time zone to use for appointment-reminder timing. Provider uses the provider’s time zone. Patient uses the patient’s time zone. The choice is about the timing basis for reminders, not appointment ownership, booking source, or the visible zone in a staff member’s calendar.

Before choosing Patient, confirm that the patient record has the intended time zone through the workflow your practice uses. Before choosing Provider, confirm the provider account has the intended time zone. The mapped documentation establishes the selection and precedence. It does not state that staff should infer a missing zone from an address or browser, so unresolved values should be reviewed rather than guessed.

Keep reminder timing separate from intake completion and other messages. The guide to measuring appointment and intake reminders separately explains why two messages tied to one visit can have different owners, timing, and success criteria.

Which time zone controls text and phone quiet hours?

DrChrono applies quiet hours for text messages and phone calls using the provider’s time zone. Those channels are allowed from 5:00 AM through 9:00 PM and blocked from 9:00 PM through 5:00 AM in provider time. Email reminders have no documented time restriction in the reminder setup guide.

This rule remains provider based even when the reminder time-zone source is Patient. That creates two separate questions: which zone calculates the intended reminder time, and whether a text or call falls inside provider-time quiet hours. A Patient selection does not move quiet hours to the patient’s zone.

The same guide says reminders of the same type can only be sent 12 hours apart. Keep that spacing rule separate as well. If a reminder did not send when expected, examine the selected source, provider-time quiet hours, channel, and same-type spacing. Do not describe every delay as a time-zone error.

Why does changing the calendar view not change reminders?

DrChrono’s local calendar time-zone feature changes only the Calendar. Once support enables it, the dropdown at the top of the calendar defaults to the browser’s local time zone. Selecting another zone redraws appointments in that zone so staff can view a schedule across locations.

The vendor documentation explicitly limits this change to the calendar view. It does not say that the dropdown edits the provider’s account zone, the patient’s zone, the practice-group reminder source, or a provider’s reminder-source override. Staff can therefore view an appointment in one zone while reminder calculations use another documented source.

Use the dropdown for visual coordination, not reminder repair. If the displayed appointment looks correct but delivery timing is wrong, return to the reminder precedence and quiet-hours checks. This distinction also protects reporting: calendar presentation should not overwrite the original facts described in appointment source versus marketing source.

How should a multi-time-zone practice test the configuration?

Use controlled appointments for a small matrix. Include one provider who inherits the group default and one with a provider override. For each, use a test patient whose intended time zone is known. Schedule reminders far enough from quiet-hour boundaries to establish the source first, then test a text or phone reminder near a provider-time boundary.

Test Configuration to record Question answered
Inherited provider Group source and no differing provider choice Does the group baseline apply?
Provider override Provider source differs from group Does the individual setting take priority?
Quiet-hour boundary Channel, provider zone, intended send time Is text or phone blocked in provider time?
Calendar display Browser zone and selected calendar zone Does only the visible appointment time change?

Record expected and observed times with their named zones. A bare value such as “9:00” cannot show whether the configuration worked. Use synthetic contact details approved for testing, and remove or close test appointments through the practice’s normal process.

How do you troubleshoot a reminder that appears early or late?

Start with the affected provider, appointment, reminder type, scheduled offset, and patient. Confirm the practice-group source, then inspect the provider’s Communications setting for an override. Check the provider and patient zones used by the practice, followed by provider-time quiet hours for text or phone. Finally, inspect the calendar dropdown only to explain what staff saw.

  1. Write down the appointment time with its zone.
  2. Record the group reminder source and support confirmation.
  3. Check the provider’s Provider or Patient selection.
  4. Record the relevant provider and patient zones.
  5. Check channel, reminder offset, 12-hour spacing, and provider-time quiet hours.
  6. Compare the result without treating calendar display as a configuration source.

If the appointment was rescheduled, preserve its history while you investigate. The article on preserving original booking source after a reschedule provides a separate data rule. It does not change DrChrono reminder precedence, but it prevents troubleshooting from rewriting attribution.

Frequently Asked Questions

Does the practice-group setting always win?

No. It supplies the default, but DrChrono says a provider’s Account Settings preference overrides the practice-group choice.

Should a telehealth provider choose Patient?

Patient is available when reminder timing should use the patient’s time zone. The practice should confirm the patient zone and test its workflow. DrChrono does not prescribe Patient for every telehealth appointment.

Do quiet hours move to the patient’s zone when Patient is selected?

No. DrChrono documents text and phone quiet hours in the provider’s time zone, from 9:00 PM through 5:00 AM. Email has no documented time restriction.

Can the calendar time-zone dropdown fix reminder timing?

No. The local calendar setting changes how appointments appear in Calendar. Reminder timing uses the separate group and provider controls.

References

Google Cloud Pub/Sub Message Storage Policy for Single-Region Health Workloads

cmsapointoo on August 16, 2026

A Google Cloud Pub/Sub topic needs more than a single value in allowedPersistenceRegions to support a strict single-region design. That list constrains where Pub/Sub stores and processes message content. Setting enforceInTransit to true adds rejection behavior for publish, pull, and streaming pull operations received in a disallowed region. For stronger regional isolation, Google recommends pairing those settings with a regional endpoint in the allowed region.

This control has sharp boundaries. It does not cover topic names, labels, or IAM settings. A policy update does not relocate messages published under the old policy. One allowed region also concentrates availability on that region. HIPAA coverage under Google’s Business Associate Agreement does not remove the customer’s responsibility to configure and secure the workload.

What the message storage policy controls

Google documents messageStoragePolicy as a topic property. Its allowedPersistenceRegions field lists Google Cloud regions where messages published to the topic may persist in storage. If a publisher runs in a different Google Cloud region or outside Google Cloud, Pub/Sub can route the message for storage in an allowed region.

The configuration page describes the policy as controlling where message contents are stored and processed, regardless of where publish or subscribe requests originate. If more than one region is allowed, Pub/Sub stores a published message in an allowed region close to where the message enters Google’s network.

For a single-region health workload, the list contains one supported region. That is a technical architecture choice, not a statement that HIPAA requires US-only or single-region storage. The service setting must follow the organization’s legal, contractual, resilience, and operational decision.

What enforceInTransit adds

Storage location and request processing are separate concerns until enforceInTransit is enabled. The REST API reference says that, when true, the allowed-region list also enforces in-transit guarantees. Pub/Sub fails publish operations and subscribe operations on attached subscriptions when those operations occur in a region outside the list.

The configuration guide names publish, pull, and streaming pull requests and states that Pub/Sub returns FAILED_PRECONDITION when a request is received in a disallowed region. It also says push delivery is handled only within allowed Cloud regions. A constrained combination of message location, allowed regions, and export-resource location can pause push delivery.

This behavior should be tested, not inferred from a successful topic creation. Run synthetic publish and consume checks through the intended endpoint and a deliberately disallowed endpoint. Confirm the expected success and rejection without putting health information in the test messages.

Why the endpoint matters

Pub/Sub has global, regional, and locational endpoints. The API overview says a regional endpoint always routes requests to Pub/Sub in the specified region and does not reroute them elsewhere. The message storage policy must include that target region. Google recommends a regional endpoint for strict data residency and isolation with enforceInTransit set to true.

The global endpoint behaves differently. Requests from outside Google Cloud can reach a nearby available region that may not be in the policy. With in-transit enforcement, that can produce FAILED_PRECONDITION. Requests originating inside Google Cloud normally route in their origin region, but a client placed in the wrong region can still fail.

Locational endpoints do not provide the same strong assurance as regional endpoints. Google says requests to them are almost always routed to the named region, while regional endpoints are never rerouted. Use the regional endpoint when it is available for the chosen region and strict isolation is the stated goal.

Message content is not all Pub/Sub data

The configuration guide states that the message storage policy applies only to message contents. It does not apply to topic names, labels, or IAM settings. A design document should therefore avoid saying that the policy makes the complete Pub/Sub resource regional.

Names and labels can disclose operational context even when they do not contain message content. Keep health conditions, patient references, and other sensitive details out of resource names and labels. That is editorial architecture advice based on the documented scope boundary, not a claim that the policy governs metadata.

The namespace is also global. Google’s reliability guidance says topics and subscriptions cannot be tied to a region as namespace objects, although resource configuration is replicated to local data stores. If administrative operations and namespace isolation are also required, Pub/Sub may not satisfy that broader requirement without a different service decision.

Policy changes are not retroactive

Changing a topic’s message storage policy affects messages published after the update. Google states that messages already stored under the earlier policy are not moved to comply with the new one. Tightening a topic from several regions to one therefore does not prove that every retained message now sits in the final region.

Organization policy has another drift boundary. New topics can inherit the effective Resource Location Restriction policy, but later organization-policy changes do not automatically propagate to existing topics. An existing topic can become inconsistent with current organization requirements until it is updated.

Migration evidence should separate old and new messages. Record the topic policy before and after the change, the effective timestamp, retention settings, backlog state, regional storage metrics, and the point at which pre-update messages expire or are otherwise handled under an approved plan. Do not claim retroactive relocation without direct service evidence.

The availability cost of one allowed region

A single allowed region creates a deliberate failure boundary. Google’s configuration guide says a distributed application with publishers in several regions becomes only as available as the one allowed region. Adding other publisher locations does not restore storage availability when the policy permits only one destination.

In-transit enforcement can also reject clients that enter through the wrong region instead of routing their requests. Push and export dependencies may stop delivery when their location constraints cannot be satisfied. Ordering and exactly-once behavior have endpoint requirements that also need review for the chosen client.

Document the trade. If regional isolation wins, define what the application does during a regional Pub/Sub outage: stop intake, retain data in another approved component, return an error, or use a separately approved recovery design. Do not silently widen the allowed-region list during an incident. The comparison of serverless health-data island cost drivers also shows why resilience and architecture choices need to be evaluated together.

HIPAA coverage is a separate gate

Google’s HIPAA guide lists Pub/Sub among products covered by the Google Cloud BAA. It also says compliance is a shared responsibility. Customers must accept the BAA where required, use covered products, and configure and secure the applications they build. Google does not present the product list as certification of the customer’s workload.

Message storage policy is one technical control within that larger system. Identity, least privilege, encryption decisions, logging, retention, subscriber behavior, dead-letter handling, exports, backups, incident response, and downstream services remain part of the customer design. A covered service can still be used in an unsuitable flow.

Keep product boundaries explicit. A Google Cloud BAA does not follow a message into an unrelated destination. See why a Google Cloud BAA does not cover Google Ads. Contract scope also does not authorize unrelated reuse, as the BAA and cross-tenant benchmarking review explains.

A verification checklist for a single-region topic

  1. Choose one supported Google Cloud region through the organization’s approved architecture process.
  2. Create or update the topic with only that region in allowedPersistenceRegions.
  3. Set enforceInTransit to true and use the matching regional endpoint.
  4. Verify publisher, pull subscriber, streaming pull, push, export, transform, and dead-letter dependencies against the same region boundary.
  5. Test allowed and disallowed routes with synthetic messages and preserve the results.
  6. Inspect existing topics for drift after organization-policy changes.
  7. Separate pre-update messages from messages published under the new policy.
  8. Monitor stored-message metrics by region and alert on unexpected location or delivery failure.
  9. Exercise the documented outage behavior without widening the policy automatically.

This checklist is editorial guidance derived from current Google documentation. It is not a Google guarantee, a HIPAA requirement, or a complete security program. For queue operations and reconciliation evidence, the outbox reporting guide offers a related state model, although its advertising use case is separate from this health workload.

Frequently asked questions

Does one allowed persistence region keep every Pub/Sub datum there?

No. Google says the policy applies to message contents, not topic names, labels, or IAM settings. Pre-existing messages also remain governed by the policy in effect when they were published.

Can a client keep using the global endpoint?

Google advises using a regional endpoint for strict residency with in-transit enforcement. A global-endpoint request may reach a disallowed region and fail, especially from outside Google Cloud or from a client deployed in another region.

Does single-region configuration improve availability?

Not generally. It limits the service to one allowed region for this topic and creates a regional dependency. The design should record that trade and define outage behavior.

Does Pub/Sub’s place on the covered-product list make the workload HIPAA compliant?

No. Google’s guide describes shared responsibility. BAA scope and product coverage are provider facts; the customer remains responsible for the application, configuration, access, data flow, and compliance assessment.

References

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

cmsapointoo on August 16, 2026

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

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

The three-part Article 22 threshold

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

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

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

Scheduling support versus appointment eligibility

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

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

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

What SCHUFA changes about upstream scores

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

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

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

Exceptions do not remove the safeguards

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

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

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

Health data creates an additional restriction

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

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

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

Explanation, intervention, and contest must work in practice

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

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

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

A product review that preserves the legal boundary

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

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

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

Frequently asked questions

Does automatically sorting appointment slots trigger Article 22?

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

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

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

Can explicit consent always authorize automated health eligibility?

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

Must the controller reveal its source code?

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

References

How a HIPAA Business Associate Supports a Patient Access Request

cmsapointoo on August 16, 2026

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

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

Who is responsible for the access request?

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

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

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

What records can the business associate hold?

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

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

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

How does the 30-day clock work?

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

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

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

What must the business associate agreement cover?

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

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

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

What should the software workflow do?

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

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

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

Where should decisions and denials remain?

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

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

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

An evidence checklist for covered entities and vendors

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

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

Frequently asked questions

Does a business associate have to answer every patient directly?

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

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

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

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

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

Can the associate send a summary instead of the records?

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

References