Procedimiento de alta
A continuación se detalla el procedimiento a seguir para solicitar el alta de un módulo en MACO.
| Paso | Descripción |
|---|---|
| Paso 1 | La OTI envía la plantilla de alta al proveedor implicado en el alta. Plantilla Alta Módulo X en MACO.doc |
| Paso 2 | El proveedor rellena el documento con la información necesaria y lo envía de nuevo a la OTI. Existen un conjunto de causas que se deben tener en cuenta y que son razón para que la OTI deniegue el documento enviado por el proveedor:
|
| Paso 3 | La OTI abre una incidencia en CGES adjunto el documento recibido en el paso 2. En caso de solicitud urgente en horario de guardia o ausencia de la JP de MACO, se envía un correo electrónico al responsable de MACO del proveedor con la JP de MACO en copia para su gestión urgente. |
| Paso 4 | MACO realiza las gestiones solicitadas y devuelve vía CGES el documento con la resolución, el código del módulo en el caso de la creación y el usuario y contraseña en caso de que se haya solicitado. |
| Paso 5 | La OTI envía el documento obtenido del paso 4 al proveedor y almacena el documento. |
Información del documento de alta
Título
Se debe indicar el nombre del módulo o sistema externo que se va a dar de alta. En el título se indica para que entorno es (Preproducción o Producción) y cuando se realice el alta del módulo se indicará el código de 3 cifras que lo identifica.
Definición del módulo
- Nombre del módulo
- Tipo del módulo: Puede ser Módulo o Sistema externo. La diferencia consiste en que un sistema externo no puede publicar servicios pero si puede consumirlos.
- Situación: Indica el estado del módulo que se quiere dar de alta, hay que indicar "Vigente".
- Distribuido: Se responde con un Sí o un No. Un módulo es distribuido cuando necesita que MACO le pase información indicando desde dónde se loga el usuario del módulo.
- Ámbito: Se debe informar solo en el caso de que el módulo o sistema externo sea distribuido e identifica el ámbito de actuación del sistema (Especializada/Primaria/Consejería/...).
- Días con la clave caducada hasta bloqueo definitivo: Salvo causa justificada el valor será 90 días. Si el módulo no tiene usuarios personales, únicamente tiene usuario de aplicación, el valor será 0 y la clave no se bloqueará.
- Días de validez de la contraseña: Salvo causa justificada el valor será 90 días. Si el módulo no tiene usuarios personales, únicamente tiene usuario de aplicación, el valor será 0 y la clave no caducará.
- Datos de profesionales: Las opciones de este campos son "SI" o "NO" en función de si la aplicación asocia o no agendas a los profesionales.
Perfiles
Se definen los diferentes perfiles de usuario que necesita la aplicación. El perfil asociado a un usuario en una aplicación se devolverá en la consulta de prevalidar a MACO. Si el módulo no tiene usuarios personales, se indica "Genérico".
Usuarios
En este apartado se indica si se solicita un usuario de aplicación genérico para el módulo. Si la aplicación va a tener usuarios personales, se indica un administrador delegado que se encargará de la gestión de los usuarios.
Servicios
Se indican dos tablas con el conjunto de servicios a los que puede acceder la aplicación y el conjunto de servicios que publica la aplicación. Cuando se trata de una modificación de los permisos de una aplicación, se utiliza un juego de colores en el documento que se detalla en la petición CGES o por correo. Si el servicio está en color negro significa que ya existía y se debe mantener. Si está en color rojo el permiso existía pero ahora se debe eliminar y si está en color verde, es un nuevo permiso que hay que añadir.
El código MACO de los servicios que ofrecen las aplicaciones se complementa con los dígitos de su módulo, por ejemplo:
- Si ECH publica el servicio de Alta Paciente, su código será AL_PA_338, en el caso de ECC será AL_PA_339.
Módulos virtuales
Existe la posibilidad de crear un módulo virtual, estos módulos no representan a una aplicación en cuestión y se utiliza para agrupar permisos. El nombre de estos módulos especiales siempre comienzan por "MV". Su utilidad radica en permitir el acceso a un determinado servicio independientemente de quien lo publique. Por ejemplo, el servicio de Recepción de Consulta de Informe lo publican muchos sistemas (ECC, ECH, MPA, PDI, departamenteles...) por lo que si un sistema quiere consultar cualquier informe, debería tener permiso para acceder a los consulta informe de cada uno, es decir, debería contener los permisos CONS_INF_338, CONS_INF_339, CONS_INF_337,... Esto supone un problema de gestión y de tamaño del ticket por lo que en su lugar, se crea un Módulo Virtual que tenga el permiso genérico de Consulta informe y cada vez que un sistema quiera acceder a cualquier consulta de informe, se le asociará el permiso del MV. Los permisos de los servicios de los MV no contienen los dígitos del sistema en MACO.