Nuno Miguel Pereira da Silva. Master Files Management

Transcrição

1 Nuno Miguel Pereira da Silva Master Files Management Departamento de Ciência de Computadores Faculdade de Ciências da Universidade do Porto Março de 2009

2 Nuno Miguel Pereira da Silva Master Files Management Relatório de Estágio submetido à Faculdade de Ciências da Universidade do Porto como parte dos requisitos para a obtenção do grau de Mestre em Ciência de Computadores Orientador: Eng o António Martins (Siemens Healthcare) (Trabalho supervisionado no DCC pelo professor Luis Filipe Coelho Antunes) Departamento de Ciência de Computadores Faculdade de Ciências da Universidade do Porto Março de 2009

3 Agradecimentos Gostaria de agradecer tanto ao meu orientador, o Eng o António Martins como ao Eng o Daniel Ramos por toda a orientação que me deram e por toda a confiança que depositaram em mim para avançar com este projecto. Com igual importância, agradeço a toda a equipa da qual fiz parte, pois todas as discussões tidas contribuiram para ultrapassar quaisquer percalços encontrados. 3

4 Abstract Healthcare organizations always have a myriad of applications to address the administrative and medical area to help in the most common, everyday tasks/activities that they have to perform. Between these applications there is shared information, usually found under the form of code or name lists (named catalogs), that should be centrally administered but globally available. These systems are, in general, composed by a central repository, owner of such catalogs, and various entities that consult this information (the consumers). The main purpose of this project, named Master Files Manager, is to implement a system that enables the centralized management of all the information aiming to significantly improve the organization and quality of available information within Healthcare organizations. 4

5 Resumo As organizações de saúde possuem um vasto leque de aplicações vocacionadas para a gestão e apoio à actividade médico-clínica e administrativa. Entre estas aplicações existe informação redundante que deveria ser partilhada, usualmente sob a forma de listas de códigos ou nomes (denominados por catálogos), que deveriam estar centralizados e acessíveis globalmente. Estes sistemas são compostos geralmente por um repositório central, proprietário da informação destes catálogos, e por várias entidades que consultam esta informação (consumidores). O objectivo do presente projecto, de nome Master Files Manager, é a implementação de um sistema que possibilite a gestão centralizada de toda a informação com vista à melhoria significativa da organização e qualidade da informação disponível nas instituições de saúde. 5

6 Conteúdo Abstract 4 Resumo 5 Lista de Figuras 10 Listagens 11 1 Introdução Apresentação da Siemens Sector Healthcare O Projecto Estrutura Estado da Arte Estudo do HL Versão 2.X Versão Estudo da Nomenclatura Registry Master File

7 2.2.3 Vocabulários Estudo das tecnologias existentes IHE Laboratory Code Sets Distribution Lexical Grid Projecto Master Files Manager Caso de Uso Administrador Consumidor Utilizador MFM Autoritativo Diagramas de Sequência Notificação Query Update Implementação Ferramentas e metodologias de desenvolvimento Arquitectura Geral Tecnologias usadas Java Hibernate ZK HAPI Implementação Mapeamento Objecto Relacional

8 4.4.2 Módulo de Comunicação Interface Web Conclusões Objectivos Cumpridos Dificuldades Sentidas Trabalho Futuro A Acrónimos 53 B Mensagens HL7 54 B.1 MFN/MFK - Evento M B.2 MFN/MFK - Evento M B.3 MFN/MFK - Evento M C Exemplo de mensagens 58 Referências 60 8

9 Lista de Figuras 1.1 Distribuição da informação numa organização de saúde Agregação da informação utilizando um Master File Manager Antes e depois do HL Caso de Uso - Vista Geral Caso de Uso - Administrador Caso de Uso - Subscritor Caso de Uso - Utilizador Caso de Uso - MFM Autoritativo Exemplo de uma actualização proveniente de um Master Files Manager autoritativo Diagrama de Sequência - Notificação Diagrama de Sequência - Query Diagrama de Sequência - update Diagrama da Arquitectura de Topo Exemplo de uma tabela mapeada numa árvore XML Ecrã de login Vista dos catálogos Edição de uma entrada de um catálogo

10 4.6 Vista dos consumidores

11 Listagens 4.1 hibernate.cfg.xml administrativegender.hbm.xml

12 Capítulo 1 Introdução Neste capítulo será feita uma introdução da Siemens, empresa onde decorreu o projecto e, de seguida, apresentaremos o mesmo. 1.1 Apresentação da Siemens Com 500 centros de produção em 50 países e presença em 190 países a Siemens está representada em todo o mundo. Em Portugal, a Siemens S.A. dispõe de duas unidades fabris, centro de investigação & desenvolvimento de software (Lisboa e Porto) e presença em todo o país, através dos seus parceiros e das suas instalações. A empresa está desde 2008 organizada em três grandes sectores de actividade: Industry, Energy e Healthcare. O Sector Industry dispõe de soluções para a indústria nas vertentes de produção, transporte e edifícios, segmentando-se em cinco áreas: Industry Automation and Drive Technologies, Building Technologies, Industry Solutions, Mobility e OSRAM. O Sector Energy disponibiliza produtos e soluções para a geração, transmissão e distribuição de energia eléctrica, segmentando-se em seis áreas: Fossil Power Generation, Renewable Energy, Oil & gas, Energy Service, Power Transmission e Power Distribuition. 12

