Embed Size (px)
Citation preview
Manual del Desarrollador
20170607_Versión 1.9
1
Contenido Contenido .................................................................................................................................................1
1 Introducción .....................................................................................................................................3
2 Tipología de App’s incluidas en el Portal AppSalut ..........................................................................4
2.1 App’s que no registran ni generan datos .................................................................................4
2.2 App que genera datos pero no requiere de ninguna personalización por parte de un profesional ...........................................................................................................................................4
2.3 App que genera datos y requiere una personalización por parte de un profesional mediante un backoffice propio de la aplicación ...................................................................................................4
3 Alta como desarrollador de app’s en el portal AppSalut .................................................................5
4 Alta de app’s en el portal AppSalut ..................................................................................................5
4.1 Formulario de alta de una APP. ................................................................................................6
4.2 Descripción del proceso de alta. ..............................................................................................7
5 Modificación de una APP .............................................................................................................. 10
6 Baja de una APP ............................................................................................................................ 10
7 Nueva versión de una app ya publicada ....................................................................................... 11
8 Funcionamiento del SDK ............................................................................................................... 11
8.1 Requerimientos ..................................................................................................................... 12
8.1.1 Android .......................................................................................................................... 12
8.1.2 iOS ................................................................................................................................. 12
8.1.3 Frameworks requeridos ................................................................................................ 13
8.2 Importar el SDK ..................................................................................................................... 13
8.2.1 Android .......................................................................................................................... 13
8.2.2 iOS ................................................................................................................................. 13
8.3 Uso de los SDK con Android .................................................................................................. 13
8.3.1 Inicialización .................................................................................................................. 13
8.3.2 Inicio de sesión en PSD .................................................................................................. 14
8.3.3 Estandarización de datos .............................................................................................. 15
8.3.4 Enviar datos en la PSD ................................................................................................... 15
8.4 Uso de los SDK con iOS .......................................................................................................... 16
8.4.1 Inicialización .................................................................................................................. 16
8.4.2 Inicio de sesión en PSD .................................................................................................. 16
8.4.3 Estandarización de datos .............................................................................................. 17
8.4.4 Enviar datos a la PSD ..................................................................................................... 17
8.5 API Errores ............................................................................................................................. 18
8.5.1 Iniciar sesión .................................................................................................................. 18
8.5.2 Enviar datos en la PSD ................................................................................................... 18
2
8.5.3 Logout ............................................................................................................................ 18
9 Integración del backoffice de la app ............................................................................................. 18
9.1 Passive STS ............................................................................................................................ 19
9.2 Agente SSO ............................................................................................................................ 19
9.3 Vinculación del profesional – Usuario en el Backoffice ........................................................ 20
10 Identificación de variables ........................................................................................................ 20
3
1 Introducción
El portal AppSalut es un aparador de aplicaciones móviles del ámbito sanitario y de bienestar social. Las app’s publicadas en este aparador, habrán superado un proceso de acreditación que consiste en un seguido de criterios agrupados en 4 bloques: contenidos y funcionalidades, seguridad, usabilidad y tecnológicos.
Circuito de alta, acreditación y publicación de una APP en el portal
Las app’s incluidas en el portal AppSalut podrán ser recomendadas por parte dos profesionales de la salud y del bienestar social a sus usuarios. A demás, en el caso que la app lo permite i el usuario acepte, los datos generados por los usuarios que hagan servir las app’s recomendadas por sus profesionales, serán almacenadas en la Plataforma de Salud Digital (PSD).
La Plataforma de Salud Digital (PSD) es un repositorio donde se recogen los datos de las aplicaciones móviles recomendadas por los profesionales y usadas por los usuarios. Los profesionales podrán consultar estos datos en cualquier momento.
Estos datos podrán ser usados por parte de profesionales para hacer un seguimiento del estado del usuario y personalizar los servicios prestados.
4
Las aplicaciones móviles en el portal AppSalut se integrarán con la PSD porque se puedan almacenar los datos generados por los usuarios.
2 Tipología de App’s incluidas en el Portal AppSalut
En el portal AppSalut coexistirán tres tipologías diferentes de aplicaciones:
App’s que no registran ni generan datos cuando interactúan con el usuario
App que genera datos debido a la interacción con el usuario, pero que no necesita ser parametrizada ni personalizada por un profesional mediante un backoffice propio de la aplicación.
App que genera datos debido a la interacción con el usuario, y que necesita ser parametrizada y/o personalizada por un profesional mediante un backoffice propio de la aplicación.
2.1 App’s que no registran ni generan datos
Este tipo de apps son aquellas que no generan ni registran datos cuando interactúan con los usuarios. Por tanto, estas aplicaciones tampoco pueden enviar ningún tipo de información a los profesionales o entidades proveedoras del sistema sanitario y/o de bienestar social público de Cataluña.
Como ejemplo de esta tipología de app’s pueden ser aquellas que solo proporcionan información o recomendaciones en el usuario, basadas en guías clínicas vigentes.
Esta tipología de app’s, no requiere la instalación de ningún SDK (software development kit), ya que no hay intercambio de datos.
2.2 App que genera datos pero no requiere de ninguna personalización por parte de un profesional
Las app’s, que debido a la interacción con el usuario generan datos y estas pueden ser de interés por el profesional, tendrán que descargar e instalar un SDK (software development kit), mediante el cual, podrá enviar datos a la Plataforma de Salud Digital (PSD), siempre y cuando:
1. El usuario acepte un disclaimer legal y 2. El usuario se identifique mediante un código personal
Con esta condición los datos podrán ser visualizados por los profesionales.
2.3 App que genera datos y requiere una personalización por parte de un profesional mediante un backoffice propio de la aplicación
Son aquellas app’s que, al igual que el caso anterior, generan datos con la interacción con el usuario, pero que además cuentan con un backoffice propio el cual permite a los profesionales del
5
sistema sanitario y de bienestar social público de Cataluña personalizar la app en función de las particularidades de cada usuario. Tendrán que hacer la aceptación de dos disclaimers con dos SDK´s diferentes. Uno por la PSD y otro por la propia aplicación de backoffice.
3 Alta como desarrollador de app’s en el portal AppSalut
Cualquier desarrollador que desee dar de alta su app en el Portal AppSalut, previamente habrá que registrarse como usuario desarrollador. Para registrarse como desarrollador tendrá que realizar los siguientes pasos:
1. Acceder en el espacio del desarrollador del portal AppSalut, para consultar las bases y condiciones para la publicación de app’s: https://appsalut.gencat.cat/ca/web/marketplace/espai-del-desenvolupador .
2. Iniciar el proceso de registro de nuevo usuario desarrollador a través del enlace habilitado en el espacio del desarrollador.
3. Complementar el formulario de registro, aceptar las condiciones de uso del portal AppSalut y enviarlo. Una vez enviado el formulario de petición de registro, la Oficina mHealth.cat de la Fundación TicSalut validará los datos y, en caso de ser todo correcto, se procederá a hacer el registro y dar de alta al nuevo usuario.
4. Una vez generado el nuevo usuario, se enviará un correo electrónico con la contraseña para acceder al espacio privado del desarrollador del portal AppSalut.
En el caso que el formulario no haya estado rellenado correctamente, el desarrollador recibirá un correo electrónico con los motivos/ información requerida para completar el proceso de registro.
4 Alta de app’s en el portal AppSalut
Los usuarios desarrolladores, una vez logados en el portal AppSalut, pueden dar de alta su app para tal de iniciar el proceso de acreditación.
Para tal de dar de alta la app en el portal e iniciar el proceso de acreditación se han de seguir las siguientes etapas, que son explicadas seguidamente con más detalle:
6
4.1 Formulario de alta de una APP.
Toda la información pertinente sobre la app estará recogida en el formulario de alta; este formulario será la base sobre la cual se realizará el proceso de validación de la app para aceptarla como a candidata a ser acreditada. El formulario consta de diferentes grupos de información solicitada:
1. Identificación del nombre de la app y propietarios 2. Imágenes e iconos que presentaran la app en el AppSalut una vez publicada
7
3. Datos tecnológicos de la app: Sistemas Operativos, identificador en el App Store, etc. 4. Datos funcionales: objetivos, descripción funcional, idioma(s) y a quien volumen de
público se dirige
5. Descripción técnica de la app; dentro de este bloque se describe si la app recoge o no
datos y con qué frecuencia, si da recomendaciones a los usuarios, en que guías de salud se basa la app, etc.
6. Proceso de cualidad: se pide incluir una serie de información sobre el proceso de cualidad que ha pasado la app: certificaciones, pruebas realizadas por terceros, etc.
7. Para tal de clasificar la app una vez publicada se pide al desarrollador que identifique debajo de que categorías sociales y de salud es incluye la app: es para cuidadores, familias, etc., que tipo de problemas trata, a qué tipo de colectivo se dirige....Esta información se tiene que seleccionar de entre las categorías disponibles que presenta el propio formulario.
8. Por último, pero importantísimo para las app’s que envían datos, se pide al desarrollador que identifique con que variables trabaja la app.
4.2 Descripción del proceso de alta.
El proceso para dar de alta una nueva app es el siguiente:
8
1. Acceder en el apartado “Nueva app” del menú izquierda de la parte privada del desarrollador del Portal AppSalut.
2. Generar En este paso, será necesario que el sistema genere una API_KEY única para la aplicación a través del formulario de alta de una nueva app; solo introduciendo el nombre de la app y pulsando el botón del final del formulario para generar la llave:
Obtendremos esta llave en el apartado de seguridad del mismo formulario:
3. Descargar el SDK de desarrollador proporcionado en el espacio del desarrollador del portal.
4. Incluir la API_KEY en el SDK.
5. Rellenar el formulario de alta de una nueva app. En este paso, será necesario que el sistema genere una API_KEY única para la aplicación que será necesario incluirla a través del SDK de desarrollador facilitado en el espacio del desarrollador del portal AppSalut.
6. API_KEY, es necesario marcar la opción “Guardar y generar llave de la app” del formulario de alta de la app y a continuación se podrá consultar en el apartado Seguridad del mismo formulario.
Una vez introducida esta API_KEY en la app, será necesario subir la nueva versión de la app a los App Stores oficiales (Google Play, iTunes, etc.) y terminar de completar el formulario de alta de una nueva app.
7. Una vez rellenado el formulario de alta, el desarrollador puede pedir iniciar el proceso de acreditación de la app.
9
En el momento que el desarrollador inicie el proceso de acreditación, la Oficina mHealth.cat procederá a la revisión de la solicitud de alta. En caso de que todos los datos sean correctos, se informará al desarrollador vía correo electrónico del nivel (ver aquí información sobre la clasificación por niveles de una app) en que ha estado clasificada su app y el coste de acreditación asociado.
En este momento el desarrollador ya puede proceder a realizar el pago del proceso de acreditación de la app.
8. El pago se realizará online dentro del espacio privado del desarrollador con una pasarela de pago del banco.
9. Una vez realizado el pago de la acreditación de la app, la Oficina mHealth.cat procederá a completar el proceso de acreditación.
10. Finalizado el proceso de acreditación, la Oficina mHealth.cat enviará vía correo electrónico el resultado de la acreditación de la app al desarrollador. En caso de que la app supere de forma satisfactoria el proceso de acreditación, la app quedará publicada automáticamente en el Portal AppSalut.
El desarrollador de la app que no supere de forma satisfactoria el proceso de acreditación recibirá un informe de no conformidad. En este informe se detallaran los criterios por los cuales la resolución de la acreditación no ha estado favorable.
10
5 Modificación de una APP
Un desarrollador solo puede modificar la información proporcionada sobre una app a publicar en el portal AppSalut:
1. mientras no haya solicitado iniciar el proceso de acreditación (estado de la app: borrador) 2. o bien si la Oficina mHealth.cat le rechaza la app en revisar su solicitud (estado de la app:
rechazada). En este caso puede enmendar los datos del formulario de alta de app y volver a solicitar el proceso de revisión.
Para modificar los datos de la app, el desarrollador (una vez logado) puede acceder a través del botón “mis apps” del menú izquierdo y clicar en el icono de formulario de la app:
6 Baja de una APP
Un desarrollador puede dar de baja una app mientras no haya solicitado el proceso de revisión. Para dar de baja la app, el desarrollador (una vez logado) puede acceder a través del botón “mis apps” del menú izquierdo y clicar en el icono de eliminación de la app:
Si la app ya ha sido publicada, el desarrollador puede solicitar la baja; esta será ejecutada por la Oficina mHealth.cat.
El borrado de una app siempre es lógico, la app queda marcada en estado “borrada”.
11
7 Nueva versión de una app ya publicada
El desarrollador que disponga de apps publicadas en el portal AppSalut, en cualquier momento tendrá disponible un listado con todas sus apps, donde podrá consultar los datos referentes a sus aplicaciones, realizar una petición de baja o pedir una reacreditación de la app para nuevas versiones.
8 Funcionamiento del SDK
El SDK permite al desarrollador de una app que envíe datos y que se quiere incluir en el portal AppSalut, usar los servicios de PSD desde código nativo Android / iOS.
Básicamente el SDK implementa las funcionalidades:
1. Gestiona el disclaimer legal del envío de datos 2. Gestiona el inicio de sesión del usuario con su contraseña y el logout de la conexión con la
PSD 3. Realiza el envío de datos en la PSD
A continuación detallamos brevemente algunos aspectos de cada funcionalidad mencionada:
Gestión del disclaimer legal.
Tal y como se ha comentado antes, para tal de enviar los datos generados por la app en la PSD, el usuario obligatoriamente tiene que aceptar un disclaimer legal. Este disclaimer legal será necesario que se muestre en el inicio de la app, la primera vez que el usuario se instala la app. En el caso que la app ya muestre al usuario un disclaimer legal propio, el disclaimer legal del SDK se mostrará seguidamente.
Gestión del inicio y final de sesión.
Para el envío de datos en la PSD se tiene que establecer sesión con la PSD. Esto solo será posible si el usuario ha aceptado previamente el disclaimer legal del SDK.
El login se realiza con el CIP del paciente y una contraseña; esta contraseña la recibirá el usuario vía SMS en el momento que el médico le recomiende una app. En ningún caso el CIP del paciente se guarda en la PSD, sino que en el login se transforma en un id de paciente interno del sistema.
En caso que el usuario desee no seguir compartiendo datos, la app tiene que ofrecer la opción de hacer logout de la sesión. Esta acción invalidará la sesión del usuario en el dispositivo y a partir de este momento los datos generados por la app no se compartirán en la PSD. En el caso que el usuario desee volver a enviar datos, la app tendrá que ofrecer la
12
posibilidad de volver a enviar datos mostrando nuevamente el disclaimer legal. El proceso volvería en el punto 2 de este proceso: Inicio de sesión del usuario con su contraseña.
Envío de datos en la PSD
Para poder enviar datos en la PSD una app:
o Tiene que estar acreditada y publicada en el portal o La app tiene que haber estado recomendada por un profesional a un paciente. o El paciente tiene que aceptar el disclaimer legal.
El envío de datos se realiza a partir de variables oficiales que están dadas de altas al subconjunto de variables del portal AppSalut y que el desarrollador tendrá identificado en dar de alta la app. Una variable que no esté categorizada dentro del portal será ignorada por los visores de datos, hasta que esta esté dada de alta en el subconjunto. Para dar de alta una nueva variable no incluida en el subconjunto existente, el desarrollador propondrá, a través del formulario de alta de la app, la inclusión de la nueva variable en la Oficina mHealth.cat de la Fundación TicSalut.
Los datos que la app envía en la PSD (una o varias) se tiene que transmitir a través de un mensaje que tiene siempre la estructura siguiente:
VARIABLE – VALOR
Donde la variable es el código de la variable al subconjunto de variables (SNOMED CT, CIM-9, etc.) y VALOR es su valor. Por ejemplo: 27113001 60, donde 27113001 se corresponde con el código de la variable peso y 60 es su valor. El SDK también necesita poder enviar la fecha y hora en que se ha registrado el valor concreto de la variable.
8.1 Requerimientos
8.1.1 Android
Nombre Versión
Android API >= 15
Android Studio >= 1.2.X
8.1.2 iOS
Nombre Versión
Sistema Operativo >= 7
13
8.1.3 Frameworks requeridos
Nombre Versión
AssertsLibrary.framework *
MobileCoreServices.framework *
SystemConfiguration.framework *
8.2 Importar el SDK
8.2.1 Android
Pasos a seguir desde Android Studio:
1. Descargar el SDK desde el espacio del desarrollador del portal AppSalut. 2. Desde el menú: File -> New -> New Module -> Import .JAR/.AAR 3. Seleccionar el archivo y asignar un nombre al módulo (Ej.: sdk-psd) 4. Desde el archivo gradle de la app en ‘dependencies' poner:
compile project(‘:sdk-psd’)
Atención a los dos puntos: delante del nombre asignado
4. Sincronizar el proyecto
8.2.2 iOS
Descargar el SDK desde el espacio del desarrollador del portal AppSalut.
Arrastrar el SDK al proyecto
Vincular al proyecto los frameworks:
o AssetsLibrary.framework o MobileCoreServices.framework o SystemConfiguration.framework
8.3 Uso de los SDK con Android
8.3.1 Inicialización
En la Activity principal donde la aplicación empieza la ejecución, se tiene que añadir la siguiente sentencia para que esta tenga acceso a poder interactuar con PSD.
@Override Protected void onCreate(BundlesavedInstanceState) {
super.onCreate(savedInstanceState);
14
setContentView(R.layout.activity_main); PSD.initialize(getApplicationContext(), "API_KEY"); // …
}
* Importante: L’API_KEY es única para cada app y la generará el portal AppSalut en el momento que se da de alta una app en estado Borrador antes del proceso de acreditación, o cuando se hace una nueva re-acreditación de una nueva versión de la misma. Una vez introducida esta API_KEY en la app, será necesario subir la nueva versión de la app a los App Stores oficiales (Google Play, iTunes, etc.) y terminar de completar el formulario de alta de una nueva app / versión. Para más información ver el punto 4: Alta de app’s en el portal AppSalut de este documento.
8.3.2 Inicio de sesión en PSD
La clase PSDService provee de los métodos necesarios para tener el control de la sesión de usuario. Devuelve true o false según si el usuario ha iniciado sesión con PSD en la aplicación.
PSDService.isLogged() : Boolean
Para que el usuario inicie sesión se pedirá aceptar un disclaimer legal. En caso de aceptar este disclaimer, se requiere que el usuario informe de su contraseña para poder autorizar el envío de datos en la PSD. El servicio de iniciar sesión da el control de errores mediante el bloque success o error.
PSDService.login(Activityactivity, newPSDCallback {
@Override
publicvoidsuccess() {
// …
}
@Override
publicvoid error(PSDException e) {
//…
}
});
De esta forma, al usar el Activity como un parámetro de login, se puede acceder en el Activity donde lanza un dialogo con el disclaimer. En caso que el usuario lo acepte, se mostrará sobre la misma vista in dialogo con el formulario, porque el usuario pueda iniciar sesión. Este dialogo es gestionado automáticamente por la PSD y no requiere de configuración previa. También es necesario realizar un control del logout de un usuario en PSD, en el caso que este decida no seguir compartiendo los datos generados por la app. Para borrar la sesión del usuario, es necesario llamar al método:
15
PSDService.logout(newPSDCallback {
@Override
publicvoidsuccess() {
// …
}
@Override
publicvoid error(PSDException e) {
//…
}
});
Este servicio da el control de errores mediante el bloque success o error.
8.3.3 Estandarización de datos
PSDData contendrá la agrupación de los datos que se enviarán posteriormente.
PSDDatapsdData = newPSDData();
psdData.add(String variableCodi, String variableValue, Date
dataDeRegistre);
Si algún parámetro es nulo o es un string vacío, lanzará una excepción.
8.3.4 Enviar datos en la PSD
PSDService.sendVariables(PSDData data, newPSDCallback() { @Override publicvoidsuccess() { // ...
} @Override publicvoid error(PSDException e) { // ... }
});
* Importante: Estos métodos solo se pueden llamar si el usuario ha iniciado sesión introduciendo su
contraseña, en caso contrario dará error.
16
8.4 Uso de los SDK con iOS
8.4.1 Inicialización
En el método application:didFinishLaunchingWithOptions: del fichero App Delegate de nuestra aplicación es necesario introducir la API_KEY.
[PSDInitializersetApiKey:@”API_KEY”];
* Importante: * Importante: L’API_KEY es única para cada app y la generará el portal AppSalut en el momento que se da de alta una app en estado Borrador antes del proceso de acreditación.
8.4.2 Inicio de sesión en PSD
La clase PSD provee de los métodos necesarios para tener el control de la sesión de usuario.
[PSD isLogged];
Devuelve TRUE o FALSE según si el usuario ha iniciado sesión con PSD en la aplicación.
Para que el usuario inicie sesión se pedirá aceptar un disclaimer legal. En caso de aceptar este
disclaimer, se requiere que el usuario informe de su contraseña para poder autorizar el envío de
datos en la PSD.
[PSD loginWithSuccess:^{
//. . .
} failure:^(NSError *error) {
// . . .
}];
Esta funcionalidad se gestiona automáticamente por la PSD y no requiere de configuración previa.
También es necesario realizar un control del logout de un usuario en PSD, en el caso que este decida
no seguir compartiendo los datos generados por la app. Para borrar la sesión del usuario, es
necesario llamar al método:
[PSD logoutWithSuccess:^{
//. . .
} failure:^(NSError *error) {
// . . .
17
}];
8.4.3 Estandarización de datos
Todos los datos del portal AppSalut iOS SDK utilizan la clase PSDObject. PSDObject contiene dos propiedades obligatorias, el nombre de la variable que guardamos y un valor concreto.
[PSDObjectobjectWithVariable:@”variable”
andValue:@”value”];
Para trabajar con un conjunto de datos se usa la clase PSDData, que agrupa un conjunto de PSDObject.
PSDData *data = [PSDDataalloc] init];
[data addObject: [PSDObjectobjectWithVariable:@”variable”
andValue:@”value” andDate:NSDate]];
8.4.4 Enviar datos a la PSD
El SDK permite enviar un dato o un conjunto de datos.
Enviar un dato:
PSDObject *object = [PSDObjectobjectWithVariable:@”variable”
andValue:@”value”];
[PSD saveObject:object
success:^{
//...
} failure:^(NSError *error) {
//...
}];
Enviar más de un dato:
PSDData *data = [PSDDataalloc] init];
[data addObject:[PSDObjectobjectWithVariable:@”variable”
andValue:@”value”]];
18
[PSD saveObjects:data
success:^{
//...
} failure:^(NSError *error) {
//...
//...
}];
*Importante: Estos métodos solo se pueden llamar si el usuario ha iniciado sesión, en caso contrario dará error.
8.5 API Errores
8.5.1 Iniciar sesión
En el caso que, a la hora de iniciar sesión, la contraseña no sea válida devolverá una excepción, que la app tendrá que controlar y tratar.
8.5.2 Enviar datos en la PSD
Para poder enviar datos en la PSD, es necesario que se cumplan 3 pre-requisitos:
La app tiene que estar acreditada
Que la aplicación sea recomendada al usuario que envía los datos. En caso que el usuario no tenga la aplicación recomendada, no podrá enviar los datos.
Que el usuario acepte el disclaimer legal y haya introducido una contraseña correcta.
8.5.3 Logout
En caso que el dispositivo no tenga conectividad con los servidores de PSD, el método de logout lanzará una excepción que será necesario controlar por la app y mostrar un mensaje de error al usuario, ya que se mantendrá la sesión del usuario en la PSD.
9 Integración del backoffice de la app
En caso que la app que se quiera publicar en el Portal tenga un backoffice de gestión porque un profesional pueda configurar o personalizar la app a un usuario, está prevista una integración Single Sign On entre el portal AppSalut y el backoffice de gestión de la app para el perfil profesional. De esta forma, no será necesario que los profesionales realicen diferentes registros y diferentes login, centralizando esta gestión en el portal AppSalut.
Los casos de uso que se usan son los siguientes, en este orden:
19
1. El usuario se conecta en el portal AppSalut; 2. El usuario se conecta en la aplicación backoffice.
Para hacer esta integración se ofrecen dos sistemas alterativos, detallados a continuación.
9.1 Passive STS
Como ejemplo de esta integración consideramos el war:PassiveSTSSampleApp.war. El código fuente correspondiente se puede encontrar aquí:
http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/is/5.0.0/modules/samples/passive-sts/.
A partir del navegador, acceder a http://<hostname:port>:8080/PassiveSTSSampleApp (aplicación cliente). Esta petición será interceptada por un filtro que hará un redirect al servicio Passive STS del servidor de identidades. El servicio pide las credenciales del usuario, o bien controla si ya existe una sesión autenticada activa. Cuando se haya validado que existe una sesión activa o bien el cliente se haya autenticado correctamente, el servicio construirá la respuesta teniendo en cuenta una serie de claims previamente configurados. Entonces, el Passive STS redirige el navegador al cliente (Relay Party). Finalmente, en el navegador se mostrará la respuesta recibida de la IS.
La aplicación se configura con 3 parámetros:
idpUrl: https://appsalut.gencat.cat/passivests(endpoint del servicio Passive STS)
replyUrl: http://<hostname:port>/PassiveSTSSampleApp/ (aplicación cliente) realm: PassiveSTSSampleApp (és el realm que es configura al servicio
Passive STS). action: wsignin1.0
La URL de la petición al Passive STS es de esta forma:
<idpUrl>?wa=<action>&reply=<replyUrl>&wtrealm=<realm>&requestParams=<....>
La respuesta se podrá evaluar mediante el parámetro de la request “wresult”.
Para cada aplicación se tendrá que establecer los claims que se usarán (dentro de los disponibles), la URL del servicio, la URL de la aplicación de retorno y el nombre del realm para la autenticación delegada.
9.2 Agente SSO
Como a ejemplo de esta integración consideramos el war:travelocity.com.war. El código fuente de la aplicación está disponible aquí:
http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/is/5.0.0/modules/samples/sso/
El punto central de esta aplicación es el uso de la librería org.wso2.carbon.identity.sso.agent-1.X.X.jar que proporciona las herramientas para comunicarse con el IS haciendo que la aplicación
20
se comporte como a un service provider. El código de la aplicación nos muestra como interactuar con este agente.
Para los parámetros de configuración del fichero travelocity.properties, se puede hacer referencia al guion publicado en esta página:
https://docs.wso2.com/display/IS500/Configuring+Single+Sign-On+with+SAML+2.0
Recordamos que se tendrá que configurar el keystore/truststore que se incluye en el war adecuadamente, con los certificados correctos y el endpoint del servicio de sso del IS es:
https://appsalut.gencat.cat/samlsso
9.3 Vinculación del profesional – Usuario en el Backoffice
En el caso que una app requiera de una personalización de los parámetros y esta se realice desde el backoffice, para poder vincular la personalización con un usuario, es propone el siguiente método.
Una vez el profesional haya accedido al backoffice de la app y haya realizado las personalizaciones que la app requiera, le preguntará el número de teléfono o correo electrónico al usuario a quién le ha recomendado la app.
Este número de teléfono o correo electrónico, servirá para enviar al usuario un código de la app propio relacionado con la personalización.
Una vez el usuario se descargue la app y acepte el disclaimer legal propio del desarrollador, tendrá que introducir el código que se le ha enviado desde el backoffice de la app con su personalización, de tal forma que cuando este empiece a usar la app ya le aparecerán los parámetros que ha personalizado su profesional.
10 Identificación de variables
Cuando un desarrollador está rellenando el formulario de ala de una app, tiene que indicar que variables enviará a la PSD, rellenando el documento de Excel Plantilla de notificación de variables mHealth.
La información que se pide en esta plantilla permitirá estandarizar las variables en base a vocabularios controlados internacionales, de manera que se podrán compartir sin que se pierda su significado.
La plantilla consta de dos pestañas:
Una de variables con los campos:
Código Sistema de codificación
Descripción Descripción
2 Tipo valor
Valor mínimo
Valor máximo
Unidad de
Comentarios adicionales
21
medida
La definición de los cuales se presenta a continuación:
Código: Identificador único de la variable. Es un campo obligatorio.
Sistema de codificación: Vocabulario controlado que se usa para representar la variable y al
cual pertenece el código. Por ejemplo puede ser: SNOMED CT, CIM-9-MC, LOINC, ATC, etc. En
caso que no se use ningún vocabulario estándar, será necesario indicar el valor “Propio”,
para tal de notificar que la variable se identifica con una codificación interna. Es un campo
obligatorio.
Descripción: Literal que describe la variable. No se trata de incluir una definición exhaustiva
de la variable. Es un campo obligatorio.
Descripción 2: Sinónimos que tiene la variable. Si hay más de uno se pueden añadir como
campos detrás de este.
Tipo valor: Tipo de la variable (es un campo obligatorio) y que puede ser:
o Fecha.
o Entero.
o Decimal.
o Text.
o Booleano: true o false en función de si la variable es Sí o No respectivamente.
o Listado simple: Variable que puede tener como a valores un listado de otros
variables (valores), de las cuales solo se puede seleccionar una en el momento de
registro.
o Listado Múltiple: Variable que puede tener como a valores un listado de otros
variables (valores), de las cuales se puede escoger más de una en el momento de
registro.
o Valor: Cuando se trata de una variable, que actúa como a valor de una otra y para a
la cual no aplica ningún de los tipos anteriores.
Valor mínimo: Valor mínimo que puede prender la variable, en caso que sea numérica
(entero o decimal) o fecha.
Valor máximo: Valor máximo que puede prender la variable, en caso que sea numérica
(entero o decimal) o fecha.
Unidad de medida: Unidades en las cuales se expresa el valor de la variable.
22
Comentarios adicionales: Información que se considere relevante para la correcta
comprensión de la variable (se puede incluir una definición o consideraciones a tener en
cuenta).
A continuación se presentan dos ejemplos de notificación de las variables “asma” y “peso”:
Código Sistema de codificación
Descripción Descripción 2
Tipo valor Valor mínimo
Valor máximo
Unidad de medida
Comentarios adicionales
195967001 SNOMED CT asma Listado simple
PESO Propio Peso Peso corporal
Decimal 0 500 Kg
El documento de Excel también contiene una pestaña nombrada “Valores”, que solo se tendrá que rellenar para las variables de la primera pestaña que como a Tipo valor tengan “Listado simple” o “Listado múltiple”:
Variable Valor
Código variable
Código valor
Sistema de codificación
Descripción Descripción
2 Tipo valor
Valor mínimo
Valor máximo
Unidad de
medida
Comentarios adicionales
La definición de estos campos se presenta a continuación:
Código variable: Identificador único de la variable. Es un campo obligatorio.
Código valor: Identificador único del valor. Es un campo obligatorio.
Sistema de codificación: Vocabulario controlado que se usa para representar la variable y al
cual pertenece el código. Por ejemplo puede ser: SNOMED CT, CIM-9-MC, LOINC, ATC, etc. En
caso que no se use ningún vocabulario estándar, será necesario indicar el valor “Propio”,
para tal de notificar que la variable se identifica con una codificación interna. Es un campo
obligatorio.
Descripción: Literal que describe el valor.
Descripción 2: Sinónimos que tiene el valor. Si hay más de uno se pueden añadir como
campos detrás de este.
Tipo valor: Tipo de la variable (es un campo obligatorio) y que puede ser:
o Fecha.
o Entero.
o Decimal.
o Text.
o Booleano: true o false en función de si la variable es Sí o No respectivamente.
23
o Valor: Cuando se trata de un valor y para la cual no aplica ningún de los tipos
anteriores.
Valor mínimo: Valor mínimo que puede prender la variable, en caso que sea numérica
(entero o decimal) o fecha.
Valor máximo: Valor máximo que puede tomar la variable, en caso que sea numérica (entero
o decimal) o fecha.
Unidad de medida: Unidades en las cuales se expresa el valor de la variable.
Comentarios adicionales: Información que se considere relevante para la correcta
comprensión de la variable (se puede incluir una definición o consideraciones a tener en
cuenta).
Retomando el ejemplo de la variable “asma”, se podría considerar que esta tiene como valor ciertos calificadores que permiten conocer el estado de la sintomatología. En esto caso, la notificación de variables se podría realizar de la forma siguiente: Variable Valor
Código variable
Código valor
Sistema de codificación
Descripción Descripción 2
Tipo valor
Valor mínimo
Valor máximo
Unidad de
medida
Comentaris addicionals
195967001 162467007 SNOMED CT asintomático
Valor
195967001 162469005 SNOMED CT
síntoma moderado
Valor
195967001 162470006 SNOMED CT
síntoma grave
Valor
195967001 162471005 SNOMED CT
síntoma muy grave
Valor
