Comparação de Páginas

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:

Image Modified

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.

Image Modified

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

Image RemovedImage Added

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.

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:

Image Modified

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.

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.

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:

Image Modified

Já na tag "dadosSolicitacao->caraterAtendimento" , temos o caráter de atendimento com valor igual a 1:

Image Modified

De acordo com a Tabela 23 - Terminologia de caráter do atendimento, o valor 1 refere-se ao regime Eletivo:

Image Modified

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:

Image Modified

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:

Image Modified

Já na tag "dadosSolicitacao->caraterAtendimento" , temos o caráter de atendimento com valor igual a 4:Image Modified

De acordo com a Tabela 50- Terminologia de Tipo de Atendimento, o valor 4 refere-se a Consulta. O 11 seria o Pronto Socorro:

Image Modified

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:Image Modified

Já na tag "dadosAtendimento", note que não temos informada a tag "tipoConsulta": 

Image Modified

Abaixo deveria constar algum dos valores abaixo, conforme a tabela Tabela 52 - Terminologia de tipo de consulta da ANS: 

Image Modified

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, e que também não existe como um pacote de serviços . Essa crítica também valida se um pacote não existe ou está cancelado.

Exemplo Como exemplo do nosso XML, temos a cobrança do procedimento na tag "procedimentosExecutados" o código: 90909010, conforme consta abaixo:

Image Modified

Buscando por este esse código nos procedimentos médicos (em Contas Módulo Conta Médicas > Cadastros > Códigos de procedimentos > Procedimentos médicos Ctrl + M), verifica-se que o mesmo este não existe:Image RemovedImage Added

Buscando nos pacotes do prestador, este esse código também não é será localizado (não existe):

Image Modified

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 desse atendimento, significando que foi utilizado indevidamente:

Image RemovedImage Added

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 barrar 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á barrada 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.

Exemplo do nosso XML temos a cobrança do item 80808090, conforme consta abaixo:

Image Modified

Ainda no XML temos o prestador MEDICO PROFISSIONAL EXECUTANTE indicado na tag "equipeSADT":

Image Modified

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:

Image Modified

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:

Image Modified

Consultando nossa guia exemplo nº 3062 podemos notar que o procedimento 10102019 não consta autorizado na mesma:

Image Modified

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:

Image Modified

Consultando nossa guia exemplo nº 3064, podemos notar que o procedimento 10102019 não consta liberado, está negado:

Image Modified

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

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.

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:

Image Modified

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:

Image Modified

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 prestador LABORATORIO DE ANALISES CLINICAS:

Image Modified

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.

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:

Image Modified

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:

Image Modified

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

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 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:

Image Modified

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:

Image RemovedImage Added

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

Ainda no XML podemos observar que o prestador informou um tipo internação igual a 2, na tag "dadosInternacao->tipoInternacao".Image Modified

Segundo a 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:

Image Modified

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:

Image Modified

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 10:00:00. Ou 10h. Ou seja, a internação começou neste horário.

Image Modified

Ainda no XML temos a cobrança do item 30727162 conforme consta abaixo, onde temos "horaInicial" igual a 08:30:0008h30.   Ou seja, prestador informou que a execução do procedimento se deu neste horário:

Image Modified

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:

Image Modified

Sendo assim, é inválido que o prestador cobre um procedimento sem informar a devida hora inicial a qual ele foi executado.

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 15temos 15/11/2022:

Image Modified

Na guia, sempre será confrontada a emissão, no nosso exemplo a guia 3064 é 17/11/2022:

Image Modified

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.

Exemplo do nosso XML "guiaResumoInternacao", temos a cobrança do procedimento 30909139, e  e na tag da data de execução deste item temos 08temos 08/11/2022:

Image Modified

Na guia, sempre será confrontada a emissão, no nosso exemplo a guia 2949 é 10/11/2022:

Image Modified

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

Image Modified

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.

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:

Image Modified

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:

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 11:00:0011h, prestador MEDICO CIRURGIAO EQUIPE:

Image Modified

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.

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 14:30:00 14h30 duas vezes na mesma guia:

Image Modified

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.

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:

Voltando a nosso exemplo, no XML "guiaResumoInternacao", temos a cobrança do procedimento 30803098 - METASTASECTOMIA PULMONAR UNILATERAL (QUALQUER TECNICA):

Image Modified

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:

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:

Image Modified

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 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:

Image Modified

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 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:

Image Modified

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.

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:Image Modified

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.

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

Image Modified

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.