CMS-0057-F e 1 de janeiro de 2027: as API dos pagadores em sistemas próprios de sinistros e de autorização prévia

Até 1 de janeiro de 2027, as organizações Medicare Advantage e os programas estaduais Medicaid e CHIP em regime de pagamento por ato (fee-for-service) têm de ter quatro API FHIR a funcionar, ao abrigo da regra final dos CMS sobre interoperabilidade e autorização prévia (CMS-0057-F): a Patient Access API já existente, alargada aos dados de autorização prévia, e as novas Provider Access API, Payer-to-Payer API e Prior Authorization API. Os planos de cuidados geridos (managed care) do Medicaid, as entidades de cuidados geridos do CHIP e os emissores de Qualified Health Plans nas bolsas federais seguem-se a partir do primeiro período de tarifação ou ano do plano que comece nessa data ou depois dela. A 16 de outubro de 2026, faltam onze semanas, e os CMS não alteraram a data.

A metade operacional da regra já está em vigor. Desde 2026, os pagadores abrangidos têm de indicar um motivo específico para cada autorização prévia recusada, decidir dentro de prazos fixos e publicar métricas de autorização prévia.

Se os seus sistemas de sinistros, de gestão da utilização e de beneficiários vêm de um fornecedor que entrega estas quatro API, a maior parte do desenvolvimento cabe ao fornecedor. A sua parte é a configuração, a digitalização das regras de autorização prévia, as comunicações aos beneficiários e os testes com os parceiros.

Este artigo é para os restantes: planos e agências cujo motor de sinistros, fluxo de gestão da utilização (UM) ou dados de beneficiários estão num sistema próprio, seja ele desenvolvido internamente, personalizado ao ponto de já não poder ser atualizado, ou um Medicaid Management Information System (MMIS) com décadas de alterações locais. Ninguém entrega as API para esses sistemas. Somos engenheiros, não advogados: este artigo explica o que a regra pede a um sistema, e não como se aplica aos seus contratos.

As datas

A regra final foi publicada no Federal Register a 8 de fevereiro de 2024 e produziu efeitos a 8 de abril de 2024. Para cada uma das quatro API, fixa as mesmas datas de cumprimento: «até 1 de janeiro de 2027, para as organizações MA e os programas estaduais Medicaid e CHIP FFS; a partir do período de tarifação que comece em 1 de janeiro de 2027 ou depois, para os planos de cuidados geridos do Medicaid e as entidades de cuidados geridos do CHIP; e para os anos do plano que comecem em 1 de janeiro de 2027 ou depois, para os emissores de QHP nas FFE.»

Um plano de cuidados geridos do Medicaid cujos períodos de tarifação começam a 1 de julho tem, portanto, até 1 de julho de 2027. Um plano com contrato por ano civil não tem.

Os CMS continuam a indicar a mesma data. A sua página sobre a regra, alterada pela última vez a 8 de outubro de 2026, diz que «os pagadores abrangidos têm, em regra, até 1 de janeiro de 2027 para cumprir os requisitos de interface de programação de aplicações (API) desta regra final».

As obrigações de 2026, tal como as descreve a ficha informativa dos CMS, são decisões «no prazo de 72 horas para os pedidos acelerados (ou seja, urgentes) e de sete dias de calendário para os pedidos normais (ou seja, não urgentes)» (os emissores de QHP nas bolsas estão excluídos destes prazos), um motivo específico para cada recusa e métricas públicas, das quais «o primeiro conjunto tem de ser comunicado até 31 de março de 2026». A utilização da Patient Access API é também comunicada aos CMS todos os anos, até 31 de março. Se alguma destas obrigações ainda não está a funcionar, já está atrasada, e assenta nos mesmos dados que as API.

Os medicamentos ficam de fora de tudo isto. Todas as disposições sobre autorização prévia da CMS-0057-F os excluem.

Quem está abrangido, e quem não está

A regra chama-lhes pagadores abrangidos (impacted payers): as organizações Medicare Advantage (MA), os programas estaduais Medicaid e CHIP em pagamento por ato (FFS), os planos de cuidados geridos do Medicaid, as entidades de cuidados geridos do CHIP e os emissores de QHP nas Federally-facilitated Exchanges (FFE). A sua análise de impacto contabiliza «365 organizações-mãe, incluindo as agências estaduais do Medicaid e do CHIP», que «são responsáveis por implementar e manter três novas API», e observa que «75 % dos pagadores desta categoria têm menos de 500 trabalhadores». Muitos são planos regionais sem uma grande equipa de plataforma.

