Разделяем формирование списка доступных ресурсов и разграничение доступа¶

Считаю необходимым разделять следующие задачи¶

Врачу необходимо отображать пациентов из региона с которым связан врач.

API с эндпоинтом /api/patients/, который возвращает только тех пациентов, которых должен видеть текущий пользователь. Т.е. API занимается как формированием списка ресурсов доступных субъекту, так и авторизацией. Фактически политика доступа описывается SQL-запросом или ORM.
Фронтенд делает запрос к /api/patients/ и занимается только отображением

Эндпоинт /api/patients/ возвращает всех пациентов, но поддерживает фильтрацию по атрибутам, т.е. можно сделать запрос /api/patients/?region-id=1 и получить пациентов только из региона 1
Access gateway: умеет идентифицировать пользователя, хранит в себе политики доступа и проверяет каждый запрос на соответствие политикам доступа, т.е. авторизует каждый запрос к ресурсу.
Фронтенд делает запрос к /api/patients/?region-id=x, где x — регион текущего пользователя. Тем самым формирует список ресурсов доступных субъекту.

Изменение логики отображения не требует вмешательства бекенд-разработчиков если логика укладывается в существующие политики доступа.
Разработка, изменение политик доступа не требует вмешательства в бизнес-логику, что уменьшает вероятность допустить ошибку в бизнес-функциях.
Аудит политик доступа не требует погружения в код бизнес-логики, что уменьшает время, сложность, стоимость и качество аудита.
Этап разработки политик доступа переносим в конец, что позволит реализовать функциональные требования и протестировать результат быстрее.

Ресурс: некий информационный актив, к примеру статья, карточка пациента, файл
Субъект: человек, информационная система отправляющая к нам запрос

P.S. не готов дискутировать на тему использования GraphQL, но вам мысленно примерить описанный подход на GraphQL советую.