Logo do e-SUS

Sistema e-SUS Atenção Básica

Manual de Exportação

Este documento apresenta o modelo de integração do Sistema e-SUS AB com outros sistemas informatizados que estruturam o processo de trabalho das equipes de atenção básica em municípios com sistemas próprios. Como  eixo central tratamos das bibliotecas de comunicação Apache Thrift, das APIs do e-SUS AB e ainda do uso de XML como alternativa para efetivar a comunicação entre os sistemas.

API Thrift e-SUS AB Versão 2.0

XML Schema e-SUS AB Versão 2.0

Capítulo 1. Introdução à Estratégia e-SUS AB

1.1 Sistema com Coleta de Dados Simplificada

1.1.1 Cadastro da Atenção Básica

1.1.2 Fichas de Atendimento

1.1.3 Sistema de software e-SUS AB com CDS

1.2 Sistema com Prontuário Eletrônico do Cidadão

1.2.1 Requisitos de um Prontuário Eletrônico para a AB

1.2.2 Sistema de Software e-SUS AB com PEC

1.3 SISAB

1.3.1 Fluxo de Transmissão de Dados do SISAB

Capítulo 2. Modelo de Troca de Informação do e-SUS AB

2.1 Troca de informação entre o sistema com CDS e com PEC

2.2 Coleta e envio das informações para o SISAB

2.3 Compartilhamento hierárquico dos dados do Sistema e-SUS AB

Capítulo 3. Modelo de Integração

3.1 Apache Thrift

3.1.1 Arquitetura do Thrift

3.2 APIs Thrift do Sistema e-SUS AB

3.2.1 Gerando um Arquivo para o Sistema e-SUS AB

3.3 Suporte XML do Sistema e-SUS AB

Capítulo 4. API Cidadão

4.1 Estrutura da API Cidadão

4.2 Exemplo de uso da API Thrift Cidadão

Capítulo 5. API  RAS

5.1 Estrutura da API RAS

5.2 Exemplo de uso da API Thrift RAS

Conclusão

Referências Bibliográficas

Capítulo 1. Introdução à Estratégia e-SUS AB

A Estratégia e-SUS Atenção Básica é apoiada, essencialmente, por dois sistemas:  i)  Sistema de Informação em Saúde para a Atenção Básica (SISAB) , o sistema de informação nacional ;  e ii) Sistema  e-SUS Atenção Básica , composto por sistemas de software que instrumentalizam o processo de trabalho nas unidades básicas de saúde (UBS). Como estratégia, é fundamental que o e-SUS AB garanta um processo amplo e padronizado de troca de informações entre sistemas em vários níveis de atenção e no próprio nível da A tenção sica.

Da mesma forma , para apoiar a  efetivação do cuidado continuado , a Estratégia e-SUS AB precisa de uma estrutura que atue sobre um registro longitudinal dos eventos de saúde de um cidadão independentemente do sistema de software que as equipes de saúde utilizem para fazer a gestão local do serviço de saúde.  P ortanto, faz-se necessário uma base de Registro Eletrônico de Saúde (RES) que dialogue minimamente com as necessidades das Redes de Atenção à Saúde organizadas de forma intermunicipal e interestadual.

       & nbsp; O Departamento de Atenção Básica (DAB) da Secretaria de Atenção à Saúde (SAS) do Ministério da Saúde (MS), com o objetivo de incentivar o uso de tecnologias de informação e comunicação em saúde na Atenção Básica, vem apoiando o desenvolvimento de tecnologias que atendam às necessidades de gestão da Atenção Básica, em especial, nos processos de gestão do cuidado e gestão por resultados.

         Característica importante desse processo é a inversão do objetivo principal na construção das ferramentas e instrumentos que apoiam os processos de gestão. Esse projeto tem como foco as necessidades locais e da esfera municipal. Nessa perspectiva, entende-se que a melhoria e a qualificação do processo de trabalho das equipes de saúde da Atenção Básica integradas às Redes de Atenção à Saúde devem trazer resultados significativos e promissores na gestão estadual e federal da AB.

Nesse contexto, a Estratégia e-SUS Atenção Básica busca, por meio dos Sistemas e-SUS AB, implementar essas tecnologias para tornar mais fácil o processo de trabalho das equipes de saúde e de gestão, reduzindo o tempo gasto com a burocracia do uso e a alimentação dos sistemas de informação em saúde que fazem interface com a AB. A estratégia busca, ainda, garantir que o desenvolvimento das soluções avancem na adoção de padrões internacionais da área de informática em saúde, ampliando, com isso, a interoperabilidade entre os sistemas gerencias da saúde e de outras áreas no município.

         O Sistema e-SUS AB é composto pelo Sistema com Coleta Simplificada de Dados (CDS) e o Sistema com Prontuário Eletrônico do Cidadão (PEC), atendendo a cenários de informatização distintos, como já foi apresentado em outros documentos.

Nas próximas seções, será apresentado, resumidamente, como funciona cada software do Sistema e-SUS AB, além de outros detalhes que podem ajudar os usuários dos sistemas na compreensão do processo de integração dos dados.

1.1 Sistema com Coleta de Dados Simplificada

         O Sistema com Coleta de Dados Simplificada (CDS) foi formulado para atender às equipes de Atenção Básica lotadas em UBS que ainda não possuem condições de infraestrutura tecnológica de informática para a utilização do sistema e-SUS AB com PEC (ver seção 2.3). O CDS tem por característica ser um sistema de transição, para viabilizar a implantação de um Sistema com PEC no tempo apropriado.

         Na versão atual (versão 2.0), o Sistema com CDS utiliza dez fichas  para o registro das informações:

  1. Cadastro Domiciliar
  2. Cadastro Individual
  3. Ficha de Atendimento Individual
  4. Ficha de Atendimento Odontológico Individual
  5. Ficha de Atividade Coletiva
  6. Ficha de Procedimentos
  7. Ficha de Visita Domiciliar
  8. Marcadores de Consumo Alimentar
  9. Ficha de Avaliação de Elegibilidade
  10. Ficha de Atendimento Domiciliar

Essas fichas deverão ser digitadas no sistema de software e-SUS AB com CDS. Como um sistema transitório, essa ferramenta não tem a pretensão de ser um sistema exaustivo em relação às necessidades de informação das equipes de AB. No entanto, o CDS organiza um conjunto essencial de informações que estruturam o cadastro da AB e os registros de atendimentos realizados pelas equipes.

