Manual del Desenvolupador

20170607_Versió 1.9

1

Contingut Contingut ..................................................................................................................................................1

1 Introducció .......................................................................................................................................3

2 Tipologia d’App’s incloses al Portal AppSalut ..................................................................................4

2.1 App’s que no registren ni generen dades ................................................................................4

2.2 App que genera dades però no requereix de cap personalització per part d’un professional 4

2.3 App que genera dades i requereix una personalització per part d’un professional mitjançant un backoffice propi de l´aplicació ........................................................................................................5

3 Alta com a desenvolupador d’app’s al portal AppSalut ...................................................................5

4 Alta d’app’s al portal AppSalut .........................................................................................................5

4.1 Formulari d’alta d’una APP.......................................................................................................6

4.2 Descripció del procés d’alta. ....................................................................................................7

5 Modificació d’una APP .................................................................................................................. 10

6 Baixa d’una APP ............................................................................................................................. 10

7 Nova versió d’una app ja publicada .............................................................................................. 11

8 Funcionament del SDK .................................................................................................................. 11

8.1 Requeriments ........................................................................................................................ 12

8.1.1 Android .......................................................................................................................... 12

8.1.2 iOS ................................................................................................................................. 12

8.1.3 Frameworks requerits ................................................................................................... 12

8.2 Importar el SDK ..................................................................................................................... 13

8.2.1 Android .......................................................................................................................... 13

8.2.2 iOS ................................................................................................................................. 13

8.3 Ús dels SDK amb Android ...................................................................................................... 13

8.3.1 Inicialització ................................................................................................................... 13

8.3.2 Inici de sessió a PSD ....................................................................................................... 14

8.3.3 Estandardització de dades ............................................................................................ 15

8.3.4 Enviar dades a la PSD .................................................................................................... 15

8.4 Ús dels SDK amb iOS.............................................................................................................. 16

8.4.1 Inicialització ................................................................................................................... 16

8.4.2 Inici de sessió a PSD ....................................................................................................... 16

8.4.3 Estandardització de dades ............................................................................................ 17

8.4.4 Enviar dades a PSD ........................................................................................................ 17

8.5 API Errors ............................................................................................................................... 18

8.5.1 Iniciar sessió .................................................................................................................. 18

2

8.5.2 Enviar dades a PSD ........................................................................................................ 18

8.5.3 Logout ............................................................................................................................ 18

9 Integració del backofficede l’app .................................................................................................. 19

9.1 Passive STS ............................................................................................................................ 19

9.2 Agent SSO .............................................................................................................................. 20

9.3 Vinculació del professional – Usuari al Backoffice ................................................................ 20

10 Identificació de variables........................................................................................................... 20

3

1 Introducció

El portal AppSalut és un aparador d’aplicacions mòbils de l'àmbit sanitari i de benestar social. Les app’s publicades en aquest aparador, hauran superat un procés d’acreditació que consisteix en un seguit de criteris agrupats en 4 blocs: continguts i funcionalitats, seguretat, usabilitat i tecnològics.

Circuit d’alta, acreditació i publicació d’una APP al portal

Les app’s incloses en el portal AppSalut podran ser recomanades per part dels professionals de la salut i del benestar social als seus usuaris. A més a més, en el cas que l’app ho permeti i l’usuari accepti, les dades generades pels usuaris que facin servir les app’s recomenades pels seus professionals, seran emmagatzemades a la Plataforma de Salut Digital (PSD).

La Plataforma de Salud Digital (PSD) és un repositori on es recullen les dades de les aplicacions mòbils recomanades pels professionals i utilitzades pels usuaris. Els professionals podran consultar aquestes dades en qualsevol moment.

4

Aquestes dades podran ser utilitzades per part dels professionals per fer un seguiment de l’estat de l’usuari i personalitzar els serveis prestats.

Les aplicacions mòbils incloses en el portal AppSalut s’integraran amb la PSD perquè es puguin emmagatzemar les dades generades pels usuaris.

2 Tipologia d’App’s incloses al Portal AppSalut

Al portal AppSalut hi coexistiran tres tipologies diferents d´aplicacions:

App’s que no registren ni generen dades quan interactuen amb l’usuari

App que genera dades degut a la interacció amb l’usuari, però que no necessita ser parametritzada ni personalitzada per un professional mitjançant un backoffice propi de l´aplicació.

