Esto se resolvería mejor con una base de datos, peor vamos si tienes que operar con objetos, se debe considerar ciertas tablas reunidos en los objetos que has definido.
Un modo eficiente sería más complejo, porque requeriría varios objetos más, tales com un despachador de citas y otro de eventos y algunos notificadores, varias colecciones, etc...

Veamos... la mejor forma es mirar la cuestión de forma lógica es suponer la situación 'real', en 'tiempo real'. Un ejemplo...

El paciente tiene un problema médico, llama por teléfono a la clínica y reclama una cita con el médico que corresponda (quizás tenga uno asignado).
El día de la cita, acude al médico, y relata su problema.
El médico tras escuchar al paciente, decide que se le realice una analítica y le da cita para la analítica o bien lo pone en cola del laboratorio quienes le llamarán cuando encuentren hueco...
El paciente regresa para que le hagan la analítica (extracción de sangre, entrega de orina... por ejemplo).
El laboratorio, toma la muestra (o quizás otro personal de la clínica, o en otro lado), el caso es que la muestra llega al laboratorio donde se analiza (donde recogen las muestras y donde se realicen las analíticas podrían ser sitios diferentes).
Al paciente se le insta a regresar x día, para los resultados de la analítica, o se le señala que ya se le llamará para indicarle la fecha de recogida (o bien le deriva a la cita del médico, quien le entrega los resultados).
Una vez que el laboratorio concluye la analítica entrega los resultados (digamos que deposita un informe en el ordenador, asociado al historial del paciente).
Cuando el paciente tenga fecha de entrega o bien va a recoger los resultados al laboratorio y luego vuelve a pedir cita al médico, o mejor acude al médico quien ya tiene los resultados en su ordenador, y le indicará el tratamiento o lo que proceda.

Viendo el transcurso, puede dibujarse el flujo... y al mismo tiempo crearse una primera aproximación a los objetos necesarios.