1.1.1 Cadastro da Atenção Básica

O Cadastro Nacional de Saúde (CNS), ou simplesmente CadSUS , é um sistema de informação de base nacional que permite a identificação dos usuários  das ações e serviços de saúde através de um número, único para cada cidadão, válido em todo o território nacional. Coordenado pelo Ministério da Saúde, esse sistema permite a vinculação do usuário à atenção realizada pelas ações e serviços de saúde, ao profissional e ao estabelecimento de saúde responsável pelo atendimento. O CNS é também o instrumento de informatização necessário para a organização da Rede de Atenção à Saúde e de gestão do SUS, por meio do acesso a uma base nacional de dados de saúde do cidadão. A Portaria nº 940/GM/MS, de 28 de abril de 2011, regulamenta o Sistema Cartão Nacional de Saúde (Sistema Cartão).

O  Cadastro da Atenção Básica (AB)  é uma extensão do  CadSUS   no que se refere aos dados que apoiam as equipes de AB no mapeamento das características de saúde, sociais e econômicas da população adscrita ao território sob sua responsabilidade. Esse cadastro está organizado em duas dimensões: domiciliar e individual.

  1. O  cadastro domiciliar  identifica as características sociossanit& aacute;rias dos domicílios no território das equipes de AB. Es s e cadastro busca identificar, também , situações de populações que habitam  em locais que não podem ser considerados domicílio -  por exemplo, situação de rua (IBGE, 2009) - e que,  no entanto, devem ser monitorad a s pela equipe de s aúde. No cadastro domiciliar, o vínculo do cidadão ao seu domicílio é feito por meio do CadSUS do  responsável familiar . Esse  cadastro pode ser vinculado a mais de um responsável familiar e ,  portanto, a mais de um  núcleo familiar .
  2. O  cadastro individual  identifica as características sociodemográficas, problemas e condições de saúde dos usuários no território das equipes de AB. Esse cadastro é composto por duas partes: informações de identificação/sociodemográficas; e condições de saúde autorreferidas pelo usuário.

1.1.2 Fichas de Atendimento

         No sistema com coleta simplificada, todas as fichas de atendimento passam a ter um cabeçalho identificando a unidade, a equipe e o profissional que realizou o atendimento. Além disso, é possível registrar se foi um atendimento compartilhado com outro profissional. Da mesma forma, em todas as fichas, é possível identificar os usuários que receberam o atendimento pelo número do CadSUS e, ainda, o local do atendimento.

         A  ficha de atendimento individual  contém o resumo do atendimento de nível superior. É nessa ficha que os profissionais de nível superior devem informar o que ocorreu no atendimento, e algumas informações fundamentais devem ser inseridas, tais como: tipo de atendimento; problema/condição avaliada; e conduta do atendimento. Para complementar essa ficha, tem-se a  ficha de procedimentos , na qual é possível registrar os procedimentos e pequenas cirurgias realizadas no atendimento. A ficha de procedimentos é utilizada também para registrar procedimentos específicos realizados por técnicos de nível médio da unidade

        Excepcionalmente, para os profissionais da Saúde Bucal, pode ser usada, ainda, a  ficha de atendimento odontológico individual , na qual se registram, de forma similar: o tipo de atendimento; o tipo da consulta odontológica; registros de vigilância em saúde bucal; e a conduta do atendimento – por exemplo, se foi agendada nova consulta na AB ou se o cidadão foi encaminhado para outro serviço.

     & nbsp;  A  ficha de visita domiciliar  busca, por meio de sua estrutura, coletar as informações sobre a realização de visitas domiciliares do agente comunitário de saúde (ACS). Assim como as outras fichas, esta ficha passa a ter o registro individualizado. Destaca-se que essa ficha passa a ser exclusiva para as visitas realizadas pelos ACS. Por sua vez, para o registro de atendimento no domicílio realizado por profissional de nível superior, é possível utilizar a ficha de atendimento individual, e informar o local de atendimento como sendo “Domicílio”.

Uma novidade para o registro de ações da AB é a  ficha de atividade coletiva , usada para registrar ações administrativas, reuniões de equipe, ações de saúde, atividades coletivas de promoção de saúde ou, ainda, atendimento em grupo.

Com exceção da ficha de atividade coletiva, as outras fichas passam a registrar vários atendimentos na mesma ficha. Com os registros organizados na vertical (em colunas), as fichas proporcionam um registro bastante objetivo. Entretanto, a ficha não tem intenção de ser exaustiva nas opções de preenchimento rápido, que em geral são acompanhados pelos campos “Outros”, em que é possível, quando necessário, registrar outras ações por meio de codificações e classificações utilizadas pelos sistemas de informações vigentes.

A ficha de Marcadores de Consumo alimentar  permite a identificação de marcadores positivos ou negativos da alimentação e de maneira mais dinâmica, a composição de indicadores. Para auxiliar a sua utilização e a orientação sobre práticas alimentares saudáveis, recomenda-se o uso do documento “Orientações para Avaliação de Marcadores de Consumo Alimentar na Atenção Básica”, disponível no Portal do DAB por meio do link: http://dab.saude.gov.br/portaldab/biblioteca.php?conteudo=publicacoes/marcadores_consumo_alimentar_atencao_basica

1.1.3 Sistema de s oftware e-SUS AB com CDS

De fácil instalação e multiplataforma, o Sistema com CDS estrutura a digitação do cadastro e das fichas de atendimento, podendo ser utilizado também em conjunto com o Sistema e-SUS AB com PEC por meio do módulo CDS.

O sistema e-SUS AB com CDS é exclusivo para digitação e não tem funções gerenciais. Esse sistema possui um banco de dados embarcado, portanto, não é necessário fazer uma instalação de um SGBD em separado. Por ter funcionalidades limitadas às necessidades dessa aplicação, não se recomenda o armazenamento de um volume grande de informações no Sistema com CDS.

CDS-Inicial-v2.0.png Figura 1.1: Tela Inicial do Sistema e-SUS AB com CDS

1.2 Sistema com Prontuário Eletrônico do Cidadão

O sistema com Prontuário Eletrônico do Cidadão (PEC) foi formulado para atender às equipes de Atenção Básica lotadas em unidades básicas de saúde (UBS) parcialmente ou totalmente informatizadas. Um Sistema com Prontuário Eletrônico é um sistema que amplia a integração e a gestão do cuidado pelos profissionais, e são indispensáveis do ponto de vista de gerar valor de uso aos sistemas de informação em saúde.

