Historial de página

...

Área Funcional

[ACT-IMP-FUNC-1] PRE

Se incluyen en las actividades incluidas en este apartado todas las actividades de esta fase relacionadas con los entornos de PRE.

[ACT-IMP-FUNC-1.1] Parametrización de PRE

Procedemos en este bloque de actividades a parametrizar el entorno de preproducción al completo

[ACT-IMP-FUNC-1.1.1] Generación de script y herramientas de parametrización por lotes

En determinadas ocasiones, la parametrización de sistemas de información supone una modificación o carga de datos de mucho volumen.

Por poner algunos ejemplos, la parametrización de toda la extensión local de la estructura física en sistemas como la Estación de gestión, la creación de todas las agendas y tramos básicos para los profesionales de un nuevo hospital, etc suelen suponer la parametrización de cientos de elementos.

Para ello, no es viable la parametrización manual de cada uno de ellos por el esfuerzo necesario que ello supondría.

En su lugar, es habitual el apoyo en herramientas de parametrización específicas que ayuden a automatizar dicho proceso de parametrización (ojo, no de migración).

En el ámbito de esta actividad será en el que procederemos a la concepción, diseño y construcción de dichas herramientas (scripts, código java, procesos ETL, etc).

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil de migración	R
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	C
Soporte N3 de sistemas terceros o departamentales afectados	C

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	--

[ACT-IMP-FUNC-1.1.2] Testing scripts y herramientas de parametrización por lotes. Cálculo de tamaño de ventana de tiempo necesario

Una vez creadas en el paso anterior las herramientas que nos ayudarán a la automatización del proceso de parametrización, estas han de ser previamente probadas y validadas antes de poder dar por bueno el resultado de su ejecución con datos reales.

Testearemos por tanto en esta actividad dichas herramientas.

Como resultado además de dichas pruebas, otro punto importante en esta actividad consiste en obtener y calcular el tamaño de ventana de tiempo necesario para su ejecución. Este dato nos servirá para poder planificar y ajustar correctamente el proceso de parametrización y el proceso de arranque.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil de migración	R
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	C
Soporte N3 de sistemas terceros o departamentales afectados	C

Dependencias

Actividad
[ACT-IMP-FUNC-1.1.1] Generación de script y herramientas de parametrización por lotes

Catálogo de entregables

Entrada	Salida
--	--

[ACT-IMP-FUNC-1.1.3] Parametrizar conectividad de los entornos en PRE

En esta área habrán de realizarse las parametrizaciones del nuevo sistema, en todos los entornos de preproducción que se utilicen: formación, validación, preproducción, producción, etc.

Basados en anteriores experiencias, se propone llevar a cabo esta parametrización en dos fases. Una primera en la que se realizará la parametrización de conectividad, y una segunda fase en la que esta parametrización será completada con todos aquellos aspectos relacionados con las decisiones funcionales acordadas durante la fase de Reingeniería de Procesos.

Esta escisión, reportará como beneficio directo la optimización de los tiempos de ejecución del resto de actividades dependientes de estas, al facilitarles un sistema en el que es posible realizar los circuitos básicos.

Basado en esta estrategia surgen las dos actividades [ACT-IMP-FUNC-1.1.3] Parametrizar conectividad de los entornos en PRE y [ACT-IMP-FUNC-1.1.4] Parametrizar funcionalmente los entornos en PRE.

En el caso de la presente, el objetivo como decimos es que el entorno sea operativo con las configuraciones por defecto.

Por ello, para llevar a cabo esta actividad no es necesario disponer de la definición de la parametrización específica para el hospital. Bastará disponer del entorno y de la documentación externa relativa a la parametrización del mismos.

Finalizada esta actividad, podremos hacer uso del sistema con la configuración básica por defecto.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE
[ACT-IMP-FUNC-1.1.

4] Parametrizar funcionalmente los entornos en PRE

2] Testing scripts y herramientas de parametrización por lotes. Cálculo de tamaño de ventana de tiempo necesario

Catálogo de entregables

Entrada	Salida
[SIST10] Entornos de PRE [EXT.FUNC01] Guías de parametrización	--

[ACT-IMP-FUNC-1.1.4] Parametrizar funcionalmente los entornos en PRE

Una vez disponemos de un entorno ejecutable tras la parametrización de la conectividad llevada a cabo en la anterior actividad, deberemos pasar de un sistema que funciona a un sistema que se comporta con la idiosincrasia y características específicas que el centro demanda.

Es hora por tanto de llevar a cabo la parametrización funcional del mismo. Para ello, si será necesario disponer previamente de la parametrización y los valores acordados para cada elemento en función de los acuerdos funcionales aprobados para el centro.

Una vez realizadas la parametrización de conectividad y funcional, podrá verificarse con el centro que los circuitos funcionales acordados en la Reingeniería de Procesos, efectivamente cumplen los requisitos necesarios para poder utilizar el nuevo sistema. Esto se llevará a cabo en el proceso “[P-IMP-FUNC-1.4] Certificar los circuitos parametrizados en PRE”.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Centro
Responsable TIC del centro	C
Referentes funcionales del centro	C
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-IMP-FUNC-1.1.

5] Implementar modificaciones sobre el aplicativo en PRE

Aquellos otros acuerdos que se alcanzaron en la Reingeniería de Procesos que estén al alcance y bajo la potestad de ser construidos o implementados por el equipo de implantación (realización o modificación de informes en el caso, decisiones específicas tomadas sobre circuitos funcionales,…) se implementarán en esta fase y serán validados por los responsables correspondientes.

Estas modificaciones fueron acordadas durante la fase de RP, y deben estar recogidas en el entregable “GEST05. Informe final Reingeniería de Procesos” generado durante la ejecución del proceso “[P-RP-GEST-5] Elaborar Informe Reingeniería de Procesos”.

Es importante que todos estos cambios queden recogidos en un Registro de modificaciones, y sean tenidos en cuenta en el contenido de los Planes de Prueba funcionales correspondientes.

Este Registro facilitará igualmente a posteriori la labor de los equipos de n3 del proveedor encargado del mantenimiento de la solución a quien deberá trasladársele dicho registro.

[ACT-IMP-FUNC-1.1.6] Verificar modificaciones sobre el aplicativo en PRE

[ACT-IMP-FUNC-1.2] Certificar los circuitos parametrizados en PRE

Una vez disponemos de un entorno en el que hemos parametrizado tanto la conectividad como las decisiones funcionales, y una vez hemos implementado sobre el mismo las modificaciones acordadas al alcance del equipo de implantación, podremos verificar que el resultado final casa con el esperado y acordado durante la fase de Reingeniería de Procesos.

Para ello, ejecutaremos el “FUNC07. Plan de Pruebas Funcionales de los Circuitos” previamente definido y recogeremos el resultado de dichas pruebas en el entregable “FUNC14. Plan de Pruebas Funcionales de los Circuitos. Registro de ejecución”.