Paciente: Básicamente tendrá algunos datos y lo demás serán métodos.
  Datos: informaticos del paciente, nombre apellidos, id de paciente, historia clínica (una tabla con su historial).
  PedirCita: el paciente reclama una cita. podría ser genérica rellenando ciertos campos, ó podría reclamar por un especialista específico. Normalmente es lo primero.
  AcudirACita: para explicar su problema al médico, para recoger la analítica, recoger medicación, para exploración, toma de muestras...
  AsignarMedico, CambiarMedico: Lo razonable es que si tiene asignado un médico, se le asocie un id al médico, en tal caso, sus peticiones de cita, podría llevar tal id. Mejor aún, es que el propio sistema verifique si el aciente (con su nombre y apellidos y número médico tiene ya asociado un médico, y si no es el caso, se le propone un formulario más amplio para rellenar (darse de alta en dicha clínica, ser socio, etc..)...
  ConsultarCita: El paciente consulta si tiene citas pednientes, en tal caso se le devuelven una lista con las fecha, hora, lugar y especialista...

Medico:
   Datos: Nombre y apellidos, id en la clínica, id de colegiado, especialidad, horario, etc...
   Agenda: Es una colección en realidad, Es una selección de citas, para el día presente, indica que citas tiene a qué hora y con qué paciente. En la propia agenda se señala la razón de la cita: (entevista al paciente, entregar análisis, seguimiento de un tratamiendo, etc..)
   ConsultarAgenda: Dados unos datos, devolver las fechas que se encuentren (por ejemplo, dados un nombre de paciente y apellidos, o su id de paciente). Varios tipos de consulta... que serán sobrecargas.
   SolicitarAnalisis: El médico solicita un ánalisis para un paciente, para ello adjunta: id del médico, id del paciente, id del tipo de análisis, como devolución de la solicitud, podría recibirse la cita exacta o aproximada, si es aproximada, será la gestión del  laboratorio quien mediante el id del paciente, obtenga su tf. para indicarle cuando proceda la fecha exacta para el ánálisis, o bien la enfermera del médico que al recibir la notificación de la fecha del análisis (en la agenda del médico), deba llamar al paciente para citarle en el laboratorio...

Laboratorio: El laboratorio debe gestionar las citas para la recogida de muestras y (quizás también) las citaciones para la entrega de los resultados de la analítica. Tambien tendrá un método de consulta de dichas citaciones y un método de entregar resultados cuando éstos estén listos.
    Datos: id de laboratorio, lista de Ids de analíticas que puede realizar, etc... (en general si la clínica dispone de un solo laboratorio, parece que el id no fuera necesario, pero es conveniente prever que eso cambie a futuro, y mientras la tabla de IDs no va a crecer, luego no importa que se añada aunque no tenga un uso intensivo de momento, es previsión de futuro).
    Agenda: Igual que el médico tiene citas a x hora, el laboratorio tiene las suyas...
    CitacionesRecogidaMuestras: Dada una cola de solicitudes de analíticas, ofrece fecha y hora para cada tipo de analítica (y como se dijo en un apartado previo, o bien desde aquíse gestiona directamente la citación del paciente, obien se devuelve al médico que lo solicitó como parte de su agenda y ya desde allí se informa. Parece más sensato que fuera desde aquí, en orden a que el paciente pueda si fuera preciso, alterar la fecha (retrasarla), si no le va bien la fecha y hora propuesta...
    CitacionesEntregaAnalíticas: Como lo previo, otra cola que gestiona las citas de los pacientes cuando la analítica ya está lista. Concordando con el paciente una fecha y hora, activa una cita en la agenda del médico que figura en la solicitud y entrega de la analítica. abrá analíticas que quizás sea el paciente quien deba recogerlas personalmente y con ella pedir cita al médico para su evaluación y tratamiento, etc... El sistema puede variar en función de si es ficiticio, o si un caso real exige uno u otro modelo o  está abierto a opciones.
    ConsultarCitas: Indicando la naturaleza de la cita (etega de muestras del paciente, o entrega de los resultados). Devuelve si hay cita para tal id de paciente, dados unos datos (el propio id, historia clínica, nombre y apellidos + tf., etc...) y desde aquí no se debería poder modificar ni eliminar citas, solo consultar...
    ModificacionCitas: Si un paciente quiere cancelacir, adelantar o posponer una cita, tras tener los datos de su cita (sea porque la recibió de 'citacionesRecogida...' ó citacionesEstrega...' o mediantye ConsultarCitas, puede alterar la fecha.
    EntregaDeAnaliticas: El laboratorio tras competar una analítica debe entregar el resultado. Lo mejor es que el resultado se quede en la base de datos y en la Agenda del médico se añada un ítem de consulta al historial clínico del paciente referido. La enfermera del médico, cada díal o primero que hará por la mañana es revisar los ítems pendientes de revisar y solicitar la citación al paciente a la consulta del médico para entregarle los resultados, indicarle el tratamiento, etc... otra alternativa como se dijo, es que se entregara directamente al paciente. Si esto último, no será el sistema usado entonce sla funcionalidad de: "CitacionesEntregaAnalíticas", debería retirarse de este objeto y ser añadido a la del médico.
    Procesar: Se supone que habrá un método procesar analítica, en realidad es un hueco cde tiempo en la cita, tal que el profesional en el laboratorio retira una cita para efectuar la analítica y pulsa 'entregar' a su finalización, luego pulsa otra vez en procesar para recibir la siguiente analítica... Si la agenda es la lista de citas (tareas), esto sería marcar que la está atendiendo, es decir responde al sistema... que aitende una y al final cuando para cerrarla modifica el estado, indicando el resultado que porceda... por ejemplo: Paciente no vino, muestra desechada, analitica finalizada, etc...

Clinica: La clínica enlaza todo, debiera ser el objeto principal. Relaciona pacientes con médicos y médicos con laboratorio. La base de datos rige en la clínica, los demás objetos consultan a la clínica, para todo.    
    PedirCita: Recoge los datos del paciente, nombre apellidos o id de paciente, y si es posible, especialista para el que pide cita, si no será su médico asociado y naturaleza de la consulta...
    AltaPaciente: Si un paciente solicita una cita y no tiene Id en la clínica se le da de alta en la misma como paso previo a la cita.
    AltaCita: Una vez realizada la petición de cita, se realiza una consulta a la Agenda del médico (cuyo id ya quedo claro) en busca de un hueco libre en la fecha que solicita el paciente, si la hay se la da si no, s ele propone la primera fecha y hora libre, etc... Si acepta finalmente se inscribe la cita en la agenda del médico.
    AltaMedico: Cuando un médico se adjunta a la clínica.
    AltaLaboratorio: Lo mismo, cuando se adjunta un nuevo laboratorio a la clínica

   (Nota: Aunque se llamen Alta... también debiera gestionar la baja, si resultare complejo, entonces mejor que sea una función aparte). El alta, genera el Id en cada caso (de paciente, de médico, de cita, de laboratorio, de analítica, etc...

Analitica: Es un objeto que recoge lo preciso que se reclama.
     Datos: Id paciente, id medico, id analisis, fecha citacion recogida de muestras, fecha aprox de entrega de resultados (sin confirmar). Id analitica previa relacionada, Id analítica posterior relacionada.
     Resultados: Texto (y/o imágenes)  que describen el resultado de los que se solicitó.
     Estado: un valor de enumeración que describa el estado del ítem: Recibido solicitud de analítica, buscando fecha para citar al paciente entrega de meustras, pactando fecha de entrega de muestras con el paciente, espera hasta fecha de cita, entrega de muestras realizada, envio al laboratorio (especialista que realiza el análisis), analizando muestras, analitica realizada, pactar fecha de entrega de resultados, espera hasta fecha de entrega, entrega realizada, pactar fecha citacion medido para evaluacion, espera hasta dicha fecha, evaluación y tratamiento de los resultados (cuando el paciente acude ya al médico) y desde aquí deriva hacia otro frente si contínúa se abre otro expediente con el que se relaciona
     Fecha de estado: Cada estado puede a su vez tener un campo fecha, que señala la fecha y hora en que pasa de un estado a otro, así puede hacerse un seguimiento si resulta preciso.
     EstadoFinal: Estado que indica que sucedió tras que el médico diera los resultados al paciente. Podría ser: finalizado, o podría ser solitatud de una analítica adicional, o podría ser nueva analítica tras 3 meses, ingreso en clínica, etc... (incluso fallecimiento dle paciente antes o durante el proceso).

Imaginemos una aplicación... la interfaz de la misma son los datos externos, crudos del paciente. Por dentro hay un objeto paciente, el objeto paciente actúa sobre el objeto clínica, en general entregando una referencia del objeto paciente
    
Básicamente tu concepto está bien, aunque hay algunas inconsistencias y la manera de evitar lo que temes es usar colas que quedan ocultas al resto de objetos. Dichas colas actúan temporizadas, resuelta una tarea de la cola se toma la siguiente, la propia tarea mantiene una referencia al objeto al que debe entregar los resultados (en forma de evento)...

Por ejemplo: Paciente.AddAnalisis(a), no es correcto.
Lo razonable sería: Laboratorio.ModificacionCitas(operacion = "ADD", analitica a)
A esto se ha llegado tras el "Analitica a = Médico.CrearAnalitica(IdMedico, IdPaciente, IdAnalitica, Motivacion)" // un texto del médico describiendo textualmente lo que sea preciso. El id Analítica identifica que se reclama, probablemente sea una confunción y requiera más parámetros un id podría representar simplemente una espcialidad y otro id más específico , las variedades de esa especialidad, por ejemplo una analítica de sangre puede solicitar 2-3-4 decenas de parámetros, luego el id, sería un entero donde cada bit indica si uno de esos analisis se requieren: hemoglobina, colesterol, glóbulos blancos, plaquetas, etc...
Y para llegar al 'CrearAnalitica, ants se ha hecho un Clinica.PedirCita (paciente p, motivo m)
Motivo podría ser otro pequeño objeto, qeu rápidamente aclare la razón de la cita al médico, incluso un cuestionario relleno, o solo un texto, o unos pocos atributos, tipo: Ya ha realizaod una consulta previa por el mismo motivo?.
Y para llegar a PedirCita, el paciente ha creado el objeto paciente rellenando su datos.

Paciente p = Clinica.Login(Nombre, apellidos, idPaciente) // si id paciente=vacio, se entiende un alta, o bien que no recuerda su id, en cuyo caso si existe algún paciente con ese nombre y apellidos se le podrá indicar que elija entre: Ya soy paciente de esta clínica y entonces pedir su número de identificación personal (en España se llama DNI, en otros lares cédula de identidad) o incluso el tf. (por si hay más de 1 perosna coincidente en nombre y apellidos), o bien No soy cliente aún en esta clínica, y solicitarle que rellene mas datos o bien informarle que al encuentro de su cita deberá rellenar más datos...


Más adelante... cuando al paciente se le da la cita y acude al médico.

Como ves a la hora de ir describiendo en pseudocódigo ya te van saliendo otros objetos... Cita: es un objeto que recoge los siguientes datos:
    Idcliente (lo relaciona con Paciente, mediante él tenemos acceso a más datos del paciente).
    IdMedico: (ídem con médico).
    Motivo: Razón de la citya, una enumeración... consultamedico, entregamuestras, recogidaresultados
     Estado: de la cita... otra enumeración que señala las fases por las queatraviesa, la gestión interna actúa en función de este estado.
     FechaProgramada: obvio...

Igualmente Citas es una colección de citas. Hay más colecciones también obvias, como Pacientes, que es donde mediante el IdPaciente entrega un objeto paciente. El ide puede ser un hash obtenido a partir de algunos de sus datos: nombre, apellidos, DNI, telefono, algún número de registor interno y algún dato que permanece en propiedad de la clínica.
También es obvio que habrá una colección Medicos, y Laboratorios y que sus respectivos Ids, hacen lo priopio que para paciente.
Medicos, Citas, Pacientes, Laboratorios, Analiticas, todas son un mismo objeto colección que se diferencia exclusivamente por el tipo de objeto que almacenan, los métodos que tienen son los mismos, Add, Remove, GetById, GetByName, GetByETC... y todas esas colecciones son privadas dentro del objeto clínica...
Los objetos "Agenda", también son una colección pero algo distinta es una selección de 'citas' ó 'Analíticas' para el día vigente, asociado a una fecha específica y quizás duración' (tiempo concedido aprox. para ello).
Ahora que ves claro las colecciones, puesdes ver más claro las inconsistencias que te decía... laboratorio, no requiere métodos addMedico, addPaciente... laboratorio, recibe analiticas, en un estado dado y las entrega en otro estado, conocerá el número de analiticas pendientes o el de servidas, y tendrá la Agenda del día...

El problema es que describir un entorno completo en este campo es tan grande como uno quiera hacerlo o tan simple como también uno quiera hacerlo, pero a buen seguro te saldrá una veintena de objetos para manejarlo de modo eficiente...

Además es preciso tomar algunas decisiones sobre algunos aspectos para elegir un modelo cuando hay varias opciones (como los casos que he planteado respecto de la forma de 'entregar los resultados', o formalizar las citas a través de la enfermera del médico (que se´ria lo más personalizado para el paciente), ó centralizado desde el objeto Citas (que sería lo más óptimo, pero más rígido), ó que las realice el departamente especializado al que se recurre (laboratorio, por ejemplo para analíticas), que es lo más óptimo de cara al profesional y la gestión interna eficiente del tiempo). Dichas decisiones determinan la forma, en que se opera, los objetos que deben crearse y la relación o 'trazado' que han de tener las llamadas a funciones...

Creo que ya tienes para inspirarte y avanzar, luego si tienes alguna duda específica, plantéala...

Muchas gracias a ambos. Demore en responder porque estaba procesando todo, mas lo que me respondieron tambien en stackoverflow.

Me han aclarado la mente, tan mal estaba que hasta formule mal la pregunta inicial, en realidad tendría que haber sido sobre como definir quien debe implementar cada requisito del sistema, pero lo que me respondieron me sirvio mucho, la conclusión es que tengo que sentarme a leer sobre patrones, y en particular sobre GRASP.

Supongo que toda mi confusión viene porque en una materia de la facultad nos hicieron desarrollar una aplicación con JavaEE donde las entidades eran solo modelos de datos, y toda la logica estaba ubicada en otra capa. Al parecer esto se conoce como "Anemic domain model".
De ahi que no podia conectar en mi cerebro otra forma de ver la orientacion a objetos, segun wikipedia ese modelo es anti-oop.


NEBIRE, simplemente gracias por el analisis tan completo.

WhiteSkull en cuanto a que Laboratorio tendria que ser una entidad estatica es cierto, segun el escenario el sistema es para un solo Laboratorio/Hospital, de todas formas entiendo que NEBIRE hizo un analisis mas completo, suponiendo algunas otras cosas y por eso su diseño es diferente.
Tambien tenes razon sobre lo de devolver el paciente, me olvide de aclarar que en otro ejercicio me lo pedian que lo incluya, a igual que con los medicos.


Ahora tengo otra duda con respecto al diseño/arquitectura como lo plantee inicialmente, dado que el sistema debe poder devolver un medico y un paciente si el usuario se lo pide, y suponiendo que uno quiere saber los analisis de un paciente y los analisis que un medico solicito.
Cuales serian las formas correctas de modelar esto?

• 1- Podria hacer que paciente y medico conozcan cuales son los analisis en los que participan, pero para ello tendria que implementarles un metodo addAnalisis() a ambos, y eso implica que no tengo forma de contolar que al agregar un analisis a un paciente, tambien se lo haga al medico que lo solicito. Es decir, podria, pero nada quita que en alguna parte del programa alguien llame a Paciente::addAnalisis() y pase por alto hacerlo tambien al medico, y que paciente se encargue de cargar al medico y viceversa me generaria problemas de acoplamiento
• 2- Lo de arriba me lleva a pensar que podria generar una clase que funcione como repositorio de analisis, y que nunca este expuesta fuera de Laboratorio, Paciente y Medico. De esta forma, al llamar a Laboratorio::addAnalisis(), cargaria el analisis al repositorio, y luego Paciente::getAnalisis() haria una consulta al repositorio. De esta forma me evitaria tener los metodos Laboratorio::getAnalisisByPaciente() y Laboratorio:getAnalisiByMedico()
  En parte seria plantear lo mismo que puse en mi primer post pero de una forma mas elegante, sin sobrecargar demasiado a Laboratorio