No entanto, um prontuário eletrônico pode ser implementado de diversas formas, considerando diferentes processos de trabalho. Nesse momento, cabe apontar algumas diretrizes usadas pelo sistema visando garantir a atenção integral à saúde do paciente tal como preconiza a Política Nacional de Atenção Básica (PNAB).

1.2.1 Requisitos de um Prontuário Eletrônico para a AB

Um sistema com prontuário eletrônico para a AB deve prover todas as informações e funções que deem suporte às atividades essenciais inscritas na prática de saúde, na prática da análise da condição de saúde da população e por fim, nas ações de gestão da AB. Isso requer lidar com o planejamento e a programação das ações, o controle de agendas, procedimentos, estoques de materiais, equipamentos, o monitoramento e a avaliação de processos e resultados, entre outros aspectos. Isto é, o sistema deve ser capaz de controlar os diferentes itens que representam as condições de organização e funcionamento dos serviços de saúde. Nesse sentido, a seguir, apresentam-se os processos essenciais para o desempenho das funções da AB destacados por requererem inovações e desenvolvimento para suporte por sistema de software: territorialização, acolhimento, agendamento, gestão do cuidado e gestão do acesso e da qualidade.

1.2.2 Sistema de Software e-SUS AB com PEC

O Sistema com PEC é um sistema complexo, pois busca estruturar o registro do conjunto de informações que apoiam a organização e troca de informação entre os profissionais das equipes de AB. É importante destacar que este é um sistema com prontuário eletrônico, ou seja, não se limita a ser apenas o registro no prontuário eletrônico e amplia o conjunto de ferramentas e funcionalidades para atender a todas as diretrizes de um sistema de informação para a AB.

         Na versão atual do sistema, como se pode ver na imagem de sua tela inicial, estão disponíveis os seguintes módulos:

Figura 1.2: Tela Inicial do Sistema e-SUS AB com PEC

1.3 SISAB

        A P ortaria nº 1.412, de 10 de julho de 2013, instituiu o  Sistema de Informação em Saúde para a Atenção Básica  (SISAB) como o novo sistema de informação nacional da Atenção Básica, em substituição ao atual Sistema de Informação da Atenção Básica (SIAB).

        Destaca-se, inicialmente, que tanto o Sistema com CDS quanto o Sistema com PEC fornecerão as mesmas informações ao SISAB. Para quem utiliza o Sistema e-SUS AB com PEC, o próprio sistema se encarregará de organizar as informações a serem enviadas ao SISAB. Para os municípios que utilizam outros sistemas com prontuário eletrônico, também será possível gerar as informações de acordo com o modelo de coleta simplificada (similar ao Sistema com CDS) e então enviar os dados. Todos os dados do Sistema e-SUS AB são organizados no Módulo Centralizador para envio ao SISAB. No próximo capítulo, será explicado com mais detalhes como esse processamento ocorre.

         Para entender melhor como funciona o fluxo de transmissão dos dados para o SISAB, na seção seguinte, amplia-se a discussão, contemplando as regras gerais de envio dos dados.

1.3.1 Fluxo de Transmissão de Dados do SISAB

        O fluxo de transmissão dos dados para o novo sistema de informação se dá de forma similar ao fluxo de envio dos dados do antigo SIAB pelo município. Este fluxo é definido em portaria anual, que determina o prazo máximo de envio das informações do sistema organizadas por competência mensal, porém em fluxo contínuo.

Figura 1.3: Esquema do fluxo de transmissão do SISAB

        Conforme ilustrado na Figura 1.3, como regra geral, as competências fazem um recorte da produção de informação dentro de um mês de competência que corresponde exatamente aos dias do mês em questão. Ao encerrar a competência, o município terá do primeiro ao vigésimo dia dos mês subsequente como prazo máximo para enviar os dados para a base nacional e um prazo de até 3 mês para enviar correções da base.


Capítulo 2. Modelo de Troca de Informação do e-SUS AB

        Os processos de troca de informações entre sistema, ou mesmo de compartilhamento dos dados, são em muitas ocasiões desafiadores. Como vimos, a Estratégia e-SUS AB busca por meio de sistemas de softwares integrados avançar na solução das necessidades de troca de informação entre sistemas , sobretudo ajudando os municípios em suas atividades do cotidiano.

        Para melhor avaliar a solução apresentada no próximo capítulo, é importante ter clareza de quais situações  estão sendo tratadas  e como  estas  se relacionam com o modelo de informações. As situações descritas neste documento,  já contempladas na versão 2.0, são :

  1. Troca de informação entre o sistema com CDS e com PEC;
  2. Coleta e envio das informações para o SISAB; e
  3. Compartilhamento hierárquico dos dados do Sistema e-SUS AB .

Figura 2 .1 - Imagem -objetivo  da Troca de Informações n o Sistema e-SUS AB

2 .1 Troca de informação entre o sistema com CDS e com PEC

         A primeira situação descrita aqui versa sobre a necessidade de  integração entre os dados do Sistemas com CDS, registrados por fichas, e do Sistema com PEC, registrados direto no sistema pelos profissionais de saúde, por meio de ferramentas informazadas . Essa integração é estruturada para oferecer uma evolução gradual da capacidade de registro de informação, ao mesmo tempo que deve atender ao sistema de informação nacional, o SISAB.

         O desenvolvimento do Sistema com CDS teve como origem a necessidade de simplificar o registro do atendimento individualizado por fichas, dado que uma boa parcela das UBS ainda não está informatizada. A simplificação do registro passou por uma análise bastante criteriosa, a fim de evitar que o processo de registro seja mais caro (em relação ao tempo) que o próprio processo de trabalho no atendimento ao cidadão. Outro critério foi em relação à necessidade de monitoramento das ações da AB, orientado por uma pauta essencial das ações da AB e de governo. Essa análise resultou na necessidade da criação de blocos consolidados para registro de ações muito frequentes – situações em que o registro individualizado seria dificultoso, porém importante para o monitoramento das ações na AB.

         O Sistema com PEC avança em outro sentido, na perspectiva de eliminar o registro em fichas e formulários de papel. Portanto, busca reestruturar o trabalho dos profissionais da UBS por meio de ferramentas informatizadas que estejam adequadas ao processo de trabalho das equipes de AB como um todo. Como o sistema estrutura as ferramentas e não o registro, os mesmos blocos que no Sistema com CDS são consolidados, no Sistema com PEC, são registrados individualmente por meio dessas ferramentas. Ao mesmo tempo, o Sistema com PEC demanda um conjunto de informações que ajudam a estruturar o sistema de saúde municipal, por exemplo, definindo o tempo de consulta ou organizando os usuários que fazem acesso ao sistema.

         Nesse contexto, é preciso entender quais blocos de informações são compatíveis e quais não são. A Figura 2.2 ilustra os blocos de informações dos sistemas destacando os grandes blocos e os documentos de troca de informação gerados a partir desses blocos. Como se observa na Figura 2.2, o Sistema e-SUS AB possui diferentes documentos de troca de dados para atender a características particulares de cada bloco do sistema, gerando os seguintes documentos:

