Does Lowering CloudWatch Logs Retention Delete Healthcare Audit Events Immediately?

cmsapointoo on August 16, 2026

Lowering an Amazon CloudWatch Logs retention setting does not delete older healthcare audit events immediately. AWS marks events for deletion when they reach the configured age. The physical deletion normally takes up to 72 hours and can take longer in rare cases. That delay matters whenever a team must prove what was retained, removed, or still recoverable.

CloudWatch also stops counting marked events toward archival storage and the storedBytes metric. A lower bill or a smaller metric can therefore appear before physical deletion finishes. HIPAA’s audit-controls standard requires mechanisms to record and examine system activity, but it does not prescribe CloudWatch, a retention duration, or a deletion workflow.

What happens when CloudWatch retention is lowered?

CloudWatch applies the new retention policy to events in the selected log group. Events older than the new period become eligible for deletion. AWS describes the first state as being marked for deletion, followed by physical removal that normally occurs within 72 hours. Rare cases may take longer.

The change can catch a large historical range at once. A group kept indefinitely yesterday might receive a shorter policy today. Events already beyond that age do not pass through a new full retention cycle. They enter the deletion path under the changed setting.

That is why an operator should record the log group ARN, old value, new value, change time, approver, and affected date range. A general screenshot of the console leaves too much unanswered. The related review of Azure Log Analytics deletion behavior reaches the same operational lesson: changing a container or setting is not the same as proving stored records disappeared.

Why does the 72-hour deletion window matter?

The 72-hour statement creates a verification window, not a service-level promise that every event disappears at exactly hour 72. AWS says deletion typically takes that long and may take longer. A team should avoid wording such as “all logs were erased immediately” or “deletion completed after three days” unless its own evidence supports that claim.

AWS also advises waiting until 72 hours after the previous retention period ends before changing a group back to a longer period. The reason is practical. Events marked under the shorter setting may still be pending physical deletion, and a later configuration change should not be mistaken for recovery or proof of removal.

Use a clear time line. Record when the policy changed, when the affected events crossed the age boundary, and when the team performed its verification. If the check happens early, label the result “pending deletion” instead of complete. That wording prevents a privacy response or audit package from outrunning the provider’s documented behavior.

Why can storedBytes fall before deletion is complete?

AWS excludes events marked for deletion from archival storage calculations and from the storedBytes value returned by DescribeLogGroups. This is useful for billing and storage reporting, but it also creates a tempting false signal. The number can fall while physical deletion remains underway.

A finance dashboard, cost alert, or API snapshot should not become the sole deletion record. Keep metric evidence because it helps reconstruct the operation. Pair it with the policy value, event age, provider timing, downstream copy inventory, and a later state check.

The same separation applies to search results. If an event no longer appears in a routine query, confirm that the query covered the right group, account, Region, time range, and log class. Query absence may support the review, but it cannot speak for exports or another destination.

What does HIPAA require from audit controls?

Section 164.312(b) requires covered entities and business associates to implement hardware, software, or procedural mechanisms that record and examine activity in information systems containing or using electronic protected health information. It states an outcome. It does not name CloudWatch, define one retention period, or say that shortening retention satisfies disposal duties.

The organization must decide which systems and events support its audit program. It also decides who reviews them and how exceptions are handled. A cloud configuration is evidence of one technical control, not a substitute for the risk analysis, policy, contracts, or legal review that set the period.

CloudWatch application logs and CloudTrail audit records answer different questions. One can capture application or service output. The other records AWS activity according to its trail and event configuration. Before shortening either path, map the control objective to the actual evidence source.

Which copies sit outside the log group’s retention policy?

A CloudWatch log group’s policy governs events in that group. It does not automatically delete copies exported to another service, forwarded through a subscription, written by an application elsewhere, included in an incident package, or retained in a separate account. Each destination has its own controls and schedule.

Build a small data-flow record before the change. Name the producer, log group, subscription filters, delivery streams, archive buckets, analytics stores, monitoring tools, and approved manual exports. Do not assume an empty list. Verify the live configuration and access paths.

Regional design matters too. A log group and an audit archive can have different homes. The article on regional Google Cloud logging describes a provider-specific implementation, but its boundary test transfers cleanly: storage location, routing, retention, and deletion are separate properties.

How should a healthcare team shorten retention safely?

Start with the decision, not the console. Identify the log classes affected and the approved reason for the shorter period. Confirm that no legal hold, incident investigation, contract, or audit requirement depends on the older events. Then map every destination before changing the setting.

  1. Capture the account, Region, log group ARN, current policy, and current time.
  2. Identify the oldest and newest event dates affected by the proposed value.
  3. Confirm the control owner and obtain required legal or security approval.
  4. Preserve only the evidence that must remain, in an approved destination.
  5. Inventory subscription filters, exports, archives, and manual incident copies.
  6. Apply the policy to the named group and record the successful API response.
  7. Allow for AWS’s documented deletion window before claiming completion.
  8. Verify the resulting state and record any downstream work separately.

Use synthetic test events when possible. They let the team validate age calculations, queries, and access without placing protected records in a ticket. If the change is broad, test one nonproduction group first. A careful rehearsal catches time-zone errors and dashboards that treat storedBytes as a deletion certificate.

What evidence supports a defensible deletion statement?

A defensible statement stays narrow: the named log group received a specified retention value at a recorded time; events older than that value entered AWS’s deletion process; verification occurred after the documented window; and listed downstream destinations received their own checks. It does not claim more than those facts prove.

Keep the configuration request and response, change record, approval, log-group identity, affected date range, and verification result. Use counts or synthetic identifiers rather than copying protected content. Record exceptions with an owner and next review date.

Provider comparisons can help reviewers spot hidden assumptions. For example, Google Cloud Pub/Sub regional controls concern message storage rather than CloudWatch deletion. The useful comparison is methodological: verify each service’s precise resource, route, timing, and exception instead of applying one cloud product’s behavior to another.

Frequently asked questions

Does lowering retention delete old CloudWatch events at once?

No. Events beyond the new retention age are marked for deletion. AWS says physical deletion typically takes up to 72 hours and can take longer in rare cases.

Does a drop in storedBytes prove deletion?

No. AWS excludes marked events from storedBytes before physical deletion necessarily finishes. Treat the metric as supporting evidence and verify timing, scope, and downstream copies separately.

Does HIPAA require a specific CloudWatch retention period?

Section 164.312(b) requires audit mechanisms that record and examine activity. It does not specify CloudWatch or one duration. The organization must set retention from its applicable duties, risks, contracts, and evidence needs.

Can increasing retention restore events marked for deletion?

Do not rely on it. AWS advises allowing the earlier deletion process to finish before increasing retention. Preserve required evidence before shortening the policy rather than treating a later increase as recovery.

References

SaaS de agenda médica precisa guardar registros de acesso por seis meses pelo Marco Civil?

cmsapointoo on August 16, 2026

Um SaaS de agenda médica pode estar sujeito à guarda de registros de acesso a aplicações por seis meses, mas essa regra não manda conservar por seis meses todo o conteúdo da agenda. O Marco Civil da Internet define esse registro de forma estreita: data e hora de uso da aplicação a partir de determinado endereço IP.

O artigo 15 aplica o prazo a provedores de aplicações constituídos como pessoa jurídica e que exerçam a atividade de forma organizada, profissional e com fins econômicos. A análise ainda precisa considerar o papel real da empresa, a operação no Brasil e eventual ordem para preservação por prazo superior. Depois vem outra pergunta: quais outros dados podem ou devem ser guardados sob a LGPD?

Qual registro o Marco Civil manda guardar?

O artigo 5º, inciso VIII, chama de registro de acesso a aplicações o conjunto de informações sobre data e hora de uso de uma aplicação a partir de determinado endereço IP. Essa definição importa porque limita o objeto da regra. Ela não inclui automaticamente o conteúdo digitado, o motivo do contato, as mensagens, o histórico clínico ou todo evento técnico emitido pelo sistema.

Em uma agenda, o time pode produzir vários registros com nomes parecidos. O servidor web registra requisições. A camada de segurança registra tentativas de autenticação. O produto registra criação, alteração ou cancelamento de horários. A integração registra entregas e falhas. Só chamar tudo de “log” não torna os conjuntos equivalentes ao registro definido no artigo 5º.

A equipe deve manter um dicionário simples. Para cada conjunto, registre campos, origem, finalidade, prazo, leitores e destino final. Esse mapa também ajuda a responder um pedido LGPD de acesso à agenda sem entregar registros de segurança que não pertençam ao escopo aprovado.

Quem entra na regra de seis meses?

O artigo 15 dirige a obrigação ao provedor de aplicações de internet constituído como pessoa jurídica e que exerça essa atividade de forma organizada, profissional e com fins econômicos. Para quem se enquadra, os registros de acesso devem ser mantidos por seis meses, sob sigilo, em ambiente controlado e seguro.

Esse texto exige uma análise do serviço e da entidade, não apenas do setor do cliente. Uma empresa não escapa da pergunta porque se apresenta como ferramenta administrativa. Também não se enquadra apenas porque atende uma clínica. O jurídico deve relacionar a definição legal ao fluxo efetivamente oferecido e documentar a conclusão.

O prazo ordinário também não elimina ordens específicas de preservação. O Marco Civil permite que autoridade policial, administrativa ou Ministério Público requeira cautelarmente a manutenção de registros por prazo superior, dentro do procedimento legal. Por isso, uma rotina automática precisa aceitar bloqueio jurídico para registros identificados, sem congelar indiscriminadamente todo o banco.

Seis meses começam quando e terminam como?

A definição legal vincula o registro ao momento de uso da aplicação. Na prática, uma política deve explicar como o sistema calcula o vencimento a partir do evento registrado, qual fuso foi adotado e como trata relógios inconsistentes. O texto da lei não fornece uma arquitetura, um formato de timestamp ou um produto de nuvem. Essas decisões pertencem ao controle técnico.

O vencimento do prazo não deve ser confundido com exclusão imediata de todo dado relacionado à conta. Primeiro, identifique qual registro completou seis meses. Depois, verifique se há preservação válida, outra obrigação ou disputa que alcance aquele conjunto. Por fim, execute a regra de destino e confirme as cópias abrangidas.

Uma fila de expiração pode falhar em silêncio. Por isso, acompanhe eventos elegíveis, eventos processados, exceções autorizadas e erros. A prova adequada não é uma planilha com linhas pessoais. Use contagens, identificadores de execução, configurações aprovadas e amostras sintéticas. O artigo sobre eliminação de prontuário e dados de marketing mostra por que cada conjunto precisa de prazo próprio.

Guardar o registro autoriza usar os dados para outra finalidade?

