Hospital Municipal de Agudos Dr. Leónidas Lucero: Modelo de la Organización

Juan A. Capodarca1 - Alejandro D. Suraci2 - Marisa A. Sánchez3

1 Estudiante avanzado de la Lic. en Cs. de la Administración. Becario del Dpto. Capacitación y Desarrollo del Hospital Municipal de Bahía Blanca. 2 Estudiante avanzado de la Lic. en Cs. de la Administración. Auxiliar de cátedra en la asignatura "Administración I" de la carrera de Contador Público, Dpto. de Cs. de la Administración, Universidad Nacional del Sur. 3 Dra. en Cs. de la Computación. Profesora Adjunta a cargo de la asignatura "Sistemas y Modelos" de la carrera de Lic. en Administración, Dpto. de Cs. de la Administración, Universidad Nacional del Sur.

Resumen En este trabajo describimos cómo modelar organizaciones utilizando el lenguaje Unified Modeling Language (UML) [Booch, 1998], y una extensión propuesta por Eriksson y Penker [Eriksson, 2000]. Un modelo es una representación de la organización que muestra los procesos y funciones de las unidades organizacionales, sus interacciones y los datos que utilizan. Describimos la propuesta de modelado, y presentamos la experiencia de modelar una organización hospitalaria de Bahía Blanca.

Palabras clave: Modelos de Organizaciones; Unified Modeling Language; Extensiones Eriksson y Penker.

1- Introducción

Un modelo constituye una representación de la organización mostrando los procesos o funciones de los departamentos o unidades organizacionales, sus relaciones, y los datos que se utilizan. Existen varias propuestas para construir un modelo de una organización [Bertolazzi, 2001; Medina, 1992; Schael, 1997; Yu, 1997] . Sin embargo, consideramos el trabajo de Eriksson y Penker [Eriksson, 2000] porque está basado en Unified Modeling Language (UML) [Booch, 1998], que es un lenguaje estándar para visualizar, especificar, desarrollar y documentar sistemas.

UML constituye un lenguaje para especificar modelos de acuerdo al paradigma de análisis y diseño de sistemas conocido como orientado a objetos. Si bien UML puede parecer complejo para el usuario principiante, UML tiene un enfoque minimalista. El problema está dado por la complejidad subyacente de los sistemas a modelar. Un lenguaje de modelamiento más simple sería incapaz de capturar todos los elementos semánticos de interés.

Inicialmente, UML fue diseñado para describir aspectos de sistemas de software. De todos modos, UML soporta el concepto de extensión a través de la estereotipación. La definición de estereotipos permite definir nuevos elementos sintácticos para ajustar la notación a necesidades particulares. En particular, Eriksson y Penker [Eriksson, 2000] definen estereotipos para representar con mayor naturalidad conceptos propios de las organizaciones tales como procesos,

objetivos estratégicos, recursos, o reglas. Además, Eriksson y Penker proponen describir un modelo de una organización incluyendo cuatro vistas principales: (a) una descripción de la visión, misión y estrategia; (b) los procesos; (c) los recursos, productos, servicios, unidades organizacionales; y (d) información dinámica relacionada con el comportamiento individual de cada recurso, y la interacción entre procesos.

El objetivo de este trabajo es mostrar cómo modelar organizaciones utilizando la propuesta de Eriksson y Penker. Tomamos como caso de estudio una entidad hospitalaria de Bahía Blanca, el Hospital Municipal de Bahía Blanca (HMBB). Las descripciones contenidas en el artículo están basadas en los procesos del hospital, por razones de espacio, se han efectuado algunas modificaciones que no se ajustan precisamente a los procesos reales, por lo que las descripciones no deben interpretarse como una especificación exacta de los mismos.

Este trabajo está organizado de la siguiente forma: en la Sección 2 brindamos una breve introducción al paradigma de modelamiento en que se basa UML; en la Sección 3 describimos el lenguaje UML; la Sección 4 está dedicada presentar el modelo para el HMBB; finalmente, en la Sección 5 sintetizamos las principales conclusiones.

