Baixar o Manual em PDF

Ministério da Saúde / SAS / Departamento de Atenção Básica

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

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

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


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.


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.

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


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.

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


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.

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


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.

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


software: territorialização, acolhimento, agendamento, gestão do cuidado e gestão do

acesso e 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.

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.


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

1Portaria Nº 1.976, de 12 de setembro 2014, define o prazo máximo de transição entre o

SIAB e o SISAB.

http://bvsms.saude.gov.br/bvs/saudelegis/gm/2014/prt1976_12_09_2014.html


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 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 2.1 - Imagem-objetivo da Troca de Informações no 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 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


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


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


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.


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.


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


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

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:

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


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,


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.

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


Para que seja possível usar as APIs geradas pelo Apache Thrift é necessário

instalar e configurar o 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ã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)

• Ruby (Ruby 1.8, bundler gem)

Para mais informações sobre como usar as libs do Thrift acesse

http://thrift.apache.org/lib/

Caso necessite de alguma outra API suportada pelo Thrift para o Sistema e-SUS

AB, contate nossa equipe de desenvolvimento através do endereço: [email protected]

Passo 02 – Baixe a API do Sistema e-SUS AB a ser utilizada

Baixe a API gerada pelo Thrift para o Sistema e-SUS AB a partir do site do e-SUS

AB, por meio do endereço: http://dab.saude.gov.br/esus.

Na área de download, selecione a opção “Integração Sistemas Próprios” e na

sequência clique em “Thrift Cidadão” ou “Thrift RAS” conforme for a necessidade.

Passo 03 – Copie o código da API para sua aplicação

Após baixar o arquivo, descompacte-o e copie os arquivos correspondentes a

linguagem usada por sua aplicação para dentro do seu código base.

Passo 04 – Inclua a API e as bibliotecas na sua aplicação

Inclua a API do Sistema e-SUS AB correspondente a sua linguagem e as bibliotecas

do Thrift no código base de sua aplicação para que você possa chamar as funções dentro

da sua aplicação.

Para exemplos sobre como fazer isso em sua aplicação veja os exemplos para cada

linguagem em http://thrift.apache.org/tutorial/.

Passo 05 – Configure a camada de Transporte e Protocolo

Após preparar a sua 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

http://thrift.apache.org/lib/

mailto:[email protected]

http://dab.saude.gov.br/esus

http://thrift.apache.org/tutorial/


◦ Java: TIOStreamTransport

◦ Delphi: TStreamTransportImpl

◦ C#: TStreamTransport

◦ PHP5: TPhpStream

◦ Ruby: IOStreamTransport

• TProtocol: BinaryProtocol

◦ Java: TBinaryProtocol

◦ Delphi: TBinaryProtocolImpl

◦ C#: TBinaryProtocol

◦ PHP5: TBinaryProtocol

◦ Ruby: BinaryProtocol

Para mais detalhes veja exemplos de funções de serialização disponível no manual:

● Exemplo na linguagem Java: ThriftSerializer.java

● Exemplo na linguagem Delphi: ThriftSerializer.pas

Passo 06 – Preenchendo os dados

Neste momento você pode criar as rotinas que irão preencher os dados conforme

definido pelas APIs. Como vimos, as APIs geradas pelo Thrift definem as estruturas dos

dados do e-SUS AB (DadoTransporteThrift ou CidadaoTransportThrift).

Nos próximos capítulos serão detalhadas as estruturas e a melhor forma de utilizar

essas APIs para importar os dados ao Sistema e-SUS AB.

Passo 07 – Empacotamento dos 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 ".esus13";

● Cadastro de Cidadão (CidadaoTransportThrift) : extensão ".cidadao"

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

● Exemplo na linguagem Java: ZipWriterExemplo.java

● Exemplo na linguagem Delphi: ZipWriterExemplo.pas

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.

http://exemplos/Java/exemplosThrift/utils/ThriftSerializer.java

http://exemplos/Delphi/exemplosThriftDelphi/src/common/ThriftSerializer.pas

http://exemplos/Java/exemplosThrift/utils/ZipWriterExemplo.java

http://exemplos/Delphi/exemplosThriftDelphi/src/common/ZipWriterExemplo.pas


Capítulo 4. API Thrift Cidadão

Esta API Thrift 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 Thrift Cidadão

A API Thrift 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 EnderecoTransportThrift

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

