Sistema e-sus Atenção Básica

Transcrição

1 Sistema e-sus Atenção Básica Manual de Exportação - API Thrift 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 e das APIs do e-sus AB para efetivar a comunicação entre os sistemas. API Thrift e-sus AB Versão 1.3 Capítulo 1. Introdução à Estratégia e-sus AB 1.1 Sistema com Coleta de Dados Simplificada Cadastro da Atenção Básica Fichas de Atendimento Sistema de Software e-sus AB com CDS 1.2 Sistema com Prontuário Eletrônico do Cidadão Requisitos de um Prontuário Eletrônico para a AB Sistema de Software e-sus AB com PEC 1.3 SISAB 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 Arquitetura do Thrift 3.2 APIs Thrift do Sistema e-sus AB Gerando um Arquivo para o Sistema e-sus AB Capítulo 4. API Thrift Cidadão 4.1 Estrutura da API Thrift Cidadão 4.2 Exemplo de uso da API Thrift Cidadão Capítulo 5. API Thrift RAS 5.1 Estrutura da API Thrift RAS 5.2 Exemplo de uso da API Thrift RAS Conclusão Referências Bibliográficas

2 Capítulo 1. Introdução à Estratégia e-sus AB A Estratégia e-sus Atenção Básica é apoiada essencialmente por dois sistemas, o Sistema de Informação em Saúde para a Atenção Básica (SISAB), o sistema de informação nacional, e o Sistema e-sus Atenção Básica, composto por sistemas de software que instrumentalizam o processo de trabalho nas 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 atenção básica. Ao mesmo tempo, 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 independente do sistema de software que as equipes de saúde utilizem para fazer gestão local do serviço de saúde, e portanto se faz necessário uma base de Registro Eletrônico de Saúde (RES) que minimamente dialogue com as necessidades das Redes de Atenção à Saúde organizadas de forma intermunicipal e interestadual. O Departamento de Atenção Básica, do Ministério da Saúde, com o objetivo de incentivar o uso de Tecnologias de Informação e Comunicação em Saúde na Atenção Básica, vêm apoiando o desenvolvimento de tecnologias que atendam as 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. Este projeto está dando foco as necessidades locais e da esfera municipal. Nessa perspectiva entendendo que a melhoria e qualificação do processo de trabalho das equipes de saúde da atenção básica integradas nas Redes de Atenção à Saúde devem trazer resultados significativos na gestão estadual e federal da AB com resultados promissores. A Estratégia e-sus Atenção Básica, nesse contexto, busca por meio dos Sistemas e-sus AB implementar essas tecnologias para tornar o processo de trabalho das equipes de saúde e de gestão mais fáceis, reduzindo o tempo gasto com a burocracia do uso e alimentação dos sistemas de informação em saúde que fazem interface com a AB. Por outro lado a estratégia busca garantir que o desenvolvimento das soluções avancem na adoção de padrões internacionais da área de informática em saúde, e com isso ampliar a interoperabilidade entre os sistemas gerencias da saúde e de outras áreas no município. Em especial 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), porém para cenários de informatização distintos, como vimos em outros documentos.

3 Nas próximas seções, resumidamente, entenderemos como funciona cada software do Sistema e-sus AB e outros detalhes que ajudem 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 Unidades Básicas de Saúde (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. Caracteristicamente é um sistema de transição, para que seja possível em tempo mais apropriado implantar um sistema com PEC. O Sistema com CDS, na versão atual (v 1.3), utiliza sete fichas para o registro das informações: Cadastro Domiciliar Cadastro Individual Ficha de Atendimento Individual Ficha de Atendimento Odontológico Individual Ficha de Atividade Coletiva Ficha de Procedimentos Ficha de Visita Domiciliar Ficha de Atividade Coletiva Essas fichas deverão ser digitadas no sistema de software e-sus AB com CDS. Como um sistema transitório este não tem a pretensão de ser um sistema exaustivo em relação as necessidades de informação das equipes de AB, no entanto organiza um conjunto essencial de informações que estruturam o cadastro da AB e os registros de atendimentos realizados pelas equipes Cadastro da Atenção Básica O Cadastro Nacional do 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 pela sua realização. É 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, através 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).

