UNIVERSIDADE FEDERAL DO TOCANTINS

Programa de Pós-Graduação em Modelagem Computacional de Sistemas

Mestrado Profissional Interdisciplinar em Modelagem Computacional de Sistemas
Campus Universitário de Palmas

Elvis Nascimento da Silva

Uma Revisão da Literatura sobre arquiteturas de Registros

Eletrônicos de Saúde baseados em Arquétipos.

PALMAS– TO
2016
 UNIVERSIDADE FEDERAL DO TOCANTINS
Programa de Pós-Graduação em Modelagem Computacional de Sistemas
Mestrado Profissional Interdisciplinar em Modelagem Computacional de Sistemas
Campus Universitário de Palmas

Elvis Nascimento da Silva

Uma Revisão da Literatura sobre arquiteturas de Registros

Eletrônicos de Saúde baseados em Arquétipos.

Dissertação apresentada ao Programa de Pós-

Graduação em Modelagem Computacional de
Sistemas da Universidade Federal do
Tocantins, como pré-requisito parcial para a
obtenção do título de Mestre em Modelagem
Computacional de Sistemas.
Orientador: Prof. Dr. Leandro Guimarães
Garcia.
Coorientador: Prof. Dr. Sergio Miranda Freire.

PALMAS- TO
2016
 Elvis Nascimento da Silva

Uma Revisão da Literatura sobre arquiteturas de Registros

Eletrônicos de Saúde baseados em Arquétipos.

Dissertação apresentada ao Programa de Pós-

Graduação em Modelagem Computacional de
Sistemas da Universidade Federal do
Tocantins, como pré-requisito parcial para a
obtenção do título de Mestre em Modelagem
Computacional de Sistemas.
1º Orientador: Prof. Dr. Leandro Guimarães
Garcia.
2º Orientador: Prof. Dr. Sergio Miranda Freire.

BANCA EXAMINADORA:

____________________________________________
Prof. Dr. Leandro Garcia Guimarães
PPG MCS – UFT
1º Orientador

____________________________________________
Prof. Dr. Patrick Letouzé
PPG MCS – UFT
Membro Interno

____________________________________________
Prof. Dr. Michel Santos Silva
IFTO
Membro Externo

____________________________________________
Prof. Dr. Sérgio Miranda Freire
UERJ
2º Orientador
AGRADECIMENTOS

Agradeço primeiramente a Deus, por me dar forças e guiar minha vida.

A minha querida esposa e filhos que incondicionalmente sempre me apoiaram na

condução deste trabalho.

Ao primeiro orientador, Professor Leandro Guimaraes Garcia, pela dedicação, por sua
competência e profissionalismo na condução das revisões e sugestões;

Ao segundo coorientador Sérgio Miranda Freire, que embora distante, se dispôs com
seus conhecimentos para o desenvolvimento deste trabalho.

Agradeço a todos os professores do PPGMCS, por compartilharem seus

conhecimentos, em especial aos professores David Nadler Prata, Patrick Letouze, pela
dedicação ao programa.

Agradeço a todos os colegas do mestrado, em especial aos já amigos Charles

Jeffersosn Rodrigues Alves e Alves, Janio Carlos Nascimento Silva e Rafael Miranda
Correia, pelas parcerias, incentivos e principalmente pela amizade.

Aos colegas de trabalho do IFTO, pela compreensão e apoio.

Agradeço ao professor e amigo Harry Richard Hamming Neto, pelo ser humano que é
e por suas palavras motivacionais.

E a todos que direta ou indiretamente participaram dessa trajetória.

“A persistência é o menor caminho do êxito”. (Charles Chaplin)
 RESUMO

Este trabalho apresenta uma revisão da literatura com o objetivo de realizar

um levantamento das arquiteturas de Registros Eletrônicos de Saúde (RES)
baseados em Arquétipos. RES é um repositório de informações relativo ao estado de
saúde de um ou mais indivíduos, armazenado em forma processável pelo
computador, transmitida com segurança e acessível por múltiplos usuários
autorizados. Arquétipos são fragmentos que fornecem uma modelagem semântica
de objetos. Podem ser usados para padronizar as estruturas da informação clínica e
fornecem uma porta de entrada comum para o intercâmbio de dados. A norma ISO
13606 e o conjunto de especificações openEHR, atualmente ganham destaque na
busca da interoperabilidade da informação clínica entre sistemas RES. Esta revisão
utilizou critérios de inclusão e exclusão que levaram à inserção de 21 artigos sobre o
tema, no período entre Jan/2007 a Mar/2016. As seguintes fontes foram utilizadas:
(a) sítios da Fundação openEHR, da norma ISO 13606 e no repositório de artigos
sobre openEHR, organizados por Koray Atalag, utilizando o gerenciador de
referência Zotero; (b) as bases de dados Association for Computing Machinery (ACM)
Digital Library, Institute of Electrical and Electronics Engineers (IEEE) Xplore,
Elsevier, Emerald, ISI Web of Science, ScienceDirect e PubMed. Os resultados
mostraram uma maior difusão de estudos na Europa. Diversas arquiteturas de
sistemas de RES foram identificadas. Quanto aos mecanismos de persistência, os
bancos de dados relacionais têm sido utilizados de forma não convencional, seja por
mapeamento, por meio de frameworks ou middlewares, ou por algum suporte já
implementado no gerenciador de banco de dados para persistirem os dados de
maneira não relacional como, por exemplo, dados no formato XML. Os bancos de
dados NoSQL MongoDB e Couchbase, por naturalmente trabalharem de modo
distribuído, têm apresentado bons desempenhos, principalmente para consultas de
base populacionais, em grandes quantidades de dados clínicos.

Palavras-chave: Arquitetura, Registro Eletrônico em Saúde, Arquétipos, openEHR,

ISO 13606
 ABSTRACT

This paper presents a literature review in order to carry out a survey of

architectures of Electronic Health Records (RES) based on Archetypes. RES is a
repository of information regarding the health status of one or more individuals, stored
in a processable form by the computer, securelytransmitted, and accessible by
multiple authorized users. Archetypes are fragments that provide a semantic object
modeling. They can be used to standardize the structures of the clinical information
and provide a common gateway for data exchange. The ISO 13606 standard and the
set of openEHR specifications are currently on the spotlight in the search for
interoperability of clinical information among RES systems. This review used inclusion
and exclusion criteria that led to the inclusion of 21 articles on the topic, between
Jan/2007 to Mar/2016. The following sources were used: (a) sites of the openEHR
Foundation, the ISO 13606 standard and the repository of articles on openEHR,
organized by Koray Atalag using the Zotero reference manager; (B) databases of the
Association for Computing Machinery (ACM) Digital Library, Institute of Electrical and
Electronics Engineers (IEEE) Xplore, Elsevier, Emerald, ISI Web of Science,
ScienceDirect and PubMed. The results showed a greater difusion in Europe. Several
architectures of RES systems have been identified. As for the persistence
mechanisms, relational databases have been used unconventionally, either by
mapping through frameworks or middleware or through some support already
implemented in the database manager to persist data in no relational form, such as
in the XML format. The MongoDB and Couchbase NoSQL databases, which natively
work in distributed mode, have shown good performances, especially for population
based queries in large amounts of clinical data.

Keywords: Architecture, Electronic Health Record, Archetype, openEHR, ISO 13606.

 LISTA DE FIGURAS

Figura 1. Diferença entre EHR, EMR................................................................................................. 20

Figura 2. Modelo de sinais vitais (pulso). Na definição em dois hospitais diferentes. ............... 24
Figura 3. Modelagem de único nível de desenvolvimento. ............................................................ 28
Figura 4. Modelagem de dois níveis (RM e AM) .............................................................................. 29
Figura 5. Representação “Dual Model” por meio do jogo de peças de LEGO®......................... 30
Figura 6. Etapas de elaboração da revisão da literatura. ............................................................... 33
Figura 7. Diagrama de fluxo de seleção dos Estudos..................................................................... 37
Figura 8. Difusão openEHR/ISO 13606 nos continentes. .............................................................. 45
Figura 9. Quantidade de estudos no período de 2007 a 2016. ..................................................... 47
Figura 10. Quantitativo de citações por estudo de acordo com sua classificação. ..................... 59
Figura 11. Persistência de dados utilizando mapeamento ARM (a), ORM (b) e XML (c). ........ 64
Figura 12. Armazenamento distribuído em banco de dados NoSQL mongoDB. ....................... 67
 LISTA DE TABELAS

Tabela 1: Bases de dados para a realização das buscas. ...................................................... 34

Tabela 2. Critérios de classificação dos trabalhos selecionados ............................................ 35
Tabela 3. Estudos excluídos de acordo com o critério adotado. ............................................ 36
Tabela 4. Quantitativo de estudos de acordo com a fonte pesquisada ................................... 36
Tabela 5. Informações das instituições que adotam openEHR em seus sistemas. ............... 38
Tabela 6. Fornecedoresdos quais foram solicitadas informações para este trabalho. ........... 40
Tabela 7. Campos da planilha para extração de informações dos artigos .............................. 42
Tabela 8. Estudos incluídos na revisão ................................................................................. 43
Tabela 9. Informações do produto Think!EHR Platform, da Marand. ...................................... 44
Tabela 10. Estudos incluídos localizados nas bases e sua seleção ....................................... 46
Tabela 11. Nomes dos produtos/projetos e local de desenvolvimento. .................................. 47
Tabela 12. Resumo dos estudos classificados como Sistemas RES .................................... 49
Tabela 13. Resumo dos estudos classificados como Sistemas de Integração/Plataforma. .... 52
Tabela 14. Resumo dos estudos classificados como Repositórios........................................ 55
Tabela 15. Variáveis qualitativas contidas nos projetos/produtos de estudo .......................... 60
 LISTA DE ABREVIATURA E SIGLAS

ACID Atomic, Consistent, Isolation and Durable

AM Archetype Model
AQL Archetype Query Language
ARM Archetype Relational Mapping
BASE Basically Available, Soft state, Eventually consistency)
CKM Clinical Knowledge Manager
EHR Electronic Health Record
EMR Electronic Medical Record
HIMSS Health Information and Management System Society
HL7 Health Level 7
ISO International Organization for Standardization
JSON JavaScript Object Notation
MVC Model-view-controller
NAHIT National Alliance for Health Information Technology)
NoSQL Not Only SQL
OO Orientação a Objetos
ORM Object Relational Mapping
PHR Personal Health Record
RES Registro Eletrônico de Saúde
RM Reference Model
SGBD Sistemas de Gerenciamento de Banco de Dados
SOAP Simple Object Access Protocol)
SQL Structured Query Language
SUS Sistema Único de Saúde
TI Tecnologia da Informação
WS Web Service
XML eXtensible Markup Language
 SUMÁRIO

CAPÍTULO I ........................................................................................................................... 13
1. Introdução ....................................................................................................................... 13
1.1 Justificativa .............................................................................................................. 16
1.2 Objetivo Geral .......................................................................................................... 18
1.2.1 Objetivos Específicos ........................................................................................ 18
1.3 Organização da Dissertação .................................................................................... 18
CAPÍTULO II .......................................................................................................................... 19
2. Referencial Teórico ......................................................................................................... 19
2.1 Registro Eletrônico de Saúde (RES) ........................................................................ 19
2.2 EHR x EMR ............................................................................................................. 20
2.3 Integração e Interoperabilidade em sistemas. .......................................................... 21
2.3.1 Integração vs. interoperabilidade ...................................................................... 22
2.3.2 Interoperabilidade Sintática e Semântica .......................................................... 22
2.4 Persistência de Dados ............................................................................................. 24
2.4.1 ACID x BASE .................................................................................................... 25
2.5 A Fundação openEHR ............................................................................................. 26
2.6 A norma ISO 13606 ................................................................................................. 27
2.7 Abordagem “Dual Model” ......................................................................................... 27
2.7.1 Arquétipos......................................................................................................... 30
CAPÍTULO III ......................................................................................................................... 33
3. Metodologia .................................................................................................................... 33
3.1 Elaboração do Projeto de Pesquisa ......................................................................... 33
3.2 Seleção e Avaliação Crítica dos Estudos Encontrados ............................................ 34
3.3 Coleta de Dados ...................................................................................................... 41
3.4 Agrupamento e apresentação dos dados ................................................................. 42
CAPÍTULO IV......................................................................................................................... 43
4. Resultados ...................................................................................................................... 43
4.1 Estudos incluídos na Revisão .................................................................................. 43
4.2 Difusão das especificações openEHR/ISO 13606 nos continentes .......................... 44
4.3 Frequência das publicações por ano e por base pesquisada ................................... 45
4.4 Projetos/Produtos apresentados nos estudos .......................................................... 47
4.5 Classificação dos estudos incluídos ......................................................................... 48
4.6 Taxa de citação........................................................................................................ 59
4.7 Tecnologias utilizadas nas arquiteturas ................................................................... 59
4.7.1 Comparação de arquiteturas de armazenamento ............................................. 62
CAPÍTULO V.......................................................................................................................... 69
5. Discussão ....................................................................................................................... 69
5.1 Metodologia de busca .............................................................................................. 69
5.2 Estágio das implementações openEHR ................................................................... 69
5.3 Arquiteturas dos Sistemas ....................................................................................... 70
5.4 Persistência de Dados ............................................................................................. 71
CAPÍTULO VI......................................................................................................................... 74
6. Conclusão ....................................................................................................................... 74
Referências ............................................................................................................................ 75
 13

CAPÍTULO I
1. Introdução

Um Sistema de Informação em Saúde(SIS) capaz de gerenciar as informações

necessárias durante as diferentes etapas do processo de atendimento do paciente, pode
ser crucial para os profissionais de saúde no processo de tomada de decisões, pois esses
sistemas facilitam a comunicação e subsidiam a administração pública com informações
valiosas(HIQA, 2013). Para a eficiência dos cuidados de saúde, os sistemas precisam ser
desenvolvidos com o objetivo de favorecer a comunicação e transmissão de informações
clínicas entre sistemas diferentes (ALMEIDA, 2013; KALRA, DIPAK, 2006).O novo
paradigma de saúde eletrônica, e-Health 1, exige que sistemas e dispositivos de saúde
permitam a integração transparente e interoperabilidade de seus dados(MARTÍNEZ-
COSTA et al., 2009).

Um dos sistemas de informação mais importantes são os sistemas de Registro

Eletrônico de Saúde (RES), do Inglês Eletronic Health Record – EHR. Um RES é um
repositório de informações sobre o estado de saúde e assistência à saúde de um indivíduo,
mantido eletronicamente, de modo que ele possa servir aos múltiplos e legítimos usos e
usuários do registro (MCDONALD; TANG, P. C.; HRIPCSAK, 2014). Essas informações
são categorizadas em várias seções, incluindo o contato do paciente, resumo das visitas
ao médico, o diagnóstico do paciente, histórico médico e familiar, lista de prescrições,
exames de saúde, tratamento, etc. (AMATO et al., 2012).

Iniciativas vêm sendo discutidas envolvendo organismos de normatização, que

definem uma arquitetura genérica de um RES para a comunicação de dados de saúde,
tais como o CEN/ISO EN13606 2, openEHR3 e HL7 CDA 4. Essas organizações propõem
padrões e especificações que possibilitem que as informações clínicas sejam
interoperáveis entre os diversos RES de diferentes instituições ou em uma mesma
instituição. A interoperabilidade visa facilitar as interações, permitindo a troca de
informações e reutilização, entre sistemas de informação não homogêneos.

1
e-Saúde é qualquer aplicação de Internet focada na melhoraria do acesso, da eficiência, da
efetividade e da qualidade dos processos clínicos e assistenciais necessários a toda a cadeia de
prestação de serviços de saúde. HIMSS Analytics. Dispobível em: http://www.himss.org/.
2
www.en13606.org
3
www.openehr.org
4
www.hl7.com.br
 14

A interoperabilidade, de acordo com a norma ISO/TR 16056 5, é a habilidade de

dois ou mais sistemas interagirem um com o outro, trocando informações de acordo com
um método prescrito. Para sistemas baseados em RES, existem dois tipos de
interoperabilidade básicos: sintática (funcional) e semântica. A sintática é quando dois ou
mais sistemas estão interligados sintaticamente para troca dados. Para tal, é essencial a
especificação de protocolos de comunicação que descrevam como esta troca deva
ocorrer(POKRAEV, 2009). A interoperabilidade semântica é a capacidade de dois ou mais
sistemas heterogêneos trabalharem em conjunto, compartilhando as informações entre
eles com entendimento comum de seu significado, independentemente da intervenção
humana (MARUT, 2001).

A ISO (International Organization for Standardization) e a fundação openEHR

apresentam uma abordagem comum para a comunicação e interoperabilidade semântica
de RES que é baseada em uma arquitetura chamada “Dual Model”(ISO 13606, 2015;
KALRA, Dipak; BEALE, Thomas; HEARD, Sam, 2005). Para compreender essa
metodologia, é necessário visualizar o usual “modelo único”. MUNOZ (2007) afirma que,
tradicionalmente, o desenvolvimento de sistemas de informação em saúde é realizado
utilizando metodologias de um único nível de modelagem, em que os conceitos de domínio
são codificados diretamente para o software e seus modelos de banco de dados. Esse
tipo de relação permite relativamente um rápido desenvolvimento, porém, quando é
aplicada em ambientes com alto grau de complexidade, no caso de dados clínicos de
pacientes, esses sistemas de informações necessitam de atualizações frequentes.

A arquitetura chamada “Dual Model” (Modelagem de dois níveis), procura

solucionar essa situação, com a utilização de dois modelos relacionados: um Modelo de
Referência (RM) e um Modelo de Objetos de Arquétipos (AM).

O primeiro é um modelo genérico definido para a representação de dados e possui

um número relativamente pequeno de classes genéricas fixas (BEALE, T et al.,
2008). Esse modelo representa as estruturas genéricas de componentes de informação
do registro de saúde. A base de dados da aplicação é construída a partir do RM
(SACHDEVA; BHALLA, 2009). O segundo, os Arquétipos (AM), são uma camada de

5
ISO/TR 16056-1: 2004-- Interoperability of telehealth systems and networks Part 1:
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37351
 15

abstração entre o armazenamento e recuperação de informações em um RES

específico(BARCA et al., 2014). Os arquétipos são usados para restringir as estruturas
válidas de instâncias das classes genéricas do RM e fornecem uma modelagem semântica
(independente da aplicação) (SACHDEVA; BHALLA, 2009). A principal finalidade do
Arquétipo é fornecer uma maneira poderosa, reutilizável e interoperável, para a criação,
validação e consulta do RES(MALDONADO et al., 2007). Nesse contexto, os arquétipos
desempenham um papel importante na implementação da interoperabilidade entre RES.

A modelagem de dois níveis permite que os sistemas se tornem mais sustentáveis,

com um RM estável e os arquétipos dinâmicos. Com essa separação de modelos e
independência de aplicações, a capacidade de adaptação dos sistemas aumenta
significativamente(MARCOS et al., 2011).

No cenário mundial, há projetos em andamento de RES baseados em arquétipos

