caso de estudio centro médico y laboratorio

SISTEMA ELECTRÓNICO DE FICHAS DE PACIENTES (SEFP)

CASO DE ESTUDIO: CENTRO MÉDICO DE ESPECIALIDADES Y LABORATORIOS CLÍNICOS

ANÁLISIS Y DISEÑO Sistema Electrónico de Fichas de Pacientes - CEMELAB

2

TABLA DE CONTENIDO

Situación Actual ..................................................................................................................................... 3

Análisis del Sistema ............................................................................................................................... 4

Especificación de Requisitos ........................................................................................................................... 4

Identificación Del Sistema ......................................................................................................................... 4

Especificación De Funciones ...................................................................................................................... 4

Modelo de Casos de Uso ................................................................................................................................ 5

Especificación de Casos de Uso ................................................................................................................. 5

Diagrama de Casos de Uso ........................................................................................................................ 9

Glosario ........................................................................................................................................................ 10

Modelo de Dominio ...................................................................................................................................... 11

Diagrama de Actividades ......................................................................................................................... 11

Diagrama de Clases Conceptuales ........................................................................................................... 12

Modelo de Comportamiento ........................................................................................................................ 15

Diagramas de Secuencia .......................................................................................................................... 15

Contratos de las Operaciones .................................................................................................................. 18

Diagramas de Estado ............................................................................................................................... 20

Diseño del Sistema............................................................................................................................... 21

Modelo Arquitectónico ................................................................................................................................ 21

Diagrama de Componentes ..................................................................................................................... 21

Modelo de Diseño ........................................................................................................................................ 23

Diagramas de Colaboración ..................................................................................................................... 23

Diagrama de Clases de Diseño ................................................................................................................. 28

Preparando la Implementación............................................................................................................ 33

Modelo de Implementación ......................................................................................................................... 33

Diagrama de Clases de Implementación ................................................................................................. 33

Estructura de Clases................................................................................................................................. 34


3

SITUACIÓN ACTUAL

El Centro Médico de Especialidades y Laboratorios Clínicos, CEMELAB, es un servicio que de atención médica

(consultas) de diferentes especialidades y laboratorio para diferentes exámenes médicos a lo largo de todo

el país. CEMELAB posee convenio con casi todas las ISAPRES lo que la hace una excelente alternativa.

El gerente general ha decidido desarrollar un sistema electrónico de fichas médicas e historial de pacientes

(SEFP) para realizar todo el seguimiento de los pacientes independientemente de donde se atiendan o

realicen los procedimientos indicados por los especialistas. Este sistema de ficha electrónica está

reemplazando al sistema actual de fichas de atención que tiene cada centro.

Para el diseño del SEFP se ha contratado a su consultora, la cual ha realizado una primera entrevista

obteniendo una descripción aproximada del proceso y ciclo de vida de la ficha en cuestión. Esta información

incluye la siguiente:

1) Cuando un paciente nuevo llega a cualquier centro, se le crea una nueva ficha médica, la cual debe

ser completada con la información básica del individuo (nombre completo, rut, dirección, teléfono

de contacto y correo electrónico si tuviera). Estos datos deben ser ingresados en la recepción

correspondiente (ya sea en el laboratorio como en la recepción de atención médica).

2) Cuando un especialista atiende a un paciente, éste podrá ver la ficha completa del individuo para

poder realizar un seguimiento completo. Esto lo hace a través del terminal ubicado en cada box de

atención.

3) Una vez que ha terminado la atención del especialista, éste debe llenar con la anamnesis realizada

en la entrevista y posterior análisis realizado. Esta información debe incluir fecha de la atención,

datos de la inspección (peso, talla, IMC, temperatura y presión arterial), observaciones del examen

físico obtenido, diagnóstico e indicaciones (alimentaria y conductual, medicamentos y/o

procedimientos clínicos, derivaciones u hospitalización).

4) Además, en cada atención, el SEFP debe conectarse con un servicio web de la Agenda Médica para

informar cuando se realizan las atenciones de los especialistas, de manera de llevar el control y

poder cancelar los honorarios médicos respectivos.

5) Algo similar pasa cuando un paciente va a laboratorio por un procedimiento. En este caso el

tecnólogo médico o enfermera podrá ver la información referente a la última entrevista con

especialista o aquella que le derivó a dicho procedimiento. Así mismo, deberá ingresar cualquier

observación y los resultados obtenidos en el procedimiento (ya sea in situ o posterior análisis de los

resultados).

6) En caso de ser derivado a un centro asistencial para hospitalización, el especialista que lo deriva

podrá imprimir un informe médico que deberá presentar en el hospital o clínica que asista para que

lleve toda la información de manera más expedita.

7) El SEFP no debe realizar cobros por bonos o servicios prestados, ni tampoco el control de

remuneraciones y honorarios médicos del personal.


4

ANÁLISIS DEL SISTEMA

ESPECIFICACIÓN DE REQUISITOS

En esta sección se describe la visión funcional del sistema a la luz de los requerimientos expresados por el

cliente final.

Identificación Del Sistema

El sistema se describe de la siguiente forma:

Nombre del Sistema: Sistema Electrónico de Fichas de Paciente (SEFP)

Panorama: CEMELAB, a través de sus centros médicos y laboratorios a lo largo del país

Clientes: Recepcionistas, Médicos y Laboratoristas

Metas: Crear un sistema de registro electrónico de fichas únicas de pacientes del centro

para:

Centralizar la información médica de cada paciente registrado en el centro

Mantener la información en línea de manera de que cualquier especialista

pueda consultarla en forma oportuna

Entregar la información requerida al paciente en caso de hospitalización y/o

traslado a otro centro de atención.

Especificación De Funciones

En un análisis simple, podemos obtener que los requerimientos 1 al 6 son del tipo funcional y el número 7 es

una restricción del sistema. Por otro lado, el requerimientos 4 tiene una componente de interoperatividad

con el sistema de agendamiento médico.

La especificación funcional del sistema se detalla a través de las siguientes funciones:

# Ref: R1.1

Función: Registro de un Paciente

Descripción: El sistema debe permitir el registro de un paciente con los datos básicos de éste

(nombre completo, rut, dirección, teléfono de contacto y correo electrónico).

Categoría: Evidente

Atributo Detalles y Restricciones Categoría

# Ref: R1.2

Función: Registro de Anamnesis

Descripción: El sistema debe permitir que el médico tratante ingrese el detalle de la atención

en box incluyendo los procedimientos y medicamentos indicados.



# Ref: R1.3

