Fig. 1. Visão Geral do processo de desenvolvimento

Transcrição

1 Usando Arquétipos e Linguagem Específica de Domínio no Desenvolvimento de Aplicações Ubíquas para o Cuidado de Saúde Pervasivo Using Archetypes and Domain Specific Languages on Development of Ubiquitous Applications to Pervasive Healthcare Descritores: Health Level Seven, Registros Eletrônicos de Saúde e Informática Médica Descriptors: Health Level Seven, Electronic Health Records and Medical Informatics 1. Introdução João L. C. de Moraes 1, Anderson L. Menezes 2, Carlos E. Cirilo 3, Wanderley L. de Souza 4, Antonio F. do Prado 5 RESUMO Objetivos: Tornar o Cuidado de Saúde distribuído, em que o paciente desempenhe um papel fundamental no tratamento de suas doenças. Métodos: Nesse sentido, o Cuidado de Saúde Pervasivo visa habilitar esse modelo distribuído por meio do emprego de tecnologias, tais como Health Level Seven (HL7) e arquétipos, a fim de prover a interoperabilidade entre aplicações do domínio de cuidado de saúde. A abordagem proposta usa Linguagem Específica de Domínio (DSL), a qual simplifica a modelagem de mensagens HL7 e permite a criação de uma infraestrutura para a geração dos esquemas das mensagens. Resultados: Foi desenvolvida uma aplicação que foi implantada em dispositivos móveis de pacientes, os quais receberam instruções sobre as funcionalidades. A partir da implantação foi possível coletar dados sobre a usabilidade e facilidade de uso da aplicação. Conclusão: A abordagem proposta é útil por permitir a integração de arquétipos em mensagens HL7, proporcionando agilidade e eficiência na comunicação entre SIHs heterogêneos. ABSTRACT Objective: Making the healthcare distributed, where the patient plays a more active role in the treatment of their diseases. Methods: In this sense, the Pervasive Healthcare aims to enable this distributed model through the use of technologies such as Health Level Seven (HL7) and archetypes in order to provide interoperability between applications in the healthcare domain. The proposed approach uses Domain Specific Language (DSL), which simplifies the modeling HL7 messages and allows the creation of an infrastructure to generate the schemas of the messages. Results: It was developed an application that was deployed on patient s mobile devices, which received instructions about the features. From the deployment was possible to collect data about the usability and ease of use of the application. Conclusion: The approach proposed is useful to allow the integration of archetype into HL7 messages, providing flexibility and efficiency in communication between heterogeneous HISs. Atualmente, grande parte dos países enfrenta muitos problemas relacionados à Healthcare, neste artigo, denominada Cuidado de Saúde, tais como os altos custos e a baixa qualidade dos serviços, os quais surgiram devido ao aumento populacional e à insuficiência de profissionais de saúde. Esse cenário tem se agravado principalmente devido à expansão da população idosa, ao aumento de doenças crônicas e à crescente demanda por novos tratamentos e tecnologias. Por exemplo, nos Estados Unidos, o número de graduações em Medicina era de em 1981 e em 2001 (aumento de 0,5%), enquanto no mesmo período sua população cresceu de 225 milhões para 281 milhões (aumento de 24%) 1. Os modelos centralizados de Cuidado de Saúde, que ainda prevalecem em muitos países, já não conseguem mais lidar com tais problemas, pois estão concentrados em torno de pessoas altamente especializadas, localizadas em grandes hospitais e com foco em casos agudos de tratamento. Como consequência, modelos distribuídos de Cuidado de Saúde têm sido propostos, buscando permitir ao paciente gerenciar a sua própria saúde e assim minimizar a sobrecarga de trabalho dos profissionais de saúde. A Pervasive Healthcare 2, neste artigo denominada Cuidado de Saúde Pervasivo, visa habilitar tais modelos distribuídos de Cuidado de Saúde via o uso de Tecnologias de Informação e Comunicação (TICs), a fim de tornar o Cuidado de Saúde disponível em todo lugar, a qualquer hora e para qualquer pessoa. O objetivo da Computação Ubíqua é permitir aos usuários o acesso à informação de qualquer lugar e a qualquer momento 3. Ambientes de Computação Ubíqua em comunidades, lares e hospitais podem ser extremamente úteis na construção de um modelo de Cuidado de Saúde Pervasivo e, para que esse modelo seja centrado no paciente, é necessário que a troca de informações, entre os responsáveis pelo cuidado de saúde dos pacientes, seja ágil, eficiente e segura. Health Level Seven (HL7) é um padrão internacional para a troca de mensagens entre Sistemas de Informação Hospitalar (SIHs) heterogêneos. Embora o HL7 seja amplamente usado, apresenta limitações quanto à representação de conceitos clínicos. Arquétipos 4 são estruturas que indicam como representar conceitos clínicos de um determinado domínio da saúde, sendo que são especificados por especialistas desse domínio e têm sido empregados na organização de informações semanticamente interoperáveis. Este artigo propõe um processo para o desenvolvimento de aplicações para o cuidado de saúde pervasivo, o qual integra arquétipos a mensagens HL7 v3 usando Linguagens Específicas de Domínio (DSLs) 5. O uso de DSL no cuidado de saúde permite modelar mensagens HL7 com arquétipos e automatizar a geração de código simplificando o desenvolvimento de aplicações de saúde. A sequência deste artigo está estruturada da seguinte forma: a seção 2 introduz os métodos empregados neste trabalho e o processo proposto ilustrando-o com um estudo de caso; a seção 3 avalia a aplicação desenvolvida no estudo de caso e discute e compara trabalhos correlatos ao aqui apresentado; e a seção 4 apresenta conclusões e aponta para trabalhos futuros. 1 Mestre pela Universidade Federal de São Carlos (UFSCar), São Carlos (SP), Brasil. Autor correspondente: moraes.uol@uol.com.br 2 Mestre pela Universidade Federal de São Carlos (UFSCar), São Carlos (SP), Brasil. 3 Mestre pela Universidade Federal de São Carlos (UFSCar), São Carlos (SP), Brasil. 4 Doutor em Ciência da Computação pela Université des Sciences et Techniques du Languedoc (USTL) - Montpellier II, Montpellier - França. 5 Doutor em Ciência da Computação pela Pontifícia Universidade Católica do Rio de Janeiro (PUC-RJ), Brasil.

