Go into your database and look at the value directly. I bet you it has
  Hasta ve Çalışan Güvenliği

you lose that bet (at least partly)

well, there is only one entity only god knows

where it came from because the entered data 
are for sure not entity encoded in the source
otherwise ü would also be ü in the DB

+---------------------------------+
| s2titel                         |
+---------------------------------+
| Hasta Güvenliği Platformu  |
+---------------------------------+
1 row in set (0.00 sec)

htmlentities: Hasta ve Çalışan Güvenliği
browser display in the input-filed: Hasta ve Çalışan Güvenliği

as you can see there are more entities than expected

Looks like I totally won that, actually: I didn't say *all* the entities would be encoded, just those three (on that input). More specifically, there'll be numeric entities in place of characters that aren't present in ISO 8859-1.

I'm also betting you entered the data through an HTML form on a page that's encoded (or interpreted as) ISO 8859-1? When you entered characters that weren't supported by the character set the browser entity-encoded them, and using the only encoding scheme it knew would work: numeric entities. [1]

So not a bug: PHP diligently encoded the already-partially-encoded input as you requested. Your two best options are
a) Use an encoding that supports the characters you want to use
b) Pass $double_encode=false to htmlentities()

[1] Ratified in HTML 5 as http://www.w3.org/TR/html5/forms.html#application/x-www-form-urlencoded-encoding-algorithm step 4.3. It's also the behavior for HTML 4 but I don't see where it's declared in the standard.

how do you imagine taht you have totally won?

DATABASE: Hasta Güvenliği Platformu
ENCODED:  Hasta ve Çalışan Güvenliği

however, starting with PHP 5.4 htmlentities() is *completly broken* anyways because by stupidity the change default to UTF-8 breaks *any code* not wokring with UTF8 and then PHP upstream wonders that nobody upgrades servers

well, we did because we are using wrappers on at least 98% of all code from the last 10 years because htmlentities() never correctly encoded the whole ASCII-table

The bet is beside the point: characters submitted through an HTML form that are not representable in the character encoding used will be numeric-entity-encoded by the browser.

There is no possible way you gave that input string to htmlentities() and got that output string returned so I'm going to extrapolate:

Input:  Hasta Güvenliği Platformu
Output: Hasta Güvenliği Platformu

Input:  Hasta ve Çalışan Güvenliği
Output: Hasta ve Çalışan Güvenliği

In both cases htmlentities() did exactly what it was supposed to do. The fact that the input is already partially encoded is irrelevant because you didn't pass $double_encode=false to the function.