Construção de Aplicações em Saúde Baseadas em Arquétipos

Transcrição

1 Construção de Aplicações em Saúde Baseadas em Arquétipos Fabiane Bizinella Nardon 1, Tony França 1, Humberto Naves 1 1 Zilics Sistemas de Informação em Saúde, Brasil Resumo Este artigo apresenta uma discussão sobre a construção de aplicações na área da saúde baseadas na especificação de arquétipos, proposta pela Fundação OpenEHR. São apresentadas estratégias, soluções e dificuldades na adoção deste padrão, apresentando resultados coletados a partir de uma experiência concreta. Palavras-chave: Arquétipos, Sistemas de Informação em Saúde, Padrões em Informática em Saúde. Abstract This paper discusses the process of building health information systems based on the archetypes specification proposed by the OpenEHR Foundation. Strategies, solutions and difficulties when adopting this standard will be presented. The results of this experience were collected from a real world application. Key-words: Archetypes, Health Information Systems, Standards on Health Informatics. Introdução Arquétipos [1] são pedaços de conhecimento que indicam como representar conceitos ou informação. Um arquétipo que representa o conceito peso corporal, por exemplo, pode definir que este conceito é formado por uma quantidade (um número e uma unidade) e por uma data que indica o momento em que o peso foi medido. Desta forma, a utilização de arquétipos permitiria compartilhar conceitos e conhecimento clínico, formando sistemas a partir da união de diversos deles. Esta é a proposta da fundação OpenEHR [2]: criar um padrão que permita representar formalmente arquétipos, possibilitando assim que as especificações de conceitos clínicos criadas com este formalismo sejam compartilhadas e resultem na construção de sistemas de informação em saúde fundamentados em conceitos sólidos e interoperáveis. Embora o padrão proposto pela Fundação OpenEHR tenha recebido muita atenção nos últimos anos, poucas são as experiências de utilização deste padrão na construção de sistemas de informação reais e de larga escala. O objetivo deste trabalho é apresentar o resultado de uma experiência deste tipo, descrevendo as possíveis estratégias para a utilização do padrão de arquétipos, dificuldades comuns, e, principalmente, discutindo a adequação deste padrão para atingir o seu objetivo principal: permitir a criação de sistemas de informação em saúde a partir da reutilização de conhecimento clínico representado de forma portável e independente de plataforma. Arquétipos e a Fundação OpenEHR A Fundação OpenEHR é uma organização sem fins lucrativos cujo objetivo é transformar em realidade prontuários eletrônicos interoperáveis, permitindo assim que informações melhores estejam disponíveis para a área da saúde. Para atingir este objetivo, a fundação propõe uma série de padrões, centrados no conceito de arquétipos. Arquétipos são descritos como um modelo formal e reutilizável de um conceito do domínio. Assim, se um conceito é representado por um arquétipo, este conceito pode ser reutilizado nos vários cenários em que se aplica. Os arquétipos são definidos em uma linguagem computável chamada de ADL (Archetype Definition Language) [3]. Diferentes arquétipos podem ser agrupados em um template. Um template geralmente é usado para definir uma ficha clínica, ou um formulário que será preenchido. Em um template, é possível determinar os arquétipos que serão utilizados, as ocorrências que devem existir de cada arquétipo, elementos que, dentro de um arquétipo, serão utilizados, entre outras definições. A partir de um template, é possível inferir uma interface que permita criar uma aplicação de entrada de dados que colete as informações a partir dos conceitos e definições contidas nos diversos arquétipos. Quando as informações descritas pelos templates e arquétipos são instanciadas, ou seja, quando os dados clínicos reais são informados, através do preenchimento de um formulário, por exemplo, dá-se origem a um documento chamado de composition. São as compositions que