4 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 a mapear as características de saúde, sociais e econômicas da população adscrita ao território sob sua responsabilidade. Este cadastro está organizado em duas dimensões: domiciliar e individual. O cadastro domiciliar identifica as características sociossanitárias dos domicílios no território das equipes de AB. Este cadastro busca identificar, ainda, situações de populações domiciliadas em locais que não podem ser considerados domicílio, por exemplo, situação de rua (IBGE, 2009), no entanto devem ser monitorados pela equipe de saúde. No cadastro domiciliar o vínculo do cidadão ao seu domicílio é feito por meio do CadSUS do responsável familiar. Podendo este cadastro ser vinculado a mais de um responsável familiar e portanto a mais de um núcleo familiar. 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, sendo elas: informações de identificação/sociodemográficas e condições de saúde autorreferidas pelo usuário 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 caracteriza o resumo do atendimento de nível superior, é nesta ficha que os profissionais de nível superior devem informar o que ocorreu no atendimento. Algumas informações são fundamentais nesta ficha, tais como tipo de atendimento, problema/condição avaliada e conduta do atendimento. Complementar a esta ficha vem a ficha de procedimentos, onde se podem registrar os procedimentos e pequenas cirurgias realizadas no atendimento. A ficha de procedimentos ainda é utilizada para registrar procedimentos específicos realizados por técnicos de nível médio da unidade.

5 Excepcionalmente para os profissionais da Saúde Bucal, ainda pode ser usada a ficha de atendimento odontológico individual, onde registramos similarmente 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. 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, passam a ter o registro individualizado. Devemos destacar que esta ficha passa a ser exclusiva para as visitas realizadas pelos ACS, quando for necessário registrar um atendimento no domicílio, realizada por profissional de nível superior, é possível usar a ficha de atendimento individual informando no local de atendimento como Domicílio, caracterizando assim um atendimento em domicílio. Uma novidade para o registro de ações da AB é a ficha de atividade coletiva, usada para registrar tanto ações administrativas, como reuniões de equipe, quanto ações de saúde, como atividades coletivas de promoção de saúde ou ainda atendimento em grupo. Exceto a ficha de atividade coletiva, as outras fichas passam a registrar vários atendimentos na mesma ficha. Registrados na vertical (em colunas) as fichas buscam um registro bastante objetivo e sem a pretensão de ser exaustivo nas opções de preenchimento rápido, que em geral são acompanhados por campos Outros onde é possível, quando necessário, registrar outras ações usando codificações e classificações utilizadas pelos sistemas de informações vigentes Sistema de Software e-sus AB com CDS Sistema que estrutura a digitação do cadastro e das fichas de atendimento, o Sistema com CDS conta com uma estrutura de fácil instalação e multiplataforma, podendo ser utilizado também em conjunto com o Sistema e-sus AB com PEC através do módulo CDS. O sistema e-sus AB com CDS é exclusivo para digitação, portanto não tem funções gerenciais. Este 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, as necessidades dessa aplicação, não é recomendado o armazenamento de um volume grande de informações no Sistema com CDS.

6 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 integração e 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, ao que cabe neste momento apontar algumas diretrizes usadas pelo sistema que busca garantir a atenção integral à saúde do paciente da forma que se preconiza na PNAB 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 dêem 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 o que 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 etc. Isto é, controlar aspectos que representam as condições de organização e funcionamento dos serviços de saúde. Nesse sentido apresentam-se abaixo processos essenciais para o desempenho das funções da AB destacados por requererem inovações e desenvolvimento para suporte por sistema de

7 software: territorialização, acolhimento, agendamento, gestão do cuidado e gestão do acesso e qualidade 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. O sistema, como podemos ver na imagem de sua tela inicial, na versão atual, já implementa os seguintes módulos: Módulo Cidadão: contempla o cadastro do cidadão e a integração com o CadSUS. Todo cidadão atendido no Sistema com PEC precisa de um cadastro, mesmo que este ainda não possua um CNS. Módulo de Agenda: contempla as necessidades de configuração de agenda dos profissionais, marcação de consulta, controle de chegada e controle de faltosos da agenda, além das reservas de horários por demandas administrativas e de atividades programáticas da equipe / profissional. Módulo de Atendimento Individual: contempla o controle de lista de atendimento (fluxo do cidadão na unidade), acolhimento à demanda espontânea (inserção na lista de atendimento e escuta inicial), prontuário eletrônico (Folha de Rosto, SOAP, Lista de Problemas, etc), entre outras funcionalidades. Módulo de Relatórios: contempla a geração de relatórios de cadastro, situação de saúde, atendimentos do território, entre outros. Módulo Administração: contempla o cadastro geral e configuração do sistema, cadastro de unidade, cadastro do profissional (usuário do sistema), controle de perfil de usuário, importação dos dados do CNES, exportação do BPA, entre outros.