Não. Dever de guarda e liberdade de uso são questões diferentes. O artigo 16 do Marco Civil veda a guarda de dados pessoais excessivos em relação à finalidade para a qual o titular consentiu seu tratamento. Também restringe a guarda de registros de acesso a outras aplicações sem consentimento prévio, respeitadas as condições legais.

A LGPD reforça a separação. O princípio da necessidade limita o tratamento ao mínimo pertinente, proporcional e não excessivo. Finalidade e adequação exigem compatibilidade entre o que foi informado e o uso real. Segurança e prevenção exigem medidas contra acesso, perda, alteração ou tratamento inadequado.

Logo, a retenção do registro legal não autoriza enriquecer perfil comercial, reconstruir comportamento ou manter campos extras “para o caso de precisar”. Se uma equipe pretende usar outro conjunto para suporte, fraude, faturamento ou segurança, ela deve definir finalidade, fundamento e prazo próprios. A análise sobre legítimo interesse em formulários de agendamento explica por que dados sensíveis não cabem numa justificativa genérica.

Como separar registro de acesso, auditoria e dados da agenda?

Comece por três caixas, mesmo que a infraestrutura guarde tudo no mesmo serviço. A primeira contém somente o registro de acesso definido no Marco Civil. A segunda contém eventos internos de auditoria e segurança, como alteração de permissão ou mudança de configuração. A terceira contém dados funcionais da agenda. Misturar armazenamento físico não elimina essa separação lógica.

Cada caixa precisa de uma política. O registro legal recebe o prazo e as salvaguardas aplicáveis. O log de auditoria recebe prazo baseado em risco, obrigações, contratos e necessidade operacional. A agenda segue sua finalidade e as normas relevantes. Campos compartilhados devem manter controles coerentes, mas não herdam automaticamente o maior prazo encontrado.

Considere uma alteração de disponibilidade feita por um administrador. O registro de acesso pode documentar data, hora e IP de uso. O log de auditoria pode registrar que uma configuração mudou. A agenda passa a mostrar outro horário. São três fatos ligados, porém com finalidades diferentes. O sistema deve conseguir expirar um sem quebrar a integridade dos outros.

Que controles tornam a guarda defensável?

O artigo 15 não pede apenas retenção. Ele exige sigilo e ambiente controlado e seguro. Uma implementação defensável restringe leitura, registra ações administrativas, protege chaves e credenciais, monitora exportações e testa a expiração. O desenho deve reduzir cópias informais, pois uma exportação manual pode sobreviver ao ciclo do sistema principal.

  1. Documente o enquadramento do provedor e a versão da análise jurídica.
  2. Defina o esquema mínimo do registro de acesso e rejeite campos extras.
  3. Separe permissões de leitura, operação e alteração de retenção.
  4. Registre mudanças de configuração sem copiar o conteúdo protegido.
  5. Implemente expiração por evento e bloqueio para preservação autorizada.
  6. Teste a busca, a restrição de acesso e o vencimento com dados sintéticos.
  7. Revise réplicas, exportações e cópias sob responsabilidade de operadores.
  8. Guarde evidência proporcional da execução e das exceções.

Responsabilidades contratuais também precisam acompanhar o fluxo. O conteúdo sobre BAA, DPA e contrato de operador ajuda a distinguir instrução do controlador, dever do operador, subcontratação e retorno ou eliminação no encerramento. Contrato não corrige retenção mal configurada, mas reduz zonas sem dono.

Como responder a um pedido de eliminação?

Um pedido de titular não deve acionar uma exclusão cega nem uma recusa automática de seis meses. Localize os conjuntos abrangidos, separe o registro legal dos demais dados e examine o estágio do prazo. A resposta deve explicar de forma clara o que foi eliminado, bloqueado, conservado ou encaminhado a outro agente, conforme o caso.

A LGPD prevê hipóteses de conservação após o término do tratamento no artigo 16. Elas são específicas e não criam permissão geral para manter todo o perfil. Se a organização conservar determinado registro, restrinja os usos à finalidade aprovada e impeça que o item volte a alimentar rotinas incompatíveis.

Um pedido pode também revelar acesso indevido, cópia desconhecida ou falha de expiração. Nesse caso, o atendimento ao titular e o processo de incidente seguem trilhas coordenadas, mas distintas. O guia sobre comunicação de incidente à ANPD aborda avaliação de risco, agentes envolvidos e registro da decisão.

Perguntas frequentes

Todo log de uma agenda médica deve ficar seis meses?

Não. O Marco Civil define um registro específico composto por data, hora e endereço IP de acesso à aplicação. Logs de auditoria, integrações e dados funcionais exigem análise própria de finalidade, fundamento, risco e prazo.

O SaaS pode apagar o registro antes de seis meses se o usuário pedir?

Não deve decidir isso por um comando genérico. Se o provedor estiver sujeito ao artigo 15, a obrigação de guarda precisa entrar na análise. Outros dados do pedido podem receber eliminação, bloqueio ou conservação distinta.

Uma ordem pode estender o prazo?

Sim. O Marco Civil prevê procedimento para preservação cautelar de registros por prazo superior. A organização deve validar a ordem e restringir o bloqueio aos registros alcançados, com acesso controlado e evidência da decisão.

Se o banco usa criptografia, a obrigação está cumprida?

Não. Criptografia pode apoiar segurança, mas o artigo 15 também exige sigilo e controle. Escopo mínimo, permissões, monitoramento, expiração, cópias e resposta a incidentes continuam relevantes.

Referências

Why Did Google Calendar Return 410 Gone During Incremental Appointment Sync?

cmsapointoo on August 16, 2026

Google Calendar returns HTTP 410 Gone during token-based incremental sync when the stored syncToken is no longer valid. Google says token invalidation can follow expiration or related access-control changes. The required recovery is to clear the client’s synchronized calendar store and run a new full sync to obtain a fresh token.

For an appointment integration, “clear the client store” should mean the local Google Calendar mirror built from that token. It should not mean deleting the clinic’s source-of-record bookings, webhook evidence, marketing attribution, or other independent records. That boundary is an operational interpretation that must be designed and tested before the first 410 occurs.

Why does an incremental sync token return 410 Gone?

Google’s synchronization guide says an invalidated token produces HTTP 410. It names token expiration and changes in related access-control lists as reasons a token may become invalid. The server can no longer use that token as a reliable cursor through the calendar’s change history.

A 410 is therefore different from “no changes.” An empty incremental result can mean the token remains valid and nothing in scope changed. A 410 means the client must stop using that cursor. Retrying the same request with the same token does not satisfy Google’s documented recovery.

Do not assume the event list itself is damaged. The error concerns the synchronization cursor and local incremental state. Rebuilding that state is expected behavior in a long-running integration, so the recovery path belongs in normal application logic rather than an emergency script.

If the problem happened while computing availability rather than mirroring event changes, use why a Google Calendar FreeBusy error is not an open provider slot. FreeBusy queries and sync tokens solve different problems.

Does every Google Calendar 410 mean the same thing?

No. Google’s error guide documents more than one 410 scenario. A request using an invalid syncToken or updatedMin requires the client to wipe its synchronized store and synchronize again. A delete request for an event that is already deleted can also return 410, but Google says no further action is needed for that delete.

Classify the operation before choosing a remedy. If the failing request is an incremental event-list call with syncToken, start a full resync. If the failing request tried to delete one event and the response says it is already deleted, do not erase the whole mirror.

Operational inference: attach an operation type to each error record: incremental list, full list, event delete, or another Calendar action. Status code alone is too coarse. The same number can lead to very different safe responses.

Keep the distinction visible in alerts. “Calendar API 410” sends an operator toward guesswork. “Incremental list token invalidated, mirror rebuild started” states the condition and action without exposing event content.

What should be cleared before the full resync?

Google instructs the client to clear its store and perform a full sync after token invalidation. In an appointment system, the store tied to the token is usually a local mirror of Google event state. Its records can be rebuilt from the authorized calendar. Independent booking records need a different retention and deletion contract.

Define that boundary in code and data ownership. A table or cache populated exclusively by Google sync may be replaceable. An appointment record created by the clinic, a payment record, consent evidence, or original booking-source attribution is not merely a sync cache. Do not cascade a calendar reset into those systems.

Operational inference: mark the affected calendar mirror as rebuilding before clearing it. While rebuild is incomplete, fail closed for slot publication if the mirror participates in availability. A partially repopulated calendar should not be presented as a complete free-time view.

Google Calendar can also be a secondary blocking calendar for another scheduler. The article on secondary Google calendars not blocking Jane online booking shows why calendar coverage must be proven at the actual scheduling boundary.

How should a new full sync be performed?

A full sync retrieves the calendar collection page by page. Google’s guide says the last page includes nextSyncToken. The client must finish every page before treating the new full sync as complete and before replacing its stored token.

Build the replacement mirror in a recoverable way. One option is a separate generation that becomes active only after all pages succeed. Another is a transaction or checkpointed rebuild suited to the local data size. These are operational designs, not Google requirements. The acceptance condition is that incomplete data never masquerades as a completed calendar.

Use the approved full-sync query parameters consistently across pagination. Preserve the page token until the final page arrives. If a middle page fails, do not store a token from an earlier page as though it represented the completed collection.

Once the final page is applied, persist its nextSyncToken with the calendar identity, sync generation, completion time, and relevant query configuration. Keep the token out of logs when it can be correlated through an internal fingerprint.

How do incremental pages and deletions affect correctness?

Google’s synchronization guide says incremental sync returns entries changed since the previous token, including deleted entries. It can also paginate. Every page in one incremental cycle belongs to the same cursor progression, and the new nextSyncToken arrives on the final page.

Apply deleted entries to the local mirror rather than filtering them out before state reconciliation. Otherwise an event removed in Google can remain as a permanent false block. A deletion in the mirror does not automatically mean deleting an appointment from the clinic’s source system. It means Google’s current calendar representation no longer includes that event.

Operational inference: make page application idempotent and save a completion checkpoint. If the worker crashes after page two, replay should not duplicate events or expose a half-applied sync. Advance the durable sync token only when the full page chain has succeeded.

Do not change the incremental query shape casually. Google’s guide restricts query parameters used with sync tokens. Treat the token and the request configuration that produced it as one sync contract. A different filter belongs to a new full-sync generation.

What recovery sequence protects appointment availability?

The recovery should make uncertainty explicit. Stop publishing availability that depends on the stale mirror, preserve the 410 evidence, invalidate the local token, rebuild from a full sync, and reopen only after the new generation is complete. Do not interpret the empty rebuilding store as a calendar with no busy events.

  1. Confirm the failed operation is a token-based incremental list request.
  2. Mark the affected calendar mirror unavailable or rebuilding.
  3. Discard the invalid sync token.
  4. Clear or replace only the token-bound mirror.
  5. Run a full paginated sync and process deleted states correctly.
  6. Persist the final page’s nextSyncToken.
  7. Compare mirror coverage with the expected calendar before republishing slots.