[ACT-IMP-FUNC-1.2.1] Validación del alcance

El objetivo de esta tarea es que el equipo de implantación, una vez parametrizados los entornos, valide que sobre dicho entorno funcionan perfectamente todos los circuitos funcionales y que estos son conformes con todos los acuerdos establecidos durante la fase de reingeniería de procesos.

Es una tarea previa de los equipos de implantación antes de que dichos circuitos sean posteriormente verificados por los responsables funcionales durante la ejecución de la tarea "[ACT-IMP-FUNC-1.2.2] Verificación del alcance. Soporte a las pruebas funcionales".

En ningún caso debe procederse a ejecutarse la verificación del alcance por parte de los responsables funcionales sin que previamente exista recogida formalmente el resultado satisfactorio del equipo de implantación al proceso de "Validación de alcance" realizado en esta tarea.

3] Parametrizar conectividad de los entornos en PRE

[ACT-PRE-FUNC-5.2] Verificar que los valores definidos corporativamente son respetados

[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE

[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-PRE-FUNC-4] Preparar dependencias en módulos centralizados

[ACT-PRE-FUNC-5.1] Definir parametrización del sistema a implantar

[ACT-PRE-FUNC-5.3] Definir mapeos de tablas maestras

Catálogo de entregables

Entrada	Salida
[FUNC11] Parametrización del sistema [SIST10] Entornos de PRE [FUNC08] Estructura física [FUNC09] Estructura funcional [FUNC11] Parametrización del sistema [FUNC12] Mapeos de tablas maestras [EXT.FUNC01] Guías de parametrización [FUNC10] Catálogo de operadores, profesionales y perfiles	--

[ACT-IMP-FUNC-1.

2

1.

2] Verificación del alcance. Soporte

5] Implementar modificaciones sobre el aplicativo en PRE

Aquellos otros acuerdos que se alcanzaron en la Reingeniería de Procesos que estén al alcance y bajo la potestad de ser construidos o implementados por el equipo de implantación (realización o modificación de informes en el caso, decisiones específicas tomadas sobre circuitos funcionales,…) se implementarán en esta fase y serán validados por los responsables correspondientes.

Estas modificaciones fueron acordadas durante la fase de RP, y deben estar recogidas en el entregable “GEST05. Informe final Reingeniería de Procesos” generado durante la ejecución del proceso “[P-RP-GEST-5] Elaborar Informe Reingeniería de Procesos”.

Es importante que todos estos cambios queden recogidos en un Registro de modificaciones, y sean tenidos en cuenta en el contenido de los Planes de Prueba funcionales correspondientes.

Este Registro facilitará igualmente a posteriori la labor de los equipos de n3 del proveedor encargado del mantenimiento de la solución a quien deberá trasladársele dicho registro.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Centro
Responsable TIC del centro	C
Referentes funcionales del centro	C
Proveedores de soporte N3
Soporte N3 del producto a implantar	C I

Dependencias