2 efetivamente contém os dados clínicos que formam as diversas fichas clínicas que compõem o prontuário do paciente. O padrão que define como uma composition deve ser representada é baseado em XML. Portanto, é possível exportar informações para o formato de composition, mesmo que a aplicação original que coletou as informações não tenha sido baseada em arquétipos e templates. A compreensão destes três conceitos, arquétipos, templates e compositions, é fundamental para que se inicie o processo de adoção e avaliação deste padrão. Metodologia A perspectiva de reutilização de conhecimento clínico bem especificado e validado por diversas organizações é a maior motivação para adoção de arquétipos na construção de aplicações. Existe uma grande biblioteca de arquétipos disponível [4], grande parte deles criados pela comunidade européia. Em função disto, a primeira etapa deste trabalho consistiu em validar os arquétipos existentes com especialistas do domínio no Brasil. Esta etapa tinha como objetivo verificar se os arquétipos existentes eram adequados à realidade do pais e verificar que adaptações seriam necessárias. Para isso, foi escolhido como estudo de caso um sistema de informação hospitalar em que as fichas de triagem, atendimento ambulatorial, pronto atendimento e internação seriam construídas a partir de arquétipos. Nesta etapa, foram investigadas ferramentas de edição que permitissem a um especialista no domínio traduzir os arquétipos existentes, já que praticamente não existem arquétipos em português. Estas ferramentas deveriam permitir que o especialista fizesse os ajustes necessários nos arquétipos existentes e também criar novos arquétipos quando necessário. Duas ferramentas disponíveis gratuitamente foram utilizadas nesta fase: Ocean Archetype Editor [5] e Java Archetype Editor [6]. Após a análise e tradução dos arquétipos selecionados, foram identificados e criados novos arquétipos pelos especialistas no domínio. Quando os arquétipos já estavam determinados, iniciou-se a fase de criação dos templates necessários. A criação de templates apresentou algumas dificuldades importantes: a especificação do padrão para representação de templates ainda não está concluída e não existem editores disponíveis gratuitamente para gerar arquivos compatíveis com a versão em andamento da especificação. Por isso, para realizar esta etapa, foi necessário analisar os exemplos de templates disponibilizados pela fundação OpenEHR para derivar dali o esquema que permitiria criar arquivos XML contendo os templates compatíveis com a especificação em andamento. Como não existem editores de templates disponíveis, nesta fase foi necessária a intervenção de uma equipe técnica para que, em conjunto com os especialistas, criassem os arquivos XML representando os templates. Uma vez definidos os arquétipos e templates, a equipe técnica passou a definir a arquitetura que seria utilizada para suportar o uso do padrão na aplicação real. A arquitetura de uma aplicação baseada em arquétipos depende fundamentalmente da estratégia adotada para construir a interface da aplicação. Uma vez que arquétipos e templates modelam conceitos clínicos computacionalmente processáveis, é possível utilizá-los tanto para criar aplicações cuja interface é gerada automaticamente, semi-automaticamente ou não automática. Na estratégia não automática, os arquétipos e templates são usados simplesmente como modelos a serem seguidos, sendo que o desenvolvimento da interface é realizado manualmente, a partir dos conceitos expressos pelos arquétipos, mas sem que a especificação contida nos arquétipos seja interpretada por um processo computacional. Na estratégia semi-automática, são disponibilizados diversos componentes de interface, cada um representando uma das estruturas de dados suportadas pelo padrão de arquétipos, e a interface é criada por um desenvolvedor a partir destes componentes, mas criando a distribuição dos elementos na interface manualmente. Na estratégia totalmente automatizada, um processo computacional interpreta as definições dos arquétipos e templates gerando automaticamente as interfaces. Cada uma das abordagens possui vantagens e desvantagens. Na estratégia totalmente automatizada, ganha-se na flexibilidade da aplicação, uma vez que novos arquétipos podem ser introduzidos e automaticamente passam a fazer parte da aplicação, sem necessidade de desenvolvimento adicional. Por outro lado, interfaces geradas automaticamente tendem a ser mais genéricas e menos flexíveis, pois todas as interfaces resultantes do processamento dos templates são similares, dificultando grandes customizações. Nesta experiência, a estratégia adotada foi a de geração totalmente automática das interfaces, uma vez que se pretendia flexibilizar a introdução de novos arquétipos e templates por parte do especialista. O padrão de arquétipos suporta diversas estruturas de dados complexas e não triviais. Além das estruturas simples, como booleanos, números inteiros, datas, etc, estruturas mais