(ISO 13606 ou openEHR), como na Espanha [03, 06, 09, 11], Portugal [04, 14], China
[15], Argentina [12] e Uruguai [13]. No Brasil já se cogita a utilização desses sistemas no
Sistema Único de Saúde (SUS) 6 com maior ênfase no Estado de Minas Gerais. De acordo
com (SANTOS, 2011), na Secretaria de Estado de Saúde de Minas Gerais (SES/MG)
pretende criar um sistema de RES, em nível estadual, para consolidar dados
demográficos e o sumário clínico para os pacientes, em apoio ao programa Saúde
Família, na atenção primária. O autor desenvolveu uma proposta (tese) de arquitetura de
sistema de RES compartilhável para a atenção primária do Estado de Minas Gerais,
baseada nos modelos de referência e arquétipos da norma ISO13606. Até a presente
data, não há informações da implementação da proposta.

Neste estudo, o RES (EHR) se refere a um repositório de informações sobre o

estado de saúde de um indivíduo, numa forma eletronicamente processável(ISO/TR
20514, 2005).

Portanto, a presente pesquisa buscou identificar e analisar as arquiteturas de RES

baseados em arquétipos da metodologia “Dual Model”, seja da Fundação OpenEHR ou
da norma ISO 13606.

6
http://portalsaude.saude.gov.br/
 16

1.1 Justificativa

O estabelecimento de interoperabilidade semântica entre sistemas de informação

em saúde é provavelmente um dos desafios mais importantes da informática em saúde
hoje (KUHN; OTHERS, 2007). No cenário mundial, há discussões na adoção de padrões
ou especificações (HL7, ISO 13606 ou OpenEHR) para melhor implementarem seus
sistemas de saúde.

Os sistemas de informações em saúde, especificamente os Sistemas de Registro

Eletrônico em Saúde (SRES) devem apresentar flexibilidade na representação do
conhecimento específico na medicina, para suportar a complexidade do domínio e sua
constante evolução. Além disso, a conectividade é um importante pré-requisito, no
entanto, a diversidade de modelos e componentes constitui uma barreira para
comunicação com outros sistemas. Diante de uma falta de padronização, significativas
contribuições foram realizadas através da produção de especificações como o openEHR
(openEHR, 2012).

Diante da necessidade de alinhar as iniciativas de registro eletrônico, e devido aos

desafios da transferência da informação clínica do paciente entre sistemas heterogêneos,
de modo a manter o seu significado original, o Governo Brasileiro, por meio do Ministério
da Saúde, publicou a Portaria nº 2.073/2011 7, que regulamenta o uso de padrões de
interoperabilidade e informação em saúde para sistemas de informação em saúde no
âmbito do SUS, nos níveis Municipal, Distrital, Estadual e Federal, e para os sistemas
privados e do setor de saúde suplementar. Na portaria, alguns padrões e especificações
de informação relacionados aos sistemas estão definidos em categorias, sendo o modelo
de referência e modelos de domínio sob a forma de arquétipos e templates 8determinados
de acordo com a openEHR, para a implementação do RES. No entanto, a arquitetura
(armazenamento e processamento), a infraestrutura, e as ferramentas tecnológicas
utilizadas no desenvolvimento dos sistemas, ficam a cargo dos desenvolvedores.

7
Ministério da Saúde. Portaria nº 2.073/2011. Disponível em:
http://bvsms.saude.gov.br/bvs/saudelegis/gm/2011/prt2073_31_08_2011.html
8
São estruturas compostas de um ou mais arquétipos onde são acrescentadas restrições
necessárias ao uso destes arquétipos em um cenário particular. Disponível em:
http://www.openehr.org/pt/programs/clinicalmodels/
 17

Para o armazenamento da informação clínica, uma atenção especial é necessária

na escolha do projeto de arquitetura de armazenamento ou como os dados são
persistidos, devido às características que cada sistema possui. Atualmente, esse
armazenamento depende muito dos Sistemas de Gerenciamento de Banco de Dados
Relacionais (SGBDR), pois esse modelo de dados adota uma estrutura de
armazenamento estático, em que são apresentados conceitos de esquemas e relações
entre tabelas (LEE; TANG, W.-C.; CHOI, 2013). No entanto, há algumas preocupações no
uso desse modelo como: (a) Há casos em que suas performances não são adequadas
para as necessidades específicas, como suporte de decisão (STONEBRAKER et al.,
2007); (b) Há deficiência no fornecimento de escalabilidade (STONEBRAKER; CATTELL,
2011); (c) Possui rigidez para dados semiestruturados, como os dados clínicos de um
paciente.(MELLO et al., 2000). Para lidar com essas questões, são utilizadas alternativas
que podem lidar com características específicas de dados clínicos com mais eficácia: os
bancos de dados conhecidos como NoSQL (No only SQL)(LEE; TANG, W.-C.; CHOI,
2013).

Quanto à arquitetura e avaliação do funcionamento de um RES, poucos são os

estudos que abordam essa temática, porém existe um considerável número de estudos
envolvidos com a questão da interoperabilidade dos dados em saúde (PÖHLSEN et al.,
2009; SALAMANCA et al., 2008). Especificamente, na abordagem “Dual Model”, com a
utilização de arquétipos, embora seja eficaz para a aquisição de interoperabilidade
semântica entre sistemas de saúde e permite a evolução do sistema sem precisar alterar
o modelo de dados(DIAS; COOK; FREIRE,2011), não há um conjunto de boas práticas
estabelecidas para a implementação de sistemas baseados nestas especificações.

A partir dessa conjuntura, o presente trabalho objetiva verificar o estado da arte das
arquiteturas dos sistemas eletrônicos de saúde baseados em arquétipos da metodologia
“Dual Model”. Por meio desse estudo, será possível realizar um mapeamento das
implementações no cenário mundial, bem como, apresentar as diversas tecnologias
usadas pelos desenvolvedores.
 18

1.2 Objetivo Geral

Investigar as diferentes iniciativas ao redor do mundo, a partir das evidências

encontradas na literatura nos últimos anos, das arquiteturas dos RES baseados em
arquétipos.

1.2.1 Objetivos Específicos

• Mapear as iniciativas de implementação no cenário mundial;

• Identificar os mecanismos de persistência de dados apresentados nas
implementações;
• Comparar as arquiteturas apresentadas na implementação de um RES baseado
em arquétipos.

1.3 Organização da Dissertação

Esta dissertação encontra-se dividida em 6 capítulos, organizados da seguinte

forma:

Capítulo I – Introdução: apresenta uma visão geral do tema, justificativa e

objetivos da revisão da literatura.

Capítulo II – Referencial Teórico: Apresenta os conceitos relacionados ao objeto

de estudo;

Capítulo III – Metodologia: apresenta o planejamento da pesquisa, como a

especificação da pergunta, a definição dos termos de busca nas bases de dados, a
avaliação e seleção dos estudos, os critérios de inclusão e exclusão, a coleta de dados
e o agrupamento dos dados.

Capítulo IV – Resultados: apresenta os resultados da pesquisa, com análises dos

estudos incluídos a partir dessa revisão da literatura, e a evolução das publicações por
ano e fonte de dados.

Capítulo V – Discussão: Discute sobre os resultados obtidos;

Capítulo VI – Conclusão: Apresenta as conclusões do estudo.

 19

CAPÍTULO II
2. Referencial Teórico

Neste capítulo são abordados os principais conceitos que serviram de base para o
desenvolvimento da pesquisa.

2.1 Registro Eletrônico de Saúde (RES)

Existem diversas definições para o RES. Mcdonald; Tang, e Hripcsak (2014) o

definem como um repositório de informações sobre o estado de saúde e assistência à
saúde de um indivíduo, mantido eletronicamente, de modo que ele possa servir aos
múltiplos e legítimos usos e usuários do registro.

A ISO 20514(ISO/TR 20514, 2005), oferece uma definição de RES para a

Assistência Integral (RES-AI):

“ Repositório de informação relativo ao estado de saúde de um ou mais

indivíduos, em forma processável pelo computador, armazenada e
transmitida com segurança e acessível por múltiplos usuários autorizados,
tendo um modelo lógico de informação padronizado ou acordado que seja
independente dos sistemas de RES e cuja principal finalidade é apoiar a
continuidade, eficiência e a qualidade da assistência integral à saúde. ”

A ISO considera esta como a principal definição de um Registro Eletrônico de

Saúde, reconhecendo, porém, que atualmente ainda há muitas variantes do RES nos
sistemas de informação em saúde que não estão em conformidade com a definição
principal do RES. A ISO 20514 também adota a seguinte definição para o RES básico-
genérico: “Um repositório das informações a respeito do estado de saúde de um ou mais
indivíduos numa forma processável pelo computador”. Para o Sistema de Registro
Eletrônico de Saúde (SRES) a norma define como “um sistema para registro, recuperação
e manipulação de um Registro Eletrônico de Saúde”.Os S-RES possui definição mais
ampla e abrangente, pois engloba outros subsistemas e componentes (Sistema
Operacional, Sistemas de Gerenciamento de Banco de Dados (SGBD’s, servidores,
bibliotecas, etc.).No Brasil, o RES e S-RES são definidos de acordo com a norma ABNT
ISO/TR 20514 9.

9
ABNT ISO/TR 20.514:2005 – Informática em saúde - Registro eletrônico de saúde - Definição, escopo e
contexto. Disponível em: http://www.abntnet.com.br/fidetail.aspx?FonteID=41192
 20

2.2 EHR x EMR

EMR (Eletronic Medical Record) ou Prontuário Eletrônico do Paciente (PEP) é

composto pelo registro de informação de saúde de um paciente, gerado a partir de eventos
ocorridos no processo assistencial em uma única organização de saúde, que pode ou não
alimentar um sistema de RES(GARETS; DAVIS, 2006). O RES é também composto pelo
registro de informação de saúde de um paciente. Porém, esse registro é elaborado a partir
de eventos ocorridos em múltiplas organizações de saúde. É composto de um ou vários
repositórios de dados clínicos e demográficos de pacientes. Seus dados são coletados
prioritariamente por meio de sistemas de PEP de organizações prestadoras de serviço em
saúde(SANTOS, 2011).

Um outro conceito de RES se refere a um repositório que integra as informações

dos pacientes provenientes de vários EMR diferentes e espalhados em diversos
provedores de saúde em uma dada região geográfica (GARETS; DAVIS, 2006). Essa
relação entre RES e PEP é mostrada na Figura 1, demonstrando que os dados do EHR
podem ser obtidos a partir dos sistemas EMR de diferentes instituições. Estes dados
posteriormente são compartilhados com outras instituições, retornando informações e
atualizações no EHR.

Figura 1. Diferença entre EHR, EMR

Fonte: https://doctors.practo.com/emr-vs-ehr-whats-difference/. Adaptado.
 21

Partindo dessas definições, compreende-se que o RES é um componente central

na construção de um sistema integrado de saúde, que constitui um repositório para
pesquisa e melhoria nas condições de tratamento de pacientes(SANTOS, 2011). No
entanto, muitos s ã o os desafios e mudanças culturais enfrentados no desenvolvimento
de um sistema de RES(KALRA, DIPAK, 2003). Na visão técnica, o desafio da
interoperabilidade e a natureza complexa e dinâmica das informações em saúde, que
dificultam a evolução dos sistemas, fazem seu desenvolvimento ser mais árduo do que o
de outros sistemas de informação (NARDON, 2000).

É nesse cenário desafiador, que sistemas RES devem evoluir de maneira mais fácil
e interoperar com outros sistemas, tratando a informação estruturada e não estruturada,
em diferentes formatos e volumes.

2.3 Integração e Interoperabilidade em sistemas.

A integração é o processo de assegurar a interação entre entidades necessárias

para atingir os objetivos de um domínio (“ISO 19439”). A integração pode ser abordada de
várias maneiras e em vários níveis (VERNADAT, 1996), por exemplo: (i) a integração física
(interligação de aparelhos, máquinas); (ii) a integração de aplicações (integração de
aplicações de software e sistemas de banco de dados) e (iii) integração de negócios
(coordenação de funções como gerir, controlar e monitorar processos de negócio).

Na interoperabilidade, a palavra ''inter-operar'' implica que um sistema realiza uma

operação para outro sistema. Do ponto de vista da TI, é a faculdade de dois sistemas
heterogêneos funcionarem em conjunto e de compartilharem recursos de uma forma
recíproca (CHEN; VERNADAT, 2004). Das condições para que ocorra interoperabilidade
entre sistemas de informação em saúde incluem especialmente o modelo de informação,
utilização de terminologias e ontologias específicas de um domínio, entre outras
características.

Segundo o HIMSS 10, a integração é o arranjo dos sistemas de informação, de modo

que esses possam se comunicar eficientemente, reunindo as partes relacionadas e
formando um único sistema composto por sistemas menores. Já a interoperabilidade é a
capacidade dos sistemas de informação de trabalharem juntos, dentro e fora das fronteiras

10
HIMSS. Electronic Health Record. 2010. Disponível em
http://www.himss.org/ASP/topics_ehr.asp
 22

organizacionais, a fim de atingir um determinado objetivo. Nesse sentido, a integração

pode ser obtida se os sistemas incorporarem, em suas interfaces de programas, uma
forma única de trabalho, almejando um objetivo comum, de maneira unificada e
padronizada. Ou seja, esse nível de integração exige,em geral, a adaptação dos programas
(ou módulos) que constituem os sistemas. Por outro lado, a interoperabilidade implica que
diferentes sistemas de informação associem seus recursos em prol de um objetivo comum,
sem, no entanto, alterarem em nada sua autonomia e características próprias(SANTOS,
2011).

2.3.1 Integração vs. interoperabilidade

Integração é geralmente considerada para além da interoperabilidade, pois envolve

algum grau de dependência funcional (PANETTO; MOLINA, 2008). Enquanto os sistemas
interoperáveis podem funcionar de forma independente, um sistema integrado perde a
funcionalidade significativa se o fluxo de serviços é interrompido. Dois sistemas integrados
são inevitavelmente interoperáveis, mas dois sistemas interoperáveis não são
necessariamente integrados (CHEN; DOUMEINGTS, 2003).

2.3.2 Interoperabilidade Sintática e Semântica

A definição de interoperabilidade adotada nesta revisão é dada pela norma ISO/TR

16056 11, que diz:

[...] a habilidade de dois ou mais sistemas (computadores, dispositivos de

comunicação, redes, software e outros componentes de tecnologias de
informação) interagir um com outro,trocando informações de acordo com um
método prescrito[...].

A interoperabilidade pode ser classificada em diferentes níveis: sistema, sintaxe,

estrutura e semântica (OUKSEL; SHETH, 1999). Existem ainda outros níveis de
interoperabilidade discutidos na literatura(MILLER, 2000; RODRIGUES et al.)que não
serão apresentados. Nesta revisão,os níveis de interoperabilidade a serem considerados
serão a interoperabilidade sintática e semântica.

Para enfatizar esses dois mecanismos de interação de dados clínicos, a

interoperabilidade sintática (ou funcional), de acordo com IDA (2004),está relacionada com

11
ISO/TR 16056-1: 2004: Health informatics -- Interoperability of telehealth systems and networks -
Part 1:. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37351
 23

as questões técnicas para que sistemas de computadores trabalhem em conjunto,

incluindo as interfaces técnicas, redes, middleware, acessibilidade e segurança. A norma
ISO18308(ISO 18308, 2011) a define como:

[...] a capacidade de dois ou mais sistemas de comunicarem e

intercambiarem dados através de formatos de dados e protocolos de
comunicação[...]

Na interoperabilidade semântica, os sistemas compartilham um vocabulário comum

e há uma preocupação com o significado dos dados ou da informação que se deseja
transmitir ou utilizar(BRASIL, 2015). Na transmissão, a informação deve ser compreensível
mesmo para sistemas que possuem diferentes arquiteturas.

Um exemplo de interoperabilidade é apresentado por (GØEG; CORNET;

ANDERSEN, 2015) que mostra informações de dois hospitais: o Hospital A apresenta os
sinais vitais de um paciente, que poderiam conter pulso, pressão arterial, temperatura,
saturação de oxigênio e frequência da respiração, sendo cada um deles representado em
um único campo de texto (em um banco de dados) onde poderiam ser escritos também
os comentários. O Hospital B apresenta um modelo onde quantidades, comentários e
campos relacionados com o protocolo são mantidos separadamente, como ilustrado na
Figura 2.

Em uma simples comparação, tem-se uma ideia sobre o que é interoperabilidade

semântica no modelo de sinais vitais. Na representação da informação no hospital A,
caso fosse necessário realizar uma análise das informações sobre os sinais vitais de
algum paciente, haveria a necessidade de intervenção humana manual, o que tornaria a
tarefa desgastante, dado o grande volume de dados a serem analisados e o desafio de
sintetizar esses dados. No hospital B é apresentada uma melhor organização da
informação clínica, com campos separados para os vários dados obtidos
simultaneamente acerca de um mesmo sinal vital. Neste exemplo existe
interoperabilidade sintática entre os dois hospitais (são recolhidos os dados dos mesmos
sinais vitais), mas não existe interoperabilidade semântica (o mesmo sinal vital é
representado de forma diferente quando se comparam os hospitais A e B).

Contudo, percebe-se que mesmo havendo interoperabilidade sintática, não se pode

realizar adequadamente a troca de dados clínicos sem a interoperabilidade semântica.
 24

Figura 2. Modelo de sinais vitais (pulso). Na definição em dois hospitais diferentes.

Fonte: (GØEG; CORNET; ANDERSEN, 2015). Adaptado.

Na abordagem “Dual Model”, a proposta é a utilização de especificações que

possibilitem que as informações sejam interoperáveis entre RES de diferentes instituições.
Para que ocorra a partilha de dados entre os sistemas RES, é necessário que haja
interoperabilidade, que só é conseguida quando as partes envolvidas estabelecem um
compromisso com um modelo de informação comum (MALDONADO; LOPEZ; BLOBEL,
2009).

2.4 Persistência de Dados

Segundo Júnior (2006), a propriedade de um dado manter sua integridade ao longo

do tempo é chama de persistência. Dentro do contexto de desenvolvimento de sistemas,
a persistência de dados é uma forma de manter as informações das aplicações em um
meio do qual possam ser recuperados posteriormente.

Bauer (2005) afirma que a persistência nada mais é do que armazenar dados em
um banco de dados relacional. Um modelo gerencial de persistência atua em camadas,
podendo ser feito por intermédio de instruções SQL 12 (Structured Query Language). O uso
da persistência deixa transparentes as operações básicas de inserção, recuperação,
atualização e remoção de dados. Nesse caso, o autor aborda somente uma categoria de
banco de dados. No entanto, existem outras categorias que atuam na persistência de
forma diferente, como os que utilizam o paradigma de Orientação a Objetos (OO) e os que
pertencem a categoria denominada NoSQL.

12
DASAR, Pemakaian. SQL (Structured Query Language). 2007.
 25

O uso dos bancos de dados relacionais, trazem alguns inconvenientes aos

programadores de linguagens OO (ROCHA; KUBOTA). Para usar os recursos de bancos
de dados relacionais e aproveitar os conceitos do paradigma OO, é necessário fazer o
mapeamento objeto-relacional (mapeamento O/R). Nesse mapeamento, as classes e os
atributos do sistema são mapeados para tabelas e campos/colunas e a persistência é feita
de forma transparente pela aplicação. Para suprir essas necessidades, surgiram diversos
frameworks e tecnologias de persistência, a exemplo do Hibernate 13 e do iBatis 14. Essas
ferramentas facilitam o trabalho do desenvolvedor e aumentam sua produtividade,
fornecendo poderosas API’s de manipulação de dados.

Ercan e Lane (2014) afirmam que a literatura recente mostra a emergente categoria
de bancos de dados NoSQL, a qual apresenta vantagens significativas, tais como
escalabilidade, melhor desempenho e alta disponibilidade e revisa as principais
características de bancos de dados NoSQL em RES. O estudo também aborda as
limitações dos bancos de dados relacionais nos sistemas de saúde distribuídos. Para Han
et al. (2011), os Bancos de dados NoSQL, vêm de uma família heterogênea de produtos,
incluindo bancos de dados XML, que pretendem lidar de uma forma mais natural com
dados não estruturados ou semiestruturados do que os bancos de dados relacionais.

2.4.1 ACID x BASE

Como já dito, os bancos de dados relacionais adotam uma estrutura de

armazenamento estático. Os dados são armazenados de forma organizada com base na
interrelação de dados em que problemas de redundância e de consistência podem ser
eliminados pela normalização dos dados (ABITEBOUL; HULL; VIANU, 1995). Essa
categoria adota um conjunto de funcionalidades fundamentais que garantem as
propriedades ACID (Atomicity, Consistency, Isolation, Durability), (atomicidade,
preservação, consistência, isolamento, durabilidade) em que as propriedades devem ser
rigorosamente aplicadas(HAERDER; REUTER, 1983).

Os sistemas NoSQL não fornecem as propriedades ACID, as atualizações,

eventualmente, são propagadas, mas existem limitações quanto à consistência de
dados. Por outro lado, pode-se conseguir muito mais alto desempenho e escalabilidade.

13
Hibernate. Everything data. - Hibernate. Disponível em: hibernate.org/
14
iBATIS Home. Disponível em: ibatis.apache.org/
 26

Os bancos de dados NoSQL utilizam o conceito BASE (Basically Available, Soft state,
Eventual consistency), que considera um cenário que provê transações distribuídas,
tolerância a falhas, e replicação otimista em um sistema distribuído, mas este modelo não
possui compromisso com a consistência dos dados (TOTH, 2011). A partir do conceito
BASE, foram criados diferentes tipos de bancos de dados não relacionais. Por conta
dessas características e de outras, De Diana; Gerosa (2010) afirmam que o mecanismo
NoSQL veio como “uma solução para a questão da escalabilidade no armazenamento e
processamento de grandes volumes de dados na Web 2.0”.

2.5 A Fundação openEHR

A Fundação openEHR (BEALE, Thomas et al., 2006) é uma organização sem fins
lucrativos que aborda a interoperabilidade e computabilidade em sistemas de informações
em saúde, que lida com a gestão, armazenamento, recuperação e troca de dados em um
RES. O openEHR consiste de um conjunto de especificações que fornecem tanto
interoperabilidade sintática quanto interoperabilidade semântica e permite a evolução dos
sistemas sem necessidade de reformular seus modelos de dados.

Bird, Goodchild (2003) destacam que o openEHR mantém uma arquitetura de RES
concebida para apoiar a construção de ambientes distribuídos de um registro eletrônico,
e utiliza uma abordagem conhecida como metodologia de dois níveis, que é baseado em
uma separação clara entre informação e conhecimento. O primeiro é descrito por meio de
um modelo de referência (RM). O segundo é baseado no conceito de arquétipos (AM),
objetos que definem a semântica dos sistemas, e que permitem que o software realize
consultas de dados por meio do uso de uma linguagem própria baseado no RM, a AQL 15.

Esse novo paradigma inova o universo de implementações de um RES, pois atua

na padronização das estruturas básicas dos dados de saúde. Sua metodologia é projetada
para envolver tanto a comunidade médica quanto os especialistas em desenvolvimento
de software.

15
Archetype Query Language. Disponível: www.openehr.org/releases/QUERY/latest/AQL.html
 27

2.6 A norma ISO 13606

A norma ISO 13606 (ISO 13606, 2015) foi desenvolvida pelo Comitê Técnico
ISO/TC 215, Informática em Saúde, e concebida a partir de experiência prática obtida
durante a implementação do padrão precursor europeu, ENV 13606. Propõe um modelo
de referência simplificado e inspirado no modelo de referência proposto pela Fundação
openEHR. Assim como openEHR, o padrão ISO/EN 13606 EHR fornece um quadro para
a criação de RES interoperáveis, baseado na abordagem de dois níveis, que combina dois
tipos de modelos - o Modelo de Referência e arquétipos para representar conteúdo de um
RES (BIRD; GOODCHILD; TUN, 2003).

A norma é classificada em 5 partes: ISO 13606-1 - Reference Model; ISO 13606-2

- Archetype interchange specification; ISO 13606-3 - Reference archetypes and term lists;
ISO 13606-4 –Security; ISO 13606-5 – Interface specification. Somente as normas ISO
13606-1 e ISO 13606-2 são tratadas nesse estudo.

A norma EN 13606-1 (ISO 13606-1, 2008) especifica a comunicação, por meio de

um único indivíduo identificado, entre sistemas RES, ou entre sistemas RES e um
repositório de dados centralizado. Essa comunicação usa aplicativos ou middlewares para
acessarem os dados do RES. Uso do RES para outros fins, como ensino, auditoria clínica,
administração e relatórios, pesquisa e epidemiologia, não são o foco dessa norma. A ISO
13606-2 (ISO 13606-2, 2008) define um modelo de arquétipo a ser usado para representar
a comunicação entre os repositórios.

2.7 Abordagem “Dual Model”

A maioria dos sistemas de informação de hoje são construídos na abordagem de

nível único. Nessa abordagem, as entidades são modeladas diretamente em modelos de
software e banco de dados, por meio de um processo de escrever casos de uso, encontrar
classes e modelos que resultará em um software (BEALE, T, 2002). O autor ainda afirma
que esses sistemas não são muito estáveis, pois os conceitos de domínio são diretamente
codificados nos modelos utilizados para construir o software e bases de dados, com a
utilização de entidades como atributos, tabelas e colunas, ou seja, há uma dependência
das definições de entidades de conhecimento a partir do qual é construído o sistema. As
 28

mudanças na definição nas entidades exigem que o sistema seja alterado. A Figura 3
ilustra esse conceito.

Figura 3. Modelagem de único nível de desenvolvimento.

Fonte: (BEALE, Thomas, 2002).

No entanto, para situações onde as entidades, a complexidade e taxa de mudança

de definição é pequena, essa abordagem pode ser viável. Porém, em domínios grandes,
ricos em informação e sujeitos a constantes mudanças, como a área médica, a abordagem
de nível único pode ter consequências negativas, como afirma Beale (BEALE, T, 2002):

• A modelagem do sistema pode ser logisticamente difícil de administrar,

devido ao facto de dois tipos de pessoas estarem envolvidas: especialistas
de domínio e desenvolvedores de software. Especialistas do domínio são
forçados a expressar seus conceitos em UML 16, por exemplo, ou então
participar de discussões ad hoc com os desenvolvedores. Da mesma
forma, os desenvolvedores de software têm dificuldade em lidar com
inúmeros conceitos que eles não entendem. O típico resultado é um
processo de modelagem precário em que os conceitos de domínio são
muitas vezes perdidos ou expressos incorretamente, resultando em um
software que não faz o que os usuários querem;

16
UML (Unified Modeling Language) permite representar um sistema de forma padronizada, com
intuito de facilitar a compreensão pré-implementação. Disponível em: http://www.uml.org/what-
is-uml.htm
 29

• A introdução de novos conceitos requerem mudanças no software e no

banco de dados. Reconstrução, testes e reimplantação podem ser caros
e arriscados.

• A interoperabilidade é difícil de alcançar, uma vez que cada ambiente local

deva continuamente fazer seus modelos e softwares compatíveis com os
outros, ou então continuamente atualizar conversores de software ou
pontes. Ambientes heterogêneos em que o software foi criado usando
metodologia de um único nível de desenvolvimento, normalmente não
interagem bem, por causa da complexidade dos modelos subjacente de
cada sistema.

Para conseguir acompanhar a evolução do conhecimento em saúde sem realizar

alterações profundas nos sistemas de informações em saúde, o openEHR precisou
recorrer a uma nova estrutura de modelagem. A solução para este desafio foi a modelação
em dois níveis (BACELAR; CORREIA, 2015) (“Dual Model” ou Multinível). Nela ocorre a
separação do conteúdo da forma com que este é representado. Assim foram criados os
modelos de conteúdo clínico representado pelo Modelo de Arquétipo (AM) e o modelo de
informação representado pelo Modelo de Referência (RM). A Figura 4 mostra essas
representações.

Figura 4. Modelagem de dois níveis (RM e AM)

(BEALE, Thomas, 2002).
 30

Nessa abordagem, o usuário pode acessar a informação clínica por meio da

aplicação. Os especialistas do domínio são os responsáveis pela construção de arquétipos
(camada independente do software) e os profissionais de TI sãos os responsáveis pela
criação de ferramentas de integração dos dados entre os sistemas existentes em um
modelo de RES (SACHDEVA; BHALLA, 2010). Os arquétipos são usados para padronizar
as estruturas da informação clínica e oferecem uma porta comum de entrada para o
intercâmbio de dados, acordada entre sistemas envolvidos. Nesse sentido, o RM é mais
estável e menos sujeito a alterações que o arquétipo, essa separação habilita o
desenvolvimento de “sistemas à prova de futuro” (future-proof systems) (BEALE, T, 2002),
permitindo aos mecanismos de persistência serem pouco alterados e aos arquétipos
serem afetados pelas alterações de estrutura e regras de negócio (FREIRE; COPETTI;
LOQUES, 2008).

2.7.1 Arquétipos

Uma analogia que define o arquétipo na abordagem de dois níveis é apresentada

por BEALE et. al (2008), os componentes do RM são como especificações das peças do
jogo de LEGO®, como ilustrado na Figura 5. Os arquétipos são similares a estruturas
significativas construídas a partir das peças do LEGO. A aplicação openEHR é o ambiente
contendo essas várias formas, tendo essas a possibilidade de comunicar entre si.

Figura 5. Representação “Dual Model” por meio do jogo de peças de LEGO®.

Fonte: http://data.nczisk.sk/old/nczisk/ZI/stvrtok/3_SamHeardArchetypesTemplates.pdf (acessado
em mar. 30, 2016). Adaptado.