2- Modelos y Análisis Orientado a Objetos

Una introducción al paradigma de análisis de sistemas orientado a objetos está fuera del alcance de este artículo. El lector interesado puede consultar literatura específica (por ejemplo, [Meyer,2000]). A continuación, describimos las ideas principales.

Una estrategia para construir modelos de algo grande y complejo, es intentar descomponerlo en elementos estructurales o de conducta. Actualmente, el paradigma dominante en la industria es el orientado a objetos. Este paradigma resulta de la combinación de tres ideas: un método de estructuramiento, una disciplina de confiabilidad, un principio epistemológico, y una técnica de clasificación [Meyer,2000].

El método de estructuramiento se refiere al criterio de descomposición del sistema a modelar. En este caso, la estructura se basa en el tipo de objetos (entidades) del sistema. El concepto resultante es el de clase. Una clase encapsula en una descripción sus atributos (propiedades) y las operaciones que se pueden aplicar sobre los atributos. Un objeto es una instancia particular de una clase.

La disciplina de confiabilidad surge de la necesidad de construir sistemas de software que hagan lo que se supone que hacen. La idea es tratar a un sistema como una colección de componentes que colaboran adhiriendo a contratos que definen las responsabilidades de cada elemento del modelo.

El principio epistemológico define explícitamente las obligaciones y beneficios que le incumben a cada parte. Este principio está vinculado con la pregunta de cómo debemos definir clases. En la tecnología de objetos, los objetos descriptos por una clase están definidos por lo que se puede hacer con ellos: operaciones y propiedades de estas operaciones. El fundamento de la idea es la teoría de tipos de datos abstractos [Hoare, 1989].

La técnica de clasificación aparece debido a que el razonamiento científico en general requiere determinar taxonomías para los dominios que se están estudiando. El análisis orientado a objetos organiza las clases en una estructura jerárquica basada en el concepto de herencia. La herencia significa que la conducta y atributos de una clase hija son siempre una extensión de las propiedades de la clase padre.

A partir del paradigma orientado a objetos han surgido diferentes métodos y lenguajes de especificación. De todos modos, desde 1997, el lenguaje UML constituye el estándar para modelar sistemas. En la próxima sección, introducimos brevemene UML.

3- Breve Introducción a UML

El lenguaje Unified Modeling Language (UML), como su nombre lo indica, constituye un lenguaje para especificar modelos de acuerdo al paradigma basado en objetos. La sintaxis y semántica de UML están formalmente definidos. Esto significa que la notación y reglas gramaticales están perfectamente definidas. La existencia de una semántica formal implica que los modelos UML tienen un significado preciso, lo cual facilita el análisis de consistencia, y es posible derivar propiedades. Además, UML es un lenguaje gráfico que utiliza una variedad de elementos visuales que facilita su manipulación.

UML contiene bloques de construcción para modelar conceptos definidos por las técnicas de modelos basadas en objetos (por ejemplo, clases, objetos, estados de objetos, actividades, casos de uso, comunicaciones entre objetos, etc.). En el Apéndice I incluímos algunos de los elementos notacionales de UML que utilizamos en este trabajo. Los diagramas son los medios para ver estos modelos de construcción. Los diagramas se utilizan para visualizar un sistema desde diferentes perspectivas o vistas. Por ejemplo, la vista estática o estructural de un sistema puede visualizarse con los diagramas de clases; la vista de procesos con diagramas de actividad.

Además, UML soporta el concepto de extensión a través de la estereotipación. La definición de estereotipos permite definir nuevos elementos sintácticos para ajustar la notación a necesidades particulares. Por ejemplo, para modelar un proceso de una organización, se pueden necesitar elementos como personal, documentos o recursos. Cuando se aplica un estereotipo sobre un elemento como una clase se está extendiendo UML creando un nuevo bloque de construcción

como cualquiera de los existentes, pero con sus propias características. Cada estereotipo proporciona su propio conjunto de valores, su semántica y su notación.

