UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA - UEFS
MATHEUS CARDOSO DE ANDRADE SILVA
UMA PROPOSTA DE ADOÇÃO DO PRONTUÁRIO ELETRÔNICO
PESSOAL: INTEGRANDO SISTEMAS MÉDICOS AO GOOGLE HEALTH
FEIRA DE SANTANA
2009
MATHEUS CARDOSO DE ANDRADE SILVA
UMA PROPOSTA DE ADOÇÃO DO PRONTUÁRIO ELETRÔNICO
PESSOAL: INTEGRANDO SISTEMAS MÉDICOS AO GOOGLE
HEALTH
Dissertação apresentada como requisito parcial
à obtenção do grau de Bacharel em Engenharia
de Computação pela Universidade Estadual de
Feira de Santana
Orientador: Professor Mestre Kellyton Brito
FEIRA DE SANTANA
Janeiro 2009
Resumo
O prontuário médico do paciente é uma criação de médicos e enfermeiros com intuito de garantir e sistematizar a memória de fatos e eventos clı́nicos referentes a um indivı́duo. De forma
que quaisquer outros profissionais envolvidos no processo de assistência do paciente possam
ter acesso às mesmas informações. Contudo, a heterogeneidade de profissionais envolvidos
na produção, circulação de informações e conhecimentos médicos são os maiores percalços
concernentes a representação em papel do prontuário médico. A impossibilidade de acessar e
integrar dados individuais ou de grupos de pacientes registrados em documentos em papel resulta em uma visão fragmentada da evolução dos problemas de saúde.
É nesse contexto que se apresenta uma nova solução que permite a possibilidade de manter registros que reúnem toda a vida do indivı́duo e a criação de bases de dados contendo informações
clı́nicas e administrativas agregadas.O desenvolvimento deste novo conceito de prontuário baseado no poder computacional foi denominado de prontuário médico eletrônico (PME).
Embora seja proprietário de suas informações de saúde, o paciente não tem amplo acesso a estes
dados, pois, como a guarda de suas informações clı́nicas é de obrigação dos estabelecimentos
de saúde por onde foi atendido, as suas informações fragmentam-se por todos estes estabelecimentos.Por essa razão, o PME somente supre as limitações anteriores do prontuário em papel
em seus locais de origem, sem interação externa.
É nessa deficiência de interoperabilidade do PME que este trabalho apresenta a proposta de
adoção do conceito de prontuário eletrônico pessoal (PEP).Este conceito representa a habilidade de compartilhar informações médicas entre as partes interessadas (paciente, instituições
médicas, profissionais da saúde) e fazer com que as informações do paciente estejam acessı́veis
independente da modalidade ou do local do atendimento. Assim, o indivı́duo passa a controlar suas informações de saúde, atuando em conjunto com as instituições médicas para manter a
coerência e integridade de seus dados clı́nicos. E o paciente ainda poderá acessar seu prontuário
médico através da internet em qualquer lugar e a qualquer momento. É motivado pelos fatos
apresentados acima que este trabalho propõe, principalmente, disponibilizar o prontuário do
paciente através da internet às partes interessadas (e somente a elas - paciente, profissionais e
instituições de saúde), criando um protótipo, para corroborar a proposta, que comunique um
sistema de uma instituição médica real com um serviço existente de PEP.
Palavras-chave: Prontuário Médico. Prontuário Médico Eletrônico. Prontuário Eletrônico Pessoal. Paciente. Google Health.
Abstract
The patient’s medical record is a creation of physicians and nurses in order to secure and standardize the memory of facts and clinical events related to an individual. So that any other
professionals involved in patient care can access the same information. However, the diversity
of professionals involved in the production, circulation of information and medical knowledge
are the major drawbacks concerning the representation of the paper medical records. The inability to access and integrate individual data or groups of patients enrolled in paper, results in a
fragmented view of the health problems evolution.
It is in this context that presents a new solution that allows the possibility to maintain records
that meet every individual’s life and the creation of databases containing clinical information
and administrative agregadas.O developing this new concept of medical record-based computing power was called electronic medical record (EMR).
Although the owner of your health information, the patient does not have wide access to these
data because, as the care of their medical information is required of health facilities where it
was met, your information spreads up by all these institutions . For this reason, the EMRs only
supplies the previous limitations of paper records in their places of origin, without external interaction.
It is this deficiency interoperability of EMRs that this paper presents a proposal for adoption
of the concept of personal health recors (PHR). It represents the ability to share medical information among stakeholders (patient, medical institutions, health professionals) and make
accessible patient’s information regardless of the mode or place of care. Thus, the individual
begins to control your health information, working in conjunction with the medical institutions to maintain consistency and integrity of clinical data. And the patient can still access their
medical records via the Internet anywhere and anytime. It is motivated by the facts presented
above that this paper proposes, mainly to give the patient’s records via the Internet to interested
parties (and only them - patient, professional and health institutions), creating a prototype, to
support the proposal, to communicate a real institution medicalsystem with a real PHR service.
Keywords: Medical Recordos. Electronic Medical Records. Personal Health Records. Patient.
Google Health.
Lista de Tabelas
Tabela 1.1 Google Health versus Microsoft HealthVault
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Lista de Figuras
Figura 1.1 Visão em camadas da arquitetura do Google Health.
Figura 1.2 Trecho de um arquivo CCR. Seção ’Procedures’.
. . . . . . . . . . . . . . . . . . . . . 31
. . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 1.3 Correspondência visual do arquivo CCR da figura 1.2 no Google Health (Google, 2009).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 1.4 Subconjunto CCR do Google Health (Google, 2009).
. . . . . . . . . . . . . . . . . . . . 35
Figura 1.5 Quadro exemplo de especificação para valores para os elementos de Results
(Google, 2009).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 1.6 Trecho de um arquivo CCR ilustrando a construção em XML para a seção
Results.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 1.7 Resultado de exame das figuras 1.5 e 1.6 exibido no Google Health (Google,
2009).
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 1.8 Estrutura da camada de serviços de comunicação e integração de dados.
Figura 1.9 Exemplo de uma página de autorização
. . . . 41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 1.10 Processo de autenticação com ClientLogin.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 1.11 Processo de autenticação usando FederatedLogin.
. . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 1.12 Processo de autorização utilizando OAuth.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 1.13 Processo de autenticação usando AuthSub.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 2.1 Processo geral de comunicação do protótipo com o Google Health e um sistema
Medicware.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 2.2 Fluxograma da operação do protótipo.
Figura 2.3 Arquitetura do protótipo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 2.4 Arquivo XML de exames de um sistema Medicware.
. . . . . . . . . . . . . . . . . . . . . 61
Figura 2.5 Fragmento de um documento CCR lido pelo protótipo de um perfil do Google
Health.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 2.6 Conteúdo de uma notı́cia (notice) em um perfil de testes do Google Health.
. 62
Lista de Siglas
PME
Prontuário Médico Eletrônico
PEP
Prontuário Eletrônico Pessoal
PHR
Personal Health Record
EHR
Eletronic Health Record
GH
Google Health
ASTM
American Society for Testing and Materials
ANSI
American National Standards Institute
CCR
Continuity of Care Record
XML
eXtensible Markup Language
LOINC
Logical Observation Identifier Names and Codes
SAG
Serviço de Autenticação Google
CAPTCHA Completely Automated Public Turing Test To Tell Computers and Humans Apart
Sumário
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1
15
Fundamentação Teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
O prontuário médico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
1.1.1
Evolução Histórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
1.2
O prontuário médico eletrônico (PME) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
1.3
O prontuário eletrônico pessoal (PEP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.3.1
Benefı́cios e Desafios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
1.3.2
Princı́pios e aspectos de segurança para o PEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
1.3.3
Questões éticas e legais relacionadas ao PEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
1.4
Sistemas disponı́veis de PME e PEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
1.5
O Google Health versus MS HealthVault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
1.6
O Google Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29
1.6.1
Arquitetura do Google Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
1.6.1.1
Padrão de Estruturação de Dados de Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
1.6.1.2
Continuity of Care Record(CCR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
1.6.1.3
Conteúdo e estrutura do padrão CCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
1.6.1.4
Subconjunto CCR do Google Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
1.6.1.5
Serviços de comunicação e integração de dados . . . . . . . . . . . . . . . . . . . . . . . . . p. 40
1.6.1.6
Serviços de autenticação e autorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
1.6.1.7
Interface com usuário, serviços terceiros e provedores de dados . . . . . . . . . . . . p. 51
2
Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
2.1
Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
2.2
A aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
2.3
A empresa parceira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
2.4
Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56
2.5
Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57
2.5.1
Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57
2.5.2
Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60
2.5.2.1
Processamento XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60
2.5.2.2
Autenticação e Autorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
2.5.2.3
Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
2.5.3
3
3.1
Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
10
Introdução
A gestão e a utilização de conhecimento e informação, além do processo decisório envolvido no gerenciamento de informações, são as atividades fundamentais de qualquer atividade
profissional. Na área de saúde não é diferente e se intensifica em seu âmbito, pois a sensibilidade das informações que precisam ser controladas neste campo é muito maior: os registros
pessoais de saúde de indivı́duos. Historicamente, este registro é feito através da utilização dos
prontuários médicos em papel.
O prontuário médico do paciente é uma criação de médicos e enfermeiros com intuito de
garantir e sistematizar a memória de fatos e eventos clı́nicos referentes a um indivı́duo de forma
que quaisquer outros profissionais envolvidos no processo de assistência do paciente possam ter
acesso às mesmas informações (SLEE; SLEE; SCHMIDT, 2000). É o prontuário médico que
representa a principal ligação entre os profissionais de uma equipe de uma instituição médica
responsáveis pelo atendimento dos pacientes (MASSAD; MARIN; NETO, 2003). Além de
ser fundamental ferramenta e fonte de pesquisa para a definição do estado de saúde de uma
população, o prontuário médico é parâmetro para a construção de modelos e polı́ticas de atendimento e gestão das organizações de saúde de uma nação (MASSAD; MARIN; NETO, 2003).
Os prontuários médicos eram representados, desde Hipócrates (século V a.C.), somente por
documentos em papel, mantidos em uma variedade de formatos, conteúdos e locais diferentes (BEMMEL; MUSEN; HELDER, 1997). A heterogeneidade de informações, profissionais
envolvidos na produção, circulação de informações e conhecimentos médicos são os maiores
percalços concernentes a representação em papel do prontuário médico. A impossibilidade de
acessar e integrar dados individuais ou de grupos de pacientes registrados em documentos em
papel resulta em uma visão fragmentada da evolução dos problemas de saúde de cada indivı́duo.
Além da impossibilidade de recuperar a informação agregada dos prontuários de uma comunidade, aumentando os riscos de perdas, duplicatas ou envelhecimento destes registros de saúde
(MASSAD; MARIN; NETO, 2003).
É nesse contexto da falta de integração e organização das informações do prontuário em
papel que se apresenta uma nova solução, embasada no poder computacional, para transpor
essas limitações. Esse novo modelo permite a possibilidade de manter registros que reúnem
toda a vida do indivı́duo e a criação de bases de dados contendo informações clı́nicas e administrativas agregadas. Estes novos recursos representam mudanças de paradigmas na eficácia,
11
eficiência, segurança, e qualidade da prática de saúde (MASSAD; MARIN; NETO, 2003). O
desenvolvimento deste, até então, novo conceito de prontuário baseado no poder computacional
foi denominado de prontuário médico eletrônico (PME).
O prontuário médico eletrônico aparace como uma solução para a sistematização e organização
que o prontuário médico em papel não pode suprir. O PME pode ser entendido como sendo a estrutura eletrônica para manutenção de informação sobre o estado de saúde e o cuidado recebido
por um indivı́duo durante todo seu tempo de vida (MASSAD; MARIN; NETO, 2003). Segundo
Dick, Steen e Detmer (1997), além do registro eletrônico das informações de saúde de um indivı́duo, o PME deve prover também outros serviços no auxı́lio à manutenção e observação do
estado de saúde de uma pessoa, como acesso a um completo conjunto de dados corretos, alertas,
sistemas de apoio à decisão e outros recursos, como links para bases de conhecimento médico.
No Brasil, por não ter sido encontrado ainda um programa de escala nacional a respeito do
prontuário médico eletrônico, o conceito de PME é largamente entendido como a informatização
do acervo clı́nico de uma determinada instituição médica ou uma rede destas. Assim, embora o
serviço de PME de uma instituição médica provenha todo os recursos possı́veis que este tipo de
prontuário pode dispor, todas as informações de um determinado indivı́duo que fora atendido
em tal instituição somente serão manejadas a partir desta.
Apesar de ser o proprietário de suas informações de saúde, o paciente não tem amplo acesso
a estes dados, pois, como a guarda de suas informações clı́nicas é de obrigação dos estabelecimentos de saúde por onde foi atendido, as suas informações fragmentam-se por todos os
estabelecimentos pelos quais foi atendido (MASSAD; MARIN; NETO, 2003; JUNIOR et al.,
2004). Por essa razão, nestes casos, o PME somente supre as limitações anteriores do modelo
clássico de prontuário médico em papel em seus locais de origem, sem a existência de interação
entre os sistemas de PME de instituições médicas diferentes.
É nessa deficiência de interoperabilidade entre sistemas de PME, principalmente no contexto nacional, que este trabalho apresenta a proposta de adoção do conceito de prontuário
eletrônico pessoal (PEP). O prontuário eletrônico pessoal representa a habilidade de, facilmente, compartilhar informações médicas entre as partes interessadas (paciente, instituições
médicas, profissionais da saúde, dentre outros) e fazer com que as informações do paciente estejam acessı́veis, independente da modalidade ou do local do atendimento (GARETS; DAVIS,
2006). O fundamento deste conceito e, por conseguinte, desta proposta, é que as instituições
médicas continuem com seu dever legal de manter as informações clı́nicas dos indivı́duos, todavia, agora, realizando a interação com algum serviço de PEP que o paciente para que este
possa também gerenciar seus dados de saúde.
O serviço de PEP escolhido pelo paciente, por sua vez, encarrega-se de organizar e sistema-
12
tizar as informações enviadas pelas diferentes instituições pelas quais ele foi atendido. Assim,
o paciente passa a controlar, de fato, suas informações de saúde, atuando em conjunto com as
instituições médicas para manter a coerência e integridade de seus dados clı́nicos. E, talvez o
mais importante neste novo conceito,o paciente poderá acessar seu prontuário médico através da
internet em qualquer lugar e a qualquer momento. Como detentor principal de seu prontuário,
o paciente poderá ainda, a depender do serviço de PEP, compartilhar, se assim autorizar, seu
prontuário com outras pessoas cadastradas no serviço ou com profissionais de saúde também
cadastrados. O novo paradigma do PEP abre inúmeras possibilidades tanto para o paciente
quanto para o profissional de saúde.
É motivado pelos fatos apresentados acima que este trabalho propõe os seguintes objetivos:
• Possibilitar a centralização do prontuário do paciente;
• Disponibilizar o prontuário do paciente através da internet às partes interessadas (e
somente a elas): paciente, profissionais e instituições de saúde;
• Viabilizar a centralização do prontuário criando um protótipo que comunique um sistema de uma instituição médica real com um serviço existente de prontuário eletrônico
pessoal;
• Testar, validar e documentar o protótipo de integração junto à empresa parceira;
Escopo negativo
O campo de pesquisa de registros eletrônicos de saúde é bastante extenso. Somente a
pesquisa para a universalização dos conceitos, definições e tipos de prontuários existentes somam grande volume de trabalhos nas linhas de estudo que envolvem esta área da informática
médica. A definição comumente encontrada no cenário nacional, por exemplo, para prontuário
eletrônico pessoal (inclusive o acrônimo) diverge das encontradas no cenário internacional.
Enquanto no Brasil o conceito de PEP é generalizado, mesclando definições dos prontuários
eletrônicos, o cenário internacional delimita especificamente o escopo de cada tipo de prontuário.
É em meio a essa vastidão dos registros eletrônicos de saúde que este trabalho discute a
proposta de prontuário eletrônico pessoal, focando em seu processo de integração com sistemas
médicos. Com o intuito de não deixar margens para dúvidas, devido a vastidão da pesquisa que
este trabalho se insere, são listados abaixo tópicos que esclarecem os aspectos que este trabalho
não aborda:
13
• Desenvolvimento de um sistema de prontuário médico eletrônico: esses sistemas possuem grande complexidade e foram discutidos neste trabalho por serem parte fundamental na análise da evolução, criação e do uso do PEP. Além disso este trabalho
se utilizou de um sistema de PME já existente,consolidado no mercado regional e
nacional,com o objetivo de integrá-lo a um sistema de PEP também já criado;
• Desenvolvimento de um sistema de prontuário eletrônico pessoal: este trabalho utiliza um sistema de PEP já existente (com suas próprias caracterı́sticas e limitações)
como base de testes e embasamento para corroborar a proposta do uso de prontuário
eletrônico pessoal. É este serviço que este trabalho utilizou para integrar-se ao sistema
de PME real;
• Questões éticas e legais: este campo de pesquisa configura-se, por si só, potencialmente em um trabalho de pesquisa. Dessa maneira, este trabalho não procurará se
aprofundar nestes aspectos. A abordagem de tais problemas se limitará somente a
expor os principais problemas relacionados, pois tais questões são comumente consideradas pelo usuário ao adotar novo serviço, proposta ou conceito. Além disso, os
problemas éticos e legais são bastante discutidos quando se trata de dados pessoais e
legislação concernentes a transações eletrônicas de quaisquer conteúdos.
Contribuições deste trabalho
Algumas considerações sobre as contribuições que este trabalho deixará podem ser, de ante
mão, levantadas:
• Revisão dos conceitos relacionados aos registros eletrônicos de saúde: as definições,
tipos e conceitos de prontuários eletrônicos são revisados, reunindo informações de
várias vertentes para reforçar e propor novas perspectivas;
• Discussão do PEP no cenário nacional: o conceito PEP é comumente utilizado no
cenário nacional como ’prontuário eletrônico do paciente’. Numa primeira análise,
a mudança da palavra pessoal para paciente não representaria uma mudança significante. Tal diferença do significado do conceito de PEP (prontuário eletrônico
pessoal, traduzido do padrão internacional personal health record (PHR) - ISO TR
20514:2005) implica em uma mudança significativa. O ”PEP nacional” (prontuário
eletrônico do paciente) abrange os escopos do PME e do ”PEP internacional”, considerando a junção de ambos conceitos em um único sistema. Contudo, as caracterı́sticas estritas do PEP são bastante limitadas ou até inexistentes.
14
• Criação de um protótipo de integração com um sistema de PEP (PHR): não foi encontrado ainda nas pesquisas, aplicações, comerciais ou protótipos, no cenário nacional que se integrem a um serviço de PEP gratuito e de abrangência global, como o
Google Health (Google, 2009) e o MS HealthVault (Microsoft, 2009). Existem muitas aplicações comerciais existentes, tanto no Brasil como no exterior. Contudo, são
serviços de PEP que não disponibilizam ferramentas que possam realizar a integração
automática com as instituições médicas, fragmentando ainda mais o desorganizado
acervo clı́nico dos pacientes.
• Documentação das etapas de desenvolvimento: com a criação do protótipo, foi produzida documentação detalhada do processo de estudo, criação e desenvolvimento da
aplicação, deixando em aberto e com maior respaldo, a continuidade para trabalhos
futuros. As fontes existentes para trabalhos como esta dissertação são bastante escassos e o legado deste trabalho ajudará a aumentar o número de fontes de estudo para
outros estudos.
15
1
Fundamentação Teórica
1.1
O prontuário médico
O prontuário médico ou prontuário do paciente é o principal elo entre o fato clı́nico do
paciente e o profissional da saúde, reunindo as informações necessárias para garantir o inı́cio
ou continuidade do tratamento para o problema de saúde do indivı́duo. São as informações
que constam no prontuário médico que subsidiarão a continuidade e a verificação do estado
de saúde do paciente, possibilitando a seleção correta dos procedimentos a serem seguidos e
identificação, caso aconteça, de novos problemas de saúde. Todavia, o prontuário do paciente
não se restringe a uma ferramenta de análise e acompanhamento do estado de saúde de um
único indivı́duo (MASSAD; MARIN; NETO, 2003).
A análise conjunta dos dados dos prontuários informa, por exemplo, quais tratamentos
foram realizados, quais obtiveram êxito, custo individual ou cumulativo dos tratamentos para
um dado paciente ou um grupo deles ou ainda de toda uma população (MASSAD; MARIN;
NETO, 2003). Essa análise conjunta permite avaliar o nı́vel de saúde de uma população a partir
de um ou mais pacientes.
1.1.1
Evolução Histórica
Esta subseção se baseia, sobretudo, no trabalho realizado por Massad, Marin e Neto (2003)
sobre a evolução histórica do prontuário médico. A primeira utilização do prontuário médico
clássico em papel é datada do século V a.C. com Hipócrates que estimulava os médicos da época
a fazerem registros médicos escritos (BEMMEL; MUSEN; HELDER, 1997). Florence Nightingale (1820-1910), precursora da Enfermagem Moderna, já relatava na Guerra da Criméia
(1853-1856) que a documentação das informações clı́nicas relacionadas aos doentes eram fundamentais para a continuidade dos cuidados ao paciente (NIGHTINGALE, 1989). Contudo, até
o século XIX, os médicos ainda baseavam suas observações e suas anotações no que ouviam,
sentiam e viam, fazendo registros em ordem cronológica, criando o conceito de prontuário ori-
16
entado ao tempo, ainda usado até hoje (MASSAD; MARIN; NETO, 2003).
Em 1907, a clı́nica Mayo, criada por William Mayo em 1880, passou a adotar registros
médicos separados para cada indivı́duo, arquivados separadamente e ordem cronológica (MASSAD; MARIN; NETO, 2003). Essa separação dos registros médicos por paciente resultou na
extensão do conceito anterior de prontuário orientado ao tempo, acrescentando o foco individual
a cada paciente . Treze anos mais tarde, a clı́nica Mayo iniciou um processo de padronização
dos prontuários, selecionando um conjunto mı́nimo de dados que deviam ser registrados, criando uma estrutura mais sistematizada da informação médica, caracterizando, naquela época, o
prontuário médico usado até hoje (MASSAD; MARIN; NETO, 2003).
Apesar de todos os esforços pioneiros e todas as reformulações que o prontuário sofreu
durante os anos, o prontuário médico em papel ainda não destituiu-se dos inúmeros problemas
tanto para os profissionais de saúde quanto para os pacientes. O maior problema é a heterogeneidade do dado clı́nico que é bastante complexo para ser inserido em sistemas de informação
tradicionais (MASSAD; MARIN; NETO, 2003). Por exemplo, dados de controle de sinais
vitais precisam ser verificados e acompanhados, usualmente, em planilhas ou gráficos; tomografias computadorizadas e radiologia são analisadas através de imagens.
As situações anteriores exemplificam como a disparidade dos tipos e formatos dos dados
clı́nicos de um paciente é imensa, isso sem considerar pacientes com múltiplas enfermidades.São fatores como a heterogeneidade dos dados clı́nicos que fizeram com que o modelo
de atendimento ao indivı́duo, bem como o registro clı́nico de seus estados de saúde mudassem
para amenizar ou contornar tais entraves. O novo modelo de atendimento clı́nico apresenta as
seguintes caracterı́sticas(MASSAD; MARIN; NETO, 2003):
• O atendimento clı́nico tem que ser visto como um todo. A informação integrada
permite gerenciar e analisar de forma contı́nua os sucessos e fracassos da atenção de
saúde;
• O foco do atendimento é o nı́vel primário, entendendo que os hospitais continuam
a ser um centro para diagnóstico e cuidado de problemas complexos e para procedimentos cirúrgicos e cuidados intensivos;
• A equipe que atende é interdisciplinar, colaborativa, conduzida por uma organização
horizontal. Não existe um profissional que seja mais importante que outro, uma vez
que todos colaboram para que o paciente se restabeleça.
É neste contexto de mudança de paradigmas no atendimento clı́nico que uma nova estrutura
17
computacional que se apresenta, oferencendo uma solução para novos patamares de integração
e sistematização das informações clı́nicas do paciente: o prontuário médico eletrônico (PME).
1.2
O prontuário médico eletrônico (PME)
Dick, Steen e Detmer (1997) caracterizam o prontuário médico eletrônico do paciente como
um registro eletrônico que reside em um sistema especificamente projetado para apoiar os
usuários, fornecendo acesso a um completo conjunto de dados corretos, alertas, sistemas de
apoio à decisão e outros recursos, como links para bases de conhecimento médico. Já em ISO
(2004), por sua vez, define, de forma mais generalizada, o registro eletrônico de saúde como um
repositório de informações relacionadas ao estado de saúde de um indivı́duo, sob uma forma
computadorizada de processamento. E de forma muito mais detalhista, por fim, Kwak (2005)
define o registro eletrônico de saúde como uma junção de funções automatizadas, técnicas, administrativas, operacionais, de comunicação, baseadas no poder computacional, organizadas
para aceitar, processar, armazenar, transmitir e retornar informações clı́nicas eletrônicas para
diversos propósitos.
Tomando como base as definições do parágrafo anterior, o conceito de prontuário médico
eletrônico recebe várias outras denominações, principalmente quando se tomam como referência
as definições estrangeiras e suas possı́veis interpretações no contexto nacional. Contudo, divergindo de nomenclatura, como registro eletrônico do paciente ou de saúde, baseado em computador, a essência do conceito de prontuário eletrônico persiste inalterada. Outro ponto a ser
ressaltado é que a mera digitalização de documentos em papel não se configura como prontuário
eletrônico, pois não traz a mudança do comportamento em relação ao prontuário em papel e não
permite a estruturação e sistematização da informação médica.
Sittig (1999) analisa os benefı́cios do prontuário médico eletrônico e frisa os seguintes
pontos:
• Acesso remoto e simultâneo: vários profissionais podem acessar um mesmo prontuário
simultaneamente e de forma remota;
• Legibilidade: registros feitos à mão são difı́ceis de ler;
• Segurança de dados: possibilidade de backups contra perdas;
• Confidencialidade dos dados do paciente: nı́veis de acesso, monitoramento e auditoria;
18
• Integração com outros sistemas de informação: uma vez em formato eletrônico, os
dados do paciente podem ser integrados a outros sistemas de informação.
É possı́vel observar ainda outras vantagens do PME como: acesso mais rápido às informações
clı́nicas, melhoria no processo de tomada de decisões, aumento da efetividade dos tratamentos,
redução de custos em longo prazo e melhoria no gerenciamento de recursos (MASSAD; MARIN; NETO, 2003). Contudo, o modelo do prontuário médico eletrônico não é um modelo
infalı́vel. A despeito dos benefı́cios supracitados, o PME, ou qualquer outro conceito de registro eletrônico de saúde sofre de muitos problemas. Alguns deles são elicitados abaixo:
• Grande investimento da produção e aquisição de software e hardware;
• Mudança de comportamento dos usuários.
• Retorno demorado do investimento;
• Sujeito a falhas de inoperância.
Todavia, o PME, além destas e outras limitações, sofre com outro problema mais especı́fico
e importante: interoperabilidade. O conceito primário de PME não abrange a possibilidade ou
caracterı́stica de interoperabilidade entre sistemas diferentes, mesmo se tratando de documentos
eletrônicos. Frequentemente os conceitos de PME e PEP são confundidos e se misturam desde
o conceito primeiro da sistematização do prontuário eletrônico até a interoperabilidade direta
entre sistemas diferentes.
É importante salientar a diferença entre interoperabilidade direta e indireta. A primeira
forma trata de comunicação direta propriamente dita entre sistemas diferentes de PME. A interoperabilidade indireta se dá quando esses sistemas se comunicam através de um serviço
terceiro.
Em Dick, Steen e Detmer (1997) é relatado que não é possı́vel comprar um sistema de
registro eletrônico de saúde (do acrônimo em inglês EHR - eletronic health record) nos dias
de hoje que esteja de acordo com os princı́pios existentes nessa mesma obra. Esta obra afirma
ainda que nenhum fabricante possui qualquer produto que chegue perto da visão de interoperabilidade, sem uso de papel, registros que documentam todo e qualquer cuidado, integrando base
de dados,bases de conhecimento e oferecendo a segurança necessária. É importante ressaltar
que o conceito especı́fico abordado na declaração de Dick, Steen e Detmer (1997) é o PME,
pois se fala em uso de papel e, como será visto a seguir, o conceito de prontuário eletrônico
pessoal dispensa o uso de papel para as atividades de controle e visualização dos dados clı́nicos
de um paciente.
19
O PME é o passo primeiro no processo de informatização de prontuários médicos em papel.
Além de proporcionar melhorias para a equipe de atendimento de uma instituição no processo de
gerenciar informações e melhoramento nos cuidados, os pacientes se beneficiam destes ganhos,
pois são eles o publico alvo de todo esse avanço tecnológico nas instituições médicas. Contudo,
como já foi dito, tais avanços nas instituições restringem-se ao local destas. O aprimoramento
da sistematização das informações de saúde dos pacientes desenvolvido nestes locais não está
disponı́vel ao paciente em locais que não seja a instituição que mantem seu prontuário - é a
limitação da interoperabilidade.
A partir do entrave da interoperabilidade existente para o PME e tomando a declaração do
parágrafo anterior de Dick, Steen e Detmer (1997), é que o conceito do PME foi estendido e
criou-se uma nova visão para o uso e interação do prontuário médico eletrônico: o prontuário
eletrônico pessoal (PEP) - traduzido do inglês, personal health record.
1.3
O prontuário eletrônico pessoal (PEP)
Os sistemas de registros eletrônicos de saúde podem ser caracterizados de duas maneiras
(ISO, 2004; STANDORD; THORNTON, 2006): (a)locais e (b) compartilhados.
O sistema (a) engloba a junção dos dois tipos de prontuários já tratados (clássico e PME)
ou somente um deles (somente PME ou somente prontuário em papel). As principais caracterı́sticas desse sistema são o acesso restrito somente à instituição detentora do sistema, acesso
externo reduzido ou inexistente e nenhuma interoperabilidade com outros sistemas.
O sistema (b) é um conceito de registros eletrônicos direcionados à comunidade das instituições
e dos profissionais de saúde. O objetivo principal dos registros eletrônicos de saúde compartilhados é facilitar a integração entre os registros locais de cada instituição, fazendo com que o registro médico de um paciente não se fragmente através das instituições pelas quais foi atendido.
Dessa forma as informações clı́nicas de um paciente estará disponı́vel em qualquer instituição
que este venha ser atendido. Todavia, é importante ressaltar que, sendo um processo direcionado às instituições, o conceito primário não considera o acesso do paciente ao seu prontuário.
Alguns paı́ses, como Austrália, Canadá e Inglaterra , já utilizam os registros eletrônicos compartilhados em escala nacional com o adendo de que cada indivı́duo pode acessar seu prontuário
onde quer esteja através da internet (JALAL-KARIM; BALACHANDRAN, 2008). Exemplos
de sistemas com esses são o cerne do conceito de prontuário eletrônico pessoal (PEP).
O PEP é definido como resumos eletrônicos de registros médicos de pacientes que são
frequentemente portáveis e facilmente acessı́veis a qualquer hora ou momento (ENDSLEY et
20
al., 2006). Enquanto sistemas PME ou sistemas de registros de saúde compartilhados possuem
os profissionais de saúde como público alvo principal, sistemas de PEP capturam dados de saúde
de indivı́duos particulares e proveem informações relacionadas aos cuidados a esses indivı́duos
(TANG et al., 2006). A principal caracterı́stica do PEP, conforme Kwak (2005) e Tang et
al. (2006), é que o prontuário eletrônico pessoal passa a incluir informações inseridas pelo
indivı́duo, além daquelas oriundas das instituições médicas mantenedoras das informações de
saúde dos pacientes. Essa caracterı́stica contrasta com o conceito do PME que são controlados
somente pelos profissionais ou instituições de saúde.
Não existem abordagens de criação de sistemas PEP universalmente aceitos e definidos,
contudo há três tipos que estão em maior evidência (ENDSLEY et al., 2006):
1. Resumo digital: o paciente possui acesso ao seu PEP, contudo não lhe é permitido modificar ou inserir conteúdo em seu prontuário. As informações são providas, controladas e
mantidas pelo provedor do serviço de prontuário eletrônico pessoal;
2. PEP baseado em programas de computador: este modelo permite que o detentor do
prontuário insira,controle e resgate suas próprias informações de saúde e registre suas
preocupações, sintomas de doenças e contato para emergências. Este modelo pode ser
independente, que não faz integração com qualquer outro sistema, funcionando off-line
ou o programa de computador pode basear-se no acesso a internet. Neste último caso
de acesso a internet, todos os dados, telas de visualização e edição de dados através da
internet são mantidos por um serviço terceiro de PEP;
3. Arquivo digital portátil: este modelo aborda o uso de plataformas portáteis para armazenar os dados de saúde de um indivı́duo, como cartões inteligentes, telefones celulares e
dispositivos USB.
O resumo digital alcança quase todas as caracterı́sticas principais que constituem um PEP,
contudo exime a principal delas: a participação do paciente na alimentação de informações
de seu prontuário. Em relação às duas abordagens seguintes, Endsley et al. (2006) e Tang et
al. (2006) ressaltam os pontos positivos do modelo do arquivo digital portátil, pois provê, por
exemplo, maior controle sobre o acesso às informações contidas no prontuário.
Contudo, a despeito das motivações e dos pontos positivos do arquivo digital portátil,Tang
et al. (2006) discutem que não é ideal que sistemas do modelo 3, que dependem somente da
inserção de dados do paciente, sejam utilizados como canais confiáveis para a transmissão de
prontuários médicos entre o paciente e as instituições médicas. A confiança destes sistemas
21
depende principalmente da natureza das informações inseridas pelos pacientes e das formações
acadêmicas destes indivı́duos (TANG et al., 2006). Baseado nessas conclusões, embora os
modelos 1 e 3 possuam vantagens individuais, sejam eles integrados a somente uma única
instituição ou mais de uma, o modelo 2 (com acesso a internet) provê muito mais benefı́cios e
se adéqua ao conceito fundamental de PEP do que os outros modelos.
1.3.1
Benefı́cios e Desafios
O sucesso do prontuário eletrônico pessoal depende, antes de tudo, do envolvimento do
paciente (KOHN; CORRIGAN; DONALDSON, 2001). Partindo do princı́pio do envolvimento
do paciente no manejo de seu prontuário em conjunto com as instituições que provem e mantêm
os registros médicos, o PEP oferece muitos benefı́cios (ENDSLEY et al., 2006):
• Permite aos pacientes verificarem as informações existentes em seus prontuários, monitorando seu estado de saúde continuamente;
• Aumento da comunicação entre paciente e profissionais/instituições de saúde;
• Aumento da segurança do paciente: o PEP pode prover alerta de uso de medicamentos, identificação de procedimentos faltantes, provimento rápido de resultados de
testes, dentre outros.
• Aumento da qualidade dos tratamentos: o PEP permite a continuidade, o aumento da
abrangência e coordenação dos tratamentos médicos entre os pacientes, profissionais
de saúde e outras instituições de saúde;
• Maior eficiência na entrega do tratamento: o PEP previne duplicatas em testes e
serviços médicos desnecessários;
• Maior proteção aos dados médicos dos pacientes: o PEP provê ao paciente maior
controle sobre seus dados, oferecendo maior granularidade, backups e possibilidade
de compartilhamento das informações médicas do prontuário. O PCASSO (PatientCentered Access to Secure Systems Online) (MASYS et al., 2002), estudo realizado
na Universidade da Califórnia e San-Diego, diz que os sistemas PEP são mais seguros
que os registros médicos em papel.
Não obstante, o PEP não é somente formado de vantagens. Existem dois grandes problemas
em relação a este conceito de prontuário (ENDSLEY et al., 2006):
22
• Privacidade: nos EUA, por exemplo, 91% dos cidadãos estadunidenses têm preocupações
a respeito da privacidade de suas informações;
• Precisão dos dados: envolvimento de pacientes, não somente na visualização dos
dados, bem como a inserção de novas informações, aumentam o problema da precisão
e confiabilidade dos dados existentes nos prontuários eletrônicos pessoais.
1.3.2
Princı́pios e aspectos de segurança para o PEP
Independente do modelo ou do tipo de sistema em que dados sigilosos devem ser protegidos
ou o acesso a estes devem ser regrados, de forma geral, a segurança da informação, em papel ou
eletrônico, é embasada nos seguintes princı́pios (MARTINS; SAUKAS; ZANARDO, 2004):
• Integridade: dados não podem ser alterados sem autorização;
• Confidencialidade: informações sensı́veis não podem ser acessadas indiscriminadamente;
• Disponibilidade: acesso disponı́vel por usuários autorizados;
• Autenticação: verificação da identidade de uma pessoa ou usuário;
• Autorização: associação de uma identidade a uma lista de privilégios, direitos, ou
áreas de acesso;
• Legalidade: impossibilidade de um indivı́duo negar autenticidade de um documento,
assinatura ou seu envio;
• Auditoria: registro da atividade de um usuário, com fins de detecção de erros ou
atividades suspeitas.
Segundo Martins, Saukas e Zanardo (2004), um sistema genérico de controle de acesso
deve, fundamentalmente, impedir que usuários não autorizados tenham acesso a informações sigilosas ou exerçam operações as quais não poderiam realizar sem autorização prévia. O mesmo
autor ainda destaca que qualquer sistema de proteção de dados deve considerar a existência de
um usuário com permissões máximas (chamado comumente de administrador) que possa determinar quais funcionalidades ou módulos de uma aplicação um usuário ou grupo de usuários
pode acessar dependendo de seu papel dentro da instituição.
23
Para a área de saúde, especificamente, o princı́pio fundamental para o controle de acesso
ao prontuário eletrônico do paciente é que, em nenhuma circunstância, o atendimento pode ser
prejudicado por negar o acesso legı́timo às informações e serviços requisitados pelo médico
(MARTINS; SAUKAS; ZANARDO, 2004). Excetuando-se esse contexto, as informações do
prontuário do paciente, seja em papel ou eletrônico, devem permanecer sigilosas, exceto quando
em atendimento à vontade do paciente ou por determinações legais, conforme Martins, Saukas
e Zanardo (2004).
Por outro lado, Tang et al. (2006) salientam que somente medidas técnicas não são suficientes para garantir a privacidade e a precisão dos dados dos prontuários dos pacientes. Estes
autores enaltecem a educação como parte integral do processo de prevenção contra acessos
não-autorizados e violação de informações. Para que sistemas PEP alcancem seus potenciais
máximos, é importante que medidas educacionais sejam tomadas para conscientizar e politizar
a equipe médica que gerencia parte ou todas as informações do PEP de um paciente que residem
em uma ou mais instituições médicas.
A educação para a equipe que reside e gerencia as informações clı́nicas dos provedores de
dados dos pacientes - as instituições médicas - além das questões técnicas de segurança antes
discutidas, ataca outra grande preocupação que receia os pacientes em relação aos seus dados:
o acesso inapropriado por usuários da própria instituição médica. Uma pesquisa, realizada na
Faculdade de Medicina de Marı́lia, mostra as porcentagens alarmantes de acessos indevidos
realizados, pelos próprios profissionais da saúde, ao Registro Clı́nico Informatizado do hospital
desta instituição: 37% olharam exames laboratoriais de pessoas que não eram seus pacientes e
30% acessaram para outra finalidade que não o cuidado médico (AL-SALQAN, 1998).
Em relação ao indivı́duo detentor do prontuário, Tang et al. (2006) também frisam que o
sucesso do prontuário, ou grande parte dele, é dependente da aceitação do indivı́duo por esse
novo conceito e pelas novas tecnologias relacionadas. Estes autores vão mais longe e afirmam
que a importância de gerenciar a saúde do indivı́duo por ele mesmo usando ferramentas simples
deve ser ensinada desde cedo pelo sistema de educação do paı́s em questão e continuada através
de todos os nı́veis possı́veis de educação para essa área, como: escolas de medicina, escolas de
enfermagem, residências, treinamentos especı́ficos, dentre outros.
1.3.3
Questões éticas e legais relacionadas ao PEP
Para que o paciente possa ter acesso as suas informações médicas em seu prontuário eletrônico
pessoal, é necessário que as instituições médicas onde o paciente foi atendido estejam integradas ao serviço de PEP que o indivı́duo utiliza, alimentando este último com os dados médicos
24
registradas no PME do paciente. As atividades de acesso e divulgação de dados e informações
pessoais dos prontuários nas instituições médicas, sejam eles eletrônicos ou não, são intensamente observadas e regulamentadas, tanto por diretrizes técnicas e educacionais - como foi visto
na seção anterior - quanto por leis e normas éticas.
As preocupações éticas e legais relacionadas ao PEP iniciam-se desde a base que o alimenta
e o forma (os sistemas de PME) até o sistema propriamente dito do PEP. Na base do PEP, o
profissional de saúde que primeiro entra em contato com o paciente, recebendo, registrando,
manipulando, digitando, armazenando, arquivando e processando os dados e informações, é
responsável pela sua guarda e integridade. Este profissional deve estar atento para a importância
e significado de preservar o sigilo da informação e assegurar a privacidade da pessoa cujos dados
estão sendo manuseados (MASSAD; MARIN; NETO, 2003). Todas as profissões da área de
saúde têm, em seus códigos de ética, normas expressas que proı́bem a divulgação de qualquer
dado ou informação de pacientes que estão ou estiveram sob seus cuidados e recomendam
especial rigor na guarda dos prontuários e fichas clı́nicas que contenham qualquer informação
sobre os pacientes (MASSAD; MARIN; NETO, 2003).
O maior conflito ético, portanto, sobre a utilização do PEP reflete sobre a privacidade
da informação em um meio eletrônico e seus aspectos legais, cujo paciente é detentor das
informações contidas em seu prontuário, seja ele eletrônico ou não (SALVADOR; FILHO,
2005). A confidencialidade das informações do PEP é um direito de todo cidadão, com respaldo na Constituição Federal de 1988, em seu artigo 5o , inciso X e também no Código Penal,
artigo 154, que garante a inviolabilidade da intimidade, da vida privada, da imagem e da honra
das pessoas.Salvador e Filho (2005) ainda reiteram o direito do paciente à confidencialidade de
suas informações médicas, citando o Código de Ética Médica, que impõe o segredo como um
princı́pio fundamental para o exercı́cio da medicina.
Utilizando-se ainda dos conhecimentos de Salvador e Filho (2005), somente com o consentimento do paciente é que se poderia autorizar a revelação do conteúdo do prontuário, através
do princı́pio da autonomia. Contudo, excetuando-se a vontade do indivı́duo, as informações
do prontuário médico do paciente podem ser reveladas, a partir do Código de Ética Médica,
por justa causa ou dever legal. Não obstante, não somente os médicos e enfermeiros e demais
profissionais de saúde, assim como todos os funcionários administrativos que entram em contato com as informações do paciente por dever de ofı́cio, tem autorização de acesso às estas
informações (SALVADOR; FILHO, 2005).
Diferentemente do modelo de prontuário em papel, tanto sistemas PME e PEP sofrem das
mesmas lacunas quanto regulamentação por leis do uso e adoção desses sistemas, sejam eles ins-
25
titucionais (PME) ou pessoais (PEP). Excetuando-se paı́ses que já possuem sistemas de registros
de saúde em estudo ou já em execução, como Inglaterra, Canadá e Austrália (JALAL-KARIM;
BALACHANDRAN, 2008), muitos outros paı́ses engatinham nesse processo de elaboração de
um projeto de PEP em escala nacional,pois dentre os inúmeros fatores que embargam, entre
eles estão os fatores legais.
O Brasil é um exemplo de uma legislação não consolidada a esse respeito. Embora Salvador e Filho (2005) enumere algumas leis e códigos que se referem aos aspectos legais do
PEP, tais legislações não tratam do problema de forma generalizada, atacando nuances especı́ficas relacionadas ao uso de registros eletrônicos de saúde. Junior et al. (2004) também
enfatizam que no Brasil ainda não exite lei especı́fica sobre a privacidade e a confidencialidade da informação em saúde, armazenada ou transmitida por meios eletrônicos, mas cita como
exemplo de esforço rumo a consolidação a Lei Federal no 7.232 de 29 de outubro de 1984, que
estabelece ”Princı́pios, objetivos e diretrizes da Polı́tica Nacional de Informática, seus fins e
mecanismos de formulação”.
Aspectos éticos e legais são pontos fortes de discussão em qualquer segmento. A área
de saúde não é diferente, principalmente devido à sensibilidade das informações em questão.
Quando se trata de manejo e acesso por profissionais de saúde, administrativos ou possibilidade
de quebra de sigilo das informações de pacientes, cada detalhe, nuance ou aspecto deve ser
considerado. É por isso que no Brasil, por exemplo, existem vários códigos de ética, leis,
projetos que procuram solucionar questões ainda controversas, como a autonomia do paciente
mediante seu prontuário e seu estado de saúde.
1.4
Sistemas disponı́veis de PME e PEP
A criação de um sistema de PME por uma instituição de saúde é a principal medida para a
informatização de seu acervo clı́nico e o primeiro passo em direção a disponibilização de seu
acervo para seus reais donos, os pacientes. Como sistemas de PME, em sua acepção primeira,
não permitem acesso externo ou integração com outros sistemas de mesmo cunho, os PME’s
possuem maior facilidade de desenvolvimento e implantação, comparado aos sistemas de PEP.
Considerando ainda que o PME é um conceito de gerenciamento de registros de saúde
mais consolidado,pode-se perceber que o número de sistemas de PME é maior que os de PEP
no Brasil e no mundo, além do fato de que o conceito de PEP esteja, ainda, em construção.
No Brasil, como exemplo, é possı́vel citar, dentre os inúmeros sistemas de PME, os sistemas
do INCOR (PIRES et al., 2000), iDOCTOR (FEITOZA,2009) e a atuação de empresas no
26
desenvolvimento de soluções neste ramo, como a Medicware Sistemas (MEDICWARE,2009) e
a Mv Sistemas (SISTEMAS,2009).
No cenário internacional, exemplos não especificamente de PME, mas válidos como referências (e que já foram citados neste trabalho), os sistemas de PEP da Inglaterra, Canadá e
Austrália (JALAL-KARIM; BALACHANDRAN, 2008) se destacam pelos seus estágios atuais
de estudo, desenvolvimento, implantação e uso naqueles paı́ses. Tais sistemas são exemplos
de grande informatização da área de saúde, pois para alcançarem nı́veis nacionais de PEP, foi
preciso, antes, massiva informatização de inúmeros acervos clı́nicos das instituições de saúde
destes paı́ses. Quanto ao sistemas de PEP, embora o número de serviços ao redor do mundo
venha crescendo, a quantidade ainda é pequena em relação aos sistemas de PME.
É nesse contexto que sistemas gratuitos surgem para oferecer tais serviços de integração e
centralização de registros de saúde, apresentando boa oportunidade de sucesso, principalmente
por parte das grandes empresas. A empresa Google, por exemplo, engajou-se nesta área de
gerenciamento de registros de saúde e lançou em janeiro de 2008 o seu serviço de PEP, o
Google Health (GH) (GOOGLE, 2009). A empresa Microsoft também possui um sistema de
PEP e lançou-o pouco antes da Google. O sistema da Microsoft chama-se MS HealthVault. A
seção a seguir discute esses dois sistemas de escala global que polarizam, hoje, os serviços de
PEP gratuitos e terceirizados no mundo.
27
1.5
O Google Health versus MS HealthVault
Ambos os serviços, Google Health e MS HealthVault, possuem funcionalidades e caracterı́sticas bastante equivalentes. Stoltz (2008) fez uma análise a respeito dos dois serviços e
chegou as seguintes conclusões:
• São ambientes integrados para criar e armazenar registros médicos pessoais;
• Proveem compartilhamento do prontuário, mediante autorização do usuário;
• Proveem gerenciamento de medicações e medições;
• São serviços gratuitos;
• Proporcionam comunicação com outros usuários e profissionais cadastrados no serviço;
• Possuem referências para bases de conhecimentos;
Já Kuraitis (2008) destaca as principais diferenças entre os serviços da Microsoft e da
Google. Algumas delas, que são relevantes para este trabalho, seguem abaixo:
Tabela 1.1: Google Health versus Microsoft HealthVault
Google Health
Microsoft Health Vault
Serviço com maior foco no usuário.
Serviço com maior foco nos parceiros.
Divide a responsabilidade da
Responsabiliza as empresas ou
interação com o usuário
instituições médicas parceiras
com as empresas ou instituições
para a criação da interação
parceiras registradas no serviço.
com o usuário.
Mais inclinado a reunir informações
O sucesso deste serviço
oriundas dos parceiros do que deixar
dependente do êxito das aplicações
para estes o fazerem.
criadas pelos parceiros.
Menor granularidade das informações. Maior granularidade das informações.
Ainda não possui interação direta
Comunicação direta com dispositivos
com dispositivos.
de monitoramento.
Uma terceira análise foi realizada por Peters et al. (2009) , durante dezembro de 2008 e
janeiro de 2009, entre os dois serviços. Segundo Peters et al. (2009) nenhum indivı́duo relacionado a nenhum dos dois serviços participou desde estudo comparativo. O estudo foi realizado
com 30 pessoas que realizaram tarefas chave em ambos os serviços. Cinco tópicos foram avaliados: usabilidade geral, utilidade (das funcionalidades), segurança, privacidade e confiança.
28
Um terceiro serviço de PEP (MYMEDICALRECORD, 2009) foi acrescentado no decorrer do
teste para acrescentar mais dados e embasar os resultados finais.
De forma geral, os participantes do estudo indicaram que o Google Health é mais útil, pois
a navegação e a entrada das informações de saúde foram mais fáceis do que os outros serviços.
Os participantes ainda acrescentaram que o GH utiliza uma terminologia médica mais amigável,
mais próxima do conhecimento médico familiar e possui um sumário simplificado e objetivo
das informações de saúde do prontuário. Além disso, os seguintes tópicos foram avaliados:
• Usabilidade: o serviço de PEP da Google obteve a preferência geral dos participantes neste quesito, pois a interface do Google Health os permitiu a fácil inserção das
informações médicas. Em contrapartida, o serviço da Microsoft perdeu pontos por
apresentar interface confusa, jargões médicos e inconsistências entre diferentes dados
inseridos;
• Utilidade: ambos os serviços foram bem avaliados em suas funcionalidades exclusivas. Contudo, devido à maior facilidade de uso do serviço da Google e a bem
avaliada funcionalidade de integração com drogas. Mais uma vez o Google Health
recebeu maior pontuação neste quesito;
• Segurança, privacidade e confiança: embora a Microsoft tivesse tido, no primeiro
contato dos participantes, melhor recepção nestes pontos, o Google Health, ao fim
do questionário, obteve maior pontuação. A causa desta pontuação final foi a forma
como os termos de uso e de privacidade foram apresentados e a clareza destes termos;
• Avaliação geral: avaliação geral feita no trabalho de Peters et al. (2009) constatou que
nenhum dos dois serviços é plenamente satisfatório, cada um tem falhas comuns e
especificas e que o maior problema de ambos os serviços é a interação com o usuário.
Todavia, o Google Health, de forma geral, recebeu maior pontuação neste quesito do
que o serviço de PEP da Microsoft.
Analisando os resultados desses estudos, principalmente os resultados em Peters et al.
(2009), verificou-se que o GH se apresenta como uma proposta mais próxima à deste trabalho,
por focar principalmente o usuário. Adicionalmente, mostrou vantagens em relação à usabilidade, facilidade de uso e segurança. Por fim, sua arquitetura permite mais facilmente a criação
de aplicações de testes, como o protótipo deste trabalho. Por esses motivos, o serviço de PEP
da Google foi o serviço escolhido para a implementação do protótipo proposto nesse estudo.
29
1.6
O Google Health
O Google Health (GOOGLE, 2009) é a proposta de prontuário eletrônico pessoal da empresa Google. Este serviço, que é gratuito, pode ser utilizado por qualquer indivı́duo que possua
uma conta registrada na mesma empresa (caso não possua tal conta, basta criar uma nova conta
gratuitamente). Dessa forma, utilizando o GH, é possı́vel que o indivı́duo possa gerenciar suas
informações médicas e possa acessá-las através da internet a partir de qualquer local e a qualquer momento.
Este serviço de PEP permite ao indivı́duo: organizar suas informações em um único lugar; reunir seus registros médicos, eventualmente, fragmentados pelas clı́nicas, hospitais, e até
farmácias em que foi atendido; compartilhar as informações contidas em seu ”Google PEP”
com outras pessoas, como familiares, médicos e outros profissionais de saúde.
O Google Health possui a seguintes caracterı́sticas principais (GOOGLE, 2009):
• Permite ao usuário alimentar seu prontuário: o indivı́duo pode inserir suas condições
de saúde, medicamentos que estão sendo utilizados,alergia, exames, dentre outros.
Contudo, para evitar ou amenizar informações imprecisas do próprio usuário, o GH
possui extenso banco de dados de definições para os tipos de condições de saúde,
medicamentos e alergias, como por exemplo, tipos de diabetes;
• Importar registros médicos: permite ao usuário selecionar as instituições médicas
pelas quais foi atendido, desde que estas estejam registradas no GH, permitindo que
estas se conectem a sua conta pessoal e possam importar seus registros médicos lá
existentes;
• Rastreamento: o GH permite ao usuário rastrear a origem das informações contidas
em seu prontuário oriundas das instituições médicas ligadas ao seu PEP;
• Referências a conhecimentos médicos: o GH gerencia todos os dados inseridos no
prontuário. A cada novo dado inserido, o serviço provê ao usuário referências (indicações
de livros, links para páginas na internet, etc.) para bases de conhecimentos correlacionadas aos dados inseridos, para que os usuários possam estudar ou conhecer mais a
respeito das informações contidas em seus prontuários;
• Compartilhamento: o serviço permite que os usuários compartilhem eletronicamente
seu prontuário como outros usuários do serviço, como familiares, médicos ou outros
profissionais de saúde. Caso algum destes indivı́duos não estejam cadastrados no
30
serviço de PEP da Google, o GH permite que seu prontuário possa ser impresso para
ser compartilhado pessoalmente.
O serviço de PEP da Google é, fundamentalmente, uma plataforma de aplicações. É por
este motivo que aplicações externas, construı́das de acordo com a arquitetura do serviço, podem
se comunicar com este e prover serviços terceiros aos usuários. Gerenciar datas de consultas
médicas, alertas para horários de medicamentos e interação com instituições médicas são exemplos de serviços terceiros existentes.
É importante salientar que o Google Health avisa que, oficialmente, não está disponı́vel
para instituições médicas fora dos Estados Unidos da América e que este mesmo serviço está
sob as leis federais daquele paı́s. E, embora este serviço se adéque aos requisitos de segurança,
ou a quase todos eles, citados neste trabalho, este serviço é regido por sua própria polı́tica de
privacidade. Todavia, a Google permite que aplicações de teste possam ser livremente desenvolvidas, de acordo com suas próprias especificações, independente do paı́s de origem de onde
se realiza o desenvolvimento da aplicação. Comercialmente, ainda não é possı́vel concretizar
uma aplicação real para este serviço, pois o mesmo ainda não está disponı́vel oficialmente para
o mercado, embora já esteja em testes em hospitais dos EUA.
Não obstante, embora o GH ainda não esteja disponı́vel oficialmente, o desenvolvimento
deste protótipo ataca um nicho mercadológico carente ou até inexistente de aplicações com
o cunho que este trabalho apresenta. Não foram encontradas nas pesquisas, até o presente
momento da pesquisa, quaisquer outras aplicações no mercado com a mesma proposta deste
trabalho. Além disso, quando o serviço da Google, após sua fase de testes e projetos piloto, for
lançado oficialmente para o uso em mercado, esta aplicação protótipo já possuirá maturidade
suficiente perante a versão final do serviço, diminuindo o tempo do eventual lançamento desta
aplicação no mercado.
31
1.6.1
Arquitetura do Google Health
A arquitetura do GH pode ser dividida nas seguintes camadas (abordando processos, padrões,
interfaces, serviços e atores):
• Padrão de estruturação de dados de saúde: define a forma como os dados são representados;
• Serviços de comunicação e integração de dados: define como os dados são agrupados
e acessados;
• Serviços de autenticação e autorização: define os processos de autenticação e autorização
que aplicações terceiras e usuários tem de se submeter em determinadas atividades;
• Provedores de dados, serviços terceiros e interface com usuário: essa camada define
os principais atores que interagem com o serviço.
Essas camadas do GH se relacionam e podem ser estruturados da maneira ilustrada na 1.1.
Essa visão em camadas foi concebida mediante análise e estudo da documentação do serviço e
do resultado desenvolvimento do protótipo deste trabalho.
Figura 1.1: Visão em camadas da arquitetura do Google Health.
A análise da estrutura apresentada na figura 1.1 do GH será feita de baixo para cima, pois a
camada mais inferior é a camada que fundamenta todas as informações do serviço, definindo a
forma como os dados são estruturados.
32
1.6.1.1
Padrão de Estruturação de Dados de Saúde
Todos os dados existentes no prontuário de um usuário deste serviço são estruturados no
padrão internacional de informação de saúde da ASTM International e aprovado pelo ANSI: o
padrão Continuity of Care Record(CCR). Os dados podem ser oriundos da própria inserção do
usuário, enviados por provedores de dados ou por serviços terceiros.
1.6.1.2
Continuity of Care Record(CCR)
O padrão CCR foi criado em 2003 e vem sendo desenvolvido por profissionais voluntários
da área de saúde e de tecnologia, sob o jugo a ASTM International. O CCR é um padrão livre de custo de uso, embora ele seja licenciado pela ASTM International - o custo se encontra
em adquirir a documentação completa concernente ao padrão disponı́vel no site da associação
detentora. O objetivo do padrão CCR é tornar possı́vel a criação de um resumo digital de
informações administrativas e clı́nicas relevantes sobre um indivı́duo, para ser criado, armazenado e transmitido de um computador para outro com pouco ou nenhuma intervenção humana
para a realização da troca das informações (KIBBE, 2007).
1.6.1.3
Conteúdo e estrutura do padrão CCR
Conteúdo
Diferentemente dos conceitos de PME ou PEP, o padrão CCR não tem por objetivo capturar
todo histórico médico de um indivı́duo. O conteúdo de um arquivo dentro do padrão CCR é um
retrato do estado de saúde de uma pessoa com suas informações de saúde mais relevantes em
um dado momento de sua vida (KIBBE, 2007). O processo de reunir todo o histórico médico
de um indivı́duo, reunindo vários arquivos CCR de épocas da vida deste é a função de sistemas
PME ou PEP que se proponham a utilizar o padrão CCR, como o Google Health.
O padrão é composto por 17 (dezessete) seções, embora não seja necessário utilizar todas
para um arquivo ser válido ou útil. Cada seção contém elementos que podem conter informações
em texto livre, texto estruturado, códigos ou o que mais for apropriado para uma aplicação
(KIBBE, 2007). Essa maleabilidade no conteúdo das seções deste padrão será detalhada mais
a frente quando for discutido como um arquivo CCR é estruturado. As seções deste padrão
podem ser conhecidas a seguir, contudo as denominações de cada seção não serão traduzidas
para expor o conteúdo real e evitar possı́veis ambiguidades na tradução:
• Patient demographics - informações demográficas (idade, sexo, altura, peso);
33
• Insurance information - informações sobre seguros (de vida, saúde);
• Advance directives - diretivas antecipadas (aqui o conteúdo dependente da utilização
desta seção);
• Problems/diagnoses - problemas de saúde (passados, atuais) e/ou diagnósticos
• Allergies and alerts - alergias e alertas (alerta de nı́vel baixo de insulina, por exemplo);
• Medication list - lista de medicamentos (já consumidos ou em curso);
• Immunizations - imunizações (imunização a febre amarela, por exemplo);
• Family history - histórico familiar;
• Social history - histórico social;
• Vital signs - sinais vitais (mais utilizado para monitoramento em tempo real);
• Results - resultado de exames (hemograma, endoscopia, por exemplo);
• Procedures - procedimentos cirúrgicos já realizados;
• Encounters - encontros (marcações de consultas, por exemplo);
• Medical equipment - equipamento médico;
• Plan of care - plano de saúde;
• Health care providers - instituições de saúde por onde já foi atendido e/ou que são
provedores de dados;
• Functional status - estado funcional do indivı́duo;
Estrutura
O padrão CCR utiliza XML (eXtensible Markup Language) para estruturar as informações
administrativas e clı́nicas mais relevantes. O XML é um simples formato baseado em texto
para representar informação estruturada: documentos, dados, configuração, livros, transações,
dentro outros. Este formato é um dos mais utilizados para a partilha de informação estruturada
hoje: entre programas, entre computadores e pessoas, tanto localmente e através das redes.
As figuras 1.2 e 1.3 abaixo ilustram, respectivamente, um trecho de arquivo no padrão CCR,
mostrando a seção ’Procedures’ e a correspondência visual daquele trecho do arquivo no GH.
34
Figura 1.2: Trecho de um arquivo CCR. Seção ’Procedures’.
Figura 1.3: Correspondência visual do arquivo CCR da figura 1.2 no Google Health (Google,
2009).
1.6.1.4
Subconjunto CCR do Google Health
O GH não suporta toda a especificação do padrão CCR. Somente um subconjunto do padrão
é, por enquanto, utilizado pelo serviço. Como foi apresentado anteriormente, para que um
arquivo no padrão CCR seja válido ou útil, não é necessário que todas as seções sejam utilizadas.
O subconjunto suportado pelo GH, ilustrado na figura 1.4 abaixo, é divido em três partes:
• O cabeçalho (do inglês, Header) compreende os seguintes elementos: CCRDocumen-
35
tObjectID, Language, Version, DateTime e Patient;
• O corpo do subconjunto (do inglês, Body) contem todas as seções que compõem o
elemento Body;
• E o rodapé (do inglês, Footer), representado pelo elemento Actors.
Figura 1.4: Subconjunto CCR do Google Health (Google, 2009).
Assim, um arquivo CCR, seja ele composto por uma ou mais seções, será composto por
essas três partes. O cabeçalho e o rodapé são partes, no GH, que podem ou não ser preenchidos.
Embora essas seções sejam mandatórias, o envio de informações para o serviço, como resultado
de testes, por exemplo, não necessitam obrigatoriamente de serem preenchidos, pois, caso não
sejam, o próprio GH se encarrega de preencher essas seções automaticamente, baseando-se na
origem dos dados (usuário, provedor de dados ou serviço terceiro).
36
Como as seções do padrão CCR já foram discutidas anteriormente, por conseguinte, as do
GH também já foram. Contudo, este trabalho discutirá de forma mais aprofundada somente a
seção Results, pois foi esta cujo desenvolvimento do protótipo se concentrou. Mais detalhes
sobre as demais seções suportadas pelo GH podem ser encontrados em Google (2009). A
escolha da seção Results será discutida no capı́tulo de desenvolvimento.
Results
A seção Results do padrão CCR corresponde à seção Test Results do Google Health. Nesta
seção do GH, é permitida inserção no prontuário eletrônico pessoal do indivı́duo, resultados de
exames que o paciente já tenha realizado.
Essa seção é formada, por sua vez, por um número ilimitado de elementos Result (mesma
tradução de Results, exceto por estar no singular). Assim, Results pode encadear vários resultados de exames em uma única unidade de registro, possibilitando que vários testes possam ser
inseridos em lote ou agrupados mediante algum critério de classificação.
Result
O elemento Result descreve individualmente cada resultado de exame que o paciente já
tenha realizado. Este elemento é formado, por sua vez, por outros elementos que definem sua
estrutura e conteúdo. São os elementos que compõem Result:
• Test: descreve um teste realizado;
• DateTime: indica quando um evento ocorreu - data em que um ou mais exames foram
realizados;
• Description: este elemento descreve o resultado do exame. Neste nı́vel, a descrição
é opcional, mas em caso de múltiplos testes, como em uma biópsia ou hemograma,
é muito útil incluir uma descrição mais detalhada do resultado ou uma descrição geral dos vários testes que compõe o exame maior (um hemograma, por exemplo, é
composto por sub-exames de medição de hemoglobina, hemácias,plaquetas, dentre
outros);
• Source: indica quem requisitou o(s) exame(s).
É importante salientar a peculiaridade da estrutura de elementos que compõe as seções
gerais do padrão CCR (Results, Medications, etc.). No caso da seção Results, um elemento
37
Result pode conter um ou mais elementos Test que descreve um único exame, como já foi visto.
Contudo, o próprio elemento Test possui os mesmos elementos filhos que Result (DateTime,
Description e Source) e outros mais que serão discutidos a seguir. Isso é constatado na figura
1.4. As seções CCR suportadas pelo GH compartilham em sua base (extrema direita da figura)
os mesmos elementos, diferindo, a depender da hierarquia, nos conteúdos das estruturas.
Assim, a partir deste compartilhamento de elementos entre as seções do padrão, na situação
da seção de resultado de exames, quando houver somente um exame em um Result, os elementos
filhos de Test podem ser utilizados para descrever o resultado, em vez dos elementos filhos de
Result. Por outro lado, quando houver mais de um teste compondo um exame (e.g. hemograma),
utilizam-se os elementos filhos do elemento Result, já que a descrição deste elemento será
aplicável a todos seus sub-exames.
Test
Este elemento descreve, individualmente, um exame realizado e é formado pelos mesmos
elementos filhos que seu elemento pai e de dois outros elementos filhos: NormalResult e TestResult. Segue a descrição destes dois elementos:
• NormalResult: indica os valores normais aos os quais são esperados para um determinado exame. Este elemento pode conter um texto descrevendo os resultados
considerados normais ou conter um código para representar o resultado.
• TestResult: este elemento indica os resultados obtidos de um exame. Este elemento
necessita do valor do resultado (um número ou um nome, dependendo do contexto) e
a unidade do valor (e.g. mg, ml).
DateTime
Este elemento, independente do elemento no nı́vel acima, é composto pelas seguintes estruturas:
• Type: indica o tipo da data. Por exemplo: quando o elemento DateTime possui como
elemento pai o elemento Test que, por sua vez, é elemento filho de Result ou é filho
direto deste último. Type deve ser definido como:
• Collection start date: significa que a data que será definida é a data de realização
do exame;
38
• ExactDateTime: valor exato da data e hora da realização do exame. Essa estrutura utiliza a representação ISO-8601 (CCYY-MM-DDThh:mm:ssZ ou CCYY-MMDDThh:mm:ss-hh:mm).
Description
Assim como o elemento DateTime, a estrutura de Description independe do elemento no
nı́vel acima. Como a seção que esta sendo tratada é a de Results, os valores das estruturas de
Description serão explicitados nesse contexto. Description é formado por:
• Text: uma descrição sobre o(s) exame(s) realizado(s) no paciente;
• Code: código para identificar o exame realizado. Essa estrutura possui, por sua vez,
outras subestruturas que definem Code. São elas:
• Value: representação do código utilizado. Pode ser um número ou representação
textual, como ’Diabetes’;
• CondingSystem: identifica o tipo do código utilizado. O sistema de codificação
que o GH tenciona padronizar é o LOINC. Esse sistema reúne nomes e códigos
universais para identificar resultados de exames, testes laboratoriais, dentre outros. Mais informações em Google (2009);
• Version: versão da estrutura do registro criado. Valor suportado atualmente:
’V1.0’.
Source
Este elemento é formado por uma única subestrutura chamada Actor. Essa subestrutura
identifica o profissional de saúde que prescreveu o exame ao paciente. Por sua vez, essa subestrutura é formada pelos seguintes elementos:
• ActorID: primeiro nome e sobrenome do associado. Por exemplo: ”Matheus Cardoso”;
• ActorRole: identifica a relação entre o paciente e o profissional de saúde relacionado
ao exame. O elemento ActorRole pode ter três valores diferentes. Contudo, sob a hierarquia Results/Result ou Results/Results/Test, somente a representação textual ’Ordering clinician’ é suportada (tradução própria: clinico que requereu o(s) exame(s)).
39
As figuras abaixo ilustram,respectivamente, a especificação dos valores para cada elemento
da seção Results (figura 1.5), a construção do arquivo no padrão CCR (figura 1.6) e o resultado
visual deste arquivo no GH (figura fig:testresults).
Figura 1.5: Quadro exemplo de especificação para valores para os elementos de Results (Google, 2009).
Figura 1.6: Trecho de um arquivo CCR ilustrando a construção em XML para a seção Results.
40
Figura 1.7: Resultado de exame das figuras 1.5 e 1.6 exibido no Google Health (Google, 2009).
1.6.1.5
Serviços de comunicação e integração de dados
A camada de comunicação e integração de dados é responsável por realizar a comunicação
entre a base de dados do GH e a camada que engloba os atores que interagem com o serviço,
discutida mais adiante. Além disso, é essa camada que gerencia como os dados são agregados
e organizados no GH.
O GH utiliza duas tecnologias bastante utilizadas na troca de informações através da web:
Atom e RSS 2.0 (Google,2009). Essas tecnologias são formas alternativas de acessar o conteúdo
de um site. Assim como o padrão CCR, Atom e RSS 2.0 utilizam XML para estruturar os dados.
É através destas tecnologias que o GH gerencia as buscas e criação de novos registros em
sua base de dados. Embora o GH suporte ambas, Atom é a tecnologia padrão do serviço (e
de todos os serviços Google). O desenvolvedor pode optar por escolher o RSS 2.0 se desejar.
Todavia, independente da tecnologia usada, ambas , nos processos de busca e criação, geram
estruturas chamadas feeds. São essas estruturas que são enviadas para um aplicativo terceiro
quando este requer ou (envia nova) informação de alguma conta de usuário do GH. Os feeds
são agrupados da seguinte forma (Google,2009):
• Profile feed - é um conjunto de entradas que, coletivamente, descrevem as condições
médicas do usuário (seção Conditions), medicamentos (seção Medications), resultados de teste (Results), e outras informações de saúde. Essa fonte contém os dados
digitados pelo usuário e os dados enviados por terceiros. Se o usuário garantiu acesso
á alguma aplicação terceira a seu prontuário, é por esse grupo de feeds que a aplicação
41
terá de passar para ler informações da conta de um usuário;
• Register feed - Uma entrada nesse grupo de feeds representa uma única ’notı́cia’(do
original em inglês, notice) no painel de avisos do usuário. Este agrupamento de feeds é usado para coletar dados de fontes externas do GH, como provedores de dados.
Mensagens individuais para este grupo são conhecidas como notices. As notices,
ou notı́cias, podem conter texto simples (incluindo certos elementos HTML),um documento CCR ou ainda ambos. Por exemplo, as notı́cias podem ser enviadas para
lembrar os usuários de pegar uma receita ou eles podem conter resultados de exames
em anexo (em um arquivo CCR). É somente através destes feeds que um provedor
de dados ou serviço terceiro podem enviar, através de notı́cias, novos dados para o
prontuário de um usuário.
A figura 1.8 abaixo ilustra a estrutura básica desta camada.
Figura 1.8: Estrutura da camada de serviços de comunicação e integração de dados.
A figura acima, além de ilustrar a estrutura dos feeds, mostra também que é esta camada que
suporta a comunicação com aplicações externas desenvolvidas nas linguagens de programação
mostradas na figura. Entre as mais utilizadas estão as linguagens Java, .Net e PHP e Python (as
demais foram recentemente integradas ao serviço).
O próprio GH, através desta camada de comunicação, provê ferramentas (client libraries)
desenvolvidas nessas linguagens, no intuito de facilitar o desenvolvimento e a comunicação
de aplicações terceiras com o GH. A utilização dessas ferramentas exime o desenvolvedor de
preocupar-se com problemas de desenvolvimento em baixo nı́vel e proporciona maior produtividade. Contudo, o conhecimento da arquitetura de comunicação do serviço ainda se faz
necessário para saber que tipo de grupo de feeds será acessado para fazer leitura ou escrita de
dados nas contas do GH.
42
1.6.1.6
Serviços de autenticação e autorização
Os serviços Google são protegidos por contas de usuário relacionadas, como é o caso do
GH. Para que aplicações terceiras possam se comunicar com estes serviços faz-se necessário
que os usuários detentores de suas contas garantam o acesso às aplicações de maneira explicita.
Isso significa que um aplicativo externo, como o protótipo deste trabalho, precisa de alguma
forma de gerenciamento de autorização do usuário para poder requerer o acesso a um serviço
e manejar o garantia do acesso. O Serviço de Autenticação Google (SAG) ajuda a simplificar
essa tarefa, validando as solicitações de acesso e emitindo sı́mbolos de autenticação para as
aplicações terceiras.
O SAG dispõe de cinco mecanismos de autenticação para acesso a contas de usuários relacionadas a serviços. Os mecanismos são os seguintes:
• ClientLogin: utilizado no processo de autenticação de aplicações standalone ou desktop;
• FederatedLogin: forma de autenticação para aplicações web basaeda no padrão OpenID (Google, 2009);
• OAuth: forma de autenticação para aplicações web de desenvolvimento livre e comunitário;
• AuthSub: forma de autenticação para aplicações web desenvolvida pelo próprio GH;
• GadgetAuthentication: autenticação para gadgets.
Dentre estes serviços, o último não será abordado, pois este trabalho não intenta desenvolver
um gadget (Google, 2009).
Aplicativos utilizam estes mecanismos com o fim de comunicar-se com uma conta de
usuário relacionada a um serviço, como a conta de um usuário do GH. Com estes mecanismos, os usuários podem acessar suas contas Google e, a partir destas, garantir ou não o acesso
às aplicações terceiras à suas contas. Todos os mecanismos do SAG trabalham com chaves
(tokens) que são associadas às contas dos usuários dos serviços da empresa. Contudo, cada
mecanismo trabalha com um ou mais tipos de tokens.
As aplicações web podem operar registradas ou não junto a um serviço Google. Existem
três nı́veis de registro:
43
• Não registrado: a aplicação não é reconhecida por Google. A página de requisição
de acesso (vide figura 1.9), que exibe aos usuários uma mensagem para conceder ou
negar o acesso para a aplicação terceira, exibe uma precaução destacada em amarelo: ”This website has not registered with Google. We recommend that you continue
the process only if you trust this destination” (tradução própria: ”Este site não foi
registrado com Google. Recomendamos que você continue o processo somente se
você confiar neste destino”); Os serviços que aceitam aplicações não registradas não
impõem quaisquer restrições para as aplicações.
• Registrado: a aplicação é reconhecida por Google. A página de requisição de acesso
exibe o seguinte aviso: ”This website is registered with Google to make authorization
requests, but has not been configured to send requests securely. We recommend that
you continue the process only if you trust the following destination” (tradução própria:
”Este site está registrado com Google para realizar requisições de autorização, mas
não está apto para enviar requisições seguras. Nós recomendamos que você continue
o processo somente se você confiar no destino a seguir”);
• Registrado com segurança aprimorada: este modo permite que aplicações registradas possam utilizar um certificado de segurança para as transações de autenticação
e comunicação, manuseando tokens seguros. A página de requisição, de acesso remove a mensagem de precaução e exibe uma nova mensagem: ”Google is affiliated
with ’the requesting application’, and we recommend that you grant access only if
you trust the site.” (tradução própria: ”Google é afiliado com ’nome da aplicação que
está pedindo o acesso’ e nós recomendamos que você garanta acesso, mas somente se
você confiar neste site”).
O registro faz com que a aplicação seja ”conhecida” por Google, fazendo com que esta
seja reconhecida como uma aplicação confiável. O registro de uma aplicação web que se quer
comunicar com um serviço da Google não é obrigatório, embora alguns serviços Google não
aceitem comunicação não registrada. Até o presente momento da pesquisa, não foi encontrado
qualquer indı́cio de que haja algum custo para esse registro.
ClientLogin
O mecanismo de autenticação ClientLogin, de autoria da Google, é utilizado no processo
de autenticação de aplicações standalone ou desktop (programas que são executados diretamente em um computador pessoal, portátil, etc.). A autenticação com ClientLogin requer que
44
Figura 1.9: Exemplo de uma página de autorização
a aplicação terceira requisite do usuário seu nome de acesso e sua senha toda vez que tenha
de se comunicar com um serviço Google. Após a validação dos dados do usuário, o serviço
Google em questão envia uma chave (chamada de token) para a aplicação terceira. Munido
desta chave, que autoriza o acesso da aplicação à conta do usuário no serviço, a aplicação executa as requisições subsequentes da comunicação sem que peça novamente os dados de acesso
do usuário. Esta chave somente é válida para uma única sessão de uso. Ao se iniciar uma
nova sessão, a aplicação deverá requisitar ao usuário suas informações de acesso e requerer,
novamente, um ’token’.Este mecanismo de autenticação utiliza somente um tipo token: o Onetime-use token. Este tipo expira após o término de uma sessão de uso de um serviço.
O processo de autenticação com ClientLogin envolve uma sequência de interações entre
três entidades: o aplicativo instalado na máquina do usuário, um serviço Google e o usuário. A
figura 1.10 a seguir ilustra o processo de comunicação entre as entidades citadas, utilizando o
ClientLogin
Figura 1.10: Processo de autenticação com ClientLogin.
45
Os passos do processo de autenticação ilustrado acima são detalhados a seguir:
1. Quando o aplicativo terceiro precisa acessar o serviço Google em que um usuário possui
conta, este aplicativo requisita ao usuário seus dados de acesso;
2. O aplicativo terceiro, munido dos dados de acesso do usuário, em seguida, faz uma chamada ao SAG;
3. Se o SAG decidir que é necessária uma verificação adicional, ele retorna uma resposta
de falha contento um CAPTCHA, na forma de uma URL para uma imagem CAPTCHA
(Google, 2009);
(a) Se um desafio CAPTCHA é recebido, o aplicativo terceiro exibe a imagem CAPTCHA para o usuário e solicita uma resposta do usuário para o CAPTCHA recebido;
(b) Se requisitado, o usuário envia uma resposta ao desafio CAPTCHA;
(c) O aplicativo terceiro faz uma nova chamada, desta vez incluindo a resposta para o
desafio;
4. Em uma tentativa de acesso bem sucedido (com ou sem o desafio), o SAG retorna um
token para o aplicativo;
5. Após o processo de autenticação propriamente dito, a aplicação entra em contato com o
serviço em questão com um pedido de acesso aos dados, utilizando o token recebido do
SAG;
6. Se o serviço Google reconhece o token enviado pela aplicação, o serviço fornece o acesso
aos dados solicitados.
FederatedLogin
Este serviço é outra forma de autenticação de desenvolvimento livre e aberto, que a Google
suporta para comunicação com aplicações web. Essa forma de autenticação, baseada no padrão
OpenID , libera os usuários de ter que criar contas separadas para sites diferentes, eximindo,
também, os desenvolvedores da tarefa de desenvolver medidas de autenticação de acesso para
novas contas de usuário. O padrão OpenID atinge este objetivo, proporcionando um quadro no
qual os usuários podem criar uma conta com um provedor de OpenIDs, como Google, e usar
essa conta para iniciar sessão em qualquer outro site que aceite OpenIDs (Google,2009).
O processo de autenticação utilizando o modo de autenticação FederatedLogin é ilustrado
e descrito a seguir:
46
Figura 1.11: Processo de autenticação usando FederatedLogin.
1. O usuário requisita o serviço provido pela aplicação web;
2. A aplicação web solicita ao usuário final para acessar sua conta, oferecendo um conjunto
de opções de acessos, incluindo o uso de sua conta do Google;
3. O usuário seleciona a opção ”Sign in with Google”(tradução própria: ”Entrar com o Google”);
4. O aplicativo web envia um pedido de ”descoberta” (do original, discovery request) ao
SAG para obter informações sobre o usuário;
5. Google devolve um documento XRDS (Google,2009), que contém o endereço final referente à conta do usuário em questão;
6. O aplicativo web envia uma solicitação de autenticação de login (opcionalmente com
parâmetros OAuth - seção seguinte) para o endereço final ,retornado no passo anterior, do
usuário;
7. A ação anterior redireciona o usuário para uma página do Google Federated Login;
8. O usuário acessa sua conta Google. Daı́ é exibida uma página de confirmação e pede
ao usuário para confirmar ou rejeitar um conjunto de solicitações de autenticação através
da aplicação web. Se o aplicativo está usando OpenID + OAuth (protocolo hı́brido), o
47
usuário também é convidado a aprovar o acesso a um determinado conjunto de serviços
do Google;
9. Se o usuário aprova a autenticação, Google retorna o usuário para a aplicação web e
fornece um identificador que o aplicativo pode usar para reconhecer o usuário. Com a
utilização do protocolo hı́brido, um token de pedido de autorização também é retornado;
10. O aplicativo web usa o identificador fornecido por Google para reconhecer o usuário e
acessar os dados alvo. Para o uso do protocolo hı́brido, o aplicativo web usa o token de
solicitação para continuar a sequência OAuth (na etapa 7 deste processo de autenticação)
e ter acesso aos serviços Google do usuário.
Perceba que neste modo de autenticação, a despeito do uso do protocolo hı́brido, não há
restrições ou classificações de token ou modos de operação.
OAuth
Google suporta outro mecanismo para aplicações web: o mecanismo de autenticação OAuth.
Este mecanismo não é uma criação da empresa. Esta desenvolveu um processo de autenticação
baseado nesse mecanismo.
O OAuth é um mecanismo de desenvolvimento livre e comunitário de autenticação que
permite ao usuário conceder acesso aos seus recursos privados de um site para outro site ou
aplicação terceira. Este mecanismo somente garante acesso único e exclusivamente à conta do
usuário relacionada ao serviço que está sendo requerido. Essa forma de autenticação requer que
todas as requisições sejam assinadas com algum mecanismo de segurança para transmissão de
dados, como por exemplo, criptografia (Google, 2009).
Atualmente, Google suporta uma versão hı́brida do mecanismo OAuth, combinando-o com
o FederatedLogin. O OAuth possui a vantagem de eximir a aplicação terceira de manejar as
informações de acesso do usuário a seu serviço, diferentemente do que acontece com o
ClientLogin. OAuth envolve as seguintes entidades no processo de autenticação: a aplicação
terceira, um serviço Google e o usuário final. O diagrama a seguir ilustra como se desenvolve
o processo de comunicação do OAuth e após o diagrama segue a descrição mais detalhada a
respeito da sequência ilustrada:
1. O usuário requisita o serviço provido pela aplicação web;
48
Figura 1.12: Processo de autorização utilizando OAuth.
2. A aplicação terceira web contata o SAG, pedindo um token de requisição para um ou mais
serviços Google;
3. O SAG responde o contato com um token não-autorizado;
4. O aplicativo requisita autorização para token de requisição antes recebido;
5. A aplicação web direciona o usuário final para uma página de autorização Google (figura
1.9, fazendo referência ao token de requisição pedido no passo 1;
6. Na página de autorização do serviço Google, o usuário é solicitado a acessar sua conta
(para verificação) e, em seguida, conceder, limitadamente, ou negar o acesso à aplicação
web aos seus dados do serviço.
7. O usuário decide se concede ou nega o acesso à aplicação. Se o usuário nega o acesso,
ele é direcionado para uma página da Google em vez de voltar para a aplicação terceira
que requisitou o acesso.
8. Se o usuário concede acesso, o SAG redireciona o usuário de volta para a aplicação. O
redirecionamento inclui um token de requisição, desta vez, autorizado.
9. A aplicação terceira envia uma requisição para o SAG para trocar o token de requisição
autorizado por um token de acesso;
49
10. O SAG verifica a requisição do passo anterior e retorna, se válida a requisição, um token
de acesso;
11. A partir deste ponto, a aplicação web envia uma requisição para o serviço alvo. Essa
requisição é assinada pela presença do token de acesso;
Se o token de acesso for reconhecido pelo serviço alvo Google, este dá o acesso aos dados
à aplicação web.
Como pode ser visto na descrição anterior, o processo de autenticação de OAuth envolve
dois tipos de tokens: de requisição e de acesso. Tokens de requisição são usados para verificar o
registro da aplicação terceira junto a Google e conseguir a autorização do usuário final. Somente
após a autorização do usuário final é que esses tipos de tokens podem ser trocados por tokens
de acesso. Estes, por sua vez, são utilizados pela aplicação terceira para requisitar acesso aos
dados do serviço coberto pelo token (Google, 2009).
Os tokens de requisição, válidos por uma hora após a emissão, podem ser encontrados
em dois estados: não-autorizados e autorizados. Como pode ser visto na descrição anterior,
inicialmente o SAG emite um token de requisição não-autorizado. Uma vez concedido o acesso
pelo usuário, o estado do token muda para autorizado. Somente tokens autorizados podem ser
utilizados para trocar por tokens de acesso - essa troca só pode ser feita uma vez.
Cada token de acesso é especifico para uma conta de usuário e cobre somente o serviço
especificado na requisição inicial (passo 1.) feita para o SAG. De forma pré-definida, tokens
de acesso podem ser usados a qualquer momento pela aplicação web quando esta comunicar-se
com o serviço. Assim, não necessitará mais da intervenção do usuário para comunicar-se com
o serviço.
AuthSub
Este mecanismo de autenticação é mais um mecanismo provido pelo SAG para as aplicações
web. O AuthSub é um mecanismo de autenticação desenvolvido pela própria Google. O processo de autenticação deste mecanismo é semelhante ao OAuth e também não necessita manusear as informações sigilosas do usuário (nome de acesso e senha pessoal) para acessar um
conta. O resultado disso é o aumento da segurança da comunicação da aplicação com o serviço,
pois a aplicação se exime de manusear as informações sensı́veis do usuário, diminuindo a possibilidade de violação destes dados.
O processo de autenticação AuthSub envolve uma sequência de interações, semelhante ao
mecanismo anterior, de três entidades: a aplicação web, um serviço Google e o usuário que
50
possua conta no serviço em questão. A figura 1.13 a seguir ilustra essa sequência e após o
diagrama segue o detalhamento dos passos do processo ilustrado.
Figura 1.13: Processo de autenticação usando AuthSub.
1. O usuário requisita o serviço provido pela aplicação web;
2. Quando uma aplicação web precisa acessar um serviço Google de um usuário, ele faz
uma chamada usando o mecanismo AuthSub para o SAG;
3. O SAG responde enviando para o usuário uma página de solicitação de acesso (vide figura
1.9). Esta página, gerenciada por Google, mostra ao usuário uma mensagem explicando
que uma aplicação quer acessar os dados de sua conta. Além da mensagem, está página
exibe as opções para conceder ou negar o acesso aos seus serviços Google. Caso o usuário
não esteja conectado a sua conta antes da exibição da página de solicitação de acesso, o
GH envia a página de acesso para que o usuário acesse sua conta e, assim, exibir a página
autorização. Caso ainda o usuário não possua conta no serviço em questão, ele será
redirecionado para criar uma nova conta, daı́ a página de consentimento será exibida;
4. O usuário decide se concede ou nega o acesso à aplicação terceira. Se o usuário nega o
acesso, ele é direcionado para uma página Google em vez de voltar para a aplicação que
requisitou o acesso.
5. Se o usuário concede acesso, o SAG redireciona o usuário de volta para a aplicação web.
O redirecionamento contém um token que autoriza uma única utilização, mas que pode
ser trocado por um token para múltiplos acessos;
6. A aplicação terceira contata o serviço Google com um pedido de utilização, utilizando o
token de autorização para atuar como um agente para o usuário.
51
7. Se o serviço Google reconhece o token, ele fornece acesso aos dados solicitados.
O AuthSub trabalha com os seguintes tipos de tokens:
• One-time-use token (já descrito no tópico que tratou sobre o ClientLogin);
• Session token: não expira após o término de uma sessão. É válido para quaisquer
sessões subsequentes de uso em um serviço associado a um usuário.
De forma pré-determinada, o SAG retorna um ’one-time-use token’ no processo anteriormente ilustrado e descrito. Para que esse tipo de token seja trocado por um ’session token’,
basta que a aplicação web faça uma solicitação ao SAG para trocar o token.
1.6.1.7
Interface com usuário, serviços terceiros e provedores de dados
Essa camada é composta por sub-camadas que englobam todos os tipos de atores que podem
interagir com o GH. São elas:
• Provedores de dados: são as instituições clı́nicas pelas quais o indivı́duo foi atendido,
laboratórios onde foram realizados exames, empresas de plano de saúde, farmácias,
dentre outros. Esses atores são detentores de informações administrativas e de saúde
relevantes, das quais um indivı́duo possa querer manejá-las diretamente. Assim, esses
atores podem desenvolver aplicações que possam comunicar-se com o GH, enviando
somente dados relevantes para o prontuário pessoal do indivı́duo. O protótipo deste
trabalho se encaixa nessa camada de interação;
• Serviços terceiros: essa sub-camada comporta as aplicações que se propõem a realizar
serviços extras aos do GH. Como ferramentas de buscas de prescrição de medicamentos,de medicamentos em farmácias, marcação de consultas médicas on-line, busca de
artigos relacionados às informações existentes no prontuário, dentre outros;
• Interface com usuário: esta sub-camada comporta as ferramentas de interação do GH
com os usuários finais. É através desta sub-camada que os usuários podem manejar
as informações existentes em seu prontuário, compartilhar-lo, verificar o histórico
de acesso de outrem que tiveram permissão de acesso, de provedores de dados que
enviaram informações, pesquisar sobre as doenças existentes no banco de dados do
serviço, dentre outras possibilidades;
52
2
Desenvolvimento
2.1
Metodologia
O desenvolvimento de todo estudo desta monografia foi pautado nas seguintes etapas:
1. Revisão bibliográfica, estudo de viabilidade e definição de escopo
(a) Levantamento e estudo das fontes de pesquisa: essa etapa compreendeu o angariamento e estudo das fontes de pesquisa para a monografia, tanto para a parte escrita,
que foi a maior parte, quanto para a parte de desenvolvimento (embora as fontes
desta última estivessem, em grande parte, concentradas no site do GH) Além disso,
como PEP é um conceito ainda em desenvolvimento, a maioria das fontes de estudo
foram artigos publicados em congressos, apresentações, dentre outros. Somente
Massad, Marin e Neto (2003) mostrou-se uma fonte mais completa em relação aos
conceitos de prontário médico, PME e PEP;
(b) Criação de resumos semanais a respeito das fontes e dos estudos realizados: esta
etapa compreendeu o processo de criação de resumos (e apresentações) a respeito
dos assuntos estudados durante a etapa de levantamento da bibliografia. Esse processo foi bastante relevante para direcionar os estudos da pesquisa, evitando que
esta abrangesse ou restringisse demais os estudos;
(c) Pesquisa e estudo de casos relacionados ao PME e PEP: essa etapa compreendeu
no processo de pesquisar por trabalhos já existentes relacionados ao PME e PEP.
O primeiro não foi laborioso, já que o conceito de PME é bastante consolidado,
tanto no Brasil quanto no mundo. Contudo, encontrar casos ou estudos que se encaixassem em projetos de PEP foi bastante difı́cil. Com exceção das inciativas mais
expressivas da Google e da Microsoft, com seus projetos de PEP, os demais softwares encontrados não pareciam mais do que uma escolha qualquer entre as poucas
existentes. Projetos de escala nacional foram mais árduos ainda de serem encontrados, pois a maior potência econômica do mundo era carente de um sistema de saúde
53
de qualidade e integrado. Contudo, o estudo de Jalal-Karim e Balachandran (2008)
mostrou os projetos e estudos em uso ou em processo de estudo e implantação de
PME e PEP em escala nacional nos paı́ses citados no trabalho;
(d) Estudo de viabilidade de uso e desenvolvimento usando o Google Health: esta etapa
compreendeu em estudar a viabilidade de uso para desenvolvimento com o GH fora
de seu paı́s de origem. Já que, oficialmente, o GH só estava disponı́vel para os EUA.
(e) Criação da prova de conceito para atestar a viabilidade do desenvolvimento do
protótipo: verificado positivamente o uso do GH para o desenvolvimento de protótipos
utilizando sua plataforma, tinha de ser desenvolvido uma aplicação com funcionalidades mı́nimas (leitura e envio de dados) para testificar a viabilidade de se desenvolver uma aplicação nos moldes da proposta deste trabalho e no tempo disponı́vel;
(f) Estudo sobre a arquitetura do GH: esta etapa consistiu no estudo mais aprofundado
do GH. Toda documentação e descrição da seção 1.6.1 foi concebida baseada no
estudo da arquitetura do GH e da documentação provida por este;
(g) Reunião com a empresa parceira e definição do escopo do protótipo: esta etapa foi
importante para a definição do escopo da aplicação. Duas reuniões foram feitas
com a empresa: na primeira discutiu-se, principalmente, o que era mais usado no
mercado em relação a entregar através da internet informações clı́nicas aos pacientes. Nessa primeira reunião definiu-se o foco de desenvolvimento do protótipo:
resultados de exames. A segunda reunião foi realizada para se conhecer os produtos Medicware e definir quais ou qual deles mais se encaixava na proposta deste
trabalho. E por fim, a empresa comprometeu-se a fornecer documentos de testes
baseados nos sistemas médicos cobertos pela empresa para a realização dos testes
do protótipo;
2. Produção da aplicação
(a) Definição dos requisitos: foram definidos quais seriam as funcionalidades presentes
no protótipo.
(b) Definição dos processos (geral e especı́fico): aqui foi idealizado em que cenário
o protótipo se inseriria no contexto geral entre usuário e o sistema de entrega de
exames laboratoriais (figura 2.1). Além disso, foi definido também o fluxo de dados
interno do protótipo (figura 2.2);
(c) Definição da arquitetura: definição da arquitetura da aplicação;
(d) Produção do software: desenvolvimento propriamente dito do protótipo;
54
(e) Testes das funcionalidades: testes das funcionalidades do protótipo utilizando os
arquivos providos pela empresa e juntamente com o GH;
3. Escrita da monografia.
É importante ressaltar que muitas das etapas descritas se sobrepujaram, devido ao tempo reduzido para a realização de todas elas. Por exemplo, a etapa de escrita da monografia estendeuse desde praticamente o inı́cio dos trabalhos até o fim; a produção da aplicação iniciou-se desde
o estudo de viabilidade do uso do GH. O estudo da arquitetura do GH, devido a documentação
ainda escassa, por ser um serviço ainda em desenvolvimento, perdurou até meados da produção,
propriamente dita, do software.
2.2
A aplicação
A proposta apresentada para este trabalho, em relação ao desenvolvimento do protótipo,
apontou dois objetivos:
• Viabilizar a centralização do prontuário criando um protótipo que comunique um sistema de uma instituição médica real com um serviço existente de prontuário eletrônico
pessoal;
• Testar, validar e documentar o protótipo de integração junto a empresa parceira.
Dentre os mecanismos de autenticação disponı́veis pelo SAG e aqui descritos, este trabalho
optou por desenvolver o protótipo utilizando o modo de autenticação AuthSub. Os seguintes
pontos foram culminantes em relação à escolha:
• O mecanismo de autenticação AuthSub é desenvolvido pela própria empresa;
• Por ser de criação própria, a documentação é de mais fácil acesso e mais numerosa;
• A empresa possui grupos e fóruns de discussão orientados para o serviço GH, focando
nos mecanismos de autenticação da própria empresa;
• Por ser um protótipo, foram priorizadas as funcionalidades principais da proposta,
relegando as questões de segurança aos patamares mı́nimos (sem uso de criptografia,
por exemplo);
55
• Como o AuthSub pode operar de forma não registrada e utilizando token não-seguros,
facilita a produção de software de testes para interação com os serviços Google. Desta
forma, exime o desenvolvedor da obrigação de registrar-se junto à empresa e a criar
mecanismos extras de segurança.
Antes de partir para a discussão da produção, testes e resultados do protótipo, um pouco
será discorrido a respeito da empresa parceira e como ela foi importante no rumo e definição do
escopo da aplicação.
2.3
A empresa parceira
A Medicware Sistemas de Informática atua, diretamente, no desenvolvimento e fornecimento de soluções tecnológicas (softwares) e serviços agregados as mesmas (consultoria, treinamento) para o mercado de saúde do Brasil. Mais especificamente para hospitais, clı́nicas,
laboratórios, consultórios e Home Cares que compõem o cenário de unidades do Sistema de
Saúde Complementar em todo paı́s.
Atualmente a Medicware possui uma linha de produtos para estabelecimentos médicohospitalares, possuindo quatro sistemas principais: SmartHealth, SmartClin, SmartLab e SmartDoctor.
• O SmartHealth - Sistema de Informação Hospitalar, é a solução em gestão estratégica
e operacional, estruturado de forma a atender por completo às necessidades das diversas especialidades e perfis profissionais presentes nas unidades hospitalares.
• O SmartClin é o Sistema de Gestão Clı́nica que possui controle do fluxo informacional das demandas operacionais e gerenciais nas unidades de consultas, exames
diagnósticos e Day Hospital.
• O SmartLab - Sistema de Informação Laboratorial é a solução que integra um conjunto de módulos voltados para atender a rotina dos laboratórios de patologia clı́nica,
cobrindo o atendimento do paciente, a coleta do material e identificação das amostras,
com total rastreabilidade, passando pela realização das análises, aquisição, crı́tica e
liberação de resultados, até a emissão e entrega dos laudos, seja na unidade principal,
nos postos de coleta ou via WEB.
• O SmartDoctor funciona totalmente web, online, oferecendo uma solução acessı́vel
24 horas utilizando apenas seu navegador de internet. O SmartDoctor possui funcio-
56
nalidades especı́ficas que apoiam as tarefas e rotinas do consultório, filtrando erros e
prevenindo falhas, integrando e agilizando os processos de um consultório. contratos
de suporte e manutenção.
Estes produtos já são ofertados nacionalmente pela empresa, tanto através da matriz em
Salvador, quanto por parceiros em variados estados, como a MedicNor em Recife, a AMWare
em Natal, a R7 em Brası́lia, e a WiseTech em Feira de Santana, provendo também contratos de
suporte e manutenção.
O protótipo desenvolvido neste trabalho visa à agregação de valor a este portfólio de produtos, propiciando uma melhor integração entre os estabelecimentos que utilizam os sistemas
da Medicware, bem como o fornecimento de uma interface de comunicação com outros estabelecimentos que utilizam outros sistemas. Analisando cada sistema, dos recursos disponı́veis
no Google Health, do que era mais relevante, atualmente, para os pacientes e a partir da experiência de mercado da empresa na área de saúde, foi que o desenvolvimento do protótipo
deste trabalho voltou-se à entregar ao paciente/usuário seus exames laboratoriais diretamente
em seu prontuário eletrônico pessoal.
2.4
Requisitos
Atualmente, dentre as informações de saúde concernentes aos indivı́duos que mais estão
sendo entregues através da web são os resultados de exames. Muitos laboratórios permitem que
os indivı́duos que nesses estabelecimentos realizaram exames, possam resgatar os resultados
através da internet, assegurando a privacidade destes pacientes com mecanismos de segurança
e autenticação, como nomes de usuário e senha. A partir deste contexto que o protótipo foi
testado em conjunto com o SmartLab que já possuı́a um processo de autenticação (nome de
usuário e senha).
É mais cômodo para o usuário não deslocar-se de onde estiver para resgatar os resultados de
seus exames. Através da internet, o indivı́duo pode consultar os resultados diretamente do site
do laboratório onde foram realizados os exames. Contudo, no processo de acompanhamento de
saúde de qualquer pessoa, é importante ter em mãos todas as informações de saúde possı́veis
para tratar qualquer tipo de enfermidade. Resultados laboratoriais são peças-chave no acompanhamento de saúde de qualquer indivı́duo. Dessa maneira, não basta consultar os resultados
de exames, faz-se necessário resgatá-los também, como, inclusive, é possı́vel fazê-lo através da
internet.
57
Todavia, o processo de resgate dos exames oriundos dos laboratórios via internet inverte
o caminho da sistematização das informações de saúde: retornando-os para a representação
em papel (imprimindo-os). Não obstante, como já foi dito no inı́cio deste trabalho, seja nas
instituições de saúde ou nas residências dos pacientes, o processo de acompanhamento e gerenciamento das informações de saúde de qualquer indivı́duo tente a deteriorar-se com o tempo
devido ao aumento expressivo do volume de papéis.
É nesse ponto especı́fico que o protótipo desenvolvido por este trabalho propõe outra solução.
Em vez de o indivı́duo resgatar seus resultados de exames diretamente para a forma de papel, ele
pode, considerando a situação da presença deste protótipo em um desses laboratórios que entregam exames via web, o indivı́duo tem a opção de enviar aqueles resultados para seu prontuário
eletrônico pessoal em sua conta no GH. Dessa forma, toda a informação estará organizada, sistematizada, disponı́vel e acessı́vel a qualquer momento e em qualquer lugar através da internet.
2.5
2.5.1
Projeto
Processos
O processo geral da proposta deste trabalho pode ser representado e descrito das maneiras
que se seguem:
Figura 2.1: Processo geral de comunicação do protótipo com o Google Health e um sistema
Medicware.
1. O usuário/paciente acessa um sistema de laboratório em que o SmartLab, por exemplo,
esteja sendo utilizado, e intenta resgatar seus respectivos resultados de exames.
2. O sistema mostra os exames disponı́veis e, se utilizando do protótipo deste trabalho, exibe
ao usuário a opção de enviar aqueles exames para sua conta no GH. Lembrando que foi
visto na seção em que foram tratados os serviços de autenticação e autorização do GH
que, caso o usuário não possua uma conta, o SAG o envia para criar uma nova conta e,
então, autorizar o acesso.
58
3. Escolhido o exame no sistema Medicware, este sistema envia o exame escolhido, no
formato XML já conhecido, para o protótipo.
4. O protótipo processa o pedido enviado e envia os exames para a conta do usuário no GH.
O processo geral mostra a simplicidade da integração de um sistema externo com a aplicação
deste trabalho. Assim como ilustrado e descrito, basta que o protótipo seja acionado de alguma
maneira (um botão, por exemplo) e que seja enviado para este um arquivo XML no formato
correto.
O último passo do processo geral envolve mais do que somente a extração dos dados do
XML de entrada e envio das informações. O fluxograma a seguir mostra como o passo 4 envolve
várias verificações antes de enviar (ou não) os exames para o GH.
Ao receber o XML dos resultados de exames, o protótipo extrai todas as informações relevantes do documento, sejam elas para mapear para o padrão CCR, seja para controle interno
(como o código do paciente e seu nome). Munido das informações do paciente extraı́das no
arquivo de entrada, o protótipo checa se esse paciente existe no banco de dados local. Essa
verificação define o caminho a ser seguindo pelo protótipo. Se o paciente não consta no banco
de dados local é porque, segundo a premissa de desenvolvimento dessa aplicação, o paciente
jamais enviou algum exame para sua conta no GH através do protótipo.
Se a verificação do paciente no registro local não retornar um valor positivo, paciente é
enviado para o processo de autorização com AuthSub. Esse fluxo só prossegue se o paciente
autorizar a comunicação do protótipo com sua conta no GH. Uma vez autorizado, o protótipo
registra o paciente no banco de dados local (nome e código) juntamente com o ’session token’
relacionado ao usuário. O tipo de token é diferente do padrão (one-time-use token), pois o
protótipo, ao receber o token, já requisita a troca. Assim, dá próxima vez que este paciente
tornar a usar o serviço, o fluxo de dados passará para quando o indivı́duo que requisitou os
serviços desta aplicação já esteja registrado localmente.
Uma vez verificado a existência do paciente no registro local, o protótipo passa para o
processo de autenticação com o GH ,sem precisar contatar o usuário, já que o token deste já
foi armazenado anteriormente. Uma vez que o GH reconheceu o token apresentado para aquele
usuário, o protótipo requisita todos os exames existentes no prontuário do paciente. Munido
destes exames existentes no perfil do paciente, o protótipo compara os códigos dos exames e
testes do GH com os exames e resultados do XML de entrada. Essa comparação é importante
para que o protótipo não envie exames repetidos para o prontuário do paciente.
59
Figura 2.2: Fluxograma da operação do protótipo.
60
Somente após a filtragem dos exames existentes e a serem enviados é que o protótipo passa
para a etapa de mapeamento XML e de depois para a camada de comunicação para enviar os
exames requeridos.
2.5.2
Arquitetura
A arquitetura do protótipo foi criada para que fosse a mais extensı́vel possı́vel dentro do
tempo disponı́vel e da proposta deste trabalho. Atualmente este protótipo somente reconhece
arquivos XML no padrão Medicware. Contudo, a arquitetura da aplicação foi criada para que,
caso outras empresas ou instituições ”comprassem” a proposta, novos padrões de XML fossem
simplesmente adicionados, sem alterar a estrutura principal do software. Além disso, muito
mais proporcionado pela escolha da linguagem, esta aplicação pode ser hospedada em qualquer
servidor web, exceto aqueles de arquitetura proprietária. Dessa maneira, numa eventual atuação
mercadológica do protótipo, este poderia ser comercializado como um serviço, já que este não
altera a estrutura dos sistemas em que este se acoplou para os testes.
A arquitetura do protótipo pode ser visualizada da seguinte maneira na figura 2.3 abaixo.
Figura 2.3: Arquitetura do protótipo
2.5.2.1
Processamento XML
A camada de processamento XML é responsável por extrair as informações dos documentos
(XML) oriundos dos sistemas Medicware e do CCR do GH. Essa camada, no processo que será
visto na seção seguinte, é a primeira a ser acionada quando um documento contendo resultado
de exames é enviado para o protótipo.
61
Em relação ao XML no padrão Medicware, essa camada é responsável por extrair as
informações do paciente relacionado ao arquivo enviado, para saber para que conta no GH
enviar e registrar localmente o paciente. Além disso, é responsabilidade dessa camada extrair
os exames do arquivo e as informações relevantes e possı́veis a serem enviadas para o GH e
armazenar em estruturas temporárias para serem, posteriormente, mapeadas na camada de Mapeamento XML.
As informações dos exames extraı́das são: nome do (s) exame (s), código, data da emissão
do(s) exame (s) e os resultados. A figura 2.4 abaixo mostra um exemplo de um documento XML
de exames no padrão Medicware de um paciente de testes (embora seja de testes, a geração deste
arquivo é baseada em uma base real de dados de sistemas médicos cobertos pela empresa).
Figura 2.4: Arquivo XML de exames de um sistema Medicware.
Em relação às informações vindas do GH (arquivos CCR), essa camada exerce a mesma
função descrita para os arquivos XML da Medicware, excetuando-se que a estrutura do documento XML do GH é diferente. Esse processamento das informações oriundas de uma conta de
usuário do GH é importante para que não hajam exames repetidos em um perfil, como foi visto
fluxo de dados do protótipo na seção anterior.
A extração de informações de exames de um perfil de um usuário do GH é meramente para
fins de comparação. A figura 2.5 abaixo mostra um fragmento do documento CCR do GH de
um perfil da seção de resultados de exames (Test Results).
Esta camada também responsável por transformar o documento de resultados de exames
no padrão Medicware no formato CCR suportado pelo GH, como ilustrado nas figuras 2.4 e
2.5. Essa camada realiza duas etapas principais para formatar as informações do documento de
62
Figura 2.5: Fragmento de um documento CCR lido pelo protótipo de um perfil do Google
Health.
entrada dos resultados de exames para o formato CCR.
A primeira etapa consiste na criação da notı́cia (notice). O nome paciente(tag ’solicitação’,
vide figura 2.4) e a data de emissão do primeiro exame no documento são extraı́dos para criar
a notı́cia com tı́tulo e assunto, respectivamente. O tı́tulo da notı́cia é o aviso de chegada de
resultados de exames emitidos em uma determinada data. O assunto é o paciente relacionado
aos exames. A figura abaixo mostra o conteúdo de uma notı́cia que foi enviada para o GH com
os exames, em anexo, da figura 2.4.
Figura 2.6: Conteúdo de uma notı́cia (notice) em um perfil de testes do Google Health.
A etapa seguinte consiste no mapeamento propriamente dito das informações de arquivos
como os da figura 2.4 em arquivos no formato CCR. A correlação entre as entidades existentes
nos dois arquivos é feita da seguinte forma:
1. Todo exame (tag ’exame’) em um arquivo no formato Medicware é mapeado para um
63
elemento Result (vide seção 4.1);
2. O atributo ’nome’ de um exame é utilizado na descrição de um Result (elemento filho
Description) e o atributo ’dataresultado’ é utilizado para definir a data de emissão daquele
resultado (elemento filho DateTime);
3. No intuito de identificar unicamente os exames enviados para o GH para posteriores
comparações, foi definida a criação de um código de identificação para os exames, a
partir das informações existentes no XML de entrada. O código para exames foi definido
como a concatenação do atributo ’dataresultado’ de um exame, o sı́mbolo ’#’ e o atributo ’código’ de um exame. Por exemplo, no documento da figura 2.4, o exame ’ACIDO
URICO SORO’ terá ,no GH, o código ’01/11/200907:48#ACU’. Essa informação entra
no elemento filho de Description, o elemento Code.
4. Esse código criado foi denominado pelo desenvolvedor como ’TCC RESULT CODE’.
Essa informação entra no elemento filho de Code , o elemento CodingSystem;
5. Cada entidade ’resultado’ (tag filha de ’exame’) é mapeada para um elemento Test, elemento filho de Result. Assim, se um ’exame’ possui um ou mais ’resultado’, consequentemente um elemento Result terá um ou mais elementos Test;
6. O atributo ’atributo’ de um ’resultado’ é utilizado na descrição de um Test;
7. O atributo ’resultado’ de um ’resultado’ é utilizado para constar no elemento que guarda
o resultado propriamente dito do exame. Essa informação entra no elemento TestResult,
elemento filho de Test;
8. No intuito de também identificar os testes ou resultados unicamente, foi criado um código
somente para os elementos Test. O padrão do código é similar para os elementos Result.
O código para os resultados é composto pela concatenação do código do exame a que
pertence, o sı́mbolo ’$’, o conteúdo de ’amostra’ e o de ’atributo’. A esse código deuse o nome, para constar no elemento CodingSystem, de ’TCC TEST CODE’. Exemplo:
’01/11/200907:48#ACU$750000416836ÁCIDO ÚRICO’.
As demais informações não foram utilizadas por não terem correspondência com o padrão
CCR suportado pelo GH. Após o mapeamento para o formato XML, o novo documento é anexado à notı́cia e esta é passada para a camada de comunicação que se encarregará de fazer o
envio.
64
2.5.2.2
Autenticação e Autorização
Esta camada é responsável por realizar dois subprocessos ilustrados na figura 2.2: o processo de autorização (quando o usuário autoriza o protótipo) e o de autenticação (quando o
protótipo autentica-se com o serviço para enviar os exames). É esta camada que se responsabiliza por se comunicar com o SAG e por apresentar o token de um usuário ao GH e retornar para
o protótipo se o token foi reconhecido.
Essa camada possui ainda papel ainda mais relevante para o protótipo. Através do processo de autorização que , como já foi visto, o usuário autoriza explicitamente o envio de suas
informações clı́nicas, neste caso resultado de exames, para o GH. Este ato explı́cito do indivı́duo
exime esta aplicação dos problemas legais e éticos descritos na seção 1.3.3, principalmente em
relação a exposição dos dados clı́nicos de um paciente. Agora essa ”exposição” só feita por
este protótipo mediante autorização do próprio sujeito das informações, utilizando da lei da
autonomia citada anteriormente.
2.5.2.3
Comunicação
A camada de comunicação é responsável por fazer todas as requisições ao GH. Seja para o
envio de notı́cias (anexado CCR ou não) como acabou de ser dito, seja para fazer a leitura dos
exames já existentes em uma determinada conta de usuário. Essa camada ainda se responsabiliza por:
• Capturar o ’token’ enviado pelo serviço quando o usuário autoriza o acesso a uma
aplicação terceira;
• Requisitar a troca de um ’one-time-use token’ por um ’session token’. Dessa maneira
a aplicação não precisará mais contatar o usuário para sempre pedir novo ’token’ para
acessar sua conta;
É importante agora explicar um importante detalhe da comunicação do protótipo com o
GH. Como este ainda é um serviço em desenvolvimento e atrai, cada vez mais, o interesse
de desenvolvedores de várias partes do mundo para criar aplicações de integração de bases de
dados (como este protótipo) ou serviços terceiros, o GH somente permite que aplicações se
comuniquem com ele se registradas juntamente a Google e a ele mesmo. Esse processo é um
tanto impreciso, já que envolve o preenchimento de alguns formulários e ainda um tempo de
aprovação que varia entre poucos dias até várias semanas. Há aproximadamente duas semanas
65
atrás esse processo ganhou alguns passos automatizados que diminuı́ram a latência entre ao
registro e a aprovação. Contudo, a imprecisão do tempo de registro compromete o cronograma
de qualquer produção de software.
Com o intuito de prover as funcionalidades do serviço o quanto antes para os desenvolvedores testarem seus protótipos, eximindo-os da obrigação de criarem um domı́nio próprio,
registrá-lo, aguardar sua aprovação e então desenvolver suas aplicações, foi que a equipe do
GH criou um serviço paralelo direcionado para os desenvolvedores. O nome serviço é H9
Sandbox. Em termos de arquitetura e funcionalidades, este serviço não difere em nada do GH.
Assim, o comportamento que se tem no H9 será o mesmo quando a aplicação deixar de ser um
protótipo e se integrar diretamente ao GH. A maior diferença é que o H9 permite que o domı́nio
’localhost’ (existente em qualquer máquina de trabalho) possa ser utilizado para se comunicar
com o H9, privando o desenvolvedor de passar obrigatoriamente pelo processo de registro junto
a Google e ao GH. É através deste serviço de testes de aplicações em desenvolvimento que este
protótipo se comunicou para testar suas funcionalidades e integrar o sistema médico.
2.5.3
Tecnologias utilizadas
A aplicação produzida por este trabalho é uma aplicação web desenvolvida na linguagem
de programação Java. Já discutido anteriormente, essa linguagem está entre as suportadas nativamente pelo GH, já que este serviço disponibiliza ferramentas próprias nessa linguagem que
facilitam o desenvolvimento e comunicação de aplicações externas com o serviço. Java também
é a linguagem que mais possui documentação, suporte, e adesão dentro do serviço, além da gigantesca gama de fontes pesquisa e estudo da própria linguagem.
Além disso, no embasamento da escolha desta linguagem, foi fator crucial que o desenvolvedor deste trabalho já possuı́a conhecimentos e experiência no desenvolvimento de aplicações
nessa linguagem. Por esses motivos principais que a linguagem de programação Java foi escolhida para desenvolver esse protótipo.
Para desenvolver o protótipo nos moldes de uma aplicação web tı́pica, foram utilizadas as
seguintes tecnologias:
• JSP - Essa tecnologia de criação de páginas web com Java foi utilizada para criar
páginas de teste e de simulações das funcionalidades do protótipo;
• Servlets - Essa tecnologia é o cerne do protótipo.
66
3
3.1
Resultados
Validação
67
Considerações Finais
68
Referências
AL-SALQAN, Y. Security and confidentiality in healthcare informatics. In: IEEE COMPUTER
SOCIETY. Proceedings of the 7th Workshop on Enabling Technologies: Infrastructure for
Collaborative Enterprises. [S.l.], 1998. p. 375.
BEMMEL, J. V.; MUSEN, M.; HELDER, J. Handbook of Medical Informatics. [S.l.]: Bohn
Stafleu Van Loghum, 1997.
DICK, R.; STEEN, E.; DETMER, D. The computer-based patient record: an essential
technology for health care. [S.l.]: National Academy Press Washington, 1997.
ENDSLEY, S. et al. An introduction to personal health records. Family Practice Management,
THE AMERICAN ACADEMY OF FAMILY PHYSICIANS, v. 13, n. 5, p. 57, 2006.
FEITOZA, F. D. P. iDOCTOR. Disponı́vel em: <http://www.fmt.am.gov.br/idoctor.htm>.
Acesso em: 12 ago. 2009.
GARETS, D.; DAVIS, M. Electronic medical records vs. electronic health records: Yes, there
is a difference. himss analytics white paper. Chicago, IL: HIMSS Analytics. Retrieved August,
v. 30, p. 2006, 2006.
GOOGLE. Google Health. Disponı́vel em: <https://www.google.com/health>. Acesso em: 25
ago. 2009.
ISO. 215/WG 1: Health Informatics-Electronic Health Record-Definition, Scope and Context.
[S.l.], 2004.
JALAL-KARIM, A.; BALACHANDRAN, W. The national strategies for electronic health
record in three developed countries: General status. In: IEEE International Multitopic
Conference, 2008. INMIC 2008. [S.l.: s.n.], 2008. p. 132–138.
JUNIOR, G. de F. et al. Validade do prontuário médico eletrônico como prova jurı́dica. 2004.
KIBBE, D. C. The ASTM Continuity of Care Record, CCR, Standard: A
Brief Description for a Non-Technical Audience. april 2007. Disponı́vel em:
<http://www.ccrstandard.com/TheASTMCCRdefinition2.pdf>. Acesso em: 5 dez.
2009.
KOHN, L.; CORRIGAN, J.; DONALDSON, M. Crossing the quality chasm: a new health
system for the 21st century. Washington, DC: Committee on Quality of Health Care in
America, Institute of Medicine, 2001.
KURAITIS, V. A First Comparison of Google Health and MS HealthVault. mar. 2008.
E-CareManagement blog. Disponı́vel em: <http://e-caremanagement.com/a-first-comparisonof-google-health-and-ms-healthvault/>. Acesso em: 05 ago. 2009.
69
KWAK, Y. International standards for building electronic health record (ehr). In: Enterprise
networking and Computing in Healthcare Industry, 2005. HEALTHCOM 2005. Proceedings of
7th International Workshop on. [S.l.: s.n.], 2005. p. 18–23.
MARTINS, A.; SAUKAS, E.; ZANARDO, J. Scai: Sistema de controle de acesso para os
requisitos da saúde. In: IX Congresso Brasileiro de Informática em Saúde. [S.l.: s.n.], 2004.
MASSAD, E.; MARIN, H.; NETO, R. A. O prontuário eletrônico do paciente na assistência,
informação e conhecimento médico. São Paulo: USP: H. de F. Marin, 2003. 213 p.
MASYS, D. et al. Giving patients access to their medical records via the internet: the pcasso
experience. Journal of the American Medical Informatics Association, Am Med Inform Assoc,
v. 9, n. 2, p. 181, 2002.
MEDICWARE. Medicware Sistemas. Disponı́vel em: <http://www.medicware.com.br/>.
Acesso em: 22 ago. 2009.
MICROSOFT. Microsoft Health Vault. Disponı́vel em: <www.healthvault.com/>. Acesso em:
22 ago. 2009.
MYMEDICALRECORD. MyMedicalRecord: Secure, Web-Based Storage for Your Medical
Records. Disponı́vel em: <http://www.mymedicalrecord.com>. Acesso em: 25 ago. 2009.
NIGHTINGALE, F. Notas sobre a enfermagem. Traduzido por Amália Correa de Carvalho.
[S.l.]: São Paulo: Cortez., 1989.
PETERS, K. et al. Usability Guidance for Improving the User Interface and Adoption of
Online Personal Health Records. 2009. Disponı́vel em: <http://www.usercentric.com>.
Acesso em: 25 ago. 2009.
PIRES, F. et al. Prontuário eletrônico: Aspectos legais e situação atual. Revista da Sociedade
de Cardiologia Estado de São Paulo, v. 13, 2000.
SALVADOR, V.; FILHO, F. de A. Aspectos Éticos e de segurança do prontuário eletrônico do
paciente. II Jornada do Conhecimento e da Tecnologia, UNIVEM, Marilia, SP, 2005.
SISTEMAS, M. MV Sistemas. Disponı́vel em: <https://www.google.com/health>. Acesso
em: 22 ago. 2009.
SITTIG, D. Advantages of Computer-Based Medical Records. 1999.
SLEE, V.; SLEE, D.; SCHMIDT, J. The endangered medical record: ensuring its integrity in
the age of informatics. [S.l.]: Tringa Press, Saint Paul, MN, 2000.
STANDORD, J.; THORNTON, P. Electronic Health Records Overview. 2006. Disponı́vel em:
<www.ncrr.nih.gov/publications/informatics/ehr.pdf>. Acesso em: 25 ago. 2009.
STOLTZ, C. Microsoft Health vs. Google Health. march 2008. The
Washington Post. Disponı́vel em: <http://www.washingtonpost.com/wpdyn/content/article/2008/03/10/AR2008031001532.html>. Acesso em: 05 ago. 2009.
TANG, P. et al. Personal health records: Definitions, benefits, and strategies for overcoming
barriers to adoption. Journal of the American Medical Informatics Association, American
Medical Informatics Association, v. 13, n. 2, p. 121, 2006.