Actividad
[ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos
[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE

Catálogo de entregables

Entrada	Salida
[GEST05] Informe final Reingeniería de Procesos [SIST10] Entornos de PRE [EXT.FUNC01] Guías de parametrización	[FUNC13] Registro de modificaciones implementadas

[ACT-IMP-FUNC-1.1.6] Verificar modificaciones sobre el aplicativo en PRE

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Perfil de integración	S
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
[EXT.FUNC01] Guías de parametrización	--

[ACT-IMP-FUNC-1.2] Certificar los circuitos parametrizados en PRE

Una vez disponemos de un entorno en el que hemos parametrizado tanto la conectividad como las decisiones funcionales, y una vez hemos implementado sobre el mismo las modificaciones acordadas al alcance del equipo de implantación, podremos verificar que el resultado final casa con el esperado y acordado durante la fase de Reingeniería de Procesos.

Para ello, ejecutaremos el “FUNC07. Plan de Pruebas Funcionales de los Circuitos” previamente definido y recogeremos el resultado de dichas pruebas en el entregable “FUNC14. Plan de Pruebas Funcionales de los Circuitos. Registro de ejecución”.

[ACT-IMP-FUNC-1.2.1] Validación del alcance

El objetivo de esta tarea es que el equipo de implantación, una vez parametrizados los entornos, valide que sobre dicho entorno funcionan perfectamente todos los circuitos funcionales y que estos son conformes con todos los acuerdos establecidos durante la fase de reingeniería de procesos.

Es una tarea previa de los equipos de implantación antes de que dichos circuitos sean posteriormente verificados por los responsables funcionales durante la ejecución de la tarea "[ACT-IMP-FUNC-1.2.2] Verificación del alcance. Soporte a las pruebas funcionales".

En ningún caso debe procederse a ejecutarse la verificación del alcance por parte de los responsables funcionales sin que previamente exista recogida formalmente el resultado satisfactorio del equipo de implantación al proceso de "Validación de alcance" realizado en esta tarea.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Centro
Responsable TIC del centro	S
Referentes funcionales del centro	S
STIC
Jefe de proyecto de la STIC	I

Dependencias

Actividad
[ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos
[ACT-IMP-FUNC-1.1.5] Implementar modificaciones sobre el aplicativo en PRE
[ACT-IMP-FUNC-1.1.4] Parametrizar funcionalmente los entornos en PRE
[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE
[ACT-RP-FUNC-8] Definir Plan de Pruebas Funcionales de los circuitos

Catálogo de entregables

Entrada	Salida
[GEST05] Informe final Reingeniería de Procesos [SIST10] Entornos de PRE [FUNC13] Registro de modificaciones implementadas [FUNC07] Plan de Pruebas Funcionales de los Circuitos [EXT.FUNC01] Guías de parametrización	[FUNC14] Plan de Pruebas Funcionales de los Circuitos. Registro de ejecución

[ACT-IMP-FUNC-1.2.2] Verificación del alcance. Soporte a las pruebas funcionales

Durante esta tarea, los respnosanbles responsables funcionales verifican que el funcionamiento y los procesos implementados y parametrizados en las herramientas a implantar son conforme a los acuerdos establecidos y las funcionalidades esperadas del producto.

En esta actividad, el objetivo es que, las mismas pruebas que previamente ya ha debido validar el equipo de implantación en la actividad "[ACT-IMP-FUNC-1.2.1] Validación del alcance" sean ejecutadas en presencia de los responsables funcionales, "verificando" estos que efectivamente el funcionamiento es correcto.En ningún caso esta actividad ha de suponer el primer encuentro contra una situación anómala que ha todas luces refleje una situación previamente no verificada."[ACT-IMP-FUNC-1.2.1] Validación del alcance" sean ejecutadas en presencia de los responsables funcionales, "verificando" estos que efectivamente el funcionamiento es correcto.

En ningún caso esta actividad ha de suponer el primer encuentro contra una situación anómala que ha todas luces refleje una situación previamente no verificada.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	I
Perfil funcional	S
Perfil de formación	S
Perfil de integración	S
Perfil de sistemas	S
STIC
Jefe de proyecto de la STIC	I
Responsables funcionales	R A

Dependencias

Actividad
[ACT-RP-GEST-5] Elaborar Informe Reingeniería de Procesos
[ACT-IMP-FUNC-1.1.5] Implementar modificaciones sobre el aplicativo en PRE
[ACT-IMP-FUNC-1.1.4] Parametrizar funcionalmente los entornos en PRE
[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE
[ACT-RP-FUNC-8] Definir Plan de Pruebas Funcionales de los circuitos

Catálogo de entregables

Entrada	Salida
[GEST05] Informe final Reingeniería de Procesos [SIST10] Entornos de PRE [FUNC13] Registro de modificaciones implementadas [FUNC07] Plan de Pruebas Funcionales de los Circuitos [EXT.FUNC01] Guías de parametrización	[FUNC14] Plan de Pruebas Funcionales de los Circuitos. Registro de ejecución

[ACT-IMP-FUNC-2] PRO

Se incluyen en las actividades incluidas en este apartado todas las actividades de esta fase relacionadas con los entornos de PRO.

[ACT-IMP-FUNC-2.1] Parametrización de PRO

Procedemos en este bloque de actividades a parametrizar el entorno de producción al completo.

[ACT-IMP-FUNC-2.1.1] Parametrización conectividad de los entornos en PRO

En esta área habrán de realizarse las parametrizaciones del nuevo sistema, en el entorno de producción.

Basados en anteriores experiencias, como ya hemos comentado anteriormente para los entornos preproductivos, se propone llevar a cabo esta parametrización en dos fases.

Una primera en la que se realizará la parametrización de conectividad.
Una segunda fase en la que esta parametrización será completada con todos aquellos aspectos relacionados con las decisiones funcionales acordadas durante la fase de Reingeniería de Procesos.

Esta escisión, reportará como beneficio directo la optimización de los tiempos de ejecución del resto de actividades dependientes de estas, al facilitarles un sistema en el que es posible realizar los circuitos básicos.

Basado en esta estrategia surgen las dos actividades “[P-IMP-FUNC-2.1] Parametrización conectividad de los entornos en PRO” y “[P-IMP-FUNC-2.2] Trasladar parametrización funcional a PRO”.

En el caso de la presente, el objetivo como decimos es que el entorno sea operativo con las configuraciones y flujos acordados para el centro.

Por ello, para llevar a cabo esta actividad si es necesario disponer de la definición de la parametrización específica para el centro, debiendo disponer del entorno y de la documentación externa relativa a la parametrización de mismo.a la parametrización de mismo.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-PRE-SIST-7.3] Verificar entrega de los entornos para PRO
[ACT-IMP-FUNC-1.1.2] Testing scripts y herramientas de parametrización por lotes. Cálculo de tamaño de ventana de tiempo necesario

Catálogo de entregables

Entrada	Salida
[SIST11] Entornos de PRO [EXT.FUNC01] Guías de parametrización	--

[ACT-IMP-FUNC-2.1.2] Trasladar parametrización funcional a PRO

Una vez disponemos de un entorno ejecutable tras la parametrización de la conectividad llevada a cabo en la anterior actividad, deberemos pasar de un sistema que funciona a un sistema que se comporta con la idiosincrasia y características específicas que el centro demanda.

Es hora por tanto de llevar a cabo la parametrización funcional del mismo. Para ello, si será necesario disponer previamente de la parametrización y los valores acordados para cada elemento en función de los acuerdos funcionales aprobados para el centro.

Lo que haremos en este caso será trasladar sobre este entorno la parametrización ya llevada a cabo sobre los entornos preproductivos, y ya verificaos sobre estos.

Una vez realizadas la parametrización de conectividad y funcional, que previamente se ha probado ya en PRE en la ejecución de la actividad “[P

. Para ello, si será necesario disponer previamente de la parametrización y los valores acordados para cada elemento en función de los acuerdos funcionales aprobados para el centro.

Lo que haremos en este caso será trasladar sobre este entorno la parametrización ya llevada a cabo sobre los entornos preproductivos, y ya verificaos sobre estos.

Una vez realizadas la parametrización de conectividad y funcional, que previamente se ha probado ya en PRE en la ejecución de la actividad “[P-IMP-FUNC-1.4] Certificar los circuitos parametrizados en PRE”, tendremos un entorno parametrizado para producción al que solo faltará incorporar las modificaciones realizadas en PRE y recogidas en el entregable “FUNC17. Registro de modificaciones implementadas sobre Sistema Origen”.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Centro
Responsable TIC del centro	C
Referentes funcionales del centro	C
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-IMP-FUNC-2.1.1] Parametrización conectividad de los entornos en PRO
[ACT-IMP-FUNC-1.1.4] Parametrizar funcionalmente los entornos en PRE
[ACT-PRE-SIST-7.3] Verificar entrega de los entornos para PRO

Catálogo de entregables

Entrada	Salida
[SIST11] Entornos de PRO [EXT.FUNC01] Guías de parametrización	--

[ACT-IMP-FUNC-2.1.3] Trasladar modificaciones sobre el aplicativo en PRO

Una vez implementadas las modificaciones acordadas y al alcance del equipo de implantación sobre los entornos preproducitvos (actividad [ACT-IMP-FUNC-1.

4] Certificar los circuitos parametrizados en PRE”, tendremos un entorno parametrizado para producción al que solo faltará incorporar las modificaciones realizadas en PRE y recogidas en el entregable “FUNC17. Registro de modificaciones implementadas sobre Sistema Origen”.

3] Implementar modificaciones sobre el aplicativo en PRE”) y una vez certificada la va.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil funcional	R
Centro
Responsable TIC del centro	C I
Referentes funcionales del centro	C
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-IMP-FUNC-

2

1.1.

3

5]

Trasladar

Implementar modificaciones sobre el aplicativo en

PROUna vez implementadas las modificaciones acordadas y al alcance del equipo de implantación sobre los entornos preproducitvos (actividad

PRE

[ACT-

IMP

PRE-

FUNC

SIST-

1

7.3]

Implementar modificaciones sobre el aplicativo en PRE”) y una vez certificada la va.

Verificar entrega de los entornos para PRO

Catálogo de entregables

Entrada	Salida
[FUNC13] Registro de modificaciones implementadas [SIST11] Entornos de PRO [EXT.FUNC01] Guías de parametrización	--

[ACT-IMP-FUNC-3] Sistemas origen

Se incluyen en las actividades incluidas en este apartado todas las actividades de esta fase relacionadas con los entornos de los sistemas origen a sustituir durante el proces proceso de implantación.

[ACT-IMP-FUNC-3.1] Implementar modificaciones necesarias sobre sistema origen

Durante los procesos de sustitución de sistemas de información, en infinidad de situaciones es necesario mantener la convivencia entre el anterior sistema y el nuevo. Esta convivencia puede ir desde un escenario de total funcionamiento de los dos sistemas a un escenario en el que el anterior sistema queda activo para consultas solo en modo lectura.

La adecuación del antiguo sistema al nuevo escenario en el que tendrá que funcionar, supone en multitud de casos la necesidad de llevar a cabo adecuaciones y modificaciones sobre el mismo para permitir el funcionamiento del mismo en esta nueva etapa. Estas adecuaciones son recogidas durante el proceso “[P-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen”.

De igual forma, normalmente la implementación de mecanismos de extracción de datos que diferencien entre los bloques de información histórico y activa, supone la necesidad de implementar sobre el sistema origen en el que extraeremos los datos determinados cambios que permitan implementar la diferenciación de datos que marca esta política. Estos criterios se definen en el proceso “[P-PRE-MIGR-1] Establecer mecanismo diferenciación histórico vs activo”.

Por último, de la ejecución del proceso”[P-IMP-GEST-5] Definir e implementar el Plan de Transición“ puede surgir la necesidad de implementar determinados cambios en el sistema origen que faciliten el momento de transición del antiguo sistema al nuevo, generalmente durante la noche de arranque. Estos cambios a implementar, recogidos en el entregable “GEST12. Plan de Transición durante el Arranque” deberán ser tenidos en cuenta en este proceso para su implementación.

Es por ello, necesario, durante la fase de implantación, implementar una serie de cambios sobre el sistema origen, según se haya acordado durante el proceso “[Ppor ello, necesario, durante la fase de implantación, implementar una serie de cambios sobre el sistema origen, según se haya acordado durante el proceso “[P-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema origen”, el proceso “[P-PRE-MIGR-1] Establecer mecanismo diferenciación histórico vs activo” y el proceso “GEST12. Plan de Transición durante el Arranque”.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Perfil funcional	C
Centro
Responsable TIC del centro	A S
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	R

Dependencias

Actividad
[ACT-PRE-MIGR-1] Establecer mecanismo diferenciación activo vs pasivo
[ACT-IMP-GEST-5] Definir e implementar el Plan de Transición
[ACT-PRE-FUNC-6.1] Definir modificaciones necesarias sobre sistema

origen”, el proceso “[P-PRE-MIGR-1] Establecer mecanismo diferenciación histórico vs activo” y el proceso “GEST12. Plan de Transición durante el Arranque”.

origen

Catálogo de entregables

Entrada	Salida
[MIGR02] Definición Alcance de las Migraciones GEST12] Plan de Transición durante el Arranque [GEST19] Mecanismos de recogida de información para la Transición [FUNC17] Registro de modificaciones implementadas sobre Sistema Origen [FUNC06] Plan de Pruebas de los sistemas origen	--

[ACT-IMP-FUNC-3.2] Validar modificaciones necesarias sobre sistema origen

Todas las modificaciones llevadas a cabo sobre el sistema origen deberán ser validadas mediante la ejecución del Plan de pruebas correspondiente, dando como resultado un registro de la ejecución de dicho plan.

Este Plan de pruebas se nutre de los tres procesos anteriormente citados que son susceptibles de definir modificaciones sobre el sistema origen.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	I
Centro
Responsable TIC del centro	A
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	R

Dependencias

Actividad
[ACT-IMP-FUNC-3.

2

1]

Validar

Implementar modificaciones necesarias sobre sistema origen

Todas las modificaciones llevadas a cabo sobre el sistema origen deberán ser validadas mediante la ejecución del Plan de pruebas correspondiente, dando como resultado un registro de la ejecución de dicho plan.

Este Plan de pruebas se nutre de los tres procesos anteriormente citados que son susceptibles de definir modificaciones sobre el sistema origen.

[ACT-PRE-FUNC-6.2] Definir Plan de pruebas sobre sistemas origen

Catálogo de entregables

Entrada	Salida
[FUNC06] Plan de Pruebas de los sistemas origen	[FUNC16] Plan de Pruebas de los sistemas origen. Registro de ejecución

Área Formación

[ACT-IMP-FORM-1] Impartir sesiones de formación

...

Durante esta fase además se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, 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 hospital 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 hospital 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.y facilitando la necesaria autonomía de los usuarios y del hospital 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
Referentes funcionales del centro	I
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-PRE-FORM-3] Validar Plan de formación
[ACT-IMP-FUNC-1.2] Certificar los circuitos parametrizados en PRE

Catálogo de entregables

Entrada	Salida
[FORM03] Plan de formación [EXT.FORM01] Manuales de usuario EXT.FORM02] Guías rápidas de procesos [EXT.FORM03] Modelo de datos y cambios	[FORM01] Registro de asistencia [FORM02] Encuesta de satisfacción

[ACT-IMP-FORM-1.2] Impartir sesiones de formación a usuarios finales

...

Durante esta fase además se seguirá profundizando en Transferir el Conocimiento a los usuarios expertos de referencia, 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 hospital 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 hospital 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.de los usuarios y del hospital 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	I
Perfil de formación	S
Centro
Responsable TIC del centro	A
Responsable de cartera y servicios en el centro	I
Referentes funcionales del centro	R
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-PRE-FORM-3] Validar Plan de formación
[ACT-IMP-FUNC-1.2] Certificar los circuitos parametrizados en PRE

Catálogo de entregables

Entrada	Salida
[FORM03] Plan de formación [EXT.FORM01] Manuales de usuario EXT.FORM02] Guías rápidas de procesos [EXT.FORM03] Modelo de datos y cambios	[FORM01] Registro de asistencia [FORM02] Encuesta de satisfacción