2 2. Métodos Os métodos usados no processo proposto estão relacionados com padrão HL7, Arquétipos e DSLs Health Level Seven O comitê HL7 foi fundado nos Estados Unidos em 1987 e o padrão especificado por esse comitê foi paulatinamente difundido em vários países. Em junho de 2009, o Technical Committee (TC) 215 da International Organization for Standardization (ISO) estabeleceu o HL7 v2.5 como um protocolo de aplicação padrão para o intercâmbio eletrônico de dados em ambientes de Cuidado de Saúde 6. Apesar de um padrão robusto e difundido, a família HL7 v2.x possui limitações relacionadas principalmente à representação de conceitos clínicos e à interoperabilidade funcional 7. Visando lidar com tais deficiências, a família HL7 v3 foi desenvolvida baseada no paradigma de Orientação a Objetos (OO). Essa nova família emprega um Reference Information Model (RIM), que provê uma representação explícita dos relacionamentos entre os objetos pertencentes ao domínio Cuidado de Saúde. Entretanto, há um grande inconveniente: muitos refinamentos do RIM são necessários para se alcançar uma descrição de mensagem HL7 v3. Uma visão geral do processo proposto é ilustrada na Figura 1. Este processo compreende quatro atividades principais: Especificar Casos de Uso, Especificar Modelo de Interação, Especificar Modelo de Informação e Criar Descrição da Mensagem. Fig. 1. Visão Geral do processo de desenvolvimento Na atividade Especificar Casos de Uso, os requisitos da aplicação são identificados e representados por meio de diagramas de casos de uso. Na atividade Especificar Modelo de Interação, os diagramas de caso de uso são detalhados em diagramas de sequência, os quais descrevem o fluxo das informações, as regras de comunicação e os eventos que disparam as mensagens. Na atividade Especificar Modelo de Informação, o RIM HL7 é refinado com base nos diagramas de casos de uso e de sequência. De acordo com os casos de uso é extraído um subconjunto do RIM HL7, denominado Message Information Model (MIM), o qual é então refinado considerando os mesmos casos de uso e os diagramas de sequência correspondentes. Este último refinamento gera um modelo de classes denominado Refined-Message Information Model (R-MIM). Durante o refinamento do MIM atributos desnecessários são eliminados, cardinalidades são adicionadas aos relacionamentos e especializações das classes são realizadas em conformidade com os requisitos da aplicação. Finalmente, na atividade Criar Descrição da Mensagem, um esquema de descrição da mensagem é elaborado de acordo com as especificações do R- MIM. Essa descrição define a estrutura adequada da mensagem para atender aos requisitos do domínio da aplicação alvo. Mesmo com um modelo de referência e um processo bem definido para a estruturação de mensagens, a representação semântica de conceitos clínicos em HL7 exige um trabalho árduo, já que esta é realizada via a combinação de diferentes elementos do RIM HL7 (e.g., classes, classes auxiliares, atributos, relacionamentos) e via codificações de vocabulários específicos, os quais fornecem significado semântico às mensagens. Essa fragmentação esparsa de conceitos clínicos e esse uso de diferentes codificações sobrecarregam o desenvolvimento e dificultam a criação de mensagens HL7 v3. Além disso, existe uma carência de ferramentas que suportem o processo completo de desenvolvimento de mensagens HL7 v Arquétipos A estratégia adotada pelo comitê HL7 para a representação de conceitos clínicos tem sido questionada. A estrutura de conhecimento para o domínio Cuidado de Saúde provida pelo RIM HL7 pode limitar-se a templates, muitas vezes uma solução simplista para a representação do conhecimento no nível conceitual 8. Devido à sua natureza estática, os templates não permitem que variações socioculturais sejam representadas nos conceitos (e.g., rótulos, unidades de medida, idioma), o que em 9 é denominado de Problema de Variabilidade. Para lidar com esse problema e ampliar o significado semântico na representação de conceitos clínicos, o uso de arquétipos tem sido proposto. Arquétipos são pedaços de conhecimento, que indicam como representar conceitos ou informações de um domínio via expressões computáveis, que se baseiam num modelo de referência Linguagens Específicas de Domínio Uma DSL é projetada para ser útil a um conjunto específico de tarefas de um domínio alvo (ou do problema) 10, sendo geralmente constituída por um conjunto reduzido de abstrações e notações semelhantes aos termos reais usados pelos