3 complexas como clusters, que são agrupamentos de múltiplas estruturas de dados, duration, que representam durações de tempo, e sections, que representam seções nas fichas clínicas, também estão disponíveis. Para que cada uma destas estruturas de dados fosse representada adequadamente, resultando em uma interface com boa ergonomia e usabilidade, foi realizado um estudo com especialistas em projeto de interfaces e submetida a diversos especialistas no domínio para determinar a melhor representação para cada estrutura de dados. Durante esta fase do experimento, diversas possibilidades de interface foram testadas e submetidas a testes de usabilidade e ergonomia. A partir deste estudo, verificou-se que algumas estruturas de dados, quando definidas sob a forma de arquétipos, não possuem informação suficiente para que sejam bem representados em uma interface. Por exemplo, elementos do tipo texto não possuem número máximo de caracteres. Assim, tanto informações que tipicamente contém um pequeno número de caracteres quanto informações que geralmente contém diversas páginas de texto seriam representadas na interface da mesma forma. Isto exigiu soluções de interface não convencionais. Para resolver o problema do tamanho dos campos texto, por exemplo, adotou-se uma solução baseada em caixas de texto expansíveis. Estas caixas de texto aumentam de tamanho à medida que o usuário digita o texto. Este tipo de dificuldade tem gerado uma série de discussões na fundação OpenEHR, onde se defende a criação de mecanismos que permitam associar às estruturas de dados dos arquétipos informações úteis para renderização de interfaces gráficas. No entanto, até o momento da conclusão deste trabalho, ainda não havia um padrão estabelecido neste sentido. A maior dificuldade de representação foi encontrada em estruturas complexas com múltiplas repetições, como clusters múltiplos. Estes tipos de estrutura formam hierarquias que não são facilmente representadas em uma interface gráfica, principalmente quando o especialista do domínio cria hierarquias mais profundas, com diversos níveis. Depois de diversos experimentos, concluiu-se que a estrutura que melhor representava os conceitos propostos era uma interface baseada em árvores, onde cada folha representa um elemento atômico e nós da árvore representam elementos com múltiplos filhos, como clusters e sections. A Figura 1 apresenta uma pequena parte de uma interface criada a partir de um template para coleta de dados para um atendimento ambulatorial. Quando construindo uma aplicação baseada em arquétipos, é importante que a arquitetura adotada proponha uma boa solução para o armazenamento e recuperação das informações coletadas através da interface. Estas informações são representados sob a forma de compositions. Uma composition é um documento no formato XML que contém o valor informado para cada elemento de dado previsto nos arquétipos que deram origem a ela. Figura 1 Representação de arquétipos em forma de árvore A estratégia mais comum adotada em sistemas baseados em arquétipos, é armazenar todo o conteúdo da composition como sendo uma coluna de uma tabela em um banco de dados relacional. Isto faz com que o armazenamento seja mais fácil e com que pesquisas que recuperem todo o prontuário do paciente sejam executadas com eficiência, uma vez que o critério de consulta é o identificador do paciente associado à composition e não o conteúdo da compositiion. Esta abordagem traz alguns problemas. O primeiro deles é que pesquisas populacionais que envolvam o conteúdo das compositions são computacionalmente muito caras em grandes bases de dados. Por exemplo, para pesquisar todos os pacientes com peso maior que 60Kg, seria necessário processar e interpretar todas as compositions armazenadas no banco de dados. Outro problema com esta abordagem é que informações que deveriam estar disponíveis para acesso rápido pelo restante da aplicação não são rapidamente obtidas. Por exemplo, em nosso experimento, o sistema de prescrição (que não é baseado em arquétipos) necessitava do peso do paciente, que era coletado via arquétipos e armazenado em uma composition. Por questões de desempenho, era inviável processar todas as compositions existentes para o paciente a cada momento que a prescrição precisasse da informação de peso. Uma estratégia alternativa que pode ser usada ao armazenamento da composition como uma coluna do banco de dados, é a adoção de

