01. DADOS GERAIS
| Produto: | TOTVS Saúde Planos |
|---|---|
| Linha de Produto: | Datasul |
| Segmento: | Saúde |
| Módulo: | HAT - Atendimento ao Público |
| Função: | Webservices TISS |
| País: | Brasil |
| Requisito: | DSAUGPSAUTOR-13147 |
02. SITUAÇÃO/REQUISITO
Com o objetivo de dar continuidade à estratégia de evolução tecnológica dos produtos da linha Datasul, é necessário disponibilizar um novo serviço para os Webservices TISS, eliminando a dependência do Foundation Saúde.
O objetivo deste documento é apresentar os detalhes do novo serviço para os Webservices TISS no Tomcat, criado para a substituir o atualmente em uso no JBoss.
03. SOLUÇÃO
Foi realizada a implementação das funcionalidades destacadas abaixo, dando origem ao novo serviço para os Webservices TISS.
A versão mínima para utilização do serviço é a 12.1.2407, com liberação da release no dia 01/07/2024.
É possível utilizar o serviço de forma híbrida com o Foundation Saúde, realizando a migração parcialmente, conforme detalhado na aba Procedimento para Utilização.
A implementação descrita no documento estará disponível a partir da atualização da release no cliente.
O pacote está disponível no portal (https://suporte.totvs.com/download).
Com o novo serviço, a aplicação htzfoundation.ear (JBoss) passa a ser dividida em dois artefatos distintos no Tomcat, contendo somente os Webservices TISS conforme a versão:
| Versão TISS | Artefato |
|---|---|
| 4.01.00 | totvs-hgp-tiss-webservices-40100.war |
| 4.00.01 | totvs-hgp-tiss-webservices-40001.war |
Versões TISS anteriores à 4.00.01 não estão contempladas.
Para que a comunicação funcione corretamente, é necessário que o Tomcat onde é executado o serviço totvs-hgp-tiss-webservices-40100.war e totvs-hgp-tiss-webservices-40001.war reconheça as variáveis abaixo. A configuração pode ser feita diretamente nos scripts de inicialização do Tomcat (mais detalhes e exemplos aqui: Como criar variaveis de ambiente visiveis ao Datasul no Tomcat) ou mesmo diretamente como variáveis de ambiente do sistema operacional:
TOTVS_HOST: <host>:<porta> do serviço do Tomcat do Datasul. Ex: http://meu-datasul:8080
TOTVS_USERNAME: usuário de login que será utilizado para autenticação Basic no Datasul para execução dos serviços
TOTVS_PASSWORD: senha que será utilizada junto ao parâmetro acima
Obs: estas variáveis são utilizadas por outras aplicações, portanto é possível que já estejam configuradas no seu ambiente, e nesse caso, nenhuma ação é necessária, apenas a conferência.
Dica para validar esta etapa
Após configurar as variáveis de ambiente e reiniciar o Tomcat, utilize a URL abaixo para validar se o ambiente as reconheceu corretamente:
http://<SERVIDOR>:<PORTA>/totvs-hgp-webservices/ptu/v8/integrations/gateway/serverInfo
O resultado deve ser semelhante a isto:
As variáveis precisam aparecer nesta consulta antes de prosseguir para a próxima etapa. Caso contrário ocorrerão problemas de comunicação.
O novo serviço utiliza o conceito de Broker Escalável, onde é possível direcionar as chamadas ao Progress para um broker específico, isolando o back-end de outras aplicações, como o ERP por exemplo.
Toda comunicação encaminhada da aplicação totvs-hgp-tiss-webservices-40100.war ou totvs-hgp-tiss-webservices-40001.war para o Progress enviará na requisição a chave "x-totvs-server-alias" como "totvs-saude-planos-tiss-webservices", sendo necessário que o cliente inclua através do Empresas do Foundation (html.companies) um novo registro contendo esse alias.
Exemplo:
No programa html.companies (Empresas do Foundation), criar um novo registro nos Cadastros relacionados → Servidores de aplicação, contendo o alias "totvs-saude-planos-tiss-webservices":
Caso o cliente deseje isolar a parte Progress dos Webservices TISS em um broker separado, deve ser criada uma nova instância do PASOE, referenciando-a através do campo "Servidor Aplicação". Para maiores detalhes sobre a criação da instância no PASOE, ver a documentação: Criando uma instância PASOE através do OpenEdge Explorer
Caso o cliente não deseje fazer essa separação, basta criar o registro com o alias "totvs-saude-planos-tiss-webservices" referenciando para o mesmo "Servidor Aplicação" existente.
Na página Broker Escalável - Exemplo de como fazer uso do aplicativo e alias para chamadas REST é possível verificar maiores detalhes sobre essa configuração.
Para integrar com o novo serviço, deve ser realizada a autenticação do prestador na própria mensagem, conforme previsto pelo manual da TISS:
Exemplo de preenchimento no XML:
A habilitação do prestador ocorre através do cadastro Manutenção de Usuários Portal do Prestador (hat.secretary).
- O campo loginPrestador a ser informado no XML será o Usuário informado nesse cadastro
- O campo senhaPrestador a ser informado no XML será a Senha informada nesse cadastro, em formato MD5
Exemplo - formato MD5 de "totvs@123" gerado através do link https://www.md5hashgenerator.com/:
Na aba Prestadores Associados deve haver o vínculo do prestador informado na tag "codigoPrestadorNaOperadora" com o papel de Serviço:
Caso o papel esteja como Padrão, o Status como Inativo, o vínculo com o prestador não exista ou a senha não corresponda, o usuário não terá permissão para integrar com o serviço, sendo retornada a mensagem:
- Falha na autenticação. Usuário ou senha incorretos ou o usuário informado não tem permissão para utilizar esse serviço nesse prestador e/ou versão da TISS
- Exemplo:
Não houve alteração no processo de utilização das funcionalidades que envolvem os Webservices TISS. Todas as regras de negócio (incluindo CPC's) foram mantidas.
O que irá diferenciar os serviços será o endpoint com que o prestador realizará a integração de cada mensagem, conforme destacado a seguir:
- Solicitação Demonstrativo de Retorno: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/solicitacaoDemonstrativoRetorno
- Solicitação Status Protocolo: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/solicitacaoStatusProtocolo
- Envio de Documentos: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/envioDocumentos
- Cancela Guia: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/cancelaGuia
- Verifica Elegibilidade: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/pedidoElegibilidade
- Comunicação Beneficiário: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/comunicacaoBeneficiario
- Solicitação Status de Autorização: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/solicitaçãoStatusAutorizacao
- Solicitação Status Recurso Glosa: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/solicitaçãoStatusRecursoGlosa
- Recurso Glosa: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/recursoGlosa
- Solicitação Procedimento: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/solicitacaoProcedimento
- Lote Anexo: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/loteAnexo
- Lote Guias: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-<versao>/api/loteGuias
É necessário substituir o <servidor> e <porta> conforme seu ambiente e a <versao> conforme a TISS (40100 para 4.01.00 ou 40001 para 4.00.01).
Exemplo comparativo de endpoints da TISS 4.01.00:
Para validar se um endpoint está no ar, pode ser acessado o endereço via navegador, acrescido de ".wsdl".
- Exemplo: http://<servidor>:<porta>/totvs-hgp-tiss-webservices-40100/api/solicitacaoProcedimento.wsdl - deverá ser retornada a estrutura XML da mensagem.
Dica
Um prestador pode consumir ambos serviços simultaneamente .
Exemplo: Para Solicitação de Procedimentos, integrar com o endpoint antigo e para o Cancelamento de Guia, integrar com o endpoint novo.
Essa abordagem permite à Operadora realizar a homologação/migração de forma parcial, por prestador e por mensagem.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas