UNIVERSIDADE DE MOGI DAS CRUZES

ANTONIO ANDRADE DOS SANTOS

MODELO DE DISPONIBILIZAÇÃO DO PRONTUÁRIO ELETRÔNICO

ÚNICO DO PACIENTE EM DISPOSITIVOS MÓVEIS

Mogi das Cruzes, SP

2015

UNIVERSIDADE DE MOGI DAS CRUZES

ANTONIO ANDRADE DOS SANTOS

MODELO DE DISPONIBILIZAÇÃO DO PRONTUÁRIO ELETRÔNICO

ÚNICO DO PACIENTE EM DISPOSITIVOS MÓVEIS

Dissertação apresentada ao Programa de

Pós-Graduação em Engenharia Biomédica

da UMC para defesa final, como parte dos

requisitos para obtenção do grau de

Mestre em Engenharia Biomédica.

Área de concentração: Bioengenharia e

Instrumentação Biomédica

Prof. Orientador: Dr. Henrique Jesus Quintino de Oliveira

Mogi das Cruzes, SP

2015

Dedico este trabalho primeiramente a Deus por me dar saúde e força para

acordar e trabalhar todos os dias da minha vida, por me conduzir no caminho do

aprendizado e da busca de um mundo melhor para se viver.

Dedico também a minha tia/mãe (in memorian) Rosa Bagatin Rebelo que me

educou e me conduziu ao caminho da moral, ética e justiça.

AGRADECIMENTOS

Ao professor Dr. Henrique Jesus Quintino de Oliveira que me orientou durante

todo o processo e mostrou a importância da pesquisa científica e seu real valor na

formação de um mestre.

A todos os Mestres Doutores que ministraram aulas nesse período, cada um

a sua forma, contribuindo com meu aprimoramento profissional e pessoal.

À esposa Maria Verônica que sempre me incentivou, ajudou e soube ser

compreensiva nos momentos de ausência pela dedicação necessária aos estudos.

À filha Paola Beatriz que participou em diversos momentos com a criação do

logotipo e design do aplicativo e auxílio com traduções de língua estrangeira.

Aos Professores José Azanha, Gabriel Baptista, Adilson Marques e Norberto

dos Santos que colaboraram, mesmo que pontualmente, mas merecem meu apreço

e sinceros agradecimentos.

Por fim, a todos os meus amigos que souberam entender minha ausência

momentos especiais de socialização, por conta desse meu projeto de vida.

“De todas as ciências, a educação é a mais espiritual, pois aplica-se às almas em

via de evolução e condiciona o futuro de toda a humanidade.”

(Pitágoras)

RESUMO

O Prontuário Eletrônico Único do Paciente (PEUP) é um modelo que foi proposto

para resolver os problemas de fragmentação dos Prontuários Eletrônicos do

Paciente (PEP). Os PEPs são os softwares e bancos de proprietários distintos e,

portanto, fragmentados, o que resulta em redundâncias desnecessárias e dificulta o

acesso devido por parte do paciente e dos profissionais de saúde. O modelo PEUP

é composto por três estruturas de dados: Síntese, Síntese Estendida e o Prontuário

Completo. Essas estruturas são organizadas em grade computacional Java Parallel

Processing Framework (JPPF). Cada conjunto de servidores da grade, com seus

nós de processamento, é chamado de Central Regional PEUP. As centrais são

interligadas através da Internet. Durante esta pesquisa foi desenvolvido um modelo

para disponibilizar o PEUP em dispositivos móveis (DM). O modelo foi testado e

avaliado por meio de um aplicativo PEUP-Mobile (PEUP-M) que permitiu avaliar se o

modelo supre a necessidade de disponibilidade do PEUP aos próprios pacientes e

principalmente aos profissionais da saúde, através de seus DM. Com o modelo do

PEUP-M o profissional médico pode consultar o prontuário no DM do próprio

paciente, mesmo sem internet. O médico ainda pode interagir com o PEUP-M em

seu DM, caso haja conexão. O aplicativo do PEUP-M foi desenvolvido em Java com

SQLite para armazenamento em DM e faz a comunicação com as centrais através

de Web Services, observando-se a necessidade de autenticidade e integridade dos

dados disponibilizados nos DM. Em 400 testes, mesmo em conexão com baixa

velocidade e qualidade de comunicação, realizados em dois DM em três tipos de

conexões com Internet (3G, 3G+ e Wi-Fi), foi obtido aproveitamento de 73% das

sincronizações, com tempo médio de aproximadamente três segundos para

sincronizar a Síntese do PEUP com o DM.

Palavras-chave: Prontuário Eletrônico Único do Paciente (PEUP), Dispositivos Móveis, Computação em Grade.

ABSTRACT

The Unique Electronic Health Record (UEHR) is a model that was presented to solve

the fragmentation problems in Patient’s Electronic Medical Records (PEMR). The

PEMRs are the softwares and distinct proprietary's bank and, therefore, fragmented,

which results in unnecessary duplication and makes it hard to have a right access by

the patient and health professionals. The UEHR model consists on three data

structures: Synthesis, Extended Synthesis and Full Medical Records. These

structures are organized in Java Parallel Processing Framework (JPPF). Each set of

servers, with their processing nodes, is called UEHR Regional Center. The centers

are interconnected through the internet. During this search a model to provide UEHR

in Mobile Devices (MD) was developed. The model was tested and evaluated by a

Mobile-UEHR app (M-UEHR) which allowed assessing whether the model meets the

availability need of PEUP to patients themselves and especially health professionals,

through their MD. With the M-UEHR model, the health professional can refer to the

health record in the patient's own MD, even without internet. The doctor may also

interact with the M-UEHR in your own MD, in case there is connection. The UEHR-M

was developed in Java with SQLite for storage in MD and communicates with the

centrals by Web Services, noticing the need for authenticity and integrity of the data

published in DMs. In 400 tests, even in connection with low speed and quality of

communication, made in two MD in three types of internet connection (3G, 3G + and

Wi-Fi), there was a 73% efficiency of synchronizations with about 3 seconds of mean

time to synchronize the UEHR Synthesis with DM.

Keywords: Electronic Health Records (HER), Mobile Devices, Grid Computing.

LISTA DE ILUSTRAÇÕES

Figura 1 - Relatório anual da Sociedade do Hospital “New York Hospital” de 1797. .............. 19

Figura 2 - Pulseira carrega histórico médico para situações de emergência ........................... 37

Figura 3 - Clipe do dispositivo GlucoTrack ..................................................................................... 38

Figura 4 - Dispositivo GlucoTrack .................................................................................................... 38

Figura 5 - Dispositivo HG1-c C8 MediSensors .............................................................................. 39

Figura 6 - Diagrama demonstrativo resumido do modelo PEUP-M ........................................... 42

Figura 7 - Diagrama demonstrativo do modelo PEUP com o PEUP-M ..................................... 47

Figura 8 - Criptografia de Chave Privada ....................................................................................... 56

Figura 9 – Mapeamento de rede das PMs para execução de teste do PEUP na grade

Computacional JPPF. ........................................................................................................................ 66

Figura 10 – Mapeamento de rede da VMs para execução de teste do PEUP na grade

Computacional JPPF. ........................................................................................................................ 67

Figura 11 – Modelo de comunicação adotado nos testes. .......................................................... 68

Figura 12 – Sincronização de dados entre JPPF e Servidor em Nuvem. ................................. 71

Figura 13 – Software sincronizador entre Central PEUP e servidor Web em Nuve. ............... 73

Figura 14 - Tela de Parâmetros ....................................................................................................... 74

Figura 15 - Tela de redefinição de parâmetros .............................................................................. 74

Figura 16 - Tela – Edição de checagens ........................................................................................ 75

Figura 17 - Tela – Edição de distância ............................................................................................ 75

Figura 18 - Tela – Edição sincronização ........................................................................................ 76

Figura 19 - Tela – Apresentação inicial .......................................................................................... 76

Figura 20 - Tela inicial do PEUP-M no Samsung Galax Tab II com Android ............................ 77

Figura 21 - Tela de visualização de Síntese do PEUP-M em um Samsung Galax Tab II ...... 77

Gráfico 1 - Teste de integridade e desempenho – Sucesso x Inconformidades e erros ........ 80

Gráfico 2 - Teste de integridade e desempenho – Tempo de sincronização ........................... 81

LISTA DE TABELAS

Tabela 1: Tabelas do servidor PEUP para manter prontuário do paciente............................... 50

Tabela 2: Tabelas do servidor PEUP para manter autenticidade dos dispositivos. ................ 51

Tabela 3: Web Services no servidor PEUP para consumo nos dispositivos. ........................... 58

Tabela 4 – Teste de sincronização entre dispositivos e servidores. .......................................... 78

Tabela 5 – Teste de integridade e desempenho na sincronização ............................................ 80

LISTA DE ABREVIATURAS E SIGLAS

ABRAMGE Associação Brasileira de Medicina em Grupo ADT Android Developer Tools AMB Associação Médica Brasileira ANS Agencia Nacional de Saúde Suplementar ANVISA Agência Nacional de Vigilância Sanitária APH Atendimento Pré-Hospitalar API Application Programming Interface CEO Chief Executive Officer (Chefe executivo de Ofício) CFM Conselho Federal de Medicina CFO Conselho Federal de Odontologia CNS Cartão Nacional de Saúde DATASUS Departamento de Informática do Sistema Único de Saúde (SUS) DM Dispositivo Móvel EHR Electronic Health Record - Registro Eletrônico de Saúde (RES) GPS Global Positioning System - Sistema de Posicionamento Global HL7 Health Level Seven HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure IDE Integrated Development Environment IMEI International Mobile Equipment Identity JPPF Java Parallel Processing Framework NHR National Health Service - Serviço Nacional de Saúde (SNS) OPS Operadoras de Planos de Saúde PEP Prontuário Eletrônico do Paciente PEPS Registro Eletrônico Pessoal de Saúde PEUP Prontuário Eletrônico Único do Paciente PIB Produto Interno Bruto PS Pronto Socorro PUP Prontuário Único do Paciente RES Registro Eletrônico de Saúde - Electronic Health Record (EHR) SAMU Serviço de Atendimento Móvel de Urgência SBIS Sociedade Brasileira de Informática em Saúde SDK Software Development Kit SNS Serviço Nacional de Saúde - National Health Service (NHR) SO Sistema Operacional SOA Service Oriented Architecture SOAP Simple Object Access Protocol SUS Sistema Único de Saúde TI Tecnologia da Informação TICS Tecnologia da Informação e Comunicação em Saúde TISS Troca de Informação de Saúde Suplementar

SUMÁRIO

1 INTRODUÇÃO ......................................................................................................... 13

1.1 OBJETIVOS ............................................................................................................. 15

1.2 ORGANIZAÇÃO DO TEXTO .................................................................................... 16

2 ESTADO DA ARTE .................................................................................................. 18

2.1 EVOLUÇÃO DOS REGISTROS MÉDICOS.............................................................. 18

2.2 A IMPORTÂNCIA DO REGISTRO ELETRÔNICO EM SAÚDE ................................ 20

2.2.1 Dificuldades Técnicas e Políticas na disseminação do RES ..................................... 24

2.3 O PEP E O RES NO BRASIL ................................................................................... 24

2.4 O RES NACIONAL COM PADRÕES INTERNACIONAIS ......................................... 26

2.4.1 O padrão HL7 e o OpenEHR .................................................................................... 27

2.4.2 O RES Nacional com o DATASUS ........................................................................... 29

2.5 A NECESSIDADE DE EVOLULÃO DO PUP ............................................................ 32

2.6 PEUP ....................................................................................................................... 34

2.7 EXEMPLOS DE PRONTUÁRIOS MÓVEIS .............................................................. 36

2.8 TECNOLOGIAS QUE PODEM SER INTEGRADOS AO PEUP-M ............................ 38

3 MATERIAIS E MÉTODOS ....................................................................................... 41

3.1 TECNOLOGIAS DE DESENVOLVIMENTO UTILIZADAS ........................................ 43

3.2 MÉTODOS ............................................................................................................... 45

3.3 PREMISSAS INICIAIS DO PEUP-M ......................................................................... 48

3.4 DETALHAMENTO DO MODELO – PEUP-M ............................................................ 49

3.4.1 Banco de dados do PEUP-M no DM ........................................................................ 49

3.4.2 Comunicação e sincronização entre dispositivos móveis e o PEUP ......................... 53

3.4.3 Disponibilização segura do prontuário no DM........................................................... 54

3.4.4 Segurança na disponibilização dos dados no DM .................................................... 57

3.5 SOFTWARE ............................................................................................................. 58

3.5.1 Prontuário no servidor .............................................................................................. 58

3.5.2 Descritivo das especificações ................................................................................... 59

3.5.3 Teste de consumo de Web Service no PEUP JPPF ................................................. 65

3.5.4 Criação de um Servidor Web doméstico para testes ................................................ 67

4 RESULTADOS ......................................................................................................... 70

4.1 PRONTUÁRIO NO SERVIDOR ................................................................................ 70

4.2 PRONTUÁRIO NO DISPOSITIVO MÓVEL .............................................................. 73

4.3 DISPONIBILIDADE DA SÍNTESE OFF-LINE ........................................................... 78

4.4 TESTES DE INTEGRIDADE E DESEMPENHO DE SINCRONIZAÇÃO ................... 79

5 CONCLUSÕES ........................................................................................................ 82

5.1 TRABALHOS FUTUROS.......................................................................................... 83

REFERÊNCIAS ................................................................................................................... 84

APÊNDICES ........................................................................................................................ 92

13

1 INTRODUÇÃO

Antes do surgimento da Tecnologia da Informação e Comunicação (TIC) o

suporte aos cuidados com a saúde era realizado em papel, onde era comum a

constatação de diagnósticos com inconformidades, muitas vezes por

indisponibilidade de informações anteriores, demora no acesso aos dados dos

pacientes e ainda a insuficiência de espaço para armazenamento de todas as

informações necessárias aos registros de saúde (ADESINA et al., 2011).

Ainda assim, mesmo com a tecnologia disponível é fácil constatar deficiências

no atendimento médico causadas pela falta de informações do paciente em tempo

real. A falta de informações, ou a sua imprecisão, ou a demora na sua obtenção

prejudica o atendimento médico ambulatorial ou de emergência. Afinal, em

determinados atendimentos, poucos minutos podem fazer a diferença em relação à

eficiência e ao resultado do atendimento (COSTA, 2012).

Com a aceitação da internet como ferramenta de trabalho para os

profissionais de cuidados com a saúde torna-se possível o acesso aos dados por

estes profissionais de forma dinâmica e compartilhada. Isso possibilita a realização

de serviços tais como: “relatórios clínicos de laboratório; informações de

compromisso com a saúde e relatórios de prevenção; informações de faturamento;

entre outros” (ADESINA et al., 2011).

Graças ao constante e crescente desenvolvimento tecnológico, tornou-se

possível aos centros de atendimento a saúde terem seus próprios sistemas

eletrônicos de registro de atendimento de seus pacientes, que são chamados de

Prontuário Eletrônico do Paciente (PEP) (MIAZAKI et al., 2011).

O PEP trouxe uma melhoria significativa para o atendimento à saúde (FRITZ,

2011) e como sistema de apoio a decisão (MARIN e WEBER, 2014), uma vez que o

registro dos atendimentos armazena informações que auxiliam no atendimento, no

acompanhamento e nos tratamentos do paciente. Dados que podem ainda servir de

base para os mais diversos estudos. Entretanto, o PEP está fragmentado entre

hospitais, clínicas, laboratórios e consultórios particulares, por onde o paciente foi

atendido. Azanha e Oliveira (2014) traz a seguinte indagação: como obter

informações em tempo real com PEPs tão fragmentados?

14

A falta da definição de um modelo de prontuário único acaba causando

problemas de inconsistências de dados entre as instituições, uma vez que cada

instituição de saúde acaba adaptando seus sistemas proprietários, tornando os

PEPs adequados às suas necessidades administrativas e não às necessidades dos

pacientes (AZANHA; OLIVEIRA, 2014, p. 24).

Para sanar estes problemas foi proposto um modelo de Prontuário Eletrônico

Único do Paciente (PEUP). O PEUP é uma proposta de solução para o problema de

fragmentação do PEP, que deve ser do paciente, com registros unificados de toda

sua vida, desde o pré-natal até sua morte (AZANHA; OLIVEIRA, 2014). Esse modelo

resolve o problema de fragmentação dos dados, que existe nos PEPs atuais,

definindo um banco de dados distribuído com as informações unificadas e com a

possibilidade de interação de todos os centros de saúde no compartilhamento de

informações.

Embora o modelo tenha trazido avanços na uniformização dos dados e na

sua distribuição, ainda fica uma lacuna em termos da disponibilidade dos dados e a

possibilidade de acesso em tempo real que seja adequada às novas tecnologias.

É notório o surgimento de tecnologias cada vez mais avançadas e propostas

de melhorias significativas como a do modelo PEUP. Ainda assim existem

dificuldades de acesso aos dados do paciente em atendimentos hospitalares e

principalmente, em atendimentos de emergência. O maior problema do PEUP neste

sentido é que ele depende de uma rede on-line para disponibilizar a informação

(AZANHA; OLIVEIRA, 2014).

Então, torna-se imprescindível a complementação do modelo para que

proporcione a disponibilidade imediata da informação. Pois há estudos que apontam

claramente problemas na agilidade do atendimento médico, principalmente em

atendimentos de emergência, em que muitas vezes o paciente não se encontra em

condições de responder a questionamentos necessários a um pré-atendimento. Por

exemplo, quando está fora de seu estado mental normal por problemas

psiquiátricos, doença, intoxicação, acidente, etc. (SOBANIA, 2015).

O contexto exposto nos leva a alguns questionamentos:

- O PEP é fragmentado e tem fortes restrições de acesso fora dos domínios

de quem o controla. Por outro lado o PEUP é concentrado e tem maior viabilidade

para disponibilização. Então por que não deixá-lo em poder do paciente?

15

- Como fazer para armazenar a parte essencial das informações do PEUP no

próprio dispositivo móvel (DM) do paciente, para que seja possível um acesso

rápido, principalmente em atendimentos de emergência, mesmo que o dispositivo

esteja off-line ou até mesmo parcialmente danificado?

- De que forma a Tecnologia Móvel pode auxiliar no atendimento ambulatorial

ou de emergência ou ambulatoriais?

- Como melhorar a disponibilidade através da redundância?

Para responder a estes questionamentos, é necessário que seja estabelecido

um modelo de síntese do PEUP que possa ser utilizado de forma eficaz, dando

agilidade em atendimentos de emergência. Este modelo pode utilizar os próprios

dispositivos móveis (como celulares e tablets) para o armazenamento de dados

essenciais na agilidade do atendimento.

A ideia do desenvolvimento de um modelo que possibilite atribuir agilidade no

atendimento e ajudar na melhoria da qualidade de vida das pessoas, é fator

essencial de motivação no desenvolvimento desse trabalho, que deve considerar

estudos já realizados de um modelo nacional com padrões internacionais, como o

HL7 (Health Level Seven) e o EHR (Electronic Health Record) (BRASIL, 2015).

Com as tecnologias de dispositivos móveis cada vez mais acessíveis a todas

as camadas sociais, que tal ter no dispositivo do paciente, os dados essenciais de

sua saúde que auxiliem em um imprevisto ou mesmo em um atendimento de rotina?

Além de manter uma síntese do PEUP no DM, informações de locomoção do

paciente obtidas pela tecnologia Global Positioning System (GPS)1, podem ser

enviadas a central PEUP, com o propósito de tornar possível o monitoramento de

pacientes com necessidade de atendimento de emergência por programas de Home

Care.

1.1 OBJETIVOS

O objetivo deste trabalho é desenvolver um modelo que possibilite a

disponibilização da parte essencial, a síntese, do PEUP em DM. O modelo deve

1 GPS = Global Positioning System (Sistema de Posicionamento Global).

16

prever que o acesso poderá ser realizado tanto pelo paciente quanto pelos

profissionais de saúde, em atendimentos de rotina, de urgência ou emergência.

Para atingir este objetivo será proposto o um modelo de comunicação e de

armazenamento que garanta o controle do acesso e a integridade dos dados. O

modelo de armazenamento deve garantir também que os dados contidos no DM

sejam acessados de forma integra em computadores pessoais.

Como objetivo específico é necessário desenvolver um aplicativo para avaliar

o modelo sugerido, que permita a sincronização com o PEUP e a manutenção da

síntese.

O aplicativo passa a ser chamado de PEUP-M e deve ser desenvolvido com

as seguintes funcionalidades:

Sincronizar dados armazenados no dispositivo com a central PEUP

periodicamente.

Receber aviso da central, toda vez que alguma informação for atualizada

em seu prontuário.

Manter a central PEUP atualizada em relação à localização geográfica do

paciente.

Permitir acesso à síntese do paciente mesmo com a troca do chip de

dispositivo.

1.2 ORGANIZAÇÃO DO TEXTO

Esta dissertação está organizada em cinco capítulos, sendo que neste

capitulo são apresentados à contextualização do problema, as justificativas e os

objetivos da pesquisa.

No capítulo 2 foi apresentado o estado da arte em prontuários eletrônicos de

saúde e registros médicos. Também consta o estado atual dos recursos móveis

aplicados aos prontuários eletrônicos.

No capítulo 3 são apresentadas as tecnologias, os matérias e métodos

adotados no desenvolvimento da pesquisa.

O capítulo 4 traz os resultados obtidos com o desenvolvimento do método e

as discussões relativas os demais trabalhos encontrados na literatura.

17

Por fim, o capítulo 5 traz a discussão final e apresenta os resultados obtidos

através dos testes realizados.

18

2 ESTADO DA ARTE

2.1 EVOLUÇÃO DOS REGISTROS MÉDICOS

O mundo está presenciando uma grande mudança de paradigmas em relação

aos registros médicos dos paclientes e na responsabilidade sobre a gestão desses

registros. Através do Registro Eletrônico de Saúdo (RES), que é “uma forma de

organização dos sistemas de informática das instituições”, obtêm-se dados de

pacientes tais como: “informações multiprofissionais sistematizadas a respeito dos

problemas de saúde, exames, diagnósticos, tratamentos e evolução clínica” de

forma individualizada, dando origem ao PEP (VIVANCO e MARIN, 2014; MIAZAKI et

al., 2011).

Segundo Costa (2012), o PEP é a principal ferramenta de Tecnologia da

Informação e Comunicação em Saúde (TICS) que o médico precisa ou precisará

lidar nas suas atividades diárias, seja no consultório, centro diagnóstico ou hospital.

O RES trata do armazenamento e do compartilhamento seguro das informações de

um paciente.

Diante da constante evolução tecnológica, muitas são as possibilidades que

vislumbramos diante de nossos olhos, principalmente em relação à melhoria da

qualidade de vida das pessoas. Afinal, a tecnologia só se justifica se for para auxiliar

as pessoas a terem melhor qualidade de vida (COSTA, 2012; FRITZ, 2011).

Segundo Gillum (2013), as primeiras evidências de transformação nos

registros clínicos ocorreram no início do século XIX, quando os casos clínicos

passaram a ser escritos para fins didáticos. Esses registros ajudaram os médicos a

fazerem pesquisas e a melhorar o atendimento de pacientes. No NewYork-

Presbyterian Hospital2, Hospital universitário de Nova York, os médicos começaram

a manter registros permanentes de pacientes ainda antes, desde o início de 1800

(SIEGLER, 2010).

Em seu trabalho, Siegler (2010) relata que os registros dos casos de

pacientes eram inicialmente realizados de forma livre, sendo influenciados pela

personalidade dos médicos que os faziam. No final do século XIX, a imposição de

uma estrutura de tabela fixa para registro através do uso de fórmulas reduziu

2 Fundado em 1971, chamado apenas de New York Hospital e em 1998 passou a se chamar NewYork-

Presbyterian Hospital. Mais informações: http://nyp.org/about/history.html.

19

drasticamente o volume dos registros de casos reais. Foram necessárias mudanças

no formato de registro para que fosse possível gerenciar o crescente volume de

dados. Veja na Figura 1, um exemplo de registro estruturado em tabela desta época:

Figura 1 - Relatório anual da Sociedade do Hospital “New York Hospital” de 1797.

Fonte: Siegler, 2010, p. 229.

20

O registro dos atendimentos médicos foi evoluindo de forma a necessitar de

regulamentação para definir os direitos e deveres sobre o armazenamento e acesso

aos prontuários. A Resolução CFM nº 1331/89 considera o prontuário um “conjunto

de documentos padronizados e ordenados, destinados ao registro dos cuidados

profissionais prestados ao paciente pelos Serviços de Saúde Pública ou Privado”.

O prontuário é um elemento valioso para o paciente, para os profissionais da

saúde e também ao ensino e pesquisa. Ele deve servir como base de dados

arquivada onde se afere informações das assistências médicas prestadas, dentro

dos conceitos da Ética Médica.

Em Sessão Plenária de 04/08/1989 foi aprovado que o prontuário médico é de

responsabilidade dos estabelecimentos de saúde e deve ficar à disposição para

aferições pelo prazo de até 10 anos, sendo que após esse período os dados podem

ser arquivados de forma a serem restaurados plenamente se necessário (BRASIL,

1989).

Através da Resolução CFM nº 1.639/2002 foi definido consórcio entre o

Conselho Federal de Medicina (CFM) e Sociedade Brasileira de Informática em

Saúde (SBIS) para regulamentar e certificar os sistemas “para guarda e manuseio

de prontuários eletrônicos que estejam de acordo com as normas técnicas

especificadas no anexo a esta resolução.”. Estas normas tratam especificamente de:

- Integridade da Informação e Qualidade do Serviço; Cópia de Segurança; Bancos

de Dados; Privacidade e Confidencialidade; Autenticação; Auditoria; Transmissão de

Dados; Certificação do software; e Digitalização de prontuários (BRASIL, 2002).

Dado a necessidade da inserção de exames, imagens ou outros meios

digitais, esse volume tornou-se cada vez maior, sendo necessário que as

informações fossem reestruturadas.

2.2 A IMPORTÂNCIA DO REGISTRO ELETRÔNICO EM SAÚDE

Após regulamentação através da Resolução nº 1821/2007 que define as

“Normas Técnicas Concernentes à Digitalização e Uso dos Sistemas Informatizados

para a Guarda e Manuseio dos Documentos dos Prontuários dos Pacientes,

Autorizando a Eliminação do Papel e a Troca de Informação Identificada em Saúde”

21

a SBIS define Manual de Certificação para Sistemas de Registro Eletrônico em

Saúde (S-RES) e Manual de Requisitos de Segurança (SBIS, 2015, p.8).

Era necessário que estes dados estivessem armazenados de forma segura e

com fácil acesso, pois havia necessidade de acessá-los, obviamente por pessoas

devidamente autorizadas (SBIS, 2015, p.8).

O RES tem por finalidade controlar todo armazenamento de dados dos

pacientes de forma eletrônica, segura, integra e com alta disponibilidade.

Obedecendo-se estes critérios, têm-se registros eletrônicos confiáveis que podem vir

a ser utilizados como base para acompanhamento dos PEPs dos pacientes ou para

as pesquisas médicas ou epidemiológicas.

Para melhor elucidar sobre a grande importância na utilização do RES, são

apresentados alguns exemplos:

Com o registro realizado em PEPs, torna-se possível a realização de

pesquisas exploratórias temporal como a realizada por Joia (2009), que identificou a

inovação, a eficácia e a segurança sobre determinados medicamentos,

considerando-se um período de registros nos PEPs.

Outro estudo relevante foi o estudo exploratório realizado nos Estados Unidos

por Zwicker (2010) que identificou alguns fatores que contribuem para a adoção de

Inovações Tecnológicas, com o uso de um sistema de PEP em um Pronto Socorro

(PS) e um sistema de apoio ao ensino pela Web em uma Faculdade de Medicina.

O estudo identificou grupos de profissionais agindo no sentido de usar o novo

sistema. Identificou também que há aqueles que rejeitam o novo desafio por ter que

dedicar parte do seu tempo no registro dos atendimentos em sistemas de

computador. No entanto, observou-se que o principal fato que determinou a

preparação para a mudança para que os profissionais passassem a adotar o

sistema, foram os canais utilizados para difusão e preparação dos envolvidos no

processo. É de suma importância que os profissionais envolvidos na implantação de

um novo sistema, tenham plena consciência da importância do registro correto no

PEP (ZWICKER, 2010).

Shih et al. (2011) realizou pesquisa no sentido de reduzir a morbidade e

mortalidade de adultos, através de serviços clínicos preventivos, apoiados no estudo

de registros específico, que foram possíveis com a implementação do RES. As

coletas foram feitas em 2009 e 2010, com análises realizadas em 2010 e 2011. O

resultado foi o melhor controle e o direcionamento de ações práticas sobre

22

pacientes, que apresentavam necessidades de cuidados preventivos em relação à

hipertensão arterial, diabetes e câncer de mama. Isso significa melhor qualidade de

vida às pessoas, possibilitado por ações específicas de médicos e gestores da área

da saúde, com o apoio da Tecnologia da Informação (TI) através do RES eficiente.

Um estudo de caso de prontuário na China proposto pela empresa Intel®3,

demonstra uma forma de implantar uma rede de “hospitais digitais", utilizando

sistemas de informação em rede e tecnologias avançadas para a utilização dos

hospitais e outras áreas de cuidados à saúde que são relevantes a níveis nacionais

e regionais, destacando ainda que os PACS (Picture Archiving and Communication

Systems ou Arquivamento de Imagens e Sistemas de Comunicação) são um

componente crítico desse modelo, por ter “altas exigências de capacidade de

armazenamento, desempenho, escalabilidade e confiabilidade.” (INTEL, 2015).

Como solução, a empresa Intel® propõe um conjunto de produtos e

infraestrutura, buscando suprir todas as necessidades de um armazenamento

unificado de alta capacidade com desempenho otimizado e baixo consumo de

energia, que visa atender às necessidades de um sistema de informações unificado

entre os hospitais do país, agilizando os registros médicos e possibilitando facilitar

também os processos de negócios.

Intel® (2015) declara que o sistema deve apresentar principalmente os

seguintes benefícios:

Apoiar atividades clínicas e de gestão hospitalar, científica e fornecer dados precisos e adequados. Aumentar a eficiência, melhorar a gestão e uso da informação do hospital. Integrar os recursos e a aplicação colaborativa de informações e dos processos em todos os elos da cadeia de serviços médicos. Apoiar os extensos e complexos aplicativos de software utilizados no hospital digital. Aperfeiçoar a infraestrutura de sistemas de informação.

A evolução dos registros médicos se deu com o tempo, à medida que esses

registros foram se tornando úteis e necessários no auxílio aos cuidados com a

saúde dos pacientes e pesquisas científicas.

A estruturação dos registros ainda em papel e sua reestruturação para

armazenamento e controle através de meio eletrônico, com o apoio de resoluções e

instituições legitimamente definidas, contribuiu para que se chegasse a um nível de

3 Nota de direitos autorais do original: Copyright © 2013 Intel Corporation. All rights reserved. Intel, the Intel

logo, Xeon, and Xeon Inside are trademarks of Intel Corporation in the U.S. and other countries. * Other names and brands may be claimed as the property of others. Printed in USA 0413/YMB/VF/PDF Please Recycle

23

maturidade importante em relação ao registro e controle das informações de saúde

das pessoas.

No entanto muitos esforços ainda são necessários para se atingir um nível

satisfatório para um sistema nacional de cuidados com a saúde da população

brasileira. Sendo que um dos problemas identificado que evidencia prioridade está

relacionado à disponibilidade das informações (AZANHA; OLIVEIRA, 2014).

Somente há poucos anos o setor político começa a ver o RES como uma

necessidade. Quer seja pelo poder de centralização de informações geográficas e

do estado de saúde da população, ou impulsionados por pressões internacionais.

Até porque, com a globalização, os fatos ocorridos em um país ultrapassam

fronteiras. O grau de desenvolvimento tecnológico de um país e sua capacidade de

utilização desses recursos serve como medida que define o nível de

desenvolvimento dos pais (UNIFESP, 2011).

De acordo com Takian et al. (2012), muitos governos passam a ver o RES

como uma parte estratégica essencial para reforma da saúde. Passaram a pensar

em recursos viáveis e inclusive a estipular prazos para sua implementação, uma vez

que há muitos seguimentos interessados. Isso torna interessante pensar na melhoria

da saúde da população e ainda gerar benefícios econômicos, tanto aos cofres

públicos, como às outras partes envolvidas. O que antes era uma dificuldade

transforma-se em necessidade e já demonstra resultados positivos em muitos

exemplos espalhados pelo mundo.

Um exemplo de sucesso da adoção do RES está sendo realizado na

Inglaterra através de um projeto que visa “o ser humano em primeiro lugar”. Trata-se

do Serviço Nacional de Saúde (SNS) da Inglaterra, o “NHS England” 4, um projeto

que objetiva melhorar os resultados de saúde para as pessoas na Inglaterra (NHS

ENGLAND, 2014).

A ambição central do projeto é colocar o público e os pacientes no centro das

atenções. Com base em evidências e transparência nas decisões, na maneira de

operar e nos impactos resultantes. Com isso, se coloca os interesses dos pacientes

em primeiro lugar, tratando-os com respeito e atenção.

O NHS capacita e apoia líderes clínicos e ajuda prestadores de serviços com

informações confiáveis, o que proporciona serviço de qualidade, justificando os

4 NHS = National Health Service (ou, Serviço Nacional de Saúde). No Reino Unido, principalmente Inglaterra.

24

gastos patrocinados pelos contribuintes. O NHS ainda envolve sua equipe de

profissionais, compartilhando ideias e conhecimentos, sucessos e fracassos, de

forma colaborativa, com objetivo de oferecer sempre o melhor serviço ao paciente,

não só na Inglaterra, mas no mundo.

2.2.1 Dificuldades Técnicas e Políticas na disseminação do RES

Há alguns anos a implementação do RES no setor público era apenas uma

previsão. Para alguns, até um sonho. Pois, não havia uma visão política que

evidenciasse sua real necessidade, com ganho na saúde pública e,

consequentemente, na economia de recursos públicos da saúde (LOBACH, 2007).

Há aproximadamente oito anos, Lobach et al. (2007) previu um aumento significativo

quanto à disponibilidade e uso do RES nos próximos dez anos. Apesar de

conhecidos os benefícios vitais que o RES poderia proporcionar, há questões

metodológicas críticas a serem avaliadas e também questões políticas que afetavam

diretamente a capacidade de produção dos pesquisadores e dos profissionais de

saúde.

Dois anos mais tarde, em pesquisa realizada entre fevereiro de 2009 e

novembro de 2010, Cresswell et al. (2012) identificaram que os hospitais de

diferentes regiões (Urbanas e Rurais) da Inglaterra enfrentavam problemas técnicos

e políticos na implementação de software de RES. Necessitavam de investimentos

tecnológicos e de treinamento dos usuários para que conseguissem se adaptar às

mudanças complexas. Dessa forma, o RES efetivamente passaria a ser

implementado e utilizado de forma eficaz na melhoria da qualidade de vida da

população e na melhor eficiência do serviço de saúde.

2.3 O PEP E O RES NO BRASIL

No Brasil, implantou-se há alguns anos o Sistema Único de Saúde (SUS).

Com ele, foi implantado também o Departamento de Informática do SUS

25

(DATASUS) (BRASIL, 2015). A regulamentação mais significativa neste sentido veio

através da portaria nº 2.073 de 31 de agosto de 2011, que considera:

[...] As condições para a promoção, proteção e recuperação da saúde, a organização e o funcionamento dos serviços correspondentes; [...] a política nacional de arquivos públicos e privados, [...] a Lei que redefine o Comitê [...] cuja atribuição é emitir deliberações, normas e padrões técnicos de interoperabilidade e intercâmbio de informações em conformidade com a política de informação e informática em saúde; [...] melhoria e a modernização do seu sistema de gerenciamento de informações; [...] permitir o intercâmbio das informações e a agilização dos procedimentos [...] efetivo e eficiente sistema de registro das ações e eventos de saúde contribui para o gerenciamento do Sistema Único de Saúde (SUS), garantindo ao cidadão o registro dos dados relativos à atenção à saúde, que lhe é garantida, num sistema informatizado; [...] a organização de uma rede de serviços regionalizada e hierarquizada para a gestão do SUS; [...] a necessidade de garantir ao cidadão o registro dos dados relativos à atenção à saúde; [...] a consolidação da implantação do Cartão Nacional de Saúde (CNS) (BRASIL, 2015).

Outra regulamentação é o decreto 7.508 e as portarias nº 399/GM/MS, de 22

de fevereiro de 2006 e nº 2.072/GM/MS, de 31 de agosto de 2011, que resolveram

regulamentar:

[...] o uso de padrões de informação em saúde e de interoperabilidade entre os sistemas de informação do SUS, nos níveis Municipal, Distrital, Estadual e Federal, e para os sistemas privados e de saúde suplementar; [...] os padrões de informação em saúde e de interoperabilidade; [...] fundamentar arquitetura de informação nacional, independente de plataforma tecnológica de software ou hardware; [...] estruturar as informações referentes aos atendimentos prestados aos usuários do SUS visando à implementação de um Registro Eletrônico de Saúde (RES) nacional e longitudinal; [...] definir o conjunto de mensagens e serviços a serem utilizados na comunicação entre os sistemas de informação em saúde; [...] padrões de interoperabilidade de que trata esta Portaria deverão utilizar mensagens formatadas em padrão eXtensible Markup Language (XML) para troca de informações, de forma a atender aos XML schemas definidos pelo Ministério da Saúde e respectivas definições dos respectivos serviços - Web Service Definition Language (WSDL), quando for o caso; (BRASIL, 2015).

É importante destacar a questão dos custos e responsabilidades dos mesmos

nos âmbitos Federal, Estadual e Municipal. Esta portaria define que os recursos

financeiros necessários à efetivação do projeto ficam por conta do Ministério da

Saúde. No entanto:

Os custos relacionados à adequação de sistemas de informação para uso dos padrões de interoperabilidade e informação em saúde serão de responsabilidade dos proprietários dos respectivos sistemas; [...] Os Estados, o Distrito Federal e os Municípios arcarão

26

com todas as despesas para adequação de seus sistemas próprios; [...] O Ministério da Saúde arcará com as despesas para adequação de seus sistemas de informação; (BRASIL, 2015).

A portaria regulamenta também as principais tecnologias e modelos a serem

utilizados para interoperabilidade dos sistemas:

[...] Para a interoperabilidade entre os sistemas dos SUS será utilizada a tecnologia Web Service, no padrão SOAP 1.1 (Simple Object Access Protocol) ou superior; [...] Para a definição do Registro Eletrônico em Saúde (RES) será utilizado o modelo de referência OpenEHR; [...] Para estabelecer a interoperabilidade entre sistemas, com vistas à integração dos resultados e solicitações de exames, será utilizado o padrão HL7; [...] Para a definição da arquitetura do documento clínico será utilizado o padrão HL7 CDA; [...] Para a codificação de exames laboratoriais será utilizado o padrão LOINC (Logical Observation Identifiers Names and Codes); [...] Outras classificações que serão utilizadas para suporte à interoperabilidade dos sistemas de saúde: CID, CIAP-2 (Atenção primária de saúde), TUSS e CBHPM (Classificação brasileira hierarquizada de procedimentos médicos) e tabela de procedimentos do SUS (BRASIL, 2015).

Embora todos os itens dessa portaria sejam fundamentais e imprescindíveis

para amparar o desenvolvimento de sistemas de registro e controle da Saúde no

país, vale destacar aqui que o desenvolvimento de sistemas se baseia em padrões

internacionais consolidados.

2.4 O RES NACIONAL COM PADRÕES INTERNACIONAIS

O RES é semelhante ao acrônimo utilizado em Inglês: EHR (Electronic Health

Record). E, conforme norma ASTM E1769 apud Linden 2009, EHR é definido como

"um conjunto abrangente de estrutura de dados e de informações em formato

eletrônico, com dados clínicos, demográficos, ambientais, sociais e financeiros, que

documentam os cuidados com a saúde de um único indivíduo" (LINDEN, 2009,

p.11).

Conforme definido pela ISO/TR 20514:2005, o EHR (ou RES) é um

repositório de informações genérico sobre o cuidado do estado de saúde de um

paciente na forma processável armazenado em computador, transmitido de forma

segura e acessível por vários usuários autorizados. Ele tem um modelo de

informação lógico normalizado de comum acordo que é independente dos sistemas

EHR. Seu principal objetivo é o apoio ao registro de cuidados da saúde de forma

27

eficiente e de qualidade, contínua e integrada, com informações retrospectivas,

simultânea e potencial (LINDEN, 2009, p.11; ISO, 2005).

Conforme demonstrado pela ISO, o termo EHR deve ser utilizado para se

referir ao repositório de informações que compõe um prontuário. Utilizado

genericamente como uma arquitetura de sistemas que suporte e gerencie o

repositório.

Segundo Blumenthal (2010), o uso generalizado de EHRs nos Estados

Unidos é inevitável à medida que melhora o apoio às tomadas de decisões dos

profissionais da Saúde e que é adotado pelos próprios pacientes após terem

experimentado os benefícios dessa tecnologia. Embora seja inevitável, a transição

não é tão fácil. Pois, grandes clínicas ainda têm dificuldades na integração com

clínicas menores, que cuidam da saúde da maioria dos americanos.

Em 2010, o governo dos Estados Unidos lançava um regulamento com regras

de incentivo ao uso do EHR para 2011 e 2012, assim como também estabeleceu

regras para o processo de certificação dos EHR, que promove especial atenção à

questão da segurança dos dados e à coerência com a legislação do país

(BLUMENTHAL, 2010).

O HL7, principal padrão internacional vem sendo debatido há pelo menos

duas décadas e na última década tem sido implementado em diversos territórios

internacionais, inclusive no Brasil.

2.4.1 O padrão HL75 e o OpenEHR

O que é HL7?

Fundada em 1987, Health Level Seven (HL7) é uma norma credenciada da American National Standards Institute (ANSI), organização de padrões para o desenvolvimento sem fins lucrativos, cuja missão é estabelecer normas para o intercâmbio, a integração, compartilhamento e recuperação de informações eletrônicas de saúde; apoio à prática clínica; e apoio à gestão, execução e avaliação dos serviços de saúde. [...] (ANSI, 2007, tradução nossa).

Em comum acordo entre o HL7 e ANSI, qualquer norma publicada pelo HL7

serão...

5 Documentos que descrevem o HL7 e EHR pela ANSI disponível para download em:

http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2fHL7+EHR+FM+R1-2007

28

[...] submetidos a ANSI para aprovação, será elaborado e ratificado por um processo que adere aos procedimentos da ANSI para consenso aberto para encontrar um equilíbrio de exigência de juros por atingir perto de uma participação igual no processo de votação pelos diversos círculos eleitorais que são materialmente afetadas pela norma (por exemplo, vendedores, fornecedores, órgãos governamentais, consultores, organizações sem fins lucrativos) (ANSI, 2007, tradução nossa).

Segundo Linden (2015, p.23) em 2001, a fundação openEHR foi criada para

trabalhar na consolidação e na implementação do conhecimento adquirido nos

projetos GEHR, Synapses/Synex e GeHR, através do conceito de arquétipos,

denominado Clinical Document Architecture (CDA). Isso é uma maneira de trocar

informações sob a forma de documentos clínicos. Esta fundação foi criada por um

grupo com interesse especial no HL7 que “estabeleceu um grupo de trabalho em

Registros Eletrônicos em Saúde (EHR-SIG)” (SBIS, 2015, p.12).

O HL7 está sendo implementado em sua versão 3, edição normativa 2015 no

Reino Unido, Canadá, Holanda, México, Alemanha e Croácia, com a pretensão de

atender às necessidades locais do Serviço Nacional de Saúde do Reino Unido; NHS

(UK National Health Service), mas com objetivos mais amplos, projetados para

aplicação universal com impacto mundial (HL7, 2015).

O HL7 inclui uma ampla variação de configurações de saúde com padrões

internacionais de comunicação e gerenciamento dos dados dos pacientes.

Em fevereiro de 2007 foi criado o INSTITUTO HL7 BRASIL para dar apoio

administrativo e jurídico às atividades do HL7 no país, além de "promover e prover

padrões relacionados com a troca, integração, compartilhamento e recuperação de

informação eletrônica, para apoio da prática médica e administrativa, permitindo um

maior controle dos serviços de saúde" (SBIS, 2015, p.12).

O manual de certificação 2013 da SBIS define alguns requisitos fundamentais

ao desenvolvimento de sistemas de integração ao EHR. Os requisitos de estrutura e

conteúdos relevantes para certificação são: a) a utilização da arquitetura de

documentos com base nos modelos de referência HL7/CDA, ASTM/CCR; b) os

serviços de terminologia devem utilizar os modelos HL7 e CTS; c) devem ser

utilizados os modelos UMLS ou SNOMED-CT para criação dos serviços de sistemas

responsáveis pela comunicação e troca de dados; d) a importação ou exportação

dos dados devem utilizar os protocolos HL7 e DICOM; e) o padrão DICOM é

29

utilizado para troca de arquivos de imagem.6; e a estrutura de dados clínicos e

arquétipo de pressão arterial estruturado devem seguir os padrões da openEHR”

(SBIS, 2015, p. -74-75).

As descrições dos procedimentos clínicos devem obedecer o padrão LOINC.

Mesmo quando a informação for traduzida para o português Brasil, deve preservar o

texto original (SBIS, 2015, p. 78).

O padrão HL7 pode ter implantação parcial e gradativa, com a utilização de

esquemas XML, o que torna o trabalho mais flexível e possível (SLAVOV et al.,

2013). O HL7 é um padrão internacional consolidado utilizado como base para os

padrões adotados pelo sistema de saúde brasileiro.

2.4.2 O RES Nacional com o DATASUS

O DATASUS é, no entanto, o responsável pelo desenvolvimento do RES

Nacional, que através de documento publicado na Internet por seu Diretor, Gadelha

(2012), assim define a estrutura do RES Nacional:

o DATASUS mantém diversos datacenters espalhados em regionais pelo

país, interligando uma rede em nuvem do RES Nacional;

o PEP acessa e se integra ao RES através da internet;

o Registro Eletrônico Pessoal de Saúde (PEPS) também se integra ao

RES pela internet.

Através desse sistema e da implantação do Cartão Nacional de Saúde (CNS),

se possibilita manter diversos serviços, tais como:

CADSUS: Sistema de Cadastramento de usuários do SUS

O CADSUS “permite a geração do Cartão Nacional de Saúde, que facilita

a gestão do Sistema Único de Saúde”, contribuindo para melhor eficiência

do “atendimento direto ao usuário” (CADSUS, 2014).

CNES: Cadastro Nacional de Estabelecimentos de Saúde

6 Para melhor entendimento, visite os sites do HL7: http://www.hl7.org e EHR: http://www.hl7.org/EHR

30

O “CNES visa ser a base para operacionalizar os Sistemas de

Informações em Saúde, sendo estes imprescindíveis a um gerenciamento

eficaz e eficiente do SUS.” (CNES, 2014).

Farmácia Popular

Programa criado no Brasil em junho de 2004 e integrado através do CNS

ao RES nacional em maio de 2013, que tem por objetivo oferecer

medicamentos com até “90% menores dos que são cobrados nos

estabelecimentos privados não cadastrados.” (DATASUS, 2014a).

Hórus

Um sistema com implementação de BI (inteligência de negócio),

licenciado pela plataforma Microstrategy para o DATASUS, capaz de

“gerar relatórios analíticos e fazer outras investigações com base nos

dados do Sistema Nacional de Gestão da Assistência Farmacêutica”

(DATASUS, 2014b).

SISREG

É um “Sistema on-line, criado para o gerenciamento de todo complexo

regulatório indo da rede básica à internação hospitalar.” (SISREG, 2014).

SAMU

Sistema para “captura de dados captura de dados do SAMU (Serviço de

Atendimento Móvel de Urgência)”. Para integração e registro de

procedimentos “realizados nos atendimentos de urgência e que deverão

ser incorporados nos boletins de produção gerenciados pela central de

regulação.” (DATASUS, 2014c).

SISRCA

É um “Sistema de Regulação, Controle e Avaliação (SISRCA).” Que

processa informações referentes à “gestão da informação, com

programação ambulatorial e hospitalar e controle e avaliação dos dados.”,

através de dados fornecidos pelos gestores da área da saúde, visando a

“unificação das funcionalidades existentes nos atuais sistemas de

processamento e agrega novas funções que priorizam a qualidade da

informação e a responsabilidade do gestor” (BRASIL, 2015).

31

Em seminário realizado em São Paulo na Universidade Corporativa

ABRAMGE7, a Dra. Pellegrini (2014) discute sobre a implantação do novo padrão

para a Troca de Informação de Saúde Suplementar (TISS) 3.01, que deveria entrar

em operação em 31/05/2014, sendo adiada para 31/08/2014, dando origem a versão

3.02 com novos ajustes (ANS, 2015b; p.22).

A primeira versão do padrão TISS obrigatório foi implantando em 2007 (ANS,

2015a). Esse padrão determina como deve ser “a interoperabilidade entre os

sistemas de informação em saúde preconizados pela Agência Nacional de Saúde

Suplementar (ANS) e pelo Ministério da Saúde (MS)” (ANS, 2015b). A ANS exige

prestação de contas das Operadoras de Planos de Saúde (OPS) que interage com

seus beneficiários (pacientes) e prestadores (contratante individual, por adesão ou

empresarial). Algumas entidades de referências são destinadas a validar sugestões

de alterações no Padrão TISS no intuito de resolver dúvidas técnicas, sendo elas:

Associação Médica Brasileira (AMB); Conselho Federal de Odontologia (CFO);

Agência Nacional de Vigilância Sanitária (ANVISA); Confederação Nacional de

Saúde e a SBIS (ANS, 2015b, p.50).

Com o início da implantação do Padrão TISS ocorrida há aproximadamente

sete anos, constataram-se diversas dificuldades. Dentre elas, vale destacar que o

sistema ainda não contempla o desejo de se ter indicadores regionalizados

confiáveis para a ANS, uma vez que com o passar dos anos foram criadas

codificações distintas para procedimentos similares. Pellegrini (2014) se diz

esperançosa no sentido de que esse problema seja minimizado o bastante para não

influenciar negativamente os números apontados nos indicadores a partir dessa

nova versão (3.02).

Embora o padrão TISS ainda mantenha seu foco na troca de informações

entre as instituições de saúde, gerando apenas indicadores genéricos à ANS,

Pellegrini (2014) ressalta a importância de ter o controle das informações referente a

cada tipo de procedimento realizado, tanto para trazer maior realidade financeira às

instituições como para ter um mapeamento do que acontece em termos de saúde da

população. E esse tipo de informação é fundamental tanto para as OPS quanto para

o governo, uma vez que com essas informações pode-se tomar medidas preventivas

no sentido de evitar que determinados problemas de saúde aconteçam.

7 ASSOCIAÇÃO BRASILEIRA DE MEDICINA DE GRUPO (ABRAMGE):

http://www.atendimentoabramge.com.br/operadoras-planos-saude.html#1

32

As OPS têm adotado de forma cada vez mais frequente, programas de

medicina preventiva e o cuidado em domicílio (o chamado Home Care), que traz

benefícios financeiros às OPS e o conforto do tratamento de seus pacientes em seu

próprio lar.

A ANS aponta para possibilidade das próprias OPS auxiliarem na composição

do PEP (Pellegrini, 2014; ANS, 2015c). O que tecnicamente não é difícil de

acontecer, uma vez que grande parte do que deve ser registrado nos PEPs está

contida neste relacionamento controlado pelas OPS, que consiste em todos os

documentos de guias de consultas, guias SP/SADT, guia de internação e resumo de

internação e tratamento odontológico (ANS, 2015b), onde todos os procedimentos

realizados são compartilhados.

Segundo Costa (2012, p.4), o Brasil dispõe do CFM e SBIS para "estabelecer

as normas, padrões e regulamentos para o PEP/RES".

Esse convênio propiciou a criação de um processo de Certificação de Sistemas de Registro Eletrônico de Saúde, com o estabelecimento dos requisitos obrigatórios e, acompanhando a legislação federal para documento eletrônico, reforçou a obrigatoriedade do uso de certificação digital (assinatura eletrônica) para a validade ética e jurídica de um PEP/RES. Um marco regulatório importante foi a publicação da Resolução CFM Nº 1821/2007 (COSTA, 2012, p.4).

2.5 A NECESSIDADE DE EVOLULÃO DO PUP

O Prontuário Único do Paciente (PUP) é uma tentativa de unificar as

informações relativas aos cuidados com a saúde dos pacientes. Um exemplo desse

modelo foi implantado nas cidades de Florianópolis, Belo Horizonte e Curitiba e

apresenta dificuldades na implantação, principalmente em relação ao trânsito das

informações e resistência de implantação da rede pública e privada vinculada à rede

municipal (HARZHEIM, 2011, p.72).

Um exemplo que vale ser citado inclusive fora do País é o HelloHealth

(2014a) desenvolvido no México. Trata-se de uma solução de negócios

desenvolvida por profissionais da área da saúde, visando ganhos aos médicos por

seus esforços extras no atendimento ou acompanhamento médico aos seus

pacientes.

33

O projeto HelloHealth (2014b) é de propriedade da empresa Myca Health Inc.

e se compõe através de sistemas distribuídos em nuvem na internet para o

armazenamento dos prontuários e telefones celulares para possibilitar a

comunicação eficiente, confortável e conveniente entre os médicos e seus

pacientes. Para ter acesso aos serviços prestados pelo HelloHealth (2014c), cada

paciente tem um custo mínimo mensal de $75.00 (pesos mexicanos, cerca de R$

13,008).

O HelloHealth (2014d) aposta em um melhor relacionamento com os

pacientes que podem entrar em contato com os médicos e acessar às atualizações

realizadas em seus prontuários através de um portal que oferece serviços com

funcionalidades para: agendamentos; resultados de exames laboratoriais; acesso

anotações de consultas; troca de mensagens com médicos; contato via vídeo chat;

acesso aos registros médicos através da Web e iPhone.

No Brasil, um dos maiores problemas para a implantação do sistema de PUP

acaba sendo o custo, e principalmente a necessidade de comunicação com a

internet. Isso o torna inviável até mesmo em regiões próximas aos grandes centros,

se pensarmos em termos do enorme território Brasileiro. Além disso, há a

necessidade de vencer as resistências de integração entre os sistemas públicos

nacional, privados e municipais (HARZHEIM, 2011, p.72).

Conforme a Telebrasil (2009), o Brasil finalmente estabelece mudanças

evolutivas. O que significa que, embora a infraestrutura atual não atenda as novas

demandas, tanto em relação à quantidade de novos usuários, como os novos

serviços oferecidos, não há como ignorar todo investimento já realizado, tendo-se

que agregar novas tecnologias às existentes de maneira a se integrarem de forma

harmoniosa.

Para compatibilizar as novas tecnologias, integra-se serviços tais como o já

conhecido Service Oriented Architecture (SOA) que significa arquitetura orientada a

serviço, onde elementos de softwares são programados para fazer a integração

entre sistemas de diferentes fornecedores e diferentes arquiteturas de

hardware/software.

Lobo (2014) afirma que as conexões das coisas estão mais necessárias a

cada dia. Afirma também que Jon Baksaas, presidente e Chefe Executivo (CEO,

8 Conversão realizada pelos sites http://economia.terra.com.br/herramientas/calculadoras/conversor.aspx e

http://pt.exchange-rates.org/converter/MXN/BRL/75

34

Chief Executive Officer) do grupo Telenor, acredita que em breve as conexões terão

importância equivalente a da eletricidade, já que segundo a GSMA (2014), que é

representante das operadoras de telefonia móvel de todo mundo, apresentou em

2013, contribuição da mobilidade para o Produto Interno Bruto (PIB) mundial de

3,6%. Numa expectativa de que passará de 200 milhões para 2,5 bilhões de

conexões 4G no mundo em 2020.

Em pesquisa realizada por Wood (1989), foi utilizada uma técnica

interessante de obtenção das informações, subdividindo-os em três tipos de

agrupamentos: anamnese geral; anamnese específica e administração geral. Esse

método foi utilizado para avaliar a eficácia do acompanhamento médico por telefone,

que resultou em uma documentação escrita.

Estes acompanhamentos foram gravados em fitas que posteriormente foram

analisadas por médico examinador, relata grande preocupação em relação à

fidelidade do atendimento telefônico ao transcrever para o prontuário médico.

No entanto, o que vale ressaltar, é o método utilizado para agrupar as

informações, o que nos remete ao trabalho desenvolvido por Azanha e Oliveira

(2014).

Estes autores identificaram que devido à complexidade que tange o RES

Nacional, o modelo atual não atende à expectativa e necessidade do PEP e

sugerem um modelo de PEUP geograficamente distribuído, que possa atender às

eminentes necessidades da população nacional Brasileira.

2.6 PEUP

Azanha e Oliveira (2014) apresentam o PEUP como um modelo de PEP para

resolver o problema de fragmentação dos dados dos PEPs, através da definição de

um banco de dados distribuído com as informações unificadas, com a possibilidade

de interação de todos os centros de saúde no compartilhamento de informações.

Esse modelo divide o prontuário do paciente em três níveis: síntese; síntese

estendida e prontuário completo trabalham dessa forma, exigindo baixa dependência

da tecnologia, mas com consistente disponibilidade e interoperabilidade através de

um modelo computacional denominado Java Parallel Processing Framework (JPPF).

35

Esse modelo prevê que as informações devem estar disponíveis independentemente

da disponibilidade de uma rede on-line todo o tempo.

A síntese deve ter baixo nível de volume de dados. Deve conter informações

em texto como dados de anamnese e de atendimentos relevantes para exames de

rotina, emergência ou urgência.

A síntese estendida é complementada com imagens e arquivos contendo

maior volume de dados decorrente de um período de 12 a 24 meses, além de um

sumário que possibilitará o acesso a pontos específicos do prontuário completo.

O prontuário completo é uma base mantida na central da região do paciente,

que acumula toda interação no PEUP.

A síntese e a síntese estendida são atualizadas dinâmica e automaticamente

através de gatilhos computacionais entre as regiões pré-estabelecidas pelo PEUP.

Sendo que o prontuário completo ficará fisicamente armazenado somente na central

da região de localização geográfica do paciente, sendo transferido parcialmente

sempre que houver a solicitação por um profissional da saúde devidamente

identificado, através do sumário do prontuário referente a determinado paciente

(AZANHA; OLIVEIRA, 2014).

O projeto do PEUP é uma proposta para atender adequadamente no que

tange ao modelo desejado para um prontuário que garantirá a unicidade exclusiva

do paciente com a possibilidade de armazenamento completo de sua vida em

termos de saúde. O grande problema, no entanto, continua sendo a questão da

disponibilidade em redes não confiáveis que garantam o acesso dos dados sempre

que desejado.

Aqui vale lembrar que alguns questionamentos foram realizados na

introdução desse trabalho, em relação à tecnologia móvel para auxiliar no