13 CAPÍTULO 1. INTRODUÇÃO Sector Healthcare O Sector Healthcare oferece um conjunto de produtos inovadores e soluções integradas bem como serviços e consultadoria na área da saúde, segmentando-se em três áreas: Imaging & IT, Workflow & Solutions e Diagnostics. A área Imaging & IT disponibiliza sistemas de imagem para diagnóstico precoce e intervenção, bem como para prevenção efectiva, nomeadamente Sistemas de ressonância magnética (MR), Sistemas de tomografia axial computorizada (CT), Sistemas de radiografia, Sistemas angiográficos digitais, Sistemas de tomografia por emissão de positrões (PET/CT) e tomografia por emissão de fotão único (SPECT e SPECT/CT), Unidades de ecografia, entre outros. Todos os sistemas estão interligados por tecnologias de informação de elevada performance possibilitando uma optimização dos processos a nível dos prestadores de cuidados de saúde (sistemas de gestão hospitalar como o Soarian R, sistemas de processamento de imagem como o Syngo R e tecnologias knowledge-based como auxiliares de diagnóstico). A área Workflow & Solutions disponibiliza soluções globais para especialidades como a cardiologia, a oncologia e a neurologia. Esta área fornece ainda soluções, por exemplo, para saúde da mulher (mamografia), a urologia, a cirurgia e a audiologia, englobando igualmente a vertente de consultadoria e soluções globais (soluções globais para prestadores de cuidados de saúde). Simultaneamente, a área de Workflow & Solutions engloba a prestação de serviços pós-venda e gestão de clientes. A área Diagnostics encerra a vertente de diagnóstico in-vitro, incluindo imunodiagnóstico e análise molecular. As soluções da área vão desde os aplicativos point-ofcare até à automatização de grandes laboratórios. Desta forma, o Sector Healthcare é hoje a primeira empresa a nível mundial a disponibilizar um portofolio integrado de tecnologia que permite responder a todas as fases do ciclo de cuidados de saúde. A Siemens IT Solutions and Services, um dos líderes em oferta de serviços na área das Tecnologias de Informação (TI), funciona como unidade de negócio transversal. Em Portugal, o Sector Healthcare da Siemens S.A. é um dos líderes de mercado no ramo dos cuidados de saúde, reconhecido pelas suas competências e força de inovação em diagnóstico e tecnologias terapêuticas, assim como engenharia de conhecimento, incluíndo tecnologias de informação e integração de sistemas.

14 CAPÍTULO 1. INTRODUÇÃO 14 Nos últimos anos, o Sector Healthcare da Siemens SA tem promovido uma estratégia de contacto e parceria com a Comunidade Académica e Científica em Portugal, no sentido da criação de uma rede de conhecimento e parcerias estratégias que potenciem a inovação, a investigação e o desenvolvimento (IDI) na área da Saúde. Actualmente o Sector Healthcare conta com um Grupo de IDI com mais de 15 elementos, desenvolvendo investigação em áreas estratégicas como Sistemas de informação para a Saúde, Imagem Computacional, Análise automática de Imagem Médica, Modelação e ferramentas de suporte à decisão e Avaliação Tecnológica Estratégica, que resultou já no registo de uma patente e submissão de duas outras, bem como na publicação de mais de dez artigos científicos [1]. 1.3 O Projecto Hoje em dia, as unidades de saúde possuem uma enorme quantidade de aplicações que são utilizadas na gestão de várias tarefas diárias, tanto em áreas médicas como admininstrativas. A informação gerida por estas aplicações encontra-se distribuída por diferentes bases de dados que armazenam a mesma informação e que podem nem se encontrar no mesmo espaço físico, ou seja, cada aplicação acede à sua própria base de dados (figura 1.1). A sincronização da informação entre as diferentes bases de dados é garantida manualmente o que pode muito facilmente levar a uma discrepância de dados causada por erros humanos. Além disso, se se estiver a falar de uma organização de saúde suficientemente grande, o número elevado de diferentes aplicações por onde a mesma informação se encontra distribuida, obriga à existência de vários responsáveis pela gestão da informação. Neste cenário, seria vantajosa a existência de uma aplicação que gerisse toda a informação distribuida e a sincronizasse? Com o crescente aparecimento de software com capacidade de comunicar através do protocolo de mensagens Health Level 7 (HL7), não podemos deixar de pensar que será mesmo possível integrar todas as aplicações isoladas, que necessitem de informação partilhada, num grupo centralizado. O objectivo do projecto Master File Manager é colmatar essa falha, minimizando o risco de dessincronia da informação que está armazenada nas diferentes base

15 CAPÍTULO 1. INTRODUÇÃO 15 Figura 1.1: Distribuição da informação numa organização de saúde de dados.(figura 1.2) Master files tratam-se de conjuntos de ficheiros-mestre (ou catálogos) 1 que são utilizados por um ou mais sistemas de informação. Alguns exemplos de master files incluem: Listas de medicamentos, funcionários, actos facturáveis, listas de exames realizáveis, localidades, etc. São estes catálogos que necessitam de ser sincronizados e é o Master File Manager que realiza essa sincronização utilizando uma base de dados relacional como repositório para esses catálogos. [2] O presente projecto procura criar uma aplicação que possibilite a criação e gestão de repositórios de diversos catálogos bem como a notificação a todos os sistemas que necessitem de actualizar informação nos catálogos internos, quando estes são modificados. 1 Os termos catálogos e master-files têm significados idênticos sendo que serão doravante utilizados de forma alternada ao longo do presente relatório

16 CAPÍTULO 1. INTRODUÇÃO 16 Figura 1.2: Agregação da informação utilizando um Master File Manager 1.4 Estrutura O presente documento começa por expor os objectivos e a motivação do projecto desenvolvido. Segue-se uma apresentação do estado-da-arte caracterizando as tecnologias já existentes no mercado e introduzindo conceitos gerais sobre a norma de comunicação Health Level 7 (capítulo 2). No capítulo intitulado O Projecto iremos explicar detalhadamente todas as funcionalidades pretendidas da aplicação e no quarto capítulo proceder-se-á à explicação da implementação do projecto MFM. Por fim, no capítulo 5, serão mencionados quais os objectivos cumpridos e qual a satisfação com os mesmos assim como quais os próximos passos para possíveis implementações futuras.

