Role Based Access Control + Data Ownership based permissions

This is a very good question, and it has been identified as one of the problems with RBAC. There is been a line of research on parameterized roles (the pdf can be found online), and more recently, the idea of relationship-based access control has emerged (see work of P. Fong et al, for instance this one). I'm not sure how much has been implemented though.

You could configure a modern Multi-Level Security (MLS) product to address the issue. These systems are designed for military grade data protection on shared infrastructure. Typically the systems use Role Based Access Control (RBAC), Discretionary Access Control (DAC), and Mandatory Access Control (MAC) based on security labels.

The security labels address your missing element. In an MLS system all objects have a label to include both data and processes. The labels provide the scheme to address your doctor and specific group situation.

Here is an example configuration. The master label set (known as system encodings) includes a label scheme that has individual groups for all the doctor groups in question. The application that is used by all doctors could be limited by the RBAC control you mentioned. Each doctor would also have their unique security label in their account profile and thus would only be able to access the data defined by that label.

Initial configuration is heavy lifting but you get tons of other features useful in your case such as controlling which document print at which printer (think hardware limits just like doctor group limits).

The Wikipedia page for MLS provides vendors (when not in SOPA blackout). Oracle’s Trusted Extensions product had some good commercial use case examples online along the lines of your question.

There is a similar pattern that Exchange 2010 is using; where the access model is limited using the "Scope" property that applies to the Binding layer. In this implementation, Scope is the "relation" between the authenticated user, and the OU that the "patient" is in.

Exchange 2010 has a delegation model where groups of winrm Powershell cmdlets are essentally grouped into roles, and the roles assigned to a user.

(Image source)

This is a great & flexible model considering how I can leverage all the benefits of PowerShell, while using the right low level technologies (WCF, SOAP etc), and requiring no additional software on the client side.

(Image source)

This is a very modern application design, and I'm trying to imitate it myself. I have a similar question on StackOverflow here