SmartCall Mobile Core Service

O m ´oduloSmartCall_MCS ´e respons ´avel pela gest ˜ao de uma base de dados necess ´aria para garantir a persist ˆencia da informac¸ ˜ao dos utilizadores da aplicac¸ ˜ao m ´ovel.

Durante o desenvolvimento da aplicac¸ ˜ao tornou-se necess ´ario persistir alguns dados num servidor daOutsystemsde forma a efetuar a gest ˜ao de acessos atrav ´es das plataformas fornecidas pelaOutsystems. Como alguma da informac¸ ˜ao persistida apenas seria utilizada no contexto desta aplicac¸ ˜ao, a partilha e persist ˆencia na ´ıntegra da mesma com o sistema n ˜ao se tornou relevante.

Na Figura 4.7 ´e poss´ıvel observar o modelo de dados criado para a persist ˆencia da informac¸ ˜ao anteriormente referida.

CAP´ITULO 4. AN ´ALISE, DESENHO E IMPLEMENTAC¸ ˜AO

Figura 4.7: Modelo de dados do utilizador na aplicac¸ ˜ao.

De forma a acelerar muitos processos oOutsystems j ´a possui algumas tabelas de sistema como ´e o caso da tabelaUser. Esta persiste a informac¸ ˜ao dos utilizadores que possam ter acesso ao ambiente aplicacional e permite a gest ˜ao dos mesmos atrav ´es doService Studio. A utilizac¸ ˜ao desta tabela foi necess ´aria para que o potencial de informac¸ ˜ao local fosse aproveitado na sua totalidade, como ´e o caso da persist ˆencia de dados em sess ˜ao. Em relac¸ ˜ao `a adic¸ ˜ao de um registo nesta tabela, esse apenas acontece ap ´os a criac¸ ˜ao do utilizador no sistema SIREPH dado que se tornou necess ´ario a persist ˆencia doId externo do utilizador no campoExternal_Id.

A tabela OnBoardingUser tem como objetivo registar a informac¸ ˜ao alocada ao utilizador aquando do registo do mesmo. Esta tabela apenas mant ´em dados associadas ao utilizador aplicacional e alguns meios de contacto que possam ser ´uteis no ˆambito da aplicac¸ ˜ao como o n ´umero de telem ´ovel e o email, ´e ainda solicitado o preenchimento do cart ˜ao de cidad ˜ao (campo IdentificationNumber) dado que ser ´a esse o valor persistido comousername do utilizador. O campoHasSBVKnowledgeguarda a informac¸ ˜ao se o utilizador padr ˜ao da aplicac¸ ˜ao tem algum conhecimento de t ´ecnicas de SBV. Se a resposta for afirmativa, ent ˜ao a aplicac¸ ˜ao poder ´a ser configurada de forma a apresentar indicac¸ ˜oes mais concretas do que fazer em certas tipologias de ocorr ˆencias. A persist ˆencia da informac¸ ˜ao sobre a autorizac¸ ˜ao de termos e condic¸ ˜oes da utilizac¸ ˜ao da aplicac¸ ˜ao est ´a refletida nos camposHasAgreedWithTermseSignatureque, para efeitos de

46

CAP´ITULO 4. AN ´ALISE, DESENHO E IMPLEMENTAC¸ ˜AO auditorias, poder ˜ao vir a mostrar-se ´uteis. O resto da informac¸ ˜ao do utilizador ´e persistida na tabelaProfilee ser ´a detalhada de seguida.

No que toca `a informac¸ ˜ao que ´e necess ´aria persistir para os perfis que futuramente ser ˜ao utilizados para abrir uma ocorr ˆencia, esta encontra-se persistida na tabelaProfile. Esta tabela persiste a informac¸ ˜ao cl´ınica que poder ´a ser alterada sempre que necess ´ario de forma a que seja enviada a informac¸ ˜ao mais recente e correta para o sistema SIREPH. Para al ´em da informac¸ ˜ao b ´asica carater´ıstica (n ´umero de identificac¸ ˜ao, nome, apelido, morada, data de nascimento e g ´enero) ´e ainda solicitado:

• Contacto de emerg ˆencia (EmergencyContact) - Relevante para situac¸ ˜oes em que as v´ıtimas n ˜ao possuam nenhum contacto de emerg ˆencia no SNS ou que o mesmo esteja desatualizado;

• Grupo sangu´ıneo (BloodType) - Para casos em que o indiv´ıduo tenha conhecimento de qual o seu tipo de sangue pode ajudar a antever a necessidade do mesmo;

• Doenc¸as Cr ´onicas (CronicalDiseases) - Listagem concatenada de doenc¸as cr ´onicas que o indiv´ıduo possui;

