Introducción
El siguiente ejemplo es una versión simplificada del proceso Sala de Emergencias, en el cual se analizarán diversas situaciones que se presentan cuando ingresa un paciente con una condición particular y cómo las personas que se encuentran involucradas en el caso de dicho paciente, tienen como objetivo, mejorar su estado de salud. Este proceso no considera la admisión de cualquier persona en el hospital. Dicha situación se manejaría enviando al paciente en una ambulancia a otra clínica.
Alcance: El proceso inicia cuando un paciente ingresa a la Sala de Emergencias, y finaliza cuando se efectúa el tratamiento que curará al paciente.
El proceso de Sala de Emergencias representa un ejemplo del uso de las funcionalidades y opciones de Bizagi 11, tomando ventaja del concepto Diseño de Experiencia en el manejo de procesos no estructurados.
Los procesos no estructurados son aquellos que se pueden catalogar como impredecibles o dinámicos, principalmente, porque estos procesos involucran, en algún punto, un gran número de posibles alternativas de flujo de trabajo.
De igual manera, representa cómo los Stakeholders (trabajadores del conocimiento) pueden tomar decisiones que definen el flujo de cada caso, el cual no puede ser previsto con anterioridad.
El alcance de un caso del proceso Sala de Emergencias es la atención de un paciente.
A través del Diseño de Experiencia usted podrá aprovechar el empoderamiento de los trabajadores del conocimiento, presentando una experiencia personalizada, la cual utiliza las capacidades de BPM, entre otros.
Nota: este no es un proceso de Sala de Emergencias completo, se requeriría definiciones extensivas adicionales.
Descripción del Proceso en Bizagi Modeler (Bpm)
La documentación completa de este proceso se puede encontrar dentro de su archivo de Bizagi Modeler (.bpm). Desde allí, se puede generar un documento de Word con toda su información.
Identificar el proceso general y sus hitos
Identificar el proceso general, o la ruta feliz, que proporciona un alto nivel de la descripción del negocio a automatizar y de igual manera, identifica los resultados comunes (en la primera etapa sin incluir excepciones) y las etapas para el caso o sus hitos.
Los hitos del proceso de Sala de Emergencias de Bizagi son:
-Registro y Triage
-Exámenes
-Tests
-Tratamiento
-Transferencia del paciente a cirugía
No todos los hitos culminan en un caso particular. De hecho, varios de ellos son exclusivos. Algunos pueden ser revocables: incluso cuando el hito ha sido alcanzado, el Stakeholder del caso como segunda opción, puede decidir si finalmente se alcanza o no.
Stakeholders
Bizagi 11 presenta un Portal de trabajo que permite a los trabajadores del conocimiento tomar decisiones informadas, tales como, cuándo iniciar un proceso o cuándo actualizar datos, de manera que se impulse la agilidad y la productividad en la organización.
Varios Stakeholders pueden estar asociados con un caso. Sin embargo, cada Stakeholder deberá influenciar dicho caso directa o indirectamente. No todos los Stakeholders que han sido mencionados deben estar involucrados en cualquier instancia del caso.
Para personalizar su experiencia es importante que identifique sus Stakeholders.
-Médico(a)
-Enfermero(a)
-
Stakeholders Externos (usualmente son evaluados para ser incluidos o no, como parte de la automatización).
-Paciente
Diseño de Experiencia
En Bizagi Studio cada Stakeholder tiene su propia experiencia diseñada en el menú Diseño de Experiencia. Cada pestaña, (Acciones, Mis Cosas, Búsqueda) tiene una definición, de acuerdo a las opciones disponibles para cada usuario.
Tenga en cuenta que para habilitar un grupo que estará disponible en la sección de Mis Cosas, el Stakeholder debe tener una colección bien sea directa o indirecta a una entidad.
Por lo tanto, el enfemero(a), por ejemplo, tiene una colección a la entidad Medical Equipment. De esta manera, cada enfemero(a) será propietario de uno o varios equipos médicos, y podrá verlos en el Portal de Trabajo, y administrarlos si existen acciones disponibles para ello.
Diseño de experiencia del Enfermero(a)
Gestionar los Stakeholders
Tan pronto descargue esta plantilla, asegúrese de haber creado y configurado al menos un usuario por Stakeholder en la opción Admin en el Portal de Trabajo. Si usted no tiene un usuario por Stakeholder, esta plantilla no funcionará adecuadamente.
Diríjase a la opción Admin y para cada Stakeholder, establezca un Nuevo registro, creando un Nuevo usuario, e ingrese toda la información adicional requerida.
Tenga en cuenta que la administración de Stakeholders en el Portal de Trabajo ha sido definida previamente en la configuración de formas. Dichas formas mostrarán qué información será mostrada y requerida cuando se esté configurando un usuario como un Stakeholder.
En Studio se ha definido una forma para mostrar, en la cual se representan las columnas de la vista principal del Stakeholder.
De igual manera, se ha añadido una forma de edición que se refiere a la manera cómo se añade y se edita un registro de un Stakeholder.
Identificar actividades, ¿Qué pueden hacer los Stakeholders?
Representa aquellas actividades y otras operaciones relacionadas que pueden iniciar y ejecutar los Stakeholders, categorizando las interacciones permitidas en el Portal de trabajo habilitadas para cada uno de los Stakeholders.
Se debe definir si las actividades son obligatorias sobre cierta circunstancia o, si están disponibles, pero son ejecutadas según el criterio de elección de cada Stakeholder; lo cual ayudará a categorizar una actividad como una acción disponible como parte de un proceso no estructurado.
En un caso, muchas de las actividades no están siempre disponibles para ser ejecutadas. Sólo cuando ciertos hitos son culminados en dicho caso, o se cumplen ciertas condiciones específicas, se podrá ejecutar la actividad.
Las actividades pueden ser retiradas cuando pierdan su nivel de relevancia y no deben ser presentadas a los Stakeholders.
Stakeholder |
Descripción de la actividad |
¿Cuándo será ejecutada la acción/actividad? |
Comentarios |
|---|---|---|---|
Enfermero |
Registro del paciente y comienzo del Triage |
Cuando se encuentre en turno, y llegue un paciente. |
El enfermero(a) busca el paciente y luego, incluye la fecha y la hora de su llegada |
Escoger la categoría del Triage |
Cuando se ejecute un Triage |
||
Enviar el paciente a cirugía |
Cuando se ejecute un Triage |
||
Actualizar la información del paciente |
En cualquier momento |
||
Realizar el monitoreo de salud |
En turnos nocturnos |
||
Ver/ Administrar equipos médicos |
En cualquier momento |
||
Médico |
Examinar pacientes: Muy urgente, urgente y básico |
Cuando los pacientes están esperando en la sala respectiva. Y el médico es quien los atiende |
|
Solicitar examines de laboratorio o de radiología |
Cuando se estén examinando los pacientes |
||
Revisar los resultados de los exámenes |
Cuando los pacientes han sido enviados para los exámenes |
||
Tomar una muestra de sangre |
|||
Ejecutar un procedimiento de radiología |
|||
Enviar a cirugía |
Cuando se estén examinando los pacientes y revisando los exámenes |
||
Ver equipo médico |
En cualquier momento |
||
Enviar equipo médico a reparación |
En cualquier momento |
||
Paciente |
Ver Exámenes, Triage y Médicos |
En cualquier momento |
|
Buscar Médicos |
En cualquier momento |
||
Identificar Acciones, Actividades, Contextos y Datos
Enfermero(a)
Descripción de la actividad |
Contexto |
Disponibilidad |
|
|---|---|---|---|
Registro del paciente y comienzo del Triage |
Cuando se encuentra en turno e ingresa un paciente |
A través del campo de Búsqueda, Siempre disponible |
|
Escoger la categoría del Triage |
Cuando se ejecute un Triage |
Obligatorio |
|
Enviar paciente a cirugía |
Cuando se ejecute un Triage |
Obligatorio |
|
Actualizar la información del paciente |
Siempre, sin la necesidad de pertenecer a un caso particular |
Según prefiera |
|
Monitorear su estado de salud |
En turnos nocturnos |
Según prefiera |
|
Mirar el equipo médico asignado |
Siempre, sin la necesidad de pertenecer a un caso particular |
A través del registro de datos en Mis Cosas |
Descripción de los datos |
Contexto |
Disponibilidad |
Acción / Actividad |
|---|---|---|---|
Pacientes |
Siempre |
A través de Búsquedas por pacientes |
Acción: Comenzar Triage e iniciar el proceso de Emergencia |
Equipo médico |
Siempre |
Siempre Disponible |
|
Monitoreo de la salud |
Durante turnos nocturnos |
Obligatorio |
Actividad: Añadir monitoreo |
Médico(a)
Descripción de los datos |
Contexto |
Acción / Actividad |
|
|---|---|---|---|
Examinar pacientes de acuerdo al nivel de urgencia establecido en el Triage: Muy urgente, urgente y básico |
Cuando los pacientes se encuentran en la sala de espera y el médico es quien los atendrá |
Obligatorio |
|
Solicitar exámenes de laboratorio o radiología |
Cuando se estén examinando los pacientes |
Según prefiera |
|
Revisar exámenes |
Cuando los exámenes solicitados han sido finalizados |
Obligatorio |
|
Tomar muestra de sangre |
Cuando sea asignado |
Obligatorio |
|
Ejecutar procedimiento de radiología |
Cuando sea asignado |
Obligatorio |
|
Enviar a cirugía |
Cuando se examinen pacientes y cuando se revisen los exámenes |
Según prefiera |
|
Reparar equipo médico |
En cualquier momento |
Según prefiera |
Descripción de los datos |
Contexto |
Disponibilidad |
Acción / Actividad |
|---|---|---|---|
Pacientes |
Siempre |
Mediante Búsqueda por pacientes |
Acción: Comenzar Triage para iniciar el proceso de Emergencia |
Equipo médico |
Siempre |
Siempre disponible |
Acción Iniciar el proceso de reparación, incluyendo uno o más equipos médicos |
Paciente
Descripción de los datos |
Contexto |
Disponibilidad |
Acción / Actividad |
|---|---|---|---|
Médicos(as), Exámenes, Triage |
Siempre |
A través de Mis Cosas, modo solo lectura |
Ninguna |
Descripción del proceso
Después de revisar las acciones disponibles, podemos crear la estructura del proceso principal y los procesos complementarios que serán iniciados vía Acciones para soportar la estructura del caso.
El proceso inicia cuando un paciente ingresa a la Sala de Emergencias. Un(a) enfermero(a) examina el paciente y determina el nivel de emergencia. El paciente procede a una examinación ejecutada por un médico, o es enviado a cirugía.
El medico puede solicitar los exámenes necesarios para poder realizar el diagnóstico.
Los procesos de los exámenes solicitados son iniciados, como parte del caso de Sala de Emergencias.
Una vez los exámenes son finalizados, la actividad Revisar Exámenes es habilitado.
El paciente puede ser dado de alta después de la revisión de los exámenes, o ser enviado a cirugía.
Proceso principal: Triage
Procesos relativos a los exámenes (procesos soportados en gestión de procesos no estructurados):
Principales aspectos en el Proceso de Construcción
Modelo de Datos
La entidad de proceso del proceso Triage es “Triage”, la cual contiene todos los atributos y las relaciones necesarias para almacenar la información principal del caso.
En este ejemplo, se han creado tres Stakeholders los cuales tienen un Diseño de Experiencia específico, es decir, un Portal de Trabajo único para cada uno de ellos.
•Médico(a)
•Enfemero(a)
•Paciente
Configuración de la herencia
Varias entidades de proceso que soportan el caso, hacen parte de la entidad Medical Exams (Exámenes médicos). Esta entidad es construida utilizando un modelo jerárquico, que nos permite utilizar un lanzador polimórfico en la actividad Examine Patient (Examinar paciente).
Constructores
Cada uno de los procesos de los exámenes soportados necesitan un Constructor previamente definido, es decir, necesitan una definición de cómo se construye un registro en cada entidad, de manera que puedan ser mostrados a través del lanzador polimórfico en el Portal de Trabajo. Para esta plantilla, usamos un constructor para todos los procesos definidos, los cuales son:
Bilirrubina, Hemograma Tomografía, Ecografía y Radiología.
Se utilizó el Asistente de Constructores en Bizagi Studio, y se definió un proceso para cada uno.
Plantillas
Cuando navega a través de los datos, bien sea respecto a los resultados de una búsqueda específica o sobre listas de información que hacen parte de Mis Cosas, usted podrá personalizar la información mostrada para los registros resultantes.
Por defecto, Bizagi utiliza una plantilla básica que escoge de manera aleatoria atributos de la entidad a la cual pertenece un registro.
Hemos definido plantillas de datos para mostrar las entidades más relevantes: Patient (Paciente), Doctor (Médico) para cada una de las entidades de los exámenes y Triage.
Disparadores y actividades/eventos condicionales
Las actividades condicionales son usadas en los procesos para habilitar o deshabilitar actividades de acuerdo a la condición de los datos en el proceso. En esta plantilla, usamos la actividad condicional “Review Exams” (“Revisar Exámanes”).
Una vez se finalizan todos los exámenes, se deberá habilitar la actividad “Review Exams” (“Revisar Exámenes”). y no antes de que se hayan completado.
La condición para habilitar o deshabilitar la actividad condicional se configura en el cuarto paso del Asistente de procesos, Definir Expresiones, tal como se muestra a continuación:
Para configurar el atributo Triage.Examsready a verdadero o falso, y, en consecuencia, para habilitar o deshabilitar la actividad, usaremos un Disparador.
Primero, utilizaremos una expresión al finalizar todos los procesos concernientes a Exámenes, indicando que han sido finalizados. Cuando se finaliza cada uno de ellos, se lanza el Disparador y luego se analiza:
Si el examen en cuestión ha sido finalizado, el Disparador ejecuta una expresión en el evento para revisar si realmente todos los exámenes del caso de Triage han sido culminados
Si al menos uno de ellos no ha sido finalizado, el atributo Triage.Examsready permanecerá en falso.
Sin embargo, tan pronto culminen, el atributo Triage.Examsready será verdadero y la actividad condicional Review exams será habilitada para continuar con el proceso., asignándose al Médico.
Last Updated 10/28/2022 10:26:23 AM