Nesse contexto de estrutura de arquétipo, eles podem ser trabalhados sob as

restrições (estrutura, tipos, valores e comportamentos) de um RM em cada domínio em
que se deseja usar (SACHDEVA; BHALLA, 2010) e que apresenta algumas características
funcionais como:
 31

• São flexíveis, reutilizáveis e combináveis;

• O significado dos dados clínicos é preservado em sistemas baseados em arquétipo;
• A normalização pode ser alcançada, de forma que, sempre que houver uma alteração
no conhecimento clínico, o software não precisa ser mudado e somente os arquétipos
precisam ser modificados.

A tarefa de desenvolver os arquétipos é tipicamente realizada por profissionais de

saúde. Para isso são usadas ferramentas específicas de modelagem, como por exemplo
o Archetype Editor 17 da Ocean Informatics 18.

Os arquétipos podem ser construídos em um idioma e posteriormente traduzidos

para qualquer outro. Isso significa que um arquétipo pode ser visto e interpretado em
diversas línguas sem perder o seu significado e contexto. De modo semelhante, os
elementos dos arquétipos podem ser associados a diversas terminologias, como por
exemplo, CID-10 e SNOMED, o que dará mais especificidade aos seus
elementos(BACELAR; CORREIA, 2015). Os arquétipos podem ser compartilhados por
meio de um repositório de nível internacional, por exemplo o Clinical Knowledge Manager
(CKM), gerido pela fundação openEHR. Arquétipos do CKM são criados por especialistas
de domínio independentes, e em seguida, eles são liberados para a comunidade como
fonte aberta e de conteúdo disponível gratuitamente (MARCOS et al., 2011).

É importante observar que, a existência de vários arquétipos para um mesmo

conceito clínico levaria ao tradicional problema da falta de interoperabilidade. Por isso, o
arquétipo precisa ser único, o mais abrangente e completo possível para servir a todas as
situações de uso. Caso o arquétipo seja muito abrangente, é possível usar apenas os
campos de interesse (BACELAR; CORREIA, 2015).

Arquétipos em outras áreas

A palavra arquétipo, segundo Silva (SILVA, 2006) deriva do grego arché: primitivo,
primeiro; e de typon: tipo, marca, modelo. Na Literatura, tem o sentido de texto original ou
mais antigo, do qual derivam outros textos. Na Filosofia, tem o sentido de modelo ideal,

17
openEHR - Archetype Editor Home. Disponível em
http://www.openehr.org/downloads/archetypeeditor/home
18
Ocean Informatics - Home. Disponível em: https://oceaninformatics.com/
 32

protótipo ideal, ideia primeira. Na Psicologia, de modo mais estudado na linha de

orientação junguiana 19, os arquétipos correspondem às imagens ancestrais e simbólicas
materializadas nas lendas e mitos da humanidade e constituem o inconsciente coletivo.

Nessa pesquisa, verificou-se que o termo arquétipo foi citado em outros setores.
Na área de desenvolvimento de software, alguns trabalhos foram encontrados em que
abordam o tema, porém com um significado peculiar, como no trabalho de Piho et al.
(2010), em que o arquétipo representa um meio de fornecer orientações para a prática de
profissionais relativa à organização de tarefas de desenvolvimento de software e de
seleção de métodos e ferramentas. O arquétipo é visto como um objeto primordial que
ocorre de forma consistente e universalmente nos sistemas.

19
Orientação Junguiana - Abordagem que aprofunda a investigação do inconsciente. Disponível
em: www.psicoterapiajunguiana.com.br
 33

CAPÍTULO III
3. Metodologia

O processo de Revisão da literatura utilizou como base metodológica, trabalhos

que demonstram passos para o desenvolvimento de uma revisão (RIDLEY,
2012),(KIRKPATRICK et al., 2004), (KURPANIK; PAŃKOWSKA, 2015), (DUARTE, 2007).
Os estudos foram organizados criteriosamente e posteriormente avaliados. A Figura 6
apresenta a descrição das etapas que constituíram o processo de elaboração dessa
revisão da literatura.

3.1 Elaboração do Projeto de Pesquisa

Esta revisão da literatura empregou um processo para identificar, avaliar e

interpretar os estudos científicos disponíveis e relevantes relacionadas a um tema
específico de interesse (EGGER; SMITH, 2001).

Figura 6. Etapas de elaboração da revisão da literatura.

 34

Definição das bases de dados, palavras-chave e termos de busca

Nessa etapa foram identificados todos os estudos que foram incluídos na revisão.
A identificação dos estudos foi realizada por meio de pesquisas em bases de dados
eletrônicas. A Tabela 1 apresenta as bases de dados escolhidas.

Tabela 1: Bases de dados para a realização das buscas.

Base de Dados Sítio

1 - ACM Digital Librarys
2 - Emerald Insight
3 - IEEE Xplore
4 - ISI Web of Science
5 - PubMed
6 - ScienceDirect
http://dl.acm.org/
http://www.emeraldinsight.com/
http://ieeexplore.ieee.org/Xplore/guesthome.jsp
https://webofknowledge.com/
http://www.ncbi.nlm.nih.gov/pubmed/
http://www.sciencedirect.com/

A partir da leitura do título e do resumo (abstract) de cada artigo identificado nas

bases de dados pesquisadas, foi construída uma base de artigos científicos com relação
direta com o tema de pesquisa. A fase seguinte foi a aplicação de critérios de inclusão e
exclusão sobre os referidos artigos, seguido pela leitura integral daqueles que passaram
por esses critérios. As palavras-chave utilizadas foram ElectronicHealthRecord;
Archetype; Database.

Em todas as bases de dados pesquisadas, foi necessário realizar a busca no modo

avançado (Advanced Search), com a finalidade de configurar alguns filtros tais como:
período de publicação; termos compostos entre aspas; Paper/Articles, etc. As junções de
palavras-chave resultaram em temos que foram utilizados nas bases de dados. Das 3
palavras-chave utilizadas, formaram-se os seguintes termos:

1. “Electronic health record” and Archetype2. “Archetype and Database”

3.2 Seleção e Avaliação Crítica dos Estudos Encontrados

O processo de busca nas bases de dados selecionadas utilizando as palavras-

chave e termos descritos, retornou estudos para a análise que potencialmente poderiam
ser incluídos na revisão. Esses estudos foram classificados em categorias, da seguinte
forma:
 35

a) Estudos identificados: estudos identificados por meio da primeira busca nas bases de
dados. Os títulos e/ou resumos de cada estudo identificado, resultante de cada busca,
foram avaliados de acordo com os critérios de inclusão e exclusão apresentados a
seguir. Os estudos identificados que aparentemente obedeciam a todos os critérios
de inclusão e não satisfaziam a nenhum dos critérios de exclusão foram selecionados
para leitura;

b) Estudos não selecionados: claramente não preenchem os critérios de inclusão. Foi

registrado apenas o número desses estudos;

c) Estudos selecionados: aparentemente preenchem os critérios de inclusão. Cada um

dos artigos selecionados foi lido e analisado integralmente.

Critérios de Inclusão e Exclusão

A Tabela 2 apresenta os critérios.

Tabela 2. Critérios de classificação dos trabalhos selecionados

Critérios de inclusão Critérios de exclusão

Ci1. Língua inglesa; Ce1. Não possuir relação com o tema;

Ci2. Artigos com ano de publicação entre Ce2. Artigos em duplicidade;
Jan/2007 e Mar/2016;
Ce3. Artigos de revisão;
Ci3. Publicações em revistas,
Ce4. Somente abordam o mecanismo de
conferências, simpósios, workshops,
consulta;
periódicos e eventos científicos;
Ce5. Abordam sobre arquétipos, mas não
Ci4. Especificar com profundidade as
apresentam soluções,
arquiteturas de RES, adotando
implementações ou experimentos.
arquétipos.

Para mais detalhes acerca dos critérios de inclusão e exclusão dos estudos, foram
analisados nos artigos reais implementações de arquiteturas e/ou experimentos de
comparações de componentes de banco de dados de um RES. A Tabela 4 apresenta
artigos excluídos que se encaixam nesses critérios.
 36

Tabela 3. Estudos excluídos de acordo com o critério adotado.

Critério de
Título Ano Observações
Exclusão
O artigo aborda uma linguagem de consulta
EHR Query Language (EQL) –
declarativa (EQL - EHR Query Language)
A Query Language for
2007 desenvolvida para consultar RES baseados Ce3
Archetype-Based Health
no openEHR. Apresenta a Syntaxe da
Records
linguagem com algumas expressões.
ImplementingHigh-Level
Aborda o XQBE, uma linguagem visual
Query Language Interfaces for
criada para facilitar o uso por profissionais
Archetype-Based Electronic 2008 Ce3
que não sejam da área de computação. É
Health Records Database
uma alternativa à AQL.
Electronic systems
Os autores propõem um modelo para a
interoperability study: based
transmissão da informação clínica (Extrato)
on 2015 Ce3
a partir de sistema de informação em uma
the interchange of hospital
maternidade para outros sistemas.
obstetrical information
Managing Archetypes for Apresenta um repositório baseado na web.
Sustainable and Semantically Não apresenta especificações do sistema e
2008 Ce4
Interoperable Electronic sim diagramas de caso de uso para
Health Records. representar o repositório.
Exporting data from an Apresenta uma metodologia para exportar
openEHR repository to 2014 dados a partir de um repositório openEHR Ce4
standard formats para formatos padrão.