Não estão abrangidos, pelo menos diretamente:

• Os planos de empregadores fora destes programas e o Original Medicare. Não constam da lista de pagadores abrangidos.
• Os prestadores de cuidados. A parte que lhes cabe é a medida Electronic Prior Authorization dos programas Promoting Interoperability do Medicare, cumprida através de tecnologia de processo clínico eletrónico (EHR) certificada. A regra final IPPS do ano fiscal de 2027, de 4 de agosto de 2026, tornou-a uma medida de bonificação facultativa para os hospitais em 2027.
• As entidades de UM delegadas e os administradores terceiros (TPA). Não têm obrigações próprias, mas as do pagador passam pelos seus sistemas. No caso dos emissores de QHP, a regra repete que estes «são responsáveis pelo seu próprio cumprimento e pelo de quaisquer entidades delegadas ou a jusante».

Há poucas saídas, e nenhuma ajuda muito tão perto do prazo. Um estado pode pedir uma prorrogação única de um ano para o seu programa Medicaid ou CHIP FFS, mas o pedido é feito no seu Advance Planning Document (APD) e tem de ser «aprovado antes da data de cumprimento». Um estado com pelo menos 90 % dos beneficiários do Medicaid em cuidados geridos pode pedir uma isenção, e os emissores de QHP podem pedir uma exceção à bolsa. Quanto aos próprios planos, os CMS escreveram: «Não propusemos prorrogações nem isenções para as organizações MA nem para os planos de cuidados geridos do Medicaid.» Os estados podem ainda pedir financiamento federal de contrapartida reforçado, de 90 %, para desenvolver as API, aprovado caso a caso através do APD.

O que cada API tem de fazer

As quatro dependem de uma coisa que muitas vezes falta a um sistema personalizado: a autorização prévia como dados estruturados, com histórico de estados. Construa isso uma vez e as quatro leem a partir daí.

Patient Access API: acrescentar as autorizações prévias

Tem esta API a funcionar desde 1 de janeiro de 2021, para sinistros, episódios de cuidados e dados clínicos. A partir de 2027, tem também de disponibilizar cada autorização prévia de bens e serviços: o estado, a data em que foi aprovada ou recusada, quando termina, os bens e serviços aprovados, um motivo específico em caso de recusa e a documentação estruturada relacionada enviada pelo prestador. Os dados têm de estar disponíveis «o mais tardar 1 dia útil após» o pagador receber o pedido, ser atualizados no prazo de um dia útil após qualquer alteração de estado e ser conservados enquanto a autorização estiver ativa e durante pelo menos um ano após a última alteração.

Um sistema de UM que regista as decisões como notas em texto livre, ou que só envia o estado por fax, não consegue alimentar isto sem alterações.

Provider Access API

Os prestadores da rede podem pedir os dados de um doente: sinistros e episódios de cuidados sem as remessas aos prestadores nem a comparticipação do beneficiário (cost-sharing), as classes de dados clínicos USCDI e a informação de autorização prévia, para datas de prestação a partir de 1 de janeiro de 2016. O pagador responde no prazo de um dia útil, mas apenas relativamente aos doentes que atribuiu a esse prestador e que não exerceram o direito de oposição (opt-out).

Isto exige três coisas que um sistema legado raramente tem. Um processo de atribuição que associe os beneficiários aos prestadores. Uma oposição que o beneficiário possa alterar a qualquer momento, com comunicações em linguagem simples antes da primeira utilização, no prazo de uma semana após o início da cobertura e todos os anos. E exportação em massa, porque as normas exigidas incluem o FHIR Bulk Data Access para um prestador que pergunte por toda a sua carteira de doentes.

Payer-to-Payer API

Quando um beneficiário adere, o novo pagador pede autorização (aqui é preciso consentimento expresso, opt-in) e começa a identificar os pagadores anteriores e concomitantes no prazo de uma semana após o início da cobertura. Quando os tiver identificado, pede cinco anos de dados no prazo de uma semana: sinistros e episódios de cuidados sem remessas nem comparticipação do beneficiário, dados USCDI e as autorizações prévias que não tenham sido recusadas, com a respetiva documentação não estruturada. O pagador anterior responde no prazo de um dia útil. Havendo cobertura concomitante, a troca repete-se pelo menos trimestralmente.

A parte difícil não é a resposta enviada. É receber dados de pagadores com quem nunca testou e integrá-los no registo do beneficiário, como a regra exige.