atendimento e, principalmente, na disponibilidade do prontuário. Para tentar

responder tais indagações, faz-se necessário aprofundar e direcionar pesquisa

sobre o que há de mais inovador em cuidados com a saúde, ligado a prontuários

eletrônicos, principalmente, no Brasil.

36

2.7 EXEMPLOS DE PRONTUÁRIOS MÓVEIS

Pode-se destacar inicialmente o sistema HelloHealth (2014a) criado no

México e já citado na introdução, um sistema capaz de oferecer serviços de:

agendamentos; resultados de exames laboratoriais; acesso às anotações de

consultas; troca de mensagens com médicos; contato via vídeo chat; acesso aos

registros médicos através da Web e iPhone.

Metzdorf (2013) apresenta outro exemplo interessante que foi desenvolvido

nos EUA. Um software de RES em nuvem denominado drchrono que, através de

ferramentas em seus iPads, possibilita aos médicos interação sobre exames de

imagens e a manterem suas referências, laboratórios, alertas, vídeos, fotos e

centenas de outras características.

Independentemente da especialidade, o médico pode personalizar os

formulários e realizar interação com voz, transformando o que o médico fala, em

texto. O projeto ainda dispõe de um aplicativo móvel, onde os pacientes atualizam

informações demográficas e de seguro, além de um módulo que faz e envia

prescrição médica às farmácias dos EUA.

O sistema drchrono (2014) traz uma versão gratuita que disponibiliza boa

parte do sistema para uso livre. No entanto, as versões pagas com todas as

funcionalidades, variam entre U$ 179.99 a U$ 449.99 por fornecedor (ou profissional

da saúde) por mês9. Inclusive, vale observar que drcrhono se utiliza de estratégias

de marketing empresarial moderna para ganhar novos adeptos, enviando

mensagens por e-mail com seus contatos cadastrados sobre utilização e atualização

do software.

Enquanto a saúde pública caminha em passos lentos e burocráticos, a saúde

privada inova a cada dia e aproveita as novas tecnologias para proporcionar opções

e melhorar o suporte a saúde dos pacientes com melhor custo possível (SAUDE

BUSINESS, 2015).

Como exemplo, vale observar dispositivos como o novo bracelete de 10g

denominado LifeCode, que consegue armazenar anos de histórico médico que

podem ser utilizados quando necessários em consultas médicas ou em

atendimentos de urgência/emergência, desde que o profissional da saúde tenha um

9 Tabela de preços acessada no link: https://www.drchrono.com/pricing

37

computador com acesso USB para acessar os dados contidos no bracelete,

conforme demonstrado na Figura 2 (LIFECODE, 2014).

Figura 2 - Pulseira carrega histórico médico para situações de emergência

Fonte: (LIFECODE, 2014) 10

Analisando o que há de mais inovador disponível no mercado em relação a

dispositivos móveis, que podem auxiliar as pessoas na área da saúde, identifica-se a

importância da definição de um modelo para desenvolvimento de aplicativos que,

além de disponibilizar o PEP no dispositivo, consiga também sincronizar

automaticamente esse prontuário com um PEUP, o que justifica investir no

desenvolvimento do modelo para o aplicativo PEUP-M para sincronizar dados com o

PEUP e manter o PEP atualizado, tanto em uma central como no próprio dispositivo,

com a possibilidade de acesso inclusive off-line.

Dentro de um ambiente hospitalar, o PEUP-M poderá ser utilizado por

profissionais da saúde para acessar a síntese de seus pacientes e fazer as devidas

anotações de atendimento / acompanhamento, definindo o que deve ser adicionado

ao prontuário do paciente.

10 LifeCode guarda toda a ficha médica dos pacientes e custa 195 reais (Foto: Divulgação), por Mauricio Xavier [Com reportagem de Raphael Martins e Ricardo Rossetto], 11.abr.2014. Acesse o link: http://vejasp.abril.com.br/materia/pulseira-carrega-historico-medico-para-situacoes-de-emergencia

38

2.8 TECNOLOGIAS QUE PODEM SER INTEGRADOS AO PEUP-M

Um assunto bastante explorado tem sido o auxílio no controle e tratamento do

diabetes através de métodos não invasivos. Hoskins (2014) afirma que há anos vem

sendo realizadas diversas tentativas de se desenvolver métodos não invasivos

através de tatuagens, lágrimas, suor, saliva, impressões digitais e exames do globo

ocular e até mesmo de lentes de contato. Então Hoskins (2014) apresenta o

GlucoTrack que oferece a capacidade de testar o açúcar no sangue através de um

clipe colocado na orelha, conforme podemos observar na Figura 3. Esse clipe faz a

leitura dos vasos capilares e envia ao dispositivo (Figura 4) para armazenamento

temporário.

Figura 3 - Clipe do dispositivo GlucoTrack

Fonte: (HOSKINS, 2014)

Figura 4 - Dispositivo GlucoTrack

Fonte: (HOSKINS, 2014)

Os dados armazenados no dispositivo, depois são descarregados em um

computador pessoal para análise e acompanhamento clínico. Esse dispositivo vem

sendo desenvolvido desde 2009 e a proposta é que, a partir do segundo semestre

de 2014, comece a ser distribuído comercialmente a um custo aproximado de dois

mil dólares e ainda que o clipe deva ser substituído a cada seis meses, por um custo

de cem dólares.

Já Nimlos (2011) apresenta um monitor de glicose preciso, não invasivo

produzido pela empresa C8 MediSensors. Um projeto que vem sendo desenvolvido

39

desde 2003. O dispositivo tem o nome de HG1-c e faz a medição da glucose por

espectroscopia11 e transmite os dados para um iPhone ou Android. Veja dispositivo

na Figura 5.

Figura 5 - Dispositivo HG1-c C8 MediSensors

Fonte: (MEDSENSORS, 2015)

Esse dispositivo foi apresentado no congresso European Association For The

Study Of Diabetes (EASD) realizada em outubro de 2011 em Istanbul, conforme Dr.

Krakauer (2011) apresenta em vídeo no youtube com título “Congresso EASD - Dr.

Marcio Krakauer - Sensor” 12, dando algumas informações sobre o dispositivo. O

preço previsto para o equipamento é de U$ 4 mil em 2011 e de € 3 mil no mesmo

evento na Espanha em 2012.

11

Espectroscopia é a “técnica de aferimento de dados físico-químicos através da transmissão,

absorção ou reflexão da energia radiante incidente em uma amostra. Sua origem encontra-se no estudo da luz visível dispersa de acordo com seu comprimento de onda, por exemplo, por um prisma”. Segundo o site infoescola.com. Mais informações: http://www.infoescola.com/fisica/espectroscopia 12

Link de acesso ao vídeo: https://www.youtube.com/watch?v=lQIDDa_Dwbc#t=15

40

Como visto, existe no mercado nacional e, principalmente, internacional uma

gama enorme de dispositivos e aplicativos que auxiliam no cuidado com a saúde.

Um modelo de desenvolvimento de aplicativos para dispositivos móveis para

área da saúde pode atender as necessidades de acesso de profissionais da saúde

em informações relevantes dos prontuários de seus pacientes, com a possibilidade

de registrar informações de atendimento ou acompanhamento, além de poder

disponibilizar informações importantes de saúde ao próprio paciente.

Dessa forma, reforça-se a necessidade de criação de um “Modelo de

Disponibilização do Prontuário Eletrônico Único do Paciente em Dispositivos

Móveis”, o PEUP-M.

41

3 MATERIAIS E MÉTODOS

Antes de maiores detalhes sobre o modelo, faz-se necessário um prévio

resumo do mesmo, para facilitar o entendimento do objetivo proposto por meio de

um diagrama que incorpora o modelo do PEUP-M ao modelo do PEUP, como pode

ser esclarecido na figura 6. Os itens a, b e c da figura 6 representam o modelo

PEUP com suas centrais que se comunicam entre si para o prontuário completo de

cada paciente em sua região geográfica. A síntese é mantida atualizada em todas as

centrais.

O item d da figura 6 representa os Registros Eletrônicos de Saúde

fragmentados entre (hospitais, clínicas, consultórios particulares, operadoras de

planos de saúde, postos de saúde e laboratórios), que detêm informações dos

prontuários oriundos de consultas, exames, acompanhamentos de home care ou

medicina preventiva, atendimentos pré-hospitalares, atendimentos em postos de

saúde ou prontos socorros, exames laboratoriais, ou qualquer informação que seja

importante para o paciente do ponto de vista médico / hospitalar.

O item e da figura 6 representa o servidor middleware que tem a síntese

atualizada por cada Central PEUP e serve como sincronizador entre os DM dos

pacientes ou dos profissionais da saúde, além de servir de redundância da síntese

nas Centrais PEUP.

O item f da figura 6 representa os DM dos pacientes ou dos profissionais de

saúde que fazem sincronização com o servidor middleware para atualização das

sínteses mantidas pelos PEUPs.

42

Figura 6 - Diagrama demonstrativo resumido do modelo PEUP-M

Neste capítulo é apresentado: as tecnologias de desenvolvimento utilizadas,

os métodos adotados na pesquisa, as premissas iniciais do PEUP-M, o

detalhamento do modelo PEUP-M, o Banco de dados do PEUP-M no DM, a

comunicação e sincronização entre os DM e o PEUP, a disponibilização segura do

prontuário no DM, o prontuário no servidor, o descritivo das especificações, os testes

de consumo de Web Service no PEUP JPPF, a criação de um servidor Web

doméstico para testes e o método de segurança adotado na disponibilização dos

dados para os DM.

43

3.1 TECNOLOGIAS DE DESENVOLVIMENTO UTILIZADAS

A tecnologia a ser utilizada para atingir o objetivo esperado, é um dos

primeiros questionamentos que surgem no início de cada projeto. O PEUP-M, como

próprio nome sugere, precisa atingir o maior número de dispositivos móveis possível.

No entanto, este é um projeto experimental e, por isso, o front-end foi desenvolvido

para o sistema que estiver presente na maior quantidade de dispositivos. Segundo o

portal “Convergência Digital”, o sistema Android está presente em 82% dos

dispositivos móveis no Brasil (LOBO, 2015).

Mesmo o PEUP-M sendo um aplicativo que precisará consumir serviços do

PEUP (com suas tecnologias já definidas), é importante que ele se utilize de

conceitos tecnológicos, para se comunicar com as centrais PEUP, sem

dependências das tecnologias utilizadas no desenvolvimento dos servidores. Assim

sendo, diversas tecnologias foram estudadas, objetivando-se a escolha da melhor

tecnologia com o intuito de atingir o maior número de dispositivos possível.

A seguir, uma breve descrição das tecnologias possíveis e relevantes para se

utilizar no desenvolvimento do projeto PEUP-M:

a) Banco de dados SQLite

O SQLite é uma biblioteca compacta de código fonte aberto que provê as

funções básicas necessárias de um banco de dados relacional para armazenamento

de dados em dispositivos com limitados recursos de memória física, como celulares,

PDAs13 e MP3 players. O SQLite é mantido por uma equipe internacional de

desenvolvedores que o utiliza em tempo integral em suas aplicações. O lema de

seus desenvolvedores é mantê-lo pequeno, rápido e confiável (SQLite, 2014).

No PEUP-M, o SQLite tem a função de armazenar e garantir a privacidade

dos dados armazenados, que só podem ser acessados por ferramentas específicas

de manutenção de bancos de dados.

b) Eclipse

Eclipse é mais que um ambiente de desenvolvimento de sistemas. É um

projeto open source supervisionado por um comitê gestor de projetos que

13

PDAs (Personal Digital Assistants). Assistente digital pessoal (computadores de dimensões reduzidas)

44

disponibilizam ferramentas para um ambiente de desenvolvimento (ECLIPSE, 2014).

Tem sido uma das plataformas mais utilizadas para o desenvolvimento de

aplicativos móveis do mercado. Conforme publicação da revista Computerworld

(2014) em uma publicação sobre dicas para jovens talentos que querem dominar a

linguagem Cobol. O Eclipse foi a principal ferramenta de desenvolvimento do

aplicativo do PEUP-M para teste do modelo proposto.

c) NetBeans

O NetBeans foi a IDE que se mostrou mais amigável para o desenvolvimento

de Web Services no lado servidor, onde foi utilizada a linguagem de programação

PHP que permite acesso ao banco de dados MySQL, juntamente com a biblioteca

NuSOAP, que facilita o tratamento dos dados em XML no lado servidor para retorno

para a aplicação no lado cliente. O NetBeans foi utilizado para tratar a comunicação

entre a Central PEUP e o servidor middleware para atualização da síntese do PEUP

e também dos Web Services que fazem sincronização entre os DM e o servidor

middleware. Foi utilizado com a tecnologia Java para integrar a tecnologia JPPF

através da linguagem de desenvolvimento Java, tornando possível o trabalho com

tarefas executadas no servidor controladas pelo servidor de aplicações GlassFish,

que além de controlar a distribuição das atividades da plataforma JPPF, também

controla as solicitações e as respostas do prontuário através de Web Services. O

GlassFish é um servidor de aplicações open source que suporta todas as

especificações da API Java EE, tais como JDBC, RMI, JMS, JMX.

d) Workbench

Ferramenta de desenvolvimento e acesso ao banco de dados MySQL para

auxiliar no tratamento do armazenamento dos dados.

e) Google Maps

O Google Maps disponibiliza um conjunto de funcionalidades interessantes

em relação à localização, visualização e navegação por GPS. Para acesso e

controle das funcionalidades oferecidas pelo Google Maps, é necessário que se

obtenha uma chave de controle a ser inserida no aplicativo, possibilitando seu

registro e distribuição pelo Google Play (https://play.google.com).

45

f) Astah

O Astah é um software de modelagem de sistemas que torna fácil a

compreensão das funcionalidades a serem desenvolvidas em um sistema. Veja mais

em astah.net.

A principal dúvida no momento de começar o desenvolvimento foi a escolha

da linguagem para o desenvolvimento Mobile. Pois estamos vivendo constantes

sobreposições de paradigmas em termos de tecnologia móvel. Neste momento,

cada fabricante tenta impor padrões ou “sair na frente” para se solidificar no

mercado. Esta é uma concorrência que acaba trazendo muitas inovações, mas que

faz com que os produtores de software tenham que dedicar parte de seus recursos

na busca do conhecimento das novas tecnologias.

Neste sentido e com o intuito de escolher as melhores ferramentas para o

desenvolvimento, veio a tentativa de desenvolver um software Mobile genérico, que

atendesse a todos os modelos de todos os fabricantes.

Após diversas pesquisas e testes, a conclusão foi que o projeto PEUP-M

deveria ser desenvolvido na plataforma Android Java EE, com o auxílio da IDE

Eclipse, repositório de dados SQLite e comunicação via Web Service com o servidor.

Esse conjunto de ferramentas traz um desenvolvimento limitado para

dispositivos com o Android, mas traz mais estabilidade e garantia de funcionamento

nestes aplicativos, sem contar que é o Android o sistema operacional mais utilizado

em dispositivos móveis (LOBO, 2015).

3.2 MÉTODOS

Analisando o modelo PEUP que foi desenvolvido para suprir as diversas

necessidades detectadas nos modelos PEPs, tais como: interoperabilidade;

disponibilidade; acesso por parte do paciente; alto volume de dados e distribuição

geográfica do país, identifica-se que o modelo PEUP pode ser melhorado no sentido

de aumentar a disponibilidade de acesso à síntese do prontuário por profissionais de

saúde e pelo próprio paciente.

Este capítulo apresenta um modelo de acesso, armazenamento e distribuição

de dados do PEUP para ser utilizado em dispositivos móveis. Nas sessões

46

seguintes é apresentado o modelo, que foi elaborado com base nos seguintes

requisitos:

Buscar síntese do paciente em uma central PEUP, geograficamente

mais próxima do paciente;

Manter dados cadastrais do paciente;

Sincronizar e manter dados de saúde do paciente (síntese do PEUP);

Disponibilizar síntese para profissionais da saúde em situações de

urgência / emergência;

Dar acesso à síntese do paciente, mesmo que só com o cartão de

memória.

Este novo modelo prevê a baixa (ou ausência temporária de) disponibilidade

de acesso à internet. Dentre as diversas tecnologias disponíveis para

desenvolvimento de aplicativos para dispositivos móveis, as tecnologias descritas no

tópico de tecnologia de desenvolvimento utilizada, foram escolhidas por serem as

mais consolidadas do mercado.

Este capítulo se destina a descrever as validações realizadas no que diz

respeito a preocupações como a disponibilidade dos dados de forma segura, mesmo

estando off-line. Para melhor entendimento do modelo proposto, vamos analisar a

Figura 7:

47

Figura 7 - Diagrama demonstrativo do modelo PEUP com o PEUP-M

A Figura 7 ilustra a sugestão de modelo computacional com interligação entre

os RES e o PEUP. Os RES podem ser hospitais, clínicas/consultórios, prestadores

de serviços Home Care, medicina preventiva, Atendimento Pré-Hospitalar (APH),

RE

S e

xist

ente

s e f

ragm

enta

do

s

PE

UP

(desen

volv

ido p

or

Aza

nha e

Oliv

eir

a (

2014))

P

EU

P-M

- a

ser

desen

volv

ido

48

laboratórios e Postos de saúde. O PEUP por sua vez se relaciona entre as Bases de

Dados das diferentes regiões e também com o PEUP-M. A comunicação do PEUP-

M com o PEUP é realizada por sua região geográfica ou com o PEUP de outra

região, caso a região do paciente esteja inacessível. Os dados são atualizados

localmente no DM do paciente (celular ou tablet) e pode ser acessado sempre que

necessário, por um profissional da saúde.

3.3 PREMISSAS INICIAIS DO PEUP-M

No conceito do PEUP-M, uma das primeiras preocupações é o volume de

dados, que consiste no armazenamento dos seus dados cadastrais e na síntese do

seu PEUP. O volume do cadastro é pequeno e relativamente constante para todos

os pacientes. Entretanto, o volume de dados do PEUP correspondente aos últimos

24 meses pode variar, de um paciente para outro, de poucos kilo-bytes até dezenas

de gigabytes. Somado a isto, existe a limitação na capacidade de armazenamento e

de comunicação dos dispositivos móveis. Então, conforme estudo realizado por

Azanha e Oliveira (2014), optou-se por armazenar os textos significativos,

correspondente à síntese do PEUP e os hiperlinks que levem às informações mais

detalhadas como imagens, vídeos e outros dados de maior volume. Porém neste

caso, devido ao grande volume de dados é aconselhável que o acesso seja

realizado através de um computador desktop pelo próprio PEUP. A síntese deve

conter as informações referentes aos últimos atendimentos do paciente e

informações relevantes de caráter permanente que devam ser consideradas em

atendimentos de urgência e emergência.

Para os testes iniciais os dados são apenas em texto, armazenados em

banco de dados compacto, exclusivo para DM. Para tornar o PEUP-M viável foi

necessário desenvolver os seguintes artefatos:

Base de dados e programação para manter o banco de dados no DM,

que seja capaz de suportar a síntese do PEUP e dos dados cadastrais

do paciente;

Módulo de comunicação e de sincronização entre os dispositivos

móveis e o PEUP;

49

Módulo de controle para a disponibilização do prontuário para

profissionais da saúde, em casos de atendimentos de urgência ou

emergência.

3.4 DETALHAMENTO DO MODELO – PEUP-M

Para atender os requisitos foram descritos mais detalhadamente os seguintes

tópicos: a) Descrição do modelo de banco de dados no DM com a síntese e dados

cadastrais do paciente; b) Teste do modelo de comunicação e sincronização com o

PEUP; c) Teste do módulo de disponibilização para os profissionais de saúde.

3.4.1 Banco de dados do PEUP-M no DM

Em relação aos dados a serem mantidos no DM do paciente, temos os

seguintes grupos de informações a serem tratadas:

Dados básicos do paciente - Informações cadastrais como: endereço