Com base nos critérios de classificação dos artigos selecionados, foram obtidos
inicialmente um total de 2.521 estudos identificados, utilizando as associações de
palavras-chaves. 2.439 estudos foram excluídos em decorrência dos critérios de
exclusão. Por fim, obtivemos 82 estudos selecionados, dos quais, após leitura integral,
chegamos a 16 estudos incluídos para a coleta dos dados. Para melhor representar os
números obtidos, utilizou-se dois mecanismos: a) Tabela 4, que exibe o quantitativo de
cada Base pesquisada, de acordo com os termos utilizados; b) Figura 7, que apresenta as
fases de seleção dos estudos.

Tabela 4. Quantitativo de estudos de acordo com a fonte pesquisada

Bases Incluídos
ACM digital 1
Emerald 0
IEEE Xplore 6
ISI Web of Science 0
ScienceDirect – Elsevier 2
PubMed 6
Subtotais 15
Outras fontes 6
Total 21
 37

Figura 7. Diagrama de fluxo de seleção dos Estudos.

Outras fontes para complementação dos estudos

Esta pesquisa bibliográfica foi complementada com os seguintes procedimentos:

1. Verificação da lista de “Referências Bibliográficas”: a cada finalização da leitura do

estudo, os artigos das referências com afinidade com o tema foram visualizados e
baixados. 04 artigos foram incluídos na relação. Esses artigos não foram
encontrados no processo de busca nas bases listadas na Tabela 1.

2. Verificação no acervo de artigos em um repositório criado por meio do Zotero 20, um

gerenciador de referência disponível gratuitamente em que se encontra um grupo
de publicações relacionadas com a Fundação openEHR. Este repositório foi
organizado e disponibilizado porKoray Atalag 21.

3. Artigos publicados que se encontram no sítio da ISO 13606. É uma fonte de

informações sobre o padrão para os prestadores de cuidados de saúde. Nenhum
novo artigo, por meio dos critérios utilizados, foi incluído.

20
https://www.zotero.org/groups/openehr - gerenciador de dados bibliográficos e materiais
relacionados à pesquisa.
21
Dr Koray Atalag - The University of Auckland: https://unidirectory.auckland.ac.nz/profile/k-
atalag.
 38

4. Contato com os Prestadores de Serviços de Saúde encontrados no sítio da

Fundação openEHR. No sítio, há uma relação de organizações que adotam as
especificações openEHR em suas implementações, como mostra a Tabela 5. Na
tabela, os Prestadores são representados como Fornecedores. Foi enviado e-mail
para esses Fornecedores, explicando sobre a pesquisa. No corpo do e-mail,
solicitamos informações das implementações/propostas/soluções em conformidade
com os campos da Tabela 7 na seção 3.3, que aborda a coleta de dados.

Tabela 5. Informações das instituições que adotam openEHR em seus sistemas.

Fonte: http://www.openehr.org/who_is_using_openehr/

País Instituição Fornecedor (es) E-mail Situação

Queensland Health
Ocean Informatics, sales@oceaninformatics Implantado em
Autoridade de saúde do estado Austrália .com agosto 2012
australiano.
Northern Territory Health
AUSTRÁLIA

Ocean Informatics, sales@oceaninformatics Implantado em

Instituiçãode saúde do estado
Austrália .com outubro 2012
australiano responsável pela
prestação de saúde pública.

St Andrews Hospital Toowoomba, Ocean Informatics, sales@oceaninformatics Implantado em

Queensland, Australia Austrália .com junho 2012

St Vincents Holy Spirit Hospital Ocean Informatics, sales@oceaninformatics Implantado em

Brisbane, Australia Austrália .com dezembro 2012
Cerca de 3.000 profissionais de saúde,
incluindo médicos (principalmente
Implantado em
Oftalmologistas - Colégio Brasileiro de P2D, Brasil suporte@p2d.com.br
BRASIL

fevereiro 2012
Oftalmologistas), fisioterapeutas,
enfermeiros e recepcionistas.
Plano de saúde SPAsaude
Implantado em
ezVida, Brasil
junho 2012
Boa Esperança, São Paulo
GGZ Noord Holland Noord
Code24, Países Implantado em
info@code24.nl
Baixos abril 2011
HOLANDA

Organização de saúde mental

GGZ Friesland Code24, Países Implantado em
info@code24.nl
Organização de saúde mental Baixos agosto 2012
Rode Kruis Ziekenhuis Code24, Países Implantado em
info@code24.nl
Hospital Baixos novembro 2012

IdealMed, Coimbra, Portugal

PORTUGAL

Hospital privado que cobre várias A Critical Software info@criticalsoftware.co Implantado em

especialidades com regime de SA, Portugal m maio 2011
internação, ambulatório, cirurgia,
emergência e formação médica.
 39

EHR platform:
Moscow City Department of Marand (Slovenia)
info@marand.si
Information Technologies Clinical apps: Fase piloto.
Infinnity (Russia) info@infinnity.ru Implantado em
Autoridade responsável por soluções 2013
de e-saúde para Moscou, com 130.000 Clinical strategy & sales@oceaninformatics
usuários em 780 instalações. tooling: Ocean .com
Informatics UK

Clínica de Chelyabinsk Medical Implantadono

Infinnity, Rússia info@infinnity.ru
Academy final de 2012

Federal Medical Biological Agency

of Trekhgorny, Chelyabinskaya
RÚSSIA

oblast
Implantado em
Infinnity, Rússia info@infinnity.ru
2012
Federal Medical Biological Agency of
Chelyabinsk, Radiation Rehabilitation
Center
Russian Railways Medical Center,
Implantado em
Chelyabinsk, Department of Infinnity, Rússia info@infinnity.ru
2011
Southern Urals
University Medical Center Ljubljana,
Slovenia

UMCL é uma instituição de cuidados Implantado em

Marand, Eslovênia info@marand.si
terciários cobrindo todas as abril 2011
especialidades médicas com mais de
2.000 camas e 7.500 funcionários,
incluindo 1.200 médicos.
Institute of Oncology, Ljubljana

O Instituto é a principal instituição de Implantado em

Marand, Eslovênia info@marand.si
cuidados de câncer e pesquisa na dezembro 2012
ESLOVENIA

região. 400 leitos, 150 médicos e 800

funcionários.
Ministry of Health, Slovenia
Contratado em
O Ministério da Saúde da Eslovênia é Consoritum led by setembro de
info@marand.si
responsável pela maior parte de todas Marand, Slovenia 2012; implantado
as instituições de assistência à saúde em 2013
no país.
Piloto contratado
em setembro
UNIDO
REINO

NHS Leeds North Clinical Ocean Informatics sales@oceaninformatics de2012;

Commissioning Group UK .com implantação
inicial em outubro
2013

5. Como complementação, também foi enviado e-mail para Fornecedores que

implementam sistemas de informações em saúde baseados nas especificações
openEHR ou na norma ISO 13606. A relação das instituições, apresentada na
Tabela 6, foi conseguida por meio do trabalho de Frade et al. (2013).
 40

Tabela 6. Fornecedoresdos quais foram solicitadas informações para este trabalho.

Fonte: (FRADE, Samuel et al., 2013)
Projeto/Produto Fornecedor Sigla Pais
Base24 Code24 B.V. B24 NL
eWEAVE eWEAVE AB eW SE
Valencia Health Agency,
Tech.
HSEAVS HSEAVS ES
Univ. Valencia, Novasoft,
Everis
OceanEHR platform Ocean Informatics OEHR AU
Companies/ I nstitutions

Open EHRGen CaboLabs OGen UY

Open EHRServer CaboLabs OServ UY
OpenHealth:MultiCare Infinnity Solutions OH RU
OpenKernel ROSA Software OK NL
RecordPoint Extensia RP AU
Sistema Clinico PT
IdealMed Crit
Integrado
Think!EHR Platform Marand TEHR SI
EHRFlex Tech. Univ. Valencia, Veratech EHRF ES
GastrOS University of Auckland GOS NZ
LinkEHR Tech. Univ. Valencia, Veratech LEHR ES
LiU EEE Linko¨ping University LiU SE
OpenEyes Moorfields Eye Hospital OEyes UK

Nas Tabelas 5 e 6, alguns Fornecedores são listados mais de uma vez, o que
representa que os mesmos implementaram seus sistemas em mais de uma
instituição ou desenvolvem outros sistemas. Os casos em destaque são da Marand
(Eslovênia), Code24 (Países Baixos), Ocean Informatics(Austrália), Infinnity,
(Rússia),CaboLabs(Uruguai) e a Technical University of Valencia (Espanha).

Foram obtidas duas respostas dos e-mails, a primeira da Marand 22que enviou
informações a respeito dos campos solicitados na Tabela 7. As informações
contidas na resposta desse e-mail foram úteis em um estudo já incluído na revisão,
[17]. Na seção de resultados, as informações do e-mail são apresentadas. A
segunda empresa foi a Critical Software AS 23 de Portugal. No e-mail há
agradecimento pelo contato, e justificativas quanto a não profundidade de algumas
informações fornecidas. O conteúdo do e-mail enviado (Apêndice A) encontra-se
no final desse trabalho.

22
www.marand.com
23
http://www.criticalsoftware.com/pt/homepage
 41

6. Estudos encontrados por meio de buscas realizadas nas bases: (ACM) Digital
Library, Institute of Electrical and Electronics Engineers (IEEE) Xplore, Elsevier,
Emerald, ISI Web of Science, ScienceDirect e PubMed. O período da busca foi entre
2009 e 2014. Os termos de busca foram:

“Electronic Medical Record” and Standards;

“Electronic Medical Record” and Profiles;
“Electronic Medical Record"and Development;
“Electronic Medical Record” and “Data Integration”;
“Electronic Medical Records” and Standards;
“Electronic Medical Records” and Profiles;
“Electronic Medical Records” AND Development;
“Electronic Medical Records” AND “Data Integration”;
“Electronic Health Record” AND Standards;
“Electronic Health Record” AND Profiles;
“Electronic Health Record” AND Development;
“Electronic Health Record” AND “Data Integration”;
“Medical Record Systems” AND Standards;
“Medical Record Systems” AND Profiles;
“Medical Record Systems” AND Development;
“Medical Record Systems” AND “Data Integration”;
“Computerized Medical Records Systems”;
“Computerized Patient Medical Records”;
“Computerized Medical Record System”;
“Computerized Medical Record Systems”;
“Computerized Medical Records System”;
“Computerized Medical Records”;
“Computerized Medical Record”.

Nenhum novo trabalho foi encontrado nessa busca.

3.3 Coleta de Dados

Nesta etapa, todos os estudos selecionados foram lidos integralmente. Um

mecanismo utilizado para auxílio no processo de leitura dos estudos foi uma planilha
eletrônica com 20 campos delimitados que faz referência a determinado assunto ou
informação contida no estudo. A Tabela 7 apresenta os campos com sua respectiva
descrição.
 42

Tabela 7. Campos da planilha para extração de informações dos artigos

Variável
Ferramentas e Linguagens
Abordagem Utilizada
Ambiente em Nuvem
Segurança de Rede
Padrão/Especificação
Descrição
Ferramentas tecnológicas utilizadas, como Linguagens de
programação, servidores web, frameworks, etc.
(Distribuída, centralizada ou híbrida)
Caso utilizem Cloud Computer para armazenamento e/ou
processamento de informações
Quais os requisitos e mecanismos de segurança de rede
utilizados
OpenEHR ou ISO 13606

Projeto/Produto Nome do produto ou projeto utilizado no Estudo

Licença Qual tipo de licença do produto (Open Source/Proprietária)

Banco de Dados Mecanismo (s) de armazenamento utilizado

Tamanho do Banco Tamanho em GB.

Modelo de Dados Estrutura de armazenamento dos dados.