3 especialistas desse domínio. Dessa forma, a DSL expressa os conceitos no idioma e nível de abstração adequados ao domínio alvo, reduzindo os esforços de tradução desses conceitos para o domínio da solução 11. O uso de DSLs para a modelagem de aplicações, ao invés de linguagens de modelagem de propósito geral (e.g., Unified Modeling Language-UML), possibilita criar modelos mais específicos e completos. Assim, recursos como frameworks, padrões de projeto e componentes podem ser incluídos aos modelos, criando uma infraestrutura que permite a execução de transformações 6 Modelo-para-Código (M2C), para a geração de uma maior quantidade de código Abordagem Proposta A abordagem utiliza uma DSL que expressa o conhecimento do domínio Cuidado de Saúde para integrar os arquétipos em mensagens HL7, visando utilizá-las na comunicação de aplicações ubíquas no Cuidado de Saúde Pervasivo. Usando a notação Structured Analysis and Design Technique (SADT), a Figura 2 mostra a visão geral da abordagem proposta, a qual consiste de duas etapas: Engenharia de Domínio (ED) e Engenharia de Aplicação (EA). Na ED são identificados e implementados ou recuperados do repositório Clinical Knowledge Manager (CKM) 13 os arquétipos; é desenvolvida uma DSL representada via um metamodelo para comunicação no domínio Cuidado de Saúde; são desenvolvidas transformações M2C para geração dos esquemas das mensagens; e são desenvolvidos os parsers responsáveis por instanciar objetos descritos nos esquemas das mensagens. Na EA aplicações ubíquas são desenvolvidas por meio do reuso dos artefatos desenvolvidos na etapa ED. O metamodelo é usado para suportar a modelagem da aplicação e as transformações M2C são reutilizadas para geração dos esquemas das Fig. 2. Visão geral da abordagem proposta mensagens HL7 v3 com arquétipos a partir dos modelos Engenharia de Domínio A etapa ED é dividida em quatro atividades principais descritas a seguir. Na atividade Especificar Metamodelo do Domínio, os requisitos do domínio Cuidado de Saúde são identificados, especificados, analisados e representados num metamodelo que expressa o conhecimento desse domínio. No IDE Eclipse, o Engenheiro de Domínio, guiado pelo RIM HL7, especifica o metamodelo usando o Eclipse Modeling Framework (EMF) 14. O RIM HL7 representa a informação num alto nível de abstração, o que permite o uso de diferentes terminologias na descrição dos conceitos desse domínio 15. A Figura 3 mostra parte do metamodelo elaborado, onde as metaclasses, os metaatributos e os metarrelacionamentos foram criados a partir de um mapeamento direto do diagrama de classes do RIM. Na atividade Projetar Metamodelo do Domínio a especificação do metamodelo é refinada, de acordo com os padrões, tecnologias e plataformas que viabilizaram a construção do mesmo. Empregando o EMF, o Engenheiro de Domínio adiciona ao metamodelo elementos para a identificação dos principais conceitos clínicos do domínio de saúde. O processo é guiado por terminologias médicas, tais como a Systematized Nomenclature of Medicine - Clinical Terms (SNOMED-CT) 16. SNOMED-CT é um esquema para identificação de termos e conceitos clínicos que são usados para suportar a interoperabilidade semântica entre aplicações de saúde. A Figura 4 mostra parte do metamodelo com a inclusão da metaenumeração Archetype, que lista os conceitos bparchetype e glucarchetype, os quais correspondem Fig. 3. Metamodelo RIM HL7 Na atividade Implementar Metamodelo do Domínio é realizada a implementação com base nas especificações contidas no projeto do metamodelo. Apoiado pelo framework EMF, o Engenheiro de Domínio gera o código Java do metamodelo e de um editor de modelos. Na etapa EA, esse editor auxiliará na especificação dos modelos das mensagens a partir do metamodelo. A execução dessa atividade resulta na disponibilização do metamodelo e do editor de modelos correspondente como um plugin no IDE Eclipse. Durante a EA, esse plugin permite que o metamodelo seja instanciado para a modelagem das mensagens. Uma respectivamente aos conceitos clínicos de pressão sanguínea e concentração de glicose sanguínea definidos pela SNOMED-CT. Fig. 4. Metamodelo com inlusão de conceitos 6 Transformações consistem num conjunto de regras que descrevem como um modelo de entrada deve ser mapeado num outro modelo de saída ou código-fonte.

