Entendendo a crítica:
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador, principal dono do arquivo, não for identificado pelo sistema através da tag "origem" > "identificacaoPrestador".
Exemplo de prestador enviado no XML:
O prestador dono do XML é identificado por uma das três chaves no XML, sendo que, dentre elas, apenas uma é obrigatória perante schema da ANS, ficando a critério do prestador escolher qual enviar:
- CNPJ
- CPF
- codigoPrestadorNaOperadora
No nosso exemplo, foi escolhida a tag "codigoPrestadorNaOperadora".
A chave informada deverá ser verdadeira, ou seja, deverá existir um cadastro de prestador de serviços no sistema contendo a informação enviada. No sistema, o código do prestador fica disponível no topo do cadastro:
No exemplo acima, nosso prestador dono do XML HOSPITAL DAS CLINICAS não foi encontrado, pois o código enviado não bate com o cadastrado no sistema. Foi enviado no XML o código "1002050", sendo que no cadastro o correto seria "1003030".
Entendendo a crítica:
Ocorre quando o prestador de serviços informado na tag "contratadoSolicitante" não foi encontrado no sistema. Ocorrerá apenas em XMLs do tipo "guiaSP-SADT".
Exemplo do XML enviado:
O Solicitante Contratado é identificado por uma das três chaves abaixo no XML perante schema da ANS, logo, apenas uma é obrigatória:
- codigoPrestadorNaOperadora
- cpfContratado
- cnpjContratado
A chave informada deverá ser verdadeira, ou seja, deverá existir um cadastro de prestador solicitante no sistema contendo a informação enviada. No sistema, o código do prestador fica disponível no topo do cadastro, já o CPF/CNPJ estão localizados na aba "4. Documentação", sub-aba "Documentação" do cadastro de prestador de serviços:
No exemplo acima, nosso prestador MEDICO SOLICITANTE não foi encontrado, pois o código enviado não bate com o cadastrado no sistema. Foi enviado no XML o código "101010", sendo que no cadastro o correto seria "102030".
Entendendo a crítica:
Ocorre quando o prestador de serviços informado na tag "profissionalSolicitante" não foi encontrado no sistema. Ocorrerá apenas em XMLs do tipo "guiaSP-SADT".
Exemplo do XML enviado:
O Profissional Solicitante é identificado por três chaves no XML, sendo que todas são obrigatórias perante o schema xsd da ANS:
- conselhoProfissional
- numeroConselhoProfissional
- UF
Ambas as chaves devem ser verdadeiras, ou seja, deverá existir um cadastro de prestador solicitante no sistema contendo as três informações. No sistema, o conselho profissional, número de conselho e UF estão localizados na aba "4. Documentação", sub-aba "Registros" do cadastro de prestador de serviços:
No exemplo acima, nosso prestador MEDICO SOLICITANTE não foi encontrado, pois apesar de termos o conselho (CRM), Número do conselho (12222), não temos no cadastro a UF do conselho que deveria ser PR - Paraná.
Entendendo a crítica:
Ocorre quando o prestador de serviços informado na tag "contratadoExecutante" não foi encontrado no sistema. Ocorrerá em XMLs do tipo "guiaSP-SADT", "guiaHonorarios" e "guiaResumoInternacao".
Exemplo do XML enviado (guiaSP-SADT):
O Executante Contratado é identificado pelo sistema por uma das quatro chaves abaixo no XML, conforme rege o schema da ANS. Dentre as três primeiras, apenas uma é obrigatória: codigoPrestadorNaOperadora OU cpfContratado (se pessoa física) OU cnpjContratado (se pessoa jurídica). O CNES, independente das demais, é sempre obrigatório.
- codigoPrestadorNaOperadora
- cpfContratado
- cnpjContratado
- CNES
O sistema localizará o cadastro do prestador executante por uma das quatro chaves, caso o código, CPF/CNPJ não sejam verdadeiros, a localização se dará pelo CNES. No sistema, o código do prestador fica disponível no topo do cadastro, o CPF/CNPJ está localizado na aba "4. Documentação" sub-aba "Documentação":
O CNES também se encontra na aba 4. Documentação", porém, na sub-aba "Registros"do cadastro de prestador de serviços:
No exemplo acima, nosso prestador LABORATORIO DE ANALISES CLÍNICAS não foi encontrado, pois ambos CNPJ e CNES não batem com o cadastrado no sistema. Foi enviado no XML o CNES "1213131", sendo que no cadastro o correto seria "1212121" (conforme print acima). CNPJ no XML: "17060510000157", no sistema: "91.716.182/0001-57".
Para que o sistema não valide o prestador pelo CNES, atribuir o direito ao perfil/operador do prestador: WEB PRESTADOR - NÃO VALIDA CNES DO EXECUTANTE. Desta forma, por mais que o CNES do XML esteja divergente do cadastro o sistema não fará nenhum confronto.
Entendendo a crítica:
Ocorre quando o prestador de serviços informado na tag "localContratado" não foi encontrado no sistema. Ocorrerá apenas em XMLs do tipo "guiaHonorarios".
Exemplo do XML enviado:
O Local Contratado é identificado pelo sistema por uma das três chaves abaixo no XML, dentre elas, se codigoNaOperadora for informada, a cnpjLocalExecutante não é obrigatória, e vice-versa. Apenas cnes é obrigatório, independente das demais, perante o schema da ANS para este tipo de XML:
- codigoNaOperadora
- cnpjLocalExecutante
- cnes
O sistema localizará o cadastro do prestador local contratado por uma das três chaves acima. Caso o código/CNPJ não sejam verdadeiros, a localização se dará pelo CNES. No sistema, o código do prestador fica disponível no topo do cadastro, o CNPJ está localizado na aba "4. Documentação" sub-aba "Documentação":
O CNES também encontra-se na aba 4. Documentação", porém, na sub-aba "Registros" do cadastro de prestador de serviços:
No exemplo acima, nosso prestador HOSPITAL DAS CLINICAS não foi encontrado pois ambos o código e CNES não batem com o cadastrado no sistema. Foi enviado no XML o CNES "999999", sendo que no cadastro está vazio (conforme imagem acima). Código do prestador no XML: "1004040", no sistema: "1003030".
Para que o sistema não valide o prestador pelo CNES, atribuir o direito ao perfil/operador do prestador: WEB PRESTADOR - NÃO VALIDA CNES DO EXECUTANTE. Desta forma, por mais que o CNES do XML esteja divergente do cadastro o sistema não fará nenhum confronto e somente o realizará através da outra chave enviada.
Entendendo a crítica:
Ocorre quando o prestador de serviços informado na tag "identificacaoEquipe" não foi encontrado no sistema. Ocorrerá em XMLs do tipo "guiaResumoInternacao". No XML do tipo "guiaSP-SADT" também ocorre, porém na tag "equipeSadt".
Neste exemplo, tivemos a crítica por "Cirurgião" devido ao grau de participação enviado no arquivo XML: 00. Dependendo do que for enviado, teremos mudança na nomenclatura. Abaixo temos o de/para das participações de acordo com a Tabela 35 da ANS - Terminologia de grau de participação:
Exemplo do XML enviado (guiaResumoInternacao - grau do cirurgião 00):
O médico da equipe cirúrgica é identificado pelo sistema por uma das chaves abaixo no XML, dentre elas, se codigoPrestadorNaOperadora for informada, a cpfContratado não é obrigatória, e vice-versa. Já as: conselho, numeroConselhoProfissional e UF são obrigatórias, independente das demais, perante o schema da ANS para este tipo de XML:
- codigoPrestadorNaOperadora
- cpfContratado
- conselho
- numeroConselhoProfissional
- UF
Caso o código/CPF não sejam verdadeiros, a localização se dará pela combinação de conselho + número do Conselho e UF. No sistema, o código do prestador fica disponível no topo do cadastro, o CPF está localizado na aba "4. Documentação" sub-aba "Documentação":
Já o conselho profissional, número de conselho e UF estão localizados na aba "4. Documentação", sub-aba "Registros" do cadastro de prestador de serviços:
No exemplo acima, nosso prestador MEDICO CIRURGIAO EQUIPE não foi encontrado, pois ambos CPF e a combinação de conselho não batem com o cadastrado no sistema. Foi enviado no XML o CPF "56274752269", sendo que no cadastro o correto seria "18765227719". Já o conselho, número de conselho e UF, apesar de estarem informados no arquivo, estão vazios no cadastro do prestador, tornando impossível a localização do mesmo.
Lembrando que nesta situação, por mais que o CPF não fosse verdadeiro, o sistema tentaria encontrar pela combinação de conselho e vice-versa.
Para que o sistema NÃO efetue a validação da Equipe Sadt ou Equipe internação, é necessário que o parâmetro abaixo esteja configurado com a opção NÃO.
Em Contas > Configurações > Parametrização do sistema > aba Processamento Tiss 3x > Parâmetro: Validar equipe na importação do arquivo XML da TISS?
Entendendo a crítica:
Ocorre quando o prestador de serviços informado na tag "contratadoExecutante" não foi encontrado no sistema. Ocorrerá apenas em XMLs do tipo "guiaConsulta".
Exemplo do XML enviado:
O Prestador Contratado é identificado por uma das chaves abaixo no XML, dentre elas, se codigoPrestadorNaOperadora for informada, a cpfContratado/cnpjContratado não é obrigatória e vice-versa. Apenas CNES é obrigatório, independente das demais, perante o schema da ANS para este tipo de XML:
- codigoPrestadorNaOperadora
- cpfContratado
- cnpjContratado
- CNES
A chave a informada deverá ser verdadeira, ou seja, deverá existir um cadastro de prestador no sistema contendo a informação enviada. No sistema, o código do prestador fica disponível no topo do cadastro, já o CPF/CNPJ estão localizados na aba "4. Documentação", sub-aba "Documentação" do cadastro de prestador de serviços:
O CNES também encontra-se na aba 4. Documentação", porém, na sub-aba "Registros" do cadastro de prestador de serviços:
No exemplo acima, nosso prestador HOSPITAL DAS CLINICAS não foi encontrado pois ambos, código e CNES, não batem com o cadastrado no sistema. Foi enviado no XML o CNES "2803984", sendo que no cadastro o correto seria "9999999" (conforme print acima). Código do prestador no XML: "200407", no sistema: "1003030".
Para que o sistema não valide o prestador pelo CNES, atribuir o direito ao perfil/operador do prestador: WEB PRESTADOR - NÃO VALIDA CNES DO EXECUTANTE. Desta forma, por mais que o CNES do XML esteja divergente do cadastro o sistema não fará nenhum confronto e somente o fará através da outra chave enviada.
Entendendo a crítica:
Ocorre quando o prestador de serviços informado na tag "profissionalExecutante" não foi encontrado no sistema. Ocorrerá apenas em XMLs do tipo "guiaConsulta".
Exemplo do XML enviado:
O Profissional Executante é identificado pela combinação de três chaves no XML, sendo que todas são obrigatórias perante o schema xsd da ANS:
- conselhoProfissional
- numeroConselhoProfissional
- UF
Ambas as chaves devem ser verdadeiras, ou seja, deverá existir um cadastro de prestador no sistema contendo as três informações combinadas. No sistema, o conselho profissional, número de conselho e UF estão localizados na aba "4. Documentação", sub-aba "Registros" do cadastro de prestador de serviços:
No exemplo acima, nosso prestador MEDICO PROFISSIONAL EXECUTANTE não foi encontrado pois apesar de termos o conselho (CRM) cadastrado, não temos o número do conselho e tampouco a UF.
Entendendo a crítica:
Pode acontecer em duas formas:
Solicitante contratado
- Profissional solicitante
Ocorre quando o prestador solicitante foi encontrado corretamente no sistema, porém configurado para não ser solicitante. Ocorrerá em XMLs do tipo "guiaSP-SADT" tanto no médico informado na tag "contratadoSolicitante", quanto na "profissionalSolicitante".
Para solucionar, buscar pelo médico no sistema e analise a configuração abaixo, no cadastro de prestador de serviços > aba "3. Informações adicionais":
No exemplo acima, nosso prestador MEDICO SOLICITANTE existe corretamente no sistema com os dados informados no XML, porém está configurado que "NÃO" pode ser solicitante. Para efetuar o ajuste para modificar o campo para "SIM".
Para que o sistema NÃO efetue a validação do Profissional Solicitante/Contratado Solicitante é necessário atribuir o seguinte direito ao perfil/operador:
WEB PRESTADOR - NÃO VALIDAR SOLICITANTE NO ENVIO DO XML
WEB PRESTADOR - NÃO VALIDAR PROFISSIONAL SOLICITANTE NO ENVIO DO XML
Os direitos informados acima inibem a validação do solicitante como um todo e não somente da crítica retratada neste tópico, ou seja, caso o solicitante não exista no sistema também não haverá nenhum tipo de crítica. Logo, não validaremos se pode ser solicitante ou não.
Entendendo a crítica:
Pode acontecer em todas as tags referente a médicos executantes, exemplo:
- Prestador contratado
- Executante contratado
- Equipe médica (cirurgião, anestesista, auxiliar, etc)
Ocorre quando o prestador executante foi encontrado corretamente no sistema, porém, está configurado para não ser executante. Ocorrerá em todos os XMLs que contiverem tag de executante.
Caso ocorra, buscar pelo médico no sistema e analise a configuração abaixo, no cadastro de prestador de serviços > aba "3. Informações adicionais":
No exemplo acima, nosso prestador MEDICO EXECUTANTE existe corretamente no sistema com os dados informados no XML, porém está configurado que "NÃO" pode ser executante. Para efetuar o ajuste para modificar o campo para "SIM".
Para que o sistema NÃO efetue a validação do Profissional Solicitante/Contratado Solicitante é necessário atribuir o seguinte direito ao perfil/operador:
WEB PRESTADOR - NÃO VALIDAR EXECUTANTE NO ENVIO DO XMLWEB PRESTADOR - NÃO VALIDAR EXECUTANTE NO ENVIO DO XML
Os direitos informados acima inibem a validação do solicitante como um todo e não somente da crítica retratada neste tópico, ou seja, caso o solicitante não exista no sistema também não haverá nenhum tipo de crítica. Logo, não validaremos se pode ser solicitante ou não.
Entendendo a crítica:
Irá ocorrer somente em XMLs do tipo "guiaConsulta" que contiverem os procedimentos 10101012 e 10101039. Quando o prestador solicitante da guia for um cooperado ou ex-cooperado, é obrigatório que o executante informado no XML na tag "contratadoExecutante" seja o mesmo.
Guia exemplo:
Cadastro do solicitante da guia, aba "3. Informações adicionais" o prestador é um cooperado:
XML com o executante:
Note que o solicitante da guia é diferente do executante enviado no XML, guia de consulta e procedimento da guia 10101012. Essa combinação é suficiente para a crítica ocorrer.
Para solucionar, será necessário ajustar a guia ou acionar o prestador para que ajuste o XML, qual dos dois estiver errado. Também há a opção de ajustar o parâmetro, indicado no item abaixo, para que essa validação não ocorra, caso não seja de interesse da operadora.
Para que o sistema NÃO efetue essa validação se o solicitante cooperado é o mesmo executante do XML, é necessário que o parâmetro abaixo esteja configurado com a opção NÃO.
Em Contas > Configurações > Parametrização do sistema > aba Web Prestador > Parâmetro: Valida solicitante/executante no faturamento?
Entendendo a crítica:
Irá ocorrer em XMLs do tipo "guiaResumoInternacao" e "guiaSP-SADT", sempre com o prestador informado nas tags de "identificacaoEquipe". A validação tem por objetivo verificar se o prestador enviado nessa equipe é um credenciado da operadora e, se sim, haverá a crítica, pois neste cenário é esperado que o próprio prestador credenciado faça a sua cobrança através do faturamento web ou por XML próprio.
Exemplo de prestador enviado no XML guiaResumoInternacao:
Cadastro do prestador de serviços, na aba "3. Informações adicionais" o prestador é um cooperado:
Para solucionar, seria necessário que o prestador hospital corrigisse o XML, não enviando a cobrança de um credenciado da operadora na tag de equipe, ou remover o direito, indicado no item abaixo, para que a validação não ocorra, caso não seja de interesse da operadora.
Entendendo a crítica:
Irá ocorrer em XMLs do tipo "guiaResumoInternacao" e "guiaSP-SADT", sempre com o prestador informado nas tags de "identificacaoEquipe". A validação tem por objetivo verificar se o prestador enviado nessa equipe pertence ao corpo clínico do dono do XML.
Exemplo de prestador enviado no XML guiaResumoInternacao:
No cadastro do prestador de serviços da equipe, no botão "Corpo Clínico":
Podemos verificar que ele até pertence ao corpo, porém, está com status cancelado:
Desta forma o sistema critica nas duas situações: caso o médico da equipe não exista no corpo clínico do dono do XML, ou exista, porém cancelado.
Para solucionar seria necessário que o prestador hospital corrigisse o XML, enviando o médico correto na equipe, ou a operadora ativar o cadastro do prestador corpo clínico, caso esteja errado, ou remover o direito indicado no item abaixo para que a validação não ocorra, caso não seja de interesse da operadora.
Entendendo a crítica:
Irá ocorrer apenas em XMLs do tipo "guiaResumoInternacao", quando o código do conselho do prestador enviado na tag "identEquipe" está inválido, ou seja, foram enviados outros tipos de caracteres junto ao número. Tag "numeroConselhoProfissional".
Exemplo do número do conselho do prestador equipe enviado no XML guiaResumoInternacao:
Acima podemos notar que o conselho está composto por um tracinho ( - ) junto ao número. O sistema aceitará apenas números nessa tag pois pode ocorrer erro no banco de dados caso processado com os caracteres. Por este motivo a crítica é pertinente e é inválido que o prestador poste o arquivo desta forma.
Para solucionar seria necessário que o prestador corrigisse o XML, enviando somente o número sem caracteres especiais na tag do número de conselho do médico da equipe. Caso contrário não será possível postar o arquivo visto que não existe configuração para inibir essa validação, conforme veremos no item abaixo.