17 Capítulo 2 Estado da Arte Neste capítulo será apresentado todo o estudo que suporta a aquisição de competências no âmbito do presente projecto. Será explicada a nomenclatura necessária para a compreensão da temática em questão assim como o estudo realizado sobre a norma Health Level 7. Finalmente dar-se-ão a conhecer algumas tecnologias com objectivos idênticos à que pretendemos implementar. 2.1 Estudo do HL7 O Health Level Seven é uma organização voluntária, sem fins lucrativos, dedicada ao desenvolvimento de padrões na indústria da saúde. O nome Health Level Seven é uma referência à sétima camada do modelo OSI, a camada de aplicação. O nome indica que o HL7 foca-se nos protocolos da camada de aplicação, independentemente das camadas mais baixas. Tem como objectivo final a criação de normas coerentes por forma a permitir interoperabilidade entre todos os sistemas de informação médica, estimulando os peritos da área de saúde a participar no seu desenvolvimento. O HL7 desenvolve especificações conceituais (e.g. HL7 Reference Information Model), documentais (e.g. HL7 Clinical Document Architecture), aplicacionais (e.g. HL7 Clinical Context Object Workgroup) e de mensagens (e.g. HL7 v2.x e v3.0). 17

18 CAPÍTULO 2. ESTADO DA ARTE 18 Esta última especificação é de extrema importância pois é ela que define como a informação deve ser agrupada e comunicada através das várias aplicações envolvidas em actividades médico-clínicas, permitindo assim uma maior interoperabilidade entre sistemas de informação médica. [3] Para este projecto estudamos tanto a versão 2.X como a versão 3.0, que explicaremos melhor nas subsecções seguintes Versão 2.X Esta versão define uma série de mensagens electrónicas usadas para suportar não só processos clínicos mas também administrativos, logísticos e financeiros. Esta especificação começou a ser criada desde 1987 e tem vindo a ser actualizada regularmente, culminando nas versões 2.1 à 2.6. O aparecimento deste protocolo levou a que cada aplicação deixasse de necessitar de comunicar através de mais do que um método, como se pode ver na figura 2.1. (a) Sistemas de informação médica sem HL7 (b) A mesma organização com HL7 Figura 2.1: Antes e depois do HL7 Saber a versão exacta usada por uma aplicação não é crucial pois todas as versões 2.X são em grande parte compatíveis entre si. A filosofia desta especificação aponta que todas as novas versões devem ter compatibilidade com as versões já existentes. Sempre que novos dados e tipo de mensagens são adicionados, são marcados como elementos opcionais, o que significa que as versões mais recentes conseguem processar uma mensagem de uma aplicação que use uma versão mais antiga e vice-versa. Apesar de já existir uma nova versão 3.0 no mercado, a 2.X continua a ser a mais

19 CAPÍTULO 2. ESTADO DA ARTE 19 utilizada e continua ainda a ser refinada. Apesar de todos os esforços, esta norma tem ainda alguns problemas: A falta de um modelo de dados consistente o que implica que o armazenamento de dados feito por uma aplicação clínica tenha um impacto directo sobre que porções da mensagem se consegue implementar Falta de metodologias formais para modelação dos elementos de dados e mensagens, o que pode causar inconsistências dentro da especificação e trazer dificuldades na forma como cada elemento da mensagem se relaciona com os restantes elementos A grande flexibilidade da especificação leva a que a mesma seja vaga e pouco precisa. Não existem papéis (user roles) definidos para a sua utilização, portanto a implementação deste padrão pode variar entre aplicações No entanto, apesar destas desvantagens, esta foi a versão utilizada no projecto visto que continua a ser a mais utilizada nas organizações de saúde. Além disso, já existem ferramentas de software livre que implementam esta especificação, o que facilita bastante o desenvolvimento do módulo de comunicação HL Versão 3.0 Sendo esta versão uma especificação derivada dum modelo, será apenas lógico começarmos por explicar o modelo de informação a partir do qual todos os standards desta versão são gerados: o Reference Information Model ou simplesmente RIM. Isto significa que tanto os padrões de mensagens em V3 como os documentos em V3 (e.g., CDA, CCD, etc) são todos baseados neste RIM. O RIM é a pedra angular do desenvolvimento do HL7 versão 3.0 e uma parte fundamental da sua metodologia. Este modelo expressa os dados necessários em cada contexto clínico ou administrativo e fornece uma representação de todas as conexões existentes entre os campos das mensagens. Podemos assim dizer que, se o HL7 é uma linguagem, o Reference Information Model é a gramática, que possibilita a construção de frases correctas para a linguagem em questão e especifica a relação entre palavras. À primeira vista o RIM é bastante simples, sendo o seu núcleo constituído por apenas seis classes:

20 CAPÍTULO 2. ESTADO DA ARTE 20 Act - Representa as acções que são executadas e que necessitam de ser catalogadas quando serviços são prestados; Participation - Representa o contexto de um acto: quem o realizou e onde, para quem foi executado, etc.; Entity - Representa materiais e seres físicos que são de interesse, e tomam parte nos cuidados médicos; Role - Estabelece os papéis (roles) que as entidades desempenham enquanto participantes em serviços de cuidados médicos; Act Relationship - Representa a ligação de dois actos, i.e., a relação entre uma ordem para uma observação e a própria ocorrência dessa mesma observação; Role Link - Representa as relações entre cada papel individual. 2.2 Estudo da Nomenclatura Nesta secção iremos explicar todos os conceitos definidos pelo HL7, necessários para um melhor entendimento do âmbito deste projecto Registry O propósito de uma registry é facilitar a localização de objectos, guardando identificadores e meta-dados desses mesmos objectos. Uma registry tem de responder a pesquisas de objectos usando um ou mais parâmetros pré-definidos, por forma a encontrar uma ocorrência única de uma entidade. O conteúdo de uma registry não se deverá categorizar apenas como dados clínicos mas sim como todos os dados necessários para operacionalizar transacções clínicas. Uma registry apresenta as seguintes características: Aceitar acréscimos e/ou actualizações de múltiplas origens; Não aceitar notificações de sistemas com informações idênticas. I.e. uma registry de pacientes não aceita notificações de outras registries de pacientes, com o intuito de incorporar esses dados no seu domínio;