[ACT-IMP-FORM-1.3] Semana de contingencia

Es importante dejar planificada una reserva de tiempo de entre 1 y 2 semanas antes del arranque sin planificación prevista de formación debido a que en los últimos días antes del arranque suele ser habitual que deba dirigirse el esfuerzo en otro tipo de actividades.También suele ser habitual que sea necesario planificar alguna sesión adicional de formación no prevista inicialmente. Utilizaremos esta semana, si no hay otra opción, para este tipo de imprevistos.suele ser habitual que deba dirigirse el esfuerzo en otro tipo de actividades.

También suele ser habitual que sea necesario planificar alguna sesión adicional de formación no prevista inicialmente. Utilizaremos esta semana, si no hay otra opción, para este tipo de imprevistos.

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
Responsable de cartera y servicios en el centro	I
Referentes funcionales del centro	I
Proveedores de soporte N3
Soporte N3 del producto a implantar	C

Dependencias

Actividad
[ACT-PRE-FORM-3] Validar Plan de formación
[ACT-IMP-FUNC-1.2] Certificar los circuitos parametrizados en PRE

Catálogo de entregables

Entrada	Salida
[FORM03] Plan de formación [EXT.FORM01] Manuales de usuario EXT.FORM02] Guías rápidas de procesos [EXT.FORM03] Modelo de datos y cambios	[FORM01] Registro de asistencia [FORM02] Encuesta de satisfacción

