U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciências
Departamento de Informática
SISTEMA DE INFORMAÇÃO PARA
PRESCRIÇÃO E AGENDAMENTO DE MEIOS
COMPLEMENTARES DE DIAGNÓSTICO E
TERAPÊUTICA
Bruno Miguel Batista Ferreira
PROJECTO
Versão Pública
MESTRADO EM ENGENHARIA INFORMÁTICA
Especialização em Engenharia de Software
U
NIVERSIDADE DE
L
ISBOA
Faculdade de Ciências
Departamento de Informática
SISTEMA DE INFORMAÇÃO PARA
PRESCRIÇÃO E AGENDAMENTO DE MEIOS
COMPLEMENTARES DE DIAGNÓSTICO E
TERAPÊUTICA
Bruno Miguel Batista Ferreira
PROJECTO
MESTRADO EM ENGENHARIA INFORMÁTICA
Especialização em Engenharia de Software
Trabalho orientado pelo Prof. Doutor João Balsa da Silvae co-orientado pelo Doutor Paulo Jorge Paiva de Sousa
Agradecimentos
Em primeiro lugar, agradeço aos meus orientadores, o Doutor Paulo Sousa e o Professor Doutor João Balsa da Silva, por todo o apoio prestado durante a elaboração deste relatório.
Um especial agradecimento à Maxdata, que me concedeu a oportunidade de participar neste projecto, e a todos os seus funcionários, em especial aos meus colegas da equipa de desenvolvimento, Alexandre Correira, Nuno Castro, Paulo Sousa e Gonçalo Gerardo que contribuíram bastante para a minha integração na empresa.
Agradeço também a todo o corpo docente do Departamento de Informática da Faculdade de Ciências da Universidade de Lisboa por todo o seu trabalho de formação do qual tive a oportunidade de usufruir durante o meu percurso académico.
A todos os meus amigos e colegas de curso, agradeço o companheirismo e amizade ao longo desta caminhada. Obrigado João Pedro Coelho, João Oliveira, Hugo Neves, Fernando Silva, Flávio Saraiva, Filipe Cabaço, Vasco Tareco e Rafael Soledade Matos.
À Eunice, agradeço toda a paciência e incentivo ao longo de mais uma jornada. E por fim, um grande obrigado aos meus pais que sempre me acompanharam e se esforçaram para que pudesse realizar os meus estudos com as melhores condições possíveis.
i
Resumo
O projecto descrito neste relatório consistiu no desenvolvimento de um módulo de
software responsável pelo registo de dados de utentes e pela prescrição e agendamento
de meios complementares de diagnóstico e terapêutica (MCDT) que desempenham um papel essencial na actividade clínica, permitindo ao médico a prescrição do tratamento mais adequado a cada paciente num determinado momento.
O desenvolvimento deste módulo teve como base vários requisitos recolhidos e documentados pelos analistas seniores da Maxdata e seguiu um modelo de desenvolvimento ágil de modo a responder rapidamente a mudanças de requisitos. Também com o intuito de desenvolver software de boa qualidade de uma maneira modular e, consequentemente, mais fácil de manter, foi utilizado o padrão arquitectural
Model-View-Presenter que se revelou a melhor alternativa entre as várias possíveis.
O módulo de software desenvolvido é composto por quatro camadas: fontes de dados, acesso aos dados, negócio e apresentação. Cada uma das camadas tem diferentes responsabilidades e foram utilizadas várias frameworks (Google Web Toolkit, Hibernate e Spring) para o seu desenvolvimento.
Palavras-chave: agendamento, prescrição, diagnóstico, terapêutica, model-view-presenter
iii
Abstract
The project described in this report consisted in the development of a software module with the following goals: registration of patient data, prescription and scheduling of complementary means of diagnosis and therapeutic (MCDT). MCDT play an essential role in the clinical activity, allowing the clinician to prescribe the most appropriate treatment for each patient at a given time.
The development of this module was based on several requirements collected and documented by Maxdata’s senior analysts and followed a model for agile development in order to respond quickly to changing requirements. Also with the aim of developing good quality software in a modular manner and, therefore, easier to maintain, it was used the Model-View-Presenter architectural pattern which proved to be the best choice among the possible.
The software module that was developed is composed of four layers: data sources, data access, business and presentation. Each of the layers has different responsibilities, and multiple frameworks (Google Web Toolkit, Hibernate and Spring) were used for its development.
v
Conteúdo
Lista de Figuras ... ix
Lista de Tabelas ... xiii
Capítulo 1 Introdução ... 1
1.1 A Maxdata e os seus produtos ... 1
1.2 Motivação ... 3 1.3 Objectivos ... 4 1.4 Organização do documento... 4 Capítulo 2 Enquadramento ... 7 2.1 Contexto do trabalho ... 7 2.2 A Gestão do Projecto ... 11 2.2.1 As Pessoas ... 11 2.2.2 O Produto ... 12 2.2.3 O Processo ... 12 2.2.4 O Projecto ... 15
Capítulo 3 Trabalho relacionado ... 18
3.1 wClínicas ... 19 3.2 MCDT Global ... 20 3.3 MedicineOne ... 20 3.4 Orkos ... 22 3.5 iCare ... 22 3.6 Outros ... 23
Capítulo 4 Análise e Desenho ... 25
4.1 Requisitos ... 25 4.1.1 Requisitos normais ... 25 4.1.2 Requisitos esperados ... 26 4.1.3 Requisitos opcionais ... 27 4.2 Modelo de dados ... 28 4.2.1 Entidades e Relações ... 28
vi
4.2.1.2 Entidade Atendimento (DTW_EPISODE) ... 32
4.2.1.3 Entidade Exame do Atendimento (DTW_EPISODE_EXAM) .... 34
4.2.1.4 Entidade Pedido (DTW_REQUISITION) ... 35
4.2.1.5 Entidade Exame do Pedido (DTW_REQ_EXAM) ... 37
4.3 Arquitectura da aplicação ... 40
4.3.1 Model-View-Presenter ... 40
4.3.2 Diagramas de packages e de classes ... 42
4.3.3 Diagramas de actividades e de sequência ... 47
4.3.4 Protótipos ... 51
4.3.4.1 Ecrã Inicial ... 52
4.3.4.2 Exibição e alteração de dados ... 53
Capítulo 5 Codificação ... 57
5.1 Java ... 57
5.2 SGBDs – Sistemas de Gestão de Bases de dados ... 57
5.3 Hibernate ... 58 5.4 Spring ... 62 5.5 GWT ... 64 5.6 Arquitectura em camadas ... 66 5.7 Casos de Uso ... 67 5.7.1 Configuração de ecrã ... 67
5.7.2 Adição de exames a um pedido ... 71
5.7.3 Inserção de exames através de “botões de prescrição” ... 73
5.7.4 Criação de um novo pedido ... 75
5.7.5 Eliminação de um atendimento ... 76
5.7.6 Alterações de atributos dos exames ... 78
5.8 Resultados ... 80
Capítulo 6 Conclusão e Trabalho Futuro ... 83
6.1 Conclusão ... 83
6.2 Trabalho Futuro ... 83
vii
Glossário ... 88 Bibliografia ... 90
ix
Lista de Figuras
Figura 1. Diagrama representativo das redes laboratoriais. ... 8
Figura 2. Iterações no modelo de desenvolvimento ágil utilizado na Maxdata. ... 13
Figura 3. Tabela DTW_PATIENT relativa aos dados do paciente. ... 31
Figura 4. Tabela DTW_EPISODE relativa aos dados do atendimento. ... 32
Figura 5. Tabela DTW_EPISODE_EXAM que contém todos os exames para realizar de todos os atendimentos. ... 34
Figura 6. Tabela DTW_REQUISITION relativa aos dados do pedido. ... 37
Figura 7. Tabela DTW_REQ_EXAM que contém todos os exames dos pedidos. 39 Figura 8. Padrão arquitectural MVC (Model-View-Controller). ... 41
Figura 9. Padrão arquitectural MVP (Model-View-Presenter). ... 42
Figura 10. Notação utilizada no diagrama de packages e de classes. ... 43
Figura 11. Visão geral do package “client” da aplicação. ... 43
Figura 12. Visão geral das classes existentes no client-side da Gestão de Pedidos. ... 44
Figura 13. Visão geral do package “shared” da aplicação. ... 45
Figura 14. Visão geral do package “server”. ... 46
Figura 15. Descrição das várias componentes utilizadas no diagrama de actividades. ... 48
Figura 16. Diagrama de actividades para a eliminação de um atendimento ou de um pedido. ... 49
Figura 17. Protótipo do ecrã inicial da opção "Gestão de Pedidos". ... 52
Figura 18. Protótipo do ecrã de pesquisa de atendimentos ou pacientes. ... 53
Figura 19. Protótipo do ecrã de exibição do atendimento (e dos pedidos) de um paciente. ... 54
Figura 20. Protótipo da visão Administrativa sobre os exames do pedido. ... 55
Figura 21. Protótipo do pop-up utilizado para colocar um exame para realizar ou para não realizar... 55
x
Figura 22. Exemplo da utilização de HQL na aplicação. ... 59
Figura 23. Diagrama representativo do problema e da solução para as modificações concorrentes a um atendimento. ... 60
Figura 24. Exemplo de código SQL gerado pelo Hibernate aquando da actualização dos dados de um atendimento. ... 61
Figura 25. Exemplo da utilização das anotações do Spring para a injecção de dependências. ... 63
Figura 26. Arquitectura da aplicação em camadas. ... 66
Figura 27. Ecrã de login do utilizador. ... 68
Figura 28. Ambiente de trabalho do utilizador na aplicação Clinidata®. ... 69
Figura 29. Exemplo de configuração do ecrã de Gestão de Pedidos. ... 70
Figura 30. Exemplo do ecrã de Gestão de Pedidos em modo de exibição... 71
Figura 31. Ecrã de Gestão de Pedidos em modo de edição e com um exame pronto a ser inserido. ... 72
Figura 32. Confirmação de gravação do atendimento após a inserção de um exame no 2º pedido. ... 73
Figura 33. Exemplo de vários botões de prescrição de exames. ... 74
Figura 34. Exemplo de exames associados a um botão de prescrição. ... 75
Figura 35. Introdução da razão para a criação de um novo pedido. ... 76
Figura 36. Adição de um pedido e exibição do separador relativo aos "Dados clínicos e hospitalares"... 77
Figura 37. Confirmação da eliminação do pedido ou do atendimento. ... 77
Figura 38. Exibição de um atendimento eliminado. ... 78
Figura 39. Exibição de uma possível configuração para a visão financeira sobre os exames. ... 79
Figura 40. Alteração do estado de um exame para "Não realizar". ... 79
Figura 41. Exibição de uma possível configuração para a visão técnica sobre os exames. ... 80
xiii
Lista de Tabelas
Tabela 1. Tabela com exemplo de numerações de etiquetas e os respectivos dados utilizados para a sua formação... 10
Tabela 2. Abreviaturas utilizadas no relatório. ... 87 Tabela 3. Glossário com alguns dos conceitos utilizados no relatório. ... 88
1
Capítulo 1
Introdução
1.1 A Maxdata e os seus produtos
A Maxdata1 concebe, desenvolve, instala e mantém, há mais de 30 anos, diferentes tipos
de soluções informáticas (software Clinidata®) para a área da saúde, sendo líder de mercado desde a sua criação. O software Clinidata® encontra-se em funcionamento nos maiores hospitais portugueses em diversas áreas e laboratórios, nomeadamente, requisição electrónica, patologia clínica, anatomia patológica, imunohemoterapia (banco de sangue e transfusões), gestão de termos de responsabilidade e vigilância epidemiológica. Para cada área referida anteriormente existe uma aplicação diferente:
O Clinidata®NET (requisição electrónica) é um sistema Web que utiliza a
intranet do hospital, clínica ou laboratório para interligar os médicos e os
serviços clínicos aos laboratórios de diagnóstico, facilitando assim a coordenação e colaboração dos vários intervenientes envolvidos no diagnóstico e tratamento do paciente. De entre as várias funcionalidades destacam-se a possibilidade de consultar resultados actuais e históricos por diversos critérios, controlar e gerir os pedidos realizados por um médico ou serviço clínico, gerar alertas de situações especiais ou anómalas, para médicos, serviços e farmácias;
O Clinidata®XXI (patologia clínica) é um sistema inteligente de gestão global de laboratórios de análises clínicas e de diagnóstico, nas vertentes técnicas e financeiras. Este sistema, considerado como o produto mais representativo da Maxdata, engloba todas as áreas de patologia clínica, ligação de equipamentos e controlo de qualidade. É adaptável a qualquer
2
laboratório independentemente da sua dimensão, de ser público ou privado, de ser um laboratório de apoio ou integrado em organizações como os centros hospitalares. Através de um motor de regras, permite incorporar inteligência no sistema de modo a executar automaticamente operações rotineiras, ajustáveis às opções de cada utilizador;
O Clinidata®ANP (anatomia patológica) é um sistema de gestão global para laboratórios de anatomia patológica, abrangendo todos os processos intrínsecos ao diagnóstico anatomopatológico, tanto a nível técnico como também a nível financeiro. Este software tem como funcionalidades a requisição electrónica dos exames e a consulta dos relatórios nos serviços clínicos, permitindo assim a interacção online entre o laboratório de anatomia patológica e os serviços clínicos. Garante também outras funcionalidades como por exemplo o arquivo de imagens nas várias fases dos exames e a utilização de etiquetas de código de barras para a identificação de recipientes e lâminas;
O Clinidata®BST (imunohemoterapia) é um sistema web de gestão de Banco de Sangue e Transfusões. É dirigido ao laboratório, ao médico e ao enfermeiro e fornece ao hospital uma solução completa para o serviço de Imunohemoterapia, simplificando processos, garantindo segurança, fiabilidade e rastreabilidade;
O Clinidata®STK é uma aplicação específica para gestão de stocks do laboratório clínico, possibilitando assim um controlo mais eficaz dos gastos. O software incorpora todo o processo de gestão de stocks, desde a encomenda e recepção até à requisição interna de artigos. O objectivo passa por fornecer ao laboratório um controlo cuidado e uma gestão eficaz dos stocks, das encomendas e dos recibos. Através da integração com o
software Clinidata®XXI, já referido anteriormente, é então possível cruzar
directamente os consumos de reagentes com a quantidade de análises efectuadas;
O Clinidata®TRM (gestão de termos de responsabilidade) permite gerir o circuito de aprovações e rejeições associado aos exames que se realizam fora da unidade de saúde. Este é um processo transversal a vários sectores da unidade de saúde e inicia-se aquando da prescrição dos exames por
3
parte do médico. Esta aplicação disponibiliza assim uma solução que responde às especificidades de cada organização no controlo dos exames realizados fora desta;
O Clinidata®VEP (vigilância epidemiológica) permite a identificação, detecção e eventualmente a prevenção e controlo de doenças, a nível pessoal e colectivo, abrangendo toda a instituição médica e possibilitando a obtenção de informações que expressam a ecologia infecciosa e que, pelas suas repercussões, constituem um aspecto importante na prevenção e controlo de infecções em ambiente hospitalar.
Tal como se pode verificar, actualmente a Maxdata comercializa aplicações independentes para várias áreas do hospital. Nos últimos anos, a aposta na internacionalização tem sido um dos objectivos estratégicos mais importantes e, por esta razão, a Maxdata encontra-se de momento a efectuar uma reengenharia dos seus produtos de modo a desenvolver uma única aplicação cross-platform, cross-browser e
cloud-ready que integre todas as aplicações em ambiente web, adaptando deste modo os
seus produtos a novos paradigmas de computação como o cloud computing [1] e às novas funcionalidades emergentes na nova era da Web 2.0 [2]. No contexto desta nova aplicação, um dos módulos principais é o tema do trabalho descrito neste relatório: Prescrição e Agendamento de Meios Complementares de Diagnóstico e Terapêutica.
1.2 Motivação
Actualmente, a maioria das diferentes aplicações da Maxdata contam já com vários anos de manutenção em que foram sofrendo várias alterações de modo a satisfazer os diferentes requisitos apresentados pelos seus clientes. Todos os sistemas de software são “mortais” [3] e a causa da sua morte não se restringe apenas à deterioração causada pelas várias modificações ao longo dos anos mas também por mudanças de hardware ou de sistema operativo. Deste modo, uma das motivações para este projecto, e também para toda a aplicação no qual este se insere, passa pela renovação dos produtos existentes. Esta renovação é efectuada tendo sempre como foco uma melhoria contínua, de maneira a que o tempo de vida da nova aplicação seja longo e que a sua manutenção seja o mais simples possível. A outra motivação é portanto a melhoria dos produtos já desenvolvidos pela Maxdata de modo a tornar o seu sofware mais adaptável às
4
preferências dos clientes, independente de plataformas de execução e preparado para executar na cloud.
1.3 Objectivos
O principal objectivo do trabalho descrito neste relatório consistiu no desenvolvimento do módulo SIPA-MCDT2 responsável pela prescrição e agendamento de meios
complementares de diagnóstico e terapêutica (MCDT). As principais funcionalidades deste módulo são:
Inscrição de utentes e alteração dos seus dados;
Prescrição electrónica de MCDTs;
Alocação de recursos, como por exemplo, salas para colheitas ou técnicos clínicos, através da criação de agendas ou livros de marcações;
Criação e configuração de etiquetas para recipientes (tubos) com informação legível sobre a identificação do tubo, da agenda, do doente, etc.;
Registo de colheitas e exames realizados.
1.4 Organização do documento
Os capítulos deste documento estão organizados da seguinte forma:
Capítulo 2 – Enquadramento: É apresentada uma descrição sucinta do contexto onde se insere o módulo desenvolvido neste PEI e são descritos vários aspectos da gestão do projecto;
Capítulo 3 – Trabalho relacionado: São descritas várias aplicações semelhantes ao módulo desenvolvido neste PEI, sendo também apresentado um estudo comparativo;
Capítulo 4 – Análise e Desenho: São enumerados os requisitos do projecto, bem como a descrição sobre a arquitectura e o modelo de dados;
2 SIPA-MCDT, Sistema de Informação para Prescrição e Agendamento de Meios Complementares
5
Capítulo 5 – Codificação: São apresentadas as diferentes frameworks utilizadas nas diferentes camadas da arquitectura e são também apresentados vários casos de uso relativos a cenários de utilização do módulo desenvolvido. No final do capítulo, são apresentados alguns dos resultados obtidos;
Capítulo 6 – Conclusão e Trabalho Futuro: Neste capítulo são apresentadas as conclusões retiradas de todo o processo de desenvolvimento do SIPA-MCDT, bem como o trabalho ainda a desenvolver.
7
Capítulo 2
Enquadramento
2.1 Contexto do trabalho
Nesta secção são descritos alguns dos principais conceitos subjacentes ao módulo desenvolvido e é feita uma explicação sobre o circuito dos exames laboratoriais desde a prescrição até à colheita dos produtos.
Os laboratórios clínicos, numa visão um pouco simplista, podem ser considerados como “fábricas” que produzem resultados de diversos exames que irão servir para diagnosticar doenças. Têm como input os pedidos de exames e as respectivas amostras dos doentes (sangue, urina, expectoração, etc.) e o output são os relatórios dos exames.
Actualmente, no contexto nacional, existem três tipos de laboratórios:
Os laboratórios hospitalares, públicos ou privados, que produzem para o próprio hospital ou para uma rede de hospitais;
Os laboratórios não hospitalares, que têm uma rede de pontos de colheitas associados e realizam os exames mais frequentes;
Os laboratórios de apoio que prestam serviços a outros laboratórios, realizando normalmente exames pouco comuns.
8
Figura 1. Diagrama representativo das redes laboratoriais.
Na figura 1 é representado o circuito das amostras e dos resultados entre os hospitais, clínicas ou postos de colheita e os diferentes tipos de laboratórios apresentados anteriormente. Tanto nos hospitais como nas clínicas ou postos de colheita, como se pode observar, após a recolha das amostras necessárias para efectuar os exames, estas são enviadas para os laboratórios. No caso dos hospitais, são primeiramente enviadas para o laboratório hospitalar e que, por sua vez, poderão reencaminhá-las para um laboratório não hospitalar por várias razões, como por exemplo, nos casos em que o laboratório hospitalar não tenha meios para realizar um determinado tipo de exame, tendo este de ser realizado num laboratório não hospitalar. Ainda assim, determinadas amostras poderão ter ainda de ser reencaminhadas para um laboratório de apoio para efectuar o exame e, por fim, os resultados farão o caminho inverso até ao hospital. No caso das clínicas ou dos postos de colheita, não existe um laboratório próprio da unidade médica e, deste modo, as amostras são reencaminhadas para um laboratório não hospitalar que, se for um exame muito específico, poderá ter de ser realizado num laboratório de apoio.
Deste modo, a função do laboratório é atender os pedidos ou requisições, ou seja, as prescrições de exames. No contexto do software Clinidata® temos os conceitos de inscrição e de pedido. Uma inscrição, ou atendimento, corresponde a uma visita de um utente ao laboratório. Pode ter mais de um pedido, cada um com os seus exames.
Os pedidos são discriminados automaticamente pelo sistema aquando da sua inserção, sendo estes distinguidos, por exemplo, pelo médico que prescreveu os exames, ou seja, uma mesma inscrição de um utente pode gerar vários pedidos de exames associados, por exemplo, a diferentes médicos prescritores. No entanto, os pedidos
9
também podem ser definidos opcionalmente pelo utilizador quando é desejável separar exames com alguma característica em particular como por exemplo exames isentos de taxas moderadoras, exames urgentes ou exames de uma área especial.
As inscrições, tal como já foi referido, podem conter exames de várias prescrições médicas ou pedidos. Por exemplo, se um utente for a uma clínica onde é consultado por vários médicos e cada um deles lhe prescrever exames, quando chegar ao laboratório ser-lhe-á efectuada uma única inscrição mas subdividida em vários pedidos, um por cada médico. Se diferentes médicos prescreverem o mesmo exame em diferentes pedidos, ao nível da inscrição figurará apenas um desses exames, evitando assim a realização de exames repetidos e os custos desnecessários associados a estes.
Para a colheita ou para a realização de exames são necessários recursos, como por exemplo, salas para colheita ou para a realização do exame, técnicos clínicos ou paramédicos, sendo portanto importante definir horários e estimar tempos médios por exame de modo a efectuar a criação de agendas, ou livros de marcações. No sistema Clinidata® uma agenda define, em conjunto com a sala, uma sigla (ou matrícula) que figurará na numeração da etiqueta dos recipientes produzidos na colheita ou realização do exame. A etiqueta dos recipientes (ou tubos) pode conter muita informação legível, como por exemplo a identificação do tubo, da agenda, do doente, etc., sendo esta configurável consoante as necessidades do laboratório.
Um exame ou um conjunto de exames de um ou de vários pedidos que necessitem de uma sala própria, de um determinado paramédico, que tenham limitações no número de marcações ou de um tipo específico de doentes, definem então uma agenda. As colheitas são depois efectuadas após a marcação da sala de colheita associada à agenda, quando o doente se apresenta no dia e hora do agendamento.
No dia da marcação, é efectuada a colheita e são obtidas as amostras necessárias, sendo registadas no sistema todas as colheitas realizadas, cada uma com um número identificativo. As etiquetas para colar nos recipientes que contêm as amostras são produzidas antes da colheita.
10
Paciente Pedidos Exames por
pedido
Exames do
atendimento Agenda Sala
Marcações e respectivos exames Exemplo de numeração na etiqueta Sr. Joaquim (Nid: 12345) 1 Hemograma Eritograma Hemograma Eritograma Adenograma Mielograma A1 S1 M1: Hemograma 01.12345.S1 M2: Eritograma Adenograma 02.12345.S1 2 Hemograma Adenograma Mielograma A2 S2 M3: Mielograma 03.12345.S2
Tabela 1. Tabela com exemplo de numerações de etiquetas e os respectivos dados utilizados para a sua formação.
Na tabela 1 podemos observar exemplos de numerações de etiquetas e como é que estas são formadas. Temos o paciente “Sr. Joaquim” com o NID3 12345 que apresentou dois
pedidos diferentes, que pode ter ocorrido por exemplo devido ao facto de ter consultado dois médicos diferentes e cada um prescreveu um determinado número de exames. No pedido 1 o médico prescreveu um Hemograma e um Eritograma, enquanto que no pedido 2 foi prescrito outro Hemograma e também um Adenograma e um Mielograma. Uma vez que temos dois Hemogramas em pedidos diferentes, apenas um deles será realizado e portanto, apenas figurará um Hemograma ao nível do atendimento do Sr. Joaquim. Os cinco exames para realizar formam então duas agendas em salas diferentes uma vez que um dos exames, neste caso o Mielograma, tem de ser realizado na sala S2 (por exemplo, devido à existência de algum aparelho de colheita específico nesta sala) enquanto que os restantes serão realizados na sala S1. No total, são efectuadas três marcações diferentes uma vez que, apesar do Hemograma ser realizado na mesma sala que o Eritograma e que o Adenograma, este poderia, por exemplo, de ter de ser realizado em jejum e ficaria portanto numa marcação à parte. Por fim, temos então três numerações de etiquetas diferentes, cada uma constituída por um número sequencial, seguido do NID do paciente e por fim a sigla da sala onde o exame foi realizado. Como já foi referido, esta numeração poderia conter outro tipo de informação, consoante as necessidades do laboratório.
As informações referidas anteriormente são um resumo de alguns documentos de análise elaborados pelos analistas seniores da Maxdata, que depois são discutidos em
11
reuniões quinzenais onde participam também programadores e técnicos da assistência com mais anos de experiência. Os documentos incluem informação detalhada sobre a lógica do negócio, requisitos funcionais e não funcionais, protótipos de média fidelidade[4], relações entre tabelas e definição dos campos das tabelas da base de dados, entre outros tipos de informação essenciais para o desenvolvimento da aplicação.
2.2 A Gestão do Projecto
Nesta secção é descrito o processo de gestão do projecto do novo software Clinidata®, no qual o módulo desenvolvido neste PEI está inserido.
Segundo Pressman [5], a gestão de projectos de software foca-se essencialmente nas Pessoas, no Produto, no Processo e no Projecto e a ordem dos “4 P’s” não é arbitrária.
2.2.1 As Pessoas
As funções e as responsabilidades de cada elemento da equipa do projecto estão definidas no manual de funções e responsabilidades da Maxdata. No entanto, no âmbito deste PEI salientam-se as seguintes categorias:
O Gestor de projecto tem como principais responsabilidades a definição do processo de gestão do projecto e a monitorização e avaliação de desempenho do projecto.
O Director de Investigação e Desenvolvimento é responsável pela gestão do circuito de desenvolvimento do software, valida a análise funcional do sistema e avalia os programadores/analistas.
Os Analistas Séniores prestam trabalhos de consultadoria a clientes e efectuam o levantamento de requisitos e a análise funcional do software. O grupo de
analistas seniores é formado por colaboradores com vários anos de experiência,
tendo adquirido grande conhecimento “no terreno” e são assim aqueles que, dentro da empresa, melhor conhecem as necessidades do utilizador final.
Os Programadores/Analistas, que formam a equipa de desenvolvimento, são responsáveis pela arquitectura e desenvolvimento do software, efectuando também análises funcionais ao sistema. A equipa de desenvolvimento reúne-se diariamente[6], normalmente ao início do dia, para discutir problemas
12
encontrados durante o dia transacto, de modo a discutir soluções com os colegas, com o Director de Investigação e Desenvolvimento e com o Gestor de
projecto. Quinzenalmente, ocorre uma outra reunião com os Analistas Séniores
onde são apresentados, discutidos e posteriormente aperfeiçoados os documentos de análise do novo software Clinidata®.
Os Técnicos de Assistência, para além de serem responsáveis pela instalação do
software nos clientes e pela resolução de problemas técnicos, formam também a equipa de testes, efectuando testes aos vários módulos da aplicação após o seu
desenvolvimento. Todos os erros encontrados são depois reportados para serem corrigidos pela equipa de desenvolvimento.
O Cliente, através da sua colaboração, ajuda a definir os requisitos, sugerindo ideias e fornecendo alguns casos de uso para a aplicação. Neste caso, o cliente consiste no largo conjunto de hospitais e laboratórios clínicos onde a Maxdata já tem os seus produtos instalados e serão também o ponto de partida para o arranque da nova aplicação.
Os Utilizadores são, por fim, as pessoas que trabalham com a aplicação diariamente. Neste módulo desenvolvido, os utilizadores alvo serão os médicos, os enfermeiros, os técnicos laboratoriais e os administrativos de um hospital, de um laboratório ou de uma clínica.
2.2.2 O Produto
O produto, tal como já foi referido, consiste numa aplicação web que unifica todas as aplicações desenvolvidas pela Maxdata ao longo dos anos. Neste PEI foi desenvolvido o módulo responsável pela prescrição e agendamento de meios complementares de diagnóstico e terapêutica (MCDT). As funcionalidades do módulo desenvolvido serão apresentadas em maior detalhe na secção dos requisitos.
2.2.3 O Processo
O processo de desenvolvimento utilizado na Maxdata e, deste modo, praticado também no desenvolvimento deste módulo, é baseado na família de metodologias de
13
desenvolvimento Agile4, sendo constituído por um conjunto de iterações de curta
duração, aplicadas sequencialmente às funcionalidades a desenvolver. Cada iteração é composta pelas fases de levantamento de requisitos, análise e desenho, codificação, testes e documentação, tal como é ilustrado na figura 2.
Figura 2. Iterações no modelo de desenvolvimento ágil utilizado na Maxdata.
A fase inicial do processo de desenvolvimento consiste no levantamento de requisitos e tem como principal objectivo definir todos os requisitos da(s) funcionalidade(s) a desenvolver. Na análise e detalhe da funcionalidade a desenvolver, pode ser necessário realizar reuniões com um ou mais clientes para detalhar os processos de trabalho e regras de negócio, e analisar também a legislação a aplicar e quais as regras a seguir.
Após o levantamento de requisitos segue-se a análise e o desenho que têm como objectivos definir a forma mais correcta de implementar os requisitos definidos, assegurando a sua compatibilidade e coerência com funcionalidades que podem já estar implementadas. Esta fase tem como input os documentos elaborados no contexto da fase de levantamento de requisitos que detalham os requisitos funcionais e não funcionais da aplicação e da funcionalidade a desenvolver. O output consiste num documento onde são definidos o modelo de dados, alguns diagramas em UML5
4 Manifesto for Agile Software Development, http://agilemanifesto.org/iso/en. 5 UML, Unified Modeling Language.
14
(diagramas de actividades, de sequência e de classes) e esboços de alto nível da
interface.
A codificação consiste na implementação da funcionalidade utilizando as técnicas e linguagens de programação mais adequadas, assegurando também a correcção de erros que eventualmente tenham sido detectados na fase de testes. A fase de codificação pode assim ter dois tipos de input: o documento com a análise e desenho da funcionalidade a desenvolver, ou então uma lista de erros detectados durante os testes efectuados à funcionalidade. Se surgir algum impedimento na codificação da funcionalidade, a mesma regressa à fase de análise e desenho, voltando depois o documento de análise e desenho devidamente actualizado. O processo de implementação da funcionalidade é realizado pela equipa de desenvolvimento e o código produzido é integrado num sistema central de gestão de versões, sendo actualmente utilizado o CVS6. É enviado diariamente para toda a equipa de
desenvolvimento um relatório automático com a actividade de cada elemento e no seu seguimento é realizada uma daily standup meeting [6] onde é feito um acompanhamento dos trabalhos. De referir também que nesta fase são efectuadas revisões de código7 [7] que ocorrem após a codificação de uma determinada funcionalidade e que são efectuadas por outro programador da equipa de desenvolvimento, que analisa o código em conjunto com o programador que o desenvolveu. Estas revisões são muito importantes pois encorajam a partilha de conhecimento, são encontrados bugs durante o processo, forçam a escrita de código mais “legível” (ou seja, código que possa ser entendido facilmente), entre outras vantagens [8] [9].
A fase de testes tem como objectivo testar a funcionalidade implementada na fase de codificação. Os testes são efectuados por colaboradores que não estiveram envolvidos na fase de codificação e num ambiente que simula as diversas realidades dos clientes onde a funcionalidade será disponibilizada, por exemplo, em diferentes
browsers e em diferentes SGBDs, de modo a averiguar se o comportamento da
aplicação é idêntico em todos os cenários. Quando são encontrados problemas, o Director de Investigação e Desenvolvimento revê os resultados e decide se a funcionalidade deve ou não ser retornada para a codificação.
6 CVS – Concurrent Versions System, http://cvs.nongnu.org/. 7 Code Reviews ou Peer Code Reviews.
15
Por fim, a fase de documentação consiste na actualização da documentação técnica e funcional da aplicação. A equipa de testes e/ou de marketing avalia as funcionalidades que foram implementadas e actualiza a documentação relevante.
2.2.4 O Projecto
Este PEI foi dividido em 3 fases:
1ª fase (de Setembro a Dezembro de 2012)
Nesta fase foi recebida formação por parte de vários colaboradores da Maxdata, foi lida a documentação sobre as tecnologias a serem utilizadas no desenvolvimento da aplicação, bem como as tecnologias utilizadas pela empresa noutras aplicações, e foi elaborado o relatório preliminar deste PEI.
Existiu também uma forte componente prática nesta fase de formação, uma vez que me foram atribuídas várias tarefas de desenvolvimento que se podem considerar como essenciais para a minha integração no ambiente de desenvolvimento da aplicação. Através do desenvolvimento destas tarefas obtive conhecimento sobre os detalhes da arquitectura da aplicação e sobre vários conceitos da lógica de negócio, muitos deles relacionados com o contexto do módulo desenvolvido neste PEI. De salientar também que entrei numa fase em que a equipa de testes estava a detectar muitos problemas de lentidão na aplicação e, após algumas pesquisas, a equipa de desenvolvimento detectou problemas8 de memory leaks em alguns browsers, o que implicou alguma refactorização
do código desenvolvido até então. A minha participação neste processo de refactorização foi também importante pois contribuiu para o meu conhecimento da estrutura da aplicação.
No dia 9 de Outubro de 2012 obtive formação no Hospital de Santa Maria, em Lisboa, onde observei o funcionamento de um laboratório de análises clínicas e o
software Clinidata® a ser utilizado por utilizadores reais. No final do dia, produzi um
pequeno relatório sobre o que foi aprendido.
2ª fase (de Janeiro a Maio de 2013)
8 Alguns destes problemas eram bugs das frameworks externas utilizadas no ambiente de
desenvolvimento e que foram corrigidos em novas versões, como por exemplo: https://code.google.com/p/google-web-toolkit/issues/detail?id=6938.
16
Esta fase correspondeu à concepção e desenvolvimento do sistema de informação para prescrição e agendamento de meios complementares de diagnóstico e terapêutica.
3ª fase (Junho e Julho de 2013) Nesta fase foi elaborado o relatório final.
18
Capítulo 3
Trabalho relacionado
Segundo Galvoeira [10], os meios complementares de diagnóstico e terapêutica (MCDT) desempenham um papel fundamental na actividade clínica, possibilitando ao médico a prescrição do tratamento mais ajustado a cada paciente num determinado momento. Devido à evolução tecnológica nos últimos anos, é então possível oferecer um leque alargado de novos meios complementares.
A forma mais comum de realização de MCDT é através de prescrição médica. No entanto, é sempre possível que o utente se auto proponha à realização de um exame específico. A realização de MCDT envolve um custo, por vezes elevado, para a entidade responsável pelo pagamento dos cuidados de saúde (SNS9, subsistemas de saúde,
seguros de saúde ou o próprio utente).
Ainda de acordo com Galvoeira [10], o grande desafio que se coloca nos dias de hoje ao sector dos MCDT, centra-se sobretudo na necessidade de optimizar a capacidade instalada nos prestadores públicos. São apontados vários factores para a ineficiência que se verifica actualmente, entre os quais a inexistência de uma rede de informação capaz de possibilitar a consulta e a requisição de exames entre os centros de saúde e os hospitais, ou seja, se um determinado utente que realize MCDT numa ida à urgência, caso prefira depois ser seguido no seu centro de saúde pelo seu médico de família, tem de transportar consigo os exames realizados. Caso não os possua, o médico de família prescreverá novos exames, alguns deles repetidos. A criação de uma rede de informação que permitisse a partilha dos resultados dos exames realizados pelos utentes, permitira assim uma grande redução de custos no SNS e optimizaria os recursos instalados nos prestadores públicos, reduzindo até a necessidade de contratação externa de alguns serviços.
19
Actualmente existe uma extensa oferta10 de produtos de software para meios
complementares.
3.1 wClínicas
A aplicação wClínicas11 é um sistema de gestão e informação médica destinado a
consultórios, clínicas médicas e clínicas hospitalares de pequena e média dimensão. Desenvolvido pela empresa WinTouch, apresenta várias funcionalidades em comum com o SIPA-MCDT, nomeadamente:
Agendamento para marcação de consultas, com possibilidade de alocação automática de vários recursos por marcação;
Envio automatizado de SMS a clientes/pacientes, por exemplo, para alertar sobre próximas consultas;
Informação detalhada do utente, com todo o seu historial clínico.
Uma desvantagem em relação ao SIPA-MCDT, que se pode verificar na página web da descrição do produto, são os requisitos mínimos para o funcionamento da aplicação. São necessários pelo menos 2Gb de memória RAM (recomendam-se 4Gb) e 100Gb de disco rígido (poderá variar em função do volume de dados) para que a aplicação tenha um bom desempenho. No contexto actual, em grande parte dos hospitais públicos (e também em alguns privados), existem computadores com recursos muito menores do que os referidos anteriormente. Durante o desenvolvimento do novo software Clinidata® a preocupação com o desempenho é constante, sendo efectuados testes regularmente em computadores com recursos semelhantes aos do cliente, de modo a garantir um bom desempenho mesmo em máquinas mais antigas.
O facto de o wClínicas executar apenas no sistema operativo proprietário
Windows (Xp ou superior) consiste também numa desvantagem. Por outro lado, o
Clinidata® poderá executar nos browsers mais comuns e, deste modo, suportará diferentes tipos de sistemas operativos.
10 Software para Meios complementares de diagnóstico e terapêutica (actualizado dia 22 de Outubro de
2012), http://www.acss.min-saude.pt/Portals/0/Fornecedores%20MCDT_22out2012.pdf.
11 Software wClínicas,
20
Por fim, de notar que não é observada qualquer referência ao facto da aplicação wClínicas poder funcionar temporariamente sem conexão à internet. Uma das funcionalidades do Clinidata® será a existência de uma base de dados local onde poderão, por exemplo, ser registadas inscrições de utentes que depois serão sincronizadas com o servidor quando o sistema estiver novamente conectado.
3.2 MCDT Global
Esta aplicação12 desenvolvida pela empresa GlobalSoft BSC13 é um módulo de
prescrição electrónica de medicamentos que tem como função a elaboração e emissão de receitas médicas electrónicas.
Tem como principais características a possibilidade de funcionar offline, ou seja, não necessita de estar ligado à internet para efectuar a prescrição de receitas, permite a elaboração de receitas através da ficha clínica do utente e a consulta dos dados do deste na Rede Nacional de Utentes (com a respectiva actualização na base de dados local). Permite também a integração com o restante sistema de gestão e clínico desenvolvido pela GlobalSoft BSC.
Uma das desvantagens que se pode verificar na descrição dos diferentes produtos desenvolvidos pela empresa, e que foi também referida anteriormente, é o funcionamento da aplicação apenas em ambiente Windows.
3.3 MedicineOne
O MedicineOne14 é uma aplicação de gestão clínica que gere informação clínica e administrativa dos utentes. É um software produzido e mantido pela empresa com o
12 Prescrição electrónica de medicamentos,
http://www.globalsoft.pt/PortalGlobalsoft/UserFiles/File/PDFs/PDFsSaude/PresElec.pdf.
13 GlobalSoft BSC, http://www.globalsoft.pt/PortalGlobalsoft/. 14 MedicineOne,
http://www.medicineone.net/Solu%C3%A7%C3%B5es/MedicineOne/Apresenta%C3%A7%C3%A3o/tabi d/129/Default.aspx
21
mesmo nome que se dedica inteiramente ao desenvolvimento de soluções para a área da saúde (tal como a Maxdata).
A aplicação MedicineOne apresenta muitas funcionalidades em comum com o SIPA-MCDT como por exemplo:
Prescrição electrónica de análises e MCDTs;
Gestão de marcações;
Capacidade de configurar alguns parâmetros da interface gráfica da aplicação, com a possibilidade de escolha de skins consoante as preferências do cliente. No entanto, analisando a descrição das funcionalidades na página web do produto foi possível verificar outra desvantagem, também presente em produtos anteriores: o facto da aplicação apenas executar em ambiente Windows.
De notar, como pontos positivos, o facto de a página web desta aplicação descrever com detalhe muitas informações úteis sobre a aplicação, tendo também vídeos15 com demonstrações de algumas funcionalidades, contrastando assim com a
maioria das aplicações de software para meios complementares de diagnóstico e terapêutica listadas pela Administração Central do Sistema de Saúde. É também possível transferir uma versão gratuita da aplicação, mas com menos funcionalidades16.
O MedicineOne distingue-se também positivamente dos anteriores pelo facto de permitir a sua utilização através do pagamento de uma subscrição, ou taxa de utilização (modelo Software-as-a-Service, mais comumente denominado de SaaS). Deste modo, ao contrário do cenário habitual, não é necessária a aquisição de servidores e de licenciamento de software servidor, permitindo ao cliente utilizar o software apenas com uma ligação à internet. Os dados ficam guardados na cloud e, portanto, com uma alta taxa de disponibilidade [11] (alguns cloud providers, como por exemplo a Amazon através do seu serviço Amazon EC217, garantem um nível de disponibilidade de
99.85%). Outra vantagem consiste na redução do total cost of ownership (TCO), que pode ultrapassar os 80% em alguns casos [12]. A única desvantagem desta aplicação
15 Tutorial para a prescrição de medicamentos no MedicineOne,
http://www.mymedicineone.com/prescricao-medicamentos.aspx.
16 Módulos disponíveis nas várias versões do software MedicineOne,
http://www.mymedicineone.com/modulos-disponiveis.aspx.
22
neste aspecto, é mesmo a não utilização de um browser como cliente, como tipicamente acontece no modelo SaaS [13].
3.4 Orkos
O Orkos18 é um conjunto de aplicações móveis e serviços online, na área da saúde, para
médicos e utentes. Os principais pontos positivos do Orkos são a possibilidade do médico prescrever medicamentos e MCDT a partir de qualquer local uma vez que o Orkos tem uma aplicação web19 e tem também uma aplicação para dispositivos com o
sistema operativo Android20 que não permite a prescrição de MCDTs, mas permite a
prescrição de medicamentos21, bem como a pesquisa de medicamentos equivalentes. Uma funcionalidade interessante da aplicação Android consiste no Scan do código de barras de embalagens de medicamentos que identifica imediatamente o medicamento, permitindo verificar no momento se existem alternativas e quais os seus preços.
3.5 iCare
O iCare22, desenvolvido pela empresa CimpleCare, é uma plataforma WebBased
destinada a hospitais, clínicas, consultórios, laboratórios entre outras instituições de saúde. Tem como principais funcionalidades o registo clínico de consultas, registo de alertas clínicos, elaboração de relatórios médicos, gestão de marcações e prescrição electrónica de medicamentos e de MCDT’s.
A aplicação iCare pode ser fornecida como “hosted service” (funcionando num modelo SaaS como o MedicineOne) a consultórios médicos e clínicas de pequena dimensão que deste modo não precisam de adquirir licenças e servidores próprios para utilizar o sistema, sendo também possível fornecer o serviço em servidores numa instalação local a instituições que prefiram ter os seus próprios servidores. Apesar da
18 Orkos, http://www.orkos.pt/.
19 Orkos Online, https://online.orkos.pt/Account/Register. 20 Android, http://www.android.com/.
21 Orkos Medicamentos, http://www.orkos.pt/medicamentos/. 22 iCare, http://cimplecare.eu/sitecc/pk_website.v_index.
23
aplicação ser cross-platform (uma vez que executa no browser, pode ser executada em qualquer sistema operativo, sem a necessidade de instalar qualquer tipo de software adicional na máquina local), no website da aplicação é referido que esta está configurada para utilizar o browser Internet Explorer (versão 8.0 ou superior) ou o
browser Opera (9.6 ou superior), não sendo referido se esta aplicação funcionará
noutros browsers mais populares23 como o Firefox ou o Chrome. É também referido na
secção de notícias que o browser Safari também já suporta a aplicação e que esta pode assim ser executada no iPad.
3.6 Outros
Quanto às restantes aplicações listadas pela Administração Central do Sistema de Saúde grande parte carece de informação nas respectivas páginas web sobre as suas funcionalidades (como por exemplo o Clinicare, o DOCbase ou o MCDT Module), enquanto que outras não se diferenciam muito das que foram apresentadas anteriormente. Pode verificar-se que a maior parte das aplicações executam apenas em ambientes Windows, mas a tendência será para executarem em ambiente web, para que possam assim ser utilizadas em dispositivos móveis, permitindo aos utilizadores o acesso à informação on-the-go.
25
Capítulo 4
Análise e Desenho
Neste capítulo são descritos os requisitos, o modelo de dados e a arquitectura aplicacional do módulo desenvolvido neste PEI.
4.1 Requisitos
Segundo Pressman[5], podemos definir três conjuntos de requisitos:
Requisitos normais: reflectem os objectivos estabelecidos para a aplicação durante as reuniões com o cliente. Exemplos destes requisitos são funções específicas da aplicação e níveis de desempenho definidos.
Requisitos esperados: são requisitos que estão implícitos na aplicação e são tão fundamentais que o cliente não se refere a eles explicitamente. Exemplos de requisitos esperados são a facilidade de interacção homem-máquina, correcção e confiabilidade operacional e facilidade de instalação.
Requisitos opcionais: são aqueles que reflectem características que vão além das expectativas do cliente e mostram ser muito satisfatórias quando presentes. Na Maxdata, os requisitos são catalogados de forma semelhante, pois os requisitos são classificados como obrigatórios ou opcionais e a sua origem poderá ser do cliente (através de pedidos ou necessidades do cliente) ou poderá ser interna (resulta da estratégia definida pela empresa).
Deste modo, nesta secção, os requisitos da aplicação serão agrupados segundo os três tipos descritos anteriormente.
4.1.1 Requisitos normais
26
Inscrever um utente, ou seja, a criação de um atendimento, com um ou mais pedidos médicos;
Editar os dados de um atendimento:
Adicionar novos pedidos ao atendimento; Eliminar pedidos existentes;
Alterar dados do atendimento como a sala e a cama onde ficou o doente ou a data de internamento.
Eliminar um atendimento e, por sua vez, eliminar todos os pedidos associados a este;
Duplicar um atendimento, ou seja, criar um novo atendimento a partir de outro para depois o utilizador alterar os dados que desejar;
Alterar um pedido de um determinado atendimento:
Adicionar exames ao pedido, através de uma procura pelo código do exame e/ou por partes do nome do exame;
Eliminar exames do pedido;
Alterar particularidades de exames associados ao pedido, como por exemplo, a sua urgência, se é para facturar ou se é para realizar (ou ambos);
Alterar os dados do próprio pedido, como por exemplo a entidade e o plano para a facturação, o médico que prescreveu os exames desse pedido ou informação clínica relacionada com este.
4.1.2 Requisitos esperados
O módulo desenvolvido tem os seguintes requisitos esperados:
Este módulo, tal como toda a aplicação Clinidata®, deverá ser
cross-browser, ou seja, terá um comportamento similar ao ser executado nos browsers mais comuns24, incluindo o Internet Explorer, Google Chrome, Mozilla Firefox e Apple Safari;
Tendo em conta que nem todos os clientes utilizam o mesmo tipo de sistema de gestão de bases de dados, o SIPA-MCDT e toda a aplicação Clinidata® deverão ser independentes do SGBD utilizado, ou seja,
27
poderão executar sobre os SGBDs mais comuns, incluindo Oracle
Database, Microsoft SQL Server, PostgreSQL e MySQL;
A aplicação terá diversos tipos de utilizadores, uns mais experientes do que outros e, de acordo com Sainfort et al. [14]25 alguns dos principais
desafios para as aplicações de software na área da saúde passam pela personalização e pela adaptação, ou seja, conseguir configurar vários aspectos da aplicação de maneira a responder facilmente às diversas preferências dos vários perfis de utilizador. Deste modo, para melhorar a usabilidade, a aplicação também deve ser configurável de diversas maneiras:
Deve ser possível mudar o tema da aplicação, variando as cores; A disposição dos campos nos ecrãs deve ser editável, ou seja, o
utilizador deve conseguir editar a ordem de determinados campos de edição para aparecerem primeiro os que para si são mais importantes. Do mesmo modo, se os campos não forem obrigatórios, deve ser também possível removê-los da interface. Deverão também existir atalhos para utilizadores mais experientes para que a introdução de dados seja mais prática e eficiente;
A aplicação deverá ser independente do idioma, ou seja, deverá ser possível traduzir toda a aplicação para um idioma diferente do original sem ter que alterar o código da aplicação;
Por último, o desempenho é outro requisito essencial pois serão manipuladas quantidades consideráveis de dados e, deste modo, as pesquisas e as operações sobre o modelo de dados deverão ser rápidas e eficazes, de forma a garantir um desempenho aceitável.
4.1.3 Requisitos opcionais
Os requisitos opcionais são alguns requisitos que serão desenvolvidos em versões posteriores do Clinidata®, sendo também essenciais para, por exemplo, conquistar mercado em alguns países. Um exemplo de um requisito opcional é a possibilidade de realizar inscrições sem acesso à Internet, através da existência de uma base de dados
28
local onde poderão ser registadas as inscrições de utentes que depois serão sincronizadas com o servidor quando o sistema estiver novamente conectado.
Não é aqui apresentada a lista completa de requisitos opcionais uma vez que a duração do PEI não permitiu endereçar a totalidade destes requisitos.
4.2 Modelo de dados
O modelo de dados da aplicação é um modelo relacional e os dados poderão ser armazenados em diversos sistemas de gestão de bases de dados relacionais (ou SGBDR).
As tabelas do modelo relacional da aplicação encontram-se nomeadas do seguinte modo:
Tabelas de configuração: armazenam toda a informação relacionada com a configuração da aplicação, como por exemplo labels, tamanhos default das janelas da aplicação, ícones, etc. Tipicamente estas tabelas têm tamanho reduzido, bem como o seu crescimento. Este tipo de tabela é identificado com o prefixo “TB” no seu nome, por exemplo TBW_OPTION (tabela das opções) ou TBW_EX_EXAM (tabela de configuração de exames);
Tabelas de dados: armazenam dados oriundos das transacções efectuadas a partir das funcionalidades da aplicação. Estas tabelas podem atingir dimensões muito elevadas, dependendo do tipo de dados armazenados, e da dimensão do cliente. São identificadas pelo prefixo “DT” no seu nome, por exemplo DTW_PATIENT (tabela dos pacientes) ou DTW_EPISODE (tabela dos atendimentos).
4.2.1 Entidades e Relações
Esta secção pretende detalhar cada uma das entidades do modelo de dados bem como as relações e dependências entre estas. A cada entidade, também designada como objecto do domínio, corresponde uma tabela.
29
26 Oracle SQL Developer,
30
4.2.1.1 Entidade Paciente (DTW_PATIENT)
A tabela DTW_PATIENT, representada na figura 3, corresponde à entidade paciente, contendo a última versão dos dados pessoais actualizados do paciente (ou doente).
27 Médis, http://www.medis.pt/. 28 Medicare, http://www.medicare.pt/.
31
Figura 3. Tabela DTW_PATIENT relativa aos dados do paciente.
32
4.2.1.2 Entidade Atendimento (DTW_EPISODE)
A tabela DTW_EPISODE, representada na figura 4, corresponde à entidade atendimento, contendo os dados relativos ao atendimento do doente, que pode incluir
um ou vários pedidos .
33
34
4.2.1.3 Entidade Exame do Atendimento (DTW_EPISODE_EXAM)
A tabela DTW_EPISODE_EXAM, representada na figura 5, corresponde à entidade exame do atendimento, contendo apenas os exames do atendimento que são para realizar (alguns dos exames poderão ser só para facturar29). De notar que os
exames que se repitam por vários pedidos num atendimento, nesta tabela figuram apenas uma vez. Por exemplo, se um atendimento tiver dois pedidos e nesses dois pedidos cada um contiver um Hemograma, então nesta tabela existirá apenas um Hemograma para realizar.
Figura 5. Tabela DTW_EPISODE_EXAM que contém todos os exames para realizar de todos os atendimentos.
35
4.2.1.4 Entidade Pedido (DTW_REQUISITION)
A tabela DTW_REQUISITION corresponde à entidade pedido, contendo todos os pedidos de cada atendimento. Geralmente, existe um pedido diferente por médico, por entidade (“Médis”, por exemplo) ou por plano (“Plano Sénior”, por exemplo).
36
Figura 6. Tabela DTW_REQUISITION relativa aos dados do pedido.
4.2.1.5 Entidade Exame do Pedido (DTW_REQ_EXAM)
A tabela DTW_REQ_EXAM corresponde à entidade exame do pedido, contendo todos os procedimentos (não só exames mas também perfis ou conjuntos de exames, medicamentos, portes e domicílios) inscritos em pedidos.
38
39
40
4.3 Arquitectura da aplicação
Nesta secção é detalhado o desenho arquitectural da aplicação em geral, com foco especial no módulo desenvolvido no âmbito deste PEI.
4.3.1 Model-View-Presenter
Apesar da utilização do Google Web Toolkit30 (ou GWT) facilitar um pouco as tarefas da
equipa de desenvolvimento neste projecto (como explicado na secção 5.5), existem sempre dificuldades no desenvolvimento de aplicações de larga escala. Se não forem definidos padrões de desenho para criar áreas específicas de responsabilidade no projecto, vários programadores a trabalhar simultaneamente sobre o mesmo código pode levar rapidamente ao desenvolvimento de código de difícil manutenção no futuro.
De entre vários padrões de desenho populares a nível arquitectural [16], como por exemplo o Model-View-Controller (MVC) ou o Presentation-Abstraction-Control, concluiu-se que o Model-View-Presenter (MVP) é a arquitectura que melhor se adequa ao desenvolvimento de aplicações GWT [17] por duas razões principais, a saber: (i) tal como noutros padrões de desenho, existe uma distribuição do desenvolvimento em várias áreas, permitindo aos programadores trabalhar em simultâneo; (ii) em ambiente de testes, este modelo permite a execução de testes unitários mais rapidamente uma vez que é reduzida a utilização da classe GWTTestCase31, que é utilizada para testar código
que necessite de javascript em tempo de execução e que assenta assim na presença de um browser. No cerne do padrão MVP está a separação da funcionalidade em componentes que façam sentido logicamente mas, no caso do GWT existe um claro objectivo em tornar a view o mais simples possível de modo a minimizar a utilização da classe GWTTestCase e, tal como foi referido anteriormente, reduzir assim o tempo gasto na execução de testes unitários, uma vez que grande parte do código, como é
30 Google Web Toolkit, http://www.gwtproject.org/. 31 GWTTestCase,
41
desenvolvido em Java, pode ser testado utilizando por exemplo o JUnit32, uma
ferramenta madura para testes unitários de código Java.
Uma característica comum entre os vários padrões arquitecturais mais utilizados para construir e testar a GUI (Graphical User Interface) de uma aplicação consiste no objectivo de remover o máximo de lógica da view para colocá-lo em camadas mais facilmente testáveis. No MVP, o presenter assume um papel de mediador entre a view (GUI) e os objectos do model e comunica à view para alterar o seu estado em resposta a
inputs do utilizador ou a mudanças no model. Este padrão é muito similar ao MVC,
contudo, ao invés de conter a lógica de apresentação partilhada entre o Controller e a
View, no MVP toda esta lógica de apresentação situa-se no Presenter [18].
Figura 8. Padrão arquitectural MVC (Model-View-Controller).
42
Figura 9. Padrão arquitectural MVP (Model-View-Presenter).
Tal como se pode verificar, através da comparação do diagrama da figura 8 com o da figura 9, no MVC a view, aquando da recepção de inputs por parte do utilizador, modifica o model através de um controller mas acede directamente ao model para alterar o seu estado e mostrar os outputs ao utilizador. No entanto, no padrão MVP a
view não acede ao model directamente, todas as mudanças e todas a queries ao model
são efectuadas através de um presenter que funciona assim como um intermediário entre a view e o model.
4.3.2 Diagramas de packages e de classes
Antes do início do desenvolvimento deste módulo foi planeada a estrutura dos vários packages e das várias classes a desenvolver, de modo a definir uma estrutura antes do desenvolvimento do código. Esta estrutura foi actualizada e melhorada durante o desenvolvimento e fará parte da documentação da aplicação.
43
Figura 10. Notação utilizada no diagrama de packages e de classes.
Figura 11. Visão geral do package “client” daaplicação.
33 O documento de análise utilizado como base para o desenvolvimento da aplicação deste PEI
utiliza várias vezes o nome “Gestão de Pedidos” que engloba toda a parte de agendamento e prescrição de exames, bem como a inscrição de doentes.
44
45
46
Figura 14. Visão geral do package “server”.
34 GWT Remote Procedure Calls,
47
4.3.3 Diagramas de actividades e de sequência
48
49
Figura 16. Diagrama de actividades para a eliminação de um atendimento ou de um pedido.
51
4.3.4 Protótipos
No documento de análise utilizado para o desenvolvimento do módulo SIPA-MCDT, para além dos requisitos da aplicação, são também apresentados vários protótipos de média fidelidade[4], acompanhados de descrições das acções que cada componente da interface irá desencadear aquando da interacção do utilizador com estas. Estes protótipos serviram de base para o desenvolvimento dos diagramas de actividade apresentados na secção anterior e, por sua vez, os diagramas de actividade vieram melhorar o encadeamento entre os vários ecrãs da aplicação uma vez que foram descobertas várias falhas que iram só aparecer na fase de desenvolvimento.
Nesta secção são apresentados alguns protótipos do documento de análise para ser possível verificar que a aplicação final ficou praticamente idêntica ao idealizado inicialmente pelos analistas.
52
4.3.4.1 Ecrã Inicial
53
Figura 18. Protótipo do ecrã de pesquisa de atendimentos ou pacientes.