4 vez que o metamodelo baseia-se no RIM, os modelos gerados, usando a DSL expressa por esse metamodelo, correspondem ao refinamento que deve ser realizado, criando dessa forma as mensagens HL7 usadas no intercâmbio entre as aplicações. Na atividade Construir Transformações Modelo para Código, as transformações para geração de código são construídas com o auxílio do framework Java Emitter Templates (JET) 17, que permite a criação da transformação M2C. As transformações interpretam os modelos criados usando o metamodelo do domínio Cuidado de Saúde implementado, gerando os esquemas apropriados das mensagens que transportam as informações sobre as entidades especificadas no modelo. Desde que os modelos também correspondam a um refinamento do RIM HL7, o mapeamento desses modelos para mensagens HL7 usando transformações é facilmente realizado, uma vez que os termos e conceitos expressados nos modelos são semelhantes aos usados para estruturar as mensagens Engenharia de Aplicação A etapa EA inclui as tradicionais disciplinas da Engenharia de Software, Análise, Projeto, Implementação e Teste. O uso dos metamodelos para modelagem de aplicação, além de facilitar o desenvolvimento de aplicações do domínio, permite o mapeamento do processo definido para o desenvolvimento de mensagens HL7 v3 (Figura 1) para as atividades tradicionais da Engenharia de Software. Deste modo, o refinamento do RIM pode ser realizado diretamente nos modelos que especificam os requisitos da aplicação. Além disso, as transformações M2C automatizam muitas das tarefas do Engenheiro da Aplicação associadas à organização das mensagens HL7 e sua integração com os arquétipos. O metamodelo do Cuidado de Saúde também possibilita o reuso do domínio do conhecimento em diferentes projetos durante a EA. A fim de investigar a viabilidade da abordagem proposta, um estudo de caso foi desenvolvido construindo uma aplicação ubíqua do domínio de Saúde. Esta aplicação permite que pacientes hipertensos registrem sua pressão sanguínea em seus dispositivos móveis. Esses registros são transmitidos para um servidor de modo que os cuidadores de saúde possam analisá-los e agir rapidamente, se necessário. Esta aplicação consiste de três partes: a primeira, executada no dispositivo móvel, registra e persiste os dados pressóricos inseridos pelo paciente, transmitindo-os para um servidor remoto via mensagens HL7 v3 com arquétipos que definem o conceito de pressão sanguínea; a segunda, executada no servidor, recebe as mensagens, trata os dados baseados em arquétipos contidos nas mesmas e os persiste numa base de dados; a última, também executada no servidor, provê uma interface web permitindo aos profissionais de Saúde visualizar os dados pressóricos de seus pacientes. As atividades da EA estão detalhadas a seguir, apresentando exemplos baseados na aplicação descrita no estudo de caso. Na atividade de Analisar, a aplicação é especificada conforme seus requisitos. O Engenheiro de Aplicação faz uso de notações UML, tais como a diagramação dos casos de uso e classes. Um exemplo é o uso de diagrama de caso de uso mostrado na Figura 5, o qual descreve os requisitos para registro dos dados pressóricos; a submissão desses dados ao servidor via mensagens HL7 v3 com arquétipos; e o acesso desses dados pelo cardiologista. Na atividade Projetar, as especificações da Análise Fig. 5. Casos de uso da aplicação são refinadas com as tecnologias de hardware e software pertinentes as quais permitem implementar a aplicação, tais como a plataforma Java ME. Baseado nos diagramas de casos de uso, o Engenheiro de Aplicação modela as mensagens com base no metamodelo desenvolvido na ED, selecionando as classes e atributos relevantes ao domínio do problema. A Figura 6 mostra, à esquerda, uma visão em árvore do modelo, desenvolvido a partir do metamodelo, e à direita é apresentado o diagrama de objetos instanciado do metamodelo. Este modelo descreve as informações da aplicação para intercâmbio de registros pressóricos. Como especificado no diagrama de casos de uso, o paciente registra a pressão sanguínea em seu dispositivo móvel. Esse registro é traduzido numa Observation no modelo de mensagens. A associação entre o paciente e seu registro de pressão sanguínea é indicada pelo elemento Participation. Esse elemento é composto de uma Person e uma Organization, as quais descrevem os atributos do paciente e a instituição de saúde na qual o mesmo recebe cuidados médicos. No modelo tem-se uma segunda Participation associada à Qualified Entity para representar o profissional de Saúde responsável pelo paciente. Adotando a codificação SNOMED-CT, empregada no metamodelo, os arquétipos que definem os conceitos clínicos, representados nos modelos das mensagens, são combinados aos seus respectivos códigos. Por exemplo, no modelo da Figura 6, o código SNOMED-CT, que identifica o conceito clínico de pressão sanguínea, é atribuído ao campo code do elemento Observation. Fig. 6. Modelo construído no editor de modelos Além disso, são atribuídos ao campo value os dados restringidos