completo (logradouro, número, complemento, bairro, cidade, estado,

CEP); dados de contato (telefones, e-mails, Skype); documentos (CPF,

RG, CNS); acesso (usuário e senha) e dados do plano de saúde

(numero da OPS na ANS, Matrícula de associado);

Dados biométricos e características individuais - Informações

biométricas: peso, altura, características físicas relevantes; tipo

sanguíneo; antecedentes mórbidos (familiares e pessoais);

Observações sobre glicemia, frequência cardíaca, pressão arterial e

restrições: alimentares e medicamentosas.

Síntese do prontuário – Conforme Azanha e Oliveira (2014): Registros

dos últimos atendimentos médicos, considerando o mínimo de 24

meses. Informações relevantes registradas no prontuário que sejam de

caráter permanente, com doenças crônicas, sequelas, limitações e

restrições de ordem médica. Nesses registros devem constar os

resultados e/ou laudos de exames, relatos de ocorrências que tenha

50

consequências futuras, relato do estado de saúde recente do paciente

(AZANHA; OLIVEIRA, 2014).

Os dados são mantidos no DM através de banco de dados, podendo ser

acessados e atualizados a qualquer momento. Todos os dados são recebidos do

PEUP via sincronização. No entanto, algumas informações, como os relatos de

sintomas do paciente e seus dados cadastrais, podem ser atualizadas pelo próprio

paciente em seu DM e enviado ao servidor PEUP. Já os dados de atendimentos só

podem ser alterados por profissionais de saúde que devem analisar os relatos do

paciente para auxiliar em seu diagnóstico. Desta forma, a síntese disponibilizada no

DM deve manter a integridade com as informações originais.

Os dados de um prontuário não podem ser alterados ou excluídos. O

prontuário deve apenas receber novas observações e registros de exames,

consultas ou observações, por profissionais de saúde. Neste sentido, a síntese é

formada pelas interações dos profissionais da saúde e mantidas em bancos de

dados do PEUP. O paciente por sua vez, pode apenas fazer alterações referente a

configurações do aplicativo em seu DM e algumas informações tais como endereço,

telefone, dados do plano de saúde e relatos de seu estado de saúde por exemplo.

Ainda assim, qualquer informação só é agregada ao prontuário do paciente por um

profissional de saúde.

As seguintes tabelas são utilizadas para manter os dados no DM e no

servidor.

Na Tabela 1 demonstra as tabelas no servidor PEUP:

Tabela 1: Tabelas do servidor PEUP para manter prontuário do paciente.

Nome da tabela Definição

tb_atendimento

Mantêm os dados mais recentes, os mais relevantes do histórico de atendimentos do paciente. Ou seja, a síntese.

tb_prontuario Mantém todos os dados do histórico de atendimentos do paciente, ou seja, mantem a síntese estendida referente à saúde do paciente.

tb_paciente Mantém dados cadastrais do paciente. O CPF será o campo chave para identificação do paciente pelo DM no PEUP.

51

A Tabela 2 apresenta o conjunto de tabelas necessárias para manter os

dados coletados dos DMs e a autenticidade do paciente.

Tabela 2: Tabelas do servidor PEUP para manter autenticidade dos dispositivos.

Nome da tabela Definição

ps_autenticidade Mantém os dados de registros dos dispositivos. Tendo como chave principal o CPF do paciente para controle de seus dispositivos com o PEUP-M instalado através do código IMEI dos dispositivos.

ps_paciente_log_gps Mantém log do registro de locomoção do paciente quando permitido pelo mesmo para monitoramento e movimentação dos dados do paciente entre servidores se necessário.

ps_paciente_perfil Mantém dados cadastrais do paciente realizados pelo próprio paciente no dispositivo.

ps_relato Mantém dados dos relatos dos pacientes que podem ser considerados pelo médico em atendimentos.

Alguns artefatos foram elaborados para definição do modelo:

a) Paciente, Médico, Administrador e Atendente são os atores que formam

quatro casos de uso para interação com o sistema:

Caso de Paciente: Manter paciente, manter relatos, consultar

prontuário, definir médico responsável, manter usuário, Exames

agendados e Consultas agendadas.

Caso de Médico: Manter médico, consultar relatos, consultar

prontuário, manter usuário, Exames agendados e Consultas

agendadas, manter agendamentos.

Caso de uso Atendente: manter usuários, manter agendamentos.

Caso de uso Administrador: manter usuários, manter

agendamentos, manter perfis.

Para maiores detalhes, ver diagrama de casos de uso no Apêndice A.

b) O Modelo de Entidade e Relacionamento (MER) que represente a

definição das tabelas do banco de dados para manter os dados do

paciente em seu DM e no servidor PEUP.

52

Para maiores detalhes, ver diagrama de Entidade e Relacionamento

(MER) no Apêndice A.

c) Diagrama de sequencia de autenticação do paciente e interação com a

síntese.

Para autenticação o sistema solicita o CPF do paciente e uma senha

previamente cadastrada. Os dados são submetidos ao servidor, que

identifica a autenticação do paciente, disponibilizando em tela apenas as

opções do aplicativo pertinentes ao paciente através de seu perfil. Desta

forma, o paciente tem à disposição a opção de manter seus dados

pessoais, manter seus relatos pessoais de saúde e de consultar seu

prontuário.

Para maiores detalhes ver diagrama de sequência para autenticação e

interação do paciente no Apêndice A.

d) Diagrama de sequencia de autenticação do médico e interação com a

síntese.

Para autenticação o sistema solicita o CRM do médico e uma senha

previamente cadastrada. Os dados são submetidos ao servidor, que

identifica a autenticação do médico, disponibilizando em tela apenas as

opções do aplicativo que tem direito através de seu perfil. Desta forma, o

médico pode manter seus dados pessoais, consultar o prontuário de seus

pacientes para atendimento no dia e registrar informações no prontuário

do paciente, submetendo texto, imagem, som ou vídeo.

Para maiores detalhes ver o diagrama de sequência para autenticação e

interação do médico no Apêndice A.

A comunicação inicia-se na interface do DM do paciente ou do médico, efetua

autenticação no DM para disponibilizar as opções pertinentes à cada perfil e ao fazer

a sincronização com o servidor, efetua autenticação para garantir a segurança da

informação.

O servidor gera as informações para enviar para o DM e gera também um

HASH que é verificado no lado cliente pelo aplicativo no DM. Caso o HASH não

confira, os dados são descartados e nova sincronização é realizada.

53

3.4.2 Comunicação e sincronização entre dispositivos móveis e o PEUP

A comunicação entre o DM do paciente e o PEUP se dá das seguintes

formas:

Sempre que o paciente solicitar;

Sempre que o paciente modificar alguma informação cadastral ou

acrescentar relatos ou dados sobre sua saúde;

Sempre que informações forem adicionadas em seu prontuário por

profissionais de saúde.

Como o objetivo deste modelo é que funcione também com o dispositivo off-

line, toda vez que houver a necessidade de sincronização dos dados, será verificado

se há conexão com a internet. Caso não seja possível, a sincronização ficará

pendente, sendo checada a disponibilidade de rede periodicamente, até que a

sincronização seja concluída.

Na primeira vez que o aplicativo for executado no dispositivo, as tabelas de

armazenamento local são criadas e a primeira sincronização realizada. Assim todos

os dados cadastrais, de saúde e a síntese do prontuário serão atualizados no

dispositivo.

Depois, caso não haja conexão com a internet o paciente poderá utilizar as

funcionalidades do aplicativo. Todas as inserções que ocorrerem off-line são

atualizadas no PEUP ocorrem por meio de sincronização, sempre que houver

conexão com a Internet e o paciente autorizar.

Uma vez que o prontuário esteja atualizado no DM do paciente, através de

suas interações e sincronizações com uma central PEUP, estes dados podem ser

utilizados a qualquer momento em atendimentos de rotina, emergência, urgência, ou

enviado para um profissional da saúde para análise.

No próximo tópico são apresentadas alternativas de como essa

disponibilização ocorre.

54

3.4.3 Disponibilização segura do prontuário no DM

Ao pensar em disponibilizar os dados do prontuário do paciente, é importante

garantir que estes dados são disponibilizados de forma segura e integra.

Adesina et al. (2011, p.1) define que a necessidade de segurança e

privacidade estão ligados diretamente à questão da ética médica e expectativas

sociais. O direito de acesso aos dados, bem como onde, quando e como serão

armazenados e ainda a segurança durante a transmissão e o direito de análise dos

dados são definições políticas e de governo.

O dinamismo com que a tecnologia vem se desenvolvendo nas últimas

décadas, nos faz refletir a cada dia sobre o papel dessa tecnologia no âmbito de

possibilitar uma melhor qualidade de vida para as pessoas.

A tecnologia móvel (mobile), por exemplo, tem se desenvolvido de forma as

vezes "espantosa" nos últimos anos, e ainda assim, quando se faz uma análise de

seu potencial, conclui-se que as possibilidades são infinitas.

Uma maneira de tornar a tecnologia móvel mais útil e talvez até indispensável

seja sua utilização como ferramenta de apoio na área da saúde em geral.

Considerando a afirmação de Pinochet (2011, p.390) que diz que:

O futuro das redes e tecnologias sem fio é promissor, pois estão promovendo a convergência entre telefonia celular (smartphones) e computação móvel (PDAs com comunicação), além de viabilizar redes digitais de área local e de área ampla de alto desempenho, graças às novas tecnologias Wi-Max e OFDM.

É possível se desenvolver aplicações que venham cada vez mais contribuir

para a manutenção da saúde da população em geral, bem como auxiliar em casos

de emergência ou monitorar determinados fatores da saúde para determinação de

tratamentos preventivos a eventuais gravidades (LIMA, 2010, p.12).

Um grande avanço tecnológico tem sido visto por parte das empresas que

tem desenvolvido e implantado sistemas como PEP para melhor atender e dinamizar

o acesso aos dados principalmente no tocante ao âmbito comercial (PINOCHET,

2011, p.388).

Em se tratando de segurança, vale destacar que o Sistema Operacional (SO)

Android tem seu próprio sistema de segurança baseado em "uma estrutura de

aplicativo, bibliotecas de aplicativo e um tempo de execução com base em máquina

virtual" denominada Dalvik, executado em um kernel do Linux que gerencia

55

processos, memória, rede, drivers, etc. (ORTIZ, 2010). A ideia é que o

desenvolvedor não tenha que se preocupar com a segurança de seus aplicativos,

pois outros processos "não podem acessar seu código ou dados privados", a menos

que se tenha permissão específica para isso (ANDROID, 2014).

Com essa afirmação, entendemos que os aplicativos com banco de dados

desenvolvidos para a plataforma Android conta com a segurança do próprio SO em

relação a integridade dos dados.

A comunicação entre os dispositivos móveis e a central PEUP será realizada

através de um protocolo rede segura, o HyperText Transfer Protocol Secure

(HTTPS), que por si garante a criptografia dos dados na transmissão, para garantir

que os dados, mesmo que interceptados, não possam ser cifrados por pessoas não

autorizadas.

É de suma importância que ao pensar na comunicação, seja considerado os

requerimentos necessários na segurança em comunicação de dados (ETI, 2012;

MOECKE et al., 2010; REIS, 2014), que pode ser obtida com uma assinatura digital:

Autenticação: Que deve garantir que a mensagem é originada pelo

emitente, através do uso de usuário e senha, smart cards ou de meios

biométricos se autentica em determinado servidor.

Integridade: Garantir a integridade da informação enviada pelo

emitente ao receptor, através do uso do cálculo de Hash.

Confiabilidade: Garantir que as informações serão acessadas somente

por pessoas autorizadas.

Não-Repúdio: Garantir que não haja como ser negado o envio das

informações pelo emissor, obtido através da utilização de assinaturas

com certificados digitais.

Técnicas de criptografia simétrica ou assimétrica devem ser utilizadas. Na

técnica simétrica, tem-se um remetente que enviará uma mensagem ao destinatário,

sendo essa mensagem encriptada com o auxilio de uma chave privada. A

mensagem criptografada trafega sobre a rede e chega ao destinatário, conforme

demonstrado na parte superior da Figura 8.

Já a técnica de criptografia assimétrica, são duas chaves, sendo uma pública

e outra privada. Para transmitir uma mensagem com segurança através dessa

56

técnica, o emitente encripta a mensagem com a chave pública do destinatário que

só poderá ser decriptografada com a chave privada do mesmo. Para melhor

elucidação, observar a Figura 8.

.

Figura 8 - Criptografia de Chave Privada

Em relação à integridade, utiliza-se a técnica do cálculo de Hash para verificar

se determinada informação ou conjunto de dados estejam íntegros. Ou seja, que

não foram modificados a partir de sua origem.

A fórmula: c=E(k,m); representa a encriptação dos dados. E a fórmula:

m=D(k,c); representa a desencriptação. Sendo que: m = texto (ou mensagem) a ser

encriptado; c = texto cifrado (ou, já com a encriptação aplicada); k = chave de

criptografia; E = algoritmo de encriptação; D = algoritmo de desencriptação. Os

algoritmos devem ser relacionados através de uma “Equação de Consistência”:

m=D(k,E(k,m)).

É de suma importância garantir o não-repúdio, através da técnica de

assinatura digital de criptografia assimétrica, que deve funcionar da seguinte forma:

o remetente gera a mensagem desejada encriptada com a chave privada, passando

a chave pública para o destinatário poder abrir. Isso prova que a assinatura partiu do

remetente específico. A assinatura digital consegue garantir três princípios básicos

da criptografia, autenticação, não repúdio e integridade.

Como o foco desse trabalho destina-se à questão da disponibilização do

PEUP ao paciente, é importante considerar que a questão de segurança e direito de

acesso ao prontuário pelo paciente é assunto tratado e resolvido. Desta forma, vale

57

salientar que os meios de seguranças e critérios éticos devem ser seguidos para

que o acesso ao PEUP através de dispositivos móveis esteja dentro da legitimidade

exigida.

3.4.4 Segurança na disponibilização dos dados no DM

Para assegurar o acesso seguro ao aplicativo do PEUP-M foi desenvolvido

com mecanismo de segurança que verifica autenticidade do DM no servidor através

do CPF e do IMEI do DM toda vez que uma nova versão for instalada. No caso de

mais de um IMEI registrado no servidor, o usuário tem a opção de desabilitar um dos

DM ou deixar que o sistema seja executado em diversos DM. No caso de um

determinado DM não estar mais em poder do paciente, o mesmo poderá ser

desabilitado para acesso. O aplicativo no dispositivo desabilitado terá seus dados

eliminados em qualquer tentativa de acesso. Esse mecanismo de funcionamento

está descrito no item Start (ou principal) no tópico de “Descritivo das especificações”.

É importante lembrar que para implantar o modelo de forma eficiente, não se

deve ignorar um modelo de segurança para comunicação, armazenamento e acesso

seguro. Além de protocolo seguro de comunicação (HTTPS), criptografia para

armazenamento e Hash para verificar integridade dos dados transmitidos. É

importante a implantação de assinatura ou certificado digital e outros programas de

criptografia (CERT.BR, 2015).

O Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no

Brasil (CERT.BR) disponibiliza em http://cartilha.cert.br uma cartilha completa de

segurança para internet, que deve ser considerada na implantação desse modelo,

além dos Níveis de Garantia de Segurança (NGS) disponíveis na cartilha sobre PEP

e certificação de sistemas de RES (SBIS, 2015).

58

3.5 SOFTWARE

3.5.1 Prontuário no servidor

Para que o projeto pudesse ser colocado em prática com testes acessando

diretamente a grade computacional JPPF, foi criado um domínio para hospedagem

denominado: http://peup.adm.br.

Para manter dados de simulação das sínteses e informações sobre o projeto

PEUP-M, foi criado o subdomínio http://peup.aas.pro.br.

É importante lembrar que no servidor do PEUP, o histórico completo de

atendimentos, é mantido em uma tabela (tb_prontuario). Estes dados nunca são

eliminados. No entanto, os dados mais recentes ou mais relevantes para servir de

base para um atendimento de rotina ou de urgência/emergência, estão mantidos em

outra tabela denominada (tb_atendimento). Os dados são armazenados inicialmente

na tabela tb_atendimento e transferidas automaticamente via trigger (gatilho) no

banco de dados para a tabela tb_prontuario. Sendo os registros mais antigos, de

caráter temporário, ou menos significativos para atendimentos, eliminados da tabela

de atendimentos, conforme apresentado na sessão 3.4.1.

O conjunto de tabelas necessárias para manter os dados coletados dos

dispositivos móveis e a autenticidade do paciente pode ser visto na sessão 3.4.1.

Além dessas tabelas, foram desenvolvidos e disponibilizados alguns Web

Services que são consumidos pelos dispositivos móveis, como apresentado na

Tabela 3.

Tabela 3: Web Services no servidor PEUP para consumo nos dispositivos.

Operação Definição

getOutroDispositivo Retorna uma lista de dispositivos cadastrados no mesmo CPF do paciente, exceto o dispositivo que está fazendo acesso no momento. Requer os argumentos CPF do paciente e IMEI do dispositivo.

getAutenticidade Retorna informações para checagem de autenticidade do paciente. Requer os argumentos CPF do paciente e IMEI do dispositivo.

getPaciente Retorna os dados do paciente registrados pelo próprio em seu(s) dispositivo(s). Requer o CPF do paciente como argumento.

59

lockDispositivoRequest Bloqueia dispositivos do próprio paciente na Central PEUP. Os dispositivos que podem ser bloqueados são obtidos através da operação getOutroDispositivo. Requer CPF do paciente e IMEI a ser bloqueado.

setDispositivo Registra o dispositivo na Central, na primeira execução do aplicativo. Requer CPF do paciente e IMEI do dispositivo.

getAtendimentos Retorna os atendimentos mais relevantes (síntese) para manter no DM.

O IMEI do dispositivo é obtido automaticamente pelo aplicativo.

No servidor, a Central PEUP tem a responsabilidade de receber as

solicitações realizadas pelo aplicativo PEUP-M executados nos dispositivos dos

pacientes.

Os dispositivos móveis através do aplicativo PEUP-M, são encarregados de

manter as informações necessárias dos pacientes e acionar o servidor (Central

PEUP) para enviar informações dos dispositivos e receber essas informações se

necessário no futuro em um novo dispositivo ou receber dados referentes à Síntese

de seu prontuário.

A seguir são apresentados os requisitos usados no desenvolvimento do

aplicativo para o DM, no intuito de detalhar a análise do software.

3.5.2 Descritivo das especificações

Após o aplicativo ser baixado do site www.peup.aas.pro.br e instalado,

executa-se o mesmo pela primeira vez. O resumo metodológico vem justificar a

teoria e apresenta as funcionalidades desenvolvidas na aplicação, dividida em

tópicos:

1) Start (ou Principal)

Ao ser acionado, o aplicativo faz alguns testes iniciais, para identificar

alguns fatores que determinam seu comportamento, que estão relacionados

abaixo.

60

Se for a primeira execução, é criado um banco de dados compacto no DM

e alguns valores são inicializados, conforme descrito no item “Preferências” deste

tópico.

O aplicativo passa a obedecer às configurações padrão ou

personalizadas, tais como:

Primeiro acesso no DM.

Troca do DM e registro de mais de um DM no PEUP

Verificação de autenticidade do dispositivo.

Ao iniciar o aplicativo, já nas primeiras interatividades do usuário, o

aplicativo deve detectar o IMEI (International Mobile Equipment

Identity) do DM e efetuar as seguintes verificação:

Se nas preferências locais do dispositivo estiver registrado que o

PEUP-M está bloqueado, apenas apresenta mensagem de

bloqueio.

Ver tela de bloqueio no Apêndice B.

Caso não haja bloqueio do PEUP-M registrado nas preferências

do DM, o aplicativo faz contato com a central PEUP para

verificar se o dispositivo não foi bloqueado por uma instalação

em outro dispositivo ou por opção do próprio paciente. Caso seja

