Identificação do beneficiário não consistente

Compreensão e Solução

Entendendo a crítica

Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador quando o beneficiário enviado na tag "dadosBeneficiario" não foi encontrado pelo sistema no cadastro da Operadora.

Exemplo de beneficiário enviado no XML ("guiaSP-SADT"):

O beneficiário do XML é identificado por uma das duas chaves no XML, sendo que entre elas apenas numeroCarteira é obrigatória perante schema da ANS, portanto, numeroCNS é opcional ficando a critério do prestador enviar ou não:

numeroCarteira
numeroCNS

No nosso exemplo foram enviadas ambas as tags.

A chave informada deverá ser verdadeira, ou seja, deverá existir um cadastro de beneficiário contendo a informação enviada. Caso não encontre pelo código, o sistema tentará buscar pelo CNS e vice-versa. O cadastro de beneficiário fica disponível no módulo Estrututral em Cadastro de contratos > Beneficiários F8, e ambos código e CNS ficam disponíveis na primeira "Beneficiário":

No exemplo acima, nosso beneficiário JOAO SILVEIRA não foi encontrado pois o código e CNS enviados não batem com o cadastrado no sistema. Foi enviado no XML o código "0561500000200", sendo que no cadastro o correto seria "0561500000100". O CNS enviado foi "267985351990099", no sistema o correto é "267985351990003.

É importante frisar que cada operadora terá sua própria montagem do código do beneficiário, de acordo com sua máscara padrão. Aqui documentamos apenas um exemplo, porém, não será necessariamente a mesma situação de sua Operadora. Note que seu prestador pode enviar um código de beneficiário sem dígito, ou apenas uma combinação diferente e o próprio sistema fará a montagem e busca do código de acordo com seu padrão de máscara.

Configurar o sistema para que NÃO efetue essa validação

Para que o sistema não efetue a validação do beneficiário se faz necessária uma configuração no cadastro do prestador > aba 9.Configuração do TISS, campo "É preciso validar o número da guia e o código do beneficiário?"

Se configurado com a opção "Acertando o número da guia não é necessário acertar o beneficiário" não existe a necessidade do beneficiário existir na base de dados, somente a guia deverá existir. Com isso a conta médica entrará como um registro de atendimento cortesia/particular.

A configuração informada acima irá repercutir apenas em XMLs do tipo "guiaSP-SADT". Para os demais tipos é obrigatório que o beneficiário seja validado para a devida entrada do arquivo no sistema.

Beneficiário da guia diferente do beneficiário do XML

Compreensão e Solução

Entendendo a crítica

Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador quando o beneficiário enviado na tag "dadosBeneficiario" diverge do beneficiário que de fato consta na guia dentro do sistema.

Exemplo de beneficiário enviado no XML ("guiaSP-SADT"):

Note que o beneficiário enviado no XML foi "JOAO SILVEIRA", o qual existe corretamente no sistema com este código e CNS conforme consta abaixo:

No entanto, o beneficiário constante na guia a qual está sendo cobrada no XML é o "CARLOS ALVES":

Sendo assim, neste caso temos a crítica de que o beneficiário da guia é diferente do beneficiário enviado no XML. Para solucionar, analisar a guia x arquivo, se o prestador enviou incorretamente será necessário que corrija o arquivo e o reenvie para validação. Caso a guia esteja com o beneficiário incorreto, se faz necessária a geração de nova guia com o paciente correto para que o prestador possa reenviar o arquivo com este novo número de guia.

Configurar o sistema para que NÃO efetue essa validação

Para que o sistema não efetue a validação se beneficiário do XML é o mesmo da guia se faz necessária uma configuração no cadastro do prestador > aba 9.Configuração do TISS, campo "É preciso validar o número da guia e o código do beneficiário?"

Se configurado com a opção "Acertando o número da guia não é necessário acertar o beneficiário" não existe a necessidade do beneficiário existir na base de dados, somente a guia deverá existir. Com isso a conta médica entrará como um registro de atendimento cortesia/particular.

A configuração informada acima fará com que o sistema assuma que o beneficiário enviado no XML é o correto, desprezando o que constar na guia.

Não é permitido enviar beneficiários de...

Compreensão e Solução

Entendendo a crítica