4- Caso de estudio

Como mencionamos en la Sección 1, las extensiones Eriksson-Penker utilizan cuatro vistas diferentes de la organización. Las vistas no son modelos separados sino que constituyen diferentes perspectivas de uno o más aspectos de la entidad. La combinación de estas vistas conforman un modelo completo. En las secciones siguientes, utilizando el caso de estudio del HMBB, describimos cada una de estas vistas, su propósito y los diagramas necesarios. Por razones de espacio, sólo incluímos los aspectos vinculados con los procesos relacionados con la internación de un paciente.

4.1- Vista de la Organización

La Vista de la Organización es el primer aspecto considerado en las extensiones de Eriksson-Penker. Incluye una descripción textual de la estrategia general de la organización, un análisis de las Fortalezas, Oportunidades, Debilidades y Amenazas (FODA), un Diagrama de Objetivos/Problemas para definir metas, y un Diagrama de Conceptual que representa los conceptos esenciales usados en la organización.

4.1.1- Visión de la Organización

"El Hospital Municipal de Agudos Dr. Leónidas Lucero, con un perfil de emergencias desarrollará actividades sanitarias y asistenciales para la población en términos de universalidad, accesibilidad y equidad con el claro propósito de asegurar una prestación de calidad, impulsando también la complementación de los efectos tanto de gestión pública como privada con el fin de optimizar los recursos de Salud" (ver sitio www.hmabb.gov.ar).

4.1.2- Análisis de FODA

Oportunidades: disponibilidad de recursos humanos externos a la organización, relativamente económicos y capacitados.

Amenazas: panorama económico complicado, con un crecimiento constante en la demanda de atención médica por el incremento del nivel de pobreza de la sociedad.

Fortalezas: personal jerárquico capacitado y sistema informático ya instalado.

Debilidades: personal capacitado para las exigencias actuales, pero no para alcanzar los objetivos futuros.

4.1.3- Diagrama de Conceptual

El modelo conceptual define los conceptos esenciales utilizados en la organización. El modelo establece un vocabulario común para todos los conceptos y muestra las relaciones entre los mismos. Este modelo se representa con un diagrama de clases. La Figura 1 muestra el modelo conceptual para nuestro caso de estudio. Los conceptos importantes se modelan como clases, y las relaciones se expresan utilizando la relación de asociación UML. La multiplicidad indica que la entidad Hospital está vinculada con uno o más (1..n) Proveedores y Pacientes. Existe una realción uno a uno entre el Hospital y la Asociación Médica y el Municipio. Finalmente, dado un paciente, puede estar vinculado con ninguna o muchas Internaciones.

 Figura 1: Diagrama Conceptual

4.1.4- Diagrama de Objetivos/Problemas

Un modelo de objetivos describe los objetivos de la organización y los problemas que los afectan. El diagrama de Objetivos/Problemas es un diagrama de objetos UML. Los objetivos se describen como objetos de clases que han sido estereotipadas como "objetivos". Tales objetos se utilizan para mostrar objetivos, las dependencias entre los mismos, y las relaciones entre objetivos y problemas. La clase "Objetivo Cuantitativo" puede medirse a través de un valor. La clase "Objetivo Cualitativo" sirve para modelar objetivos difíciles de describir en términos cuantificables.

Los objetivos generales del hospital apuntan a incorporar tecnología que asegure un adecuado nivel de prácticas sanitarias; promover el perfeccionamiento de profesionales; y procurar un adecuado equilibrio entre costos y prestación de servicios. A continuación, modelamos parte de estos objetivos estratégicos (verFigura 2).

Figura 2: Diagrama de Objetivos/Problemas

4.2- Vista Estructural

La Vista Estructural muestra la estructura de recursos, productos, o servicios, y la información en la organización, incluyendo la organización de la compañía (por ejemplo, divisiones, departamentos, secciones) [Eriksson, 2000]. Los diagramas UML usados para documentar esta vista son Diagramas de Clases y de Objetos. Los Diagramas de Clases muestran la estructura principal; los Diagramas de Objetos muestran la organización en un instante específico del tiempo.

