• Mobile Mashups, ou seja, a incorporac¸˜ao de aplicac¸ ˜oes e APIS j´a implementadas noutras situac¸ ˜oes;
• Interchangeable Applications, a utilizac¸˜ao de Intents ´e independente de uma deter- minada implementac¸˜ao em especifico.
O dispositivo n˜ao ´e um ambiente fechado, como qualquer sistema operativo destinado a utilizadores, permite a estender as suas funcionalidades utilizando aplicac¸ ˜oes. Estas podem ser desenvolvidas em Java em conjunto com o sistema de desenvolvimento do soft- ware Android(SDK). Software Development Kit disponibiliza ferramentas que permitem a programac¸˜ao de aplicac¸ ˜oes ou soluc¸ ˜oes para um determinado software.
Todas as aplicac¸ ˜oes Android desenvolvidas desta forma apresentam 4 componentes b´asicos na sua arquitetura [128]:
• Atividades, s˜ao porc¸ ˜oes de c ´odigo que podem ser chamadas quando necess´ario e correm num janela temporal desempenhando determinada tarefa. A maior parte do c ´odigo implementado ser´a neste formato;
• Servic¸os porc¸ ˜oes de c ´odigo que correm nos bastidores desempenhando func¸ ˜oes de interac¸˜ao com bases de dados por exemplo;
• Broadcast and Intent Receivers respondem a eventos recebidos na aplicac¸˜ao com origem no pr ´oprio Sistema Operativo (SO), numa outra aplicac¸˜ao ou por exemplo um aviso Push;
• Provedores de Conte ´udo, criados para partilhar dados entre atividades ou servic¸os. Android apresenta grande capacidade de reconhecer que dispositivos m ´oveis tˆem capa- cidades limitadas, assim sendo ajustam o seu ciclo de vida para melhorar e apresentar o melhor conte ´udo poss´ıvel ao utilizador. Como visto na figura 9 onde s˜ao definidas as di-
versas etapas e eventos pelo quais uma aplicac¸˜ao passa, este ´e completamente diferente daquele definido para uma aplicac¸˜ao de desktop. As abas ou vistas de uma aplicac¸˜ao s˜ao ent˜ao as atividades, quando um aplicac¸˜ao ´e iniciada ´e invocada a func¸˜ao onCreate(), onde as disposic¸ ˜oes gr´aficas s˜ao criadas. S ´o ap ´os a func¸˜ao onStart() ser “chamada” ´e que os pedidos a web services e outras func¸ ˜oes s˜ao executadas. Um ponto marcante na figura 9
´e a pergunta In Foreground, esta define o ciclo de vida de uma atividade. Se estiver em utilizac¸˜ao (Yes), segue o ciclo normal, caso contr´ario, passa diretamente para o ponto onS- top(), podendo voltar a ser utilizada e o c ´odigo volta ao estado onStart(), ou ent˜ao ´e Killed em definitivo, voltando ao ponto inicial. Embora os IDE e framewoks fac¸am este c ´odigo de forma autom´atica, ´e importante ter em conta este ciclo quando existem pedidos a web services, porque estes podem ditar atrasos em todo o processamento.
Figura 9.: Ciclo de vida de uma aplicac¸˜ao android (adaptado de [128]).
3.7.2 Java
A linguagem Java ´e uma linguagem orientada para objetos com base em classes, desen- volvida por James Gosling, colaborador da Sun Microsystems no ano de 1995 [129]. O principio por detr´as da linguagem ´e “write once run anywhere”. Ou seja o c ´odigo apenas deve ser compilado uma vez sendo que depois pode ser utilizado em qualquer m´aquina. Java ´e atualmente na vers˜ao SE 8, ´e uma das linguagens de programac¸˜ao mais utilizadas principalmente em aplicac¸ ˜oes cliente-servidor contando em todo o mundo com 9 milh ˜oes de programadores a utilizar a linguagem.
A linguagem foi criada com 5 princ´ıpios b´asicos [129]: • Deve ser simples, orientada a objetos e familiar; • Deve ser robusta e segura;
• Deve ser independente de arquitetura e port´atil;
• Deve ser executada com baixos recursos de processamento; • Deve ser interpretativa, dinˆamica e com recurso a threads.
Como dito anteriormente, ´e necess´ario uma plataforma para conseguir compilar um pro- grama, no contexto do presente cap´ıtulo ´e oSOandroid. Embora seja uma distribuic¸˜ao n˜ao
3.8. Conclus˜ao 63
oficial uma vez que utiliza caracter´ısticas de Java 6 e algumas de Java 8 numa libraria dife- rente do habitual (Apache Harmony). Apresenta uma virtual machine diferente que recorre tamb´em a um bytecode diferente (Dalvik bytecode) [129]. Por ser neste caso orientado para dispositivos m ´oveis, focou-se ent˜ao no baixo consumo de mem ´oria.
3.8 c o n c l u s˜ao
Ao longo do presente cap´ıtulo foram abordadas as ferramentas transversais a todos casos de estudo, que v˜ao ser apresentados nos pr ´oximos cap´ıtulos. Embora sejam ferramentas e linguagens distintas permite representar o vasto leque de recursos dispon´ıveis quando se pretende implementar soluc¸ ˜oes relativas `a partilha de informac¸˜ao.
Sem d ´uvida que os web services no acesso a informac¸˜ao em base de dados assumem ele- vada importˆancia dai a explicac¸˜ao um pouco mais exaustiva e a comparac¸˜ao entre diversos tipos.
O Angularjs ´e exemplo de uma framework recente que trouxe novas ideias ao mundo do desenvolvimento de soluc¸ ˜oes web e que simplifica em muito o trabalho do programador. Nomeadamente a utilizac¸˜ao de ferramentas que possibilitem a reutilizac¸˜ao de c ´odigo em diversas plataformas. A framework ´e exemplo disso mesmo. Utiliza o Angularjs apenas com diversas alterac¸ ˜oes nas tagsHTML, possibilitando a escrita de apenas um c ´odigo para Android e Web.
Aspetos mais t´ecnicos de cada secc¸˜ao n˜ao foram abordados por dois motivos, n˜ao ser esse o objetivo do presente projeto ou ent˜ao v˜ao ser referidos em maior detalhe no caso de estudo em que forem utilizados.
4
C A S O D E E S T U D O - S I S T E M A D E E N V I O E R E C E C¸ ˜A O D EM E N S A G E N S E M F O R M AT O H L 7
Num momento em que as autoridades um pouco por todo o mundo est˜ao a fomentar a interoperabilidade entre sistemas de informac¸˜ao ´e vital que no caso das unidades de sa ´ude existam sistemas de envio e recec¸˜ao de mensagens em formato Health Level Seven International (HL7)capazes de estar `a altura dos acontecimentos.
Embora n˜ao seja uma necessidade identificada no Centro Hospitalar do Porto uma vez que j´a existe um sistema respons´avel pelas funcionalidades descritas anteriormente, ´e im- portante ter sistemas alternativos com capacidade de competir com aquele implementado.
Ao longo do presente capitulo ´e ent˜ao apresentado o trabalho desenvolvido na criac¸˜ao de um sistema de envio e recec¸˜ao de mensagens em formatoHL7. Primeiro ´e feita uma pe- quena introduc¸˜ao e contextualizac¸˜ao com o tema, seguindo-se uma abordagem dos materi- ais e da metodologia implementada. Nas duas ´ultimas secc¸ ˜oes s˜ao apresentados resultados e conclus ˜oes.
4.1 i n t r o d u c¸ ˜ao e enquadramento no tema
A evoluc¸˜ao das Tecnologias de Informac¸˜ao e Comunicac¸˜ao (TIC) conduziu tamb´em a um r´apido desenvolvimento no campo dos sistemas de informac¸˜ao hospitalares. Cada vez mais, registos eletr ´onicos de pacientes, resultados provenientes do laborat ´orio, dados financeiros e outros s˜ao transferidos utilizando redes de computadores. Embora os avanc¸os emHealth Information Systems (HIS) se processem de forma quase exponencial, existem ainda alguns problemas relativos `a integrac¸˜ao de sistemas inform´aticos heterog´eneos.
Nos ´ultimos anos muito tem sido feito um esforc¸o para fomentar a interoperabilidade sint´atica entre sistemas que por natureza n˜ao comunicam utilizando um formato seme- lhante. Existem no entanto dificuldades/desafios para a comunicac¸˜ao de informac¸˜ao a n´ıvel de unidades de sa ´ude, como por exemplo [42]:
• Acesso a informac¸˜ao cl´ınica em m ´ultiplos sistemas de informac¸˜ao; • Pouco investimento por parte das instituic¸ ˜oes de sa ´ude;
• A criac¸˜ao de interfaces feitas `a medida de uma unidade de sa ´ude ou secc¸˜ao, aumenta a dificuldade da difus˜ao de informac¸˜ao;
• Interfaces bastante dispares entre sistemas dificulta o estabelecimento de protocolos de comunicac¸˜ao;
• Com o aumento do n ´umero de sistemas, o n ´umero de interfaces aumenta fazendo com que a dificuldade de conex˜ao seja superior.
Quando sistemas n˜ao conseguem por si s ´o comunicar, deve ser colocado entre ambos um “interprete” viabilizando assim a comunicac¸˜ao, fazendo uma analogia com o caso humano.
Neste cen´ario, as unidades de sa ´ude optam pela utilizac¸˜ao de standards de comunicac¸˜ao propostos pela HL7 International. Estes foram abordados com maior detalhe no cap´ıtulo 3,
devendo ser relembrado que esta organizac¸˜ao ´e respons´avel pelo lanc¸amento e a atualizac¸˜ao diversas diretrizes na tentativa de fomentar a interoperabilidade (Conceptual Standards, Do- cument Standards, Application Standards, Messaging Standards) [130, 131]. De entre as opc¸ ˜oes existentes aquelas que melhor desempenham o papel de “interprete” s˜ao message stan- dards, nomeadamente a vers˜ao 2 para a troca de mensagens em contexto cl´ınico [42]. A organizac¸˜ao n˜ao produz software, da´ı que todo o trabalho de desenvolvimento fica a cargo de empresas especializadas ou dos respons´aveis inform´aticos nas unidades de sa ´ude, se- guindo as guidelines publicadas. As implementac¸ ˜oes s˜ao a “face” doSistemas de Informac¸˜ao (SI)na rede que constitui osSistemas de Informac¸˜ao em Sa ´ude (SIS), denominadas de interfa- ces, apresentam a responsabilidade de enviar e receber dados e ainda perceber o meio onde est˜ao inseridas.
Representando esta, uma ´area de elevado interesse econ ´omico, existem diversas alternati- vas no mercado. No documento de 2012 intitulado “HL7 Interface Technology Survey Results” divulgado pela Core Health Technologies, ´e apresentada uma vis˜ao geral do mercado de interfaces HL7 [132]. As mais utilizadas s˜ao a Cloverleaf da Lawson (Quovadx), a Epic Bridges da Epic e o Mirth Connect da Mirth Corporation [132]. Nessa mesma lista surge ainda uma distribuic¸˜ao que nos ´ultimos anos tem ganho destaque, Iguana da empresa In- terfaceWare. Para al´em de apresentar uma interfacemais apelativa que as demais, surge com novas ideias relativas a Business Intelligence (BI) sobre troca de mensagens, controlo de agentes `a distˆancia e escrita de mensagens utilizando a plataforma Web disponibilizada. No mesmo documento ´e perceptivel que quando os respons´aveis de uma organizac¸˜ao op- tam por uma distribuic¸˜ao, n˜ao a pretendem substituir num futuro proximo. S ´o em casos de extrema necessidade, prova disso s˜ao os 70% de respostas negativas quando questionado se nos pr ´oximos 5 anos pretendiam alterar a suainterface[132].
Aplicac¸ ˜oes com a func¸˜ao dinterfaces˜ao um ingrediente essencial para alcanc¸ar a intero- perabilidade. Exemplos de aplicac¸ ˜oes que necessitam dessas implementac¸ ˜oes s˜ao oProcesso Cl´ınico Eletr´onico (PCE), oHIS, oRede Inform´atica da Sa ´ude (RIS), oLaboratory Information Sys-