http://drive.google.com/open?id=0BxkbOQf43KQiTVhrT3VOQ1RhTDA


Capítulo 5. API Thrift RAS

Esta API Thrift é recomendado 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 Thrift RAS

A API Thrift 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 Thrift 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:

• uuidDadoSerializado: UUID do dado (identificador "universal" gerado na

criação do item) ;

• tipoDadoSerializado: Tipo/classe do objeto serializado ;

• cnesDadoSerializado: CNES da unidade de saúde ;

• codIbge: Código IBGE do dado serializado

• ineDadoSerializado: código do Identificador Nacional da Equipe (INE) da

equipe que efetivamente gerou a informação/registro de atendimento;

• numLote: Número do Lote, controlado pela originadora;

• dadoSerializado: Dado serializado a partir de um Thrift . É neste campo que

será vinculada o registro de atendimento/cadastro que está sendo enviada,

usando as estruturas do RAS.

• remetente: Identifica a instalação que enviou o dado, por meio da estrutura

auxiliar DadoInstalacaoThrift , conforme descrito a seguir;

• originadora: Identifica a instalação que cadastrou/digitou, por meio da

estrutura auxiliar DadoInstalacaoThrift , conforme descrito a seguir;

• versao: Identifica a versão do E-SUS AB usando VersaoThrift (1, 3, 0);

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

entidade DadoInstalacaoThrift:

• contraChave: Identifica o software que está gerando a informação. Não

demanda nenhuma descrição mandatória, mas sugere-se usar o

NomeDoSoftware_Versao;

• uuidInstalacao: Identificador UUID da instalação do sistema, associado à

contraChave auxilia no controle de fluxo da aplicação que gerou a

informação. Cada instalação deve controlar seu próprio identificador, gerado

apenas no primeiro envio.

• cpfOuCnpj: Cpf do responsável ou CNPJ da empresa responsável, em geral

usa-se o CPF do profissional cadastrado no Centralizador Municipal que

receberá os dados.

• nomeOuRazaoSocial: Nome do responsável ou Razão Social da empresa

responsável

• fone: Telefone da pessoa ou empresa responsável

• email: Email da pessoa ou empresa responsável


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.

Figura 5.3 Estrutura de um possível arquivo RASZipFile.zip

A seguir são apresentadas as entidades, detalhadas no Anexo I, usadas na API

Thrift RAS:

• PROFISSIONAL / CABEÇALHO

◦ UnicaLotacaoHeaderThrift: Esta entidade é utilizada para representar o

profissional responsável pelas fichas

◦ VariasLotacoesHeaderThrift: Esta entidade é utilizada para representar o

profissional responsável pela ficha, e os outros que o auxiliaram na atividade

◦ ProfissionalCboRowItemThrift: Entidade 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

data respectiva

• ATENDIMENTO

◦ 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 avaliadas no atendimento individual

• OutrosSiaThrift: Entidade que organiza os Exames Solicitados e/ou

Avaliados referenciados pelo código do SIGTAP

◦ 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

◦ FichaAtividadeColetivaMasterThrift: Entidade que organiza os dados de uma

Atividade Coletiva

▪ ParticipanteRowItemThrift: Entidade que organiza os itens da lista de

participantes de uma Atividade Coletiva

◦ 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

◦ VisitaDomiciliarMasterThrift: Entidade que organiza as Visitas Domiciliares

realizadas por um profissional

▪ FichaVisitaDomiciliarChildThrift: Entidade que organiza as visitas

domiciliares realizadas a um cidadão, individualmente

• CADASTRO

◦ 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

◦ 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 sócio-demográ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

5.2 Exemplo 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.

Exemplo 5.1 – Implementação na Linguagem Java

ExemploDadosParaThrift.java

Exemplo 5.2 – Implementação na Linguagem Delphi

ThriftExample.dpr

http://exemplos/Java/exemplosThrift/procedimentos/ExemploDadosParaThrift.java

http://exemplos/Delphi/exemplosThriftDelphi/ThriftExample.dpr


Conclusão

Este manual buscou trazer vários conceitos para que se torne mais fácil a

implementação da exportaçã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

http://thrift.apache.org/docs/install/

http://jnb.ociweb.com/jnb/jnbJun2009.html

http://thrift-tutorial.readthedocs.org/

http://thrift.apache.org/

http://dab.saude.gov.br/esus

Baixar o Manual em PDF

Documents

Transcript of Baixar o Manual em PDF