If the clinic’s booking engine has another authoritative availability source, it may use that source under an approved rule. Do not invent a silent fallback during an incident. Operators and patients should not see stale Google-derived openings presented as current.

Availability evidence also should not rewrite acquisition evidence. See appointment source versus marketing source before allowing a resynced event to replace the original channel.

How can the 410 recovery be tested?

Use a synthetic calendar with neutral event titles and no real patient information. Build an initial full sync, store the resulting token, and confirm one incremental change. Then simulate the application’s 410 branch with a controlled invalid-token response or approved test seam.

The test should prove more than a second API call. Verify that the old mirror is marked incomplete, authoritative appointment records remain untouched, all full-sync pages are applied, deleted entries reconcile correctly, and the final page supplies the only newly stored token.

Interrupt one rebuild between pages. On restart, the system should resume or safely restart according to its documented design without publishing partial availability. Then test a 410 from an already-deleted event operation and confirm it does not trigger the incremental-sync reset branch.

Preserve technical evidence: calendar identifier or approved alias, sync generation, operation type, page count, response status, token fingerprint, start time, completion time, and result. Keep event titles, descriptions, attendees, patient names, contact details, and clinical notes out of general logs.

What monitoring catches a broken sync early?

Monitor the age of the last completed sync, the age of the active token, consecutive failures, rebuild duration, expected versus mirrored calendar identity, page count, and whether availability publication is blocked. These are operational indicators. Google does not prescribe their alert thresholds.

A healthy HTTP response is not enough. The integration must reach the final page and save its token. An alert should distinguish a fetch in progress from a completed generation, and a dashboard should not label a calendar current while its replacement mirror is rebuilding.

Track booking outcomes separately from synchronization health. The clinic booking outcome taxonomy for Google Ads helps keep a calendar recovery from being counted as a new lead, cancellation, or conversion.

Close the incident after a controlled incremental change appears in the rebuilt mirror and availability uses the complete generation. Document why the token became unusable if known, but do not delay the required full sync while trying to prove expiration versus an access-control change.

Frequently asked questions

Can I retry the same sync token after HTTP 410?

No. Google says an invalid sync token requires a full synchronization. Discard the token, rebuild the token-bound local store, and save the new nextSyncToken from the final page.

Should a 410 delete the clinic’s appointment database?

No. Google’s instruction concerns the client’s synchronized calendar store. Keep the Google mirror separate from authoritative bookings and other records, then rebuild only the state derived from that calendar sync.

When should nextSyncToken be saved?

Save it after the final page of a successful full or incremental sync. A token from an incomplete page sequence cannot prove that the local mirror includes the complete change set.

Are deleted Google events included in incremental sync?

Yes. Google’s synchronization guide says incremental results include deleted entries. Apply them to the calendar mirror so a removed event does not remain as a false busy block.

References

Why Does Zocdoc Not Retry an Appointment Webhook After HTTP 500?

cmsapointoo on August 16, 2026

Zocdoc does not retry an appointment webhook because your endpoint returned HTTP 500. Its webhook guide states that retries depend on transport failure: Zocdoc could not connect, received no response within five seconds, or lost the connection before a response arrived. The status code in a completed HTTP response is not a retry trigger.

A receiver that sends 500 after a database or queue failure can therefore lose the update if it expects Zocdoc to deliver it again. The safer operational design is to authenticate the webhook, persist enough verified event data for recovery, and only then complete the response. That design is an implementation recommendation, not a promise made by Zocdoc.

Why does HTTP 500 not cause another delivery?

Zocdoc’s Webhooks guide says the service does not retry based on the HTTP status code returned by the receiving endpoint. A 500 response tells your own monitoring that the handler failed, but it does not meet Zocdoc’s documented conditions for another attempt.

This can feel counterintuitive because many webhook providers treat a non-success status as a negative acknowledgement. Zocdoc documents a different boundary. Once it establishes a connection and receives a response within the time limit, the response code does not decide whether the event enters the retry schedule.

A concrete failure sequence is short. The endpoint verifies a request, tries to write to a queue, the queue write fails, and the handler returns 500. If the connection stayed intact and the response arrived within five seconds, the receiver should not wait for another Zocdoc delivery. It needs its own evidence and recovery procedure.

This transport rule is separate from which appointment changes produce webhooks. Read which Zocdoc cancellations and reschedules trigger a webhook before diagnosing a missing event. Sometimes no webhook is expected because the initiating path should use the API response.

Which failures does Zocdoc retry?

The guide lists three retry conditions: Zocdoc cannot connect to the endpoint, no response arrives within five seconds, or the connection is severed before Zocdoc receives a response. For those failures, Zocdoc retries with exponential backoff for up to 48 hours after the first attempt.

These rules create two distinct risks. Respond too slowly and Zocdoc may retry while the original handler continues to work. Respond quickly with 500 and Zocdoc may not retry at all. The receiver must tolerate duplicate delivery without using an error status as a request for redelivery.

Operational inference: make event handling idempotent. A repeated event should lead to the same appointment state rather than applying the transition twice or sending another message. The guide to preventing duplicate appointment reminders covers one downstream consequence when retries are not contained.

Do not deliberately hold the connection open or interrupt it to force a retry. That relies on transport behavior as a queue, can create concurrent attempts, and offers no durable record inside your system. Build recovery where your team can observe and control it.

How should the signature and timestamp be checked?

Zocdoc documents HMAC verification with the shared webhook key and SHA-256. It also instructs receivers to extract the webhook timestamp and reject stale requests. The guide shows five minutes as the default timestamp tolerance. These checks belong before a message can affect appointment state.

Use the exact request material required by the current Zocdoc algorithm. Do not parse and reserialize JSON before computing the signature if the documentation requires the received payload form. A harmless formatting change can produce different bytes and a failed HMAC comparison.

Compare signatures in a timing-safe way available in the implementation language. Keep the shared key in an approved secret store, never in source control or general logs. A failed signature or stale timestamp should stop processing and create a security signal without printing the key or full patient payload.

Operational inference: log a one-way event fingerprint, receipt time, verification outcome, and reason code. That is usually enough to correlate repeated delivery without copying names, contact details, visit reasons, or other patient information into observability tools.

Where should the durable acknowledgement boundary sit?

Zocdoc’s five-second response boundary favors a short receiver. A common operational pattern is: verify the request, write a compact event record to durable storage or a durable queue, and then respond. A worker applies the appointment update after the event is safe from process crashes.

This pattern is an engineering recommendation. The cited source defines delivery, verification, and retries, but it does not require one queue product or database design. The durable step must fit the practice’s security, privacy, retention, and availability requirements.

Do not acknowledge first and keep the only event copy in memory. If the process exits after the response, Zocdoc has completed a non-retryable delivery from its point of view. At the other extreme, do not perform long downstream work before responding if that work can exceed five seconds and provoke concurrent retries.

The stored event needs an idempotency boundary. Use a stable event fingerprint or documented event identifier when available, plus the relevant appointment and update type, without treating patient content as the deduplication key. Preserve the original booking lineage using the method described in preserving booking source after a reschedule.

How should processing failures be recovered?

A worker failure after durable receipt should move the event into a visible retry or review state. It should not disappear, and it should not depend on Zocdoc sending the request again. Record attempt count, last error category, next action, and final resolution without storing sensitive payload fields in general logs.

Operational inference: use bounded internal retries for temporary dependencies, then quarantine the event for review. Before replay, compare current local appointment state with the event’s intended transition. An old update may no longer be safe to apply mechanically after later changes.

A reconciliation job or operator check should compare provider-originated appointment changes with the local state using an approved API path. The Zocdoc webhook page establishes which provider updates can be notified, but it does not define your full reconciliation schedule. Document the clinic’s acceptable delay and escalation owner.

Do not turn a missing update into a new appointment. Duplicate booking is not a repair for uncertain state. If visit-reason mapping is part of the failure, inspect the guide to mapping Zocdoc visit reason IDs to EHR appointment types before replaying the write.

When should the API response update local state instead?

Zocdoc’s patient-booking guidance says webhook notifications cover provider-initiated appointment changes. Developer-initiated and patient-initiated actions use their API response as the evidence path. An integration should not wait for a webhook that the documented flow does not promise.

That initiator boundary avoids false missing-webhook incidents. If your application called an API to cancel or reschedule an appointment, store the result from that call and reconcile its outcome. Reserve webhook handling for the provider-side changes that Zocdoc sends.

Keep the evidence paths distinct but converge them into one appointment state machine. The same transition may arrive from an API response in one scenario and a verified webhook in another. Both paths need idempotency, audit history, and protection against an older result overwriting a newer state.

Acquisition attribution is a different field. A provider-initiated change should not replace the original channel with “webhook.” See appointment source versus marketing source for a clean separation between operational event origin and marketing origin.

What test demonstrates the HTTP 500 behavior?

Use Zocdoc’s supported test environment and synthetic appointment data. Configure a receiver that records only technical evidence. Never use a real person’s name, phone number, email, reason for visit, or clinical notes to prove retry behavior.

  1. Send a valid signed test event and confirm signature and timestamp verification.
  2. Return HTTP 500 within five seconds while preserving receipt evidence.
  3. Confirm that your system does not assume another delivery will arrive.
  4. Exercise a transport failure that matches a documented retry condition.
  5. Confirm repeated delivery produces one final state.
  6. Recover a durably stored event through the internal review path.

The test should distinguish what Zocdoc sent from what your receiver did. Capture connection outcome, response timing, response status, fingerprint, verification result, queue result, and processing result. Keep secrets and patient content out of the record.

Pass only when the 500 case remains visible without an expected provider retry, the retryable transport case is idempotent, and the stored event can be recovered. A unit test of the handler alone does not prove proxy timeouts, queue durability, or production monitoring.

What should an incident report preserve?

Record the webhook receipt time, endpoint and deployment version, connection outcome, response latency, status code, HMAC verification result, timestamp result, event fingerprint, durable-write result, worker outcome, and reconciliation decision. That sequence shows where the event stopped.

Avoid full request dumps. If a restricted forensic copy is required under clinic policy, keep it in the approved clinical or security boundary with limited access and retention. General application logs should use technical identifiers and redacted metadata.

Write the root cause plainly. “Returned HTTP 500 after queue failure and expected Zocdoc retry” is actionable. “Webhook missing” is not. Attach the source contract and the local test that proves the corrected acknowledgement boundary.

Finally, check outcome reporting. A recovered cancellation or reschedule should not create a second acquisition or booking conversion. The clinic booking outcome taxonomy provides a related reporting boundary.

Frequently asked questions

Will Zocdoc retry when my endpoint returns HTTP 500?