Objeto de Consulta Linguagem de Consulta utilizada ((SQL, AQL, Xquery, etc)

Nº de Registros de Pacientes
Informações Demográficas?
Solução de Persistência
Avaliação de Desempenho
Plataforma Mobile?
Número de Citações
Em produção?
Quantidade atual de registros armazenados no banco de
dados.
Caso a solução proposta no artigo trata de Informações
Demográficas
Descrição do mecanismo de persistência da solução descrita
no estudo
Descrição das avaliações de desempenho da solução
Caso a proposta/sistema/produto utiliza alguma
funcionalidade em dispositivos móveis
Quantidade de citações do estudo por outros artigos.
Informação se o produto/solução/sistema ainda está em
pleno funcionamento.

3.4 Agrupamento e apresentação dos dados

Fase importante no processo da revisão, representa os dados agrupados no

formato da planilha eletrônica com os campos já preenchidos de modo que as informações
possam ser interpretadas. Por meio do agrupamento, foi possível classificar as
informações dentro de categorias, permitindo a realização de uma análise crítica e
comparativa.
 43

CAPÍTULO IV
4. Resultados

Nesta seção são apresentados os principais resultados da revisão.

4.1 Estudos incluídos na Revisão

A Tabela 8 mostra os 21 estudos incluídos com o ano em que foram publicados.

Tabela 8. Estudos incluídos na revisão

Estudo Título Ano

[01] A Cloud-based Approach for Interoperable Electronic Health Records (EHRs) 2013
pyEHR: a scalable clinical data management toolkitfor biomedical research
[02] 2014
projects
yourEHRM: standard-based management of your personal healthcare
[03] 2014
information
[04] OpenEHR aware multi agent system for interinstitutional health data integration 2014

[05] Medical Informatics System for RomanianHealthcare System 2011

Proof-of-concept Design and Development of an EN13606-based Electronic
[06] 2007
Health Care Record Service
Evaluation of software maintainability withopenEHR – a comparison of
[07] 2014
architectures
"The iCabiNET system: Harnessing Electronic Health Record standards from
[08] 2012
domestic and mobile devices to support better medication adherence"
Implementation of an end-to-end standard-based
[09] 2008
patient monitoring solution
Applying representational state transfer (REST)architecture to archetype-based
[10] 2013
electronic healthrecord systems
Standardized and flexible health data Management with an archetype driven
[11] 2010
EHR system (EHRflex)
[12] Evaluation of a Framework to Implement EHR Systems 2016

[13] Towards the Implementation of an openEHR-based Open Source EHR Platform 2015

[14] An openEHR repository based on a native xml database 2012

Archetype relational mapping - a practical
[15] 2015
openEHR persistence solution
Quasi-Relational Query Language Interface for Persistent Standardized EHRs:
[16] 2013
Using NoSQL Databases
Archetype-based data warehouse environment to enable the reuse of electronic
[17] 2015
health record data
Performance of XML Databases for Epidemiological Queries in Archetype-Based
[18] 2012
EHRs
Design of an Electronic Healthcare Record Server
[19] 2011
Based on Part 1 of ISO EN 13606
[20] An Electronic Healthcare Record ServerImplemented in PostgreSQL 2015
Comparing the Performance of NoSQLApproaches for Managing Archetype-
[21] 2016
BasedElectronic Health Record Data
 44

Reposta das consultas realizadas a desenvolvedores

Como já mencionado na seção 3.2 que trata da Seleção e Avaliação Crítica dos
Estudos, foram enviados e-mails a fornecedores (Tabela 6) que implementam sistemas de
informações em saúde baseados nas especificações openEHR ou na norma ISO 13606.
A Tabela 9 apresenta as informações fornecidas pela empresa respondente, Marand. A
empresa é responsável pelo produto Think!EHR Platform 24, uma plataforma de dados de
saúde baseada em padrões de dados abertos, desenvolvida para armazenamento,
consulta, recuperação e troca de dados transacionais de saúde em tempo real. A
plataforma é utilizada na implementação do sistema proposto por MARCO-RUIZ et al.[17].

Tabela 9. Informações do produto Think!EHR Platform, da Marand.

Variável Descrição
Produto Think!EHR Platform
Plataforma central é desenvolvida em Java;
Ferramentas e
Web Services and REST API, Web SOAP, REST, Java Remoting.
Linguagens
Servidor Web: Embedded.
A solução suporta modelos de implantação diferentes, variando de único nó
Abordagem Utilizada
(centralizado) ou distribuída
Ambiente em Nuvem EhrScape - https://www.ehrscape.com/
Segurança de Rede Camada de transporte com SSL / HTTPS, e API REST
Padrão/Especificação OpenEHR
Licença comercial.
Há contribuições (código aberto):
Licença - https://github.com/openEHR/adl2-core
- https://github.com/openEHR/adl-designer
- https://github.com/ehrscape/examples
Banco de Dados Suportada por Oracle, PostgreSQL, IBM DB2, MS SQL
Objeto de Consulta AQL
DB como um armazenamento para composições BLOB. O processamento da
consulta se faz fora do DB.
Solução de Persistência
A plataforma separa a camada de índices da camada de persistência. A camada
de persistência pode conter qualquer solução de banco de dados ou até mesmo
um sistema de arquivos.

4.2 Difusão das especificações openEHR/ISO 13606 nos continentes

A Figura 08 mostra os continentes em que a norma ISO 13606 e as especificações

openEHR são adotadas em implementações. Esses padrões e especificações têm sido
mais difundidos na Europa (n=14), e na América do Sul (n=4).

24
Think! EHR Platform. Disponível em: http://www.marand-think.com/pt/index.
 45

Figura 8. Difusão openEHR/ISO 13606 nos continentes.

Fonte: http://www.dreamstime.com/royalty-free-stock-photo-colorful-continents-world-map-
image38235795. Adaptada.

4.3 Frequência das publicações por ano e por base pesquisada

No processo de busca, vários estudos foram localizados em bases diferentes, ou

seja, alguns estudos podem ser encontrados pelo menos em duas bases de dados
distintas, o que indica uma maior disponibilidade para a coleta e em um número geral de
estudos maior do que a quantidade de incluídos nesta revisão. Nesse caso, o critério de
seleção (eliminação dos repetidos) deu-se a partir da ordem de busca pelas bases, como
mostra a Tabela10, em que são apresentados os 21 estudos incluídos na revisão. O item
“Outras” se refere à busca pelas referências bibliográficas dos artigos, como explicado na
seção 3.2.
 46

Tabela 10. Estudos incluídos localizados nas bases e sua seleção

1. 2. 3. 4. 5. 6. 7.
Outras
ACM digital Emerald IEEE Xplore ISI Web Elsevier PubMed Zotero
S1 ● ●

S2 ● ●

S3 ●
S4 ●
S5 ● ●

S6 ● ● ●

S7 ● ● ●

S8 ● ●

S9 ●
S10 ● ●

S11 ●
S12 ●
S13 ● ●

S14 ●
S15 ● ●

S16 ●
S17 ● ● ●

S18 ● ●

S19 ●
S20 ●
S21 ● ●

Total 1 0 6 0 4 9 7 9

Legenda: ●Estudo incluído pela base, na revisão

●Estudo não incluído pela base, na revisão.

A partir dessa análise, as bases que se destacaram são o grupo de publicações do

openEHR (Zotero), a IEEE e PubMed. A Figura 9 apresenta a curva de evolução dos
artigos, ao longo do tempo, agrupados por base de dados. Percebe-se um crescimento do
número de publicações a partir do ano de 2012.
 47

5
ISI Web
4 EMERALD
ZOTERO
3
PUBMED
Quantidade de Estudos

2 IEEE
ACM
1
ELSEVIER
0 OUTROS
2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
Ano de publicação

Figura 9. Quantidade de estudos no período de 2007 a 2016.

4.4 Projetos/Produtos apresentados nos estudos

Um número crescente de países esforça-se no desenvolvimento de RES baseados

no openEHR/ISO 13606, o que resulta na construção de vários projetos ou produtos
implementados em diversas instituições. Nessa revisão da literatura, nem todos os
projetos/produtos usaram um nome registrado, com uma denominação específica, como
CHISTAR no sistema proposto por BAHGA e MADISETTI[01], como mostra a Tabela 11.
Tabela 11. Nomes dos produtos/projetos e local de desenvolvimento.

Produto/Projeto Instituição/Organização País Modelo

Chistar [01] Georgia Institute of Technology Geórgia OpenEHR
PyEHR [02] Instituto de Pesquisa Científica Itália OpenEHR
yourEHRM [03] ATOS Research and Innovation Espanha OpenEHR
Vepr [04] Faculdade de Medicina Universidade do Portugal OpenEHR
DESP [05] Faculty of Automation and Computer Romênia OpenEHR
[06] Hospital Universitário “Puerta de Hierro” Espanha ISO 13606
GastrOS [07] The University of Auckland Nova OpenEHR
iCabiNET [08] University of Vigo Espanha OpenEHR
[09] University of Zaragoza Espanha ISO 13606
Liu EEE [10] Universidade de Linköping Suécia OpenEHR
EHRflex [11] Universidad Politécnica de Valencia Espanha ISO 13606
EHRGen [12] Universidad Nacional de Tucumán Argentina OpenEHR
EHRServer [13] CaboLabs Uruguai OpenEHR
[14] University of Aveiro Portugal OpenEHR
ARM [15] Universidade de Zhejiang China OpenEHR
[16] University of Aizu Japão OpenEHR
[17] University Hospital of North Norway Noruega OpenEHR
[18] Universidade do Estado do Rio de Janeiro Brasil OpenEHR
[19] University College London Inglaterra ISO 13606
[20] University College London Inglaterra ISO 13606
[21] Universidade do Estado do Rio de Janeiro Brasil OpenEHR
 48

Os dados apresentados mostram que os produtos desenvolvidos originam-se de

instituições de pesquisa (n=20) e de instituições de saúde (n=1), como no caso do estudo
do Hospital Universitário “Puerta de Hierro” de MUNOZ et al.[06], na Espanha.

4.5 Classificação dos estudos incluídos

Os estudos foram classificados de acordo com sua natureza nas seguintes

categorias:

• Sistemas de RES (S-RES) – 7 estudos;

• Sistemas de Integração/Plataforma – 7 estudos. Esta categoria abrange os sistemas

responsáveis por interagir com outras tecnologias, como consulta a outros sistemas de
informações ou plataformas, kit de ferramentas e ambientes para desenvolvimento de
Sistemas de Registros Eletrônicos em Saúde;

• Repositórios – 7 estudos. Esta categoria abrange estudos que abordam comparações

entre mecanismos de persistência e experimentos de avaliação quanto à inserção e
consulta de dados.

As Tabelas 12, 13 e 14 apresentam, respectivamente, de acordo com a

classificação, um breve resumo de cada estudo, juntamente com as suas características
técnicas.

Na tabela 12 e 13, as propostas apresentam mais informações de arquitetura. Isso

se deve ao fato de pertencerem à classificação destinada às implementações dos
sistemas. Uma arquitetura distribuída, diz respeito ao ambiente em que as informações
são ou podem ser processadas e armazenadas em um modo distribuído; Ao contrário
disso, um modelo centralizado, é quando o modelo de armazenamento, segundo a
arquitetura da proposta, se dá em um nó (servidor).
 49

Tabela 12. Resumo dos estudos classificados como Sistemas RES

Resumo Arquitetura
O estudo aborda uma proposta de arquitetura de Registro Eletrônico de
Saúde chamada (CHISTAR®).Este sistema possui sub-aplicações e
• Compute Cloud
módulos que integram hospitais, farmácias, etc. O Sistema RES
(EC2 – Amazon);
CHISTAR® é implementado com os benefícios das tecnologias de nuvem
por meio da Amazon Compute Cloud (EC2) (AMAZON, 2015), e que • framework Hadoop

permite a interoperabilidade de dados por meio de um motor de MapReduce 25.

[01]
integração e interoperabilidade semântica com o uso de arquétipos. O • Distribuída;
sistema possui um módulo de integração de dados, que integrada • Web Service REST
informações clinicas (estruturados ou não) de diferentes sistemas de API.
armazenamento de dados, tais como bancos de dados relacionais
• Escalável
(RDBMS, como MySQL, Oracle, etc.), servidores de arquivos (como
texto, imagem, arquivos de vídeo, etc.) e mensagens HL7.

O estudo trata de uma ferramenta que permite consultar as informações

e extrair os dados relevantes do EHR em vários modelos de dados, tais
como openEHR ou HL7. É uma solução baseada em modelos de
informação genéricos que estão em conformidade com a norma
EN13606 e openEHR. A ferramenta, denominada yourEHRM, possibilita
a troca de informações com outros Sistemas de Informações. A • Web Service SOAP
arquitetura do sistema permite a integração de dados provenientes de e REST;
sistemas de informação de saúde heterogêneos e fragmentados. Para • Distribuída;
[03]
mecanismo de armazenamento e persistência de dados, utiliza bancos
• Escalável
de dados NoSQL orientados a documentos, MongoDB 26. O middleware
e interfaces da arquitetura são implantados como serviços baseados em
REST API (uma interface de programação de aplicativos que, usa
solicitações HTTP para GET, PUT, POST e DELETE) e usa documentos
JSON para fornecer a informação. Esta abordagem permite a extração
fácil da informação, através de consultas AQL (Archetype Query
Language).

25
MapReduce Tutorial - Apache™ Hadoop. Disponível em:
https://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html
26
MongoDB for GIANT Ideas | MongoDB. Disponível em: https://www.mongodb.com/
 50

Apresenta o VERP (Virtual Electronic Patient Record Patient), um

sistema que contém as informações médicas de um paciente,
armazenadas em uma variedade de sistemas em diferentes localizações.
Integra dados interinstitucionais utilizando as especificações openEHR
para consulta e armazenamento de dados. Fornece meios para construir
consultas semânticas, independentemente do modelo de dados do • Web Service
sistema remoto subjacente. É uma abordagem Multi-Agent. Os Integration Gateway
resultados de uma simulação mostraram que os agentes podem coletar (WSIG), SOAP;
[04]
dados de fontes externas. A troca de dados entre os sistemas é baseada
• Distribuída;
em consulta AQL no repositório remoto para recuperar extratos. O extrato
openEHR é visualizado devido a uma transformação XSLT de extratos • Escalável

XML em HTML. Como repositório é utilizado o eXist-db 27, acessível por

meio de uma série de serviços. Também utiliza XQuery para consultas,
e pode executar qualquer consulta em AQL. Embora armazena
informações em XML, os clientes podem utilizar outros tipos de formato,
como por exemplo, HTML, JSON e YAML.

Este trabalho descreve um software denominado DESP (sigla em

Romeno para o Arquivo Eletrônico de Saúde do Paciente), um modelo
experimental baseado na web com tecnologias open-source. Apresenta
uma perspectiva local, correspondente a uma unidade médica e nacional
que representa todo o sistema médico do país. Em nível nacional, ele
descreve como interconectar os sistemas locais individuais. Ele cria uma
rede nacional de sistemas nas unidades médicas que comunicam entre
• Centralizada/Distrib
si. Como uma unidade médica local entende-se uma instância de um
[05] uída;
sistema a partir do nível local, que armazena os dados e se comunica
• Escalável.
com outros sistemas semelhantes. O design do nível local é composto
de três níveis: a) Nível de dados (Camada de dados), o Nível lógico
(Lógica de negócios) e o Nível de Apresentação (Camada de
Apresentação). O sistema adota o Repositório Nacional de Arquétipos,
que contém todas as informações necessárias definidas em nível
nacional de acordo com as especificações openEHR. Por razões de
velocidade e estabilidade no sistema, cada arquétipo é salvo localmente.

27
eXistdb - The Open Source Native XML Database. Disponível em exist-db.org/
 51

O artigo apresenta um protótipo, instalado em cenário real, de um

servidor RES desenvolvido para a transferência de extratos em
• CORBA e SOAP
conformidade com a norma EN13606. O sistema é composto por cinco
Web Services para
módulos: a) As bibliotecas para a gestão do modelo de referência padrão,
comunicações entre
para o pacote demográfico e para os tipos de dados; b) O módulo de
máquinas remotas;
[06] armazenamento permanente, construído sobre uma base de dados
relacional; c) Duas interfaces de comunicação por meio das quais os • Cliente/Servidor

clientes podem enviar informações ou fazer consultas; d) O processador (Distribuída);

XML e as ferramentas para a validação dos extratos gerenciados,

implementados em um esquema XML 28; e) Uma linguagem baseada no
formato XML para definição de regras de validação ("esquemas").

O estudo apresenta uma comparação entre dois sistemas com enfoques

diferentes para o desenvolvimento de aplicações: um chamado GST e
um outro baseado no modelo openEHR, chamado GastrOS. A aplicação • Cliente/Servidor
GST segue a abordagem de programação objeto-procedimental e uma (Centralizada);
modelagem de dados relacional. GastrOS é uma implementação • Não Escalável;
openEHR desktop, utilizando plataforma .Net e C#. As principais
[07] • MVC
características tecnológicas do sistema GastrOS são: plataforma Net e
C#;a biblioteca openEHR.Net;SQLite versão 3 e MS SQL Server como
Banco de Dados. Na persistência de dados, primeiramente a instância do
valor preenchido é serializado como XML e em seguida, armazenado no
banco. Os artefatos e código-fonte estão disponíveis no site:
http://gastros.sourceforge.net.

O estudo aborda um sistema de RES baseado no OpenEHR com fins

educacionais (LiU EEE). Este ambiente educativo é destinado a ajudar
os desenvolvedores e público interessado a experimentar e aprender
sobre a abordagem de RES baseado em arquétipos e permitir uma
• REST API;
prototipagem rápida. A implementação do LiU EEE se baseia em Java
[10] • Cliente/Servidor
(lado do servidor) e um banco de dados XML é utilizada para repositório.
No lado do cliente, ele utilizaJavaScript e HTML5. O software está (Centralizada)

disponível como código aberto sob a licença Apache 2. Embora o LiU

EEE armazene informações em XML, os clientes podem utilizar outros
tipos de formato, como por exemplo, HTML, JSON e YAML.

28
W3C XML Schema. Disponível em: https://www.w3.org/XML/Schema
 52

Tabela 13. Resumo dos estudos classificados como Sistemas de Integração/Plataforma.

Resumo Arquitetura
O estudo descreve a plataforma pyEHR 29, um conjunto de ferramentas
para a construção de sistemas clínicos de gerenciamento de dados para
aplicações de pesquisa biomédica. É um kit de ferramentas, usa
formalismos openEHR para garantir a dissociação das descrições de
dados clínicos de detalhes de implementação e tecnologias NoSQL para
fornecer armazenamento escalável. O sistema possui três componentes:
a) Sistema de Gestão de Dados, que lida com o armazenamento de
dados e recuperação; b) Sistema de Gestão de Informação, que lida com • Arquitetura REST

[02] os recursos openEHR; c) Mecanismo de Consulta, que utiliza a • Distribuída;

Archetype Query Language, anteriormente conhecido como linguagem • Escalável.
de consulta de EHRs (EQL) (MA et al., 2007). O pyEHR foi escrito em
grande parte em Python. O Sistema de Gestão de Dados e o Mecanismo
de Consulta foram concebidos para suportar dados de múltiplas
tecnologias de gerenciamento via drivers conectáveis, a fim de alcançar
os objetivos de escalabilidade (vertical, horizontal ou ambos). Quanto ao
mecanismo de armazenamento e persistência de dados, a
implementação atual utiliza o MongoDB.

29
PyEHR é distribuído como código aberto e disponível no GitHub https://github.com/crs4/pyEHR
 53

Esta proposta, denominada iCabiNET, visa interagir com o repositório do

RES com base em dispositivos domésticos e móveis. O elemento-chave
do iCabiNET é o Archetype Manager, que conta com um analisador ADL
para processar o arquétipo. A arquitetura utiliza bibliotecas JDOM 30 para
o processamento do conteúdo XML. O Archetype Manager é também
responsável poracessar o repositório do RES. Para isso, ele invoca duas • Web Services

interfaces diferentes: uma baseada no paradigma de chamada remota de baseados em

RMI Java, e a outra baseada em tecnologia de Web Services para SOAP;

[08]
dispositivos móveis, o WS J2ME (AGARWAL; LAU, 2010). Na • Centralizada
arquitetura, quanto à segurança no tráfego, todas as comunicações entre (Cliente/Servidor;
o cliente iCabiNET e o repositório do RES fluem por meio de túneis • Não Escalável.
SSL 31, usando as funções criptográficas da Security and Trust Services
API32 para dispositivos móveis. Nessa proposta, implementações
openEHR podem facilmente gerar e consumir dados EN13606, portanto,
uma eventual adaptação do iCabiNET à tecnologia EN13606 não deve
exigir muito esforço.

Este trabalho é uma solução de monitoramento de pacientes em

ambientes de unidade de terapia intensiva. É baseado no padrão end-to-
end, usando as normas ISO/IEEE 11073 e EN13606. O padrão
ISO/IEEE 11073 permite a comunicação entre dispositivos médicos e • Web Services

sistemas de registros médicos de saúde. O sistema fornece captura based SOAP;

[09] eletrônica detalhada da informação do dispositivo do cliente, como os • Centralizada

sinais vitais. A aplicação possui uma rede de sensores plug-and-play que (Cliente/Servidor;
se comunica com um gateway que recolhe a informação médica e envia • Não Escalável.
os dados para um servidor de monitoramento; em seguida o servidor de
monitoramento transforma esses dados em um extrato EN13606 para ser
armazenado no servidor RES.

Apresenta um sistema baseado em arquétipos, de código aberto, para a

construção de um prontuário eletrônico baseado na web, denominado • Centralizada
EHRflex. A aplicação habilita o profissional (médico, especialista, etc.) a (Cliente/Servidor;
[11] gerir o seu próprio sistema RES em uma base simples e formal,
• Não Escalável;
assegurando que o usuário trabalha com estruturas de dados
padronizados subjacentes baseados na norma ISO 13606. Como • MVC

repositório, utiliza o eXistdb.

30
www.jdom.org/
31
http://searchsecurity.techtarget.com/definition/SSL-VPN
32
http://www.oracle.com/technetwork/java/satsa-136426.html
 54

Aborda o projeto EHRGen, uma ferramenta de software, guiada pela

gestão do conhecimento clínico, para a criação de sistemas de registros
de saúde eletrônicos (RSE). Possui três componentes fundamentais na
arquitetura: a) o repositório clínico (RC), que mantém todas as • Centralizada

informações do paciente clínico em um formato para atender o modelo (Cliente/Servidor;

[12]
de informação padrão;b) o repositório demográfico (DR), que contém os • Não Escalável.
dados de organizações, pessoas e os seus papéis (paciente, médico, • MVC
etc.); c) a base de conhecimento (BC), que mantém os arquétipos e
terminologias que serão utilizados por sistemas EHR. Utiliza MySQL ou
PostgreSQL como opções de repositório e o Hibernate (Persistência).

Apresenta um protótipo chamado EHRServer, um repositório de dados

clínicos baseado no openEHR. Fornece serviços de armazenamento e • Plataforma Cloud
consulta de informações clínicas. As principais características do Ready(Nuvem)
repositório são: a) é Open Source; b) suporta dados XML e JSON; c)
• API REST;
acesso a auditoria para rastreabilidade; d) possui interface para criação
[13] • SOA 34 (Arquitetura
de consultas; e) suporta qualquer estrutura de documento clínico; f) é
Orientada a
“Multitenancy”, ou seja, uma aplicação que atende a múltiplos clientes
Serviços);
como empresas/organizações. Tanto O EHRServer como EHRGen [12]
são fornecidos pela CaboLabs Healthcare Informatics 33. São sistemas • MVC.
diferentes que utilizam, em grande parte, as mesmas tecnologias.

33
CaboLabs Healthcare Informatics. Disponível em: cabolabs.com/
34
SOA: Arquitetura proposta para interoperabilidade de sistemas por meio de um conjunto de
interfaces de serviços fracamente acoplados, onde os serviços não necessitam de detalhes
técnicos da plataforma dos outros serviços para a troca de informações ser realizada(E-
PING_V2016, 2016).
 55

O objetivo da proposta é promover o desenvolvimento de sistemas de

informação de saúde com base na norma openEHR, permitindo uma
integração de várias áreas clínicas (por exemplo, radiologia,
administração, farmácia), e tornar o processo mais unificado por meio de
serviços web e um aplicativo de administração. Na proposta, é permitido
• Centralizada
que os pacientes acessem sua própria informação médica. O sistema
possui arquitetura projetada para dividir as funcionalidades em três • Não Escalável;
camadas, seguindo o modelo de Arquitetura Orientada a Serviços (SOA): • Arquitetura
[14]
a) camada de aplicação -possui uma aplicação web com um determinado Orientada a
conjunto de serviços ao cliente, que valida as funcionalidades do Serviços (SOA)
repositório openEHR. A aplicação funciona como uma plataforma de
• API RESTful
administração para qualquer repositório; b) camada de serviço -um
conjunto de serviços que permitem a gestão remota e transparente do
armazenamento e das consultas a informações contidas no RES; c)
núcleo, que possui um banco de dados XML nativo como tecnologia de
armazenamento.

Tabela 14. Resumo dos estudos classificados como Repositórios

Resumo Arquitetura
Apresenta uma solução de persistência para registros eletrônicos de
saúde baseados em arquétipos: ARM (Archetype Relational Mapping).
Essa solução usa uma técnica que mapeia os arquétipos para tabelas de
bancos relacionais. Um estudo comparativo foi realizado para investigar
as diferenças entre o banco de dados convencional de um sistema de
saúde em um hospital na China, o banco de dados ARM e um banco de
dados Node + Path. Cinco testes de recuperação de dados foram
projetados com base no fluxo de trabalho clínico para recuperar exames • Centralizada;
[15]
e testes laboratoriais. Além disso, dois testes de consulta foram • Escalável.
projetados para identificar os pacientes que satisfazem determinados
critérios. A base de dados ARM teve melhor desempenho na maioria dos
testes. Quanto ao banco de dados Node + Path, objetos são
serializados 35 em blobs ou strings em bancos relacionais ou objeto-
relacionais. Nessa abordagem, todos os nós de dados são serializados,
e seus caminhos são registrados em uma tabela em que se armazena o
<caminho do nó> e o <valor do nó serializado>(BEALE, 2008).

35 Processo que converte um objeto em um fluxo de bytes, para que ele possa ser persistido na memória,
num banco de dados, ou num arquivo. Sua finalidade é salvar o estado de um objeto para ser capaz de
 56

O estudo apresenta a persistência de RES utilizando um banco de dados