Figura 2 .2: Blocos de Informações do Sistema e-SUS AB

         Como se pode observar, os documentos RAC, RAS e parte do CONS têm origem no mesmo bloco de informações – o bloco de eventos de saúde individualizados –, sendo que a outra parte do CONS vem de eventos de saúde sem registros individualizados. Na Figura 2.3, a seguir, apresenta-se a relação entre os três documentos e sua origem no Sistema e-SUS AB, deixando mais clara a relação de sobreposição semântica dos documentos RAC, RAS e CONS. É importante, no entanto, perceber que o documento CONS pode ser gerado a partir dos documentos RAC e RAS por meio da agregações dos dados desses documentos, ou mesmo usando as estrutura individualizadas, porém sem identificação do cidadão. Obviamente, o inverso não é possível.

figura07.png

Figura 2 .3: Origem dos Documentos de Troca de Dados do Sistema e-SUS AB

Vale ressaltar que, na versão atual  do sistema, apenas os Modelos CAD (parcialmente) , RAS e CONS  de documentos de troca de informações estão disponíveis . Os outros modelos estão em desenvolvimento   e devem ser disponibilizados em versões futuras.

2 .2 Coleta e envio das informações para o SISAB

         A segunda situação de troca de informações versa sobre a coleta e envio dos dados ao SISAB, o sistema nacional. O SISAB tem o mesmo conjunto de informações do Sistema com CDS, dessa forma, para garantir o envio dos dados, o sistema de origem deve ser capaz de gerar um conjunto de dados compatível com esse sistema.

         Na estrutura preconizada pelo Sistema e-SUS AB, compete ao Módulo Centralizador organizar as informações a serem enviadas ao SISAB. Assim, é esse módulo que irá processar os dados enviados ao Sistema e-SUS AB, independentemente da fonte de informação. Ou seja, as informações podem ser provenientes do Sistema e-SUS AB com CDS ou com PEC, ou, ainda, de qualquer outro Sistema com Prontuário que atenda aos requisitos mínimos dos sistemas de prontuário para a AB e seja compatível com o modelo de informação clínica e demográfica da AB. Logo, não é necessário que os sistemas de origem gerem os documentos de troca de dados de acordo com o Sistema com CDS, bastando garantir um dos modelos a seguir:

2 .3 Compartilhamento hierárquico dos dados do Sistema e-SUS AB

         A terceira situação faz referência à necessidade de compartilhar os dados do Sistema e-SUS AB com ele mesmo (em rede). Considerando os diferentes cenários de implantação, é possível que, na grande maioria dos municípios, a base seja descentralizada, sendo possível ter dados em UBS  ou distritos   sanitários  separados do ambiente central. Essa descentralização demanda uma estrutura de transmissão do sistema entre a base local e a central.

        Esse processo de transmissão , dentro de uma rede de sistema distribuídos, com sistemas desconectados, eventualmente conectados, eventualmente desconectados ou conectados a essa rede, deve ser o mesmo, alterando apenas a forma de envio dos dados: i)  por arquivo;  ou ii)  por internet . Vale lembrar que toda forma de transmissão de dados se dá usando o modelo CAD + RAS , ou seja, nesse momento, mesmo que o município esteja usando o Sistema com PEC, os dados completos permanecerão apenas na base local.

Independentemente do cenário, o parâmetro máximo de tempo para transmissão das bases deve respeitar o fluxo de envio de informações ao SISAB , ou seja, na pior das hipóteses, um período máximo de um mês de desatualização das bases, o que permite antecipar problemas e gerenciar melhor os conflitos.

FluxoDados_PEC_Centralizador.png

Figura 2 .6: Rede distribuída de instalações do sistema

        A Figura 2 .6 ilustra diferentes formas de usar o Sistema e-SUS AB em rede, considerando instalações de Sistemas com PEC para atender a uma UBS, e Sistemas com Centralizador para organizar os dados de mais de uma UBS. A ilustração mostra, em um primeiro caso duas UBS (A e B) transmitindo suas bases para uma instalação centralizadora em um distrito sanitário. Obviamente, para que esses dados cheguem ao Centralizador Municipal, é necessário que a instalação do distrito sanitário AB esteja transmitindo dados para ele. Outro caso na rede é o de uma UBS (C) transmitindo sua base diretamente com o Centralizador Municipal. E, por último, tem-se uma UBS (D) que não possui uma base local e usa o Sistema com PEC conectada diretamente no Centralizador Municipal.

        Es s e pequeno cenário ilustrado na Figura 2.6   permite visualizar as cópias dos dados distribuídos na rede de sistema. As UBS A e B possuem, além da sua base local, mais duas cópias da informação de seus territórios, uma no centralizador do distrito sanitário e a outra no Centralizador Municipal. Por sua vez, a UBS C, tem apenas uma cópia no Centralizador Municipal, enquanto a UBS D não tem cópia da informação, ficando dependente apenas da instalação do Centralizador Municipal.

        Como visto  anteriormente, compete aos municípios a coordenação da AB, logo,  o nível mais alto de centralização  dos dados do Sistema e-SUS AB  é o nível municipal . Em alguns casos, e principalmente pela dificuldade de alguns municípios de manter um servidor centralizador do Sistema e-SUS AB, os Estados , Regionais de Saúde ou Municípios associados  podem oferece r  servidores para armazenar fisicamente os dados desses municípios.

Centralizador_MultiMunicipal.png

Figura 2 .7: Municípios usando Base Multi-Municipal

        

