Uma Revisão da Literatura sobre arquiteturas de
Propaganda
UNIVERSIDADE FEDERAL DO TOCANTINS Programa de Pós-Graduação em Modelagem Computacional de Sistemas Mestrado Profissional Interdisciplinar em Modelagem Computacional de Sistemas Campus Universitário de Palmas Elvis Nascimento da Silva Uma Revisão da Literatura sobre arquiteturas de Registros Eletrônicos de Saúde baseados em Arquétipos. PALMAS– TO 2016 UNIVERSIDADE FEDERAL DO TOCANTINS Programa de Pós-Graduação em Modelagem Computacional de Sistemas Mestrado Profissional Interdisciplinar em Modelagem Computacional de Sistemas Campus Universitário de Palmas Elvis Nascimento da Silva Uma Revisão da Literatura sobre arquiteturas de Registros Eletrônicos de Saúde baseados em Arquétipos. Dissertação apresentada ao Programa de PósGraduação em Modelagem Computacional de Sistemas da Universidade Federal do Tocantins, como pré-requisito parcial para a obtenção do título de Mestre em Modelagem Computacional de Sistemas. Orientador: Prof. Dr. Leandro Guimarães Garcia. Coorientador: Prof. Dr. Sergio Miranda Freire. PALMAS- TO 2016 Elvis Nascimento da Silva Uma Revisão da Literatura sobre arquiteturas de Registros Eletrônicos de Saúde baseados em Arquétipos. Dissertação apresentada ao Programa de PósGraduação em Modelagem Computacional de Sistemas da Universidade Federal do Tocantins, como pré-requisito parcial para a obtenção do título de Mestre em Modelagem Computacional de Sistemas. 1º Orientador: Prof. Dr. Leandro Guimarães Garcia. 2º Orientador: Prof. Dr. Sergio Miranda Freire. BANCA EXAMINADORA: ____________________________________________ Prof. Dr. Leandro Garcia Guimarães PPG MCS – UFT 1º Orientador ____________________________________________ Prof. Dr. Patrick Letouzé PPG MCS – UFT Membro Interno ____________________________________________ Prof. Dr. Michel Santos Silva IFTO Membro Externo ____________________________________________ Prof. Dr. Sérgio Miranda Freire UERJ 2º Orientador AGRADECIMENTOS Agradeço primeiramente a Deus, por me dar forças e guiar minha vida. A minha querida esposa e filhos que incondicionalmente sempre me apoiaram na condução deste trabalho. Ao primeiro orientador, Professor Leandro Guimaraes Garcia, pela dedicação, por sua competência e profissionalismo na condução das revisões e sugestões; Ao segundo coorientador Sérgio Miranda Freire, que embora distante, se dispôs com seus conhecimentos para o desenvolvimento deste trabalho. Agradeço a todos os professores do PPGMCS, por compartilharem seus conhecimentos, em especial aos professores David Nadler Prata, Patrick Letouze, pela dedicação ao programa. Agradeço a todos os colegas do mestrado, em especial aos já amigos Charles Jeffersosn Rodrigues Alves e Alves, Janio Carlos Nascimento Silva e Rafael Miranda Correia, pelas parcerias, incentivos e principalmente pela amizade. Aos colegas de trabalho do IFTO, pela compreensão e apoio. Agradeço ao professor e amigo Harry Richard Hamming Neto, pelo ser humano que é e por suas palavras motivacionais. E a todos que direta ou indiretamente participaram dessa trajetória. “A persistência é o menor caminho do êxito”. (Charles Chaplin) RESUMO Este trabalho apresenta uma revisão da literatura com o objetivo de realizar um levantamento das arquiteturas de Registros Eletrônicos de Saúde (RES) baseados em Arquétipos. RES é um repositório de informações relativo ao estado de saúde de um ou mais indivíduos, armazenado em forma processável pelo computador, transmitida com segurança e acessível por múltiplos usuários autorizados. Arquétipos são fragmentos que fornecem uma modelagem semântica de objetos. Podem ser usados para padronizar as estruturas da informação clínica e fornecem uma porta de entrada comum para o intercâmbio de dados. A norma ISO 13606 e o conjunto de especificações openEHR, atualmente ganham destaque na busca da interoperabilidade da informação clínica entre sistemas RES. Esta revisão utilizou critérios de inclusão e exclusão que levaram à inserção de 21 artigos sobre o tema, no período entre Jan/2007 a Mar/2016. As seguintes fontes foram utilizadas: (a) sítios da Fundação openEHR, da norma ISO 13606 e no repositório de artigos sobre openEHR, organizados por Koray Atalag, utilizando o gerenciador de referência Zotero; (b) as bases de dados Association for Computing Machinery (ACM) Digital Library, Institute of Electrical and Electronics Engineers (IEEE) Xplore, Elsevier, Emerald, ISI Web of Science, ScienceDirect e PubMed. Os resultados mostraram uma maior difusão de estudos na Europa. Diversas arquiteturas de sistemas de RES foram identificadas. Quanto aos mecanismos de persistência, os bancos de dados relacionais têm sido utilizados de forma não convencional, seja por mapeamento, por meio de frameworks ou middlewares, ou por algum suporte já implementado no gerenciador de banco de dados para persistirem os dados de maneira não relacional como, por exemplo, dados no formato XML. Os bancos de dados NoSQL MongoDB e Couchbase, por naturalmente trabalharem de modo distribuído, têm apresentado bons desempenhos, principalmente para consultas de base populacionais, em grandes quantidades de dados clínicos. Palavras-chave: Arquitetura, Registro Eletrônico em Saúde, Arquétipos, openEHR, ISO 13606 ABSTRACT This paper presents a literature review in order to carry out a survey of architectures of Electronic Health Records (RES) based on Archetypes. RES is a repository of information regarding the health status of one or more individuals, stored in a processable form by the computer, securelytransmitted, and accessible by multiple authorized users. Archetypes are fragments that provide a semantic object modeling. They can be used to standardize the structures of the clinical information and provide a common gateway for data exchange. The ISO 13606 standard and the set of openEHR specifications are currently on the spotlight in the search for interoperability of clinical information among RES systems. This review used inclusion and exclusion criteria that led to the inclusion of 21 articles on the topic, between Jan/2007 to Mar/2016. The following sources were used: (a) sites of the openEHR Foundation, the ISO 13606 standard and the repository of articles on openEHR, organized by Koray Atalag using the Zotero reference manager; (B) databases of the Association for Computing Machinery (ACM) Digital Library, Institute of Electrical and Electronics Engineers (IEEE) Xplore, Elsevier, Emerald, ISI Web of Science, ScienceDirect and PubMed. The results showed a greater difusion in Europe. Several architectures of RES systems have been identified. As for the persistence mechanisms, relational databases have been used unconventionally, either by mapping through frameworks or middleware or through some support already implemented in the database manager to persist data in no relational form, such as in the XML format. The MongoDB and Couchbase NoSQL databases, which natively work in distributed mode, have shown good performances, especially for population based queries in large amounts of clinical data. Keywords: Architecture, Electronic Health Record, Archetype, openEHR, ISO 13606. LISTA DE FIGURAS Figura 1. Diferença entre EHR, EMR................................................................................................. 20 Figura 2. Modelo de sinais vitais (pulso). Na definição em dois hospitais diferentes. ............... 24 Figura 3. Modelagem de único nível de desenvolvimento. ............................................................ 28 Figura 4. Modelagem de dois níveis (RM e AM) .............................................................................. 29 Figura 5. Representação “Dual Model” por meio do jogo de peças de LEGO®......................... 30 Figura 6. Etapas de elaboração da revisão da literatura. ............................................................... 33 Figura 7. Diagrama de fluxo de seleção dos Estudos..................................................................... 37 Figura 8. Difusão openEHR/ISO 13606 nos continentes. .............................................................. 45 Figura 9. Quantidade de estudos no período de 2007 a 2016. ..................................................... 47 Figura 10. Quantitativo de citações por estudo de acordo com sua classificação. ..................... 59 Figura 11. Persistência de dados utilizando mapeamento ARM (a), ORM (b) e XML (c). ........ 64 Figura 12. Armazenamento distribuído em banco de dados NoSQL mongoDB. ....................... 67 LISTA DE TABELAS Tabela 1: Bases de dados para a realização das buscas. ...................................................... 34 Tabela 2. Critérios de classificação dos trabalhos selecionados ............................................ 35 Tabela 3. Estudos excluídos de acordo com o critério adotado. ............................................ 36 Tabela 4. Quantitativo de estudos de acordo com a fonte pesquisada ................................... 36 Tabela 5. Informações das instituições que adotam openEHR em seus sistemas. ............... 38 Tabela 6. Fornecedoresdos quais foram solicitadas informações para este trabalho. ........... 40 Tabela 7. Campos da planilha para extração de informações dos artigos .............................. 42 Tabela 8. Estudos incluídos na revisão ................................................................................. 43 Tabela 9. Informações do produto Think!EHR Platform, da Marand. ...................................... 44 Tabela 10. Estudos incluídos localizados nas bases e sua seleção ....................................... 46 Tabela 11. Nomes dos produtos/projetos e local de desenvolvimento. .................................. 47 Tabela 12. Resumo dos estudos classificados como Sistemas RES .................................... 49 Tabela 13. Resumo dos estudos classificados como Sistemas de Integração/Plataforma. .... 52 Tabela 14. Resumo dos estudos classificados como Repositórios........................................ 55 Tabela 15. Variáveis qualitativas contidas nos projetos/produtos de estudo .......................... 60 LISTA DE ABREVIATURA E SIGLAS ACID Atomic, Consistent, Isolation and Durable AM Archetype Model AQL Archetype Query Language ARM Archetype Relational Mapping BASE Basically Available, Soft state, Eventually consistency) CKM Clinical Knowledge Manager EHR Electronic Health Record EMR Electronic Medical Record HIMSS Health Information and Management System Society HL7 Health Level 7 ISO International Organization for Standardization JSON JavaScript Object Notation MVC Model-view-controller NAHIT National Alliance for Health Information Technology) NoSQL Not Only SQL OO Orientação a Objetos ORM Object Relational Mapping PHR Personal Health Record RES Registro Eletrônico de Saúde RM Reference Model SGBD Sistemas de Gerenciamento de Banco de Dados SOAP Simple Object Access Protocol) SQL Structured Query Language SUS Sistema Único de Saúde TI Tecnologia da Informação WS Web Service XML eXtensible Markup Language SUMÁRIO CAPÍTULO I ........................................................................................................................... 13 1. Introdução ....................................................................................................................... 13 1.1 Justificativa .............................................................................................................. 16 1.2 Objetivo Geral .......................................................................................................... 18 1.2.1 1.3 Objetivos Específicos ........................................................................................ 18 Organização da Dissertação .................................................................................... 18 CAPÍTULO II .......................................................................................................................... 19 2. Referencial Teórico ......................................................................................................... 19 2.1 Registro Eletrônico de Saúde (RES) ........................................................................ 19 2.2 EHR x EMR ............................................................................................................. 20 2.3 Integração e Interoperabilidade em sistemas. .......................................................... 21 2.3.1 Integração vs. interoperabilidade ...................................................................... 22 2.3.2 Interoperabilidade Sintática e Semântica .......................................................... 22 2.4 Persistência de Dados ............................................................................................. 24 2.4.1 ACID x BASE .................................................................................................... 25 2.5 A Fundação openEHR ............................................................................................. 26 2.6 A norma ISO 13606 ................................................................................................. 27 2.7 Abordagem “Dual Model” ......................................................................................... 27 2.7.1 Arquétipos......................................................................................................... 30 CAPÍTULO III ......................................................................................................................... 33 3. Metodologia .................................................................................................................... 33 3.1 Elaboração do Projeto de Pesquisa ......................................................................... 33 3.2 Seleção e Avaliação Crítica dos Estudos Encontrados ............................................ 34 3.3 Coleta de Dados ...................................................................................................... 41 3.4 Agrupamento e apresentação dos dados ................................................................. 42 CAPÍTULO IV......................................................................................................................... 43 4. Resultados ...................................................................................................................... 43 4.1 Estudos incluídos na Revisão .................................................................................. 43 4.2 Difusão das especificações openEHR/ISO 13606 nos continentes .......................... 44 4.3 Frequência das publicações por ano e por base pesquisada ................................... 45 4.4 Projetos/Produtos apresentados nos estudos .......................................................... 47 4.5 Classificação dos estudos incluídos ......................................................................... 48 4.6 Taxa de citação........................................................................................................ 59 4.7 Tecnologias utilizadas nas arquiteturas ................................................................... 59 4.7.1 Comparação de arquiteturas de armazenamento ............................................. 62 CAPÍTULO V.......................................................................................................................... 69 5. Discussão ....................................................................................................................... 69 5.1 Metodologia de busca .............................................................................................. 69 5.2 Estágio das implementações openEHR ................................................................... 69 5.3 Arquiteturas dos Sistemas ....................................................................................... 70 5.4 Persistência de Dados ............................................................................................. 71 CAPÍTULO VI......................................................................................................................... 74 6. Conclusão ....................................................................................................................... 74 Referências ............................................................................................................................ 75 13 CAPÍTULO I 1. Introdução Um Sistema de Informação em Saúde(SIS) capaz de gerenciar as informações necessárias durante as diferentes etapas do processo de atendimento do paciente, pode ser crucial para os profissionais de saúde no processo de tomada de decisões, pois esses sistemas facilitam a comunicação e subsidiam a administração pública com informações valiosas(HIQA, 2013). Para a eficiência dos cuidados de saúde, os sistemas precisam ser desenvolvidos com o objetivo de favorecer a comunicação e transmissão de informações clínicas entre sistemas diferentes (ALMEIDA, 2013; KALRA, DIPAK, 2006).O novo paradigma de saúde eletrônica, e-Health 1, exige que sistemas e dispositivos de saúde permitam a integração transparente e interoperabilidade de seus dados(MARTÍNEZCOSTA et al., 2009). Um dos sistemas de informação mais importantes são os sistemas de Registro Eletrônico de Saúde (RES), do Inglês Eletronic Health Record – EHR. Um RES é um repositório de informações sobre o estado de saúde e assistência à saúde de um indivíduo, mantido eletronicamente, de modo que ele possa servir aos múltiplos e legítimos usos e usuários do registro (MCDONALD; TANG, P. C.; HRIPCSAK, 2014). Essas informações são categorizadas em várias seções, incluindo o contato do paciente, resumo das visitas ao médico, o diagnóstico do paciente, histórico médico e familiar, lista de prescrições, exames de saúde, tratamento, etc. (AMATO et al., 2012). Iniciativas vêm sendo discutidas envolvendo organismos de normatização, que definem uma arquitetura genérica de um RES para a comunicação de dados de saúde, tais como o CEN/ISO EN13606 2, openEHR3 e HL7 CDA 4. Essas organizações propõem padrões e especificações que possibilitem que as informações clínicas sejam interoperáveis entre os diversos RES de diferentes instituições ou em uma mesma instituição. A interoperabilidade visa facilitar as interações, permitindo a troca de informações e reutilização, entre sistemas de informação não homogêneos. 1 2 3 4 e-Saúde é qualquer aplicação de Internet focada na melhoraria do acesso, da eficiência, da efetividade e da qualidade dos processos clínicos e assistenciais necessários a toda a cadeia de prestação de serviços de saúde. HIMSS Analytics. Dispobível em: http://www.himss.org/. www.en13606.org www.openehr.org www.hl7.com.br 14 A interoperabilidade, de acordo com a norma ISO/TR 16056 5, é a habilidade de dois ou mais sistemas interagirem um com o outro, trocando informações de acordo com um método prescrito. Para sistemas baseados em RES, existem dois tipos de interoperabilidade básicos: sintática (funcional) e semântica. A sintática é quando dois ou mais sistemas estão interligados sintaticamente para troca dados. Para tal, é essencial a especificação de protocolos de comunicação que descrevam como esta troca deva ocorrer(POKRAEV, 2009). A interoperabilidade semântica é a capacidade de dois ou mais sistemas heterogêneos trabalharem em conjunto, compartilhando as informações entre eles com entendimento comum de seu significado, independentemente da intervenção humana (MARUT, 2001). A ISO (International Organization for Standardization) e a fundação openEHR apresentam uma abordagem comum para a comunicação e interoperabilidade semântica de RES que é baseada em uma arquitetura chamada “Dual Model”(ISO 13606, 2015; KALRA, Dipak; BEALE, Thomas; HEARD, Sam, 2005). Para compreender essa metodologia, é necessário visualizar o usual “modelo único”. MUNOZ (2007) afirma que, tradicionalmente, o desenvolvimento de sistemas de informação em saúde é realizado utilizando metodologias de um único nível de modelagem, em que os conceitos de domínio são codificados diretamente para o software e seus modelos de banco de dados. Esse tipo de relação permite relativamente um rápido desenvolvimento, porém, quando é aplicada em ambientes com alto grau de complexidade, no caso de dados clínicos de pacientes, esses sistemas de informações necessitam de atualizações frequentes. A arquitetura chamada “Dual Model” (Modelagem de dois níveis), procura solucionar essa situação, com a utilização de dois modelos relacionados: um Modelo de Referência (RM) e um Modelo de Objetos de Arquétipos (AM). O primeiro é um modelo genérico definido para a representação de dados e possui um número relativamente pequeno de classes genéricas fixas (BEALE, T et al., 2008). Esse modelo representa as estruturas genéricas de componentes de informação do registro de saúde. A base de dados da aplicação é construída a partir do RM (SACHDEVA; BHALLA, 2009). O segundo, os Arquétipos (AM), são uma camada de 5 ISO/TR 16056-1: 2004-- Interoperability of telehealth systems and networks Part 1: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37351 15 abstração entre o armazenamento e recuperação de informações em um RES específico(BARCA et al., 2014). Os arquétipos são usados para restringir as estruturas válidas de instâncias das classes genéricas do RM e fornecem uma modelagem semântica (independente da aplicação) (SACHDEVA; BHALLA, 2009). A principal finalidade do Arquétipo é fornecer uma maneira poderosa, reutilizável e interoperável, para a criação, validação e consulta do RES(MALDONADO et al., 2007). Nesse contexto, os arquétipos desempenham um papel importante na implementação da interoperabilidade entre RES. A modelagem de dois níveis permite que os sistemas se tornem mais sustentáveis, com um RM estável e os arquétipos dinâmicos. Com essa separação de modelos e independência de aplicações, a capacidade de adaptação dos sistemas aumenta significativamente(MARCOS et al., 2011). No cenário mundial, há projetos em andamento de RES baseados em arquétipos (ISO 13606 ou openEHR), como na Espanha [03, 06, 09, 11], Portugal [04, 14], China [15], Argentina [12] e Uruguai [13]. No Brasil já se cogita a utilização desses sistemas no Sistema Único de Saúde (SUS) 6 com maior ênfase no Estado de Minas Gerais. De acordo com (SANTOS, 2011), na Secretaria de Estado de Saúde de Minas Gerais (SES/MG) pretende criar um sistema de RES, em nível estadual, para consolidar dados demográficos e o sumário clínico para os pacientes, em apoio ao programa Saúde Família, na atenção primária. O autor desenvolveu uma proposta (tese) de arquitetura de sistema de RES compartilhável para a atenção primária do Estado de Minas Gerais, baseada nos modelos de referência e arquétipos da norma ISO13606. Até a presente data, não há informações da implementação da proposta. Neste estudo, o RES (EHR) se refere a um repositório de informações sobre o estado de saúde de um indivíduo, numa forma eletronicamente processável(ISO/TR 20514, 2005). Portanto, a presente pesquisa buscou identificar e analisar as arquiteturas de RES baseados em arquétipos da metodologia “Dual Model”, seja da Fundação OpenEHR ou da norma ISO 13606. 6 http://portalsaude.saude.gov.br/ 16 1.1 Justificativa O estabelecimento de interoperabilidade semântica entre sistemas de informação em saúde é provavelmente um dos desafios mais importantes da informática em saúde hoje (KUHN; OTHERS, 2007). No cenário mundial, há discussões na adoção de padrões ou especificações (HL7, ISO 13606 ou OpenEHR) para melhor implementarem seus sistemas de saúde. Os sistemas de informações em saúde, especificamente os Sistemas de Registro Eletrônico em Saúde (SRES) devem apresentar flexibilidade na representação do conhecimento específico na medicina, para suportar a complexidade do domínio e sua constante evolução. Além disso, a conectividade é um importante pré-requisito, no entanto, a diversidade de modelos e componentes constitui uma barreira para comunicação com outros sistemas. Diante de uma falta de padronização, significativas contribuições foram realizadas através da produção de especificações como o openEHR (openEHR, 2012). Diante da necessidade de alinhar as iniciativas de registro eletrônico, e devido aos desafios da transferência da informação clínica do paciente entre sistemas heterogêneos, de modo a manter o seu significado original, o Governo Brasileiro, por meio do Ministério da Saúde, publicou a Portaria nº 2.073/2011 7, que regulamenta o uso de padrões de interoperabilidade e informação em saúde para sistemas de informação em saúde no âmbito do SUS, nos níveis Municipal, Distrital, Estadual e Federal, e para os sistemas privados e do setor de saúde suplementar. Na portaria, alguns padrões e especificações de informação relacionados aos sistemas estão definidos em categorias, sendo o modelo de referência e modelos de domínio sob a forma de arquétipos e templates 8determinados de acordo com a openEHR, para a implementação do RES. No entanto, a arquitetura (armazenamento e processamento), a infraestrutura, e as ferramentas tecnológicas utilizadas no desenvolvimento dos sistemas, ficam a cargo dos desenvolvedores. 7 8 Ministério da Saúde. Portaria nº 2.073/2011. Disponível em: http://bvsms.saude.gov.br/bvs/saudelegis/gm/2011/prt2073_31_08_2011.html São estruturas compostas de um ou mais arquétipos onde são acrescentadas restrições necessárias ao uso destes arquétipos em um cenário particular. Disponível em: http://www.openehr.org/pt/programs/clinicalmodels/ 17 Para o armazenamento da informação clínica, uma atenção especial é necessária na escolha do projeto de arquitetura de armazenamento ou como os dados são persistidos, devido às características que cada sistema possui. Atualmente, esse armazenamento depende muito dos Sistemas de Gerenciamento de Banco de Dados Relacionais (SGBDR), pois esse modelo de dados adota uma estrutura de armazenamento estático, em que são apresentados conceitos de esquemas e relações entre tabelas (LEE; TANG, W.-C.; CHOI, 2013). No entanto, há algumas preocupações no uso desse modelo como: (a) Há casos em que suas performances não são adequadas para as necessidades específicas, como suporte de decisão (STONEBRAKER et al., 2007); (b) Há deficiência no fornecimento de escalabilidade (STONEBRAKER; CATTELL, 2011); (c) Possui rigidez para dados semiestruturados, como os dados clínicos de um paciente.(MELLO et al., 2000). Para lidar com essas questões, são utilizadas alternativas que podem lidar com características específicas de dados clínicos com mais eficácia: os bancos de dados conhecidos como NoSQL (No only SQL)(LEE; TANG, W.-C.; CHOI, 2013). Quanto à arquitetura e avaliação do funcionamento de um RES, poucos são os estudos que abordam essa temática, porém existe um considerável número de estudos envolvidos com a questão da interoperabilidade dos dados em saúde (PÖHLSEN et al., 2009; SALAMANCA et al., 2008). Especificamente, na abordagem “Dual Model”, com a utilização de arquétipos, embora seja eficaz para a aquisição de interoperabilidade semântica entre sistemas de saúde e permite a evolução do sistema sem precisar alterar o modelo de dados(DIAS; COOK; FREIRE,2011), não há um conjunto de boas práticas estabelecidas para a implementação de sistemas baseados nestas especificações. A partir dessa conjuntura, o presente trabalho objetiva verificar o estado da arte das arquiteturas dos sistemas eletrônicos de saúde baseados em arquétipos da metodologia “Dual Model”. Por meio desse estudo, será possível realizar um mapeamento das implementações no cenário mundial, bem como, apresentar as diversas tecnologias usadas pelos desenvolvedores. 18 1.2 Objetivo Geral Investigar as diferentes iniciativas ao redor do mundo, a partir das evidências encontradas na literatura nos últimos anos, das arquiteturas dos RES baseados em arquétipos. 1.2.1 Objetivos Específicos • Mapear as iniciativas de implementação no cenário mundial; • Identificar os mecanismos de persistência de dados apresentados nas implementações; • Comparar as arquiteturas apresentadas na implementação de um RES baseado em arquétipos. 1.3 Organização da Dissertação Esta dissertação encontra-se dividida em 6 capítulos, organizados da seguinte forma: Capítulo I – Introdução: apresenta uma visão geral do tema, justificativa e objetivos da revisão da literatura. Capítulo II – Referencial Teórico: Apresenta os conceitos relacionados ao objeto de estudo; Capítulo III – Metodologia: apresenta o planejamento da pesquisa, como a especificação da pergunta, a definição dos termos de busca nas bases de dados, a avaliação e seleção dos estudos, os critérios de inclusão e exclusão, a coleta de dados e o agrupamento dos dados. Capítulo IV – Resultados: apresenta os resultados da pesquisa, com análises dos estudos incluídos a partir dessa revisão da literatura, e a evolução das publicações por ano e fonte de dados. Capítulo V – Discussão: Discute sobre os resultados obtidos; Capítulo VI – Conclusão: Apresenta as conclusões do estudo. 19 CAPÍTULO II 2. Referencial Teórico Neste capítulo são abordados os principais conceitos que serviram de base para o desenvolvimento da pesquisa. 2.1 Registro Eletrônico de Saúde (RES) Existem diversas definições para o RES. Mcdonald; Tang, e Hripcsak (2014) o definem como um repositório de informações sobre o estado de saúde e assistência à saúde de um indivíduo, mantido eletronicamente, de modo que ele possa servir aos múltiplos e legítimos usos e usuários do registro. A ISO 20514(ISO/TR 20514, 2005), oferece uma definição de RES para a Assistência Integral (RES-AI): “ Repositório de informação relativo ao estado de saúde de um ou mais indivíduos, em forma processável pelo computador, armazenada e transmitida com segurança e acessível por múltiplos usuários autorizados, tendo um modelo lógico de informação padronizado ou acordado que seja independente dos sistemas de RES e cuja principal finalidade é apoiar a continuidade, eficiência e a qualidade da assistência integral à saúde. ” A ISO considera esta como a principal definição de um Registro Eletrônico de Saúde, reconhecendo, porém, que atualmente ainda há muitas variantes do RES nos sistemas de informação em saúde que não estão em conformidade com a definição principal do RES. A ISO 20514 também adota a seguinte definição para o RES básicogenérico: “Um repositório das informações a respeito do estado de saúde de um ou mais indivíduos numa forma processável pelo computador”. Para o Sistema de Registro Eletrônico de Saúde (SRES) a norma define como “um sistema para registro, recuperação e manipulação de um Registro Eletrônico de Saúde”.Os S-RES possui definição mais ampla e abrangente, pois engloba outros subsistemas e componentes (Sistema Operacional, Sistemas de Gerenciamento de Banco de Dados (SGBD’s, servidores, bibliotecas, etc.).No Brasil, o RES e S-RES são definidos de acordo com a norma ABNT ISO/TR 20514 9. 9 ABNT ISO/TR 20.514:2005 – Informática em saúde - Registro eletrônico de saúde - Definição, escopo e contexto. Disponível em: http://www.abntnet.com.br/fidetail.aspx?FonteID=41192 20 2.2 EHR x EMR EMR (Eletronic Medical Record) ou Prontuário Eletrônico do Paciente (PEP) é composto pelo registro de informação de saúde de um paciente, gerado a partir de eventos ocorridos no processo assistencial em uma única organização de saúde, que pode ou não alimentar um sistema de RES(GARETS; DAVIS, 2006). O RES é também composto pelo registro de informação de saúde de um paciente. Porém, esse registro é elaborado a partir de eventos ocorridos em múltiplas organizações de saúde. É composto de um ou vários repositórios de dados clínicos e demográficos de pacientes. Seus dados são coletados prioritariamente por meio de sistemas de PEP de organizações prestadoras de serviço em saúde(SANTOS, 2011). Um outro conceito de RES se refere a um repositório que integra as informações dos pacientes provenientes de vários EMR diferentes e espalhados em diversos provedores de saúde em uma dada região geográfica (GARETS; DAVIS, 2006). Essa relação entre RES e PEP é mostrada na Figura 1, demonstrando que os dados do EHR podem ser obtidos a partir dos sistemas EMR de diferentes instituições. Estes dados posteriormente são compartilhados com outras instituições, retornando informações e atualizações no EHR. Figura 1. Diferença entre EHR, EMR Fonte: https://doctors.practo.com/emr-vs-ehr-whats-difference/. Adaptado. 21 Partindo dessas definições, compreende-se que o RES é um componente central na construção de um sistema integrado de saúde, que constitui um repositório para pesquisa e melhoria nas condições de tratamento de pacientes(SANTOS, 2011). No entanto, muitos s ã o os desafios e mudanças culturais enfrentados no desenvolvimento de um sistema de RES(KALRA, DIPAK, 2003). Na visão técnica, o desafio da interoperabilidade e a natureza complexa e dinâmica das informações em saúde, que dificultam a evolução dos sistemas, fazem seu desenvolvimento ser mais árduo do que o de outros sistemas de informação (NARDON, 2000). É nesse cenário desafiador, que sistemas RES devem evoluir de maneira mais fácil e interoperar com outros sistemas, tratando a informação estruturada e não estruturada, em diferentes formatos e volumes. 2.3 Integração e Interoperabilidade em sistemas. A integração é o processo de assegurar a interação entre entidades necessárias para atingir os objetivos de um domínio (“ISO 19439”). A integração pode ser abordada de várias maneiras e em vários níveis (VERNADAT, 1996), por exemplo: (i) a integração física (interligação de aparelhos, máquinas); (ii) a integração de aplicações (integração de aplicações de software e sistemas de banco de dados) e (iii) integração de negócios (coordenação de funções como gerir, controlar e monitorar processos de negócio). Na interoperabilidade, a palavra ''inter-operar'' implica que um sistema realiza uma operação para outro sistema. Do ponto de vista da TI, é a faculdade de dois sistemas heterogêneos funcionarem em conjunto e de compartilharem recursos de uma forma recíproca (CHEN; VERNADAT, 2004). Das condições para que ocorra interoperabilidade entre sistemas de informação em saúde incluem especialmente o modelo de informação, utilização de terminologias e ontologias específicas de um domínio, entre outras características. Segundo o HIMSS 10, a integração é o arranjo dos sistemas de informação, de modo que esses possam se comunicar eficientemente, reunindo as partes relacionadas e formando um único sistema composto por sistemas menores. Já a interoperabilidade é a capacidade dos sistemas de informação de trabalharem juntos, dentro e fora das fronteiras 10 HIMSS. Electronic Health Record. 2010. Disponível em http://www.himss.org/ASP/topics_ehr.asp 22 organizacionais, a fim de atingir um determinado objetivo. Nesse sentido, a integração pode ser obtida se os sistemas incorporarem, em suas interfaces de programas, uma forma única de trabalho, almejando um objetivo comum, de maneira unificada e padronizada. Ou seja, esse nível de integração exige,em geral, a adaptação dos programas (ou módulos) que constituem os sistemas. Por outro lado, a interoperabilidade implica que diferentes sistemas de informação associem seus recursos em prol de um objetivo comum, sem, no entanto, alterarem em nada sua autonomia e características próprias(SANTOS, 2011). 2.3.1 Integração vs. interoperabilidade Integração é geralmente considerada para além da interoperabilidade, pois envolve algum grau de dependência funcional (PANETTO; MOLINA, 2008). Enquanto os sistemas interoperáveis podem funcionar de forma independente, um sistema integrado perde a funcionalidade significativa se o fluxo de serviços é interrompido. Dois sistemas integrados são inevitavelmente interoperáveis, mas dois sistemas interoperáveis não são necessariamente integrados (CHEN; DOUMEINGTS, 2003). 2.3.2 Interoperabilidade Sintática e Semântica A definição de interoperabilidade adotada nesta revisão é dada pela norma ISO/TR 16056 11, que diz: [...] a habilidade de dois ou mais sistemas (computadores, dispositivos de comunicação, redes, software e outros componentes de tecnologias de informação) interagir um com outro,trocando informações de acordo com um método prescrito[...]. A interoperabilidade pode ser classificada em diferentes níveis: sistema, sintaxe, estrutura e semântica (OUKSEL; SHETH, 1999). Existem ainda outros níveis de interoperabilidade discutidos na literatura(MILLER, 2000; RODRIGUES et al.)que não serão apresentados. Nesta revisão,os níveis de interoperabilidade a serem considerados serão a interoperabilidade sintática e semântica. Para enfatizar esses dois mecanismos de interação de dados clínicos, a interoperabilidade sintática (ou funcional), de acordo com IDA (2004),está relacionada com 11 ISO/TR 16056-1: 2004: Health informatics -- Interoperability of telehealth systems and networks Part 1:. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37351 23 as questões técnicas para que sistemas de computadores trabalhem em conjunto, incluindo as interfaces técnicas, redes, middleware, acessibilidade e segurança. A norma ISO18308(ISO 18308, 2011) a define como: [...] a capacidade de dois ou mais sistemas de comunicarem e intercambiarem dados através de formatos de dados e protocolos de comunicação[...] Na interoperabilidade semântica, os sistemas compartilham um vocabulário comum e há uma preocupação com o significado dos dados ou da informação que se deseja transmitir ou utilizar(BRASIL, 2015). Na transmissão, a informação deve ser compreensível mesmo para sistemas que possuem diferentes arquiteturas. Um exemplo de interoperabilidade é apresentado por (GØEG; CORNET; ANDERSEN, 2015) que mostra informações de dois hospitais: o Hospital A apresenta os sinais vitais de um paciente, que poderiam conter pulso, pressão arterial, temperatura, saturação de oxigênio e frequência da respiração, sendo cada um deles representado em um único campo de texto (em um banco de dados) onde poderiam ser escritos também os comentários. O Hospital B apresenta um modelo onde quantidades, comentários e campos relacionados com o protocolo são mantidos separadamente, como ilustrado na Figura 2. Em uma simples comparação, tem-se uma ideia sobre o que é interoperabilidade semântica no modelo de sinais vitais. Na representação da informação no hospital A, caso fosse necessário realizar uma análise das informações sobre os sinais vitais de algum paciente, haveria a necessidade de intervenção humana manual, o que tornaria a tarefa desgastante, dado o grande volume de dados a serem analisados e o desafio de sintetizar esses dados. No hospital B é apresentada uma melhor organização da informação clínica, simultaneamente com acerca campos de um separados mesmo para sinal os vital. vários Neste dados exemplo obtidos existe interoperabilidade sintática entre os dois hospitais (são recolhidos os dados dos mesmos sinais vitais), mas não existe interoperabilidade semântica (o mesmo sinal vital é representado de forma diferente quando se comparam os hospitais A e B). Contudo, percebe-se que mesmo havendo interoperabilidade sintática, não se pode realizar adequadamente a troca de dados clínicos sem a interoperabilidade semântica. 24 Figura 2. Modelo de sinais vitais (pulso). Na definição em dois hospitais diferentes. Fonte: (GØEG; CORNET; ANDERSEN, 2015). Adaptado. Na abordagem “Dual Model”, a proposta é a utilização de especificações que possibilitem que as informações sejam interoperáveis entre RES de diferentes instituições. Para que ocorra a partilha de dados entre os sistemas RES, é necessário que haja interoperabilidade, que só é conseguida quando as partes envolvidas estabelecem um compromisso com um modelo de informação comum (MALDONADO; LOPEZ; BLOBEL, 2009). 2.4 Persistência de Dados Segundo Júnior (2006), a propriedade de um dado manter sua integridade ao longo do tempo é chama de persistência. Dentro do contexto de desenvolvimento de sistemas, a persistência de dados é uma forma de manter as informações das aplicações em um meio do qual possam ser recuperados posteriormente. Bauer (2005) afirma que a persistência nada mais é do que armazenar dados em um banco de dados relacional. Um modelo gerencial de persistência atua em camadas, podendo ser feito por intermédio de instruções SQL 12 (Structured Query Language). O uso da persistência deixa transparentes as operações básicas de inserção, recuperação, atualização e remoção de dados. Nesse caso, o autor aborda somente uma categoria de banco de dados. No entanto, existem outras categorias que atuam na persistência de forma diferente, como os que utilizam o paradigma de Orientação a Objetos (OO) e os que pertencem a categoria denominada NoSQL. 12 DASAR, Pemakaian. SQL (Structured Query Language). 2007. 25 O uso dos bancos de dados relacionais, trazem alguns inconvenientes aos programadores de linguagens OO (ROCHA; KUBOTA). Para usar os recursos de bancos de dados relacionais e aproveitar os conceitos do paradigma OO, é necessário fazer o mapeamento objeto-relacional (mapeamento O/R). Nesse mapeamento, as classes e os atributos do sistema são mapeados para tabelas e campos/colunas e a persistência é feita de forma transparente pela aplicação. Para suprir essas necessidades, surgiram diversos frameworks e tecnologias de persistência, a exemplo do Hibernate 13 e do iBatis 14. Essas ferramentas facilitam o trabalho do desenvolvedor e aumentam sua produtividade, fornecendo poderosas API’s de manipulação de dados. Ercan e Lane (2014) afirmam que a literatura recente mostra a emergente categoria de bancos de dados NoSQL, a qual apresenta vantagens significativas, tais como escalabilidade, melhor desempenho e alta disponibilidade e revisa as principais características de bancos de dados NoSQL em RES. O estudo também aborda as limitações dos bancos de dados relacionais nos sistemas de saúde distribuídos. Para Han et al. (2011), os Bancos de dados NoSQL, vêm de uma família heterogênea de produtos, incluindo bancos de dados XML, que pretendem lidar de uma forma mais natural com dados não estruturados ou semiestruturados do que os bancos de dados relacionais. 2.4.1 ACID x BASE Como já dito, os bancos de dados relacionais adotam uma estrutura de armazenamento estático. Os dados são armazenados de forma organizada com base na interrelação de dados em que problemas de redundância e de consistência podem ser eliminados pela normalização dos dados (ABITEBOUL; HULL; VIANU, 1995). Essa categoria adota um conjunto de funcionalidades fundamentais que garantem as propriedades ACID (Atomicity, Consistency, Isolation, Durability), (atomicidade, preservação, consistência, isolamento, durabilidade) em que as propriedades devem ser rigorosamente aplicadas(HAERDER; REUTER, 1983). Os sistemas NoSQL não fornecem as propriedades ACID, as atualizações, eventualmente, são propagadas, mas existem limitações quanto à consistência de dados. Por outro lado, pode-se conseguir muito mais alto desempenho e escalabilidade. 13 14 Hibernate. Everything data. - Hibernate. Disponível em: hibernate.org/ iBATIS Home. Disponível em: ibatis.apache.org/ 26 Os bancos de dados NoSQL utilizam o conceito BASE (Basically Available, Soft state, Eventual consistency), que considera um cenário que provê transações distribuídas, tolerância a falhas, e replicação otimista em um sistema distribuído, mas este modelo não possui compromisso com a consistência dos dados (TOTH, 2011). A partir do conceito BASE, foram criados diferentes tipos de bancos de dados não relacionais. Por conta dessas características e de outras, De Diana; Gerosa (2010) afirmam que o mecanismo NoSQL veio como “uma solução para a questão da escalabilidade no armazenamento e processamento de grandes volumes de dados na Web 2.0”. 2.5 A Fundação openEHR A Fundação openEHR (BEALE, Thomas et al., 2006) é uma organização sem fins lucrativos que aborda a interoperabilidade e computabilidade em sistemas de informações em saúde, que lida com a gestão, armazenamento, recuperação e troca de dados em um RES. O openEHR consiste de um conjunto de especificações que fornecem tanto interoperabilidade sintática quanto interoperabilidade semântica e permite a evolução dos sistemas sem necessidade de reformular seus modelos de dados. Bird, Goodchild (2003) destacam que o openEHR mantém uma arquitetura de RES concebida para apoiar a construção de ambientes distribuídos de um registro eletrônico, e utiliza uma abordagem conhecida como metodologia de dois níveis, que é baseado em uma separação clara entre informação e conhecimento. O primeiro é descrito por meio de um modelo de referência (RM). O segundo é baseado no conceito de arquétipos (AM), objetos que definem a semântica dos sistemas, e que permitem que o software realize consultas de dados por meio do uso de uma linguagem própria baseado no RM, a AQL 15. Esse novo paradigma inova o universo de implementações de um RES, pois atua na padronização das estruturas básicas dos dados de saúde. Sua metodologia é projetada para envolver tanto a comunidade médica quanto os especialistas em desenvolvimento de software. 15 Archetype Query Language. Disponível: www.openehr.org/releases/QUERY/latest/AQL.html 27 2.6 A norma ISO 13606 A norma ISO 13606 (ISO 13606, 2015) foi desenvolvida pelo Comitê Técnico ISO/TC 215, Informática em Saúde, e concebida a partir de experiência prática obtida durante a implementação do padrão precursor europeu, ENV 13606. Propõe um modelo de referência simplificado e inspirado no modelo de referência proposto pela Fundação openEHR. Assim como openEHR, o padrão ISO/EN 13606 EHR fornece um quadro para a criação de RES interoperáveis, baseado na abordagem de dois níveis, que combina dois tipos de modelos - o Modelo de Referência e arquétipos para representar conteúdo de um RES (BIRD; GOODCHILD; TUN, 2003). A norma é classificada em 5 partes: ISO 13606-1 - Reference Model; ISO 13606-2 - Archetype interchange specification; ISO 13606-3 - Reference archetypes and term lists; ISO 13606-4 –Security; ISO 13606-5 – Interface specification. Somente as normas ISO 13606-1 e ISO 13606-2 são tratadas nesse estudo. A norma EN 13606-1 (ISO 13606-1, 2008) especifica a comunicação, por meio de um único indivíduo identificado, entre sistemas RES, ou entre sistemas RES e um repositório de dados centralizado. Essa comunicação usa aplicativos ou middlewares para acessarem os dados do RES. Uso do RES para outros fins, como ensino, auditoria clínica, administração e relatórios, pesquisa e epidemiologia, não são o foco dessa norma. A ISO 13606-2 (ISO 13606-2, 2008) define um modelo de arquétipo a ser usado para representar a comunicação entre os repositórios. 2.7 Abordagem “Dual Model” A maioria dos sistemas de informação de hoje são construídos na abordagem de nível único. Nessa abordagem, as entidades são modeladas diretamente em modelos de software e banco de dados, por meio de um processo de escrever casos de uso, encontrar classes e modelos que resultará em um software (BEALE, T, 2002). O autor ainda afirma que esses sistemas não são muito estáveis, pois os conceitos de domínio são diretamente codificados nos modelos utilizados para construir o software e bases de dados, com a utilização de entidades como atributos, tabelas e colunas, ou seja, há uma dependência das definições de entidades de conhecimento a partir do qual é construído o sistema. As 28 mudanças na definição nas entidades exigem que o sistema seja alterado. A Figura 3 ilustra esse conceito. Figura 3. Modelagem de único nível de desenvolvimento. Fonte: (BEALE, Thomas, 2002). No entanto, para situações onde as entidades, a complexidade e taxa de mudança de definição é pequena, essa abordagem pode ser viável. Porém, em domínios grandes, ricos em informação e sujeitos a constantes mudanças, como a área médica, a abordagem de nível único pode ter consequências negativas, como afirma Beale (BEALE, T, 2002): • A modelagem do sistema pode ser logisticamente difícil de administrar, devido ao facto de dois tipos de pessoas estarem envolvidas: especialistas de domínio e desenvolvedores de software. Especialistas do domínio são forçados a expressar seus conceitos em UML 16, por exemplo, ou então participar de discussões ad hoc com os desenvolvedores. Da mesma forma, os desenvolvedores de software têm dificuldade em lidar com inúmeros conceitos que eles não entendem. O típico resultado é um processo de modelagem precário em que os conceitos de domínio são muitas vezes perdidos ou expressos incorretamente, resultando em um software que não faz o que os usuários querem; 16 UML (Unified Modeling Language) permite representar um sistema de forma padronizada, com intuito de facilitar a compreensão pré-implementação. Disponível em: http://www.uml.org/whatis-uml.htm 29 • A introdução de novos conceitos requerem mudanças no software e no banco de dados. Reconstrução, testes e reimplantação podem ser caros e arriscados. • A interoperabilidade é difícil de alcançar, uma vez que cada ambiente local deva continuamente fazer seus modelos e softwares compatíveis com os outros, ou então continuamente atualizar conversores de software ou pontes. Ambientes heterogêneos em que o software foi criado usando metodologia de um único nível de desenvolvimento, normalmente não interagem bem, por causa da complexidade dos modelos subjacente de cada sistema. Para conseguir acompanhar a evolução do conhecimento em saúde sem realizar alterações profundas nos sistemas de informações em saúde, o openEHR precisou recorrer a uma nova estrutura de modelagem. A solução para este desafio foi a modelação em dois níveis (BACELAR; CORREIA, 2015) (“Dual Model” ou Multinível). Nela ocorre a separação do conteúdo da forma com que este é representado. Assim foram criados os modelos de conteúdo clínico representado pelo Modelo de Arquétipo (AM) e o modelo de informação representado pelo Modelo de Referência (RM). A Figura 4 mostra essas representações. Figura 4. Modelagem de dois níveis (RM e AM) (BEALE, Thomas, 2002). 30 Nessa abordagem, o usuário pode acessar a informação clínica por meio da aplicação. Os especialistas do domínio são os responsáveis pela construção de arquétipos (camada independente do software) e os profissionais de TI sãos os responsáveis pela criação de ferramentas de integração dos dados entre os sistemas existentes em um modelo de RES (SACHDEVA; BHALLA, 2010). Os arquétipos são usados para padronizar as estruturas da informação clínica e oferecem uma porta comum de entrada para o intercâmbio de dados, acordada entre sistemas envolvidos. Nesse sentido, o RM é mais estável e menos sujeito a alterações que o arquétipo, essa separação habilita o desenvolvimento de “sistemas à prova de futuro” (future-proof systems) (BEALE, T, 2002), permitindo aos mecanismos de persistência serem pouco alterados e aos arquétipos serem afetados pelas alterações de estrutura e regras de negócio (FREIRE; COPETTI; LOQUES, 2008). 2.7.1 Arquétipos Uma analogia que define o arquétipo na abordagem de dois níveis é apresentada por BEALE et. al (2008), os componentes do RM são como especificações das peças do jogo de LEGO®, como ilustrado na Figura 5. Os arquétipos são similares a estruturas significativas construídas a partir das peças do LEGO. A aplicação openEHR é o ambiente contendo essas várias formas, tendo essas a possibilidade de comunicar entre si. Figura 5. Representação “Dual Model” por meio do jogo de peças de LEGO®. Fonte: http://data.nczisk.sk/old/nczisk/ZI/stvrtok/3_SamHeardArchetypesTemplates.pdf (acessado em mar. 30, 2016). Adaptado. Nesse contexto de estrutura de arquétipo, eles podem ser trabalhados sob as restrições (estrutura, tipos, valores e comportamentos) de um RM em cada domínio em que se deseja usar (SACHDEVA; BHALLA, 2010) e que apresenta algumas características funcionais como: 31 • São flexíveis, reutilizáveis e combináveis; • O significado dos dados clínicos é preservado em sistemas baseados em arquétipo; • A normalização pode ser alcançada, de forma que, sempre que houver uma alteração no conhecimento clínico, o software não precisa ser mudado e somente os arquétipos precisam ser modificados. A tarefa de desenvolver os arquétipos é tipicamente realizada por profissionais de saúde. Para isso são usadas ferramentas específicas de modelagem, como por exemplo o Archetype Editor 17 da Ocean Informatics 18. Os arquétipos podem ser construídos em um idioma e posteriormente traduzidos para qualquer outro. Isso significa que um arquétipo pode ser visto e interpretado em diversas línguas sem perder o seu significado e contexto. De modo semelhante, os elementos dos arquétipos podem ser associados a diversas terminologias, como por exemplo, CID-10 e SNOMED, o que dará mais especificidade aos seus elementos(BACELAR; CORREIA, 2015). Os arquétipos podem ser compartilhados por meio de um repositório de nível internacional, por exemplo o Clinical Knowledge Manager (CKM), gerido pela fundação openEHR. Arquétipos do CKM são criados por especialistas de domínio independentes, e em seguida, eles são liberados para a comunidade como fonte aberta e de conteúdo disponível gratuitamente (MARCOS et al., 2011). É importante observar que, a existência de vários arquétipos para um mesmo conceito clínico levaria ao tradicional problema da falta de interoperabilidade. Por isso, o arquétipo precisa ser único, o mais abrangente e completo possível para servir a todas as situações de uso. Caso o arquétipo seja muito abrangente, é possível usar apenas os campos de interesse (BACELAR; CORREIA, 2015). Arquétipos em outras áreas A palavra arquétipo, segundo Silva (SILVA, 2006) deriva do grego arché: primitivo, primeiro; e de typon: tipo, marca, modelo. Na Literatura, tem o sentido de texto original ou mais antigo, do qual derivam outros textos. Na Filosofia, tem o sentido de modelo ideal, 17 18 openEHR - Archetype Editor Home. Disponível em http://www.openehr.org/downloads/archetypeeditor/home Ocean Informatics - Home. Disponível em: https://oceaninformatics.com/ 32 protótipo ideal, ideia primeira. Na Psicologia, de modo mais estudado na linha de orientação junguiana 19, os arquétipos correspondem às imagens ancestrais e simbólicas materializadas nas lendas e mitos da humanidade e constituem o inconsciente coletivo. Nessa pesquisa, verificou-se que o termo arquétipo foi citado em outros setores. Na área de desenvolvimento de software, alguns trabalhos foram encontrados em que abordam o tema, porém com um significado peculiar, como no trabalho de Piho et al. (2010), em que o arquétipo representa um meio de fornecer orientações para a prática de profissionais relativa à organização de tarefas de desenvolvimento de software e de seleção de métodos e ferramentas. O arquétipo é visto como um objeto primordial que ocorre de forma consistente e universalmente nos sistemas. 19 Orientação Junguiana - Abordagem que aprofunda a investigação do inconsciente. Disponível em: www.psicoterapiajunguiana.com.br 33 CAPÍTULO III 3. Metodologia O processo de Revisão da literatura utilizou como base metodológica, trabalhos que demonstram passos para o desenvolvimento de uma revisão (RIDLEY, 2012),(KIRKPATRICK et al., 2004), (KURPANIK; PAŃKOWSKA, 2015), (DUARTE, 2007). Os estudos foram organizados criteriosamente e posteriormente avaliados. A Figura 6 apresenta a descrição das etapas que constituíram o processo de elaboração dessa revisão da literatura. 3.1 Elaboração do Projeto de Pesquisa Esta revisão da literatura empregou um processo para identificar, avaliar e interpretar os estudos científicos disponíveis e relevantes relacionadas a um tema específico de interesse (EGGER; SMITH, 2001). Figura 6. Etapas de elaboração da revisão da literatura. 34 Definição das bases de dados, palavras-chave e termos de busca Nessa etapa foram identificados todos os estudos que foram incluídos na revisão. A identificação dos estudos foi realizada por meio de pesquisas em bases de dados eletrônicas. A Tabela 1 apresenta as bases de dados escolhidas. Tabela 1: Bases de dados para a realização das buscas. Base de Dados Sítio 1 - ACM Digital Librarys http://dl.acm.org/ 2 - Emerald Insight http://www.emeraldinsight.com/ 3 - IEEE Xplore http://ieeexplore.ieee.org/Xplore/guesthome.jsp 4 - ISI Web of Science https://webofknowledge.com/ 5 - PubMed http://www.ncbi.nlm.nih.gov/pubmed/ 6 - ScienceDirect http://www.sciencedirect.com/ A partir da leitura do título e do resumo (abstract) de cada artigo identificado nas bases de dados pesquisadas, foi construída uma base de artigos científicos com relação direta com o tema de pesquisa. A fase seguinte foi a aplicação de critérios de inclusão e exclusão sobre os referidos artigos, seguido pela leitura integral daqueles que passaram por esses critérios. As palavras-chave utilizadas foram ElectronicHealthRecord; Archetype; Database. Em todas as bases de dados pesquisadas, foi necessário realizar a busca no modo avançado (Advanced Search), com a finalidade de configurar alguns filtros tais como: período de publicação; termos compostos entre aspas; Paper/Articles, etc. As junções de palavras-chave resultaram em temos que foram utilizados nas bases de dados. Das 3 palavras-chave utilizadas, formaram-se os seguintes termos: 1. “Electronic health record” and Archetype2. “Archetype and Database” 3.2 Seleção e Avaliação Crítica dos Estudos Encontrados O processo de busca nas bases de dados selecionadas utilizando as palavraschave e termos descritos, retornou estudos para a análise que potencialmente poderiam ser incluídos na revisão. Esses estudos foram classificados em categorias, da seguinte forma: 35 a) Estudos identificados: estudos identificados por meio da primeira busca nas bases de dados. Os títulos e/ou resumos de cada estudo identificado, resultante de cada busca, foram avaliados de acordo com os critérios de inclusão e exclusão apresentados a seguir. Os estudos identificados que aparentemente obedeciam a todos os critérios de inclusão e não satisfaziam a nenhum dos critérios de exclusão foram selecionados para leitura; b) Estudos não selecionados: claramente não preenchem os critérios de inclusão. Foi registrado apenas o número desses estudos; c) Estudos selecionados: aparentemente preenchem os critérios de inclusão. Cada um dos artigos selecionados foi lido e analisado integralmente. Critérios de Inclusão e Exclusão A Tabela 2 apresenta os critérios. Tabela 2. Critérios de classificação dos trabalhos selecionados Critérios de inclusão Critérios de exclusão Ci1. Língua inglesa; Ce1. Não possuir relação com o tema; Ci2. Artigos com ano de publicação entre Jan/2007 e Mar/2016; Ce2. Artigos em duplicidade; Ci3. Publicações em revistas, conferências, simpósios, workshops, periódicos e eventos científicos; Ci4. Especificar com arquiteturas de arquétipos. profundidade as RES, adotando Ce3. Artigos de revisão; Ce4. Somente abordam o mecanismo de consulta; Ce5. Abordam sobre arquétipos, mas não apresentam soluções, implementações ou experimentos. Para mais detalhes acerca dos critérios de inclusão e exclusão dos estudos, foram analisados nos artigos reais implementações de arquiteturas e/ou experimentos de comparações de componentes de banco de dados de um RES. A Tabela 4 apresenta artigos excluídos que se encaixam nesses critérios. 36 Tabela 3. Estudos excluídos de acordo com o critério adotado. Título EHR Query Language (EQL) – A Query Language for Archetype-Based Health Records ImplementingHigh-Level Query Language Interfaces for Archetype-Based Electronic Health Records Database Electronic systems interoperability study: based on the interchange of hospital obstetrical information Managing Archetypes for Sustainable and Semantically Interoperable Electronic Health Records. Exporting data from an openEHR repository to standard formats Ano Observações Critério de Exclusão 2007 O artigo aborda uma linguagem de consulta declarativa (EQL - EHR Query Language) desenvolvida para consultar RES baseados no openEHR. Apresenta a Syntaxe da linguagem com algumas expressões. Ce3 2008 Aborda o XQBE, uma linguagem visual criada para facilitar o uso por profissionais que não sejam da área de computação. É uma alternativa à AQL. Ce3 2015 Os autores propõem um modelo para a transmissão da informação clínica (Extrato) a partir de sistema de informação em uma maternidade para outros sistemas. Ce3 2008 2014 Apresenta um repositório baseado na web. Não apresenta especificações do sistema e sim diagramas de caso de uso para representar o repositório. Apresenta uma metodologia para exportar dados a partir de um repositório openEHR para formatos padrão. Ce4 Ce4 Com base nos critérios de classificação dos artigos selecionados, foram obtidos inicialmente um total de 2.521 estudos identificados, utilizando as associações de palavras-chaves. 2.439 estudos foram excluídos em decorrência dos critérios de exclusão. Por fim, obtivemos 82 estudos selecionados, dos quais, após leitura integral, chegamos a 16 estudos incluídos para a coleta dos dados. Para melhor representar os números obtidos, utilizou-se dois mecanismos: a) Tabela 4, que exibe o quantitativo de cada Base pesquisada, de acordo com os termos utilizados; b) Figura 7, que apresenta as fases de seleção dos estudos. Tabela 4. Quantitativo de estudos de acordo com a fonte pesquisada Bases ACM digital Emerald IEEE Xplore ISI Web of Science ScienceDirect – Elsevier PubMed Subtotais Outras fontes Total Incluídos 1 0 6 0 2 6 15 6 21 37 Figura 7. Diagrama de fluxo de seleção dos Estudos. Outras fontes para complementação dos estudos Esta pesquisa bibliográfica foi complementada com os seguintes procedimentos: 1. Verificação da lista de “Referências Bibliográficas”: a cada finalização da leitura do estudo, os artigos das referências com afinidade com o tema foram visualizados e baixados. 04 artigos foram incluídos na relação. Esses artigos não foram encontrados no processo de busca nas bases listadas na Tabela 1. 2. Verificação no acervo de artigos em um repositório criado por meio do Zotero 20, um gerenciador de referência disponível gratuitamente em que se encontra um grupo de publicações relacionadas com a Fundação openEHR. Este repositório foi organizado e disponibilizado porKoray Atalag 21. 3. Artigos publicados que se encontram no sítio da ISO 13606. É uma fonte de informações sobre o padrão para os prestadores de cuidados de saúde. Nenhum novo artigo, por meio dos critérios utilizados, foi incluído. 20 21 https://www.zotero.org/groups/openehr - gerenciador de dados bibliográficos e materiais relacionados à pesquisa. Dr Koray Atalag - The University of Auckland: https://unidirectory.auckland.ac.nz/profile/katalag. 38 4. Contato com os Prestadores de Serviços de Saúde encontrados no sítio da Fundação openEHR. No sítio, há uma relação de organizações que adotam as especificações openEHR em suas implementações, como mostra a Tabela 5. Na tabela, os Prestadores são representados como Fornecedores. Foi enviado e-mail para esses Fornecedores, explicando sobre a pesquisa. No corpo do e-mail, solicitamos informações das implementações/propostas/soluções em conformidade com os campos da Tabela 7 na seção 3.3, que aborda a coleta de dados. Tabela 5. Informações das instituições que adotam openEHR em seus sistemas. Fonte: http://www.openehr.org/who_is_using_openehr/ País Instituição Fornecedor (es) E-mail Situação PORTUGAL HOLANDA BRASIL AUSTRÁLIA Queensland Health Ocean Informatics, estado Austrália sales@oceaninformatics Implantado em .com agosto 2012 Ocean Informatics, estado Austrália pela sales@oceaninformatics Implantado em .com outubro 2012 St Andrews Hospital Toowoomba, Ocean Informatics, Queensland, Australia Austrália sales@oceaninformatics Implantado em .com junho 2012 St Vincents Holy Spirit Hospital Ocean Informatics, Brisbane, Australia Austrália Cerca de 3.000 profissionais de saúde, incluindo médicos (principalmente Oftalmologistas - Colégio Brasileiro de P2D, Brasil Oftalmologistas), fisioterapeutas, enfermeiros e recepcionistas. Plano de saúde SPAsaude ezVida, Brasil Boa Esperança, São Paulo GGZ Noord Holland Noord Code24, Países Baixos Organização de saúde mental sales@oceaninformatics Implantado em .com dezembro 2012 Autoridade de saúde do australiano. Northern Territory Health Instituiçãode saúde do australiano responsável prestação de saúde pública. [email protected] Implantado em fevereiro 2012 Implantado em junho 2012 [email protected] Implantado em abril 2011 GGZ Friesland Organização de saúde mental Code24, Países Baixos [email protected] Implantado em agosto 2012 Rode Kruis Ziekenhuis Hospital Code24, Países Baixos [email protected] Implantado em novembro 2012 [email protected] m Implantado em maio 2011 IdealMed, Coimbra, Portugal Hospital privado que cobre várias A Critical Software especialidades com regime de SA, Portugal internação, ambulatório, cirurgia, emergência e formação médica. 39 EHR platform: Moscow City Department of Marand (Slovenia) Information Technologies Clinical apps: Infinnity (Russia) Autoridade responsável por soluções de e-saúde para Moscou, com 130.000 Clinical strategy & usuários em 780 instalações. tooling: Ocean Informatics UK RÚSSIA Clínica de Academy Chelyabinsk Medical [email protected] [email protected] Fase piloto. Implantado em 2013 sales@oceaninformatics .com Infinnity, Rússia [email protected] Implantadono final de 2012 Infinnity, Rússia [email protected] Implantado em 2012 Russian Railways Medical Center, Chelyabinsk, Department of Infinnity, Rússia Southern Urals [email protected] Implantado em 2011 [email protected] Implantado em abril 2011 [email protected] Implantado em dezembro 2012 [email protected] Contratado em setembro de 2012; implantado em 2013 Federal Medical Biological Agency of Trekhgorny, Chelyabinskaya oblast Federal Medical Biological Agency of Chelyabinsk, Radiation Rehabilitation Center University Medical Center Ljubljana, Slovenia REINO UNIDO ESLOVENIA UMCL é uma instituição de cuidados Marand, Eslovênia terciários cobrindo todas as especialidades médicas com mais de 2.000 camas e 7.500 funcionários, incluindo 1.200 médicos. Institute of Oncology, Ljubljana O Instituto é a principal instituição de Marand, Eslovênia cuidados de câncer e pesquisa na região. 400 leitos, 150 médicos e 800 funcionários. Ministry of Health, Slovenia O Ministério da Saúde da Eslovênia é Consoritum led by responsável pela maior parte de todas Marand, Slovenia as instituições de assistência à saúde no país. NHS Leeds North Commissioning Group Clinical Ocean Informatics UK Piloto contratado em setembro sales@oceaninformatics de2012; .com implantação inicial em outubro 2013 5. Como complementação, também foi enviado e-mail para Fornecedores que implementam sistemas de informações em saúde baseados nas especificações openEHR ou na norma ISO 13606. A relação das instituições, apresentada na Tabela 6, foi conseguida por meio do trabalho de Frade et al. (2013). 40 Tabela 6. Fornecedoresdos quais foram solicitadas informações para este trabalho. Fonte: (FRADE, Samuel et al., 2013) Projeto/Produto Fornecedor Sigla Pais Base24 Code24 B.V. B24 NL eWEAVE eW SE HSEAVS ES OceanEHR platform eWEAVE AB Valencia Health Agency, Tech. Univ. Valencia, Novasoft, Everis Ocean Informatics OEHR Open EHRGen CaboLabs OGen AU UY Open EHRServer CaboLabs OServ UY OpenHealth:MultiCare Infinnity Solutions OH RU OpenKernel ROSA Software OK NL RecordPoint Sistema Clinico Integrado Think!EHR Platform Extensia RP AU IdealMed Crit Marand TEHR SI EHRFlex Tech. Univ. Valencia, Veratech EHRF ES Companies/ I nstitutions HSEAVS PT GastrOS University of Auckland GOS NZ LinkEHR Tech. Univ. Valencia, Veratech LEHR ES LiU EEE Linko¨ping University LiU SE OpenEyes Moorfields Eye Hospital OEyes UK Nas Tabelas 5 e 6, alguns Fornecedores são listados mais de uma vez, o que representa que os mesmos implementaram seus sistemas em mais de uma instituição ou desenvolvem outros sistemas. Os casos em destaque são da Marand (Eslovênia), Code24 (Países Baixos), Ocean Informatics(Austrália), Infinnity, (Rússia),CaboLabs(Uruguai) e a Technical University of Valencia (Espanha). Foram obtidas duas respostas dos e-mails, a primeira da Marand 22que enviou informações a respeito dos campos solicitados na Tabela 7. As informações contidas na resposta desse e-mail foram úteis em um estudo já incluído na revisão, [17]. Na seção de resultados, as informações do e-mail são apresentadas. A segunda empresa foi a Critical Software AS 23 de Portugal. No e-mail há agradecimento pelo contato, e justificativas quanto a não profundidade de algumas informações fornecidas. O conteúdo do e-mail enviado (Apêndice A) encontra-se no final desse trabalho. 22 23 www.marand.com http://www.criticalsoftware.com/pt/homepage 41 6. Estudos encontrados por meio de buscas realizadas nas bases: (ACM) Digital Library, Institute of Electrical and Electronics Engineers (IEEE) Xplore, Elsevier, Emerald, ISI Web of Science, ScienceDirect e PubMed. O período da busca foi entre 2009 e 2014. Os termos de busca foram: “Electronic Medical Record” and Standards; “Electronic Medical Record” and Profiles; “Electronic Medical Record"and Development; “Electronic Medical Record” and “Data Integration”; “Electronic Medical Records” and Standards; “Electronic Medical Records” and Profiles; “Electronic Medical Records” AND Development; “Electronic Medical Records” AND “Data Integration”; “Electronic Health Record” AND Standards; “Electronic Health Record” AND Profiles; “Electronic Health Record” AND Development; “Electronic Health Record” AND “Data Integration”; “Medical Record Systems” AND Standards; “Medical Record Systems” AND Profiles; “Medical Record Systems” AND Development; “Medical Record Systems” AND “Data Integration”; “Computerized Medical Records Systems”; “Computerized Patient Medical Records”; “Computerized Medical Record System”; “Computerized Medical Record Systems”; “Computerized Medical Records System”; “Computerized Medical Records”; “Computerized Medical Record”. Nenhum novo trabalho foi encontrado nessa busca. 3.3 Coleta de Dados Nesta etapa, todos os estudos selecionados foram lidos integralmente. Um mecanismo utilizado para auxílio no processo de leitura dos estudos foi uma planilha eletrônica com 20 campos delimitados que faz referência a determinado assunto ou informação contida no estudo. A Tabela 7 apresenta os campos com sua respectiva descrição. 42 Tabela 7. Campos da planilha para extração de informações dos artigos Variável Ferramentas e Linguagens Abordagem Utilizada Ambiente em Nuvem Segurança de Rede Descrição Ferramentas tecnológicas utilizadas, como Linguagens de programação, servidores web, frameworks, etc. (Distribuída, centralizada ou híbrida) Caso utilizem Cloud Computer para armazenamento e/ou processamento de informações Quais os requisitos e mecanismos de segurança de rede utilizados Padrão/Especificação OpenEHR ou ISO 13606 Projeto/Produto Nome do produto ou projeto utilizado no Estudo Licença Qual tipo de licença do produto (Open Source/Proprietária) Banco de Dados Mecanismo (s) de armazenamento utilizado Tamanho do Banco Tamanho em GB. Modelo de Dados Estrutura de armazenamento dos dados. Objeto de Consulta Linguagem de Consulta utilizada ((SQL, AQL, Xquery, etc) Nº de Registros de Pacientes Informações Demográficas? Solução de Persistência Quantidade atual de registros armazenados no banco de dados. Caso a solução proposta no artigo trata de Informações Demográficas Descrição do mecanismo de persistência da solução descrita no estudo Avaliação de Desempenho Descrição das avaliações de desempenho da solução Plataforma Mobile? Caso a proposta/sistema/produto utiliza alguma funcionalidade em dispositivos móveis Número de Citações Quantidade de citações do estudo por outros artigos. Em produção? Informação se o produto/solução/sistema ainda está em pleno funcionamento. 3.4 Agrupamento e apresentação dos dados Fase importante no processo da revisão, representa os dados agrupados no formato da planilha eletrônica com os campos já preenchidos de modo que as informações possam ser interpretadas. Por meio do agrupamento, foi possível classificar as informações dentro de categorias, permitindo a realização de uma análise crítica e comparativa. 43 CAPÍTULO IV 4. Resultados Nesta seção são apresentados os principais resultados da revisão. 4.1 Estudos incluídos na Revisão A Tabela 8 mostra os 21 estudos incluídos com o ano em que foram publicados. Tabela 8. Estudos incluídos na revisão Estudo [01] [02] [03] Título A Cloud-based Approach for Interoperable Electronic Health Records (EHRs) pyEHR: a scalable clinical data management toolkitfor biomedical research projects yourEHRM: standard-based management of your personal healthcare information Ano 2013 2014 2014 [04] OpenEHR aware multi agent system for interinstitutional health data integration 2014 [05] Medical Informatics System for RomanianHealthcare System 2011 [06] [07] [08] [09] [10] [11] Proof-of-concept Design and Development of an EN13606-based Electronic Health Care Record Service Evaluation of software maintainability withopenEHR – a comparison of architectures "The iCabiNET system: Harnessing Electronic Health Record standards from domestic and mobile devices to support better medication adherence" Implementation of an end-to-end standard-based patient monitoring solution Applying representational state transfer (REST)architecture to archetype-based electronic healthrecord systems Standardized and flexible health data Management with an archetype driven EHR system (EHRflex) 2007 2014 2012 2008 2013 2010 [12] Evaluation of a Framework to Implement EHR Systems 2016 [13] Towards the Implementation of an openEHR-based Open Source EHR Platform 2015 [14] An openEHR repository based on a native xml database 2012 [15] [16] [17] [18] [19] Archetype relational mapping - a practical openEHR persistence solution Quasi-Relational Query Language Interface for Persistent Standardized EHRs: Using NoSQL Databases Archetype-based data warehouse environment to enable the reuse of electronic health record data Performance of XML Databases for Epidemiological Queries in Archetype-Based EHRs Design of an Electronic Healthcare Record Server Based on Part 1 of ISO EN 13606 2015 2013 2015 2012 2011 [20] An Electronic Healthcare Record ServerImplemented in PostgreSQL 2015 [21] Comparing the Performance of NoSQLApproaches for Managing ArchetypeBasedElectronic Health Record Data 2016 44 Reposta das consultas realizadas a desenvolvedores Como já mencionado na seção 3.2 que trata da Seleção e Avaliação Crítica dos Estudos, foram enviados e-mails a fornecedores (Tabela 6) que implementam sistemas de informações em saúde baseados nas especificações openEHR ou na norma ISO 13606. A Tabela 9 apresenta as informações fornecidas pela empresa respondente, Marand. A empresa é responsável pelo produto Think!EHR Platform 24, uma plataforma de dados de saúde baseada em padrões de dados abertos, desenvolvida para armazenamento, consulta, recuperação e troca de dados transacionais de saúde em tempo real. A plataforma é utilizada na implementação do sistema proposto por MARCO-RUIZ et al.[17]. Tabela 9. Informações do produto Think!EHR Platform, da Marand. Produto Variável Descrição Think!EHR Platform Plataforma central é desenvolvida em Java; Ferramentas e Linguagens Web Services and REST API, Web SOAP, REST, Java Remoting. Abordagem Utilizada Ambiente em Nuvem Segurança de Rede Padrão/Especificação Licença Banco de Dados Objeto de Consulta Solução de Persistência Servidor Web: Embedded. A solução suporta modelos de implantação diferentes, variando de único nó (centralizado) ou distribuída EhrScape - https://www.ehrscape.com/ Camada de transporte com SSL / HTTPS, e API REST OpenEHR Licença comercial. Há contribuições (código aberto): - https://github.com/openEHR/adl2-core - https://github.com/openEHR/adl-designer - https://github.com/ehrscape/examples Suportada por Oracle, PostgreSQL, IBM DB2, MS SQL AQL DB como um armazenamento para composições BLOB. O processamento da consulta se faz fora do DB. A plataforma separa a camada de índices da camada de persistência. A camada de persistência pode conter qualquer solução de banco de dados ou até mesmo um sistema de arquivos. 4.2 Difusão das especificações openEHR/ISO 13606 nos continentes A Figura 08 mostra os continentes em que a norma ISO 13606 e as especificações openEHR são adotadas em implementações. Esses padrões e especificações têm sido mais difundidos na Europa (n=14), e na América do Sul (n=4). 24 Think! EHR Platform. Disponível em: http://www.marand-think.com/pt/index. 45 Figura 8. Difusão openEHR/ISO 13606 nos continentes. Fonte: http://www.dreamstime.com/royalty-free-stock-photo-colorful-continents-world-mapimage38235795. Adaptada. 4.3 Frequência das publicações por ano e por base pesquisada No processo de busca, vários estudos foram localizados em bases diferentes, ou seja, alguns estudos podem ser encontrados pelo menos em duas bases de dados distintas, o que indica uma maior disponibilidade para a coleta e em um número geral de estudos maior do que a quantidade de incluídos nesta revisão. Nesse caso, o critério de seleção (eliminação dos repetidos) deu-se a partir da ordem de busca pelas bases, como mostra a Tabela10, em que são apresentados os 21 estudos incluídos na revisão. O item “Outras” se refere à busca pelas referências bibliográficas dos artigos, como explicado na seção 3.2. 46 Tabela 10. Estudos incluídos localizados nas bases e sua seleção 1. ACM digital 2. Emerald 3. 4. IEEE Xplore ISI Web 5. Elsevier ● ● ● ● ● S1 S2 S3 S4 S5 Outras 7. Zotero ● ● ● ● ● S6 S7 ● S8 6. PubMed ● ● ● ● ● ● ● ● ● S9 S10 S11 ● S12 ● S13 ● ● S14 ● S15 ● ● S16 ● S17 ● S18 S19 ● ● ● ● ● ● 7 9 ● S20 S21 1 Total Legenda: 0 6 0 4 9 ●Estudo incluído pela base, na revisão ●Estudo não incluído pela base, na revisão. A partir dessa análise, as bases que se destacaram são o grupo de publicações do openEHR (Zotero), a IEEE e PubMed. A Figura 9 apresenta a curva de evolução dos artigos, ao longo do tempo, agrupados por base de dados. Percebe-se um crescimento do número de publicações a partir do ano de 2012. 47 5 ISI Web EMERALD Quantidade de Estudos 4 ZOTERO 3 PUBMED IEEE 2 ACM 1 ELSEVIER OUTROS 0 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 Ano de publicação Figura 9. Quantidade de estudos no período de 2007 a 2016. 4.4 Projetos/Produtos apresentados nos estudos Um número crescente de países esforça-se no desenvolvimento de RES baseados no openEHR/ISO 13606, o que resulta na construção de vários projetos ou produtos implementados em diversas instituições. Nessa revisão da literatura, nem todos os projetos/produtos usaram um nome registrado, com uma denominação específica, como CHISTAR no sistema proposto por BAHGA e MADISETTI[01], como mostra a Tabela 11. Tabela 11. Nomes dos produtos/projetos e local de desenvolvimento. Produto/Projeto Chistar [01] PyEHR [02] yourEHRM [03] Vepr [04] DESP [05] [06] GastrOS [07] iCabiNET [08] [09] Liu EEE [10] EHRflex [11] EHRGen [12] EHRServer [13] [14] ARM [15] [16] [17] [18] [19] [20] [21] Instituição/Organização Georgia Institute of Technology Instituto de Pesquisa Científica ATOS Research and Innovation Faculdade de Medicina Universidade do Faculty of Automation and Computer Hospital Universitário “Puerta de Hierro” The University of Auckland University of Vigo University of Zaragoza Universidade de Linköping Universidad Politécnica de Valencia Universidad Nacional de Tucumán CaboLabs University of Aveiro Universidade de Zhejiang University of Aizu University Hospital of North Norway Universidade do Estado do Rio de Janeiro University College London University College London Universidade do Estado do Rio de Janeiro País Geórgia Itália Espanha Portugal Romênia Espanha Nova Espanha Espanha Suécia Espanha Argentina Uruguai Portugal China Japão Noruega Brasil Inglaterra Inglaterra Brasil Modelo OpenEHR OpenEHR OpenEHR OpenEHR OpenEHR ISO 13606 OpenEHR OpenEHR ISO 13606 OpenEHR ISO 13606 OpenEHR OpenEHR OpenEHR OpenEHR OpenEHR OpenEHR OpenEHR ISO 13606 ISO 13606 OpenEHR 48 Os dados apresentados mostram que os produtos desenvolvidos originam-se de instituições de pesquisa (n=20) e de instituições de saúde (n=1), como no caso do estudo do Hospital Universitário “Puerta de Hierro” de MUNOZ et al.[06], na Espanha. 4.5 Classificação dos estudos incluídos Os estudos foram classificados de acordo com sua natureza nas seguintes categorias: • Sistemas de RES (S-RES) – 7 estudos; • Sistemas de Integração/Plataforma – 7 estudos. Esta categoria abrange os sistemas responsáveis por interagir com outras tecnologias, como consulta a outros sistemas de informações ou plataformas, kit de ferramentas e ambientes para desenvolvimento de Sistemas de Registros Eletrônicos em Saúde; • Repositórios – 7 estudos. Esta categoria abrange estudos que abordam comparações entre mecanismos de persistência e experimentos de avaliação quanto à inserção e consulta de dados. As Tabelas 12, 13 e 14 apresentam, respectivamente, de acordo com a classificação, um breve resumo de cada estudo, juntamente com as suas características técnicas. Na tabela 12 e 13, as propostas apresentam mais informações de arquitetura. Isso se deve ao fato de pertencerem à classificação destinada às implementações dos sistemas. Uma arquitetura distribuída, diz respeito ao ambiente em que as informações são ou podem ser processadas e armazenadas em um modo distribuído; Ao contrário disso, um modelo centralizado, é quando o modelo de armazenamento, segundo a arquitetura da proposta, se dá em um nó (servidor). 49 Tabela 12. Resumo dos estudos classificados como Sistemas RES Resumo O estudo aborda uma proposta de arquitetura de Registro Eletrônico de Saúde chamada (CHISTAR®).Este sistema possui sub-aplicações e módulos que integram hospitais, farmácias, etc. O Sistema RES CHISTAR® é implementado com os benefícios das tecnologias de nuvem por meio da Amazon Compute Cloud (EC2) (AMAZON, 2015), e que [01] permite a interoperabilidade de dados por meio de um motor de Arquitetura • Compute Cloud (EC2 – Amazon); • framework Hadoop MapReduce 25. integração e interoperabilidade semântica com o uso de arquétipos. O • Distribuída; sistema possui um módulo de integração de dados, que integrada • Web Service REST informações clinicas (estruturados ou não) de diferentes sistemas de armazenamento de dados, tais como bancos de dados relacionais (RDBMS, como MySQL, Oracle, etc.), servidores de arquivos (como API. • Escalável texto, imagem, arquivos de vídeo, etc.) e mensagens HL7. O estudo trata de uma ferramenta que permite consultar as informações e extrair os dados relevantes do EHR em vários modelos de dados, tais como openEHR ou HL7. É uma solução baseada em modelos de informação genéricos que estão em conformidade com a norma EN13606 e openEHR. A ferramenta, denominada yourEHRM, possibilita a troca de informações com outros Sistemas de Informações. A arquitetura do sistema permite a integração de dados provenientes de [03] • Web Service SOAP e REST; sistemas de informação de saúde heterogêneos e fragmentados. Para • Distribuída; mecanismo de armazenamento e persistência de dados, utiliza bancos • Escalável de dados NoSQL orientados a documentos, MongoDB 26. O middleware e interfaces da arquitetura são implantados como serviços baseados em REST API (uma interface de programação de aplicativos que, usa solicitações HTTP para GET, PUT, POST e DELETE) e usa documentos JSON para fornecer a informação. Esta abordagem permite a extração fácil da informação, através de consultas AQL (Archetype Query Language). 25 26 MapReduce Tutorial - Apache™ Hadoop. Disponível em: https://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html MongoDB for GIANT Ideas | MongoDB. Disponível em: https://www.mongodb.com/ 50 Apresenta o VERP (Virtual Electronic Patient Record Patient), um sistema que contém as informações médicas de um paciente, armazenadas em uma variedade de sistemas em diferentes localizações. Integra dados interinstitucionais utilizando as especificações openEHR para consulta e armazenamento de dados. Fornece meios para construir consultas semânticas, independentemente do modelo de dados do [04] • Web Service sistema remoto subjacente. É uma abordagem Multi-Agent. Os Integration Gateway resultados de uma simulação mostraram que os agentes podem coletar (WSIG), SOAP; dados de fontes externas. A troca de dados entre os sistemas é baseada em consulta AQL no repositório remoto para recuperar extratos. O extrato openEHR é visualizado devido a uma transformação XSLT de extratos • Distribuída; • Escalável XML em HTML. Como repositório é utilizado o eXist-db 27, acessível por meio de uma série de serviços. Também utiliza XQuery para consultas, e pode executar qualquer consulta em AQL. Embora armazena informações em XML, os clientes podem utilizar outros tipos de formato, como por exemplo, HTML, JSON e YAML. Este trabalho descreve um software denominado DESP (sigla em Romeno para o Arquivo Eletrônico de Saúde do Paciente), um modelo experimental baseado na web com tecnologias open-source. Apresenta uma perspectiva local, correspondente a uma unidade médica e nacional que representa todo o sistema médico do país. Em nível nacional, ele descreve como interconectar os sistemas locais individuais. Ele cria uma rede nacional de sistemas nas unidades médicas que comunicam entre [05] si. Como uma unidade médica local entende-se uma instância de um sistema a partir do nível local, que armazena os dados e se comunica com outros sistemas semelhantes. O design do nível local é composto • Centralizada/Distrib uída; • Escalável. de três níveis: a) Nível de dados (Camada de dados), o Nível lógico (Lógica de negócios) e o Nível de Apresentação (Camada de Apresentação). O sistema adota o Repositório Nacional de Arquétipos, que contém todas as informações necessárias definidas em nível nacional de acordo com as especificações openEHR. Por razões de velocidade e estabilidade no sistema, cada arquétipo é salvo localmente. 27 eXistdb - The Open Source Native XML Database. Disponível em exist-db.org/ 51 O artigo apresenta um protótipo, instalado em cenário real, de um servidor RES desenvolvido para a transferência de extratos em conformidade com a norma EN13606. O sistema é composto por cinco módulos: a) As bibliotecas para a gestão do modelo de referência padrão, para o pacote demográfico e para os tipos de dados; b) O módulo de [06] armazenamento permanente, construído sobre uma base de dados relacional; c) Duas interfaces de comunicação por meio das quais os clientes podem enviar informações ou fazer consultas; d) O processador • CORBA e SOAP Web Services para comunicações entre máquinas remotas; • Cliente/Servidor (Distribuída); XML e as ferramentas para a validação dos extratos gerenciados, implementados em um esquema XML 28; e) Uma linguagem baseada no formato XML para definição de regras de validação ("esquemas"). O estudo apresenta uma comparação entre dois sistemas com enfoques diferentes para o desenvolvimento de aplicações: um chamado GST e [07] um outro baseado no modelo openEHR, chamado GastrOS. A aplicação • Cliente/Servidor GST segue a abordagem de programação objeto-procedimental e uma (Centralizada); modelagem de dados relacional. GastrOS é uma implementação • Não Escalável; openEHR desktop, utilizando plataforma .Net e C#. As principais características tecnológicas do sistema GastrOS são: plataforma Net e • MVC C#;a biblioteca openEHR.Net;SQLite versão 3 e MS SQL Server como Banco de Dados. Na persistência de dados, primeiramente a instância do valor preenchido é serializado como XML e em seguida, armazenado no banco. Os artefatos e código-fonte estão disponíveis no site: http://gastros.sourceforge.net. O estudo aborda um sistema de RES baseado no OpenEHR com fins educacionais (LiU EEE). Este ambiente educativo é destinado a ajudar os desenvolvedores e público interessado a experimentar e aprender sobre a abordagem de RES baseado em arquétipos e permitir uma prototipagem rápida. A implementação do LiU EEE se baseia em Java [10] (lado do servidor) e um banco de dados XML é utilizada para repositório. • Cliente/Servidor No lado do cliente, ele utilizaJavaScript e HTML5. O software está (Centralizada) disponível como código aberto sob a licença Apache 2. Embora o LiU EEE armazene informações em XML, os clientes podem utilizar outros tipos de formato, como por exemplo, HTML, JSON e YAML. 28 • REST API; W3C XML Schema. Disponível em: https://www.w3.org/XML/Schema 52 Tabela 13. Resumo dos estudos classificados como Sistemas de Integração/Plataforma. Resumo O estudo descreve a plataforma pyEHR 29, um conjunto de ferramentas Arquitetura para a construção de sistemas clínicos de gerenciamento de dados para aplicações de pesquisa biomédica. É um kit de ferramentas, usa formalismos openEHR para garantir a dissociação das descrições de dados clínicos de detalhes de implementação e tecnologias NoSQL para fornecer armazenamento escalável. O sistema possui três componentes: a) Sistema de Gestão de Dados, que lida com o armazenamento de [02] dados e recuperação; b) Sistema de Gestão de Informação, que lida com • Arquitetura REST os recursos openEHR; c) Mecanismo de Consulta, que utiliza a • Distribuída; Archetype Query Language, anteriormente conhecido como linguagem • Escalável. de consulta de EHRs (EQL) (MA et al., 2007). O pyEHR foi escrito em grande parte em Python. O Sistema de Gestão de Dados e o Mecanismo de Consulta foram concebidos para suportar dados de múltiplas tecnologias de gerenciamento via drivers conectáveis, a fim de alcançar os objetivos de escalabilidade (vertical, horizontal ou ambos). Quanto ao mecanismo de armazenamento e persistência de dados, a implementação atual utiliza o MongoDB. 29 PyEHR é distribuído como código aberto e disponível no GitHub https://github.com/crs4/pyEHR 53 Esta proposta, denominada iCabiNET, visa interagir com o repositório do RES com base em dispositivos domésticos e móveis. O elemento-chave do iCabiNET é o Archetype Manager, que conta com um analisador ADL para processar o arquétipo. A arquitetura utiliza bibliotecas JDOM 30 para o processamento do conteúdo XML. O Archetype Manager é também responsável poracessar o repositório do RES. Para isso, ele invoca duas [08] • Web interfaces diferentes: uma baseada no paradigma de chamada remota de baseados RMI Java, e a outra baseada em tecnologia de Web Services para SOAP; dispositivos móveis, o WS J2ME (AGARWAL; LAU, 2010). Na arquitetura, quanto à segurança no tráfego, todas as comunicações entre o cliente iCabiNET e o repositório do RES fluem por meio de túneis Services em • Centralizada (Cliente/Servidor; • Não Escalável. SSL 31, usando as funções criptográficas da Security and Trust Services API32 para dispositivos móveis. Nessa proposta, implementações openEHR podem facilmente gerar e consumir dados EN13606, portanto, uma eventual adaptação do iCabiNET à tecnologia EN13606 não deve exigir muito esforço. Este trabalho é uma solução de monitoramento de pacientes em ambientes de unidade de terapia intensiva. É baseado no padrão end-toend, usando as normas ISO/IEEE 11073 e EN13606. O padrão ISO/IEEE 11073 permite a comunicação entre dispositivos médicos e sistemas de registros médicos de saúde. O sistema fornece captura [09] eletrônica detalhada da informação do dispositivo do cliente, como os sinais vitais. A aplicação possui uma rede de sensores plug-and-play que se comunica com um gateway que recolhe a informação médica e envia • Web Services based SOAP; • Centralizada (Cliente/Servidor; • Não Escalável. os dados para um servidor de monitoramento; em seguida o servidor de monitoramento transforma esses dados em um extrato EN13606 para ser armazenado no servidor RES. Apresenta um sistema baseado em arquétipos, de código aberto, para a construção de um prontuário eletrônico baseado na web, denominado EHRflex. A aplicação habilita o profissional (médico, especialista, etc.) a [11] gerir o seu próprio sistema RES em uma base simples e formal, assegurando que o usuário trabalha com estruturas de dados padronizados subjacentes baseados na norma ISO 13606. Como repositório, utiliza o eXistdb. 30 31 32 www.jdom.org/ http://searchsecurity.techtarget.com/definition/SSL-VPN http://www.oracle.com/technetwork/java/satsa-136426.html • Centralizada (Cliente/Servidor; • Não Escalável; • MVC 54 Aborda o projeto EHRGen, uma ferramenta de software, guiada pela gestão do conhecimento clínico, para a criação de sistemas de registros de saúde eletrônicos (RSE). Possui três componentes fundamentais na arquitetura: a) o repositório clínico (RC), que mantém todas as [12] informações do paciente clínico em um formato para atender o modelo • Centralizada (Cliente/Servidor; de informação padrão;b) o repositório demográfico (DR), que contém os • Não Escalável. dados de organizações, pessoas e os seus papéis (paciente, médico, • MVC etc.); c) a base de conhecimento (BC), que mantém os arquétipos e terminologias que serão utilizados por sistemas EHR. Utiliza MySQL ou PostgreSQL como opções de repositório e o Hibernate (Persistência). Apresenta um protótipo chamado EHRServer, um repositório de dados clínicos baseado no openEHR. Fornece serviços de armazenamento e consulta de informações clínicas. As principais características do repositório são: a) é Open Source; b) suporta dados XML e JSON; c) [13] acesso a auditoria para rastreabilidade; d) possui interface para criação de consultas; e) suporta qualquer estrutura de documento clínico; f) é “Multitenancy”, ou seja, uma aplicação que atende a múltiplos clientes como empresas/organizações. Tanto O EHRServer como EHRGen [12] são fornecidos pela CaboLabs Healthcare Informatics 33. São sistemas • Plataforma Ready(Nuvem) • API REST; • SOA 34 (Arquitetura Orientada Serviços); • MVC. diferentes que utilizam, em grande parte, as mesmas tecnologias. 33 34 Cloud CaboLabs Healthcare Informatics. Disponível em: cabolabs.com/ SOA: Arquitetura proposta para interoperabilidade de sistemas por meio de um conjunto de interfaces de serviços fracamente acoplados, onde os serviços não necessitam de detalhes técnicos da plataforma dos outros serviços para a troca de informações ser realizada(EPING_V2016, 2016). a 55 O objetivo da proposta é promover o desenvolvimento de sistemas de informação de saúde com base na norma openEHR, permitindo uma integração de várias áreas clínicas (por exemplo, radiologia, administração, farmácia), e tornar o processo mais unificado por meio de serviços web e um aplicativo de administração. Na proposta, é permitido que os pacientes acessem sua própria informação médica. O sistema [14] • Centralizada possui arquitetura projetada para dividir as funcionalidades em três • Não Escalável; camadas, seguindo o modelo de Arquitetura Orientada a Serviços (SOA): • Arquitetura a) camada de aplicação -possui uma aplicação web com um determinado Orientada conjunto de serviços ao cliente, que valida as funcionalidades do Serviços (SOA) repositório openEHR. A aplicação funciona como uma plataforma de • API RESTful administração para qualquer repositório; b) camada de serviço -um conjunto de serviços que permitem a gestão remota e transparente do armazenamento e das consultas a informações contidas no RES; c) núcleo, que possui um banco de dados XML nativo como tecnologia de armazenamento. Tabela 14. Resumo dos estudos classificados como Repositórios Resumo Apresenta uma solução de persistência para registros eletrônicos de Arquitetura saúde baseados em arquétipos: ARM (Archetype Relational Mapping). Essa solução usa uma técnica que mapeia os arquétipos para tabelas de bancos relacionais. Um estudo comparativo foi realizado para investigar as diferenças entre o banco de dados convencional de um sistema de saúde em um hospital na China, o banco de dados ARM e um banco de dados Node + Path. Cinco testes de recuperação de dados foram [15] projetados com base no fluxo de trabalho clínico para recuperar exames • Centralizada; e testes laboratoriais. Além disso, dois testes de consulta foram • Escalável. projetados para identificar os pacientes que satisfazem determinados critérios. A base de dados ARM teve melhor desempenho na maioria dos testes. Quanto ao banco de dados Node + Path, objetos são serializados 35 em blobs ou strings em bancos relacionais ou objetorelacionais. Nessa abordagem, todos os nós de dados são serializados, e seus caminhos são registrados em uma tabela em que se armazena o <caminho do nó> e o <valor do nó serializado>(BEALE, 2008). 35 Processo que converte um objeto em um fluxo de bytes, para que ele possa ser persistido na memória, num banco de dados, ou num arquivo. Sua finalidade é salvar o estado de um objeto para ser capaz de a 56 O estudo apresenta a persistência de RES utilizando um banco de dados NoSQL. O gerador de consulta AQBE (SACHDEVA et al., 2012) é proposto para consultar informações em RES padronizados baseados no openEHR, usando um banco de dados NoSQL. O sistema AQBE serializa o RM e os arquétipos (openEHR) em formato JSON.. A arquitetura é dividida entre o cliente e o servidor. O lado do cliente possui [16] o editor de consultas AQBE, que permite que o usuário insira e consulte os dados no RES. O lado do servidor é composto por dois repositórios de dados: o repositório de arquétipos local e o repositório de dados RES. Apresenta uma comparação utilizando a AQL em uma base openEHR, a • Play framework 36 (Nuvem); • Cliente/Servidor; • Centralizada/Distrib uída; • Escalável. interface AQBE em uma base relacional e o sistema AQBE proposto. Esses dois últimos apresentaram os melhores resultados, sendo que o AQBE proposto preservou, na consulta, a semântica dos conceitos. Este trabalho apresenta um ambiente de armazém de dados para resolver os desafios de interoperabilidade e de infraestrutura na reutilização de dados clínicos, utilizando arquétipos. A abordagem age sobre um sistema chamado SNOW que gera as informações médicas SOAP, correspondente a uma unidade médica e outra nacional que representa Java Remoting como interconectar os sistemas locais individuais, bem como componentes adicionais necessários. A arquitetura da proposta é dividida em quatro partes: a modelagem, extração, transformação e a carga para exploração dos dados existentes no RES do sistema SNOW. A infraestrutura tecnológica utilizada compreende: a) ETL 37 (Extract Transform Load), que extrai dados de diversos sistemas, transforma-os conforme regras de negócios e por fim realiza a carga desses em um data warehouse; b) LinkEHR - ferramenta que transforma os dados clínicos existentes em um formato padrão. Como mecanismo de persistência é utilizada a Plataforma Think!EHR. 36 37 Services dos pacientes. A proposta apresenta duas perspectivas, uma local que todo o sistema médico do país. Em nível nacional, o sistema descreve [17] • Web recriá-lo quando necessário.Disponível em: https://msdn.microsoft.com/ptbr/library/ms233836(v=vs.90).aspx. Play Framework. Disponível em: https://www.playframework.com/ ETL - Data Warehouse. Disponível em datawarehouse4u.info/ETL-process.html RESTful, • Spring MVC Framework; • Embedded web server; • Centralizada/Distrib uída; • Escalável. 57 O estudo mostra uma comparação do desempenho de banco dados XML, por meio da avaliação do tempo de resposta. Dados do Sistema Nacional de Informação sobre o Rastreamento do Câncer do Colo do Útero – SISCOLO foram armazenados em duas tabelas em um banco de dados relacional, o MySQL. Em uma outra etapa, as tabelas foram convertidas em objetos seguindo o RM do openEHR. Os objetos [18] convertidos em XML foram armazenados nos bancos de dados XML (eXist, Basex 38,Sedna 39e XML Berkeley DB 40). • Centralizada. Consultas epidemiológicas foram realizadas nos bancos XML com AQL/xQuery, e no MySQL (relacional) usando SQL. Todas as bases XML tiveram desempenho pior em comparação com a base relacional. O MySQL obteve melhor desempenho, seguido de Sedna, Basex, eXist e Berkeley DB XML. A pesquisa demonstra uma arquitetura para a implementação de um servidor RES compreendendo um repositório que está em conformidade com a Parte 1 da ISO EN 13606. A arquitetura utiliza middleware para processar instâncias do registro. A arquitetura utiliza arquétipos (136062) para a validação de dados. O servidor em si compreende uma série de módulos individuais constituídos por hosts. O servidor é composto por [19] serviços de autenticação, gerenciamento de dados demográficos, recuperação de registros, auditoria e alguns serviços estendidos para a gestão clínica.O sistema utiliza ORM (Hibernate) e o banco de dados • Cliente/Servidor; • Centralizada (Implementação); • Escalável PostgreSQL. Na recuperação de dados, o servidor possui um módulo que contém um conjunto de funções que permitem vários tipos de recuperação de dados com base no identificador do arquétipo. O módulo usa EJB-QL 41(Enterprise Java Beans Query Language). 38 39 40 41 BaseX | The XML Database. Disponível em: basex.org/ Sedna XML Database. Disponível em: www.sedna.org/ Oracle Berkeley DB XML | Oracle.Disponível em www.oracle Chapter 7. EJB-QL: The Object Query Language. Disponível em: https://docs.jboss.org/hibernate/entitymanager/3.4/reference/en/html/queryhql.html 58 O estudo descreve a implementação de um servidor EHR dentro de um banco de dados relacional, o PostgreSQL. O servidor roda sem dependência de qualquer outra infraestrutura de middleware. A arquitetura é hibrida: (a) com a utilização do Hibernate em algumas funções, como por exemplo, nas consultas (EJB-QL) que são baseadas [20] em nomes de tabelas e de colunas que fazem sentido para especialistas do domínio; (b) os dados do modelo de referência e dos índices de cada nó foram representados por duas tabelas.Isto permitiu a redução do • Cliente/Servidor; • Centralizada; • Escalável. número de tabelas nas consultas. Os dados dos pacientes são visíveis para usuários, de acordo com suas permissões. Os usuários são classificados como: (a) administrador, usuário; pesquisador; cuidador e paciente. Este estudo trata-se de uma avaliação de desempenho experimental por meio de consultas de base populacional em bancos de dados NoSQL. Foram utilizados como parâmetros dos resultados, a capacidade de armazenamento do BD e o tempo de resposta da consulta. O experimento utilizou dados de quatro sistemas de informações do SUS. Os dados foram extraídos para uma tabela no esquema relacional do MySQL. Posteriormente esse conjunto de registros foram mapeados em documentos XML e JSON, de acordo com o modelo de informação do openEHR. Os documentos XML foram armazenados nos bancos de [21] dados XML: BaseX, eXistdb e Berkeley DB XML, e os documentos JSON • Distribuída; foram armazenados no banco de dados distribuído NoSQL baseado na • Escalável. abordagem MapReduce, o Couchbase 42. Como resultados, no quesito capacidade de armazenamento, os arquivos JSON (Couchbase) foram menores do que os arquivos XML, porém os dados no Couchbase exigiram mais espaço que o conjunto de dados no MySQL. Quanto ao tempo de resposta, as bases de dados XML foram mais lentas que o MySQL e o Couchbase, em consultas de base populacional ad hoc. O Couchbase, apesar de requerer mais espaço do que a base de dados relacional e exigir um tempo de indexação muito maior para cada nova consulta, obteve melhores tempos de resposta. 42 Couchbase: NoSQL Database. Disponível em www.couchbase.com 59 4.6 Taxa de citação A Figura 10 fornece uma visão da taxa de citações dos estudos. Os dados das NÚMERO DE CITAÇÕES citações foram coletados por meio do Google Scholar43. 52 49 45 29 S1 0 S3 1 S4 5 3 S5 S6 Sistema RES 9 0 S7 S10 S2 11 S8 10 17 4 5 2 1 0 0 0 0 S9 S11 S12 S13 S14 S15 S16 S17 S18 S19 S20 S21 Sistema de Integração/Plataforma Repositório CLASSIFICAÇÃO DOS ESTUDOS Figura 10. Quantitativo de citações por estudo de acordo com sua classificação. Coleta realizada em 20.05.2016. Pelo autor. Na classificação dos estudos por categorias, o percentual do total de citações por categorias foram: Sistemas RES- 49,0% (n=119); Sistemas de Integração/Plataforma - 39,5% (n=96); Repositórios - 11,5% (n=28). O estudo mais citado da presente revisão é o de MUNOZ et al.[06], publicado em 2007. O artigo é o mais antigo dentre todos. 4.7 Tecnologias utilizadas nas arquiteturas A Tabela 15 apresenta uma visão qualitativa das tecnologias adotadas nos projetos/produtos de cada estudo. 43 Google Scholar. Disponível em: http://scholar.google.com.br/ 60 Banco de Dados Serviços Linguagem de Consulta Estrutura de Armazenamento ● ● S21 S20 ● S19 S18 S17 S16 ● S15 S13 ● S14 S12 ● S11 ● S10 S9 S7 S6 S5 S4 ● S8 MySQL PostgreSQL Oracle SQL Server SQLite MongoDB Hbase eXist BaseX Couchbase Berkeley DB XML Não definido XML JSON XML ou JSON Tabelas Relacionais AQL XQuery SQL HQuery AQL XPath/Xquery AQBE AQL + SPARQL EJB-QL Não definido REST SOAP REST/SOAP CORBA/SOAP REST/SOAP/Java Remoting S3 S1 S2 Tabela 15. Variáveis qualitativas contidas nos projetos/produtos de estudo ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● Σ 5 3 0 1 1 3 1 3 1 1 1 1 12 3 4 3 5 8 6 1 3 0 1 1 2 2 4 4 3 1 1 Frameworks e Linguagens Licença JVM Google Web Toolkit EJB 3/Jboss Não definido Apache 2.0 Open Source AGPL ● Comercial GPL/MPL Não definido .Net Axis C# C/C++ Eclipse/NetBeans Eiffel FreeMarker GRAILS + Groovy (MVC) Java ● JavaScript Maven Visual Studio Python SAX Scala Smarty + PHP5 Spring MVC ZK JSF (MVC) Não definido S21 S20 S19 S18 S17 S16 S15 S14 S13 S12 S11 S10 S9 S8 S7 S6 S5 S4 S3 S1 S2 61 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● Σ 1 1 2 4 5 9 1 3 1 2 1 2 1 2 2 1 3 2 13 2 1 1 1 1 1 2 1 1 2 2 62 JAVA destaca-se como linguagem de programação no cenário das implementações. Xquery foi a linguagem de consulta mais utilizada, uma vez que muitos projetos utilizaram bancos de dados XML em suas implementações, seguida de AQL, uma linguagem de consulta em uso extensivo em uma implementação openEHR; e SQL, que acompanha o esquema relacional. O uso de Web Services (WS) apresenta destaque nas implementações. De acordo com SHENG et al.(2014), um serviço Web é essencialmente uma abstração semanticamente bem definida de um conjunto de atividades computacionais ou físicas envolvendo uma série de recursos, destinada a satisfazer uma necessidade do cliente ou um requisito de negócio. Os WSmais populares e implementados foram os baseados em SOAP e RESTful. O primeiro é baseado em WSDL, (Web Services Description Language) 44, uma linguagem que permite descreverem formato XML a interface de um serviço), o segundo está em conformidade com os princípios da arquitetura do REST. Algumas propostas usam os benefícios do padrão MVC. Esse é o padrão que separa o modelo (conteúdo de informações) da visualização (o que o usuário vê na tela) e do controlador (o que ocorre em resposta à entrada do usuário ou a um navegador que aponta para uma URL). Além disso, frameworks populares, como Spring, JSF(Java Server Faces) e GRAILS, facilitam a utilização do padrão MVC para ambientes distribuídos. 4.7.1 Comparação de arquiteturas de armazenamento Dentre os produtos/projetos implementados e abordados nos estudos, apresentamos os que utilizam banco de dados SQL (n=12) [05, 06, 07, 08, 09, 12, 13, 15, 17, 18, 19 e 20] e NoSQL (n=09) [01, 02, 03, 04, 10, 11, 14, 16 e S21]. A partir dessas informações, realizamos uma comparação das arquiteturas de armazenamento. Para realizar essa comparação, utilizamos a classificação de acordo com os resultados observados na seção 4.1, em que os estudos são representados por categorias. Modelos que representam as arquiteturas foram desenhados para apresentar suas similaridades e diferenças. As informações foram agrupadas de acordo com os seguintes serviços: 44 XML WSDL - W3Schools. Disponível em: www.w3schools.com/xml/xml_wsdl.asp 63 1. Armazenamento em banco de dados relacionais; 2. Armazenamento XML em banco de dados XML; 3. Armazenando JSON em banco de dados NoSQL. 1. Armazenamento em banco de dados relacionais A Figura 11 apresenta três modelos de arquiteturas em que o armazenamento se dá em bancos de dados relacionais, porém de maneira diferentes: a) solução ARM (Archetype Relational Mapping) para persistência em um RES baseado em arquétipo [15]: A solução ARM aborda uma técnica de persistência para um RES por meio de regras de mapeamento que gerenciam as versões dos arquétipos (novos e antigos) e mapeiam os arquétipos para o esquema relacional (tabelas, colunas, índices, etc.) para alcançar um melhor desempenho na recuperação de consultas. b) ORM (Object Relational Mapping) por frameworks [12], [13], [19] e [20]: A técnica ORM utiliza um mapeamento das classes do modelo de referência para uma representação do modelo de dados relacional. Essa técnica auxilia na construção da camada de acesso a dados, simplificando a implementação das operações básicas da camada de persistência (indexação, inserção/alteração, exclusão e leitura). Frameworks são utilizados, como o Hibernate [19] e [20], que tem como finalidade fazer a ponte de ligação com o banco de dados para obter persistência. As consultas são realizadas por meio do modelo de objetos utilizando a linguagem EJB QL. (c) Armazenamento XML no modelo relacional [05], [06], [08] e [09]. Na proposta de STAN et al.[05], não houve mapeamento. O PostgreSQL dispõe de um tipo de dados especial usado para armazenar dados XML, possibilitando a verificação de valores de entrada, além de armazenar documentos bem formados e armazenar fragmentos de conteúdo. Os arquétipos são salvos no formato XML. MUNOZ et al.[06] usam a API SAX para manipular o arquivo XML. Após o arquivo ser analisado pela API, ele é inserido no banco por meio do ODBC. Cada classe do RM é representada por uma tabela no MySQL. O ponto fraco da aplicação é no sistema de 64 armazenamento. Os tempos registrados durante o uso demonstraram que, com a configuração apresentada, houve grande demora na operação em um ambiente de tempo real. Figura 11. Persistência de dados utilizando mapeamento ARM (a), ORM (b) e XML (c). LÓPEZ-NORES et al.[08] usam a API JDOM para analisar o documento XML. Porém as informações do arquivo XML são carregadas como uma estrutura de dados em árvore na memória, para depois serem armazenadas no repositório MySQL. JDOMé a implementação disponibilizada pela linguagem Javada API DOM(Document Object Model), utilizada também por MARTÍNEZ, I. et al.09]. Experimentos foram realizados para analisar o desempenho e escalabilidade do repositório MySQL. Foi verificada a sobrecarga no sistema e o custo computacional na utilização das tecnologias de Web Services (SOAP, REST e Java RMI). Embora Java RMI apresentou melhores resultados, as diferenças em termos de custo computacional em relação a SOAP e REST foram pequenas. 65 Embora as arquiteturas apresentadas na Figura 11 apresentem armazenamento em bancos de dados relacionais, há uma grande diferença entre elas: o modelo de mapeamento. Em (a) não ocorre ORM, como método de persistência, pois o mapeamento, na abordagem, ocorre de maneira direta entre o arquétipo e banco de dados relacional por meio da técnica ARM. O objetivo desse método é de alcançar desempenho semelhante em relação às bases de dados convencionais na recuperação de consultas (não populacionais). A solução mapeia o arquétipo para uma tabela por meio de regras. Essas regras analisam o arquétipo. Caso não haja um item de identificação de dados no arquétipo, é gerado um item com a descrição "id" e utilizado uma chave para identificar os registros na tabela. Após o mapeamento, obtém-se o esquema relacional (tabelas, colunas, índices, relacionamentos, etc.). Em (b) ocorre ORM. A finalidade na utilização desse método é de aproveitar ao máximo o conceito de OO. Cada classe a ser armazenada é tratada no banco como uma tabela. É feito um mapeamento do Modelo de Referência para o modelo relacional, diferente do que ocorre em (a). Cada objeto de uma determinada classe é mapeado em uma tupla da tabela que representa sua classe. Os atributos da classe são as colunas da tabela correspondente(MURTA; VERONESE; WERNER, C. M. L., 2001). Não há uma concepção análoga no modelo relacional. Com essa técnica, o desenvolvedor poderá usar uma interface de programação simples onde o framework utilizado pode fazer todo o trabalho de persistência(NASCIMENTO, 2005). Em (c) não ocorre mapeamento. O tratamento do arquivo XML se dá ou por característica própria do banco de dados, no caso o PostgreSQL ou pelo uso de Analisadores (parser), ou seja, uma ferramenta que percorre um documento e extrai os dados relevantes. Nesses casos, os analisadores utilizam as interfaces SAX ou DOM para analisar documentos XML. 2. Armazenamento XML com banco de dados XML Nos estudos [04], [11], [14] e [18], os dados no formato XML são armazenados em bancos de dados XML nativos. Uma característica básica desses bancos é que eles lidam de forma mais natural com os dados semiestruturados em relação aos bancos de dados 66 relacionais, diferente do apresentado nos modelos do item I. Embora o MySQL, o SQL Server e o PostgreSQL possuam suporte a XML, as técnicas e armazenamento e consultas são diferenciadas em relação ao banco XML Nativo, devido à estrutura intrínseca do XML. VELTE et al. [14] utilizam o BaseX. A análise de desempenho foi realizada com operações de consulta e inserção de dados de um paciente. O processo de consulta foi mais rápido que o de inserção. No entanto, o tempo de inserção aumenta de acordo com o número de registros. Nessas circunstâncias, o repositório é mais adequado para sistemas que requerem uma resposta mais rápida a consultas individuais. Em outra avaliação, quando utilizado um mecanismo de indexação, os resultados foram semelhantes, porém, para consultas a atributos especiais ao longo de um conjunto de dados de vários pacientes, os tempos de resposta foram muito mais altos, e que depende do número de registros inseridos. Em FREIRE et al. [18], consultas epidemiológicas foram realizadas em bancos XML e em um banco de dados relacional. Os tempos de resposta dos bancos de dados XML deixaram muito a desejar, em comparação com a base de dados SQL. Para o BaseX, o tempo de resposta é muito elevado, mesmo para o menor conjunto de dados. O banco de dados relacional obteve um desempenho muito melhor que todos os bancos XML. Há duas soluções que apresentam uma arquitetura com existDB, porém de forma diferenciada. BLOBEL et al.[11] abordam uma arquitetura local ou primária,(VIEIRAMARQUES et al.[04], embora não apresentem uma análise de desempenho, adotam uma arquitetura em nível nacional, ou seja, o sistema armazena a informação médica em um paciente, coletada de outros sistemas locais (em hospitais e clínicas). 3. Armazenando JSON com banco de dados NoSQL Apresentamos na Figura 12, o modelo de banco de dados que pertencem à categoria NoSQL, o mongoDB [02, 03 e 16], como solução de código aberto, de alta performance e orientado a documentos. Essa solução não utiliza esquemas e o armazenamento das informações são em documentos no formato JSON. Uma grande característica nessas propostas [02, 03, e 16], é a utilização de um outro repositório para armazenamento de arquétipos XML que depois são convertidos 67 para o formato JSON. O paradigma da computação nas nuvens também é utilizado nesses estudos. Por sua característica própria (NoSQL), em todas as soluções com mongoDB há escalabilidade horizontal. As arquiteturas são do tipo cliente/servidor, em que no lado cliente, é permitido que o usuário consulte os dados no Servidor RES. O Servidor é composto por dois repositórios: (a) um local, que contém os arquivos XML correspondente aos arquétipos baixado no CKM; (b) o repositório RES, usado para recuperar resultados da consulta do usuário. Figura 12. Armazenamento distribuído em banco de dados NoSQL mongoDB. LIANAS et al.[02] e BARCA et al.[03] utilizam REST API para operações CRUD (Create, Read, Update, Delete). As propostas não apresentam uma avaliação de desempenho. Em MADAAN et al.[16], há um gerador de consultas que serializa os dados do RES e os arquétipos (openEHR) em formato JSON, o AQBE. O MongoDB é apresentado em duas comparações: a) a primeira com alguns tipos de consultas, utilizando a AQL em uma base openEHR, uma interface de consulta AQBE em uma base relacional. A proposta não apresenta uma avaliação de desempenho. Outras propostas também utilizaram bancos de dados NoSQL, como no estudo de BAHGA e MADISETTI [01], em que se utiliza o Hbase, um banco de dados distribuído, orientado a coluna, que fornece uma maneira tolerante a falhas de armazenar grandes 68 quantidades de dados dispersos. Na arquitetura é utilizado o HDFS, um sistema de arquivos que segue a estrutura MapReduce. O desempenho nessa solução foi testado quanto à escalabilidade e o tempo de resposta. Em consultas com múltiplos usuários em um banco de dados distribuídos em um cluster (escalabilidade horizontal), o tempo de resposta obteve melhores desempenhos, quando comparados em um ambiente em que se aumenta a capacidade de processamento de servidores (escalabilidade vertical). Em FREIRE et al. [21], o Couchbase, com armazenamento JSON e de acordo com as especificações openEHR, foi experimentado para consultas de base populacionais e apresentou resultados melhores em relação a um banco de dados relacional, o MySQL e aos bancos de dados XML. Os resultados mostram que os bancos de dados XML avaliados possuem desempenho limitado para essas consultas, mesmo com alterações nos índices e otimização das consultas. Um outro resultado foi quanto à análise de um cluster de bancos de dados Couchbase. Tamanhos maiores do cluster podem melhorar o desempenho na recuperação para maiores conjuntos de dados. 69 CAPÍTULO V 5. Discussão Os resultados desta pesquisa mostraram que a utilização da abordagem “Dual Model” no desenvolvimento de sistemas de registro eletrônico de saúde tem sido um tema de pesquisa recorrente. Não há ainda um consenso sobre as melhores práticas para a implementação de um S-RES baseado na modelagem multinível. Entretanto esta revisão levanta uma série de questões que merecem ser discutidas. 5.1 Metodologia de busca Na metodologia de busca dos estudos, apesar de serem utilizadas poucas palavras-chaves e termos de busca, acreditamos que as buscas complementares (lista de referências dos artigos encontrados, repositório da Fundação openEHR no Zotero e consulta aos resultados de um outro estudo de revisão) permitiu uma cobertura abrangente dos trabalhos publicados sobre a implementação de S-RES baseados na modelagem multinível, utilizando as especificações openEHR ou ISO-13606. O período compreendido entre 2002 e 2008 foi um período de amadurecimento das especificações openEHR e o padrão ISO 13606. Em 2008, a Fundação openEHR lançou uma versão estável de suas especificações e a ISO publicou a especificação do modelo de referência da ISO 13606. Assim o período de busca utilizado nesta revisão (de 2007 a 2016) foi adequado para identificar implementações com base em especificações estáveis. De fato, o que se observou é um número crescente de publicações relativas à implementação de S-RES que utilizam as especificações openEHR e ISO 13606, especialmente a partir de 2012. 5.2 Estágio das implementações openEHR Embora o número de publicações tenha crescido nos últimos anos, o número de artigos identificados nesta revisão foi relativamente pequeno, com poucas implementações, em geral protótipos, e poucas avaliações de mecanismos de persistência. Empresas que implementaram as especificações openEHR e afirmam ter sistemas em produção, como a Ocean Informatics e Marand, não publicaram artigos em revistas científicas sobre seus produtos. Tivemos um baixíssimo retorno (apenas Marand 70 forneceu dados sobre o seu sistema) dos e-mails enviados para empresas identificadas no sítio da Fundação openEHR. Porém, o trabalho de FRADE et al.(2013), utilizado nessa revisão, de certa forma, compensa esta situação. O trabalho obteve 16 respostas de 21 emails enviados. A maioria das implementações identificadas naquele estudo também não estavam em produção. As mudanças propiciadas por estas especificações têm o potencial de incrementar ainda mais a evolução da TI no setor da saúde. O seu impacto está sendo sentido no rápido desenvolvimento e na atualização de novos RES. Tradicionalmente, os S-RES têm sido desenvolvidos por meio da abordagem de um único nível. Com constantes modificações necessárias, é preciso alterar o código-fonte e a base de dados do RES, significando mais tempo e trabalho. A adoção do modelo de referência e arquétipos parece refletir positivamente na evolução e manutenção do S-RES [07]. A acomodação de novos conceitos, sem a necessidade de alterações, resulta na redução de custos de TI. Entretanto, mais estudos são necessários para avaliar o impacto da modelagem multinível sobre a manutenção evolutiva de S-RES. 5.3 Arquiteturas dos Sistemas As linguagens de programação orientadas a objetos mais populares (Java especialmente, C++, Python e C#), ambientes integrados de desenvolvimento e padrões de projeto têm sido utilizados no desenvolvimento dos S-RES baseados na modelagem multinível. Estes recursos têm contribuído para um tempo menor de desenvolvimento e reutilização de componentes. Diversas arquiteturas têm sido utilizadas para a implementação dos sistemas revisados neste trabalho. O modelo cliente/servidor, frequentemente utilizando o padrão de projeto MVC (Model-View-Controller), é bastante adotado nas implementações. A arquitetura orientada a serviços (SOA), por meio de web services (WS) também são bastante frequentes. Os WS mais populares são SOAP e RESTful. Os estudos apresentam propostas semelhantes, utilizando web services para autenticação de usuários e consulta de dados clínicos em um repositório. Como exemplo, a abordagem REST é utilizada na interface de administração do usuário, por meio de uma API, em GUTIÉRREZ [13], como servidor de extratos OpenEHR em MARCO-RUIZ et al. [17], ou 71 ainda em VELTE et al. [14], que utiliza REST no armazenamento e consulta de registros em um banco de dados XML. Porém há arquiteturas que utilizam tanto REST como SOAP, como em VELTE et al. [14]. No paradigma da computação em nuvem, as tecnologias oferecidas são utilizadas em grande escala associadas a um conceito de Big Data, em que o foco é a capacidade de lidar com o grande armazenamento de dados em volume e variedade. Os usuários podem solicitar os serviços de computação em nuvem, de acordo com três modelos: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) e Software as a Service (Saas). Cada um deles difere do nível de funcionalidade fornecida pelo provedor de nuvem ao usuário. Em BAHGA e MADISETTI [01] a arquitetura utiliza Saas, em que os médicos podem fazer uploads de relatórios de diagnóstico para a nuvem de forma que podem ser acessados remotamente por outros médicos para diagnosticarem uma doença. Em GUTIÉRREZ [13], o sistema também utiliza SaaS, em que a plataforma fornece alta disponibilidade de dados, redundância e backup de metadados, ou seja, requisitos básicos para qualquer RES compartilhado. 5.4 Persistência de Dados Uma questão central em todo o sistema de informação é o desempenho do seu mecanismo de persistência. Diversos enfoques têm sido experimentados no desenvolvimento de S-RES baseados na modelagem multinível, sendo que esses mecanismos podem ser utilizados nas diversas arquiteturas discutidas no item anterior. Uma solução de persistência deve atender a diversos casos de uso: inserção e atualização de registros, consultas individuais e consultas de base populacional. As consultas individuais são utilizadas principalmente no atendimento de um paciente, onde os dados do paciente devem ser apresentados ao profissional de saúde para que o mesmo realize o atendimento. Os tempos de resposta nesta situação devem ser baixos, no máximo alguns poucos segundos. As propriedades ACID são frequentemente exigidas para este tipo de consulta. As consultas de base populacional são aquelas que buscam retornar dados agregados ou um conjunto de pacientes que atendem a certos critérios especificados. Neste caso, há uma maior tolerância em relação aos tempos de resposta e as 72 propriedades ACID não são requisitos prioritários, sendo suficientes que as propriedades BASE sejam satisfeitas. Uma técnica de persistência utilizada frequentemente pelos desenvolvedores OO é o mapeamento objeto-relacional, por meio de frameworks como o Hibernate. Poucas implementações de sistemas multiníveis utilizaram este recurso [6, 13]. Entretanto MUNOZ et al.[06] afirmam que seu desempenho não foi satisfatório, apesar de não apresentar dados que suporte esta conclusão. Os bancos de dados relacionais, MySQL e PostgreSQL, são frequentemente utilizados como repositórios de dados nos sistemas identificados nesta revisão, mas, na maioria dos casos, eles não são utilizados da forma tradicional, via mapeamento objetorelacional. Possivelmente, umas das primeiras propostas de armazenamento de dados para sistemas openEHR foi a apresentada por BEALE(2008), a qual utiliza nós indexados por caminhos (Node + Path), onde os objetos são serializados em blobs ou strings em bancos relacionais ou objeto-relacionais e seus caminhos são armazenados em uma tabela e compõem um índice para os nós. WANG et al. [15] propuseram um mapeamento de arquétipos para o modelo relacional. Esta proposta apresentou melhor desempenho do que a proposta Node + Path, tanto em consultas individuais quanto populacionais. O armazenamento de dados no formato XML, seja em bancos de dados XML nativos, seja em bancos de dados relacionais com suporte a XML, como o PostgreSQL, não apresentou bom desempenho, especialmente para consultas de base populacional [18, 21]. Além dos bancos de dados XML, outros bancos de dados NoSQL, como o MongoDB e Couchbase, com suporte a MapReduce, foram experimentados como repositórios de S-RES baseados em arquétipos, apresentando bons desempenhos para consultas individuais e populacionais. Por sua natureza distribuída, estes repositórios são escaláveis horizontalmente. Por outro lado, por enfatizarem as propriedades BASE, eles podem não satisfazer as propriedades ACID, quanto elas forem requisitos obrigatórios. Esta é uma questão que merece ser melhor estudada. 73 Alguns sistemas comerciais estão em produção, mas poucas informações estão disponíveis sobre estes sistemas. A empresa Marand (software Think!EHR), por exemplo, em seus folhetos de divulgação, afirma que seu sistema apresenta desempenho satisfatório, mas não apresenta detalhes de suas avaliações. O trabalho de MARCO-RUIZ et al. [17], que aborda um datawarehouse baseado no openEHR, utiliza o Think!EHR e, no entanto, o desempenho, a julgar pelos dados publicados, não poderia ser considerado muito satisfatório. Apesar de não oferecer uma receita de como implementar um sistema de registro eletrônico de saúde baseado em arquétipos, este trabalho apresentou as arquiteturas e os mecanismos de persistência utilizados propostas até então publicadas. Algumas linhas gerais foram apresentadas, as quais podem ser utilizadas para orientar novas pesquisas e/ou novas propostas de desenvolvimento de sistemas baseados na modelagem multinível. 74 CAPÍTULO VI 6. Conclusão Embora não seja possível estabelecer um conjunto de práticas consensuais sobre a melhor forma de implementar um S-RES baseados na modelagem multinível, algumas conclusões podem ser extraídas deste estudo de revisão. O período da busca realizada nesta revisão corresponde ao período onde a modelagem multinível por meio das especificações openEHR e ISO 13606 vem sendo utilizada para o desenvolvimento de S-RES, particularmente a partir de 2012. Em geral, as implementações publicadas estão em estágio inicial. As empresas que afirmam ter implementações em produção não têm publicado artigos sobre seus produtos em revistas científicas. Os sistemas têm sido implementados por meio de linguagens OO e nas mais diversas arquiteturas: cliente-servidor, SOA e em nuvem. Em relação aos mecanismos de persistência, das propostas avaliadas até o momento, as que tiveram melhor desempenho foram o mapeamento arquétipo-relacional e os bancos de dados NoSQL que implementam o paradigma MapReduce. 75 Referências ABITEBOUL, S.; HULL, R.; VIANU, V. Foundations of databases: the logical level. [S.l.]: AddisonWesley Longman Publishing Co., Inc., 1995. AGARWAL, S.; LAU, C. T. Remote health monitoring using mobile phones and Web services. Telemedicine and e-Health, 2010. v. 16, n. 5, p. 603–607. ALMEIDA, M. B. Revisiting Ontologies: a necessary clarification. Journal of the American Society for Information Science and Technology, 2013. v. 64, n. 8, p. 1682–1693. AMATO, F. et al. CloSe: A Cloud SaaS for Semantic Document Composition. [S.l.]: IEEE, 2012. p. 781–786. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6245775>. Acesso em: 20 jul. 2016. AMAZON, E. Amazon web services. Available in: http://aws. amazon. com/es/ec2/(November 2012), 2015. BACELAR, G.; CORREIA, R. As bases do openEHR. 2015. n. SEPTEMBER 2015, p. 42. BAHGA, A.; MADISETTI, V. K. A Cloud-based Approach for Interoperable Electronic Health Records (EHRs). IEEE Journal of Biomedical and Health Informatics, set. 2013. v. 17, n. 5, p. 894–906. BARCA, C. C. et al. yourEHRM: Standard-based management of your personal healthcare information. [S.l.]: IEEE, 2014. p. 89–92. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6864311>. Acesso em: 20 jul. 2016. BAUER, C. Hibernate em ação. [S.l.]: Ciência Moderna, 2005. BEALE. Node+Path Persistence. [S.l.], 2008. Disponível em: <https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=6553626>. Acesso em: 9 set. 2016. BEALE, T. Archetypes: Constraint-based domain models for future-proof information systems. [S.l.]: [s.n.], 2002. V. 105. BEALE, T. et al. OpenEHR architecture overview. The OpenEHR Foundation, 2006. BEALE, T. et al.The openEHR reference model—EHR information model—Release 1.0. 2. [S.l.]: [s.n.], 2008. BIRD, L.; GOODCHILD, A.; TUN, Z. Z. Experiences with a two-level modelling approach to electronic health records. Journal of Research and Practice in Information Technology, 2003. v. 35, n. 2, p. 121–138. BLOBEL, B.; OTHERS. Standardized and flexible health data management with an archetype driven EHR system (EHRflex). [S.l.]: IOS Press, 2010. V. 155, p. 212. BRASIL. Ministério do Planejamento, Orçamento e Gestão. Guia de Interoperabilidade: Cartilha Técnica. [S.l.], 2015. Disponível em: <http://www.governoeletronico.gov.br/documentos-earquivos/Guia_de_Interoperabilidade_Cartilha_Tecnica_2015.pdf>. Acesso em: 9 set. 2016. 76 CHEN, D.; DOUMEINGTS, G. European initiatives to develop interoperability of enterprise applications—basic concepts, framework and roadmap. Annual Reviews in Control, 2003. v. 27, n. 2, p. 153–162. CHEN, D.; VERNADAT, F. Standards on enterprise integration and engineering—state of the art. International Journal of Computer Integrated Manufacturing, 2004. v. 17, n. 3, p. 235–253. DE DIANA, M.; GEROSA, M. A. Nosql na web 2.0: Um estudo comparativo de bancos nãorelacionais para armazenamento de dados na web 2.0. 2010. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/wtdbd/2010/sbbd_wtd_12.pdf>. Acesso em: 21 jul. 2016. DIAS; COOK; FREIRE, S. M. Modeling healthcare authorization and claim submissions using the openEHR dual-model approach. BMC medical informatics and decision making, 2011. v. 11, n. 1, p. 1. DUARTE, C. M. R. Reflexos das políticas de saúde sobre as tendências da mortalidade infantil no Brasil: revisão da literatura sobre a última década Health policy effects on infant mortality trends in Brazil: a literature review from the last decade. Cad. Saúde Pública, 2007. v. 23, n. 7, p. 1511– 1528. EGGER, M.; SMITH, G. D. Principles of and procedures for systematic reviews. Systematic Reviews in Health Care: Meta-Analysis in Context, Second Edition, 2001. p. 23–42. E-PING_V2016. e-PING_v2016_26022016 - e-PING_v2016_26022016.pdf. [S.l.], 2016. Disponível em: <http://www.governoeletronico.gov.br/documentos-e-arquivos/e-PING_v2016_26022016.pdf>. Acesso em: 9 set. 2016. ERCAN, M. Z.; LANE, M. An evaluation of NoSQL databases for EHR systems. [S.l.]: Auckland University of Technology, School of Business Information Systems, 2014. Disponível em: <http://eprints.usq.edu.au/26225>. Acesso em: 21 jul. 2016. FRADE, S. et al. Survey of openEHR storage implementations. [S.l.]: IEEE, 2013. p. 303–307. FREIRE, S. M. et al. Performance of XML Databases for Epidemiological Queries in ArchetypeBased EHRs. [S.l.]: Linköping University Electronic Press, 2012. p. 51–57. Disponível em: <http://www.ep.liu.se/ecp/article.asp?issue=070&volume=&article=009>. Acesso em: 20 jul. 2016. ______. Comparing the Performance of NoSQL Approaches for Managing Archetype-Based Electronic Health Record Data. PLOS ONE, 9 mar. 2016. v. 11, n. 3, p. e0150069. FREIRE; COPETTI, A.; LOQUES, O. Utilizando o modelo dual para a representação e persistência de contexto em aplicações ubíquas de telemonitoramento. [S.l.]: [s.n.], 2008. p. 15–18. GARETS, D.; DAVIS, M. Electronic medical records vs. electronic health records: yes, there is a difference. Policy white paper. Chicago, HIMSS Analytics, 2006. p. 1–14. GØEG, K. R.; CORNET, R.; ANDERSEN, S. K. Clustering clinical models from local electronic health records based on semantic similarity. Journal of Biomedical Informatics, abr. 2015. v. 54, p. 294– 304. GUTIÉRREZ, P. P. Towards the Implementation of an openEHR-based Open Source EHR Platform (a vision paper). [S.l.]: IOS Press, 2015. V. 216, p. 45. HAERDER, T.; REUTER, A. Principles of transaction-oriented database recovery. ACM Computing Surveys (CSUR), 1983. v. 15, n. 4, p. 287–317. 77 HAN, J. et al. Survey on NoSQL database. [S.l.]: IEEE, 2011. p. 363–366. HIQA. National Standard for Patient Discharge Summary Information Safer Better Care. 2013. n. July, p. 42. IDA. INTERCHANGE OF DATA BETWEEN ADMINISTRATIONS. IDA. European Interoperability Framework: for Pan-European Egovernment Services. [S.l.], 2004. Disponível em: <http://xml.coverpages.org/IDA-EIF-Final10.pdf>. Acesso em: 9 set. 2016. ISO 13606. The CEN/ISO EN13606 standard. [S.l.]: [s.n.], 2015. ISO 13606-1:2008 - Health informatics -- Electronic health record communication -- Part 1: Reference model. ISO, [S.l.], [s.d.]. Disponível em: <http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=40784>. Acesso em: 27 ago. 2016. ISO 13606-2:2008 - Health informatics -- Electronic health record communication -- Part 2: Archetype interchange specification. ISO, [S.l.], [s.d.]. Disponível em: <http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=50119>. Acesso em: 27 ago. 2016. ISO 18308. ISO 18308:2011 - Health informatics -- Requirements for an electronic health record architecture. ISO, [S.l.], 2011. Disponível em: <http://www.iso.org/iso/catalogue_detail?csnumber=52823>. Acesso em: 9 set. 2016. ISO 19439:2006 - Enterprise integration -- Framework for enterprise modelling. ISO, [S.l.], [s.d.]. Disponível em: <http://www.iso.org/iso/catalogue_detail.htm?csnumber=33833>. Acesso em: 26 jul. 2016. ISO/TR 20514:2005 - Health informatics -- Electronic health record -- Definition, scope and context. ISO, [S.l.], 2005. Disponível em: <http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39525>. Acesso em: 9 set. 2016. JÚNIOR, H. F. De A. Mapeando Objetos para Bancos de Dados Relacionais: técnicas e implementações. Semestre de, 2006. KALRA, D. Clinical foundations and information architecture for the implementation of a federated health record service. [S.l.]: University of London, 2003. ______. Electronic health record standards. 2006. KALRA, D.; BEALE, T.; HEARD, S. The openEHR foundation. Studies in health technology and informatics, 2005. v. 115, p. 153–173. KIRKPATRICK, B. et al. Literature review of Florida red tide: implications for human health effects. Harmful algae, 2004. v. 3, n. 2, p. 99–115. KUHN, K.; OTHERS. A generic, web-based clinical information system architecture using HL7 CDA: successful implementation in dermatological routine care. [S.l.]: IOS Press, 2007. p. 439. KURPANIK, J.; PAŃKOWSKA, M. NOSQL problem literature review. Studia Ekonomiczne, 2015. v. 234, p. 80–100. 78 LEE, K. K.-Y.; TANG, W.-C.; CHOI, K.-S. Alternatives to relational database: comparison of NoSQL and XML approaches for clinical data storage. Computer methods and programs in biomedicine, 2013. v. 110, n. 1, p. 99–109. LIANAS, L. et al. pyEHR: A scalable clinical data management toolkit for biomedical research projects. [S.l.]: IEEE, 2014. p. 370–374. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=7001871>. Acesso em: 20 jul. 2016. LÓPEZ-NORES, M. et al. The iCabiNET system: Harnessing Electronic Health Record standards from domestic and mobile devices to support better medication adherence. Computer Standards & Interfaces, jan. 2012. v. 34, n. 1, p. 109–116. MA, C. et al. EHR query language (EQL)-a query language for archetype-based health records. Medinfo, 2007. v. 129, p. 397–401. MADAAN, A. et al. Quasi-Relational Query Language Interface for Persistent Standardized EHRs: Using NoSQL Databases. [S.l.]: Springer, 2013. p. 182–196. Disponível em: <http://link.springer.com/chapter/10.1007/978-3-642-37134-9_15>. Acesso em: 20 jul. 2016. MALDONADO et al. Framework for clinical data standardization based on archetypes. Studies in health technology and informatics, 2007. v. 129, n. 1, p. 454. MALDONADO; LOPEZ, D.; BLOBEL, B. A development framework for semantically interoperable health information systems. International Journal of Medical Informatics, fev. 2009. v. 78, n. 2, p. 83–103. MARCO-RUIZ, L. et al. Archetype-based data warehouse environment to enable the reuse of electronic health record data. International Journal of Medical Informatics, set. 2015. v. 84, n. 9, p. 702–714. MARCOS, M. et al. An archetype-based solution for the interoperability of computerised guidelines and electronic health records. [S.l.]: Springer, 2011. p. 276–285. MARTÍNEZ, I. et al. Implementation of an end-to-end standard-based patient monitoring solution. IET Communications, 2008. v. 2, n. 2, p. 181. MARTÍNEZ-COSTA, C. et al. A model-driven approach for representing clinical archetypes for Semantic Web environments. Journal of Biomedical Informatics, fev. 2009. v. 42, n. 1, p. 150– 164. MARUT, B. The Foundation for Semantic Interoperability on the World Wide Web. [S.l.]: Submitted in partial fulfillment of the requirement for the degree of Doctor of Philosophy, Department of Information Science and Telecommunications, School of Information Sciences, University of Pittsburgh, 2001. MCDONALD, C. J.; TANG, P. C.; HRIPCSAK, G. Electronic Health Record Systems. Biomedical Informatics. [S.l.]: Springer, 2014, p. 391–421. MELLO, R. Dos S. et al. Dados semi-estruturados. XV Simpósio Brasileiro de Banco de Dados, 2000. MILLER, P. Interoperability: What is it and why should I want it? Ariadne, 2000. n. 24. 79 MUNOZ, A. et al. Proof-of-concept Design and Development of an EN13606-based Electronic Health Care Record Service. Journal of the American Medical Informatics Association, 1 jan. 2007. v. 14, n. 1, p. 118–129. MURTA, L. G. P.; VERONESE, G. O.; WERNER, C. M. L. MOR: Uma Ferramenta para o Mapeamento Objeto-Relacional em Java. Simpósio Brasileiro de Engenharia de Software (SBES), Sessão de Ferramentas, 2001. p. 392–397. NARDON, F. B. Utilizando XML para a representação de informação em saúde. São Paulo, 2000. NASCIMENTO, N. D. L. D. PERSISTÊNCIA EM BANCO DE DADOS: UM ESTUDO PRÁTICO SOBRE AS API JPA E JDO. 2005. OUKSEL, A. M.; SHETH, A. Semantic interoperability in global information systems. ACM Sigmod Record, 1999. v. 28, n. 1, p. 5–12. PANETTO, H.; MOLINA, A. Enterprise integration and interoperability in manufacturing systems: Trends and issues. Computers in industry, 2008. v. 59, n. 7, p. 641–646. PIHO, G. et al. Towards archetypes-based software development. Innovations in Computing Sciences and Software Engineering. [S.l.]: Springer, 2010, p. 561–566. PÖHLSEN, S. et al. A concept for a medical device plug-and-play architecture based on web services. ACM SIGBED Review, 2009. v. 6, n. 2, p. 6. POKRAEV, S. V. Model-driven semantic integration of service-oriented applications. 2009. RIDLEY, D. The literature review: A step-by-step guide for students. [S.l.]: Sage, 2012. ROCHA, A. D.; KUBOTA, S. O. Persistência no Java EE 5. Java Magazine, [s.d.]. n. 39, p. 29–37. RODRIGUES, J. et al.Conceptual Framework for eHealth Interoperability, Deliverable 1.1 of the SemanticHEALTH Project. August 2006. [S.l: s.n., s.d.]. SACHDEVA, S. et al. AQBE &mdash; QBE Style Queries for Archetyped Data. IEICE Transactions on Information and Systems, 2012. v. E95.D, n. 3, p. 861–871. SACHDEVA, S.; BHALLA, S. Implementing high-level query language interfaces for archetypebased electronic health records database. [S.l.]: [s.n.], 2009. p. 235–238. ______. Semantic Interoperability in Healthcare Information for EHR Databases. 2010. SALAMANCA, A. et al. A flexible OLAP query model for a telemedicine system. [S.l.]: ACM, 2008. p. 9. SANTOS, M. R. Dos. Sistema de registro eletrônico de saúde baseado na norma ISO 13606: aplicações na Secretaria de Estado de Saúde de Minas Gerais. Perspectivas em Ciência da Informação, 2011. v. 16, n. 3, p. 272–272. SHENG, Q. Z. et al.Web services composition: A decade’s overview. Information Sciences, out. 2014. v. 280, p. 218–238. SILVA, J. E. H. AUTOCONHECIMENTO E A TEORIA DOS ARQUÉTIPOS NAS HABILIDADES DE COMUNICACÃO DE JORNALISTAS. XI Simpósio de Ciências da Comunicação na Região Sudeste, 2006. 80 STAN, O.; SAUCIUC, D.; MICLEA, L. Medical informatics system for Romanian healthcare system. [S.l.]: [s.n.], 2011. STONEBRAKER, M. et al. The end of an architectural era:(it’s time for a complete rewrite). [S.l.]: VLDB Endowment, 2007. p. 1150–1160. STONEBRAKER, M.; CATTELL, R. 10 Rules for Scalable Performance in “Simple Operation” Datastores. Commun. ACM, jun. 2011. v. 54, n. 6, p. 72–80. TOTH, R. M. Abordagem NoSQL–uma real alternativa. [S.l.]: Sao Paulo, 2011. VELTE, LINDA; PEDROSA, TIAGO; COSTA, CARLOS. AN OPENEHR REPOSITORY BASED ON A NATIVE XML DATABASE: [S.l.]: SciTePress - Science and and Technology Publications, 2012. p. 386–389. Disponível em: <http://www.scitepress.org/DigitalLibrary/Link.aspx?doi=10.5220/0003784003860389>. Acesso em: 21 jul. 2016. VERNADAT, F. Enterprise modeling and integration. [S.l.]: Boom Koninklijke Uitgevers, 1996. VIEIRA-MARQUES, P. et al.OpenEHR aware multi agent system for inter-institutional health data integration. [S.l.]: IEEE, 2014. p. 1–6. Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6876864>. Acesso em: 20 jul. 2016. WANG, L. et al. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making, dez. 2015. v. 15, n. 1. Disponível em: <http://www.biomedcentral.com/1472-6947/15/88>. Acesso em: 20 jul. 2016. Welcome to ApacheTM Hadoop®! [S.l.], [s.d.]. Disponível em: <http://webcache.googleusercontent.com/search?q=cache:ZTXkQkt47_QJ:hadoop.apache.org/+& cd=4&hl=pt-BR&ct=clnk&gl=br>. Acesso em: 21 jul. 2016. Estudos Incluídos na Revisão [01] A. Bahga and V. K. Madisetti, “A Cloud-based Approach for Interoperable Electronic Health Records (EHRs),” IEEE Journal of Biomedical and Health Informatics, vol. 17, no. 5, pp. 894–906, Sep. 2013. [02] L. Lianas, F. Frexia, G. Delussu, P. Anedda, and G. Zanetti, “pyEHR: A scalable clinical data management toolkit for biomedical research projects,” 2014, pp. 370–374. [03] C. C. Barca, C. M. Lagunar, J. M. Rodríguez, A. M. Quintero, I. R. M. Martins, I. Martínez, M. A. Sanguino, and T. P. Lobo, “yourEHRM: Standard-based management of your personal healthcare information,” in IEEE-EMBS International Conference on Biomedical and Health Informatics (BHI), 2014, pp. 89–92. [04] P. Vieira-Marques, J. Patriarca-Almeida, S. Frade, G. Bacelar-Silva, S. Robles, and R. Cruz-Correia, “OpenEHR aware multi agent system for inter-institutional health data integration,” in 2014 9th Iberian Conference on Information Systems and Technologies (CISTI), 2014, pp. 1–6. [05] O. Stan, D. Sauciuc, and L. Miclea, “Medical informatics system for Romanian healthcare system,” in 2011 E-Health and Bioengineering Conference (EHB), 2011. 81 [06] A. Munoz, R. Somolinos, M. Pascual, J. A. Fragua, M. A. Gonzalez, J. L. Monteagudo, and C. H. Salvador, “Proof-of-concept Design and Development of an EN13606-based Electronic Health Care Record Service,” Journal of the American Medical Informatics Association, vol. 14, no. 1, pp. 118–129, Jan. 2007. [07] K. Atalag, H. Y. Yang, E. Tempero, and J. R. Warren, “Evaluation of software maintainability with openEHR – a comparison of architectures,” International Journal of Medical Informatics, vol. 83, no. 11, pp. 849–859, Nov. 2014. [08] M. López-Nores, Y. Blanco-Fernández, J. J. Pazos-Arias, and J. García-Duque, “The iCabiNET system: Harnessing Electronic Health Record standards from domestic and mobile devices to support better medication adherence,” Computer Standards & Interfaces, vol. 34, no. 1, pp. 109–116, Jan. 2012. [09] I. Martínez, J. Fernández, M. Galarraga, L. Serrano, P. de Toledo, S. Jiménez-Fernández, S. Led, M. Martínez-Espronceda, and J. García, “Implementation of an end-to-end standard-based patient monitoring solution,” IET Communications, vol. 2, no. 2, p. 181, 2008. [10] E. Sundvall, M. Nyström, D. Karlsson, M. Eneling, R. Chen, and H. akan Örman, “Applying representational state transfer (REST) architecture to archetype-based electronic health record systems,” BMC medical informatics and decision making, vol. 13, no. 1, p. 1, 2013. [11] B. Blobel and others, “Standardized and flexible health data management with an archetype driven EHR system (EHRflex),” in Seamless Care, Safe Care: The Challenges of Interoperability and Patient Safety in Health Care: Proceedings of the EFMI Special Topic Conference, June 2-4, 2010, Reykjavik, Iceland, 2010, vol. 155, p. 212. [12] D. A. Orellana, A. A. Salas, P. F. Solarz, L. M. Ruiz, and V. I. Rotger, “Evaluation of a Framework to Implement Electronic Health Record Systems Based on the openEHR Standard,” Journal of Physics: Conference Series, vol. 705, p. 12046, Apr. 2016. [13] P. P. Gutiérrez, “Towards the Implementation of an openEHR-based Open Source EHR Platform (a vision paper),” in MEDINFO 2015: EHealth-enabled Health: Proceedings of the 15th World Congress on Health and Biomedical Informatics, 2015, vol. 216, p. 45. [14] Velte, Linda, Pedrosa, Tiago, and Costa, Carlos, “AN OPENEHR REPOSITORY BASED ON A NATIVE XML DATABASE:,” 2012, pp. 386–389. [15] L. Wang, L. Min, R. Wang, X. Lu, and H. Duan, “Archetype relational mapping - a practical openEHR persistence solution,” BMC Medical Informatics and Decision Making, vol. 15, no. 1, Dec. 2015. [16] A. Madaan, W. Chu, Y. Daigo, and S. Bhalla, “Quasi-Relational Query Language Interface for Persistent Standardized EHRs: Using NoSQL Databases,” in International Workshop on Databases in Networked Information Systems, 2013, pp. 182–196. [17] L. Marco-Ruiz, D. Moner, J. A. Maldonado, N. Kolstrup, and J. G. Bellika, “Archetype-based data warehouse environment to enable the reuse of electronic health record data,” International Journal of Medical Informatics, vol. 84, no. 9, pp. 702–714, Sep. 2015. [18] S. M. Freire, E. Sundvall, D. Karlsson, and P. Lambrix, “Performance of XML Databases for Epidemiological Queries in Archetype-Based EHRs,” in Scandinavian Conference on Health Informatics 2012; October 2-3; Linköping; Sverige, 2012, pp. 51–57. 82 [19] T. Austin, Y. Lim, D. Nguyen, and D. Kalra, “Design of an electronic healthcare record server based on part 1 of ISO EN 13606,” Journal of Healthcare Engineering, vol. 2, no. 2, pp. 143–160, 2011. [20] T. Austin, S. Sun, Y. S. Lim, D. Nguyen, N. Lea, A. Tapuria, and D. Kalra, “An electronic healthcare record server implemented in PostgreSQL,” Journal of healthcare engineering, vol. 6, no. 3, pp. 325–344, 2015. [21] S. M. Freire, D. Teodoro, F. Wei-Kleiner, E. Sundvall, D. Karlsson, and P. Lambrix, “Comparing the Performance of NoSQL Approaches for Managing Archetype-Based Electronic Health Record Data,” PLOS ONE, vol. 11, no. 3, p. e0150069, Mar. 2016. 83 APÊNDICE A – CORPO DE ENVIADO A EMPRESAS/ INSTITUIÇOES Dear Software Developer, My name is Elvis Nascimento da Silva, and I am a researcher at the Graduate Program in Computational Modeling Systems at Federal University of Tocantins UFT, located in the Amazon region, in Brazil. I am conducting a research for my Master's thesis which aims to identify the architectures, models and mechanisms of persistence in the Electronic Registration Health Care Systems based on openEHR or ISO 13606. We identified through the literature that your company has been working with openEHR or ISO13606 specification for the following product: • Product name We appreciate if you could please provide us with more information about your product, such as the following questions/information: 1. What is the Project / Product Name? 2. What is the Year of Development? 3. Which Programming Languages are used? 4. The storage / data processing is performed in a Centralized or Distributed way? Or both? 5. Is there a Web Server? Which one? 6. Which database is it used? 7. Do you use a framework for software development? If yes, which one? 8. Does it use a Cloud Environment? 9. Which is the Web Services Technology (REST, SOAP?) used? Or another (RMI, CORBA, etc.)? 10. What are the security mechanisms used?; 11. What is the Reference Model used? 12. What standards are used? 13. Is there a License to use? Which one? 14. What is the Size of the Database (GB)? 15. Which Query Language (SQL, SQL, Query, SQL + XPath) is used? 16. What is the number of Patient Records? 17.Is the demographic information storage use a demographic reference model? 18. What is the Persistence Solution ? 19. Is there a performance evaluation? Which one?; 20. Is there a Mobile Platform? 21. Any other important information? 22. Is there any academic publications? Responsible for this information: We thank you for taking the time to send us this information. Kind regards, Elvis Nascimento da Silva Graduate Program in Computational Modeling Systems at Federal University of Tocantins UFT, Brazil. skype: [email protected] phone number: +556381231907