Función: Registro de Observaciones en un Procedimiento

Descripción: El sistema debe permitir que la enfermera o médico a cargo ingrese las

observaciones durante el procedimiento médico de un paciente.


5



# Ref: R1.4

Función: Registro de Resultados de un Procedimiento

Descripción: El sistema debe permitir que el tecnólogo médico ingrese los resultados y las

inferencias según sea el caso de los procedimientos realizados por el paciente.



# Ref: R2.1

Función: Consulta de Historial del Paciente

Descripción: El sistema debe permitir al profesional consultar sobre la historia reciente del

paciente registrada en su ficha.



Información Segmentada La información debe ser segmentada según el nivel de

acceso del profesional consultante.

Política

# Ref: R2.2

Función: Actualización de Agenda Médica

Descripción: El sistema debe actualizar el sistema de agendamiento cuando el especialista

cierra la ficha luego de terminada la consulta de un paciente.

Categoría: Oculto


Servicio Web La actualización debe realizarse a través de un servicio

web prestado por el sistema de agenda médica.

Interoperatividad

# Ref:

Función:

Descripción:

Categoría:


MODELO DE CASOS DE USO

En esta sección se describen los casos de uso, su detalle y la relación que tienen con las funciones

determinadas en la sección anterior. Es importante incorporar el detalle de cada iteración priorizado de

manera de mantener coherencia con lo que se realize a través del proceso de desarrollo complete.

Especificación de Casos de Uso

Casos de Uso de Alto Nivel

A pesar de que no siempre es así, en este caso los casos de uso se parecerán mucho a lo que encontramos

como funciones. Veamos paso a paso la técnica de especificación.


6

Si observamos las metas de la especificación funcional, podemos decir que el límite del sistema está la

creación y registro del historial médico de un paciente que ingresa y se atiende en algún centro de

CEMELAB. Sin embargo, también podemos decir que excluye:

La administración de la agenda

La compra de bonos y el pago de los servicios prestados por el centro

El control de remuneraciones y honorarios de profesionales

A partir de los clientes y del texto entregado, podemos decir que los actores del sistema son:

Actor Objetivo

Recepcionista Registrar un paciente nuevo para atención Imprimir detalle de ficha médica en caso de derivación o traslado

Especialista Consultar ficha del paciente a ser atendido Ingresar a la ficha del paciente la anamnesis

Enfermera Consultar ficha del paciente a ser atendido Ingresar observaciones en procedimiento

Tecnólogo Ingresar resultados y diagnóstico de un procedimiento

Paciente Ser atendido

Agenda Médica Actualizar las horas médicas cuando se cierre una atención

Los casos de uso encontrados en esta iteración son los siguientes:

Caso de Uso: CU1: Registrar Paciente

Actores: Recepcionista (I), Paciente

Tipo: Primario

Descripción: Cuando llega un paciente nuevo, éste debe ser registrado en el sistema y su ficha

será creada. La información necesaria para este registro es nombre completo, rut,

dirección, teléfono y correo electrónico.

Caso de Uso: CU2: Consultar Historial

Actores: Especialista/ Enfermera (I)

Tipo: Primario

Descripción: Antes de la atención, el encargado deberá revisar la ficha del paciente.

Caso de Uso: CU3: Registrar Anamnesis

Actores: Especialista (I), Paciente

Tipo: Primario

Descripción: Al terminar la atención médica, el médico tratante ingrese el detalle de la atención


Caso de Uso: CU4: Registrar Observaciones por Procedimiento

Actores: Enfermera (I)

Tipo: Secundario

Descripción: Durante un procedimiento, la enfermera puede ingresar observaciones que le

parezcan relevantes para el análisis del mismo.

Caso de Uso: CU5: Registrar Resultado de Procedimiento

Actores: Tecnólogo (I)

Tipo: Primario


7

Descripción: Al analizar una muestra, el tecnólogo debe ingresar los resultados clínicos en la

ficha, así como también el diagnóstico preliminar si procede.

Caso de Uso: CU6: Generar Traslado

Actores: Recepcionista (I), Especialista, Paciente

Tipo: Opcional

Descripción: En caso de un traslado (derivación u hospitalización), se debe emitir un informe

indicando el último diagnóstico y procedimientos asociados a éste.

Caso de Uso: CU7: Actualizar Agenda Médica

Actores: Especialista (I)

Tipo: Primario

Descripción: Cada vez que el especialista cierra una atención médica, ésta debe ser actualizada en

la agenda médica.

Es importante destacar que solo los CU principales serán expandidos a continuación.

Casos de Uso Expandidos

El detalle de los casos de uso identificados es el siguiente:


Actores: Recepcionista (I), Paciente

Propósito: Realizar el registro de un paciente nuevo en el SEFP.

Resumen: Cuando llega un paciente nuevo, éste debe ser registrado en el sistema y su ficha

será creada. La información necesaria para este registro es nombre completo, rut,

dirección, teléfono y correo electrónico.

Tipo: Primario y Esencial

Ref. Cruzadas: R1.1

Curso Normal

Acciones de los Actores Respuestas del Sistema

1. Paciente llega al mesón de atención y entrega

su RUT.

2. Recepcionista ingresa RUT en el sistema para

confirmar que es nuevo.

3. Sistema confirma que el paciente es nuevo y

solicita información básica.

4. Recepcionista solicita al paciente información.

5. Paciente entrega a Recepcionista información

solicitada.

6. Recepcionista ingresa la información en el

sistema.

7. Sistema registra la información y crea la ficha

electrónica informando acción.

8. Recepcionista entrega RUT al Paciente.

Cursos Alternos

(3a) Si el paciente ya existe, informa al Recepcionista y termina el CU.

(7a) Si el RUT ya está registrado con otra información, alerta al Recepcionista y solicita confirmación para

actualizar información.


Actores: Especialista/Enfermera (I)

Propósito: Consultar aspectos relevantes de la ficha previos a la atención.

Resumen: Antes de la atención, el encargado deberá revisar la ficha del paciente utilizando el


8

RUT de éste.


Ref. Cruzadas: R2.1

Curso Normal


1. Especialista/Enfermera ingresa el RUT del

paciente en el sistema.

2. Sistema obtiene ficha del paciente y muestra

información.

Cursos Alternos

(2a) Si el paciente no existe, lo informa y termina el CU.


Actores: Especialista (I), Paciente

Propósito: Registrar la información resultante de la consulta médica.

Resumen: Al terminar la atención médica, el médico tratante ingrese el detalle de la atención