• Alergias (Allergies) - Listagem concatenada de alergias que o indiv´ıduo possui. Esta informac¸ ˜ao pode prevenir a administrac¸ ˜ao de algum tipo de medicac¸ ˜ao que possa causar uma reac¸ ˜ao al ´ergica `a v´ıtima;

• Medicac¸ ˜ao recorrente (UsualMedication) - Listagem concatenada de medicac¸ ˜ao que o indiv´ıduo usa regularmente. Ao ter conhecimento de qual a medicac¸ ˜ao tomada pela v´ıtima, os intervenientes t ˆem uma maior facilidade em tratar a mesma;

De forma a tornar a aplicac¸ ˜ao f ´acil de utilizar, existe a possibilidade de adicionar uma fotografia a cada perfil de um indiv´ıduo. Esta fotografia poder ´a facilitar o processo de selec¸ ˜ao de v´ıtimas durante a abertura de uma ocorr ˆencia, visto que, a facilidade de interpretac¸ ˜ao de uma imagem

´e superior `a de um texto. Segundo as boas pr ´aticas recomendadas pela Outsystems [59], a informac¸ ˜ao de ficheiros persistida numa base de dados dever ´a ser, sempre que poss´ıvel, isolada da tabela a que se refere por forma a evitar que a informac¸ ˜ao seja sempre requerida mesmo quando n ˜ao ´e necess ´aria. Por essa raz ˜ao, foi criada a tabelaProfilePictureque tem o objetivo de persistir a fotografia associada a cada perfil registado sem que haja a necessidade de carregar a mesma sempre que se aceda `a informac¸ ˜ao cl´ınica de um indiv´ıduo. Esta tabela apenas possu´ı a informac¸ ˜ao do perfil a que se refere e a pr ´opria imagem.

De forma a suportar a funcionalidade de selec¸ ˜ao da tipologia da ocorr ˆencia, e garantir a escalabilidade da aplicac¸ ˜ao, foi ainda criado o modelo apresentado na Figura 4.8, utilizando entidades est ´aticas visto que estes registos n ˜ao seriam alvo de atualizac¸ ˜oes recorrentes.

A tabelaMotiveobservada na Figura 4.8 ´e respons ´avel por persistir os registos selecionados como tipologias de ocorr ˆencias [10]. Cada tipologia ter ´a uma descric¸ ˜ao t ´ecnica associada sendo que o texto apresentado na aplicac¸ ˜ao ser ´a algo mais gen ´erico (campolabel) e compreensivo

CAP´ITULO 4. AN ´ALISE, DESENHO E IMPLEMENTAC¸ ˜AO

para todos os indiv´ıduos. Como exemplo pr ´atico a tipologia de Obstruc¸ ˜ao da Via A ´erea ter ´a essa mesma descric¸ ˜ao por ´em, na aplicac¸ ˜ao aparecer ´a como Engasgo para que evitar qualquer hesitac¸ ˜ao sobre a sua definic¸ ˜ao. O campoOrder ´e utilizado para atribuir a ordem com que as tipologias aparecer ˜ao na aplicac¸ ˜ao considerando uma ordem decrescente face ao n ´umero de ocorr ˆencias verificadas para cada tipologia em 2021 [10].

Figura 4.8: Modelo de dados da tipologia de ocorr ˆencias na aplicac¸ ˜ao.

Cada tipologia inserida na aplicac¸ ˜ao dever ´a ter um canal associado. Na tabelachannel est ˜ao persistidos os canais para associac¸ ˜ao `as pr ´oprias tipologias. Cada canal de emerg ˆencia tem um contacto associado e umalabelque o permite identificar quando demonstrado ao utilizador atrav ´es da aplicac¸ ˜ao (ex: 112 - Linha de Emerg ˆencia M ´edica ou 808242424 - Linha Sa ´ude 24).

Durante o processo de desenvolvimento aplicacional surgiu ainda a necessidade de distinguir algumas tipologias de ocorr ˆencia dado que, consoante a sua criticidade, estas poderiam resultar na selec¸ ˜ao de diferentes canais. As tipologias que se encontravam nesta situac¸ ˜ao eram, na sua totalidade, tipologias associadas `a dor. Por essa raz ˜ao, e com base no algoritmo descrito em 4.2.1.8 foi criada uma tabela denominada dePainScalecom o objetivo de persistir informac¸ ˜ao associada a uma escala de dor. Para percecionar se determinada tipologia (motive) deveria ou n ˜ao estar associada a essa escala foi adicionado o campoIs_Painde forma a que fosse poss´ıvel efetuar a associac¸ ˜ao do canal atrav ´es de um dos seguintes registos ordenados de forma crescente consoante a sua criticidade:

1. Dor Suave - N´ıvel de Dor 2 2. Dor Moderada - N´ıvel de Dor 4 3. Dor Forte - N´ıvel de Dor 6 4. Dor Muito Forte - N´ıvel de Dor 8 5. Dor M ´axima - N´ıvel de Dor 10

48

CAP´ITULO 4. AN ´ALISE, DESENHO E IMPLEMENTAC¸ ˜AO Para o ˆambito de validac¸ ˜ao da pr ´opria aplicac¸ ˜ao foi considerado que um n´ıvel de dor superior a 6 estaria associado ao canal da Linha de Emerg ˆencia M ´edica e os restantes `a Linha Sa ´ude 24.