Persistência de dados clínicos baseados no openEHR: uma

U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
B EATRIZ P ROTO M ARTINS
Persistência de dados clínicos baseados
no openEHR: uma abordagem
orientada por recursos limitados
Goiânia
2016
B EATRIZ P ROTO M ARTINS
Persistência de dados clínicos baseados
no openEHR: uma abordagem
orientada por recursos limitados
Dissertação apresentada ao Programa de Pós–Graduação do
Instituto de Informática da Universidade Federal de Goiás,
como requisito parcial para obtenção do título de Mestre em
Ciência da Computação.
Área de concentração: Ciência da Computação.
Orientador: Prof. Plínio de Sá Leitão Júnior
Co-Orientador: Prof. Fábio Nogueira de Lucena
Goiânia
2016
Ficha de identificação da obra elaborada pelo autor, através do
Programa de Geração Automática do Sistema de Bibliotecas da UFG.
Proto Martins, Beatriz
Persistência de dados clínicos baseados no openEHR: uma
abordagem orientada por recursos limitados [manuscrito] / Beatriz
Proto Martins. - 2016.
CVI, 106 f.: il.
Orientador: Prof. Dr. Plínio de Sá Leitão Júnior; co-orientador Dr.
Fábio Nogueira de Lucena.
Dissertação (Mestrado) - Universidade Federal de Goiás, Instituto
de Informática (INF), Programa de Pós-Graduação em Ciência da
Computação, Goiânia, 2016.
Bibliografia. Apêndice.
Inclui lista de figuras, lista de tabelas.
1. Armazenamento e Recuperação de Informação. 2. Registro
Eletrônico de Saúde. 3. Sistemas de Informação em Saúde. 4.
Modelagem Multinível. I. de Sá Leitão Júnior, Plínio, orient. II. Título.
CDU 004
Todos os direitos reservados. É proibida a reprodução total ou parcial do
trabalho sem autorização da universidade, do autor e do orientador(a).
Beatriz Proto Martins
Graduou–se em Ciência da Computação pela UFG - Universidade Federal de
Goiás. Durante sua graduação foi estagiária em Suporte Técnico, monitora
de Banco de Dados e publicou vários artigos na área de Teste de Software.
Atualmente é Desenvolvedora de Software com foco na geração de relatórios
baseados em consultas SQL.
Agradecimentos
Ao meu orientador, Plínio, e meu co-orientador, Fábio, por toda dedicação e
suporte.
À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pela
bolsa de estudos concedida.
Resumo
Martins, Beatriz Proto. Persistência de dados clínicos baseados no openEHR:
uma abordagem orientada por recursos limitados. Goiânia, 2016. 106p.
Dissertação de Mestrado. Instituto de Informática, Universidade Federal de
Goiás.
Motivação: Registros Eletrônicos em Saúde contém dados clínicos e estão presentes
em Sistemas de Informação em Saúde. Neste cenário, a especificação do openEHR
define a estrutura dos registros para permitir que os sistemas sejam interoperáveis, isto
é, tenham um entendimento comum sobre os dados trocados. Os registros compreendem
dados modelados conforme conceitos de domínio em saúde, chamados arquétipos (nível
de conhecimento). Um arquétipo, por sua vez, é composto por um subconjunto de
entidades fixas do Modelo de Referência (nível de informação). Devido ao detalhamento
necessário, a estrutura definida pode ser altamente granular. Deste modo, a persistência
dos registros com o mesmo formato empregado durante a troca pode ser prejudicada em
termos de desempenho, principalmente em dispositivos com considerável limitação de
recursos. Método: Este trabalho apresenta uma estratégia que serve de referência para
o armazenamento e recuperação de dados clínicos baseados no openEHR. Tendo em
vista a limitação de recursos, serviços em saúde podem persistir seus registros em um
formato otimizado em relação ao formato empregado para troca. Para isso, cada serviço
deve aplicar uma estratégia de empacotamento e desempacotamento de dados que efetue a
conversão entre ambos os formatos. Resultados: A estratégia de persistência apresentada
emprega regras de mapeamento entre o grafo de objetos do Modelo de Referência e um
vetor de dados serializados. As regras englobam desde tipos de dados primitivos, como
um inteiro, até tipos complexos, como um hashmap composto por objetos de tipos e
tamanhos variáveis. Conclusões: A estratégia foi projetada considerando a redução de
espaço ocupado em memória, mas sem inviabilizar o tempo de processamento. Estudos
devem ser realizados com a implementação e experimentação da estratégia.
Palavras–chave
Armazenamento e Recuperação de Informação, Registro Eletrônico de Saúde,
Sistemas de Informação em Saúde, Modelagem Multinível
Abstract
Martins, Beatriz Proto. Persistence of clinical data based on openEHR: an approach oriented by limited resources. Goiânia, 2016. 106p. MSc. Dissertation.
Instituto de Informática, Universidade Federal de Goiás.
Motivation: Electronic Health Records contain clinical data and are found in Health
Information Systems. In this scenario, openEHR specification defines the record structure
to allow systems to be interoperable, that is, to have a common understanding over
exchanged data. A record comprises data modeled according to health domain concepts,
called archetypes (knowledge level). An archetype, in turn, is composed by a subset of
fixed entities from the Reference Model (information level). Due to the required detailing,
the defined structure can be highly granular. Thus, the persistence of records, with the
same format used during data exchange, can be hampered in terms of performance,
especially in devices with a considerable resource limitation. Method: This work presents
a strategy that serves as reference for the storage and retrieval of clinical data based on
openEHR. Considering resources limitation, health services can persist their records in
an optimized format, different from the format used for exchange. In this way, each
service must implement a strategy for packing and unpacking that makes the conversions
between both formats. Results: The persistence strategy presented in this work employs
mapping rules between the objects graph of the Reference Model and a serialized data
array. The rules range from primitive data types, such as an integer, to complex types,
such as a hashmap consisting of objects with variable types and sizes. Conclusions: The
strategy was designed considering the reduction of memory space occupied, but without
turning the processing time unfeasible. Studies should be carried out for the strategy
implementation and its experimentation.
Keywords
Information Storage and Retrieval, Electronic Health Records, Health Information Systems, Multilevel Modeling
Sumário
Lista de Figuras
11
Lista de Tabelas
12
Lista de Algoritmos
14
1
15
15
16
17
17
18
Introdução
1.1
1.2
1.3
1.4
1.5
2
Fundamentação teórica
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3
Contexto
Problema
Justificativa
Objetivos
Organização do trabalho
RESs e a abordagem multinível
Padrões internacionais
Contexto brasileiro
Plataforma openEHR
Limitação de recursos
Serialização e desserialização de dados
Considerações Finais
Revisão Bibliográfica
3.1
3.2
3.3
3.4
Formulação da questão
3.1.1
Problema
3.1.2
Questões
3.1.3
Intervenção, palavras-chave e sinônimos
3.1.4
Outros tópicos
Seleção de fontes
Seleção de estudos
3.3.1
Critérios de seleção
3.3.2
Procedimentos para seleção de estudos
3.3.3
Seleção de estudos iniciais
Extração de informação
3.4.1
Definição de critérios para inclusão de informação
3.4.2
Formulários de extração de dados
3.4.3
Extração de resultados em tabelas
3.4.4
Critério CI-1 (requisitos)
3.4.5
Critério CI-2 (mapeamento)
19
19
21
22
22
24
26
27
28
28
28
28
29
29
30
31
31
31
32
33
33
33
37
38
38
3.5
3.6
3.7
4
4.2
4.3
4.4
3.4.8
Critério CI-5 (avaliação)
Sumarização dos resultados
3.5.1
Cálculos estatísticos
3.5.2
Análise sensitiva
3.5.3
Plotagem
Respostas às questões de pesquisa
Considerações Finais
Visão Geral
4.1.1
Requisitos para a persistência de dados
4.1.2
Estratégia de persistência
Especificação da estratégia
4.2.1
Formato da estrutura de persistência
4.2.2
Estrutura geral para a codificação de um registro clínico
4.2.3
Mapeamento das classes do MR
Regras de mapeamento das estruturas de dados
4.3.1
Identificadores de tipo de classe
4.3.2
Separação entre atributos de tamanho fixo e variável
4.3.3
Área de metadados
4.3.4
Codificação da cardinalidade de coleções e Strings
4.3.5
Concatenação de atributos
Considerações finais
Algoritmos de persistência
5.1
5.2
5.3
5.4
5.5
5.6
6
Critério CI-3 (implementações)
Critério CI-4 (benchmarks)
Mapeamento de Dados Clínicos para Persistência
4.1
5
3.4.6
3.4.7
Funções auxiliares
Serialização de dados
Desserialização de dados
Desempenho dos algoritmos de persistência
Estratégia de persistência exemplificada
Considerações finais
Conclusão
6.1
6.2
Comparação com trabalhos correlatos
Trabalhos futuros
43
44
48
48
48
49
50
50
51
52
52
52
53
54
54
54
55
56
56
57
58
58
59
59
61
61
62
67
70
72
73
75
75
77
Referências Bibliográficas
78
A
Artigos incluídos
84
B
Mapeamento das classes do MR
87
Lista de Figuras
2.1
Exemplo de modelo multinível em que as camadas de nível mais baixo
podem ser utilizadas por camadas de nível superior.
Meta-arquitetura de arquétipos[8]
Parte do pacote de tipos de dados do MR (restrito a quantidades)[45].
Estrutura de um RES[28].
Formato BSON para serialização de dados[41].
20
23
24
25
26
Quantidades de estudos que abordam cada critério de inclusão na segunda fase de seleção de um total de 22 estudos (considerando interseções).
50
4.1
Classes do MR mapeadas para o esquema de dados desenvolvido.
56
5.1
Exemplo de execução do algoritmo de serialização, com uma raiz composta por uma String de tamanho 2.
Pacote rm.data_types.text versão 1.0.3[45].
Exemplo da estratégia de persistência aplicada ao pacote data_types.text
do MR com a raiz e um objeto que a compõe.
Exemplo da estratégia de persistência aplicada sobre um objeto composto
por atributos de tamanho fixo e variável.
2.2
2.3
2.4
2.5
3.1
5.2
5.3
5.4
65
72
73
74
Lista de Tabelas
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
4.1
String de busca aplicada nas fontes bibliográficas.
String de busca aplicada na fonte Google Scholar.
Critérios para inclusão de estudos.
Critérios para exclusão de estudos.
Resultados da primeira fase de seleção de estudos.
Resultados da primeira fase de seleção de estudos da fonte Google Scholar
Formulário para extração de informações estruturadas relacionadas à persistência de dados no desenvolvimento de sistemas em saúde multiníveis
(CI-1).
Formulário para extração de informações estruturadas relacionadas ao
mapeamento de modelos conceituais em saúde multiníveis para modelos
de dados lógicos ou físicos (CI-2).
Formulário para extração de informações estruturadas relacionadas à
descrição da camada ou serviço de persistência de dados em SISs com
modelagem multinível (CI-3).
Formulário para extração de informações estruturadas relacionadas à
descrição de benchmarks para SISs com modelagem multinível (CI-4).
Formulário para extração de informações estruturadas relacionadas à
avaliação da camada ou serviço de persistência de dados presentes em
SISs com modelagem multinível (CI-5).
Exemplos de preenchimento do formulário da primeira fase de seleção.
Estudos que apresentam requisitos diretamente relacionados à persistência de dados para o desenvolvimento de sistemas em saúde multiníveis
(CI-1).
Estudos que descrevem o mapeamento de modelos conceituais em saúde
multiníveis para modelos de dados lógicos ou físicos (CI-2).
Estudos que descrevem a camada ou serviço de persistência de dados
em SISs com modelagem multinível (CI-3).
Estudos que descrevem benchmarks para SISs com modelagem multinível (CI-4).
Estudos que avaliam a camada ou serviço de persistência de dados
presentes em SISs com modelagem multinível (CI-5).
Quantidades de estudos por CI/CE na segunda fase de seleção de estudos.
Quantidade de estudos por CI/CE na segunda fase de seleção da fonte
Google Scholar
Exemplo de codificação de trecho do vetor: tipo p do objeto, um booleano
b e uma lista L com t elementos.
30
31
31
31
32
33
34
35
35
36
36
37
39
40
41
45
46
49
49
57
4.2
Exemplo de codificação de trecho do vetor: tipo p do objeto, cardinalidade
n da lista L, tipo t de cada elemento da lista, um inteiro i e uma lista L com
n elementos.
4.3
Codificação de tamanho de atributos de tamanho variável.
58
59
6.1
Adição da contribuição do trabalho atual à Tabela 3.14.
76
A.1
Artigos incluídos na revisão sistemática
84
B.1
Planilha com o mapeamento das classes do MR
87
Lista de Algoritmos
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
serializaObjeto(o)
grupo(p)
serializaPrimitivo(a)
vetorTamanho(t)
serializaColecao(C)
desserializaObjeto(V, j)
desserializaPrimitivo(V, j, p)
recuperaTamanho(V, j)
desserializaColecao(V, j, p)
62
63
64
65
66
67
68
69
70
CAPÍTULO 1
Introdução
Na Seção 1.1 é descrito o contexto deste trabalho relativo aos sistemas e registros
em saúde, cujos dados são modelados conforme o openEHR. Em seguida, na Seção 1.2
é relatado o problema desta pesquisa, o qual se baseia na complexidade existente para
se armazenar e recuperar dados. Na Seção 1.3 são apresentadas as justificativas para se
desenvolver uma estratégia de persistência otimizada, relacionando-a com as estratégias
de trabalhos correlatos. Por fim, na Seção 1.4 são citados os objetivos com respeito á
estratégia de persistência.
1.1
Contexto
A cada mês cerca de mil serviços em saúde são cadastrados no Ministério da
Saúde do Brasil (em junho de 2015 haviam 275 mil cadastros, já em novembro de 2016
foram registrados 297 mil serviços) [13]. Cada estabelecimento pode possuir um Sistema
de Informação em Saúde (SIS) diferente e armazenar uma grande quantidade de Registros
Eletrônicos em Saúde (RESs) contendo dados de pacientes. Durante o mês de setembro
de 2016, por exemplo, foram registrados cerca de 860 mil procedimentos hospitalares de
internação [53] no Sistema Único de Saúde (SUS).
Geralmente, os conceitos de domínio em saúde são codificados diretamente nos
modelos de bancos de dados, isso faz com que haja uma alta complexidade para que
os sistemas sejam alterados e estendidos. Percebe-se, também, uma dificuldade notável
em definir um vasto número de entidades e em possibilitar a interoperabilidade entre os
sistemas em saúde [7].
Para proporcionar interoperabilidade aos sistemas e, consequentemente, permitir
a troca de RESs entre diferentes SISs, ou mesmo para possibilitar a extração de informação, é preciso conhecer a sintaxe e a semântica dos dados armazenados. Isto pode ser
alcançado através da padronização da definição dos dados. Deste modo a temperatura
corpórea de um paciente, por exemplo, pode ser facilmente identificada em meio a um
conjunto de dados, por qualquer outro SIS que conheça o padrão empregado.
1.2 Problema
16
Através da norma CEN/ISO EN13606:2008, o Comitê Europeu recomenda
meios para que seja alcançada a interoperabilidade semântica na comunicação de sistemas
em saúde. Isso deve ser feito através de uma arquitetura de informação estável e rigorosa
e um repositório de dados centralizado. A CEN/ISO EN13606 descreve uma arquitetura
de Modelo Dual para registros clínicos que separa o conhecimento clínico da informação
que o representa. Esta arquitetura favorece a interoperabilidade de SISs e a redução da
complexidade para alterar e estender tais sistemas[19].
A plataforma openEHR é mundialmente conhecida e abordada em diversas
pesquisas, tais como em Freire et al. (2016)[24], Wang et al. (2015)[55], Sundvall et
al. (2013)[52] e Muirhead (2009)[42]. O openEHR é responsável por fornecer uma ampla
especificação [26] que orienta a definição de RESs, além de inspirar a definição da norma
CEN/ISO EN13606:2008. Esta especificação inclui a modelagem multinível dos dados,
mais especificamente a modelagem de dois níveis, onde há a separação entre informação
e conhecimento, conforme ressaltado.
Nesta abordagem dual, os dados são modelados conforme entidades que representam o conhecimento, chamadas “arquétipos”. Os arquétipos são definidos a partir dos
conceitos presentes no MR, o qual compreende um conjunto de entidades genéricas de
informação[8]. Assim, o valor da temperatura corpórea, dada como exemplo, é representado pela estrutura de dados correspondente ao arquétipo de temperatura, presente na base
de arquétipos de referência. O arquétipo de temperatura, por sua vez, pode abranger um
tipo de dado de quantidade do MR para acomodar o valor da temperatura.
1.2
Problema
A persistência dos dados (armazenamento e recuperação) modelados conforme o
openEHR é realizada a partir do mapeamento da estrutura utilizada para troca. Entretanto,
o mapeamento objeto-relacional é altamente granular e pode gerar prejuízos para o
desempenho da persistência. A interoperabilidade, por outro lado, não requer que os
sistemas utilizem o mesmo formato de definição para realizar a persistência dos dados.
Portanto, cada sistema pode ter uma estratégia diferente para realizar o armazenamento e
recuperação de dados.
O problema pertinente a esta pesquisa está focado no aspecto crítico das operações de sistemas em saúde, em que a persistência de dados é um dos elementos de
impacto. Assim, é necessário explorar uma estratégia de persistência que considere critérios de eficiência e eficácia e sirva de referência para a implementação de sistemas em
saúde baseados no openEHR.
1.3 Justificativa
1.3
17
Justificativa
Para que os sistemas sejam interoperáveis, é preciso que haja uma padronização
na comunicação e na definição dos RESs. Por isso, a maioria dos trabalhos relacionados
ao tema abordam os aspectos semânticos dos dados clínicos, tais como integração de
arquétipos com mapeamento de terminologias[18][47] e troca de mensagens estruturadas
[39][31].
Por outro lado, a persistência de dados impacta diretamente no desempenho das
funcionalidades do SIS que requisitam acesso aos RESs. A complexidade da persistência
de dados modelados conforme o openEHR é influenciada pelas classes do MR e por suas
associações, similar a qualquer sistema orientado a objetos. Assim, os principais desafios
centram-se em realizar o mapeamento objeto-relacional e, ao mesmo tempo, assegurar
que o desempenho, dentre outros requisitos não funcionais, seja satisfeito. Além disso,
deve-se reduzir o longo tempo de acesso ao disco, causado pela granularidade elevada do
modelo[5].
Apesar de não haver uma implementação de referência para a persistência em si,
o openEHR recomenda o uso da estratégia Node+Path[6] para a realização da persistência
de dados. Nesta estratégia é armazenado o caminho de cada objeto binário grande (blob) e
o respectivo conteúdo do nó em uma tabela de duas colunas. Contudo, o custo de memória,
a velocidade de parsing e comparação de cada caminho pode ocasionar um gargalo na
recuperação dos dados, já que são armazenados todos os caminhos dos objetos.
Algumas soluções exploram o desenvolvimento da camada de persistência com
critérios de desempenho[29][54][35], mas não consideram as especificidades do openEHR para projetar uma camada de persistência otimizada. Já Wang et al. (2015)[55]
realiza o mapeamento objeto-relacional de arquétipos, todavia essa solução requer que
os arquétipos sejam previamente conhecidos. Outros estudos realizam o mapeamento de
classes do MR para tabelas de bancos de dados com o uso, por exemplo, da ferramenta
Hibernate[21][12][50], sem a orientação para critérios de desempenho.
1.4
Objetivos
Ao longo desta dissertação, espera-se alcançar os seguintes objetivos gerais e
específicos, relacionados ao projeto, desenvolvimento e avaliação de uma camada de
persistência para sistemas baseados na modelagem multinível:
1. Definir formatos de estruturas para persistência de dados baseados nas especificações do openEHR.
1.1. Detalhar a especificação sintática utilizada na formatação dos dados;
1.5 Organização do trabalho
18
1.2. Definir regras de mapeamento de tipos de dados básicos e complexos
baseados no MR para um modelo lógico de persistência.
2. Desenvolver uma estratégia de persistência para ser empregada como referência por
camadas de persistência.
2.1. Definir um esquema de dados de referência, baseado na especificação do
openEHR e orientado pela limitação de espaço em memória;
2.2. Descrever algoritmos para a serialização e desserialização de dados que
empregue o esquema proposto.
1.5
Organização do trabalho
O restante deste trabalho está organizado do seguinte modo: no Capítulo 2 é
dada a fundamentação teórica relativa aos registros em saúde baseados no openEHR e às
motivações deste trabalho sobre a atual limitação de recursos e a persistência de dados.
Em sequência, no Capítulo 3 é realizada a revisão sistemática do estado da arte referente
à persistência de dados modelados conforme o openEHR.
No Capítulo 4, são exploradas as regras de mapeamento do modelo de objetos
para o modelo lógico, de acordo com o objetivo 1. Já no Capítulo 5 é abordada a
prova de conceito das regras de mapeamento através do desenvolvimento da estratégia
de serialização e desserialização, conforme o objetivo 2. Por último, no Capítulo 6 são
dadas as conclusões sobre os objetivos alcançados e expectativas de trabalhos futuros.
CAPÍTULO 2
Fundamentação teórica
Neste capítulo é apresentada, na Seção 2.1, a abordagem multinível empregada
pelo openEHR na modelagem de dados clínicos e sua relação com normas internacionais,
na Seção 2.2, e nacionais, na Seção 2.3. A plataforma openEHR é abordada na Seção 2.4.
Já na Seção 2.5 é feita uma investigação sobre a limitação de infraestruturas físicas. Por
fim, na Seção 2.6 são explorados alguns mecanismos para persistência que empregam a
serialização de dados. A revisão sobre a persistência aplicada a dados clínicos baseados
no openEHR será abordada no Capítulo 3.
2.1
RESs e a abordagem multinível
Os Registros Eletrônicos em Saúde (ou RESs) são responsáveis por armazenar
dados clínicos de pacientes. Conforme o relatório da IOM[17], um sistema RES (S-RES)
é definido como um conjunto de componentes que possibilita que registros de pacientes
sejam criados, usados, armazenados e recuperados. O sistema é localizado num ambiente
que inclui pessoas, dados, regras e procedimentos, dispositivos de armazenamento e de
processamento e meios de suporte e de comunicação.
Normalmente os dados de um paciente são espalhados por vários RESs. Porém,
é crucial o compartilhamento de RESs de forma segura, isto é, com uma comunicação
que respeite a privacidade de cada paciente. Além disso, o compartilhamento deve ser
significativo, isto é, os sistemas devem ter um entendimento comum do conteúdo trocado
(interoperabilidade semântica) [38].
Em muitos SISs, os conceitos de domínio são codificados diretamente nos
modelos de bancos de dados (BD)[7]. O conhecimento clínico pode definir, por exemplo,
um conceito relacionado a temperatura corpórea com um único valor em graus Celsius.
Um desenvolvedor pode, então, determinar que esse valor seja armazenado em uma
coluna de uma tabela no BD em um intervalo de poucas dezenas de unidades. Caso o
usuário requisite, posteriormente, que a temperatura seja armazenada em graus Kelvin
(valores em centenas de unidades) pode ser necessário alterar o esquema da tabela, o tipo
2.1 RESs e a abordagem multinível
20
Figura 2.1: Exemplo de modelo multinível em que as camadas de
nível mais baixo podem ser utilizadas por camadas de
nível superior.
do dado e as tabelas que o referenciam. Além disso, a interoperabilidade é limitada aos
sistemas que seguem esse mesmo modelo de dados [43].
Uma solução para os problemas anteriores é fazer a separação das diferentes visões sobre os dados dos SISs. A abordagem de dois níveis (multinível) propõe a separação
entre informação e conhecimento[7]. Assim, torna-se possível, por exemplo, alterar um
conceito de domínio relacionado a temperatura corpórea sem requerer alterações no esquema do BD e dos dados dos pacientes no nível de informação. Isso também possibilita
que um conceito único e bem definido de temperatura corpórea possa ser compartilhado
entre vários sistemas em saúde.
Um exemplo de um modelo multinível com 6 camadas é ilustrado na Figura
2.1. A camada do Modelo de Informação, no nível mais baixo, contém elementos com o
mínimo de semântica que podem ser mapeados para um banco de dados. O Modelo de
Arquétipos abrange os conceitos clínicos e pode ser agregado para formar um Modelo de
Template[25].
A partir de arquétipos e templates, no Modelo de Consultas, são definidas consultas mapeadas para serviços de recuperação. Com base em arquétipos e consultas, podem ser definidas regras para gerar relatórios. Já no Modelo de Mensagem, a informação é estruturada e pode ser mapeada em formatos de troca, como no caso do HL7 e
da ISO/EN13606. No Modelo de Interface do Usuário, na última camada, são definidas
diretrizes de como a informação é organizada e apresentada[25].
2.2 Padrões internacionais
2.2
21
Padrões internacionais
Por ser um tema com relevância internacional, a ISO/TC 2151 estabelece um
Comitê Técnico de informática em saúde que trabalha na padronização da Tecnologia de
Comunicação e Informação em Saúde para possibilitar a compatibilidade e interoperabilidade entre sistemas independentes. A padronização facilita a troca e uso de dados, de
informação e de conhecimento de modo consistente e coerente. O comitê trata de assuntos relacionados aos RES através de grupos de trabalho que abordam desde estruturas de
dados até requisitos de negócios. As definições e diretrizes do comitê são publicadas por
meio de padrões ISO.
Para a definição, delimitação de escopo e apresentação de contexto do RES,
foi elaborada a ISO/TR 20514[30]. Conforme essa ISO, um RES é um “repositório de
informação relacionado ao status de saúde de um sujeito sob cuidados, em formulário
processável computacionalmente”. No caso de RES para cuidado integrado, o formulário
deve ser armazenado e transmitido de forma segura e acessível para múltiplos usuários.
O modelo de informação deve ser predefinido e independente dos sistemas. Já a ISO
18308 estabelece os requisitos arquiteturais de um RES para garantir sua validade e
confiabilidade, dando suporte a boas práticas clínicas. A arquitetura é vista como um
conjunto de componentes estruturais genéricos definidos de acordo com um modelo de
informação e sobre a qual constroem-se os RESs.
Outra ISO de grande importância do Comitê Técnico 215 é a ISO EN13606
[19] elaborada, originalmente, pelo Comitê Europeu, com o objetivo de alcançar a
interoperabilidade semântica na comunicação de RES. Para isso, recomenda-se o uso de
uma arquitetura de informação estável e rigorosa e um repositório de dados centralizado.
O padrão propõe uma arquitetura de Modelo Dual com a informação estruturada em um
Modelo de Referência (MR), contendo as entidades básicas para representar qualquer
informação de um RES, e o conhecimento baseado em arquétipos. De modo mais preciso,
os arquétipos são definições formais de conceitos clínicos com significado semântico na
forma de combinações de entidades do MR[8].
A interoperabilidade pode ser definida como a propriedade de sistemas e organizações serem capazes de cooperar. Na interoperabilidade sintática os sistemas têm a
possibilidade de se comunicar e trocar dados. Para isso são especificados, por exemplo,
formatos de dados e protocolos de comunicação utilizando padrões como o XML ou SQL.
Já na interoperabilidade semântica a informação trocada é automaticamente interpretada
utilizando um modelo de referência comum e as requisições não são ambíguas [19]. Neste
sentido, a plataforma ResearchEHR é um exemplo de tecnologia que provê acesso e in1 International Organization for Standardization / Technical Comitee 215. Disponível em:
<http://www.iso.org/iso/iso_technical_committee?commid=54960>
2.3 Contexto brasileiro
22
tegração de dados, normalização de estruturas existentes e modelagem semântica através
de arquétipos [38].
A ISO especifica, ainda, o Modelo de Arquétipos, construído através de uma
combinação de entidades do MR. O MR, por sua vez, é um modelo orientado a objetos
que representa a informação para a construção de RES, especificando estruturas de dados
e informações de contexto. Ele é composto por[19][7]:
• um conjunto de tipos primitivos;
• seis tipos de entidades principais: folder, composition, section, entry, cluster e
element;
• classes auxiliares e, opcionalmente;
• classes de descrição de dados demográficos e de comunicação.
2.3
Contexto brasileiro
Com a publicação da Portaria no 2073 de 2011[16], passa a ser regulamentado,
no Brasil, o uso de padrões de interoperabilidade e de informação em saúde entre os
sistemas privados, de saúde suplementar e de informação do SUS. Para a definição da
estrutura do RES, a portaria exige o uso do Modelo de Referência do openEHR. Já para a
interoperabilidade de modelos de conhecimento, incluindo arquétipos, a portaria define o
uso do padrão ISO 13606-2.
Adicionalmente, a Portaria GM no 589 institui a Política Nacional de Informação
e Informática em Saúde (PNIIS)[15]. A PNIIS apresenta princípios e diretrizes para
nortear uma organização institucional a fim de melhorar o acesso e qualidade do SUS,
a transparência e segurança de informação e o suporte para tomada de decisão. São
recomendadas estratégias como o desenvolvimento de sistemas interoperáveis e o uso
de RESs.
O Ministério da Saúde apresenta, também, um documento propondo uma visão
de e-Saúde vigente até 2020 e descreve mecanismos para executar o Plano Nacional de
Saúde e do SUS. Um de seus pilares são os Padrões e Interoperabilidade, para os quais
são apresentadas nove ações estratégicas e resultados esperados. Nesse sentido, é dada
suma importância à implantação de sistemas RES[14].
2.4
Plataforma openEHR
A organização openEHR foi a responsável pela criação da abordagem de dois
níveis, normatizada pela ISO EN13606, e por aplicar estas teorias em uma plataforma
homônima. Nesta abordagem os dados são modelados em conformidade a um conjunto de
2.4 Plataforma openEHR
23
Figura 2.2: Meta-arquitetura de arquétipos[8]
conceitos pré-estabelecidos, os quais são formados por entidades padronizadas. Estes conceitos são os chamados arquétipos e definem o segundo nível do modelo multinível[7]. Os
arquétipos são expressados por meio da linguagem ADL (Archetype Definition Language)
e recuperados a partir de consultas escritas em AQL (Archetype Query Language)[8].
Já o conjunto de entidades básicas que constitui cada arquétipo é o já citado Modelo de Referência e retrata o primeiro nível da abordagem multinível. O MR segue o
método orientado a objetos e, portanto, representa um conjunto de classes com relacionamentos. Os arquétipos, por sua vez, combinam elementos do MR para refletir conceitos
com conteúdo semântico. Assim, dados modelados conforme um arquétipo compreendem
instâncias de entidades do MR.
A Figura 2.2 mostra a meta-arquitetura do openEHR[8] e a separação entre as
atividades desempenhadas pelo usuário e pelo especialista do domínio. O especialista cria
um arquétipo com a linguagem ADL ao aplicar restrições no MR. O usuário, por sua vez,
cria uma informação em conformidade semântica ao arquétipo. Consequentemente, essas
informações são mantidas por instâncias de classes do MR.
O MR é dividido em pacotes reusáveis de baixo nível que fornecem identificadores, tipos de dados e estruturas de dados para pacotes de domínio em alto nível, como o
pacote de integração[8]. Um exemplo de parte de um pacote de baixo nível é mostrado na
Figura 2.3. Os dados clínicos são armazenados em instâncias das classes folhas como, por
exemplo, em DV_QUANTITY e DV_TIME. Para cada classe folha há uma determinada
classe raiz conhecida que, quando instanciada, gera um grafo de objetos. São exemplos
de raízes as classes ELEMENT, OBSERVATION e SECTION.
O RES, por sua vez, segue a estrutura representada na Figura 2.4, cujos objetos
são instâncias de classes do pacote EHR, englobado pelo MR do openEHR. Uma lista
2.5 Limitação de recursos
24
Figura 2.3: Parte do pacote de tipos de dados do MR (restrito a
quantidades)[45].
de contribuições (do tipo CONTRIBUTION) referencia um conjunto de versões de um
mesmo RES. O objeto EHR contém o identificador do RES (do tipo HIER_OBJECT_ID)
e referências (do tipo OBJECT_REF) para os demais objetos presentes na Figura. Estes
objetos são versionados e contém informações de acesso (classe EHR_ACESS do MR),
status e controle (EHR_STATUS), além de um diretório (DIRECTORY) de pastas (FOLDERs) para organizar as composições (COMPOSITIONs) que contém todo o conteúdo
clínico e administrativo do RES[28].
2.5
Limitação de recursos
Durante as últimas décadas do século passado, houve um aumento, aparentemente exponencial, da capacidade de processamento e de memória em computadores
pessoais, mainframes e em estações de trabalho. Por este motivo, os projetos de software
não mais se orientavam pela limitação de recursos computacionais[44].
Entretanto, no início deste século, houveram indícios do surgimento de um
mercado iminente constituído por centenas de milhões de dispositivos móveis. Tais
dispositivos são limitados pelo tamanho físico e armazenamento de energia, o que implica
2.5 Limitação de recursos
25
Figura 2.4: Estrutura de um RES[28].
em memória limitada[44]. Em 2014, haviam cerca de 7,22 bilhões de celulares ativos,
ultrapassando a quantidade de seres humanos e com uma taxa de crescimento cinco vezes
maior do que o crescimento populacional[10].
Além de dispositivos móveis, servidores Web e de banco de dados requerem
capacidade de processamento e espaço suficiente para atender milhares de usuários
simultâneos em suas aplicações. A capacidade de memória gera dificuldades, até mesmo,
em computadores tradicionais, devido às demandas de multimídia, principalmente de
vídeo[44].
Soluções relacionadas ao armazenamento de dados clínicos normalmente utilizam índices altamente otimizados. Por isso, as maiores preocupações se voltam para o
tempo de inserção e espaço de armazenamento do que para o tempo de consulta[42].
Freire et al. (2016) utiliza a base de dados brasileira do Sistema de Informação
do Câncer do Colo do Útero. Esta base contém registros de mais de 1,6 milhões de
pacientes[24]. Além disso, a quantidade de informações de cada paciente pode requerer
um espaço de alguns gigabytes de memória. Logo, uma alternativa é realizar a compressão
dos dados[51].
Neste contexto, a estratégia de persistência de dados baseados no openEHR deve
ser orientada pela limitação de recursos, uma vez que um SIS pode conter milhares de
RESs de pacientes. Tais registros, podem conter, além de texto, conteúdos de multimídia
e podem ser acessados através de aplicações tradicionais, Web ou através de aplicativos
móveis.
2.6 Serialização e desserialização de dados
26
Figura 2.5: Formato BSON para serialização de dados[41].
2.6
Serialização e desserialização de dados
A camada de persistência de um sistema é responsável por fornecer uma interface
abstrata com funcionalidades para armazenar e recuperar objetos através de chaves
específicas, consultar instâncias de um determinado tipo, gerenciar sessões e transações. A
diferença entre a persistência de dados modelados conforme o openEHR e a dos demais
dados, é que no primeiro caso a modelagem se baseia no MR, um conjunto de classes
menor e mais genérico do que outros modelos[8] e que, para tanto, pode ser otimizado
pelo uso de estratégias específicas.
A persistência de um grafo de objetos pode ser realizada através da serialização
e desserialização dos dados. Durante a serialização, é feita a decomposição de estruturas
complexas em uma sequência de partes primitivas, o estado e o modelo do objeto são
armazenados de modo a permitir o acesso serial. Na desserialização é feito o caminho
inverso com a recriação do objeto a partir da leitura do estado e do esquema[9]. No caso
de dados baseados no openEHR, a serialização é aplicada sobre um grafo de objetos do
MR. O estado de um objeto é composto pelos dados clínicos propriamente ditos, já o
modelo do objeto faz referência às estruturas especificadas das classes do MR.
A serialização dos dados segue um formato predefinido, os padrões XML,
JSON e BSON (JSON binário) são alguns exemplos de formatos de armazenamento
de documentos. Diferentemente dos outros formatos, o BSON é uma representação
binária de um documento JSON, formado por pares atributo-valor de tipos básicos que
constituem objetos complexos. Conforme a Figura 2.5[41], o BSON contém informações
que facilitam o parsing dos dados de entrada, como, por exemplo, prefixos de tamanho,
de tipo e delimitadores. As operações de recuperação e armazenamento da camada de
persistência devem estar de acordo com o formato do objeto BSON [57].
2.7 Considerações Finais
27
Outro exemplo de mecanismo para serialização de dados é o framework Protocol
Buffers. Este mecanismo gera um código-fonte que permite a escrita e leitura de dados
estruturados de/para diversos tipos de streams de dados. Assim como o BSON, também
são utilizados pares nome-valor. Comparado ao XML, por exemplo, o Protocol Buffers é
mais simples, menor, dezenas de vezes mais rápido e gera menos ambiguidade [49]. Isto
ocorre devido ao fato do framework otimizar a persistência no nível de bytes por meio da
codificação.
Por fim, o framework FlatBuffers é um buffer binário para a persistência de objetos aninhados, como, por exemplo, vetores e tabelas. Para percorrer o buffer, são armazenados tamanhos de deslocamentos que funcionam como ponteiros. Ao contrário dos
outros formatos, o FlatBuffers direciona-se para dispositivos móveis com restrição de memória e em aplicações, como jogos, que exigem um alto desempenho de processamento
[20].
2.7
Considerações Finais
A estratégia de persistência desenvolvida neste trabalho realiza o mapeamento do
grafo de objetos do MR para um vetor binário. Para generalizar a explicação, é afirmado
que o grafo de objetos possui uma raiz de tipo indefinido e que, a partir de sua indicação,
todo o restante da estrutura passa a ser conhecida. Contudo, a persistência do RES deve
conter, obrigatoriamente os objetos ilustrados na Figura 2.4.
A estratégia deve considerar, principalmente, a limitação de recursos computacionais de memória, discutida na Seção 2.5. A estrutura de dados para persistência deve ser
baseada nos formatos apresentados na Seção 2.6.
CAPÍTULO 3
Revisão Bibliográfica
Este capítulo detalha a revisão sistemática relacionada à persistência de dados
clínicos modelados com base no openEHR, conforme o protocolo definido em Mian et al.
(2005)[40]. A revisão contribui para o aprofundamento do estado da arte e descobrimento
de lacunas presentes no tema abordado.
A Seção 3.1 apresenta a contextualização do tema e a elaboração de questões
para serem respondidas no final desta revisão. As bases bibliográficas são selecionadas
na Seção 3.2 juntamente com a String de busca. Os estudos selecionados das bases, com
seus respectivos critérios de seleção, são apresentados na Seção 3.3. Já a Seção 3.4 relata a
extração de informações relevantes dos estudos em formulários (não estruturados), tabelas
(estruturadas) e agrupadas por critério de inclusão. A sumarização dos resultados em
estatísticas é feita na Seção 3.5. Por fim, a Seção 3.6 relata as respostas para as questões
de pesquisa.
3.1
3.1.1
Formulação da questão
Problema
Para que um RES modelado conforme as especificações do openEHR seja
armazenado e recuperado, é necessário persistir instâncias do MR. Neste sentido, são
demandadas estratégias específicas que atendam aos requisitos de qualidade para se
persistir um grande volume de dados e metadados. Consequentemente, um problema
decorrente do uso desta abordagem é encontrar estratégias, modelos e estruturas de dados
que abranjam a persistência de RESs.
3.1.2
Questões
A revisão sistemática deve responder às questões principal e secundárias:
• Questão principal: Que estratégias de persistência de dados têm sido empregadas
em sistemas de informação em saúde baseados na modelagem multinível?
3.1 Formulação da questão
29
• Questão secundária 1: Que critérios de avaliação têm sido empregados na persistência de dados em sistemas de informação em saúde baseados na modelagem multinível?
• Questão secundária 2: Que benchmarks (compostos por, por exemplo, arquétipos,
dados clínicos reais com modelagem multinível, consultas e seus resultados, etc.)
têm sido empregados na avaliação de sistemas de informação em saúde baseados
na modelagem multinível?
3.1.3
Intervenção, palavras-chave e sinônimos
Nesta revisão deve ser observado o detalhamento dos trabalhos em relação à
persistência dos dados clínicos. A busca pelos estudos de interesse deve englobar as
seguintes palavras-chave, com seus respectivos sinônimos:
• Persistência, armazenamento e recuperação;
• Registro eletrônico em saúde, registro eletrônico médico, registro eletrônico do
paciente;
• Modelagem, metodologia ou abordagem multinível;
• Modelo de dois níveis, modelo dual;
• MR, modelo de informação;
• Arquétipo, conceitos clínicos;
• Modelo de dados lógico ou físico, esquema de banco de dados;
• openEHR.
3.1.4
Outros tópicos
Quanto ao efeito causado pela revisão, espera-se encontrar estudos com estratégias de persistência de dados que exponham detalhes acerca das estruturas de dados e dos
benchmarks utilizados. Também espera-se encontrar estratégias de serialização dos dados
para o armazenamento das informações ou transferência entre diferentes sistemas.
Para medir o efeito, contabiliza-se em uma tabela inicial e em uma tabela final
a quantidade de estudos abrangendo cada critério de inclusão e de exclusão. Durante as
buscas dos estudos, a string deve ser formulada de modo a permitir a recuperação dos
artigos de controle, são eles: Wang et al. (2015)[55], Freire et al. (2016)[24], Sundvall et
al. (2013)[52], Frade et al. (2013)[22], Velte et al. (2012)[54].
A população em análise desta revisão são os dados clínicos baseados no openEHR. Este estudo pode ser aplicado no desenvolvimento de sistemas da área de informática médica devido à apresentação de alternativas que consideram a perspectiva da
persistência de dados clínicos.
3.2 Seleção de fontes
30
Tabela 3.1: String de busca aplicada nas fontes bibliográficas.
((storage OR persistence OR “database model” OR “database
schema”) AND (openEHR OR 13606) OR (electronic PRE/0 (health OR
medical OR patient) PRE/0 record)) AND NOT (owl)
3.2
Seleção de fontes
As fontes bibliográficas escolhidas são bases científicas da área de Ciência da
Computação, na Língua Inglesa e Portuguesa, disponibilizadas pelo portal da CAPES1 .
A string de busca aplicada na seleção de estudos das fontes cobrem artigos científicos e
monografias de 2006 a 2016.
A string avançada de busca possui variações sintáticas por fonte, mas, basicamente, com o mesmo significado semântico da string representada na Tabela 3.1. Esta
expressão abrange a persistência de RES modelados conforme o openEHR. Estudos focados nos aspectos semânticos dos dados, como no caso do desenvolvimento de sistemas
pervasivos e de suporte à decisão, devem ser excluídos, portanto supõe-se que referências à tecnologias, como no caso da linguagem OWL, são feitas apenas em estudos que
aprofundam tópicos da Inteligência Artificial.
Na seleção das fontes considera-se o uso comum na àrea de informática médica.
As fontes selecionadas são as seguintes:
•
•
•
•
•
•
IEEE Xplore2 ;
SpringerLink3 ;
ScienceDirect4 ;
PMC PubMed Central5 ;
PubMed6 ;
Scopus7 .
Adicionalmente, esta revisão considera a fonte Google Scholar8 . Por ser uma
base que indexa um grande volume de trabalhos (em grande parte sem caráter científico),
aplica-se uma string de busca mais restrita sobre esta fonte, conforme a Tabela 3.2.
Esta string restringe a revisão ao padrão do openEHR e é mais excludente em trabalhos
relacionados à semântica dos dados.
1 Disponível
em: <http://www.periodicos.capes.gov.br/>
em: http://ieeexplore.ieee.org/
3 Disponível em: http://link.springer.com/
4 Disponível em: http://www.sciencedirect.com/
5 Disponível em: http://www.ncbi.nlm.nih.gov/pmc/
6 Disponível em: http://www.ncbi.nlm.nih.gov/pubmed/
7 Disponível em: https://www.scopus.com/
8 Disponível em: http://scholar.google.com/
2 Disponível
3.3 Seleção de estudos
31
Tabela 3.2: String de busca aplicada na fonte Google Scholar.
(((storage OR persistence OR “database model” OR “database schema”) openehr)
ehr) -“owl” -“data mining” -“multi agent” -vocabularies -“knowledge management”
Tabela 3.3: Critérios para inclusão de estudos.
CI-1 Estudos que apresentam requisitos diretamente relacionados à persistência de
dados, para o desenvolvimento de sistemas em saúde baseados no openEHR.
CI-2 Estudos que descrevem o mapeamento de modelos conceituais em saúde
baseados no openEHR para modelos de dados lógicos ou físicos.
CI-3 Estudos que descrevem a camada ou serviço de persistência de dados em
SISs baseados no openEHR.
CI-4 Estudos que descrevem benchmarks para SISs baseados no openEHR.
CI-5 Estudos que avaliam a camada ou serviço de persistência de dados presentes
em SISs baseados no openEHR.
Tabela 3.4: Critérios para exclusão de estudos.
CE-1
CE-2
CE-3
CE-4
CE-5
3.3
Estudos que não exploram as questões de pesquisa e, consequentemente, não
são cobertos pelos critérios de inclusão.
Duplicações de estudos, isto é, estudos recuperados de outras fontes nesta
revisão.
Estudos com contribuições totalmente abrangidas por outras publicações,
recuperadas nesta revisão.
Estudos inacessíveis ou não disponíveis integralmente.
Estudos que fogem do escopo com respeito ao seu propósito.
Seleção de estudos
A revisão bibliográfica engloba todos os tipos de estudos científicos, tais como
qualitativos, quantitativos e de caracterização.
3.3.1
Critérios de seleção
Os critérios de inclusão dos estudos são apresentados na Tabela 3.3 e os critérios
de exclusão na Tabela 3.4
3.3.2
Procedimentos para seleção de estudos
Os artigos devem ser importados para a ferramenta Mendeley9 , onde são criadas
pastas para cada um dos critérios de inclusão e exclusão. Na primeira fase de seleção são
lidos o título, resumo e palavras-chave de cada trabalho. Os artigos são copiados para as
pastas correspondentes aos seus critérios de inclusão ou exclusão. Nos casos de resumos
9 Disponível
em: https://www.mendeley.com/
3.3 Seleção de estudos
32
Tabela 3.5: Resultados da primeira fase de seleção de estudos.
IEEE PMC
CI-1
0
2
CI-2
1
1
CI-3
8
3
CI-4
0
0
CI-5
1
1
Incluídos
10
7
CE-1
40
96
CE-2
0
0
CE-3
0
0
CE-4
0
0
CE-5
1
0
Excluídos
41
96
Total de
51
103
estudos
PubMed ScienceDirect Scopus
0
0
0
2
1
3
6
3
6
1
0
0
0
1
0
9
5
9
76
140
301
5
4
28
0
0
2
0
0
4
3
2
6
84
146
341
93
151
350
Springer TOTAL
1
3
1
9
1
27
0
1
2
5
5
45
80
733
6
43
0
2
0
4
1
13
87
795
92
840
superficiais ou inconsistentes ou nos casos de trabalhos sem resumos, as palavras-chave da
string de busca são pesquisadas no corpo do texto e são lidas as frases onde se encontram
a fim de classificar o artigo de acordo com suas reais contribuições para esta pesquisa.
Em virtude de não haver uma seção específica nos trabalhos científicos para
identificar os critérios de exclusão, principalmente no caso do critério “CE-5”, os artigos
incluídos passam por uma segunda fase de seleção. Esta fase de exclusão é simultânea à
fase de extração de dados, já que um critério de exclusão é atendido se, e somente se, não
houverem dados relevantes para extração.
3.3.3
Seleção de estudos iniciais
As quantidades de estudos classificados por critério de inclusão e exclusão (com
base na leitura dos resumos) são apresentadas na Tabela 3.5, com exceção dos estudos
da fonte Google Scholar, mostradas na Tabela 3.6. Para evitar interseções nos cálculos,
ambas as tabelas classificam um determinado estudo de acordo com seu critério primário,
isto é, o tópico de maior abrangência do estudo. Assim um estudo se enquadra primariamente em apenas um critério, apesar de poder abordar outros critérios secundariamente.
Subtraindo-se as repetições recuperadas de estudos, foram lidos 1042 resumos
durante a primeira fase de seleção. No total houve uma taxa de inclusão de aproximadamente 5,3%. Deste valor, cerca de 65% corresponde a estudos que tratam primariamente
do critério CI-3. Por outro lado, dentre os estudos excluídos, mais de 86% se enquadra no
critério CE-1.
3.4 Extração de informação
33
Tabela 3.6: Resultados da primeira fase de seleção de estudos da
fonte Google Scholar
CI
CI-1
0
CE CE-1
228
CI-2
2
CE-2
90
CI-3
13
CE-3
0
CI-4
0
CE-4
0
CI-5
2
CE-5
0
Incluídos
17
Excluídos
318
Total de estudos 335
3.4
Extração de informação
3.4.1
Definição de critérios para inclusão de informação
As informações dos estudos devem ser extraídas caso abordem os seguintes
pontos:
•
•
•
•
•
•
3.4.2
Definição de requisitos para a execução da persistência;
Descrição em alto nível do modelo de dados mapeado;
Técnica de persistência aplicada;
Métricas de avaliação da persistência;
Resultados da avaliação de diferentes técnicas ou modelos de persistência;
Descrição do benchmark utilizado na avaliação do sistema.
Formulários de extração de dados
Durante a segunda fase de seleção de estudos deve-se preencher um formulário
para cada artigo incluído na primeira fase com informações de autores, ano, critério de
inclusão ou de exclusão. Paralelamente, deve-se resumir cada estudo com informações
não-estruturadas sobre seu respectivo objetivo e suas contribuições, relacionadas a persistência de dados clínicos multiníveis, ou motivo para exclusão do estudo.
Além disso, devem ser preenchidos formulários com informações estruturadas
(convertidos em tabelas) apontando tópicos específicos abordados pelos estudos pertinentes aos critérios de inclusão. Assim, um estudo é incluído na segunda fase de seleção caso
apresente dados relevantes para extração.
O formulário correspondente à Tabela 3.7 expõe características dos estudos
que fornecem requisitos próprios ao desenvolvimento da camada de persistência em
sistemas multiníveis. A coluna A1 aponta o critério de inclusão primário pelo qual o
estudo foi considerado nesta revisão, portanto valores “CI-1” denotam artigos que tratam
primariamente de requisitos de persistência, já os demais artigos abordam este tópico de
maneira secundária.
3.4 Extração de informação
34
Tabela 3.7: Formulário para extração de informações estruturadas relacionadas à persistência de dados no desenvolvimento de sistemas em saúde multiníveis (CI-1).
CI
(A1)
Requisitos funcionais (A2)
Desempenho
(A3)
Espaço
(A4)
Outros
RNFs (A5)
O projeto dos mecanismos de persistência deve considerar os requisitos funcionais indispensáveis ao sistema. Estes requisitos descrevem as funcionalidades oferecidas
pelos sistemas, que são fortemente ligadas ao armazenamento e recuperação dos dados,
como é o caso do serviço de criação, leitura, atualização e exclusão (CRUD) de dados.
Assim, a coluna A2 da Tabela 3.7 retrata os requisitos funcionais encontrados nos estudos.
O projeto da camada de persistência também deve considerar o comportamento
esperado pelos usuários em relação à execução do serviço de persistência. Neste sentido,
a coluna A3 da Tabela 3.7 apresenta requisitos não-funcionais de desempenho. Estes
requisitos exprimem a eficiência no tempo de resposta para a manipulação de dados, mais
especificamente, para a execução das operações de CRUD.
É importante que no projeto do serviço de persistência dos estudos sejam
consideradas as restrições impostas pelos usuários e pelo sistema sobre o uso de recursos
computacionais. Assim, a coluna A4 da Tabela 3.7 expõe os requisitos não-funcionais de
espaço relacionados à apropriação de memória.
Devido a necessidade de prover sistemas em saúde interoperáveis, o desenvolvimento dos serviços de persistência desses sistemas deve atender a critérios variáveis e
fazer uso de tecnologias heterogêneas. Nesse sentido, os estudos da Tabela 3.7 definem
outros requisitos não-funcionais na coluna A3, como os de adaptabilidade, portabilidade
e compatibilidade.
As propriedades dos estudos que exploram o mapeamento de modelos conceituais para esquemas de dados para persistência são mostradas na Tabela 3.8, de modo que
estudos com o critério de inclusão “CI-2” na coluna B1 abordam este assunto com mais
intensidade.
Na abordagem multínivel, o esquema de dados deve ser gerado de acordo com
o modelo conceitual de informação ou de conhecimento. Por exemplo, em um sistema
baseado no openEHR a camada de persistência pode utilizar um esquema de banco de
dados definido a partir do modelo conceitual do MR ou dos arquétipos. Por isto, a coluna
B2 da Tabela 3.8 aponta o modelo conceitual base do esquema de dados.
Além de definir o modelo conceitual, é preciso escolher o modelo de dados
lógico ou físico, de acordo com o nível de abstração necessário, para a representação do
esquema para persistência de dados. O modelo de dados utilizado pelo estudo selecionado
é citado na coluna B3 da Tabela 3.8.
Uma vez que os modelos de informação e de conhecimento dos sistemas multiní-
3.4 Extração de informação
35
Tabela 3.8: Formulário para extração de informações estruturadas relacionadas ao mapeamento de modelos conceituais em saúde multiníveis para modelos de dados lógicos ou físicos (CI-2).
CI
Modelo
(B1) conceitual
(B2)
Modelo lógico ou físico (B3)
Tipos de
dados
básicos
(B4)
AssociaçãoHerança Coleção Mapeamentos
e agre- (B6)
(B7)
específicos
gação
(B8)
(B5)
Tabela 3.9: Formulário para extração de informações estruturadas relacionadas à descrição da camada ou serviço de
persistência de dados em SISs com modelagem multinível (CI-3).
CI
Nome
BD - Padrão de Definição
(C1) ou quan- SGBD referência de esquema
tidade
(C3)
(C4)
RES (C5)
(C2)
Consulta
RES (C6)
Organização
dos
arquivos
(C7)
veis são representados por grafos de entidades seguindo a abordagem orientada a objetos
(OO), é preciso que essas estruturas de dados e seus relacionamentos sejam mapeados
para o esquema de dados desejado. Assim, a coluna B4 e B7 da Tabela 3.8 relata, respectivamente, as decisões de mapeamento de tipos de dados básicos e de coleções. A
coluna B5 descreve o mapeamento do relacionamento de associação e agregação, já o
relacionamento de herança é descrito na coluna B6. Mapeamentos específicos do modelo
conceitual são definidos na coluna B8.
A Tabela 3.9 realça as propriedades dos serviços de persistência de dados
multiníveis apresentados pelos estudos. A coluna C1 corresponde ao critério de inclusão
do artigo, assim, estudos com o critério “CI-3” abrangem a descrição do serviço de
persistência com mais profundidade. Esta tabela expõe nas respectivas colunas:
• C2: o nome do sistema ou a quantidade de sistemas em análise, em caso de revisão
bibliográfica;
• C3: os tipos de bancos de dados e respectivos Sistemas Gerenciadores de Bancos
de Dados (SGBD) ou interfaces para gerenciamento de dados utilizados;
• C5: os padrões de especificação da modelagem dos dados;
• C6: os mecanismos de definição do esquema de dados;
• C7: os mecanismos de consulta dos dados;
• C8: os formatos de organização dos arquivos no BD (tabela, documento, etc).
A Tabela 3.10 detalha os elementos dos benchmarks utilizados na avaliação da
camada de persistência. Os artigos que melhor descrevem seus benchmarks apresentam
o critério de inclusão “CI-4” no atributo D1. Já a coluna D2 informa o nome/local do
repositório de conceitos (geralmente de arquétipos).
3.4 Extração de informação
36
Tabela 3.10: Formulário para extração de informações estruturadas relacionadas à descrição de benchmarks para
SISs com modelagem multinível (CI-4).
CI
Repositório BDs
(D1) de con- de
ceitos de um
domínio
nível
(D2)
(D3)
BDs com esquemas dependentes do domínio (D4)
BDs com esquemas independentes do
domínio (D5)
Quantidade Quantidade
de RESs de
con(D6)
sultas
(D7)
Tabela 3.11: Formulário para extração de informações estruturadas relacionadas à avaliação da camada ou serviço
de persistência de dados presentes em SISs com modelagem multinível (CI-5).
CI
Tamanho
(E1) das bases
(E2)
Tempo para
consultas de
indivíduos
(E3)
Tempo para
consultas de
populações
(E4)
Tempo
para
armazenamento
ou padrão de uso
(E5)
Análise
dos resultados
(E6)
As bases de dados apresentadas em um mesmo estudo na Tabela 3.10 expressam
as mesmas informações, apesar de suas sintaxes variarem conforme as restrições impostas
pelos seus respectivos BDs. Os BDs utilizados com modelagem de um nível (convencional) são citados em D3. BDs cujos esquemas seguem o modelo do nível de conhecimento
são apresentados em D4 e BDs contendo esquemas conforme o nível de informação em
D5, ambos do modelo multinível. A quantidade de RESs que constituem as bases de dados
é exibida em D6. Já a coluna D7 cita a quantidade de consultas com semânticas diferentes
executadas sobre estas bases.
A Tabela 3.11 descreve as propriedades de estudos que avaliam a camada de
persistência de dados baseados na modelagem multinível. Para isso, o estudo avalia o
serviço de persistência sob a aplicação de diferentes entradas e em diferentes contextos. A
avaliação é tratada primariamente nos estudos com o valor “CI-5” no atributo E1 relativo
ao critério de inclusão.
Mais especificamente, a Tabela 3.11 apresenta os resultados das operações
aplicadas sobre os dados e suas análises. A coluna E2 expõe o tamanho do espaço em
memória ocupado por cada base de dados.
A camada de persistência deve tratar, basicamente, de dois tipos de consultas:
baseada em indivíduo (registro único) e em população (multi-registro). Para uma consulta
baseada em indivíduo deve-se informar o identificador único de um registro. Este é o
caso, por exemplo, da recuperação de dados de um paciente específico. Para uma consulta
baseada em população deve-se informar a condição de seleção dos dados. Este é o
caso, por exemplo, da recuperação dos identificadores de pacientes com uma temperatura
corpórea em uma determinada faixa de valores. Neste sentido, a coluna E3 relata o tempo
3.4 Extração de informação
37
Tabela 3.12: Exemplos de preenchimento do formulário da primeira fase de seleção.
Autores
(ano)
[CI/CE]
Chen e
Klein
(2007)
[12]
[CE-5]
Descrição
Implementa as especificações do openEHR utilizando a linguagem Java.
Para isso, os tipos de dados do openEHR são mapeados para os tipos de
dados nativos da linguagem. Também são implementados os tipos de
dados de alto nível e consultas baseadas em caminho para encontrar
nós folhas em uma grande árvore de objetos. Deste modo sistemas RES
podem se basear completamente nos componentes do MR. Entretanto, o
estudo não fornece mais detalhes a respeito da estratégia de persistência
empregada.
médio de resposta para consultas baseadas em indivíduos e E4 para consultas baseadas
em populações.
A camada de persistência pode ser otimizada após o reconhecimento de padrões
de uso desse serviço. Os padrões podem ser detectados em alto nível, por exemplo, relativos à frequência de consultas feitas pelos usuários, sejam elas baseadas em populações ou
em indivíduos. Por outro lado, os padrões também podem ser detectados em baixo-nível,
por exemplo, considerando a frequência de armazenamento de instâncias de determinadas
classes do MR. Estas estatísticas de frequência de uso de elementos diretamente relacionados ao serviço de persistência e o tempo médio gasto no armazenamento dos dados não
são comumente informados e, portanto, são detalhados na mesma coluna E5 da Tabela
3.11.
Por fim, a coluna E6 da Tabela 3.11 resume as análises feitas pelos estudos
sobre os resultados das avaliações do serviço de persistência com diferentes entradas e/ou
comparado a trabalhos correlatos.
3.4.3
Extração de resultados em tabelas
Com base nos formulários da Subseção 3.4.2 são apresentadas justificativas
para a inclusão ou exclusão de estudos na primeira fase da seleção e a extração de
informações dos estudos incluídos na segunda fase de seleção. A Tabela 3.12 exemplifica
o preenchimento do formulário relativo à primeira fase para um estudo excluído da
revisão. O restante deste formulário, com o resumo de todos os estudos incluídos, são
apresentados no Apêndice A.
Durante a segunda fase de seleção, os estudos são considerados como incluídos caso apresentem informações relevantes para o preenchimento dos formulários da
3.4 Extração de informação
38
Subseção 3.4.2, relativas às informações estruturadas dos critérios de inclusão. Estes formulários são convertidos nas Tabelas 3.13, 3.14, 3.15, 3.16 e 3.17.
Uma desvantagem da Tabela 3.17 é que não é possível fazer comparações
precisas entre os estudos, já que eles não utilizam as mesmas bases de dados. Entretanto,
é possível extrair indícios de comparação sobre seus desempenhos a partir da realização
de inferências e cálculos proporcionais. Estudos posteriores deverão comprovar estas
suposições.
3.4.4
Critério CI-1 (requisitos)
Em relação ao critério CI-1, os estudos recomendam que o modelo de BD escolhido seja flexível, facilitando a adição e remoção de entidades e atributos[55][54][29],
possivelmente livre de esquema[37], e que ofereça suporte a diferentes tecnologias e formatos de armazenamento[52][35]. Além disso, deve-se assegurar o acesso transparente a
múltiplos BDs por meio de drivers[35] ou ao BD único através de abstrações para gerenciar os RESs[54][52][29]. Isso inclui não exigir do usuário conhecimento da estrutura do
BD (usando o mapeamento objeto-relacional[29][37]) e das sintaxes[37] na realização de
consultas, além de não exigir o mapeamento, serialização e validação dos RESs[42].
Os estudos esperam que o sistema seja eficiente no acesso (leitura/escrita) de um
grande volume de RESs[29] e aplicável em um ambiente real[55][52][42]. As operações
devem centrar-se no paciente com consultas mais rápidas do que inserções[54]. Nesse
sentido, a camada de persistência deve permitir a execução de consultas complexas[37].
Isso pode ser alcançado através de caching no servidor e/ou no cliente[52] e através de
índices[52][37] que otimizam a consulta[37].
Além do desempenho, o espaço é outro requisito relevante. O sistema deve
propiciar escalabilidade horizontal e/ou vertical sobre o volume de dados[52][35][42].
A escalabilidade pode ser alcançada através do suporte a múltiplos sistemas de
armazenamento[35] ou pelo uso de sharding[52] (divisão do BD). O uso de índices[37] e
de armazenamento de caching em disco[52] também são úteis.
3.4.5
Critério CI-2 (mapeamento)
Duas estratégias detalham o mapeamento de instâncias do modelo de BD conceitual para o modelo de BD lógico pelo critério CI-2, são elas: mapeamento do HL7
RIM (MR do HL7/CDA) para o modelo relacional com a aplicação do modelo EntidadeAtributo-Valor-Otimizado (OEAV) sobre a classe Observation[48] e mapeamento de
arquétipos para o modelo relacional[55].
As estratégias desenvolvidas evitam a perda de desempenho e de espaço na camada de persistência. No caso dos arquétipos, diferentes versões de um mesmo arquétipo
3.4 Extração de informação
39
Tabela 3.13: Estudos que apresentam requisitos diretamente relacionados à persistência de dados para o desenvolvimento de sistemas em saúde multiníveis (CI-1).
A1
[29] CI-1
A2
-
[54] CI-3
Oferecer
CRUD
RES.
[35] CI-3
Oferecer
CRUD,
(de)serializar
e criar estruturas
de
dados.
Mais rápido que
soluções XML,
Node+Path, EAV
e ORM. Eficiente
em ambiente real.
Permitir inser- Eficiente
para
ção e consulta consultas comde RES.
plexas através do
uso de índices.
[55] CI-4
[37] CI-3
[52] CI-3
[42] CI-5
A3
Eficiente
no
processamento de
grande volume de
RESs.
Em
operações
de centradas
no
paciente, as consultas devem ser
mais rápidas do
que inserções.
A4
Espaço com
suporte
para
uma
quantidade
volumosa de
registros.
-
A5
O modelo de dados deve ser geral,
flexível,
conveniente/transparente (usar
abstrações).
Escolher BD dinâmico.
Gerenciar RES de
modo
transparente
e remoto. Usar web
services para CRUD de
RES (camada de aplicação independente).
Escalável
Assegurar o acesso univertical
e forme e transparente à
horizontalmúltiplos BDs
mente sobre
o volume de
dados
BD deve ser adaptável
às mudanças nos arquétipos e aos requisitos
dos RES.
Altamente
escalável, favorecido pelo
uso de índice.
Adaptação às consultas,
sem exigir do usuário
conhecimento da estrutura do BD e de sintaxes.
Permitir
Alto desempenho Caching
no Flexível dando suporte
CRUD distri- em
ambiente disco.
Es- a diferentes tecnologias
buído de RES real, utilizando calabilidade
e formatos de armaze(sem deleção). índice e caching vertical
ou namento. Sistema RES
no servidor e/ou horizontal
transparente e gerenciácliente.
com uso de vel.
sharding.
Criar
RES; Desempenho
Escalar con- O BD deve ser transpersistir
aceitável
na forme
as parente sem requerer
COMPOprática
sobre necessidades
o mapeamento, serialiSITIONs;
estruturas com- do sistema.
zação e validação dos
recuperar
plexas de objetos.
RESs. O BD deve suconteúdo de
portar aplicações orienarquétipos.
tadas a documentos.
3.4 Extração de informação
40
Tabela 3.14: Estudos que descrevem o mapeamento de modelos
conceituais em saúde multiníveis para modelos de
dados lógicos ou físicos (CI-2).
CI (B1)
Modelo conceitual (B2)
Modelo lógico ou
físico (B3)
Tipos de dados
básicos (B4)
Associação
e
agregação (B5)
Herança (B6)
Coleção (B7)
Mapeamentos específicos (B8)
[48]
CI-2
HL7 RIM
[55]
CI-4
Arquétipos
EAV-Otimizado (OEAV) sobre a Modelo de BD Relacional
classe Observation e relacional
nas demais
Tipos padrões de BD
Coluna de tipo básico SQL
FK em 1:1 e 1:N; Tabela separada em N:N e agregação
Uma tabela por classe (com
identificação) e uma coluna por
atributo.
-
Incorpora coluna em 1:1; Usa
FK em 1:N
Template mapeia os campos do arquétipo especializado para o do generalizado
Tabela com FK para id. do
arquétipo e coluna de tipo básico
Campo AV contém um código Tabela contém as versões
do Atributo concatenado ao Va- nova e antigas do arquétipo
lor
são organizadas em uma única tabela[55]. No caso do HL7 RIM, uma variável AtributoValor de tipo inteiro armazena a representação binária concatenada do atributo e do valor
da classe Observation no modelo OEAV[48].
Os tipos de dados básicos do modelo conceitual, com no máximo uma ocorrência, são mapeados para os tipos padrões de BD[55][48]. A classe DvBoolean com seu
atributo value, por exemplo, é mapeada para uma coluna SQL de tipo INTEGER[55]. A
chave primária em cada tabela relacional corresponde ao item de identificação do arquétipo instanciado ou a um valor gerado[55] (chave substituta). No caso da tabela OEAV, a
chave é baseada na identificação do paciente[48].
O mapeamento de itens de dados em arquétipos sem limites de ocorrências e de
tipos de dados de coleção no HL7 RIM geram tabelas com duas colunas: uma coluna com
uma chave estrangeira (FK) referenciando o arquétipo, ou classe ao qual o item pertence,
e outra coluna com os dados propriamente ditos[55][48]. Para isso é necessário criar uma
tabela para cada atributo do tipo coleção[48].
Associações entre tabelas representando arquétipos ou classes do HL7 RIM,
do tipo um-para-muitos (i.e. atual-para-alvo) são mapeadas como FK na tabela alvo
para a tabela atual[55] ou vice-versa[48]. Em associações um-para-um, a tabela alvo é
concatenada na tabela atual[55] ou utiliza-se uma FK[48]. No relacionamento muitos-
3.4 Extração de informação
41
Tabela 3.15: Estudos que descrevem a camada ou serviço de persistência de dados em SISs com modelagem multinível (CI-3).
C1
[29] CI-1
C2
-
[55] CI-4
-
[1]
CI-3
[21] CI-3
[43] CI-3
[36] CI-3
[34] CI-5
[46] CI-3
[32] CI-3
C3
Relacional
SQL
Server
Relacional
SQL
Server
GastrOS
Relacional
- MS Access
e
SQLite
Relacional
- MySQL
com
InnoDB
Relacional
- Interface
ODBC
iCabiNET
Relacional
- MySQL
XML
nativo Oracle
XML DB
eHealthCom XML BaseX
XML eXistdb
[54] CI-3
-
[52] CI-3
LiU EEE
C4
HL7
modificado
C5
-
C6
.NET
LINQ
openEHR SQL SQL
C7
Tabelas geradas
por uma ferramenta
ORM:
Entity, Role e Act
Tabela denormalizada por arquétipo
Tabela relacional
com MR serializado em XML
openEHR -
-
openEHR modificado
-
Tabela por classe
do MR gerada
pelo Hibernate
EN13606 ADL -
Tabela por classe
do MR
EN13606 ADL -
-
HL7/CDA -
SQL e Documento XML
XQuery por
encontro
em
diretório
hierárquico
openEHR Documento XML
por RES
openEHR ADL Documentos
XML
comXForms eRESs
XML na- openEHR ADL AQL,
Documento XML
tivo - BaXPath/ por paciente
seX
XQuery
XML - openEHR ADL AQL
Documento XML
BaseX,
(XQuery por RES
eXistdb
interno)
3.4 Extração de informação
[24] CI-4
[4]
CI-3
42
-
NoSQL
openEHR Couchbase;
XML BaseX,
eXistdb,
Berkeley
DB XML
yourEHRMNoSQL
openEHR/ ADL AQL
- Mon- EN13606
goDB
[37] CI-3
-
[33] CI-5
-
[3]
CHISTAR Nãorelacional
- HBase
CI-3
[35] CI-3
PyEHR
[22] CI-3
16
[23] CI-3
-
[42] CI-5
-
NoSQL
openEHR ADL AQBE
- MongoDB
NoSQL - HL7/CDA SQL Server
Estende
API
o
ope- Java
nEHR e
o HL7
openEHR ADL
API
Java ou
HQL
Múltiplos
- Multidriver
Relacional, openEHR XML,
OO com
SQL
Server,
MySQL e
outros
Relacional openEHR PostgreSQL
AQL
OO
- openEHR Db4o, Intersystem
Caché
QbE,
Native
Queries e
SODA
Documentos
XML e JSON por
paciente
Documento
JSON com coluna por caminho
de arquétipo
Documento
JSON por arquétipo
Tabela de pares chave-valor
generalizados
com
conceito
individual
por
linha
Tabelas
com
pares chave/valor
conforme tipos
de dados do MR
-
SQL,
AQL,
XQuery,
SQL+XPath
e outros
-
Duas
tabelas,
uma
contendo
XML serializado
do paciente.
Objeto
Caché
Proxy ou Db4o
por RES
3.4 Extração de informação
43
para-muitos cria-se uma nova tabela com FKs para as duas tabelas associadas.
Em relação à herança, o mapeamento fica a cargo de templates que associam os
campos de arquétipos especializados a um subconjunto de campos correspondentes nos
arquétipos generalizados[55]. Para instâncias HL7 RIM, cria-se uma tabela por classe, de
modo a não armazenar atributos herdados[48].
Uma forma de otimizar a persistência é através do uso de índices. Para tanto,
os estudos recomendam o uso de índices nos itens de dados de consulta[55] e de
identificação[55][48], este último relacionado à Entidade OEAV da classe Observation.
Ambas as estratégias[55][48] fazem a conversão dos modelos de BDs com
técnicas de mapeamento amplamente conhecidas na área de Banco de Dados, como no
caso do tratamento de herança e associação de entidades. Isto significa que os estudos
aplicam estratégias comuns, em sua maioria, no cenário específico de dados em saúde.
Além disso, o BD relacional baseado em arquétipos[55] pode ser inflexível, já que exige
que todos os conceitos sejam previamente conhecidos.
3.4.6
Critério CI-3 (implementações)
Com exceção de um artigo de revisão[22], os estudos que descrevem a camada
ou serviço de persistência de dados multinível pelo critério CI-3, abordam um único sistema ou arquitetura. Para tanto, esta revisão relata as tecnologias usadas na persistência e
o formato de organização dos arquivos no BD. Dentre os estudos são descritos os sistemas GastrOS[22][1], iCabiNET[36], eHealthCom[46], LiU EEE[22][52], yourEHRM[4],
CHISTAR[3] e pyEHR[35].
Os estudos utilizam os seguintes BDs e Sistemas Gerenciadores de Bancos de Dados (SGBDs): BDs relacionais com os SGBDs SQL Server[55][22][29],
MS Acess[1], SQLite[22][1], MySQL[22][36][21], PostgreSQL[23] ou fornecem
uma interface ODBC[43]; BDs XML com os SGBDs Oracle XML DB[22][34],
BaseX[24][54][22][52][46], eXistdb[24][22][52][32] e Berkeley DB XML[24]; BDs
NoSQL com os SGBDs CouchBase[24], MondoDB[37][4] e SQL Server[33]; BD nãorelacional com o SGBD HBase[3]; BD orientado a objetos com os SGBDs Db4o e
Intersystem Caché[42] e; BDs múltiplos[35], isto é, diferentes tipos de BDs oferecidos pelo serviço, desde que os sistemas que usem estes BDs implementem a interface
multi-driver fornecida.
Os estudos empregam os seguintes padrões de definição multinível da estrutura
dos dados para persistência: openEHR[24][55][54][22][52][35][37][1][46][4][32][42][23],
EN13606[36][4][43], HL7/CDA[34][33], HL7 modificado[29][3] e openEHR
modificado[3][21]. Com base nestes padrões, os estudos utilizam os seguintes mecanismos para consulta dos esquemas de dados: AQL[54][22][52][35][4], SQL[55][22][34],
3.4 Extração de informação
44
XQuery[22][52][34], .NET LINQ[29], AQBE[37], HQL[3], API Java[3], QbE, Native
Queries e SODA[42].
Os estudos do critério CI-3 geralmente descrevem, de forma sucinta, a estrutura
do modelo de BD utilizado para persistência. Alguns BDs de SISs multiníveis são
formados por tabelas relacionais, em que cada tabela representa um arquétipo[55] ou
uma classe do MR[43][29][21]. Essas tabelas são geradas pelo mapeamento manual[55]
e implementadas com o apoio de ferramentas que auxiliam no mapeamento objetorelacional[29][21], por exemplo, pelo Hibernate[21][11][50][56]. Também é possível
serializar objetos do MR[1] ou o próprio RES[23] de/para o formato XML e persisti-los
em tabelas relacionais.
Na maioria dos casos o BD é composto por documentos XML, seja por
paciente[24][54] ou por RES[52][46][32] ou, ainda, por visita em um diretório
hierárquico[34]. BDs NoSQL são constituídos por tabelas de pares chave-valor
generalizados[33] (contendo conceito por linha) ou por documentos JSON. Estes documentos JSON são gerados por paciente[24] ou por arquétipo, contendo uma coluna
para cada caminho do arquétipo[37][22]. No caso do BD não-relacional, são armazenadas
tabelas com pares chave-valor conforme os tipos de dados do MR[3]. O BD OO pode
persistir um objeto Caché Proxy ou Db4o para cada RES[42].
3.4.7
Critério CI-4 (benchmarks)
Os benchmarks dos estudos do critério CI-4 são formados por bases de
dados conforme o modelo de um nível (convencional), das quais, cinco, no total,
são relacionais[24][55] e uma é estruturada textualmente[33]. Em relação aos dados modelados com a abordagem multinível, os benchmarks são compostos por bases relacionais[24][55][21], XML[24][54][46][33], NoSQL[24][37][33], Node+Path[55],
XML-relacional e OO[42].
Para os BDs baseados na modelagem multinível, foram utilizados os modelos
de conceitos presentes nos repositórios CKM[24][55][37][21][46], NHS[21] e repositórios próprios não divulgados[24][55][33][2][42], incluindo um repositório de SynOD
(Dicionário de Objetos Synapses)[2] e um com conceitos extraídos do BD empregado na
avaliação[33]. Em alguns casos[24][55][37], apenas parte do repositório é importado para
o benchmark.
As bases de dados dos benchmarks são compostas por RESs, com as seguintes quantidades máximas por estudo: 120[21], 2.400[42], 3.226[2], 30 mil[55][54][46],
50 mil[33] e 4,2 milhões[24]. Destes registros apenas um conjunto é sintético[46]
(gerado com base em amostras). Em média, são disponibilizadas 7 consultas por
estudo[24][55][54][37][33]. Apesar de serem fornecidos benchmarks com dados reais, a
3.4 Extração de informação
45
Tabela 3.16: Estudos que descrevem benchmarks para SISs com
modelagem multinível (CI-4).
D1
[54] CI-3
D2
-
D3
-
[21] CI-3
CKM
e
NHS
16 arquétipos
do
CKM e 1
criado.
-
[55] CI-4
[2]
CI-5
[37] CI-3
[46] CI-3
SynOD (Dicionário de
Objetos Synapses)
40 arquétipos
do
CKM
CKM
D4
XML
nativo
-
D7
>4
Relacional
D6
1 mil, 10
mil e 30 mil
120
Relacional Relacional
(Mapeamento
Relacional
de
Arquétipos
- ARM)
-
Node+Path
30 mil
7
-
3.226
-
-
NoSQL
-
-
16
-
-
XML
-
-
NoSQL,
XML não
nativo
e
nativo.
NoSQL,
XML
e
relacional
1 mil, 10
mil e 30 mil
1 mil, 5 mil,
10 mil e 50
mil
10 mil, 42
mil,
100
mil,
424
mil, 1 mi,
4,2 mi
2.400
8
[33] CI-5
Conceitos
extraídos do
BD avaliado
Textual
(formatado)
[24] CI-4
19 arquétipos
do
CKM
ou
criados
4 relaci- onais
[42] CI-5
9 arquétipos
criados
-
-
D5
-
XMLrelacional e
OO
-
5
4
3.4 Extração de informação
46
Tabela 3.17: Estudos que avaliam a camada ou serviço de persistência de dados presentes em SISs com modelagem
multinível (CI-5).
E1
[54] CI-2
E2
-
E3
0,65 ms
E4
Mil: 20 ms;
10 mil: 176
ms; 30 mil:
523 ms
[55] CI-3
Relacional:
1,6
GB;
ARM:
2,9
GB;
Node+Path:
43,87 GB
EAV
=
1,26*OEAV
Relacional:
272
ms;
ARM:
243
ms;
Node+Path:
165.246 ms
EAV
=
15,15*OEAV
Relacional:
6.082 ms;
ARM:
379
ms;
Node+Path:
10.708 ms
EAV
= 56,3*OEAV
[43] CI-3
-
-
-
-
[2]
CI-5
-
-
-
-
[34] CI-5
-
-
10,2 ms
Tempo de
inserção:
15,08 ms
[46] CI-3
-
1 mil: 4 ms;
10 mil: 5
ms; 30 mil:
5 ms
1 mil: 126
ms; 10 mil:
232 ms; 30
mil: 594 ms
[Inserir
RES] 1 mil:
34 ms; 10
mil: 36 ms;
30 mil: 49
ms
[48] CI-4
E5
Tempo de
inserção
aumenta
com o volume, para
30 mil: 423
ms
-
E6
Eficaz para consulta baseada em
indivíduos.
Consulta
agilizada
pelos
índices e caching de dados
em
arquétipos
descendentes
Eficiente
para
buscas,
dados
esparsos e de
alta
dimensão;
Consome menos
espaço que EAV
Não opera em um
cenário real
Dados
seguem
hierarquias; alocação explícita
de memória gera
desperdício
Índices
com
Árvore B e XPath
melhoram consultas baseadas
em
indivíduo
e
população,
respectivamente
Persistência de
RES é eficiente,
ao contrário de
consulta baseada
em
população
e inserção de
Compositions
3.4 Extração de informação
47
[33] CI-5
Textual: 120
MB
-
[24] CI-4
[100
mil]
Relacional:
0,15
GB;
XML: 2,8
GB (BaseX),
7,6
GB
(eXistdb),
8,9
GB
(Berkeley);
NoSQL:
0,48 GB
[100 RES]
OO: 105MB
(Caché),
108MB
(Db4o);
XMLRelacional:
90MB (SQL
Server FI),
102MB
(SQL Server
XML)
-
[42] CI-5
[Recuperar
COMPOSITION
por
UID]
OO:
500
ms (Db4o);
XMLRelacional:
10 ms (SQL
Server FI),
240
ms
(SQL Server
XML)
[50
mil
RESs]
Chavevalor
generalizado: 1.414
ms; XML
não nativo:
4.722 ms;
XML nativo: 8.407
ms
[100 mil]
Relacional:
30
ms;
XML: 13
s
(BaseX), 97 s
(eXistdb),
270 s (Berkeley);
NoSQL: 18
ms
-
-
-
[Inserir
RES] OO:
3 s (Caché),
0,7
s (Db4o);
XMLRelacional:
0,25
s
(SQL Server FI e
SQL Server
XML)
Chave-valor
generalizado
é mais rápida,
mas
tamanho tem
crescimento
exponencial,
já o do XML
é
mínimo.
Ambos
têm
esquema
flexível.
Couchbase
é mais eficiente do que
SGBDs XML
e
MySQL
em consultas
agregadas,
mas requer a
indexação de
cada consulta
Com exceção
das consultas
baseadas em
conteúdo em
que o Caché é
mais rápido, o
SQL Server é
melhor. Já o
desempenho
do Db4o não é
aceitável
3.5 Sumarização dos resultados
48
quantidade de registros é pequena, exceto em um estudo[24], se comparada à de sistemas
reais.
3.4.8
Critério CI-5 (avaliação)
De acordo com os estudos do critério CI-5, o modelo relacional[24][55][42]
é o modelo de BD baseado na abordagem multinível que menos consome espaço,
quando comparado ao Node+Path, ARM (Archetype Relational Mapping) [55], NoSQL,
XML[24] e OO[42]. Consultas baseadas em indivíduos são mais rápidas no BD
Node+Path do que nas soluções relacional e ARM[55]. A solução OO do Intersystem
Caché, comparado ao XML-relacional do SQL Server com Fast Infosets, se sobressai
em consultas baseadas em conteúdo[42]. Por outro lado, não são recomendadas consultas
baseadas em população em BDs XML[24][33].
Consultas baseadas em indivíduos são mais rápidas do que consultas baseadas
em população[55][54][46] e do que inserções de Compositions em RESs[46]. Além
disso, as consultas podem ser agilizadas pelo uso de índices[24][55][34] e caching[55].
A solução chave-valor generalizada é rápida, mas tem um tamanho significativo[33].
Adicionalmente, a alocação de coleções deve ser dinâmica para evitar desperdício de
memória[2]. Com relação à eficiência dos modelos de dados, o OEAV é mais eficiente do
que o EAV[48]. Por outro lado, uma das soluções relacionais apresentadas não consegue
operar em cenário real[43], assim como a solução OO com o SGBD Db40[42].
3.5
3.5.1
Sumarização dos resultados
Cálculos estatísticos
As Tabelas 3.18 e 3.19 mostram as quantidades de estudos classificados por
critério de inclusão e exclusão na segunda fase de seleção. Para todas as fontes, com
exceção da Google Scholar, houve uma redução de cerca de 55% dos estudos incluídos
em relação a primeira fase de seleção. A exclusão dos estudos se deu, principalmente,
pelo fato dos autores relatarem determinadas contribuições nos resumos dos artigos
relacionadas a persistência de dados clínicos baseados na modelagem multinível, mas
ao longo dos trabalhos estes tópicos não são abordados ou o são superficialmente.
Para a fonte Google Scholar, a redução dos artigos incluídos na segunda fase
(conforme a Tabela 3.19) em relação a primeira fase é de cerca de 88%. Isto ocorre porque
a fonte indexa trabalhos de caráter não científico em que não é verificado a comprovação
do que é apresentado no resumo em relação ao que é relatado no restante do texto. Outro
fator é que a fonte indexa teses e dissertações que agrupam vários artigos previamente
abordados por outras fontes.
3.5 Sumarização dos resultados
49
Tabela 3.18: Quantidades de estudos por CI/CE na segunda fase
de seleção de estudos.
IEEE PMC PubMed Science
CI-1
1
0
0
0
CI-2
0
0
0
0
CI-3
5
2
2
1
CI-4
0
1
1
0
CI-5
0
1
0
1
Incluídos
6
4
3
2
CE-1
42
96
78
142
CE-2
0
0
5
4
CE-3
0
0
1
0
CE-4
0
0
0
0
CE-5
3
3
6
3
Excluídos
45
99
90
149
Total
51
103
93
151
Scopus Springer TOTAL
0
0
1
1
0
1
3
0
13
0
0
2
1
0
3
5
0
20
302
82
742
28
6
43
2
0
3
4
0
4
9
4
28
345
92
820
350
92
840
Tabela 3.19: Quantidade de estudos por CI/CE na segunda fase de
seleção da fonte Google Scholar
CI
CI-1
0
CE CE-1
231
CI-2
0
CE-2
76
CI-3
1
CE-3
7
CI-4
0
CE-4
5
CI-5
1
CE-5
14
Incluídos
2
Excluídos
333
Total de estudos 335
Apesar do resultado ruim, a fonte Google Scholar teria um grande número de
artigos incluídos (16 dos 22 estudos incluídos na segunda fase) caso fosse analisada antes
das demais fontes. O mesmo ocorre com a fonte Scopus, na qual seriam indexados 15
dos 22 estudos incluídos na segunda fase. Por outro lado, a fonte SpringerLink seria
responsável por indexar 2 artigos dos 22 estudos.
3.5.2
Análise sensitiva
Com exceção da fonte Google Scholar, a inclusão dos estudos considera a
persistência em sistemas baseados na modelagem multinível, apesar de sistemas baseados
no openEHR serem suficientes, isso dá margem para a busca de trabalhos correlatos que
sejam diferenciados apenas por questões tecnológicas. Além disso, várias strings de busca
foram testadas de modo a abranger diferentes palavras-chave e os artigos de controle.
A robustez da revisão sistemática também pode ser verificada durante a primeira
fase de seleção, principalmente entre os artigos excluídos. Nos casos de dúvidas para
incluir ou excluir um estudo, as palavras-chave foram pesquisadas no corpo do texto para
3.6 Respostas às questões de pesquisa
50
Figura 3.1: Quantidades de estudos que abordam cada critério de
inclusão na segunda fase de seleção de um total de 22
estudos (considerando interseções).
encontrar menções sobre a persistência de dados clínicos modelados com a abordagem
multinível.
3.5.3
Plotagem
Independentemente de fontes de indexação, a segunda fase de seleção resultou
em 22 estudos incluídos. Cada estudo pode abordar um número variado de critérios
de inclusão. Neste sentido, a Figura 3.1 expõe as quantidades de estudos que abordam
cada critério de inclusão de modo primário ou secundário. A maior parte dos estudos
trata de aspectos relacionados à implementação do serviço de persistência, mas apenas
dois[55][48] se aprofundam em questões envolvendo o mapeamento do modelo conceitual
para um esquema de BD.
3.6
Respostas às questões de pesquisa
Os requisitos dos artigos para o desenvolvimento da camada de persistência
centram-se em critérios de flexibilidade e adaptabilidade do modelo de BD e de desempenho na manipulação dos dados. Esses requisitos devem ser atingidos considerando a
redução do tempo de resposta para consultas.
Ambas as estratégias de mapeamento do modelo de BD[55][48] fazem uso de
estratégias amplamente conhecidas na área de Banco de Dados. Isto significa que são
3.7 Considerações Finais
51
aplicadas estratégias comuns, em sua maioria, no cenário específico de dados em saúde.
Além disso, um BD relacional baseado em arquétipos[55] proporciona inflexibilidade, já
que exige que todos os conceitos sejam previamente conhecidos.
Em relação às tecnologias empregadas no desenvolvimento da camada de persistência, percebe-se o uso frequente de dados baseados no openEHR. A persistência dos
dados ocorre nos tradicionais BDs relacionais ou em BDs XML, já que os dados são hierárquicos. Contudo, formatos livres de esquemas podem ser vantajosos na persistência de
dados em saúde. A escolha da organização dos arquivos (por exemplo, por paciente ou por
conceito) depende dos requisitos de cada sistema (por exemplo, requisitos direcionados
para consultas baseadas em indivíduo ou em população).
Apesar de serem fornecidos benchmarks com dados reais, a quantidade de
registros é pequena, exceto em um estudo[24], quando comparada ao volume de dados
presente em sistemas reais.
Em resposta à questão de pesquisa principal, foram encontradas estratégias de
persistência que realizam o mapeamento do MR e do modelo de arquétipos para BDs
amplamente conhecidos. Para isto, utilizam-se técnicas de mapeamento comuns e não
técnicas otimizadas que contemplem as especificidades do modelo multinível.
Em resposta à questão secundária 1, os estudos requerem, geralmente, o uso de
um BD que seja flexível na definição do esquema e eficiente em desempenho e espaço. As
soluções dos estudos mostram-se mais vantajosas para consultas baseadas em indivíduo
do que para qualquer outra operação sobre o BD. Para a questão secundária 2, um dos
benchmarks encontrados apresenta um volume de dados significativamente superior aos
demais. Todavia, os estudos não apresentam o desenvolvimento sistemático e detalhado
dos benchmarks.
3.7
Considerações Finais
Ao longo deste trabalho deve-se desenvolver uma estratégia para persistência de
dados modelados conforme o openEHR que atenda aos requisitos de qualidade (requisitos
não funcionais) identificados pelo critério CI-1, considerando, principalmente, o consumo
de espaço em memória. A estratégia deve considerar as especificidades do modelo
multinível no mapeamento do MR para uma estrutura de dados otimizada em relação
as propostas dos trabalhos do critério CI-2.
CAPÍTULO 4
Mapeamento de Dados Clínicos para
Persistência
Este capítulo especifica a estratégia de persistência de dados clínicos baseados
no openEHR. A Seção 4.1 apresenta uma visão geral da estratégia de acordo com os
requisitos necessários para seu desenvolvimento. Já na Seção 4.2, este trabalho especifica
a estratégia quanto ao seu formato, contendo estruturas mapeadas a partir do MR. As
regras aplicadas durantes este mapeamento são conceituadas na Seção 4.3
4.1
Visão Geral
Conforme o objetivo desta pesquisa, este trabalho deve apresentar uma estratégia
para realizar a persistência de dados clínicos a partir das classes do MR, incluindo
seus tipos de dados básicos e complexos, para estabelecer estruturas que os comportam.
A estratégia proposta potencialmente servirá de referência para o desenvolvimento de
sistemas clínicos, uma vez que contempla as especificidades do MR do openEHR.
A solução apresentada considera a redução do custo de memória, justificada pelo
atual uso intenso de sistemas móveis e embarcados, mas de modo a não inviabilizar o
tempo de resposta do sistema.
4.1.1
Requisitos para a persistência de dados
Conforme os requisitos de qualidade encontrados durante a Revisão Sistemática
do Capítulo 3, o desenvolvimento da camada de persistência de dados baseados no
openEHR deve permitir que o SIS seja escalável horizontal e verticalmente. Neste sentido,
o mapeamento do modelo de dados deve considerar o uso de estruturas otimizadas, ao
contrário das propostas existentes que mapeiam uma classe para cada conceito do MR
[29][42][46].
Idealmente, uma proposta para a persistência de dados clínicos deve promover o
processamento de um grande volume de RESs[29], e ser mais rápida do que as soluções
4.1 Visão Geral
53
encontradas, como XML, Node+Path, EAV e ORM[55]. Na direção destes desafios, este
trabalho prioriza o desenvolvimento de uma estratégia de persistência de dados baseados
no openEHR que considera a limitação de recursos computacionais, especialmente o uso
de memória.
Outros pressupostos são considerados para a estratégia introduzida nesta pesquisa:
• preservação da arquitetura de múltiplos níveis, em que há camadas distintas para o
modelo de conhecimento (domínio da saúde) e o modelo de informação;
• priorização do modelo de informação, tal que as estruturas de persistência sejam
independentes dos conceitos clínicos definidos no modelo de conhecimento;
• promoção da reutilização de estruturas de persistência, as quais são compartilhadas
por qualquer RESs;
• redução do número de classes do MR que serão propriamente persistidas, com
escopo delimitado a classes concretas do MR.
4.1.2
Estratégia de persistência
O armazenamento de dados baseados no openEHR ocorre sobre uma instância
do grafo do MR, cuja estrutura é conhecida pelo SIS. Para se realizar a persistência deste
grafo, deve-se requisitar o armazenamento dos valores que compõem seus objetos. Em
outro momento, a recuperação retorna os valores dos campos dos objetos para uma nova
instanciação do grafo.
Na estratégia proposta, a persistência propriamente dita ocorre sobre as classes
concretas do MR, e para cada uma dessas classes, devem ser implementados métodos
específicos que realizam o armazenamento e a recuperação de dados. Por exemplo, para
que o armazenamento de dados mantidos em uma instância da classe COMPOSITION
seja efetivada, recorre-se ao método que armazena especificamente uma instância de
COMPOSITION, não sendo uma abordagem que considera objetos genéricos.
As classes do MR do openEHR formam uma hierarquia que baseia a persistência
de dados. Assim, para armazenar dados clínicos em conformidades às especificações
do openEHR, é necessário que sejam apontadas as classes concretas que participam
da definição de um registro clínico. Já para realizar a recuperação de uma instância
do grafo, é preciso apontar os tipos das classes que admitem mais de uma alternativa.
Demais classes de tipo não-folha possuem classes descendentes conhecidas a partir da
especificação do próprio MR.
Por exemplo, conforme observado na Figura 2.3, DV_QUANTITY é uma classe
do tipo folha que possui três atributos[45]: magnitude, precision e units. Para se armazenar
dados clínicos baseados nessa classe, é necessário gravar os valores de seus três atributos
4.2 Especificação da estratégia
54
e os valores de atributos de suas classes ancestrais até a raiz, incluindo classes de
associação e agregação, a saber: DV_AMOUNT, DV_QUANTIFIED, DV_ORDERED,
etc, até atingir uma classe raiz, como é o caso de COMPOSITION.
O armazenamento de cada objeto dá-se pelo empilhamento dos valores dos
atributos da classe folha (base da pilha), caminhando pela hierarquia de classes até atingir
a classe raiz (topo da pilha). Ao se atingir a raiz, a representação final dos dados clínicos é
construída pela concatenação de valores a partir do desempilhamento dos dados, de modo
que a recuperação ocorra de forma sequencial no espaço de memória final.
4.2
Especificação da estratégia
A estratégia desenvolvida faz o mapeamento entre objetos do MR e codificações
binárias, através da serialização e desserialização dos dados. Portanto, é necessário
especificar o formato utilizado no armazenamento, a sequência geral de codificação e
sequência específica (com detalhes das classes do MR).
4.2.1
Formato da estrutura de persistência
Para realizar o armazenamento propriamente dito dos dados clínicos baseados na
especificação do MR do openEHR, uma estrutura do tipo vetor é utilizada, tal que possa
conter os valores dos atributos de uma classe do tipo concreta e os valores dos atributos
de suas classes ancestrais. O vetor é codificado por uma sequência de bytes, resultando
em um vetor binário.
A persistência de dados é realizada sobre um grafo de objetos que representa
instâncias de um subconjunto de classes do MR do openEHR. Assim, o vetor gerado é
composto por n vetores, onde cada vetor i se refere à serialização de um objeto do grafo
com uma quantidade reduzida de metadados (quando comparado a trabalhos correlatos
[29][42][46]), isto é, objetos com tamanho reduzido.
O MR contém mais de 150 classes. Para que uma estrutura de dados do tipo vetor
suporte a persistência de dados modelados conforme essas classes, é preciso que seja
realizado o mapeamento de cada uma das mais de 150 classes com seus atributos e seus
relacionamentos para a estrutura desejada. Para isto, deve ser considerado o tratamento
de tipos de dados simples e complexos, como listas de tamanho variável, mídias com
tamanho superior à memória principal e classes recursivas.
4.2.2
Estrutura geral para a codificação de um registro clínico
Para que a codificação do registro clínico através de um vetor de bytes ocorra de
forma determinística, devem ser previamente conhecidos:
4.2 Especificação da estratégia
•
•
•
•
•
55
a hierarquia das classes do MR;
os atributos pertinentes a cada classe definida no MR;
o formato aplicado a cada tipo de dados básico;
os valores dos identificadores das classes concretas; e
o formato adotado para a ocorrência de coleção de dados.
Um registro clínico é codificado conforme a sequência que estrutura o vetor:
1. identificador de classe (concreta);
2. dados de tamanho fixo;
3. dados de tamanho variável, estrutura recursiva composta por:
(a) dados de tamanho fixo;
(b) dados de tamanho variável.
A estrutura recursiva ocorre quando o tipo de um atributo refere-se a uma classe
do modelo de referência, a qual terá seus dados de tamanho fixo e variável. Ou seja, é
estabelecida o aninhamento de classes na definição dos seus tipos de atributos.
Dados de tamanho fixo referem-se a tipos de dados primitivos do openEHR, tais
como Integer, char e Boolean. Dados de tamanho variável são representados por coleções,
tais como List e Hashmap (denotado por Hash pelo openEHR). Uma String é um tipo
primitivo, mas pode ser classificada como uma coleção de caracteres neste contexto.
4.2.3
Mapeamento das classes do MR
O esquema de dados gerado a partir do MR é representado em uma planilha.
Este esquema é exemplificado através da Figura 4.1 e apresentado integralmente no
Apêndice B. Para cada classe do MR são citados: a constante que identifica a classe;
o nome da classe; o tamanho, em bytes, de cada atributo e do total da classe com
base na estratégia de persistência definida; os nomes dos atributos da classe; e, por fim,
observações relacionadas ao tipo do atributo ou classe.
Por exemplo, para a persistência de um objeto do tipo DV_QUANTITY é necessário armazenar os atributos das classes ascendentes, indicado em “dvAmountDvQuantity”. Este atributo utiliza 1 byte para armazenar o tipo da classe e requer um espaço para
armazenar 3 Strings, 3 objetos, uma lista e 11 bytes de tipos primitivos, incluindo o tipo
da classe. Em seguida são armazenados os atributos “precision” e “magnitude” de tipos
“Integer” e “Float”, respectivamente. Por fim, armazena-se o tamanho da String “units”,
seguido de seu valor propriamente dito, totalizando 4 Strings, 3 objetos, uma lista e outros
19 bytes. Mais explicações sobre a estratégia empregada na planilha do Apêndice B são
dadas no restante deste capítulo.
4.3 Regras de mapeamento das estruturas de dados
56
Figura 4.1: Classes do MR mapeadas para o esquema de dados
desenvolvido.
Listas e objetos requerem mais espaço do que strings e demais tipos primitivos,
portanto uma classe como OBSERVATION composta por, pelo menos, 39 listas consome,
em média, mais espaço do que as outras classes do MR.
4.3
Regras de mapeamento das estruturas de dados
Para a realização do mapeamento é dada atenção aos membros de objetos de
tipos variáveis (relativos a classes polimórficas) e membros de tamanhos variáveis. Além
disso, propõe-se a separação lógica do objeto entre áreas de metadados, de membros com
tamanho fixo e de membros com tamanho variável.
4.3.1
Identificadores de tipo de classe
Apesar do MR não ser uma árvore, o modelo possui classes que funcionam como
raízes. A partir destes pontos de início, pode-se compor todo o restante da estrutura necessária para representar um registro clínico. São exemplos de raízes as classes COMPOSITION, ELEMENT, ROLE e SECTION.
A construção do vetor ocorre para objetos de classes concretas, devendo-se,
portanto, ser conhecida a estrutura hierárquica para tal classe, conforme definido pelo
MR. No conteúdo do vetor, é necessário incluir o identificador do tipo de classe para
a raiz da hierarquia do objeto pertinente ao registro clínico em questão, bem como
4.3 Regras de mapeamento das estruturas de dados
57
Tabela 4.1: Exemplo de codificação de trecho do vetor: tipo p do
objeto, um booleano b e uma lista L com t elementos.
p
i
n L0
... Ln
identificadores de classes descendentes cujas instâncias podem assumir diferentes tipos.
Os identificadores de classe são constantes codificadas para ocupar o tamanho de um
byte. Esses identificadores são definidos na coluna “Identificador” da Tabela B.1 e são
utilizados para especificar ou reconhecer os objetos de tipo variável que compõem os
dados a serem persistidos.
O exemplo da Tabela 4.1 pode ser visto como um exemplo de serialização
do grafo de objetos baseado no MR do openEHR. Para a ilustração do vetor é feita a
abstração de parte do grafo, isto é, o objeto raiz é representado sem detalhar os objetos
que o compõe. Desta forma, o exemplo representa um objeto raiz com tipo variável p.
Para isto, p assume um valor de identificação relativo a uma das classes do MR, cujos
identificadores são previamente definidos. De acordo com a hierarquia do modelo, todo o
restante da estrutura do vetor passa a ser conhecida, desde que seja formada por objetos
de tipo fixo.
O mesmo raciocínio de identificação de tipo deve ser empregado na persistência
de objetos que admitem a variação de tipo, por exemplo no caso da classe abstrata
DATA_VALUE que possui vários tipos de classes especializadas e no caso da classe
concreta DV_TEXT, que também pode assumir o tipo DV_CODED_TEXT. Os demais
objetos, de tipo fixo, não necessitam de identificadores de classe para a codificação
do registro clínico (vetor), pois suas classes são previamente conhecidas a partir da
especificação do MR.
4.3.2
Separação entre atributos de tamanho fixo e variável
Algumas decisões de projeto foram tomadas para realizar a persistência dos dados baseados no openEHR. Conforme ressaltado anteriormente, para projetar a camada de
persistência é preciso mapear as classes do MR para um modelo de dados lógico estruturado em um vetor. As classes concretas de tipo e tamanho fixo são trivialmente persistidas
no vetor, por outro lado classes de tamanho variável ou com membros (atributos) de tipo
variável seguem uma estrutura mais elaborada.
Para cada objeto, com seus respectivos membros, é feita a separação entre área
com elementos de tamanho fixo no início do vetor e área com elementos de tamanho
variável no final. Como exemplo, considere a Tabela 4.1. O vetor é iniciado com o
identificador de tipo p do objeto, ocupando 1 byte. Posteriormente, são persistidos os
membros de tipos primitivos, este é o caso do inteiro i que ocupa 4 bytes. Para conjuntos
de objetos (coleções), guarda-se a cardinalidade n em um espaço de 1 a 5 bytes. Em
4.3 Regras de mapeamento das estruturas de dados
58
Tabela 4.2: Exemplo de codificação de trecho do vetor: tipo p
do objeto, cardinalidade n da lista L, tipo t de cada
elemento da lista, um inteiro i e uma lista L com n
elementos.
p
n t0
... tn
i L0
... Ln
seguida são persistidos todos os objetos da coleção, como, por exemplo, uma lista
composta por L0 . . Ln .
4.3.3
Área de metadados
No caso de objetos formados por mais de uma String, as cardinalidades desses
membros podem ser armazenadas em uma área anterior a de tamanho variável, denominada área de metadados. Assim, a soma dos tamanhos das Strings pode indicar o próximo
ponto de leitura, possibilitando um “salto” maior no vetor. Caso a prioridade seja a redução do tempo de processamento, é possível armazenar o tamanho dos objetos e referências
de listas, e aplicar o mesmo raciocínio de “saltos” mais longos.
A Tabela 4.2 representa um exemplo deste formato. De acordo com uma ordem
predefinida, o vetor inicia-se pelo tipo do objeto, seguido pelo tamanho da lista que
compõe um de seus membros. Como os elementos desta lista são de tipos variáveis, seguese o tipo de cada elemento, para somente então armazenar o conteúdo da área de tamanho
fixo e de tamanho variável.
Para estratégias guiadas por consultas baseadas em população, isto é, recuperação de objetos com um determinado tipo, recomenda-se armazenar os identificadores
de objetos de tipo variável na área de metadados. Deste modo este tipo de consulta é
realizada sem a necessidade de consultar dados de tipos indesejáveis.
4.3.4
Codificação da cardinalidade de coleções e Strings
Ainda sobre o conteúdo da Tabela 4.1, nota-se que n é a cardinalidade da coleção.
O openEHR estabelece a especificação de tipos básicos que define o o uso do tipo inteiro
com capacidade de armazenamento de 32 bits equivalente a 4 bytes [27]. Tendo em vista o
requisito inicial de redução do custo de memória, a codificação de um inteiro pode variar
de acordo com o tamanho efetivo da coleção.
Para se evitar o desperdício do tamanho da coleção em 4 bytes, pode-se utilizar
um tamanho com 1, 2, 3 ou 5 bytes. Nesta abordagem são utilizados 2 bits para indicar
o tamanho do inteiro. Consequentemente, são necessários 5 bytes para armazenar 31
ou 32 bits de informação. Por exemplo, para uma coleção de tamanho 50, são usados,
por padrão, 4 bytes. Já na abordagem proposta é necessário 1 byte. Destes 8 bits, 2 bits
4.4 Considerações finais
59
Tabela 4.3: Codificação de tamanho de atributos de tamanho variável.
No. de bytes
1
2
3
5
No. mínimo de elementos
0
26
214
222
No. máximo de elementos
26 − 1
214 − 1
222 − 1
232 − 1
indicam a quantidade 1 referente ao comprimento do tamanho da coleção. Os demais 6
bits representam o tamanho 50 da coleção.
O conteúdo da Tabela 4.3 denota a codificação usada para tamanhos de coleções:
a primeira coluna representa o número de bytes usados para o valor do tamanho; as colunas segunda e terceira definem a faixa de pertinente ao número de bytes da codificação.
Vale ressaltar que os dois bits iniciais do primeiro byte da codificação, definem o próprio
número de bytes utilizados na codificação, a saber:
•
•
•
•
4.3.5
o valor binário “00” estabelece 1 (um) byte para a codificação de tamanho;
o valor binário “01” estabelece 2 (dois) bytes para a codificação de tamanho;
o valor binário “10” estabelece 3 (três) bytes para a codificação de tamanho;
o valor binário “11” estabelece 5 (cinco) bytes para a codificação de tamanho.
Concatenação de atributos
O mapeamento utiliza o conceito de armazenamento “inline”, em que um ou
mais atributos de uma classe referenciada são concatenados em apenas um campo da
classe referenciadora. Com a concatenação física de n Strings, por exemplo, n tamanhos
de Strings podem ser substituídos por apenas uma referência para um próximo membro.
Estes casos devem ser especificados durante o mapeamento das classes do MR para o
formato pretendido.
Apesar dos membros serem separados logicamente, os objetos nesta estratégia
são armazenados de forma inline, uma vez que os objetos são persistidos sequencialmente,
conforme a especificação do MR. Neste caso, não é necessário o uso adicional de
referências para avançar entre diferentes pontos do vetor, fazendo com que o acesso seja
realizado de forma contínua.
4.4
Considerações finais
A camada de persistência proposta serializa o grafo de objetos do MR em uma
sequência de bytes. A serialização pode ser destinada para locais como arquivos e serviços
4.4 Considerações finais
60
web. Durante a recuperação carrega-se uma cópia do vetor na memória principal. Para a
persistência de um grafo de objetos extenso, com conteúdo multimídia, por exemplo,
deve-se utilizar a memória secundária. Neste caso apenas partes do grafo são carregadas
em memória principal conforme a necessidade.
CAPÍTULO 5
Algoritmos de persistência
Este capítulo apresenta uma estratégia possível de persistência, baseada nas
regras de mapeamento definidas no Capítulo 4. Na Seção 5.1 é feita uma descrição breve
de funções assumidas para a persistência dos dados. Na Seção 5.2, são apresentados
os algoritmos empregados para a realização da serialização, seguidos dos algoritmos
de desserializacao na Seção 5.3. O impacto no custo de memória e de processamento,
gerados pelos algoritmos, são analisados na Seção 5.4. Por fim, a Seção 5.5 relata um
exemplo aplicado sobre um pacote do openEHR.
5.1
Funções auxiliares
Em todos os algoritmos apresentados posteriormente, assume-se a disponibilização de funções trivialmente implementadas sobre o MR do openEHR. São elas:
• Integer p ← tipo (RMObject objeto): retorna a constante previamente definida para
o tipo do objeto;
• byte[] V ← obtemValor(RMObject o): recupera o valor do atributo o, cujo tipo é
conhecido, convertido em um vetor de bytes;
• defineValor(RMObject o, byte[] V): atribui o conteúdo de v ao valor do atributo o,
após a conversão do vetor para o tipo conhecido do membro;
• byte[] W ← obtemBytes(byte[] V, int i, int j): obtém os bytes contidos no vetor V
da posição i até a posição i + j − 1;
• defineBytes(byte[] V, int i, byte[] W): atribui ao vetor V , da posição i até a posição
i + |W | − 1, o vetor W ;
• RMObject c ← chave(Hash h, Integer i): retorna o objeto chave do hashmap h na
posição i;
• RMObject c ← valor(Hash h, Integer i): retorna o objeto valor do hashmap h na
posição i;
• Integer s ← vetorBytesParaInteiro(byte[] V): retorna o inteiro convertido a partir
do vetor de bytes V;
5.2 Serialização de dados
62
• Byte b ← (a >> b) | (c << d): retorna o byte a com b bits deslocados à direita,
sobre o qual é aplicada a operação booleana “ou” com o byte c deslocado d bits à
esquerda;
• Integer s ← tamanhoFixo(Integer p): retorna o tamanho predefinido em bytes
ocupado por um elemento de tipo p, conforme a especificação do openEHR.
• List L ← L + RMObject o: adiciona o objeto o à lista L;
• Hash S ← S + RMObject c + RMObject v: adiciona o par de objetos chave c e seu
respectivo valor v ao hashmap S.
5.2
Serialização de dados
O armazenamento de cada objeto do MR depende de um algoritmo específico, o qual é parametrizado com os objetos previstos na especificação. Por exemplo,
para o armazenamento de um DV_PARAGRAPH deve ser implementado, especificamente, um algoritmo que exija um objeto composto pelos campos (membros) de um
DV_PARAGRAPH.
Algoritmo 5.1: serializaObjeto(o)
Entrada: objeto o a ser serializado em uma sequência de bytes.
Saída: Vetor de bytes contendo a serialização do objeto o.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Cria vetor V
V [0] ← tipo(o)
j←1
para todo a ∈ A(o) faça
Cria vetor S
se grupo(tipo(a)) = PRIMITIVO então
S ← serializaPrimitivo(a)
fim
se grupo(tipo(a)) ∈ {COLECAO, COLECAO_PRIMITIVO} então
S ← serializaColecao(a)
fim
se grupo(tipo(a)) = OBJETO então
S ← serializaOb jeto(a)
fim
de f ineBytes(V, j, S)
j ← j + |S|
fim
retorna V
5.2 Serialização de dados
63
Contudo, o Algoritmo 5.1 representa uma forma generalizada de se armazenar
uma instância o de uma classe qualquer do MR. Assim, o algoritmo é responsável por
armazenar o grafo completo de objetos caso seja parametrizado, inicialmente, com o objeto raiz do grafo. Isto é feito através do comando “byte[] vetorFinal ← serializaObjeto(RMObject raiz)”.
No Algoritmo 5.1 o armazenamento do grafo de objetos exige a indicação de
cada objeto do grafo. A instância da classe deve permitir a recuperação de seu tipo,
em conformidade à planilha do Apêndice B, através de uma função como em “byte t
← tipo(objeto o)”. O tipo do objeto é, então, armazenado no primeiro byte do vetor de
persistência, mostrado na linha 2 do algoritmo. Com o conhecimento do tipo do objeto,
todos os seus membros (atributos), compostos por tipos primitivos, coleções e/ou objetos,
podem ser posteriormente persistidos. Este algoritmo retorna um vetor de bytes que pode
ser arquivado em memória secundária.
Uma das funções empregadas pelo algoritmo 5.1 é denominada A(o), na linha 4.
Tal função define, a partir do objeto o, a sequência de atributos A(o) = ha0 , a1 , . . ., an−1 i.
Esta função é definida apenas para objetos que fazem parte do Modelo de Referência
do openEHR. Em particular, essa função ainda está em conformidade com a sequência
estabelecida na planilha em anexo, ou seja, a ordem dos membros é definida na planilha.
Para cada membro do objeto de entrada, o Algoritmo 5.1 verifica o tipo do
membro a partir da linha 6. Caso o tipo pertença ao grupo de primitivos, conforme o
Algoritmo 5.2, a serialização do membro é efetuada na linha 7, caso contrário devem ser
feitas outras chamadas às funções de serialização.
Algoritmo 5.2: grupo(p)
Entrada: o tipo de um atributo.
Saída: o grupo que contém o tipo fornecido.
1
2
3
4
5
6
7
8
9
10
se p ∈ {BOOLEAN, INT EGER, REAL,CHAR, OCT ET, ST RING} então
retorna PRIMITIVO
fim
se p ∈ {LIST < T >, SET < T >, ARRAY < T >, HASH < T,U >} então
se T ∈ {BOOLEAN, INT EGER, REAL,CHAR, OCT ET, ST RING}
então
retorna COLECAO_PRIMITIVO
fim
retorna COLECAO
fim
retorna OBJETO
5.2 Serialização de dados
64
Para membros de tipos do grupo “primitivo”, é feita uma chamada pelo Algoritmo 5.3. Conforme a linha 2 deste algoritmo, se o membro é do tipo String, a cardinalidade da String, na linha 3, é transformada em um vetor de bytes na linha 4, seguindo as
especificações da Subseção 4.3.4. Este tamanho é armazenado na linha 5 em um intervalo
do vetor que varia da posição atual j até a posição acrescida do comprimento do tamanho
de 1, 2, 3 ou 5 bytes.
Algoritmo 5.3: serializaPrimitivo(a)
Entrada: membro a a ser serializado em uma sequência de bytes.
Saída: Vetor de bytes contendo a serialização do membro a.
1
2
3
4
5
6
7
8
9
Cria vetor V e inteiro t
se tipo(a) = STRING então
t ← |a|
T ← vetorTamanho(t)
de f ineBytes(V, 0, T )
fim
/* Senão t ← tamanhoFixo(tipo(a)) */
de f ineBytes(V, |T |, obtemValor(a))
retorna V
A transformação do tamanho da String em um vetor de bytes é feita na linha 4
pelo Algoritmo 5.4. Este algoritmo verifica o tamanho parametrizado, caso seja inferior a
6 bits de informação, o tamanho é armazenado em um byte na linha 3, de modo que os 2
bits iniciais permanecem zerados, conforme a Subseção 4.3.4. Para os demais tamanhos,
os bytes necessários são ocupados e os dois primeiros bits são configurados de acordo
com a quantidade de bytes utilizada.
Para elementos primitivos diferentes de Strings, o Algoritmo 5.3 recupera o
tamanho fixo do tipo, na linha 7, de acordo com a especificação do openEHR. Em seguida,
na linha 9, o valor do membro primitivo é serializado em um intervalo do vetor que varia
da posição atual j até o tamanho ocupado pelo membro.
Ainda conforme o Algoritmo 5.1, caso o membro a seja do tipo coleção,
primitiva ou não, executa-se o Algoritmo 5.5, senão é feita uma chamada recursiva ao
próprio Algoritmo 5.1. O vetor S resultante é armazenado definitivamente no vetor de
saída V , o qual é retornado pela função contendo a serialização completa do objeto.
5.2 Serialização de dados
65
Algoritmo 5.4: vetorTamanho(t)
Entrada: inteiro t cujo valor será serializado em vetor de bytes.
Saída: vetor de bytes V com o valor t serializado.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Cria vetor de bytes V
se t < 26 então
V [0] ← t
senão
se t < 214 então
de f ineBytes(V, 0,t | (1 << 14))
senão
se l < 222 então
de f ineBytes(V, 0,t | (2 << 22))
senão
de f ineBytes(V, 0,t | (3 << 30))
fim
fim
fim
retorna V
A Figura 5.1 exemplifica o modo de funcionamento do procedimento de persistência. O Algoritmo 5.1 armazena o tipo do objeto, seja ele ou não a raiz do grafo
de objetos, na posição 0 do vetor V , exemplificado pelo valor 84 correspondente a um
tipo predefinido. A variável j aponta para o final do vetor em cada iteração, portanto j
é responsável pelo controle de posição para inserção no vetor. Para o armazenamento do
tamanho t de um atributo de tamanho variável, t ocupa q bytes antes do conteúdo do atributo, isto é exemplificado pelo tamanho de valor 2 armazenado em 1 byte. Em seguida, o
conteúdo do atributo é representado nos t bytes, exemplificado com os valores “z” e “y”.
Figura 5.1: Exemplo de execução do algoritmo de serialização,
com uma raiz composta por uma String de tamanho
2.
Para efetuar a serialização de um membro constituído por uma coleção, o
Algoritmo 5.5 armazena na variável n da linha 1 a cardinalidade da coleção. No caso
5.2 Serialização de dados
66
Algoritmo 5.5: serializaColecao(C)
Entrada: a coleção C de objetos a ser serializada.
Saída: o vetor de bytes V com a serialização da coleção C.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
n ← |C|
Defina a sequência S = hc1 , c2 , . . . , cn i, onde ci ∈ C, para i = 1 . . . , n
Cria vetor V
j←0
se tipo(C) = HASH < K,U > então
Cria listas K e L
para h ← 1 até n passo h ← h + 1 faça
K ← K + chave(ch )
L ← L + valor(ch )
fim
W ← serializaColecao(K)
de f ineBytes(V, j,W )
j ← j + |W |
Z ← serializaColecao(L)
de f ineBytes(V, j, Z)
j ← j + |Z|
senão
T ← vetorTamanho(n)
de f ineBytes(V, j, T )
j ← j + |T |
para i ← 1 até n passo i ← i + 1 faça
se grupo(tipo(C)) = COLECAO_PRIMITIVO então
S ← serializaPrimitivo(ci )
senão
S ← serializaOb jeto(ci )
fim
de f ineBytes(V, j, S)
j ← j + |S|
fim
fim
retorna V
uma coleção do tipo Hash<T,U>, composta por pares chave-valor, realizam-se as serializações recursivas, nas linhas 11 e 14, respectivamente, de uma lista com as chaves (obtidas
5.3 Desserialização de dados
67
na linha 8) e de uma lista com os respectivos valores (obtidos na linha 9). Para os demais
tipos de coleção, armazena-se a cardinalidade de objetos n através do Algoritmo 5.4. Caso
seja verificado, na linha 22, que a coleção é composta por elementos primitivos, então o
Algoritmo 5.3 é executado para cada elemento da coleção. Caso contrário, o Algoritmo
5.1 serializa cada objeto em uma nova execução.
5.3
Desserialização de dados
Para desserializar o vetor de t bytes V a partir da raiz, deve ser feita uma chamada
ao Algoritmo 5.6 através do comando “(objeto raiz, inteiro t) ← desserializaObjeto(V, 0)”.
Algoritmo 5.6: desserializaObjeto(V, j)
Entrada: vetor de bytes V para ser desserializado; inteiro j com a posição de início
da desserialização.
Saída: objeto o contido no vetor V ; inteiro j com a próxima posição de
desserialização (isto é, j − 1 é a última posição recuperada).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
t ← V [ j]
defina S = ha1 , a2 , . . . , an i a sequência dos atributos do tipo t
cria o conjunto M de membros de um objeto do tipo t
para i ← 1 até n passo i ← i + 1 faça
cria variável r com o tipo de classe “tipo(ai )”
se grupo(tipo(ai )) = PRIMITIVO então
(r, j) ← desserializaPrimitivo(V, j,tipo(ai ))
fim
se grupo(tipo(ai )) = COLECAO então
(r, j) ← desserializaColecao(V, j,tipo(ai ))
fim
se grupo(tipo(ai )) = OBJETO então
(r, j) ← desserializaOb jeto(V, j)
fim
j ← j + tamanho(r)
M ← M∪r
fim
Cria objeto o do tipo t usando os membros M
retorna o, j
Na linha 1 do Algoritmo 5.6 recupera-se o tipo da classe do primeiro objeto
serializado no vetor, presente no primeiro byte. Em posse do tipo, é possível definir a
5.3 Desserialização de dados
68
sequência de membros S do objeto, na linha 2, de acordo com a ordem dos atributos das
classes relacionadas na planilha do Apêndice B.
Ainda conforme o Algoritmo 5.6, se o membro é de tipo primitivo, é feita uma
chamada ao Algoritmo 5.7. No caso de Strings no algoritmo chamado, recupera-se a
cardinalidade, na linha 2, e a ela multiplica-se o tamanho de um caractere, na linha 3,
para se obter o tamanho total. Para os demais tipos primitivos, este tamanho é fixado pela
especificação do openEHR. Por fim, o valor do tipo primitivo é configurado, na linha 7,
de acordo com o vetor na posição atual até o tamanho encontrado.
Algoritmo 5.7: desserializaPrimitivo(V, j, p)
Entrada: Vetor de bytes V ; inteiro j com a posição de início da desserialização;
inteiro p com o tipo primitivo do elemento.
Saída: Elemento r de tipo primitivo p; inteiro j com a próxima posição para
desserialização de V.
1
2
3
4
5
6
7
8
9
cria inteiro c
se p = STRING então
(s, j) ← recuperaTamanho(V, j)
s ← s ∗ tamanhoFixo(CHAR)
senão
s ← tamanhoFixo(tipo(ai ))
fim
de f ineValor(r, obtemBytes(V, j, s))
retorna r, j.
A recuperação da cardinalidade de uma String, é realizada através do Algoritmo
5.8, onde são verificados os dois primeiros bits para determinar a quantidade n de bytes
ocupada pelo tamanho, conforme explicado na Subseção 4.3.4. Assim, o algoritmo retorna
o tamanho contido na porção inicial do vetor até a quantidade n.
5.3 Desserialização de dados
69
Algoritmo 5.8: recuperaTamanho(V, j)
Entrada: Vetor de bytes V ; inteiro j com a posição de início da
desserialização.
Saída: Inteiro t correspondente ao tamanho do próximo membro; inteiro j
com a próxima posição para desserialização de V.
1
2
3
4
5
6
7
8
9
10
cria inteiros q, t e vetor de bytes W.
q ← (V [ j] >> 6) + 1
se q = 4 então
q←5
fim
W ← obtemBytes(V, 0, q)
atribua 0 ao 1o e 2o bit de W
t ← vetorByteParaInteiro(W )
j ← j+q
retorna t, j
Para a desserialização de coleções é feita uma chamada do Algoritmo 5.6, na
linha 10, ao Algoritmo 5.9, parametrizando-o com uma referência para o vetor, a posição
inicial de leitura e o tipo específico da coleção. Já para a desserialização de um membro
cujo tipo é um objeto, é realizada, na linha 13, uma chamada recursiva ao próprio
algoritmo com a referência do vetor.
Para coleções do tipo hashmap, o Algoritmo 5.9 realiza uma chamada recursiva
para cada lista que o compõe, isto é, para a lista de chave e para a lista de valores. Os
pares de chaves e valores são, então, combinados na linha 8 para formar cada elemento do
hashmap. Para as demais coleções, recupera-se a cardinalidade de elementos da coleção
na linha 11. Assim, caso a coleção seja composta por elementos primitivos, é realizada
uma chamada ao Algoritmo 5.7 para cada elemento. Senão, cada objeto é desserializado
na linha 17 por uma nova chamada ao Algoritmo 5.6.
5.4 Desempenho dos algoritmos de persistência
70
Algoritmo 5.9: desserializaColecao(V, j, p)
Entrada: Vetor de bytes V ; inteiro j com a posição de início da desserialização;
inteiro p com o tipo da coleção.
Saída: Coleção de elementos S; inteiro j com a próxima posição para
desserialização de V.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
cria inteiro c
se p = HASH então
cria LIST K, LIST L e HASH S
(K, j) ← desserializaColecao(V, j, LIST ))
(L, j) ← desserializaColecao(V, j, LIST ))
c ← |K|
para i ← 0 até c − 1 passo i ← i + 1 faça
S ← S + Ki + Li
fim
senão
(c, j) ← recuperaTamanho(V, j)
para i ← 0 até c − 1 passo i ← i + 1 faça
cria elemento o de tipo p
se grupo(tipo(p)) = COLECAO_PRIMITIVO então
(o, j) ← desserializaPrimitivo(V, j, p)
senão
(o, j) ← desserializaOb jeto(V, j)
fim
S ← S+o
fim
20
21
22
fim
retorna S, j.
5.4
Desempenho dos algoritmos de persistência
O custo de memória e processamento do Algoritmo 5.1 cresce linearmente
conforme a quantidade de objetos presentes no grafo. Isto ocorre devido ao fato do
algoritmo armazenar cada objeto do grafo no vetor de saída, acrescido de metadados em
um espaço constante. Assim, instâncias do DV_BOOLEAN do MR, por exemplo, exigem
um espaço em memória suficiente para armazenar os valores booleanos e o tipo do objeto,
opcionalmente em alguns casos.
A estrutura da classe (ou modelo de objeto), em conformidade com a especi-
5.4 Desempenho dos algoritmos de persistência
71
ficação do openEHR, pode ser armazenada uma única vez para todos os registros. Esta
estrutura deve indicar o tipo e tamanho do campo que compõe o objeto. Por outro lado,
o mapeamento objeto-relacional puro resultaria em estruturas complexas com o armazenamento de referências e metadados repetidos. Sobre a estrutura gerada é possível aplicar
técnicas conhecidas de compressão que reduzem o custo de espaço, mas que aumentam o
custo de processamento.
Para a recuperação de dados no Algoritmo 5.6, é necessário que se percorra o
vetor do início ao fim de forma contínua, com possíveis “saltos” sobre tipos primitivos.
Nestes casos, o tamanho ocupado é previamente definido pela especificação do openEHR
ou pode ser obtido no vetor, no caso de Strings.
A leitura do vetor correspondente ao RES indicado inicia-se pelo tipo da raiz.
Com essa informação, passa-se a conhecer a estrutura do vetor, uma vez que a estrutura
segue a especificação do MR do openEHR. O projeto da camada de persistência parte do
pressuposto de que esta especificação, criada a partir da planilha explicada na Tabela B.1,
encontra-se armazenada conforme a implementação empregada pela aplicação, a qual é
responsável por instanciar o grafo correspondente ao RES.
Tanto o armazenamento, quanto a recuperação do grafo, devem ser parametrizados com uma referência para o vetor serializado e um contador com o tamanho ocupado pelo vetor. Para se percorrer o vetor serializado, efetua-se a leitura do primeiro byte,
responsável por apontar o tipo da raiz. Assim como a aplicação conhece previamente a
estrutura do MR, também são conhecidos metadados do vetor, isto inclui a relação entre
cada classe do MR e um byte identificador de tipo. Em posse do tipo da raiz, a aplicação
consulta a especificação armazenada do MR para conhecer a organização dos atributos.
Os algoritmos representados recursivamente podem ser transformados em versões iterativas. No pior caso, deve-se percorrer todo o vetor para encontrar um objeto específico. Desconsiderando o uso de métodos conhecidos de otimização, como por exemplo índices, este custo é o menor possível já que os objetos são armazenados de forma
ordenada, isto é, sem o uso de referências. Além de aumentar o custo de memória, o
emprego de referências implicaria em percorrer repetidamente um mesmo ponto do vetor.
O armazenamento das cardinalidade das coleções e tamanhos de Strings em um
espaço de 1 a 5 bytes reduzem o custo de armazenamento caso o tamanho da coleção
seja inferior, em média, a 30 bits de informação. Adicionalmente, no caso de objetos
compostos por outros objetos, a consulta pelos tipos das instâncias pode ser melhorada
com o armazenamento do tipo no início do objeto.
5.5 Estratégia de persistência exemplificada
72
Figura 5.2: Pacote rm.data_types.text versão 1.0.3[45].
5.5
Estratégia de persistência exemplificada
O pacote data_types.text do MR, ilustrado na Figura 5.2 é um exemplo representativo do restante do modelo. Este pacote contém herança, atributos de tamanho fixo,
como char, e de tamanho variável, como Strings e lista de tipo variável. Também contém
atributos explicitamente inline, como é o caso do atributo de tipo DV_URI.
Um exemplo hipotético da estratégia de persistência aplicada a uma instância do
pacote data_types.text do MR é mostrado, inicialmente, na Figura 5.3. Neste exemplo, a
classe DV_PARAGRAPH rotulada com o tipo 3 (conforme o identificador do Apêndice
B) é definida como a raiz do vetor. De acordo com a Figura 5.2 um objeto do tipo
DV_PARAGRAPH contém uma lista de DV_TEXT nomeada “items”.
Assim, a Figura 5.3 contém uma coleção com apenas um elemento, mais
especificamente do tipo DV_CODED_TEXT rotulado pelo identificador 6. Um objeto DV_CODED_TEXT apresenta, dentre outros atributos, a String “formatting” e o
DV_URI “hyperlink”, que também se reduz a uma String quando tratado de modo inline.
Ambas as Strings possuem metadados relacionados ao tamanho da cadeia de caracteres,
portanto, a Figura 5.3 exemplifica os tamanhos ocupados por essas Strings com o valor 1
e seus respectivos conteúdos “F” e “H”.
De acordo com a Figura 5.2, um DV_TEXT também é formado por uma
lista de TERM_MAPPING chamada de “mappings”[45]. Assim, a Figura 5.4 retrata
uma lista com um elemento. Tal TERM_MAPPING é composto por um caractere,
isto é, um atributo de tamanho fixo, exemplificado com o valor “M”. Além disso, um
5.6 Considerações finais
73
Figura 5.3: Exemplo da estratégia de persistência aplicada ao
pacote data_types.text do MR com a raiz e um objeto
que a compõe.
TERM_MAPPING é composto por uma lista de DV_CODED_TEXT nomeada “purpose”
e por um CODE_PHRASE nomeado “target”, ambos atributos de tamanho variável e,
portanto, armazenados no final do objeto. No exemplo “purpose” não possui quaisquer
elementos.
Por outro lado, o CODE_PHRASE “target” é composto por um “terminology_id” e um “code_string”, ambos suficientemente representados por Strings. Este objeto é armazenado de forma aninhada no objeto ao qual pertence. Assim, a separação no
vetor entre elementos de tamanho fixo e variável deve ser aplicada tanto no objeto-pai
quanto no objeto-filho que o compõe. Como o objeto-filho não é composto por outro objeto, no vetor são armazenadas as Strings relativas a seus atributos, com seus respectivos
tamanhos e valores, exemplificados no vetor com um caractere para cada atributo e com
valores “T”.
Em uma visão geral, o armazenamento de um DV_PARAGRAPH depende do
armazenamento de um DV_TEXT especializado pelo objeto DV_CODED_TEXT, o qual
se resume a um DV_TEXT justaposto a um CODE_PHRASE. Tanto neste aninhamento
de objetos, quanto nos demais, os atributos de tamanho fixo e metadados precedem
os atributos de tamanho variável, o que inclui objetos que não sejam armazenados de
forma estritamente “inline”, isto é, que sejam tratados como objetos com atributos e não,
simplesmente, como atributos.
5.6
Considerações finais
Para as estratégias apresentadas, assume-se que o conteúdo da planilha do
Apêndice B é armazenado no diretório de registros ou mesmo na aplicação. Isso é possível
5.6 Considerações finais
74
Figura 5.4: Exemplo da estratégia de persistência aplicada sobre
um objeto composto por atributos de tamanho fixo e
variável.
devido ao fato do MR ser um modelo estável. Contudo, caso haja alguma modificação
realizada na especificação do openEHR, ela deve ser refletida no conteúdo da planilha.
A fim de facilitar o entendimento da estratégia de persistência, o identificador de
classes foi empregado em todos os objetos. A separação da área de metadados, por sua
vez, só é possível em algoritmos iterativos, já que o dado deve ser separado do metadado.
Todavia, para evitar o detalhamento de procedimentos relativos à implementação, foram
utilizadas técnicas de recursividade.
CAPÍTULO 6
Conclusão
Neste trabalho foi especificado o formato de serialização do grafo de objetos
do openEHR, aplicado sobre um vetor de bytes. Além disso, foi definida uma gama de
conceitos empregada na geração de regras de mapeamento, que incluem desde o mapeamento de membros de objetos de tipos primitivos previamente conhecidos e ordenados,
até estruturas complexas como coleções de objetos de tipos e tamanhos desconhecidos.
O esquema de dados para persistência segue o esquema conceitual do MR. Contudo, cada classe folha foi convertida para um conjunto de atributos (unidos aos atributos
das classes ascendentes). Tais atributos foram projetados para serem armazenados em um
vetor de bytes considerando a redução de espaço ocupado, mas de modo a não inviabilizar
o tempo de processamento.
A estratégia de persistência foi descrita através de algoritmos recursivos de serialização e desserialização de dados. Estes algoritmos são reflexivos, isto é, os algoritmos
de serialização validam os algoritmos de desserialização (e vice-versa) ao percorrer o caminho inverso apontado pelo outro. Assim a estratégia apresentada deve ser viável para
ser executada em ambas as direções. Por fim, a estratégia de persistência foi exemplificada
e discutida em relação a sua eficácia.
A principal contribuição deste trabalho é o desenvolvimento de uma estratégia
de persistência que considera as especificidades do MR do openEHR, isto é, um modelo
explicitamente restrito, composto por estruturas predefinidas. Esta estratégia é recomendada para o armazenamento e recuperação de dados clínicos localizados em um ambiente
com recursos de espaço e processamento limitados.
6.1
Comparação com trabalhos correlatos
A comparação da estratégia apresentada com trabalhos relacionados pode ser
realizada através da inclusão da contribuição deste estudo em formulários da Subseção
3.4.2, preenchidos na Subseção 3.4.3. A contribuição deste estudo centra-se no mapeamento do MR para um modelo de dados físico, portanto a comparação realizada na Tabela
3.14 é novamente realizada, com a adição deste trabalho, na Tabela 6.1.
6.1 Comparação com trabalhos correlatos
76
Tabela 6.1: Adição da contribuição do trabalho atual à Tabela
3.14.
CI (B1)
Modelo conceitual (B2)
Modelo
lógico
ou
físico (B3)
[48]
CI-2
HL7 RIM
[55]
CI-4
Arquétipos
Trabalho atual
CI-2
MR do openEHR
EAV-Otimizado
Modelo de BD Re- Modelo físico com ob(OEAV) sobre a lacional
jetos serializados em
classe Observation
um vetor de bytes
e relacional nas
demais
Tipos de da- Tipos padrões de BD Coluna de tipo bá- Strings com inclusão
dos básicos
sico SQL
de tamanho e demais
(B4)
tipos primitivos com
tamanho fixo
Associação
FK em 1:1 e 1:N; Incorpora
coluna Objetos ordenados no
e agregação Tabela separada em em 1:1; Usa FK em vetor de forma fixa e
(B5)
N:N e agregação
1:N
sem uso de referências
Herança
Uma tabela por Template mapeia Membros do objeto
(B6)
classe (com identifi- os
campos
do generalizado incluídos
cação) e uma coluna arquétipo especi- no objeto especialipor atributo.
alizado para o do zado
generalizado
Coleção
Tabela com FK para Objetos serializados
(B7)
id. do arquétipo e sequencialmente
e
coluna de tipo bá- precedidos da cardisico
nalidade
Mapeamentos Campo AV contém Tabela contém as Ordem de membros é
específicos
um código do Atri- versões nova e anti- fixa e tipos são arma(B8)
buto concatenado ao gas do arquétipo
zenados ou seguem esValor
pecificação.
De acordo com a primeira e quarta coluna da Tabela 6.1, uma instância de um
subconjunto do MR do openEHR, isto é, o grafo de objetos (na linha do atributo B2),
é serializado em um vetor de bytes (atributo B3), para que a persistência dos dados
possa ser efetuada. Tipos primitivos são armazenados com tamanho fixo, conforme a
especificação do openEHR, exceto para o caso de Strings, em que o tamanho da String é
guardado previamente (atributo B5). Objetos, por sua vez, armazenam seus tipos através
de identificadores constantes, já os membros dos objetos seguem a estrutura apresentada
na planilha do Apêndice B e, deste modo, as associações são previamente conhecidas
(atributo B6).
No caso de heranças (linha do atributo B7 da Tabela 6.1), o armazenamento
dos objetos generalizados não é realizado separadamente. Assim, apenas objetos folhas
são armazenados contendo todos os atributos dos objetos ascendentes. Com relação a
6.2 Trabalhos futuros
77
coleções (atributo B8), a estratégia apresentada armazena a cardinalidade da coleção para
ser utilizada durante a recuperação, o que possibilita a realização de “saltos” no vetor.
A estratégia de persistência apresentada explora as especificidades do openEHR
para reduzir os custos em espaço ocupado. Isto ocorre, principalmente, devido ao mapeamento das estruturas do MR na planilha do Apêndice B. Conforme mencionado no
atributo B9 da Tabela 6.1, neste mapeamento são fixadas a ordem e tipos dos membros
dos objetos, de acordo com a especificação do openEHR.
6.2
Trabalhos futuros
Em relação as limitações encontradas durante o trabalho, a revisão sistemática
foi utilizada como meio de se obter os requisitos para o desenvolvimento da estratégia
de persistência. Portanto, não foi feito um estudo aprofundado dos requisitos do ponto
de vista do usuário final e dos requisitos (de modo preciso e detalhado) relacionados
ao tempo de processamento e espaço de memória disponibilizados pelos sistemas. Além
disso, não houve tempo hábil para a implementação da camada de persistência, o que
impossibilitou a realização de experimentações. Assim, como trabalho futuro, espera-se:
• Explorar requisitos de usuário e de sistema para o desenvolvimento da camada;
• Detalhar o projeto arquitetural interno da camada de persistência e de sua relação
com outros serviços em um SIS, além de detalhar o fluxo de dados interno e externo
à camada;
• Apresentar funções matemáticas e provas formais do tempo de processamento e
espaço de memória requeridos;
• Implementar as funcionalidades de armazenamento e recuperação de dados em
conformidade à estratégia apresentada;
• Gerar e disponibilizar um benchmark de grande porte com dados clínicos baseados
no openEHR e realizar experimentos sobre a estratégia apresentada, comparando-a
com trabalhos correlatos encontrados durante a revisão sistemática.
Referências Bibliográficas
[1] ATALAG , K.; YANG , H. Y.; T EMPERO, E.; WARREN , J. Model driven development
of clinical information systems using openehr. 2011.
[2] AUSTIN , T.; K ALRA , D.; L EA , N.; PATTERSON , D.; I NGRAM , D. Analysis of clinical
record data for anticoagulation management within an ehr system. Open Med
Inform J, 3:54–64, 2009.
[3] B AHGA , A.; M ADISETTI , V. K. A cloud-based approach for interoperable electronic health records (ehrs). IEEE Journal of Biomedical and Health Informatics,
17(5):894–906, 2013.
[4] B ARCA , C. C.; L AGUNAR , C. M.; R ODRÍGUEZ , J. M.; Q UINTERO, A. M.; M ARTINS ,
I. R. M.; M ARTÍNEZ , I.; S ANGUINO, M. A.; L OBO, T. P. yourehrm: Standard-based
management of your personal healthcare information. In: IEEE International
Conference on Biomedical and Health Informatics (BHI), p. 89–92. IEEE, 2014.
[5] B EALE , T. Persistence FAQs. Última modificação em: 04 de Maio de 2016. Último
acesso em: 10 de Agosto de 2016.
[6] B EALE , T. Node+Path Persistence. Última modificação em: 04 de Agosto de 2008.
Último acesso em: 21 de Julho de 2016.
[7] B EALE , T. Archetypes: constraint-based domain models for future-proof information systems. OOPSLA 2002 Workshop on Behavioural Semantics, p. 1–18,
2002.
[8] B EALE , T.; H EARD, S. Architecture overview. openEHR Foundation, 2008.
[9] B HATTI , N.; H ASSAN , W.; M C C LATCHEY, R.; M ARTIN , P.; KOVACS , Z.; L E G OFF , J.;
S TOCKINGER , H.; W ILLERS , I.; L E , J.-M. Object serialization and deserialization
using xml. Advances in Data Management, 2000.
[10] B OREN , Z. There are officially more mobile devices than people in the world.
Última modificação em: 07 Out. de 2014. Último acesso em: 22 Nov. de 2016.
Referências Bibliográficas
79
[11] C HEN , R.; E NBERG , G.; K LEIN , G. O. Julius–a template based supplementary
electronic health record system. BMC medical informatics and decision making,
7(1):1, 2007.
[12] C HEN , R.; K LEIN , G.; OTHERS .
The openehr java reference implementation
project. Medinfo, 129:58–62, 2007.
[13] CNES. Dados do setor. Mês de referência: Novembro de 2016. Último acesso em:
17 de Novembro de 2016.
[14] DA S AÚDE , M. Estratégia e-saúde para o brasil. Secretária de Gestão Estratégica
e Participativa, Departamento de Informática do SUS.
[15] DA S AÚDE , M. Política nacional de informação e informática em saúde. Comitê
de Informação e Informática em Saúde.
[16] DA S AÚDE , M. Portaria no 2.073, de 31 de agosto de 2011.
[17] D ICK , R.; S TEEN , E.; D ETMER , D.
The computer-based patient record: An
essential technology. Technical report, IOM, 1991. Atualizado em 1997.
[18] D UFTSCHMID, G.; C HALOUPKA , J.; R INNER , C. Towards plug-and-play integration of archetypes into legacy electronic health record systems: the archimed
experience. BMC medical informatics and decision making, 13(1):1, 2013.
[19] EN13606-A SSOCIATION . The CEN/ISO EN13606 standard. Último acesso em: 21
de Julho de 2016.
[20] F LAT B UFFERS . FlatBuffers white paper. Última modificação em: 20 de Janeiro de
2016. Último acesso em: 10 de Agosto de 2016.
[21] F LEMMING , D.; PAUL , M.; H ÜBNER , U.
Building a common ground on the
clinical case: design, implementation and evaluation of an information model
for a handover ehr. Stud Health Technol Inform. 2014;201:167-74. PubMed PMID:
24943540., 2014.
[22] F RADE , S.; F REIRE , S. M.; S UNDVALL , E.; PATRIARCA -A LMEIDA , J. H.; C RUZ C ORREIA , R. Survey of openehr storage implementations. In: Proceedings of
the 26th IEEE International Symposium on Computer-Based Medical Systems, p.
303–307. IEEE, 2013.
[23] F REIRE , S. M.; S ZTAJNBERG , A.; C OPETTI , A.; L OQUES , O. Utilizando o modelo
dual para a representação e persistência de contexto em aplicações ubíquas
de telemonitoramento. In: VIII Workshop de Informática Médica. XXVIII Congresso
da Sociedade Brasileira de Computação, p. 15–18, 2008.
Referências Bibliográficas
80
[24] F REIRE , S. M.; T EODORO, D.; W EI -K LEINER , F.; S UNDVALL , E.; K ARLSSON , D.;
L AMBRIX , P. Comparing the performance of nosql approaches for managing
archetype-based electronic health record data. PloS one, 11(3):e0150069, 2016.
[25] F UNDAÇÃO - OPEN EHR. Multi-level Modelling concepts. Última modificação em:
31 de Julho de 2014. Último acesso em: 26 de Novembro de 2016.
[26] F UNDAÇÃO - OPEN EHR. Programa de Especificações. Último acesso em: 21 de
Julho de 2016.
[27] F UNDAÇÃO - OPEN EHR. openEHR Base Types specification. Último acesso em:
01 de Outubro de 2016.
[28] F UNDAÇÃO - OPEN EHR. EHR Information Model. Último acesso em: 22 de Novembro de 2016.
[29] H UMM , B. G.; WALSH , P. Flexible yet efficient management of electronic health
records. In: 2015 International Conference on Computational Science and Computational Intelligence (CSCI), p. 771–775. IEEE, 2015.
[30] ISO/TR-20514. Health informatics - electronic health record - definition, scope
and context. 2005.
[31] K IM , H. S.; T RAN , T.; C HO, H. A clinical document architecture (cda) to generate clinical documents within a hospital information system for e-healthcare
services. In: The Sixth IEEE International Conference on Computer and Information
Technology (CIT’06), p. 254–254. IEEE, 2006.
[32] K ROPF, S.; C HALOPIN , C.; D ENECKE , K. Template and model driven development
of standardized electronic health records. 216:30, 2015.
[33] L EE , K. K.-Y.; TANG , W.-C.; C HOI , K.-S. Alternatives to relational database:
comparison of nosql and xml approaches for clinical data storage. Computer
methods and programs in biomedicine, 110(1):99–109, 2013.
[34] L I , H.; D UAN , H.; L U, X.; H UANG , Z. A clinical document repository for cda
documents. In: 2007 1st International Conference on Bioinformatics and Biomedical
Engineering, p. 1084–1087. IEEE, 2007.
[35] L IANAS , L.; F REXIA , F.; D ELUSSU, G.; A NEDDA , P.; Z ANETTI , G. pyehr: A scalable
clinical data management toolkit for biomedical research projects. In: Healthcom, p. 370–374, 2014.
Referências Bibliográficas
81
[36] L ÓPEZ -N ORES , M.; B LANCO -F ERNÁNDEZ , Y.; PAZOS -A RIAS , J. J.; G ARCÍA -D UQUE ,
J. The icabinet system: Harnessing electronic health record standards from domestic and mobile devices to support better medication adherence. Computer
Standards & Interfaces, 34(1):109–116, 2012.
[37] M ADAAN , A.; C HU, W.; DAIGO, Y.; B HALLA , S. Quasi-relational query language interface for persistent standardized ehrs: Using nosql databases. In: International
Workshop on Databases in Networked Information Systems, p. 182–196. Springer,
2013.
[38] M ALDONADO, J. A.; C OSTA , C. M.; M ONER , D.; M ENÁRGUEZ -TORTOSA , M.; B OSCÁ ,
D.; G IMÉNEZ , J. A. M.; F ERNÁNDEZ -B REIS , J. T.; R OBLES , M. Using the researchehr platform to facilitate the practical application of the ehr standards. Journal
of biomedical informatics, 45(4):746–762, 2012.
[39] M ENEZES , P. M.; C OOK , T. W.; C AVALINI , L. T. Convergence of health level
seven version 2 messages to semantic web technologies for software-intensive
systems in telemedicine trauma care. Healthcare informatics research, 22(1):22–
29, 2016.
[40] M IAN , P.; C ONTE , T.; N ATALI , A.; B IOLCHINI , J.; T RAVASSOS , G. A systematic
review process for software engineering. In: ESELAW 2005, 2005.
[41] M OLINA , A. BSON Mad Science for fun and profit. Publicado em 26 de Outubro
de 2013. Último acesso em: 18 de Dezembro de 2016.
[42] M UIRHEAD, T. Object databases and object persistence for openehr, 2009.
[43] M UÑOZ , A.; S OMOLINOS , R.; PASCUAL , M.; F RAGUA , J. A.; G ONZÁLEZ , M. A.;
M ONTEAGUDO, J. L.; S ALVADOR , C. H. Proof-of-concept design and development
of an en13606-based electronic health care record service.
Journal of the
American Medical Informatics Association, 14(1):118–129, 2007.
[44] N OBLE , J.; W EIR , C. Small memory software: patterns for systems with limited
memory. Addison-Wesley Longman Publishing Co., Inc., 2001.
[45] OPEN EHR F OUNDATION , T. Data Types Information Model. Última modificação
em: 15 de Novembro de 2015. Último acesso em: 21 de Julho de 2016.
[46] O SÓRIO, E.; F ERREIRA , L.; A BREU, R.; S OUSA , F. Interoperability in ambient
assisted living using openehr. In: e-Health Networking, Applications & Services
(Healthcom), 2013 IEEE 15th International Conference on, p. 394–398. IEEE, 2013.
Referências Bibliográficas
82
[47] PARAISO -M EDINA , S.; P EREZ -R EY, D.; B UCUR , A.; C LAERHOUT, B.; A LONSO C ALVO, R. Semantic normalization and query abstraction based on snomed-ct
and hl7: supporting multicentric clinical trials. IEEE journal of biomedical and
health informatics, 19(3):1061–1067, 2015.
[48] PAUL , R.; S AYED M D L ATIFUL H OQUE , A.
Search efficient representation of
healthcare data based on the hl7 rim. Journal of Computers, 5(12):1810–1818,
2010.
[49] P ROTOCOL -B UFFERS . Developer Guide. Última modificação em: 20 de Janeiro de
2016. Último acesso em: 10 de Agosto de 2016.
[50] S ACHDEVA , S.; B HALLA , S. Visual query language for archetype-based electronic health records databases. Journal of information processing, 20(2):438–450,
2012.
[51] S ANTOS , C.; P EDROSA , T.; C OSTA , C.; O LIVEIRA , J. L. On the use of openehr in
a portable phr. In: 4th International Conference on Health Informatics. Institute for
Systems and Technologies of Information, Control and Communication, 2011.
[52] S UNDVALL , E.; N YSTRÖM , M.; K ARLSSON , D.; E NELING , M.; C HEN , R.; Ö RMAN , H.
Applying representational state transfer (rest) architecture to archetype-based
electronic health record systems. BMC medical informatics and decision making,
13(1):1, 2013.
[53] TAB N ET. Procedimentos hospitalares do SUS - Por local de internação - Brasil.
Fonte dos dados: Ministério da Saúde - Sistema de Informações Hospitalares do
SUS (SIH/SUS). Mês de referência: Setembro de 2016. Último acesso em: 17 de
Novembro de 2016.
[54] V ELTE , L.; P EDROSA , T.; C OSTA , C.; O LIVEIRA , J. L. An openehr repository based
on a native xml database. In: 5th International Conference on Health Informatics
(HEALTHINF 2012). INSTICC–Institute for Systems and Technologies of Information,
Control and Communication, 2012.
[55] WANG , L.; M IN , L.; WANG , R.; L U, X.; D UAN , H. Archetype relational mappinga practical openehr persistence solution. BMC medical informatics and decision
making, 15(1):1, 2015.
[56] YANG , W.-Y.; L EE , L.-H.; G IEN , H.-L.; C HU, H.-Y.; C HOU, Y.-T.; L IOU, D.-M.
The design of the hl7 rim-based sharing components for clinical information
systems. International Journal of Social Sciences, 5(2), 2010.
Referências Bibliográficas
83
[57] Z OLLMANN , J. Nosql databases. Retrieved from Software Engineering Research
Group: http://www. webcitation. org/6hA9zoqRd, 2012.
APÊNDICE A
Artigos incluídos
Uma breve descrição dos artigos incluídos, com as contribuições relacionadas ao
tema deste trabalho, é dada na Tabela A.1
Tabela A.1: Artigos incluídos na revisão sistemática
Frade et Faz um catálogo das características de sistemas que armazenam dados
al. (2013) modelados em arquétipos conforme as especificações da plataforma
[22]
openEHR. O catálogo inclui detalhes do sistema como a quantidade
de registros, modelo de banco de dados e linguagem de consulta.
Wang et Projeta regras de mapeamento de arquétipos para um esquema de BD
al. (2015) relacional, onde cada arquétipo corresponde a uma tabela. As regras
[55]
abordam desde o mapeamento de itens básicos até coleções de dados,
passando por nomeações de tabelas.
Velte et Apresenta um repositório XML baseado no openEHR. Para cada pacial. (2012) ente é armazenado um documento XML com todas as suas informações
[54]
a fim de simplificar os procedimentos de persistência.
Barca et Projeta a arquitetura yourEHRM com foco na integração de diferentes
al. (2014) padrões de interoperabilidade. A arquitetura contém uma camada que
[4]
armazena documentos JSON contendo pares NoSQL de caminho/valor.
Portanto, as consultas AQL podem ser construídas para acessar dados
com base em caminhos.
Lianas et Projeta a arquitetura PyEHR contendo os módulos de Gerenciamento
al. (2014) de Dados e Motor de Consultas. A arquitetura gera escalabilidade sobre
[35]
o volume de dados ao oferecer interfaces que podem ser implementadas
por diferentes SGBDs.
Paul
e Apresenta o modelo de dados OEAV (EAV otimizado) aplicado sobre
Hoque
a classe Observation. Este estudo detalha o mapeamento do HL7 RIM
(2010)
para a representação física de dados. No OEAV cada Atributo é repre[48]
sentado por um código que é concatenado ao Valor e são aplicados índices sobre a Entidade. Isso reduz o consumo de memória e torna a busca
eficiente.
Atalag et Apresenta o sistema GastrOS, onde os dados clínicos são serializados
al. (2011) em XML e persistidos em um BD relacional no MS Acess e SQLite.
[1]
Apêndice A
Muñoz et Desenvolve um servidor como prova de conceito do padrão EN13606
al. (2007) em que cada classe do MR é mapeada para uma tabela relacional. En[43]
tretanto, o servidor apresenta um desempenho de persistência inviável
quando aplicado em um cenário real
Austin et Importa dados de um sistema legado do projeto Synapses para um MR
al. (2009) genérico. A implementação do MR é avaliada através da revisão do
[2]
conteúdo de um servidor de RESs. A análise considera, principalmente,
a porcentagem de uso de cada classe do MR.
Humm
Descreve os requisitos necessários para o desenvolvimento de um gee Walsh renciador de RESs. Também apresenta um modelo de dados baseado no
(2015)
HL7 RIM, mas restrito a um estudo de caso. A modelagem de conceitos
[29]
é feita em uma planilha e o gerenciador de RES é gerado automaticamente. Uma ferramenta ORM é utilizada para mapear as classes para
tabelas de hierarquias.
Bahga e Desenvolve a arquitetura CHISTAR implantada na nuvem. O sistema
Madisetti estende arquétipos openEHR, adaptando o MR do openEHR e do HL7.
(2013)
Os registros são armazenados no BD HBase conforme os tipos de
[3]
dados do MR. Além disso, um motor de integração converte RESs de
diferentes fontes para arquivos planos.
Flemming Desenvolve um sistema para armazenar informações para serem utilizaet
al. das durante as trocas de turnos. É apresentado um modelo de informa(2014)
ção baseado no openEHR RIM. As classes são mapeadas para tabelas
[21]
através do Hibernate.
Kropf et Apresenta um sistema em que os arquivos XML gerados pelo openEHR
al. (2015) são inseridos em modelos do XForms. Assim, a interface gráfica e os
[32]
campos de entrada são conectados diretamente ao XML pelo XForms.
Consequentemente, os dados podem ser persistidos em um BD XML
utilizando o eXistdb e os RESs por uma interface REST.
Li et al. Desenvolve um repositório para armazenar documentos CDA em um
(2007)
BD XML com alta performance e disponibilidade. O repositório é
[34]
organizado hierarquicamente e centrado no paciente, com separação de
visitas e versões. Já que o desempenho das consultas decresce com o
volume de dados, são utilizados índices baseados em árvore B e XPath.
LópezDesenvolve o sistema iCabiNET baseado no padrão EN 13606, para
Nores et dar suporte a medicações, interagindo com repositórios domésticos e
al. (2012) móveis. O sistema fornece serviços baseados na tecnologia SOAP e
[36]
armazena os dados em um BD relacional através de uma interface
JDBC do MySQL. O sistema também apresenta uma camada ADL que
manipula instâncias de arquétipos do repositório CKM.
Madaan
Desenvolve um sistema cliente-servidor utilizando um BD NoSQL com
et
al. MongoDB. Além disso, apresenta o mecanismo de consulta AQBE
(2013)
(Consulta-Por-Exemplo baseada em Arquétipos) que abstrai a comple[37]
xidade sintática das consultas. O sistema suporta índices de árvore B,
mas não permite consultas baseadas em população.
85
Apêndice A
Osorio et Evolui a plataforma eHealthCom, relacionada à assistência de idosos
al. (2013) em casa, ao possibilitar o gerenciamento de RESs. A aplicação utiliza
[46]
um repositório openEHR, integrado à mensagens HL7, que insere composições nos registros em um BD XML.
Sundvall Explora a arquitetura REST sobre sistemas críticos distribuidos baseaet
al. dos no openEHR. São detalhados diversos tipos de tecnologias possí(2013)
veis de serem usadas e seus impactos, além do método de consulta de
[52]
RES. O estudo também apresenta a plataforma LiU EEE (Linköping
University Educational EHR Environment) para armazenar RESs em
BDs XML focado na abordagem baseada em indivíduos.
Freire et Converte 4 BDs relacionais convencionais, com mais de 4 milhões
al. (2016) de RESs, em BDs NoSQL, XML e relacional conforme o padrão
[24]
openEHR. Sobre esses BDs são avaliados o tempo de resposta de 8
consultas baseadas em população. Além disso, o NoSQL é avaliado em
um ambiente distribuído.
Lee et al. O estudo gera um MC a partir de conceitos extraídos de um BD
(2013)
convencional e mapeia o BD para o formato HL7 CDA contendo dados
[33]
estruturados em árvore conforme o MC. O conteúdo do documento
CDA gerado é persistido nos BDs de modo que, para cada conceito
de cada RES, é inserida uma tupla em um BD NoSQL utilizando
pares generalizados de chave-valor. O BD NoSQL é mais rápido, por
outro lado os BDs XML nativo e não-nativo são escaláveis, flexíveis e
extensíveis.
Freire et Desenvolve um protótipo que persiste os dados em duas tabelas relacial. (2008) onais no PostgreSQL: uma com campos para o caminho do arquétipo,
[23]
o valor do atributo definido pelo caminho e o identificador único do
registro com os dados; e outra com campos para o identificador único
do paciente e o texto XML serializado dos dados do paciente. O trabalho afirma que o protótipo é viável sem apresentar demonstrações ou
experimentos.
Muirhead Realiza uma avaliação preliminar para encontrar problemas e oportuni(2011)
dades na persistência de um modelo de objetos recursivo linear simples
[42]
com os SGBDs Db4o e Caché da Intersystem para BDs OO. Na avaliação final, um protótipo da camada de persistência, com ambos SGBDs,
é comparada a uma solução em SQL Server que utiliza o padrão Fast
Infoset e outra com uma base XML.
86
APÊNDICE B
Mapeamento das classes do MR
As classes do MR foram mapeadas para a estrutura da Tabela B.1. Com relação
ao tamanho médio em bytes, S representa o tamanho ocupado pelos dados e meta-dados
de uma String, L por uma lista e B por um objeto de tipo variável. As classes são
separadas por subpacotes, os quais são combinados em pacotes versionados. Por exemplo,
OBSERVATION, do subpacote “composition.entry” (pacote composition, versão 1.0.4) é
identificada pelo tipo 76 e requer um tamanho total de 187 ∗ S + 38 ∗ B + 39 ∗ L + 185
bytes.
Tabela B.1: Planilha com o mapeamento das classes do MR
Id.
Nome
da classe
Tamanho médio
em bytes
Nome e tipo dos
campos (em ordem)
Observação
Pacote: data_types; versão: 1.0.3
DATA_VALUE
1
1
tipo
Abstrata
data_types.uri
1
DV_URI
1
S
1+S
dataValue
value_String
Herança
2
DV_EHR_URI
1+S
1+S
dvURI
Herança
data_types.text
3
DV_PARAGRAPH 1
L
1+L
dataValue
items_ListDvText
Herança
Polimórfico
Apêndice B
4
DV_TEXT
88
1
S
S
L
1+S
2*S+2
2*S+2
7*S+L+6
dataValue
formatting_String
value_String
mappings_ListTermMapping
hyperlink_DvUri
language_CodePhrase
encoding_CodePhrase
5
CODE_PHRASE
1
S
1+S
2*S+2
tipo
codeString_String
terminologyId_TerminologyId
6
DV_CODED_TEXT
7*S+L+6
2*S+2
9*S+L+8
dvText
definingCode_CodePhrase
7
TERM_MAPPING
1
match_Char
2*S+2
target_CodePhrase
9*S+L+8
purpose_DvCodedText
11*S+L+10
Herança
Polimórfico
Herança
data_types.basic
8
DV_BOOLEAN
1
1
2
dataValue
value_Boolean
Herança
9
DV_IDENTIFIER
1
S
S
S
S
4*S+1
dataValue
issuer_String
assigner_String
id_String
type_String
Herança
10
DV_STATE
1
1
9*S+L+8
9*S+L+10
dataValue
isTerminal_Boolean
value_DvCodedText
Herança
Apêndice B
89
data_types.encapsulated
DV_ENCAPSULATED 1
2*S+2
2*S+2
4*S+5
dataValue
charset_CodePhrase
language_CodePhrase
Herança
Abstrata
Abstrata
Abstrata
11
DV_MULTIMEDIA
4*S+5
1
1
4
S
2*S+2
2*S+2
10*S+L+4+12
L
1+S
20*S+2*L+32
dvEncapsulated
Herança
integrityCheck_byte
data_byte
size_Integer
alternateText_String
mediaType_CodePhrase
compAlg_CodePhrase
thumbnail_DvMultimedia
checkAlg_ListCodePhrase
uri_DvUri
Polimórfico
12
DV_PARSABLE
4*S+5
S
S
6*S+5
dvEncapsulated
value_String
formalism_String
Herança
data_types.time_specification
DV_TIME_
SPECIFICATION
13
14
1
dataValue
6*S+5
6*S+6
value_DvParsable
DV_GENERAL_
6*S+6
TIME_SPECIFICATION
6*S+6
DV_PERIODIC_
6*S+6
TIME_SPECIFICATION
6*S+6
Herança
Abstrata
dvTimeSpecification
Herança
dvTimeSpecification
Herança
data_types.quantity
15
DV_INTERVAL <T>
2*B+7
2*B+7
intervalT
Herança
Apêndice B
16
17
REFERENCE_
RANGE<T>
90
1
tipo
7*S+L+6
2*B+7
7*S+L+2*B+14
meaning_DvText
range_DvIntervalT
Polimórfico
DV_ORDERED<T> 1
2*B+7
2*S+2
L
2*S+2*B+L+10
dataValue
Herança
normalRange_DvIntervalT
normalStatus_CodePhrase
other_ListReferenceRangeT
Abstrata
DV_ORDINAL
2*S+2*B+L+10
9*S+L+8
4
11*S+2*B+2*L+22
dvOrderedDvOrdinal
symbol_DvCodedText
value_Integer
Herança
2*S+2*B+L+10
dvOrderedT
Herança
B
S
3*S+3*B+L+10
accuracy_Any
magnitudeStatus_String
Polimórfico
3*S+3*B+L+10
1
3*S+3*B+L+11
dvQuantifiedTFloat
Herança
accuracyIsPercent_Boolean
Abstrata
3*S+3*B+L+10
dvQuantifiedTS
DV_QUANTIFIED
<T, S>
DV_AMOUNT<T>
DV_ABSOLUTE_
QUANTITY<T, S>
Abstrata
3*S+3*B+L+10
Herança
Abstrata
18
DV_PROPORTION
3*S+3*B+L+11
4
4
4
4
3*S+3*B+L+27
dvAmountDvProportion
numerator_Float
denominator_Float
type_int
precision_int
Herança
19
DV_COUNT
3*S+3*B+L+11
8
3*S+3*B+L+19
dvAmountDvCount
magnitude_Integer64
Herança
20
DV_QUANTITY
3*S+3*B+L+11
4
4
S
4*S+3*B+L+19
dvAmountDvQuantity
precision_Integer
magnitude_Float
units_String
Herança
Apêndice B
91
data_types.datetime
DV_TEMPORAL<T> 3*S+3*B+L+10
dvAbsoluteQuantity
TDvDuration
3*S+3*B+L+10
Herança
Abstrata
21
DV_DURATION
3*S+3*B+L+11
S
4*S+3*B+L+11
dvAmountDvDuration
value_String
Herança
22
DV_TIME
3*S+3*B+L+10
S
4*S+3*B+L+10
dvTemporalDvTime
value_String
Herança
23
DV_DATE_TIME
3*S+3*B+L+10
S
4*S+3*B+L+10
dvTemporalDvDateTime
value_String
Herança
24
DV_DATE
3*S+3*B+L+10
S
4*S+3*B+L+10
dvTemporalDvDate
value_String
Herança
Pacote: support; versão: 1.0.4
support.identification
UID
1
S
1+S
tipo
value_String
Abstrata
25
INTERNET_ID
1+S
1+S
uid
Herança
26
ISO_OID
1+S
1+S
uid
Herança
27
UUID
1+S
1+S
uid
Herança
OBJECT_ID
1
S
1+S
tipo
value_String
1+S
1+S
objectId
UID_BASED_ID
Abstrata
Herança
Abstrata
Apêndice B
92
28
ARCHETYPE_ID
1+S
1+S
objectId
Herança
29
TEMPLATE_ID
1+S
1+S
objectId
Herança
30
GENERIC_ID
1+S
S
1+2*S
objectId
scheme_String
Herança
31
TERMINOLOGY_ID
1+S
1+S
objectId
Herança
32
OBJECT_VERSION_ID 1+S
1+S
uidBasedId
Herança
33
HIER_OBJECT_ID
1+S
1+S
uidBasedId
Herança
34
OBJECT_REF
1
S
S
1+S
3*S+2
tipo
namespace_String
type_String
id_ObjectId
Polimórfico
35
ACCESS_GROUP_REF 3*S+2
3*S+2
objectRef
Herança
36
PARTY_REF
3*S+2
3*S+2
objectRef
Herança
37
LOCATABLE_REF
3*S+2
S
4*S+2
objectRef
path_String
Herança
38
VERSION_TREE_ID
1
S
1+S
tipo
value_String
Pacote:
common; versão 1.0.4
common.archetyped
PATHABLE
1
1
tipo
Abstrata
Apêndice B
39
40
FEEDER_AUDIT_
DETAILS
FEEDER_AUDIT
93
1
tipo
4*S+L+3
4*S+L+3
4*S+3*B+L+10
3*S+3
S
S
17*S+3*B+3*L+20
provider_PartyIdentified
location_PartyIdentified
time_DvDateTime
subject_PartyProxy
versionId_String
systemId_String
1
17*S+3*B+3*L+20
17*S+3*B+3*L+20
4*S+5
L
L
38*S+6*B+8*L+45
tipo
oa_FeederAuditDetails
fa_FeederAuditDetails
oc_DvEncapsulated
os_ListDvIdentifier
fi_ListDvIdentifier
Polimórfico
Polimórfico
Polimórfico
Polimórfico
41
ARCHETYPED
1
1+S
1+S
S
3*S+3
tipo
archetypeId_ArchetypeId
templateId_TemplateId
rmVersion_String
42
LINK
1
7*S+L+6
7*S+L+6
1+S
15*S+2*L+14
tipo
meaning_DvText
type_DvText
target_DvEhrUri
1
1+S
7*S+L+6
3*S+3
38*S+6*B+8*L+45
L
S
50*S+6*B+10*L+56
tipo
uid_T
Polimórfico
name_DvText
Polimórfico
archetypeDtls_Archetyped
feederAudit_FeederAudit
links_ListLink
archetypeNodeId_String
Abstrata
LOCATABLE<T>
Polimórfico
Polimórfico
common.change_control
VERSION
1
3*S+2
24*S+3*B+3*L+28
S
28*S+3*B+3*L+31
tipo
contribution_ObjectRef
commitAd_AuditDetails
signature_String
Polimórfico
Polimórfico
Abstrata
Apêndice B
43
ORIGINAL_
VERSION<T>
94
28*S+3*B+3*L+31 Version
1+S
1+S
9*S+L+8
L
L
1+B
39*S+4*B+5*L+46
44
IMPORTED_
VERSION<T>
Herança
uid_ObjectVersionId
preV_ObjectVersionId
lifecycState_DvCodedText
other_ListObjectVersionId
attestions_ListAttestation
data_T
Polimórfico
28*S+3*B+3*L+31 Version
Herança
39*S+4*B+5*L+46 item_OriginalVersionT
67*S+7*B+8*L+77
45
46
VERSIONED_
OBJECT
CONTRIBUTION
1
1+S
3*S+2
4*S+3*B+L+10
8*S+3*B+L+14
tipo
uid_HierObjectId
ownerId_ObjectRef
timeCreated_DvDateTime
1
1+S
24*S+3*B+3*L+28
L
25*S+3*B+4*L+30
tipo
uid_HierObjectId
audit_AuditDetails
versions_ListObjectRef
Polimórfico
Polimórfico
Polimórfico
common.generic
47
AUDIT_DETAILS
1
3*S+3
4*S+3*B+L+10
9*S+L+8
7*S+L+6
S
24*S+3*B+3*L+28
tipo
commiter_PartyProxy
Polimórfico
tCommited_DvDateTime
changeType_DvCodedText
description_DvText
Polimórfico
systemId_String
48
ATTESTATION
24*S+3*B+3*L+28
1
20*S+2*L+32
7*S+L+6
1+S
S
53*S+3*B+6*L+68
auditDetails
isPending_Boolean
attView_DvMultimedia
reason_DvText
items_DvEhrUri
proof_String
Herança
Polimórfico
Apêndice B
49
50
51
52
REVISION_
HISTORY_ITEM
95
1
tipo
1+S
L
S+L+2
versionId_ObjectVersionId
audits_ListAuditDetails
1
tipo
L
L+1
it_ListRevisionHistoryItem
PARTICIPATION
1
3*S+3
7*S+L+6
9*S+L+8
2*B+7
20*S+3*L+2*B+25
tipo
perfomer_PartyProxy
Polimórfico
function_DvText
Polimórfico
mode_DvCodedText
time_DvIntervalDvDateTime
PARTY_PROXY
1
3*S+2
3*S+3
tipo
externalRef_PartyRef
3*S+3
partyProxy
L
S
4*S+L+3
identifiers_ListDvIdentifier
name_String
REVISION_
HISTORY
PARTY_
IDENTIFIED
Polimórfico
Abstrata
Herança
53
PARTY_RELATED 4*S+L+3
9*S+L+8
13*S+2*L+11
partyIdentified
relantionship_DvCodedText
Herança
54
PARTY_SELF
partyProxy
Herança
3*S+3
3*S+3
common.resource
55
TRANSLATION
_DETAILS
1
tipo
2*S+2
2*L
2*L
S
1
language_CodePhrase
otherDtls_HashStringString
author_HashStringString
accreditation_String
Apêndice B
56
57
96
RESOURCE_
DESCRIPTION 1
_ITEM
2*S+2
2*L
2*L
L
S
S
S
S
6*S+2+5*L+1
RESOURCE_
1
DESCRIPTION
4*S+8*L+5
2*L
2*L
L
L
S
S
6*S+14*L+6
AUTHORED_
RESOURCE
tipo
language_CodePhrase
origRsrcUri_HashStringString
otherDetails_HashStringString
keywords_ListString
purpose_String
use_String
misuse_String
copyright_String
tipo
parentRsrc_AuthoredResource Polimórfico
origAuthor_HashStringString
otherDetails_HashStringString
otherContributors_ListString
dt_ListResourceDescriptionItem
lifecycleState_String
resourcePackageUri_String
1
isControlled_Boolean
2*S+2
2*S+6*L+1
L+1
L
4*S+8*L+5
originalLanguage_CodePhrase
descr_ResourceDescription
revHistory_RevisionHistory
transl_ListTranslationDetails
Abstrata
common.directory
58
59
FOLDER
50*S+6*B+10*L+56 locatable
L
folders_ListFolder
L
items_ListObjectRef
50*S+6*B+12*L+56
VERSIONED_
8*S+3*B+L+14
FOLDER
8*S+3*B+L+14
versionedObject
Pacote: data_structures; versão: 1.0.3
data_structures.representation
Herança
Polimórfico
Herança
Apêndice B
97
ITEM
50*S+6*B+10*L+56
50*S+6*B+10*L+56
locatable
60
ELEMENT
50*S+6*B+10*L+56
9*S+L+8
B
59*S+7*B+11*L+64
item
Herança
nullFlavour_DvCodedText
value_DataValue
Polimórfico
61
CLUSTER
50*S+6*B+10*L+56
L
50*S+6*B+11*L+56
item
items_ListItem
Herança
Abstrata
Herança
Polimórfico
data_structures.item_structure
DATA_STRUCTURE 50*S+6*B+10*L+56
50*S+6*B+10*L+56
locatable
Herança
Abstrata
ITEM_STRUCTURE 50*S+6*B+10*L+56
50*S+6*B+10*L+56
dataStructure
Herança
Abstrata
62
ITEM_LIST
50*S+6*B+10*L+56
L
50*S+6*B+11*L+56
itemStructure
items_ListElement
Herança
Polimórfico
63
ITEM_TREE
50*S+6*B+10*L+56
L
50*S+6*B+11*L+56
itemStructure
items_ListItem
Herança
Polimórfico
64
ITEM_SINGLE
50*S+6*B+10*L+56 itemStructure
50*S+6*B+10*L+56 item_Element
100*S+12*B+20*L+112
Herança
65
ITEM_TABLE
50*S+6*B+10*L+56
L
50*S+6*B+11*L+56
Herança
itemStructure
rows_ListCluster
data_structures.history
EVENT
50*S+6*B+10*L+56
4*S+3*B+L+10
B
B
54*S+11*B+20*L+66
locatable
time_DvDateTime
state_ItemStructure
data_ItemStructure
Herança
Polimórfico
Polimórfico
Abstrata
Apêndice B
98
66
INTERVAL_EVENT 54*S+11*B+20*L+66
4
4*S+3*B+L+11
9*S+L+8
67*S+14*B+22*L+89
event
Herança
sampleCount_Integer
width_DvDuration
mathFunc_DvCodedText
67
POINT_EVENT
54*S+11*B+20*L+66 event
54*S+11*B+20*L+66
Herança
68
HISTORY
50*S+6*B+10*L+56
4*S+3*B+L+10
4*S+3*B+L+11
4*S+3*B+L+11
B
L
62*S+15*B+14*L+88
Herança
dataStructure
origin_DvDateTime
period_DvDuration
duration_DvDuration
summary_ItemStructure
events_ListEvent
Polimórfico
Polimórfico
Pacote: composition; versão: 1.0.4
69
EVENT_CONTEXT 1
B
4*S+3*B+L+10
4*S+3*B+L+10
9*S+L+8
B
L
S
18*S+7*B+4*L+29
pathable
Herança
hlthFacilty_PartyIdentified Polimórfico
startTime_DvDateTime
endTime_DvDateTime
setting_DvCodedText
otherCt_ItemStructure
Polimórfico
partp_ListParticipation
location_String
70
COMPOSITION
locatable
Herança
context_EventContext
composer_PartyProxy
Polimórfico
category_DvCodedText
language_CodePhrase
territory_CodePhrase
content_ListContentItem Polimórfico
50*S+6*B+10*L+56
18*S+7*B+4*L+29
B
9*S+L+8
2*S+2
2*S+2
L
81*S+14*B+16*L+97
composition.content
CONTENT_ITEM
50*S+6*B+10*L+56
50*S+6*B+10*L+56
locatable
composition.navigation
Herança
Abstrata
Apêndice B
71
SECTION
99
50*S+6*B+10*L+56
L
50*S+6*B+11*L+56
contentItem
items_ListContentItem
Herança
Polimórfico
composition.entry
72
ACTIVITY
73
INSTRUCTION
_DETAILS
74
50*S+6*B+10*L+56
B
6*S+5
S
51*S+13*B+10*L+61
locatable
Herança
description_ItemStructure Polimórfico
timing_DvParsable
actionArchetypeId_String
1
pathable
4*S+2
B
S
5*S+B+3
instructionId_LocatableRef
wfDetails_ItemStructure Polimórfico
activityId_String
Herança
ISM_TRANSITION 1
9*S+L+8
9*S+L+8
9*S+L+8
L
27*S+4*L+9
pathable
Herança
currentState_DvCodedText
transition_DvCodedText
careflowStep_DvCodedText
reason_ListDvText
Polimórfico
ENTRY
50*S+6*B+10*L+56
2*S+2
2*S+3
3*S+3
3*S+3
3*S+2
L
63*S+6*B+11*L+69
contentItem
language_CodePhrase
encoding_CodePhrase
subject_PartyProxy
provider_PartyProxy
workflowId_ObjectRef
otherP_ListParticipation
CARE_ENTRY
63*S+6*B+11*L+69
B
B
63*S+8*B+11*L+69
entry
protocol_ItemStructure
guidelineId_ObjectRef
Herança
Polimórfico
Polimórfico
Abstrata
75
ADMIN_ENTRY
63*S+6*B+11*L+69
B
63*S+7*B+11*L+69
entry
data_ItemStructure
Herança
Polimórfico
76
OBSERVATION
63*S+8*B+11*L+69 careEntry
Herança
62*S+15*B+14*L+88 data_HistoryItemStructure
62*S+15*B+14*L+88 state_HistoryItemStructure
187*S+38*B+39*L+185
Herança
Polimórfico
Polimórfico
Polimórfico
Abstrata
Apêndice B
100
77
EVALUATION
63*S+8*B+11*L+69 careEntry
B
data_ItemStructure
63*S+9*B+11*L+69
Herança
Polimórfico
78
INSTRUCTION
63*S+8*B+11*L+69 careEntry
B
narrative_DvText
4*S+3*B+L+10
expiryTime_DvDateTime
6*S+5
wfDefinition_DvParsable
L
activities_ListActivity
74*S+11*B+13*L+84
Herança
Polimórfico
79
ACTION
63*S+8*B+11*L+69 careEntry
4*S+3*B+L+10
time_DvDateTime
27*S+4*L+9
itr_IsmTransition
5*S+B+3
idt_InstructionDetails
B
description_ItemStructure
99*S+13*B+15*L+91
Herança
Polimórfico
Pacote: demografic; versão: 1.0.4
PARTY
50*S+6*B+10*L+56
B
L
L
L
L
50*S+7*B+14*L+56
locatableHierObjectId
Herança
details_ItemStructure
Polimórfico
identities_ListPartyIdentity
contacts_ListContact
reverseRel_ListLocatableRef
rel_ListPartyRelationship
Abstrata
80
ROLE
50*S+7*B+14*L+56
2*B+7
1+S
L
51*S+9*B+15*L+64
party
Herança
tValidity_DvIntervalDvDate
performer_PartyRef
capabilities_ListCapability
81
PARTY_
RELATIONSHIP
50*S+6*B+10*L+56 locatable
1+S
1+S
B
2*B+7
52*S+9*B+10*L+65
82
Herança
source_PartyRef
target_PartyRef
details_ItemStructure
Polimórfico
tValidity_DvIntervalDvDate
PARTY_IDENTITY 50*S+6*B+10*L+56 locatable
B
details_ItemStructure
50*S+7*B+10*L+56
Herança
Polimórfico
Apêndice B
101
83
CONTACT
50*S+6*B+10*L+56 locatable
Herança
2*B+7
tValidity_DvIntervalDvDate
L
addresses_ListAddress
50*S+8*B+1’*L+63
84
ADDRESS
50*S+6*B+10*L+56 locatable
B
details_ItemStructure
50*S+7*B+10*L+56
85
CAPABILITY
50*S+6*B+10*L+56 locatable
Herança
B
credentials_ItemStructure
Polimórfico
2*B+7
tValidity_DvIntervalDvDate
50*S+9*B+10*L+63
86
ACTOR
50*S+7*B+14*L+56 party
L
languages_ListDvText
L
roles_ListPartyRef
50*S+7*B+16*L+56
Herança
Polimórfico
87
PERSON
50*S+7*B+16*L+56 actor
50*S+7*B+16*L+56
Herança
88
ORGANISATION
50*S+7*B+16*L+56 actor
50*S+7*B+16*L+56
Herança
89
GROUP
50*S+7*B+16*L+56 actor
50*S+7*B+16*L+56
Herança
90
AGENT
50*S+7*B+16*L+56 actor
50*S+7*B+16*L+56
Herança
Herança
Polimórfico
Pacote: ehr; versão: 1.0.4
91
92
EHR
VERSIONED_
EHR_ACCESS
1
1+S
1+S
3*S+2
3*S+2
3*S+2
4*S+3*B+L+10
L
L
15*S+3*B+3*L+17
tipo
systemId_HierObjectId
ehrId_HierObjectId
ehrStatus_ObjectRef
ehrAccess_ObjectRef
directory_ObjectRef
timeCreated_DvDateTime
contributions_ListObjectRef
compositions_ListObjectRef
Polimórfico
Polimórfico
Polimórfico
8*S+3*B+L+14
versionedObject
Herança
8*S+3*B+L+14
Polimórfico
Polimórfico
Apêndice B
102
93
VERSIONED_
EHR_ACCESS
50*S+6*B+10*L+56 locatable
Herança
B
st_AccessControlSettings
50*S+7*B+10*L+56
94
VERSIONED_
EHR_STATUS
8*S+3*B+L+14
8*S+3*B+L+14
versionedObject
Herança
95
EHR_STATUS
50*S+6*B+10*L+56
1
1
3*S+3
B
53*S+7*B+10*L+61
locatable
isQueryable_Boolean
isModifiable_Boolean
subject_PartySelf
otherDt_ItemStructure
Herança
8*S+3*B+L+14
8*S+3*B+L+14
versionedObject
Herança
96
VERSIONED_
COMPOSITION
Polimórfico
Pacote: integration; versão: 1.0.1
97
GENERIC_ENTRY
50*S+6*B+10*L+56 contentItem
50*S+6*B+11*L+56 data_ItemTree
100*S+12*B+20*L+112
Herança
Pacote: ehr_extract; versão: 1.0.4
ehr_extract.common
98
EXTRACT_REQUEST50*S+6*B+10*L+56 locatableHierObjectId
Herança
9*S+2*B+2*L+29
extractSpec_ExtractSpec
6*S+3*B+2*L+15
updateSpec_UpdateSpec
65*S+11*B+14*L+100
99
EXTRACT_ACTION 50*S+6*B+10*L+56 locatableHierObjectId
_REQUEST
3*S+2
requestId_ObjectRef
9*S+L+8
action_DvCodedText
62*S+6*B+11*L+66
100 EXTRACT_SPEC
1
1
4
4
2*B+11
1+L
9*S+L+8
L
9*S+2*B+2*L+30
Herança
Polimórfico
tipo
includeMultimedia_Boolean
priority_Integer
linkDepth_Integer
vSpec_ExtractVersionSpec
manifest_ExtractManifest
extractType_DvCodedText
criteria_ListDvParsable
Apêndice B
103
101 EXTRACT_
MANIFEST
1
L
1+L
tipo
e_ListExtractEntityManifest
102 EXTRACT_ENTITY
_MANIFEST
1
S
S
S
L
L
4*S+2*L+1
tipo
extractIdKey_String
ehrtId_String
subjectId_String
otherIds_ListString
itemList_ListObjectRef
Polimórfico
8*S+3*B+L+14
8*S+3*B+L+14
versionedObject
Herança
103 VERSIONED_
COMPOSITION
104 EXTRACT_VERSION 1
_SPEC
1
1
1
2*B+7
2*B+11
tipo
incAllVersions_Boolean
incRevHistory_Boolean
incData_Boolean
cm_DvIntervalDvDateTime
105 EXTRACT_
UPDATE_SPEC
1
1
4*S+3*B+L+11
2*S+2
L
6*S+3*B+2*L+15
tipo
persistInServer_Boolean
repeatPeriod_DvDuration
updateMethod_CodePhrase
triggerEv_ListDvCodedText
106 EXTRACT
50*S+6*B+10*L+56 locatable
Herança
4
sequenceNr_Integer
9*S+2*B+2*L+29
specification_ExtractSpec
1+S
requestId_HierObjectId
1+S
systemId_HierObjectId
4*S+3*B+L+10
timeCreated_DvDateTime
L
p_ListExtractParticipation
63*S+11*B+14*L+95
107 EXTRACT_
CHAPTER
50*S+6*B+10*L+56 locatable
L
items_ListExtractItem
50*S+6*B+11*L+56
Herança
108 EXTRACT_ENTITY
_CHAPTER
50*S+6*B+11*L+56 extractChapter
S
extractIdKey_String
51*S+6*B+11*L+56
Herança
Apêndice B
EXTRACT_ITEM
104
50*S+6*B+10*L+56 locatable
50*S+6*B+10*L+56
109 EXTRACT_FOLDER 50*S+6*B+10*L+56 extractItem
L
items_ListExtractItem
50*S+6*B+11*L+56
EXTRACT
_CONTENT
_ITEM<S>
110 EXTRACT_
PARTICIPATION
Herança
Abstrata
Herança
Polimórfico
50*S+6*B+10*L+56
1
1
1
B
50*S+7*B+10*L+59
extractItem
isPrimary_Boolean
isChanged_Boolean
isMasked_Boolean
item_Any
Herança
1
2*B+7
S
B
9*S+L+8
10*S+3*B+L+16
tipo
t_DvIntervalDvDateTime
performer_String
function_DvText
Polimórfico
mode_DvCodedText
Polimórfico
Abstrata
ehr_extract.openehr_extract
111 OPENEHR_
CONTENT_ITEM
50*S+7*B+10*L+59 extractContentItem
50*S+7*B+10*L+59 XVersionedObject
Herança
112 X_VERSIONED
_OBJECT
1
4
4
1+S
3*S+2
4*S+3*B+L+10
L+1
L
8*S+3*B+3*L+23
tipo
totalVersionCount_Integer
extVersionCount_Integer
uid_HierObjectId
ownerId_ObjectRef
Polimórfico
timeCreated_DvDateTime
revHist_RevisionHistory
vers_ListOriginalVersion
113 X_VERSIONED_
EHR_ACCESS
8*S+3*B+3*L+23
8*S+3*B+3*L+23
XVersionedObject
Herança
114 X_VERSIONED_
EHR_STATUS
8*S+3*B+3*L+23
8*S+3*B+3*L+23
XVersionedObject
Herança
115 X_VERSIONED
_COMPOSITION
8*S+3*B+3*L+23
8*S+3*B+3*L+23
XVersionedObject
Herança
Apêndice B
105
116 X_VERSIONED
_FOLDER
8*S+3*B+3*L+23
8*S+3*B+3*L+23
XVersionedObject
Herança
117 X_VERSIONED
_PARTY
8*S+3*B+3*L+23
8*S+3*B+3*L+23
XVersionedObject
Herança
ehr_extract.generic_extract
118 GENERIC
_CONTENT
_ITEM
50*S+7*B+10*L+59 extractContentItemLocatable Herança
9*S+L+8
itemType_DvCodedText
9*S+L+8
itemStatus_DvCodedText
4*S+3*B+L+10
creationT_DvDateTime
4*S+3*B+L+10
authorisationT_DvDateTime
S
author_String
S
authoriser_String
S
versionId_String
S
itemTypeVersion_String
S
versionSetId_String
S
systemId_String
2*L
otherDt_HashStringString
82*S+13*B+16*L+95
ehr_extract.sync_extract
119 SYNC_EXTRACT
_REQUEST
50*S+6*B+10*L+56 messageContent
4*S+3*B+2*L+12
spec_SyncExtractSpec
54*S+9*B+12*L+68
Herança
120 SYNC_EXTRACT
50*S+6*B+10*L+56 messageContent
4*S+3*B+2*L+13
spec_SyncExtractSpec
L
items_ListXContribution
54*S+9*B+13*L+68
Herança
121 SYNC_EXTRACT
_SPEC
1
1
1
4*S+3*B+L+10
L
4*S+3*B+2*L+13
122 X_CONTRIBUTION 1+S
24*S+3*B+3*L+28
L
25*S+3*B+4*L+28
tipo
includesVersions_Boolean
allContributions_Boolean
contrSince_DvDateTime
contrList_ListHierObjectID
uid_HierObjectId
audit_AuditDetails
versions_ListVersions
Polim.
Apêndice B
106
ehr_extract.message
MESSAGE_
CONTENT
50*S+6*B+10*L+56 locatable
50*S+6*B+10*L+56
Herança
Abstrata
123 ADDRESSED_
MESSAGE
1
4
77*S+9*B+10*L+88
S
S
L
79*S+9*B+11*L+93
tipo
urgency_Integer
message_Message
sender_String
senderReference_String
addresses_ListString
124 MESSAGE
1
24*S+3*B+3*L+28
50*S+6*B+10*L+56
3*S+3
S
77*S+9*B+10*L+88
tipo
audit_AuditDetails
Polimórfico
content_MessageContent Polimórfico
author_PartyProxy
Polimórfico
signature_String