21 CAPÍTULO 2. ESTADO DA ARTE 21 Ser uma fonte de notificações de mensagens para outros sistemas, alguns dos quais podem replicar esses dados como um todo ou como partes (e.g. tabelas de referência); Poder suportar publicação (dados) e subscrição (consumidores) Master File As funcionalidades dos master files contituem, essencialmente, um subconjunto das funcionalidades das registries. O conteúdo poderá ser o idêntico ao de uma registry, com a diferença de que num master file, a informação deverá ser relativamente estável o que também leva a que os metadados deixem de ter grande importância. O Master File apresenta as seguintes características: Não aceitar pedidos de acréscimos e/ou actualizações provenientes de outros sistemas Ser visto como uma fonte autoritativa de dados para outros sistemas Poder, opcional e periodicamente, enviar o seu conteúdo a outros sistemas Suportar consultas e estar optimizado para altos volumes destas transacções Vocabulários Tal como definido pelo HL7 versão 3.0, os vocabulários lidam com o conteúdo, comunicação e armazentamento de informação. Consistente com a filosofia empreendida pela terceira versão do HL7 de restringir sucessivamente um modelo abstracto, também os vocabulários se dividem por várias categorias. A categoria menos restringida é o Concept Domain. Esta categoria existe com o propósito de permitir o adiamento da associação de cada elemento a uma terminologia específica até, possivelmente, à fase de implementação. Assim, os Concept Domains são independentes de qualquer vocabulário específico.[4] À lista de valores pretendidos para um Concept Domain é chamado Value Set que, por sua vez, contém um ou mais Concept Codes. Estes ultimos consistem em qualquer tipo de dados que pode ser enviado numa mensagem HL7 Versão 3 e é apenas válido no

22 CAPÍTULO 2. ESTADO DA ARTE 22 contexto que o define (por exemplo, um F pode significar Feminino num contexto e Fumador noutro). Ao contexto que define estes conceitos é chamado um Code System. No domínio médico já existem alguns Code Systems tais como o SNOMED- CT e ICD-9 e por este motivo o HL7 prefere reutilizar os conceitos existentes em vez de desenvolver novos.[5] 2.3 Estudo das tecnologias existentes Devido ao foro inovador do nosso projecto, não existem ainda aplicações que consigam enquadrar totalmente todo o cenário de funcionalidades permitidas pelos master files IHE Laboratory Code Sets Distribution O IHE (Integrating the Healthcare Enterprise) é uma iniciativa encetada por profissionais da indústria de saúde dedicada a melhorar a interoperabilidade entre sistemas de informação médica. [6] Neste âmbito, o IHE tem vindo a desenvolver (está ainda em fase experimental) o Laboratory Code Sets Distribution, denominado por LCSD (ainda em fase experimental) [7], um perfil de integração para sistemas de informação médica. Este perfil permite partilhar nomenclatura comum entre sistemas envolvidos em trabalhos laboratoriais. Implementando as transacções de mensagens para master files baseadas na versão 2.5 do HL7, este projecto foi o ponto de partida para o presente projecto, apesar do âmbito ser completamente diferente Lexical Grid O Lexical Grid [8] é um projecto publicado pela clínica Mayo [9], mais específicamente pela divisão de informática e estatística biomédica desta mesma clínica[10]. Este projecto procura fornecer suporte a uma rede distribuida de recursos léxicos, tais como terminologias e ontologias (e.g. SNOMED-CT[11], LOINC[12], etc), através de ferramentas, formatos de armazenamento e mecanismos de acesso e actualização padrão.

23 CAPÍTULO 2. ESTADO DA ARTE 23 Actualmente há bastantes terminologias e ontologias existentes mas praticamente cada uma tem o seu próprio formato, o seu próprio conjunto de ferramentas e os seu próprios métodos de actualização; o LexGrid foi desenhado como uma forma de ligar estas terminologias e ontologias com um mesmo conjunto de ferramentas. Este projecto é uma referência importante no que toca a acesso e partilha de informação distinta, fornecendo tanto uma API como uma implementação do HL7 Common Terminology Services[13][14]. Apesar de este ter, também, um âmbito diferente do nosso objectivo, achamos que a sua inclusão nesta investigação foi crucial.

24 Capítulo 3 Projecto Master Files Manager Precedendo a implementação da aplicação em si, os requisitos do projecto foram transformados num diagrama de caso de uso específico. Este diagrama define todas as funcionalidades pretendidas no projecto. (Figura 3.1) Após esta etapa elaboramos os diagramas de sequência, que explicam o funcionamento de determinadas acções chave do programa. Neste capítulo vamos assim explanar o conteúdo acima referido. 3.1 Caso de Uso O propósito deste diagrama é apresentar uma vista geral das funcionalidades fornecidas pela nossa aplicação em termos de actores e objectivos de cada um. Nesta secção iremos assim explicar que funções poderão ser executadas por cada actor presente no Master File Manager Administrador Um administrador, que não é mais do que um utilizador devidamente autenticado na interface web do programa, tem a capacidade de gerir os catálogos já existentes no sistema e também acrescentar novos catálogos. A gestão de catálogos inclui a remoção ou edição de entradas já existentes assim como a adição de novas entradas. A adição de entradas pode, opcionalmente, ser feita através do upload de um ficheiro em formatos XML ou CSV, o que permite adicionar várias entradas de uma só vez. 24

25 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 25 Figura 3.1: Caso de Uso - Vista Geral

26 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 26 Figura 3.2: Caso de Uso - Administrador Além das operações com catálogos, um administrador tem também a responsabilidade de gerir as subscrições a cada catálogo assim como os subscritores em si. Pode adicionar, remover e editar cada subscritor e os catálogos por ele subscritos. (Figura 3.2) Consumidor Este actor é o principal cliente da nossa aplicação. Este actor pode, assim, pedir a subscrição a um ou mais catálogos, subscrição essa que tem de ser aprovada por um administrador; pode fazer queries a catálogos e, uma vez subscrito, recebe notificação de todas as alterações feitas a esses catálogos. De salientar que este actor representa tanto uma aplicação (para quem as notificações de alterações se dirigem) como o administrador dessa mesma aplicação (que é quem deve fazer o pedido de subscrição de catálogos). (Figura 3.3) Utilizador Um utilizador será qualquer pessoa autenticada, que não possua direitos de administrador, que aceda à interface do sistema.