encontrado bloqueio na central, registra-se nas preferências do

dispositivo para que em futuras execuções do aplicativo não

haja necessidade de contato com a central para exibir

mensagem de aplicativo bloqueado. Na condição de bloqueio

todas as informações do paciente são eliminadas do dispositivo.

Esta verificação é realizada via Web Service.

Ver Web Service – Operações: getAutenticidade no Apêndice C.

Em todos os acessos é feita a verificação de bloqueio do dispositivo.

Caso o dispositivo seja válido são solicitados o nome e o CPF do

paciente, com o objetivo de registrar estas informações no dispositivo e

verificar na central PEUP se o paciente está acessando seu prontuário

do mesmo dispositivo que acessou da última vez.

Ver tela de registro de autenticidade no Apêndice B.

61

o Se os dados do paciente forem encontrados na central PEUP, os

mesmos são atualizados no dispositivo. Estes dados são obtidos

da central através do Web Service getPaciente.

Ver Web Service – Operações: getPaciente no Apêndice C.

o Após confirmação do nome e CPF do paciente, informado em sua

primeira execução, o dispositivo é registrado na central PEUP via

Web Service.

Ver Web Service – Operações: setDispositivo no Apêndice C.

Esta atualização ocorre mesmo que o IMEI do dispositivo seja

diferente, proporcionando ao paciente a possibilidade de migrar a

utilização do aplicativo de um DM para outro ou manter seus dados

atualizados em mais de um DM.

o Se na central PEUP existir CPF com IMEI diferente do DM que está

acessando, o PEUP-M perguntará ao paciente se deseja bloquear

o aplicativo no outro dispositivo. O Web Service apresentado no

“Apêndice C – Web Service – Operações: getOutroDispositivo” tem

o objetivo de obter os dados de outros dispositivos registrados com

mesmo CPF na central PEUP, habilitados a utilizar o PEUP-M. Em

caso de opção de bloqueio do uso do PEUP-M, O Web Service

apresentado no “Apêndice C - Web Service – Operações:

lockDispositivo” se encarrega de enviar comando de bloqueio de

cada dispositivo, que será solicitado ao paciente.

Verificação e registro da localização GPS. Em caso de necessidade de

localização rápida do paciente ou monitoramento, o recurso de

localização GPS pode ser ativado para que a localização do paciente

possa ser enviada à central PEUP constantemente. Se o recurso for

ativado o PEUP-M faz o registro de mudança de localização GPS

obedecendo a uma quantidade de verificações por determinado tempo

(que pode ser em horas, minutos ou segundos). Também obedecer a

uma distância mínima de locomoção que pode ser em quilômetros,

metros ou centímetros.

Com esta parametrização é possível a identificação de um

deslocamento do paciente entre cidades ou regiões, ou mesmo um

62

monitoramento de deslocamento de forma intensiva e minuciosa, e

ainda on-line e em tempo real (real time).

Verificação e envio automático de dados à central PEUP. Ao atingir o

tempo determinado (em horas, minutos ou segundos), desde que haja

conexão com a Internet, o aplicativo faz o envio de informações de

registros de locomoção GPS e dos dados de perfil atualizados pelo

paciente.

Será registrada a data/hora em que foi feito a ultima checagem e

atualização na central PEUP.

Verificação e recebimento automático da síntese da central PEUP para

sincronização. Ao atingir o tempo determinado (em horas, minutos ou

segundos), desde que haja conexão com a Internet, o aplicativo faz o

recebimento da síntese da central PEUP, desde que o mesmo tenha

tido alguma atualização.

Será registrada a data/hora em que foi feito a última checagem e

atualização no dispositivo.

Verificação de lembretes. O dispositivo pode lembrar o paciente sobre

horário de tomar remédios, de realizar algum autoexame, de ir ao

hospital, clínica ou laboratórios para realização de consultas ou

exames, ou retirada de resultados.

Exibição de lembretes e LOGs. Na tela de start são apresentados

separadamente os lembretes previamente agendados e os LOGs

acima determinados. - Por exemplo: Data/hora de última tentativa e

atualização do perfil na central PEUP; - Data/hora de ultima tentativa e

atualização da síntese no dispositivo. Data/hora de desativação de

dispositivo; - Data/hora de instalação do aplicativo, etc.

2) Perfil

É exibida uma lista de perfis cadastrados, com o nome, CPF e dispositivo.

Ao ser selecionado um dos itens da lista, é dada opção para realizar as

seguintes operações:

Desativar um determinado dispositivo (desde que haja mais que um).

Manter dados pessoais e de endereço do paciente.

63

A inclusão do paciente é realizada automaticamente logo após ser

informado nome e CPF e identificação do IMEI, conforme descrito no

start da aplicação. No entanto outros dados tais como telefones e,

dados de plano de saúde podem ser atualizados sempre que

necessário.

3) Sincronização

A sincronização é o envio dos dados coletados pelo aplicativo no DM para

central PEUP e o recebimento da síntese atualizada do prontuário para

armazenamento no DM. Esta sincronização ocorrerá automaticamente.

No entanto, caso seja necessário, a sincronização tanto para envio como para

recebimento o paciente pode iniciá-la em opção específica.

3.1. Exportar perfil

Os dados do perfil do paciente armazenados no dispositivo são

exportados para cartão SD no formato XML. Com essa funcionalidade, o

aplicativo visa suprir a necessidade de acesso por profissionais da saúde

em acesso ao próprio DM ou através do cartão SD colocado em outro

dispositivo ou PC.

3.2. Enviar perfil

Enviar informações do perfil para a central PEUP. (utilizando formato CSV

para minimizar impacto de quantidade de dados a trafegar na rede).

Este envio visa manter os dados de perfil atualizados na central PEUP,

possibilitando o acesso por profissionais da saúde se necessário e ainda a

atualização do perfil em outros dispositivos ou recuperação do perfil se

necessário reinstalação do aplicativo no mesmo dispositivo.

O perfil é atualizado na central PEUP;

Os dados de deslocamento GPS são inseridos na central PEUP e

eliminados do DM. Uma vez que estes dados servem apenas para

monitorar o deslocamento do paciente para ação preventiva de socorro

ou atendimento, eles também serão eliminados da central PEUP se

gerados em um período superior a três meses. (não eliminando caso

64

haja um número menor ou igual a 1000 registros de LOG,

independente do tempo em que foi gerado).

3.3. Receber síntese

A síntese do paciente é solicitada à central PEUP através do consumo de

um Web Service específico (getAtendimentos). O resultado dessa

operação é um arquivo XML em memória interna (com integridade

protegida) ou memória externa (cartão SD) para utilização por

profissionais da saúde. Esta opção disponibiliza os dados para acesso por

terceiros (profissionais da saúde, por exemplo, podem guardar os arquivos

para análise futura).

Os dados disponibilizados em memória externa precisam ser validados

através de Hash para verificar sua autenticidade.

4) Visualização

4.1. LOG GPS

Os registros de LOG da mudança de localização realizados por GPS

poderão ser visualizados e analisados no dispositivo, até o momento em

que forem enviados à central PEUP e eliminados do dispositivo.

4.2. Perfil

Visualização da última versão do perfil, previamente exportado no formato

XML.

4.3. Síntese PEUP

Visualização da última versão da síntese previamente recebida da central

PEUP e transformada em arquivo XML.

5) Preferências

Habilitar rastreamento GPS: Pode ser ativado o rastreamento GPS

a qualquer momento, a fim de registrar os deslocamentos regionais

para que o PEUP seja automaticamente remanejado entre

servidores para garantir possibilidade de uso imediato em novo

destino, ou ainda o registro de deslocamento para monitoramento

65

de paciente que necessite de cuidados especiais ou de

atendimento de emergência ou socorro.

Configuração para verificação GPS: Pode ser determinada a

distância mínima de mudança de localização para verificação de

posicionamento GPS, que pode ser em centímetros, metros ou

quilômetros.

Quantidade de verificação para sincronização em determinado

tempo: o PEUP-M pode ser configurado o aplicativo para que faça

um determinado número de verificações em determinado tempo,

que poderá ser em horas, minutos ou segundos.

Intervalo de tempo de sincronização dos dados do DM com a

central PEUP: configuração de intervalo de tempo para envio dos

dados atualizados no dispositivo para a central PEUP. O intervalo

poderá ser determinado em horas, minutos ou segundos.

3.5.3 Teste de consumo de Web Service no PEUP JPPF

Inicialmente, um Web Service foi desenvolvido na linguagem de programação

Java para retornar o prontuário do paciente, com o proposito de realizar os testes

funcionais do recurso computacional. O serviço é executado em servidor GlassFish

que recebe as solicitações do paciente e aciona tarefas da grade computacional

JPPF para distribuir o processamento entre os Nodes disponíveis. Para ver exemplo

de execução desse Web Service, veja o “Apêndice F - Exemplo de teste de Web

Service para obter dados do paciente”.

Depois de informado valor do parâmetro exigido pelo exemplo acima, o

resultado em formato XML pode ser visto no “Apêndice F - Exemplo de teste de Web

Service com dados obtidos do paciente”, assim como os dados de configurações do

WSDL são demonstrados no “Apêndice F - Exemplo de teste de Web Service para

obter dados do paciente – WSDL”.

O ambiente computacional para realização do teste se deu em um laboratório

de informática com a utilização de sete máquinas físicas (Physical Machine – PM) e

66

seis máquinas virtuais (Virtual Machine – VM), conforme demonstrado na Figura 9 e

na Figura 10.

Figura 9 – Mapeamento de rede das PMs para execução de teste do PEUP na grade Computacional

JPPF.

67

Figura 10 – Mapeamento de rede da VMs para execução de teste do PEUP na grade Computacional

JPPF.

3.5.4 Criação de um Servidor Web doméstico para testes

Para a realização dos testes o ideal seria instalar todo ambiente JPPF com o

Driver, Nodes, Administrador e MySQL, além de um Servidor Web em um ambiente

próprio, pois são configurações específicas, que não estão disponíveis a preços

acessíveis, nos provedores tradicionais. Então, optou-se por produzir um ambiente

de testes doméstico.

Todo ambiente foi instalado em dois Notebooks com Windows, com rede local

entre as máquinas físicas e máquinas virtuais criadas com o software Oracle VM

VirtualBox. No entanto, como disponibilizar o acesso através da Web, com baixo ou

nenhum custo adicional?

O problema foi solucionado através das seguintes ações:

• Criação de um domínio no registro.br (peup.adm.br);

68

• Criação de uma hospedagem de redirecionamento na LocaWeb;

• Criação de um subdomínio para resolver DNS dinâmicos no no-ip.com;

• Configuração do roteador de internet (Modem Mini ADSL Sem Fio W-

M1120) para enviar os IPs dinâmicos ao no-ip.com;

• Configuração no provedor LocaWeb para redirecionar as entradas de

peup.adm.br para o no-ip.com (subdomínio peup-sp.no-ip.org:88);

Na Figura 11 pode ser observado um diagrama do modelo de comunicação

que foi adotado para a realização dos testes.

Os testes resumem-se no acesso ao PEUP através dos seguintes passos:

Chamada ao link http://www.peup.adm.br na nuvem;

Redirecionado automaticamente para o no-ip no endereço peup-sp-no-

ip.org que redireciona para o roteador local;

O roteador redireciona para o equipamento local onde se encontra o

conjunto de computadores físicos ou virtuais com a Grade JPPF

instalada e configurada para responder as solicitações.

Figura 11 – Modelo de comunicação adotado nos testes.

Notebooks: Equipamentos

físicos (Windows)

Registro.br: peup.adm.br

No-ip.com: peup-sp.no-ip.org

VMs (JPPF - Driver, Node,

MySQL), instaladas no notebook 2.

VM (JFFP - Admin e Web-Server Java), instalado no notebook 1

69

O detalhamento da implementação da grade computacional JPPF está

descrito no “Apêndice D - Ambiente de testes da grade computacional JPPF”. O

domínio peup.adm.br e o subdomínio peup-sp.no-ip.org foram criados apenas para

testes de acesso direto à grade computacional JPPF. Neste anexo, está sendo

apresentada a criação do ambiente, através da criação de VMs que compõe a grade

computacional JPPF, sendo:

- Uma VM para o Driver JPPF (encarregado de gerenciar a execução das

tarefas distribuídas na grade);

- Uma VM Node JPPF (nó encarregado de fazer o processamento solicitado

pelo Driver JPPF);

- Uma VM para o Banco de Dados que será acessado pelos processamentos

realizados pelas tarefas distribuídas nos Nodes;

- Uma VM Admin JPPF para monitorar e gerenciar toda grade computacional

JPPF.

A grade computacional JPPF pode a qualquer momento agregar outros

Drivers e Nodes, tanto quanto forem necessários para que o bom desempenho dos

processamentos necessários.

70

4 RESULTADOS

O resultado deste projeto foi obtido pelas respostas dos serviços

disponibilizados nos servidores de conteúdo e do aplicativo para DM, conforme

apresentado a seguir.

4.1 PRONTUÁRIO NO SERVIDOR

Os serviços foram disponibilizados em servidores de diferentes configurações.

Um dos servidores utilizados foi um provedor popular de internet e o outro, um

servidor de Grade Computacional JPPF. Para uma melhor ideia da distribuição do

ambiente de testes da grade computacional JPPF, pode ser consultado o “Apêndice

E - Criação de um Servidor Web doméstico para testes”.

O prontuário no servidor Web se conecta diretamente a grade computacional,

pode ser acessada e atualizada por profissionais da saúde em geral. Estes

profissionais atualizam os prontuários dos pacientes de acordo com os atendimentos

realizados.

Cada Central PEUP se comunica com as outras centrais através de

sincronização de bancos de dados pela plataforma JPPF, sempre que for necessário

o transporte de um grande volume de informações, que é o caso da transferência

entre servidores da síntese estendida ou completa do paciente.

No caso da disponibilização da síntese dos dados a serem sincronizados com

os dispositivos móveis dos pacientes, observou-se que um pequeno aplicativo

desenvolvido e instalado no servidor JPPF sincronizando com o servidor em Nuvem,

dá ganho de desempenho e maior disponibilidade para o paciente. Vale observar

também que nos testes realizados com acesso diretamente à plataforma JPPF

utilizou-se do recurso de um DNS para resolver Web Sites que não possuem

numero de IP fixo (no-ip.com). Este recurso influencia negativamente o desempenho

de comunicação, pois exige maior quantidade de processamento a cada acesso que

é realizado na base do PEUP.

Na Figura 12 é apresentado um esquema do processo de sincronização dos

dados a serem disponibilizados aos pacientes através do aplicativo em execução no

71

servidor de grade computacional (Central PEUP). As Centrais PEUP se conectam

com o servidor Web em Nuvem e os pacientes também se conectam com a Nuvem

com seus dispositivos móveis.

É importante destacar que cada Central PEUP (1, 2 e 3) apresentada na

Figura 12, corresponde a uma rede que composta por grades computacionais JPPF

de cada região.

Desta forma, cada Central PEUP se comunica uma com a outra através do

modelo definido por Azanha e Oliveira (2014), e se comunicam com o servidor em

Nuvem para facilitar o acesso à síntese do PEUP de forma simplificada e ágil.

Figura 12 – Sincronização de dados entre JPPF e Servidor em Nuvem.

Cada Central PEUP (ou grade computacional JPPF) atualiza a síntese do

paciente na Nuvem assim que houver dados novos. Isso garantirá que assim que o

paciente acessar com seu sistema no DM (manualmente ou através de tarefa

agendada, periódica), os dados estarão atualizados.

Cada Central PEUP pode através do mesmo software de sincronização,

buscar na Nuvem dados de outra Central PEUP em relação à síntese que não esteja

atualizada localmente. Desta forma, garante-se a redundância dos dados da síntese

que não fica dependente de apenas uma Central PEUP. Neste caso, mesmo que

uma ou mais Centrais PEUP fiquem temporariamente inacessível, as demais

tratarão de manter os dados da síntese disponíveis na Nuvem.

Utilizando-se um servidor em nuvem para centralizar as informações a serem

disponibilizadas como síntese dos prontuários aos pacientes, evita-se também que o

72

aplicativo no dispositivo tenha que identificar o servidor PEUP de acesso aos dados

via GPS.

Uma das premissas definidas na metodologia do projeto baseia-se em:

“Buscar síntese do paciente em uma central PEUP, geograficamente mais próxima

do paciente”.

Com a utilização desta ferramenta de sincronização, essa premissa está

sendo alterada e se justifica, através da identificação do auto consumo de bateria

dos dispositivos quando há a necessidade em manter o GPS ativo por muito tempo

e a possibilidade de não ter acesso de imediato ao servidor PEUP mais próximo por

falta de conexão, fazendo com que o aplicativo tenha que continuar tentando outros

endereços até conseguir a sincronização desejada.

A identificação do posicionamento GPS do paciente passa a ter a

necessidade de utilização apenas quando for necessário em casos especiais, do

monitoramento remoto do mesmo por alguma necessidade específica.

Veja tela de configuração de conexões do software de sincronização (Central PEUP

Control) na Figura 13.

73

Figura 13 – Software sincronizador entre Central PEUP e servidor Web em Nuve.

4.2 PRONTUÁRIO NO DISPOSITIVO MÓVEL

O PEUP-M é responsável por averiguar de tempos em tempos se há novas

informações no servidor disponibilizadas pelas Centrais PEUP para serem

atualizados no DM do paciente.

A sincronização e o intervalo de tempo entre cada sincronização é

parametrizada no aplicativo do DM. O exemplo dessa parametrização pode ser visto

através das seguintes figuras:

A Figura 14 apresenta os principais parâmetros definidos e um botão que dá

acesso para redefinição desses parâmetros e a Figura 15 apresenta a lista de

opções de parâmetros que podem ser redefinidos;

74

Figura 14 - Tela de Parâmetros Figura 15 - Tela de redefinição de parâmetros

A Figura 16 e a Figura 17, apresentam telas de ajustes do intervalo de tempo

entre as checagens de mudança de localização GPS e a Figura 17 apresenta a tela

de ajustes de distância de apontamentos do GPS para que seja considerada

mudança de locomoção do paciente;

75

Figura 16 - Tela – Edição de checagens Figura 17 - Tela – Edição de distância

A Figura 18 apresenta a tela de ajustes do intervalo de tempo entre as

sincronizações com a Central PEUP e a Figura 19 apresenta a tela inicial do

aplicativo, toda vez que for iniciado (desde que não seja a primeira execução, que

não depende mais de sincronização).

Os itens “Alt:” e “Vel:” da Figura 19 correspondem à altitude e velocidade

retornados pelo GPS e não foram utilizados no escopo deste trabalho.

76

Figura 18 - Tela – Edição sincronização Figura 19 - Tela – Apresentação inicial

Uma vez que o PEUP-M entende que a síntese do paciente deve ser

atualizada, ele tenta fazer a atualização automaticamente. Caso não seja possível

devido à falta de conexão com a internet, a atualização é efetivada assim que a

conexão for retomada.

Vale observar que o limite de armazenamento varia de acordo com o modelo

dos DM devido a capacidade de armazenamento livre cada dispositivo.

Outros modelos de dispositivos podem ser utilizados para execução do

aplicativo. Em modelos mais antigos o aplicativo pode não corresponder,

observando porem que, os modelos utilizados para testes já não são modelos de

última geração. Conforme “Apêndice G - Tela de criação de aplicativos da IDE

Android Studio”, utilizando-se a API 14 para Android 4.0, a abrangência de

compatibilidade é de 94%.

Considerando-se que cada registro de LOG de GPS necessite de 16 bytes

para armazenar (CPF, latitude, longitude, altitude e velocidade), armazenando um

registro de locomoção por minuto, teríamos a necessidade de um espaço de 675

kbytes para armazenar um mês de LOG.

77

Toda vez que o aplicativo sincroniza os dados com o servidor, uma