4 tabelas verticais. Tabelas verticais são tabelas modeladas de forma que uma coluna contém o identificador da informação e outra coluna contém o valor associado com aquele identificador. Desta forma, em uma coluna pode-se armazenar o identificador de cada um dos elementos contidos na composition e na outra coluna o valor informado para o elemento. Tabelas verticais são historicamente consideradas bastante eficientes para armazenamento de dados esparsos, como é o caso das compositions. Como estas tabelas são facilmente indexáveis, a busca pode se tornar muito rápida. No entanto, mesmo com um número médio de atendimentos, uma abordagem baseada somente em tabelas verticais pode gerar volumes de dados enormes. Um hospital de 200 leitos, por exemplo, produziria em torno de 10 milhões de linhas nesta tabela por ano. Com o tempo, isto traria problemas de desempenho ou um custo computacional muito alto. Considerando que nem todas as informações contidas nas compositions são usadas para pesquisas populacionais ou para acesso por outros sistemas e que a maioria das informações é recuperada apenas quando se deseja ver o prontuário do paciente, optou-se por uma arquitetura híbrida. Nesta arquitetura, as compositions são armazenadas no banco de dados em formato XML, porém, aqueles elementos que se desejam utilizar em pesquisas populacionais são armazenados e indexados em tabelas verticais. Além disso, a arquitetura disponibiliza um serviço de eventos, que permite que outros módulos do sistema se inscrevam em eventos em que estão interessados. Por exemplo, para obter sempre o último peso informado para um paciente, o sistema de prescrição pode se inscrever em um evento, de forma que sempre que um arquétipo contendo o peso for preenchido, este valor é enviado para o sistema de prescrição, que pode então armazená-lo para recuperação rápida posteriormente. Esta arquitetura foi testada em um banco de dados com mais de 2 milhões de compositions, apresentando um bom desempenho. Outro aspecto que deve ser considerado na implementação de um sistema baseado em arquétipos é a necessidade de um serviço de terminologias. A fundação OpenEHR especifica interfaces para um serviço de terminologias que deve ser usado quando pesquisando terminologias externas. São consideradas terminologias externas aquelas que não são definidas dentro do próprio arquétipo e geralmente representam vocabulários controlados, como CID, SNOMED, etc. Existem dois problemas com a forma como as terminologias são tratadas no OpenEHR. O primeiro problema é a forma como uma terminologia é associada com um elemento de um arquétipo. Segundo a especificação, esta associação é feita através de uma URL. Ou seja, se um elemento, por exemplo, diagnóstico deve receber como valores possíveis itens do capítulo A da tabela CID-10, basta que o criador do arquétipo defina uma URL arbitrária que indique isso. Como o formato da URL não é controlado, perde-se em portabilidade semântica, uma vez que quem utilizar o mesmo arquétipo não terá mecanismos para saber o que a URL definia. Outro problema prático com o serviço de terminologias é que as suas interfaces são bastante simples e ineficientes para acesso a grandes terminologias. Por exemplo, não há formas, dentro do padrão, de limitar o numero de elementos retornado em uma consulta ao serviço de terminologias, algo essencial em sistemas reais, onde os resultados são freqüentemente apresentados paginados. A estratégia adotada neste experimento foi implementar uma interface estendida do serviço de terminologias que permitisse um acesso mais racional a grandes terminologias, mas mantendo a compatibilidade com a interface original do padrão. Como tecnologias, neste experimento, adotou-se a linguagem de programação Java, com uma arquitetura baseada no padrão JavaEE, que resultou em uma aplicação web. Esta escolha permitiu reutilizar partes da implementação de referência disponibilizada em Java pela fundação OpenEHR. Resultados A construção de aplicações baseadas em arquétipos permite reutilizar conhecimento especificado por especialistas no domínio, criando sistemas mais robustos e inteligentes. É interessante, no entanto, observar que embora o padrão tenha sido feito para que os especialistas no domínio criem arquétipos, a maturidade das ferramentas existentes não permite que um especialista desenvolva arquétipos sem antes conhecer boa parte dos conceitos existentes no padrão proposto pela fundação OpenEHR. Em nossos experimentos, foi observado que os especialistas só conseguiam produzir arquétipos depois de um treinamento e de aprender diversos conceitos não triviais. As ferramentas usadas para editar os arquétipos não são amigáveis e exigem paciência e dedicação dos especialistas que desejam criar arquétipos. Esta é uma barreira de entrada importante que precisa ser solucionada para que a base de conhecimento baseada em arquétipos cresça consistentemente. A edição de templates é outra barreira importante. Como este padrão não está ainda bem definido e nem existem editores disponíveis gratuitamente, a edição de templates, acaba ficando a cargo da equipe técnica e não dos especialistas no domínio, como seria esperado.