No. Zocdoc states that it does not retry based on the returned HTTP status code. A 500 response should trigger your own monitoring and recovery path, not an expectation of another webhook.

How long can Zocdoc retry a transport failure?

The Webhooks guide says retryable failures use exponential backoff for up to 48 hours after the first attempt. The receiver must still handle repeated events idempotently.

What response time avoids a timeout-based retry?

Zocdoc lists no response within five seconds as a retry condition. Keep the synchronous path short, but verify the signature and persist the event before acknowledging it under your approved design.

Do patient-initiated changes always produce a webhook?

No. For the patient-booking use case, Zocdoc says provider-initiated changes produce webhook notifications. Developer- and patient-initiated actions should update local state from the API response.

References

Why Does NexHealth Return Only One Operatory for the Same Available Time?

cmsapointoo on August 16, 2026

NexHealth can return only one operatory for a time that is open in several operatories because overlapping_operatory_slots defaults to false. The Available Slots reference says the endpoint returns one slot when the same time is available in multiple operatories. Set that parameter to true when the booking flow must receive every eligible operatory for the time.

The flag changes the response, but it does not remove the need to respect scope. Location, provider, operatory, appointment type, and local time still determine what the returned option means. A booking interface that groups records by clock time alone can erase the distinction again after the API has supplied it.

What does the endpoint return by default?

NexHealth’s Available Slots guide says that when the same appointment time is available in multiple operatories, only one slot is returned. The endpoint reference explains the switch behind that behavior: overlapping_operatory_slots is a Boolean query parameter whose default value is false.

This is a response contract, not evidence that the other operatory is occupied. A practice may confirm two open rooms in its scheduling system and still see one API choice for 10:00. Under the documented default, NexHealth chooses the first available operatory it finds for that overlapping time.

The distinction matters during diagnosis. If the response contains one operatory, do not start by changing working hours or creating duplicate availability. First capture the exact request and check whether the overlapping flag was absent or false. The separate guide on empty NexHealth availability despite an open EHR calendar covers cases where no eligible slot is returned at all.

Operational inference: record the query parameter explicitly in test fixtures, even when the application wants the default. That makes the intended behavior visible during review and prevents a library update or request builder from hiding whether the flag was sent.

How does overlapping_operatory_slots change the response?

When overlapping_operatory_slots is true, NexHealth says it returns all available slots for operatories at a given time instead of only the first one found. The option is useful when the application needs to preserve operatory choice, allocate rooms under its own approved rule, or show separate eligible resources.

The flag does not promise that every configured operatory will appear. It asks for all operatories that qualify under the rest of the request and scheduling configuration. An operatory outside the requested scope, without matching availability, or without the required mapping should not be inferred from another operatory’s result.

Compare two otherwise identical requests. Send the first with the parameter false and the second with it true. Use the same location identifiers, provider identifiers, appointment type, operatory filters, date window, and API version. A controlled comparison isolates the documented behavior better than comparing two calls made from different screens.

Be careful with a UI that deduplicates options. If the API returns two records and the application stores them in a map keyed only by 10:00, one record can overwrite the other. That would be a local data-shaping defect, not a NexHealth availability result.

Which request fields still control operatory scope?

The endpoint reference requires location scope through lids[] and provider scope through pids[], unless an appointment_type_id supplies the required scheduling context. The request can also include operatory_ids[]. NexHealth advises using those operatory identifiers when operatories are mapped in the practice management system.

Arrays make multi-resource searches possible, but they also make an accidental mismatch less obvious. A request can ask for the intended provider across the wrong location, or it can carry an operatory ID that belongs to a different configuration. Preserve the exact arrays and compare them with the response fields.

Appointment type affects slot length. The View available slots endpoint reference states that supplying appointment_type_id sets slot_length to the appointment type’s minutes. Without that field, a manually supplied slot_length applies, or the endpoint uses its documented 15-minute default. Two records that start at the same clock time may therefore belong to different booking contexts. Do not merge them merely because their displayed label matches.

Provider working-hour validation is another boundary. If the issue is a returned time outside the intended schedule, use NexHealth v3 appointment validation against working hours. The operatory overlap flag answers which eligible resources are returned, not whether a later appointment write should bypass scheduling rules.

Why is the clock time alone an unsafe identifier?

NexHealth documents that returned slot times use the location’s local time zone. A text value such as 10:00 only has meaning when it stays attached to the location and date. The response also carries provider, location, and operatory context. Those fields distinguish two resources that happen to share a start time.

A concrete synthetic example shows the risk. Suppose operatories A and B both qualify for the same provider at 10:00 in one location. With the flag false, the response may expose only A. With the flag true, the client may receive A and B. If the client reduces both records to one display string, it has recreated the default even though the API returned both choices.

Operational inference: use a composite internal key built from the returned scheduling identifiers and time, rather than a patient-facing time label. Keep that key through selection, confirmation, and write-back. Do not fabricate an operatory after the user selects a time.

This same separation helps attribution. An operatory is a scheduling resource, not a marketing source. The guide to appointment source versus marketing source explains why operational routing fields should not replace acquisition fields.

How should a booking flow preserve the returned choice?

First decide whether the user should choose an operatory or whether the application may allocate one under a documented clinic rule. If the choice matters, request overlapping operatories and keep separate options. If the clinic treats eligible rooms as interchangeable, it may choose a deterministic allocation rule, but that rule comes from clinic operations, not the NexHealth source.

Show only the information a patient needs. Internal operatory IDs rarely belong in a public label. The application can retain the ID while presenting a neutral time and location. When the user confirms, submit the exact selected resource context rather than repeating availability and guessing which record corresponds to the display.

Operational inference: perform a final availability check close to booking and handle a rejected choice without silently moving the appointment to another operatory. Availability can change between search and confirmation. This article does not claim a specific NexHealth reservation guarantee; follow the current appointment creation contract for the write.

After a successful booking, keep reminders idempotent. A resource-level retry should not create a second patient message. The workflow in preventing duplicate appointment reminders addresses that downstream problem.

What controlled test proves the behavior?

Create a synthetic scheduling case with one provider, one location, and two mapped operatories that are eligible for the same interval. Do not use a real patient’s appointment or clinical details. Record only the technical identifiers needed to reproduce the request.

  1. Confirm both operatories are eligible for the same local date and start time.
  2. Send one request with identical scope and overlapping_operatory_slots=false.
  3. Record the returned location, provider, operatory, and time fields.
  4. Repeat with overlapping_operatory_slots=true.
  5. Verify that the second response preserves the separate operatory results.
  6. Pass both results through the booking UI and confirm that local deduplication does not remove one.

Test one negative case too. Filter to a single mapped operatory and confirm the response does not invent the second resource. The overlap flag broadens representation of eligible matches; it should not defeat explicit request scope.

If the second API response contains both records but the interface shows one, inspect the client transformation. If the API still returns one, preserve the full request and response, confirm mappings, and escalate to NexHealth with synthetic evidence.

What should logs and support evidence contain?

Useful evidence includes request time, API version, location IDs, provider IDs, operatory IDs, appointment type ID when used, date range, slot length setting, overlap flag, response status, and returned technical resource IDs. Redact authorization headers and other credentials.

Do not log patient names, contact details, appointment reasons, insurance information, or free-text notes. The availability question can be reproduced before any patient enters the flow. A support packet filled with unrelated personal data creates risk without improving the operatory diagnosis.

Keep business outcome reporting separate as well. If the practice measures whether a shown slot became a booked visit, define the result with a stable taxonomy such as clinic booking outcomes for Google Ads. That report should not depend on which room appeared first in an API response.

Close the incident only after the API and interface both pass the same controlled case. A correct parameter in source code is not enough if an intermediary drops it, and a screenshot of two rooms in the EHR is not proof that the request asked NexHealth to return both.

Frequently asked questions

Does one returned operatory mean all other operatories are busy?

No. With overlapping_operatory_slots at its default false value, NexHealth returns only the first operatory found when several have the same available time. Check the parameter and request scope before changing availability.

Should I always set overlapping_operatory_slots to true?

Set it to true when the workflow needs every eligible operatory at the same time. If one returned resource is sufficient, the default may match the product design. The clinic should decide how resource allocation works.

Can I group returned slots by start time?

You can group them for display, but do not discard location, provider, operatory, date, or time-zone context. Keep each selectable record distinct through booking so one 10:00 option does not overwrite another.

Are returned slot times in UTC?

The Available Slots guide says times are returned in the location’s local time zone. Keep the location attached to the value and apply one explicit time-zone policy in the client.

References

Por que horários personalizados do Feegow não aparecem na agenda da Doctoralia?

cmsapointoo on August 16, 2026

Os Horários Personalizados do Feegow não aparecem na agenda da Doctoralia porque esse tipo de horário não é suportado pela integração. Segundo a documentação do Feegow, a Doctoralia recebe a grade padrão compartilhada do profissional. Criar ou editar um Horário Personalizado no Feegow, portanto, não faz esse intervalo surgir no canal externo.

A correção começa pela origem da disponibilidade. Se o intervalo precisa aceitar agendamentos online pela Doctoralia, ele deve estar em uma grade compatível e marcada para exibição no canal. Uma exceção de grade pode ser compartilhada. Já uma grade livre não entra nesse fluxo. Essa distinção evita o atalho perigoso de abrir um horário paralelo diretamente na Doctoralia sem entender quem passará a controlá-lo.

Por que o Horário Personalizado não chega à Doctoralia?

O motivo é uma limitação documentada da integração, não necessariamente uma falha de sincronização. O Feegow informa, nas dúvidas sobre Doctoralia, que os Horários Personalizados não são suportados e que apenas a grade padrão é integrada. O intervalo personalizado pode existir e funcionar dentro do Feegow sem aparecer na agenda externa.

Essa diferença costuma confundir porque as duas telas podem mostrar o mesmo profissional e o mesmo dia. Ainda assim, cada disponibilidade carrega uma origem e uma regra. O fato de a equipe ver uma abertura no Feegow não prova que ela pertence ao conjunto compartilhado com a Doctoralia.

Antes de investigar atrasos, filas ou credenciais, confira o tipo de grade. Se o horário foi criado como personalizado, esperar mais tempo ou refazer a mesma edição não altera o contrato publicado. O caminho é decidir se aquele intervalo deve entrar na grade compartilhada ou permanecer apenas no uso interno.

Há um caso vizinho que merece uma auditoria própria: uma disponibilidade pode ter sido criada diretamente na plataforma externa. O guia sobre como encontrar horários manuais na Doctoralia fora da integração com o Feegow ajuda a separar esse cenário da limitação dos Horários Personalizados.

Qual grade a integração realmente compartilha?

