The relevant analysis is not what a stranger like me thinks of the design, but rather how well it solves the problem it's meant to solve.
Everything proceeds from, depends upon a painfully detailed, painfully thorough requirement document.
So the answer to your question is a set of point-by-point comparisons between the detailed requirement document and the database design.
A fundamental goal is to minimise redundancy of action and of storage ...
> I therefore have to enter an e.g. ECG 7 times,
... so the relationship of exams to health ins is 1:many, you need a representation that permits entering one event once.
Quote
time brackets
>health_insurances_id
>bracket_1_from
>bracket_1_to
>bracket_2_from
>bracket_2_to
Yikes, no! That's another 1:many relationship. Columns like x1,x2 &c are normalisation errors. Read about normalisation. You need to aim at 3NF.
Give yourself time to soak up normalisation basics, and be prepared to throw away the first design, its function is usually to help you understand the problem.
Edited 1 time(s). Last edit at 12/02/2021 09:28AM by Peter Brawley.