App que genera dades degut a la interacció amb l’usuari, i que necessita ser parametritzada i/o personalitzada per un professional mitjançant un backoffice propi de l´aplicació.

2.1 App’s que no registren ni generen dades

Aquest tipus d´app’s són aquelles que no generen ni registren dades quan interactuen amb els usuaris. Per tant, aquestes aplicacions tampoc poden enviar cap tipus d’informació als professionals o entitats proveïdores del sistema sanitari i/o de benestar social públic de Catalunya.

Com exemple d’aquesta tipologia d’app’s poden ser aquelles que només proporcionen informació o recomanacions a l´usuari, basades en guies clíniques vigents.

Aquesta tipologia d’app’s, no requereix la instal·lació de cap SDK (software development kit), ja que no hi ha intercanvi de dades.

2.2 App que genera dades però no requereix de cap personalització per part d’un professional

Les app’s, que degut a la interacció amb l’usuari generen dades i aquestes poden ser d’interès pel professional, hauran de descarregar i instal·lar un SDK (software development kit), mitjançant el qual, podrà enviar dades a la Plataforma de Salut Digital (PSD), sempre i quan:

1. l’usuari accepti un disclaimer legal i 2. l’usuari s’identifiqui mitjançant un codi personal

Amb aquesta condició les dades podran ser visualitzades pels professionals.

5

2.3 App que genera dades i requereix una personalització per part d’un professional mitjançant un backoffice propi de l´aplicació

Són aquelles app’s que, a l’igual que el cas anterior, generen dades amb la interacció amb l’usuari, però que a més compten amb un backoffice propi el qual permet als professionals del sistema sanitari i de benestar social públic de Catalunya personalitzar l’app en funció de les particularitats de cada usuari. hauran de fer l´acceptació de dos disclaimers amb dos SDK´s diferents. Un per la PSD i un altre per la pròpia aplicació de backoffice..

3 Alta com a desenvolupador d’app’s al portal AppSalut

Qualsevol desenvolupador que desitgi donar d’alta la seva app al Portal AppSalut, prèviament haurà de registrar-se com a usuari desenvolupador. Per registrar-se com desenvolupador caldrà realitzar els següents passos:

1. Accedir a l’espai del desenvolupador del portal AppSalut, per consultar les bases i condicions per a la publicació d’app’s: https://appsalut.gencat.cat/ca/web/marketplace/espai-del-desenvolupador .

2. Iniciar el procés de registre de nou usuari desenvolupador a través de l’enllaç habilitat a l’espai del desenvolupador.

3. Complimentar el formulari de registre, acceptar les condicions d’ús del portal AppSalut i enviar-lo. Un cop enviat el formulari de petició de registre, l’Oficina mHealth.cat de la Fundació TicSalut validarà les dades i, en cas de ser tot correcte, es procedirà a fer el registre i donar d’alta al nou usuari.

4. Un cop generat el nou usuari, s’enviarà un correu electrònic amb la contrasenya per accedir a l’espai privat del desenvolupador del portal AppSalut.

En el cas que el formulari no hagi estat omplert correctament, el desenvolupador rebrà un correu electrònic amb els motius/informació requerida per completar el procés de registre.

4 Alta d’app’s al portal AppSalut

Els usuaris desenvolupadors, un cop logats al portal AppSalut, poden donar d’alta la seva app per tal d’iniciar el procés d’acreditació.

Per tal de donar d’alta l’app al portal i iniciar el procés d’acreditació s’han de seguir les següents etapes, que són explicades tot seguit amb més detall:

6

4.1 Formulari d’alta d’una APP.

Tota la informació pertinent sobre l’app estarà recollida en el formulari d’alta; aquest formulari serà la base sobre la qual es realitzarà el procés de validació de l’app per acceptar-la com a candidata a ser acreditada. El formulari consta de diferents grups d’informació sol·licitada:

1. Identificació del nom de l’app i propietaris 2. Imatges i icones que presentaran l’app en el AppSalut un cop publicada

7

3. Dades tecnològiques de l’app: Sistemes Operatius, identificador en el App Store, etc. 4. Dades funcionals: objectius, descripció funcional, idioma(es) i a quin volum de públic

s’adreça

5. Descripció tècnica de l’app; dins aquest bloc es descriu si l’app recull o no dades i amb

quina freqüència, si dona recomanacions als usuaris, en quines guies de salut es basa l’app, etc.