[ACT-IMP-FORM-2] Generar Informe final actividades de formación

Una vez finalizadas las sesiones de formación, el equipo de implantación deberá generar un Informe final con el resumen y la información de interés relativa al impacto y efectividad de dichas sesiones para que el centro pueda valorar la ejecución de la misma, así como la potenciar si lo estima oportuno aquellas áreas o aspectos que hayan tenido un peor resultado con la formación planificada.

Este informe contendrá al menos y entre otras, la siguiente información:

...

con la formación planificada.

Este informe contendrá al menos y entre otras, la siguiente información:

Número de sesiones de formación impartidas
Número de usuarios convocados por perfil
Número de usuarios por perfil que asisten y son formados
% de usuarios formados
Total de horas de formación impartidas
Puntuación media en las encuestas de satisfacción en cada una de las unidades didácticas.
Puntuación media en las encuestas de satisfacción para cada uno de los formadores.

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
STIC
Jefe de proyecto de la STIC	I

Dependencias

Actividad
[ACT-PRE-FORM-4] TC > formación a responsables TIC del centro / cges
[ACT-IMP-FORM-1.1] Impartir sesiones de formación a Formadores

Catálogo de entregables

Entrada	Salida
[FORM01] Registro de asistencia [FORM02] Encuesta de satisfacción	[FORM05] Informe final Actividades de Formación

...

Área de Migración

[ACT-IMP-MIGR-1] Validar el proceso de migración (catas) en PRE

...

Para evitar este riesgo es por lo que en lugar de utilizar el juego completo de datos se utiliza una cata especialmente seleccionada. Esto permite que la extracción de datos del sistema origen no se demore en exceso, y que sea viable repetir el proceso de extracción de datos cuantas veces sea posible hasta afinar y validar el proceso completo de migración de datos.el proceso completo de migración de datos.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil de migración	C I
Centro
Responsable TIC del centro	I
Referentes funcionales del centro	C
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	S

Dependencias

Actividad
[ACT-PRE-MIGR-3] Verificar procesos de extracción y transformación de datos
[ACT-PRE-MIGR-4] Establecer subconjunto de datos para las pruebas de migración unitarias

Catálogo de entregables

Entrada	Salida
[MIGR03] Procesos de extracción y transformación de datos [MIGR02] Definición Alcance de las Migraciones	[MIGR06.x] Datos para migración. Catas

[ACT-IMP-MIGR-1.2] Validar los ficheros o soportes de datos obtenidos

...

Para ello, contrastará la información contenida en dichos soportes con la información original existente en el sistema origen.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Perfil de migración	C I
Centro
Responsable TIC del centro	A
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	R

Dependencias

Actividad
[ACT-IMP-MIGR-1.1] Extraer y transformar los datos para las catas

Catálogo de entregables

Entrada	Salida
[MIGR06.x] Datos para migración. Catas	[MIGR06.x] Datos para migración. Catas

[ACT-IMP-MIGR-1.3] Cargar los datos activos en PRE

Una vez los ficheros han sido extraídos y validados por el proveedor, el equipo de implantación procederá a su carga en el entorno preproductivo del nuevo sistema de información, haciendo uso para ello de las herramientas de migración proporcionadas por el fabricante, así como de las guías y manuales de migración correspondientes.sistema de información, haciendo uso para ello de las herramientas de migración proporcionadas por el fabricante, así como de las guías y manuales de migración correspondientes.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil de migración	C
Centro
Responsable TIC del centro	I
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	C I

Dependencias

Actividad
[ACT-IMP-MIGR-1.2] Validar los ficheros o soportes de datos obtenidos
[ACT-PRE-SIST-5.3] Verificar entrega de los entornos para PRE

Catálogo de entregables

Entrada	Salida
[MIGR06.x] Datos para migración. Catas [SIST10] Entornos de PRE [EXT.MIGR01] Guía de migración [EXT.MIGR02] Definición del Alcance de las Migraciones [EXT.MIGR03] Herramienta Migrador	--

[ACT-IMP-MIGR-1.4] Ejecutar el Plan de Pruebas de migración Cualitativas

...

Este plan de prueba, debe ser ejecutado por personal de referencia funcional en el centro para verificar la validez de los procesos de migración.Una vez el proceso es validado cualitativa y cuantitativamente mediante la validación de catas, se procederá a la migración de datos históricos en su totalidad, y no antes.la validez de los procesos de migración.

Una vez el proceso es validado cualitativa y cuantitativamente mediante la validación de catas, se procederá a la migración de datos históricos en su totalidad, y no antes.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	C I
Perfil funcional	S
Perfil de migración	C I
Centro
Responsable TIC del centro	A
Responsables funcionales del centro	R
STIC
Jefe de proyecto de la STIC	I
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	C I

Dependencias

Actividad
[ACT-IMP-MIGR-1.3] Cargar los datos activos en PRE
[ACT-RP-MIGR-3] Definir Plan de Pruebas de migración Cualitativas (catas)

Catálogo de entregables

Entrada	Salida
[MIGR04] Plan de pruebas de migración Cualitativas [EXT.MIGR01] Guía de migración [EXT.MIGR02] Definición del Alcance de las Migraciones [EXT.MIGR03] Herramienta Migrador	[MIGR09] Plan de pruebas de migración cualitativas. Registro de ejecución

[ACT-IMP-MIGR-1.5] Ejecutar el Plan de Pruebas de migración cuantitativas

...

Una vez el proceso es validado cualitativa y cuantitativamente mediante la validación de catas, se procederá a la migración de datos históricos en su totalidad, y no antes.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	A
Perfil de migración	C
Centro
Responsable TIC del centro	I
Responsables funcionales del centro	S
STIC
Jefe de proyecto de la STIC	I
Proveedores de soporte N3
Soporte N3 del producto existente a sustituir	C I

Dependencias

Actividad
[ACT-RP-MIGR-4] Definir Plan de Pruebas de migración Cuantitativas
[ACT-IMP-MIGR-1.3] Cargar los datos activos en PRE

Catálogo de entregables

Entrada	Salida
[MIGR05] Plan de pruebas de migración Cuantitativas [EXT.MIGR01] Guía de migración [EXT.MIGR02] Definición del Alcance de las Migraciones [EXT.MIGR03] Herramienta Migrador	[MIGR10.x] Plan de pruebas de migración cuantitativas. Registro de ejecución

[ACT-IMP-MIGR-3] Simulación migración en PRO

...