8 Figura 1.2: Tela Inicial do Sistema e-sus AB com PEC 1.3 SISAB A portaria 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, o qual substitui o atual Sistema de Informação da Atenção Básica (SIAB), que permanece em um período de transição até Maio de Uma das principais características desse novo sistema é o registro de informações individualizadas, pois oferece ao gestor uma visão mais fidedigna das ações das equipes de saúde em relação a cada cidadão de seu território. 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 abordamos 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 ampliamos a discussão contemplando as regras gerais de envio dos dados. 1 Portaria Nº 1.976, de 12 de setembro 2014, define o prazo máximo de transição entre o SIAB e o SISAB.

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

10 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 1.3, 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; 3. Compartilhamento hierárquico dos dados do Sistema e-sus AB; Figura Imagem-objetivo da Troca de Informações no Sistema e-sus AB

11 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 ainda temos uma boa parcela das UBS não informatizadas. A simplificação do registro passou por uma análise bastante criteriosa para 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 a 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, onde o registro individualizado seria dificultoso, porém importante para o monitoramento das ações na AB. O Sistema com PEC avança no outro sentido, na perspectiva de eliminar o registros em fichas e formulários de papel. E portanto busca reestruturar o trabalho dos profissionais da UBS por meio de ferramentos 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. Neste contexto, precisamos entender quais os 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 que são gerados a partir desses blocos. Como vemos 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: CAD: gerado a partir dos dados de Cadastro da AB, é um documento que permite compartilhar as informações de cadastro por cidadão, associado aos dados de domicílio e de situação auto-referida de saúde do cidadão; RAS: sigla para Registro de Atendimento Simplificado, é gerado a partir dos eventos de saúde individualizados e identificados. Corresponde a um conjunto essencial de

12 informações que devem ser suficientes para atender as demandas do sistema nacional; RAC: sigla para Registro de Atendimento Completo, também gerado a partir dos eventos de saúde individualizados e identificados, porém com um conjunto de informações mais estruturado que busca o compartilhamento de informações de sistemas com prontuário eletrônico. Este modelo é totalmente compatível com o modelo RAS. CONS: gerado a partir dos dados consolidados do Sistema com CDS, este modelo permite o compartilhamento dessas informações apenas para complementar informações do sistema nacional, no entanto para os sistemas que não trabalham com dados consolidados este conjunto de informações deve ser enviado via modelo RAS. CONF: gerado a partir dos dados de configuração e parametrização do sistema com prontuário eletrônico, este modelo possibilita o compartilhamento dessas informações tanto para fins de gestão de saúde quanto para administração do sistema. Figura 2.2: Blocos de Informações do Sistema e-sus AB Como vimos, os documentos RAC, RAS e parte do CONS tem 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, ilustramos 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

13 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. Fig ura 2.3: Ori ge m dos Doc um ent os de Tro ca de Dad os do Sist em a e- SU S AB Val e res saltar 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. Neste momento precisamos ter claro que o SISAB tem o mesmo conjunto de informações do Sistema com CDS, portanto, para garantir o envio dos

14 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, portanto é esse módulo que irá processar os dados enviados ao Sistema e-sus AB, independente da fonte de informação, podendo ser do Sistema e-sus AB com CDS ou com PEC, ou ainda 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: CAD + RAS (cadastro e registro simplificado) CAD + RAS + CONS (cadastro, registro simplificado e alguns dados consolidados) 2.3 Compartilhamento hierárquico dos dados do Sistema e-sus AB A terceira situação faz referência a 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 descentralizadas, sendo possível ter dados em UBS ou Distrito Sanitários separados do ambiente central. Essa descentralização demanda uma estrutura de transmissão do sistema, entre a base local e 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. Lembrando que toda forma de transmissão de dados se dá usando o modelo CAD + RAS, portanto, neste momento, mesmo que o município esteja usando o Sistema com PEC, os dados completos permanecerão apenas na base local. Independente 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, um período máximo, no pior caso, de desatualização das bases de um mês, o que nós permite antecipar problemas e gerenciar melhor os conflitos.