Prior Authorization API

É esta que chega ao núcleo da UM. A API tem de listar os bens e serviços cobertos que exigem autorização prévia, identificar a documentação exigida para cada um, suportar um pedido e uma resposta conformes à HIPAA e indicar se o pagador aprovou (com a data de termo), recusou (com um motivo específico) ou precisa de mais informação.

Os CMS recomendam, sem exigir, três guias de implementação Da Vinci: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) e Prior Authorization Support (PAS). Na prática, as suas regras de cobertura e os questionários de documentação têm de passar a ser legíveis por máquina, e não um manual de políticas em PDF. Os pagadores inquiridos pela WEDI puseram a «digitalização das políticas de autorização prévia» entre os seus três maiores desafios.

Quanto à transação em si, o HHS deu margem aos pagadores. A 28 de fevereiro de 2024, anunciou uma política de discricionariedade na aplicação (enforcement discretion): segundo os CMS, o seu National Standards Group «não tomará medidas de execução da HIPAA Administrative Simplification contra as entidades abrangidas pela HIPAA que optem por não utilizar a norma X12 278 num processo eletrónico de autorização prévia em FHIR». Pode desenvolver só em FHIR ou em FHIR com X12, e manter em paralelo uma transação só em X12.

As normas

As normas exigidas são o HL7 FHIR Release 4.0.1, o US Core, o SMART App Launch, o Bulk Data Access e o OpenID Connect Core; os pagadores podem usar versões atualizadas de forma voluntária, sob determinadas condições. A regra de 2024 indicava o US Core 3.1.1 e o SMART App Launch 1.0.0 com data de caducidade a 1 de janeiro de 2026, por isso defina as versões que vai seguir antes de alguém escrever o mapeamento.

Onde os sistemas próprios costumam ficar aquém

Pelo que a regra pede, estas são as lacunas a procurar primeiro:

• A autorização prévia como registo, e não como documento. O estado, as marcas temporais, os códigos de motivo de recusa e a data de termo têm de ser campos, escritos quando mudam, com histórico. Uma decisão enviada por fax precisa de um gémeo estruturado.
• As regras de cobertura. Que serviços precisam de autorização, e que documentação exige cada um, têm de ser dados que a API consiga servir. Em muitos planos, essa informação vive em PDF de políticas e na cabeça de quem analisa os pedidos.
• Os sinistros em FHIR. Os sinistros e episódios de cuidados têm de sair como recursos FHIR, sem remessas nem comparticipação do beneficiário para os prestadores e os outros pagadores, mas com elas para o beneficiário.
• A identidade e o histórico do beneficiário. Fazer corresponder os dados de outro pagador ao seu beneficiário, e encontrar os pagadores anteriores de um novo beneficiário, exige dados demográficos e um histórico de cobertura que talvez não tenha num único sítio.
• O estado do consentimento. Uma oposição para a Provider Access e um consentimento expresso para a Payer-to-Payer, cada um alterável a qualquer momento e verificado em cada pedido. Um estado tem também de transmitir o consentimento expresso de um beneficiário aos planos de cuidados geridos do Medicaid dessa pessoa.
• O relógio de um dia útil. Um processamento noturno em lote no mainframe serve para alguns dados e é demasiado lento para outros. Meça o tempo entre a decisão e a API, e não apenas se a API responde.
• Os fornecedores delegados. Se é um fornecedor de UM delegado que toma as decisões, os seus dados têm de lhe chegar a tempo de cumprir a obrigação de um dia útil. O inquérito da WEDI de fevereiro de 2026 pôs «as entidades terceiras delegadas com dificuldades em ligar-se a sistemas diferentes» em primeiro lugar entre os desafios dos pagadores.

Em que ponto está o setor

O inquérito da WEDI de fevereiro de 2026, divulgado a 10 de março de 2026, concluiu que, nos requisitos das API, «10 % ainda não começaram o trabalho», contra 33 % em outubro de 2025. Assinalou também «um aumento notório dos que estimam um custo superior a 5 milhões de dólares, de 15 % (out. 2025) para 25 % (fev. 2026)». A amostra é pequena: 86 respostas, 52 % delas de pagadores. Leia-o como um indício, e não como um recenseamento.

Um plano de onze semanas até 1 de janeiro de 2027

A partir de meados de outubro, uma organização MA ou um programa estadual FFS tem cerca de onze semanas. Não chega para construir quatro API a partir do zero, por isso o plano tem a ver com a sequência e com o que consegue mostrar no primeiro dia.