27 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 27 Figura 3.3: Caso de Uso - Subscritor Figura 3.4: Caso de Uso - Utilizador

28 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 28 Este actor terá a possibilidade de visualizar quais os catálogos existentes e a ser geridos pelo Master Files Manager, assim como visualizar o conteúdo de cada catálogo. (Figura 3.4) MFM Autoritativo Figura 3.5: Caso de Uso - MFM Autoritativo Este actor explica o funcionamento da nossa aplicação enquanto cliente de um outro Master Files Manager. Isto significa que a nossa aplicação poderá servir de proxy entre os seus subscritores e outros MFM externos. (Figura 3.5). Com isto, a aplicação torna-se num subscritor, podendo executar todas as operações feitas por esse mesmo actor, descrito no capítulo anterior. (Figura 3.3). A figura 3.6 representa uma actualização a um, ou vários, catálogos subscritos por várias aplicações ao nosso Master Files Manager que, por sua vez, tem os mesmos

29 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 29 Authoritative MFM Hospital A MFM ADT MPI MPS Figura 3.6: Exemplo de uma actualização proveniente de um Master Files Manager autoritativo

30 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 30 catálogos subscritos a um outro Master Files Manager. Neste tipo de casos, o objectivo é o nosso Master Files Manager ser o mais transparente possível; os subscritores à nossa aplicação nunca necessitarão de comunicar directamente com o nível acima do nosso sistema. 3.2 Diagramas de Sequência Os diagramas aqui apresentados servem para demonstrar a troca de mensagens entre os diversos intervenientes do nosso projecto Notificação Figura 3.7: Diagrama de Sequência - Notificação Esta sequência de mensagens ocorrerá sempre que for necessário actualizar qualquer registo presente na base de dados da aplicação. Cada subscritor deverá enviar um aviso de recepção da mensagem de volta à aplicação. (Figura 3.7). Caso não o faça, o MFM interpretará a mensagem como não entregue e reiniciará a notificação.

31 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER Query Figura 3.8: Diagrama de Sequência - Query Sequência iniciada quando um subscritor coloca uma questão ao MFM. Caso a query efectuada seja referente a um outro MFM, a mesma query é reenviada para o MFM representante dos catálogos pretendidos. Após a resposta pretendida ser recebida, a entidade receptora deverá notificar o remetente desta recepção ou a sequência será reiniciada. (Figura 3.8) Update Esta sequência é iniciada quando algum subscritor efectua um pedido de actualização a um catálogo gerido pelo Master Files Manager. O administrador deverá rever o pedido efectuado e responder aceitando ou rejeitando o pedido.

32 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 32 Figura 3.9: Diagrama de Sequência - update

33 CAPÍTULO 3. PROJECTO MASTER FILES MANAGER 33 Caso o pedido seja aceite, a actualização será executada tendo em consideração se é ou não necessário desactivar uma entrada e criar uma nova para albergar a actualização. Após isto, será necessário notificar todos os subscritores associados ao catálogo em questão e estes subscritores deverão enviar uma notificação de recepção de volta ao nosso sistema. Caso o pedido de actualização seja recusado, apenas o consumidor requerente da alteração será notificado de tal decisão e terá que enviar uma recepção deste notificação de volta ao Master Files Manager.

34 Capítulo 4 Implementação 4.1 Ferramentas e metodologias de desenvolvimento Toda a implementação do projecto, que será descrita no presente capítulo, foi feita em Linux, usando o IDE NetBeans, e o versionamento foi feito recorrendo a Subversion. O projecto foi gerido através do GForge, uma ferramenta de gestão de projectos, com uma interface web, disponível no nosso ambiente de desenvolvimento. Toda a implementação procurou seguir uma metodologia ágil de desenvolvimento que valoriza: Individualidade e iteracções sobre processos e ferramentas; Software funcional sobre documentação; Colaboração sobre negociação; Facilidade de resposta a mudança sobre seguimento de um plano. 4.2 Arquitectura Geral O diagrama da arquitectura aqui apresentado (Figura 4.1) foi elaborado a partir dos cenários descritos no capítulo anterior e das tecnologias descritas na secção anterior. Este diagrama permite mostrar uma visão global de todo o projecto, mostrando que componentes interagem entre si, e a constituição destes mesmos componentes. 34

35 CAPÍTULO 4. IMPLEMENTAÇÃO 35 Figura 4.1: Diagrama da Arquitectura de Topo

36 CAPÍTULO 4. IMPLEMENTAÇÃO 36 Permitimos assim uma melhor noção dos requisitos de implementação de todo o projecto. Vamos, nas próximas secções, explicar em detalhe cada um dos componentes principais desta arquitectura, assim como o porquê da escolha de tais tecnologias. 4.3 Tecnologias usadas Java Java foi a linguagem de programação escolhida para o desenvolvimento do núcleo do presente projecto. O Java é uma linguagem orientada a objectos que foi desenvolvida pela Sun Microsystems e que se caracteriza essencialmente pela sua portabilidade, simplicidade e segurança. A portabilidade é conseguida através da sua máquina virtual a JVM (Java Virtual Machine), que interpreta o bytecode gerado pelo compilador. Isto permite ao Java funcionar em qualquer plataforma, desde exista uma JVM para essa palataforma. A máquina virtual de Java ajuda também na simplicidade da programação devido ao garbage collector que trata de toda a gestão de memória durante o ciclo de vida de um objecto. O vasto conjunto de bibliotecas que são distribuídos com a linguagem simplificam o processo de desenvolvimento de código. Além destas característas, o Java proporciona uma boa integração com todas as outras tecnologias presentes no projecto, daí ter sido a nossa escolha final Hibernate O Hibernate é uma framework que foi desenvolvida para a linguagem Java e serve para mapear os objectos tradicionais desta linguagem para uma base de dados relacional, como MySQL ou Oracle por exemplo. A sua característica fundamental é permitir o mapeamento de classes em Java para tabelas numa base de dados e dos tipos de dados de Java para os tipos de SQL.