6. Procés de qualitat: es demana incloure una sèrie d’informació sobre el procés de qualitat que ha passat l’app: certificacions, proves realitzades per tercers, etc.

7. Per tal de classificar l’app un cop publicada es demana al desenvolupador que identifiqui sota quines categories socials i de salut s’inclou l’app: és per a cuidadors, famílies, etc., quin tipus de problemes de salut tracta, a quin tipus de col·lectiu s’adreça....Aquesta informació s’ha de seleccionar d’entre les categories disponibles que presenta el propi formulari.

8. Per últim, però importantíssim per a les app’s que envien dades, es demana al desenvolupador que identifiqui amb quines variables treballa l’app.

4.2 Descripció del procés d’alta.

El procés per donar d’alta una nova app és el següent:

8

1. Accedir a l’apartat “Nova app” del menú esquerra de la part privada del desenvolupador del Portal AppSalut.

2. Generar En aquest pas, serà necessari que el sistema generi una API_KEY única per l’aplicació a través del formulari d’alta d’una nova app; només introduint el nom de l’app i prement el botó del final del formulari per generar la clau:

Obtindrem aquesta clau en l’apartat de seguretat del mateix formulari:

3. Descarregar el SDK de desenvolupament proporcionat en l’espai del desenvolupador del portal.

4. Incloure l’API_KEY al SDK.

5. Omplir el formulari d’alta d’una nova app. En aquest pas, serà necessari que el sistema generi una API_KEY única per l’aplicació que caldrà incloure-la a través del SDK de desenvolupament facilitat a l’espai del desenvolupador del portal AppSalut.

6. API_KEY, cal marcar l’opció “Guardar i generar clau de l’app” del formulari d’alta de l’app i a continuació es podrà consultar a l’apartat Seguretat del mateix formulari.

Un cop introduïda aquesta API_KEY a l’app, serà necessari pujar la nova versió de l’app als App Stores oficials (Google Play, iTunes, etc.) i acabar de completar el formulari d’alta d’una nova app.

7. Un cop omplert el formulari d’alta, el desenvolupador pot demanar iniciar el procés d’acreditació de l’app.

9

En el moment que el desenvolupador inici el procés d’acreditació, l’Oficina mHealth.cat procedirà a la revisió de la sol·licitud d’alta. En cas de que totes les dades siguin correctes, s’informarà al desenvolupador via correu electrònic del nivell (veure aquí informació sobre la classificació per nivells d’una app) en que ha estat classificada la seva app i el cost d’acreditació associat.

En aquest moment el desenvolupador ja pot procedir a realitzar el pagament del procés d’acreditació de l’app.

8. El pagament es realitzarà online dins de l’espai privat del desenvolupador amb una passarel·la de pagament del banc.

9. Un cop realitzat el pagament de l’acreditació de l’app, l’Oficina mHealth.cat es procedirà a completar el procés d’acreditació.

10. Finalitzat el procés d’acreditació, l’Oficina mHealth.cat enviarà via correu electrònic el resultat de l’acreditació de l’app al desenvolupador. En cas de que l’app superi de forma satisfactòria el procés d’acreditació, l’app quedarà publicada automàticament al Portal AppSalut.

El desenvolupador de l’app que no superi de forma satisfactòria el procés d’acreditació rebrà un informe de no conformitat. En aquest informe es detallaran els criteris pels quals la resolució de l’acreditació no ha estat favorable.

10

5 Modificació d’una APP

Un desenvolupador només pot modificar la informació proporcionada sobre una app a publicar al portal AppSalut:

1. mentre no hagi sol·licitat iniciar el procés d’acreditació (estat de l’app: esborrany) 2. o bé si l’Oficina mHealth.cat li rebutja l’app en revisar la seva sol·licitud (estat de l’app:

rebutjada). En aquest cas pot esmenar les dades del formulari d’alta d’app i tornar a sol·licitar el procés de revisió.

Per modificar les dades de l’app, el desenvolupador (un cop logat) por accedir a través del botó “les meves apps” del menú esquerra i clicar en la icona de formulari de l’app:

6 Baixa d’una APP

Un desenvolupador pot donar de baixa una app mentre no hagi sol·licitat el procés de revisió. Per donar de baixa l’app, el desenvolupador (un cop logat) por accedir a través del botó “les meves apps” del menú esquerra i clicar en la icona d’eliminació de l’app:

Si l’app ja ha estat publicada, el desenvolupador pot sol·licitar la baixa; aquest serà executada per l’Oficina mHealth.cat.

L’esborrat d’una app sempre es lògic, l’app queda marcada en estat “esborrada”.

11

7 Nova versió d’una app ja publicada

El desenvolupador que disposi d’apps publicades al portal AppSalut, en qualsevol moment tindrà disponible un llistat amb totes les seves apps, on podrà consultar les dades referents a les seves aplicacions, realitzar una petició de baixa o demanar una reacreditació de l’app per noves versions.

8 Funcionament del SDK

El SDK permet al desenvolupador d’una app que envií dades i que es vol incloure al portal AppSalut, utilitzar els serveis de PSD des de codi natiu Android / iOS.

Bàsicament el SDK implementa les funcionalitats:

1. Gestiona el disclaimer legal d’enviament de dades 2. Gestiona l’inici de sessió de l’usuari amb la seva contrasenya i el logout de la connexió amb la

PSD 3. Realitza l’enviament de dades a la PSD

A continuació detallem breument alguns aspectes de cada funcionalitat esmentada:

Gestió del disclaimer legal.

Tal i com s’ha comentat abans, per tal d’enviar les dades generades per l’app a la PSD, l’usuari obligatòriament ha d’acceptar un disclaimer legal. Aquest disclaimer legal serà necessari que es mostri a l’inici de l’app, el primer cop que l’usuari s’instal·la l’app. En el cas que l’app ja mostri a l’usuari un disclaimer legal propi, el disclaimer legal del SDK es mostrarà seguidament.

Gestió del inici i final de sessió.

Per l’enviament de dades a la PSD s’ha d’establir sessió amb la PSD. Això només serà possible si l’usuari ha acceptat prèviament el disclaimer legal del SDK.

El login es realitza amb el CIP del pacient i una contrasenya; aquesta contrasenya la rebrà l’usuari via SMS en el moment que el metge li recomani una app. En cap cas el CIP del pacient es guarda a la PSD, sinó que en el login es transforma en un id de pacient intern del sistema.

En cas que l’usuari desitgi no seguir compartint dades, l’app ha d’oferir l’opció de fer logout de la sessió. Aquesta acció invalidarà la sessió de l’usuari al dispositiu i a partir d’aquest moment les dades generades per l’app no es compartiran a PSD. En el cas que l’usuari desitgi tornar a enviar dades, l’app haurà d’oferir la possibilitat de tornar a enviar dades mostrant novament el disclaimer legal. El procés tornaria al punt 2 d’aquest procés: Inici de sessió de l’usuari amb la seva contrasenya.

12

Enviament de dades a la PSD

Per tal de poder enviar dades a la PSD una app:

o Ha d’estar acreditada i publicada al portal o L’app ha d’haver estat recomanada per un professional a un pacient o El pacient ha d’acceptar el disclaimer legal.

L'enviament de dades es realitza a partir de variables oficials que estan donades d'alta al subconjunt de variables del portal AppSalut i que el desenvolupador haurà identificat en donar d’alta l’app. Una variable que no estigui categoritzada dintre del portal serà ignorada pels visors de dades, fins que aquesta estigui donada d’alta al subconjunt. Per tal de donar d’alta una nova variable no inclosa en el subconjunt existent, el desenvolupador proposarà, a través del formulari d’alta de l’app, la inclusió de la nova variable a la Oficina mHealth.cat de la Fundació TicSalut.

Les dades que l’app envia a la PSD (una o vàries) s’han de transmetre a través d’un missatge que té sempre l’estructura següent:

VARIABLE – VALOR

On la variable és el codi de la variable al subconjunt de variables (SNOMED CT, CIM-9, etc.) i VALOR és el seu valor. Per exemple: 27113001 60, on 27113001 es correspon amb el codi de la variable pes i 60 n’és el seu valor. El SDK també necessita poder enviar la data i hora en què s’ha registrat el valor concret de la variable.

8.1 Requeriments

8.1.1 Android

Nom Versió

Android API >= 15

Android Studio >= 1.2.X

8.1.2 iOS

Nom Versió

Sistema Operatiu >= 7

8.1.3 Frameworks requerits

13

Nom Versió

AssertsLibrary.framework *

MobileCoreServices.framework *

SystemConfiguration.framework *

8.2 Importar el SDK

8.2.1 Android Passes a seguir des de Android Studio :