mensagem é exibida no dispositivo, conforme mostra a Figura 20, que apresenta a

tela inicial do PEUP-M em um DM Samsung Galax Tab II.

Figura 20 - Tela inicial do PEUP-M no Samsung Galax Tab II com Android

A Figura 21 apresenta um exemplo da exibição da síntese do paciente,

também em um DM Samsung Galax Tab II.

Figura 21 - Tela de visualização de Síntese do PEUP-M em um Samsung Galax Tab II

Os dados apresentados são inseridos por profissionais da saúde em

atendimento hospitalar ou ambulatorial por interface do sistema PEUP. Para facilitar

a complementação da síntese, pode ser utilizado um banco de palavras e frases

78

formado pelos próprios profissionais da saúde que definem novas palavras e frases

a serem inseridos ao repositório.

4.3 DISPONIBILIDADE DA SÍNTESE OFF-LINE

O PEUP com o poder de seu processamento dinâmico e expansível através

da grade computacional JPPF resolve a questão do processamento e

armazenamento dos prontuários completos em diversas Centrais PEUP espalhadas

pelo país (AZANHA; OLIVEIRA, 2014).

O software sincronizador instalado em cada Central PEUP é responsável pelo

envio dos dados recentes referente às sínteses para um servidor Web em Nuvem. O

aplicativo PEUP-M instalado nos dispositivos móveis dos pacientes é responsável

em atualizar os dados nos dispositivos, através da sincronização com o servidor

Web na Nuvem sempre que possível e necessário.

Desta forma, a síntese do paciente estará em seu poder. Em seu celular ou

tablet para ser utilizado sempre que necessário, mesmo que o dispositivo não esteja

conectado à internet no momento de sua necessidade.

Alguns testes foram realizados para identificar o tempo de sincronização dos

dados diretamente do DM com a Central PEUP para validação do método. Observe

os resultados obtidos analisando a Tabela 4.

Tabela 4 – Teste de sincronização entre dispositivos e servidores.

Tempo de acesso em segundos - Plataforma JPPF e Servidor em nuvem

[J]P

PF

x

[N]u

vem

Dis

po

sitivo

Qtd

e.

de

A

mo

stra

s

Mé

dia

s

Me

dia

nas

Desvi

o

Pa

drã

o

Err

o

Pa

drã

o

J Tablet Samsung 30 18,1333 18,0 15,025 0,2743

J Celular LG 30 17,6667 17,5 16,678 0,3045

N Tablet Samsung 30 2,87 2 2,7258 0,4977

N Celular LG 30 2,57 3 0,9714 0,1774

Para realização dos testes demonstrados, foi utilizado o Teste t de amostras

pareadas de análise estatística.

79

Para validar o modelo, primeiramente foram realizados 30 testes de busca da

Síntese na plataforma JPPF por dispositivos Tablet Samsung modelo GT-P3100,

Android 4.0 e 30 testes em Celular LG modelo LG-E467f Android 4.1.

As duas primeiras linhas da Tabela 4 apresentam os 30 testes em cada

dispositivo acessando a plataforma JPPF e a terceira e quarta linha apresentam os

30 testes em cada dispositivo acessando as informações em nuvem.

Os acessos ao servidor em nuvem foi bem mais rápido, variando entre 2 e 3

segundos em média, em acessos que levaram de 1 a 13 segundos, enquanto que o

acesso à plataforma JPPF foi mais estável, variando entre 13 e 24 segundos.

4.4 TESTES DE INTEGRIDADE E DESEMPENHO DE SINCRONIZAÇÃO

Para os testes de integridade foi criado um mecanismo de hash gerado pelo

servidor e enviado via Web Service para o dispositivo. No dispositivo, outro hash é

gerado pelo aplicativo PEUP-M com os dados recebidos, que é validado com o hash

recebido do servidor. Se houver divergência, nova solicitação da síntese deve ser

enviada ao servidor.

Os testes apresentaram uma variação relevante em relação às

inconformidades e erros. As inconformidades são as ocorrências em que o aplicativo

faz o upload da síntese no servidor middleware e o hash calculado pelo aplicativo

não confere com o que foi enviado pelo servidor. Neste caso, os dados devem ser

descartados, pois eles estão corrompidos. Já os erros, são as ocorrências em que

houve algum tipo de erro de comunicação ou falha de conexão, de modo que

nenhum dado da síntese foi retornado do servidor para o DM. A conexão menos

estável foi a LG 3G (pré-pago) que apresentou erros e uma quantidade menor de

inconformidades. Entre as três conexões semelhantes (LG Wi-Fi, LG 3G+ e

Samsung Wi-Fi) e mais estáveis não foram identificados erros. A melhor conexão

consequentemente obteve menor quantidade de inconformidades.

A Tabela 5 apresenta os testes realizados em dois dispositivos diferentes (um

LG e um Samsung). Foram realizados 400 testes e esses 100 testes foram divididos

em 4 configurações diferentes, sendo: a) Celular LG com rede Wi-Fi com velocidade

de 300 Mbps; b) Celular LG com rede 3G+ de aproximadamente 200 Mbps; c) Tablet

80

Samsung Wi-Fi de 300 Mbps; d) Celular LG 3G de velocidade inferior à 300 Mbps e

intermitente (pré-pago).

Tabela 5 – Teste de integridade e desempenho na sincronização

a) LG Wi-Fi

b) LG 3G+

c) Samsung

Wi-Fi

d) LG 3G

(pré-pago)

Operações realizadas com sucesso 90 95 93 73

Média (tempo em segundos) 1,41 2,97 1,09 3,67

Mediana (tempo em segundos) 1 2 1 3

Quantidade de inconformidades 10 5 7 1

Quantidade de erros 0 0 0 26

Total de inconformidades e erros: 10 5 7 27

Total de operações 100 100 100 100

% Sucesso na operação 90% 95% 93% 73%

Em continuidade à análise dos valores apresentados na Tabela 5, observar os

gráficos apresentados no Gráfico 1 e Gráfico 2 para constatar os diferentes

resultados entre os quatro testes realizados:

Gráfico 1 - Teste de integridade e desempenho – Sucesso x Inconformidades e erros

Os testes demonstraram que:

Mesmo com conexão de internet de baixa qualidade é possível fazer a

sincronização com o dispositivo móvel. No entanto, os testes demonstram

0

10

20

30

40

50

60

70

80

90

100

a) b) c) d)

105 7

27

9095 93

73Total deinconformidadese erros:

Operaçõesrealizadas comsucesso

81

um aproveitamento de 73% das tentativas, quando que na melhor

hipótese, o aproveitamento é de 95%.

Os testes realizados em redes Wi-Fi e 3G+ não apresentaram erros de

conexão com o servidor, mas apresentaram um número maior de

inconformidade de inconsistência do hash. Já os testes realizados em rede

3G (pré-pago), apresentaram 26% de erros e apenas 1% de

inconformidade.

O retorno mais rápido foi obtido pelo DM Samsung em rede Wi-Fi com

tempo médio de 1,09 segundos por sincronização.

Gráfico 2 - Teste de integridade e desempenho – Tempo de sincronização

O Gráfico 2 apresenta a média e mediana dos tempos obtidos para a

sincronização da síntese, durante os testes, nos quatro tipos de conexão. Os tempos

médios para se obter a síntese varia entre 1,09 segundos na conexão de maior

velocidade e 3,67 segundos na conexão de menor velocidade.

0

0,5

1

1,5

2

2,5

3

3,5

4

a) b) c) d)

1,41

2,97

1,09

3,67

1

2

1

3 Média (tempoem segundos)

Mediana(tempo emsegundos)

82

5 CONCLUSÕES

Esse trabalho se originou da necessidade de disponibilização da síntese do

PEUP em DM dos pacientes, com possibilidade de acesso pelos profissionais da

saúde em situações de urgência, emergência ou atendimento de rotina, mesmo em

situações em que não se tenha acesso à internet. O objetivo foi atingido através do

desenvolvimento de um modelo de disponibilização do PEUP em DM. Foi criado um

aplicativo que executa os acessos e operações previstos no modelo. Dessa forma,

foi possível avaliar os acessos à central de armazenamento do PEUP. A central

PEUP, desenvolvida em grade computacional JPPF, foi modificada para manter as

atualizações da síntese do paciente nos DM.

Os testes realizados envolveram uma grade computacional JPPF completa e

um conjunto de funcionalidades desenvolvidas para acesso e sincronização com a

Central PEUP. Essas funcionalidades foram instaladas em um servidor em nuvem

para servir de middleware, fazendo a interação entre as Centrais PEUP e o

aplicativo do DM do paciente.

Em análise comparativa com os modelos e softwares pesquisados, foi

identificado que o modelo PEUP-M traz avanços em relação à disponibilização do

PEUP. As principais vantagens são: o modelo tem a possibilidade de ser utilizado de

forma ampla, ou seja, por grande número de pessoas e num grande território, como

o Brasil. Ele não depende de conexão, em tempo integral, com a internet, pois

mantem os dados off-line para consulta e atualizações no DM, até que consiga

novamente conexão com a internet para sincronizar novamente as atualizações com

o servidor middleware.

Outra vantagem do modelo PEUP-M é a utilização da síntese como um

conjunto de informações relevantes para atendimentos de urgência ou emergência e

que se adequa ao pouco espaço disponível nos DM. Comparado aos demais

modelos de PEP ou PUP que utilizam apenas um nível de informação (o prontuário

completo) este modelo representa um avanço no que se refere à disponibilidade de

informações relevantes. Pois, o prontuário completo é composto por grande volume

de dados, o que o torna inviável seu uso corriqueiro e principalmente em DM. Além

disso, o prontuário completo está repleto de informações com pouca ou nenhuma

relevância para a grande maioria dos atendimentos, ou que os profissionais de

83

saúde não irão ler para realizar os atendimentos. Já no modelo proposto nesta

pesquisa, o PEUP é estratificado em três níveis de informação o que diminui

drasticamente o volume de dados, mantendo somente as informações relevantes

com disponibilidade em tempo real, mesmo em dispositivos com baixa capacidade

de processamento e de memória, como os dispositivos móveis.

5.1 TRABALHOS FUTUROS

Em trabalhos futuros, pode-se considerar a utilização desse modelo como

sendo um “guardião” do paciente. Uma vez que, através da síntese no DM do

paciente, há a possibilidade de rastreamento com a melhoria dos canais de

comunicação. Além disso, tem-se a possiblidade de determinar que o aplicativo

auxilie nos cuidados com o paciente de muitas outras formas, por exemplo:

- Acoplar dispositivos de leitura de batimento cardíaco, pressão, etc.

- Contatar uma central para ajuda ou socorro em caso de necessidade.

Enfim, a tecnologia móvel tem muito a agregar na área da saúde para ajudar

as pessoas preventivamente, evitando complicações em determinados quadros,

prolongando a vida com qualidade e até, salvando vidas ao detectar

inconformidades com o organismo do paciente, a tempo de busca de socorro.

84

REFERÊNCIAS

ADESINA A.O., AGBELE K.K., FEBRUARIE R., ABIDOYE A.P., NYONGESA H. O.

Ensuring the security and privacy of information in mobile health-care

communication systems. S Afr J Sci. 2011;107(9/10), Art. #508, 7 pages.

doi:10.4102/sajs. v107i9/10.508. Disponível em:

<http://www.sajs.co.za/sites/default/files/publications/pdf/508-5883-8-PB.pdf>.

Acesso em: 15 ago 2015.

ANDROID, Developers. Security Tips. Disponível em:

<http://developer.android.com/training/articles/security-tips.html>. Acesso em: 24 mai

2014.

ANS, Agência Nacional de Saúde Suplementar. TISS - Versão 2.0. Disponível em:

<http://www.ans.gov.br/espaco-dos-prestadores/tiss/1760-padrao-tiss-20203>.

Acesso em: 20 set 2015a.

__________. Padrão TISS – Versão 3.02.00 - Material de Divulgação. Disponível

em:

<http://www.ans.gov.br/images/stories/Plano_de_saude_e_Operadoras/tiss/Padrao_t

iss/tiss3/20120103_apresentacao_padrao_tiss_versao_30000.ppt>. Acesso em: 20

set 2015b.

__________. Padrão para Troca de Informação de Saúde Suplementar – TISS.

Disponível em: <http://www.ans.gov.br/prestadores/tiss-troca-de-informacao-de-

saude-suplementar>. Acesso em: 20 set 2015c.

ANSI, AMERICAN NATIONAL STANDARDS INSTITUTE. ANSI/HL7 EHR, R1-2007.

February 12, 2007. The HL7 EHR System Functional Model, Release 1. Chapter

One: Overview. Copyright © 2007 HL7.

AZANHA NETO, J. S.; OLIVEIRA, H. J. Q. Novo modelo de banco de dados para

gestão do Prontuário Eletrônico Único do Paciente. 2014. Dissertação (Mestrado

em Engenharia Biomédica). Universidade de Mogi das Cruzes, Mogi das Cruzes,

2014.

BLUMENTHAL David, M.D., M.P.P., and Tavenner Marilyn, R.N., M.H.A. The

“Meaningful Use” Regulation for Electronic Health Records. Perspective. august

5, 2010. Pag 501-504. Disponível em:

<http://www.nejm.org/doi/pdf/10.1056/NEJMp1006114>. Acesso em: 01 jul 2015.

85

BRASIL. Conselho Federal de Medicina. Resolução CFM nº 1.331/1989. Conarq Arquivo Nacional. Brasilia-DF, 1989.

____________. Conselho Federal de Medicina. Resolução CFM nº 1.639/2002.

Aprova as "Normas Técnicas para o Uso de Sistemas Informatizados para a

Guarda e Manuseio do Prontuário Médico", dispõe sobre tempo de guarda dos

prontuários, estabelece critérios para certificação dos sistemas de informação

e dá outras providências. Brasília-DF, 10 jul 2002.

____________. Ministério da Saúde. Portaria nº 2.073, de 31 de agosto de 2011.

Regulamenta o uso de padrões de interoperabilidade e informação em saúde

para sistemas de informação em saúde no âmbito do Sistema Único de Saúde,

nos níveis Municipal, Distrital, Estadual e Federal, e para os sistemas privados

e do setor de saúde suplementar. Diário Oficial da União, Poder Executivo,

Brasília, DF, 1 set. 2011. Seção 1. p. 63. Disponível em:

<http://bvsms.saude.gov.br/bvs/saudelegis/gm/2011/prt2073_31_08_2011.html>.

Acesso em: 08 ago 2015.

____________. Ministério da Saúde. Portaria nº1.905 de 6 de setembro de 2013.

Institui o Sistema de Regulação, Controle e Avaliação (SISRCA), no âmbito do

Ministério da Saúde. Disponível em:

<http://bvsms.saude.gov.br/bvs/saudelegis/gm/2013/prt1905_06_09_2013.html>.

Acesso em: 08 nov 2015.

CADSUS, Sistema de Cadastramento de usuários do SUS. Disponível em:

<http://datasus.saude.gov.br/index.php/sistemas-e-aplicativos/cadastros-

nacionais/cadsus>. Acesso em 03 mai 2014.

CERT.BR. Cartilha de Segurança para Internet. Disponível em:

<http://cartilha.cert.br/mecanismos>. Acesso em 29 dez 2015.

CNES, Cadastro Nacional de Estabelecimentos de Saúde. Disponível em:

<http://datasus.saude.gov.br/index.php/sistemas-e-aplicativos/cadastros-

nacionais/cnes>. Acesso em 03 mai 2014.

COMPUTERWORLD. Dez dicas para jovens talentos que querem dominar

Cobol. Disponível em: <http://computerworld.com.br/carreira/2013/08/19/dez-dicas-

para-jovens-talentos-que-querem-dominar-cobol>. Publicado em 19 ago 2013.

Acesso em: 07 set 2014.

COSTA, Claudio Giulliano Alves da. Cartilha Sobre Prontuário Eletrônico: A

certificação de sistemas de registro Eletrônico em Saúde. Conselho Federal de

Medicina (CFM) e da Sociedade Brasileira de Informática em Saúde. 2012.

Disponível em:

86

<http://portal.cfm.org.br/crmdigital/Cartilha_SBIS_CFM_Prontuario_Eletronico_fev_2

012.pdf>. Acesso em: 04 jun 2015.

CRESSWELL, Kathrin M; WORTH, Allison; SHEIKH, Aziz. Comparative case study

investigating sociotechnical processes of change in the context of a national

electronic health record implementation. Health Informatics Journal, 2012,

Vol.18(4), pp.251-270.

DATASUS. Farmácia Popular. Disponível em:

<http://datasus.saude.gov.br/index.php/noticias/55-farmacia-popular>. Acesso em 03

mai 2014a.

________. DATASUS usa BI para gestão de medicamentos. Disponível em:

<http://datasus.saude.gov.br/index.php/noticias/atualizacoes/378-datasus-usa-bi-

para-gestao-de-medicamentos>. Publicado em: 18 mar 2014. Acesso em 03 mai

2014b.

________. SAMU. Disponível em: <http://datasus.saude.gov.br/index.php/sistemas-

e-aplicativos/regulacao/samu>. Acesso em 03 mai 2014c.

DRCHRONO. DrChrono. Disponível em: <https://www.drchrono.com>. Acesso em:

01 mai 2014.

ECLIPSE. Eclipse Project: About the Eclipse Project. Disponível em:

<http://www.eclipse.org/eclipse>. Acesso em: 07 set 2014.

ETI. Instituto Nacional de Tecnologia da Informação. SOBRE CERTIFICAÇÃO

DIGITAL. Publicação: 11 ago 2012. Disponível em: <http://www.iti.gov.br/perguntas-

frequentes/1743-sobre-certificacao-digital>. Acesso em: 23 jul 2014.

FRITZ, Fleur; STÄNDERF, Sonja; BREIL, Bernhard; RIEK, Markus; DUGAS, Martin.

CIS-based registration of quality of life in a single source approach. U.S.

National Library of Medicine (NIH/NLM). BMC Medical Informatics and Decision

Making, 2011, Vol.11, p.26-2.

GADELHA, Augusto. Registro Eletrônico de Saúde para o Brasil. CBIS.

DATASUS/SGEP/MS. Documento de 22 Novembro 2012. Disponível em:

<http://sbis.org.br/cbis2012/apresentacoes/c04_01.pdf>. Acesso em: 22 fev 2014.

GILLUM, Richard F. From Papyrus to the Electronic Tablet: A Brief History of the

Clinical MedicalRecord with Lessons for the Digital Age.The American Journal of

Medicine, 2013, Vol.126(10), pp.853-857.

87

GSMA. About Us. Disponível em: <http://www.gsma.com/aboutus>. Acesso em: 10

ago 2014.

HARZHEIM, Erno. INOVANDO O PAPEL DA ATENÇÃO PRIMÁRIA NAS REDES DE ATENÇÃO À SAÚDE: Resultados do Laboratório de Inovação em quatro capitais brasileiras. Brasília-DF, 2011. Disponível em: <http://www.cff.org.br/userfiles/23 - ORGANIZAÇÃO PAN-AMERICANA DA SAÚDE_ Inovando o papel da atenção primária nas redes de atenção à saúde.pdf>. Acesso em: 02 nov 2015.

HELLOHEALTH. Ganancias Inesperadas Porque usted lo merece. Disponível em:

<http://hellohealth.mx>. Acesso em: 18 mai 2014a.

_____________. Sobre Nosotros - Myca Health, la empresa detrás de Hello

Health México. Disponível em: <http://hellohealth.mx/sobre-nosotros>. Acesso em:

18 mai 2014b.

_____________. La Plataforma Hello Health. Disponível em:

<http://hellohealth.mx/ganancias-concepto-de-salud-digital>. Acesso em: 18 mai

2014c.

_____________. Portal de Pacientes. Disponível em:

<http://hellohealth.mx/soluciones/portal-de-pacientes>. Acesso em: 18 mai 2014d.