15 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 as 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 este 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 é uma UBS (C) que está transmitindo sua base diretamente com o Centralizador Municipal. E por último uma UBS (D) que não possui uma base local e usa o Sistema com PEC diretamente no Centralizador Municipal. Este pequeno cenário ilustrado na Figura 2.6 permite visualizar as cópias dos dados distribuídos na rede de sistema. A 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 AB e a outra no Centralizador Municipal. A UBS C tem apenas uma cópia no Centralizador Municipal, e a UBS D não tem cópia da informação e fica dependendo apenas da instalação do Centralizador Municipal. Como vimos 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 oferecer servidores para armazenar fisicamente os dados desses municípios.

16 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).

17 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. Neste capítulo entenderemos um pouco mais 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 usando Apache Thrift 3.1 Apache Thrift O Apache Thrift é um framework RPC (Remote 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. Traduzido do inglês para brechó, traz a intuição do conceito de troca de objetos oferecendo um ambiente de troca de serviços entre aplicações por meio de uma estrutura para desenvolvimento de serviços escaláveis entre linguagens e oferecendo não apenas suporte a geração de código para várias linguagens, mas também uma pilha de software que simplifica 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:

18 Serialização entre linguagens com menor sobrecarga do que as alternativas como SOAP, devido à utilização do formato binário; A biblioteca leve, enxuta e limpa, sem estrutura para código. Não há arquivos de configuração XML; O formato de nível de aplicação e de serialização são claramente separados, podendo ser modificados de forma independente; Os estilos de serialização predefinidos incluem: binário, HTTP-friendly e binário compacto; Sem dependências de construção ou de software não-padrão. Não mistura licenças de softwares incompatíveis; Oferece suporte para várias linguagens de programação (em níveis variados), incluindo Java, PHP, C/C++, Delphi, Python, Ruby, Smalltalk, Haskell, Erlang, Node.js, Go, D, entre outras; Compatível com plataformas de computação distribuída como Apache Hadoop e Apache Cassandra 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: Tipos: Um sistema de tipo comum devem existir em toda linguagens de programação, sem exigir que o desenvolvedor do aplicativo use tipos de dados Thrift personalizados ou tenha que escrever seu próprio código de serialização. Transporte: Cada linguagem tem de ter uma interface comum para o transporte bidirecional de dados. Os detalhes de como um determinado transporte é implementado não deve importar para o desenvolvedor do serviço. O mesmo código do aplicativo deve rodar sobre um fluxo sockets TCP, na memória ou em arquivos no disco. Protocolo: Tipos de dados devem ter alguma maneira de utilizar a camada de transporte para codificar e decodificar a si mesmos. Mais uma vez, o desenvolvedor do aplicativo não precisa se preocupar com esta camada. Se o serviço usa um XML ou protocolo binário é irrelevante para o código da aplicação. Tudo o que importa é que os dados possam ser lidos e escritos de forma consistente e determinística; Versionamento: Para serviços robustos, os tipos de dados envolvidos devem fornecer um mecanismo para controle de versão. Especificamente, deve ser possível adicionar ou remover campos em um objeto ou alterar a lista de argumentos de uma função sem qualquer interrupção do serviço (ou pior, falhas de segmentação desagradáveis); Processadores: Por fim, gerar um código capaz de processar fluxos de dados para realizar chamadas de procedimento remoto em diferentes linguagens. Estas características deram as diretrizes para a definição de uma boa arquitetura, como será descrito a seguir.

19 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 (Fonte: Wikipedia) 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,

20 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: API Thrift Cidadão tem o objetivo de garantir uma forma de importar cadastros já consolidados no município ou estado, de modo que seja possível reutilizar esses cadastros no Sistema com PEC, no módulo cidadão. API Thrift RAS tem o objetivo de oferecer uma forma de importar os Registros de Atendimento Simplificado (RAS), como vimos na seção 3.1, semelhante ao formato usado pelo Sistema com CDS. Este modelo simplificado permite que os municípios que tem sistemas próprios e estruturados nas Unidades Básicas de Saúde possam exportar os dados para que estes sejam enviados ao SISAB via Centralizador Municipal do 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 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 simplicidade, oferece neste momento apenas uma forma de integração usando troca de arquivos, portanto iremos detalhar nesta seção os passos para gerar esse arquivo abstraindo as especificidades de alguma linguagem em particular. Passo 01 Configure sua aplicação para usar Thrift