Out of box, the data to prevent the approval is not present in the approval record.
When you view a change or interation in a full client in SM to approve it. you can apply constraints based on the ticket data to prevent an approval group member from approving if the are the coordinator. For example, add an approval control of "coodinator in $L.file<>$lo.user.name"
When approving via ESS or SRC, your approval is against the approval records themselves, which do not include the data to either prevent them from appearing to the user to approve or provide a way to block the approval.
You could tailor the approval table to add a field to hold the ticket coordinator from the change (you'd want to tailor it to manage reassignment to another coordinator).
Once the approval def includes the coordinator ID, you could limit the user's ability to approve via the SRC.
One possible option: Use a manadanten restricting query against the approval table which applies when the user is logged into a self-service client. For example: $G.ess & coordinator <> operator() | not $G.ess
The query parses as:
when accessing approvals, if self service is true do not display any approval records where the coordinator in the approval record is the logged in operator
If not ESS (not $G.ess) then show all approval records to which the user should have access and your controls will prevent them from approving.
There are several exising topics which explain mandanten in more detail if you are not familiar with it.