Arquitetura do sistema

A aplicação a construir deverá conter as funcionalidades estudadas e confirmadas na secção 3.2. Para a construção de uma aplicação com estas funcionalidades foi necessário arquitetar um sistema que respondesse às necessidades.

A primeira questão relativa à arquitetura do software seria a forma de armazenamento da informação inserida e acedida pela aplicação. Inicialmente, foi pensado utilizar ficheiros de texto para o armazenamento simples e rápido da informação. No entanto, a complexidade revelada pela necessidade de haver relações entre médicos e pacientes, intervenções e medicações e médicos e especialidades veio alterar o sentido da forma de armazenamento da informação e alterá-lo para uma base de dados. Neste caso, os dados ficam muito mais organizados, de acesso facilitado, de simples edição e eliminação de registos e possíveis operações impossibilitadas pelo uso de ficheiros.

A arquitetura do sistema seria feita, então com uma aplicação a aceder e alterar a informação de uma base de dados. A seguinte questão que se levanta é a localização dessa base de dados.

Duas hipóteses poderiam ser aplicadas: a base de dados estar localmente (offline) ou online. A primeira hipótese a ser cogitada foi a possibilidade de a base de dados ficar localizada no próprio dispositivo móvel, como está apresentado na figura 20. Esta opção permitia um acesso offline, ou seja, sem haver necessidade de haver ligação a uma rede wi-fi, o que era uma vantagem. No entanto o fator segurança de toda a informação prevaleceu e como neste caso, se o utilizador ficasse sem telemóvel perderia a sua informação, esta hipótese foi descartada. A segurança dos dados clínicos de um paciente é muito importante e cada utilizador, sendo médico, iria estar na posse da informação de vários pacientes, o que tornaria ainda mais grave a perda de informação. Apesar de este fator poder ser ultrapassado de várias formas como a encriptação, este modo de armazenamento traz algumas outras desvantagens. Por exemplo, cada médico apenas poderia aceder aos dados por si inseridos e toda a informação de um paciente estaria nas mãos de vários médicos, possivelmente de

Proposta de Aplicação de Registo Clínico

68

várias instituições, havendo redundância de informação. Desta forma, esta hipótese foi abandonada.

Figura 20 – Arquitetura de sistema offline.

A outra hipótese, que acabou por ser implementada, é a implementação de um sistema online, em que a base de dados está presente num servidor e é acedida a partir de qualquer dispositivo desde que este esteja ligado a uma rede wi-fi. A arquitetura sugerida neste caso está presente na figura 21, em que na mesma base de dados estão todos os utilizadores registados e todos os pacientes de todos os médicos utilizadores com possível acesso a todas as informações. Foi implementado este esquema, com uma base de dados mySQL. Trata-se de uma arquitetura cliente-servidor, em que cada cliente tem acesso à sua informação e dos seus pacientes, que está presente na base de dados, no servidor. Cada cliente faz pedidos à base de dados do servidor, obtendo as respostas para as informações que pretende.

Figura 21 – Arquitetura de sistema online.

Com as decisões acerca da forma de armazenamento e a sua localização tomadas, resta fazer o desenho da base de dados. Apenas os dados essenciais serão contidos na base de dados,

69 cujo esquema está presente na figura 22. Em primeiro lugar, as entidades mais importantes são a intervenção e o utilizador. Daí haver necessidade de uma tabela para cada uma destas.

O facto de os utilizadores serem médicos cria a necessidade de criação de campos na tabela Utilizador relativo à sua atividade profissional, como a Especialidade e a Instituição. Como a especialidade corresponde por si só uma entidade, é também criada uma tabela Especialidade e relacionada com o utilizador. Cada médico pode criar utilizadores, sendo estes inseridos na mesma tabela Utilizador, pois muitos campos necessários relativos a médicos e pacientes são os mesmos, como Nome, Data de Nascimento, Morada, BI e Email.

Desta forma, torna-se necessário um campo que sirva de distinção entre médicos e seus pacientes, neste caso é o campo Medico, que é um campo boolean, sendo 0 caso o registo seja de um paciente e 1 caso se trate de um médico. No caso dos pacientes, os campos relativos a Username, Password, Especialidade e Instituição ficarão vazios. A ligação entre médicos e pacientes está feita na tabela medicoPaciente, onde todas as ligações ficam estabelecidas acerca dos pacientes de cada médico. Esta relação apenas irá restringir os médicos que têm acesso aos dados de determinado paciente.

Cada intervenção tem sempre um médico, paciente e tipo de intervenção associado, daí os campos idMedico, idPaciente e idTipoInterv, para isso o tipo de intervenção foi colocado numa tabela à parte, TipoIntervencao pois corresponde igualmente a uma entidade. Uma intervenção pode ter medicação associada ou não. Daí a colocação desta numa tabela aparte.

Caso a medicação fosse obrigatória, faria sentido colocar algum campo na tabela para obrigação de preenchimento. Como o número de medicamentos é desconhecido, seria necessário haver outra tabela para a medicação associada com o registo da intervenção que se pretende. Se fosse obrigatório seria colocado um campo na tabela Intervencao com a referência à identificação da medicação associada. Neste caso, como não é obrigatório haver medicação, o campo não é colocado e a associação é feita através de um campo na tabela Medicacao com a referência à identificação da intervenção, IdIntervencao.

Proposta de Aplicação de Registo Clínico

70

Figura 22 – Diagrama do esquema relacional da base de dados a implementar.