1. Descarregar el SDK des de l’espai del desenvolupador del portal AppSalut. 2. Des de el menú: File -> New -> New Module -> Import .JAR/.AAR 3. Seleccionar l’arxiu i assignar un nom al mòdul (Ex. sdk-psd) 4. Des de l’arxiu gradle de la app en ‘dependencies' poner:

a. compile project(‘:sdk-psd’)

Atenció als dos punts : davant del nom assignat

4. Sincronitzar el projecte

8.2.2 iOS

Descarregar el SDK des de l’espai del desenvolupador del portal AppSalut.

Arrossegar el SDK al projecte

Vincular al projecte els frameworks:

o AssetsLibrary.framework o MobileCoreServices.framework o SystemConfiguration.framework

8.3 Ús dels SDK amb Android

8.3.1 Inicialització

A la Activity principal on l’aplicació comença l’execució, s’ha d’afegir la següent sentència per a què aquesta tingui accés a poder interactuar amb PSD.

@Override Protected void onCreate(BundlesavedInstanceState) {

super.onCreate(savedInstanceState); setContentView(R.layout.activity_main);

14

PSD.initialize(getApplicationContext(), "API_KEY"); // …

}

* Important: L’API_KEY és única per cada app i la generarà el portal AppSalut en el moment que es dóna d’alta una app en estat Esborrany abans del procés d’acreditació, o quan es fa una nova re-acreditació d’una nova versió de la mateixa. Un cop introduïda aquesta API_KEY a l’app, serà necessari pujar la nova versió de l’app als App Stores oficials (Google Play, iTunes, etc.) i acabar de completar el formulari d’alta d’una nova app / versió. Per a més informació veure el punt 4: Alta d’app’s al portal AppSalut d’aquest document.

8.3.2 Inici de sessió a PSD

La classe PSDService proveeix dels mètodes necessaris per tenir el control de la sessió d’usuari. Retorna true o false segons si l’usuari ha iniciat sessió amb PSD a l’aplicació.

PSDService.isLogged() : Boolean

Per a què l’usuari inici sessió es demanarà acceptar un disclaimer legal. En cas d’acceptar aquest disclaimer, es requereix que l’usuari informi de la seva contrasenya per poder autoritzar l’enviament de dades a PSD. El servei d’iniciar sessió dóna el control d’errors mitjançant el bloc success o error.

PSDService.login(Activityactivity, newPSDCallback {

@Override

publicvoidsuccess() {

// …

}

@Override

publicvoid error(PSDException e) {

//…

}

});

D’aquesta manera, al fer servir l’Activity com un paràmetre de login, es pot accedir a l'Activity on llança un diàleg amb el disclaimer. En cas que l’usuari l’accepti, es mostrarà sobre la mateix vista un diàleg amb el formulari, perquè l'usuari pugui iniciar sessió. Aquest diàleg és gestionat automàticament per la PSD i no requereix de configuració prèvia. També és necessari realitzar un control del logout d’un usuari a PSD, en el cas que aquest decideixi no seguir compartint les dades generades per l’app. Per esborrar la sessió de l'usuari, cal cridar al mètode:

15

PSDService.logout(newPSDCallback {

@Override

publicvoidsuccess() {

// …

}

@Override

publicvoid error(PSDException e) {

//…

}

});

Aquest servei dóna el control d’errors mitjançant el bloc success o error.

8.3.3 Estandardització de dades

PSDData contindrà l’agrupació de les dades que s’enviaran posteriorment.

PSDDatapsdData = newPSDData();

psdData.add(String variableCodi, String variableValue, Date

dataDeRegistre);

Si algun paràmetre és nul o és un string buit, llançarà una excepció.

8.3.4 Enviar dades a la PSD