37 CAPÍTULO 4. IMPLEMENTAÇÃO 37 O mapeamento de classes numa base de dados é conseguida através da configuração de ficheiros XML (extensible Markup Language) o que permite ao Hibernate gerar o código para cada classe. O esquema da base de dados pode, no entanto, ser mantido exclusivamente através dos ficheiros de configuração em XML, sem nenhuma classe Java escrita. Apesar da complexidade do programa aumentar, esta foi a opção escolhida para permitir mudar o esquema da base de dados sem criar uma outra classe Java e, por conseguinte, compilar todo o código envolvido. Esta opção será melhor descrita no capítulo 5, em que falaremos da implementação do projecto em detalhe. O Hibernate é uma parte fulcral do nosso projecto pois com esta framework conseguimos abstrair-nos completamente da base de dados relacional usada, necessitando apenas de configurar tal parâmetro num dos ficheiros de configuração ZK ZK é uma framework escrita em Java que permite a criação de uma RIA (Rich Internet Application), com o mínimo conhecimento de programação. Entre as suas principais características destacam-se: Uma especificação declarativa de alto nível, mais do que simples HTML (Hyper- Text Markup Langyage), que permite a criação de interface de utilizador. Suporte de alto-nível para Ajax Modelo de componentes baseado em eventos, um modelo de programação idêntico à programação de GUI para desktop Esta solução inclui: um motor baseado em Ajax, regido por eventos, que aumenta a interactividade existente; um conjunto de componentes XUL (XML User interface Language) e XHTML (extensible HTML) predefinidos que promovem a usabilidade; e uma markup-language baseada em XML usada para desenhar a interface com o mínimo de programação. Em termos de práticas de desenvolvimento, o ZK fomenta o uso de um modelo de arquitectura denominado por MVC (Model View Controller). Este modelo procura isolar a interface de utilizador de todos os outros aspectos do programa, resultando

38 CAPÍTULO 4. IMPLEMENTAÇÃO 38 numa aplicação em que é simples alterar tanto a aparência visual como as regras lógicas base da mesma sem se afectarem mutuamente HAPI O HAPI (HL7 Application Programming Interface) é um analisador léxico, escrito na linguagem Java, para mensagens HL7 2.x. Esta solução, completamente open-source, possui as seguintes funcionalidades: Criação e análise léxica de mensagens para ambas as codificações usadas pelo HL7 (ER7 e XML); Várias funções de transporte de mensagens; Vários meios de validação de mensagens (envio e recepção); Verificação de coerência da informação tendo por base os perfis de conformidade HL7. Apesar de esta não ser a única solução existente no mercado, encontra-se referenciada em inúmeros locais incluindo a própria organização HL7 [21]. Por tudo isto, foi esta a API escolhida para suportar a troca de mensagens entre sistemas. 4.4 Implementação Mapeamento Objecto Relacional Base de dados O primeiro passo foi configurar o Hibernate para utilizar a base de dados pretendida, com o utilizador e password correctos, configurando para isso o ficheiro XML hibernate.cfg.xml. Listagem 4.1: hibernate.cfg.xml 1 <?xml version= 1. 0 encoding= UTF 8?>

39 CAPÍTULO 4. IMPLEMENTAÇÃO 39 2 <!DOCTYPE hibernate c o n f i g u r a t i o n PUBLIC // Hibernate / Hibernate Configuration DTD 3.0//EN h t t p : // h i b e r n a t e. s o u r c e f o r g e. net / 3 hibernate c o n f i g u r a t i o n 3.0. dtd > 4 <hibernate c o n f i g u r a t i o n> 5 <s e s s i o n f a c t o r y> 6 <property name= h i b e r n a t e. d i a l e c t > org. h i b e r n a t e. d i a l e c t. MySQLDialect </ property> 7 <property name= h i b e r n a t e. connection. d r i v e r c l a s s > com. mysql. jdbc. Driver </ property> 8 <property name= h i b e r n a t e. connection. u r l > j d b c : m y s q l : // l o c a l h o s t / h b t e s t </ property> 9 <property name= h i b e r n a t e. connection. username > Username </ property> 10 <property name= h i b e r n a t e. connection. password > Password </ property> 11 <property name= hbm2ddl. auto > update </ property> 12 </ s e s s i o n f a c t o r y> 13 </ hibernate c o n f i g u r a t i o n> Da listagem 4.1, que ilustra um ficheiro de configuração funcional, explicar-se-ão alguns campos mais importantes: hibernate.dialect (linha 6) - Especifica a variante de SQL que o Hibernate gera. As opções variam desde MySQL e PostgreSQL até Oracle, Sybase e Microsoft SQL Server; hibernate.connection (linhas 7 a 10) - Configuração do driver JDBC (Java DataBase Connectivity) a utilizar:.driver class (linha 7) - A classe que contém o driver. Tem de coincidir com o tipo especificado no dialecto;.url (linha 8) - O url que indica onde se encontra a base de dados a que o Hibernat deve estabelecer uma ligação;.username e.password (linhas 9 e 10) - Nome de utilizador e palavrachave com que o Hibernate deve autenticar-se;

40 CAPÍTULO 4. IMPLEMENTAÇÃO 40 hbm2ddl.auto (linha 11) - Esta opção possibilita a importação/exportação automatica do esquema da base de dados. O valor update utilizado sinaliza que os campos devem apenas ser actualizados aquando da criação de uma sessão. Tabelas Para além da configuração necessária para definir os parâmetros que o Hibernate necessita para estabelecer uma ligação a uma base de dados, é também necessário definir a estrutura da mesma, nomeadamente as tabelas que farão parte dela. Estas entidades são definidas em ficheiros XML. Na listagem abaixo encontra-se representado um exemplo do esqueleto da tabela administrative gender, contendo os campos Code e Description Listagem 4.2: administrativegender.hbm.xml 1 <?xml version= 1. 0?> 2 <!DOCTYPE hibernate mapping PUBLIC 3 //Hibernate / Hibernate Mapping DTD//EN 4 h t t p : // h i b e r n a t e. s o u r c e f o r g e. net / hibernate mapping 3.0. dtd > 5 6 <hibernate mapping> 7 <c l a s s entity name= a d m i n i s t r a t i v e g e n d e r t a b l e= a d m i n i s t r a t i v e g e n d e r > 8 <id type= s t r i n g name= code > <g e n e r a t o r c l a s s= a s s i g n e d /> </ id> 9 <property name= d e s c r i p t i o n type= s t r i n g /> 10 </ c l a s s> 11 </ hibernate mapping> Da listagem acima, que representa uma tabela de nome Administrative Gender, com os campos Code e Description salientam-se as linhas: Linha 7 - Especifica qual o nome da entidade a criar e o nome da tabela a mapear. No projecto usou-se dom4j para este efeito, tecnologia que será explicada mais à frente. Linha 8 - Indica qual o nome e tipo da chave-primária da tabela. Neste caso, o campo chamar-se-á code e será do tipo string. O elemento generator indica qual

