Um exemplo de Uso da Arquitetura SIP para Implementação de Integração Automatizada de Dados de Contas Médicas e Senhas / Autorizações

Objetivo

Esse documento tem como objetivo demonstrar um exemplo de uso do aplicativo IWSip para implementar a integração entre o Sistemas de Gerenciamento de Contas Médicas (SGCM) de Operadoras com o software IW-Health.

Definição Sucinta de Escopo dos Sistemas Envolvidos na Integração

SGCM : (Sistema de Gerenciamento de Contas Médicas da Operdora) : mplementa a camada operacional (cadastramento de senhas / autorizações , e registros de contas médicas com regras de pré-auditoria (checagem de regras contratuais e bloqueio de procedimentos médicos infactíveis).

IW-Health: Implementa recursos avançados de estratificação de contas médicas através de tecnologia (BI – Business Inteligence) extensível (onde novos escores ou estratificações podem ser declarados dinamicamente). Esses recursos se integram com filtros inteligentes que permite implementar processos de Triagem (screening) e gerenciamento de casos e doenças crônicas integrados a um prontuário eletrônico (WEB).

Diagrama de Contexto

O diagrama abaixo ilustra os requisitos do fluxo de informações requeridos pelo processo de integração proposto:

[1] – Integração dos dados de contas médicas : Migração sistematizada dos dados analíticos das contas médicas
[2] – Integração dos dados de senhas e autorizações de internações : Migração sistematizada dos dados de senhas e autorizações

[1] – Integração dos dados de contas médicas

Sentido da Integração :

SGCM para IW-Health

Modelo de Dados

Vide : Modelo de Dados Padronizado para Importação de Dados de Contas Médicas , Senhas e Autorizações

Gatilhamento do Fluxo de Dados

Diário : em horário noturno de baixa carga de processamento nos servidores da Operadora (exemplo: 00:00).

Escopo da Transferência

Deverão ser transferidos todos dados referentes às contas médicas de todas contas (IDPROTOCOL) que sofreram qualquer tipo de alteração no SGCM desde a última transferência bem sucedida (DUTBS) realizada para o IW. Nota: O próprio SIP armazena internamente a data e hora da última transferência de dados bem sucedida e irá passar essa informação como parâmetro de filtragem a cada ciclo de execução.

[2] – Integração dos dados de senhas e autorizações de internações

Sentido da Integração :

SGCM para IW-Health

Modelo de Dados

Vide : Modelo de Dados Padronizado para Importação de Dados de Contas Médicas , Senhas e Autorizações

Gatilhamento do Fluxo de Dados

Horário : A cada 60 minutos , respeitando intervalo de bloqueio, se existirem, a serem definidos pela Operadora.

Escopo da Transferência

Deverão ser transferidos todos dados referentes às senhas e autorizações que tenham sido geradas e/ou alteradas após uma data e hora da última transferência de dados bem sucedida (DUTBS), no contexto de senhas e autorizações, fornecida como parâmetro de filtragem pelo (SIP).

Descritivo da Arquitetura de Transferência de Informações entre Servidores

A arquitetura física para implementação das integrações propostas consiste nos seguintes elementos :

Um software servidor do processo de integração (IW-SIP) (tecnologia Java) desenvolvido pela Incoway
Driver JDBC para acesso ao banco de dados do SGCM (oracle ou sqlserver)
Servidor IW-Health remoto acessível através de protocolo http.

Requisitos de Infra-estrutura

Instalação de maquina virtual java JRE (1.5) na estação servidora onde será instalado o IW-SIP.
Instalação do IW-Sip propriamente dita
Liberação de portas de acesso ao servidor de banco de dados via tecnologia JDBC (exemplo:liberação da porta 1433 na estação servidora de banco de dados quando se tratar de banco de dados SQLSERVER)
Liberação no firewall da Operadora de acesso à url do servidor remoto do IW-Health com liberação dos protocolos FTP e HTTP.

Especializações no Driver de Leitura dos Dados de Contas Médicas

O tópico “Importando carteiras de segurados e dados de histórico de utilização da rede credenciada” do manual do IW apresenta um modelo de driver de leitura de contas médicas utilizado tipicamente para transferência de dados no contexto de Estudos Preliminares (estratificações) dos dados de contas médicas da Operadora. Em estágios mais avançados onde a empresa de monitoramento (que utiliza a tecnologia IW-Health) estabelece um vinculo de prestação de serviços estável onde os processos de “Estratificação de contas médicas” , “Triagem de Pacientes Crônicos” e “Gerenciamento de Casos e Doenças” são executados em regime “contínuo” , o método de obtenção de contas médicas baseado em envios de arquivos de contas integralizadas em períodos de referência fechados não oferece uma “dinâmica” (interatividade) satisfatória. Para essas situações, o driver de leitura das contas médicas deverá ser modificado de modo a estar preparado para ler arquivos que contenham dados de contas de diversos períodos de referência. Na verdade, nessa condição operacional , o IW-SIP estará obtendo e transferindo para o servidor do IW-Health arquivos nos quais estarão presentes todos os itens das contas médicas que sofreram qualquer tipo de alteração desde a data_hora da última transferência bem sucedida. Ou seja, não se trata somente dos “itens dessas contas que foram alterados” mas a “totalidade dos itens das contas médicas que tiveram qualquer alteração em qualquer um de seus itens”. Por exemplo: Se tivermos uma conta médica apresentada por um prestador credenciado na Operadora com IDPROTOCOL = 100. E vamos supor que nessa conta médica tenham 250 itens (materiais, medicamentos, procedimentos etc). E vamos supor que um desses itens recebeu um lançamento de glosa na Operadora. Então todos os 250 itens dessa conta serão retransmitidos para o IW-Health.

Nota: No modelo de dados de contas médicas temos a coluna denominada IDPROTOCOL (tabela GLBMONITORINGCOST) que armazena o id do protocolo de entrega de contas gerado pelo SGCM.

Com base nos conceitos acima expostos foi desenvolvido um novo driver de leitura de contas (também publicado na instalação nativa do IW-Health) que denominados

A figura a seguir o acesso às informações desse driver no IW que na terminologia nativa do IW é comumente denominado “02-AnCart – Custos_SIP”. Abaixo apresentamos apenas a título de ilustração uma transcrição do arquivo de configuração desse driver (em casos reais de uso é recomendável obter a configuração exemplo diretamente do banco matriz da Incoway):

StartLine=2
SkipError=True
Trace=On
Delimiter=|
FileName=*.txt
#
# 02 - Ancart - Custos SIP
# Esse driver é uma derivação do driver 02 - Ancart - Custos especializado para o funcionamento dentro de um processo de integração remota de dados #entre a Operadora e o IW-Health. A principal diferença está no escopo do conteúdo dos arquivos de dados de contas médicas : nesse modelo em um #arquivo teremos dados de contas de diversos períodos de referência de contas médicas da Operadora. A chave para remoção e recarregamento dos #dados de contas nesse driver se fundamenta na coluna IDPROTOCOL da GLBMONITORINGCOST. A cada nova carga de dados, o IW fará a remoção de #todas as contas médicas #pregressas cujo IDPROTOCOL seja citado em registros presentes no arquivo. É condição obrigatório para o funcionamento #integro desse driver que as contas médicas (registros de mesmo IDPROTOCOL , exemplo : mesmo codigo de Protocolo de Entrega de Guia (PEG) na #Operadora sejam exportadas na sua totalidade para o arquivo. Tipicamente : O SIP irá executar um #comando de extração de contas na base de dados #da Operadora, que deverá retornar todos os registros ligados a contas médicas (IDPROTOCOL) que tenham sofrido qualquer tipo de alteração com #data_hora posterior à última transferência bem sucedida (DUTBS). Nesse driver "não" executamos o comando sqlbefore responsável pela limpeza dos #dados de contas médicas de um "período de referência" . Ao invés disso os dados do arquivo são carregados para a tabela GLBMONITORINGCOST e #posteriormente é executado um comando sqlafter que faz a remoção dos itens de contas médicas que tenham IDPROTOCOL igual a um dos #IDPROTOCOL das novas contas que foram lidas. Para identificar os IDTPROTOCOL das contas novas (lidas do #arquivo no processo de carga) utiliza-se a #variável de ambiente #maxid. Essa variável contém o valor do maior ID presente na tabela destino da carga (GLBMONITORINGCOST) exatamente antes #do início do processamento da nova carga.
#
# realiza ligação entre glbmonitoringcost e glbinsuranceenroll (chaves = careplanregister e identerprise)
#-------------------------------------------------------------------------------------------------------------
# sintaxe oracle/sqlserver
# (***) substitua a expressão <identerprise_operadora> pelo ID da Operadora relacionada a esse driver
# SqlAfter=update glbmonitoringcost b set idinsuranceenroll = (select id from glbinsuranceenroll a where a.careplanregister = glbmonitoringcost.careplanregister and a.identerprise = <identerprise_operadora> ) where idinsuranceenroll is null and identerprise = <identerprise_operadora> and discarded = 0
# Exemplo : Para uma operadora com id (na tabela glbenterprise) igual a 262 a expresssão ficaria:
# SqlAfter=update glbmonitoringcost b set idinsuranceenroll = (select id from glbinsuranceenroll a where a.careplanregister = glbmonitoringcost.careplanregister and a.identerprise = 262 ) where idinsuranceenroll is null and identerprise = 262 and discarded = 0
SqlAfter=update glbmonitoringcost set idinsuranceenroll = (select id from glbinsuranceenroll a where a.careplanregister = glbmonitoringcost.careplanregister and a.identerprise = <identerprise_operadora> ) where idinsuranceenroll is null and identerprise = <identerprise_operadora> and discarded = 0
#
#
# invalida (valora coluna DISCARDED = 1 ) os registros que ficaram sem relacionamento com a tabela glbinsuranceenroll (ficaram sem associação com segurado)
#-------------------------------------------------------------------------------------------------------------------------------------
# (***) substitua a expressão <identerprise_operadora> pelo ID da Operadora relacionada a esse driver
# SqlAfter=update glbmonitoringcost set discarded = 1 where identerprise = <identerprise_operadora> and idinsuranceenroll is null and discarded = 0
# Exemplo: Para uma operadora com id (na tabela glbenterprise) igual a 262a expresssão ficaria:
# SqlAfter=update glbmonitoringcost set discarded = 1 where identerprise = 262 and idinsuranceenroll is null and discarded = 0
SqlAfter=update glbmonitoringcost set discarded = 1 where identerprise = <identerprise_operadora> and idinsuranceenroll is null and discarded = 0
#
#
# Realiza comando sqlafter de remoção das contas pregressas que foram lidas novamente do arquivo (contas antigas que foram alteradas na Operadora)
#------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SqlAfter=delete from GLBMONITORINGCOST where idprocol in (select distinct idprotocol form GLBMONITORINGCOST where id > #maxid ) and id <= #maxid
#
#
# LAYOUT DO ARQUIVO
# copie e cole aqui a primeira linha com os nomes das colunas e segunda linha já com valores exemplo do arquivo para normalizar a documentação do driver
# Ex.: COMPETENCIA|CARTEIRA|RECEBEDOR|DATAEVE|INTHOSP|INTUTI|REGATEND|VALOREVENT|CIDAUT|CIDPGG|ESTRUTURA|DESCRICAO|ESPECIALIDADE|CODIGO_TABELA|QUANTEVENT|TIPO_EVENTO|CLASSIFICACÃO|GRAU|OBJETIVO|DATAINICIO|DATAFIM
# Ex.: 01 /2007|070104216700|CAAJARA COM IND IMP EXP REPRESENTAÇÕES LTDA|15/10/2006|31|0|Internação Hospitalar|86549,78|0|0|92.00.0002|MEDICAMENTOS NA UNIDADE| |01|1|Medicamento na Unidade|Demais Despesas Assistenciais|92051|Reparador|15/10/2006|15/11/2006
# leitura do período de referência no formato 'mm/aaaa' e grava os valores nas colunas referencedate (formato texto) e datereference (formato data)
#-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
$E(1)
Expression(REFERENCEDATE)=$E(1)
Expression(DATEREFERENCE)=01/$E(1)
#
#
# Valoração da coluna IDENTERPRISE com o ID da Operadora relacionada a esse driver
# -----------------------------------------------------------------------------------------------------------
# (***) Substitua a expressão <identerprise_operadora> pelo id correto da operadora relacionada a esse driver
# Exemplo : Para um operadora com id (na tabela glbenterprise) igual a 262 a expresssão ficaria:
# |IDENTERPRISE|<ColumnSize>|262|<Format>|<ListValue>
|IDENTERPRISE|<ColumnSize>|268|<Format>|<ListValue>
#
# Valoração da coluna DISCARDED com valor default = 0
# ---------------------------------------------------------------------
|DISCARDED|<ColumnSize>|0|<Format>|<ListValue>
#
#
Nº matrícula na operadora|CAREPLANREGISTER|40|<DefaultValue>|<Format>|<ListValue>

Nome do prestador|ENTERPRISENAME|80|SEM NOME|<Format>|<ListValue>

Codigo do prestador|ENTERPRISENAMEID|10|0|<Format>|<ListValue>

Data do atendimento|EVENTDATE|<ColumnSize>|<DefaultValue>|<Format>|<ListValue>

Tipo de Evento|EVENTTYPE|<ColumnSize>|<DefaultValue>|<Format>|Ambulatorial-0;Pronto-Socorro-1;Internação Hospitalar-3;Day Clinic (de 06 à 12 hrs) - Internação-9;UTI - Unidade de Terapia Intensiva-10;Domiciliar- Monitoramento-13;Remoção - Terrestre-18;Home Care-15;Domiciliar - Atendimento-14;Amparador-17;Médico de Família-17

Classificação do procedimento (operadora1)|CLIENTEVENTTYPE|<ColumnSize>|0|<Format>|Exames Grupo II-1;Terapias Grupo II-2;Terapias Grupo I-3;Internações-4;Atendimentos Ambulatoriais-5;NULL-6;Consultas Odontológicas-7;Consultas Médicas-8;Exames Grupo I-9;Remoção-10;Demais Despesas Assistenciais-8

Tipo_evento_classes|||<DefaultValue>|<Format>|<ListValue>

Configurando os Processos do IW-Sip no IW-Health

(a) Cadastramento dos Processos de integração de contas médicas:

Cadastramento do Processo :

Nesse caso exemplo estaremos configurando dois processos a saber: Nesse processo estaremos automatizando a integração das seguintes estruturas de informações interrelacionadas:

a.1 – Cadastro de Segurados da Operadora (relaciona-se com o Driver de leitura de arquivo denominado “ “)
a.2 – Cadastros básicos (exemplo: códigos de diárias , códigos de motivos de saída de planos etc : Relaciona-se com o driver de leitura de arquivos denominado “).
a.3 – Contas médicas propriamente ditas (relaciona-se com o driver de leitura de arquivos denominado “ “).

Note que nesse processo temos três grupos de informações relacionados a diferentes driver´s de importação de dados no IW-Health. Nesses casos deve-se eleger uma categoria de informação (correspondente a um dos driver´s) para ser gatilhada automaticamente pelo SIP ao término da execução da transmissão dos dados desse processo. No nosso exemplo optamos pela estrutura de informações “a.2” relacionada ao driver “01-AnCart-Cadastro”. Nota: Nesses caso o driver “01-AnCart-Cadastro” deverá ser configurado para gatilhar automaticamente um próximo driver no final de seu processamento (por exemplo : 02-AnCart-ConvCode”), e esse outro driver por sua vez deverá ser modificado de modo a gatilhar automaticamente o terceiro driver (no nosso semplo “03-AnCart-Custos”). Ou seja, os driver´s de leitura de cada estrutura de informação serão ser configurados para seus gatilhamentos em cascata de modo que todos os driver´s sejam gatilhados de forma automatizada.

A figura a seguir ilustra o cadastramento desse processo no IW-health: (menu-Administrador – (19) SIP – Configuração – (1) SIP – Processos):

Nota: Para configurar o gatilhamento de um driver automaticamente ao término do processamento de um outro driver basta acrescentar no arquivo de configuração do driver´s que execta primeiro (driver gatilhador) uma linha com seguinte sintaxe:

ImportTable=<n>

Onde n : valor do ID do driver que será gatilhado automaticamento no término do processamento do driver gatilhante.

Cadastramento dos Comandos Sql :

Nesse exemplo teremos três comandos sql para obtenção respectivamente das estruturas de informação a.1, a.2 e a.3.

a.1 : A figura a seguir ilustra o cadastramento de comandos sql relacionados ao processo de importação do cadastro de associados da Operadora: Acesse : menu – administrador – (19) SIP – Configuração – (2) SIP – Comandos.

(b) Processo de importação dos dados de senhas e autorizações

A importação automatizada de senhas e autorizações constitui um instrumento importante de apoio à implantação de sistemas de monitoramento e prevenção. Através desse canal de integração estabelecemos um fluxo com frequência ajustável (tipicamente diária mas podendo chegar a até de hora em hora) onde as informações referentes às autorizações e senhas de internação ou de execução de procedimentos médicos / exames clínicos serão transferidas para o IW-Health.

O IW-Health oferece recursos de notificação automatizado dos gestores , sejam profissionais que atuam no contexto de auditoria (central de regulação) ou profissionais que atuam nos processos de monitoramento ou medicina preventiva.

Nota Técnica : Nativamente o IW vem previamente configurado com um driver de leitura dos registros de senhas e autorizações denominado “005-AnCart – Senh_Autor_SIP”. Esse driver promove a importação dos registros de senhas e autorizações para a tabela GLBINSURAUTHORIZ.

A figura a seguir ilustra o cadastramento do processo de importação dos dados de senhas e autorizações:

Nesse processo estaremos integrando uma única categoria de informação. Ou seja, teremos um único comando sql relacionado a ele e haverá o gatilhamento de um único driver de importação de dados no IW-Health (sem gatilhamento em cascata de outro driver).