O artigo do Feegow sobre disponibilizar a grade na Doctoralia orienta o compartilhamento a partir da grade de horários do profissional. A configuração inclui a opção Exibir na Doctoralia. Sem essa marcação, a mera existência da grade não estabelece que ela será oferecida para agendamento online no canal externo.

Profissional e local também precisam corresponder ao escopo que a clínica pretende publicar. Uma abertura para o profissional certo, mas vinculada a outro local, não é equivalente. O mesmo vale para uma grade configurada em período diferente daquele pesquisado. Compare os campos lado a lado, em vez de usar somente a aparência do calendário.

Inferência operacional: mantenha uma tabela simples de controle com profissional, local, dia da semana, hora inicial, hora final, tipo de grade e estado da opção de exibição. Não inclua nome de paciente, motivo de consulta ou informação clínica. A tabela serve para provar a configuração, não para duplicar o prontuário.

Se o problema observado envolve feriado ou fechamento pontual, a causa e o teste são outros. Consulte por que um bloqueio de feriado no Feegow pode não fechar a agenda da Doctoralia antes de converter um bloqueio em mudança permanente da grade.

Como diferenciar grade padrão, exceção e grade livre?

A documentação citada permite uma distinção útil. A grade padrão é a base do compartilhamento. Uma grade de exceção pode ser marcada para exibição na Doctoralia. A grade livre, por sua vez, não é considerada pela integração. Horário Personalizado também não é suportado nesse fluxo.

Isso significa que uma exceção não precisa virar uma alteração permanente. Se um profissional atender em um intervalo fora do padrão por uma data específica, a equipe pode avaliar uma grade de exceção compartilhada, desde que a configuração atual do fornecedor e a política da clínica confirmem esse uso. Revise a documentação antes da mudança, pois telas e recursos podem mudar.

Não use a grade livre como substituto silencioso para a grade compartilhada. Ela pode cumprir outra função dentro do Feegow, mas o fornecedor diz que não entra na integração. Da mesma forma, renomear um Horário Personalizado não transforma sua natureza técnica.

Uma clínica com regras diferentes por convênio precisa revisar esse recorte separadamente. O artigo sobre horários exclusivos por convênio na integração entre Doctoralia e Feegow mostra por que uma janela comercial não deve ser presumida como uma restrição sincronizada.

Como corrigir sem abrir horários errados?

Comece registrando o estado atual. Escolha um único profissional, um local e uma data controlada. Anote qual intervalo deveria aparecer, em que tipo de grade ele está e se a opção de exibição está marcada. Só então ajuste a grade compatível. Essa ordem mantém a causa visível.

  1. Confirme que o intervalo ausente foi criado como Horário Personalizado.
  2. Decida, com o responsável pela agenda, se ele deve ser interno ou público.
  3. Se deve ser público, configure a disponibilidade em uma grade padrão ou de exceção compatível.
  4. Marque Exibir na Doctoralia no escopo correto.
  5. Confira profissional, local, data, início e fim antes de salvar.
  6. Espere apenas o período operacional previsto pela clínica e faça a verificação externa.

Inferência operacional: altere uma variável por vez. Se a equipe mudar tipo de grade, local, duração e canal na mesma tentativa, um resultado positivo não mostra qual ajuste resolveu o problema. Um resultado negativo também fica difícil de explicar.

Não crie uma disponibilidade direta na Doctoralia como primeira resposta. Isso pode estabelecer uma segunda origem de agenda, fora do controle esperado no Feegow. Se já houver um horário manual, preserve a evidência e siga o procedimento de auditoria antes de desativá-lo.

E se o horário estiver aberto diretamente na Doctoralia?

Um intervalo direto na Doctoralia não passa a ser integrado porque existe um horário parecido no Feegow. A documentação do Feegow reconhece a existência de disponibilidades criadas na plataforma externa sem integração. Compare o intervalo exato, o profissional e o local para saber se há uma abertura paralela.

Evite concluir que dois blocos visualmente iguais são o mesmo registro. Um pode vir da grade padrão compartilhada e o outro de uma configuração manual. Também pode haver diferença de duração. A equipe precisa identificar a origem antes de editar, pois remover o item errado pode fechar uma disponibilidade válida.

Inferência operacional: classifique cada intervalo como compartilhado, manual externo, personalizado interno, exceção compartilhada ou incerto. A categoria “incerto” é útil. Ela impede uma correção baseada em suposição e cria um ponto claro de escalonamento para o suporte.

Depois de uma remarcação, não use somente o rótulo local para julgar a sincronização. O guia sobre por que o status remarcado no Feegow não atualiza a Doctoralia separa a ação de remarcar de uma simples mudança de status.

Como testar a correção com segurança?

Use um cenário sintético aprovado pela clínica. Escolha um intervalo que possa ser aberto e fechado sem afetar pacientes. O teste deve usar um contato controlado que não alcance terceiros e não deve incluir diagnóstico, tratamento, observação clínica ou qualquer dado real de paciente.

Primeiro, confirme a grade no Feegow e a opção Exibir na Doctoralia. Depois, pesquise a disponibilidade no canal externo com o mesmo profissional, local e data. Faça uma reserva sintética e confirme se ela aparece no escopo correto. Verifique também se o intervalo deixa de aceitar outra reserva.

Se o fluxo da clínica inclui remarcação e cancelamento, teste essas ações com o mesmo registro sintético. Preserve os identificadores técnicos permitidos e as horas de cada etapa. Não copie telas com dados pessoais para uma planilha geral ou para um chamado.

Um teste aprovado cobre apenas a combinação executada. Regras distintas por local, profissional ou tipo de atendimento pedem novos casos. Se a clínica também usa Google Calendar, leia por que o link Doctoralia com Google não sincroniza o Feegow com o Google Calendar. São integrações diferentes.

Que evidência guardar para o suporte?

Guarde a menor evidência que permite reproduzir o problema: identificador técnico do profissional, local, data, intervalo, tipo de grade, estado de Exibir na Doctoralia, horário da tentativa e resultado observado. Inclua as etapas executadas e a diferença entre o esperado e o visto.

Não envie nomes, telefones, endereços, motivos de consulta ou capturas de prontuário. Se um identificador interno já basta para o suporte autorizado localizar a configuração, ele é preferível a dados pessoais. A investigação trata de disponibilidade e mapeamento.

Interrompa novas alterações quando a tela atual não corresponder à documentação, quando o tipo de grade não puder ser confirmado ou quando uma correção abrir horários além do escopo testado. Reverter a última mudança e preservar o estado é melhor do que empilhar tentativas.

Ao encerrar, registre o que foi modificado, quem aprovou, qual caso sintético passou e quais combinações continuam sem teste. Esse pequeno relatório ajuda a equipe seguinte a não recomeçar pelo palpite de que “a sincronização atrasou”.

Perguntas frequentes

Esperar mais tempo faz um Horário Personalizado aparecer na Doctoralia?

Não segundo o contrato documentado. O Feegow informa que Horários Personalizados não são suportados pela integração. Se o intervalo precisa ser público, avalie uma grade padrão ou de exceção compatível e marque a exibição no canal correto.

Uma grade de exceção pode ser exibida na Doctoralia?

Sim. O guia do Feegow informa que uma grade de exceção pode ser compartilhada. Confirme profissional, local, data e opção Exibir na Doctoralia, depois valide com um cenário sintético antes de liberar a disponibilidade.

A grade livre do Feegow entra na integração?

Não. A documentação afirma que grades livres não são consideradas. Não use uma grade livre como prova de que a Doctoralia deveria exibir o intervalo.

Posso abrir o mesmo horário manualmente na Doctoralia?

Uma configuração manual pode criar uma origem separada da grade integrada. Antes de fazer isso, confirme quem controlará o intervalo, como ele será fechado após reserva e como a equipe evitará disponibilidade duplicada. Se o horário já existe, audite sua origem antes de alterar.

Referências

Agenda online com dados de saúde exige RIPD antes do lançamento?

cmsapointoo on August 16, 2026

Uma agenda online não exige automaticamente um Relatório de Impacto à Proteção de Dados Pessoais apenas porque trata dados de saúde. A ANPD recomenda que o controlador elabore o RIPD antes de iniciar uma operação que possa gerar alto risco. A Autoridade também pode exigir o documento, inclusive em operações com dados pessoais sensíveis. São fundamentos diferentes de uma obrigação universal para todo formulário de clínica.

Enquanto não houver regulamento específico sobre RIPD, a ANPD indica como parâmetro, no que couber, o teste de alto risco da Resolução CD/ANPD nº 2/2022: ao menos um critério geral combinado com um critério específico. Dado de saúde satisfaz um critério específico, mas não encerra sozinho a análise. O controlador decide e documenta; o SaaS operador pode fornecer evidências técnicas, sem assumir a decisão jurídica da clínica.

O que é um RIPD na LGPD?

O artigo 5º, XVII define o RIPD como documentação do controlador que descreve processos de tratamento capazes de gerar riscos às liberdades civis e aos direitos fundamentais, além de medidas, salvaguardas e mecanismos de mitigação. O documento não é um selo do produto nem uma declaração curta de conformidade.

O artigo 38 permite que a ANPD determine ao controlador a elaboração do relatório, inclusive para tratamento de dados sensíveis. Seu conteúdo mínimo inclui tipos de dados coletados, metodologia usada para coleta e segurança das informações e análise das medidas e salvaguardas adotadas.

Um bom relatório precisa descrever a operação real. Para uma agenda, isso inclui campos visíveis e ocultos, finalidades, titulares, integrações, acessos, retenção, transferências, incidentes plausíveis e controles. O guia sobre base legal e dados de saúde no formulário mostra por que campo e finalidade não podem ser avaliados como um bloco único.

Quem responde pela elaboração?

A ANPD é direta: o controlador é responsável pelo RIPD. Na agenda de uma clínica, a identificação do controlador depende das decisões reais sobre finalidades e meios essenciais. O contrato e o rótulo comercial do fornecedor ajudam a registrar a relação, mas não mudam os papéis por vontade das partes.

O operador pode fornecer arquitetura, inventário de campos, subprocessadores, regiões, retenção, permissões, logs, testes e histórico de incidentes. A ANPD admite a consulta a operadores e considera desejável ouvir o encarregado. Essa colaboração não transfere ao fornecedor a decisão de prosseguir, modificar ou interromper o tratamento.

A divisão deve aparecer no contrato e no processo. O artigo sobre BAA, DPA e contrato de operador LGPD explica por que instruções, evidências e responsabilidades precisam acompanhar o papel efetivo, não apenas o título do documento.

Quando a ANPD recomenda preparar o relatório?

A orientação geral é elaborar o RIPD quando as operações possam gerar alto risco aos princípios da LGPD, às liberdades civis ou aos direitos fundamentais. A ANPD recomenda fazê-lo antes de iniciar o tratamento para a finalidade desejada. Isso permite avaliar probabilidade, impacto e salvaguardas antes de expor titulares.

Se não for possível preparar o documento antes, a orientação é elaborá-lo assim que o controlador identificar tratamento capaz de gerar alto risco. O relatório também deverá ser feito quando a ANPD o solicitar. Portanto, “antes do lançamento” é a sequência recomendada para uma operação identificada como potencialmente arriscada, não uma data legal automática para toda agenda.

O RIPD deve acompanhar mudanças relevantes. Novo campo clínico, integração, finalidade, decisão automatizada, grupo vulnerável, região, suboperador ou incidente pode alterar o risco. A ANPD recomenda revisão contínua quando fatos novos mudarem os fatores avaliados.

Como funciona o parâmetro de alto risco?

Enquanto não houver regulamento específico sobre RIPD, a ANPD diz que controladores podem usar, no que couber, o conceito do artigo 4º da Resolução nº 2. Esse conceito exige cumulativamente ao menos um critério geral e um critério específico.

Os critérios gerais são tratamento em larga escala ou tratamento que possa afetar significativamente interesses e direitos fundamentais. Os específicos incluem tecnologias emergentes ou inovadoras, vigilância de zonas públicas, decisões tomadas unicamente por tratamento automatizado e uso de dados sensíveis ou de crianças, adolescentes e idosos.

Uma agenda que trata dado de saúde pode preencher o critério específico de dado sensível. Ainda é preciso avaliar um critério geral no caso concreto. A própria ANPD diz que os critérios não são exaustivos para RIPD. Use-os como parâmetro documentado, não como calculadora que gera uma resposta universal.

Como avaliar uma agenda online no caso concreto?

Comece pelo fluxo, não pelo nome do produto. Uma agenda pode recolher somente contato e horário ou também motivo da consulta, especialidade, procedimento, documentos, respostas de triagem e dados de representante. Volume, frequência, duração, alcance geográfico e grupos vulneráveis mudam o risco.

Avalie efeitos possíveis sobre o titular: exposição de condição, discriminação, impedimento de serviço, fraude, perda de confidencialidade, indisponibilidade, alteração indevida ou uso incompatível. Um agendamento pediátrico merece análise própria; o conteúdo sobre LGPD, ECA Digital e melhor interesse ajuda a separar criança, responsável e finalidade.

Descreva também automações. Ordenar horários não é necessariamente uma decisão que afeta interesses, mas recusar, desviar ou atrasar acesso com base exclusivamente automatizada pode mudar a análise. Registre o que o sistema faz, os dados usados, as alternativas e a intervenção disponível.

O que deve entrar no documento?

A página da ANPD recomenda identificar agentes e encarregado, projeto, sistemas, categorias de titulares, dados pessoais e sensíveis, fontes, finalidades, compartilhamentos, transferências internacionais, retenção, descarte, hipóteses legais, riscos e medidas de mitigação. O nível de detalhe deve permitir compreender o tratamento e os riscos sem reproduzir dados reais de pacientes.

Use diagramas e exemplos sintéticos. Inclua interfaces, API, banco, filas, logs, backups, suporte e fornecedores. Registre quais campos chegam a cada destino e quem pode acessá-los. Uma lista genérica de serviços não mostra se texto clínico entra em analytics ou se uma equipe de marketing recebe o objeto inteiro.

O documento também precisa registrar decisões. Se uma área discordar do risco ou da salvaguarda, a ANPD considera boa prática manter a opinião e a justificativa da escolha. Ao final, o controlador avalia se prossegue, modifica ou interrompe o processo e acompanha a implementação das medidas.

O RIPD precisa ser enviado ou publicado?

Como regra geral, a LGPD não manda enviar automaticamente o RIPD à ANPD. A Autoridade pode requerer o documento e informações adicionais no exercício de suas atribuições. Mantenha uma versão controlada e pronta para revisão, sem tratar ausência de envio como dispensa de elaboração quando o risco justificar o relatório.

A publicação também não é obrigatória em regra para entidades privadas. A ANPD apresenta a divulgação como possível medida de transparência e admite uma versão pública diferente da interna para proteger segredos e outras informações resguardadas. Entidades públicas têm regras próprias.

Não publique arquitetura defensiva, credenciais, caminhos de ataque ou dados pessoais para demonstrar transparência. Uma versão pública pode resumir finalidades, categorias, riscos e salvaguardas sem expor controles sensíveis.

O que o RIPD não substitui?

O relatório não escolhe sozinho a hipótese legal, não corrige coleta excessiva e não transforma uma configuração insegura em aceitável. Base legal, finalidade, necessidade, transparência, direitos, segurança, contratos e resposta a incidentes continuam sendo decisões e controles próprios.

Também não substitui encarregado ou canal quando estes forem exigidos. A análise sobre encarregado em clínica pequena usa o mesmo teste de alto risco para uma finalidade regulatória diferente. Não copie a conclusão de uma obrigação para outra sem verificar o texto aplicável.

Se o relatório identificar risco de incidente, transforme a salvaguarda em procedimento testável. O guia sobre incidente com dados de saúde separa comunicação, papéis, prazo e registro. Citar esse fluxo no RIPD sem testá-lo não prova capacidade de resposta.

Um fluxo de decisão antes do lançamento

  1. Defina controlador, operadores, encarregado e aprovadores.
  2. Mapeie finalidades, campos, titulares, sistemas, destinos e retenção.
  3. Identifique dados sensíveis, vulneráveis, escala e possíveis efeitos.
  4. Aplique a combinação de um critério geral com um critério específico e registre outras condições de risco.
  5. Decida, com revisão qualificada, se o RIPD é recomendado ou exigido.
  6. Descreva metodologia, riscos, controles, lacunas e responsáveis.
  7. Teste salvaguardas com dados sintéticos antes de liberar o fluxo.
  8. Registre a decisão de lançar, limitar, redesenhar ou interromper.
  9. Defina gatilhos de revisão para mudanças e incidentes.

O resultado responsável é limitado: o controlador avaliou uma operação definida, numa versão e data específicas, e implementou as medidas registradas. Não converta isso em declaração permanente de que o produto ou a clínica está em conformidade com toda a LGPD.

Perguntas frequentes

Todo formulário que coleta dado de saúde exige RIPD?

Não automaticamente. Dado sensível é um fator importante, mas a ANPD recomenda avaliar o alto risco no caso concreto e pode exigir o relatório nas hipóteses legais.

O dado de saúde sozinho cumpre o teste da Resolução nº 2?

Ele cumpre um critério específico. O artigo 4º exige também ao menos um critério geral para o conceito de alto risco daquele regulamento. Para RIPD, a ANPD usa esse modelo como parâmetro não exaustivo.

O SaaS operador pode assinar o RIPD pela clínica?

Não deve presumir essa transferência. A ANPD atribui a responsabilidade ao controlador. O operador pode fornecer evidências e participar da análise conforme contrato e instruções.

O RIPD deve ser enviado à ANPD antes do lançamento?

Não como regra geral. A ANPD pode solicitar o documento. A recomendação é elaborá-lo antes do tratamento de alto risco para que controles e decisão sejam avaliados a tempo.

Referências

Pedido de eliminação pela LGPD: prontuário e dados de marketing devem ser apagados juntos?

cmsapointoo on August 16, 2026

Não. Um pedido de eliminação pela LGPD não significa apagar prontuário e dados de marketing juntos, nem autoriza a clínica a conservar tudo sob o rótulo de prontuário. O artigo 18 separa dados desnecessários, excessivos ou tratados em desconformidade dos dados tratados com consentimento. Para estes últimos, o direito de eliminação admite as hipóteses de conservação do artigo 16.

A Lei nº 13.787/2018 cria outra fronteira para o prontuário de paciente. Seu artigo 6º prevê prazo mínimo de 20 anos desde o último registro antes que o prontuário possa ser eliminado. A resposta correta exige inventário por conjunto, finalidade e fundamento: prontuário assistencial, cadastro de agendamento, lista promocional, chamados de suporte, logs, exportações e cópias do operador não têm automaticamente o mesmo prazo.

Quais direitos de eliminação aparecem no artigo 18?

O inciso IV do artigo 18 permite pedir anonimização, bloqueio ou eliminação de dados desnecessários, excessivos ou tratados em desconformidade com a LGPD. O inciso VI trata da eliminação de dados pessoais tratados com consentimento, ressalvadas as hipóteses do artigo 16. As duas vias não devem ser resumidas como um direito absoluto de apagar qualquer registro.

Quando não puder adotar a providência imediatamente, o controlador deve responder conforme o § 4º do artigo 18, inclusive apresentando as razões de fato ou de direito que impedem a ação. A página da ANPD sobre petição de titular reforça que direitos não são absolutos e cita como exemplo um pedido de exclusão diante de obrigação legal de guarda.

Eliminação também não é o mesmo que acesso. O fluxo sobre prazo para pedido de acesso à agenda trata dos relógios de confirmação e declaração. Um pedido pode reunir acesso, correção e eliminação, mas cada direito precisa de decisão, prazo e evidência próprios.

O que o artigo 16 permite conservar?

O artigo 16 parte da eliminação após o término do tratamento, dentro dos limites técnicos das atividades, e autoriza conservação para finalidades enumeradas. Entre elas estão cumprimento de obrigação legal ou regulatória pelo controlador, estudo por órgão de pesquisa sob as condições legais, transferência a terceiro em conformidade com a lei e uso exclusivo do controlador com anonimização e sem acesso por terceiro.

Essas hipóteses não são uma licença para guardar a ficha completa por prazo indefinido. O controlador deve apontar qual conjunto permanece, qual finalidade de conservação se aplica e quais usos ficam bloqueados. Uma obrigação relativa ao prontuário não se estende automaticamente ao cadastro promocional ou a uma exportação criada para campanha.

Também não basta escrever “exercício regular de direitos” numa política de retenção e encerrar a análise. O artigo 16 tem texto próprio. Outras bases e normas podem ser relevantes para um caso concreto, mas precisam de avaliação jurídica específica, não de uma justificativa genérica aplicada a todas as tabelas.

Qual é a regra de 20 anos para prontuários?

A Lei nº 13.787/2018 rege a digitalização e o uso de sistemas informatizados para guarda, armazenamento e manuseio de prontuários. O artigo 6º diz que, decorrido o prazo mínimo de 20 anos a partir do último registro, prontuários em papel e digitalizados poderão ser eliminados. A lei permite que regulamento fixe prazos diferentes conforme usos científicos, legais e probatórios.

O texto usa “poderão”. A chegada ao vigésimo ano não cria eliminação automática. A clínica ainda precisa confirmar normas setoriais, finalidade, litígios, requisitos probatórios e procedimento aplicável. Antes do prazo mínimo, um pedido LGPD não deve ser usado para apagar o prontuário sem essa análise.