NoSQL. O gerador de consulta AQBE (SACHDEVA et al., 2012) é
proposto para consultar informações em RES padronizados baseados no
openEHR, usando um banco de dados NoSQL. O sistema AQBE • Play framework 36
serializa o RM e os arquétipos (openEHR) em formato JSON.. A (Nuvem);
arquitetura é dividida entre o cliente e o servidor. O lado do cliente possui
• Cliente/Servidor;
[16] o editor de consultas AQBE, que permite que o usuário insira e consulte
• Centralizada/Distrib
os dados no RES. O lado do servidor é composto por dois repositórios
uída;
de dados: o repositório de arquétipos local e o repositório de dados RES.
Apresenta uma comparação utilizando a AQL em uma base openEHR, a • Escalável.
interface AQBE em uma base relacional e o sistema AQBE proposto.
Esses dois últimos apresentaram os melhores resultados, sendo que o
AQBE proposto preservou, na consulta, a semântica dos conceitos.

Este trabalho apresenta um ambiente de armazém de dados para

resolver os desafios de interoperabilidade e de infraestrutura na
reutilização de dados clínicos, utilizando arquétipos. A abordagem age
sobre um sistema chamado SNOW que gera as informações médicas • Web Services
dos pacientes. A proposta apresenta duas perspectivas, uma local que SOAP, RESTful,
correspondente a uma unidade médica e outra nacional que representa Java Remoting
todo o sistema médico do país. Em nível nacional, o sistema descreve • Spring MVC
como interconectar os sistemas locais individuais, bem como Framework;
[17] componentes adicionais necessários. A arquitetura da proposta é dividida
• Embedded web
em quatro partes: a modelagem, extração, transformação e a carga para
server;
exploração dos dados existentes no RES do sistema SNOW. A
infraestrutura tecnológica utilizada compreende: a) ETL 37 (Extract • Centralizada/Distrib

Transform Load), que extrai dados de diversos sistemas, transforma-os uída;

conforme regras de negócios e por fim realiza a carga desses em um • Escalável.

data warehouse; b) LinkEHR - ferramenta que transforma os dados
clínicos existentes em um formato padrão. Como mecanismo de
persistência é utilizada a Plataforma Think!EHR.

recriá-lo quando necessário.Disponível em: https://msdn.microsoft.com/pt-

br/library/ms233836(v=vs.90).aspx.
36 Play Framework. Disponível em: https://www.playframework.com/
37 ETL - Data Warehouse. Disponível em datawarehouse4u.info/ETL-process.html
 57

O estudo mostra uma comparação do desempenho de banco dados

XML, por meio da avaliação do tempo de resposta. Dados do Sistema
Nacional de Informação sobre o Rastreamento do Câncer do Colo do
Útero – SISCOLO foram armazenados em duas tabelas em um banco de
dados relacional, o MySQL. Em uma outra etapa, as tabelas foram
convertidas em objetos seguindo o RM do openEHR. Os objetos
[18] convertidos em XML foram armazenados nos bancos de dados XML • Centralizada.
(eXist, Basex 38,Sedna 39e XML Berkeley DB 40). Consultas
epidemiológicas foram realizadas nos bancos XML com AQL/xQuery, e
no MySQL (relacional) usando SQL. Todas as bases XML tiveram
desempenho pior em comparação com a base relacional. O MySQL
obteve melhor desempenho, seguido de Sedna, Basex, eXist e Berkeley
DB XML.

A pesquisa demonstra uma arquitetura para a implementação de um

servidor RES compreendendo um repositório que está em conformidade
com a Parte 1 da ISO EN 13606. A arquitetura utiliza middleware para
processar instâncias do registro. A arquitetura utiliza arquétipos (13606-
2) para a validação de dados. O servidor em si compreende uma série
• Cliente/Servidor;
de módulos individuais constituídos por hosts. O servidor é composto por
• Centralizada
[19] serviços de autenticação, gerenciamento de dados demográficos,
(Implementação);
recuperação de registros, auditoria e alguns serviços estendidos para a
gestão clínica.O sistema utiliza ORM (Hibernate) e o banco de dados • Escalável
PostgreSQL. Na recuperação de dados, o servidor possui um módulo que
contém um conjunto de funções que permitem vários tipos de
recuperação de dados com base no identificador do arquétipo. O módulo
usa EJB-QL 41(Enterprise Java Beans Query Language).

38
BaseX | The XML Database. Disponível em: basex.org/
39
Sedna XML Database. Disponível em: www.sedna.org/
40
Oracle Berkeley DB XML | Oracle.Disponível em www.oracle
41
Chapter 7. EJB-QL: The Object Query Language. Disponível em:
https://docs.jboss.org/hibernate/entitymanager/3.4/reference/en/html/queryhql.html
 58

O estudo descreve a implementação de um servidor EHR dentro de um

banco de dados relacional, o PostgreSQL. O servidor roda sem
dependência de qualquer outra infraestrutura de middleware. A
arquitetura é hibrida: (a) com a utilização do Hibernate em algumas
funções, como por exemplo, nas consultas (EJB-QL) que são baseadas • Cliente/Servidor;
em nomes de tabelas e de colunas que fazem sentido para especialistas
[20] • Centralizada;
do domínio; (b) os dados do modelo de referência e dos índices de cada
nó foram representados por duas tabelas.Isto permitiu a redução do • Escalável.

número de tabelas nas consultas. Os dados dos pacientes são visíveis

para usuários, de acordo com suas permissões. Os usuários são
classificados como: (a) administrador, usuário; pesquisador; cuidador e
paciente.

Este estudo trata-se de uma avaliação de desempenho experimental por

meio de consultas de base populacional em bancos de dados NoSQL.
Foram utilizados como parâmetros dos resultados, a capacidade de
armazenamento do BD e o tempo de resposta da consulta. O
experimento utilizou dados de quatro sistemas de informações do SUS.
Os dados foram extraídos para uma tabela no esquema relacional do
MySQL. Posteriormente esse conjunto de registros foram mapeados em
documentos XML e JSON, de acordo com o modelo de informação do
openEHR. Os documentos XML foram armazenados nos bancos de
dados XML: BaseX, eXistdb e Berkeley DB XML, e os documentos JSON • Distribuída;
[21]
foram armazenados no banco de dados distribuído NoSQL baseado na • Escalável.
abordagem MapReduce, o Couchbase 42. Como resultados, no quesito
capacidade de armazenamento, os arquivos JSON (Couchbase) foram
menores do que os arquivos XML, porém os dados no Couchbase
exigiram mais espaço que o conjunto de dados no MySQL. Quanto ao
tempo de resposta, as bases de dados XML foram mais lentas que o
MySQL e o Couchbase, em consultas de base populacional ad hoc. O
Couchbase, apesar de requerer mais espaço do que a base de dados
relacional e exigir um tempo de indexação muito maior para cada nova
consulta, obteve melhores tempos de resposta.

42
Couchbase: NoSQL Database. Disponível em www.couchbase.com
 59

4.6 Taxa de citação

A Figura 10 fornece uma visão da taxa de citações dos estudos. Os dados das
citações foram coletados por meio do Google Scholar43.
NÚMERO DE CITAÇÕES

49 52
45
29
17
9 11 10
1 3 5 1 2 4 5
0 0 0 0 0 0
S1 S3 S4 S5 S6 S7 S10 S2 S8 S9 S11 S12 S13 S14 S15 S16 S17 S18 S19 S20 S21
Sistema RES Sistema de Integração/Plataforma Repositório
CLASSIFICAÇÃO DOS ESTUDOS

Figura 10. Quantitativo de citações por estudo de acordo com sua classificação.
Coleta realizada em 20.05.2016. Pelo autor.

Na classificação dos estudos por categorias, o percentual do total de citações por

categorias foram:

 Sistemas RES- 49,0% (n=119);

 Sistemas de Integração/Plataforma - 39,5% (n=96);
 Repositórios - 11,5% (n=28).

O estudo mais citado da presente revisão é o de MUNOZ et al.[06], publicado em

2007. O artigo é o mais antigo dentre todos.

4.7 Tecnologias utilizadas nas arquiteturas

A Tabela 15 apresenta uma visão qualitativa das tecnologias adotadas nos

projetos/produtos de cada estudo.

43
Google Scholar. Disponível em: http://scholar.google.com.br/
 60

Tabela 15. Variáveis qualitativas contidas nos projetos/produtos de estudo

S10
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
Σ

S1
S2
S3
S4
S5
S6
S7
S8
S9
MySQL ● ● ● ● ● 5
PostgreSQL ● ● ● 3
Oracle 0
SQL Server ● 1
Banco de Dados

SQLite ● 1
MongoDB ● ● ● 3
Hbase ● 1
eXist ● ● ● 3
BaseX ● 1
Couchbase ● 1
Berkeley DB XML ● 1
Não definido ● 1
XML ● ● ● ● ● ● ● ● ● ● ● ● 12
Estrutura de JSON ● ● ● 3
Armazenamento XML ou JSON ● ● ● ● 4
Tabelas Relacionais ● ● ● 3
AQL ● ● ● ● ● 5
XQuery ● ● ● ● ● ● ● ● 8
Linguagem de Consulta

SQL ● ● ● ● ● ● 6
HQuery ● 1
AQL ● ● ● 3
XPath/Xquery 0
AQBE ● 1
AQL + SPARQL ● 1
EJB-QL ● ● 2
Não definido 2
REST ● ● ● ● 4
SOAP ● ● ● ● 4
Serviços

REST/SOAP ● ● ● 3
CORBA/SOAP ● 1
REST/SOAP/Java Remoting ● 1
 61

S10
S11
S12
S13
S14
S15
S16
S17
S18
S19
S20
S21
S1
S2
S3
S4
S5
S6
S7
S8
S9
JVM ● 1
Google Web Toolkit ● 1
EJB 3/Jboss ● ● 2
Não definido ● ● ● ● 4
Apache 2.0 ● ● ● ● ● 5
Open Source ● ● ● ● ● ● ● ● ● 9
Licença

AGPL ● 1
Comercial ● ● ● 3
GPL/MPL ● 1
Não definido ● ● 2
.Net ● 1
Axis ● ● 2
C# ● 1
C/C++ ● ● 2
Eclipse/NetBeans ● ● 2
Eiffel ● 1
FreeMarker ● ● ● 3
Frameworks e Linguagens

GRAILS + Groovy (MVC) ● ● 2

Java ● ● ● ● ● ● ● ● ● ● ● ● ● 13
JavaScript ● ● 2
Maven ● 1
Visual Studio ● 1
Python ● 1
SAX ● 1
Scala ● 1
Smarty + PHP5 ● ● 2
Spring MVC ● ● 1
ZK ● 1
JSF (MVC) ● ● 2
Não definido ● ● 2
 62

JAVA destaca-se como linguagem de programação no cenário das

implementações. Xquery foi a linguagem de consulta mais utilizada, uma vez que muitos
projetos utilizaram bancos de dados XML em suas implementações, seguida de AQL, uma
linguagem de consulta em uso extensivo em uma implementação openEHR; e SQL, que
acompanha o esquema relacional.

O uso de Web Services (WS) apresenta destaque nas implementações. De acordo

com SHENG et al.(2014), um serviço Web é essencialmente uma abstração
semanticamente bem definida de um conjunto de atividades computacionais ou físicas
envolvendo uma série de recursos, destinada a satisfazer uma necessidade do cliente ou
um requisito de negócio. Os WSmais populares e implementados foram os baseados em
SOAP e RESTful. O primeiro é baseado em WSDL, (Web Services Description
Language) 44, uma linguagem que permite descreverem formato XML a interface de um
serviço), o segundo está em conformidade com os princípios da arquitetura do REST.

Algumas propostas usam os benefícios do padrão MVC. Esse é o padrão que

separa o modelo (conteúdo de informações) da visualização (o que o usuário vê na tela)
e do controlador (o que ocorre em resposta à entrada do usuário ou a um navegador que
aponta para uma URL). Além disso, frameworks populares, como Spring, JSF(Java Server
Faces) e GRAILS, facilitam a utilização do padrão MVC para ambientes distribuídos.

4.7.1 Comparação de arquiteturas de armazenamento

Dentre os produtos/projetos implementados e abordados nos estudos,

apresentamos os que utilizam banco de dados SQL (n=12) [05, 06, 07, 08, 09, 12, 13, 15,
17, 18, 19 e 20] e NoSQL (n=09) [01, 02, 03, 04, 10, 11, 14, 16 e S21]. A partir dessas
informações, realizamos uma comparação das arquiteturas de armazenamento. Para
realizar essa comparação, utilizamos a classificação de acordo com os resultados
observados na seção 4.1, em que os estudos são representados por categorias. Modelos
que representam as arquiteturas foram desenhados para apresentar suas similaridades e
diferenças. As informações foram agrupadas de acordo com os seguintes serviços:

44
XML WSDL - W3Schools. Disponível em: www.w3schools.com/xml/xml_wsdl.asp
 63

1. Armazenamento em banco de dados relacionais;

2. Armazenamento XML em banco de dados XML;
3. Armazenando JSON em banco de dados NoSQL.

1. Armazenamento em banco de dados relacionais

A Figura 11 apresenta três modelos de arquiteturas em que o armazenamento se

dá em bancos de dados relacionais, porém de maneira diferentes:

a) solução ARM (Archetype Relational Mapping) para persistência em um RES

baseado em arquétipo [15]:

A solução ARM aborda uma técnica de persistência para um RES por meio de
regras de mapeamento que gerenciam as versões dos arquétipos (novos e antigos) e
mapeiam os arquétipos para o esquema relacional (tabelas, colunas, índices, etc.) para
alcançar um melhor desempenho na recuperação de consultas.

b) ORM (Object Relational Mapping) por frameworks [12], [13], [19] e [20]:

A técnica ORM utiliza um mapeamento das classes do modelo de referência para

uma representação do modelo de dados relacional. Essa técnica auxilia na construção da
camada de acesso a dados, simplificando a implementação das operações básicas da
camada de persistência (indexação, inserção/alteração, exclusão e leitura). Frameworks
são utilizados, como o Hibernate [19] e [20], que tem como finalidade fazer a ponte de
ligação com o banco de dados para obter persistência. As consultas são realizadas por
meio do modelo de objetos utilizando a linguagem EJB QL.

(c) Armazenamento XML no modelo relacional [05], [06], [08] e [09].

Na proposta de STAN et al.[05], não houve mapeamento. O PostgreSQL dispõe de

um tipo de dados especial usado para armazenar dados XML, possibilitando a verificação
de valores de entrada, além de armazenar documentos bem formados e armazenar
fragmentos de conteúdo. Os arquétipos são salvos no formato XML.

MUNOZ et al.[06] usam a API SAX para manipular o arquivo XML. Após o arquivo
ser analisado pela API, ele é inserido no banco por meio do ODBC. Cada classe do RM é
representada por uma tabela no MySQL. O ponto fraco da aplicação é no sistema de
 64

armazenamento. Os tempos registrados durante o uso demonstraram que, com a

configuração apresentada, houve grande demora na operação em um ambiente de tempo
real.

Figura 11. Persistência de dados utilizando mapeamento ARM (a), ORM (b) e
XML (c).

LÓPEZ-NORES et al.[08] usam a API JDOM para analisar o documento XML.

Porém as informações do arquivo XML são carregadas como uma estrutura de dados em
árvore na memória, para depois serem armazenadas no repositório MySQL. JDOMé a
implementação disponibilizada pela linguagem Javada API DOM(Document Object Model),
utilizada também por MARTÍNEZ, I. et al.09]. Experimentos foram realizados para analisar
o desempenho e escalabilidade do repositório MySQL. Foi verificada a sobrecarga no
sistema e o custo computacional na utilização das tecnologias de Web Services (SOAP,
REST e Java RMI). Embora Java RMI apresentou melhores resultados, as diferenças em
termos de custo computacional em relação a SOAP e REST foram pequenas.
 65

Embora as arquiteturas apresentadas na Figura 11 apresentem armazenamento

em bancos de dados relacionais, há uma grande diferença entre elas: o modelo de
mapeamento.

Em (a) não ocorre ORM, como método de persistência, pois o mapeamento, na

abordagem, ocorre de maneira direta entre o arquétipo e banco de dados relacional por
meio da técnica ARM. O objetivo desse método é de alcançar desempenho semelhante
em relação às bases de dados convencionais na recuperação de consultas (não
populacionais). A solução mapeia o arquétipo para uma tabela por meio de regras. Essas
regras analisam o arquétipo. Caso não haja um item de identificação de dados no
arquétipo, é gerado um item com a descrição "id" e utilizado uma chave para identificar os
registros na tabela. Após o mapeamento, obtém-se o esquema relacional (tabelas,
colunas, índices, relacionamentos, etc.).

Em (b) ocorre ORM. A finalidade na utilização desse método é de aproveitar ao

máximo o conceito de OO. Cada classe a ser armazenada é tratada no banco como uma
tabela. É feito um mapeamento do Modelo de Referência para o modelo relacional,
diferente do que ocorre em (a). Cada objeto de uma determinada classe é mapeado em
uma tupla da tabela que representa sua classe. Os atributos da classe são as colunas da
tabela correspondente(MURTA; VERONESE; WERNER, C. M. L., 2001). Não há uma
concepção análoga no modelo relacional. Com essa técnica, o desenvolvedor poderá usar
uma interface de programação simples onde o framework utilizado pode fazer todo o
trabalho de persistência(NASCIMENTO, 2005).

Em (c) não ocorre mapeamento. O tratamento do arquivo XML se dá ou por

característica própria do banco de dados, no caso o PostgreSQL ou pelo uso de
Analisadores (parser), ou seja, uma ferramenta que percorre um documento e extrai os
dados relevantes. Nesses casos, os analisadores utilizam as interfaces SAX ou DOM para
analisar documentos XML.

2. Armazenamento XML com banco de dados XML

Nos estudos [04], [11], [14] e [18], os dados no formato XML são armazenados em
bancos de dados XML nativos. Uma característica básica desses bancos é que eles lidam
de forma mais natural com os dados semiestruturados em relação aos bancos de dados
 66

relacionais, diferente do apresentado nos modelos do item I. Embora o MySQL, o SQL

Server e o PostgreSQL possuam suporte a XML, as técnicas e armazenamento e
consultas são diferenciadas em relação ao banco XML Nativo, devido à estrutura
intrínseca do XML.

VELTE et al. [14] utilizam o BaseX. A análise de desempenho foi realizada com
operações de consulta e inserção de dados de um paciente. O processo de consulta foi
mais rápido que o de inserção. No entanto, o tempo de inserção aumenta de acordo com
o número de registros. Nessas circunstâncias, o repositório é mais adequado para
sistemas que requerem uma resposta mais rápida a consultas individuais. Em outra
avaliação, quando utilizado um mecanismo de indexação, os resultados foram
semelhantes, porém, para consultas a atributos especiais ao longo de um conjunto de
dados de vários pacientes, os tempos de resposta foram muito mais altos, e que depende
do número de registros inseridos.

Em FREIRE et al. [18], consultas epidemiológicas foram realizadas em bancos XML

e em um banco de dados relacional. Os tempos de resposta dos bancos de dados XML
deixaram muito a desejar, em comparação com a base de dados SQL. Para o BaseX, o
tempo de resposta é muito elevado, mesmo para o menor conjunto de dados. O banco de
dados relacional obteve um desempenho muito melhor que todos os bancos XML.