1. Esta semana: confirme a sua data e o seu ponto de partida. 1 de janeiro, ou um período de tarifação ou ano do plano posterior? Liste o que já está a funcionar: as API Patient Access e Provider Directory, as métricas de 2026, os motivos de recusa.
2. Semanas 1 a 2: associe cada elemento de dados à sua origem. Para cada API, registe que sistema tem hoje os dados (sinistros, UM, adesões, rede de prestadores, dados clínicos) e quão atualizados estão.
3. Semanas 1 a 3: decida onde fica a camada FHIR. Um servidor ou uma fachada FHIR à frente dos sistemas legados, alimentado por eventos de alteração ou por extrações frequentes, é normalmente mais rápido do que ensinar o sistema central a falar FHIR. O tempo vai-se no mapeamento e nas alimentações de dados.
4. Semanas 2 a 7: construa primeiro as peças partilhadas. O registo de autorização prévia, o consentimento e a atribuição, a correspondência de beneficiários. As quatro API dependem delas.
5. Semanas 4 a 9: construa as API. Os acréscimos à Patient Access, a Provider Access com exportação em massa, a Payer-to-Payer nos dois sentidos e a Prior Authorization API com as suas regras de cobertura carregadas.
6. Semanas 8 a 11: teste com contrapartes reais. O fornecedor de EHR de um prestador, outro pagador, o seu fornecedor de UM delegado. Teste alterações de consentimento, uma recusa com o respetivo motivo e uma alteração de estado que chegue ao beneficiário no prazo de um dia útil.
7. 1 de janeiro de 2027: entrada em produção e medição. Acompanhe a latência face às regras de um dia útil desde o primeiro dia e mantenha uma lista datada do que não está terminado.

Se onze semanas não chegam, leve a questão à sua equipa de conformidade e aos seus advogados agora, e não em dezembro, com um plano que mostre o que vai estar a funcionar a 1 de janeiro e o que se segue, e quando.

Um plano de cuidados geridos do Medicaid com um período de tarifação a 1 de julho de 2027, ou um emissor de QHP com um ano do plano posterior, pode seguir os mesmos passos com mais folga. Comece agora na mesma: os pagadores e os prestadores com quem vai testar entram em produção a 1 de janeiro.

O que ainda pode mudar

CMS-0062-P. A 14 de abril de 2026, os CMS publicaram uma proposta de regra complementar. Tornaria obrigatórios, a partir de 1 de outubro de 2027, os guias de implementação hoje recomendados, incluiria os medicamentos na autorização prévia eletrónica a partir da mesma data e faria o HHS adotar o FHIR como norma HIPAA para as transações de autorização prévia, em substituição da X12 278. Sobre os prazos existentes, diz: «Esta proposta não alteraria essas datas de cumprimento.» O período de comentários terminou a 15 de junho de 2026 e, a 16 de outubro de 2026, ainda não foi publicada nenhuma regra final no Federal Register. Desenvolva segundo a regra de 2024 e mantenha as versões dos guias num único sítio configurável.

Versões. Os guias Da Vinci continuam a evoluir. A regra final IPPS do ano fiscal de 2027 observa que os EHR certificados segundo os novos critérios de autorização prévia do ONC «exigirão a utilização da versão 2.2 dos IG Da Vinci». São esses os sistemas com que a sua Prior Authorization API vai comunicar.

Nada disto é motivo para esperar. A regra é final, as datas estão no texto regulamentar e os CMS repetiram-nas a 8 de outubro.

Como podemos ajudar

Trabalhamos nos sistemas por trás das API: mapeamento para FHIR dos dados de sinistros, episódios de cuidados e autorizações, fluxos de alterações a partir de plataformas antigas de sinistros e de UM, lógica de consentimento e de atribuição, e os testes que mostram que as regras de um dia útil se cumprem. O nosso serviço de manutenção de sistemas legados é o ponto de partida quando o sistema central é antigo ou as pessoas que o construíram já saíram e, se o prazo calhar a meio de uma substituição de plataforma, veja a modernização de ERP.

Se a sua plataforma de sinistros ou de UM é uma para a qual nenhum fornecedor vai entregar estas API, escreva para office@c9group.dev. Somos engenheiros, não advogados especializados em saúde: as questões de âmbito e de contratos são assunto para os seus advogados, e desenvolvemos de acordo com a resposta deles.