A lei também exige que a eliminação preserve intimidade, sigilo e confidencialidade, e determina o registro da destinação final e da eliminação na forma do regulamento. A alternativa de devolver o prontuário ao paciente aparece no próprio artigo. Nenhuma dessas opções autoriza uma operação improvisada no banco de produção.

Digitalizar o papel é diferente de eliminar o prontuário

O artigo 3º da Lei nº 13.787 permite destruir documentos originais depois de uma digitalização que cumpra os requisitos legais e após análise obrigatória da comissão permanente responsável. Isso não equivale a eliminar o prontuário. O documento digital preservado continua sendo o registro.

Confundir os dois eventos pode produzir uma resposta errada ao titular. A clínica pode ter destruído o papel de forma regular e ainda precisar conservar o documento digital. Da mesma forma, apagar um arquivo local não prova que o sistema de prontuário, o operador, o backup ou uma exportação seguiram a mesma providência.

O inventário deve registrar formato, sistema de origem, cópias autorizadas e responsáveis. A lei exige integridade, autenticidade e confidencialidade na digitalização e proteção contra acesso, alteração, reprodução ou destruição não autorizados durante o armazenamento.

Como separar prontuário, agenda e marketing?

Nem todo dado no software de agenda integra automaticamente o prontuário, e nem todo dado fora do prontuário é descartável. A qualificação depende do conteúdo, uso, normas do setor e fluxo real. Mapeie ao menos prontuário assistencial, pedido de agendamento, contatos administrativos, consentimentos promocionais, mensagens, logs de segurança e documentos de cobrança.

Para cada conjunto, registre finalidade, hipótese analisada, prazo, sistema, acesso, compartilhamentos e destino final. A discussão sobre dados de saúde no formulário de agendamento mostra por que campos reunidos na mesma tela podem pertencer a tratamentos diferentes.

Se um telefone foi copiado do agendamento para uma lista baseada em consentimento promocional, a obrigação de guardar o prontuário não justifica manter essa cópia. Se o mesmo telefone ainda for necessário dentro de um registro legalmente conservado, restrinja-o à finalidade aprovada. A decisão ocorre por registro e contexto, não por identidade da pessoa em abstrato.

O que controlador e operador devem fazer?

A clínica precisa determinar o escopo da resposta conforme seu papel e os fatos. O operador executa o tratamento segundo instruções do controlador e deve conseguir localizar, bloquear, exportar ou eliminar dados conforme o contrato e a operação aprovada. O nome comercial “plataforma” não resolve os papéis.

O § 6º do artigo 18 exige informar de maneira imediata aos agentes com os quais houve uso compartilhado sobre correção, eliminação, anonimização ou bloqueio, para que repitam o procedimento, salvo impossibilidade comprovada ou esforço desproporcional. O fluxo deve registrar destinatários, instruções, retornos e exceções.

O artigo sobre BAA, DPA e contrato de operador LGPD ajuda a transformar essa divisão em cláusulas sobre instruções, subcontratação, devolução, eliminação e evidência. O contrato apoia a execução, mas não substitui a decisão jurídica sobre cada conjunto.

Como responder sem apagar demais nem reter demais?

  1. Registre o pedido, a identidade validada, o representante e o escopo solicitado.
  2. Separe os direitos envolvidos, como acesso, correção, bloqueio e eliminação.
  3. Localize conjuntos e cópias sem despejar dados sensíveis num chamado geral.
  4. Classifique prontuário, agenda, marketing, suporte, logs e documentos financeiros.
  5. Associe cada conjunto à finalidade, fundamento, prazo e eventual exceção.
  6. Obtenha aprovação jurídica para retenções ou recusas de alto risco.
  7. Instrua operadores e outros agentes sobre a providência aplicável.
  8. Verifique conclusão, exceções, backups e bloqueio de reutilização.
  9. Responda ao titular com linguagem clara e razões específicas.

Não use uma tela sem resultados como única prova. Preserve identificadores de operação, datas, sistemas verificados, contagens e respostas dos agentes. Evite guardar uma cópia integral dos dados eliminados apenas para demonstrar que foram eliminados.

Quando o pedido revela outro problema?

Um pedido pode mostrar que dados de marketing continuam ativos após revogação, que um operador conserva uma exportação desconhecida ou que a clínica não consegue separar prontuário de CRM. Trate a causa como falha de governança e corrija o fluxo, sem ampliar silenciosamente a resposta para sistemas não verificados.

Se a busca apontar acesso indevido, perda, exposição ou destruição acidental, acione o processo de incidente. O conteúdo sobre comunicação de incidente à ANPD separa a investigação e o teste de risco do atendimento ao titular.

A resposta de eliminação não deve encobrir um incidente nem destruir evidência necessária. Preserve somente o que a equipe jurídica e de segurança determinar, com acesso limitado e finalidade registrada.

Perguntas frequentes

Revogar consentimento apaga automaticamente o prontuário?

Não. O artigo 18, VI remete às hipóteses de conservação do artigo 16, e o prontuário possui regra setorial de guarda. A clínica deve avaliar o conjunto e explicar a razão aplicável.

Depois de 20 anos a clínica é obrigada a eliminar o prontuário?

Não por essa regra isolada. A Lei nº 13.787 diz que o prontuário poderá ser eliminado após o prazo mínimo e admite prazos diferenciados. Confirme as normas e os fatos do caso.

Guardar o prontuário permite manter o contato numa lista promocional?

Não automaticamente. Prontuário e marketing têm finalidades distintas. A clínica precisa justificar a cópia promocional por seu próprio fundamento e eliminá-la ou bloqueá-la quando o pedido for aplicável.

Apagar o registro principal encerra a solicitação?

Não sem verificar o escopo aprovado. Operadores, agentes de compartilhamento, exportações e backups podem exigir providências próprias, limitações documentadas ou espera pelo ciclo de retenção.

Referências

Why Deleting an Azure Log Analytics Table Does Not Delete Healthcare Log Data

cmsapointoo on August 16, 2026

Deleting an Azure Log Analytics table does not necessarily delete the healthcare log data stored in it. Azure documents different results for Azure tables, custom tables, search-results tables, and restored tables. For an Analytics or Basic custom table, deleting the table does not delete its data. Stopping a resource from sending logs also leaves existing records in the workspace until the applicable retention period ends.

A deletion review must name the table type, plan, retention settings, ingestion path, and every copy. Subject-level removal uses separate Delete Data or Purge operations. Exports to Storage or Event Hubs and data mirrored to another service have their own lifecycle. None of these Azure mechanics decides whether HIPAA, GDPR, a contract, or another rule requires retention or deletion.

Which Azure action is being called deletion?

Teams often use one word for four different actions: stopping a data source, deleting a table definition, shortening retention, and removing matching records. Azure treats them differently. A support ticket that says “the logs were deleted” cannot prove which action occurred or whether any record became unrecoverable.

Start with the object. Record the workspace, table name, table type, plan, configured analytics retention, total retention, and connected sources. Then identify the requested outcome. An incident cleanup, a privacy request, a tenant offboarding, and an expired retention period may need different approvals and evidence.

The distinction resembles the one in regional healthcare logging on Google Cloud: a control proves only the property assigned to it. A table deletion event cannot stand in for proof about data in exports, mirrors, backups, or another workspace.

What happens when a table or source is removed?

For an Azure table populated by an Azure resource or solution, Microsoft says that stopping the resource or solution from sending data leaves existing records in the workspace until the table’s retention period ends. The source stops producing new entries, but historical records remain queryable or retained according to their current state.

Custom tables behave differently by plan. Microsoft states that deleting a custom table on the Analytics or Basic plan does not delete its data. The table name remains reserved for 15 days, and the documented retention behavior continues. An Auxiliary custom table enters its own 15-day deletion path. Search-results tables can delete their data immediately, while deleting a restored table removes the hot cache but not the source data.

Those differences make table type part of the deletion record. A screenshot of a missing table in the portal is not enough. Preserve the API-visible plan and retention settings, the action timestamp, and the later check that shows what remained or expired.

Why does shortening retention not prove immediate removal?

Azure Monitor separates analytics retention from total retention. Data can leave the interactive analytics state and remain in long-term retention, where a search job can retrieve it. A query that no longer returns a row in the normal experience does not prove that the row no longer exists.

Microsoft also documents a 30-day waiting period when total retention is shortened. The delay lets an administrator reverse an accidental change. That safety feature means a lower number in configuration is not evidence that older records disappeared on the same day.

The special immediatePurgeDataOn30Days workspace property applies to the documented 30-day configuration. It should not be generalized into an arbitrary deletion switch. Record the actual setting and verify the resulting state instead of inferring it from a policy target.

When are Delete Data and Purge relevant?

Microsoft describes the Delete Data API as an asynchronous way to remove matching data from a specific table. It advises using the operation sparingly because deletion can affect performance, measurements, and aggregations. The predicate should therefore be tested as a query before a destructive request is approved.

The Purge API is a different operation. Microsoft authorizes it for requests required for GDPR compliance, limits request volume, and gives purge operations a formal completion service level of up to 30 days. A 202 Accepted response starts the process; it does not prove completion. The response supplies a status location that must be polled.

Purge also has coverage limits. Microsoft says it cannot purge Basic or Auxiliary tables. Purging an Analytics table does not purge a copy mirrored to Microsoft Sentinel data lake. The legal and privacy team decides whether a request qualifies and what must be retained. The platform team maps that decision to supported operations without broadening the predicate.

How do exports and mirrors change the scope?

Log Analytics data-export rules continuously send new records from selected tables to Azure Storage or Event Hubs as data reaches Azure Monitor. The exported destination is a separate store. Removing a record from the workspace does not, by itself, establish what happened to the destination’s copy.

Microsoft says export rules send all incoming data for a selected table unless an ingestion-time transformation filters or changes it. Rules apply from configuration time and do not backfill historical records. These facts help define the copy inventory: capture the rule, selected tables, activation time, destination, transformation, storage redundancy, and destination retention.

Mirrors require the same discipline. The Sentinel data-lake limitation in the Purge documentation is explicit. Other downstream systems should be checked from their own product documentation and contract. The audit method used for AWS CloudTrail routing and residency is useful here: collection, destination, access, and retention are separate facts.

What should a controlled deletion workflow record?

  1. Confirm the approved legal, contractual, or policy instruction and its exact scope.
  2. Identify the workspace, table, plan, data source, retention state, and subject predicate.
  3. Inventory exports, mirrors, search-result tables, restored tables, and support copies.
  4. Stop new ingestion only when the approved outcome requires it.
  5. Run a read-only query to test which rows the proposed predicate would match.
  6. Select retention expiry, Delete Data, Purge, or another documented route for each store.
  7. Require separate approval before any destructive operation.
  8. Poll asynchronous status and verify the final state in every covered destination.
  9. Store evidence without copying the sensitive log content into a general ticket.

