Plataforma de agendamento em ambiente hospitalar

Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Ant´ onio Jorge Monteiro Chaves Plataforma de Agendamento em Ambiente Hospitalar 29 de Abril de 2021 Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Ant´ onio Jorge Monteiro Chaves Plataforma de Agendamento em Ambiente Hospitalar Dissertac¸ ˜ ao de Mestrado Mestrado Integrado em Engenharia Inform´ atica Dissertac¸ ˜ ao supervisionada por Professor Doutor Jos´ e Manuel Ferreira Machado 29 de Abril de 2021 1 Despacho RT - 31 /2019 - Anexo 3 DIREITOS DE AUTOR E CONDIC¸ ˜ OES DE UTILIZAC¸ ˜ AO DO TRABALHO POR TERCEIROS Este ´ e um trabalho acad ´ emico que pode ser utilizado por terceiros desde que respeitadas as regras e boas pr ´ aticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licen c¸ a abaixo indicada. Caso o utilizador necessite de permiss ˜ ao para poder fazer um uso do trabalho em condi c¸ ˜ oes n ˜ ao previstas no licenciamento indicado, dever ´ a contactar o autor, atrav ´ es do Reposit´ oriUM da Universidade do Minho. https://creativecommons.org/licenses/by-sa/4.0/ AGRADECIMENTOS Primeiramente, gostaria de expressar a minha gratid ˜ ao ao Professor Douto Jos ´ e Manuel Machado, pela oportunidade que me proporcionou e o apoio prestado ao longo de todo o projeto de dissertac¸˜ ao. Ao Professor Doutor Ant ´ onio Abelha, cujo contributo ao n ´ ıvel da tomada de deci ˜ oes para o desenvolvimento do projeto foi indispens´ avel. Quero tamb ´ em agradecer ao Tiago Guimar ˜ aes e ao Hugo Peixoto, por terem sido incans ´ aveis e o mais prest ´ aveis poss ´ ıvel para que o projeto fosse conclu ´ ıdo. Para al ´ em de terem sido excelentes mentores, levo deste projeto dois amigos para a vida. Ao Centro Hospitalar Universit ´ ario do Porto e ao Centro Hospitalar do T ˆ amega e Sousa, especialmente aos respetivos Servi c¸ os de Sistemas de Informa c¸˜ ao, n ˜ ao s ´ o acompanhamento e apoio prestados, mas tamb ´ em pela oportunidade de desenvolvimento e um trabalho nos seus meios. Agrade c¸ o tamb ´ em ` a Ana, pela paci ˆ encia e o apoio ao longo destes anos de vida. Sem ela, tudo teria sido mais dif´ ıcil. Finalmente, devo um agradecimento muito especial ` a minha fam ´ ılia. Ao longo deste percurso, que nem sempre foi o mais f ´ acil, estiveram do meu lado e apoiaram-me incondicionalmente nos bons e nos maus momentos. 2 3 Despacho RT - 31 /2019 - Anexo 4 DECLARAC¸ ˜ AO DE INTEGRIDADE Declaro ter atuado com integridade na elabora c¸˜ ao do presente trabalho acad ´ emico e confirmo que n ˜ ao recorri ` a pr ´ atica de pl ´ agio nem a qualquer forma de utiliza c¸˜ ao indevida ou falsifica c¸˜ ao de informa c¸ ˜ oes ou resultados em nenhuma das etapas conducente ` a sua elaborac¸˜ ao. Mais declaro que conhe c¸ o e que respeitei o C ´ odigo de Conduta ´ Etica da Universidade do Minho. RESUMO Desde a sua g ´ enese, os Sistemas de Informa c¸˜ ao Hospitalar (SIH) t ˆ em proporcionado um conjunto de m ´ etodos e ferramentas inovadoras que t ˆ em contribu ´ ıdo significativamente para o aumento da produtividade e efici ˆ encia dos processos hospitalares e, bem assim, para o incremento da qualidade dos servi c¸ os. Com efeito, nos dias que correm, a sua utiliza c¸˜ ao na ´ area da sa´ ude ´ e mais do que uma simples funcionalidade, ´ e uma necessidade. Em particular, no centro da organiza c¸˜ ao de qualquer unidade hospitalar, o agendamento representa um dos processos que maiores benef ´ ıcios pode tirar da implementa c¸˜ ao e evolu c¸˜ ao tecnol ´ ogica dos sistemas de informa c¸˜ ao, sobretudo quando estes possuem como des ´ ıgnio principal a melhoria das condic¸ ˜ oes dos servic¸os prestados aos utentes. ´ E neste contexto que surge a presente disserta c¸˜ ao, a qual possui como objetivo primordial o estudo e enquadramento da utiliza c¸˜ ao de ontologias de ´ ultima gera c¸˜ ao aplicadas no desenvolvimento de SIH, com especial enfoque na cria c¸˜ ao de novos conceitos de agendamento de pedidos, suportados pelo desenvolvimento de uma plataforma assente em mecanismos e ferramentas inovadoras. Para al ´ em disso, o desenvolvimento e implementa c¸˜ ao da plataforma em apre c¸ o pretendeu tamb ´ em contribuir para a otimiza c¸˜ ao de fluxos de agendamento, atrav ´ es da simplifia c¸˜ ao de opera c¸ ˜ oes convencionais e da introdu c¸˜ ao de novas funcionalidades. Palavras-Chave: Agendamento, Desenvolvimento Full Stack, Interoperabilidade 4 ABSTRACT The implementation of Health Information Systems has been providing an increase in productivity and quality of service, ever since its adoption in different kinds of healthcare environments. Nowadays, its use is considered a requirement rather than a feature. Being a focal aspect of any healthcare environment’s organization, schedule management is one of the processes which can benefit the most from the implementation and evolution of health information systems, especially when their development takes into consideration the improvement that these solutions provide to patients. The main objectives of this dissertation are the assessment of state of the art ontologies suitable for the development of health information systems, especially those which define the resources needed for the implementation of scheduling workflows and the development of a platform capable of managing resources and scheduling requests, resorting to modern development methods and tools. This platform aims to optimize scheduling actions, by simplifying conventional operations and introducing new functionalities. 5 CONTE ´ UDO 1 introduc¸˜ ao 12 1.1Enquadramento 12 1.2Motivac¸˜ ao 14 1.3Objetivos 15 1.4Estrutura do Documento 15 2 estado da arte 17 2.1Sistemas de Informac¸˜ ao Hospitalar 17 2.1.1 Ag ˆ encia para a Integra c¸˜ ao, Difus ˜ ao e Arquivo de Informa c¸˜ ao M ´ edica e Cl´ ınica 17 2.1.2Sistema Integrado de Informac¸˜ ao Hospitalar 18 2.1.3SCl´ ınico 18 2.2Interoperabilidade 18 2.2.1Interoperabilidade na Sa´ ude 20 2.3Health Level Seven (HL7)22 2.3.1HL7Fast Healthcare Interoperability Resources (FHIR) 22 2.3.2Arquitetura e Metodologia 23 2.3.3Recursos 24 2.4Revis˜ ao de literatura sobre agendamento em ambiente hospitalar 27 2.4.1Tipos de Pacientes 27 2.4.2Alocamento de per´ ıodos temporais em Agendas 28 2.5Aplicac¸ ˜ oes de agendamento 28 2.5.1AGFA Healthcare 28 2.5.2CLIN1Healthcare Information Management Solutions 29 2.6Pol´ ıticas afetas ao desenvolvimento da plataforma 30 3 metodologia de investigac¸˜ ao e ferramentas 32 3.1Metodologia Design Science Research 32 3.2Objetivos - DSR 33 3.3JSON e XML 34 3.4Docker 34 3.5Nextgen Connect 35 3.6Full Stack development 35 3.7RESTful API 36 3.8Ferramentas de Desenvolvimento 38 6 conte´ udo 7 3.8.1Base de Dados 38 3.8.2Programac¸˜ ao em Node JS 39 3.8.3Framework Vue JS 39 4 arquitetura e requisitos 41 4.1Requisitos do Sistema 42 4.1.1Requisitos Funcionais 42 4.1.2Requisitos N˜ ao-Funcionais 44 4.2Arquitetura 44 4.2.1Frontend Server 44 4.2.2Backend Server 45 4.2.3NextGen Connect/Mirth 46 4.2.4Base de Dados Oracle 46 4.2.5Estrutura de Dados 46 5 an ´ alise e discuss ˜ ao de resultados 50 5.1Implementac¸˜ ao 50 5.1.1Autenticac¸˜ ao 50 5.1.2P´ agina Inicial 52 5.1.3Gest˜ ao de Agendas 53 5.1.4Visualizac¸˜ ao de Agendas 60 5.1.5Agendamento 62 5.1.6Agendamento Autom´ atico 66 5.1.7Competˆ encias por utilizador 67 5.2Discuss˜ ao 67 5.2.1An´ alise SWOT 70 5.2.2Enquadramento Te´ orico 70 5.2.3Aplicac¸˜ ao Pr´ atica 71 6 conclus ˜ ao e trabalho futuro 74 6.1Contributos 74 6.2Trabalho Futuro 76 a ap ˆ endice a 82 a.1 Development of FHIR based web applications for appointment management in healthcare 82 1.2. Motivac¸˜ ao 14 os tratamentos e um conjunto de pacientes que presenciar ˜ ao os tratamentos. Para tratamentos individuais com periodicidade, devem definir-se regras de recorr ˆ encia para diferentes tipos de periodicidade, como ´ e o exemplo do agendamento di ´ ario ou semanal num per ´ ıodo hor´ ario de um ou mais dias da semana. O fluxo inicial de requisi c¸˜ ao de MCDT prov ´ em sempre da consulta de um profissional de sa ´ ude a um paciente. Em certo ponto da consulta, ´ e feito um pedido ao sistema com toda a informa c¸˜ ao relevante para a sua defini c¸˜ ao (Identifica c¸ ˜ oes do Profissional e Paciente, tipos de MCDT e data limite para a sua realiza c¸˜ ao). A partir da cole c¸˜ ao de pedidos n ˜ ao atendidos, os administrativos do meio hospitalar definem as datas de realiza c¸˜ ao atrav ´ es de processos manuais ou autom´ aticos. Para al ´ em da cobertura dos pontos supramencionados, o prop ´ osito do sistema implica tamb ´ em a defini c¸˜ ao das manchas hor ´ arias relativas aos recursos do meio hospitalar, devido ` a rela c¸˜ ao entre o fluxo de agendamento de um recurso e a sua disponibilidade para determinado tipo de exames de uma especialidade. Para al ´ em do volume de consultas previsto ´ e necess ´ ario ter em conta a possibilidade de entradas de urg ˆ encia e uma forma eficiente de cobrir aus ˆ encias a marca c¸ ˜ oes. Hutzschenreuter et al. (2009) mencionam no seu estudo o impacto destes agentes externos na aloca c¸˜ ao de recursos, refor c¸ ando a necessidade de refinar os algoritmos a implementar. 1.2 motivac¸˜ ao O agendamento em ambiente hospitalar ´ e a base da organiza c¸˜ ao de qualquer meio hospitalar. N ˜ ao ´ e conceb ´ ıvel a idealiza c¸˜ ao um meio cl ´ ınico de presta c¸˜ ao de cuidados de sa ´ ude e realizac¸˜ ao de MCDT sem o recurso a SA. Os hospitais p ´ ublicos nacionais t ˆ em acesso a ferramentas que possibilitam o agendamento de exames e consultas, como s ˜ ao os exemplos do Sistema Integrado de Informa c¸˜ ao Hospitalar (SONHO) e SCl ´ ınico, contudo, estas aplica c¸ ˜ oes s ˜ ao desenvolvidas de forma a responder ` as necessidades gerais do servi c¸ o p ´ ublico de sa ´ ude e o seu dom ´ ınio compreende uma grande variedade de ´ areas. O seu desenvolvimento, ainda que hist ´ orico no contexto da inform ´ atica m ´ edica, j ´ a leva alguns anos e n ˜ ao ´ e exequ ´ ıvel a sua reformula c¸˜ ao de acordo com as mais modernas ferramentas e arquiteturas de desenvolvimento de software e as normas de interoperabilidade mais recentemente desenvolvidas. O presente projeto pretende disponibilizar aos meios hospitalares nacionais uma ferramenta de agendamento que, para al ´ em de fazer uso das mais recentes ferramentas de desenvolvimento, recorra ` a ontologia de interoperabilidade de maior disntin c¸˜ ao na sua g ´ enese como forma de aprimorar todo o processo de agendamento hospitalar e atender ` as necessidades espec´ ıficas dos profissionais de sa´ ude. 1.3. Objetivos 15 Para a implementa c¸˜ ao de um SA com recurso ` a ontologia FHIR ´ e imprescind ´ ıvel o estudo aprofundado desta, ao n ´ ıvel das suas carater ´ ısticas e especificidades da constru c¸˜ ao de tipos de dados desta norma. Assim, para al ´ em de promover a efici ˆ encia e a efic ´ acia de todo o processo de agendamento, tamb ´ em ´ e permitido aos administradores do sistema uma melhor gest ˜ ao das agendas e suas marca c¸ ˜ oes e a possibilidade de as integrar em diferentes plataformas. 1.3 objetivos Como forma de implementar um SIH baseado nas caracter ´ ısticas previamente introduzidas, prop ˜ oe-se a implementa c¸˜ ao do AIDA OGT, enquadrando nesta disserta c¸˜ ao o contexto te ´ orico para o seu alcance, como tamb ´ em a sua implementa c¸˜ ao num ambiente real, de forma a que a valida c¸˜ ao da implementa c¸˜ ao seja analisada por profissionais de sa ´ ude, os utilizadores alvo da aplicac¸˜ ao. Os objetivos da disserta c¸˜ ao retratam-se sob a forma da seguinte listagem de quest ˜ oes, que ser ˜ ao endere c¸ adas ao longo da extens ˜ ao do documento, com especial relevo no seu 5 º cap´ ıtulo. Quest˜ ao 1: Qual a vantagem da utiliza c¸˜ ao de uma ontologia de interoperabilidade no desenvolvimento de SIH? Quest˜ ao 2: OFHIR ´ e, na sua vers ˜ ao atual (4.0.1), uma ontologia capaz de suportar o desenvolvimento e utilizac¸˜ ao de sistemas de agendamento modernos? Quest˜ ao 3: Em que medida ´ e poss ´ ıvel a implementa c¸˜ ao de um SA com base na arquitetura e conjunto de requisitos propostos? Quest˜ ao 4: At ´ e que ponto ´ e poss ´ ıvel otimizar o agendamento hospitalar, mediante as condic¸ ˜ oes impostas? 1.4 estrutura do documento O presente documento est ´ a estruturado em seis cap ´ ıtulos. Para al ´ em do primeiro cap ´ ıtulo, nota introdut ´ oria referente ao ˆ ambito em que o projeto de disserta c¸˜ ao se insere e a sua relevˆ ancia no ˆ ambito da sa´ ude, distinguem-se os seguintes cap´ ıtulos: •Cap´ ıtulo 2: O cap ´ ıtulo referente ao estudo do estado da arte de SA espec ´ ıficos de ambientes hospitalares estende a introdu c¸˜ ao do ˆ ambito em que se insere o projeto de disserta c¸˜ ao. Para al ´ em da explica c¸˜ ao mais pormenorizada dos conceitos de SIH, e os mais utilizados exemplos nos hospitais p ´ ublicos em Portugal, ´ e explorado o 1.4. Estrutura do Documento 16 conceito de interoperabilidade e a arquitetura da ontologia que suporta a estrutura de dados do projeto. Tamb ´ em ´ e apresentado um estudo conciso sobre outros destaques mencionados na literatura sobre a tem ´ atica e um par de exemplos de aplica c¸ ˜ oes de ˆ ambito semelhante, j´ a implementados. •Cap´ ıtulo 3: Apresenta c¸˜ ao da metodologia de investiga c¸˜ ao e ferramentas utilizadas para o desenvolvimento do projeto. Em primeira m ˜ ao s ˜ ao clarificados o conceito e import ˆ ancia da utiliza c¸˜ ao da metodologia de investiga c¸˜ ao Design Science Research (DSR) no desenvolvimento de um projeto de cariz cient ´ ıfico, seguido da introdu c¸˜ ao da plenitude de ferramentas utilizadas no desenvolvimento do projeto. •Cap´ ıtulo 4: O quarto cap ´ ıtulo apresenta detalhadamente os requisitos impostos para o desenvolvimento do projeto e a fun c¸˜ ao atribu ´ ıda a cada uma das ferramentas do anterior cap´ ıtulo no alcance da soluc¸˜ ao final. •Cap´ ıtulo 5: O pen ´ ultimo cap ´ ıtulo do documento serve de avalia c¸˜ ao do trabalho desenvolvido e divide-se em duas sec c¸ ˜ oes. Inicialmente s ˜ ao discutidos os resultados obtidos e endere c¸ ados os objetivos designados na sec c¸˜ ao 1.3, seguido de uma an ´ alise SWOT do projeto desenvolvido. •Cap´ ıtulo 6: O ´ ultimo cap ´ ıtulo do documento sumariza as principais conclus ˜ oes inferidas do trabalho desenvolvido, assim como prop ˜ oe a implementa c¸˜ ao de novas funcionalidades, com vista a tornar o ˆ ambito do projeto mais completo. O Ap ˆ endice do documento alude a um trabalho cient ´ ıfico desenvolvido em paralelo com o trabalho de dissertac¸˜ ao e qualquer coisa qualquer coisa. 2 ESTADO DA ARTE Este cap ´ ıtulo apresenta um breve estudo sobre alguns pontos relevantes no desenvolvimento da plataforma. Em primeira inst ˆ ancia, ser ˜ ao analisadas aplica c¸ ˜ oes desenvolvidas no ˆ ambito da sa ´ ude, com destaque para a plataforma na qual este projeto se insere, seguida da revis ˜ ao da literatura sobre a implementa c¸˜ ao de SA, tanto do ponto de vista organizacional como de seguranc¸a. 2.1 sistemas de informac¸˜ ao hospitalar Os SIH s ˜ ao aplica c¸ ˜ oes de inform ´ atica orientados ao aux ´ ılio das opera c¸ ˜ oes de administra c¸˜ ao de um ambiente hospitalar. Desde os finais do s ´ eculo passado, ´ epoca da globaliza c¸˜ ao do uso de sistemas de informa c¸˜ ao, que se tem vindo a notar um crescimento constante da sua utiliza c¸˜ ao nas ´ areas da sa ´ ude. No presente, ´ e impens ´ avel a manuten c¸˜ ao de um meio hospitalar sem recurso a qualquer tipo de sistema desta natureza, dadas as in ´ umeras vantagens que a sua implementa c¸˜ ao traz. Mais recentemente, a digitaliza c¸˜ ao de registos de sa ´ ude abriu as portas ` a sua utiliza c¸˜ ao no contexto das Tecnologias de Informa c¸˜ ao (TI). (Marins and Machado,2013) 2.1.1Agˆ encia para a Integrac¸˜ ao, Difus˜ ao e Arquivo de Informac¸˜ ao M´ edica e Cl´ ınica Da necessidade de tratamento e manuten c¸˜ ao de toda a informa c¸˜ ao gerada por meios hospitalares nasce a Ag ˆ encia para a Integra c¸˜ ao, Difus ˜ ao e Arquivo de Informa c¸˜ ao M ´ edica e Cl ´ ınica (AIDA). Atualmente inserida em diversas unidades hospitalares, traz aos seus utilizadores uma forma segura e ´ ıntegra de tratamento e partilha de informa c¸˜ ao, assim como assegura a sua alta disponibilidade. (Marins and Machado,2013;Peixoto et al.,2012) Ainda que o seu prop ´ osito seja relevante na organiza c¸˜ ao e manuten c¸˜ ao das unidades hospitalares em que se insere, n ˜ ao comporta ainda todas as solu c¸ ˜ oes necess ´ arias para a utiliza c¸˜ ao da informa c¸˜ ao por parte dos profissionais de sa ´ ude, mas facilita o desenvolvimento de soluc¸ ˜ oes para tal efeito. 17 2.2. Interoperabilidade 18 Este projeto insere-se no ˆ ambito da AIDA, que servir ´ a de meio intermedi ´ ario de controlo e media c¸˜ ao da informa c¸˜ ao armazenada nos diferentes sistemas de apoio ` a plataforma, e pretende responder a necessidades espec ´ ıficas relatadas pelos meios hospitalares nos quais est´ a implementada. 2.1.2Sistema Integrado de Informac¸˜ ao Hospitalar OSONHO ´ e o sistema existente sob o qual opera o Servi c¸ o Nacional de Sa ´ ude (SNS). A sua primeira inst ˆ ancia foi desenvolvida na d ´ ecada de 80, tendo tido a sua primeira implementa c¸˜ ao f ´ ısica alguns anos mais tarde, em 1995. A sua implementa c¸˜ ao foi de tal modo impactuante que se considerou uma medida inovadora, difundindo-se rapidamente para a generalidade dos hospitais p´ ublicos nacionais. De modo a garantir uma resposta adequada ` as necessidades crescentes da ´ area, tem vindo gradualmente a ser substitu ´ ıdo pela nova itera c¸˜ ao SONHO V2. Esta migra c¸˜ ao foi o maior projeto alguma vez concretizado na ´ area dos SIH no ˆ ambito da sa ´ ude em Portugal. (Marto, 2017) Suportado pelo Sistema de Gest ˜ ao de Bases de Dados (SGBD) Oracle divide-se em diversos m ´ odulos para comportar mais eficientemente as necessidades espec ´ ıficas de cada servi c¸ o providenciado pelos meios hospitalares. Dentro do seu prop ´ osito, destacam-se as opera c¸ ˜ oes de identifica c¸˜ ao e acesso ao historial cl ´ ınico dos pacientes, distribui c¸˜ ao e processamento dos dados para uso intermodular, agendamento, faturac¸˜ ao e gest˜ ao administrativa. Por ser um sistema generalizado de gest ˜ ao hospitalar e conter, sobretudo, toda a informa c¸˜ ao relativa a pacientes, ´ e um dos sistemas aos quais a plataforma far ´ a liga c¸˜ ao, mediada pela camada de integrac¸˜ ao da AIDA. 2.1.3SCl´ ınico O SCl ´ ınico nasce da fus ˜ ao de dois sistemas previamente formados pelos Servi c¸ os Partilhados do Minist ´ erio da Sa ´ ude (SPMS),oSistema de Apoio ao M ´ edico (SAM) eoSistema de Apoio ` a Pr ´ atica de Enfermagem (SAPE) e permite o registo e realiza c¸˜ ao de todos os procedimentos desde a admiss ˜ ao no servi c¸ o de urg ˆ encias, inclusive triagem de pacientes, ou consultas externas, como controlo de internamento ou entrada no bloco operat ´ orio. ` A semelhan c¸ a do SONHO ´ e tamb´ em gerido pelo SGBD Oracle. (Marto,2017) 2.2 interoperabilidade A interoperabilidade ´ e, por defini c¸˜ ao, a abilidade de comunica c¸˜ ao entre diferentes Sistemas de Informa c¸˜ ao (SI) e aplica c¸ ˜ oes, a atrav ´ es da troca de dados com precis ˜ ao e seguran c¸ a, com 2.2. Interoperabilidade 19 a finalidade de, em conjunto, fazer uso dessa informa c¸˜ ao. Dogac et al. (2019); Peixoto et al. (2012) Esta capacidade de troca de informa c¸˜ ao relevante e opera c¸˜ ao para benef ´ ıcio m ´ utuo pode ser classificada em dois tipos: •Interoperabilidade Semˆ antica : troca de informa c¸˜ ao entre de modo desamb ´ ıguo entre sistemas. O envio da informa c¸˜ ao ´ e padronizado por uma gram ´ atica conhecida pelos sistemas implicados na troca de informa c¸˜ ao. A interoperabilidade sem ˆ antica ´ e um requisito base na infˆ erˆ encia e descoberta de conhecimento entre SI. •Interoperabilidade Sint´ atica : implica c¸˜ ao de que a mesma mensagem possui o mesmo significado para qualquer entidade envolvida na sua permutac¸ ˜ ao. Existem outros modelos de classifica c¸˜ ao de interoperabilidade que permitem uma melhor defini c¸˜ ao seu grau ao longo dos sistemas, atrav ´ es da aplica c¸˜ ao de m ´ etodos generalizados. O modelo LCIM foi desenvolvido, desde in ´ ıcios da d ´ ecada de 2000 e melhorado ao longo dos anos posteriores, com vista a melhorar itera c¸ ˜ oes precedentes de modelos de interoperabilidade. Este modelo apresenta sete camadas de interoperabilidade, demonstradas na figura 1. Nível 0 Nível 6 Interoperabilidade Conceptual Nível 5 Interoperabilidade Dinâmica Sem Interoperabilidade Nível 1 Interoperabilidade Técnica Nível 2 Interoperabilidade Sintática Nível 3 Interoperabilidade Semântica Nível 4 Interoperabilidade Pragmática Figura 1: Esquema do modelo LCIM. Conforme sugerido pela figura 1, a capacidade de interopera c¸˜ ao est ´ a linearmente vinculado ao n ´ ıvel de interoperabilidade em que se insere. Cada n ´ ıvel abrange as carater ´ ısticas 2.2. Interoperabilidade 20 dos n ´ ıveis inferiores. De seguida, distinguem-se os diferentes n ´ ıveis, de acordo com as designac¸ ˜ oes ilustradas por Marins and Machado (2013); Iroju et al. (2013). •N´ ıvel 0: sistemas isolados sem interoperabilidade. A informa c¸˜ ao utilizada ´ e pr ´ opria do sistema e n˜ ao h´ a possibilidade de partilha. •N´ ıvel 1: a interoperabilidade t ´ ecnica ´ e atingida quando diferentes sistemas t ˆ em a capacidade de gerac¸˜ ao e leitura de informac¸˜ ao proveniente de diferentes fontes. •N´ ıvel 2: do mesmo modo que foi acima descrito, a interoperabilidade sint ´ atica ´ e descrita pela equival ˆ encia estrutural do formato da informa c¸˜ ao permutada entre sistemas. •N´ ıvel 3: a interoperabilidade sem ˆ antica entende se pela interpreta c¸˜ ao desamb ´ ıgua ao longo de diversos SI. •N´ ıvel 4: ou interoperabilidade pragm ´ atica em sistemas que tenham um conhecimento estrutural de m ´ etodos e procedimentos entre si. O quarto n ´ ıvel implica que tanto a informa c¸˜ ao como o contexto em que ´ e empregue s ˜ ao compreendidos entre os sistemas implicados. •N´ ıvel 5: dois ou mais sistemas s ˜ ao considerados dinamicamente interoper ´ aveis quando tˆ em a abilidade de compreender e tirar proveito de alterac¸ ˜ oes de estado que ocorrem devido ` a utilizac¸˜ ao da informac¸˜ ao ao longo do tempo. •N´ ıvel 6: o ´ ultimo grau de interoperabilidade ´ e atingido se as restri c¸ ˜ oes e as premissas de cada sistema est ˜ ao de acordo entre si. O alcance do sexto n ´ ıvel de interoperabilidade permite a inst ˆ ancia c¸˜ ao do conjunto de sistemas em ambientes distintos e com abstra c¸ ˜ oes diferentes. Para isso, ´ e necess ´ aria a documenta c¸˜ ao t ´ ecnica de dos modelos conceptuais de cada sistema segundo protocolos em uso na ´ area da engenharia. 2.2.1Interoperabilidade na Sa´ ude Enquanto que SIH tenham atingido patamares sem precedentes ao n ´ ıvel de inova c¸˜ ao e fidedignidade ao longo das ´ ultimas tr ˆ es d ´ ecadas, novas implementa c¸ ˜ oes e conceitos ` a volta da inform ´ atica na sa ´ ude continuam a promover altera c¸ ˜ oes estruturais fundamentais no sentido do melhoramento destes sistemas. Com base nesta premissa, ´ e necess ´ ario compreender a import ˆ ancia que a interoperabilidade apresenta na ´ area da sa ´ ude, sobretudo dada a necessidade de reutiliza c¸˜ ao e troca de informac¸˜ ao entre SIH.Iroju et al. (2013) A presta c¸˜ ao de cuidados de sa ´ ude a um indiv ´ ıduo pode variar de car ´ ater, dependendo da necessidade. Hospitais, laborat ´ orios, cl ´ ınicas independentes s ˜ ao alguns dos exemplos de 2.2. Interoperabilidade 21 servi c¸ os de sa ´ ude que, mesmo n ˜ ao estando obrigatoriamente afiliados entre si, partilham o objetivo da garantia da sa ´ ude de um paciente. As diferentes ´ ındoles dos servi c¸ os de presta c¸˜ ao de cuidados de sa ´ ude contribuem para o armazenamento fragmentado de informa c¸˜ ao cl ´ ınica dos pacientes, dificultando a obten c¸˜ ao de informa c¸˜ ao generalizada relativa ao paciente. Al ´ em disso, o armazenamento de informa c¸˜ ao ´ e, na maioria dos casos, efetuado sem recurso a protocolos na estrutura c¸˜ ao e codifica c¸˜ ao, tornando a sua partilha uma tarefa ´ ardua. Isto traduz-se, do ponto de vista dos ambientes de presta c¸˜ ao de servi c¸ os, numa diminui c¸˜ ao da efic ´ acia de tratamentos e desperd ´ ıcio de recursos. A figura 2esquematiza a intera c¸˜ ao de v´ arios SIH com a informac¸˜ ao dos pacientes. Informação dos Pacientes Farmácia Departamento Saúde Pública Registos Eletrónicos de Saúde Radiologia Laboratório Registo de Saúde Pessoal Executantes Pacientes Hospitais Atores Entidades de Saúde Figura 2: Interoperabilidade de SIH A implementa c¸˜ ao de sistemas interoper ´ aveis promete a correta transimss ˜ ao e armazenamento em sistemas heterog ´ eneos como forma de melhorar o acesso a informa c¸˜ ao cl ´ ınica podendo, assim, promover melhores condi c¸ ˜ oes de avalia c¸˜ ao e presta c¸˜ ao de cuidados de sa ´ ude. O armazenamento de informa c¸˜ ao normalizado, de acordo com o quarto e superiores n ´ ıveis de interoperabilidade LCIM, permitem a compreens ˜ ao total da informa c¸˜ ao transmitida, atrav ´ es da imposi c¸˜ ao da utiliza c¸˜ ao de terminologia adequada. O recurso ` a interoperabilidade entre sistemas tem, portanto, um impacto significativo na assimila c¸˜ ao de informac¸˜ ao diminuindo o n´ umero de erros de ´ ındole m´ edica. Ainda que a completa implementa c¸˜ ao da interoperabilidade na ´ area da sa ´ ude seja um objetivo a alcan c¸ ar, n ˜ ao ser ´ a uma tarefa trivial. Os SIH de diferentes caracter ´ ısticas, desde laborat ´ orios ou cl ´ ınicas a instrumentos de medi c¸˜ ao, geram vastas quantidades de informa c¸˜ ao periodicamente, cuja interpreta c¸˜ ao ´ e de car ´ ater complexo. A utiliza c¸˜ ao de SIH desatualizados ´ e outro exemplo de oposi c¸˜ ao ` a implementa c¸˜ ao de sistemas interoper ´ aveis. Em Portugal, o 2.3. Health Level Seven (HL7)22 SONHO ´ e o predominante SIH em uso nos centros de sa ´ ude e hospitais do sistema p ´ ublico de sa ´ ude, estando ainda em utiliza c¸˜ ao vers ˜ oes mais antigas do sistema. Por outro lado, a ado c¸˜ ao de registos eletr ´ onicos, que tem vindo a apresentar um crescimento significativo ao longo da ´ ultima d ´ ecada, ainda n ˜ ao ´ e uma realidade completamente instalada na sa ´ ude Por fim, deve ser notada a limitada capacidade de inova c¸˜ ao por parte de uma percentagem de administrativos e profissionais de sa´ ude em atividade. 2.3 health level seven (hl7) AHL7 ´ e uma organiza c¸˜ ao sem fins lucrativos fundada em 1987 focada no desenvolvimento de frameworks compreensivos e padr ˜ oes relacionados com a partilha, integra c¸˜ ao e busca de informa c¸˜ ao m ´ edica eletr ´ onica que suporta o processo cl ´ ınico, para al ´ em da gest ˜ ao, produ c¸˜ ao e avalia c¸˜ ao de servi c¸ os de sa ´ ude. Ao longo das tr ˆ es ´ ultimas d ´ ecadas, as diferentes itera c¸ ˜ oes dos padr ˜ oes da HL7solidificaram-se como alguns dos mais prominentes da ind ´ ustria. International (2020) 2.3.1HL7FHIR Os padr ˜ oes HL7surgem da fus ˜ ao das ´ areas dos cuidados de sa ´ ude, engenharia e TI. A n ´ ıvel da sa ´ ude, s ˜ ao cobertos praticamente todos os dom ´ ınios funcionais, desde gest ˜ ao de pacientes e Registos eletr ´ onicos de sa ´ ude (RES) a ´ areas de administra c¸˜ ao ou padr ˜ oes de comunicac¸˜ ao na medicina, como DICOM. O padr ˜ ao HL7FHIR suporta os formatos JSON eXML de modo a permitir a implementa c¸˜ ao de servidores de cliente (client-side ou front end) e intermedia c¸˜ ao (server-side ou back end) tanto para aplica c¸ ˜ oes web ou m ´ oveis. A utiliza c¸˜ ao da nota c¸˜ ao FHIR especificada nos formatos acima mencionados permite a troca de informa c¸˜ ao diretamente no corpo do pedido HyperText Transfer Protocol (HTTP), simplificando a comunica c¸˜ ao a conjuntos pedidoresposta entre os servidores de cliente e intermedia c¸˜ ao. A utiliza c¸˜ ao destes formatos mais recentemente implementados - em contraste com a metodologia empregue em vers ˜ oes anteriores de separa c¸˜ ao de campos pelo s ´ ımbolo de barra vertical (—) - implica tamb ´ em uma melhoria significativa na legibilidade e parsing das mensagens trocadas. O recurso a RESTful API permite o desenvolvimento multi-plataforma e em qualquer linguagem de programa c¸˜ ao atual, sendo que os formatos JSON eXML s ˜ ao suportados na sua totalidade, sem que a transmiss ˜ ao de mensagens por HTTP seja condicionada pela formatac¸˜ ao de diferentes sistemas operativos. Maxhelaku and Kika (2019); FHIR (2019j) 2.3. Health Level Seven (HL7)23 2.3.2Arquitetura e Metodologia Consulta Marcação Resposta à Marcação Slot Paciente Executante Localização Outros Agenda Organização Localização Paciente Executante Tarefa Serviços de Saúde Figura 3: Esquematizac¸˜ ao conceptual de HL7FHIR, adaptado de FHIR (2019j) O m ´ odulo administrativo do HL7FHIR engloba os dados base que s ˜ ao enviados para quaisquer outros m ´ odulos de gest ˜ ao cl ´ ınica. A gera c¸˜ ao da informa c¸˜ ao cl ´ ınica de uma consulta pressup ˜ oe a exist ˆ encia de uma base de informa c¸˜ ao pessoal do paciente que deve ser obtida caso n ˜ ao exista no momento. Uma consulta ou encontro de cariz m ´ edico define-se como a intera c¸˜ ao entre um paciente e um prestador de cuidados de sa ´ ude com o intuito de fornecer cuidados de sa´ ude ou avaliar o estado de sa´ ude do paciente. FHIR (2019j) O agendamento de uma consulta deve respeitar todos os seus intervenientes. Executantes, dispositivos e postos de trabalho est˜ ao sujeitos aos seus pr´ oprios hor´ arios e a sobreposic¸˜ ao dos intervalos livres de cada um fornece a informa c¸˜ ao das possibilidades para o agendamento. O ponto de vista do paciente tamb ´ em tem de ser tido em conta, pois est ´ a sujeito ` a sua pr ´ opria disponibilidade para marcar presen c¸ a na consulta. Al ´ em disso, quando houver a necessidade de marca c¸˜ ao de mais de um encontro em nome do paciente, devem ser tomados em conta os espa c¸ os de tempo mais pr ´ oximos entre si dentro de um dia ou a prioridade da sua execuc¸˜ ao. Quando a disponibilidade for da concord ˆ ancia de todos os intervenientes, a marca c¸˜ ao deve ser requerida e, mediante a pol ´ ıtica de agendamento do ambiente hospitalar, ser imediatamente agendada ou aguardar a confirma c¸˜ ao de um administrativo competente. A defini c¸˜ ao do fluxo de agendamento do HL7FHIR prev ˆ e tamb ´ em a cria c¸˜ ao de listas de 2.6. Pol´ ıticas afetas ao desenvolvimento da plataforma 30 2.6 pol´ iticas afetas ao desenvolvimento da plataforma Esta sec c¸˜ ao refere algumas decis ˜ oes que a pol ´ ıtica interna do ambiente hospitalar deve tomar. Heasley (2011) defende no seu estudo que a preponder ˆ ancia dos fatores externos no agendamento ´ e tal que torna a sua otimiza c¸˜ ao num problema NP-Completo, concluindo que em casos semelhantes, o atendimento de requisitos espec ´ ıficos do meio hospitalar ´ e mais ben´ efico do que a implementac¸˜ ao de algoritmos mais generalizados. Tipo de Agendamento •Est´ atico: Apenas permite a marca c¸˜ ao de consultas numa data anterior ` a atual, solu c¸˜ ao pass ´ ıvel de implementa c¸˜ ao em meios hospitalares controlados, sem servi c¸ os de urgˆ encia. •Dinˆ amico: Toma em considera c¸˜ ao o estado instant ˆ aneo do sistema e permite altera c¸ ˜ oes ` as marca c¸ ˜ oes com base na necessidade de atendimento urgente um aus ˆ encia do paciente. Ajustes relativos a faltas de comparˆ encia •Sobrelotamento: Possibilidade de marca c¸˜ ao de consultas que exceda o n ´ umero m ´ aximo previsto de consultas para a agenda. Na eventualidade de falta de compar ˆ encia, d ´ a-se a prefer ˆ encia a pacientes excedent ´ arios e ´ e a solu c¸˜ ao ideal para manter uma taxa de ocupac¸˜ ao elevada. •Ajustar slots seguintes: Adequa c¸˜ ao da fila de espera na colmata c¸˜ ao de faltas de comparˆ encia, promovendo a entrada direta do pr´ oximo paciente em espera. Ajustes relativos a emergˆ encias e entradas na urgˆ encia •Reserva de slots pr´ e-determinados: Designa c¸˜ ao de per ´ ıodos de atendimento urgente dentro de cada agenda. •Ajustar slots seguintes: Surgimento de situa c¸ ˜ oes de emerg ˆ encia (priorit ´ arias no atendimento) resulta no adiamento dos pacientes em fila de espera. Tempos de espera e inatividade Consideram-se por fatores externos todo o tipo de condicionantes que afetem negativamente o tempo em fila de espera dos pacientes e tempo de inatividade dos profissionais de sa ´ ude. Cayrli and Veral (2003) identificam no seu estudo as medidas de desempenho a notar na defini c¸˜ ao de um SA, o tempo m ´ edio de espera de pacientes, decorrido antes do in ´ ıcio 2.6. Pol´ ıticas afetas ao desenvolvimento da plataforma 31 da consulta, tempo de fluxo de pacientes, m ´ edia da dura c¸˜ ao total da consulta, tempo de inatividade dos profissionais de sa ´ ude e horas extraordin ´ arias de servi c¸ o. A estocasticidade da entrada de pacientes no servi c¸ o de urg ˆ encias e em situa c¸˜ ao de emerg ˆ encia tem sido relatada como um dos problemas na otimiza c¸˜ ao destas medidas e a sua gest ˜ ao ´ e um t ´ opico obrigat´ orio na aproximac¸˜ ao do seu desenvolvimento. (Mardiah and Basri,2019) 3 METODOLOGIA DE INVESTIGAC¸ ˜ AO E FERRAMENTAS A natureza de uma pesquisa cient ´ ıfica e a sua solidez e potencial relev ˆ ancia t ˆ em como pilar estrutural o rigor e metodologia pelos quais se regem quando ´ e levada a cabo. A metodologia Design Science (DS) desempenha um papel central no desenvolvimento e gest˜ ao de SI.Winograd (2006) A pesquisa no campo das TI orientada pelo paradigma de DS ´ e fundamentalmente proativa e tem como objetivo a cria c¸˜ ao de objetos que dilatam as capacidades humanas e sociais, como forma de as simplificar e tornar mais acess´ ıveis. Hevner (2004) 3.1 metodologia design science research A Design Science Research ´ e uma metodologia de pesquisa que prop ˜ oe um conjunto espec ´ ıfico de regras para o desenvolvimento de aplica c¸ ˜ oes da ´ area das TI. O seu principal objetivo ´ e a maximizac¸˜ ao das capacidades funcionais e de desempenho de um aplicac¸˜ ao. Em primeira inst ˆ ancia, deve ser reconhecida a identifica c¸˜ ao de dois processos e quatro produtos, fundamentais na definic¸˜ ao de DS. Os processos s ˜ ao a constru c¸˜ ao, referente ao processo de desenho de uma ferramenta espec ´ ıfica para alcancar um objetivo, e a avalia c¸˜ ao, a determina c¸˜ ao da capacidade da ferramenta para execu c¸˜ ao do objetivo proposto. Por sua vez, os produtos caracterizam-se como abstra c¸ ˜ oes, modelos, m ´ etodos e implementa c¸ ˜ oes. A conceptualiza c¸˜ ao ou abstra c¸˜ ao ´ e a sem ˆ antica que delimita os objetos a serem desenvolvidos, sendo utilizada na descri c¸˜ ao de termos e fluxos de opera c¸˜ ao. Os m ´ etodos referem-se ao modo de execu c¸˜ ao de tarefas com um determinado objetivo enquanto que, por sua vez, os modelos e implementa c¸ ˜ oes s ˜ ao os resultados finais da instancia c¸˜ ao em produtos espec ´ ıficos com o objetivo de perpetrar as tarefas definidas para o seu uso. March (1995); Hevner (2004) 32 3.2. Objetivos - DSR 33 3.2 objetivos -dsr Hevner et al. (200); March (1995) discutem na sua pesquisa um conjunto de diretrizes fundamentais no desenvolvimento de problemas segundo a metodologia adotada. O conjunto seguinte de pontos foi adaptado desses artigos e explica clara e concisamente os passos necess´ arios para a abordagem ao problema. Design de um artefacto Um dos objetivos da DSR ´ e a produ c¸˜ ao de uma solu c¸˜ ao vi ´ avel, seja na forma de conceito, modelo, m´ etodo ou instˆ ancia. Relevˆ ancia do Problema Outro objetivo da DSR ´ e o desenvolvimento de solu c¸ ˜ oes tecnol ´ ogicas para problemas relevantes e atuais. Avaliac¸˜ ao da Soluc¸˜ ao A utilidade, qualidade e efic ´ acia da solu c¸˜ ao devem ser demonstradas segundo m ´ etodos de avaliac¸˜ ao bem executados. Contribuic¸˜ oes de Pesquisa De modo a ser considerada relevante, a DSR deve incorporar contribui c¸ ˜ oes claras e comprovadas na ´ area em que se insere. Rigor de Pesquisa A pesquisa deve ser fundamentada atrac ´ es da aplica c¸˜ ao de m ´ etodos rigorosos de constru c¸˜ ao e avaliac¸˜ ao da soluc¸˜ ao Design como Processo de Pesquisa A constru c¸˜ ao de uma solu c¸˜ ao vi ´ avel requer a utiliza c¸˜ ao de meios dispon ´ ıveis para obten c¸˜ ao da soluc¸˜ ao final e satisfazer as regras impostas pela ´ area em que se insere o problema. Comunicac¸˜ ao da Pesquisa Todo o processo de pesquisa deve ser devidamente apresentado tanto a especialistas na sua parte tecnol´ ogica e de gest˜ ao como a aos seus destinat´ arios. 3.3. JSON e XML 34 3.3 json e xml JSON eXML s ˜ ao formatos de transmiss ˜ ao e designa c¸˜ ao de dados textuais cuja independ ˆ encia de liguagens de programa c¸˜ ao os tornaram dos mais vers ´ ateis m ´ etodos de transfer ˆ encia de informac¸˜ ao. A especifica c¸˜ ao do protocolo HL7FHIR e a sua instancia c¸˜ ao foram desenvolvidas partindo de ambos estes formatos. O projeto desenvolvido no ˆ ambito da disserta c¸˜ ao faz uso do formato JSON como defini c¸˜ ao e modela c¸˜ ao da informa c¸˜ ao transmitida, pela sua facilidade de convers ˜ ao para objetos da linguagem de JavaScript e menor impacto no tamanho dos dados transmitidos. A tabela 4, adaptada de Goyal et al. (2017), compara os dois formatos textuais e elucida a escolha de JSON como o formato preterido. Campo XML JSON Parsing Relativa dificuldade de parsing por parte de dispositivos. Dispositivos muito eficazes no parsing de objetos. Definic¸˜ ao Dados definidos por Tags, resultam num maior custo de transmiss˜ ao de dados. A defini c¸˜ ao de pares chavevalor torna o formato mais leve para transmiss ˜ ao e mais f´ acil de entender. Transmiss˜ ao de dados Desempenho afetado linearmente com o tamanho dos documentos transmitidos. Alto desempenho na transmiss˜ ao de dados. Suporte de estruturas de dados complexas N˜ ao suportado. Suporta defini c¸˜ ao de tipos de dados e listas. Compactac¸˜ ao R´ apida. Muito r´ apida de leve. Orientac¸˜ ao A orienta c¸˜ ao ao documento foca a parte estrutural dos dados. A orienta c¸˜ ao aos dados permite a sua defini c¸˜ ao fora de contexto do documento, reduzindo o seu tamanho. Tabela 4: Comparac¸˜ ao entre JSON eXML, adaptado de Goyal et al. (2017). 3.4 docker A reprodutibilidade de um sistema pode ser descrita como a possibilidade de repetir um determinado processo em ambientes distintos com a inten c¸˜ ao de observar os mesmos factos. Mais especificamente, no contexto da ´ area das TI o desenvolvimento de aplica c¸ ˜ oes de software depende frequentemente da integra c¸˜ ao de algoritmos, ferramentas ou prot ´ otipos provenientes de autores distintos. Mais ainda, o desenvolvimento de software e a sua implementa c¸˜ ao dependem diretamente do ambiente onde ser ˜ ao inseridos. A t ´ ıtulo de 3.5. Nextgen Connect 35 exemplo e dentro do contexto em que se insere o projeto desenvolvido, existe a necessidade de integrar a aplica c¸˜ ao dentro de diferentes ambientes hospitalares. Cada um destes possui diferentes configura c¸ ˜ oes de rede privada, diferentes localiza c¸ ˜ oes de bases de dados entre outros. O Docker ´ e um servi c¸ o open source de virtualiza c¸˜ ao ao n ´ ıvel de um sistema operativo que permite a reprodu c¸˜ ao de software em pacotes, designados por containers. Estes pacotes s ˜ ao servi c¸ os compar ´ aveis a m ´ aquinas virtuais compactas que permitem a configura c¸˜ ao de um ambiente computacional, depend ˆ encias e bibliotecas necess ´ arias para a execu c¸˜ ao de uma aplica c¸˜ ao dentro de um contexto espec ´ ıfico, intitulados de imagens. A totalidade da configura c¸˜ ao de uma imagem ´ e descrita dentro de um ficheiro espec ´ ıfico, o dockerfile. Uma imagem Docker pode ser distribu ´ ıda entre sistemas Linux e qualquer sistema operativo compat´ ıvel. Cito et al. (2016) 3.5 nextgen connect A ferramenta open source Nextgen Connect, previamente conhecida como Mirth Connect Engine ´ e uma ferramenta multi plataforma de integra c¸˜ ao da ´ area da sa ´ ude destinada ` a integra c¸˜ ao de diferentes recursos. A sua configura c¸˜ ao ´ e feita atrav ´ es de uma interface de utilizador simples de utiliza c¸˜ ao, com acesso r ´ apido a defini c¸ ˜ oes pr ´ e definidas de uso geral. A ferramenta ´ e de elevada utilidade no contexto em que se insere e permite as opera c¸ ˜ oes de envio e rece c¸˜ ao de mensagens Transmission Control Protocol (TCP), leitura e escrita de ficheiros e a reda c¸˜ ao de scripts de JavaScript n ˜ ao s ´ o para as opera c¸ ˜ oes de Input/Output (I/O) mas tamb´ em durante esses processos. No contexto do presente projeto, a explora c¸˜ ao do protocolo TCP permite o filtro e roteamento de mensagens e a sua transforma c¸˜ ao de acordo com um conjunto espec ´ ıfico de regras. As estruturas de dados e as vers ˜ oes das aplica c¸ ˜ oes em utiliza c¸˜ ao diferem entre unidades hospitalares e a correta interpreta c¸˜ ao dos dados ´ e fulcral para o bom funcionamento da aplica c¸˜ ao em desenvolvimento e a sua interoperabilidade. Os canais desenvolvidos atrav ´ es da ferramenta Nextgen Connect servem de middleware entre certos servic¸os desenvolvidos para a RESTful API do sistema. Peixoto et al. (2020) 3.6 full stack development O desenvolvimento web ´ e o processo de cria c¸˜ ao de websites para a internet ou redes privadas (intranet). Este processo engloba os passos de design web e de conte ´ udo, programa c¸˜ ao de servi c¸ os de cliente e servidores, gest ˜ ao e administra c¸˜ ao de bases de dados, configura c¸˜ ao e implementac¸˜ ao de m´ etodos de seguranc¸a, entre outros. 3.7. RESTful API 36 As tarefas de um programador Full Stack podem ser divididas em duas ´ areas de maior relevo. O desenvolvimento frontend ou servidor cliente ´ e a implementa c¸˜ ao da interface gr ´ afica, sec c¸˜ ao visual da aplica c¸˜ ao, com a qual os seus utilizadores interagem. Esta ´ area compreende, para al ´ em do design, a estrutura c¸˜ ao de dados e conte ´ udo e implementa c¸˜ ao da camada funcional da aplica c¸˜ ao. Por outro lado, o desenvolvimento backend refere-se ` a elaborac¸˜ ao da camada de processamento da aplicac¸˜ ao. As tarefas executadas pelo servidor s ˜ ao invis ´ ıveis ao utilizador e a comunica c¸˜ ao entre os dois servi c¸ os ´ e efetuada atrav ´ es de protocolos de permuta de dados. ´ E frequente a implementa c¸˜ ao de uma camada de controlo de dados que faz a ligac¸˜ ao entre o servic¸o e as bases de dados que o suportam. 3.7 restful api RESTful API ´ e um tipo de arquitetura que define um conjunto de regras com vista a melhorar o desempenho, dipsonibilidade e escalabilidade de sistemas distribu ´ ıdos web. Com base no paradigma cliente-servidor, em que aplica c¸ ˜ oes (clientes) enviam pedidos HTTP ao servidor, que por sua vez os executa e age consoante o seu tipo, designa uma interface uniforme para os componentes de um sistema com base em quatro regras: a identifica c¸˜ ao de recursos, opera c¸˜ ao de recursos atrav ´ es da sua representa c¸˜ ao, comunia c¸˜ ao auto-denominada e a utiliza c¸˜ ao de Hypermedia como representa c¸˜ ao do estado da aplica c¸˜ ao. Salvadori and Siqueira (2015) O acesso ` as opera c¸ ˜ oes de um servi c¸ oRESTful API ´ e feito atrav ´ es de Unified Resource Identifier (URI), sob a forma de liga c¸˜ ao web padr ˜ ao. A figura 4ilustra os diferentes par ˆ ametros necess ´ arios para a constru c¸˜ ao de um link que deve ser reconhecido pela RESTful API e o seu dom´ ınio acess´ ıvel atrav´ es da rede em que se insere o sistema. http :// www.aida.com : 8080 / ogt resources search / 2020/ / Protocolo PortaDomínio Contexto Recurso Interação Parâmetros Figura 4: Construc¸˜ ao de link de acesso ` aRESTful API Os recursos s ˜ ao abstra c¸ ˜ oes que representam a informa c¸˜ ao sobre a qual operam as aplica c¸ ˜ oes RESTful API, identific ´ aveis e o seu conte ´ udo pode ser acedido atrav ´ es da interface da aplica c¸˜ ao. O acesso aos recursos n ˜ ao ´ e feito diretamente, mas sim atrav ´ es da sua c ´ opia, replicada a partir do estado da aplica c¸˜ ao num dado momento. Esta representa c¸˜ ao pode estar definida em diferentes formatos como XML,JSON,HTTP, entre outros. 3.7. RESTful API 37 OFHIR ´ e definido pela especifica c¸˜ ao RESTful API, com base na generalidade do uso do termo. Sendo um protocolo de informa c¸˜ ao, o FHIR depende da declara c¸˜ ao estrutural de recursos e interfaces o que, mesmo n ˜ ao estando de acordo com os princ ´ ıpios de RESTful API,´ e essencial na implementac¸˜ ao de interoperabilidade em diferentes sistemas. A API descreve os recursos FHIR como um conjunto de opera c¸ ˜ oes, formas de intera c¸˜ ao entre o cliente e o servidor. As entradas individuais s ˜ ao agrupadas por tipo e geridas pelo mesmo controlador, que por sua vez arbitra as interac¸˜ oes poss´ ıveis por tipo de dados. De seguida, na tabela 5, listam-se os conjuntos de intera c¸ ˜ oes poss ´ ıveis especificados em FHIR.FHIR (2019j) Interac¸˜ ao Descric¸˜ ao Interac¸ ˜ oes ao n´ ıvel das instˆ ancias de recursos read Leitura do estado atual de um recurso. vread Leitura do estado de uma vers ˜ ao espec ´ ıfica de um recurso. update Altera c¸˜ ao de recurso existente por identificador (ou sua criac¸˜ ao caso n˜ ao exista). patch Atualiza c¸˜ ao de um recurso promovendo diversas altera c¸ ˜ oes ao seu estado. delete Eliminac¸˜ ao de recurso. history Listagem do hist´ orico de alterac¸ ˜ oes a um recurso. Interac¸ ˜ oes com tipos de recursos create Criac¸˜ ao de recurso e atribuic¸˜ ao de identificador ´ unico. search Pesquisa de tipos de recursos com base em filtros por categoria. history Listagem de alterac¸ ˜ oes a determinado tipo de recurso. Interac¸ ˜ oes com o sistema capabilities Listagem dos tipos de intera c¸ ˜ oes existentes por recurso ou tipo. batch/transaction Opera c¸ ˜ oes Create, Read, Update, Delete (CRUD) a conjuntos de recursos. history Listagem de altera c¸ ˜ oes a todas as especifica c¸ ˜ oes da arquitetura. search Pesquisa ao longo de todos os elementos da estrutura do sistema. Tabela 5: Operac¸ ˜ oes FHIR sobre recursos, adaptado de FHIR (2019j) Ap ´ os o envio de um pedido, a aplica c¸˜ ao cliente aguarda o seu processamento e envio de uma resposta gerada a partir do servidor. Esta deve conter informa c¸˜ ao relativa ao sucesso ou falha da execu c¸˜ ao da opera c¸˜ ao e a mensagem gerada, uma de erro na eventualidade desta ocorr ˆ encia aquando do processamento ou a resposta ao pedido sob a forma de JSON. 3.8. Ferramentas de Desenvolvimento 38 3.8 ferramentas de desenvolvimento Em concord ˆ ancia com a especifica c¸˜ ao do projeto proposto e como forma de melhorar as ferramentas atualmente em utiliza c¸˜ ao nos hospitais p ´ ublicos em Portugal, foram desenvolvidos dois sistemas dependentes entre si para a execuc¸˜ ao da plataforma. O servi c¸ o de backend, desenvolvido em Node JS 1 , ´ e uma RESTful API capaz de mediar pedidos HTTP espec ´ ıficos relacionados com a gest ˜ ao do m ´ odulo de agendamento da plataforma AIDA. ´ E, para al ´ em do servi c¸ o do qual depende todo o funcionamento da plataforma AIDA OGT, utilizado como suporte a outras aplica c¸ ˜ oes e servi c¸ os da plataforma cuja especifica c¸˜ ao implique a gera c¸˜ ao ou leitura de informa c¸˜ ao referente ao contexto do agendamento hospitalar. Como forma de tornar mais intuitivo o processo de gest ˜ ao de informa c¸˜ ao relativa ao agendamento, foi desenvolvida em conjunto com profissionais de sa ´ ude p ´ ublica de diversas zonas do pa ´ ıs, uma aplica c¸˜ ao web, AIDA OGT, capaz de interpretar toda a informa c¸˜ ao proveniente de servi c¸ os AIDA (gest ˜ ao de acessos e agendamento) e reproduzir os fluxos de trabalho necess ´ arios para a ges ˜ ao de agendas e execu c¸˜ ao de marca c¸˜ ao de exames e consultas. De seguida, apresentam-se brevemente as ferramentas utilizadas para o alcance dos objetivos propostos, sendo a sua import ˆ ancia explicada no contexto do desenvolvimento do projeto. 3.8.1Base de Dados O processo de gest ˜ ao de agendamento hospitalar requer, como pr ´ e-requisito, a disponibilidade de uma larga escala de dados. Informa c¸˜ ao demogr ´ afica de pacientes, executantes e recursos hospitalares s ˜ ao alguns dos exemplos de dados necess ´ arios para o agendamento de consultas ou exames. A inser c¸˜ ao deste projeto no ˆ ambito da plataforma AIDA foi um dos fatores preponderantes na escolha do SGBD Oracle. O sistema, desenvolvido pela Oracle Corporation, ´ e um sistema de gest ˜ ao de bases de dados relacional, no qual dados s ˜ ao armazenados em tabelas relacionadas entre si por um conjunto de regras l ´ ogicas. A sua aplica c¸˜ ao ´ e frequentemente utilizada, para al ´ em do pr ´ oposito de armazenamento e gest ˜ ao de dados atrav ´ es do processamento transaccional em tempo real, como suporte a estruturas de Data Warehousing. Esta caracter ´ ıstica, ainda que a sua explora c¸˜ ao se encontre em fase de teoriza c¸˜ ao e desenvolvimento, est ´ a prevista no prop ´ osito da plataforma desenvolvida como forma de implementa c¸˜ ao de uma camada de Business Intelligence (BI) capaz de produzir informa c¸˜ ao anal ´ ıtica relevante para o contexto do agendamento e utilizac¸˜ ao de recursos hospitalares. ORA (2005) 1https://www.nodejs.org/ 3.8. Ferramentas de Desenvolvimento 39 No desenvolvimento do presente projeto, foram utilizadas as ferramentas DataGrip 2 e SQL Developer3na criac¸˜ ao e gest˜ ao das tabelas de dados afetas ` a plataforma. 3.8.2Programac¸˜ ao em Node JS O crescente grau de popularidade de desenvolvimento de aplica c¸ ˜ oes web tem promovido a introdu c¸˜ ao de ferramentas com melhores capacidades de processamento, configura c¸ ˜ oes de seguranc¸a e facilidade de desenvolvimento. O Node JS ´ e um software open source multi plataforma para compila c¸˜ ao e execu c¸˜ ao de c ´ odigo Javascript. ´ E ideal para o desenvolvimento de servi c¸ os backend para intera c¸˜ ao e processamento de informa c¸˜ ao em tempo real e de alta escalabilidade. Shah and Soomro (2017) Como forma de n ˜ ao sobrecarregar o processo de desenvolvimento e tirar o m ´ aximo partido do paradigma open source, ´ e poss ´ ıvel a inclus ˜ ao de m ´ odulos desenvolvidos por utilizadores para facilitar a acessibilidade a certos aspetos da linguagem. Este modelo, designado por Node Package Manager (NPM), ´ e importante no desenvolvimento de software pois, por um lado, reduz a carga de trabalho dos intervenientes no processo de desenvolvimento, como tamb´ em permite o acesso a m´ etodos mais eficientes e escal´ aveis. Dependˆ encia node-oracledb Um dos exemplos a referir no contexto do AIDA OGT ´ eom ´ odulo de integra c¸˜ ao com bases de dados Oracle. Este m ´ odulo permite, a partir de fun c¸ ˜ oes e m ´ etodos documentados a cria c¸˜ ao e gest ˜ ao de conex ˜ oes de uma ou v ´ arias inst ˆ ancias a uma Base de Dados (BD) Oracle e tomar partido da execu c¸˜ ao de queries Structured Query Language (SQL) para a sua administrac¸˜ ao. 3.8.3Framework Vue JS O Vue JS 4´ e um framework de JavaScript para a implementa c¸˜ ao de interfaces de utilizador e Single Page Applications (SPA), baseado na arquitetura de software Model View ViewModel (MVVM). A vantagem de utiliza c¸˜ ao de um framework progressivo para a implementa c¸˜ ao de p ´ aginas web ´ e a significativa simplicidade de renderiza c¸˜ ao progressiva de p ´ aginas da interface. No ciclo de constru c¸˜ ao de uma p ´ agina web, altera c¸ ˜ oes de elementos em tempo real s ˜ ao, de modo geral, opera c¸ ˜ oes dispendiosas de recursos computacionais. O Vue JS simplifica este processo atrav ´ es da virtualiza c¸˜ ao de componentes estruturais das p ´ aginas 2https://www.jetbrains.com/datagrip/ 3https://www.oracle.com/pt/database/technologies/appdev/sqldeveloper-landing.html 4https://www.vuejs.org/ 4.2. Arquitetura 46 permite identificar o utilizador no contexto do sistema, sem por em causa a seguran c¸ a da sua informac¸˜ ao pessoal. Por fim, todas as opera c¸ ˜ oes de gest ˜ ao de informa c¸˜ ao e conex ˜ ao ` as bases de dados do AIDA OGT dever ˜ ao ser mediadas pelo servidor de backend. Est ˜ ao dispon ´ ıveis e documentadas todas as fun c¸ ˜ oes CRUD por recurso e tipo de dados, assim como listagens de contexto espec´ ıfico. 4.2.3NextGen Connect/Mirth Assim como j ´ a referido, o Nextgen Connect ´ e uma ferramenta da ´ area da sa ´ ude destinada ` a integra c¸˜ ao de diferentes recursos. A integra c¸˜ ao da plataforma em diferentes hospitais pode significar que o armazenamento de dados externos ` a plataforma, mas importantes para o decorrer de certos fluxos, seja feito com base em diferentes vers ˜ oes da mesma estrutura de dados ou at ´ e estruturas diferentes. Com vista a resolver potenciais conflitos desta natureza, procedeu-se ` a implementac¸˜ ao de uma instˆ ancia de um servic¸o Nextgen Connect. Os dados geridos pelo servi c¸ o s ˜ ao externos ao contexto do agendamento, sendo aplicados em exclusivo ao m ´ odulo de emiss ˜ ao de convocat ´ orias. Este ´ e capaz de analisar a estrutura de dados vigente no ambiente hospitalar em que est ´ a inserido e convert ˆ e-la num formato pr´ e-definido pronto para ser consumido pela aplicac¸˜ ao. 4.2.4Base de Dados Oracle A implementa c¸˜ ao do sistema apresentado tem como pr ´ e-requisito a instala c¸˜ ao de uma base de dados OracleDB, configurada de acordo com a especifica c¸˜ ao de dados definida na figura 6. Os dados relativos ao agendamento garantem na totalidade a execu c¸˜ ao de todas as fun c¸ ˜ oes definidas para o efeito. No caso do m ´ odulo de emiss ˜ ao de convocat ´ orias, ´ e necess ´ ario o armazenamento de informa c¸˜ ao relativa aos pacientes do ambiente hospitalar. Esta informa c¸˜ ao pode ser obtida a partir de liga c¸ ˜ oes ` as bases de dados do SONHO atrav ´ es dos servi c¸ os AIDA. 4.2.5Estrutura de Dados A figura 6esquematiza, sob a forma de modelo entidade relacionamento, a estrutura de dados definida para suporte do AIDA OGT e o modo como a informac¸˜ ao se relaciona. As tabelas referentes aos recursos dispon ´ ıveis do ambiente hospitalar OGT CARETEAM, OGT PRACTITIONER, OGT TASK, OGT DEVICE e OGT LOCATION s ˜ ao alusivas, respetivamente, ` as equipas de trabalho dentro dos diversos servi c¸ os hospitalares, executantes, 4.2. Arquitetura 47 tarefas ou MCDT executados, dispositivos pr ´ oprios do ambente hospitalar e locais em que ´ e poss ´ ıvel levar a cabo as marca c¸ ˜ oes efetuadas. Esta ´ ultima tabela deve armazenar informa c¸˜ ao que n ˜ ao s ´ o identifique o local mas tamb ´ em o descreva geograficamente, sendo esta importante para a gerac¸˜ ao autom´ atica de convocat´ orias para envio aos pacientes. Uma das tabelas de maior relevo no ˆ ambito do projeto ´ e a OGT WORKLIST, tabela de armazenamento de todos os pedidos efetuados serve como meio de sele c¸˜ ao de pedidos cujo estado se enquadra no fluxo de agendamento, de entre os quais se salientam a necessidade de gera c¸˜ ao e associa c¸˜ ao de eps ´ odios de hospital de dia , pronto a agendar ou para reagendamento. Os pedidos s ˜ ao importados de uma tabela que faz o registo de todos os pedidos de um hospital e s ˜ ao mantidos na tabela OGT WORKLIST at ´ e ` a sua conclus ˜ ao, seja por anula c¸˜ ao ou concretiza c¸˜ ao da marca c¸˜ ao. Este processo foi desenhado tendo em conta o desempenho da aplica c¸˜ ao que, dada a elevada quantidade de dados armazenados na tabela pr ´ evia de pedidos, demonstrou uma melhoria significativa dos tempos de carregamento de dados a partir da implementac¸˜ ao. A estrutura de uma agenda recorre a trˆ es tabelas: •OGT SCHEDULE: Identifica as diferentes agendas existentes no meio. A cria c¸˜ ao de uma agenda implica a sua inser c¸˜ ao numa especialidade e categoria de servi c¸ o, filtros utilizados para listar agendas na aplica c¸˜ ao mediante o utilizador autenticado. A descri c¸˜ ao do hor ´ ario de uma agenda permite identificar e limitar dinamicamente cada agenda aquando do seu carregamento. Os relacionamentos com os recursos hospitalares permitem limitar as liga c¸ ˜ oes poss ´ ıveis entre entradas da tabela OGT SLOT e esses recursos, sendo que apenas s ˜ ao permitidas associa c¸ ˜ oes que estejam definidas tamb´ em entre a tabela OGT SCHEDULE e as tabelas de recursos. •OGT SLOT: Defini c¸˜ ao de manchas hor ´ arias para agendamento dentro de uma agenda. Permite, sob o formato JSON, a defini c¸˜ ao de regras extraordin ´ arias que limitem as possibilidades de agendamento nesse espa c¸ o, como o agendamento de exames com/sem contraste, a limita c¸˜ ao por g ´ enero ou idade do paciente, entre outros. A inclus ˜ ao destas regras permite n ˜ ao s ´ o um maior controlo sobre cada mancha hor ´ aria como tamb ´ em maior fidelidade em rela c¸˜ ao ao fluxo atual de gest ˜ ao de agendas. A correta configura c¸˜ ao de regras de slots ´ e utilizada por determinadas ´ areas de especializac¸˜ ao para o agendamento autom´ atico de exames. O slot pode apresentar os estados de livre, quando est ´ a dispon ´ ıvel para aceitar marca c¸ ˜ oes, ocupado quando tem pelo menos uma marca c¸˜ ao associada ou bloqueado, que representa a impossibilidade de agendamento para esse espac¸o de tempo. A cria c¸˜ ao de um slot implica tamb ´ em a defni c¸˜ ao do n ´ umero m ´ aximo de vagas dispon ´ ıveis, sendo que cada marca c¸˜ ao num slot apenas ocupa uma vaga. Quando exista a possibilidade de executar mais do que um exame no mesmo espa c¸ o de tempo ou a 4.2. Arquitetura 48 natureza deste implique uma multiplicidade de pacientes, deve definir-se a ocupa c¸˜ ao m ´ axima do intervalo. Durante o processo de agendamento, os slots cujo total de marca c¸ ˜ oes efetuadas seja inferior ao seu m ´ aximo de vagas ser ˜ ao disponibilizados para agendamento. Ainda que esteja prevista a sobrelota c¸˜ ao de espa c¸ os temporais, esta pr ´ atica n ˜ ao ´ e recomendada e apenas dever ´ a ser implementada caso o meio hospitalar em que a aplicac¸˜ ao est´ a implementada o requerir. •OGT APPOINTMENT: Tabela de armazenamento de todas as marca c¸ ˜ oes efetuadas. Cada marca c¸˜ ao tem de estar obrigatoriamente associada a pelo menos um slot, sendo poss ´ ıvel a associa c¸˜ ao com v ´ arios. A marca c¸˜ ao de consultas pode ser efetuada de diferentes modos, sendo o mais comum o agendamento singular. A marca c¸˜ ao de consultas pode ser feita a partir da sele c¸˜ ao de v ´ arios pedidos de um paciente para facilitar o seu encadeamento, denominado agendamento m ´ ultiplo. Al ´ em disso, ´ e poss ´ ıvel converter e importar marca c¸ ˜ oes de outras aplica c¸ ˜ oes e, como referido anteriormente, agendar exames automaticamente. O resto das tabelas foi gerado a partir do processo de normaliza c¸˜ ao da base de dados, culminando na cria c¸˜ ao de dez tabelas interm ´ edias, que mediam os relacionamentos das tabelas OGT SLOT e OGT SCHEDULE e as tabelas referentes aos recursos hospitalares. Por n ˜ ao estar diretamente inserida no m ´ odulo de agendamento, toda a informa c¸˜ ao necess ´ aria para a emiss ˜ ao de convocat ´ orias foi deixada de parte do modelo entidade relacionamento da figura 6. 4.2. Arquitetura 49 OGT_APPOINTMENT PK APPOINTMENT_ID NUMBER EXTERNAL_ID CLOB APPOINTMENT_UID VARCHAR2(256) STATUS VARCHAR2(1 BYTE) FK1 NUMPEDIDO VARCHAR2(128 BYTE) FK1 ID_PED VARCHAR2(128 BYTE) CREATED VARCHAR2(32 BYTE) START_TS VARCHAR2(30 BYTE) END_TS VARCHAR2(30 BYTE) DURATION NUMBER SCHEDULE_TYPE VARCHAR2(1 BYTE) ORDER_ID VARCHAR2(200 BYTE) SCHEDULED_BY VARCHAR2(64 BYTE) FK2 SLOT_ID CLOB OGT_CARETEAM PK CARETEAM_ID NUMBER CARETEAM_UID VARCHAR2(256) CARETEAM_NAME VARCHAR2(64) CARETEAM_COLOR VARCHAR2(20) OGT_DEVICE PK DEVICE_ID NUMBER EXTERNAL_ID CLOB DEVICE_UID VARCHAR2(256 BYTE) DEVICE_STATUS VARCHAR2(16 BYTE) DEVICE_NAME VARCHAR2(64 BYTE) SERIAL_NUMBER VARCHAR2(128) OGT_LOCATION PK LOCATION_ID NUMBER EXTERNAL_ID CLOB LOCATION_UID VARCHAR2(256 BYTE) LOCATION_NAME VARCHAR2(128) DESCRIPTION VARCHAR2(256 BYTE) TELECOM VARCHAR2(16 BYTE) ADDRESS VARCHAR2(128 BYTE) HOURS_OF_OPERATION CLOB LC_COMMENT CLOB OGT_PRACTITIONER PK PRACTITIONER_ID NUMBER PRACTITIONER_UID VARCHAR2(256) NUM_MECANOGRAFICO VARCHAR2(64) PRACTITIONER_NAME VARCHAR2(64) OGT_TASK PK TASK_ID VARCHAR2(20 BYTE) TASK_UID VARCHAR2(256 BYTE) TASK_CODE VARCHAR2(32 BYTE) TASK_NAME VARCHAR2(500 BYTE) AREA_ID VARCHAR2(32 BYTE) OGT_SLOT PK SLOT_ID NUMBER EXTERNAL_ID CLOB SLOT_UID VARCHAR2(256 BYTE) RULES CLOB FK SCHEDULE_ID NUMBER START_TS VARCHAR2(30 BYTE) END_TS VARCHAR2(30 BYTE) SLOT_STATUS NUMBER OVERBOOKED VARCHAR2(1 BYTE) SLOT_COMMENT VARCHAR2(256 BYTE) SCHEDULE_TYPE VARCHAR2(1 BYTE) LOCKED VARCHAR2(1 BYTE) ORDER_ID NUMBER MAX_VACANCIES NUMBER BOOKED_VACANCIES NUMBER OGT_SCHEDULE_CARETEAM PK SCHEDULE_CARETEAM_ID NUMBER SCHEDULE_ID NUMBER CARETEAM_ID NUMBER OGT_SCHEDULE_DEVICE PK SCHEDULE_DEVICE_ID NUMBER SCHEDULE_ID NUMBER DEVICE_ID NUMBER OGT_SCHEDULE_LOCATION PK SCHEDULE_LOCATION_ID NUMBER PK SCHEDULE_LOCATION_ID NUMBER SCHEDULE_ID NUMBER LOCATION_ID NUMBER OGT_SCHEDULE_PRACTITIONER PK SCHEDULE_PRACTITIONER_ID NUMBER SCHEDULE_ID NUMBER PRACTITIONER_ID NUMBER OGT_SCHEDULE_TASK PK SCHEDULE_TASK_ID NUMBER SCHEDULE_ID NUMBER TASK_ID VARCHAR2(20 BYTE) OGT_SLOT_CARETEAM PK SLOT_CARETEAM_ID NUMBER SLOT_ID NUMBER CARETEAM_ID NUMBER OGT_SLOT_DEVICE PK SLOT_DEVICE_ID NUMBER SLOT_ID NUMBER DEVICE_ID NUMBER OGT_SLOT_LOCATION PK SLOT_LOCATION_ID NUMBER SLOT_ID NUMBER LOCATION_ID NUMBER OGT_SLOT_PRACTITIONER PK SLOT_PRACTITIONER_ID NUMBER SLOT_ID NUMBER PRACTITIONER_ID NUMBER OGT_SLOT_TASK PK SLOT_TASK_ID NUMBER SLOT_ID NUMBER TASK_ID VARCHAR2(20 BYTE) OGT_SCHEDULE PK SCHEDULE_ID NUMBER EXTERNAL_ID CLOB SCHEDULE_UID VARCHAR2(256 BYTE) SCHEDULE_NAME VARCHAR2(256 BYTE) ACTIVE VARCHAR2(1 BYTE) SERVICE_CATEGORY CLOB SERVICE_TYPE CLOB SPECIALTY CLOB HORIZON_START VARCHAR2(30 BYTE) HORIZON_END VARCHAR2(30 BYTE) SCHEDULE_COMMENT VARCHAR2(256) OGT_WORKLIST PK ID_PED VARCHAR2(50 BYTE) PK NUMPEDIDO VARCHAR2(50 BYTE) EQUIPA VARCHAR2(20 BYTE) NSEQ VARCHAR2(30 BYTE) PROCESSO VARCHAR2(10 BYTE) NOME VARCHAR2(100 BYTE) SEXO NUMBER DATANASCIMENTO VARCHAR2(40 BYTE) DATAPEDIDO VARCHAR2(40 BYTE) EPISODIO VARCHAR2(10 BYTE) MODULO VARCHAR2(3 BYTE) MEDICO VARCHAR2(30 BYTE) ESPECIALIDADE VARCHAR2(200 BYTE) MODALIDADE VARCHAR2(20 BYTE) TAREFAS CLOB TAREFAS CLOB INFORMACAOCLINICA VARCHAR2(4000 BYTE) PROPRIEDADES CLOB SUGMARC CLOB GERAREPISODIO NUMBER GERAREPISODIMOD VARCHAR2(4 BYTE) EPISODIOGERADO NUMBER MODULOGERADO NUMBER DATAGERADO DATE USERGERACAO VARCHAR2(7 BYTE) MARCAR NUMBER DATAMARCADO VARCHAR2(40 BYTE) USERMARCADO VARCHAR2(7 BYTE) GERARSESSOES NUMBER DATAGERACAO DATE SESSOESGERADAS CLOB WL_COMMENT CLOB Figura 6: Modelo Entidade Relacionamento AIDA OGT 5 A N ´ ALISE E DISCUSS ˜ AO DE RESULTADOS Neste cap ´ ıtulo ´ e apresentado e discutido o projeto desenvolvido no ˆ ambito da disserta c¸˜ ao. A apresenta c¸˜ ao do projeto consiste na introdu c¸˜ ao dos elementos da aplica c¸˜ ao de maior relev ˆ ancia e a sua contextualiza c¸˜ ao nos requisitos funcionais da proposta. Para este efeito, s˜ ao inseridos alguns excertos da plataforma e explicadas as suas funcionalidades. A discuss ˜ ao dos resultados obtidos est ´ a dividida em duas sec c¸ ˜ oes. Inicialmente ´ e feita uma an ´ alise cr ´ ıtica ` a adequa c¸˜ ao das ferramentas e componentes utilizados ao desenvolvimento do projeto, sublinhando tanto os pontos a favor da sua utiliza c¸˜ ao como as suas desvantagens. A sec c¸˜ ao seguinte consiste numa reflex ˜ ao sobre a implementa c¸˜ ao do ponto de vista interno e ponto de vista externo, comparando o estado da aplica c¸˜ ao com potenciais concorrentes e destacando as suas caracter´ ısticas. 5.1 implementac¸˜ ao A presente sec c¸˜ ao serve de exibi c¸˜ ao e explica c¸˜ ao dos diversos componentes e funcionalidades da plataforma, que se divide em tr ˆ es sec c¸ ˜ oes de maior relevo, os componentes de gest ˜ ao e visualiza c¸˜ ao de agendas e de agendamento. O encadeamento da apresenta c¸˜ ao dos componentes ´ e feito pela ordem de preced ˆ encia necess ´ aria para o processo de agendamento: ´ e necess ´ ario, em primeiro lugar, configurar as agendas do ambiente em que a aplica c¸˜ ao se insere, para que depois seja poss ´ ıvel agendar e gerir marca c¸ ˜ oes dentro dessas mesmas agendas. A implementa c¸˜ ao do servi c¸ o de cliente foi alcan c¸ ada atrav ´ es da utiliza c¸˜ ao exclusiva do framework de Javascript Vue JS. A concretiza c¸˜ ao do design gr ´ afico de todos os componentes da aplicac¸˜ ao foi feita com recurso ao framework Vuetify. 5.1.1Autenticac¸˜ ao A utiliza c¸˜ ao da plataforma ´ e exclusiva a utilizadores credenciados de cada unidade hospitalar. A p ´ agina inicial de acesso ` a plataforma ´ e o formul ´ ario de autentica c¸˜ ao que, atrav ´ es do servi c¸ o 50 5.1. Implementac¸ ˜ ao 51 de verifica c¸˜ ao de credenciais fornecido para todas as aplica c¸ ˜ oes AIDA, permite limitar o acesso aos componentes sempre que esta seja acedida sem que as credenciais de acesso sejam fornecidas e devidamente autenticadas. O primeiro passo, executado antes da renderiza c¸˜ ao de cada p ´ agina da aplica c¸˜ ao, ´ e a verifica c¸˜ ao da presen c¸ a e caducidade do JWT. Sempre que haja uma falha neste passo, a p ´ agina de login ´ e chamada automaticamente, assegurando a integridade e seguran c¸ a da informac¸˜ ao da aplicac¸˜ ao, uma vez que nunca s˜ ao invocadas as rotas da RESTful API. A autentica c¸˜ ao de utilizadores ´ e maioritariamente executada a partir deste componente, mas n ˜ ao exclusivamente. A AIDA oferece uma plataforma de integra c¸˜ ao de aplica c¸ ˜ oes dentro do seu ˆ ambito que inclui o AIDA OGT. Dado que a implementa c¸˜ ao dos mecanismos de seguran c¸ a de autentica c¸˜ ao de credenciais ´ e semelhante para as aplica c¸ ˜ oes do ˆ ambito da AIDA, utilizadores autenticados podem aceder a todo o conte ´ udo do AIDA OGT, desde que estejam devidamente autenticados e possuam credenciais de acesso ` a plataforma. Esta funcionaliade ´ e tornada poss ´ ıvel atrav ´ es da partilha do JWT adquirido previamente que ´ e, aquando da tentativa de acesso ` a plataforma AIDA OGT, devidamente validado atrav ´ es de um servic¸o de validac¸˜ ao de credenciais externo. Figura 7: P´ agina de autenticac¸˜ ao Ap ´ os a autentica c¸˜ ao na aplica c¸˜ ao com sucesso, o utilizador ´ e redireccionado para a p ´ agina inicial, representada na figura 8. 5.1. Implementac¸ ˜ ao 52 5.1.2P´ agina Inicial Figura 8: P´ agina inicial p´ os autenticac¸˜ ao A p ´ agina inicial serve como roteador para os componentes da aplica c¸˜ ao e permite a execu c¸˜ ao de fun c¸ ˜ oes de acesso r ´ apido. A barra superior com o log ´ otipo da aplica c¸˜ ao e o bot ˜ ao de logout ´ e fixa e ´ e parte integrante de todos os componentes. O log ´ otipo da aplica c¸˜ ao permite, a qualquer momento, aceder ` a p´ agina inicial da aplicac¸˜ ao. A barra lateral esquerda cont ´ em dois bot ˜ oes de acesso direto aos componentes de cria c¸˜ ao de agendas e listagem geral de pedidos. ´ E poss ´ ıvel identificar pela figura 8duas tabelas de informa c¸˜ ao. A primeira tabela disp ˜ oe as agendas ` as quais o utilizador tem acesso, fornecendo os seguintes dados: •Nome: Identificador da agenda; •Hor´ ario: Horizonte de planeamento di´ ario; •Vagas Livres: N ´ umero total de vagas dispon ´ ıveis, contadas a partir do momento em que ´ e feito o carregamento dos dados. O n ´ umero est ´ a inserido num r ´ otulo colorido que indica, mediante a sua cor a necessidade de expans˜ ao das vagas da agenda; •Pr´ oxima Vaga Dispon´ ıvel: Data e Hora da pr´ oxima vaga dispon´ ıvel; 5.1. Implementac¸ ˜ ao 53 •´ Ultima Vaga Dispon´ ıvel: Data da ´ ultima vaga dispon ´ ıvel que, ` a semelhan c¸ a do n ´ umero de vagas livres se encontra inserido num r ´ otulo de cor vari ´ avel que indica a proximidade da ´ ultima vaga dispon´ ıvel da agenda; •Ver: Redirec¸˜ ao para o componente de visualizac¸˜ ao da agenda selecionada; •Gerir: Redirec¸˜ ao para o componente de gest˜ ao da agenda selecionada. A segunda tabela lista os ´ ultimos pedidos agendados pelo utilizador, os quais s ˜ ao apresentados por nome do paciente e respetivo n ´ umero de processo. Adicionalmente, ´ e poss ´ ıvel visualizar mais detalhes da marca c¸˜ ao, nomeadamente a agenda na qual o pedido foi marcado, bem como a data e hora da marca c¸˜ ao e o momento em que foi efetuado o registo. A ordena c¸˜ ao da lista ´ e feita, por defeito, pela data e hora do momento de agendamento, no entanto, ´ e poss´ ıvel ordenar a lista por qualquer um dos campos acima mencionados. A pen ´ ultima coluna da tabela permite a redire c¸˜ ao para o componente de visualiza c¸˜ ao da agenda em que a marca c¸˜ ao foi efetuada, sendo esta aberta na data da marca c¸˜ ao. Por fim, a ´ ultima coluna permite a gera c¸˜ ao autom ´ atica de uma convocat ´ oria em formato Portable Document File (PDF) a entregar ao paciente. Este bot ˜ ao ´ e acess ´ ıvel em diversas partes da aplica c¸˜ ao, quando existe informa c¸˜ ao sobre uma marca c¸˜ ao. A gera c¸˜ ao de convocat ´ oria ´ e executada numa nova p ´ agina. Primeiramente, s ˜ ao obtidos todos os dados necess ´ arios para a defini c¸˜ ao do utilizador, atrav ´ es do servi c¸ o NextGen Connect, descrito inicialmente na sec c¸˜ ao 4.2.3. O sucesso na obten c¸˜ ao desta informa c¸˜ ao permite ` a aplica c¸˜ ao a constru c¸˜ ao autom ´ atica de um documento que dever´ a fazer-se chegar ao paciente. 5.1.3Gest˜ ao de Agendas O componente de gest ˜ ao de agendas ´ e dos mais relevantes para o fluxo de agendamento. A correta parametriza c¸˜ ao de slots de agendas ´ e um dos aspetos fundamentais para a otimiza c¸˜ ao do fluxo de agendamento. A figura 9ilustra a vista inicial do componente de gest ˜ ao de uma agenda j´ a configurada. ` A semelhan c¸ a de outros componentes da aplica c¸˜ ao, encontra-se dividido em 3partes. A aplica c¸˜ ao foi desenhada para ser utilizada em computadores de uso pessoal independentemente do tamanho ou propor c¸˜ ao do seu ecr ˜ a, contudo, a sua utiliza c¸˜ ao em dispositivos de tamanho inferior ´ e limitada. Dada a quantidade de informa c¸˜ ao e funcionalidades dispon ´ ıveis nos componentes, a responsividade do tamanho dos componentes aquando da sua utiliza c¸˜ ao em smartphones ou tablets implica a redu c¸˜ ao das funcionalidades nestes formatos. Esta regra ´ e aplic´ avel a todos os componentes da aplicac¸ ˜ ao. A barra lateral esquerda ´ e composta por tr ˆ es sec c¸ ˜ oes, que foram agrupadas por fazerem refer ˆ encia direta aos slots da agenda a gerir. No topo encontra-se um calend ´ ario que serve 5.1. Implementac¸ ˜ ao 54 Figura 9: Ecr˜ a de gest˜ ao de agendas de apoio ao componente central, a agenda. O calend ´ ario permite a r ´ apida mudan c¸ a entre datas, afetando os dias apresentados na agenda. Cada dia do calend ´ ario com slots agendados apresenta, na parte inferior do n ´ umero referente ao dia, um pequeno c ´ ırculo colorido que representa a taxa de ocupa c¸˜ ao desse dia. O c ´ alculo da taxa de ocupa c¸˜ ao de um dia ´ e feito atrav ´ es da divis ˜ ao entre o somat ´ orio de slots bloqueados ou cujas vagas estejam ocupadas na sua totalidade e o n ´ umero total de vagas desse dia. A cor do c ´ ırculo difere consoante o c ´ alculo, sendo utilizada a cor vermelha para taxas de ocupa c¸˜ ao superiores a 80%, laranja entre 40% e 80% e verde, quando a taxa ´ e inferior aos 40%. O calend ´ ario destaca tamb ´ em a data selecionada, num tom escuro de verde com preenchimento e a data de hoje, circundada pela mesma cor. Na parte central da barra ´ e poss ´ ıvel filtrar os slots apresentados pelas suas caracter ´ ısticas. Para al ´ em dos filtros por equipa de trabalho, executante, tarefas pass ´ ıveis de execu c¸˜ ao, dispositivos e locais, ´ e poss ´ ıvel filtrar pelas regras definidas para os slots, determinadas dinamicamente atrav´ es dos slots em disposic¸˜ ao. Por fim, s ˜ ao apresentadas algumas indica c¸ ˜ oes sobre os slots: as contagens de slots dispon ´ ıveis para o resto da agenda, semana e m ˆ es. Estes servem como aux ´ ılio para mais facilmente se entender a quantidade de pacientes que ´ e poss ´ ıvel encaixar num dado horizonte de planeamento. ´ E tamb ´ em feita dinamicamente uma legenda da agenda, para melhor se entender a equipa afeta aos slots definidos. 5.1. Implementac¸ ˜ ao 55 A barra do lado direito cont ´ em todos os elementos necess ´ arios para a configura c¸˜ ao e submiss ˜ ao de slots. A escolha das manchas hor ´ arias a agendar ´ e feita clicando em hor ´ arios dispon ´ ıveis do calend ´ ario central. A figura 9, no espa c¸ o representado na coluna de domingo, entre as 14:00 e as 22:00, ilustra alguns slots selecionados para agendamento. A informa c¸˜ ao associada com os slots ´ e opcional para os par ˆ ametros de equipa, executante, tarefa, dispositivo e local. Por defeito, ´ e definida uma vaga por slot, valor que pode ser editado. A defini c¸˜ ao de regras para slots ´ e feita numa janela deslizante e permite a defini c¸˜ ao de limita c¸ ˜ oes dos slos selecionados. A gest ˜ ao das regras dispon ´ ıveis ´ e feita numa aplica c¸˜ ao externa ao AIDA OGT e ´ e exclusivamente utilizada na parametriza c¸˜ ao de slots de determindas especialidades para a marca c¸˜ ao autom ´ atica de consultas e exames. A sua implementa c¸˜ ao serviu como prova de conceito e prev ˆ e-se a generaliza c¸˜ ao do seu uso para a totalidade das agendas do sistema. A unidade central do ecr ˜ a ´ e a ´ area de visualiza c¸˜ ao e gest ˜ ao de manchas hor ´ arias de uma agenda. A agenda ´ e um componente vers´ atil que apresenta v´ arios pontos de interac¸˜ ao. No topo do componente, ´ e poss ´ ıvel identificar, oposto ao nome e hor ´ ario de opera c¸˜ ao da agenda, tr ˆ es bot ˜ oes que abrem, em painel deslizante, os componentes de replica c¸˜ ao e remo c¸˜ ao de slots e edi c¸˜ ao de agenda (os quais ser ˜ ao abordados em detalhe seguidamente). Mais abaixo encontram-se alguns bot ˜ oes de controlo da agenda. Os bot ˜ oes + e - permitem a amplia c¸˜ ao ou diminui c¸˜ ao da escala de intervalo da agenda, enquanto que os bot ˜ oes < e >permitem a navegac¸˜ ao para a pr´ oxima e anterior semanas. Com vista na otimiza c¸˜ ao dos tempos de carregamento das agendas, tendo em conta a quantidade de dados que cada slot pode suportar e os vastos horizontes de planeamento, o carregamento de slots ´ e feito apenas para a semana em disposi c¸˜ ao na agenda. Esta funcionalidade permite o r ´ apido acesso ` as agendas e permite atenuar a carga imposta em operac¸ ˜ oes de base de dados. O planeamento de agendas em ambiente hospitalar tem uma particularidade que permite um incremento significativo no tempo dispendido na configura c¸˜ ao de agendas. Sublinhado por Csenar (2019) e corroborado pelos administrativos hospitalares que acompanharam o processo de desenvolvimento, o planeamento de agendas em ambiente hospitalar ´ e feito entre as frequ ˆ encias semanal e mensal, isto ´ e, a defini c¸˜ ao de slots temporais numa agenda ´ e uma opera c¸˜ ao c ´ ıclica, sendo que, por vezes, o mesmo modelo semanal ´ e aplicado a meses de operac¸˜ ao. Com base neste requisito, foi criado um componente da gest ˜ ao de agendas para cria c¸˜ ao de slots temporais cujo ˆ ambito ´ e a replica c¸˜ ao de uma semana j ´ a definida. Isto permite a administrativos copiar integralmente todas as carater ´ ısticas de slots de uma semana para o intervalo temporal desejado. 5.1. Implementac¸ ˜ ao 62 5.1.5Agendamento O m ´ odulo de agendamento ´ e o componente principal de utiliza c¸˜ ao da aplica c¸˜ ao. Tem como base uma itera c¸˜ ao anterior tamb ´ em desenvolvida dentro do AIDA e o prop ´ osito da implementa c¸˜ ao foi a otimiza c¸˜ ao do fluxo de agendamento, numa tentativa de aumentar a quantidade de a c¸ ˜ oes dispon ´ ıveis e simplificar o processo na sua generalidade. O m ´ odulo de agendamento robusto e confi ´ avel ´ e fundamental na manuten c¸˜ ao de uma pluralidade de servic¸os e ´ e de importˆ anica renomada dentro de um contexto hospitalar. Figura 17: Selecc¸˜ ao de pedidos para agendar O primeiro passo do fluxo de agendamento ´ e a escolha de pedidos a agendar. Tendo em conta um dos principais fatores que levaram ` a reestrutura c¸˜ ao do m ´ odulo de agendamento, a possibilidade de encadeamento do agendamento de pedidos do mesmo paciente, ´ e permitida a sele c¸˜ ao m ´ ultipla de pedidos que podem ser agendados simultaneamente. A otimiza c¸˜ ao do processo de agendamento passa pela melhoria da qualidade de servi c¸ o prestado aos pacientes e a funcionalidade anteriormente descrita nasce da considera c¸˜ ao das potenciais dificuldades de um paciente se deslocar a um meio hospitalar em diferentes dias para realizac¸˜ ao de exames m´ edicos. A figura 17 foi editada de modo a demonstrar a listagem de pedidos existente e a sele c¸˜ ao de pedidos para agendamento do mesmo paciente. Em conformidade com os ecr ˜ as de gest ˜ ao e visualiza c¸˜ ao de agendas, pode observar-se ` a esquerda do componente o conjunto 5.1. Implementac¸ ˜ ao 63 de funcionalidades de filtro e ordenac¸˜ ao dos pedidos listados. Estas operac¸ ˜ oes permitem a modifica c¸˜ ao da listagem de pedidos com base numa sele c¸˜ ao ponderada dos seus par ˆ ametros. ´ E poss ´ ıvel observar na figura 17 a listagem de pedidos mais recentemente agendados. Para al ´ em da emiss ˜ ao r ´ apida de convocat ´ orias, esta tabela permite o acesso a informa c¸˜ ao sobre o agendamento destes pedidos e redirecionamento da aplica c¸˜ ao para o componente de visualizac¸˜ ao desse pedido. Aquando da sele c¸˜ ao de um pedido, este ´ e agrupado com outros pedidos do paciente focados numa barra lateral. A natureza da grande maioria dos pedidos submetidos para agendamento ´ e a de marca c¸˜ ao de MCDT que antecedem um consulta de avalia c¸˜ ao. De modo a orientar a administra c¸˜ ao de agendas e para melhor perce c¸˜ ao do prazo limite de agendamento do pedido, est ˜ ao associados a cada pedido tr ˆ es par ˆ ametros: dois relativos aos limites ideais da meta de agendamento e um com a data da pr ´ oxima consulta agendada para o paciente. A meta de agendamento deve ser tida em conta no enquadramento de um pedido, visto que ´ e uma indica c¸˜ ao dada pelo m ´ edico requisitante. Apenas dever ´ a ser permitido o agendamento fora da meta de agendamento quando n ˜ ao existam vagas para essa meta ou n˜ ao haja disponibilidade, da parte do paciente, para a presenc¸a nessas datas. O agrupamento de pedidos ´ e feito de acordo com as suas metas de agendamento, que serve como indica c¸˜ ao da possibilidade de encadeamento dos pedidos selecionados. ´ E permitido o agendamento de v ´ arios pedidos de um paciente que n ˜ ao coincidam na sua meta de agendamento mas, salvo as exce c¸ ˜ oes previstas acima, devem manter-se dentro da pr ´ opria meta. Cada pedido apresentado tem, para al ´ em da sua sele c¸˜ ao para agendamento, duas outras a c¸ ˜ oes dispon ´ ıveis, representadas pelos bot ˜ oes laterais vis ´ ıves na figura 17. O cancelamento de pedidos serve para permanentemente remover o seu registo da tabela OGT WORKLIST e enviar para os registos externos ` a plataforma com a indica c¸˜ ao da a c¸˜ ao, que carece a indica c¸˜ ao do motivo apresentado e a opc¸˜ ao de adic¸˜ ao de informac¸˜ ao textual. A outra a c¸˜ ao poss ´ ıvel ´ e o envio de pedidos para triagem. Existe um conjunto de motivos pelos quais possa ser necess ´ aria a invoca c¸˜ ao desta funcionalidade, sendo que os mais frequentes s ˜ ao a corre c¸˜ ao de poss ´ ıveis inconsist ˆ encias na gera c¸˜ ao do pedido ou a associa c¸˜ ao a epis ´ odios de Hospital de Dia (HDI), obtidos a partir da interopera c¸˜ ao com a plataforma SONHO. O envio de pedidos para triagem remove temporariamente o pedido da listagem e invoca os meios externos necess ´ arios para a ua corre c¸˜ ao. No final do processo, o pedido deve ser reinstaurado na listagem e agendado. O componente de agendamento de pedidos est ´ a demonstrado na figura 18. Nesta figura ´ e poss ´ ıvel distinguir a sele c¸˜ ao de tr ˆ es pedidos para agendamento, pertencentes ao mesmo paciente, mas com indica c¸ ˜ oes distintas. O carregamento da p ´ agina de agendamento altera a data do calend ´ ario para a menor data de in ´ ıcio de todas as metas de agendamento dos pedidos a agendar. Na eventualidade de n ˜ ao existirem vagas dispon ´ ıveis para o 5.1. Implementac¸ ˜ ao 64 Figura 18: Componente de agendamento dia, ´ e procurado o dia mais pr ´ oximo do calend ´ ario com possibilidade de agendamento e selecionado. Os slots dipostos na agenda s ˜ ao agrupados por pedido. Quando os pedidos para agendamento s ˜ ao escolhidos, ´ e enviada essa informa c¸˜ ao atrav ´ es de um pedido HTTP para a rota da RESTful API designada. Para cada pedido s ˜ ao lidos os atos m ´ edicos e a meta de agendamento e feita uma pesquisa de todos os slots que coincidam com esses fatores. O agrupamento de slots por pedido ´ e independente da agenda ` a qual pertencem. A sec c¸˜ ao esquerda do ecr ˜ a apresentado na figura 18 agrupa as caracter ´ ısticas de gest ˜ ao da agenda, ao centro da janela. No topo, o calend ´ ario segue o mesmo formato do dos componetes de gest ˜ ao e visualiza c¸˜ ao de agendas mas serve um prop ´ osito distinto. Em vez da dispoi c¸˜ ao da taxa de ocupa c¸˜ ao di ´ aria do calend ´ ario, cada c ´ ırculo colorido indica a presen c¸ a de vagas dispon ´ ıveis para o agendamento no dia. Cada c ´ ırculo ´ e referente ao pedido com o mesmo c ´ odigo de cor e nos dias em que n ˜ ao h ´ a nenhuma indica c¸˜ ao, n ˜ ao ´ e poss ´ ıvel agendar. Esta funcionalidade ´ e mais relevante na procura de datas para o encadeamento do agendamento dos pedidos selecionados. No exemplo apresentado na figura 18, ´ e poss ´ ıvel verificar pelo calend ´ ario que nos dias 5a9de julho ´ e poss ´ ıvel agendar todos os pedidos pretendidos atrav´ es do calend´ ario. Os filtros dispostos mais abaixo na sec c¸˜ ao s ˜ ao calculados dinamicamente com base nos pedidos escolhidos. Em primeiro lugar, ´ e poss ´ ıvel omitir e visualizar todos os slots, selecionando o pedido em quest ˜ ao. De seguida, ´ e poss ´ ıvel fazer esta sele c¸˜ ao por agendas 5.1. Implementac¸ ˜ ao 65 com slots dispon ´ ıveis. A remo c¸˜ ao da sele c¸˜ ao de uma agenda implica a omiss ˜ ao de todos os seus slots, independentemente do pedido a que estejam associados. Os filtros por regras s ˜ ao calculados assim que os slots para agendamento sejam enviados. ` A partida, existem regras que omitem automaticamente certos slots, como ´ e o exemplo das regras de sexo. Slots definidos com regra de exclusividade de atendimento a pacientes do sexo feminino n ˜ ao s ˜ ao apresentados em pedidos de pacientes do sexo masculino e vice versa. O componente central do ecr ˜ a segue o mesmo modelo dos anteriormente mencionados. Os slots s ˜ ao apresentados com as cores associadas a cada pedido e, para al ´ em da informa c¸˜ ao do seu hor ´ ario, exibem a agenda na qual est ˜ ao inseridos. A sele c¸˜ ao de um slot ´ e feita atrav ´ es de um clique, o que altera a sua cor para preto. ´ E poss ´ ıvel selecionar mais do que um slot para o mesmo pedido, se a dura c¸˜ ao da sua realiza c¸˜ ao se previr mais longa do que o agendado. Do lado direito est ˜ ao listados todos os pedidos com agendamento pendente. As suas informa c¸ ˜ oes de maior relev ˆ ancia, de entre as quais se destacam a data de requisi c¸˜ ao e requerente, informa c¸˜ ao cl ´ ınica do pedido, meta de agendamento e tarefas, est ˜ ao listadas com a cor atribu´ ıda aos slots do pedido. Por baixo de cada pedido, num componente dinˆ amico, est ´ a apresentado o slot selecionado ou, na eventualidade de n ˜ ao existirem slots dispon ´ ıveis para o pedido, essa informac¸˜ ao. De modo a facilitar a distin c¸˜ ao dos conjuntos de slots para cada pedido, foi implementada uma fun c¸˜ ao que faz uso da nota c¸˜ ao Hue, Saturation and Lightness (HSL), demonstrada na figura 19 para obter cores distintas para cada pedido. A cor associada a cada pedido ´ e obtida atrav ´ es da divis ˜ ao do ´ ındice do pedido atual pelo n ´ umero total de pedidos. Estas cores s ˜ ao depois convertidas em nota c¸˜ ao Red, Green and Blue (RGB), de modo a serem corretamente interpretadas pelo componente da agenda, assumindo os valores H,S e L dentro dos seguintes intervalos: 0≤H<1, 0 ≤S≤1, 0 ≤L≤1 (1) As equac¸ ˜ oes 2a5apresentam os c´ alculos interm´ edios da func¸˜ ao C= (1− |2L−1|)×S(2) X=C×(1− |H/6|mod 2 −1|)(3) m=L−C/2 (4) 5.1. Implementac¸ ˜ ao 66 (R0,G0,B0) =                            (C,X, 0)0≤H<1/6 (X,C, 0)1/6 ≤H<1/3 (0, C,X)1/3 ≤H<1/2 (0, X,C)1/2 ≤H<2/3 (X, 0, C)2/3 ≤H<5/6 (C, 0, X)5/6 ≤H<1 (5) Finalmente, os valores R,G e B s˜ ao obtidos atrav´ es da seguinte equac¸˜ ao: (R,G,B) = ((R0+m)×255, (G0+m)×255, (B0+m)×255)(6) 0 60 180 240 Figura 19: C´ ırculo crom´ atco HSL 5.1.6Agendamento Autom´ atico Assim como anteriormente mencionado, ´ e poss ´ ıvel efetuar o agendamento autom ´ atico de exames na plataforma. Esta opera c¸˜ ao est ´ a limitada, por enquanto, ao setor de servi c¸ os de Radiologia e opera a partir da defini c¸˜ ao de um conjunto espec ´ ıfico de regras de associa c¸˜ ao de slots de agendas. 5.2. Discuss˜ ao 67 Estas regras est ˜ ao relacionadas com par ˆ ametros espec ´ ıficos de MCDT da ´ area e devem ser associadas aos pedidos, assim como aos slots em que se pretendem fazer coincidir. Os tipos de regra necess´ arios s˜ ao os seguintes: •M´ odulo: Proveniˆ encia do pedido (Internamento, Consulta e Urgˆ encia); •Motivo: Raz˜ ao pela qual ´ e efetuado o pedido de realizac¸˜ ao de exames; •Regi˜ ao Anat´ omica: Regi˜ ao anat´ omica para a execuc¸˜ ao do exame; O envio destes par ˆ ametros em conjunto com a informa c¸˜ ao do pedido desencadeia o processo de pesquisa de slots dispon ´ ıveis e, consoante a sua disponibilidade, executa o agendamento do pedido, retornando a informac¸˜ ao do estado da operac¸˜ ao. 5.1.7Competˆ encias por utilizador Existem diferentes tipos de utilizadores nos ambientes hospitalares com acesso previsto ao AIDA OGT. O acesso ` as funcionalidades da plataforma varia consoante o tipo de utilizador autenticado. A tabela 6ilustra o grau de acesso garantido a cada utilizador. Administrador Gestor Auditor Administrativo Executante Perfil Cl´ ınico Gerir Agenda X X × × × × Bloqueio e Remoc¸˜ ao Vagas X X × × × × Agendamento X X ×X× × Envio para Triagem X X ×X× × Cancelamento de Pedidos X X ×X X X Visualizar Marcac¸ ˜ oes X X ×X X X Emitir Convocat´ orias X X ×X× × ´ Area de Conhecimento (BI) X X X × × × Visualizac¸˜ ao de Logs X×X× × × Tabela 6: Competˆ encias por tipo de utilizador 5.2 discuss ˜ ao O objetivo principal da presente disserta c¸˜ ao era o estudo e concep c¸˜ ao de uma plataforma de agendamento em ambiente hospitalar que, para al ´ em de ser implementada de modo a ser poss ´ ıvel competir com aplica c¸ ˜ oes de objetivo semelhante e do estado da arte, deveria incluir funcionalidades diretamente especificadas por profissionais de sa´ ude. O prot ´ otipo desenvolvido encontra-se em fase de testes da sua primeira vers ˜ ao e a sua implementa c¸˜ ao est ´ a, ` a data da reda c¸˜ ao da disserta c¸˜ ao, a ser avaliada por potenciais utilizadores finais, profissionais de sa ´ ude vinculados aos hospitais do servi c¸ o nacional de 5.2. Discuss˜ ao 68 sa ´ ude Centro Hospitalar Universit ´ ario do Porto (CHUP) eCentro Hospitalar do T ˆ amega e Sousa (CHTS). Em primeira inst ˆ ancia, e como forma de endere c¸ ar a primeira e segunda quest ˜ oes da sec c¸˜ ao 1.3, deve ser notada a mais-valia do suporte do protocolo de interoperabilidade na ´ area da sa´ ude implementado, o FHIR. A estrutura de dados de um SIH ´ e naturalmente complexa e o recurso ao protocolo permitiu, desde uma fase prematura do desenvolvimento da plataforma, a clara defini c¸˜ ao dos conceitos envolvidos no agendamento. A seguran c¸ a na conformidade e solidez da estrutura de dados do projeto foi um passo importante e a celeridade da sua implementa c¸˜ ao levou ` a dr ´ astica redu c¸˜ ao do tempo em que a aplica c¸˜ ao foi conclu ´ ıda. A maior vantagem do FHIR, sobretudo em rela c¸˜ ao a vers ˜ oes anteriores do protocolo ´ e o suporte de formatos textuais como JSON eXML. Esta mais valia est´ a representada na figura 20. MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4<cr> PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^ ^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520<cr> OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730||||||||| 555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F<cr> { "resourceType": "Practitioner", "id": "f002", "identifier": [{ "use": "official", "system": "urn:oid:2.16.528.1.1007.3.1", "value": "730291637" }], "name": [{ "use": "official", "family": "Voigt", "given": ["Pieter"], "suffix": ["MD"] }], "telecom": [{ "system": "phone", "value": "0205569336", "use": "work" }, { "system": "email", "value": "[email protected]", "use": "work" }], "address": [{ "use": "work", "line": ["Galapagosweg 91"], "city": "Den Burg", "postalCode": "9105 PZ", "country": "NLD" }], "gender": "male", "birthDate": "1979-04-29" } HL7 V2 HL7 FHIR Figura 20: Comparac¸˜ ao de tipos de dados de HL7V2eFHIR A especifica c¸˜ ao do protocolo ´ e simples de entender e a sua documenta c¸˜ ao ´ e clara e fornece os exemplos necess ´ arios para o seu perfeito entendimento.A r ´ apida compreens ˜ ao de objetos e a reduzida necessiade de parsing tornam o manuseamento de informa c¸˜ ao nestes formatos uma tarefa simples e com grande potencial. De modo a n ˜ ao complicar a estrutura pretendida para o projeto, aceitou-se minimizar o n ´ umero de campos definidos pelo FHIR ao estritamente necess ´ ario, passo que permitiu n ˜ ao sobrecarregar o trabalho de cria c¸˜ ao e gest ˜ ao de agendas por parte dos administrativos dos hospitais e reduzir a complexidade da implementa c¸˜ ao e manuten c¸˜ ao das bases de dados do sistema. 5.2. Discuss˜ ao 69 Os protocolos V2e V3da HL7mant ˆ em-se como os mais utilizados globalmente para tirar proveito da interoperabilidade. Information and Authority (2018) OFHIR, que apesar de n ˜ ao se encontrar na sua ver ˜ ao final e que continua sujeito a altera c¸ ˜ oes estruturais, demonstra a solidez necess ´ aria para se tornar o pr ´ oximo protocolo de elei c¸˜ ao no desenvolvimento de aplica c¸ ˜ oes interoper ´ aveis na ´ area da sa ´ ude. A utiliza c¸˜ ao da ontologia ´ e tamb ´ em uma mais valia por este aspeto: a partir do momento em que o modelo de agendamento est ´ a implementado segundo o FHIR, a sua especifica c¸˜ ao ´ e de conhecimento generalizado e a sua integra c¸˜ ao noutras plataformas est ´ a apenas dependente do conhecimento do protocolo. O segundo ponto a discutir ´ e a aptid ˜ ao da arquitetura proposta para a satisfa c¸˜ ao de todos os requisitos funcionais do projeto e implementa c¸˜ ao da plataforma. Os par ´ agrafos que se seguem s˜ ao referentes ` a quest˜ ao 3da secc¸˜ ao 1.3. Este dividir-se- ´ a em dois aspetos, a implementa c¸˜ ao do servidor como RESTful API e a utilizac¸˜ ao dos frameworks Vue e Vuetify como desenvolvimento gr´ afico da aplicac¸˜ ao. Da necessidade de gest ˜ ao de uma multiplicidade de pedidos em simult ˆ aneo e da promo c¸˜ ao da interoperabilidade entre sistemas, optou-se pela ado c¸˜ ao de um servidor de arquitetura RESTful API, em Javascript. O desenvolvimento do servidor na linguagem Javascript proporciona diversas vantagens. A utiliza c¸˜ ao de m ´ odulos como Express permite a r ´ apida configura c¸˜ ao do servidor e a sua cria c¸˜ ao atrav ´ es da invoca c¸˜ ao de um comando. A nota c¸˜ ao de objetos JSON tem integra c¸˜ ao direta com a linguagem, o que promove a compreens ˜ ao de mensagens FHIR. A defini c¸˜ ao de rotas do servidor permite a sua integra c¸˜ ao com aplica c¸ ˜ oes externas, desde sejam respeitados os parˆ ametros necess´ arios para a sua invocac¸˜ ao. O Vue era, dos tr ˆ es elementos mais relevantes da arquitetura, aquele que poderia ser substitu ´ ıdo por qualquer outro framework de desenvolvimento. A sua escolha debateu-se e eventualmente se aceitou devido a um conjunto de fatores: •Desenvolvimento em Javascript: Todo o scripting aplicado na parte gr ´ afica da aplica c¸˜ ao ´ e desenvolvido em Javascript. A utiliza c¸˜ ao de uma ´ unica linguagem de programa c¸˜ ao para o desenvolvimento do projeto ´ e vantajosa, sobretudo quando este ´ e desenvolvido em Full Stack; •Definic¸˜ ao de componentes: Os componentes em Vue s ˜ ao divididos em sec c¸ ˜ oes para uma mais simples compreens˜ ao da sua definic¸˜ ao; •Propriedades dinˆ amicas: As numerosas fun c¸ ˜ oes de filtro de slots e listagens podiam opor-se ao bom funcionamento da plataforma. A defini c¸˜ ao de propriedades din ˆ amicas em Vue permite a aplicac¸ ˜ ao destas func¸ ˜ oes sem abdicar do seu desempenho; 5.2. Discuss˜ ao 70 •Roteamento de pedidos: O m ´ odulo de roteamento de pedidos do Vue ´ e acess ´ ıvel e intuitivo na sua defini c¸˜ ao, para al ´ em de permitir a implementa c¸˜ ao de mecanismos de seguranc¸a por defeito ao n´ ıvel do acesso ` as rotas da aplicac¸˜ ao. A presente secc¸˜ ao ´ e finalizada com a resposta ` a quest˜ ao 4dos objetivos da dissertac¸˜ ao. A introdu c¸˜ ao de novas tecnologias, que na sua implementa c¸˜ ao, procuram responder ` as quest ˜ oes de usabilidade e experi ˆ encia solictiadas pelos utilizadores, faz com que os benef´ ıcios surjam de forma natural. Os processos de agendamento de uma unidade de sa ´ ude s ˜ ao bastante complexos e assumem, por vezes, condi c¸ ˜ oes inadequadas at ´ e para os pr ´ oprios profissionais de sa ´ ude que t ˆ em a tarefa de fazer as marca c¸ ˜ oes. A ado c¸˜ ao de um sistema de informa c¸˜ ao estruturado que proporciona fluxos e regras de agendamento bem definidas e concretas, facilita a sua utiliza c¸˜ ao, implementa c¸˜ ao e consolida c¸˜ ao no meio hospitalar. Ao conceder regras espec ´ ıficas faz com que o processo de decis ˜ ao e escolha de uma vaga seja mais orientado, diminuindo n ˜ ao s ´ o os tempos de marca c¸˜ ao, mas aumentando a qualidade da escolha da vaga para o pr ´ oprio doente. A escolha de vagas tendo em considera c¸˜ ao todas as condicionantes do paciente, como outras marca c¸ ˜ oes, outros pedidos, dist ˆ ancia ` a unidade de sa ´ ude e prioridade torna o processo mais flu´ ıdo, dinˆ amico e eficaz. 5.2.1An´ alise SWOT A An ´ alise SWOT ´ e uma t ´ ecnica de planeamento estrat ´ egico que permite a avalia c¸˜ ao cr ´ ıtica de uma solu c¸˜ ao com o intuito de delinear estrat ´ egias ao n ´ ıvel organizacional e competitivo. A an ´ alise interna de uma solu c¸˜ ao ´ e utilizada como modo de identifica c¸˜ ao dos seus recursos, capacidades e compet ˆ encias inerentes, de modo a estabelecer um grau de compara c¸˜ ao com ofertas similares. O seu objetivo ´ e obter e empregar conhecimento n ˜ ao s ´ o do seu ˆ ambito interno como aquele em que se insere, de modo a melhor formular estrat ´ egias para a sua produc¸˜ ao. Para al ´ em do acima referido, a an ´ alise SWOT ´ e uma t ´ ecnica conceptualmente simplificada e que n˜ ao envolve grande custo para levar a cabo. 5.2.2Enquadramento Te´ orico O processo da an ´ alise SWOT implica a listagem de pontos-chave referentes ` a solu c¸˜ ao apresentada, que podem ser classificados em quatro ´ areas que pertencem a duas dimens ˜ oes. A figura 21 ilustra a matriz de conceito aliada ao processo da an´ alise SWOT. Em primeira inst ˆ ancia, definem-se como dimens ˜ oes da an ´ alise os fatores internos e externos ` a solu c¸˜ ao. A natureza destas dimens ˜ oes ajuda a compreender o modo com os 5.2. Discuss˜ ao 71 Positivo Negativo Fatores Internos Fatores Externos Oportunidades Forças Fraquezas Ameaças Figura 21: Matriz conceptual de an´ alise SWOT pontos chave s ˜ ao seleccionados. Os fatores internos devem apresentar uma avalia c¸˜ ao cr ´ ıtica da solu c¸˜ ao comparativamente a sistemas similares no mercado. Dentro dos fatores internos ser ˜ ao considerados os pontos fortes, aqueles que afirmam a vantagem competitiva da solu c¸˜ ao e os pontos fracos, que, para al ´ em de permitirem a identifica c¸˜ ao de problemas afetos ` a conceptualiza c¸˜ ao e desenvolvimento da solu c¸˜ ao, podem servir como funda c¸˜ ao da promo c¸˜ ao de alterac¸ ˜ oes a esta. Do ponto de vista externo, ´ e importante a monitoriza c¸˜ ao constante das vari ´ aveis fora do ˆ ambito da solu c¸˜ ao que possam vir a por em causa a sua integridade ou competitividade. Dentro do mesmo dom ´ ınio, ´ e tamb ´ em importante reconhecer as oportunidades emergentes de investimento e explorar os fatores externos de modo a retirar o m´ aximo proveito destes. 5.2.3Aplicac¸˜ ao Pr´ atica Em concord ˆ ancia com o previamente mencionado, ´ e imperativo entender os pontos fortes e fracos da plataforma, bem como as oportunidades que podem existir e as amea c¸ as a serem consideradas. A an ´ alise desta plataforma foi realizada ap ´ os a sua execu c¸˜ ao em ambiente de testes inserido num sistema muito pr ´ oximo daquele que ser ´ a o seu contexto real. Segue-se a listagem dos pontos retirados da experiˆ encia realizada. Forc¸as (Strengths) •Elevada escalabilidade: A plataforma foi desenhada de modo a sustentar a estrutura integral de um ambiente cl ´ ınico e, como forma de n ˜ ao comprometer o seu desempenho, ´ e altamente escal´ avel; BIBLIOGRAFIA Database Concepts. Oct 2005. URL https://docs.oracle.com/cd/B19306 01/server.102/b14220/ intro.htm. Agfa healthcare, Mar 2021. URL https://global.agfahealthcare.com/scheduling/. Clinical software, Mar 2021. URL https://clin1mobile.net/scheduling-software. Luciana Almeida Cardoso and Ant ´ onio Abelha. Desenvolvimento de uma Plataforma baseadaem Agentes para a Interoperabilidade.2013. URL https://repositorium.sdum.uminho.pt/ bitstream/1822/27770/1/Luciana%20Almeida%20Cardoso.pdf. Tugba Cayrli and Emre Veral. Outpatient Scheduling in Health Care: A review of Literature. 2003. URL https://www.researchgate.net/publication/229881171 Outpatient scheduling in health care A review of literature. J ¨ urgen Cito, Vincenzo Ferme, and Harald C. Gall. Using docker containers to improve reproducibility in software and web engineering research. 2016. URL https://www.researchgate.net/publication/303515069 Using Docker Containers to Improve Reproducibility in Software and Web Engineering Research. Mag. Christopher Csenar. Design and development of a FHIR based mobile application for appointment scheduling in clinical context.2019. URL https://phaidra.fhstp.ac.at/open/o: 3929. Asuman Dogac, Tuncay Namli, Alper Okcan, Gokce Laleci, Yildiray Kabak, and Marco Eichelberg. Key issues of technical interoperability solutions in ehealth and the ride project. 2019. URL https://www.researchgate.net/publication/335362287 IMPROVING INTEROPERABILITY IN HEALTHCARE USING HL7 FHIR. Gang Du, Xinyue Li, Hui Hu, and Xiaoling Ouyang. Optimizing Daily Service Scheduling for Medica lDiagnostic Equipment Considering Patient Satisfaction and Hospital Revenue.2018. URL https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd= 4&ved=2ahUKEwjY5Z JxPbmAhWRDmMBHbKFCQoQFjADegQIBBAC. Health Level Seven FHIR. Resource appointment - hl7fhir, 2019a. URL https://www.hl7. org/fhir/appointment.html. 78 bibliografia 79 Health Level Seven FHIR. Resource careteam - hl7fhir, 2019b. URL https://www.hl7.org/ fhir/careteam.html. Health Level Seven FHIR. Resource device - hl7fhir, 2019c. URL https://www.hl7.org/fhir/ device.html. Health Level Seven FHIR. Resource location - hl7fhir, 2019d. URL https://www.hl7.org/ fhir/location.html. Health Level Seven FHIR. Resource patient - hl7fhir, 2019e. URL https://www.hl7.org/fhir/ patient.html. Health Level Seven FHIR. Resource practitioner - hl7fhir, 2019f. URL https://www.hl7.org/ fhir/practitioner.html. Health Level Seven FHIR. Resource schedule - hl7fhir, 2019g. URL https://www.hl7.org/ fhir/schedule.html. Health Level Seven FHIR. Resource slot - hl7fhir, 2019h. URL https://www.hl7.org/fhir/ slot.html. Health Level Seven FHIR. Resource task - hl7fhir, 2019i. URL https://www.hl7.org/fhir/ task.html. Health Level Seven FHIR. Hl7fhir, 2019j. URL https://www.hl7.org/fhir/. Gaurav Goyal, Karanjit Singh, and Dr. K. R. Ramkumar. A detailed analysis of data consistency concepts in data exchange formats (json & xml). 2017. URL https://ieeexplore. ieee.org/document/8229774. Tiago Andr ´ e Saraiva Guimar ˜ aes and Jos ´ e Machado. Ferramenta de Suporte ` a Decis ˜ ao e Pr ´ atica Cl ´ ınica em Unidades de Cuidados Neonatais e Pedi ´ atricos. 2015. URL https://repositorium.sdum.uminho.pt/bitstream/1822/40858/1/TiagoAndr\ let\begingroup\escapechar\m@ne\let\MT@subst@\OT1/pplj/m/it/10.95\def{\@@par}. McKay N. Heasley. Dynamic Appointment Scheduling in Healthcare.2011. URL https:// scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=4175&context=etd. Alan Hevner. Design science in the information systems. 2004. URL http://www3.cis.gsu. edu/vvaishnavi/9220Sp07/Documents/Hevner%20et%20al.%202004%20MISQ.pdf. Alan Hevner, Salvatore T. March, and Jinsoo Park. Design Science in the Information Systems Research.200. URL https://www.researchgate.net/publication/201168946 Design Science in Information Systems Research. bibliografia 80 Anke K. Hutzschenreuter, Peter A. N. Bosman, and Han La Poutr. Evolutionary Multiobjective Optimization for Dynamic Hospital Resource Management.2009. URL https://homepages.cwi. nl/∼bosman/publications/2009 evolutionarymultiobjectiveoptimization.pdf. Health Information and Quality Authority. Overview of healthcare interoperability standards. 2018. URL https://www.hiqa.ie/sites/default/files/2017-01/ Healthcare-Interoperability-Standards.pdf. Health Level Seven International. HL7International - Homepage.2020. URL https://www.hl7. org/about/index.cfm. Olaronke Iroju, Abimbola Soriyan, Ishaya Gambo, and Janet Olaleke. Interoperability in healthcare: Benefits, challenges and resolution. 2013. Vue JS. Vue js documentation, 2019. URL https://vuejs.org/v2/guide/. Salvatore T. March. Design and natural science research on information technology. 1995. URL http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.826.5567& rep=rep1&type=pdf. Fatma Poni Mardiah and Mursyid Hasan Basri. The Analysis of Appointment System to Reduce Outpatient Waiting Time at Indonesia’s Public Hospital.2019. URL http://article.sapub.org/ 10.5923.j.hrmr.20130301.06.html. Fernando Marins and Jos ´ e Machado. Monitoriza c¸˜ ao e Preven c¸˜ ao em Plataformas de InteroperabilidadeHospitalar.2013. URL http://repositorium.sdum.uminho.pt/bitstream/1822/27773/ 1/Fernando%20de%20Abreu%20Marins.pdf. Vitor Manuel Antunes Marto. A Gest ˜ ao da Mudan c¸ a em Sistemas de Informa c¸˜ ao: a migra c¸˜ ao do sistema de gest ˜ ao de doentes para a aplica c¸˜ ao SONHO V2no Centro Hospitalar de Leiria, EPE. PhD thesis, 2017. URL https://iconline.ipleiria.pt/bitstream/10400.8/2698/1/Disserta% C3%A7%C3%A3o%20-%20MGSIM%20-%20Vitor%20Marto.pdf. Suela Maxhelaku and Alda Kika. Improving interoperability in healthcare using hl7 fhir. 2019. URL https://www.researchgate.net/publication/335362287 IMPROVING INTEROPERABILITY IN HEALTHCARE USING HL7 FHIR. Hugo Peixoto, Manuel Santos, Ant ´ onio Abelha, and Jos ´ e Machado. Intelligence in Interoperability with AIDA.2012. URL https://link.springer.com/chapter/10.1007/978-3-642-34624-8 31. Hugo Peixoto, Tiago Guimar ˜ aes, and Jos ´ e Machado. A new architecture for intelligent clinical decision support for intensive medicine. 2020. bibliografia 81 Ivan Salvadori and Frank Siqueira. A maturity model for semantic restful web apis. 2015. URL https://www.researchgate.net/profile/Frank Siqueira/publication/281287283 A Maturity Model for Semantic RESTful Web APIs/links/5695351508ae820ff074a954.pdf. Hezbullah Shah and Tariq Rahim Soomro. Node.js challenges in implementation. 2017. URL https://www.researchgate.net/publication/318310544 Nodejs Challenges in Implementation. Junhui Song and Min Zhang. Design and implementation of a vue.js-based college teaching system. 2019. URL https://www.researchgate.net/publication/334468164 Design and Implementation of a Vuejs-Based College Teaching System. Jiafu Tang, Chongjun Yanb, and Pingping Cao. Appointment scheduling algorithm considering routine and urgent patients.2014. Terry Winograd. Designing a new foundation for design.2006. A A P ˆ ENDICE A a.1 development of fhir based web applications for appointment management in healthcare Autores Ant´ onio Chaves, Tiago Guimar˜ aes, Hugo Peixoto, Ant´ onio Abelha e Jos´ e Machado Conferˆ encia International Workshop on Healthcare Open Data, Intelligence and Interoperability (HODII) Resumo The integration of Information Technology systems in healthcare is no new concept, however, the ever growing solutions offered by the IT field are pushing a revamp of older implementations of Hospital Information Systems. Contemporary web-based solutions are now readily available and promise independence from operating systems and desktop bound systems, while incorporating faster and more secure methods. The focus on interoperable systems has been setting new goals towards fully computerized hospital management and the progress of healthcare standards over the years has made interoperability an obligation. The work presented hereby reflects a FHIR web based application to overcome the problem presented by scheduling and appointment management. Relac¸ ˜ ao com o trabalho realizado O presente artigo foi elaborado aquando do estudo da ontologia FHIR que permitiu a elabora c¸˜ ao da estrutura de dados proposta para a plataforma. O aprofundamento do conhecimento da tecnologia permitiu desenvolver a especificac¸ ˜ ao proposta para o projeto. 82 A.1. Development of FHIR based web applications for appointment management in healthcare 83 Estado Aceite para publicac¸˜ ao