Essas estruturas, fora do município, são estruturas de acesso restrito ao gestor municipal, e são chamadas de Sistema e-SUS AB Multi-Municipal, ou seja, não é uma instalação estadual ou regional, é uma instalação municipal apenas otimizada para melhor aproveitar os recursos computacionais do servidor que dá suporte ao sistema de saúde municipal. Na Figura 2 .7 ilustramos a relação entre os sistemas e suas bases, organizado de tal forma que seja possível que todos os municípios acessam a sua instalação centralizadora, cabendo aos próprios municípios estruturarem suas redes dentro do seu município. Lembrando que cabe neste tipo de estrutura, inclusive, o acesso direto ao Sistema e-SUS AB pelos profissionais de saúde nas UBS (sem servidor local).


Capítulo 3. Modelo de Integração

O Sistema e-SUS AB está usando o framework de comunicação da Apache Thrift para implementar os recursos de importação e exportação dos dados para o sistema. Este capítulo traz mais explica& ccedil;ões sobre esse framework e alguns conceitos que devem ser compreendidos para se fazer um processo mais rápido de exportação dos dados a partir dos sistemas próprios.

Figura 3 .1 – Modelo de Integração com Sistema Próprio

3 .1 Apache Thrift

                        O Apache Thrift é um  framework  RPC (Remot e  Procedure Call), ou seja, é um conjunto de bibliotecas de sistema que auxiliam desenvolvedores a implementar chamadas de procedimentos remotos, porém oferecendo uma estrutura para utilização de múltiplas linguagens de programação entre clientes e servidores.

                 O termo em inglês thrift  significa “ brechó ”. Remetendo, assim, à noção de troca de objetos, o Apache Thrift oferece um ambiente de troca de serviços entre aplicações por meio de uma estrutura para desenvolvimento de serviços escaláveis entre linguagens. Dessa forma, oferece não apenas suporte à geração de código para várias linguagens mas também uma pilha de software, simplificando o desenvolvimento de serviços relacionados à rede de computadores.

                Antes de tornar-se um projeto de software livre do Apache, Thrift era uma biblioteca usada internamente no Facebook criada pelos seus desenvolvedores justamente pela necessidade de oferecer serviços em diferentes linguagens. Atualmente o Apache Thrift é usado por grandes desenvolvedores de software como Twitter e Linkedin.

                Abaixo alguns dos benefícios de se usar o Apache Thrift :

3 .1.1 Arquitetura do Thrift

                Ao se avaliar os desafios da interação entre linguagens em um ambiente de rede, alguns componentes-chave foram destacados no Thrift:

                Estas características deram as diretrizes para a definição de uma boa arquitetura, como será descrito a seguir.

                O   Thrift  implementa uma pilha ( stack ) de software que simplifica o desenvolvimento de aplicativos de comunicação em várias linguagens. Conforme podemos ver na Figura 3 .1, na parte inferior da pilha está a interface física de entrada e saída dos dados, podendo ser um fluxo de rede ou ainda um arquivo do sistema. Essa interface influencia os níveis mais altos da pilha.

                As camadas de transporte e protocolo que definem como os dados são movidos e quais formatos eles assumem, usando um processador, que contém os fluxos de entrada e saída. TBinaryProtocol define um protocolo binário eficiente para comunicação que pode ser usado sobre transporte TFileTransport que gera um arquivo para ser enviado ou salvo no disco, por exemplo.

                No nível superior estão tipos de servidor que podem ser implementados com o auxílio de Thrift . Essa configuração pode incluir um servidor de encadeamento único para depuração (TSimpleServer), um servidor HTTP que pode fornecer URLs semelhantes ao REST (Representational State Transfer) usando THttpServer, ou um servidor de vários processos que bifurca um processo para cada solicitação recebida (TforkingServer). Portanto, o Thrift  é escrito não apenas para simplificar a comunicação entre várias abordagens (protocolos e transportes), mas também para simplificar o desenvolvimento de servidor usando vários estilos de servidor.

Figura 3 .1 – Arquitetura cliente/servidor Apache Thrift API (Font e: W ikipedia)

                Como visto nas diretrizes, Thrift  ainda da suporte a um sistema de tipo que permite comunicação entre linguagens. Esse sistema oferece suporte para tipos como byte, short, int double, string  e tipos mais avançados, como contêineres (listas, mapas) e estruturas. Esse sistema de tipos genérico é a base comum (serialização e desserialização) para comunicação de dados.

3 .2 APIs Thrift do Sistema e-SUS AB

        Como estamos tratando especificamente da integração de Sistemas Próprios com o Sistema e-SUS AB, muita da complexidade da implementação já foi absorvida pelo Sistema e-SUS AB, que implementa toda a parte de servidor definindo o formato dos dados e disponibilizando as APIs geradas pelo Thrift , em diferentes linguagens,  para que sejam usadas pelos desenvolvedores que pretendem exportar dados para o Sistema e-SUS AB.

        Foram gerados dois pacotes de APIs para integração com o Sistema e-SUS AB:

        A partir das APIs é possível gerar os arquivos exportados dos Sistemas Próprios para serem importados no Sistema e-SUS AB. A estrutura de cada API será detalhada mais a frente. Na próxima seção veremos, de forma genérica, como é gerado o arquivo para ser importado.

3 .2.1 Gerando um Arquivo para o Sistema e-SUS AB

Como vimos na Figura 3 .1, a implementação do Thrift  ocorre em camadas para facilitar o desenvolvimento considerando diferentes problemas da integração. A parte do Servidor é implementada pelo Sistema e-SUS AB, portanto cabe ao desenvolvedor apenas gerar os dados a partir de sua aplicação na condição de  cliente  da aplicação.

O Sistema e-SUS AB, por simplificação, nesse momento, oferece apenas uma forma de integração usando troca de arquivos . Assim, nesta seção, serão apresentados os passos para gerar esse arquivo, abstraindo-se as especificidades de alguma linguagem em particular.

Quadro 1 – Passo a passo para geração do arquivo para o Sistema e-SUS AB

Passo 1

Configurar a aplicação para usar Thrift

Para que seja possível usar as APIs geradas pelo Apache Thrift, é necessário instalar e configurar seu ambiente de desenvolvimento para usar as bibliotecas do Apache Thrift.