4.2.1- Diagrama de Clases Estructural

El Diagrama de Clases Estructural de la Figura 3 muestra los recursos del HMBB que están representados con clases estereotipadas como "Personal" para describir los recursos humanos; "Abstracto" para denotar las cosas que no son físicas pero son de gran importancia para la organización (tales como historias clínicas, órdenes de internación, solicitudes de estudios, entre otros); "Físico" para los recursos materiales (por ejemplo, insumos, paquetes de medicamentos); e "Información" para denotar los recursos que contienen información (por ejemplo, un informe de práctica). La Historia Clínica está compuesta por diferentes secciones, y las secciones pueden ser de once tipos diferentes.

Figura 3: Diagrama de Clases Estructural

En la Figura 3 también indicamos la estructura organizacional del HMBB. El hospital se organiza en divisiones. Las divisiones pueden ser de cuatro tipos, y a su vez, algunas divisiones se organizan en áreas. La clase División constituye una superclase, y las clases Departamento, Oficina, Servicio y Unidad son clases hijas que heredan las propiedades y operaciones de División, y tienen algunas particularidades. Por ejemplo, Departamento y Servicio están vinculadas con una relación de composición con la clase Área.

4.2.2- Diagrama de Objetivos para representar las unidades organizacionales actuales

La Figura 4 describe las divisiones y áreas que existen actualmente (sólo incluímos las entidades que se mencionan en los procesos de la Sección 4.3).

Figura 4: Estructura Organizacional Actual

4.3- Vista de Procesos

La Vista de Procesos es el corazón del modelo de la organización. Un proceso está vinculado con objetivos específicos, objetos de entrada que representan recursos para el proceso, y objetos de salida que constituyen el resultado del proceso. Describimos esta vista utilizando Diagramas de Procesos. Un Diagrama de Proceso es un estereotipo basado en un Diagrama de Actividad UML que permite describir actividades, sus interacciones, recursos necesarios, resultados, y objetivos vinculados con el proceso. Observar que todas las entidades presentes en el proceso constituyen instancias de clases. Estas instancias son creadas, transformadas o referenciadas durante la ejecución del proceso.

A continuación, describimos los procesos vinculados con la internación de un paciente. Primero, presentamos una descripción sintética del proceso utilizando el estereotipo de procesos. Luego, incluímos la descripción detallada del proceso. Finalmente, en la Vista de la Conducta mostraremos la interacción entre los procesos.

Proceso de Internación Administrativa. La internación administrativa es el proceso mediante el cual queda registrado el ingreso del paciente al hospital. En este proceso se constatan los datos del paciente, si ya había estado antes internado, en qué sala, cama, y habitación será ubicado y demás datos relevantes.

Si el paciente se interna por primera vez, se crea la Historia Clínica. El proceso se inicia cuando el médico firma una orden de internación. La Figura 5 muestra el proceso en un nivel de abstracción alto, omitiendo detalles. Para realizar el proceso se utiliza una Historia Clínica y la Agenda de Asignación de Habitaciones. El resultado es el procesamiento de estas dos entradas, y además, se crea una instancia de Paciente, Orden de Internación, Informe de Hospitalización, Informe de Asistencia Social, y Censo Diario. En el proceso intervienen un médio y personal administrativo. El proceso está vinculado con la satisfacción del objetivo cuantitativo "Errores y Omisiones en la carga" indicado en el Diagrama de Objetivos/Problemas de la Vista de la Organización. En la Figura 6 se incluyen todos los detalles de flujo de control y flujo de datos del proceso.

Figura 5: Proceso de Internación Administrativa

Figura 6: Proceso de Internación Administrativa (detalle)

Proceso de Solicitud y Registración de Medicamentos. El proceso comienza cuando el médico prescribe medicación a su paciente a través de la hoja de indicaciones médicas. Posteriormente, en el Office de Enfermería (asentamiento de los enfermeros en la sala de internación) se confecciona la Foja de Enfermería que contiene las indicaciones médicas y la medicación prescripta. Desde enfermería se solicitan los medicamentos a la farmacia del hospital,

