Versões comparadas

Versão antiga 4

changes.mady.by.user Solus (Unlicensed)

Gravado em

comparado com

Nova versão Atual

changes.mady.by.user Solus - Publicação

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Revisão QA Documentação

...

...

...

Autor: H. S.

Âncora
topo
topo

Painel
titleColorwhite
titleBGColor#AB0047
title✔ Críticas referente ao Beneficiário:


Painel
borderWidth2 px


Expandir
titleIdentificação do beneficiário não consistente.


Expandir
titleCompreensão e Solução:

(interrogação) Entendendo a crítica:


Pode 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 operadoraOperadora.

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

Image Modified


O beneficiário do XML é identificado por uma das duas chaves no XML, sendo que dentre 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":

Image Modified


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.(ideia)


Informações

É 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

será

a mesma situação de sua

operadora

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.



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


Informações

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.

Image Modified(aviso)


Informações

A configuração informada acima irá repercutir apenas em XMLs do tipo "guiaSP-SADT". Para

todos

os demais tipos é obrigatório que o beneficiário seja validado para a devida entrada do arquivo no sistema.






Painel
borderWidth2 px


Expandir
titleBeneficiário da guia diferente do beneficiário do XML.


Expandir
titleCompreensão e Solução:

(interrogaçã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"):

Image Modified


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:

Image Modified


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

Image Modified


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.


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


Informações

 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. 

Image AddedImage Removed

Aviso
(aviso)  A
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.






Painel
borderWidth2 px


Expandir
titleNão é permitido enviar beneficiários de grupos distintos...


Expandir
titleCompreensão e Solução:

(interrogaçã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:

Image RemovedImage Added


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

Image RemovedImage Added


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

Image RemovedImage Added


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

Image RemovedImage Added


Sendo assim, não é inválido válido que o prestador tente cobrar no mesmo arquivo guias de beneficiários que sejam de congêneres distintas. Nesta 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 utilizar ou utilize a configuração indicada no item abaixo, caso não seja de interesse da operadora Operadora validar essa informação.


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


Informações

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

Image Added


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".





Painel
borderWidth2 px


Expandir
titleIndicação RN divergente da guia informada


Expandir
titleCompreensão e Solução:

(interrogação) Entendendo a crítica

Image Added


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):
Image Added


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

Image Added


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


Informações

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

WEB PRESTADOR - BLOQUEAR ENVIO DO XML COM CONGENERES DIFERENTES

Retornar

– VALIDAR ATENDIMENTO RN NO ENVIO DO XML.





Painel
borderWidth2 px


Expandir
titleBeneficiário atendido antes da data de inclusão


Expandir
titleCompreensão e Solução

(interrogação) Entendendo a crítica

Image Added

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":
Image Added


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:

Image Added


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


Informações

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