You don't. (Not saying it cannot be tweaked somhow into there, but I think it is not a good idea).

Class diagrams show properties of the actual classes, like access modifiers "private", "public" and "protected", not restrictions on the use cases for the users of your system. A view restriction of clinicians on notes is something which needs to be encoded into the application by certain features, non-features or access rights, and maybe by utilizing database access rights as well. This is a very different level of abstraction than the level a class diagram typically shows. (And don't intermix a class Clinician with the real person which sits in front of a workstation and uses the system.)

A sensible place where you can put such restrictions in UML is a use case diagram, inside the textual description of a use case "View Notes" or "Manage Notes", for example.

Better don't. (Not saying it cannot be tweaked somehow into there, but I think it is not a good idea).

Class diagrams show properties of the actual classes, like access modifiers "private", "public" and "protected", not restrictions on the use cases for the users of your system. A view restriction of clinicians on notes is something which needs to be encoded into the application by certain features, non-features or access rights, and maybe by utilizing database access rights as well. This is a very different level of abstraction than the level a class diagram typically shows. (And don't intermix a class Clinician with the real person which sits in front of a workstation and uses the system.)

A sensible place where you can put such restrictions in UML is a use case diagram, inside the textual description of a use case "View Notes" or "Manage Notes", for example.

You don't.

Class diagrams show properties of the actual classes, not restrictions on the use cases for the users of your system. Don't intermix a class Clinician with the real person which sits in front of a workstation and uses the system.

A sensible place where you can put such restrictions in UML is a use case diagram, inside the textual description of a use case "View Notes" or "Manage Notes", for example.

You don't. (Not saying it cannot be tweaked somhow into there, but I think it is not a good idea).

Class diagrams show properties of the actual classes, like access modifiers "private", "public" and "protected", not restrictions on the use cases for the users of your system. A view restriction of clinicians on notes is something which needs to be encoded into the application by certain features, non-features or access rights, and maybe by utilizing database access rights as well. This is a very different level of abstraction than the level a class diagram typically shows. (And don't intermix a class Clinician with the real person which sits in front of a workstation and uses the system.)

A sensible place where you can put such restrictions in UML is a use case diagram, inside the textual description of a use case "View Notes" or "Manage Notes", for example.