esto se hace a través de un sistema informático. La medicación es enviada desde farmacia al Office de Enfermería donde se controla el pedido con lo enviado, de no coincidir, se remiten los medicamentos para que se corrija el lote. La Figura 7 muestra una descripción de alto nivel del proceso, mientras que los detalles se encuentran en la Figura 8.

Figura 7: Proceso de Solicitud y Registración de Medicamentos

Figura 8: Proceso de Solicitud y Registración de Medicamentos (detalle)

Proceso de Solicitud y Registración de Interconsultas. Las interconsultas médicas son consultas que el médico responsable de un paciente determinado hace a otro médico, generalmente, de otra especialidad, para que este último realice un diagnóstico de alguna afección que el paciente esté sufriendo y no sea esta el motivo principal de la internación. La solicitud de interconsulta se realiza con un comprobante confeccionado por el médico responsable del paciente; la secretaria realiza la registración en el sistema informático y envía el comprobante al médico que deberá efectuar la interconsulta. Este último deberá registrar su diagnóstico en la Historia Clínica. La secretaria de la sala de internación deberá registrar la realización de la interconsulta en un sistema de Interconsultas Informático. La Figura 9 y 10 especifican este proceso.

Figura 9: Proceso de Solicitud y Registración de Interconsultas

Figura 10: Solicitud y Registración de Interconsultas (detalle)

Proceso de Solicitud y Registración de Estudios. Para la realización de diversos estudios (o prácticas) es menester que el médico que indica el estudio confeccione una solicitud de estudio. Posteriormente, la enfermera de la sala de internación recibirá la solicitud y deberá registrarla en el sistema informático. El servicio efector de la práctica o estudio toma conocimiento del estudio solicitado, y luego recibe al paciente en sus consultorios y efectúa el estudio.

Cada estudio realizado debe estar acompañado de su respectivo informe, el cual será remitido a la secretaria de la sala para que esta registre la realización del estudio en el sistema informático, y luego adjunte el estudio a la Historia Clínica. El paciente retorna a su sala de internación y es ubicado nuevamente en su habitación y cama (asignadas desde su internación administrativa). La Figura 11 y 12 describen el Proceso de Solicitud y Registración de Estudios a la Unidad de Diagnóstico por Imagenes.

Figura 11: Proceso de Solicitud y Registración de Estudios a la Unidad de Diagnósticos por Imágenes

Figura 12: Proceso de Solicitud y Registración de Estudios (detalle)

Proceso de Realización de Traslados. Los traslados se solicitan y realizan cuando un paciente es enviado desde una sala de internación a otra. Los traslados son indicados por los médicos, y sólo se podrán hacer en la medida que existan camas disponibles en la sala de destino. Estos traslados se deben realizar en el sistema informático en forma concomitante con el traslado físico, y es importante tener en cuenta que si el paciente no es trasladado administrativamente utilizando el sistema informático, la sala destino no podrá solicitar los medicamentos necesarios para la adecuada atención médica. Las Figura 13 y 14 especifican este proceso.

Figura 13: Proceso de Solicitud y Registración de Traslados

Figura 14: Proceso de Realización de Traslados (detalle)

Proceso de Realización y Registración de Cirugías. Para poder efectuar cirugías se requiere la solicitud anticipada de los quirófanos, para lo cual los médicos deberán tramitar dicha solicitud con la secretaria del quirófano. Una vez reservado el quirófano, y cumplida la fecha de la intervención, se efectúa la cirugía. La misma da origen a varios registros manuales, y el formulario de insumos debe registrarse en el sistema informático. Posteriormente, el formulario de insumos, la foja quirúrgica, y la foja de anestesia, deben ser adjuntadas a la historia clínica. Las Figuras 15 y 16 especifican el proceso completo.

Figura 15: Proceso de Realización y Registración de Cirugías

Figura 16: Proceso de Realización y Registración de Cirugías (detalle)