Use synthetic identifiers when testing the workflow. If a real request must be checked, restrict query access and record counts, timestamps, operation IDs, and outcomes rather than pasting patient names or clinical text into the evidence packet.

How should healthcare teams limit log content?

Microsoft recommends filtering, obfuscating, anonymizing, or otherwise excluding personal data before collection when possible. It also suggests separating an internal identifier from the lookup that connects it to a person. These choices reduce the number of rows and copies that a later request must locate.

Do not log intake text, diagnosis, treatment, appointment reason, or other health detail merely because the logging service can store it. Keep an allowlist for event fields and inspect exception messages, URLs, query strings, resource names, and custom dimensions. Access controls and retention do not cure unnecessary collection.

The workflow for a HIPAA business associate supporting an access request provides a related role boundary. Technical retrieval or deletion work can sit with a vendor, while the covered entity or other controller retains the decision assigned by law and contract.

What can the final evidence honestly prove?

A strong result names the records and stores covered by the test. For example: a documented predicate matched a stated count in one Analytics table, the approved operation reached its completed status, the follow-up query returned no matching rows, and named export destinations received separate checks.

That evidence should not become a claim that all healthcare data was deleted from Azure. It does not cover unknown tables, backups, support artifacts, endpoints outside the inventory, or legally retained records. It also does not prove HIPAA or GDPR compliance. Those conclusions require the organization’s facts, roles, contracts, and qualified review.

Frequently asked questions

Does deleting a custom Analytics table delete its data?

No. Microsoft states that deleting an Analytics or Basic custom table does not delete its data. Table-plan and retention behavior must be checked separately.

Does stopping ingestion remove old log entries?

No. Existing records remain subject to the table’s analytics and total retention. Stopping a source controls future ingestion, not historical expiry.

Does a 202 response from the Purge API prove deletion?

No. It means Azure accepted an asynchronous request. Poll the supplied status location and then verify the target table and any separate copies.

Can one purge remove every exported or mirrored copy?

Do not assume so. Microsoft expressly says an Analytics-table purge does not purge its Sentinel data-lake mirror. Storage, Event Hubs, and other destinations have independent controls that need their own review.

References

O link da Doctoralia no Google sincroniza a agenda do Feegow com o Google Calendar?

cmsapointoo on August 16, 2026

O link da Doctoralia exibido no Google não sincroniza a agenda do Feegow com o Google Calendar. A Central de Ajuda Feegow afirma que não existe integração com o Google Calendar ou outro calendário externo nesse fluxo. A visibilidade no Google corresponde apenas ao link que leva o paciente ao agendamento online da Doctoralia.

A disponibilidade segue outro caminho. A clínica configura a grade no Feegow e usa Exibir na Doctoralia para compartilhá-la no marketplace. Já Disponível via API libera consulta pela API Pública do Feegow. As duas opções têm destinos diferentes e uma não ativa a outra.

O que o link da Doctoralia no Google realmente faz?

A documentação do Feegow separa visibilidade de calendário. O Google pode exibir um link para o agendamento online da Doctoralia, mas isso não significa que eventos do Google Calendar sejam lidos pelo Feegow. Também não significa que consultas do Feegow sejam gravadas como eventos num calendário externo.

O paciente usa o link para abrir o fluxo online da Doctoralia. A disponibilidade mostrada nesse fluxo vem da grade compartilhada pelo Feegow, dentro dos limites da integração. O papel do Google termina na descoberta do link. Ele não fornece horários nem cria bloqueios.

Inferência operacional: registre separadamente o link público, a grade publicada na Doctoralia e qualquer calendário externo. Se um horário divergir, identifique onde o erro aparece antes de alterar configurações. Assim, a equipe não atribui ao Google Calendar uma função que a fonte oficial nega.

Qual opção publica a grade na Doctoralia?

Para disponibilizar horários na Doctoralia, o Feegow orienta abrir Agenda, entrar na visualização diária ou semanal e acessar Grade. Na grade desejada, a clínica marca Exibir na Doctoralia e salva. Esse é o controle documentado para compartilhamento externo.

A página de configuração também informa que o local precisa estar apto para compartilhamento. Se o aviso indicar que a grade não pode ser compartilhada, a clínica deve verificar Exibir no agendamento online no cadastro da unidade. Uma grade correta para um profissional não comprova que outra unidade recebeu a mesma configuração.

Depois de salvar, valide a jornada pública. Não conclua pela presença de um botão interno. Se surgirem horários criados diretamente na plataforma externa, use o processo para encontrar horários manuais da Doctoralia fora da integração.

Para que serve Disponível via API?

A opção Disponível via API tem outro destino. A documentação diz que ela torna as informações da grade consultáveis por meio da API Pública do Feegow. Ela não é descrita como substituta de Exibir na Doctoralia e não cria integração com o Google Calendar.

Uma clínica pode precisar de um dos caminhos ou dos dois, conforme os sistemas aprovados. Marcar somente Disponível via API não prova que os horários chegaram ao marketplace da Doctoralia. Marcar somente Exibir na Doctoralia também não prova que um integrador próprio consegue consultar a grade pela API.

Inferência operacional: mantenha uma matriz simples por grade, profissional e unidade. Registre se a saída esperada é Doctoralia, API Pública ou ambas. A matriz é um controle interno; as fontes apenas estabelecem que as opções são separadas.

Quais grades entram no compartilhamento externo?

O artigo específico sobre compartilhamento informa que a mesma configuração pode ser aplicada a grades de exceção. Também diz que Grade Livre não é considerada pelo sistema no compartilhamento externo. Portanto, enxergar horários personalizados dentro do Feegow não prova que eles aparecerão no agendamento da Doctoralia.

Use a grade compatível com o comportamento documentado. Quando a clínica precisa limitar convênios, procedimentos ou períodos, configure a regra na grade suportada e teste o resultado. O guia de horários exclusivos por convênio no Feegow e Doctoralia detalha esse cenário.

Não recrie uma Grade Livre como vários horários externos sem avaliar duplicidade. Se a necessidade não cabe na integração atual, preserve o caso e encaminhe ao suporte. A semelhança visual entre duas agendas não comprova que usam o mesmo tipo de grade.

Como diagnosticar um horário que aparece num sistema e não no outro?

Comece pelo destino que está errado. Se o link não aparece no Google, trate a visibilidade do link. Se o link abre, mas a Doctoralia não mostra o horário, revise a grade, o profissional, o local, a unidade e Exibir na Doctoralia. Se uma aplicação própria não recebe dados, revise Disponível via API e o contrato da API.

  1. Identifique profissional, unidade, data e horário sem incluir dados de paciente.
  2. Confirme qual grade contém o período dentro do Feegow.
  3. Verifique se a grade é compatível com compartilhamento externo.
  4. Confira Exibir na Doctoralia para o marketplace.
  5. Confira Disponível via API somente para a API Pública.
  6. Abra o link público e observe a disponibilidade na Doctoralia.
  7. Registre a divergência antes de mudar outra configuração.

Se o problema for um feriado, existe um limite específico. Veja por que o bloqueio automático de feriado não fecha a agenda da Doctoralia. Não use esse comportamento para explicar toda falha de publicação.

Por que um teste no Google Calendar não valida essa integração?

Criar um evento no Google Calendar não testa o fluxo documentado entre Feegow e Doctoralia. A própria fonte informa que não há sincronização de agenda com calendários externos. Se o horário continuar aberto, esse resultado é compatível com a ausência de integração e não prova falha no Feegow.

O teste correto começa na grade do Feegow e termina na disponibilidade pública da Doctoralia. Use um horário neutro, futuro e aprovado para teste. Verifique se ele aparece, depois aplique uma alteração compatível e confirme o novo estado. Não use nome, telefone, procedimento ou motivo de consulta de um paciente real.

Inferência operacional: se a clínica precisa que compromissos externos bloqueiem a agenda, trate isso como requisito de produto separado. A documentação citada não oferece esse recurso e não escolhe uma alternativa. Compare fornecedores, riscos e operação antes de adicionar outro sincronizador.

Como remarcações e bloqueios entram nessa análise?

Uma remarcação e um bloqueio são operações da agenda, não provas de integração com o Google Calendar. Na integração Doctoralia e Feegow, mudar apenas o status para Remarcado não atualiza a plataforma externa. O fluxo documentado usa o botão Remarcar. Veja o diagnóstico completo sobre status Remarcado e atualização da Doctoralia.

Bloqueios também precisam do controle correto. Um horário bloqueado pode continuar aceitando encaixe quando a configuração específica não está ativa. Isso é diferente de um evento externo. O artigo sobre encaixe em horário bloqueado no Feegow cobre esse limite.

Teste uma variável por vez. Primeiro prove que a grade foi publicada. Depois valide remarcação, bloqueio ou encaixe pelo fluxo próprio. Misturar todas as ações num único teste torna impossível saber qual contrato falhou.

Que evidência deve acompanhar um chamado ao suporte?

Registre clínica ou conta, unidade, profissional, tipo de grade, data, intervalo, opções marcadas e resultado observado na Doctoralia. Informe também se a dúvida é sobre o link público, o marketplace ou a API Pública. Uma frase como “não sincroniza” é ampla demais para localizar o problema.

Use capturas sem dados desnecessários. O chamado não precisa de nome, telefone, convênio individual, motivo da consulta ou detalhe clínico para demonstrar que uma grade não apareceu. Se um agendamento sintético for necessário, siga o processo aprovado para removê-lo e não o envie para ferramentas de marketing.

Não peça ao suporte para “ativar o Google Calendar” com base nesse fluxo. Cite o comportamento esperado de Exibir na Doctoralia ou Disponível via API. Se a operação realmente precisa de calendário externo, apresente isso como novo requisito.

Perguntas frequentes

O link da Doctoralia no Google bloqueia horários no Google Calendar?

Não. O Feegow informa que a visibilidade no Google é apenas o link de agendamento online da Doctoralia, sem sincronização com o Google Calendar ou outro calendário externo.

Marcar Disponível via API publica a grade na Doctoralia?

Não automaticamente. Disponível via API atende à API Pública do Feegow. Para o marketplace, a opção documentada é Exibir na Doctoralia.

Grade Livre aparece no agendamento online da Doctoralia?

A fonte oficial diz que Grade Livre não é considerada no compartilhamento externo. Use uma grade suportada ou leve o requisito ao suporte sem prometer sincronização.

Como sei se o link público está funcionando?

Abra o link exibido no Google e conclua que ele funciona apenas quando leva ao fluxo correto da Doctoralia. Depois valide os horários separadamente contra a grade compartilhada no Feegow.

Referências