PSDService.sendVariables(PSDData data, newPSDCallback() { @Override publicvoidsuccess() { // ...

} @Override publicvoid error(PSDException e) { // ... }

});

* Important: Aquests mètodes només es poden cridar si l’usuari ha iniciat sessió introduint la seva

contrasenya, en cas contrari donarà error.

16

8.4 Ús dels SDK amb iOS

8.4.1 Inicialització

En el mètode application:didFinishLaunchingWithOptions: del fitxer App Delegate de la nostra aplicació cal introduir l’API_KEY.

[PSDInitializersetApiKey:@”API_KEY”];

* Important: L’API_KEY és única per cada app i la generarà el portal AppSalut en el moment que es dóna d’alta una app en estat Esborrany, abans del procés d’acreditació.

8.4.2 Inici de sessió a PSD

La classe PSD proveeix dels mètodes necessaris per tenir el control de la sessió d’usuari.

[PSD isLogged];

Retorna TRUE o FALSE segons si l’usuari ha iniciat sessió amb PSD a l’aplicació.

Per a què l’usuari inici sessió es demanarà acceptar un disclaimer legal. En cas d’acceptar aquest

disclaimer, es requereix que l’usuari informi de la seva contrasenya per poder autoritzar l’enviament

de dades a PSD.

[PSD loginWithSuccess:^{

//. . .

} failure:^(NSError *error) {

// . . .

}];

Aquesta funcionalitat es gestiona automàticament per la PSD i no requereix de configuració prèvia.

També és necessari realitzar un control del logout d’un usuari a PSD, en el cas que aquest decideixi

no seguir compartint les dades generades per l’app. Per esborrar la sessió de l'usuari, cal cridar al

mètode:

[PSD logoutWithSuccess:^{

//. . .

17

} failure:^(NSError *error) {

// . . .

}];

8.4.3 Estandardització de dades

Totes les dades del portal AppSalut iOS SDK utilitzen la classe PSDObject. PSDObject conté dues propietats obligatòries, el nom de la variable que guardem i un valor concret.

[PSDObjectobjectWithVariable:@”variable”

andValue:@”value”];

Per tal de treballar amb un conjunt de dades s’utilitza la classe PSDData, que agrupa un conjunt de PSDObject.

PSDData *data = [PSDDataalloc] init];

[data addObject: [PSDObjectobjectWithVariable:@”variable”

andValue:@”value” andDate:NSDate]];

8.4.4 Enviar dades a PSD

El SDK permet enviar una dada o un conjunt de dades.

Enviar una dada:

PSDObject *object = [PSDObjectobjectWithVariable:@”variable”

andValue:@”value”];

[PSD saveObject:object

success:^{

//...

} failure:^(NSError *error) {

//...

}];

Enviar més d’una dada:

18

PSDData *data = [PSDDataalloc] init];

[data addObject:[PSDObjectobjectWithVariable:@”variable”

andValue:@”value”]];

[PSD saveObjects:data

success:^{

//...

} failure:^(NSError *error) {

//...

//...

}];

*Important: Aquests mètodes només es poden cridar si l’usuari ha iniciat sessió, en cas contrari donarà error.

8.5 API Errors

8.5.1 Iniciar sessió

En el cas que, alhora d’iniciar sessió, la contrasenya no sigui vàlida retornarà una excepció, que l’app haurà de controlar i tractar.

8.5.2 Enviar dades a PSD

Per poder enviar dades a PSD, és necessari que es compleixin 3 prerequisits:

L’app ha d’estar acreditada

Que l’aplicació sigui recomanada a l’usuari que envia les dades. En cas que l’usuari no tingui l’aplicació recomanada, no podrà enviar les dades.

Que l’usuari accepti el disclaimer legal i hagi introduït una contrasenya correcta.

8.5.3 Logout

En cas que el dispositiu no tingui connectivitat amb els servidor de PSD, el mètode de logout llançarà una excepció que caldrà controlar per l’app i mostrar un missatge d’error a l’usuari, ja que es mantindrà la sessió de l’usuari a PSD.

19

9 Integració del backofficede l’app

En cas que l’app que es vulgui publicar al Portal tingui un backoffice de gestió perquè un professional pugui configurar o personalitzar l’app a un usuari, està prevista una integració Single Sign On entre el portal AppSalut i el backoffice de gestió de l’app pel perfil professional. D’aquesta forma, no serà necessari que els professionals realitzin diferents registres i diferents login, centralitzant aquesta gestió al portal AppSalut.

Els casos d’ús que es fan servir són els següents, en aquest ordre:

1. L’usuari es connecta al portal AppSalut; 2. L’usuari es connecta a l’aplicació backoffice.

Per fer aquesta integració s’ofereix dos sistemes alternatius, detallats a continuació.

9.1 Passive STS

Com a exemple d’aquesta integració considerem el war:PassiveSTSSampleApp.war. El codi font corresponen es pot trobar aquí:

http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/is/5.0.0/modules/samples/passive-sts/.