Proceso de Alta Administrativa. El alta administrativa es consecuencia inmediata del alta médica, la cual requiere que el médico firmante del alta confeccione un comprobante que certifica su autorización para que el paciente se retire y para que la admisionista cierre el proceso de internación. De esta forma, se libera la plaza ocupada por el paciente durante su estadía en el hospital. Las Figuras 17 y 18 completan la descripción del proceso. 

Figura 17: Proceso de Alta Administrativa

Figura 18: Proceso de Alta Administrativa (detalle)

4.4- Vista de la Conducta

La Vista de la Conducta ilustra el comportamiento individual de recursos, y la interacción entre diferentes recursos y procesos. La Vista del Proceso muestra el flujo de control y de datos de cada actividad; y la Vista de la Conducta analiza a cada uno de los objetos con más detalle: su estado (usando diagramas de Transición de Estados); y la interacción entre recursos (usando diagramas de Secuencia o Colaboración).

En la Figura 19 describimos la interacción entre algunos de los procesos incluídos en la Vista de Procesos. Observar que sólo se incluyen los objetos del flujo de datos que sirven de vínculo entre los procesos. En este caso particular, todos comparten la Historia Clínica.

Figura 19: Interacción de Procesos

5- Conclusiones

El lenguaje de modelado UML se ha convertido en el estándar aceptado por el grupo Object Management Group (OMG) (ver sitio www.omg.org) y adoptado por la International Organization for Standardization (ISO). El lenguaje tiene la potencia expresiva suficiente para capturar las propiedades de un sistema a un alto nivel de abstracción y, al mismo tiempo, permite especificar aspectos de detalle. El hecho de que UML sea un lenguaje definido formalmente es de gran importancia porque induce a la realización de modelos completos, consistentes y no ambiguos. Además, una especificación formal es la base para la validación automatizada de modelos. Esta posibilidad cobra cada vez más atractivo debido a la complejidad creciente de las reglas de negocios.

Las posibilidades de extensión de UML permiten crear nuevos tipos de bloques de construcción que se derivan de los existentes, pero que son específicos a un problema. En particular, en este trabajo ilustramos el uso de las Extensiones Eriksson-Penker para modelar organizaciones. Si bien no hemos detallado todos los diagramas disponibles para construir un modelo, hemos enfatizado los aspectos prácticos utilizando un caso de estudio real.

Apéndice I: Algunos constructores estándar de UML

Apéndice II: Algunas Extensiones de Eriksson y Penker

Referencias 1. P. Bertolazzi, C. Krusich y M. Missikoff, An Approach to the Definition of a Core enterprise Ontology: CEO, Proceedings of International Workshop on Open Enterprise Solutions: Systems, experiences, and Organizations. Roma, 2001. 2. G. Booch, J. Rumbauch and I. Jacobson, The Unified Modeling Language. User Guide, Object Technology Series, Addison Wesley Longman, Reading, MA, USA, 1998. 3. S. Brignall and J. Ballantine, Strategic Enterprise Management Systems: new directions for research, Management Accounting Research 15 (2004) 225-240. 4. Hans-Erik Eriksson and Magnus Penker, Business Modeling with UML Business Patterns at Work, Wiley Computer Publishing. John Wiley & Sons, Inc., 2000. 5. C.A.R.Hoare y C. Jones, Essays in Computer Science, Prentice Hall International, Hemel Hempstead (UK), 1989. 6. R. Medina-Mora, T. Winograd, R. Flores y C. Flores, The action Workflow Approach to Workflow Management Technology, Proceedings of the 4th Conference on Computer-Supported Cooperative

Work, p. 281-288, ACM, 1992. 7. Bertrand Meyer, Object Oriented Software Construction, 2nd edition, Prentice Hall PTR, 2000. 8. T. Schael, Cooperative Processes and Workflow Managament for Enterprise Integration, Proceedings of International Conference on Enterprise Integration and Modeling Technology, p. 496-509, Springer-Verlag, 1997.