Também pode ocorrer a Crítica = não permitido enviar beneficiários de Intercâmbio e Local no mesmo arquivo:

Esta refere-se ao beneficiário local e intercâmbio num único XML

Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador quando houver cobrança de dois ou mais beneficiários no mesmo arquivo que sejam de congêneres diferentes no sistema.

Exemplo de beneficiário 1 enviado no XML: JOAO SILVEIRA, guia 3095:

Exemplo de beneficiário 2 enviado no XML: JESSICA DOS SANTOS, guia 3198:

Analise a primeira guia clicando no ícone . Aqui, é perceber que o beneficiário JOAO pertence à congênere PRE PAGAMENTO COLETIVO EMPRESARIAL, conforme consta abaixo:

Analise a segunda guia clicando no ícone . Aqui, é perceber que a beneficiária JESSICA pertence à congênere PRE PAGAMENTO PF, conforme consta abaixo:

Sendo assim, não é válido que o prestador tente cobrar no mesmo arquivo guias de beneficiários que sejam de congêneres distintas. Nessa situação é obrigatório que todos os atendimentos sejam da mesma congênere.

Para solucionar, é necessário que o prestador ajuste a geração do arquivo de forma que emita apenas beneficiários da mesma congênere. ou utilize a configuração indicada no item abaixo, caso não seja de interesse da Operadora validar essa informação.

Configurar o sistema para que NÃO efetue essa validação

Para que o sistema não efetue a validação se os beneficiários das guias pertencem todos a mesma congênere, é necessário Configurar o parâmetro no Módulo Servertiss30 > clicar em "Configurações" () > "Parametrizações" > Aba "TISS" > Opção "Validar beneficiários na importação".

Configuração para bloquear e criticar o envio de XML de acordo com cada opção:

Não realizar nenhuma validação: nesta opção, nada será validado, e o arquivo será recebido sem crítica.
Bloquear envio de XML com congêneres diferentes: a opção "Congêneres diferentes" é a validação atualmente em vigor. Portanto, se houver beneficiários com congêneres diferentes, ela emitirá uma crítica e impedirá a continuidade da importação. Nesta opção será gerada a mensagem "Não é permitido enviar beneficiários de grupos distintos".
Bloquear envio de XML com tipos de beneficiários diferentes (Intercâmbio/Local): a opção “Tipos de beneficiários diferentes (Intercâmbio/Local)” vai validar se existe beneficiário de Intercâmbio e Local no mesmo arquivo de importação. Caso tiver crítica, não deixará prosseguir na importação, e nesta configuração será gerada a mensagem "Não é permitido enviar beneficiários de Intercâmbio e Local no mesmo arquivo".

Indicação RN divergente da guia informada

Compreensão e Solução:

Entendendo a crítica

Pode ocorrer em todos os tipos de envio de XML TISS, via Web Prestador, quando a indicação de RN (Recém-nascido) estiver divergente da autorização da guia. No exemplo abaixo, a guia está indicada que NÃO se trata de RN (Recém-nascido):

Ao enviar o XML, consta "SIM" na indicação de RN (Recém-nascido):

Configurar o sistema para que NÃO efetue essa validação:

Para que o sistema valide a indicação RN, é necessário INCLUIR o direito abaixo ao perfil/operador:

WEB PRESTADOR – VALIDAR ATENDIMENTO RN NO ENVIO DO XML.

Beneficiário atendido antes da data de inclusão

Compreensão e Solução

Entendendo a crítica

Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador quando a data de atendimento do beneficiário é inferior à data de inclusão deste no contrato. Exemplo:

Tag "dataAtendimento":

No envio do XML, consta a data do atendimento, como 20/06/2023, mas a data de inclusão do beneficiário só aconteceu no dia 01/07/2023. Essa informação fica no cadastro do beneficiário pelo caminho:

Módulo Estrutural > Cadastro > Cadastro de beneficiário > Beneficiário:

Configurar o sistema para que NÃO efetue essa validação

Não há. Nesse caso, o sistema fará a validação da data de inclusão com a data de atendimento, pois não há como o beneficiário ter sido atendido pelo plano em questão se, na data indicada, este ainda não estiver ativo no contrato.

Voltar ao início

Navegador não compatível