5 pelo arquétipo, que correspondem ao registro de pressão sanguínea. Na atividade Implementar e Testar tem-se a codificação da aplicação e a geração dos esquemas das mensagens. Com o auxílio da IDE Eclipse, o Engenheiro de Aplicação executa as transformações M2C, que são aplicadas aos modelos para gerar a estrutura das mensagens empregadas no transporte de dados de Saúde. Além disso, os parsers desenvolvidos na ED são incorporados como APIs na aplicação, garantindo à mesma a capacidade de criação, serialização e interpretação das mensagens HL7 v3 com arquétipos. Devem também ser implementados nessa atividade os demais elementos da aplicação, tais como as interfaces com o usuário e a persistência dos dados, e a lógica para manipular o conteúdo das mensagens. Ao final da implementação, testes são realizados, proporcionando o retorno para indicar se é ou não necessário retornar a uma etapa anterior da EA. 3. Resultados e Discussões Dentre as motivações para a integração de arquétipos às mensagens HL7 v3 destaca-se a real necessidade de atender os usuários finais de aplicações do domínio de saúde, proporcionando-lhes agilidade e eficiência na troca de informações de saúde. Com o objetivo de avaliar a viabilidade da abordagem proposta para produzir aplicações que atendam aos requisitos do domínio, um protótipo da aplicação desenvolvida foi apresentado a vinte e seis pacientes hipertensos e cinco cardiologistas. Como estratégia de avaliação foi aplicado o modelo Technology Acceptance Model (TAM) 18. O TAM permite avaliar a utilidade e a facilidade de uso percebida pelos usuários, considerando os efeitos de variáveis externas, tais como as características da aplicação, o processo de desenvolvimento, o treinamento e a intenção de uso 19. As aplicações desenvolvidas foram implantadas nos dispositivos móveis dos pacientes, que receberam instruções sobre as funcionalidades para registro e envio dos dados pressóricos. Utilizando dispositivos digitais, os pacientes mediram e registraram suas pressões sistólica e diastólica por cinco dias consecutivos. Baseados no arquétipo de pressão sanguínea, os dados encapsulados em mensagens HL7 v3 foram automaticamente enviados dos dispositivos móveis dos pacientes para o servidor, de modo que os cardiologistas pudessem analisá-los por meio de uma interface web. Após o período de uso da aplicação, formulários de avaliação baseados no TAM foram preenchidos pelos pacientes e cardiologistas. Nesses formulários os usuários especificaram seus níveis de concordância, com relação a uma determinada afirmação sobre a aplicação, conforme a escala de Likert 20. Os resultados dessa avaliação estão resumidos na Tabela 1. Para cada afirmação, a avaliação dos pacientes está localizada no topo das células e a avaliação dos médicos na parte inferior. Tabela 1. Resultados dos formulários submetidos aos Pacientes/Médicos Os resultados apresentados na Tabela 1 evidenciam que: em relação à utilidade percebida da aplicação, de que tratam as duas primeiras afirmações, pacientes e médicos consideram-na útil, já que todos concordam plenamente ou parcialmente com essas afirmações; em relação à facilidade de uso da aplicação, de que tratam as duas últimas afirmações, pacientes e médicos consideram-na de fácil uso, já que todos discordaram plenamente ou parcialmente dessas afirmações. Com base nesses resultados, pode-se afirmar que todos os objetivos dessa avaliação, ou seja, verificar a utilidade percebida e a facilidade de uso, foram alcançados. O uso combinado dessas tecnologias permitiu agilizar a troca de informações entre pacientes e médicos, bem como atender as necessidades de interoperabilidade de forma eficiente, o que aumentou a satisfação dos usuários Trabalhos Relacionados Devido, principalmente, à complexidade existente no processo de desenvolvimento de mensagens HL7 v3 e à falta de ferramentas de suporte que cubram este processo na sua totalidade, várias propostas para facilitar a utilização de padrões podem ser encontradas na literatura. Em 21 é relatada a implementação de uma ferramenta de modelagem para mensagens HL7 v3 via o uso da IDE Eclipse e do framework EMF. A ferramenta desenvolvida permite, tanto o uso de um editor de modelos gráfico, quanto o uso de um editor textual para modelar as mensagens, serializando os modelos em XMI para uso posterior. Em 22 e 23 é apresentada uma arquitetura e a implementação de uma fábrica de software direcionada ao domínio Cuidado de Saúde. O objetivo foi automatizar a criação das interfaces de comunicação, seguindo estritamente o processo de desenvolvimento de mensagens HL7 v3. Em 24 é

