Database design for cancer mouse models
As I said in my previous comment, you should have two main tables. 


Observation (the origin of all cases)
Clinical_case (linked to an observation - note that "case" is an SQL keyword).


It appears to me that you are overcomplicating things with so many tables. I think that any report made by a health professional should have the same status - be it a health care worker or a vet - you can keep track of this with staff_id. Have a closed field to indicate the mouse is getting well or (gulp...) being euthanized.

What database are you using to track these experiements/observations? I would recommend PostgreSQL if you haven't yet made a choice. What is your development environment?

Go with the simple system system first - remember Occam's razor - "Entities should not be multiplied beyond necessity". But, should you really need to, you can make it more complex - as Einstein said, "Everything should be made as simple as possible, but not simpler." :-). Better to start simple rather than over-engineering. 

[Edit - in response to OP's question about why PostgreSQL is better than MySQL]


more datatypes (IP address...)
CHECK CONSTRAINTS MySQL has workarounds (Triggers...) but these are clumsy and error prone,
CTEs - common table expressions - also known as the WITH clause or subquery refactoring,
Analytic functions,
a richer procedural language (or should I say language(S)),
a CREATE DOMAIN command - very useful and supported by Firebird, Oracle as well as PostgreSQL. Not by MySQL, but maybe by other RDBMSs.
generally (opinion now) - more of a focus on data integrity and correctness. MySQL's fame is built on the fact that it was quick (and nasty) - just perfect for the first Internet boom (1995 - 2000). It also was easy to set up on Windows (unlike PostgreSQL until version 8 (.3?)). It was also trendy with the GPL rather than the *BSD licence.