Há duas soluções que apresentam uma arquitetura com existDB, porém de forma
diferenciada. BLOBEL et al.[11] abordam uma arquitetura local ou primária,(VIEIRA-
MARQUES et al.[04], embora não apresentem uma análise de desempenho, adotam uma
arquitetura em nível nacional, ou seja, o sistema armazena a informação médica em um
paciente, coletada de outros sistemas locais (em hospitais e clínicas).

3. Armazenando JSON com banco de dados NoSQL

Apresentamos na Figura 12, o modelo de banco de dados que pertencem à

categoria NoSQL, o mongoDB [02, 03 e 16], como solução de código aberto, de alta
performance e orientado a documentos. Essa solução não utiliza esquemas e o
armazenamento das informações são em documentos no formato JSON.

Uma grande característica nessas propostas [02, 03, e 16], é a utilização de um

outro repositório para armazenamento de arquétipos XML que depois são convertidos
 67

para o formato JSON. O paradigma da computação nas nuvens também é utilizado nesses
estudos. Por sua característica própria (NoSQL), em todas as soluções com mongoDB há
escalabilidade horizontal. As arquiteturas são do tipo cliente/servidor, em que no lado
cliente, é permitido que o usuário consulte os dados no Servidor RES. O Servidor é
composto por dois repositórios: (a) um local, que contém os arquivos XML correspondente
aos arquétipos baixado no CKM; (b) o repositório RES, usado para recuperar resultados
da consulta do usuário.

Figura 12. Armazenamento distribuído

em banco de dados NoSQL mongoDB.

LIANAS et al.[02] e BARCA et al.[03] utilizam REST API para operações CRUD
(Create, Read, Update, Delete). As propostas não apresentam uma avaliação de
desempenho.

Em MADAAN et al.[16], há um gerador de consultas que serializa os dados do RES

e os arquétipos (openEHR) em formato JSON, o AQBE. O MongoDB é apresentado em
duas comparações: a) a primeira com alguns tipos de consultas, utilizando a AQL em uma
base openEHR, uma interface de consulta AQBE em uma base relacional. A proposta não
apresenta uma avaliação de desempenho.

Outras propostas também utilizaram bancos de dados NoSQL, como no estudo de

BAHGA e MADISETTI [01], em que se utiliza o Hbase, um banco de dados distribuído,
orientado a coluna, que fornece uma maneira tolerante a falhas de armazenar grandes
 68

quantidades de dados dispersos. Na arquitetura é utilizado o HDFS, um sistema de

arquivos que segue a estrutura MapReduce. O desempenho nessa solução foi testado
quanto à escalabilidade e o tempo de resposta. Em consultas com múltiplos usuários em
um banco de dados distribuídos em um cluster (escalabilidade horizontal), o tempo de
resposta obteve melhores desempenhos, quando comparados em um ambiente em que
se aumenta a capacidade de processamento de servidores (escalabilidade vertical).

Em FREIRE et al. [21], o Couchbase, com armazenamento JSON e de acordo com

as especificações openEHR, foi experimentado para consultas de base populacionais e
apresentou resultados melhores em relação a um banco de dados relacional, o MySQL e
aos bancos de dados XML. Os resultados mostram que os bancos de dados XML
avaliados possuem desempenho limitado para essas consultas, mesmo com alterações
nos índices e otimização das consultas. Um outro resultado foi quanto à análise de um
cluster de bancos de dados Couchbase. Tamanhos maiores do cluster podem melhorar o
desempenho na recuperação para maiores conjuntos de dados.
 69

CAPÍTULO V

5. Discussão

Os resultados desta pesquisa mostraram que a utilização da abordagem “Dual

Model” no desenvolvimento de sistemas de registro eletrônico de saúde tem sido um tema
de pesquisa recorrente. Não há ainda um consenso sobre as melhores práticas para a
implementação de um S-RES baseado na modelagem multinível. Entretanto esta revisão
levanta uma série de questões que merecem ser discutidas.

5.1 Metodologia de busca

Na metodologia de busca dos estudos, apesar de serem utilizadas poucas

palavras-chaves e termos de busca, acreditamos que as buscas complementares (lista
de referências dos artigos encontrados, repositório da Fundação openEHR no Zotero e
consulta aos resultados de um outro estudo de revisão) permitiu uma cobertura
abrangente dos trabalhos publicados sobre a implementação de S-RES baseados na
modelagem multinível, utilizando as especificações openEHR ou ISO-13606.

O período compreendido entre 2002 e 2008 foi um período de amadurecimento das

especificações openEHR e o padrão ISO 13606. Em 2008, a Fundação openEHR lançou
uma versão estável de suas especificações e a ISO publicou a especificação do modelo
de referência da ISO 13606. Assim o período de busca utilizado nesta revisão (de 2007
a 2016) foi adequado para identificar implementações com base em especificações
estáveis. De fato, o que se observou é um número crescente de publicações relativas à
implementação de S-RES que utilizam as especificações openEHR e ISO 13606,
especialmente a partir de 2012.

5.2 Estágio das implementações openEHR

Embora o número de publicações tenha crescido nos últimos anos, o número de

artigos identificados nesta revisão foi relativamente pequeno, com poucas
implementações, em geral protótipos, e poucas avaliações de mecanismos de
persistência. Empresas que implementaram as especificações openEHR e afirmam ter
sistemas em produção, como a Ocean Informatics e Marand, não publicaram artigos em
revistas científicas sobre seus produtos. Tivemos um baixíssimo retorno (apenas Marand
 70

forneceu dados sobre o seu sistema) dos e-mails enviados para empresas identificadas
no sítio da Fundação openEHR. Porém, o trabalho de FRADE et al.(2013), utilizado nessa
revisão, de certa forma, compensa esta situação. O trabalho obteve 16 respostas de 21 e-
mails enviados. A maioria das implementações identificadas naquele estudo também não
estavam em produção.

As mudanças propiciadas por estas especificações têm o potencial de incrementar

ainda mais a evolução da TI no setor da saúde. O seu impacto está sendo sentido no
rápido desenvolvimento e na atualização de novos RES.

Tradicionalmente, os S-RES têm sido desenvolvidos por meio da abordagem de

um único nível. Com constantes modificações necessárias, é preciso alterar o código-fonte
e a base de dados do RES, significando mais tempo e trabalho. A adoção do modelo de
referência e arquétipos parece refletir positivamente na evolução e manutenção do S-RES
[07]. A acomodação de novos conceitos, sem a necessidade de alterações, resulta na
redução de custos de TI. Entretanto, mais estudos são necessários para avaliar o impacto
da modelagem multinível sobre a manutenção evolutiva de S-RES.

5.3 Arquiteturas dos Sistemas

As linguagens de programação orientadas a objetos mais populares (Java

especialmente, C++, Python e C#), ambientes integrados de desenvolvimento e padrões
de projeto têm sido utilizados no desenvolvimento dos S-RES baseados na modelagem
multinível. Estes recursos têm contribuído para um tempo menor de desenvolvimento e
reutilização de componentes.

Diversas arquiteturas têm sido utilizadas para a implementação dos sistemas

revisados neste trabalho. O modelo cliente/servidor, frequentemente utilizando o padrão
de projeto MVC (Model-View-Controller), é bastante adotado nas implementações.

A arquitetura orientada a serviços (SOA), por meio de web services (WS) também
são bastante frequentes. Os WS mais populares são SOAP e RESTful. Os estudos
apresentam propostas semelhantes, utilizando web services para autenticação de
usuários e consulta de dados clínicos em um repositório. Como exemplo, a abordagem
REST é utilizada na interface de administração do usuário, por meio de uma API, em
GUTIÉRREZ [13], como servidor de extratos OpenEHR em MARCO-RUIZ et al. [17], ou
 71

ainda em VELTE et al. [14], que utiliza REST no armazenamento e consulta de registros
em um banco de dados XML. Porém há arquiteturas que utilizam tanto REST como SOAP,
como em VELTE et al. [14].

No paradigma da computação em nuvem, as tecnologias oferecidas são utilizadas

em grande escala associadas a um conceito de Big Data, em que o foco é a capacidade
de lidar com o grande armazenamento de dados em volume e variedade. Os usuários
podem solicitar os serviços de computação em nuvem, de acordo com três modelos:
Infrastructure as a Service (IaaS), Platform as a Service (PaaS) e Software as a Service
(Saas). Cada um deles difere do nível de funcionalidade fornecida pelo provedor de nuvem
ao usuário. Em BAHGA e MADISETTI [01] a arquitetura utiliza Saas, em que os médicos
podem fazer uploads de relatórios de diagnóstico para a nuvem de forma que podem ser
acessados remotamente por outros médicos para diagnosticarem uma doença. Em
GUTIÉRREZ [13], o sistema também utiliza SaaS, em que a plataforma fornece alta
disponibilidade de dados, redundância e backup de metadados, ou seja, requisitos básicos
para qualquer RES compartilhado.

5.4 Persistência de Dados

Uma questão central em todo o sistema de informação é o desempenho do seu

mecanismo de persistência. Diversos enfoques têm sido experimentados no
desenvolvimento de S-RES baseados na modelagem multinível, sendo que esses
mecanismos podem ser utilizados nas diversas arquiteturas discutidas no item anterior.

Uma solução de persistência deve atender a diversos casos de uso: inserção e

atualização de registros, consultas individuais e consultas de base populacional.

As consultas individuais são utilizadas principalmente no atendimento de um

paciente, onde os dados do paciente devem ser apresentados ao profissional de saúde
para que o mesmo realize o atendimento. Os tempos de resposta nesta situação devem
ser baixos, no máximo alguns poucos segundos. As propriedades ACID são
frequentemente exigidas para este tipo de consulta.

As consultas de base populacional são aquelas que buscam retornar dados

agregados ou um conjunto de pacientes que atendem a certos critérios especificados.
Neste caso, há uma maior tolerância em relação aos tempos de resposta e as
 72

propriedades ACID não são requisitos prioritários, sendo suficientes que as propriedades
BASE sejam satisfeitas.

Uma técnica de persistência utilizada frequentemente pelos desenvolvedores OO

é o mapeamento objeto-relacional, por meio de frameworks como o Hibernate. Poucas
implementações de sistemas multiníveis utilizaram este recurso [6, 13]. Entretanto
MUNOZ et al.[06] afirmam que seu desempenho não foi satisfatório, apesar de não
apresentar dados que suporte esta conclusão.

Os bancos de dados relacionais, MySQL e PostgreSQL, são frequentemente

utilizados como repositórios de dados nos sistemas identificados nesta revisão, mas, na
maioria dos casos, eles não são utilizados da forma tradicional, via mapeamento objeto-
relacional.

Possivelmente, umas das primeiras propostas de armazenamento de dados para

sistemas openEHR foi a apresentada por BEALE(2008), a qual utiliza nós indexados por
caminhos (Node + Path), onde os objetos são serializados em blobs ou strings em bancos
relacionais ou objeto-relacionais e seus caminhos são armazenados em uma tabela e
compõem um índice para os nós.

WANG et al. [15] propuseram um mapeamento de arquétipos para o modelo

relacional. Esta proposta apresentou melhor desempenho do que a proposta Node +
Path, tanto em consultas individuais quanto populacionais.

O armazenamento de dados no formato XML, seja em bancos de dados XML

nativos, seja em bancos de dados relacionais com suporte a XML, como o PostgreSQL,
não apresentou bom desempenho, especialmente para consultas de base populacional
[18, 21].

Além dos bancos de dados XML, outros bancos de dados NoSQL, como o
MongoDB e Couchbase, com suporte a MapReduce, foram experimentados como
repositórios de S-RES baseados em arquétipos, apresentando bons desempenhos para
consultas individuais e populacionais. Por sua natureza distribuída, estes repositórios são
escaláveis horizontalmente. Por outro lado, por enfatizarem as propriedades BASE, eles
podem não satisfazer as propriedades ACID, quanto elas forem requisitos obrigatórios.
Esta é uma questão que merece ser melhor estudada.
 73

Alguns sistemas comerciais estão em produção, mas poucas informações estão

disponíveis sobre estes sistemas. A empresa Marand (software Think!EHR), por exemplo,
em seus folhetos de divulgação, afirma que seu sistema apresenta desempenho
satisfatório, mas não apresenta detalhes de suas avaliações. O trabalho de MARCO-RUIZ
et al. [17], que aborda um datawarehouse baseado no openEHR, utiliza o Think!EHR e,
no entanto, o desempenho, a julgar pelos dados publicados, não poderia ser considerado
muito satisfatório.

Apesar de não oferecer uma receita de como implementar um sistema de registro

eletrônico de saúde baseado em arquétipos, este trabalho apresentou as arquiteturas e
os mecanismos de persistência utilizados propostas até então publicadas. Algumas linhas
gerais foram apresentadas, as quais podem ser utilizadas para orientar novas pesquisas
e/ou novas propostas de desenvolvimento de sistemas baseados na modelagem
multinível.
 74

CAPÍTULO VI

6. Conclusão

Embora não seja possível estabelecer um conjunto de práticas consensuais sobre

a melhor forma de implementar um S-RES baseados na modelagem multinível, algumas
conclusões podem ser extraídas deste estudo de revisão.

O período da busca realizada nesta revisão corresponde ao período onde a

modelagem multinível por meio das especificações openEHR e ISO 13606 vem sendo
utilizada para o desenvolvimento de S-RES, particularmente a partir de 2012.

Em geral, as implementações publicadas estão em estágio inicial. As empresas que

afirmam ter implementações em produção não têm publicado artigos sobre seus produtos
em revistas científicas.

Os sistemas têm sido implementados por meio de linguagens OO e nas mais

diversas arquiteturas: cliente-servidor, SOA e em nuvem.

Em relação aos mecanismos de persistência, das propostas avaliadas até o

momento, as que tiveram melhor desempenho foram o mapeamento arquétipo-relacional
e os bancos de dados NoSQL que implementam o paradigma MapReduce.
 75

Referências

ABITEBOUL, S.; HULL, R.; VIANU, V. Foundations of databases: the logical level. [S.l.]: Addison-
Wesley Longman Publishing Co., Inc., 1995.

AGARWAL, S.; LAU, C. T. Remote health monitoring using mobile phones and Web services.
Telemedicine and e-Health, 2010. v. 16, n. 5, p. 603–607.

ALMEIDA, M. B. Revisiting Ontologies: a necessary clarification. Journal of the American Society

for Information Science and Technology, 2013. v. 64, n. 8, p. 1682–1693.

AMATO, F. et al. CloSe: A Cloud SaaS for Semantic Document Composition. [S.l.]: IEEE, 2012. p.
781–786. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6245775>. Acesso em: 20 jul.
2016.

AMAZON, E. Amazon web services. Available in: http://aws. amazon. com/es/ec2/(November

2012), 2015.

BACELAR, G.; CORREIA, R. As bases do openEHR. 2015. n. SEPTEMBER 2015, p. 42.

BAHGA, A.; MADISETTI, V. K. A Cloud-based Approach for Interoperable Electronic Health Records
(EHRs). IEEE Journal of Biomedical and Health Informatics, set. 2013. v. 17, n. 5, p. 894–906.

BARCA, C. C. et al. yourEHRM: Standard-based management of your personal healthcare

information. [S.l.]: IEEE, 2014. p. 89–92. Disponível em:
<http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6864311>. Acesso em: 20 jul. 2016.

BAUER, C. Hibernate em ação. [S.l.]: Ciência Moderna, 2005.

BEALE. Node+Path Persistence. [S.l.], 2008. Disponível em:

<https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=6553626>. Acesso em: 9 set.
2016.

BEALE, T. Archetypes: Constraint-based domain models for future-proof information systems. [S.l.]:
[s.n.], 2002. V. 105.

BEALE, T. et al. OpenEHR architecture overview. The OpenEHR Foundation, 2006.

BEALE, T. et al.The openEHR reference model—EHR information model—Release 1.0. 2. [S.l.]:

[s.n.], 2008.

BIRD, L.; GOODCHILD, A.; TUN, Z. Z. Experiences with a two-level modelling approach to electronic
health records. Journal of Research and Practice in Information Technology, 2003. v. 35, n. 2,
p. 121–138.

BLOBEL, B.; OTHERS. Standardized and flexible health data management with an archetype driven
EHR system (EHRflex). [S.l.]: IOS Press, 2010. V. 155, p. 212.

BRASIL. Ministério do Planejamento, Orçamento e Gestão. Guia de Interoperabilidade: Cartilha

Técnica. [S.l.], 2015. Disponível em: <http://www.governoeletronico.gov.br/documentos-e-
arquivos/Guia_de_Interoperabilidade_Cartilha_Tecnica_2015.pdf>. Acesso em: 9 set. 2016.
 76

CHEN, D.; DOUMEINGTS, G. European initiatives to develop interoperability of enterprise

applications—basic concepts, framework and roadmap. Annual Reviews in Control, 2003. v. 27,
n. 2, p. 153–162.

CHEN, D.; VERNADAT, F. Standards on enterprise integration and engineering—state of the art.
International Journal of Computer Integrated Manufacturing, 2004. v. 17, n. 3, p. 235–253.

DE DIANA, M.; GEROSA, M. A. Nosql na web 2.0: Um estudo comparativo de bancos não-
relacionais para armazenamento de dados na web 2.0. 2010. Disponível em:
<http://www.lbd.dcc.ufmg.br/colecoes/wtdbd/2010/sbbd_wtd_12.pdf>. Acesso em: 21 jul. 2016.

DIAS; COOK; FREIRE, S. M. Modeling healthcare authorization and claim submissions using the
openEHR dual-model approach. BMC medical informatics and decision making, 2011. v. 11, n.
1, p. 1.

DUARTE, C. M. R. Reflexos das políticas de saúde sobre as tendências da mortalidade infantil no

Brasil: revisão da literatura sobre a última década Health policy effects on infant mortality trends in
Brazil: a literature review from the last decade. Cad. Saúde Pública, 2007. v. 23, n. 7, p. 1511–
1528.

EGGER, M.; SMITH, G. D. Principles of and procedures for systematic reviews. Systematic
Reviews in Health Care: Meta-Analysis in Context, Second Edition, 2001. p. 23–42.

E-PING_V2016. e-PING_v2016_26022016 - e-PING_v2016_26022016.pdf. [S.l.], 2016. Disponível

em: <http://www.governoeletronico.gov.br/documentos-e-arquivos/e-PING_v2016_26022016.pdf>.
Acesso em: 9 set. 2016.

ERCAN, M. Z.; LANE, M. An evaluation of NoSQL databases for EHR systems. [S.l.]: Auckland
University of Technology, School of Business Information Systems, 2014. Disponível em:
<http://eprints.usq.edu.au/26225>. Acesso em: 21 jul. 2016.

FRADE, S. et al. Survey of openEHR storage implementations. [S.l.]: IEEE, 2013. p. 303–307.

FREIRE, S. M. et al. Performance of XML Databases for Epidemiological Queries in Archetype-

Based EHRs. [S.l.]: Linköping University Electronic Press, 2012. p. 51–57. Disponível em:
<http://www.ep.liu.se/ecp/article.asp?issue=070&volume=&article=009>. Acesso em: 20 jul. 2016.

______. Comparing the Performance of NoSQL Approaches for Managing Archetype-Based

Electronic Health Record Data. PLOS ONE, 9 mar. 2016. v. 11, n. 3, p. e0150069.

FREIRE; COPETTI, A.; LOQUES, O. Utilizando o modelo dual para a representação e persistência
de contexto em aplicações ubíquas de telemonitoramento. [S.l.]: [s.n.], 2008. p. 15–18.

GARETS, D.; DAVIS, M. Electronic medical records vs. electronic health records: yes, there is a
difference. Policy white paper. Chicago, HIMSS Analytics, 2006. p. 1–14.