As linguagens que já estão com APIs disponíveis para o Sistema e-SUS AB s& atilde;o:

  • Java (requer Ant e Java 1.7);
  • Delphi (requer Delphi 2010 ou superior);
  • C# (requer Mono >= 1.2.6 or .NET framework >= 3.5);
  • PHP (requer PHP 5.0); e
  • Ruby (Ruby 1.8, bundler gem).

Mais informações sobre como usar as  libs  do  Thrift  estão disponíveis em: http://thrift.apache.org/lib/

Caso haja necessidade de alguma outra API suportada pelo  Thrift  para o Sistema e-SUS AB, deve-se contatar a equipe de desenvolvimento, por meio do endereço: nti.dab@saude.gov.br

Passo 2

Baixar a API do Sistema e-SUS AB a ser utilizada

O  download  da API gerada pelo Thrift para o Sistema e-SUS AB pode ser feito a partir do  site  do e-SUS AB, disponível em: http://dab.saude.gov.br/esus

Na área de download, selecionar a opção “Integração Sistemas Próprios” e, na sequência, clicar em “Thrift Cidadão” ou “Thrift RAS”, conforme for a necessidade.

Passo 3

Copiar o código da API para a aplicação

Após baixar o arquivo, descompactá-lo e copiar os arquivos correspondentes à linguagem usada por sua aplicação para dentro de seu código base.

Passo 4

Incluir a API e as bibliotecas na aplicação

Incluir a API do Sistema e-SUS AB correspondente à linguagem utilizada e às bibliotecas do  Thrift  no código base da aplicação para que seja possível chamar as funções dentro desta.

Para exemplos sobre como fazer esse procedimento, ver os exemplos para cada linguagem em: http://thrift.apache.org/tutorial/

Passo 5

Configurar a camada de transporte e protocolo

Após preparar a aplicação para usar o  Thrift , basta definir como e em que formato os dados serão enviados, ou seja, deve-se definir as camadas de transporte e protocolo, já implementadas pelo  Thrift .

O Sistema e-SUS AB utiliza:

  • TTransport: StreamTransport;
  • Java: TIOStreamTransport,
  • Delphi: TStreamTransportImpl,
  • C#: TStreamTransport,
  • PHP5: TMemoryBuffer,
  • Ruby: IOStreamTransport.
  • TProtocol: BinaryProtocol;
  • Java: TBinaryProtocol,
  • Delphi: TBinaryProtocolImpl,
  • C#: TBinaryProtocol,
  • PHP5: TBinaryProtocol,
  • Ruby: BinaryProtocol.

Para mais detalhes, ver os exemplos de funções de serialização disponíveis no manual:

Passo 6

Preencher os dados

Nesse momento, é possível criar as rotinas que irão preencher os dados conforme definido pelas APIs. Como já mencionado, as APIs geradas pelo  Thrift  definem as estruturas dos dados do e-SUS AB (DadoTransporteThrift ou CidadaoTransportThrift).

Nos capítulos a seguir, serão detalhadas as estruturas e a melhor forma de utilizar essas APIs para importar os dados ao Sistema e-SUS AB.

Passo 7

Empacotar os dados

O empacotamento dos dados a serem enviados ao Sistema e-SUS AB é feito por meio de um conjunto de arquivos compactados por uma biblioteca ZIP. Cada arquivo a ser compactado corresponde a uma “Ficha” serializada dos dados.

Dentro dos pacotes ZIP, cada arquivo ( entries ) deve ser nomeado com a extensão do dado empacotado, a saber:

  • Fichas CDS/RAS (DadoTransporteThrift): extensão “.esus”; e
  • Cadastro de Cidadão (CidadaoTransportThrift): extensão “.cidadao”.

Para mais detalhes ver o exemplo disponível no manual:

A serialização dos dados é feita pela própria estrutura do  Thrift , conforme definido pelo TProtocol e encapsulado pelo TTransport, de acordo com o formato que foi configurado anteriormente.

Fonte: DAB/SAS/MS.

3.3 Suporte XML do Sistema e-SUS AB

Como alternativa ao Thrift para exportação dos dados de sistemas próprios para o Sistema e-SUS AB, a partir da versão 2.0, o Sistema e-SUS AB traz suporte à importação no formato XML , exceto para a API do Cidadão.

Para tal, são disponibilizados os XSD (XML Schema Definition) para validação dos XML exportados pelo sistema próprio. Os XSD  correspondem ao modelo RAS , e têm o objetivo de oferecer uma forma de importar os Registros de Atendimento Simplificado (RAS), como visto na seção 3.1.

Capítulo 4 . API Cidadão

Esta API  permite integrar o Sistema com PEC a outro sistema de informação migrando uma base de cadastro de cidadãos, minimizando o esforço de recadastramento e digitação. O cidadão é identificado pelo CNS ou CPF, sendo assim, os dados já existentes serão alterados com a nova importação quando for localizado o mesmo cidadão. Esta importação pode ser realizada em qualquer momento.

Para entender melhor a aplicação e forma de uso da API, a seguir será detalhada a estrutura da API, bem como será apresentado um exemplo de implementação usando a linguagem Java.

4 .1 Estrutura da API C idadão

A API   Cidadão implementa a estrutura dos dados que devem ser salvos em arquivo, como vimos na Seção 3 .2.1. Esta estrutura recebeu o nome de CidadaoTransportThrift e pode ser visualizada na Figura 4 .1, com destaque aos dados obrigatórios. Dois campos são marcados como condicionais, pois o preenchimento deles depende de outro valor em bloco, a saber: CNS (naoPossuiCNS=true) e nomeMae (desconheceNomeMae=false).

Figura 4 .1 Estrutura dos dados da API CidadaoTransportThrift

A API ainda usa algumas estruturas auxiliares como: SexoThrift, TipoSanguineoThrift e EnderecoTransportThrift (ver Figura 4 .2). Além dessas estruturas auxiliares ainda é necessário fazer referência a um conjunto de informações provenientes de Tabelas de Referência, a saber: Escolaridade, Raça/Cor, Etnia, Localidade (para Município de Nascimento e Município de Residência), CBO e Estado Civil.

Figura 4 .2 Estrutura dos dados da API  Endere c oTransportThrift

4 .2 Exemplo de uso da API Thrift Cidadão

Nesta seção iremos apresentar um exemplo de uso da API Thrift Cidadão com comentários para tornar mais fácil a compreensão dos conceitos usados e das variáveis do próprio Sistema e-SUS AB em relação aos dados do cidadão.