Sistemas sigue durante toda la fase de consolidación monitorizando de los sistemas de manera que todos los sistemas de vigilancia y control estén arriba y alerta para la detección de posibles problemas de rendimiento, calidad en las comunicaciones o procesado de información, etc.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	I
Perfil de integración	S
Centro
Responsable TIC del centro	I

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	--

Área de Gestión

[ACT-CON-GEST-1] Dar seguimiento y Control a los trabajos del Proyecto

Al igual que en la fase de preimplantación, O implantación, en esta fase continuaremos de forma periódica con las reuniones de seguimiento en el ámbito del centro, cuyo objetivo serán reportar a los responsables del mismo y de la STIC el grado de avance en estas tareas y alertar sobre aquellos puntos que supongan un riesgo global para la finalización de la fase.

Sin embargo, durante esta fase, dada la importancia de contar con información de estado de situación de forma rápida y continua, estas acciones de seguimiento y control se deberán intensificar, de forma que sobre todo los primeros días, estas reuniones deberán convertirse en sesiones de kick-off diarios donde podamos reportar al centro la situación a comienzo del día y las acciones que es necesario llevar a cabo por todos os involucrados para reorientar aquellos elementos que durante la jornada anterior se hubiera llegado a la conclusión que era necesario mejorar o corregir.

Matriz RASCI

Perfil	Responsabilidad
Equipo de implantación
Jefe de equipo de implantación	R
Perfil funcional	C
Perfil de formación	C
Perfil de migración	C
Perfil de integración	C
Centro
Responsable TIC del centro	C I
Responsable de cartera y servicios en el centro	C
Referentes funcionales del centro	I
STIC
Jefe de proyecto de la STIC	A S
Responsables funcionales	C
Proveedores de soporte N3
Soporte N3 del producto a implantar	C
Soporte N3 del producto a sustituir	C
Soporte N3 de sistemas terceros o departamentales afectados	C

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	[GEST08.x] Informes de seguimiento y control [GEST10.x] Catálogo de Solicitudes de Cambio

[ACT-CON-GEST-2] Informes cuantitativos de actividad

En los primeros días tras el arranque, el objetivo principal del equipo de implantación estará centrado en conseguir que los usuarios comiencen a utilizar los nuevos sistemas de información. Problemas frecuentes en este momento son todos los relacionados con falta de credenciales para los usuarios, reticencia al cambio, etc.

Para cuantificar el nivel de consolidación a este respecto, deberá analizarse diariamente un catálogo de indicadores encaminados a cuantificar el nivel de uso. Los siguientes son ejemplo de indicadores posibles, si bien estos dependen directamente del negocio involucrado:

Nº de usuarios logados. Como comentamos, los primeros problemas suelen estar relacionados con las credenciales de acceso de los usuarios (olvido de contraseñas, usuario bloqueado por reintentos, etc.). Medir el nº de usuarios logados a diario y contrastarlo con los datos obtenidos durante el funcionamiento normal del hospital nos dará un conocimiento amplio sobre el nivel de utilización de la herramienta por los usuarios de los diferentes servicios. Se deberá ofrecer igualmente un estudio pormenorizado por servicio o colectivo para facilitar la detección de posibles focos de reticencia al cambio. Dirección podrá de esta forma acordar medidas de refuerzo específicas que se unirán al refuerzo de las actividades de soporte por parte de los tutores (del equipo de implantación y del centro).
Nº acciones de las tipologías principales (ingresos, actualización de expedientes, creación de nóminas, registro de bajas, etc). En general todos aquellos elementos que puedan ser cuantificables y que nos puedan dar el orden de utilización de las nuevas herramientas en los puntos considerados críticos para el funcionamiento de los centros involucrados en la implantación. Ejemplos de algunos ámbitos funcionales son:
- Nº de movimientos historia. Archivo es uno de los puntos clave de cuyo buen funcionamiento depende en cascada el funcionamiento de otras áreas de los centros hospitalaria.. Es por ello importante detectar posibles focos de riesgo lo antes posible. Un buen indicador sobre el funcionamiento básico de un archivo es el número de movimientos de historia que se llevan a cabo durante la jornada, comparando este dato con los obtenidos previamente durante el funcionamiento normal del hospital y los obtenidos durante los anteriores días de consolidación.
- Nº de ingresos. Al igual que archivo, admisión es otro de los puntos clave a monitorizar. En este caso, un buen indicador sobre el nivel de uso de las aplicaciones asistenciales en este servicio es el relacionado con el conteo de ingresos o de altas. Consideramos el primero en este caso, dado que marca igualmente el inicio del proceso sobre el paciente en el resto del servicio. Si los datos obtenidos no se ajustan a los esperados se procedería a reforzar el tutelado insitu en este servicio.
- Nº de intervenciones programadas. Mide el grado de utilización de los sistemas de información en los servicios de Planificación y programación quirúrgica, por lo que un número bajo de intervenciones programadas respecto a la media normal diaria del hospital puede ser un síntoma de problema a la hora de comenzar a utilizar el nuevo sistema.
- Nº de hojas de anamnesis y Nº de informes de alta creados. Estos dos indicadores por su parte verifican cuantitativamente el nivel de uso por parte de determinados colectivos, por lo que su análisis nos ofrecerá un conocimiento amplio sobre el nivel de utilización de la herramienta por los estos en las diferentes área del centro.
- Nº de informe radiológicos generados. Con respecto a la medida por centro o servicio.
- Nº de vacunas suministradas o registradas.
- Nº de incidencias registradas y gestionadas en los sistemas de gestión de profesionales,
- Etc

A partir de todos los indicadores elegidos y acordados se puede obtener una visualización detallada del nivel de uso de los sistemas de información en los diferentes puntos involucrados de los centros, permitiendo la redistribución de tutores de soporte N0 en los puntos más conflictivos, y facilitando la aplicación de medidas paliativas por parte de la dirección del centro.

Matriz RASCI

Perfil	Responsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	--

[ACT-CON-GEST-3] Informes Cualitativos de actividad

A medida que el nivel cuantitativo de utilización de los sistemas de información en los puntos calientes del centro se vaya acercando a la normalidad, iremos centrando el análisis y los esfuerzos de soporte en conseguir que la utilización que de esta herramienta sea de calidad y conforme a los procesos acordados durante la fase de Reingeniería de Procesos.

Para ello, comenzarán a analizarse, junto a los anteriores, una serie de indicadores encaminados a detectar malas praxis y errores frecuentes en el uso de los sistemas de información.

Nos centramos ya por tanto no solo en el uso de la aplicación mediante un control numérico sino en un uso correcto de la misma mediante un control de calidad del uso.

Estos indicadores dependen fuertemente del negocio involucrado en el proceso de implantación. A modo de ejemplo, planteamos una serie de indicadores del ámbito asistencial hospitalario:

Nº de ingresos anulados.
- Un número elevado de ingresos anulados suele ser consecuencia de problemas en la gestión del ingreso de los usuarios en Admisión.
- Por otro lado, la ausencia total de ingresos anulados indica igualmente que no se ha puesto en práctica este mecanismo para la resolución de los errores que se hayan podido producir, y que en su lugar, se puede estar procediendo a mantener el episodio dándole el alta al usuario, incluyendo así un episodio ficticio con información errónea a este.
Nº de preingresos ni anulados ni ingresados.
- Preingresos a pasado que no hayan sido ni finalmente ingresados ni anulados carecen de sentido.
- Es información obsoleta que debe ser revisada de forma diaria.
- Por otro lado, la existencia de un gran número de preingresos ni anulados ni ingresados suele indicar un uso incorrecto del circuito de ingreso desde preingreso.
- Este circuito es típico para los ingresos para actividad quirúrgica programada, y los ingresos a hospitalización provenientes de urgencias.
- En ambos casos, se generan preingresos para el usuario que deben ser localizados e ingresados, manteniendo así la trazabilidad entre las listas de espera y los episodios de hospitalización en el primer caso, y entre los episodios de urgencias y hospitalización en el segundo.
- Un análisis de este indicador por tanto, nos permitirá la corrección de estos aspectos.
Nº Informes de alta.
- En relación a los informes de alta suelen ocurrir dos tipos de errores frecuentes.
- El primero está relacionado con la administración del Alta administrativa al paciente sin acompañarse por el informe de alta médico y el informe de alta de enfermería.
- El segundo tiene relación con el concepto alta y el concepto traslado.
- Tradicionalmente, el cambio de servicio para un paciente se ha modelado con un Alta del servicio con destino a otro servicio.
- En los nuevos sistemas este aspecto se denomina traslado.
- Suele ser frecuente la confusión entre ambos términos y la generación de un informe de alta sobre un paciente para definir un cambio de servicio cuando en su lugar habría de haber definido un Informe de Traslado.
- Este hecho más allá del error conceptual, supone una fuente de problemas debido a que sobre un episodio de hospitalización en los sistemas de información es posible definir más de un informe de Traslado, pero solo es posible definir un único informe de alta, que corresponderá al momento en el que el paciente abandona el hospital.
- Si en un cambio de servicio, el facultativo definió un informe de alta, en el momento real de alta hospitalaria, no será posible generar un nuevo informe de alta.
- A este respecto, existen medios para facilitar el desbloqueo de esta situación y serán aplicadas en todos los casos que se produzcan. Sin embargo, su prevención evitará bloqueos en el circuito de alta de un paciente.
Nº de hojas de traslado.
- Este indicador tiene relación con el anterior, y nos dará información relativa a qué determinados servicios no han asimilado convenientemente este concepto en detrimento del concepto de alta entre servicios.
- Para ello, contrastaremos la información obtenida respecto al número de hojas de traslado por servicio respecto a los datos obtenidos con anterioridad durante el funcionamiento normal del hospital.
Nº de hojas quirúrgicas provisionales (no firmadas como definitivas).
- La hoja de registro de actividad quirúrgica permite el registro de la actividad manteniendo la misma en estado provisional para facilitar la coordinación en la cumplimentación de la misma por los facultativos y el personal de enfermería.
- Parte de esta coordinación ha de implicar la firma de la hoja quirúrgica como definitiva, siendo este hito muy importante de cara al circuito de gestión de esta intervención en los sistemas de gestión de listas de espera.
- Cuando una hoja quirúrgica es firmada como definitiva, lanza un proceso automático de baja en la lista de espera, facilitando esta tarea de forma que se gestionen correctamente los tiempos medios de espera en el hospital.
- Sin embargo, si la hoja quirúrgica se queda en estado provisional, como tal, no causa baja en la lista de espera al no estar finalizada.
- Este hecho puede suponer un repunte no real del tiempo de demora en las intervenciones, incurriendo en un incumplimiento de la Ley de Garantía que en realidad no se produjo.
Nº de ingresos por tipo de financiación.
- Otro error que suele ser recurrente es el relacionado con el tipo de financiación en los episodios de hospitalización.
- En este aspecto, en bastantes ocasiones ocurre que los usuarios suelen especificar de forma generalizada el tipo de financiación “Sistema Andaluz de Salud”, independientemente de que el paciente provenga de una aseguradora privada, o se trate de un paciente que proviene de urgencias donde fue hospitalizado por un accidente de tráfico.
- Este tipo de error no está vinculado al cambio de herramienta y suele darse con antelación al proceso de implantación.
- En el alcance de este proyecto analizaremos el % de ingresos asignados a este tipo de financiación y lo compararemos con los datos previamente obtenidos durante el funcionamiento normal del centro con el antiguo sistema de información.
- Incidiremos en todo caso en la importancia de recoger bien esta información en los ingresos aunque se trate de un error previo, para intentar mejorar este dato con la entrada del nuevo sistema de información.
Nº de altas administrativas vs altas médicas.
- Comprobaremos que todas las altas administrativas tengan su correspondiente informe de alta médico.
- Ratio de cumplimentación de Informes de Alta médico.
- Contrastaremos el % obtenido frente a la media normal del hospital.
Recién nacidos ingresados cuya madre ha sido dada de alta.
- En función de la parametrización elegida por el centro, al recién nacido no patológico se le dará el alta automáticamente cuando se dé el alta a la madre, o habrá que dársela de forma manual.
- En esta segunda opción, suelen darse casos en los que la madre obtiene su alta médica y administrativa, se va a casa con el recién nacido, y sin embargo, este no tiene alta ni médica ni administrativa.
- Este hecho se deriva de la asimilación conceptual de que un recién nacido en el momento en el que nace, es ingresado en el centro con origen “recién nacido”, tanto si se trata de un niño patológico, como si es no patológico.
Nº de partes abiertos con posterioridad a la fecha de inicio del parte.
- Como parte del circuito de programación quirúrgica, es necesario que los partes de quirófano sean “cerrados” con anterioridad a la fecha de intervención (existe un proceso automático que los cierra, pero el usuario puede revertir esta acción dejándolos abiertos).
- El evento de cierre del parte lanza el proceso de generación de hoja quirúrgica previamente cumplimentada con los datos de AGD y asociadas al episodio del paciente.
- Si el parte no es cerrado, la hoja no es creada automáticamente como una hoja de intervención programada, y solo nos quedará como opción generar una nueva hoja quirúrgica, que al no estar vinculada a una programación quirúrgica, será entendida a todos los efectos como una intervención urgente, con la distorsión correspondiente en el análisis de actividad del hospital.
- Por ello, monitorizaremos que el circuito quirúrgico es implementado correctamente y es entendida la importancia de los procesos involucrados.
Pacientes con hoja quirúrgica proveniente de programación en estado provisional que nunca se ha utilizado.
- Otra casuística que puede llegar a darse y que es necesario monitorizar para corregirla de forma temprana es la creación masiva de hojas quirúrgicas urgentes para registrar la actividad quirúrgica en lugar de utilizar la correspondiente hoja quirúrgica programada que ya debe existir en el episodio del paciente en el momento de su entrada a quirófano.
- Como en el caso anterior, este error distorsiona las estadísticas del centro en relación a la tasa de intervenciones urgentes frente a las programadas.
Duplicidad de hojas de quirófano para una misma intervención.
- Relacionado con los dos casos anteriores, puede ocurrir que determinados usuarios procedan a generar una nueva hoja quirúrgica (urgente) en lugar de la existente (programada) en el episodio del paciente, distorsionando en doble medida las estadísticas del centro y la historia clínica del paciente, ya que no solo se registra la intervención como urgente en lugar de como programada, sino que se duplica el número de hojas quirúrgicas, y si esta es la base para cálculos de indicadores, podremos obtener resultados más elevados de lo previsto debido a esta duplicidad.
Ingresos en hospital de día médico sin fecha de alta o con duración mayor a 24 horas.
- Por definición un ingreso en la modalidad hospital de día tiene que tener ingreso y alta en el mismo día.
- Por tanto todos aquellos episodios de esta tipología de duración mayor a 24 horas incluyen un error que se trasladará a las estadísticas del centro, CMBD, etc.
- Suele darse este tipo de error cuando las altas se registran al siguiente día a primera hora de la mañana. Se monitorizará este caso como todos los anteriores para mitigar su aparición e incidir en los flujos correctos.