Ref. Cruzadas: R1.2, CU7

Curso Normal


1. Especialista ingresa el RUT del paciente. 2. Sistema encuentra la ficha médica, abre la

atención médica y solicita información sobre los

datos de la inspección y observaciones al

examen físico.

3. Especialista ingresa datos de peso, talla, presión

arterial, temperatura, etc. y las observaciones si

las hubiera.

4. Sistema registra información de la inspección y

solicita información sobre diagnóstico del

paciente.

5. Especialista ingresa el diagnóstico. 6. Sistema registra el diagnóstico y solicita

información sobre procedimientos,

medicamentos e indicaciones.

7. Especialista ingresa los procedimientos,

medicamentos e indicaciones entregadas al

paciente.

8. Sistema registra información y cierra la atención

médica (CU7).

Cursos Alternos

(2a) Si la ficha no existe, informa al Especialista y termina el CU.


Actores: Tecnólogo (I)

Propósito: Registrar la información de análisis y diagnóstico del procedimiento realizado.

Resumen: Al analizar una muestra, el tecnólogo debe ingresar los resultados clínicos en la ficha,

así como también el diagnóstico preliminar si procede.


Ref. Cruzadas: R1.4

Curso Normal


1. Tecnólogo ingresa el RUT del paciente. 2. Sistema encuentra la ficha médica, solicita

información sobre la fecha de la muestra, los

resultados del examen y diagnóstico en caso de

ser necesario.

3. Tecnólogo ingresa datos obtenidos de la

muestra y en caso de que aplique se ingresa el

4. Sistema registra información y cierra la ficha.


9

diagnóstico.

Cursos Alternos

(2a) Si la ficha no existe, informa al Tecnólogo y termina el CU.


Actores: Especialista

Propósito: Enviar un mensaje al Sistema de Agenda Médica (SAM) de cierre de atención.

Resumen: Al cerrar una ficha por atención médica, el sistema debe generar un mensaje al SAM

para informar que el especialista ha dado término a la atención.


Ref. Cruzadas: R2.2, CU3

Curso Normal


1. Especialista cierra la atención médica (CU3). 2. Sistema registra el cierre de la ficha y envía un

mensaje al SAM indicando el cierre de la

atención.

3. Sistema recibe confirmación de parte del SAM

de que se ha realizado la transacción y termina

el CU.

Cursos Alternos

(3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una

alerta al administrador del sistema, quién debe cursar manualmente el proceso.

En este último CU, en el Curso Alterno (3a) se menciona que debe existir un administrador del sistema. Esto

es porque no se ha mencionado que pasa con la conectividad y comunicación entre ambos sistema (SAM y

SEFP), de modo que ha sido una sugerencia en los requerimientos. Es importante validarlo con el cliente

final antes de cerrar la iteración y utilizar dicha información para el análisis del sistema.

Diagrama de Casos de Uso

Para este caso, el Diagrama de Casos de Uso no es muy simple, ya que incorpora conexiones entre casos de

uso (CU3 y CU7, tal como aparece en su especificación expandida). A continuación se muestra gráficamente

la relación de los actores con los casos de uso especificados.


10

GLOSARIO

En esta sección se describen los conceptos más importantes del dominio y que impactan en su

entendimiento.

Término Definición

Ficha Médica Registro electrónico (en este caso) en donde queda almacenada toda la historia

médica de un paciente.

Registro Proceso a través del cual se guarda la información ingresada por un usuario.

Box Espacio físico donde se realiza la anamnesis.

Anamnesis Proceso de revisión que realiza un especialista en un box de atención a un

paciente.

Datos de la

Inspección

Información que resulta de un examen físico realizado por un especialista en un

box de atención (peso, talla, temperatura y presión arterial).

Diagnóstico Inferencia que realiza el especialista como resultado del examen físico.

Procedimiento Cualquier tipo de examen físico o psicológico que puede solicitar el especialista.

Agenda Médica

(SAM)

Sistema externo necesario para registrar cuando un especialista cierra una

atención médica.

Este glosario resumido (ya que podríamos encontrar muchos más términos para este problema) solo

muestra un ejemplo de cómo van describiéndose las diferentes definiciones de, en este caso, los conceptos

del dominio.

System

Recepcionista

Especialista

Tecnólogo

Enfermera

Agenda Médica

CU1: Registrar Paciente

CU3: Registrar Anamnesis

CU7: Actualizar SAM

CU6: Generar Traslado

CU5: Registrar Resultados

CU4: Registrar Observaciones

CU2: Consultar Ficha

<<include>>


11

MODELO DE DOMINIO

En esta sección se describen los artefactos que muestran la visión de negocio y el contexto en el cual se

desarrollará el sistema.

Diagrama de Actividades

El enfoque que utilizaremos será el ver el diagrama de actividades global a partir de las transiciones que

tiene la ficha de un paciente desde su generación y su uso posterior.

De esta manera, el diagrama nos muestra los diferentes “carriles-de-nado” para los actores y entidades que

utilizan la ficha o realizan actividades como resultado del uso de la ficha. Así, el diagrama comienza por el

recepcionista (ya sea en el laboratorio como en la consulta médica) el cual registra la información básica de

la ficha (crear).

A continuación hemos indicado un conector de decisión para diferenciar si el siguiente flujo (por consulta

médica o por procedimiento). De esta manera diferenciamos el paso dependiendo del actor principal. Cada

uno de esos flujos termina en un conector con una X de manera de que podamos volver al flujo principal en

la decisión para el siguiente flujo.

Finalmente, notaremos que no tiene una actividad de término, ya que la ficha no se destruye en el dominio,

sino que una vez que el paciente ingresa al esquema, se mantendrá desde ese momento en adelante.

Los procesos se describen de la siguiente forma:


12

Diagrama de Clases Conceptuales

Lo que vamos a realizar es utilizar ambos métodos de identificación de clases conceptuales para luego ir

dibujando el diagrama general. Veamos primero entonces la lista de categorías:

Categoría de Clase Conceptual Ejemplos

Objetos tangibles o físicos InformeDeDerivacion

Especificaciones, diseños o descripciones de las cosas DetalleDeInforme ResultadoProcedimiento DetalleAnamnesis

Lugares CentroMedico Recepción ConsultaMedica BoxDeProcedimiento

Líneas de la transacción Anamnesis Procedimiento

Roles de la gente Recepcionista Especialista Laboratorista Paciente

Contenedores de otras cosas -

Cosas en un contenedor -

Otros sistemas externos AgendaMedica

Recepcionista Especialista LaboratoristaSistema de Agenda Médica

Crear Ficha de Paciente

[paciente ingresa al centro]

Ver Ficha de Paciente

[paciente entra a consulta]

Ver Ficha de Paciente

[paciente entra a toma de muestra]

Realizar la Consulta

Registrar la Anámnesis

Registrar Término de Atención

Imprimir Informe Médico

[derivación a centro asistencial]

[no hay derivación]

Realizar el Procedimiento

Registrar Observaciones

Realizar Análisis

Registrar Resultados

[hay observaciones]

[no hay observaciones]


13

Categoría de Clase Conceptual Ejemplos

Conceptos abstractos Anamnesis Procedimiento FichaDePaciente

Organizaciones -

Hechos -

Procesos Anamnesis Procedimiento

Reglas y políticas -

Catálogos RegistroDeFichas

Registro de finanzas, trabajo, contratos, asuntos legales -

Instrumentos y servicios financieros -

Manuales, documentos, artículos de referencia, libros InformeDeDerivacion

Note que aparecen las mismas clases en varias categorías. Veamos ahora las frases nominales de los

escenarios de casos de uso:


Curso Normal


9. Paciente llega al mesón de atención y entrega

su RUT.

10. Recepcionista ingresa RUT en el sistema para

confirmar que es nuevo.

11. Sistema confirma que el paciente es nuevo y

solicita información básica.

12. Recepcionista solicita al paciente información.

13. Paciente entrega a Recepcionista información

solicitada.

14. Recepcionista ingresa la información en el

sistema.

15. Sistema registra la información y crea la ficha

electrónica informando acción.

16. Recepcionista entrega RUT al Paciente.

Cursos Alternos

(3a) Si el paciente ya existe, informa al Recepcionista y termina el CU.

(7a) Si el RUT ya está registrado con otra información, alerta al Recepcionista y solicita confirmación para

actualizar información.


Curso Normal


3. Especialista/Enfermera ingresa el RUT del

paciente en el sistema.

4. Sistema obtiene ficha del paciente y muestra

información.

Cursos Alternos

(2a) Si el paciente no existe, lo informa y termina el CU.


Curso Normal


9. Especialista ingresa el RUT del paciente. 10. Sistema encuentra la ficha médica, abre la

atención médica y solicita información sobre los

datos de la inspección y observaciones al

examen físico.

11. Especialista ingresa datos de peso, talla, presión

arterial, temperatura, etc. y las observaciones si

12. Sistema registra información de la inspección y

solicita información sobre diagnóstico del


14

las hubiera. paciente.

13. Especialista ingresa el diagnóstico. 14. Sistema registra el diagnóstico y solicita

información sobre procedimientos,

medicamentos e indicaciones.

15. Especialista ingresa los procedimientos,

medicamentos e indicaciones entregadas al

paciente.

16. Sistema registra información y cierra la atención

médica (CU7).

Cursos Alternos

(2a) Si la ficha no existe, informa al Especialista y termina el CU.


Curso Normal


5. Tecnólogo ingresa el RUT del paciente. 6. Sistema encuentra la ficha médica, solicita

información sobre la fecha de la muestra, los

resultados del examen y diagnóstico en caso de

ser necesario.

7. Tecnólogo ingresa datos obtenidos de la

muestra y en caso de que aplique se ingresa el

diagnóstico.

8. Sistema registra información y cierra la ficha.

Cursos Alternos

(2a) Si la ficha no existe, informa al Tecnólogo y termina el CU.


Curso Normal


4. Especialista cierra la atención médica (CU3). 5. Sistema registra el cierre de la ficha y envía un

mensaje al SAM indicando el cierre de la

atención.

6. Sistema recibe confirmación de parte del SAM

de que se ha realizado la transacción y termina

el CU.

Cursos Alternos

(3a) Si el SAM no responde, se mantiene el registro del mensaje pendiente por ser emitido y genera una

alerta al administrador del sistema, quién debe cursar manualmente el proceso.

Como podemos ver, en los diferentes escenarios encontramos un lenguaje mixto, en donde nos podemos

referir de diferentes formas a los mismo conceptos, por lo que es importante no solo tomar lo que dice, sino

que formalizar también el concepto como tal, ya que en el diagrama de clases conceptuales es donde debe

quedar finalmente el concepto que será utilizado finalmente en el sistema.

El dominio se observa en el siguiente diagrama:


15

Este diagrama puede ser la primera aproximación para el futuro diseño de clases y por supuesto un insumo

importante para los siguientes artefactos y modelos de análisis y diseño.

MODELO DE COMPORTAMIENTO

En esta sección se describen los artefactos que describen el comportamiento del sistema.

Diagramas de Secuencia

Para especificar los diagramas de secuencia es importante hacerlos a través de los escenarios encontrados

en los casos de uso. Según lo expuesto en este problema, los escenarios alternos son sencillos, así que,

donde corresponda, se utilizarán los cursos alternos como parte del mismo diagrama.

Veamos el escenario del primer caso de uso:

Paciente

EspecialistaLaboratorista

Recepcionista

FichaDePaciente

Procedimiento Anamnesis

DetalleProcedimiento

+observaciones+resultados+diagnostico

DetalleAnamnesis

+datos_inspeccion+observaciones+indicaciones+otros

posee1

1

contiene

0..*

1

+cotiene

0..*

1

es-descrita-por

1

1

es-descrita-por

1

1

crea

0..1

1

ingresa

0..1

1

ingresa

0..1

1

DetalleDeFicha

+rut+nombre+direccion+telefono+email

es-descrita-por

1 1


16

Es posible observar en este diagrama que gran parte de la carga se la estaría llevando el objeto

DetalleDeFicha (adelantándonos para cuando lleguemos a los diagramas de estado). Sigamos con los demás

CU y sus respectivos diagramas:

Al igual que en el caso anterior, este diagrama no es más que una traducción del escenario realizado para el

CU. Veamos el siguiente:

: Recepcionista Sistema CatalogoDePacientes

: DetalleDeFicha

1 : validarRut()2 : pacienteExiste()

3 : ack

4

5 : ingresarDetalle()6 : nuevo()

78 : asociarDetalle()

910

Funcionario Sistema CatalogoDePacientes

1 : consultar()2 : buscar()

3

4


17

En este caso podemos ver que se complejiza un poco la lógica, sin embargo debemos destacar un par de

puntos.

1. Resumimos los 3 ingresos que existen en el escenario en 1 sola operación (con la lógica de que la

filla se llena sin registrar la información hasta el final).

2. La creación del objeto DetalleAnamnesis es porque según el modelo de dominio, DetalleDeFicha

solo sabe registrar DetalleAnamnesis a través de una Anamnesis (la cual puede ser generad dentro

de DetalleFicha como una línea de transacción).

3. Las operaciónes de consultar, en realidad es la misma utilizada en el CU2.

Sigamos con el siguiente CU:

: Especialista Sistema CatalogoDePacientes d : DetalleDeFicha

: DetalleAnamnesis

1 : consultar()

2 : buscar()

3 : d4

5 : registrarInformación()6 : crear()

7 : det

8 : registrarAnamnesis()

910


18

En este caso vemos una similitud muy obvia con el CU3, tanto así que a estas alturas podríamos

“generalizarlo” de manera de que sea más reutilizable. Sin embargo, para efectos prácticos, sigamos con el

análisis tal cual.

En el último CU analizado solo tenemos el hecho del cierre de la atención médica y en este caso son

operaciones hacia fuera del sistema, así que es poca la interacción.

Con estos diagramas completamos el análisis del comportamiento a través de las secuencias, y pasaremos a

ver los contratos.

Contratos de las Operaciones

Una vez que ya se han realizado todos los diagramas de secuencia, se debe comenzar identificado cuáles son

las operaciones principales para luego ir describiéndolas a través de la estructura planteada para los

contratos. Veamos entonces los contratos del problema.

: Laboratorista Sistema CatalogoDePacientes d : DetalleDeFicha

: DetalleProcedimiento

1 : consultar()2 : buscar()

3 : d

4

5 : registrarInformacion()6 : crear()

7 : det

8 : registrarProcedimiento()

910

: Especialista Sistema AgendaMedica

1 : cerrarAtención()

2 : cierreFicha()

3 : ack4


19

Operación: CO1. validarRut(rut)

Responsabilidad: Validar que el RUT exista dentro del catalogo de pacientes

Tipo o Clase: Sistema

Ref. Cruzadas: CU1

Notas: -

Excepciones: Si el RUT existe, se aborta el resto del CU

Salidas: -

Precondiciones - Exista una instancia r de tipo CatalogoDePacientes

Postcondiciones: - No se haya encontrado una instancia f de FichaDePaciente

dentro de r que tenga asociada una instancia d de

DetalleDeFicha que tenga como atributo rut el valor del

parámetro rut.

Operación: CO2. ingresarDetalle(rut, nombre, direccion, fono, email)

Responsabilidad: Crear y agregar la información básica del paciente a la ficha


Ref. Cruzadas: CU1

Notas: -

Excepciones: -

Salidas: -

Precondiciones -

Postcondiciones: - Se haya creado una instancia d de tipo DetalleDeFicha

- Se hayan fijado los atributos rut, nombre, dirección,

teléfono e email con los valores entregados por parámetro.

- Se haya creado una instancia f de tipo FichaDePaciente

- Se haya asociado d a f

Operación: CO3. consultar(rut)

Responsabilidad: Obtiene la información de la ficha del paciente a partir del

rut ingresado.


Ref. Cruzadas: CU2, CU3, CU5

Notas: -

Excepciones: Si la ficha no existe, devuelve un valor nulo.

Salidas: -

Precondiciones - Exista una instancia r de CatalogoDePacientes

Postcondiciones: - Se haya encontrado una instancia p de DetalleDePaciente

cuyo atributo rut sea igual al valor del parámetros rut.

Operación: CO4. registrarInformacion(objeto)

Responsabilidad: Registra en la ficha del paciente la información entregada en

forma de objeto.


Ref. Cruzadas: CU3, CU5

Notas: Objeto puede tomar valores de DetalleAnamnesis y


Excepciones: -


20

Salidas: -

Precondiciones - Exiasta una instancia d de DetalleDePaciente

Postcondiciones: - Se haya asociado objeto a d.

Operación: CO5. cerrarAtencion(especialista)

Responsabilidad: Envía una notificación al sistema de agenda médica

indicando el térmido de la atención del especialista.


Ref. Cruzadas: CU7

Notas: Utiliza XML para construir la llamada al SAM.

Excepciones: -

Salidas: Un mensaje intersistemas para el SAM

Precondiciones -

Postcondiciones: -

Como podemos ver en los contratos expuestos, se hicieron varias optimizaciones en las operaciones,

generalizando las que habíamos originalmente encontrado en los diagramas. Esto permitirá un menor riesgo

desde el punto de vista del diseño e implementación futura.

Diagramas de Estado

Como última parte del análisis vamos a realizar algunos diagramas de estados que nos permiten identificar

los cabios de estado de los objetos principales.

En particular, uno de los objetos que sufre cambios es la instancia de FichaDePaciente que representa a un

paciente particular. Veamos cómo queda el diagrama de estados en este caso (considerando todos los

contratos del modelo).

Como podemos ver en el diagrama, los estados en realidad son pocos, ya que no pasa por muchos cambios

(solo se ven las asociaciones dadas por los contratos).

Es importante hacer notar que, a pesar de que este sea una visión del análisis del comportamiento no

necesariamente es la única. Esto es muy importante desde el punto de vista del problema final, ya que si la

consistencia es buena, no requiere mayor perfeccionamiento.

Disponible

entry/fijarDetalleDePaciente

nuevo

En Llenado

do/asociarDetalle

[es atendido]


21

DISEÑO DEL SISTEMA

MODELO ARQUITECTÓNICO

En esta sección se describen las decisiones de la arquitectura que afectan a la organización de los programas

finales.

Diagrama de Componentes

La primera premisa para nuestro diagrama es que separaremos las capas de interfaz gráfica de las

funcionales (negocio) y operativa, es decir, utilizaremos un modelo de 3 capas de diseño arquitectónico.

La capa funcional estará compuesta de 3 componentes básicos y que son separados por su naturaleza:

Gestión de la Ficha (creación y consulta de la ficha de un paciente)

Gestión de la Consulta Médica (ingreso de anamnesis)

Gestión de los Procedimientos (ingreso de observaciones y resultados)

Ahora bien, tanto la capa Consulta Médica como la capa Procedimiento requieren trabajar con la ficha, por

lo que también existirán algunas dependencias entre ellas:

Como podemos ver, las interfaces que exponemos para la comunicación entre los paquetes nos definen

algunas operaciones que se realizarán en los diagramas de colaboración. De esta manera, estamos

obligando que las clases las debamos discriminar de acuerdo a la naturaleza del componente:

Ficha: Todas las clases que operen con la ficha.

Consulta Médica: Todas las clases que operen con la anamnesis.

Procedimiento: Todas las clases que operen con los procedimientos.

Es fácil ver que el centro del negocio está en las clases que controlan las fichas de los pacientes y que el

resto en realidad no es tan relevante como habíamos pensado, por lo que nos sugiere que en realidad no

necesitamos tantos componentes, sino que solo uno principal y que contenga todas las operaciones del

sistema con la ficha, sin embargo, para el ejemplo, mantendremos la consistencia con el diseño realizado y

seguiremos manteniéndolo por separado.

Lo que nos queda ahora es exponer los servicios que van hacia la interfaz gráfica y completar el diagrama

con la capa completa:


22

Las operaciones expuestas en la capa funcional (que particularmente son solo las de sistema) no son para

que las use el usuario final directamente, sino que para que sean gatilladas a partir de la interfaz. De esta

manera, podríamos (y optimizando el diagrama anterior) organizar el sistema de la siguiente manera:

Lo que finalmente describimos es una componente gráfica por lugar donde funcionará el sistema y

relacionamos con qué servicio expuesto se comunican dichas componentes directamente. Así podemos

discriminar cómo organizar también los programas de la interfaz gráfica fácilmente.

Por último, debemos también comunicarnos con la capa de datos, la cual es la que gestiona las tablas de la

base de datos y muestra los servicios expuestos necesarios para trabajar con la capa funcional. Este sería

entonces el diagrama final de componentes del sistema:


23

Como podemos notar, el Registro de Fichas es una componente que representa la interacción con la base de

datos directamente. De esta manera, cuando se desea, por ejemplo, realizar una búsqueda de una ficha por

el rut, es necesario que se obtenga la ficha desde la base (a través de un select de la tabla respectiva).

En particular, solo se exponen 2 servicios básicos que son “consultar” y “registrar” (similar a un select y un

update en SQL), los cuales son consumidos solo por la componente de Ficha.

MODELO DE DISEÑO

En esta sección se describe en detalle el diseño del sistema a partir de las operaciones de éste y

completando con una vision técnica de las clases de diseño.

Diagramas de Colaboración

Los diagramas de colaboración realizan las interacciones necesarias para que lo objetos colaboren bajo el

objetivo de cumplir las operaciones de cada caso de uso.

Operación: CO1. validarRut(rut)

Responsabilidad: Validar que el RUT exista dentro del catalogo de pacientes


Ref. Cruzadas: CU1

Notas: -

Excepciones: Si el RUT existe, se aborta el resto del CU

Salidas: -

Precondiciones - Exista una instancia r de tipo CatalogoDePacientes

Postcondiciones: - No se haya encontrado una instancia f de FichaDePaciente

dentro de r que tenga asociada una instancia d de

DetalleDeFicha que tenga como atributo rut el valor del

parámetro rut.


24

Lo primero que debemos buscar en este caso es qué objeto debe ser el controlador de la operación. Es fácil

ver que como no tuvimos nunca una clase que represente nada físico del sistema, siempre utilizamos

“Sistema” como tal. Así que, como estamos hablando de aplicar el patrón, deberemos decidir si:

Lo utilizamos como un controlador general del sistema (SistemaControlador, por ejemplo).

Lo utilizamos como un controlador modular (RegistroControlador, por ejemplo).

Para que podamos probar los controladores modulares, en este caso elegiremos la segunda opción. Además,

que el ejemplo es bastante “bueno” para que podamos separar las funciones en cada ámbito de la atención

médica.

Si seguimos aplicando otros patrones, por ejemplo, para validar el rut debemos identificar de quién es la

responsabilidad de conocer o mantener conocimiento de las fichas de los pacientes. Con el patrón de

experto podemos determinar que ese es el CatálogoDePacientes, que ya teníamos identificado

anteriormente. Por último, sabiendo que el experto de información de conocer el rut de un paciente es

DetalleDeFicha, y aplicando el patrón de cadena de responsabilidad (de GoF), podemos llevar la

responsabilidad desde el controlador hasta el mismo objeto para entregar el valor del rut pidiéndole a

CatalogoDePacientes, luego a FichaDePaciente y que realice la validación si existe una ficha (esperamos

respuesta negativa por supuesto).

De esta manera, el primer diagrama de colaboración quedaría como sigue:

De una forma análoga, podemos revisar el segundo contrato:

Operación: CO2. ingresarDetalle(rut, nombre, direccion, fono, email)

Responsabilidad: Crear y agregar la información básica del paciente a la ficha


Ref. Cruzadas: CU1

Notas: -

Excepciones: -

Salidas: -

Precondiciones -

Postcondiciones: - Se haya creado una instancia d de tipo DetalleDeFicha

- Se hayan fijado los atributos rut, nombre, dirección,

teléfono e email con los valores entregados por parámetro.

- Se haya creado una instancia f de tipo FichaDePaciente

- Se haya asociado d a f


25

Es fácil ver que debemos primero buscar si el anterior controlar de las operaciones aplica en ésta, y la

respuesta es sí, porque seguimos en el mismo módulo (CU) de registro de paciente.

Por otro lado, como debemos crear un DetalleDeFicha, debemos buscar el mejor creador ese tipo de

objetos. Como sabemos, la clase que usa más estrechamente estos objetos es FichaDePaciente, sin embargo

también es parte del contrato crear un objeto de ese tipo, así que podemos realizar esa creación en cadena,

delegando la responsabilidad al mejor creador de FichaDePaciente, y que se lo podemos entregar de

inmediato al CatalogoDePacientes (ya que él es quien necesitará utilizar esas instancias de aquí en

adelante).

Por último, finalmente necesitamos obtener el experto de la información del detalle del paciente y es

DetalleDeFicha, lo que nos permite mejorar la creación de ese tipo de objetos delegándole toda esa

información a su creador (FichaDePaciente) y permitiendo que la creación se lleve a cabo en una sola

responsabilidad encapsulada.

El diagrama de colaboración quedaría así:

Notemos que en este caso particular, la existencia de la relación con el catálogo no estaba definida en el

contrato, pero la aplicación de los patrones de diseño nos permitió descubrir esta relación. Por otro lado

tampoco aparece en forma explícita el cumplimiento de la postcondición de asociar d a f, pero por la

delegación de la creación quedan asociadas esas instancias.

El siguiente contrato es:

Operación: CO3. consultar(rut)

Responsabilidad: Obtiene la información de la ficha del paciente a partir del

rut ingresado.


Ref. Cruzadas: CU2, CU3, CU5

Notas: -

Excepciones: Si la ficha no existe, devuelve un valor nulo.

Salidas: -

Precondiciones - Exista una instancia r de CatalogoDePacientes

Postcondiciones: - Se haya encontrado una instancia p de DetalleDePaciente

cuyo atributo rut sea igual al valor del parámetros rut.

Para buscar el controlador, primero debemos consultarnos si se aplica el anterior. En este caso no lo es,

porque no estamos en el registro de un paciente, pero tampoco estamos en algún CU particular, ya que esta

operación es transversal a los CU2, CU3 y CU5.


26

A pesar de ello, como la naturaleza de la operación tiene que ver con obtener la información de la ficha del

paciente, podremos crear un nuevo controlador modular llamado FichaControlador, que permite realizar las

operaciones básicas de consulta o manipulación de la ficha1.

Por otro lado, como estamos buscando una ficha particular, debemos aplicar exactamente la misma idea de

lo aplicado en el CO1. De esta manera, podemos cambiar nuestra primera realización para mejorar y aplicar

este contrato en forma equivalente.

Así, las colaboraciones corregidas para aplicar esta operación también serían:

Por último, la colaboración del CO3 sería:

Como podemos ver, la naturaleza de la operación es la misma, pero la respuesta que se espera es diferente

del controlador. El siguiente contrato es:

Operación: CO4. registrarInformacion(objeto)

Responsabilidad: Registra en la ficha del paciente la información entregada en

forma de objeto.


Ref. Cruzadas: CU3, CU5

1 Note que las operaciones anteriormente analizadas también tienen que ver con la ficha, por lo que una

mejora sería juntarlas todas en este mismo controlador, quedando 3 operaciones (CO1, CO2 y CO3).


27

Notas: Objeto puede tomar valores de DetalleAnamnesis y


Excepciones: -

Salidas: -

Precondiciones - Exiasta una instancia d de DetalleDePaciente

Postcondiciones: - Se haya asociado objeto a d.

Primero, esto tiene diferentes matices, ya que está siendo generalizada una operación que no tendrían el

mismo controlador, así que serían vistas en forma diferente (como 2 contratos aparte).

De esta forma, el primero será recibido por ConsultaControlador, el cual manejará las operaciones realizadas

por el especialista en la consulta médica. La otra será gestionada por ProcedimientoControlador, que tiene

que ver más con las operaciones realizadas durante un procedimiento médico.

Ahora si comenzamos a ver el primer caso como registrarAnamnesis(…) tendremos el detalle necesario para

aplicar los patrones de creador y experto que nos lleve al primer diagrama de colaboración:

De una manera análoga podemos realizar la operación respecto al registro del procedimiento quedando el

diagrama de la siguiente forma:

Lo relevante de este análisis, es que como el detalle necesario es por cada una de las clases, es necesario

que hayamos separados las operaciones para cada caso, ya que, tal como vimos en clase, se convertirán en

los métodos de cada una de las clases (y las clases destino son las mismas).

Por último, veamos el último contrato del dominio:


28

Operación: CO5. cerrarAtencion(especialista)

Responsabilidad: Envía una notificación al sistema de agenda médica

indicando el término de la atención del especialista.


Ref. Cruzadas: CU7

Notas: Utiliza XML para construir la llamada al SAM.

Excepciones: -

Salidas: Un mensaje intersistemas para el SAM

Precondiciones -

Postcondiciones: -

Como podemos ver, esta operación tiene que ver con la consulta médica (y de hecho es una operación de

secundaria, ya que es una notificación). Sin embargo, este contrato no aporta información al sistema como

tal, porque solo elabora un mensaje a un sistema externo, lo que no se ve reflejado en las postcondiciones.

Diagrama de Clases de Diseño

Una vez analizado por completo las operaciones del sistema, podemos plantear paso a paso el diagrama de

clases de diseño. Veamos cómo va quedando:

Con un simple paso por los diagramas de colaboración, podemos identificar las siguientes clases:

En el diagrama, además pusimos desde ya los atributos que vienen desde el diagrama de clases

conceptuales, ya que a priori sabemos que esos valores se mantendrán para el diseño.

El siguiente paso es completar con la información de los tipos de datos de los atributos y sus visibilidades

correctas:


29

Es fácil detectar que la información almacenada es mayormente de texto, ya que todos los datos generados

por los especialistas médicos son de ese tipo.

Siguiendo con las definiciones aprendidas en la técnica de creación del diagrama de clases de diseño,

podemos obtener ahora los métodos de cada una de las clases a partir de los diagramas de colaboración

dibujados en la sección anterior. Así, podemos asociar los siguientes métodos encontrados a las siguientes

clases:

FichaControlador: validarRut, ingresarDetalle, consultar.

ConsultaControlador: registrarAnamnesis.

ProcedimientoControlador: registrarProcedimiento.

CatalogoDePacientes: buscar, crearFichaDePaciente.

FichaDePaciente: consultarRut, crear, crearAnamnesis, crearProcedimiento.

DetalleDeFicha: getRut, crear.

Anamnesis: crear.

DetalleDeAnamnesis: crear

Procedimiento: crear

DetalleDeProcedimiento: crear

De esta manera, el diagrama quedaría de la siguiente forma detallado:


30

El paso siguiente es incorporar las asociaciones de acuerdo a la cercanía de las clases del diagrama. Esto es

bastante rápido de identificar porque basta con responder cualquiera de las 3 situaciones indicadas

anteriormente:

A es un creador de objetos de tipo B

A agrega objetos de tipo B

A necesita mantener conocimiento de los objetos de tipo B

De esta manera, el diagrama que estamos completando pasaría a ser de la siguiente forma:


31

Como podemos ver incorporamos también el concepto de composición en varias de esas asociaciones, por

el hecho de ser creadores de otros objetos.

Observemos por un momento la relación entre Procedimiento – DetalleDeProcedimiento y Anamnesis –

DetalleDeAnamnesis. Podemos notar una semejanza con la caja del supermercado, porque en este caso

Procedimiento y Anamnesis están jugando el papel de “línea de venta”, por lo que es posible resumir esa

sobrecarga de clases (ya que ambas hacen lo mismo) en una sola que permita almacenar ambos tipos de

registros.

Para hacer esto, y aprovechar de utilizar la generalización en el diagrama, incorporaremos la clase

RegistroDeFicha (que reemplazará Procedimiento y Anamnesis como “línea de venta”) y una clase

DetalleDeRegistro que será la superclase que incorporará ambos tipos de registros.

Además, si vemos la forma en que se comportan las operaciones de las clases, podemos notar que no

existen dependencias, por lo que no debemos incorporar más detalle y podemos mostrar finalmente el

siguiente diagrama de clases de diseño como una primera versión de nuestro SEFP:


32


33

PREPARANDO LA IMPLEMENTACIÓN

MODELO DE IMPLEMENTACIÓN

En esta sección se describen las labores de preparación de la codificación.

Diagrama de Clases de Implementación

Describiremos el diagrama de clases de implementación, utilizando el DCD de la unidad anterior. Para ello

entonces pasaremos por los pasos básicos indicados en la técnica de desarrollo del modelo respectivo.

Primero, comencemos normalizando los tipos de datos al lenguaje elegido (Java). El diagrama de clases

quedaría algo parecido a lo siguiente:

Luego de realizado esto, se van describiendo las clases a través de anotaciones en el diagrama considerando

no solo los atributos explícitos, sino que también operaciones complejas y atributos de asociación.

Para el caso de las asociaciones múltiples que existen en este diagrama, vamos a utilizar una estructura

Vector de objetos para que vaya acumulando los objetos del tipo de destino sin necesidad de conocer el

número de elementos que finalmente vamos a registrar.

De esta manera, tendremos un diagram parecido a este:


34

El siguiente paso (que aparece en la técnica vista en este capítulo) indica incorporar lógica de programación

en el diagrama, sin embargo, dada la complejidad de éste, vamos a optar por escribir el código (estructura

de clases) a partir de lo ya obtenido, y luego incorporar lógica programática.

Estructura de Clases

La estructura obtenida corresponde a las clases, con sus atributos y las firmas de todos los métodos

identificados. Sin embargo, vamos a aprovechar de incorporar lógica en los métodos de las clases según

corresponda.

A continuación el listado de las clases desde la menos acoplada a las más acoplada:

public class DetalleDeAnamnesis {

private String datos_inspeccion;

private String observaciones;

private String indicaciones;

private String otros;

public DetalleDeAnamnesis(String inspeccion, String observaciones,

String indicaciones, String otros) {

this.setDatos_Inspeccion(inspeccion);

this.setObservaciones(observaciones);

this.setIndicaciones(indicaciones);

this.setOtros(otros);

}

private void setDatos_Inspeccion(String inspeccion) {

this.datos_inspeccion = inspeccion;

}

private void setObservaciones(String observaciones) {

this.observaciones = observaciones;

}

private void setIndicaciones(String indicaciones) {

this.indicaciones = indicaciones;

}

private void setOtros(String otros) {

this.otros = otros;

}

}


35

public class DetalleDeProcedimiento {

private String observaciones;

private String resultados;

private String diagnostico;

public DetalleDeProcedimiento(String observaciones, String resultados,

String diagnostico) {

this.setObservaciones(observaciones);

this.setResultados(resultados);

this.setDiagnostico(diagnostico);

}

private void setObservaciones(String observaciones) {

this.observaciones = observaciones;

}

private void setResultados(String resultados) {

this.resultados = resultados;

}

private void setDiagnostico(String diagnostico) {

this.diagnostico = diagnostico;

}

}

public class DetalleDeFicha{

private int rut;

private String nombre;

private String direccion;

private String fono;

private String email;

public DetalleDeFicha (int rut, String nombre, String direccion,

String fono, String email) {

this.setRut(rut);

this.setNombre(nombre);

this.setDireccion(direccion);

this.setFono(fono);

this.setEmail(email);

}

public int getRut() {

return this.rut;

}

private void setRut(int rut) {

this.rut = rut;

}

private void setNombre(String nombre) {

this.nombre = nombre;

}

private void setDireccion(String direccion) {

this.direccion = direccion;

}

private void setFono(String fono) {

this.fono = fono;

}

private void setEmail(String email) {

this.email = email;

}

}

public class Procedimiento {

private DetalleDeProcedimiento detalle;

public Procedimiento(String observaciones, String resultados,


this.detalle = new DetalleDeProcedimiento(observaciones,


36

resultados, diagnostico);

}

}

public class Anamnesis {

private DetalleDeAnamnesis detalle;

public Anamnesis(String inspeccion, String observaciones,


this.detalle = new DetalleDeAnamnesis(inspeccion, observaciones,

indicaciones, otros);

}

}

public class FichaDePaciente {

private DetalleDeFicha detalle;

private Vector procedimientos;

private Vector anamnesis;

public FichaDePaciente(int rut, String nombre, String direccion,


this.detalle = new DetalleDePaciente(rut, nombre, direccion,

fono, email);

}

public DetalleDePaciente consultarRut(int rut) {

return this.detalle;

}

public void crearAnamnesis(String inspeccion, String observaciones,


Anamnesis anam = new Anamnesis(inspeccion, observaciones,


this.anamnesis.addElement(anam);

}

public void crearProcedimiento(String observaciones, String resultados,


Procedimiento proc = new Procedimiento(observaciones,

resultados, diagnostico);

this.procedimientos.addElement(proc);

}

}

public class CatalogoDePacientes {

private Vector fichas;

public FichaDePaciente buscar(int rut) {

for(int i=0; i<this.fichas.size(); i++) {

if (this.fichas.elementAt(i).getRut() == rut)

return this.fichas.elementAt(i);

}

}

public void crearFichaDePaciente(int rut, String nombre,

String direccion, String fono, String email) {

FichaDePaciente ficha = new FichaDePaciente(rut, nombre,

direccion, fono, email);

this.fichas.addElement(ficha);

}

}

public class ConsultaControlador {

private FichaDePaciente paciente;

public void registrarAnamnesis(String inspeccion, String observaciones,


this.paciente.crearAnamnesis(inspeccion, observaciones,



37

}

}

public class ProcedimientoControlador {

private FichaDePaciente paciente;

public void registrarProcedimiento(String observaciones,

String restultados, String diagnostico) {

this.paciente.crearProcedimiento(observaciones, resultados,

diagnostico);

}

}

public class FichaControlador {

private CatalogoDePacientes fichas;

public void validarRut(int rut) {

FichaDePaciente f = this.fichas.buscar(rut);

}

public void ingresarDetalle(int rut, String nombre, String direccion,


this.fichas.crearFichaDePaciente(rut, nombre, direccion,

fono, email);

}

public void consultar(int rut) {

FichaDePaciente f = this.fichas.buscar(rut);

}

}

caso de estudio centro médico y laboratorio

Documents