A partir del navegador, accedir a http://<hostname:port>:8080/PassiveSTSSampleApp (aplicació client). Aquesta petició serà interceptada per un filtre que farà un redirect al servei Passive STS del servidor d’identitats. El servei demana les credencials de l’usuari, o bé controla si ja existeix una sessió autenticada activa. Quan s’hagi validat que existeix una sessió activa o bé el client s’hagi autenticat correctament, el servei construirà la resposta tenint en compte una sèrie de claims prèviament configurats. Llavors, el Passive STS redirigeix el navegador al client (Relay Party). Finalment, al navegador es mostrarà la resposta rebuda de l’IS.

L’aplicació es configura amb 3 paràmetres:

idpUrl: https://appsalut.gencat.cat/passivests(endpoint del servei Passive STS)

replyUrl: http://<hostname:port>/PassiveSTSSampleApp/ (aplicació client) realm: PassiveSTSSampleApp (és el realm que es configura al servei Passive

STS). action: wsignin1.0

La URL de la petició al Passive STS és d’aquesta forma:

<idpUrl>?wa=<action>&reply=<replyUrl>&wtrealm=<realm>&requestParams=<....>

La resposta es podrà avaluar mitjançant el paràmetre de la request “wresult”.

Per a cada aplicació s’haurà d’establir els claims que es faran servir (dins dels disponibles), l’URL del servei, l’URL de l’aplicació de retorn i el nom del realm per a la autenticació delegada.

20

9.2 Agent SSO

Com a exemple d’aquesta integració considerem el war:travelocity.com.war. El codi font de l’aplicació està disponible aquí:

http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/is/5.0.0/modules/samples/sso/

El punt central d’aquesta aplicació és l’ús de la llibreriaorg.wso2.carbon.identity.sso.agent-1.X.X.jar que proporciona les eines per comunicar-se amb l’IS fent que l’aplicació es comporti com a un service provider. El codi de la aplicació ens mostra com interactuar amb aquest agent.

Per als paràmetres de configuració del fitxer travelocity.properties, es pot fer referència al guió publicat a aquesta pàgina:

https://docs.wso2.com/display/IS500/Configuring+Single+Sign-On+with+SAML+2.0

Recordem que s’haurà de configurar el keystore/truststore que s’inclou al war adequadament, amb els certificats correctes i l’endpoint del servei de sso del IS és:

https://appsalut.gencat.cat/samlsso

9.3 Vinculació del professional – Usuari al Backoffice

En el cas que una app requereixi d’una personalització dels paràmetres i aquesta es realitzi des del b ackoffice, per poder vincular la personalització amb un usuari, es proposa el següent mètode.

Un cop el professional hagi accedit al backoffice de l’app i hagi realitzat les personalitzacions que l’app requereixi, li preguntarà el número de telèfon o correu electrònic a l’usuari a qui li ha recomanat l’app.

Aquest número de telèfon o correu electrònic, servirà per enviar a l’usuari un codi de l’app propi relacionat amb la personalització.

Un cop l’usuari es descarregui l’app i accepti el disclaimer legal propi del desenvolupador, haurà d’introduir el codi que se li ha enviat des del backoffice de l’app amb la seva personalització, de tal manera que quan aquest comenci a fer servir l’app ja li apareixeran els paràmetres que ha personalitzat el seu professional.

10 Identificació de variables

Quan un desenvolupador està omplint el formulari d’alta d’una app, ha d’indicar quines variables enviarà a la PSD, omplint el document d’Excel Plantilla de notificació de variables mHealth.

21

La informació que es demana en aquesta plantilla permetrà estandarditzar les variables en base a vocabularis controlats internacionals, de manera que es podran compartir sense que es perdi el seu significat.

La plantilla consta de dues pestanyes:

Una de variables amb els camps:

Codi Sistema de codificació

Descripció Descripció

2 Tipus valor

Valor mínim

Valor màxim

Unitat de mesura

Comentaris addicionals

La definició dels quals es presenta a continuació:

Codi: Identificador únic de la variable. És un camp obligatori.

Sistema de codificació: Vocabulari controlat que s’utilitza per representar la variable i al qual

pertany el codi. Per exemple pot ser: SNOMED CT, CIM-9-MC, LOINC, ATC, etc. En cas que no

s’utilitzi cap vocabulari estàndard, caldrà indicar el valor “Propi”, per tal de notificar que la

variable s’identifica amb una codificació interna. És un camp obligatori.