41 CAPÍTULO 4. IMPLEMENTAÇÃO 41 o método de criação da chave-primária. Neste caso é assigned o que significa que será introduzida manualmente; se fosse native, por exemplo, seria autoincrementada pelo Hibernate mas, no entanto, estaria limitada a tipos númericos tais como int ou float. Linha 9 - Esta propriedade apenas indica o nome e o tipo do campo a mapear. Terá de existir um elemento deste tipo por cada elemento desejado na tabela. Métodos Após a configuração do Hibernate ter sido realizada foi necessário implementar métodos sobre a API fornecida pelo Hibernate de forma a criar meios de suporte e gestão de sessões e manipulação de tabelas (criação / inserção / remoção / modificação) A configuração utilizada possibilitou o desvio da utilização tradicional de Hibernate, com POJOs (Plain Old Java Objects), passando a utilizar apenas XML. Mais especificamente a sessão usada faz uso de dom4j, uma biblioteca Java para criação e utlização de elementos XML. Neste caso, todas as tabelas são mapeadas numa árvore XML (figura 4.2) o que facilita todas as operações realizadas sobre as mesmas. Figura 4.2: Exemplo de uma tabela mapeada numa árvore XML Em seguida é apresentado um excerto de código que executa uma query à base de dados e apenas percorre toda a árvore XML: 1 // Considerando que a v a r i á v e l s e s s i o n já f o i criada usando o modo Dom4J 2 q = s e s s i o n. createquery ( from + t a b l e ) ; 3 L i s t elements = q. l i s t ( ) ; 4 5 for ( I t e r a t o r i t = elements. i t e r a t o r ( ) ; i t. hasnext ( ) ; ) 6 {

42 CAPÍTULO 4. IMPLEMENTAÇÃO 42 7 // I t e r a r sobre cada elemento 8 //A v a r i á v e l element r e p r e s e n t a a t a b e l a 9 Element element = ( Element ) i t. next ( ) ; 10 //Para cada elemento i t e r a r sobre os seus f i l h o s 11 for ( I t e r a t o r i = element. e l e m e n t I t e r a t o r ( ) ; i. hasnext ( ) ; ) 12 { 13 //A v a r i á v e l element contem o nó XML completo : 14 //<nomecampo> t e x t o </nomecampo> 15 Element element = ( Element ) i. next ( ) ; 16 S t r i n g elementtext = element. gettext ( ) ; 17 } 18 } Módulo de Comunicação A norma HL7 possui um tipo de mensagem específico para gestão de master files. As mensagens deste tipo, denominadas de Master Files Notification (MFN), comportam tanto a distribuição de alterações entre sistemas como o reconhecimento de recepção da mesma (acknowledgement). Cada mensagem MFN representa as alterações feitas a apenas um catálogo. No entanto, devido a muitos segmentos da mensagem serem repetidos, uma única mensagem pode representar vários tipos de alterações (denominados por eventos) a esse catálogo. Estes eventos não especificam, no entanto, se o sistema receptor da mensagem tem de suportar uma mudança automatizada do catálogo em questão nem se este mesmo sistema necessita de criar um catálogo da mesma forma do que é mantido no nosso sistema. De uma forma geral, a maneira como o sistema receptor processa a mensagem de notificação irá depender do desenho desse mesmo sistema. Enquanto alguns poderão optar por um procedimento completamente automatizado, outros poderão proceder a uma revisão manual de todas as alterações recebidas. Isto significa também que a transmissão de uma mensagem de acknowledgement não implica que o sistema contenha, logo após a transmissão, exactamente uma cópia da informação contida no Master Files Manager; significa no entanto que a chave primária do catálogo existente no sistema emissor coincida inequivocamente com a chave primária existente