O exemplo a seguir não pretende ser completo, portanto alguns detalhes julgados irrelevantes foram suprimidos, portanto este código deve ser adaptado para ser executado.

Exemplo 4 .1 – Implementação na Linguagem Java


ExemploThriftCidadaoJava.java



Capítulo 5 . API  RAS

Esta API  é recomendad a  aos municípios que optarem pela utilização de outros sistemas de informação e que desejam transmitir seus dados produzidos na Atenção Básica para o Ministério da Saúde. A estrutura RAS (Registro de Atendimento Simplificado) é baseada em um conjunto mínimo de informações em saúde coletadas pelos Sistemas PEC e CDS, conforme descrito no Capítulo 2 , e deverá ser adotada como processo padrão para transmissão dos dados  ao Sistema de Informação em Saúde para a Atenção Básica (SISAB).

Para entender melhor a aplicação e a forma de uso da API, a seguir será detalhada a estrutura da API, bem como será apresentado um exemplo de implementação usando a linguagem Java.

5 .1 Estrutura da API  RAS

A API  RAS implementa a estrutura dos dados que devem ser salvos em arquivo, como vimos na Seção 3 .2.1. Esta estrutura recebeu o nome de DadosTransporteThrift e pode ser visualizada na Figura 5 .1, com destaque aos dados obrigatórios. Esta API tem um comportamento diferente da API  Cidadão, pois ela tem antes dos dados de atendimento uma camada para identificar o envelope dos dados que estão sendo transmitidos.

Figura 5 .1 Estrutura dos dados da API DadoTransporteThrift

Esta API usa uma estrutura auxiliar (ver Figura 5 .2) para descrever os dados da instalação. Além dessas estruturas auxiliares ainda é necessário fazer referência a um conjunto de informações provenientes das Tabelas de Referências, descrita no Dicionário de Dados.

Figura 5 .2 Estrutura dos dados da API  DadoInstalacaoThrift

        Considerando o fluxo de informações de um Sistema Próprio (originadora) para um Centralizador Municipal (remetente) alguns campos devem ser definidos para que seja possível de identificá-los no módulo de Controle de Recebimento dos dados no Sistema e-SUS AB. A seguir alguns detalhes importantes são destacados da API  DadoTransporteThrift :

        A instalação também tem alguns dados que devem ser definidos por meio da entidade DadoInstalacaoThrift:

        Como visto anteriormente a estrutura do arquivo a ser enviado pode tomar várias formas, no entanto este deve compor essencialmente um arquivo zip com vários arquivos referenciando um registro/cadastro, podendo este registro (Master) estar organizando uma lista de registro do mesmo tipo (Child). Na Figura 5 .3, podemos ver a estrutura de um possível arquivo.

RAS_ZipFile.png

Figura 5 .3 Estrutura de um possível arquivo RASZipFile.zip

        A seguir, são apresentadas as entidades, detalhadas no  Dicionário de dados das APIs , usadas na API RAS.

Quadro 2 – Entidades usadas na API RAS

Profissional/cabeçalho

  • UnicaLotacaoHeaderThrift : essa  entidade  é utilizada para representar o profissional responsável pelas fichas.
  • VariasLotacoesHeaderThrift : essa entidade é utilizada para representar o profissional responsável  pela  ficha, bem como os outros que o auxiliaram na atividade.
  • ProfissionalCboRowItemThrift : e ntidade  usada em listas de profissionais.
  • HeaderCdsCadastroThrift :  entidade  utilizada para representar o profissional que realizou uma ação (cadastro individual, domiciliar, ou visita domiciliar), e a respectiva data.

XSD para suporte ao XML:

v2000unicalotacaoheader.xsd

v2000variaslotacoesheader.xsd

v2000profissionalcborowitem.xsd

v2000headercdscadastro.xsd

Atendimento

Atendimento Individual

  • AtendimentoIndividualMasterThrift : entidade que organiza os dados de Atendimento Individual (cabeçalho e atendimentos).
  • AtendimentoIndividualChildThrift : entidade que organiza os dados de Atendimento Individual, individualmente.
  • ProblemaCondicaoAvaliacaoAIThrift : entidade que organiza os Problemas e Condições avaliados no atendimento individual.
  • OutrosSiaThrift : entidade que organiza os Exames Solicitados e/ou Avaliados referenciados pelo código do SIGTAP.

XSD para suporte ao XML:

v2000fichaatendimentoindividualmaster.xsd

v2000fichaatendimentoindividualchild.xsd

v2000problemacondicaoavaliacaoai.xsd

v2000outrossia.xsd

Procedimentos

  • ProcedimentoMasterThrift : entidade que organiza a realização de procedimentos realizados por um profissional, tanto os individualizados quanto os consolidados.
  • FichaProcedimentoChildThrift : entidade que organiza a realização de procedimentos realizados a um cidadão, individualmente.

XSD para suporte ao XML:

v2000fichaprocedimentomaster.xsd

v2000fichavisitadomiciliarchild.xsd

Atendimento Odontológico Individual

  • AtendimentoOdontologicoMasterThrift : entidade que organiza os dados de Atendimento Odontológico Individual (cabeçalho e atendimentos).
  • FichaAtendimentoOdontologicoChildThrift : entidade que organiza os dados de Atendimento Odontológico Individual, individualmente.
  • ProcedimentoQuantidadeThrift : entidade que organiza os itens da lista Outros Procedimentos do atendimento odontológico.

XSD para suporte ao XML:

v2000fichaatendimentoodontologicomaster.xsd

v2000fichaatendimentoodontologicochild.xsd

v2000procedimentoquantidade.xsd

Atividade Coletiva

  • FichaAtividadeColetivaMasterThrift : entidade que organiza os dados de uma Atividade Coletiva.
  • ParticipanteRowItemThrift : entidade que organiza os itens da lista de participantes de uma Atividade Coletiva.

XSD para suporte ao XML:

v2000fichaatividadecoletiva.xsd

v2000participanterowitem.xsd

Visita Domiciliar

  • VisitaDomiciliarMasterThrift : entidade que organiza as Visitas Domiciliares realizadas por um profissional.
  • FichaVisitaDomiciliarChildThrift : entidade que organiza as Visitas Domiciliares realizadas a um cidadão, individualmente.

XSD para suporte ao XML:

v2000fichavisitadomiciliarmaster.xsd