5 As estruturas de dados disponíveis no padrão se mostraram adequadas para representar as informações clínicas utilizadas neste experimento. Durante este experimento, 28 arquétipos já existentes na biblioteca do OpenEHR puderam ser reaproveitados, sendo só traduzidos, e 19 novos arquétipos tiveram que ser criados. Isto indica um bom índice de reaproveitamento de conhecimento, considerando que os arquétipos novos criados buscavam representar informação de domínios para os quais ainda não há bases de conhecimento no OpenEHR, como triagem para emergência. É importante salientar que a produção em larga escala de bases de conhecimento baseadas em arquétipos depende da disponibilização de editores mais amigáveis que escondam a teoria imposta pelo padrão e permitam que especialistas do domínio criem seus arquétipos sem a necessidade de formação específica para isso. A abordagem usada para gerar automaticamente as interfaces a partir das especificações se mostrou adequada pois deu maior flexibilidade para que os especialistas introduzissem novos arquétipos e templates sem a necessidade de desenvolvimento adicional. No entanto, somente as definições previstas no padrão de templates se mostraram insuficientes para criar interfaces atraentes e utilizáveis no mundo real. Particularmente, as seguintes extensões foram introduzidas para permitir interfaces melhores: 1. Em muitos casos, um arquétipo é composto de diversos elementos, mas na prática apenas alguns deles são preenchidos normalmente. Por exemplo, o arquétipo que coleta o peso corporal possui elementos como equipamento usado na pesagem, roupa que o paciente vestia, posição em que estava no momento da pesagem, etc. Estes elementos só são preenchidos em situações muito específicas, mas ao gerar a interface acabam ocupando espaço e tornando o preenchimento da ficha cansativo para o usuário. Para resolver este problema, foi criado o conceito de elementos de preenchimento regular. Elementos de preenchimento regular são aqueles indicados pelo especialista como geralmente preenchidos. Ao gerar a interface, o sistema detecta quais são os elementos de preenchimento regular e os apresenta maximizados na interface, enquanto os demais elementos são apresentados minimizados como um nó fechado da árvore. Se necessário, o usuário pode ainda preencher estes elementos, mas eles tornam a interface mais leve; 2. Em alguns casos, um elemento de um arquétipo é resultado do preenchimento de outros elementos. Por exemplo, a escala de coma de Glasgow é uma pontuação que depende do que foi preenchido em outros elementos. Assim, quando estes elementos são preenchidos, a pontuação deveria ser preenchida automaticamente. Para suportar isso na interface, foi criada uma extensão que permite associar scripts a elementos de tela, permitindo assim maior inteligência na interface; 3. O serviço de terminologias proposto pelo OpenEHR não trata adequadamente grandes terminologias e por isso foram criadas extensões que permitem realizar consultas mais eficientes, conforme discutido na seção anterior. Apesar de existirem implementações de referência de código aberto disponibilizadas pela fundação OpenEHR, elas ainda precisam de adições para facilitar a construção de aplicações baseadas em arquétipos. Como resultado deste trabalho, foram doadas para a fundação OpenEHR uma série de bibliotecas que facilitam a construção destas aplicações. Em particular, foram disponibilizadas como código aberto: um parser que permite interpretar templates e verificar se seu formato está correto, de acordo com a especificação atual; uma biblioteca para transformação de ADL em XML, que é um formato mais adequado para construção de aplicações baseadas em arquétipos. A arquitetura de armazenamento de compositions usando a estratégia híbrida de armazenamento em XML no banco de dados e o uso de tabelas verticais para armazenar elementos sujeitos a consulta populacional se mostrou eficiente e com desempenho adequado. É importante salientar, no entanto, que deve existir um equilíbrio entre funcionalidade e desempenho. Se consultas populacionais não são adequadamente planejadas e apenas os elementos realmente importantes são indexados, pode-se atingir gargalos importantes de desempenho. Neste caso, é mais adequado usar uma base de dados específica para consultas populacionais que seria indexada de forma assíncrona em relação às operações efetivadas na base real. Discussão e Conclusões A adoção em larga escala dos padrões propostos pela fundação OpenEHR depende de maior disponibilidade de ferramentas adequadas e de maior participação da comunidade na consolidação dos padrões propostos. Embora o padrão já tenha um nível de maturidade que permita atingir o objeto pelo qual foi criado, ou seja, permitir o compartilhamento de conhecimento, o seu real potencial só será alcançado quando houver participação efetiva de uma comunidade mais ampla nas especificações criadas. Particularmente, existem ainda poucos grupos no Brasil que desenvolvem pesquisas ou aplicações baseadas neste padrão. É importante que exista mais envolvimento para que as lacunas que ainda existem nas especificações possam ser preenchidas com uma visão mais