Descripció: Literal que descriu la variable. No es tracta d’incloure una definició exhaustiva de

la variable. És un camp obligatori.

Descripció 2: Sinònims que té la variable. Si n’hi ha més d’un es poden afegir com a camps

darrera d’aquest.

Tipus valor: Tipus de la variable (és un camp obligatori) i que pot ser:

o Data.

o Enter.

o Decimal.

o Text.

o Booleà: true o false en funció de si la variable és Sí o No respectivament.

o Llistat simple: Variable que pot tenir com a valors un llistat d’altres variables (valors),

de les quals només se’n pot seleccionar una en el moment de registre.

o Llistat Múltiple: Variable que pot tenir com a valors un llistat d’altres variables

(valors), de les quals se’n pot escollir més d’una en el moment de registre.

o Valor: Quan es tracta d’una variable, que actua com a valor d’una altra i per a la qual

no aplica cap dels tipus anteriors.

Valor mínim: Valor mínim que pot prendre la variable, en cas que sigui numèrica (enter o

decimal) o data.

Valor màxim: Valor màxim que pot prendre la variable, en cas que sigui numèrica (enter o

decimal) o data.

22

Unitat de mesura: Unitats en les quals s’expressa el valor de la variable.

Comentaris addicionals: Informació que es consideri rellevant per a la correcta comprensió

de la variable (es pot incloure una definició o consideracions a tenir en compte).

A continuació es presenten dos exemples de notificació de les variables “asma” i “pes”:

Codi Sistema de codificació

Descripció Descripció 2 Tipus valor Valor mínim Valor màxim

Unitat de mesura

Comentaris addicionals

195967001 SNOMED CT asma Llistat simple

PES Propi Pes Pes corporal

Decimal 0 500 Kg

El document d’Excel també conté una pestanya anomenada “Valors”, que només s’haurà d’omplir per a les variables de la primera pestanya que com a Tipus valor tinguin “Llistat simple” o “Llistat múltiple”:

Variable Valor Codi

variable Codi valor

Sistema de codificació

Descripció Descripció

2 Tipus valor

Valor mínim

Valor màxim

Unitat de mesura

Comentaris addicionals

La definició d’aquests camps es presenta a continuació:

Codi variable: Identificador únic de la variable. És un camp obligatori.

Codi valor: Identificador únic del valor. És un camp obligatori.

Sistema de codificació: Vocabulari controlat que s’utilitza per representar el valor i al qual

pertany el codi. Per exemple pot ser: SNOMED CT, CIM-9-MC, LOINC, ATC, etc. En cas que no

s’utilitzi cap vocabulari estàndard, caldrà indicar el valor “Propi”, per tal de notificar que el

valor s’identifica amb una codificació interna. És un camp obligatori.

Descripció: Literal que descriu el valor.

Descripció 2: Sinònims que té el valor. Si n’hi ha més d’un es poden afegir com a camps

darrera d’aquest.

Tipus valor: Tipus del valor (és un camp obligatori) i que pot ser:

o Data.

o Enter.

o Decimal.

o Text.

o Booleà: true o false en funció de si la variable és Sí o No respectivament.

o Valor: Quan es tracta d’un valor i per a la qual no aplica cap dels tipus anteriors.

23

Valor mínim: Valor mínim que pot prendre la variable, en cas que sigui numèrica (enter o

decimal) o data.

Valor màxim: Valor màxim que pot prendre la variable, en cas que sigui numèrica (enter o

decimal) o data.

Unitat de mesura: Unitats en les quals s’expressa el valor de la variable.

Comentaris addicionals: Informació que es consideri rellevant per a la correcta comprensió

del valor (es pot incloure una definició o consideracions a tenir en compte).

Reprenent l’exemple de la variable “asma”, es podria considerar que aquesta té com a valor certs qualificadors que permeten conèixer l’estat de la simptomatologia. En aquest cas, la notificació de variables es podria realitzar de la manera següent: Variable Valor

Codi variable

Codi valor Sistema de codificació

Descripció Descripció 2

Tipo valor

Valor mínim

Valor máxim

Unitat de

mesura

Comentaris adicionals

195967001 162467007 SNOMED CT asimptomàtic

Valor

195967001 162469005 SNOMED CT

símptoma moderat

Valor

195967001 162470006 SNOMED CT

símptoma greu

Valor

195967001 162471005 SNOMED CT

símptoma molt greu

Valor