Críticas referentes aos Procedimentos Médicos
- Solus (Unlicensed)
- Solus - Publicação
Autor: H. S.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o procedimento cobrado no arquivo estiver configurado no sistema para que a aplicação seja para determinado sexo, porém, não o mesmo do beneficiário.
Exemplo do nosso XML, no beneficiário informado temos JESSICA DOS SANTOS:
No módulo Estrutural, podemos confirmar que pertence ao sexo FEMININO:
Voltando ao XML, temos o procedimento o qual está sendo cobrado, código: 40316149.
No cadastro do procedimento, no módulo Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Outras Configurações", podemos notar que o campo "Sexo onde se aplica" é "MASCULINO":
Sendo assim, é inválido que o prestador tente cobrar um procedimento configurado apenas para determinado sexo, onde o beneficiário indicado no arquivo não seja deste mesmo gênero.
É importante afirmar que esse tipo de crítica apenas irá ocorrer quando não houver uma prévia autorização vinculada, ou seja, não existir guia emitida no sistema sobre este atendimento. Portanto, caso o prestador tenha informado uma guia no sistema e a mesma exista, essa crítica não será válida.
Essa regra funciona desta forma, pois entende-se que esse tipo de validação, assim como várias outras, são efetuadas no momento de autorizar a guia. Consequentemente, não seria algo a ser validado posteriormente, no momento de faturar. Apenas nos casos onde não existiu autorização.
A regra para não efetuar essa validação existe para operadoras Unimeds e SOMENTE em caso de beneficiário Intercâmbio. Para casos de Intercâmbio, se a Unimed tiver a regra abaixo inserida nas configurações do módulo Servertiss/Servertiss30, a validação não será feita:
ACEITAR SEXO INVÁLIDO CASO O USUÁRIO SEJA DE INTERCÂMBIO:
Ainda assim, a regra da autorização feita acima, no item "Importante" do tópico acima, continua a valer: a validação deixará de ocorrer somente se existir guia de autorização vinculada.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o procedimento cobrado no arquivo estiver configurado no sistema como não pertence ao rol de procedimentos da ANS.
Exemplo do nosso XML, temos na tag "procedimentosExecutados" o código: 50009926 - AVALIACAO COMPORTAMENTAL (NAMA), conforme consta abaixo:
No sistema, módulo Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Regras de funcionamento", podemos notar que o campo "Pertence ao rol de procedimentos da ANS?" está configurado com "NÃO":
Sendo assim, é inválido que o prestador tente cobrar no XML um procedimento fora do rol de procedimentos da ANS.
Importante!
É importante afirmar que esse tipo de crítica apenas irá ocorrer quando não houver uma prévia autorização vinculada, ou seja, não existir guia emitida no sistema sobre este atendimento. Portanto, caso o prestador tenha informado uma guia no sistema e a mesma exista, essa crítica não será válida.
Essa regra funciona desta forma, pois entende-se que esse tipo de validação, assim como várias outras, são efetuadas no momento de autorizar a guia. Consequentemente, não seria algo a ser validado posteriormente, no momento de faturar. Apenas nos casos onde não existiu autorização.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que a operadora revise o cadastro do procedimento para confirmar se de fato não pertence ao ROL. Caso esteja correto, pode-se também utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Para que o sistema NÃO efetue a validação se o procedimento está fora do ROL de procedimentos da ANS, é necessário REMOVER o seguinte direito do perfil/operador:
WEB PRESTADOR - VERIFICAR PROCEDIMENTO PERTENCE AO ROL
Ainda assim, a regra da autorização feita acima no item "Importante" do tópico acima continua a valer: a validação deixará de ocorrer somente se existir guia de autorização vinculada.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando estiver informado na tag "dadosSolicitacao->caraterAtendimento" do arquivo um caráter de atendimento diferente do regime de atendimento configurado no sistema.
Exemplo do nosso XML, temos na tag "procedimentosExecutados" o código: 40304906 - DIMERO D - PESQUISA E/OU DOSAGEM (COM DIRETRIZ DE UTILIZACAO DEFINIDA PELA ANS), conforme consta abaixo:
Já na tag "dadosSolicitacao->caraterAtendimento" , temos o caráter de atendimento com valor igual a 1:
De acordo com a Tabela 23 - Terminologia de caráter do atendimento, o valor 1 refere-se ao regime Eletivo:
No sistema, módulo Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Outras Configurações" podemos notar que o campo "Regime de uso do procedimento" está configurado com "Somente em regime de urgência":
Sendo assim, é inválido que o prestador tente cobrar no XML um procedimento informando um determinado caráter de atendimento diferente do caráter/regime configurado para o procedimento em sistema. Foi informado Eletivo no XML e no sistema consta Somente Urgente.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que a operadora revise o cadastro do procedimento para confirmar se de fato a configuração do regime de uso está correta. Caso esteja correta, pode-se também utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o procedimento médico cobrado estiver informando código "98" no arquivo.
Exemplo do nosso XML, temos na tag "procedimento->codigoTabela" temos o valor 98 conforme consta abaixo:
Primeiramente, o sistema sempre tentará buscar por pacotes com o código enviado na tag "procedimentosExecutados". Caso não seja encontrado um pacote válido para o prestador com esta numeração, o sistema tentará buscar por procedimentos médicos. Se encontrado o procedimento, caso conste "98" na tag do código de tabela, já é suficiente para ocorrer essa crítica uma vez que 98 é apenas quando se deseja cobrar pacotes.
Sendo assim, é inválido que o prestador tente cobrar no XML um procedimento médico devidamente cadastrado no sistema, porém informando o código de tabela do qual determina que trata-se de pacotes (98).
Para solucionar, é necessário que o prestador reveja o arquivo, verifique qual das duas correções está incorreta e efetue o ajuste. Se a intenção é de fato cobrar pacote, deve-se enviar o código correto do pacote e não de procedimento médico. Caso a intenção seja cobrar procedimentos, então o código de tabela para este fim é o "22".
Caso contrário, a postagem do XML será barrada e não será possível o envio do arquivo visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando especificamente o código 10101039, porém, enviou o tipo de atendimento informado na tag dadosAtendimento->tipoAtendimento diferente de 11 - Pronto Socorro.
Exemplo do nosso XML, temos na tag "procedimentosExecutados" o código: 10101039 - CONSULTA EM PRONTO SOCORRO, conforme consta abaixo:
Já na tag "dadosSolicitacao->caraterAtendimento" , temos o caráter de atendimento com valor igual a 4:
De acordo com a Tabela 50- Terminologia de Tipo de Atendimento, o valor 4 refere-se a Consulta. O 11 seria o Pronto Socorro:
Sendo assim, é inválido que o prestador tente cobrar no XML o procedimento de pronto socorro 10101039, porém informando um tipo de atendimento que não se enquadra no "11 - Pronto Socorro".
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija o tipo de atendimento e reenvie o arquivo para nova validação, ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer apenas no envio de XML TISS via Web Prestador, do tipo "guiaSP-SADT", quando o prestador estiver cobrando um código de consulta, porém, não informa o tipo de de consulta na tag dadosAtendimento->tipoConsulta no arquivo.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 10102019 - VISITA HOSPITALAR (PACIENTE INTERNADO), conforme consta abaixo:
Já na tag "dadosAtendimento", note que não temos informada a tag "tipoConsulta":
Abaixo deveria constar algum dos valores abaixo, conforme a tabela Tabela 52 - Terminologia de tipo de consulta da ANS:
Para confirmar que o código trata-se de uma Consulta, o sistema irá verificar qual opção está configurada no cadastro do procedimento (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Principais Configurações"). Se constar CONSULTAS MÉDICAS, é considerado consulta:
Sendo assim, é inválido que o prestador tente cobrar no XML um procedimento do gênero de consulta e não informar no XML qual o tipo de consulta que foi prestado no atendimento.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador reenvie o arquivo para nova validação após inserir a informação do tipo da consulta. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando um código na tag "procedimentosExecutados" que não existe na base de dados de procedimentos ou está cancelado. Essa crítica também valida se um pacote não existe ou está cancelado.
Como exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 90909010, conforme consta abaixo:
Buscando por esse código nos procedimentos médicos (Módulo Conta Médicas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl + M), verifica-se que este não existe:
Buscando nos pacotes do prestador, esse código também não será localizado (não existe):
O prestador que o sistema utilizará para buscar os pacotes será sempre o dono do arquivo, ou seja, o prestador logado postando o arquivo na Web, o que constar na tag "origem".
Tag <OutrasDespesas>
É necessário ficar atento, pois há casos em que é enviado na Tag de "procedimentoexecutados" o código de TAXA, o que está errado.
DIÁRIAS/TAXAS devem vir na tag de outrasdespesas e não na tag de procedimentoexecutados.
Também devemos nos atentar no caso do pacote existir e mesmo assim ocorrer a crítica. Se ocorrer, verifique as configurações específicas do pacote, tais como: congênere específica, local específico, etc. É possível que exista e esteja ativo, porém não seja válido para as configurações desse atendimento, significando que foi utilizado indevidamente:
Sendo assim, é inválido que o prestador tente cobrar no XML um procedimento/pacote não existente/cancelado ou não compatível com as configurações do atendimento.
Para solucionar, se a operadora não deseja bloquear o faturamento, é necessário que o prestador reenvie o arquivo para nova validação após enviar o código correto de procedimento/pacote. Caso contrário, a postagem do XML será bloqueada e não será possível o envio do arquivo, visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer apenas no envio de XML TISS via Web Prestador do tipo "guiaSP-SADT", quando o item cobrado na tag "procedimentosExecutados" não tiver sido cadastrado como um pacote válido para o prestador informado na tag "equipeSadt", ou quando não existir o procedimento ou estiver cancelado.
Por ser um item inexistente na base de dados do sistema, é comum que a crítica venha acompanhada da outra crítica Procedimento/Pacote não existe ou cancelado, conforme consta no print acima. Por isso, é importante frisar que a crítica deste tópico tem objetivo de validar a mesma situação, porém com a busca voltada especificamente para o cadastro do prestador informado na tag da equipe médica.
Exemplo do nosso XML temos a cobrança do item 80808090, conforme consta abaixo:
Ainda no XML temos o prestador MEDICO PROFISSIONAL EXECUTANTE indicado na tag "equipeSADT":
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M), o mesmo não existe:
Buscando também nos pacotes do prestador da equipe médica, este código também não existe:
Também devemos nos atentar no caso do pacote existir e mesmo assim ocorrer a crítica. Se ocorrer, verifique as configurações específicas do pacote, tais como: congênere específica, local específico, etc. É possível que exista e esteja ativo, porém não seja válido para as configurações deste atendimento, significando que foi utilizado indevidamente:
Sendo assim, é inválido que o prestador tente cobrar no XML um procedimento/pacote não existente/cancelado também para a equipe médica SADT.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador reenvie o arquivo para nova validação após enviar o código correto de procedimento/pacote. Caso contrário, a postagem do XML será barrada e não será possível o envio do arquivo visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando um procedimento enviado na tag "procedimentosExecutados" e o mesmo não estiver liberado na guia.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 10102019 - VISITA HOSPITALAR (PACIENTE INTERNADO), conforme consta abaixo:
Consultando nossa guia exemplo nº 3062 podemos notar que o procedimento 10102019 não consta autorizado na mesma:
Sendo assim, é inválido que o prestador tente cobrar um procedimento no arquivo o qual não consta previamente emitido e liberado na guia.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador emita uma nova autorização no portal para que a operadora autorize o procedimento, somente após enviar arquivo para a cobrança do mesmo. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando um procedimento enviado na tag "procedimentosExecutados" e o mesmo não estiver autorizado na guia, existindo na guia porém com qualquer status diferente de LIBERADO. Também pode ocorrer caso o procedimento não exista na guia.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 10102019 - VISITA HOSPITALAR (PACIENTE INTERNADO), conforme consta abaixo:
Consultando nossa guia exemplo nº 3064, podemos notar que o procedimento 10102019 não consta liberado, está negado:
Caso o módulo Servertiss ou Servertiss30 tenha as regras abaixo vinculadas, dependendo do tipo da guia, essa validação não será aplicada e a guia será aceita mesmo que o procedimento não tenha sido autorizado:
- ACEITAR PROCEDIMENTOS NÃO AUTORIZADOS NA GUIA DESDE QUE A GUIA SEJA DE CONSULTA : guias que contenham procedimentos classificados como CONSULTA.
- ACEITAR PROCEDIMENTOS NÃO AUTORIZADOS NA GUIA DESDE QUE A GUIA SEJA DE REGIME INTERNAÇÃO : arquivos XML do tipo "guiaResumoInternacao".
Atenção Unimeds!
Cliente Unimed, há uma validação diferente caso opte por aceitar os procedimentos não autorizados que estão classificados como Baixo risco. Regra no módulo Servertiss ou Servertiss30: ACEITAR PROCEDIMENTOS NÃO AUTORIZADOS NA GUIA DESDE QUE O PROCEDIMENTO SEJA DE BAIXO RISCO.
Se o procedimento em questão estiver configurado como pertencente à tabela de baixo risco da Brasil, o sistema irá aceitar a guia mesmo que não esteja devidamente autorizado:
Sendo assim, é inválido que o prestador tente cobrar um procedimento no arquivo que não consta devidamente liberado na guia.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador emita uma nova autorização no portal para que a operadora autorize o procedimento, somente após enviar arquivo para a cobrança do mesmo. Ou utilizar as configurações indicadas no item abaixo, caso não seja de interesse da operadora validar essa informação.
Para que o sistema NÃO efetue a validação se o procedimento cobrado no arquivo consta com status liberado na guia, é necessário REMOVER o seguinte direito do perfil/operador:
WEB PRESTADOR - VALIDA PROCEDIMENTOS DA GUIA
Também se faz necessário que a regra TISS abaixo seja removida do módulo Servertiss ou Servertiss30:
GLOSAR PROCEDIMENTOS NÃO AUTORIZADOS NA GUIA:
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando uma quantidade maior que UM em um procedimento do tipo seriado e que não pode ser faturado mais de uma vez ao dia, enviado na tag "procedimentosExecutados". Ocorrerá somente em Unimeds, quando tratar-se de guias atendidas em Intercâmbio.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 50000560- CONSULTA AMBULATORIAL POR NUTRICIONISTA (COM DIRETRIZ DE UTILIZACAO DEFINIDA PELA ANS), com a quantidade executada igual a 2, conforme consta abaixo:
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M), o mesmo está configurado com "SIM" no campo "Procedimento Seriado?" e com "NÃO" no campo "Faturar mais de uma vez ao dia?":
Sendo assim, é inválido que o prestador tente cobrar um procedimento seriado de beneficiário em Intercâmbio com quantidade maior que 1, onde a configuração deste procedimento indica que somente pode ser faturado uma vez ao dia.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija o arquivo indicando separadamente a cobrança da quantidade do procedimento cada um com sua devida data e hora de atendimento. Caso contrário, a postagem do XML será barrada e não será possível o envio do arquivo, visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando um procedimento que é Honorário Médico, porém, o médico executante é um PJ. Essa é uma regra válida para Unimeds, visto que a cobrança de honorários só pode ser feita por prestadores PF no PTU A500.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 30404223 - TROCA DE PROCESSADOR DE FALA conforme consta abaixo:
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Outras Configurações"), o mesmo está configurado com "SIM" no campo "Procedimento de Honorário Médico":
Como o sistema identifica o prestador em cada um dos tipos de XML:
- guiaSP-SADT ➜ tag "dadosExecutante->contratadoExecutante"
- guiaHonorarios ➜ tag "dadosContratadoExecutante"
- guiaResumoInternacao ➜ tag "dadosExecutante->contratadoExecutante"
Nosso XML exemplo é do tipo "guiaSP-SADT", sendo assim, o sistema buscará o prestador para verificar se é PJ na tag "contratadoExecutante", onde temos o prestador LABORATORIO DE ANALISES CLINICAS:
Consultando o cadastro do prestador LABORATORIO, podemos notar que trata-se de um PJ:
Sendo assim, é inválido que o prestador tente cobrar um procedimento configurado no sistema como sendo de Honorário Médico, e o prestador executando informado no XML trata-se de uma Pessoa Jurídica.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija o arquivo indicando o prestador Pessoa Física correto que executou o procedimento de honorário. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Para que o sistema não efetue a validação se o procedimento cobrado é Honorário Médico e o prestador executante é PJ, é necessário REMOVER a seguinte regra TISS do módulo Servertiss30 ou Servertiss: VALIDA SE O PRESTADOR E PF EM PROCEDIMENTOS DE HONORARIO:
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador que preveem o envio de equipe médica, quando o prestador está cobrando um procedimento que é Honorário Médico, porém, não informou dados da equipe médica. Essa é uma regra válida para Unimeds, visto que a cobrança de honorários só pode ser feita por prestadores PF no PTU A500.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 30404223 - TROCA DE PROCESSADOR DE FALA conforme consta abaixo. Nessa mesma imagem podemos notar que a tag "equipeSadt" não existe no procedimento:
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Outras Configurações"), o mesmo está configurado com "SIM" no campo "Procedimento de Honorário Médico":
Sendo assim, é inválido que o prestador tente cobrar um procedimento configurado no sistema como sendo de Honorário Médico, porém não informa qual equipe médica fez a execução deste procedimento.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija o arquivo indicando a equipe médica que executou o procedimento de honorário. Caso contrário, a postagem do XML será barrada e não será possível o envio do arquivo visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer apenas no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao", quando o prestador estiver cobrando um procedimento configurado no sistema como sendo de parto, porém, não informou nenhuma declaração de nascido vivo.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 31309054 - Cesariana, conforme consta abaixo:
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Regras de funcionamento"), o mesmo está configurado com "Parto cesárea" no campo "Parto":
Neste caso, tanto "parto cesárea" quanto "parto normal" seriam válidos para considerar o procedimento como sendo obstétrico, de parto.
Sendo assim, é obrigatório que o prestador informe uma declaração de nascido vivo para o recém nascido quando o procedimento for considerado de parto, na tag "dadosInternacao->declaracoes→declaracaoNascido". Essa obrigatoriedade apenas será exigida quando o motivo de alta informado na tag "dadosSaidaInternacao->motivoEncerramento" for DIFERENTE dos valores 63 e 64, os quais, conforme a Tabela 39 - Terminologia de motivo de encerramento da ANS, referem-se ao óbito do recém nascido:
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija o arquivo indicando a declaração de nascido vivo do recém nascido, caso os motivos de alta da internação não sejam referentes ao óbito do mesmo. Caso contrário, a postagem do XML será barrada e não será possível o envio do arquivo visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer apenas no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao", quando o prestador estiver cobrando um procedimento configurado no sistema como sendo de parto, porém, informar um tipo de internação diferente de Obstétrica.
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 31309127- Parto (Via Vaginal), conforme consta abaixo:
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Regras de funcionamento"), o mesmo está configurado como "Parto normal" no campo "Parto":
Neste caso, tanto "parto cesárea" quanto "parto normal" seriam válidos para considerar o procedimento como sendo obstétrico, de parto.
Ainda no XML podemos observar que o prestador informou um tipo internação igual a 2, na tag "dadosInternacao->tipoInternacao".
Segundo a "Tabela 57 - Terminologia de tipo de internação da ANS", o 2 refere-se a Internação Cirúrgica, quando o correto neste caso seria informar o 3 - Internação Obstétrica.
Sendo assim, é inválido que o prestador cobre um procedimento de parto e não indique que esse tipo de internação não foi uma internação 3 - Obstétrica, na tag "dadosInternacao->tipoInternacao".
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija o arquivo indicando o tipo de internação correto como Obstétrica no XML, ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando um procedimento no arquivo e informando a quantidade executada deste procedimento menor ou igual a zero, na tag "quantidadeExecutada".
Exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutado->quantidadeExecutada" e temos a quantidade 0 para o código o código: 40302547:
Isto por si só já é inválido perante o sistema, visto que não é possível faturar um item sem a devida quantidade informada. Esta situação, que muitas vezes é erro de digitação no sistema terceiro do prestador, causaria erro de banco de dados no sistema se fosse possível faturar desta forma.
Sendo assim, é inválido que o prestador cobre um procedimento e não informe corretamente qual a quantidade executada do mesmo.
Para solucionar, é necessário que o prestador corrija o arquivo indicando a quantidade correta e o reenvie para nova validação.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando o prestador estiver cobrando um procedimento no arquivo que está configurado no sistema para seguir a regra de múltiplos procedimentos e vias. Porém, está enviando agrupado com quantidade maior que um na tag "quantidadeExecutada".
Exemplo do nosso XML "guiaHonorarios", temos a cobrança do procedimento na tag "procedimentosRealizados" o código: 30715270- RETIRADA DE MATERIAL DE SINTESE - RETIRADA DE MATERIAL DE SINTESE - TRATAMENTO CIRURGICO, na tag de quantidade temos 2, conforme consta abaixo:
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Principais configurações"), o mesmo está configurado com "SIM" no campo "Segue a regra dos percentuais em múltiplos procedimentos e vias?":
Sendo assim, é inválido que o prestador tente cob,rar um procedimento que segue a regra de múltiplos procedimentos e vias sem informar as quantidades de forma separada no arquivo. Algumas operadoras barram esta situação pois o agrupamento da quantidade deixa o cálculo das vias mais confuso na conta médica, principalmente se for efetuar algum tipo de glosa.
Para solucionar, é necessário que o prestador corrija o arquivo detalhando cada quantidade em uma tag de procedimento separada e o reenvie para nova validação. Ou utilizar a configuração indicada no item abaixo caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer apenas no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao", quando o item cobrado na tag "procedimentosExecutados" for informado com uma data ou hora fora do período de início e fim de internação do arquivo, informados nas tags "dadosInternacao". Tanto data, quanto hora.
Para esta análise, primeiramente deve-se analisar qual a data de início e fim e a hora de início e fim indicadas no bloco "dadosInternacao". O conteúdo deste bloco é o principal período de início e fim da internação, e isto irá direcionar os períodos dos itens cobrados no XML. Ou seja, as datas e horas indicadas nos itens devem, obrigatoriamente, estar dentro do período deste bloco.
No nosso exemplo a crítica ocorreu devida a um horário fora do período da internação principal, porém é importante afirmar que a data também pode ser a culpada por este erro.
Exemplo do nosso XML temos na tag "dadosInternacao" a hora de início do faturamento/internação igual a 10h. Ou seja, a internação começou neste horário.
Ainda no XML temos a cobrança do item 30727162 conforme consta abaixo, onde temos "horaInicial" igual a 08h30. Ou seja, prestador informou que a execução do procedimento se deu neste horário:
Esta situação é inválida e causou o erro do nosso exemplo, visto que informamos no período principal 10:00 e indicamos um horário INFERIOR no procedimento. Sendo assim, é inválido que o prestador tente cobrar no XML um procedimento com data ou horário inferior (ou superior) ao que foi indicado no bloco de internação principal.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija os horários e/ou datas de execução do procedimento e reenvie o arquivo para nova validação. Caso contrário, a postagem do XML será barrada e não será possível o envio do arquivo visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao", "guiaSP-SADT" e "guiaHonorarios" quando o procedimento for informado sem a tag "procedimentoExecutado->horaInicial", ou seja, não informou a hora de início da execução do procedimento.
Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 30727162. Note que a tag "horaInicial" não está inserida no XML:
Sendo assim, é inválido que o prestador cobre um procedimento sem informar a devida hora inicial a qual ele foi executado.
Informação!
A tag "horaInicial" não é obrigatória perante o schema de validação da ANS, ou seja, o XML permanece válido mesmo sem essa tag. A crítica deste tópico tem por objetivo obrigar o prestador a indicar essa informação, para fins de Monitoramento Tiss, PTU A500, etc.
Para solucionar, se a operadora não deseja barrar o faturamento, é necessário que o prestador corrija o arquivo indicando o horário correto de execução do procedimento e reenvie o arquivo para nova validação. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao", "guiaSP-SADT" e "guiaHonorarios", quando o prestador estiver cobrando um procedimento e informando uma data de execução na tag "procedimentoExecutado->dataExecucao" menor que a data de emissão da própria guia.
Exemplo do nosso XML "guiaSP-SADT", temos a cobrança do procedimento 10102019, e na tag da data de execução deste item temos 15/11/2022:
Na guia, sempre será confrontada a emissão, no nosso exemplo a guia 3064 é 17/11/2022:
Temos ainda um parâmetro que indica a tolerância de dias para a diferença dessas duas datas. Em Contas > Parametrizações do sistema > aba "Web Prestador" > Número de dias para validar data de atendimento no XML.
Ou seja, 17/11/2022 - 15/11/2022 = 2 dias. Porém, nossa tolerância abaixo é de ZERO dias:
Sendo assim, é inválido que o prestador tente cobrar um procedimento indicando uma data INFERIOR a data de emissão da própria guia.
Para solucionar, é necessário que o prestador corrija o arquivo enviando a data correta de execução do procedimento. Também é possível que a operadora tolere uma quantidade de dias maiores para a execução e emissão no parâmetro indicado acima. Ou ainda, utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao" e "guiaSP-SADT" quando houver cobrança de guia em internação, quando o prestador cobrar um procedimento e informar uma data de execução na tag "procedimentoExecutado->dataExecucao" maior que a data de alta informada na própria guia.
Importante!
A validação irá ocorrer somente em guias únicas, guias PRINCIPAIS. Ou seja, a validação não será feita em guias que sejam complementares à outra.
Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 30909139, e na tag da data de execução deste item temos 08/11/2022:
Na guia, sempre será confrontada a emissão, no nosso exemplo a guia 2949 é 10/11/2022:
Temos ainda um parâmetro o qual indica a tolerância de dias para a diferença dessas duas datas. Em Contas > Parametrizações do sistema > aba "Web Prestador" > Número de dias para validar data de saida no XML.
Ou seja, 10/11/2022 - 09/11/2022 = 1 dia. Porém, nossa tolerância abaixo é de ZERO dias:
Sendo assim, é inválido que o prestador tente cobrar um procedimento indicando uma data SUPERIOR a data de alta indicada na própria guia.
Para solucionar, é necessário que o prestador corrija o arquivo enviando a data correta de execução do procedimento. Também é possível que a operadora tolere uma quantidade de dias maiores para a execução e emissão no parâmetro indicado acima. Ou ainda, utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador do tipo "guiaConsulta", "guiaHonorarios" e "guiaSP-SADT" quando houver cobrança de procedimento que está configurado no cadastro do prestador para exigir guia o autorizando, porém, essa guia não existe no sistema. Por isso, é comum que essa crítica venha acompanhada da "Número de guia inválido", conforme a imagem acima.
Exemplo do nosso XML "guiaSP-SADT", temos a cobrança do procedimento 50000560 - consulta ambulatorial por nutricionista (com diretriz de uti):
O local onde configuramos se o procedimento exige uma autorização ou não é no cadastro do prestador, aba "3.Informações adicionais", no botão "Procedimentos autorizados". Para que este botão seja habilitado no prestador, é necessário que o campo "Regra de atendimento (execução)" esteja configurado com uma das três opções:
- Atende somente os serviços autorizados;
- Atende a serviços dependendo da rede de atendimento;
- Atende somente os serviços autorizados referente à sua tabela de preço.
Em nosso exemplo, o prestador está configurado com a primeira opção, sendo assim, o botão dos procedimentos autorizados é liberado normalmente:
Dentro dos procedimentos autorizados podemos notar que o código 50000560 está parametrizado "SIM" no campo "Obrigatório emitir guia para atendimento?":
Sendo assim, é inválido que o prestador tente cobrar um procedimento configurado com a necessidade de possuir uma guia autorizando a sua execução, e a guia informada no XML seja inválida ou não exista.
Para solucionar, caso a operadora queira barrar o faturamento, é necessário que o prestador emita uma autorização no Solusweb Prestador e corrija o arquivo com este número de guia reenviando o arquivo para nova validação. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Não há uma configuração específica para essa crítica da guia, porém, para inibir quaisquer validações na guia utilize uma das opções indicadas na imagem abaixo no campo "Importação de guia de consulta/SP/SADT/internação" na aba 9 do cadastro do prestador:
Lembrando que essa configuração irá inibir a validação da guia como um todo e não somente da crítica indicada, ou seja, caso o número da guia esteja inválido e inexistente na base de dados da operadora, o sistema não irá criticar.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando houver uma cobrança de procedimento que já excedeu a quantidade máxima de faturamento permitida para este procedimento no dia.
Exemplo do nosso XML "guiaSP-SADT", temos a cobrança do procedimento 20103514 - PATOLOGIA OSTEOMIOARTICULAR EM DIFERENTES SEGMENTOS DA COLUNA, com quantidade cobrada igual a 1 e a data de execução igual a 06/11/2022:
Buscando por este código nos procedimentos médicos (em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Outras configurações"), o mesmo está configurado com a quantidade 3 no campo "Qtde máxima faturada por dia ambulatorial":
Analisando contas anteriores do beneficiário do XML, podemos notar que para o mesmo beneficiário, na mesma data de execução do XML, 06/11/2022, e do mesmo procedimento 20103514, já temos 3 quantidades faturadas:
Dica!
Para buscar as contas anteriores do beneficiário com este procedimento, podemos apenas tentar buscar por seu nome pela própria tela de contas Movimentação > Digitação de Contas, ou pelo relatório Relatório de contas > Relação de contas, utilizando o filtro por código de procedimento e identificação de beneficiário.
Com as informações acima, podemos concluir que o faturamento máximo DIÁRIO configurado no procedimento foi excedido, visto que é permitido faturar 3 quantidades conforme configurado no código. Porém, o beneficiário já havia feito 3 sessões anteriores no mesmo dia. Lembrando que a mesma situação também pode ocorrer para guias em internação, neste caso, o campo da quantidade é o "Qtde máxima faturada por dia em internação".
Sendo assim é inválido que o prestador tente cobrar uma quantidade de execuções que excede a configuração máxima permitida pela operadora para o código em questão.
Para solucionar, é necessário que o prestador indique as datas corretas de execução de cada quantidade no XML e o reenvie para nova validação, caso esteja errrado. Ou utilizar a configuração indicada no item abaixo. caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao", "guiaHonorarios" e "guiaSP-SADT", quando houver uma cobrança de procedimento que já conste faturado (com as mesmas condições) em outra conta médica.
As condições para essa duplicidade ocorrer são as seguintes:
- Mesmo beneficiário;
- Mesma data de execução;
- Mesma guia;
- Mesmo procedimento;
- Mesmo horário;
- Mesmo grau de participação;
- Mesmo prestador.
Logo, para que a crítica ocorra, é necessário que TODAS as informações acima que são enviadas no XML já existam em uma conta médica no sistema.
Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 30803098, Grau 00 - Cirurgião, data 15/11/2022, horário 11h,prestador MEDICO CIRURGIAO EQUIPE:
Buscando pela guia 3161 em Contas > Movimentação > Outras opções de faturamento.... > Faturamento de guias Ctrl G, podemos observar que temos a conta abaixo já faturada ligada à essa guia:
Sendo assim temos a duplicidade confirmada, visto que as informações enviadas no XML são exatamente iguais as que constam na conta acima: mesma data, mesmo procedimento, guia, beneficiário, horário, grau e prestador. Neste caso, é inválido que o prestador tente cobrar um atendimento inteiro em duplicidade. Se ao menos uma dessas informações fosse diferente, já não seria considerada a duplicidade.
Mesma guia / mesmo procedimento / mesmo grau de participação / mesmo prestador
Dessa forma, caso o faturamento já tenha sido realizado para a mesma guia/procedimento/grau de participação ou ainda mesmo prestador, caso seja apresentado o faturamento por XML ou no Web Prestador será feito o bloqueio e a mensagem será emitida.
É importante informar que caso o procedimento esteja TOTALMENTE glosado, a duplicidade não será considerada e não haverá a crítica, pois neste caso consideramos uma reapresentação do prestador.
Para solucionar, se a Operadora não deseja barrar o faturamento, é necessário que o prestador reveja o caso e corrija o arquivo, alterando a informação que estiver errada ou inibindo a cobrança em duplicidade. Caso contrário, a postagem do XML será barrada e não será possível o envio do arquivo visto que não há configuração para inibir essa crítica, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao" e "guiaSP-SADT", quando houver uma cobrança de procedimento duplicada no próprio arquivo enviado.
As condições para essa duplicidade ocorrer são as seguintes, dentro do mesmo arquivo XML conter um ou mais itens com:
- Mesmo procedimento;
- Mesma guia;
- Mesma data de execução;
- Mesma hora de execução.
Exemplo do nosso XML "guiaSP-SADT", temos a cobrança do procedimento 40101010, data 23/11/2022,horário 14h30 duas vezes na mesma guia:
Ou seja, temos uma cobrança exatamente duplicada de item para essa guia onde código, data e horário são exatamente iguais e, por este motivo, ocorre a crítica da duplicidade. Se ao menos um dos campos fosse diferente, já não seria considerada a duplicidade para essa validação.
Sendo assim, é inválido que o prestador tente cobrar um procedimento em duplicidade com outro no mesmo arquivo.
Para solucionar, é necessário que o prestador reveja o arquivo e ajuste o procedimento, caso esteja errado, ou remova o mesmo para enviar novo arquivo para validação. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Para que o sistema não efetue a validação se o procedimento cobrado está em duplicidade com outro procedimento no mesmo arquivo, é necessário REMOVER a seguinte regra TISS do módulo Servertiss30 ou Servertiss: VALIDA PROCEDIMENTO DUPLICADO NO XML TISS.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador do tipo "guiaResumoInternacao" e "guiaSP-SADT", quando houver uma cobrança de procedimento que o prestador não estiver autorizado a executar.
A análise dessa crítica deve ser feita com base na regra de execução de atendimentos no cadastro do prestador. O prestador utilizado nos dois arquivos será sempre o da tag "dadosExecutante->contratadoExecutante". A regra de execução do prestador fica na aba "3.Informações adicionais", campo "Regra de atendimento (execução)":
Com exceção da opção "2 - Atende todos os serviços", a qual não é necessário configurar mais nenhum cadastro, visto que o prestador poderá atender qualquer código, todas as demais possuem configuração específica.
A seguir, demonstraremos uma explicação sucinta de como é o funcionamento de cada opção do campo de regra de execução do prestador:
Nesta opção, o sistema libera o botão "Procedimentos autorizados" no cadastro do prestador para que a operadora cadastre quais são os procedimentos que o prestador poderá executar. Essa é a opção mais comumente utilizada e a busca se dará no que contiver cadastrado neste local, basicamente:
Nesta opção, o local onde se cadastram os procedimentos médicos autorizados para o prestador fica em Contas > Cadastros > Especialidades médicas, na aba "Procedimentos autorizados a realizar". Sendo assim, todos os códigos que constarem nesse cadastro são os autorizados na especialidade do prestador:
A especialidade utilizada será aquela que vier do arquivo na tag "CBOS".
Nesta opção, o sistema libera o botão "Procedimentos autorizados" no cadastro do prestador e a busca será com base na rede do beneficiário. Deverá haver o procedimento autorizado cadastrado com alguma rede pertencente ao beneficiário. Para a busca desta rede, o sistema irá buscar a rede tanto no cadastro do plano, quanto no contrato, quanto no próprio cadastro do beneficiário.
Uma vez obtendo a(s) rede(s), o sistema irá confrontar essa(s) rede(s) com aquela que estiver cadastrada nos procedimentos autorizados do prestador no campo abaixo:
Caso não exista nenhum procedimento autorizado com a rede do beneficiário informada no campo acima, o sistema irá considerar aquele que estiver com o campo da rede vazia, ou seja, o procedimento em questão não é específico de nenhuma rede. Logo, está válido para todas.
Nesta opção, o sistema considerará como autorizados todos os procedimentos que estiverem cadastrados na tabela de preços mais recente do prestador com base na data de atendimento no XML, no Faturamento Linear.
Uma vez que obteve a tabela, todos os procedimentos que estiverem na mesma serão os autorizados do prestador, em Contas > Tabelas > Tabelas de preços de procedimentos:
Esta opção é uma junção das opções 3 e 5. Nesta configuração o sistema considerará como autorizados todos os procedimentos que estiverem cadastrados na tabela de preços mais recente do prestador, com base na data de atendimento no XML, no Faturamento Linear. Além disso, estes mesmos procedimentos devem estar cadastrados na especialidade do prestador, em Contas > Cadastros > Especialidades médicas, na aba "Procedimentos autorizados a realizar".
A especialidade utilizada será aquela que vier do arquivo na tag "CBOS".
Tabela de preços:
Esta opção é uma junção das opções 1 e 5. Nesta configuração, o sistema libera o botão "Procedimentos autorizados" no cadastro do prestador para que a operadora cadastre quais são os procedimentos que o prestador está autorizado a executar. Além disso, estes mesmos procedimentos deverão constar na tabela de preços mais recente do prestador com base na data de atendimento no XML, no Faturamento Linear:
Tabela de preços:
Voltando a nosso exemplo, no XML "guiaResumoInternacao", temos a cobrança do procedimento 30803098 – METASTASECTOMIA PULMONAR UNILATERAL (QUALQUER TECNICA):
Nosso prestador HOSPITAL DAS CLINICAS está configurado com a opção mais utilizada, "1 – Atende somente os serviços autorizados":
Nos procedimentos autorizados do prestador, podemos notar que o código cobrado 30803098 até existe no cadastro, porém, sua data de execução estará válida somente a partir de 01/01/2023, e em nosso XML a data de atendimento ocorreu em 15/11/2022:
Importante!
Em nosso exemplo, o procedimento não estava válido devido à data de início do procedimento, sendo assim, é importante frisar que qualquer configuração divergente do XML
para com o procedimento autorizado também causaria a crítica.
Exemplo 1: XML internação, porém procedimento autorizado somente em natureza Ambulatorial;
Exemplo 2: XML ambulatorial, porém procedimento autorizado somente em natureza Internação;
Exemplo 3: XML com especialidade "X", porém procedimento autorizado somente para a especialidade "Y";
Exemplo 4: XML com caráter de urgência, porém procedimento autorizado somente para regime eletivo, e por aí continua.
Resumindo, todas as configurações devem ser correspondentes com o atendimento cobrado no XML.
Sendo assim, a cobrança do procedimento ainda não é válida para o prestador, e por este motivo é bloqueado, visto que ele tenta cobrar um código não autorizado em seu cadastro, de acordo com a configuração indicada.
Para solucionar, é necessário que a operadora reveja o cadastro do procedimento autorizado, se está correto ou não. Caso correto, simplesmente bloquear o prestador nesta situação. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer em todos os tipos de envio de XML TISS via Web Prestador, quando houver uma cobrança de procedimento em que ambos, prestador e procedimento, estejam configurados para que necessitem de laudo médico para faturar, porém, o laudo ainda não foi enviado.
Exemplo do nosso XML "guiaSP-SADT", temos a cobrança do procedimento 40808149 - Densitometria Ossea - Corpo inteiro:
Para que seja obrigatório o envio de laudo médico antes do faturamento, é necessário que procedimento e prestador estejam configurados para tal. No procedimento, em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, aba "Regras de funcionamento", campo "Obrigatório envio de Laudo Médico?" configurado com a opção "Sim - Faturamento da web":
O prestador utilizado para a validação será sempre o local de atendimento da guia. No cadastro do prestador, aba "8.Opções do portal Web", configurado com "SIM" no campo "Obriga laudo no faturamento web?":
Uma vez que essas duas opções estejam configuradas, caso o prestador não tenha feito o envio prévio do laudo do procedimento, haverá a crítica. Sendo assim, é inválido que ele tente cobrar um procedimento que exija anexo do laudo e onde o próprio prestador também tenha esta exigência, porém o laudo não foi enviado.
Para solucionar, é necessário que o prestador efetue o envio do laudo médico através da opção Solusweb Prestador > Movimentação > Exames Laboratoriais, pois uma vez configurada a obrigatoriedade, não há direito ou parâmetro que iniba a crítica de ocorrer, conforme veremos no item abaixo.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador nos tipos "guiaSP-SADT" e "guiaResumoInternacao", quando houver uma cobrança de procedimento cujo valor negociado não esteja cadastrado no sistema.
Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 31003397 - Ileo Meconial - Tratamento Cirurgico:
O prestador utilizado para a busca dos valores será sempre o da tag "dadosExecutante->contratadoExecutante", em ambos os tipos de arquivo, salvo exceção quando a operadora estiver com o parâmetro de validar equipe configurado com "SIM" (clique aqui para visualizar o parâmetro).
Para encontrar o valor do procedimento, o sistema fará uma busca no cadastro do prestador em todos os locais onde podemos inserir a negociação, sendo eles: faturamento específico, faturamento por plano e faturamento linear:
Note que o fato do sistema não encontrar de forma alguma o procedimento configurado em um das opções acima não é somente o motivo, pois, por exemplo, podemos ter sim o procedimento configurado no faturamento específico, porém com configurações diferentes do atendimento. Natureza diferente, regime, data de início, validade, local de atendimento/especialidade/rede específica, idade, dentre outras configurações existentes dentro do faturamento específico.
Não encontrando o procedimento valorado em nenhum destes locais acima, ou não batendo a configuração conforme explicado no quadro "Dica", a última opção do sistema será em Contas > Configurações > Configurações do sistema > aba '3.Configurações "C"', nos campos de tabela padrão da Operadora:
Como não foi encontrado o procedimento valorado em nenhuma das opções acima, haverá a crítica. Sendo assim, é inválido que o prestador tente cobrar um procedimento que não conste negociado com a operadora.
Para solucionar, é necessário que a operadora reveja o cadastro de negociações do prestador e efetue a inserção do valor negociado do procedimento na opção pertinente, ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador nos tipos "guiaSP-SADT" e "guiaResumoInternacao", quando houver uma cobrança de procedimento cujo o valor negociado dentro do sistema estiver MENOR que o valor enviado pelo prestador no arquivo, ou seja, o prestador está cobrando um valor maior no item.
Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 31003397 - Ileo Meconial - Tratamento Cirurgico, com valor unitário igual a 600,00:
O prestador utilizado para a busca dos valores será sempre o da tag "dadosExecutante->contratadoExecutante" em ambos os tipos de arquivo, salvo exceção quando a operadora estiver com o parâmetro de validar equipe configurado com "SIM" (clique aqui para visualizar o parâmetro).
Para encontrar o valor do procedimento, o sistema fará uma busca no cadastro do prestador em todos os locais onde podemos inserir a negociação, sendo eles: faturamento específico, faturamento por plano e faturamento linear:
Não encontrando o procedimento valorado em nenhum destes locais acima, ou não batendo a configuração no caso do faturamento específico (regime, natureza, data de validade, data de início, etc), a última opção do sistema será em Contas > Configurações > Configurações do sistema > aba '3.Configurações "C"', nos campos de tabela padrão da operadora:
Em nosso exemplo, o prestador possui uma negociação de tabela de preço no faturamento linear e o procedimento existe na nesta tabela, porém, o valor dele é abaixo do que foi enviado no arquivo:
Se o procedimento estiver cadastrado em qualquer uma das três opções acima, porém com valor INFERIOR ao enviado no XML, ocorrerá a crítica. No caso nosso prestador enviou 790,00 e sua negociação é inferior, 690,00. Sendo assim, é inválido que ele tente efetuar essa cobrança.
Para solucionar, é necessário que o prestador reveja o valor do item e ajuste no arquivo para reenviá-lo para nova validação. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Para que o sistema não efetue a validação se o procedimento cobrado está negociado com valor inferior ao enviado no arquivo, é necessário REMOVER as seguintes regras TISS do módulo Servertiss30:
VALIDA VALORES DE TABELA NA IMPORTAÇÃO XML TISS
VALIDA VALORES DE TABELA DE PROCEDIMENTO NA IMPORTAÇÃO XML TISS
Se ao menos uma das duas regras estiver configurada já é o suficiente para ocorrer a validação.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador nos tipos "guiaSP-SADT" e "guiaResumoInternacao", quando houver uma cobrança de equipe de auxiliar no procedimento que não está previsto na tabela de preços do prestador. Tag "identEquipe" para o XML do tipo internação e tag "equipeSadt" para XML de sp/SADT.
Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 31003397 - Ileo Meconial - Tratamento Cirurgico, com uma equipe de grau 03, que se refere ao 3º auxiliar do procedimento:
O prestador utilizado para a busca da tabela será sempre o da tag "dadosExecutante->contratadoExecutante" em ambos os tipos de arquivo, salvo exceção quando a operadora estiver com o parâmetro de validar equipe configurado com "SIM" (clique aqui para visualizar o parâmetro).
Para encontrar a quantidade de auxiliares previstos na tabela do procedimento, o sistema fará uma busca no cadastro do prestador no botão "Faturamento Linear":
Em nosso prestador exemplo, temos a tabela abaixo configurada, onde o procedimento 31003397 está configurada a permissão de apenas 02 auxiliares:
Uma vez que foi enviado o 3º auxiliar no XML, é pertinente a crítica visto a configuração prevista na tabela. Sendo assim, é inválida essa cobrança de um grau de participação maior do que 02 auxiliares no procedimento.
Para solucionar, é necessário que o prestador reveja a cobrança do auxiliar e efetue a correção no arquivo, se for o caso, e o reenvie para nova validação. Ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da operadora validar essa informação.
Para que o sistema não efetue a validação se o número de auxiliares do procedimento cobrado está previsto na tabela de preços do prestador, é necessário REMOVER as seguintes regras TISS do módulo Servertiss30:
VALIDA VALORES DE TABELA NA IMPORTAÇÃO XML TISS
VALIDA VALORES DE TABELA DE PROCEDIMENTO NA IMPORTAÇÃO XML TISS
Se ao menos uma das duas regras estiver configurada já é o suficiente para ocorrer a validação.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador nos tipos "guiaSP-SADT", "guiaResumoInternacao" e "guiaHonorarios" quando houver uma cobrança de grau de participação no procedimento que não está permitido em seu cadastro no sistema.
Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 40101010 - ECG CONVENCIONAL DE ATE 12 DERIVACOES, com o grau de participação 12 - Clínico (clique aqui para visualizar a terminologia de graus da ANS):
No cadastro do procedimento, em Contas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl M, temos a opção no botão direito "Graus de participação permitidos":
Em nosso procedimento exemplo, temos um grau configurado o que nos indica que apenas o 11 - Auxiliar SADT está permitido para este procedimento:
Uma vez que existe grau de permissão configurado no procedimento, é inválido que o prestador tente cobrar um tipo diferente no XML. Sendo assim a cobrança do grau diferente se torna inválida e a crítica é pertinente.
Para solucionar, é necessário que o prestador reveja a cobrança do grau de participação no procedimento e efetue a correção no arquivo, se for o caso, e o reenvie para nova validação. Caso o erro esteja na operadora, basta ajustar os graus permitidos no procedimento para inserir demais graus se for necessário.
Entendendo a crítica
Pode ocorrer no envio de XML TISS, via Web Prestador nos tipos "guiaSP-SADT" e "guiaResumoInternacao", quando houver uma cobrança de procedimento que contenha o grau de participação 06, e caso não esteja configurado na tabela do prestador o campo porte Anestésico.
Nesse exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento "10101012 - CONSULTA EM CONSULTORIO (NO HORARIO NORMAL OU PREESTABELECIDO".
No Cadastro do prestador, Módulo Contas > Cadastros > Prestadores de serviço > selecione o prestador > aba "9 Configurações do Tiss" > se o prestador tiver a regra "VALIDA VALORES DE TABELA DE PROCEDIMENTO NA IMPORTAÇÃO XML TISS" configurada ou estiver informado no Servertiss30, configurado no botão 
de configurações/parametrizações, no cadastro de regras, mais as configurações informadas abaixo, haverá a crítica mencionada.
O prestador utilizado para a busca dos valores será sempre o da tag "dadosExecutante > contratadoExecutante", em ambos os arquivos.
Para encontrar a regra do procedimento, o sistema fará uma busca no cadastro do prestador em todos os locais, onde podemos inserir a negociação, no caso será o "faturamento linear":
Conforme o Cadastro do Faturamento linear, na tabela do prestador, acesse:
Módulo Contas > Cadastros > Prestadores de serviço > Selecione um prestador > botão “faturamento linear” > na tabela de preço configurada > aba "Cadastro" > botão “...” na tabela de preço, no procedimento informado no campo "Porte Anestésico" está como "0", ou seja, é diferente do que está sendo enviado no arquivo que é definido pela tag "<ans:grauPart>":
Como não foi encontrado o procedimento com o porte, informado na tabela do prestador com o porte anestésico, haverá a crítica. Sendo assim, é inválido que o prestador tente cobrar um procedimento que não tenha um porte anestésico que não conste negociado com a Operadora.
Para solucionar, é necessário que a Operadora reveja o cadastro de negociações do prestador e efetue a inserção do porte anestésico do procedimento na opção pertinente, ou utilizar a configuração indicada no item abaixo, caso não seja de interesse da Operadora validar essa informação.
Para que o sistema não efetue a validação se o procedimento está negociado no cadastro do prestador, é necessário REMOVER o seguinte direito do cadastro do prestador ou do servertiss30 e REMOVER as configurações na tabela do prestador no faturamento linear.
Prestador: Módulo contas > Cadastros > Prestadores de serviço > selecione o prestador > aba 9 Configurações do Tiss > Remover a regra do tiss, e as demais configurações da tabela do procedimento.
Servertiss30: configurado no botão de configurações/parametrizações (), na tela de Parametrizações de negócio do processamento TISS.
VALIDA VALORES DE TABELA DE PROCEDIMENTO NA IMPORTAÇÃO XML TISS.
Entendendo a crítica
Pode ocorrer no envio de XML TISS via Web Prestador nos tipos "guiaSP-SADT", "guiaResumoInternacao" e "guiaHonorarios" e ainda que tenham materiais e medicamentos, quando apresentado no XML um valor pelo prestador negativo, como no exemplo abaixo:
