Historial de página
...
Área Funcional
[ACT-PRE-FUNC-1] Adecuar la estructura física
De las primeras actividades que los responsables del centro deberán llevar a cabo en cuento comienza la fase de Preimplantación están todas aquellas relacionadas con la parametrización y configuración de los Módulos Corporativos relacionados. De estos hacemos especial hincapié en Estructura y los procesos de autentificación.
En relación a la estructura física es importante reflejar, tal cual, la realidad física y palpable de las localizaciones y divisiones del centro: edificios, plantas, controles de enfermería, habituaciones, etc.
Dado que Estructura incluye algunas limitaciones con respecto a las opciones de modificación de elementos ya incluidos y de análisis de la información contenida, para la definición de la estructura se recomienda la utilización de una plantilla que nos permitirá plasmar de forma jerárquica dicha estructura antes de su mecanización en el Módulo Corporativo.
Esta plantilla permite analizar la coherencia y estandarización de los datos incluidos de forma fluida para detectar correcciones necesarias sobre la misma.
Una vez garantizado que el contenido de la misma es correcto, se puede proceder a su mecanizado sobre el sistema.
Independientemente de la utilización de una plantilla para la definición de estructura o la mecanización directa en el sistema, existen una serie de aspectos que es recomendable sean tenidos en cuenta:
- Si utilizamos la plantilla de definición, cada elemento ha de ir tipado con el tipo de ubicación por lo que no se debe especificar más de un nivel de estructura en la misma línea.
- Todos los nombres de los controles de enfermería han de ser unívocos independientemente del centro.
- Motivo: ECC te muestra el listado de los controles de enfermería listados de forma conjunta para todos los centros del área hospitalaria, sin especificar el centro en el que se encuentra.
- Por ello, si tenemos dos controles de enfermería que se llaman igual no habrá forma de diferenciarlos.
- Es recomendable que la estructura física siempre tenga los mismos niveles de profundidad.
- Si una planta no tiene alas especificar "ALA ÚNICA" o similar, de manera que en todo caso la definición de la estructura sea estándar y tenga el mismo número de niveles.
- Todos los controles de enfermería, por estandarización, deben estar incluidos dentro de un bloque o área
- Todas las ubicaciones finales en las que se pueda ingresar a un paciente deben estar bajo un control de enfermería
- No aplica a consultas ni quirófanos por ejemplo ya que en estas ubicaciones se atiende al paciente pero no se ingresan en él.
- Todas las ubicaciones finales de HDM deben estar bajo una habitación o sala.
- Por transitividad, concluimos que de forma general, toda ubicación final debe estar bajo una habitación o sala y ésta bajo un control de enfermería y ésta bajo un Área o Bloque .
- Verificar que el tipo de ubicación final consulta SOLO está asignado a ubicaciones finales de tipo consulta y no a plantas, edificios u otro tipo de ubicaciones.
- Motivo: todas las ubicaciones de tipo consulta tienen una consideración especial.
- Ej.:
- Son agendables en la EG para HDM.
- Pueden ser tipadas como consultas especiales (quirofanillos para HDQ).
- Localización: este campo se utiliza en las cartas que envía Citaweb a los pacientes para definir la dirección a la que se tiene que remitir el paciente cuando vaya a consultas. Tiene que ser por tanto, suficientemente autoexplicactiva,
- Ej.: Planta 2 no es suficiente.
- Dentro de un ala podemos tener más de un bloque. Éste además puede ser del mismo tipo. Ejemplo: puedo tener un bloque de quirófanos, un bloque de hospitalización y un bloque de apoyo.
- Dentro de un ala también puedo tener por ejemplo dos bloques de apoyo diferentes o dos bloques de hospitalización. Serán un único bloque o dos bloques diferenciados en función de si físicamente se trata de una zona contigua o de dos zonas dispersas.
- No existe en estructura tipos de ubicación para alas o plantas, por lo que se propone la utilización de la tipología “Bloque/Área” al no tener impacto en la funcionalidad de los sistemas.
- Cunas: no existe relación física entre ubicaciones de estructura por lo que no existe relación alguna entre la cama de una madre y la cuna de su hijo. La relación se marca a nivel de episodio.
- Se propone utilizar como convenio una nomenclatura que asemeje el nombre de la cama de la madre con el nombre de la cuna del niño, si bien al ser un convenio no implicaría en ningún momento ninguna regla funcional
- Ej.: Cama 102-A, cuna 102-Ac.
- UCI: se propone definir para las instancias de uci compuestas por una sala grande donde hay un control de enfermería y una serie de boxes con una cama como sigue:
- Control de Enfermería
- Box 1
- Cama 1
- Box 2
- Cama 2
- Box N
- Cama N
- Box 1
- Motivo: definiéndolo de esta forma el aislamiento de una cama solo implica el aislamiento del box que está en esa cama. Si definiéramos una sala con muchas camas, cuando aisláramos una de ellas el sistema aislaría automáticamente todas las camas de UCI.
- Control de Enfermería
Finalmente, bien directamente a través de la plantilla utilizada para la definición, o bien mediante una exportación de la aplicación ESTRUCTURA, deberemos devolver el catálogo de elementos del árbol de estructura física, que servirá como entrada a posteriores procesos.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil Funcional | C |
| Centro | |
| Responsable TIC del centro | A |
| Referentes funcionales del centro | R |
| STIC | |
| Jefe de proyectos Módulos centralizados | C |
Dependencias
| Actividad |
|---|
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-2] Adecuar la estructura funcional
Para la definición de la estructura funcional o de las modificaciones necesarias sobre esta, se atenderá en todo caso a las directrices y recomendaciones marcadas por el Servicio de Cartera de Servicios.
Además de dichas recomendaciones, es recomendable tener en cuenta que las decisiones que sean tomadas a la hora de definir o modificar la estructura funcional de un centro, afectan o tienen incidencia directa en los siguientes aspectos:
- Nivel de ectópico
- En algunas aplicaciones como el mapa de camas como la EG o del módulo de admisión única, la decisión acerca de si un paciente es ectópico o no está relacionado con la verificación de la relación de la UF del ingreso con la de la ubicación final.
- En función del nivel de ectópico elegido, y el nivel de profundidad de la UF asociada a la cama y al ingreso, se considera o no ectópico un episodio.
- Ej.:
- Estructura
- Udad A
- Udad A.1
- Udad A.1.1
- Udad A.1.2
- Udad A.2
- Udad A.2.1
- Udad A.1
- Udad B
- Udad B.1
- Udad B.1.1
- Udad B.1
- Udad A
- Ejemplo 1.
- UF del ingreso > A.1.1
- UF de la cama > A.1.2
- Si nivel de ectópico = 3, como A.1.1 y A.1.2 en el nivel 3 de jerarquía no comparten padre, entonces el ingreso es ectópico.
- Si nivel de ectópico = 2, como A.1.1 y A.1.2 en el nivel 2 de jerarquía si comparten padre (A.1), entonces el ingreso NO es ectópico.
- Si nivel de ectópico = 1, como A.1.1 y A.1.2 en el nivel 1 de jerarquía si comparten padre (A), entonces el ingreso NO es ectópico.
- Ejemplo 2.
- UF del ingreso > A.1.1
- UF de la cama > A.2.1
- Si nivel de ectópico = 3, como A.1.1 y A.2.1 en el nivel 3 de jerarquía no comparten padre, entonces el ingreso es ectópico.
- Si nivel de ectópico = 2, como A.1.1 y A.2.1 en el nivel 2 de jerarquía no comparten padre, entonces el ingreso es ectópico.
- Si nivel de ectópico = 1, como A.1.1 y A.2.1 en el nivel 1 de jerarquía si comparten padre (A), entonces el ingreso NO es ectópico.
- Estructura
- Generación del CMBD
- La generación del CMBD va vinculado al concepto “especialidad” en Estructura.
- Este concepto se selecciona para cada una de las UF finales a través de la selección en un desplegable de valores.
- Todos los episodios de aquellas UFs que compartan Especialidad, aparecerán de forma conjunta en el CMBD.
- Visualización de pacientes en las salas digitales
- Determinados mapas de camas o salas digitales gestionan la visualización de pacientes ingresados en función de la UF responsable del episodio.
- Una subdivisión excesiva del árbol de estructura funcional puede complicar la visualización de los datos en estos elementos gráficos.
- Asignación de operadores y profesionales a UFs.
- Si se subdivide demasiado, puede ser tediosa la tarea de asignar a cada operador en cada módulo a su UF final correspondiente.
- Puede haber casos en los que un operador haya de asignarse a más de una UF, lo cual, puede generar más complejidad.
En relación a las Líneas asistenciales en estructura, para cada UF final, se debe definir, para cada uno de los centros del hospital, dichas líneas.
Los valores posibles son:
- Consulta
- Si en el centro hay consultas externas de dicha UF.
- Procedimientos
- No aplica a DAH.
- Si aplica a Citaweb para poder agendar este tipo de técnicas.
- Si en el centro hay consultas externas para pruebas diagnósticas o terapéuticas de dicha UF (biopsias, broncoscopias, espirometrías,...).
- Hospitalización
- Si en el centro hay hospitalización en planta para dicha UF.
- Urgencias
- Si en el centro hay urgencias, y la UF es una UF de urgencias en dicho centro.
- Intervencion
- Si en centro se programan intervenciones quirúrgicas mayores para dicha UF.
- Relacionado con funcionalidades de bloques quirúrgicos.
- Laboratorio
- Si se realizan en el centro extracciones u otro tipo de actividades relacionadas con laboratorio para dicha UF.
- No aplica a Atención Especializada
- Hdq
- Si en centro se programan cirugía menor ambulatoria para dicha UF.
- Hdm
- Si en el centro hay hospital de día médico para dicha UF.
Ejemplos:
- Traumatología
- Tiene hdq, pero no suele tener hdm
- Urología
- Normalmente tiene hdq y hdm en las áreas hospitalarias
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil Funcional | C |
| Centro | |
| Responsable TIC del centro | A |
| Referentes funcionales del centro | R |
| STIC | |
| Jefe de proyectos Módulos centralizados | S |
Dependencias
| Actividad |
|---|
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-3] Procesos de autentificación
Se incluyen en este bloque las actividades relacionadas con la preparación de todos los procesos de autentificación, gestión de usuarios y contraseñas, perfiles, permisos, etc.
[ACT-PRE-FUNC-3.1] Preparar procesos de Autentificación a través de MACO
La correcta ejecución de las actividades relacionadas con los procesos de autentificación es clave para el arranque, dado que es imprescindible que todos los usuarios puedan acceder al sistema y puedan hacerlos con los permisos y roles concretos que necesitan para la ejecución de su actividad. La experiencia nos indica que la realización de esta actividad de forma manual, supone un alto grado de posibilidad de error que no saldrá a la luz hasta el mismo día del arranque, tanto referidos a usuarios que falten, como a asignación incorrecta de roles o permisos en las diferentes estaciones. En este caso su única opción de mitigación pasa por formar un equipo de contingencia que subsanen estos errores.
Por el contrario, experiencias en otros centros, que basaron la ejecución de estas tareas en la utilización de herramientas automatizadas para la carga de operadores y profesionales, obtuvieron resultados mucho más satisfactorio dado que, si bien la eliminación total de errores no fue posible, el números de estos disminuyó drásticamente.
...
Para ello, deben utilizarse procedimientos de análisis de información basados en reglas acordadas con el hospital que permitirán categorizar a los usuarios en estos grupos.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil Funcional | S |
| Centro | |
| Responsable TIC del centro | R A |
| STIC | |
| Jefe de proyectos Módulos centralizados | C |
| Proveedores de soporte N3 | |
| Soporte N3 del producto a implantar | S |
Dependencias
| Actividad |
|---|
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-3.2] Preparar procesos de Autentificación a través de DMSAS
...
Es necesario verificar de forma previa al arranque durante la fase de preimplantación que todos los usuarios que vayan a utilizar estos sistemas que se autentifican a través de DMSAS, dispongan de usuario en el dominio y tengan asociado el rol/perfil correspondiente.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil Funcional | S |
| Centro | |
| Responsable TIC del centro | R A |
| STIC | |
| Jefe de proyectos Módulos centralizados | C |
Dependencias
| Actividad |
|---|
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-3.3] Preparar otros procesos de Autentificación
De igual forma que para aplicaciones que gestionen sus usuarios y perfiles a través de MACO es necesario preparar los procesos de autentificación y la carga de usuarios en sistemas en lo que la autentifican se lleva a cabo a través de otros mecanismos de autentificación, como pueden ser certificados digitales, dni electrónico, etc.
Es necesario verificar de forma previa al arranque durante la fase de preimplantación que todos los usuarios que vayan a utilizar estos sistemas de autentificación dispongan de los elementos necesarios y tengan asociado el rol/perfil correspondiente.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil Funcional | R A |
| Centro | |
| Responsable TIC del centro | I |
Dependencias
| Actividad |
|---|
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-4] Preparar dependencias en módulos centralizados
Otro de los procesos que mayor dedicación necesitan por parte del centro para La preparación del comienzo de la implantación es la configuración y adecuación de todos los módulos corporativos centralizaos relacionados directa o indirectamente con el proyecto.
Son Módulos Centralizados por ejemplo: Citaweb, MPA, APD, PDI, BDU, AGD, ETC
El conjunto de sistemas, la forma y el grado en la que estos serán afectados dependerá específicamente de cada proceso de implantación y debe ser especializado en cada Modelo Corporativo de Implantaciones MCI que se defina sobre el marco del MCMI. A pesar de ello, el objetivo final sobre todos ellos son los mismos:
- Configurar cada uno de los módulos con la información necesaria para su interacción con el nuevo sistema a implantar. Ejemplos:
- AGD > inclusión de códigos de procedimientos que falten.
- AGD > inclusión de todas las intervenciones a futuro que estén registradas en otros sistemas de gestión.
- Citaweb > inclusión de todas las citas a futuro que estén registradas en otros sistemas de gestión.
- Citaweb > marcado de las agendas para petición o no de historia clínica.
- MPA > definir catálogo de la cartera de servicios para el centro
- Parametrización de cada uno de los sistemas corporativos centralizados para que funcionen conforme a la definición de los circuitos.
- OJO: en fase de preimplantación solo modificaremos la parametrización de los entornos preproductivos para no afectar a producción.
- El entorno de producción solo será configurado si existen garantías de que no afectarán al funcionamiento normal de los usuarios.
- En caso contrario se analizarán los cambios necesarios en este momento y se recogerán las actuaciones a realizar en el “GEST15. Plan de arranque” que definiremos para la ejecución de la “Fase 5. ARR”.
- Ejemplos:
- Citaweb > configuración de parámetros para trabajar en nuevos circuitos, como por ejemplo los circuitos de especializada.
- CAE > configuración de puertas de urgencia para su integración con DAH y que se emita mensajería.
- En preproducción, introducción de un pool de datos de muestra suficientemente amplio como para que permita la ejecución de todas las actividades de la fase 4 de implantación enfocadas a preparar el cambio. Ejemplos:
- Citaweb > creación de agendas de prueba con citas suficientes de cada tipología.
- AGD > creación de entradas de prueba.
- MPA > creación y parametrización de circuitos de prueba, peticiones, etc.
- PDI > creación de agendas de prueba, citas y resultados.
- Etc.
Es importante reseñar que esta configuración deberá llevarse a cabo en:
- Los entornos preproductivos (FOR, VAL, PRE) > para poder llevar a cabo correctamente:
- Las sesiones de formación y transferencia del conocimiento a usuarios finales.
- Las pruebas de integración con sistemas terceros en el nuevo escenario.
- La validación de los procesos de migración de datos.
- El entorno de producción > para permitir el funcionamiento correcto del nuevo sistema tras el arranque.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil Funcional | C |
| Centro | |
| Responsable TIC del centro | R A |
| Responsable de cartera y servicios en el centro | R |
| STIC | |
| Jefe de proyectos Módulos centralizados | C |
| Proveedores de soporte N3 | |
| Soporte N3 del producto a implantar | C |
Dependencias
| Actividad |
|---|
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
| -- |
[ACT-PRE-FUNC-5] Parametrización
En el conjunto de actividades englobadas dentro de este apartado llevaremos a cabo una serie de acciones encaminadas a completar la definición de la parametrización del sistema a implantar.
[ACT-PRE-FUNC-5.1] Definir parametrización del sistema a implantar
En la fase de Reingeniería de procesos, durante las sesiones de reingeniería se habrá comenzado a reflejar los valores de los parámetros y tablas maestras que se hayan acordado durante dichas sesiones.
En previsión de que existan parámetros o valores de tablas maestras que, bien por falta de tiempo o bien por necesidad de escalar la decisión sobre sus valores a otro ámbito, no hayan podido ser acordados durante la sesión (y recogido en las plantillas de parametrización), antes de finalizar dicha fase, estas plantillas han de ser facilitadas al centro para que sean finalizadas (proceso “[P-RP-FUNC-9] Entregar plantillas de parametrización”).
La finalización de la recogida de información en estas plantillas para la definición de la parametrización debe ser llevada a cabo como decimos por el centro con el apoyo consultivo de SSCC y equipo de implantación.
Esta parametrización dará como resultado una serie de documentos que definirán los valores de los parámetros cuya potestad de decisión están en el centro, y la definición de los valores de una serie de tablas maestras parametrizables.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Perfil Funcional | C |
| Centro | |
| Responsable TIC del centro | R A |
| Referentes funcionales del centro | C |
Dependencias
| Actividad |
|---|
| [ACT-RP-FUNC-9] Entregar plantillas de parametrización |
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-PRE-FUNC-1] Adecuar la estructura física |
| [ACT-PRE-FUNC-2] Adecuar la estructura funcional |
| [ACT-PRE-FUNC-3.1] Preparar procesos de Autentificación a través de MACO |
| [ACT-PRE-FUNC-3.2] Preparar procesos de Autentificación a través de DMSAS |
| [ACT-PRE-FUNC-3.3] Preparar otros procesos de Autentificación |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-5.2] Verificar que los valores definidos corporativamente son respetados
Una vez hemos definido la parametrización del sistema en el proceso “[ACT-PRE-FUNC-5.1] Definir parametrización del sistema a implantar”, y hemos recogido el resultado en el entregable “FUNC11. Parametrización del.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | A |
| Perfil Funcional | R |
| Centro | |
| Responsable TIC del centro | I |
| Responsable de cartera y servicios en el centro | C |
| STIC | |
| Responsables funcionales | C |
Dependencias
| Actividad |
|---|
| [ACT-PRE-FUNC-5.1] Definir parametrización del sistema a implantar |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-5.3] Definir mapeos de tablas maestras
En relación a los valores de tablas maestras, son de aplicación los valores incluidos en el nuevo sistema, que a su vez hace uso de tablas de valores y aplicaciones centralizadas, utilizando un conjunto de datos maestros tipo.
Para los procesos de migración de datos de un sistema origen diferente hacia un sistema del SAS, es necesario un mapeo de determinados valores maestros.
Ídem ocurre para la implementación de procesos de integración entre sistemas del SAS y sistemas terceros. En este caso, los valores a utilizar en la integración son igualmente los definidos en el sistema del SAS.
Es necesario por tanto en muchos casos un proceso de mapeo entre los valores de los parámetros y las tablas maestras del sistema origen y los del nuevo sistema a implantar. De este proceso obtendremos como salida el entregable “FUNC12. Mapeos de tablas maestras”.
Con respecto a la definición de los mapeos es importante tener en cuenta la casuística relacionada con los mapeos con cardinalidad N..1, 1..N y N..N
En todo caso un mapeo ha de ser unívoco, por lo que cada valor de origen ha de ser mapeado a uno y solo un valor de destino. Esto nos permitirá automatizar los procesos de migración e integración de datos.
OJO: es diferente el mapeo que se utilizará para las migraciones y las integraciones en sentido SISTEMA_ORIGINAL > NUEVO_SISTEMA, que el mapeo que se utilizará las integraciones en sentido NUEVO_SISTEMA > SISTEMA_ORIGINAL.
Tendremos así dos mapeos:
- Flujo de información A. Mapeo para el flujo de información con dirección SISTEMA_ORIGINAL > NUEVO_SISTEMA.
- Este flujo de información es típico para:
- Procesos de migración de datos
- Procesos de integración posibles pero no muy extendidos. Son aquellos procesos de integración con emisor SISTEMA_ORIGINAL y receptor NUEVO_SISTEMA.
- Dará como resultado la necesidad de definir un mapeo de datos específico: Mapeo A.
- Este flujo de información es típico para:
- Flujo de información B. Mapeo para el flujo de información con dirección NUEVO_SISTEMA > SISTEMA_ORIGINAL
- Este flujo de información es típico para:
- Procesos de integración más comunes. Son aquellos procesos de integración con emisor NUEVO_SISTEMA y receptor SISTEMA_ORIGINAL.
- Dará como resultado la necesidad de definir un mapeo de datos específico: Mapeo B.
- Este flujo de información es típico para:
Para el flujo de información A donde el mapeo es desde el sistema origen hacia el nuevo sistema, deberemos tener cuidado con los mapeos de datos con cardinalidad 1..N y N..N, correspondiendo el primer literal a la cardinalidad en el sistema original y el segundo a la cardinalidad en el nuevo sistema.
Para los flujos de información de tipo B, y donde el mapeo es desde el nuevo sistema hacia el sistema origen, deberemos tener cuidado con los mapeos de datos con cardinalidad N..1 y N..N, correspondiendo el primer literal a la cardinalidad en el sistema original y el segundo a la cardinalidad en el nuevo sistema.
En función de la correspondencia de datos nos podemos encontrar los siguientes escenarios:
Estrategia para definir el mapeo de datos A para Flujos de información (SISTEMA_ORIGINAL > NUEVO_SISTEMA).
CARD. SISTEMA ORIGINAL | CARD. NUEVO SISTEMA | OBSERVACIONES |
|---|---|---|
1 | 1 | En este caso, no existe mayor problema, pues es posible mapear un valor del sistema origen a un valor del sistema destino de forma unívoca. |
N | 1 | En Este caso, aunque varios valores del sistema original sean mapeados al mismo valor destino, seguimos teniendo una asignación de cada valor origen a uno de destino de forma unívoca, por lo que no habría problemas más allá de la pérdida de la diferenciación entre los n valores de origen, que son sintetizados en un único valor |
1 | N | En este caso, no existe una relación unívoca entre el valor del sistema original y los del nuevo sistema, por lo que no es posible sistematizar el proceso de migración o integración. Es por ello necesario convertir la relación 1..N en una relación 1..1 seleccionando uno de los N valores del nuevo sistema correspondientes como el valor por defecto en la migración o integración de estos datos. |
N | N | En este caso, no existe una relación unívoca entre el valor del sistema original y los del nuevo sistema, por lo que no es posible sistematizar el proceso de migración o integración. Es por ello necesario convertir la relación N..N en una relación N..1 seleccionando uno de los N valores del nuevo sistema correspondientes como el valor por defecto en la migración o integración de estos datos. |
...
En resumen, es necesario tener en cuenta que los mapeos de datos son bidireccionales, y así han de ser definidos para dar cobertura correctamente a los procesos de migración y de integración (para los sentidos de flujo de integración utilizado).
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil funcional | C |
| Perfil de migración | C I |
| Centro | |
| Responsable TIC del centro | A |
| Responsable de cartera y servicios en el centro | C |
| Referentes funcionales del centro | C |
| Proveedores de soporte N3 | |
| Soporte N3 del producto existente a sustituir | S |
| Soporte N3 de sistemas terceros o departamentales afectados | S |
Dependencias
| Actividad |
|---|
| [ACT-RP-MIGR-2] Definir Alcance de las migraciones |
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-6] Adecuar Sistemas origen
Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.
Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:
- Adecuación para el modelo de migración de datos histórico / activo. Ver apartado “9 Modelo de migración”.
- Eliminación de funcionalidades en código que queden obsoletas.
- Modificación de la parametrización del sistema origen > para eliminar funcionalidades, cambiar circuitos.
- Modificación o reducción de funcionalidades que si bien quedan activas, no en todo su alcance.
- Preparación de escenario de mantenimiento del sistema en modo solo lectura. Suele necesitar de la gestión de usuarios / roles / perfiles que no siempre dan cobertura a un escenario de solo lectura.
- Modificación en los elementos de autentificación para el sistema origen > permisos, perfiles, eliminación de usuarios, etc.
- Etc.
[ACT-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen
Sobre diferentes sistemas origen, la ejecución del proceso de implantación puede suponer una modificación de su alcance, y de sus circuitos de interoperabilidad.
Ante esta situación, es común que surja la necesidad de modificar el sistema origen para adecuarlo a este nuevo escenario. Modificaciones comunes pueden ser las siguientes:
- Adecuación para el modelo de migración de datos histórico / activo. Ver apartado “9 Modelo de migración”.
- Eliminación de funcionalidades en código que queden obsoletas.
- Modificación de la parametrización del sistema origen > para eliminar funcionalidades, cambiar circuitos.
- Modificación o reducción de funcionalidades que si bien quedan activas, no en todo su alcance.
- Preparación de escenario de mantenimiento del sistema en modo solo lectura. Suele necesitar de la gestión de usuarios / roles / perfiles que no siempre dan cobertura a un escenario de solo lectura.
- Modificación en los elementos de autentificación para el sistema origen > permisos, perfiles, eliminación de usuarios, etc.
- Etc.
Todas las modificaciones que se acuerden sean necesarias llevar a cabo, serán incluidas en un registro para su control.
El alcance concreto deberá haberse debatido durante el proceso “[P-RP-FUNC-4] Sesiones de análisis de procesos”, y basarse en los acuerdos plasmados en el entregable “GEST05. Informe final Reingeniería de Procesos”.
Por último, del acuerdo de las modificaciones a llevar a cabo deberá surgir la actualización del “FUNC06. Plan de Pruebas de los sistemas origen”.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | C I |
| Perfil funcional | C I |
| Perfil de migración | C I |
| Centro | |
| Responsable TIC del centro | R A |
| Proveedores de soporte N3 | |
| Soporte N3 del producto existente a sustituir | S |
Dependencias
| Actividad |
|---|
| [ACT-PRE-MIGR-1] Establecer mecanismo diferenciación activo vs pasivo |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-6.2] Definir Plan de pruebas sobre sistemas origen
En el proceso anterior “[ACT-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen” se definen las modificaciones sobre los sistemas origen necesarias para su convivencia con los nuevos sistemas tras la finalización de la implantación. Las modificaciones a realizar deben tener asociado un plan de pruebas que ejecutar sobre el sistema origen y que validen las modificaciones realizadas.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil funcional | C |
| Centro | |
| Responsable TIC del centro | R A |
| Referentes funcionales del centro | C |
| Proveedores de soporte N3 | |
| Soporte N3 del producto a implantar | S |
Dependencias
| Actividad |
|---|
| [[ACT-RP-FUNC-4] Sesiones de análisis de procesos |
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
| [ACT-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FUNC-7] Implementar optimizaciones como resultado de los planes de sistema
Es caso normal que una vez un producto es implantado o desplegado en determinados entornos con características similares al entorno definitivo de producción, se proceda a ejecutar sobre dicha instancia determinados planes de prueba no relacionados en si con el proceso de implantación sino con el de construcción.
El ejemplo típico es la ejecución de planes de pruebas de sistemas o de estrés. Debido a que necesitan de un entorno similar a producción no es concluyente los resultados que pudieran desprenderse de su ejecución en un entorno de desarrollo, por lo que, si bien son actividades correspondientes a la fase de Construcción, se pospone su ejecución hasta el despliegue del mismo, por lo que la actividad se enmarca temporalmente dentro de una orden de implantación.
De esta ejecución de pruebas surgirá un resultado y una serie de conclusiones que pueden mostrar la necesidad de implementar una serie de optimizaciones sobre los productos evaluados. Es en el marco de esta tarea donde los responsables del desarrollo incorporarían estas mejoras, que administrativamente hablando formarían parte del alcance de la orden de trabajo de construcción (aunque temporalmente coincidan en fase de implantación).
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | I |
| Perfil de sistemas | C |
| STIC | |
| Jefe de proyecto de la STIC | I |
| Proveedores de soporte N3 | |
| Soporte N3 del producto a implantar | R A |
Dependencias
| Actividad |
|---|
| [ACT-PRE-SIST-6] Ejecutar Plan de Pruebas de Sistemas (pruebas estrés del producto) |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
| -- |
Área Formación
[ACT-PRE-FORM-1] Definir Plan de formación
...
- Catálogo de Unidades Didácticas diferenciadas a impartir
- Índice del contenido de cada una de las Unidades Didácticas
- Mapeo de los perfiles o roles a los que aplica cada unidad didáctica.
- Número de sesiones de formación por cada Unidad Didáctica y Perfil/Rol.
- Calendario de sesiones de formación con fecha, hora, unidad didáctica y colectivo al que se va a impartir la formación.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | A |
| Perfil de formación | R |
| Centro | |
| Responsable TIC del centro | C I |
| Referentes funcionales del centro | C |
Dependencias
| Actividad |
|---|
| [ACT-RP-FORM-2] Estimar esfuerzo necesario formación usuarios finales |
| [ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FORM-2] Preparar material de formación
...
Se incluye igualmente la adecuación de guías, esquemas, y demás material de apoyo si así es necesario.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | A |
| Perfil de formación | R |
Dependencias
| Actividad |
|---|
| [ACT-PRE-FORM- |
...
Por último, se procederá a validar con el centro el Plan de formación confeccionado.
...
| 1] Definir Plan de formación |
| [ACT- |
...
| APS- |
...
| GEST- |
...
El objetivo de este proceso es facilitar a los responsables TIC del centro cuanta formación y conocimiento necesiten sobre la nueva herramienta a implantar.
Se llevarán a cabo sesiones específicas de formación sobre aspectos tanto funcionales como técnicos.
Se implementarán igualmente cualquier otra vía de transferencia del conocimiento que se estime oportuno para asegurar la misma: trabajo conjunto, tutorización, etc.
Durante esta fase se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, en este caso usuarios TIC, propiciando así que se familiaricen cuantos antes con los módulos y puedan maximizar el aporte de valor añadido y las mejores soluciones durante el soporte N0 al resto de usuarios del centro durante la fase de consolidación.
Disponer de un periodo de tiempo mayor para practicar con los módulos, resolver dudas, etc., antes del arranque redundará positivamente en una mayor destreza con los nuevos sistemas, permitiendo ofrecer el soporte deseado, y facilitando la necesaria autonomía de los usuarios y del centro en general a la salida del equipo de implantación.
...
| 2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FORM-3] Validar Plan de formación
Por último, se procederá a validar con el centro el Plan de formación confeccionado.
Este proceso será ejecutado hasta conseguir la validación de dicho plan.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | A |
| Perfil de formación | I |
| Centro | |
| Responsable TIC del centro | R |
| Referentes funcionales del centro | C |
Dependencias
| Actividad |
|---|
| [ACT-PRE-FORM-1] Definir Plan de formación |
| [ACT-PRE-FORM-2] Preparar material de formación |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
[ACT-PRE-FORM-4] TC > formación a responsables TIC del centro / CGES
El objetivo de este proceso es facilitar a los responsables TIC del centro cuanta formación y conocimiento necesiten sobre la nueva herramienta a implantar.
Se llevarán a cabo sesiones específicas de formación sobre aspectos tanto funcionales como técnicos.
Se implementarán igualmente cualquier otra vía de transferencia del conocimiento que se estime oportuno para asegurar la misma: trabajo conjunto, tutorización, etc.
Durante esta fase se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, en este caso usuarios TIC, propiciando así que se familiaricen cuantos antes con los módulos y puedan maximizar el aporte de valor añadido y las mejores soluciones durante el soporte N0 al resto de usuarios del centro durante la fase de consolidación.
Disponer de un periodo de tiempo mayor para practicar con los módulos, resolver dudas, etc., antes del arranque redundará positivamente en una mayor destreza con los nuevos sistemas, permitiendo ofrecer el soporte deseado, y facilitando la necesaria autonomía de los usuarios y del centro en general a la salida del equipo de implantación.
Por esto, insistiremos en la implicación al 100% de estos usuarios en la Transferencia del Conocimiento, garantizándose así que la salida del equipo de implantación sea un proceso natural y exitoso.
Matriz RASCI
| Perfil | Responsabilidad |
|---|---|
| Equipo de implantación | |
| Jefe de equipo de implantación | A |
| Perfil de formación | R |
| Centro | |
| Responsable TIC del centro | I |
Dependencias
| Actividad |
|---|
| [ACT-PRE-FORM-3] Validar Plan de formación |
| [ACT-APS-SIST-2.3] Verificar entrega de los entornos para RP |
| [ACT-APS-FUNC-3] Analizar estado situación inicial del hospital para la implantación (datos, parametrización, jaspers compatibles,…) |
| [ACT-RP-FORM-1] Transferencia del conocimiento > Actividades fase PRE |
| [ACT-RP-FORM-2] Estimar esfuerzo necesario formación usuarios finales |
| [ACT-APS-GEST-2] Reunión de preparación y definición calendario de sesiones de RP |
Catálogo de entregables
| Entrada | Salida |
|---|---|
|
|
Área de Migración
[ACT-PRE-MIGR-1] Establecer mecanismo diferenciación activo vs pasivo
...
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2