UNIVERSIDADE DE LISBOA · 2018. 10. 31. · UNIVERSIDADE DE LISBOA. Faculdade de Ciências ....
114
UNIVERSIDADE DE LISBOA 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 2013
Transcript of UNIVERSIDADE DE LISBOA · 2018. 10. 31. · UNIVERSIDADE DE LISBOA. Faculdade de Ciências ....
UNIVERSIDADE DE LISBOA 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
2013
UNIVERSIDADE DE LISBOA 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 Silva
e co-orientado pelo Doutor Paulo Jorge Paiva de Sousa
2013
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.
À minha família e amigos.
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
ii
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.
Keywords: prescription, scheduling, diagnosis, therapeutic, model-view-presenter
iv
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
4.2.1.1 Entidade Paciente (DTW_PATIENT) ......................................... 30
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
Abreviaturas .......................................................................................................... 86
vii
Glossário ............................................................................................................... 88
Bibliografia ........................................................................................................... 90
viii
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
xi
xii
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
xiv
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
1 Maxdata, http://www.maxdata.pt/.
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
de Diagnóstico e Terapêutica.
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.
6
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
3 NID - Número de Identificação (interno da aplicação).
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.
17
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. 9 SNS, Serviço Nacional de Saúde.
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, http://cms.wintouch.pt/index.php/products-solutions/healthcare/44-pt-
clinicas/51-pt-clinicas.
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. 17 Amazon Elastic Compute Cloud EC2, http://aws.amazon.com/pt/ec2/.
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.
23 Browser statistics, http://www.w3schools.com/browsers/browsers_stats.asp.
24
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
O módulo desenvolvido tem os seguintes 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,
24 Browser Statistics, http://www.w3schools.com/browsers/browsers_stats.asp.
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
25 Mais precisamente no capítulo 33, intitulado “Human-Computer Interaction in Health Care”.
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, http://www.oracle.com/technetwork/developer-tools/sql-
developer/overview/index.html.
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 .
Figura 4. Tabela DTW_EPISODE relativa aos dados do atendimento.
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.
29
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
Figura 7. Tabela DTW_REQ_EXAM que contém todos os exames dos pedidos.
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, http://google-web-
toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/junit/client/GWTTestCase.html.
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).
32 JUnit, http://www.junit.org.
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” da aplicaçã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
Figura 12. Visão geral das classes existentes no client-side da Gestão de Pedidos.
45
Figura 13. Visão geral do package “shared” da aplicação.
46
Figura 14. Visão geral do package “server”.
34 GWT Remote Procedure Calls, https://developers.google.com/web-
toolkit/doc/latest/tutorial/RPC.
47
4.3.3 Diagramas de actividades e de sequência
35 Para a gestão de transacções é utilizada a framework Spring, que é mais detalhada na secção 5.4.
48
Figura 15. Descrição das várias componentes utilizadas no diagrama de actividades.
49
Figura 16. Diagrama de actividades para a eliminação de um atendimento ou de um pedido.
50
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
Figura 17. Protótipo do ecrã inicial da opção "Gestão de Pedidos".
53
Figura 18. Protótipo do ecrã de pesquisa de atendimentos ou pacientes.
4.3.4.2 Exibição e alteração de dados
54
Figura 19. Protótipo do ecrã de exibição do atendimento (e dos pedidos) de um paciente.
55
Figura 20. Protótipo da visão Administrativa sobre os exames do pedido.
Figura 21. Protótipo do pop-up utilizado para colocar um exame para realizar ou para não realizar.
56
57
Capítulo 5
Codificação
Neste capítulo são descritas as diferentes tecnologias e frameworks utilizadas na
codificação do SIPA-MCDT, bem como as razões para a sua utilização. No final do
capítulo, são apresentados alguns casos de uso da aplicação, demonstrando assim o seu
funcionamento, e também alguns dos resultados obtidos.
5.1 Java
Toda a aplicação foi desenvolvida utilizando a linguagem de programação Java36, que é
de resto uma das tecnologias mais populares e utilizadas em todo o mundo. O código
nesta linguagem é compilado para bytecode e executado por uma máquina virtual (a
Java Virtual Machine), fornecendo desta maneira uma camada de abstracção que
garante independência da plataforma onde executa.
A escolha do Java para este projecto deveu-se principalmente ao facto da
framework GWT (descrita na secção 5.5) utilizar Java para o lado do cliente e, deste
modo, com o back-end desenvolvido também em Java, é utilizada uma linguagem para
todo o projecto sendo possível a partilha de código entre o cliente e o servidor.
5.2 SGBDs – Sistemas de Gestão de Bases de dados
Neste PEI, os sistemas de gestão de bases de dados utilizados foram o Oracle
Database37 e o PostgreSQL Server
38, uma vez que a maioria dos clientes actuais da
36 Java, http://www.java.com/en/download/whatis_java.jsp. 37 Oracle Database, http://www.oracle.com/technetwork/database/enterprise-
edition/overview/index.html.
58
Maxdata utiliza o primeiro enquanto que os restantes utilizam o segundo. Apesar de
serem relativamente semelhantes, existem algumas diferenças a nível sintaxe do SQL
[22] e o Oracle Database fornece um melhor desempenho [23]. No entanto, as suas
licenças são dispendiosas, o que faz com que muitos clientes de menor dimensão optem
por sistemas como o PostgreSQL.
5.3 Hibernate
O Hibernate39 é uma biblioteca ORM
40 desenvolvida primeiramente para Java, com o
objectivo de fornecer uma framework que permitisse mapear objectos pertencentes ao
modelo do domínio em objectos equivalentes no respectivo modelo relacional inerente à
bases de dados, formando assim uma camada de persistência transparente, onde as
diferentes tabelas da base de dados são representadas em classes java que lhes são
equivalentes, reflectindo e persistindo as alterações sobre esses objectos (denominados
de POJOs41) na tabela correspondente.
O Hibernate tem a sua própria linguagem para efectuar queries, denominada de
HQL42, permitindo a construção de queries com uma estrutura semelhante ao típico
SQL, com a diferença que estas são executadas sobre objectos mapeados pelo
Hibernate. Na figura 22 está representado um exemplo da utilização de HQL no módulo
desenvolvido. Neste exemplo, é obtida a colheita (collection) através do id recebido
como argumento no método getCollection. Como se pode observar, a query HQL é
construída nas linhas 7 e 8, sendo depois utilizada na instanciação do objecto Query nas
linhas 10 e 11. A variável id recebida como argumento no método é depois associada ao
wild-card “:id” da query HQL na linha 13 e, por fim, é efectuada a query na linha 15 e o
resultado é retornado na linha 21.
38 PostgreSQL, http://www.postgresql.org/. 39 Hibernate, http://www.hibernate.org/. 40 ORM – Object Relational Mapping, http://www.hibernate.org/about/orm. 41 POJO – Plain Old Java Object, http://www.martinfowler.com/bliki/POJO.html. 42 HQL – Hibernate Query Language,
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/queryhql.html.
59
Figura 22. Exemplo da utilização de HQL na aplicação.
Foi também utilizada uma funcionalidade do Hibernate que se revelou muito útil
para o controlo de acesso concorrente a determinadas entidades. Uma vez que podem
existir dois (ou mais) utilizadores a alterar o mesmo atendimento, é necessário controlar
estas modificações.
A estratégia definida consiste em ter uma coluna na tabela DTW_EPISODE com
um número que é incrementado uma unidade a cada edição. Quando um utilizador tenta
gravar um atendimento e este número não está actualizado é lançada uma
StaleObjectStateException43 que depois é capturada no lado do cliente e são carregados
os dados actualizados. Todo este processo é efectuado automaticamente pelo Hibernate
bastando para isso colocar a anotação “@Version” sobre a propriedade do objecto do
domínio a utilizar para o controlo de modificações.
Na figura 23 é possível observar a sequência de acções que dão origem ao
problema descrito anteriormente, bem como a solução encontrada para a sua resolução.
Temos dois utilizadores, Bob e Alice, que carregam o mesmo atendimento (ou seja, um
episode com id 3 e version 101) para os seus browsers e efectuam várias alterações
sobre este. No entanto, o Bob é o primeiro a gravar as suas alterações, sendo o campo
version incrementado uma unidade (para 102). Quando a Alice gravar as suas alterações,
o número de linhas actualizadas será 0, pois já não existe nenhum atendimento com a
versão 101, e será assim lançada uma StaleObjectStateException que depois é
43 StaleObjectStateException,
http://docs.jboss.org/hibernate/stable/core.old/api/org/hibernate/StaleObjectStateException.html
60
devidamente tratada no lado do cliente (ou seja, no browser). O tratamento da excepção
consistirá no aparecimento de um alerta a avisar que outro utilizador alterou os dados
desse atendimento e no carregamento dos dados actualizados.
Figura 23. Diagrama representativo do problema e da solução para as modificações concorrentes a um atendimento.
Na figura 24 podemos observar um excerto do código SQL gerado pelo
Hibernate aquando da actualização do atendimento. Na cláusula where (linhas 10 e 11)
podemos verificar que consta o id e a versão do atendimento que fará com que no caso
da Alice, tal como já foi referido, não seja actualizada qualquer linha na base de dados
61
pois a versão já foi incrementada em uma unidade aquando da gravação do atendimento
por parte do Bob.
Figura 24. Exemplo de código SQL gerado pelo Hibernate aquando da actualização dos dados de um
atendimento.
Esta técnica tem o nome optimistic locking [18] [19] e, apesar da sua
implementação ser simples, tem como limitação o facto do utilizador, neste caso, a
Alice, perder as alterações que efectuou aquando do carregamento dos dados
actualizados. Outra solução passaria pelo pessimistic locking que impediria que a Alice
conseguisse carregar o mesmo atendimento que o Bob, ou vice-versa. No entanto, a
implementação desta solução seria mais complicada devido à possibilidade de
deadlocks, por exemplo, na seguinte situação: se o Bob estivesse com o atendimento x e
a Alice estivesse com o atendimento y e se Bob quisesse obter o atendimento y e a Alice
quisesse obter o atendimento x, um deles teria que libertar o seu primeiro. Após discutir
as diferentes soluções com a equipa de desenvolvimento, optou-se pelo optimistic
locking devido à simplicidade da implementação e também porque a alteração do
mesmo atendimento por dois ou mais utilizadores no mesmo período de tempo não será
muito comum.
Resumindo, o Hibernate fornece uma camada de abstracção entre a aplicação e
o SGBD relacional permitindo que a aplicação funcione de forma praticamente
transparente sobre os SGBDs mais utilizados. Tais factores são muito relevantes pois a
realidade do negócio implica um grau elevado de adaptabilidade.
62
5.4 Spring
O Spring44 é uma framework conceptualizada e desenvolvida para Java e é constituída
por vários módulos que fornecem uma gama de serviços abrangente. De entre as várias
funcionalidades listadas no sítio web da Spring framework45, destaco as de maior
relevância para a aplicação desenvolvida neste PEI e apresento exemplos da sua
utilização:
Injecção de dependências através de anotações: As classes Java devem ser o
mais independentes possível umas das outras de forma a serem reutilizáveis e
poderem ser testadas isoladamente. Este desacoplamento entre as classes é
conseguido através da injecção de dependências (dependeny injection [26]), que
assenta sobre o princípio da inversão de controlo (Inversion of Control [26])
onde a classe não se configura a si própria, sendo esta configurada no exterior.
Por exemplo, se a classe A precisa de um DAO (Data Access Object) para
receber dados de uma base de dados deverá ser possível testar a classe A através
da criação/configuração de um objecto (mock object [27]) que simule a ligação à
base de dados e que lhe forneça os dados necessários para testá-la.
A injecção de dependências é possível sem a utilização de uma framework como
o Spring, no entanto o Spring fornece funcionalidades interessantes para a
gestão dos objectos e do seu ciclo de vida. No contexto do Spring, os objectos
são denominados de Beans, e estes são configurados através de XML onde são
guardadas as suas definições e dependências. Esta abordagem permite a
configuração e personalização de uma forma simples e consistente.
44 Spring, http://www.springsource.org/. 45 Spring framework, http://www.springsource.org/spring-framework.
63
Figura 25. Exemplo da utilização das anotações do Spring para a injecção de dependências.
Na figura 25 temos um exemplo de código que demonstra a utilização das
anotações utilizadas no serviço46 dos pedidos (“RequisitionBC”) para injectar
outros serviços como o “IUserBC” e também o DAO dos pedidos (o
“IRequisitionDAO”). A anotação “@Autowired” marca um construtor, uma
variável ou um método setter como automaticamente “injectável” pela injecção
de dependências do Spring, ou seja, em runtime o Spring irá tentar corresponder
as variáveis anotadas com “@Autowired” aos beans declarados no ficheiro de
configuração XML. Neste caso, as variáveis serão injectadas logo após a
construção do bean, antes de qualquer método ser invocado. Por fim, a anotação
“@Service” na linha 1 identifica a classe como sendo um serviço e faz com que
esta seja “auto detectada” aquando da inicialização do Spring, que a instanciará
nesse momento, ou seja, quando se inicia a aplicação no lado do servidor, o
Spring é também inicializado e instanciará todos os beans declarados no ficheiro
de configuração XML e com a anotação “@Service”.
Suporte para transacções declarativas: Uma transacção numa base de dados é
uma sequência de acções que é tratada como um único bloco, de modo a que
esta sequência de acções execute completamente ou então nenhuma delas surtirá
efeito. O Spring fornece um gestor de transacções que tem a capacidade de
propagar uma transacção entre vários métodos e de efectuar roll-back no caso de
ocorrer uma excepção. 46 Um serviço é constituído por uma série de métodos expostos de modo a poderem ser invocados
remotamente pela aplicação interna (por RPC) e/ou por aplicações externas (WebServices). Ver a secção
5.6.
64
Um exemplo da propagação de transacções no módulo SIPA-MCDT é a
inserção de um novo atendimento, que por sua vez irá “desencadear” uma série
de inserções em várias tabelas como por exemplo na tabela dos pedidos
(DTW_REQUISITION), na dos exames do atendimento
(DTW_EPISODE_EXAM) e também na dos exames do pedido
(DTW_REQUISITION_EXAM). Estas inserções são efectuadas por diferentes
métodos, iniciando-se a cadeia no método “insertEpisode”, responsável pela
inserção do atendimento. Tal como foi referido anteriormente, graças ao gestor
de transacções fornecido pelo Spring, se ocorrer por exemplo uma excepção
durante a inserção de um dos pedidos do atendimento, é efectuado roll-back e
nada é inserido.
5.5 GWT
O GWT47, brevemente referido em capítulos anteriores, é uma framework open-source
da Google que permite desenvolver RIAs48
usando a linguagem de programação Java. O
núcleo desta ferramenta é um compilador Java-to-Javascript (e também para HTML)
que transforma código Java em código Javascript e HTML, de forma a que estes
últimos possam ser interpretados nativamente pelos navegadores web mais comuns.
A tradicional arquitectura cliente-servidor é utilizada pelo GWT e a comunicação
é efectuada através de RPCs49 assíncronas, seguindo a metodologia definida para a Web
2.0 através da utilização de AJAX50.
De entre os vários módulos do GWT destacam-se os seguintes:
Dev Mode51
: Este módulo permite aos programadores executar código
cliente do GWT numa JVM, ou seja, o código cliente não é compilado
para JavaScript. Contudo, é necessário instalar um plugin no navegador
web, para que o código Java seja interpretado;
47 Google Web Toolkit, https://developers.google.com/web-toolkit/overview. 48 Rich Internet Applications 49 Remote Procedure Calls 50 Asynchronous Javascript and XML
51 GWT DevMode, https://developers.google.com/web-
toolkit/doc/latest/DevGuideCompilingAndDebugging#dev_mode.
65
Biblioteca de emulação do JRE52
: Neste módulo estão as
implementações em JavaScript de grande parte das classes
disponibilizadas no ambiente de execução do Java pertencentes aos
packages java.lang e java.util;
Biblioteca de componentes visuais: O GWT disponibiliza uma série de
widgets53 que podem servir como base para componentes gráficos mais
elaborados;
Compilador: Por fim o compilador, que é base da framework e que é
responsável pela “tradução” de código Java para código Javascript e
HTML, de modo a que a aplicação execute nativamente num browser. O
compilador efectua ainda vários processos de optimização como remoção
de código não utilizado (ou código “morto”) e também ofuscação de
código, reduzindo o tamanho deste para que a sua transmissão na rede
seja mais rápida. Uma vantagem adicional muito importante consiste na
compilação de código Javascript e HTML apropriados para os diferentes
browsers no mercado.
52 JRE Emulation Reference,
https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation. 53 Widget Gallery, https://developers.google.com/web-toolkit/doc/1.6/RefWidgetGallery.
66
5.6 Arquitectura em camadas
Nesta secção é apresentada a arquitectura global da aplicação em camadas de modo a
definir o contexto onde cada uma das frameworks descritas anteriormente é utilizada.
Figura 26. Arquitectura da aplicação em camadas.
Como se pode observar na figura 26, a arquitectura da aplicação é composta por 4
camadas diferentes: Fontes de dados, Acesso aos dados, Negócio e Apresentação.
Na camada de fontes de dados é onde residem os dados com as informações
utilizadas na aplicação. As fontes podem ser bases de dados Oracle, PostgreSQL ou
outro tipo de bases de dados mais comuns, mas também podem ser Web Services
externos como por exemplo no caso das seguradoras, que disponibilizam Web Services
para consultar os preços de um exame num determinado plano, de modo a calcular o
valor final a facturar.
67
Na camada de acesso aos dados residem as interfaces de acesso que formam uma
camada de abstracção sobre as fontes de dados. Esta abstracção é conseguida utilizando
a framework Hibernate como foi explicado na secção 5.3.
Na camada de negócio residem as interfaces dos serviços que são constituídos por
uma série de métodos expostos de modo a poderem ser invocados remotamente pela
camada de apresentação (por RPC) e/ou por aplicações externas. A gestão de
transacções do Spring, explicada na secção 5.4 é transversal às camadas de negócio e de
acesso aos dados, uma vez que as transacções são propagadas entre as chamadas dos
serviços aos DAOs que residem na camada de acesso aos dados.
Por fim, no topo temos a camada de apresentação onde reside a interface com o
utilizador (desenvolvida com a framework GWT e constituída por HTML, CSS e
Javascript) e que executa nos Browsers mais comuns. Temos também aqui uma camada
de Web Services que expõe determinados serviços para aplicações externas através do
protocolo SOAP54.
5.7 Casos de Uso
Nesta secção são apresentados alguns casos de uso da aplicação desenvolvida neste PEI,
cada um com complexidade diferente. Estes casos de uso visam dar uma visão global da
aplicação e também para destacar alguns pormenores importantes do seu
desenvolvimento.
5.7.1 Configuração de ecrã
Apenas para dar um contexto geral de toda a aplicação, da qual faz parte o módulo
desenvolvido, neste caso de uso, para além da configuração do ecrã pelo utilizador, é
também apresentado o processo de autenticação do utilizador e o aspecto do seu
ambiente de trabalho. Ao contrário da configuração do ecrã e dos restantes casos de uso,
o login e o ambiente de trabalho do utilizador estavam já desenvolvidos aquando do
início deste PEI.
54 SOAP, Simple Object Access Protocol.
68
Figura 27. Ecrã de login do utilizador.
69
Figura 28. Ambiente de trabalho do utilizador na aplicação Clinidata®.
70
Figura 29. Exemplo de configuração do ecrã de Gestão de Pedidos.
71
Figura 30. Exemplo do ecrã de Gestão de Pedidos em modo de exibição.
5.7.2 Adição de exames a um pedido
72
Figura 31. Ecrã de Gestão de Pedidos em modo de edição e com um exame pronto a ser inserido.
73
Figura 32. Confirmação de gravação do atendimento após a inserção de um exame no 2º pedido.
5.7.3 Inserção de exames através de “botões de prescrição”
74
Figura 33. Exemplo de vários botões de prescrição de exames.
75
Figura 34. Exemplo de exames associados a um botão de prescrição.
5.7.4 Criação de um novo pedido
76
Figura 35. Introdução da razão para a criação de um novo pedido.
5.7.5 Eliminação de um atendimento
77
Figura 36. Adição de um pedido e exibição do separador relativo aos "Dados clínicos e hospitalares".
Figura 37. Confirmação da eliminação do pedido ou do atendimento.
78
Figura 38. Exibição de um atendimento eliminado.
5.7.6 Alterações de atributos dos exames
79
Figura 39. Exibição de uma possível configuração para a visão financeira sobre os exames.
Figura 40. Alteração do estado de um exame para "Não realizar".
80
Figura 41. Exibição de uma possível configuração para a visão técnica sobre os exames.
5.8 Resultados
81
82
83
Capítulo 6
Conclusão e Trabalho Futuro
Neste capítulo apresentam-se as conclusões retiradas de todo o processo de
desenvolvimento do SIPA-MCDT, bem como o trabalho ainda a desenvolver.
6.1 Conclusão
Ao longo deste documento foi detalhado o desenvolvimento de um sistema de
informação para prescrição e agendamento de meios complementares de diagnóstico e
terapêutica, desenvolvido de modo a que todos os requisitos especificados nos
documentos de análise fossem satisfeitos.
Na realização deste PEI foi possível adquirir experiência profissional, integrar
numa equipa jovem e dinâmica, contribuir para um projecto ambicioso e desafiante,
adquirir novos conhecimentos e cimentar aqueles que obtive durante a licenciatura e no
primeiro ano de mestrado.
Apesar dos testes ainda não terem sido efectuados aquando da escrita deste
relatório, pode-se concluir que o projecto foi realizado como inicialmente previsto uma
vez que o documento de análise foi seguido à risca durante o desenvolvimento, sendo
este também melhorado quando eram encontradas falhas ou lacunas.
6.2 Trabalho Futuro
Tal como já foi referido na secção 5.8, aquando da elaboração deste relatório os testes
ao SIPA-MCDT ainda não tinham sido efectuados e, deste modo, estes serão realizados
num futuro próximo de modo a efectuar as correcções necessárias. No futuro, antes da
comercialização da aplicação, a aplicação será também testada e avaliada por um
utilizador final (neste caso um médico que será contratado pela Maxdata, encontrando-
84
se neste momento em processo de recrutamento) de modo a efectuar testes de aceitação
[5]. De referir que este é um problema que foi várias vezes referido em diferentes
disciplinas durante o meu percurso académico e que foi possível observar “no terreno”:
o de encontrar utilizadores finais para testar a aplicação [28] [29] [30] e até mesmo para
colaborar na recolha de requisitos. A área da saúde não é excepção a este problema e,
apesar da solução para análise de requisitos colaborativa apresentada por Scandurra et
al. [30] ter obtido bons resultados, colocá-la em prática revela-se bastante difícil devido
à quantidade de tempo necessária para obter resultados.
Uma vez que o SIPA-MCDT, bem como toda a aplicação onde este se insere,
vai substituir as aplicações mais antigas da Maxdata (ver secção 1.1), não podemos
simplesmente descartar os dados produzidos por estas aplicações ao longo dos anos.
Assim sendo, todos estes dados têm de ser migrados para a base de dados da nova
aplicação. Esta migração de dados pode ser considerada como um processo ETL60 pois
os dados são extraídos das bases de dados utilizadas pelas aplicações antigas, sendo
depois transformados de modo a efectuar o mapeamento para o esquema da base de
dados de destino e, por fim, são carregados para esta última. Nesta parte uma ferramenta
essencial será o Mirth61, que é uma ETL tool muito utilizada na área da saúde [31].
Por fim, há que integrar o SIPA-MCDT com outros módulos da aplicação,
nomeadamente com o módulo responsável pelo agendamento de consultas e de
colheitas e também com o módulo da facturação que será desenvolvido de maneira a
isolar esta área o mais possível, uma vez que apresenta um elevado nível de
complexidade e é muito susceptível a mudanças.
60 ETL, Extraction Transformation Load. 61 Mirth, http://www.mirthcorp.com/.
85
86
Abreviaturas
AJAX Asynchronous Javascript and XML
CSS Cascading Style Sheet
CVS Concurrent Versions System
DAO Data Access Object
ETL Extraction, Transformation, Load
GUI Graphical User Interface
GWT Google Web Toolkit
HQL Hibernate Query Language
HTML HyperText Markup Language
JRE Java Runtime Environment
JVM Java Virtual Machine
MCDT Meios Complementares de Diagnóstico e Terapêutica
MVC Model-View-Controller
MVP Model-View-Presenter
NID Número de Identificação
ORM Object Relational Mapping
PEI Projecto em Engenharia Informática
POJO Plain Old Java Object
RIA Rich Internet Applications
RPC Remote Procedure Call
SaaS Software-as-a-Service
SGBD Sistema de Gestão de Bases de dados
SIPA-MCDT Sistema de Informação para Prescrição e Agendamento de Meios
Complementares de Diagnóstico e Terapêutica
SNS Serviço Nacional de Saúde
SOAP Simple Object Access Protocol
87
SQL Structured Query Language
TCO Total Cost of Ownership
UML Unified Modeling Language
XML Extensible Markup Language
Tabela 2. Abreviaturas utilizadas no relatório.
88
Glossário
Atendimento Uma inscrição, ou atendimento, corresponde a uma visita de um utente
ao laboratório. Um atendimento é constituído por um ou mais pedidos. Inscrição
Pedido Pedidos, ou requisições, são prescrições de exames.
Requisição
Tabela 3. Glossário com alguns dos conceitos utilizados no relatório.
89
90
Bibliografia
[1] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “A view of cloud computing,” Commun. ACM, vol. 53, no. 4, pp. 50–58, 2010.
[2] D. Lewis, “What is web 2.0?,” Crossroads, vol. 13, no. 1, p. 3, 2006.
[3] T. Tamai and Y. Torimitsu, “Software lifetime and its evolution process over generations,” Proceedings Conference on Software Maintenance 1992, pp. 63–69.
[4] D. Engelberg and A. Seffa, “A Framework for Rapid Mid-Fidelity Prototyping of Web Sites,” in Proceedings of the IFIP 17th World Computer Congress - TC13
Stream on Usability: Gaining a Competitive Edge, 2002, pp. 203–215.
[5] Roger S. Pressman, Software engineering: a practitioner’s approach, 5th ed. 2001.
[6] A. Bjork, “Agile Development and the Daily Standup Meeting,” Visual Studio
Magazine, 2011.
[7] J. Atwood, “Code Reviews: Just Do It,” 2006. [Online]. Available: http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html.
[8] “Code Reviews, what are the advantages?” [Online]. Available: http://programmers.stackexchange.com/questions/71654/code-reviews-what-are-the-advantages.
[9] L. Clevesy and G. Sporar, “What Makes Peer Code Review an Agile Process?,” 2010. [Online]. Available: http://agile.dzone.com/articles/what-makes-peer-code-review-agile.
[10] D. Galvoeira, “Meios complementares de diagnóstico e terapêutica,” Plataforma
Barómetro Social, 2011. [Online]. Available: http://barometro.com.pt/archives/447.
[11] M. Creeger, “Cloud Computing: An Overview,” Queue, vol. 7, no. 5, pp. 2:3–2:4, 2009.
[12] J. Varia, “The Total Cost of ( Non ) Ownership of Web Applications in the Cloud,” vol. 2012, no. August, pp. 1–30, Aug-2012.
91
[13] D. Singleton, “What is SaaS? 10 Frequently Asked Questions About Software as a Service,” Software Advice, 2011. [Online]. Available: http://blog.softwareadvice.com/articles/enterprise/saas-faqs-1072811/.
[14] J. A. Jacko and A. Sears, Eds., The human-computer interaction handbook:
fundamentals, evolving technologies and emerging applications. Hillsdale, NJ, USA: L. Erlbaum Associates Inc., 2003.
[15] R. Ramakrishnan and J. Gehrke, Database Management Systems, 2nd ed. New York, NY, USA: McGraw-Hill, Inc., 1999.
[16] P. Avgeriou and U. Zdun, “Architectural Patterns Revisited–A Pattern Language,” in 10th European Conference on Pattern Languages of Programs
(EuroPlop 2005), 2005, pp. 1–39.
[17] C. Ramsdale, “Large scale application development and MVP.” [Online]. Available: https://developers.google.com/web-toolkit/articles/mvp-architecture.
[18] S. Chandel, “Testing Methodologies Using Google Web Toolkit,” 2009. [Online]. Available: https://developers.google.com/web-toolkit/articles/testing_methodologies_using_gwt.
[19] K. Fakhroutdinov, “UML 2.2 Diagrams Overview.” [Online]. Available: http://www.uml-diagrams.org/uml-22-diagrams.html.
[20] B. Lieberman, “UML Activity Diagrams : Detailing User Interface Navigation,” The Rational Edge, 2004. [Online]. Available: http://www.ibm.com/developerworks/rational/library/4697.html.
[21] M. Petre, “UML in practice,” in Proceedings of the 2013 International
Conference on Software Engineering, 2013, pp. 722–731.
[22] J. Shannon, B. Adida, and D. Baccus, “Oracle to Postgres Conversion.” [Online]. Available: http://wiki.postgresql.org/wiki/Oracle_to_Postgres_Conversion#Grammar_Differences.
[23] J. Berkis, “PostgreSQL publishes first real benchmark,” 2007. [Online]. Available: http://it.toolbox.com/blogs/database-soup/postgresql-publishes-first-real-benchmark-17470.
[24] C. Bauer and G. King, Java Persistence with Hibernate. Greenwich, CT, USA: Manning Publications Co., 2006.
[25] M. Fowler, Patterns of Enterprise Application Architecture. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002.
[26] M. Fowler, “Inversion of Control Containers and the Dependency Injection pattern,” 2004. [Online]. Available: http://www.martinfowler.com/articles/injection.html.
92
[27] M. Fowler, “Mocks Aren’t Stubs,” 2007. [Online]. Available: http://martinfowler.com/articles/mocksArentStubs.html.
[28] D. Travis, “Dealing with difficult usability test participants,” 2012. [Online]. Available: http://www.userfocus.co.uk/articles/dealing_with_difficult_usability_test_participants.html.
[29] D. Hinderer, “Challenges in participant recruiting for usability testing,” in Professional Communication Conference, 1998. IPCC 98. Proceedings. 1998
IEEE International, 1998, vol. 2, pp. 417–426 vol.2.
[30] I. Scandurra, M. Hägglund, and S. Koch, “From user needs to system specifications: multi-disciplinary thematic seminars as a collaborative design method for development of health information systems.,” Journal of biomedical
informatics, vol. 41, no. 4, pp. 557–69, Aug. 2008.
[31] J. Brauer, “Mirth: Standards-Based Open Source Healthcare Interface Engine,” 2008. [Online]. Available: http://timreview.ca/article/205.
[32] C. W. Johnson, “Why did that happen? Exploring the proliferation of barely usable software in healthcare systems.,” Quality & safety in health care, vol. 15 Suppl 1, pp. i76–81, Dec. 2006.