GØEG, K. R.; CORNET, R.; ANDERSEN, S. K. Clustering clinical models from local electronic health
records based on semantic similarity. Journal of Biomedical Informatics, abr. 2015. v. 54, p. 294–
304.

GUTIÉRREZ, P. P. Towards the Implementation of an openEHR-based Open Source EHR Platform

(a vision paper). [S.l.]: IOS Press, 2015. V. 216, p. 45.

HAERDER, T.; REUTER, A. Principles of transaction-oriented database recovery. ACM Computing

Surveys (CSUR), 1983. v. 15, n. 4, p. 287–317.
 77

HAN, J. et al. Survey on NoSQL database. [S.l.]: IEEE, 2011. p. 363–366.

HIQA. National Standard for Patient Discharge Summary Information Safer Better Care. 2013. n.
July, p. 42.

IDA. INTERCHANGE OF DATA BETWEEN ADMINISTRATIONS. IDA. European

Interoperability Framework: for Pan-European Egovernment Services. [S.l.], 2004. Disponível em:
<http://xml.coverpages.org/IDA-EIF-Final10.pdf>. Acesso em: 9 set. 2016.

ISO 13606. The CEN/ISO EN13606 standard. [S.l.]: [s.n.], 2015.

ISO 13606-1:2008 - Health informatics -- Electronic health record communication -- Part 1:

Reference model. ISO, [S.l.], [s.d.]. Disponível em:
<http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=40784>. Acesso
em: 27 ago. 2016.

ISO 13606-2:2008 - Health informatics -- Electronic health record communication -- Part 2:

Archetype interchange specification. ISO, [S.l.], [s.d.]. Disponível em:
<http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=50119>. Acesso
em: 27 ago. 2016.

ISO 18308. ISO 18308:2011 - Health informatics -- Requirements for an electronic health record
architecture. ISO, [S.l.], 2011. Disponível em:
<http://www.iso.org/iso/catalogue_detail?csnumber=52823>. Acesso em: 9 set. 2016.

ISO 19439:2006 - Enterprise integration -- Framework for enterprise modelling. ISO, [S.l.], [s.d.].
Disponível em: <http://www.iso.org/iso/catalogue_detail.htm?csnumber=33833>. Acesso em: 26 jul.
2016.

ISO/TR 20514:2005 - Health informatics -- Electronic health record -- Definition, scope and context.
ISO, [S.l.], 2005. Disponível em:
<http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39525>.
Acesso em: 9 set. 2016.

JÚNIOR, H. F. De A. Mapeando Objetos para Bancos de Dados Relacionais: técnicas e

implementações. Semestre de, 2006.

KALRA, D. Clinical foundations and information architecture for the implementation of a

federated health record service. [S.l.]: University of London, 2003.

______. Electronic health record standards. 2006.

KALRA, D.; BEALE, T.; HEARD, S. The openEHR foundation. Studies in health technology and
informatics, 2005. v. 115, p. 153–173.

KIRKPATRICK, B. et al. Literature review of Florida red tide: implications for human health effects.
Harmful algae, 2004. v. 3, n. 2, p. 99–115.

KUHN, K.; OTHERS. A generic, web-based clinical information system architecture using HL7 CDA:
successful implementation in dermatological routine care. [S.l.]: IOS Press, 2007. p. 439.

KURPANIK, J.; PAŃKOWSKA, M. NOSQL problem literature review. Studia Ekonomiczne, 2015.
v. 234, p. 80–100.
 78

LEE, K. K.-Y.; TANG, W.-C.; CHOI, K.-S. Alternatives to relational database: comparison of NoSQL
and XML approaches for clinical data storage. Computer methods and programs in biomedicine,
2013. v. 110, n. 1, p. 99–109.

LIANAS, L. et al. pyEHR: A scalable clinical data management toolkit for biomedical research
projects. [S.l.]: IEEE, 2014. p. 370–374. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7001871>. Acesso em: 20 jul.
2016.

LÓPEZ-NORES, M. et al. The iCabiNET system: Harnessing Electronic Health Record standards
from domestic and mobile devices to support better medication adherence. Computer Standards
& Interfaces, jan. 2012. v. 34, n. 1, p. 109–116.

MA, C. et al. EHR query language (EQL)-a query language for archetype-based health records.
Medinfo, 2007. v. 129, p. 397–401.

MADAAN, A. et al. Quasi-Relational Query Language Interface for Persistent Standardized EHRs:
Using NoSQL Databases. [S.l.]: Springer, 2013. p. 182–196. Disponível em:
<http://link.springer.com/chapter/10.1007/978-3-642-37134-9_15>. Acesso em: 20 jul. 2016.

MALDONADO et al. Framework for clinical data standardization based on archetypes. Studies in
health technology and informatics, 2007. v. 129, n. 1, p. 454.

MALDONADO; LOPEZ, D.; BLOBEL, B. A development framework for semantically interoperable

health information systems. International Journal of Medical Informatics, fev. 2009. v. 78, n. 2, p.
83–103.

MARCO-RUIZ, L. et al. Archetype-based data warehouse environment to enable the reuse of

electronic health record data. International Journal of Medical Informatics, set. 2015. v. 84, n. 9,
p. 702–714.

MARCOS, M. et al. An archetype-based solution for the interoperability of computerised guidelines

and electronic health records. [S.l.]: Springer, 2011. p. 276–285.

MARTÍNEZ, I. et al. Implementation of an end-to-end standard-based patient monitoring solution.

IET Communications, 2008. v. 2, n. 2, p. 181.

MARTÍNEZ-COSTA, C. et al. A model-driven approach for representing clinical archetypes for

Semantic Web environments. Journal of Biomedical Informatics, fev. 2009. v. 42, n. 1, p. 150–
164.

MARUT, B. The Foundation for Semantic Interoperability on the World Wide Web. [S.l.]:
Submitted in partial fulfillment of the requirement for the degree of Doctor of Philosophy, Department
of Information Science and Telecommunications, School of Information Sciences, University of
Pittsburgh, 2001.

MCDONALD, C. J.; TANG, P. C.; HRIPCSAK, G. Electronic Health Record Systems. Biomedical
Informatics. [S.l.]: Springer, 2014, p. 391–421.

MELLO, R. Dos S. et al. Dados semi-estruturados. XV Simpósio Brasileiro de Banco de Dados,

2000.

MILLER, P. Interoperability: What is it and why should I want it? Ariadne, 2000. n. 24.
 79

MUNOZ, A. et al. Proof-of-concept Design and Development of an EN13606-based Electronic Health

Care Record Service. Journal of the American Medical Informatics Association, 1 jan. 2007. v.
14, n. 1, p. 118–129.

MURTA, L. G. P.; VERONESE, G. O.; WERNER, C. M. L. MOR: Uma Ferramenta para o

Mapeamento Objeto-Relacional em Java. Simpósio Brasileiro de Engenharia de Software
(SBES), Sessão de Ferramentas, 2001. p. 392–397.

NARDON, F. B. Utilizando XML para a representação de informação em saúde. São Paulo, 2000.

NASCIMENTO, N. D. L. D. PERSISTÊNCIA EM BANCO DE DADOS: UM ESTUDO PRÁTICO

SOBRE AS API JPA E JDO. 2005.

OUKSEL, A. M.; SHETH, A. Semantic interoperability in global information systems. ACM Sigmod
Record, 1999. v. 28, n. 1, p. 5–12.

PANETTO, H.; MOLINA, A. Enterprise integration and interoperability in manufacturing systems:

Trends and issues. Computers in industry, 2008. v. 59, n. 7, p. 641–646.

PIHO, G. et al. Towards archetypes-based software development. Innovations in Computing

Sciences and Software Engineering. [S.l.]: Springer, 2010, p. 561–566.

PÖHLSEN, S. et al. A concept for a medical device plug-and-play architecture based on web
services. ACM SIGBED Review, 2009. v. 6, n. 2, p. 6.

POKRAEV, S. V. Model-driven semantic integration of service-oriented applications. 2009.

RIDLEY, D. The literature review: A step-by-step guide for students. [S.l.]: Sage, 2012.

ROCHA, A. D.; KUBOTA, S. O. Persistência no Java EE 5. Java Magazine, [s.d.]. n. 39, p. 29–37.

RODRIGUES, J. et al.Conceptual Framework for eHealth Interoperability, Deliverable 1.1 of

the SemanticHEALTH Project. August 2006. [S.l: s.n., s.d.].

SACHDEVA, S. et al. AQBE &mdash; QBE Style Queries for Archetyped Data. IEICE Transactions
on Information and Systems, 2012. v. E95.D, n. 3, p. 861–871.

SACHDEVA, S.; BHALLA, S. Implementing high-level query language interfaces for archetype-
based electronic health records database. [S.l.]: [s.n.], 2009. p. 235–238.

______. Semantic Interoperability in Healthcare Information for EHR Databases. 2010.

SALAMANCA, A. et al. A flexible OLAP query model for a telemedicine system. [S.l.]: ACM, 2008.
p. 9.

SANTOS, M. R. Dos. Sistema de registro eletrônico de saúde baseado na norma ISO 13606:
aplicações na Secretaria de Estado de Saúde de Minas Gerais. Perspectivas em Ciência da
Informação, 2011. v. 16, n. 3, p. 272–272.

SHENG, Q. Z. et al.Web services composition: A decade’s overview. Information Sciences, out.

2014. v. 280, p. 218–238.

SILVA, J. E. H. AUTOCONHECIMENTO E A TEORIA DOS ARQUÉTIPOS NAS HABILIDADES DE

COMUNICACÃO DE JORNALISTAS. XI Simpósio de Ciências da Comunicação na Região
Sudeste, 2006.
 80

STAN, O.; SAUCIUC, D.; MICLEA, L. Medical informatics system for Romanian healthcare system.
[S.l.]: [s.n.], 2011.

STONEBRAKER, M. et al. The end of an architectural era:(it’s time for a complete rewrite). [S.l.]:
VLDB Endowment, 2007. p. 1150–1160.

STONEBRAKER, M.; CATTELL, R. 10 Rules for Scalable Performance in “Simple Operation”

Datastores. Commun. ACM, jun. 2011. v. 54, n. 6, p. 72–80.

TOTH, R. M. Abordagem NoSQL–uma real alternativa. [S.l.]: Sao Paulo, 2011.

VELTE, LINDA; PEDROSA, TIAGO; COSTA, CARLOS. AN OPENEHR REPOSITORY BASED ON

A NATIVE XML DATABASE: [S.l.]: SciTePress - Science and and Technology Publications, 2012.
p. 386–389. Disponível em:
<http://www.scitepress.org/DigitalLibrary/Link.aspx?doi=10.5220/0003784003860389>. Acesso
em: 21 jul. 2016.

VERNADAT, F. Enterprise modeling and integration. [S.l.]: Boom Koninklijke Uitgevers, 1996.

VIEIRA-MARQUES, P. et al.OpenEHR aware multi agent system for inter-institutional health data
integration. [S.l.]: IEEE, 2014. p. 1–6. Disponível em:
<http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6876864>. Acesso em: 20 jul. 2016.

WANG, L. et al. Archetype relational mapping - a practical openEHR persistence solution. BMC
Medical Informatics and Decision Making, dez. 2015. v. 15, n. 1. Disponível em:
<http://www.biomedcentral.com/1472-6947/15/88>. Acesso em: 20 jul. 2016.

Welcome to ApacheTM Hadoop®! [S.l.], [s.d.]. Disponível em:

<http://webcache.googleusercontent.com/search?q=cache:ZTXkQkt47_QJ:hadoop.apache.org/+&
cd=4&hl=pt-BR&ct=clnk&gl=br>. Acesso em: 21 jul. 2016.

Estudos Incluídos na Revisão

[01] A. Bahga and V. K. Madisetti, “A Cloud-based Approach for Interoperable Electronic Health
Records (EHRs),” IEEE Journal of Biomedical and Health Informatics, vol. 17, no. 5, pp.
894–906, Sep. 2013.

[02] L. Lianas, F. Frexia, G. Delussu, P. Anedda, and G. Zanetti, “pyEHR: A scalable clinical
data management toolkit for biomedical research projects,” 2014, pp. 370–374.

[03] C. C. Barca, C. M. Lagunar, J. M. Rodríguez, A. M. Quintero, I. R. M. Martins, I. Martínez,

M. A. Sanguino, and T. P. Lobo, “yourEHRM: Standard-based management of your
personal healthcare information,” in IEEE-EMBS International Conference on Biomedical
and Health Informatics (BHI), 2014, pp. 89–92.

[04] P. Vieira-Marques, J. Patriarca-Almeida, S. Frade, G. Bacelar-Silva, S. Robles, and R.

Cruz-Correia, “OpenEHR aware multi agent system for inter-institutional health data
integration,” in 2014 9th Iberian Conference on Information Systems and Technologies
(CISTI), 2014, pp. 1–6.

[05] O. Stan, D. Sauciuc, and L. Miclea, “Medical informatics system for Romanian healthcare
system,” in 2011 E-Health and Bioengineering Conference (EHB), 2011.
 81

[06] A. Munoz, R. Somolinos, M. Pascual, J. A. Fragua, M. A. Gonzalez, J. L. Monteagudo, and

C. H. Salvador, “Proof-of-concept Design and Development of an EN13606-based
Electronic Health Care Record Service,” Journal of the American Medical Informatics
Association, vol. 14, no. 1, pp. 118–129, Jan. 2007.

[07] K. Atalag, H. Y. Yang, E. Tempero, and J. R. Warren, “Evaluation of software maintainability

with openEHR – a comparison of architectures,” International Journal of Medical
Informatics, vol. 83, no. 11, pp. 849–859, Nov. 2014.

[08] M. López-Nores, Y. Blanco-Fernández, J. J. Pazos-Arias, and J. García-Duque, “The

iCabiNET system: Harnessing Electronic Health Record standards from domestic and
mobile devices to support better medication adherence,” Computer Standards & Interfaces,
vol. 34, no. 1, pp. 109–116, Jan. 2012.

[09] I. Martínez, J. Fernández, M. Galarraga, L. Serrano, P. de Toledo, S. Jiménez-Fernández,

S. Led, M. Martínez-Espronceda, and J. García, “Implementation of an end-to-end
standard-based patient monitoring solution,” IET Communications, vol. 2, no. 2, p. 181,
2008.

[10] E. Sundvall, M. Nyström, D. Karlsson, M. Eneling, R. Chen, and H. akan Örman, “Applying
representational state transfer (REST) architecture to archetype-based electronic health
record systems,” BMC medical informatics and decision making, vol. 13, no. 1, p. 1, 2013.

[11] B. Blobel and others, “Standardized and flexible health data management with an archetype
driven EHR system (EHRflex),” in Seamless Care, Safe Care: The Challenges of
Interoperability and Patient Safety in Health Care: Proceedings of the EFMI Special Topic
Conference, June 2-4, 2010, Reykjavik, Iceland, 2010, vol. 155, p. 212.

[12] D. A. Orellana, A. A. Salas, P. F. Solarz, L. M. Ruiz, and V. I. Rotger, “Evaluation of a

Framework to Implement Electronic Health Record Systems Based on the openEHR
Standard,” Journal of Physics: Conference Series, vol. 705, p. 12046, Apr. 2016.

[13] P. P. Gutiérrez, “Towards the Implementation of an openEHR-based Open Source EHR

Platform (a vision paper),” in MEDINFO 2015: EHealth-enabled Health: Proceedings of the
15th World Congress on Health and Biomedical Informatics, 2015, vol. 216, p. 45.

[14] Velte, Linda, Pedrosa, Tiago, and Costa, Carlos, “AN OPENEHR REPOSITORY BASED
ON A NATIVE XML DATABASE:,” 2012, pp. 386–389.

[15] L. Wang, L. Min, R. Wang, X. Lu, and H. Duan, “Archetype relational mapping - a practical
openEHR persistence solution,” BMC Medical Informatics and Decision Making, vol. 15, no.
1, Dec. 2015.

[16] A. Madaan, W. Chu, Y. Daigo, and S. Bhalla, “Quasi-Relational Query Language Interface
for Persistent Standardized EHRs: Using NoSQL Databases,” in International Workshop on
Databases in Networked Information Systems, 2013, pp. 182–196.

[17] L. Marco-Ruiz, D. Moner, J. A. Maldonado, N. Kolstrup, and J. G. Bellika, “Archetype-based

data warehouse environment to enable the reuse of electronic health record data,”
International Journal of Medical Informatics, vol. 84, no. 9, pp. 702–714, Sep. 2015.

[18] S. M. Freire, E. Sundvall, D. Karlsson, and P. Lambrix, “Performance of XML Databases for
Epidemiological Queries in Archetype-Based EHRs,” in Scandinavian Conference on
Health Informatics 2012; October 2-3; Linköping; Sverige, 2012, pp. 51–57.
 82

[19] T. Austin, Y. Lim, D. Nguyen, and D. Kalra, “Design of an electronic healthcare record server
based on part 1 of ISO EN 13606,” Journal of Healthcare Engineering, vol. 2, no. 2, pp.
143–160, 2011.

[20] T. Austin, S. Sun, Y. S. Lim, D. Nguyen, N. Lea, A. Tapuria, and D. Kalra, “An electronic
healthcare record server implemented in PostgreSQL,” Journal of healthcare engineering,
vol. 6, no. 3, pp. 325–344, 2015.

[21] S. M. Freire, D. Teodoro, F. Wei-Kleiner, E. Sundvall, D. Karlsson, and P. Lambrix,

“Comparing the Performance of NoSQL Approaches for Managing Archetype-Based
Electronic Health Record Data,” PLOS ONE, vol. 11, no. 3, p. e0150069, Mar. 2016.
 83

APÊNDICE A – CORPO DE ENVIADO A EMPRESAS/ INSTITUIÇOES

Dear Software Developer,

My name is Elvis Nascimento da Silva, and I am a researcher at the Graduate Program in Computational
Modeling Systems at Federal University of Tocantins UFT, located in the Amazon region, in Brazil.
I am conducting a research for my Master's thesis which aims to identify the architectures, models and
mechanisms of persistence in the Electronic Registration Health Care Systems based on openEHR or ISO
13606.
We identified through the literature that your company has been working with openEHR
or ISO13606 specification for the following product:

• Product name

We appreciate if you could please provide us with more information about your product, such as the following
questions/information:

1. What is the Project / Product Name?

2. What is the Year of Development?
3. Which Programming Languages are used?
4. The storage / data processing is performed in a Centralized or Distributed way? Or both?
5. Is there a Web Server? Which one?
6. Which database is it used?
7. Do you use a framework for software development? If yes, which one?
8. Does it use a Cloud Environment?
9. Which is the Web Services Technology (REST, SOAP?) used? Or another (RMI, CORBA, etc.)?
10. What are the security mechanisms used?;
11. What is the Reference Model used?
12. What standards are used?
13. Is there a License to use? Which one?
14. What is the Size of the Database (GB)?
15. Which Query Language (SQL, SQL, Query, SQL + XPath) is used?
16. What is the number of Patient Records?
17.Is the demographic information storage use a demographic reference model?
18. What is the Persistence Solution ?
19. Is there a performance evaluation? Which one?;
20. Is there a Mobile Platform?
21. Any other important information?
22. Is there any academic publications?

Responsible for this information:

We thank you for taking the time to send us this information.

Kind regards,

Elvis Nascimento da Silva

Graduate Program in Computational Modeling Systems at Federal University of Tocantins UFT, Brazil.
skype: elvispert@hotmail.com
phone number: +556381231907