HL7, International. Section 3: Clinical and Administrative Domains HL7 Version 3

Normative Edition, 2015. Disponível em:

<http://www.hl7.org/implement/standards/product_brief.cfm?product_id=404>.

Acesso em: 15 ago 2015.

HOSKINS, Mike. Glucose Testing via Earlobe, Not Stressful Fingersticks.

Disponível em: <http://www.diabetesmine.com/2014/04/glucose-testing-via-

earlobe.html>. Acesso em: 30 set 2015.

INTEL. China’s Anhui Province Uses Intel®-based Storage to Support Digital

Hospitals. Disponível em:

<http://media13.connectedsocialmedia.com/intel/05/10335/China_Anhui_Province_In

tel_based_Storage_Support_Digital_Hospitals.pdf>. Acesso em: 16 ago 2015.

ISO – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/TR

20514:2005. Health informatics -- Electronic health record -- Definition, scope

and context. ISO 2005. Diosponível em:

<https://www.iso.org/obp/ui/#iso:std:39525:en>. Acesso em 29 set 2015.

88

JOIA, Luiz Antonio; MAGALHÃES, Carlos. Evidências empíricas da resistência a

implantação de prescrição eletrônica. RAC - Electronica, Jan-April, 2009, Vol.3(1),

p.81(24).

LIFECODE. Bracelete LifeCode Preto - L - 19,5 cm. Disponível em:

<http://www.mylifecode.com.br/bracelete/10>. Acesso em 31 mai 2014.

LIMA, Michele Nogueira. SAÚDE MÓVEL: Conceitos, Iniciativas e Aplicações.

Curitiba: Edição do Autor.1ª Edição. Impresso por AlphaGraphics Bela Veista. São

Paulo, 2010.

LINDEN, A.W.N. van. Connecting health care professionals : studies on a

generic EHR system framework : how generic can you get?. 2009. Disponível

em: <http://digitalarchive.maastrichtuniversity.nl/fedora/get/guid:d349ad43-35f2-

4860-84bf-5255402d49ee/ASSET1>. Acesso em: 05 jul 2015.

LOBACK, D. F.; DETMER, D. E. Research Challenges for Electronic Health Records.

American Journal of Preventive Medicine, May 2007, Vol.32(5), pp.S104-S111.

LOBO, Ana Paula. Teles preveem investimentos de US$ 1,7 trilhão em redes de

banda larga até 2020. Telebrasil – Associação Brasileira de Telecomunicações.

Disponível em: <http://www.telebrasil.org.br/sala-de-imprensa/na-midia/5475-teles-

preveem-investimentos-de-us-1-7-trilhao-em-redes-de-banda-larga-ate-2020>.

Publidado em: 24 fev 2014. Acesso em: 10 ago 2014.

_____________. Brasil fica para trás no consumo de apps na América Latina.

Convergência Digital. Disponível em:

<http://convergenciadigital.uol.com.br/cgi/cgilua.exe/sys/start.htm?infoid=39343&sid=

17#.VjUquyu2psk>. Acesso em: 31 out 2015.

Marin H. F.; Weber P. Personal Health Record: the Nursing Outlook. J. Health

Inform. 2014 Julho-Setembro; 6(3): 89-91. Disponível em: <http://www.jhi-

sbis.saude.ws/ojs-jhi/index.php/jhi-sbis/article/view/275>. Acesso em: 04 jun 2015

MEDSENSORS, C8 MedSensors. Pair it. Wear it. Know it. Disponível em:

<http://www.ddacorp.com/images/casestudies/c8-video/c8-tradeshow-video-3.jpg>.

Acesso em: 20 set 2015.

METZDORF, Kerry. DrChrono Launches First EHR App That Leverages AirDrop

to Enable Doctors and Patients to Securely Share Electronic Health Records on

Mobile Devices. SOURCE: drchrono. September 19, 2013 09:00 ET. Disponível em:

<http://www.marketwired.com/press-release/drchrono-launches-first-ehr-app-that-

leverages-airdrop-enable-doctors-patients-securely-1832645.htm>. Aceso em: 04

mai 2014.

89

MOECKE, Cristian Thiago; SUTIL, Jeandré Monteiro; KOHLER, Jonathan Gehard;

CARLOS, Marcelo Carlomagno. Introdução a Infraestrutura de Chaves Públicas e

Aplicações. Escola Superior de Redes RNP. Distribuição sob licença da Creative

Commons: Atribuição e Uso Não-Comercial 2.5 Brasil. Brasília-DF. 2010. Disponível

em:

<http://esr.rnp.br/publicacoes/seguranca/icpedu?download=44f683a84163b3523afe5

7c2e008bc8c>. Acesso em: 23 jul 2014.

MIAZAKI, Aline Paterno; ODA, Diogo Yochizumi; NUNCIO, Fábio Henrique de;

ALCADIPANI, Marília Soares e Silva; ALCADIPANI, Fernando Antônio Maria Claret.

Prontuário Único do Paciente: ambulatório de especialidades da Faculdade de

Medicina de Jundiaí. Perspectivas Médicas, 22(2): 5-10, jul./dez. 2011. DOI:

10.6006/perspectmed.22.010211.

NHS ENGLAND. High quality care for all, now and for future generations.

Disponível em: <http://www.england.nhs.uk>. Acesso em: 02 mai 2014.

NIMLOS, Allison Blass. New Non-Invasive Continuous Glucose Monitor Will Talk

to Your SmartPhone. Disponível em: <http://www.diabetesmine.com/2011/10/new-

non-invasive-continuous-glucose-monitor-will-talk-to-your-smartphone.html>.

Publicado em: 3 out 2011. Acesso em: 31 ago 2014.

ORTIZ, C. Enrique. Entendendo segurança no Android. J2MEDeveloper.com. IBM

developer Works. 22/Dez/2010. Disponível em:

<http://www.ibm.com/developerworks/br/library/x-androidsecurity/#toggle>. Acesso

em: 24 mai 2014.

PELLEGRINI, Giuseppina. O Novo Padrão TISS 3.01 – Mudanças e Atualizações. In:

SEMINÁRIO - UNIVERSIDADE CORPORATIVA ABRAMGE, São Paulo: 2014. Realizado

em 30 mai 2014.

PINOCHET, Luis Hernan Contreras. Tendências de Tecnologia de Informação na Gestão da Saúde. O MUNDO DA SAÚDE, São Paulo: 2011;35(4):382-394. Disponível em: <http://www.saocamilo-sp.br/pdf/mundo_saude/88/03_TendenciasdeTecnologia.pdf>. Acesso em: 16 ago 2015.

REIS, Fábio. Criptografia - Introdução e Princípios Básicos – 01. Disponível em:

<https://www.youtube.com/watch?v=cWld3rMD7Wk>. Acesso em: 20 jul 2014.

SAUDE BUSINESS. IPDFARMA. Pesquisadores enviam carta à presidente por melhora na pesquisa clínica. Disponível em: <http://www.ipd-farma.org.br/noticias/pagina/977/Pesquisadores-enviam-carta-a-presidente-por-melhora-na-pesquisa-clinica>. Acesso em: 30 set 2015.

90

SBIS, Sociedade Brasileira de Informática em Saúde. Manual de Certificação para

Sistemas de Registro Eletrônico em Saúde (S-RES) Versão 4.1. Certificação

2013. Editor: Marcelo Lúcio da Silva. Disponível em:

<http://www.sbis.org.br/certificacao/Manual_Certificacao_SBIS-CFM_2013_v4-

1.pdf>. Acesso em: 09 ago 2015.

SHIH, S. C.; MCCULLOUGH, C. M.; WANG, J. J.; SINGER, J.; PARSONS, A. S.

Health information systems in small practices: Improving the delivery of

clinical preventive services. American Journal of Preventive Medicine, December

2011, Vol.41(6), pp.603-609.

SIEGLER, Eugenia L. The evolving medical record. History of Medicine. Annals of

Internal Medicine, Nov 16, 2010, Vol.153(10), p.671(7).

SISREG. Sistema Nacional de Regulação. Disponível em: <http://sisregiii.saude.gov.br/>. Acesso em 04 mai 2014.

SLAVOV, V.; Rao, P.; Paturi, S.; Swami, T.K.; Barnes, M.; Rao, D.; Palvai, R. A new

tool for sharing and querying of clinical documents modeled using HL7

Version 3 standard. Comput. Methods Programs Biomed. 2013, 112, 529–552.

SOBANIA, Luís Carlos. A Ética na Emergência. Portal Médico. CFM. Disponível em: <http://www.portalmedico.org.br/biblioteca_virtual/des_etic/15.htm>. Acesso em: 13 set 2015.

SQLite. About SQLite. Disponível em: <http://www.sqlite.org/about.html>. Acesso em: 07 set 2014.

TAKIAN Amirhossein; PETRAKAKI Dimitra; CORNFORD Tony; SHEIKH Aziz;

BARBER, Nicholas. Building a house on shifting sand: methodological

considerations when evaluating the implementation and adoption of national

electronic health record systems. BMC Health Services Research, 2012,

Vol.12(1), p.105

TELEBRASIL. Associação Brasileira de Telecomunicações. Convergência:

prestadoras de telecomunicações pressionadas para novas estruturas de

redes e novos serviços. Criado em 19 Outubro 2009. Disponível em:

<http://www.telebrasil.org.br/sala-de-imprensa/artigos/1260-convergencia-

prestadoras-de-telecomunicacoes-pressionadas-para-novas-estruturas-de-redes-e-

novos-servicos>. Acesso em: 10 ago 2014.

UNIFESP. Departamento de Informática em Saúde. Histórico. 2011 Desenvolvido

por: Setor de Desenvolvimento WEB – SDWeb. Disponível em:

<http://www2.unifesp.br/pg/dis/gestaoeinformatica/informacoes/copy_of_sobre-o-

programa>. Acesso em: 19 set 2015.

91

VIVANCO, Cintia Ribeiro; MARIN, Heimar F. RES – PEP – PPS: Evolução e o novo

paradigma sobre a responsabilidade na gestão da saúde do cidadão. Disponível

em: <http://www.sbis.org.br/cbis11/arquivos/1040.doc>. Acesso em 30 mai 2015.

WOOD, P. R. Validity of the medical record for evaluation of telephone management.

Pediatrics, 1989, Vol.84(6), pp.1027-30. Disponível em:

<http://pediatrics.aappublications.org/content/84/6/1027.short>. Acesso em: 04 mai

2014.

ZWICKER, Ronaldo; PEREZ, Gilberto; ZILBER, Moises Ari; MEDEIROS, Alberto, Jr.

Adoption of technological innovations in the field of health: a study on information

systems in the perspective of the theory of diffusion/ Adocao de inovacoes

technologicas na area de saude: um estudo sobre sistemas de informacao sob a

otica da teoria de difusao.(Report). Journal of Information Systems & Technology

Management, Jan, 2010, Vol.7(1), p.71(24).

92

APÊNDICE A - Diagramas de Casos de Uso; Modelo de Entidade e

Relacionamento (MER); Sequência – Autenticação e interação do

paciente; Sequência – Autenticação e interação do médico.

93

Casos de Uso

94

Modelo de Entidade e Relacionamento (MER)

95

Sequência – Autenticação e interação do paciente

96

Sequência – Autenticação e interação do médico

97

APÊNDICE B - Tela de bloqueio; Tela de registro de Autenticidade.

98

Tela de bloqueio Tela de registro de Autenticidade

99

APÊNDICE C – Web Services – Operações: getAutenticidade;

setDispositivo; getPaciente; GetOutroDispositivo; lockDispositivo.

100

Web Service – Operação: getAutenticidade

Web Service – Operação: setDispositivo

101

Web Service – Operação: getPaciente

Web Service – Operação: GetOutroDispositivo

102

Web Service – Operação: lockDispositivo

103

APÊNDICE D - Ambiente de testes da grade computacional JPPF.

104

Ambiente de testes da grade computacional JPPF

Para testes em equipamento local, pode-se trabalhar com Máquinas Virtuais (Virtual

Machine / VM). Claro que é um ambiente mínimo e exclusivamente para testes.

Todas as VMs foram montadas para serem executadas com o VirtualBox rodando

sobre o Windows 8, formatadas com o Sistema Operacional Linux Ubuntu. São

quatro VMs com as seguintes configurações:

Equipamento Base – Windows 8 – IP: 192.168.1.100 (comando: ipconfig via

command)

Configurações das Maquinas Virtuais:

1. DRIVER

Configuração via terminal (atalho: ^ATL+T)

IP: 192.168.1.101 (comando: ifconfig)

Configuração do JPPF - Diretório: ~/JPPF-3.3.7-driver/config

Arquivo: jppf-driver.properties (comando: nano jppf-driver.properties)

Linha: jppf.server.host = 192.168.1.101

Linha: jppf.server.port = 11111

Start do Driver no diretório: ~/JPPF-3.3.7-driver

Comando: ./startDriver.sh

105

2. NODE

Configuração via terminal (atalho: ^ATL+T)

IP: 192.168.1.102 (comando: ifconfig)

Configuração do JPPF - Diretório: ~/JPPF-3.3.7-node/config

Arquivo: jppf-node.properties (comando: nano jppf-node.properties)

Linha: jppf.server.host = 192.168.1.101

Linha: jppf.server.port = 11111

Start do Node no diretório: ~/JPPF-3.3.7-node

106

Comando: ./startNode.sh

3. ADMIN

Configuração via terminal (atalho: ^ATL+T)

IP: 192.168.1.103 (comando: ifconfig)

Configuração do JPPF - Diretório: ~/JPPF-3.3.7-admin-ui/config

Arquivo: jppf-gui.properties (comando: nano jppf-gui.properties)

Linhas: jppf.drivers = driver1

driver1.jppf.server.host = 192.168.1.101

driver1.priority = 10

driver1.jppf.management.host = 192.168.1.101

driver1.jppf.server.port = 11111

Start do Admin no diretório: ~/JPPF-3.3.7-admin-ui

Comando: ./startConsole.sh

107

4. BANCO

Instala-se o banco de dados. O importante é que o IP do banco de dados esteja sendo

utilizado na tarefa de abertura do banco na aplicação que será executada via WebServer

GlassFish no servidor (Admin).

Neste exemplo, o IP do computador com o Banco de Dados (MySQL) devidamente instalado

no S.O. Linux Ubuntu, ficou com IP: 192.168.1.104.

108

APÊNDICE E - Criação de um Servidor Web doméstico para testes.

109

Criação de um Servidor Web doméstico para testes

Configurando o Roteador

É necessário identificar o roteador para que se consiga obter informações de como

fazer a configuração adequada. No exemplo, conforme mostram as figuras abaixo

temos um Modem Mini ADSL Sem Fio W-M1120.

Entre os muitos tutoriais e materiais disponíveis na internet, um tutorial que me

auxiliou imensamente nesta configuração foi escrito pelo engenheiro Robson,

denominado: “Informação sobre Modem ADSL / Roteador WiFi 2.4GHz W-M1120

[RT63363E] E DM2277 (Revisão 01/2015)”14. O vídeo de Nilton IbáIbáñez intitulado

“servidor web casero con no-ip y xampp“ também deu boas dicas15.

Para descobrir o IP do roteador, digita-se: ipconfig /all (no Windows):

Para autenticar no roteador, foi colocado no endereço do browser:

http://192.168.1.1/padrao. Na aba de configurações, definido Login (admin) e Senha,

que são os quatro últimos dígitos do MAC do roteador, encontrado na etiqueta do

mesmo.

14 Link: http://robsoneletronico.blogspot.com.br/2015/01/informacao-sobre-modem-adsl-roteador.html 15 Link do Vídeo: https://youtu.be/R7qO3oQ6-5o

110

Para habilitar opções avançadas de configuração do roteador, foi necessário efetuar

o download do software Sagemcom 2864 Tool16

Com esta ferramenta, se obtém as configurações do roteador no botão “Get config”.

Para facilitar o trabalho, já que o arquivo contém uma grande quantidade de linhas

de comandos, pode-se copiar o texto e colar no bloco de notas. Basta encontrar a

palavra home em (role(home)) e substituir por (role(super)) como demonstrado

abaixo:

16 Download em: https://mega.co.nz/#!wF9RGJgL!iwI95LzPbnMERoYbMiOPci9AYaro9UeKIH1IQoGYB6w

111

Após a alteração, é preciso habilitar “Unlock...” na tela do Sagemcom, colar o novo

código e clicar no botão “Put config”.

Agora é só fechar o bloco de notas, o Sagemcom e voltar ao browser, digitando

novamente http://192.168.1.1/padrao e efetuando novamente a autenticação com o

usuário admin (Login: admin / Senha: 4 últimos dígitos do MAC do roteador).

Entrar em Serviços / Firewall / Encaminhamento de Porta, clicar em (nova

Entrada):

Selecione o computador local:

112

Selecione o serviço (no caso HTTP ou Web Server HTTP) e ok:

Também foi configurado o

No site do No-IP (www.noip.com), é necessário cadastrar-se e em seguida registrar

um subdomínio para acesso via Web ao servidor local:

O site www.noip.com registra o IP de conexão da internet que está sendo utilizado e

terá a tarefa de atualizar esse endereço toda vez que dinamicamente o endereço do

roteador é modificado:

113

Por fim, o site hospedado localmente passa a ser acessado pelo endereço:

http://peup-sp.no-ip.org

Liberar porta 80 para que outros computadores além do próprio computador onde

está se executando o servidor web também tenham permissão de acesso:

Clique em adicionar “Regra de Encaminhamento de Porta”:

114

Clicar em “Nova Entrada”, selecione o nome do seu computador ou “Definido pelo

Usuário”:

Informar o IP em IPv4 se solicitado (obtido pelo comando ipconfig):

Selecionar Protocolo:

De um nome para o serviço e clique em adicionar:

115

Definir o Protocolo TCP, Porta de Destino, informar o número da porta desejado e

OK:

Clicar novamente em adicionar e fazer outra entrada com as mesmas configurações,

só que para o Protocolo UDP.

Aparecerá uma tela com os protocolos configurados. Confirme:

Mais uma vez, confirmar:

116

Por fim, clicar em Aplicar / Atualizar e Ok:

Agora, efetuar a configuração em “Provocar a porta”, e selecionar “Definido pelo

Usuário” em “Adicionar”:

Definir regras da mesma forma que foi feito com o passo anterior, para que por fim

seja dado o OK na configuração:

117

Por fim, Aplicar e OK:

Agora basta dar um reboot no roteador:

Teste realizado, conectando-se em internet banda larga speedy e 3G:

peup-sp.no-ip.org:88

118

No Windows, Acessando um equipamento Linux instalado em uma VM:

Acessando pelo browser no Windows, porque a rede local que está definida para

executar a Grid JPPF nas VMs está sem acesso à Internet:

Definir o IP e depois o Protocolo HTTP e OK:

Configurar regras de porta para os protocolos TCP e UDP, porta 8080 (default do

WebServer GlassFish):

119

Direcionamento das portas através da opção “Provocar a porta”:

Aplicar e confirmar as configurações (MyWebSiteVM):

Adicionar Encaminhamento de porta:

120

Configurar serviços:

Aplicar, atualizar e confirmar:

Reiniciar o roteador e testar.

121

Criar um domínio e redirecionar através de um provedor pago (ex: locaweb)

122

Registrado redirecionamento no painel de controle da empresa contratada:

123

Execução do site: peup-sp.no-ip.org ou peup.adm.br

124

APÊNDICE F - Exemplo de teste de Web Service para obter dados

do paciente com Web Service em Java (wsPaciente); Dados obtidos

através do Web Service; Visão do WSDL.

125

Exemplo de teste de Web Service para obter dados do paciente

Exemplo de teste de Web Service com dados obtidos do paciente

126

Exemplo de teste de Web Service para obter dados do paciente – WSDL

127

APÊNDICE G - Tela de criação de aplicativos da IDE Android Studio.

128

Tela de criação de aplicativos da IDE Android Studio