Clients requesting patient-level scopes need a way understand which patient these scopes apply to. A patient-level scope is essentially meaningless without knowing which patient it is bound to. While it might be possible for clients to infer the "patient" context value in some circumstance, leaving this as an exercise for the client is likely to cause confusion and incorrect imputation. Note that we call out patient context here as a special case, specifically because it is so closely tied to the functionality of patient-level scopes. Providing a "patient" context value whenever a patient-level scope is granted 1) is simple for servers, 2) provides a consistent developer experience for clients.   We already say:   > The application could choose to also provide  launch/patient  and/or  launch/encounter  as “hints” regarding which contexts the app would like the EHR to gather. The EHR MAY ignore these hints (for example, if the user is in a workflow where these contexts do not exist).   > The EHR MAY refuse authorization requests including patient/ that do not also include a valid launch, or it MAY infer the launch/patient scope.