43 CAPÍTULO 4. IMPLEMENTAÇÃO 43 no sistema receptor, no subconjunto de informação recebido por ele. Eventos A mensagem MFN pode ser utilizada para os seguintes eventos, definidos no corpo da mensagem: Mnn: Define o tipo de master file que a mensagem envia. O nn está compreendido entre: 01: Para master files não específicados (mantido para efeitos de compatibilidade). Ver apêndice B.1 para mais informação. 02: Master file referente a funcionários. 03: Para master file de serviços, testes e/ou observações (mantido para efeitos de compatibilidade. 04: Master file para descrições de actos facturáveis. 05: Master files referente a localizações : Master files de estudos clínicos : Para master file de serviços, testes e/ou observações 13: Master file geral. Ver apêndice B.2 para mais informação. 14: Master file definido no local. Ver apêndice B.3 para mais informação. 15: Master file para inventário : Reservado para master files futuros. A mensagem contém ainda eventos que especificam o tipo de alteração a executar ao master file. Estes eventos denominam-se por file-level events. Com a especificação de cada um destes eventos é necessário também mencionar qual o tipo de record-level event, que indica qual a operação exacta a efectuar. Segue-se uma breve explicação de todos estes eventos: REP: Evento que instrui o sistema a substituir a versão actual do catálogo pela versão contida na mensagem. MAD: Adiciona uma nova entrada ao catálogo

44 CAPÍTULO 4. IMPLEMENTAÇÃO 44 MDL: Elimina uma entrada existente no catálogo UPD: Evento que informa o sistema que deve alterar os catálogos como definido nos record-level events seguintes MUP: Actualiza o registo do master file MDC: Desactiva a entrada do catálogo, sem a apagar da base de dados MAC: Reactiva uma entrada previamente desactivada Em seguida é apresentada uma mensagem M14, de adição de uma nova entrada no catálogo, gerada pelo nosso programa: 1 MSH ˆ \& Master F i l e s Manager MFNˆM14ˆMFN Znn DˆT MFI a d m i n i s t r a t i v e g e n d e r ˆ a d m i n i s t r a t i v e g e n d e r ˆMFM MFM 4 REP AL 5 MFE MAD UNˆ code CE 6 ZL7 d e s c r i p t i o n ˆUnknownˆ s t r i n g code ˆUNˆ s t r i n g 2 Esta mensagem notifica uma adição ao catálogo administrative gender. A nova entrada vai ter o valor UN no campo Code e o valor Unknown no campo Description. De seguida segue uma explicação detalhada da mensagem (por segmentos): MSH - O cabeçalho da mensagem. Inclui obrigatoriamente a aplicação emissora; um identificador da mensagem; o tipo de mensagem a enviar; a data de envio da mensagem com uma precisão até aos segundos e a versão de HL7 a utilizar. Segmento único por mensagem. MFI - Segmento de identificação do master file sobre o qual ocorreram alterações. É necessário incluir o nome do master file; um identificador da aplicação emissora e o file-level event a notificar. Também é um segmento único por mensagem. MFE - Indica a entrada específica do master-file que foi alterada. Este segmento comporta, essencialmente: o record-level event a processar; um identificador único do segmento; nome e valor da chave primária do campo e tipo de dados utilizado.

45 CAPÍTULO 4. IMPLEMENTAÇÃO 45 ZL7 - Segmento-Z que descreve as alterações a efectuar. Este segmento contém o nome do campo, assim como o valor e o tipo de dados, por cada campo a modificar. Existe um MFE e um ZL7 por cada alteração a efectuar no master file. Este e outros exemplos de mensagens geradas pela nossa aplicação MFM, encontram-se no apêndice C Interface Web A interface Web desenvolvida tem como objectivo permitir ao administrador do sistema de master files gerir toda a base de dados. Com esta interface temos a possibilidade de: Gerir todos os catálogos criados (inserção, remoção e alteração de entradas); gerir os consumidores (adição, edição e remoção dos mesmos); gerir as subscrições de cada consumidor, ou seja, escolher os consumidores que cada catálogo tem de notificar e, finalmente, permite também popular catálogos através de ficheiros CSV ou XML. O ideal para ilustrar algum deste funcionamento será através dos screenshots nas páginas seguintes:

46 CAPÍTULO 4. IMPLEMENTAÇÃO 46 Figura 4.3: Ecrã de login

47 CAPÍTULO 4. IMPLEMENTAÇÃO 47 Figura 4.4: Vista dos catálogos (à esquerda); Listagem de um catálogo (ao centro); Fila de operações a executar (canto inferior esquerdo)

48 CAPÍTULO 4. IMPLEMENTAÇÃO 48 Figura 4.5: Edição de uma entrada de um catálogo

49 CAPÍTULO 4. IMPLEMENTAÇÃO 49 Figura 4.6: Vista dos consumidores

50 Capítulo 5 Conclusões Neste capítulo será feita uma crítica a todo o trabalho realizado, apreciando não só os resultados obtidos mas também alguns objectivos que ficaram por concretizar. No final será dado o que, na nossa opnião, serão os próximos passos para um possível trabalho futuro. 5.1 Objectivos Cumpridos De uma forma geral, conseguimos completar um esqueleto funcional do projecto. O objectivo principal era conseguir criar uma prova de conceito do funcionamento de um sistema de Master Files, que permitisse a notificação de alterções feitas a catálgos, e esta necessidade fulcral foi atingida. As alterações efectuadas nos catálogos são devidamente notificadas através de mensagens HL7 e existe um interface que permite efectuar estas alterações. No entanto, houve ainda alguns objectivos que ficaram por cumprir. O sistema não suporta a activação e desactivação de catálogos, nem consultas efectuadas por outros sistemas. O interface, apesar de apelativo, é muito simplista o que lhe retira a hipótese de competir visualmente com outros projectos que usam outras tecnologias como JavaFX ou Microsoft Silverlight. Das tecnologias usadas, todas elas satisfizeram as necessidades para quais foram pensadas. No entanto, é de salientar que o desenvolvimento do interface foi bastante moroso para o resultado produzido e que a ligação de todas as tecnologias usadas foi 50

51 CAPÍTULO 5. CONCLUSÕES 51 um processo bastante complexo. 5.2 Dificuldades Sentidas A maior dificuldade encontrada ao longo do projecto centrou-se sem dúvida alguma no estudo do HL7. A falta de informação sobre os próprios master files e sobre como implementar a versão 3.0 da norma definida por esta organização levou-nos a dispender muito mais tempo do que o esperado para estas tarefas. Para além disto, a inexperiência com todas as tecnologias usadas no projecto levou a que todo o código tivesse de ser reestruturado várias vezes ao longo do projecto, de forma a melhorar tanto a legibilidade como a performance do mesmo. 5.3 Trabalho Futuro Relativamente aos objectivos atingidos, ainda assim existe trabalho a fazer: optimizar a performance de algum código escrito, nomeadamente na parte da interface gráfica; corrigir algumas falhas, também a nível gráfico e, por fim, implementar todas as mensagens específicas de master files. Por implementar, com grande relevância para o projecto, ficaram as seguintes funcionalidades: A possibilidade de desactivação de catálogos; A possibilidade de receber consultas de outros sistemas; O funcionamento da nossa aplicação como cliente de outro Master Files Manager; Um sistema de autenticação que mantenha perfis de utilização por forma a gerir/consultar o MFM; Um sistema de que permita notificar tanto o administrador de pedidos de subscrição e alteração a catálogos como os subscritores de alterações efectuadas a catálogos subscritos pelos mesmos.