6 internacional das necessidades das aplicações clínicas. É também importante salientar que o custo do desenvolvimento de aplicações baseadas em arquétipos ainda é alto, considerando as poucas ferramentas e bibliotecas existentes. Por isso, é importante que mais organizações contribuam com a produção de ferramentas de código fonte aberto para que toda a comunidade se beneficie. Os estudos relativos à melhor forma de representação dos elementos de interface gráfica ainda são incipientes na comunidade internacional. Agregar especialistas em ergonomia e usabilidade a esta discussão é vital para a construção de aplicações sólidas e que representem adequadamente os conceitos que são utilizados. Neste aspecto, este trabalho traz uma contribuição importante, uma vez que o estudo de interface realizado contou com profissionais multi-disciplinares e foi adequado à necessidade de sistemas reais. Agradecimentos Este trabalho é o resultado do esforço de diversos profissionais e os autores gostariam de agradecer o apoio recebido pela equipe de desenvolvimento da Zilics Sistemas de Informação em Saúde e à equipe de especialistas que auxiliou na construção dos arquétipos e templates utilizados neste trabalho. Referências [1] Beale T, Heard S. Archetype Definitions and Principles Disponível em < re/am/archetype_principles.pdf> [3] Beale T, Heard S. Archetype Definition Language Disponível em < re/am/adl2.pdf> [4] OpenEHR Foundation. Archetypes Available from OpenEHR Disponível em: < es/dev/html/index_en.html> [5] Ocean Informatics. Ocean Archetype Editor Disponível em < play/ttl/archetype+editor+releases> [6] Linköping University. Java Archetype Editor Disponível em: < Contato Fabiane Bizinella Nardon Zilics Sistemas de Informação em Saúde Av. Luis C. Berrini Cj. 61-São Paulo, SP, Brasil fabiane.nardon@zilics.com.br Tony França Zilics Vale Av. Shishima Hifumi, 2911, UNIVAP, São José dos Campos, SP, Brasil tony.franca@zilics.com.br Humberto Naves Av. Shishima Hifumi, 2911, UNIVAP, São José dos Campos, SP, Brasil humberto.naves@zilics.com.br [2] OpenEHR Foundation. Web site: <