FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
Portabilidade de Informação Clínica no
Domínio dos Cuidados Críticos
Daniel Martins Albuquerque
Relatório de Projecto
Mestrado Integrado em Engenharia Informática
Orientador: Jorge Alves da SilvaPortabilidade de Informação Clínica no Domínio dos
Cuidados Críticos
Daniel Martins Albuquerque
Relatório de Projecto
Mestrado Integrado em Engenharia Informática
Aprovado em provas públicas pelo Júri:
Presidente:
____________________________________________________
Arguente:
Resumo
O objectivo deste projecto era permitir que um sistema de informação para cuidados críticos deixasse de funcionar como um sistema fechado, garantindo que todos os dados inseridos na base de dados clínica de uma dada entidade pudessem ser estruturados e exportados para um suporte amovível, de forma a puderem ser consultados e analisados por um clínico externo à entidade em questão.
No início deste projecto foi criado um plano de trabalho em que foram identificadas as principais tarefas a realizar e a sua duração prevista.
Começou-se pela análise do sistema de informação para cuidados críticos (funcionamento geral, estrutura da base de dados, identificação de informação relevante), levantamento do estado da arte (sistemas de informação hospitalares, ficheiros de informação médica e visualizadores de informação clínica), levantamento e descrição de requisitos e funcionalidades, especificação da arquitectura das aplicações, assim como do formato de suporte da informação e, finalmente, procedeu-se ao desenvolvimento das ferramentas e respectivos testes gerais e de integração, bem como a optimizações finais.
Foram criadas duas aplicações, um Exportador de dados que permite recolher e exportar informação presente numa base de dados clínica, e um Visualizador, capaz de apresentar no ecrã a informação presente num ficheiro gerado pela aplicação homóloga. A solução apresentada satisfaz plenamente os principais objectivos do projecto.
Abstract
The main goal of this project is to find a solution to solve the problem of a critical care information system working as a closed system, allowing that all the information inside the database of a given care provider could be structured and exported to a portable media storage to be shared and analyzed by an external practitioner.
At the beginning of this project, a work plan was created, in which the main tasks to perform as well as their duration were summarized.
The first step was to study the critical care information system (overview, database architecture, identifying relevant information), review the state of the art (concerning hospital information systems, medical file formats and clinical information viewers), gather and describe all the requirements and specific functionalities of applications, as well as the data format to be used, and finally, the development, integration, testing and fine-tuning of the applications.
Two independent applications were created, an information Exporter, capable of gathering and exporting data from a clinical database, and a Viewer, with the ability to display the information on-screen the information contained in a file generated by the homologous application. The presented solution fully accomplished the main project goals.
Índice
1 Introdução ... 1
2 Análise do Problema ... 3
2.1 Descrição ... 3
2.2 Requisitos ... 4
2.2.1 Casos de Uso do Exportador ... 4
2.2.2 Casos de Uso do Visualizador ... 7
2.2.3 Requisitos específicos ... 8
3 Revisão Bibliográfica ... 10
3.1 Estado da Arte ... 10
3.1.1 Sistemas de informação hospitalar ... 10
3.1.2 Gestores de informação médica pessoais ... 11
3.1.3 Ficheiros de informação médica ... 11
3.1.4 Visualizadores de informação médica ... 12
3.2 Tecnologias e formatos considerados ... 12
3.2.1 Exportador ... 12
3.2.2 Visualizador ... 13
3.2.3 Formato de suporte de dados ... 13
4 Arquitectura e Implementação ... 14 4.1 Processo de desenvolvimento ... 14 4.2 Visão Geral ... 15 4.3 Arquitectura Física ... 16 4.3.1 Exportador ... 16 4.3.2 Visualizador ... 17 4.4 Arquitectura Lógica ... 17
4.4.1 Divisão por namespaces... 17
4.4.2 Modelos de classes ... 18
4.5 Detalhes da implementação ... 22
4.5.1 Exportador ... 22
4.5.2 Visualizador ... 35
5 Funcionamento das aplicações ... 41
5.1 Exportador ... 41
5.1.1 Instalação ... 41
5.1.2 Configuração / Tarefas de administração ... 43
5.1.3 Utilização ... 48
5.1.4 Gestão de erros ... 55
5.2 Visualizador ... 58
5.2.1 Utilização (caso típico) ... 58
6.2 Perspectivas de trabalho futuro ... 68
Lista de Figuras
Figura 1 – Casos de Uso do Exportador ... 4
Figura 2 – Casos de Uso do Exportador, Tarefas de administração ... 6
Figura 3 – Casos de Uso do Visualizador ... 7
Figura 4 – Exemplo da estrutura de componentes ...15
Figura 5 – Arquitectura Física ...16
Figura 6 – Divisão lógica por namespaces do Exportador ...17
Figura 7 – Divisão lógica por namespaces do Visualizador ...18
Figura 8 – Vista geral da secção das forms visuais ...19
Figura 9 – Vista geral da secção dos controlos ...19
Figura 10 – Detalhe do controlo ControlReviewData ...20
Figura 11 – Esquema das classes de acesso à Base de Dados...20
Figura 12 – Modelo de classes do Visualizador ...21
Figura 13 – Classe FormMain ...22
Figura 14 – Classe ControlSearchPatient ...24
Figura 15 – Classe ControlSelectData...25
Figura 16 – Classe ControlReviewData ...26
Figura 17 – Classe ControlDestination ...27
Figura 18 – Classe FormEncounterDetails ...28
Figura 19 – Classe FormSurgeryDetails ...28
Figura 20 – Classe FormAdministrationPassword ...29
Figura 21 – Classe FormDBManagement ...29
Figura 22 – Classe FormQueriesSettings ...30
Figura 23 – Classes de acesso à Base de Dados ...31
Figura 24 – Classe DataStructure ...32
Figura 25 – Classe BurningManager ...32
Figura 26 – Classe EncryptionManager ...33
Figura 27 – Classe Misc ...33
Figura 28 – Classe RichTextBoxPrintCtrl ...34
Figura 29 – Classe FormMain ...35
Figura 30 – Classe ControlLoadFile ...36
Figura 31 – Classe ControlLeftMenu ...36
Figura 32 – Classe ControlClinicalInformation ...37
Figura 33 – Classe ControlEncounterDetails ...38
Figura 34 – Classe DataStructure ...39
Figura 35 – Classe FileLoadingManager ...40
Figura 36 – Classe EncryptionManager ...40
Figura 37 – Selecção do directório de instalação ...42
Figura 38 – Instalação em progresso ...42
Figura 39 – Atalho para a aplicação no Menu Iniciar ...43
Figura 40 – Activação do modo de administração ...44
Figura 42 – Política de palavras-chave ... 46
Figura 43 – Configuração de consultas à Base de Dados ... 47
Figura 45 – Pesquisar doente ... 49
Figura 46 – Seleccionar dados a exportar ... 50
Figura 47 – Rever dados ... 51
Figura 48 – Detalhes de um encontro ... 52
Figura 49 – Detalhes de uma cirurgia ... 52
Figura 50 – Definir palavra-chave e destino ... 53
Figura 51 – Menu de impressão ... 54
Figura 52 – Erro de conectividade ... 55
Figura 53 – Teste de conectividade ... 56
Figura 54 – Erro de insuficiência de dados ... 57
Figura 55 – Fluxo de utilização do Visualizador ... 58
Figura 56 – Abertura do ficheiro de dados ... 59
Figura 57 – inserção da palavra-chave para a decifração ... 60
Figura 58 – Abertura de um ficheiro de dados via menu ... 61
Figura 59 – Seleccionar informação a consultar ... 62
Figura 60 – Consulta de informação clínica ... 63
Figura 61 – Visualização dos detalhes de um encontro ... 64
Figura 62 – Visualização dos detalhes com dados de monitorização ... 65
Figura 63 – Estatísticas de um parâmetro de monitorização ... 66
Abreviaturas e Símbolos
IDE Ambiente de desenvolvimento integrado COM Component Object Model
ODP.NET Oracle Data Provider for .NET Framework SGBD Sistema de Gestão de Base de Dados ODBC Open Database Connectivity
OLE DB Object Linking and Embedding, Database CDA Clinical Document Architecture
CCR Continuity of Care Record IMAPI Image Mastering API
1 Introdução
O aumento da esperança média de vida, o elevado número de actos médicos, a cada vez maior exigência dos cidadãos e a necessidade de reduzir custos são alguns dos factores que acrescem à necessidade de melhorar os sistemas de saúde, tornando-os mais eficientes na prestação de cuidados e contribuindo para a evolução e crescimento da organização que os gere.
Neste contexto, a Siemens Healthcare surge como parceiro tecnológico das organizações de saúde, criando condições para atingir uma elevada qualidade na prestação de cuidados.
É neste âmbito que surge associado à cadeira de Projecto do Mestrado Integrado em Engenharia Informática e Computação da Faculdade de Engenharia da Universidade do Porto, o projecto Clinical Information Portability (CIP).
O principal objectivo deste projecto é dotar as organizações de saúde de uma ferramenta que possibilite a exportação de informação de uma base de dados clínicos e consequente consulta da mesma por um médico externo a essa entidade. Grande parte da informação clínica é ainda hoje inacessível por se encontrar em sistemas fechados. A solução a desenvolver pretende colmatar esta falha ao permitir a partilha de informação e consequentemente a criação de valor no serviço oferecido pelo prestador de cuidados de saúde.
Este relatório vai cobrir todas as etapas do desenvolvimento da solução CIP, descrevendo primeiramente o problema, passando pelo levantamento de requisitos, pelo estudo do estado da arte de soluções de portabilidade de ficheiros clínicos (sistemas de gestão de informação clínica, formatos de suporte a dados clínicos e visualizadores de informação clínica), e em seguida pela definição da arquitectura do sistema e implementação. No final apresentar-se-á o funcionamento das aplicações desenvolvidas, far-se-á uma conclusão e análise crítica da solução desenvolvida e serão dadas sugestões para futuros melhoramentos
2 Análise do Problema
2.1 Descrição
A Siemens Portugal comercializa uma aplicação de automatização nos cuidados perioperiativos (cuidados prestados antes, durante e depois de uma intervenção cirúrgica), o sistema Picis. Esta solução é desenvolvida pela Picis Inc. e está presente nos blocos operatórios de vários hospitais portugueses sendo utilizada para monitorizar intervenções cirúrgicas. Permite o registo de vários parâmetros em tempo real, tais como o batimento cardíaco, frequência respiratória, entre outros, assim como a consulta de vários tipos de informações pessoal, demográfica e clínica sobre o paciente que está a ser submetido a uma cirurgia.
Uma das lacunas deste sistema é a impossibilidade de exportar informação da sua base de dados para um suporte informático, impedindo assim a partilha de informação com um clínico de outra organização de saúde.
A solução a desenvolver pretende resolver este problema e consiste em duas aplicações, um Exportador, capaz de recolher informação da base de dados do Picis e guardá-la num ficheiro de dados e um Visualizador, que permita a leitura e interpretação da informação contida no ficheiro de dados gerado pelo Exportador e a apresente de forma simples e clara. Esta informação consiste nos seguintes dados:
- Dados pessoais e demográficos do doente
- Informação clínica (alergias, alergias a medicamentos, precauções, historial de reacções alérgicas e historial de intervenções cirúrgicas)
- Informação relativa a passagens do doente pelo centro hospitalar (consulta hospitalar, episódio de urgência, intervenção cirúrgica, etc.).
2.2 Requisitos
Através da interacção com a equipa de Service do Picis foi elaborada uma listagem de casos de uso e funcionalidades que a solução a desenvolver deveria suportar.
De seguida são apresentados os casos de uso recolhidos, divididos por aplicação (Exportador de informação clínica e Visualizador) e tipo de utilização.
2.2.1 Casos de Uso do Exportador
Tarefas do utilizador
Figura 1 – Casos de Uso do Exportador
Alterar idioma
Deve ser possível, em qualquer etapa do processo de exportação, alterar o idioma utilizado nas interfaces da aplicação.
Todas as palavras/expressões utilizadas devem ser guardadas num ficheiro externo à aplicação (externo ao código-fonte e consequentemente ao ficheiro binário) e num formato que permita a sua edição de modo a corrigir possíveis gralhas e a facilitar a adição de novos idiomas.
Pesquisar doente
A aplicação deve, ao ser iniciada, apresentar um ecrã onde seja possível pesquisar um doente através de informação que o identifique, seja o seu nome, data de nascimento ou número mecanográfico (código do doente no hospital).
Na eventualidade da pesquisa retornar múltiplos doentes, devem ser apresentadas todas as correspondências numa lista, da qual, o utilizador deve seleccionar apenas um para prosseguir.
Seleccionar dados a exportar
Após a selecção do doente, deve ser apresentado um ecrã onde o utilizador do sistema possa seleccionar que campos pretende que sejam exportados. Estes devem estar agrupados por “Dados demográficos”, “Informação Clínica”, e “Encontros” que representam os acontecimentos registados acerca de cada doente no hospital (por exemplo uma consulta médica ou uma intervenção cirúrgica).
Rever dados a exportar
É importante que os dados a exportar (previamente seleccionados) possam ser revistos pelo utilizador de maneira a confirmar a sua conformidade.
Cifrar ficheiro
É essencial que a aplicação ofereça a opção de cifrar os ficheiros de dados produzidos, de modo a garantir a privacidade e segurança da informação pessoal e/ou clínica exportada.
Gerar palavra-chave aleatória
A aplicação deve também oferecer a possibilidade de, a pedido do utilizador, gerar uma palavra-chave aleatória para a cifração do ficheiro de dados a exportar, de modo a garantir a privacidade e segurança da informação.
Guardar ficheiro de dados num directório à escolha
Na última etapa do processo de exportação, o utilizador deve ter a possibilidade de guardar o ficheiro de dados exportados num directório à sua escolha.
Gravar ficheiro de dados num CD
O utilizador deve também ter a opção de, alternativamente ao ponto anterior, gravar o ficheiro de dados num CD de dados.
Imprimir palavra-chave utilizada na cifração
Terminado o processo de exportação e no caso do utilizador ter escolhido cifrar o ficheiro de dados, a aplicação deve permitir a impressão de uma folha com a palavra-chave utilizada para a cifração.
Tarefas de administração
Figura 2 – Casos de Uso do Exportador, Tarefas de administração
As tarefas ilustradas na figura 2 referem-se à utilização da aplicação em modo de administração ou de privilégios elevados. Este modo deve poder ser activado a qualquer altura e deve estar dependente da correcta inserção de uma palavra-chave de administração.
Alterar parâmetros de acesso à base de dados
Podendo as instalações do sistema Picis utilizar Oracle ou SQL Server, o administrador deve ter a opção de seleccionar qual o Sistema de Gestão de Bases de Dados (SGBD) a utilizar, assim como poder definir qualquer parâmetro necessário para a ligação (tais como utilizador, palavra-chave, servidor, protocolo, porto).
Alterar política de palavras-chave (cifração do ficheiro)
É absolutamente necessário que o administrador tenha a possibilidade de forçar, desactivar ou tornar opcional a cifração dos dados exportados por parte dos utilizadores da aplicação.
Configurar consultas feitas à base de dados
As configurações utilizadas nas tabelas do sistema Picis não são iguais e vão variar de instalação para instalação. Isto prende-se com dependências que o Picis possa ter de sistemas externos (sistemas de informação hospitalar, sistemas de arquivo de imagens clínicas, etc.) assim como com o tipo de aparelhos de monitorização presentes no bloco operatório e dos parâmetros que estes registam.
O administrador deverá ter a possibilidade de indicar que colunas utilizar nos parâmetros em tempo real registados pelo Picis e de associar uma descrição a cada um (exemplo: batimento cardíaco, pressão arterial, etc.)
Activar/desactivar estilos visuais
De forma a tornar mais agradável a utilização da aplicação, o administrador deve ter a opção de activar a utilização dos estilos visuais utilizados pelo Microsoft Windows XP para melhorar a aparência e estética das interfaces.
2.2.2 Casos de Uso do Visualizador
Tarefas do Utilizador
Figura 3 – Casos de Uso do Visualizador
Abrir um ficheiro a partir da barra de menus
Deve existir na barra de menus no topo da aplicação, um botão que permita a abertura dos ficheiros de dados gerados pela aplicação de exportação.
Abrir um ficheiro através do método drag and drop
Em alternativa ao ponto 1, os ficheiros de dados podem ser abertos pelo Visualizador, simplesmente utilizando o método de arrastar e largar (drag and drop). Esta funcionalidade deve estar disponível ao iniciar a aplicação e deve existir um pequeno texto no arranque a informar o utilizador deste método.
Inserir palavra-chave utilizada na cifração
No caso do ficheiro a abrir se encontrar cifrado, a aplicação deve apresentar um ecrã onde é pedido ao utilizador que insira a palavra-chave a utilizar para decifrá-lo.
Visualizar informação clínica
A informação contida no ficheiro de dados deve estar organizada por secções (descritas anteriormente nos Casos de Uso do Exportador). Deve existir um botão que permita ao utilizador visualizar detalhes sobre a informação clínica, devendo estes dados estar agrupados por “Alergias”, “Alergias a medicamentos”, “Precauções” e “Historial cirúrgico”.
Visualizar detalhes de um encontro
Deve também existir um outro botão que apresente os detalhes relativos a um encontro. Neste ecrã deve ser apresentada a informação geral sobre o encontro (detalhes, medicação actual do doente, histórico de procedimentos cirúrgicos e diagnósticos) e caso o encontro seja referente a uma intervenção cirúrgica, a listagem de eventos registados durante a intervenção, o gráfico com os parâmetros de monitorização dos sinais vitais.
Visualizar detalhes dos parâmetros monitorizados em cada encontro
A aplicação deve apresentar, a pedido do utilizador, detalhes estatísticos sobre cada parâmetro seleccionado (no caso de no encontro em causa ter sido registada informação relativa à monitorização de sinais vitais do doente).
Estes devem incluir os valores máximos e mínimos registados e o momento em que ocorreram.
Alterar janela de visualização dos gráficos de monitorização
No caso de existir informação relativa à monitorização de sinais vitais do doente, deverá haver possibilidade de alterar a janela temporal da visualização dos gráficos destes parâmetros.
2.2.3 Requisitos específicos
Funcionalidade
A aplicação de exportação deve permitir o acesso aos menus de administração apenas após a inserção de uma palavra-chave que active o modo de privilégios elevados (modo de administração).
Usabilidade
Ambas as aplicações devem seguir as normais da Siemens no que toca ao seu design e estética, nomeadamente a nível dos tipos de letra, cores, disposição de componentes (imagens, caixas de texto, etc.).
Performance
Prevendo-se um nível elevado de acessos à base de dados, a rapidez de execução das consultas deve ser tida em atenção aquando da escolha do driver de acesso à base de dados
Suportabilidade
Para garantir a continuidade e futuras alterações às aplicações, a escrita do código fonte deverá obedecer a normas internas da Siemens.
Deste modo recomenda-se que todo o código seja escrito na língua inglesa (nome de parâmetros, métodos, comentários, etc.).
Devem ainda ser utilizados namespaces e regiões para agrupar classes e excertos de código correlacionados.
3 Revisão Bibliográfica
3.1 Estado da Arte
A partilha de informação entre entidades diferentes é de grande valor para os prestadores de cuidados médicos. Para permitir que estas transacções se processem eficazmente, deve ser utilizado um standard ou um formato aberto. Neste capítulo vai ser apresentado o estado da arte nos sistemas de informação hospitalar, gestores de informação médica, ficheiros de informação médica e visualizadores existentes actualmente.
3.1.1 Sistemas de informação hospitalar
Os Sistemas de Informação Hospitalar (Hospital Information System - HIS) são utilizados para suportar as necessidades clínicas, financeiras e administrativas. Normalmente são compostos por um Sistema de Gestão Hospitalar que se ocupa dos aspectos administrativos e financeiros e de componentes clínicos específicos que se focam no paciente e se ocupam da informação clínica (ex: Sistemas de Informação de Radiologia, etc.).
Apresentam-se a seguir alguns exemplos desse tipo.
Picis CareSuite
O CareSuite [10] é um conjunto de produtos da Picis. Unificam as funções clínicas e administrativas em ambientes perioperativos numa única solução. Apesar de garantir total compatibilidade entre os seus sub-componentes, como corre numa base de dados com uma arquitectura específica, requer um maior esforço e cuidado na partilha de informação com sistemas concorrentes.
Meditech HCIS/MPM
A Meditech [8] oferece vários subprodutos como parte integrante do seu produto principal, Health Care Information System (HCIS). À semelhança do Picis, este componentes são modulares, permitindo ao cliente escolher apenas os que necessita, por exemplo: gestão de bloco operatório, gestão de recursos humanos, etc.
Para além do HCIS, a Meditech disponibiliza o Medical Practice Management (MPM) [9] que combina a gestão de marcações, gestão do registo de ambulatório, etc.
Estas soluções são frequentemente integradas com software da Picis.
Siemens Soarian/”syngo”
O sistema Soarian [7] foi desenhado para reduzir o peso das tarefas administrativas e melhorar o real cuidado ao paciente.
Tais como os anteriores, também o Soarian está dividido em vários componentes, Soarian Scheduling, Clinicals, Cardiology, etc. que suportam diferentes tarefas e processos.
Paralelamente ao Soarian, existe outro sistema, o “syngo” [6], que pretende ser um sistema de informação de radiologia e com maior foco nos processos de diagnóstico, em oposição à vertente mais administrativa do Soarian.
Antes de uma consulta de radiologia, o Soarian fornece todas as informações relativas a um paciente ao “syngo” e no final recebe as imagens, relatórios e anotações geradas durante a consulta.
A interoperabilidade com sistemas externos é, contudo, bastante complexa.
A maioria destes sistemas não permite a exportação de informação clínica num formato electrónico (o CareSuite permite a impressão do resumo de uma intervenção cirúrgica numa impressora local), e o facto de usarem diferentes arquitecturas nas suas bases de dados acrescenta enorme dificuldade e complexidade à tarefa de criar um Exportador externo que suprima esta lacuna.
3.1.2 Gestores de informação médica pessoais
Um gestor de Informação Médica Pessoal (Personal Heatlth Record - PHR) é utilizado por uma pessoa para manter e organizar os seus registos médicos. Eram normalmente mantidos em papel, mas nos últimos anos, têm aparecido soluções PC e web-based que facilitam a actualização e partilha dos dados.
O facto de, cada vez mais, se utilizar um formato electrónico facilita a rápida e eficaz partilha de informação entre pessoal clínico ou entre um paciente e o seu médico.
3.1.3 Ficheiros de informação médica
Existem, de momento, duas grandes especificações de ficheiros de informação médica. A Clinical Document Architecture (CDA) da organização HL7, e o Continuity of Care Record (CCR) da ASTM International [1][2][3].
Continuity of Care Record
O CCR [4] foi criado pela ASTM International com base em experiências e percepções próprias.
O documento pretende agregar todo o historial clínico de uma pessoa assim como dados relativos a planos de saúde, elementos financeiros, e outros. O CCR não permite no entanto campos definidos pelo utilizador, sendo portanto bastante inflexível.
É baseado em XML e combina objectos discretos, permitindo filtrar/organizar a informação num Visualizador. O CCR faz uso de códigos e terminologia controlada como LOINC, SNOMED CT, ICD, etc.
Clinical Document Architecture
O CDA [5][11] foi criado pela HL7 para integrar e complementar as mensagens HL7. Ao contrário do CCR, cada instância representa um determinado tipo de documento médico, apesar de não especificar que secções devem aparecer em cada documento, i.e., não obriga a, por exemplo, que o documento “Historial Físico” contenha a secção “Factores de Risco”.
É baseado em XML e faz uso de identificadores ISO (OIDs) e codificação e terminologia padrão (LOINC, SNOMED CT, etc.).
Graças ao seu desenho incremental, permite definir que nível de implementação será usado, que varia desde o 1 (mais básico) em que o corpo é texto livre (texto não estruturado), até ao 2 ou 3 (mais complexos) em que todas as secções utilizam vocabulário controlado.
3.1.4 Visualizadores de informação médica
Há dois grandes tipos de visualizadores de informação médica, os que retornam informação contida numa base de dados e os que apresentam os dados contidos num ficheiro.
Os primeiros pesquisam uma base de dados e apresentam a informação recolhida via uma aplicação ou página Web.
Os segundos podem ser um de dois tipos: se o ficheiro de informação médica for um documento XML, este pode vir associado a um XSLT, permitindo assim a sua abertura utilizando qualquer browser recente, caso contrário, a utilização de uma aplicação (externa ou parte integrante de um HIS/PHR) é necessária.
3.2 Tecnologias e formatos considerados
3.2.1 Exportador
Pretende-se que a utilização da ferramenta de exportação seja possível nos computadores usados pelos utilizadores do sistema Picis. Estes computadores correm a plataforma Microsoft Windows XP e têm instalada a versão 1.1 da plataforma .NET. Esta configuração de software não pode ser alterada nomeadamente no que diz respeito à instalação/actualização de máquinas virtuais.
Linguagens de desenvolvimento / IDEs
Tendo em conta as limitações de software anteriormente descritas, optou-se por utilizar a linguagem C# sobre a plataforma .NET.
É uma linguagem moderna com uma performance bastante razoável, sendo que a similaridade com C++ e Java também teve um grande peso na escolha.
Como IDE, foi utilizado o Microsoft Visual Studio 2003, que suporta a versão 1.1 da framework .NET e permite o desenvolvimento rápido de aplicações gráficas com a utilização de Windows Forms.
Métodos de acesso à base de dados
Dada a quantidade e volume de dados de cada query SQL, foi considerado como crítico o desempenho da aplicação de exportação de dados no que concerne à rapidez destas consultas. Assim, foram analisados vários métodos de acesso à base de dados: OLE DB, ODBC, ODP.NET [14] (apenas para bases de dados Oracle) e os Data Providers da Microsoft para a framework .NET [12] [13].
Destes métodos destacam-se o ODP.NET e os Data Providers da Microsoft para .NET por evitarem o uso das interfaces COM e implementarem optimizações específicas para cada SGBD. No entanto, o ODP.NET da Oracle requer a instalação dos componentes de acesso a dados da Oracle e foi, portanto, excluído da comparação devido a limitações impostas na instalação de software nas máquinas do sistema Picis.
3.2.2 Visualizador
No desenvolvimento da aplicação de visualização de dados optou-se pela linguagem C# para uma melhor integração entre as duas aplicações e reaproveitamento de código utilizado no Exportador.
O código foi no entanto compilado para a versão 2.0 da framework .NET que de momento vem pré-instalada na última versão do Windows (Vista) e está disponível para versões anteriores na lista de actualizações do sistema operativo e como download gratuito na página da Microsoft.
3.2.3 Formato de suporte de dados
Após o levantamento do estado da arte, e tendo em conta as especificidades de cada opção estudada no que concerne a Ficheiros de Informação Médica, foi decidida a utilização do Clinical Document Architecture (CDA) como formato de suporte aos dados a serem exportados. Segundo o enumerado na secção 3.1.2, pode-se concluir que o CDA baseia-se numa estrutura menos rígida que o CCR e garante uma maior flexibilidade na sua adaptação aos dados clínicos de cuidados críticos que se pretende guardar.
A sua maior vantagem prende-se com a possibilidade de poder ser utilizado um corpo com texto não estruturado no nível de implementação mais baixo, deixando em aberto a possibilidade de evoluir para um nível cuja estrutura do corpo seja mais complexa no futuro.
4 Arquitectura e Implementação
4.1 Processo de desenvolvimento
Na gestão deste projecto foi utilizada a metodologia Scrum, um método ágil de desenvolvimento de software.
Apesar deste projecto ter sido realizado individualmente, houve bastante interacção com os interessados na solução (colaboradores Siemens do grupo de Software Engineering e com a equipa responsável pelo sistema Picis) durante a fase inicial de levantamento de requisitos e através de todo o feedback recolhido durante todo o trabalho.
Foi criado um backlog para o produto com o conjunto de requisitos a cumprir. Aproximadamente a cada 30 dias era realizada uma reunião (bastante informal) onde o trabalho realizado até ao momento era reavaliado e onde se escolhidam as tarefas a realizar durante a próxima iteração (sprint). No final de cada sprint era entregue uma nova versão da aplicação com um novo conjunto de funcionalidades.
Existiam ainda sub-ciclos diários em que era revisto o trabalho realizado no dia anterior, analisados problemas encontrados, e planeado o trabalho do dia em causa.
A utilização deste método potenciou e incentivou o feedback e reacções de todos os envolvidos no projecto de forma a garantir a consistência e eliminar possíveis ambiguidades nos requisitos ou funcionalidades recolhidas. Desta forma garantia-se que a solução que estava em desenvolvimento correspondia, na sua totalidade, ao que fora solicitado.
4.2 Visão Geral
Ambas as aplicações (Exportador e Visualizador) são constituídas por uma form visual principal em que são utilizados controlos visuais (User Controls) para cada estado ou etapa em que se encontra.
Cada um dos controlos criados representa uma etapa do processo de exportação, ou um estado do Visualizador. Temos assim um controlo para a pesquisa de doentes, outro para a selecção de dados a exportar, etc.
Deste modo, consegue-se uma arquitectura modular que permite a reutilização destes componentes e que facilita a introdução de alterações às aplicações, no caso de se pretender adicionar novas funcionalidades.
A figura 4 contém uma representação de um caso exemplo. Existem 3 controlos, em que um deles é partilhado por duas forms.
Figura 4 – Exemplo da estrutura de componentes
É importante referir que a aplicação de exportação de dados foi criada numa linguagem neutra, isto é, o texto de todos os componentes (botões, menus, caixas de texto, etc.) não se encontra nos binários compilados mas sim em ficheiros anexos (.DLL), gerados a partir de ficheiros .XML (pelo Visual Studio 2003).
Desta forma, para adicionar, à aplicação, o suporte a um novo idioma, o programador é dispensado de rescrever todo o código.
4.3 Arquitectura Física
4.3.1 Exportador
De acordo com os requisitos elaborados, a aplicação de exportação é possível em todas as máquinas que utilizam o CareSuite da Picis. No entanto, a sua instalação pode ser alargada a qualquer máquina com a versão 1.1 da framework .NET da Microsoft e com acesso de rede à base de dados do sistema Picis.
Na eventualidade destes computadores terem acesso a uma impressora, a mesma pode ser utilizada para imprimir a palavra-chave usada na cifração no final de cada exportação.
A figura 5 contém o esquema representativo da arquitectura física.
4.3.2 Visualizador
No caso do Visualizador, qualquer computador (desde que possua a versão 2.0 da framework .NET) pode ser utilizado.
Note-se que devido ao ficheiro de dados poder ser enviado por correio electrónico, ou guardado numa disquete, CD ou noutro formato amovível, o computador de destino terá que possuir o hardware necessário para conseguir abri-lo.
4.4 Arquitectura Lógica
4.4.1 Divisão por namespaces
Exportador
Para a divisão lógica foram utilizados namespaces, isto é, divisores abstractos criados para tornar o sistema mais modular. Para o Exportador, as classes foram agrupadas segundo o esquema representado na figura 6.
Figura 6 – Divisão lógica por namespaces do Exportador
Visualizador
Figura 7 – Divisão lógica por namespaces do Visualizador
4.4.2 Modelos de classes
Exportador
Para uma maior facilidade de leitura o esquema dos modelos de classes encontra-se repartido por secções mais pequenas.
No esquema seguinte podemos observar as relações existentes entre a form principal (FormMain) e as restantes forms e controlos visuais.
A classe FormMain é uma form visual e responsável pela janela principal do programa. Durante a sua execução, esta classe vai utilizar os controlos representados à direita para cada uma das etapas do processo de exportação (seleccionar paciente, seleccionar dados a exportar, etc, conforme descrito no capítulo que sobre o funcionamento da aplicação). Do lado esquerdo encontram-se representadas forms visuais secundárias responsáveis por tarefas de apoio (configuração das consultas, activação do modo de administração, etc.).
No diagrama pode também observar-se a relação da classe FormDBManagement com o namespace DatabaseTools, que contém as classes para acesso a bases de dados Oracle e SQL Server.
Os detalhes das classes mais relevantes (atributos e métodos importantes) são analisados em maior pormenor no próximo capítulo.
Figura 8 – Vista geral da secção das forms visuais
A Figura 9 representa o modelo de classes referente aos controlos criados.
Como pode ser observado, existe uma relação de todos com o namespace DataTools, que contém a classe que representa a estrutura de dados onde são guardados os dados da exportação.
Os 3 primeiros controlos têm ainda uma ligação ao namespace DatabaseTools que contém as classes para acesso a diferentes bases de dados
O último controlo (ControlDestination) está relacionado com vários namespaces. Em PrintingTools encontram-se as classes de apoio à impressão de documentos, em BurningTools classes para a gravação de dados num CD, em EncryptionTools as classes utilizadas na cifração de ficheiros e em Misc encontram-se métodos de apoio.
Figura 9 – Vista geral da secção dos controlos
O controlo ControlReviewData, utilizado na etapa de revisão dos dados exportados da base de dados Picis, tem ainda uma relação com a form visual FormEncounterDetails e com a form
FormSurgeryDetails, utilizadas para apresentar uma janela com os detalhes de um encontro e com os detalhes de uma intervenção cirúrgica, respectivamente.
Figura 10 – Detalhe do controlo ControlReviewData
A figura 10 esquematiza a relação entre as classes utilizadas no acesso às diferentes bases de dados Picis.
De forma a permitir o acesso a diferentes bases de dados, foi criada uma classe DBManager da qual derivam duas classes filhas, uma para cada SGBD.
De forma a melhorar a transparência, foi ainda criada uma interface IGenericDBManager, a qual contém os métodos que as classes acima implementam, e permite assim a utilização desta classe no código, independentemente do sistema de gestão de bases de dados em uso.
Estas classes encontram-se detalhadas em maior pormenor no próximo capítulo.
Visualizador
O modelo de classes da aplicação de visualização de dados é ilustrado na figura 12.
A classe FormMain é responsável pela janela principal da aplicação. Está relacionada com o namespace DataTools que contém a classe que representa a estrutura de dados para onde é carregada toda a informação contida num ficheiro de dados.
O controlo ControlLoadFile é utilizado para carregar um ficheiro de dados (as classes necessárias para a abertura e carregamento de um ficheiro, assim como a estrutura de dados para onde esta informação é armazenada estão dentro do namespace DataTools) e, caso seja necessário, decifrá-lo com a palavra-chave inserida pelo utilizador (as classes utilizadas na decifração localizam-se no namespace EncryptionTools).
O controlo ControlLeftMenu é responsável por apresentar e permitir a consulta da informação disponível ao utilizador da aplicação. Esta informação consiste no nome do paciente, nos seus dados demográficos, informação clínica e informação sobre os encontros registados.
No controlo ControlClinicalInformation estão presentes as groupboxes que contém a listagem das alergias, alergias a medicamentos, precauções e histórico cirúrgico.
Finalmente, o controlo ControlEncounterDetails inclui toda a informação relativa a um encontro, incluindo, se a informação se encontrar disponível, gráficos de monitorização dos sinais vitais.
4.5 Detalhes da implementação
Nesta secção apresentam-se as variáveis e métodos mais relevantes de cada classe. Para uma análise mais pormenorizada deve ser consultado o código-fonte de cada aplicação e comentários das respectivas classes.
4.5.1 Exportador
FormMain
A classe FormMain, representada na figura 14, é a classe principal do Exportador e representa a form visual de entrada da aplicação.
Tem como variáveis uma estrutura de dados (dataStructure) onde é guardada toda a informação relativa a uma exportação, um inteiro (currentStep) que indica a etapa actual do processo de exportação onde o utilizador se encontra, e 2 variáveis utilizadas para a gestão do idioma utilizado na aplicação (conforme descrito em “Visão Geral” do capítulo referente à Arquitectura).
FormMain - Método construtor da classe que inicializa os componentes da form.
AdjustCheckedMenuItems - Actualiza o estado dos itens no menu superior (idioma
seleccionado, política de palavras-chave em vigor, etc.)
AdjustCulture - Método responsável pela alteração do texto dos componentes aquando da
escolha de um novo idioma.
Add…Control - Métodos responsáveis por criar e expor os controlos em cada etapa do
processo de exportação.
controlSearchPatient_ContinueEvent - Evento despoletado pelo controlo ControlSearchPatient e que garante que o utilizador só pode avançar para a próxima etapa do processo após ter seleccionado um doente da lista de resultados.
controlSelectData_ContinueEvent - Evento despoletado pelo controlo ControlSelectData
para garantir que o utilizador só avança para a próxima etapa se tiver seleccionado pelo menos um campo de dados para exportar.
ControlSearchPatient
A classe ControlSearchPatient é um controlo utilizado pela classe FormMain que gere as pesquisas de pacientes efectuadas pelo utilizador.
Figura 14 – Classe ControlSearchPatient
Destacam-se os métodos:
BuildQueryMessage - Retorna a query SQL a executar tendo em conta os dados inseridos
na pesquisa (nome do doente, data de nascimento, etc.).
ValidateNotNullParameters - Verifica se existem parâmetros para efectuar a pesquisa.
Caso isto não se verifique apresenta uma mensagem de erro no ecrã (ver capítulo 5.1).
buttonSearchClick - Event handler despoletado com o clique no botão de pesquisar. É
ControlSelectData
O controlo ControlSelectData é responsável por gerir a selecção de dados a exportar.
Figura 15 – Classe ControlSelectData
Realçam-se os seguintes métodos:
FetchEncounters - Recorre à base de dados para recolher os encontros associados ao
paciente escolhido na etapa anterior, para que os mesmos sejam listados e o utilizador consiga assim seleccionar quais quer exportar.
ShowEncounterDetails - Este método cria uma nova form visual onde é apresentado um
resumo de um detalhe, previamente seleccionado. Desta forma, é permitido ao utilizador consultar mais detalhadamente dados de cada encontro, antes de os seleccionar para exportação.
ControlReviewData
A classe ControlReviewData é responsável por recolher a informação da base de dados Picis, e apresentá-la para revisão ao utilizador do programa.
À semelhança de todas as classes em que ocorrem transacções com a base de dados, existe um objecto (reader) do tipo IDataReader, que oferece um meio de ler de um stream resultante da execução de um comando numa base de dados relacional.
É ainda criado outro objecto, IGenericDBManager, que vai ser utilizado no cast, ou conversão de um objecto do tipo OracleDBManager ou SQLServerDBManager para evitar a utilização constante de verificações sobre qual o sistema de gestão de base de dados em uso.
Figura 16 – Classe ControlReviewData
Destacam-se os métodos:
Connect / Disconnect - Responsáveis por iniciarem e terminarem a conexão à base de
dados Picis.
Fetch... - Métodos utilizados para recolher todos os tipos de informação da base de dados.
ControlDestination
Esta classe gere a última etapa do processo de exportação.
Aqui, é permitido ao utilizador definir uma palavra-chave para cifrar o ficheiro e seleccionar o seu destino final.
Destacam-se entre as variáveis a richTextBoxPrintCtrl [15], um controlo criado a partir da classe RichTextBox que é utilizado na impressão da palavra-chave inserida numa impressora à qual o computador tenha acesso.
Figura 17 – Classe ControlDestination
Métodos importantes a referir são:
GeneratePassword - Gera uma palavra-chave aleatória para ser utilizada para cifrar o
ficheiro de dados.
UpdateCDBurningAvailability - Actualiza o estado (disponível ou não disponível) do
botão que permite a gravação dos dados num CD, dependendo da detecção de uma unidade que permita gravar CDs.
CreateCDAFile - Método responsável pela criação do ficheiro XML de dados.
UpdatePasswordStrength - Método utilizado para avaliar a força da palavra-chave
FormEncounterDetails
Nesta form visual é resumida a informação mais relevante sobre um encontro. Foi criada para apoiar o processo de exportação de dados permitindo ao utilizador rever a informação antes de a exportar.
Figura 18 – Classe FormEncounterDetails
O método mais relevante desta classe é o DrawRealTimeData, responsável pelo desenho dos gráficos dos parâmetros de monitorização (gráficos dos sinais vitais) registados durante o encontro em questão.
FormSurgeryDetails
Esta classe é, como a anterior, utilizada para apoio à revisão de dados. A mesma representa uma janela onde é apresentada informação relativa a uma intervenção cirúrgica seleccionada pelo utilizador a partir do histórico cirúrgico.
FormAdministrationPassword
Esta classe permite a activação do modo de administração. Consiste numa janela onde é pedido ao utilizador que insira a palavra-chave de administrador. É calculado o hash da palavra inserida, utilizando o algoritmo MD5, e comparado com o hash guardado no registo, e caso os valores coincidam, o modo de privilégios elevados é activado.
Figura 20 – Classe FormAdministrationPassword
FormDBManagement
A FormDBManagement providencia um meio rápido e simples de configurar na aplicação os parâmetros para a ligação à base de dados em uso. Aqui, o administrador pode definir o nome de utilizador, palavra-chave, servidor, SGDB, e todos os restantes parâmetros necessários para estabelecer uma conexão à base de dados Picis.
Figura 21 – Classe FormDBManagement
É de salientar o método SetConnectionResult que permite, após o preenchimento de todos os parâmetros, testar a conexão à base de dados.
FormQueriesSettings
Na classe FormQueriesSettings podem ser definidas as especificidades da base de dados Picis a ser usada, conforme previsto nos requisitos levantados inicialmente (Configurar consultas feitas à Base de Dados).
Figura 22 – Classe FormQueriesSettings
Classes de acesso à base de dados
Para tornar transparentes as consultas à base de dados em todo o código, foi criada uma classe DBManager onde são guardados todos os parâmetros necessários para estabelecer uma conexão a qualquer base de dados Picis, os quais podem ser alterados pela classe FormDBManagemente.
Esta classe tem duas classes filho, OracleDBManager e SQLServerDBManager, específicas para SGBC Oracle e SQL Server, onde são implementados os métodos que permitem estabelecer uma ligação (Connect), realizar uma query SQL (Query) e terminar a conexão (Disconnect) para o SGDB a que cada uma corresponde.
Para que na escrita do código se pudesse utilizar uma classe genérica, que fosse compatível com qualquer SGBD suportado, foi criada a interface IGenericDBManager onde são declarados os métodos acima referidos (implementados nas classes específicas).
Torna-se possível deste modo, após um cast para esta interface, a utilização de um objecto genérico em todo o código, independentemente da base de dados em uso.
DataStructure
A classe DataStructure foi criada para servir como suporte aos dados recolhidos durante um processo de exportação.
A classe contém várias estruturas de dados, desenhadas para armazenar toda a informação recolhida.
Figura 24 – Classe DataStructure
BurningManager
Para a gravação de CDs foi utilizado um componente para o sistema operativo Microsoft Windows chamado XPBurn [16], obtido na página da Microsoft.
Este componente permite a utilização da IMAPI, uma API que providencia meios para a gravação de ficheiros em CDs de dados.
Devido à impossibilidade de efectuar alterações nas máquinas onde a aplicação vai ser instalada, a versão IMAPI utilizada será a 1.0, que não permite a gravação em DVDs.
Figura 25 – Classe BurningManager
Esta classe contém dois métodos estáticos:
AvailableDrives - Retorna um booleano com o valor verdadeiro, caso o componente tenha
detectado um drive capaz de gravar cds, ou falso, no caso contrário.
EncryptionManager
Na cifração do ficheiro de dados é utilizado o algoritmo RC2, também conhecido por Rivest Cipher. É um algoritmo simétrico que opera em grupos de bits de tamanho fixo, ou blocos (64 KiB), em que a cifra utilizada é gerada a partir da palavra-chave inserida pelo utilizador.
Para evitar ataques de dicionário foi utilizado um vector de inicialização (salt) que é utilizado em conjunção com a palavra-chave para gerar a cifra a utilizar na cifração do ficheiro.
Figura 26 – Classe EncryptionManager
O método EncryptFile recebe como argumentos o nome do ficheiro e a palavra-chave a ser utilizada na cifração.
Misc
Na classe Misc encontram-se métodos estáticos para apoio a operações realizadas noutras classes, nomeadamente, à avaliação da força da palavra-chave inserida na classe ControlDestination. Os métodos desta classe são utilizados para calcular o número de letras maiúsculas, números e caracteres não alfanuméricos, valores estes que são utilizados para a avaliação.
RichTextBoxPrintCtrl
Para facilitar a operação de imprimir a palavra-chave numa impressora ligada ao computador, foi criado o componente RichTextBoxPrintCtrl.
Esta classe estende a RichTextBox e foi utilizada a documentação do MSDN da Microsoft para a sua criação.
O seu funcionamento resume-se em adicionar o que se pretende imprimir a um objecto como se de uma RichTextBox se tratasse.
Figura 28 – Classe RichTextBoxPrintCtrl
O método mais importante desta classe é o Print, que faz o rendering do conteúdo e inicia a impressão do documento.
4.5.2 Visualizador
FormMain
A classe FormMain representa uma form visual principal do Visualizador
Utiliza um objecto do tipo DataStructure para armazenar toda a informação carregada de um ficheiro de dados (gerado pelo Exportador) e dela destacam-se os seguintes métodos:
Add…Control – Métodos responsáveis por criar e expôr os controlos em cada etapa do
processo de exportação.
controlLoadFile_ProgressBarEvent – este evento é despoletado com o carregamento de
um ficheiro e termina quando este completar. Consiste na execução de uma thread que vai iniciar uma animação numa barra de progresso durante o carregamento e eventual cifração do ficheiro de dados. Dependendo do tamanho do ficheiro de dados e da eventual necessidade de o decifrar, este processo pode demorar alguns segundos. Desta forma o utilizador é informado de que a aplicação está a processar dados.
ControlLoadFile
A classe ControlLoadFile permite ao utilizador abrir um ficheiro de dados arrastando-o para a zona indicada no ecrã. Quando a aplicação detecta uma acção de drag and drop, despoleta um evento que ou carrega o ficheiro de dados e, caso o ficheiro se encontre cifrado, pede a palavra-chave para o decifrar ou apresenta uma mensagem de erro quando o ficheiro for inválido ou a decifração falhar.
Figura 30 – Classe ControlLoadFile
ControlLeftMenu
A classe ControlLeftMenu representa o componente colocado na barra esquerda da janela principal da aplicação e onde o utilizador pode seleccionar a informação que pretende visualizar, após o carregamento de um ficheiro de dados.
Para além da opção de visualizar a informação clínica ou um encontro (a partir de uma lista de encontros), é também apresentada, neste menu lateral, informação pessoal e demográfica do paciente ao qual corresponde o ficheiro de dados exportados.
ControlClinicalInformation
O componente ControlClinicalInformation é responsável pela apresentação da informação clínica do doente, agrupada por secções: alergias, alergias a medicamentos, precauções e historial cirúrgico, sendo que permite a inspecção com maior detalhe a este último através do evento buttonSurgicalHistorySummary_click que cria uma janela com os detalhes da cirurgia seleccionada do histórico.
ControlEncounterDetails
A classe EncounterDetails é utilizada para apresentar todos os detalhes de um encontro ao utilizador, desde informação geral sobre o mesmo, à lista de eventos e gráficos de monitorização (caso estes existam).
Destacam-se os métodos:
UpdateStartEnd – ajusta os gráficos de visualização ao intervalo temporal definido pelo
utilizador (ver capítulo “Funcionamento da Aplicação”).
UpdateParameterDetails – apresenta valores estatísticos sobre um parâmetro de
monitorização seleccionado (valores máximo e mínimo e momento da ocorrência)
DataStructure
A classe DataStructure é similar à utilizada no Exportador (página 32).
Figura 34 – Classe DataStructure
FileLoadingManager
Para centralizar todas as operações realizadas com ficheiros foi criada a classe FileLoadingManager.
Existem dois métodos públicos e estáticos, DecryptFile, responsável por decifrar um ficheiro de dados para um XML temporário, e LoadFile, para o carregamento da informação de um XML para a estrutura de dados DataStructure.
Os métodos Fetch… são privados e foram criados para facilitar o carregamento da informação contida no ficheiro separando-a por secções.
Figura 35 – Classe FileLoadingManager
EncryptionManager
A classe EncryptionManager é bastante similar à utilizada no Exportador (página 33). A diferença mais relevante entre as duas encontra-se no método DecryptFile (por oposição ao método EncryptFile) em que o processo de cifração é o inverso. A utilização do método
CreateEncryptor é substituída pelo método CreateDecryptor, sendo o restante processo igual
em ambas as operações.
5 Funcionamento das aplicações
5.1 Exportador
5.1.1 Instalação
Para facilitar a instalação da aplicação, foi criado, com recurso ao Microsoft Visual Studio 2003, um instalador. Para o executar basta clicar duas vezes sobre o ficheiro e seguir as instruções apresentadas. Este instalador trata da criação de pastas, cópia de ficheiros e criação de novas chaves no registo do Windows para o correcto funcionamento do programa.
A instalação é feita utilizado valores padrão no que toca às configurações da base de dados e especificidades da instalação de Picis sobre a qual vai operar
Figura 37 – Selecção do directório de instalação
Figura 39 – Atalho para a aplicação no Menu Iniciar
5.1.2 Configuração / Tarefas de administração
Após a instalação da aplicação, é necessário configurar alguns parâmetros, para o correcto funcionamento do Exportador. Estas alterações requerem que o modo de administração esteja activo.
Activar modo de administração
Para activar o modo de privilégios elevados, existe a opção “Activar modo de administração” em “Ficheiro”, “Opções”. Esta activação está protegida por uma palavra-chave que o desbloqueia, conforme ilustrado na figura 40.
Configuração do acesso à Base de Dados
O sistema Picis pode ser utilizado em conjunto com vários SGBDs (sistemas de gestão de bases de dados). Para minimizar dificuldades na instalação do Exportador, foi criado um menu de configuração de acessos que permite ao administrador indicar se pretende utilizar uma base de dados Oracle ou SQL Server, assim como preencher os parâmetros necessários para estabelecer uma ligação (nome de utilizador, palavra chave, servidor, etc.).
Na figura 41 encontra-se uma captura de ecrã deste diálogo.
Política de palavras-chave
Um dos requisitos do Exportador era o de permitir que o administrador conseguisse definir a política de palavras-chave a utilizar. Para este efeito foi criada uma lista com as três opções possíveis (palavra-chave obrigatória, opcional ou desactivada).
Desta maneira consegue-se forçar, desactivar ou deixar à consideração do utilizador final a cifração do ficheiro de dados.
Configuração de consultas à Base de Dados
Dependendo da instalação do sistema Picis, pode ser necessário indicar à aplicação para ignorar valores específicos em certas tabelas, nomeadamente onde são registados eventos e diagnósticos.
Ainda neste menu, o administrador deverá ter a hipótese de indicar em que colunas (de uma tabela específica) se podem encontrar os valores dos parâmetros em tempo real registados pelo Picis e de associar uma descrição a cada um (exemplo: batimento cardíaco, pressão arterial, etc.)
5.1.3 Utilização
Esta secção pretende descrever o modo de funcionamento da aplicação de exportação de dados. Cada etapa do processo vai ser descrita e brevemente analisada. Para ajudar a contextualizar o leitor no funcionamento da aplicação de exportação de dados, é apresentado na figura 44 o fluxograma da aplicação.
1º Etapa – Pesquisar doente
Imediatamente após executar a aplicação de exportação de dados, ao utilizador é apresentado o ecrã de pesquisa de doente.
As pesquisas podem ser efectuadas com base no primeiro nome, último nome, ID (código interno que identifica o doente no sistema hospitalar) e/ou data de nascimento. Todas as correspondências encontradas são listadas do lado direito do ecrã, conforme representado na figura 45.
Ao seleccionar um dos doentes listados, o nome do mesmo é apresentado no canto superior direito (conforme as normas internas das aplicações da Siemens MED) e o botão de “Continuar” fica activo, podendo o utilizador prosseguir o processo de exportação.
2ª Etapa – Seleccionar dados a exportar
A segunda etapa do processo tem por objectivo a selecção dos dados que o utilizador deseja exportar.
A informação passível de ser exportada aparece agrupada em 3 conjuntos: “Dados demográficos”, “Informação clínica” e “Encontros”.
No primeiro conjunto encontram-se para além do nome do doente os dados demográficos que o caracterizam, tais como a data de nascimento, sexo, grupo étnico, estado marital, religião e grupo sanguíneo.
Em “Informação clínica” foram colocados todos os itens com relevância médica que são registados pelo sistema Picis. Destes fazem parte as “Alergias” (alergias de que o doente sofre), “Alergias a Medicamentos” (alergias a medicação), “Precauções” (cuidados especiais que o médico deve ter em atenção), “Reacções alérgicas” (reacções alérgicas que tenham sido registadas) e “Historial Cirúrgico” (histórico de intervenções cirúrgicas a que o doente tenha sido submetido e que podem ou não estar detalhadas num encontro).
Finalmente, no conjunto “Encontros” aparece um registo de todas as passagens do doente pelo centro hospital existentes no sistema Picis (consultas externas, episódios de urgência, intervenções cirúrgicas, etc.)
Para seleccionar os itens de um conjunto, o utilizar deve marcar o item “Seleccionar Tudo.”, ou alternativamente, seleccionar individualmente apenas os que pretende.
3ª etapa – Rever dados
Na 3ª etapa do processo de exportação, a aplicação apresenta a informação recolhida da base de dados do Picis com base na selecção feita anteriormente pelo utilizador.
Pretendeu-se utilizar os conjuntos indicados na etapa anterior, assim, temos a informação separada por 3 grandes grupos: “Dados demográficos”, “Informação Clínica” e “Encontros”.
Optou-se por separar o “Historial Cirúrgico” do conjunto de “Informação Clínica” devido à sua maior relevância no contexto normal de utilização da aplicação (cuidados críticos) e também para facilitar a visualização dos detalhes de cada entrada desta lista.
Figura 47 – Rever dados
Nesta etapa também é possível consultar com maior detalhe cada registo listado em “Encontros”, bastando, para tal, seleccionar a linha correspondente e clicar no botão “Ver detalhes” localizado no canto inferior esquerdo da caixa dos encontros.
Esta acção vai apresentar uma janela semelhante à figura 48 com os detalhes do encontro seleccionado.
Figura 48 – Detalhes de um encontro
Da mesma maneira, ao clicar no botão “Ver detalhes” situado por baixo da lista do historial cirúrgico, vai abrir uma nova janela com os detalhes da cirurgia seleccionada (ver Figura 49)
4 º etapa – Definir palavra-chave e destino
O ecrã apresentado na última etapa permite ao utilizador definir uma palavra-chave para a cifração do ficheiro de dados. Este passo é controlado pelo administrador que pode definir uma política para a sua disponibilidade, e consiste na introdução de uma palavra-chave na caixa de texto mostrada na captura de ecrã seguinte que é avaliada no que concerne à sua robustez (número de dígitos, caracteres não alfanuméricos, letras maiúsculas, e comprimento). Opcionalmente esta palavra-chave pode ser gerada aleatoriamente, usando o botão correspondente.
Seguidamente o utilizador deve indicar o directório de destino do ficheiro de dados. Se o sistema detectar uma unidade que permita a gravação de CDs, o botão “Gravar CD” estará disponível, caso contrário apenas terá a possibilidade de gravar o ficheiro num directório ao qual o sistema tenha acesso (disco rígido, disquete, pendrive, etc.).
Caso o utilizador tenha optado por cifrar o ficheiro, após a sua gravação é apresentado uma janela semelhante à da figura 51, que vai permitir que a palavra-chave possa ser impressa numa folha de papel para entregar ao doente ou a outro receptor.
5.1.4 Gestão de erros
Esta secção descreve o modo como os erros encontrados pela aplicação são geridos. São cobertos apenas alguns exemplos representativos da maioria dos casos gerais.
Conectividade
Neste primeiro caso temos ilustrado um erro de conectividade à base de dados, que ocorreu ao tentar pesquisar um paciente. Como se pode observar é criada uma janela de aviso a informar do erro com uma sugestão para a resolução do mesmo.
Em modo de administrador, é possível alterar os parâmetros de acesso à base de dados. Para garantir que estes foram correctamente preenchidos é dada a possibilidade de testar a conectividade antes de guardar as novas definições, sendo o resultado desta operação apresentado numa caixa de texto.
Dados insuficientes
Tentou-se que em todas as etapas do processo de exportação as acções realizadas pelo utilizador fossem disponibilizadas à medida que eram tornadas possíveis, por exemplo, o botão “Continuar” ficaria disponível apenas após a selecção de um paciente. Nas situações em que esta disponibilidade de acções não é controlada, se o utilizador tentar executar uma operação ilegal será confrontado com um aviso e uma mensagem a indicar como o resolver.
Na seguinte encontra-se um exemplo de uma situação deste tipo.
5.2 Visualizador
À semelhança da secção anterior, pretende-se aqui descrever o modo de funcionamento da aplicação de visualização de dados.
As etapas ilustradas no fluxograma da próxima figura são descritas com maior pormenor em seguida.
5.2.1 Utilização (caso típico)
1º Etapa – Abrir ficheiro de dados
Ao executar o Visualizador, ao utilizador vai ser apresentado ao ecrã seguinte, onde lhe é pedido que escolha o ficheiro a abrir através de um de dois métodos: arrastando o ficheiro de dados para dentro da área marcada a cinzento, ou utilizando o menu superior, clicando em “File”, “Open”.
No caso do ficheiro estar encriptado, é-lhe pedido que insira a palavra-chave, caso contrário, o ficheiro é carregado e a informação nele contida é imediatamente apresentada no ecrã.
Ressalva-se ainda que a opção de abrir um ficheiro está disponível em qualquer momento via menu superior através das opções “File”, “Open”.