6 apresentada uma solução para auxiliar os desenvolvedores na manipulação de mensagens da família HL7 v2.x, baseada no uso de uma DSL programática para dar suporte à criação, envio, interpretação e validação de tais mensagens. A abordagem proposta neste trabalho baseia-se em diversas características do trabalho descrito acima. No entanto, tem suas próprias contribuições por meio da evolução e adaptação das concepções dos trabalhos relacionados. Entre as contribuições deste trabalho, há o uso de arquétipo para representar conceitos clínicos, que são integrados em mensagens HL7. Além disso, a abordagem propõe o uso de terminologias, tais como SNOMED-CT, o que facilita a identificação de termos clínicos contidos nas mensagens trocadas entre as aplicações. A DSL é usada também, com base em um metamodelo de domínio Cuidado de Saúde, que permite a modelagem e geração automática do esquema para os módulos de comunicação das aplicações nesse domínio. 4. Conclusões Este artigo apresentou uma abordagem para o desenvolvimento de aplicações ubíquas para o Cuidado de Saúde Pervasivo que integra arquétipos em mensagens HL7 via DSLs. A integração de arquétipos em mensagens HL7 visa suportar a agilidade e eficiência na comunicação entre diferentes SIH, uma vez que a comunicação se torna interoperável e os conceitos clínicos podem facilmente ser identificados. O uso de DSLs permite a criação de uma infraestrutura para a geração dos esquemas das mensagens, e seu reuso em diferentes aplicações do domínio de destino, as quais reduzem os esforços no desenvolvimento de aplicações. Uma aplicação ubíqua para RES foi desenvolvida para investigar a viabilidade do processo proposto. A aplicação foi apresentada a um grupo de usuários qualificados (pacientes hipertensos e cardiologistas) e avaliada quanto à utilidade e facilidade de uso percebida pelos mesmos. Os resultados favoráveis demonstram o potencial da proposta para desenvolver aplicações que correspondam às reais necessidades dos usuários em ambientes de Cuidado de Saúde Pervasivo. Espera-se que essas aplicações possam contribuir para a redução da readmissão em centros de saúde de portadores de Doenças Crônicas Não Transmissíveis (DCNTs), melhorando a qualidade de vida dos mesmos, na medida em que possibilitam a monitoração à distância desses pacientes pelos profissionais de saúde. A fim de aperfeiçoar o processo e suporte computacional apresentados, outros trabalhos estão sendo desenvolvidos visando: a definição de uma atividade sistemática de testes para maximizar a correção de erros nos esquemas das mensagens; a melhoria do metamodelo de Cuidado de Saúde para fornecer uma maior variedade de arquétipos e permitir o desenvolvimento de aplicações que gerenciem outras DCNTs, tais como diabetes, asma e obesidade; e otimizações nas transformações M2C para possibilitar uma maior automação na geração dos esquemas das mensagens. 5. Referências [1] U. Varshney, Pervasive Healthcare Computing: EMR/EHR, Wireless and Health Monitoring, 1 ed. Springer Publishing Company, [2] J. E. Bardram, A. Mihailidis, and D. Wan, Pervasive Computing in Healthcare. CRC Press, [3] U. Hansmann, L. Merk, M. S. Nickous, and T. Stober, Pervasive Computing, 2 ed. Springer-Verlag, [4] T. Beale, Archetype constraint-based domain models for future-proof information systems, p. 69, 2001, Disponível: [5] D. A. Sadilek, Prototyping Domain-Specific Language Semantics, in Conf. on OOP Syst. Languages and Applications. Orlando, Flórida: ACM, [6] TC215, ISO Technical Committee 215 (ISO/TC215). Disponível: Acessado: [7] NEOTOOL, The HL7 Evolution. Disponível: , Acessado: [8] E. Browne, Archetypes for HL7 CDA Documents. Disponível: , Acessado: [9] T. Beale and S. Heard, Archetype Definition and Principles. Disponível: , Acessado: [10] R. C. Gronback, Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. Addison-Wesley, [11] D. Lucrédio, Uma Abordagem Orientada a Modelos para Reutilização de Software. PhD Thesis, São Paulo University, São Carlos, São Paulo, [12] J. Greenfield, K. Short, S. Cook, and S. Kent, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, [13] openehr, openehr Fundation. Disponível: Acessado: [14] D. Steinberg, F. Budinsky, M. Paternostro, E. Merks, EMF Eclipse Modeling Framework. Addison-Wesley, [15] T. Benson, Principles of Health Interoperability HL7 and SNOMED, 1 ed. Springer, [16] SNOMED, Systematized Nomenclature of Medicine - Clinical Terms. Disponível: Acessado: [17] Eclipse, EMFT JET Developer Guide. Disponível: Acessado: [18] F. D. Davis, Perceived usufulness, perceived ease of use, and user acceptance of information technology, MIS Quarterly, vol. 13, no. 3, pp , [19] A. Dillon and M. Morris, User acceptance of new information technology: theories and models, in Review of Information Science and Technology, [20] R. Likert, A technique for the measurement of attitudes, Archives of Psychology, vol. 22, no. 140, p. 55, [21] B. Bánfai, B. Ulrich, Z. Török, R. Natarajan, T. Ireland, Implementing an HL7 version 3 Modeling Tool from an Ecore Model, in Medical Informatics in a United and Healthy Europe, 2009, pp [22] M. Regio, J. Greenfield, B. Thuman, A Software Factory Approach to HL7 version 3 Solutions. Disponível: Acessado: [23] M. Regio and J. Greenfield, Designing and Implementing an HL7 Software Factory, in 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Application, San Diego, California, 2005, p. 7. [24] C. Ohr and M. Václavík, Using HL7 Processing Capabilities of the Open Ehealth Integration Platform in the Implementation of IHE Profiles, in ICW Developer Conf. 2009, Walldorf, 2009, p. 11.