v2000fichavisitadomiciliarchild.xsd

Marcadores de Consumo Alimentar

  • FichaConsumoAlimentar: entidade que organiza as informações do questionário de Marcadores de Consumo Alimentar
  • PerguntaQuestionarioCriancasMenoresSeisMeses: bloco de respostas aplicado exclusivamente para crianças menores de seis meses
  • PerguntaQuestionarioCriancasDeSeisVinteTresMeses: bloco de respostas aplicado exclusivamente para crianças maiores de seis meses e até 24 meses não completos
  • PerguntaQuestionarioCriancasComMaisDoisAnos: bloco de respostas aplicado exclusivamente para crianças com 2 (dois) anos ou mais
  • PerguntaCriancasMenoresSeisMesesEnum: enumerador das questões para crianças menores de seis meses
  • PerguntaCriancasDeSeisVinteTresMesesEnum: para crianças maiores de seis meses e até 24 meses não completos
  • PerguntaCriancasComMaisDoisAnosEnum:  para crianças com 2 (dois) anos ou mais
  • RespostaMultiplaEscolhaEnum: controlador de respostas multiplas
  • RespostaUnicaEscolhaEnum: controlador de resposta única

XSD para suporte ao XML:

v2000fichaconsumoalimentar.xsd

v2000perguntaquestionariocriancascommaisdoisanos.xsd

v2000perguntaquestionariocriancasdeseisvintetresmeses.xsd

v2000perguntaquestionariocriancasmenoresseismeses.xsd

v2000respostamultiplaescolhaenum.xsd

v2000respostaunicaescolhaenum.xsd

v2000perguntacriancascommaisdoisanosenum.xsd

v2000perguntacriancasdeseisvintetresmesesenum.xsd

v2000perguntacriancasmenoresseismesesenum.xsd

Atendimento Domiciliar

Avaliação de Elegibilidade

  • FichaAvaliacaoElegibilidadeThrift: entidade que organiza as informações da Ficha de Avaliação de Elegibilidade, , exclusivo para Serviço de Atenção Domiciliar

XSD para suporte ao XML:

v2000fichaavaliacaoelegibilidade.xsd

Atendimento Domiciliar

  • FichaAtendimentoDomiciliarMasterThrift: entidade que organiza as informações da Ficha de Atendimento Domiciliar com as informações do profissional, exclusivo para Serviço de Atenção Domiciliar
  • FichaAtendimentoDomiciliarChildThrift: entidade que organiza o atendimento individualizado em cada ficha de atendimento

XSD para suporte ao XML:

v2000fichaatendimentodomiciliarmaster.xsd

v2000fichaatendimentodomiciliarchild.xsd

Cadastro

Cadastro Domiciliar

  • CadastroDomiciliarMasterThrift : entidade que organiza os dados de um Cadastro Domiciliar.
  • EnderecoLocalPermanenciaThrift : entidade que organiza os dados de Endereço (Local de Permanência, para Situação de Rua) de um Cadastro Domiciliar.
  • CondicaoMoradiaThrift : entidade que organiza os dados de condição de moradia do Cadastro Domiciliar.
  • FamiliaRowThrift : entidade que organiza os itens da lista de famílias de um domicílio.

XSD para suporte ao XML:

v2000cadastrodomiciliar.xsd

v2000enderecolocalpermanencia.xsd

v2000condicaomoradia.xsd

v2000familiarow.xsd

Cadastro Individual

  • CadastroIndividualMasterThrift : entidade que organiza os dados de Cadastro Individual do cidadão adscrito.
  • IdentificacaoUsuarioCidadaoThrift : entidade que organiza os dados de identificação do cidadão no Cadastro Individual.
  • InformacoesSocioDemograficasThrift : entidade que organiza as informações sociodemográficas do cidadão no Cadastro Individual.
  • CondicoesDeSaudeThrift : entidade que organiza os dados de Cadastro Individual do cidadão adscrito.
  • EmSituacaoDeRuaThrift : entidade que organiza os dados específicos sobre cidadão em situação de rua.

XSD para suporte ao XML:

v2000cadastroindividual.xsd

v2000identificacaousuariocidadao.xsd

v2000informacoessociodemograficas.xsd

v2000condicoesdesaude.xsd

v2000emsituacaoderua.xsd

Fonte: DAB/SAS/MS.

        

5 .2 Exemplos de uso da API Thrift RAS

Nesta seção iremos apresentar um exemplo de uso da API Thrift Cidadão com comentários para tornar mais fácil a compreensão dos conceitos usados e das variáveis do próprio Sistema e-SUS AB em relação aos dados do cidadão.

Foram implementados dois exemplos, um na linguagem Java, Exemplo 5.1, e outro na linguagem Delphi, Exemplo 5.2.

5.2.1 Exemplo: Implementação na Linguagem Java


ExemploDadosParaThrift.java


5.2.2 Exemplo: Implementação na Linguagem Delphi


ThriftExample.dpr


5.3 Exemplo de uso do RAS exportado via XML

Nesta seção iremos apresentar um exemplo de uso da estrutura RAS, descrita no dicionário de dados, usando arquivos XML.

5.3.1 Exemplo: XML de exportação do Cadastro Domiciliar


CadastroDomiciliar.esus.xml


5.3.2 Exemplo: XML de exportação do Cadastro Individual


CadastroIndividual.esus.xml


5.3.3 Exemplo: XML de exportação do Ficha de Atendimento Individual


FichaAtendimentoIndividual.esus.xml


Conclusão

Este manual buscou trazer vários conceitos para que se torne mais fácil a implementação da exp ortação de dados para o Sistema e-SUS AB por meio das API Thrift geradas para integração com  Sistema Próprios.

Para maiores detalhes consultar os manuais citados nas referência bibliográficas e em todo decorrer do texto.


Referências Bibliográficas

Apache Thrift Install - http://thrift.apache.org/docs/install/

Andrew Prunicki, Apache Thrift, 2009 Object Computing, Inc. EUA: http://jnb.ociweb.com/jnb/jnbJun2009.html

Ministério da Saúde, Estratégia de e-Saúde para o Brasil, 2014 (em publicação)

Stratos Dimopoulos. Thrift Tutorial, 2013: http://thrift-tutorial.readthedocs.org/

Site do Apache Thrift - http://thrift.apache.org

Site do Sistema e-SUS Atenção Básica: http://dab.saude.gov.br/esus