La revisión de todos estos indicadores nos permitirá consolidar la calidad de los procesos ejecutados sobre el nuevo sistema de información conforme a los criterios acordados en la fase de Reingeniería de Procesos, monitorizando aquellas casuísticas que se detecten erróneas y facilitando a Dirección herramientas para su detección y mitigación.

Matriz RASCI

Perfil	Responsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	--

[ACT-CON-GEST-4] Soporte a usuarios finales

Durante esta fase posterior al arranque el objetivo fundamental es conseguir, en el menor tiempo posible, que el centro trabaje de la forma más fluida posible con los nuevos sistemas.

Para ello es clave en esta actividad de soporte a usuarios finales el papel de los tutores del equipo de implantación ( tutor n0) y de los usuarios expertos del centro que participarán en el tutelado insitu ( referentes n0). Esta figura perteneciente al centro asentará durante estas fases el conocimiento adquirido durante todo el proceso de Transferencia del Conocimiento iniciado en la fase de Reingeniería de Procesos.

Los equipos de soporte n0 serán equipos mixtos compuestos por:

Un tutor n0 del equipo de implantación y
El usuario referente n0 vinculado al punto de soporte correspondiente.

Ante una consulta de un profesional o una incidencia a resolver, esta será resuelta por el tutor del equipo de implantación, quien estará en contacto en todo momento por el usuario referente del hospital correspondiente (presencialmente, telefónicamente o según el modelo recogido en la relación con el proveedor). Conseguimos así que este usuario referente del hospital conozca la información relacionada con la resolución de la duda o de la incidencia y vaya centralizando actuación tras actuación todo el conocimiento necesario para tutelar al resto de compañeros a la salida del equipo de implantación del centro.

El soporte durante esta fase debe ser 24x7, siendo recomendada la presencia in-situ en el puesto del usuario para reforzar en todo lo posible el aprendizaje de las funcionalidades que le afecten.

Existirán durante esta fase determinadas ubicaciones clave en el hospital, acordadas en el Plan de Arranque, donde se prestará especial atención a las actividades de soporte. Será en estos puntos, donde los equipos mixtos de soporte n0 deben prestar un servicio más relevante.

En este periodo igualmente, se debe disponer de soporte n3 prioritario de los proveedores de los diferentes sistemas afectados, de manera que la resolución del volumen inicial de incidencias que suelen registrarse en los momentos iniciales sea estabilizado lo más rápidamente posible.

La organización del soporte vendrá definido en el entregable Plan de soporte definido en la fase de implantación durante la definición del Plan de Arranque, que como ya comentabamos en dicha actividad, Tiene las siguientes características:

Plan de soporte.
- Para su elaboración, se hará un análisis de los puntos calientes para el arranque. Es decir, aquellos puntos en los que es crítico minimizar el impacto y reforzar el soporte para que el proceso de adaptación al nuevo sistema sea rápido y eficaz, y el resto de áreas funcionales del hospital no sufran efectos colaterales adversos relacionados con estos.
- El soporte se organizará en torno a la elección de estos puntos, en los que se hará especial seguimiento al soporte.
- Estos puntos calientes estarán definidos y descritos en el Plan de Arranque.
- El plan de soporte consta de dos matrices relativas a la estructuración del soporte una vez se finalice la fase de arranque.
- Una primera matriz con el nivel de soporte que se acuerde para cada punto caliente en cada día y en cada turno. Define igualmente los turnos de soporte que se van a gestionar.
  - Incluye por tanto la siguiente tupla:
    - Centro.
    - Punto caliente.
    - Día.
    - Turno.
    - Nivel de soporte.
- Una segunda matriz, definirá para los valores definidos en la primera, quién será el recurso del equipo de implantación (soporte n0) y quien será el recurso del centro (tutor n0) que darán cobertura a dicho punto caliente en dicho turno.
- De cada uno de los recursos aquí incluidos este documento debe reflejar:
  - Nombre y apellidos.
  - Rol.
  - Teléfono de contacto.
  - Correo.
  - DNI (para la gestión del acceso a las zonas restringidas del centro).
  - Empresa.

Matriz RASCI

Perfil	Responsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	--

[ACT-CON-GEST-5] Corrección de incidencias in stiu

Fruto de estas actividades de soporte y del comienzo de la utilización de nuevas herramientas, se incrementará durante los primeros días el número de incidencias y consultas por dudas funcionales que trasladen los usuarios finales hacia el servicio de soporte. Es por ello que durante la fase de consolidación, la parte del equipo de implantación que se dedique a soporte n2 deberá atender de forma ágil y cercana estas incidencias y consultas para aportar en aras de la normalización del hospital en el menor tiempo posible.

De igual forma, en este periodo igualmente, se debe disponer de soporte n3 prioritario de los proveedores de los diferentes sistemas afectados, de manera que la resolución del volumen inicial de incidencias que suelen registrarse en los momentos iniciales sea estabilizado como decimos lo más rápidamente posible.

Matriz RASCI

Perfil	Responsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	--

Ancla
FaseEXT
FaseEXT
Extensión

...

Configuración de elementos de listados adicionales
Configuración de elementos de explotación de datos.
Parametrización y puesta en marcha de circuitos funcionales secundarios.
Etc.

Matriz RASCI

Perfil	Responsabilidad
--

Dependencias

Actividad
--

Catálogo de entregables

Entrada	Salida
--	--