There are multiple unclarities in this section which makes the meaning of the scopes unclear.

1. A back-end service based infrastructure can still have a current context. A client could potentially still access a context through FHIRcast. The client could be part of a set of systems that operate within the context of a current patient (e.g. the set of services in an operating theater). In the case, the launch scope could be used to signal patient and encounter id's. In such case, a patient scope still would have meaning. It could also be used to limit the resource access to a single patient.
2. What the system scope means is unclear and needs further clarification.
   The section indicates that the system scopes "parallel" user scopes. This concept is a bit vague. A granted user scope for a device means the device can use the resource(s) in line with what the user is allowed to do. So read access can be granted while not all resources will be returned. The resources a device can access will be different depending on the authorizations of the user.
   Without a user, what does a system code mean? Access to the resources within the authorizations of the device? In this case a device that is not allowed to read patients, can be granted a system/Patient.read scope which will result in empty Bundles? Does it imply access to all resources? In this case subsets as defined by SmartV2 are essential. In this case the request to system/Patient.read would be denied for the case described above.
   If it is a subset of the device rights, 'device' would be better than 'system'.
3. What will happen if system scopes are requested in a normal smart launch? Is this allowed (I suggest it would)? If so, what will it mean (see previous discussion)?
4. The scopes are expressed in SmartV1 style, I would update them to SmartV2 style.

Please revise the section to clarify these issues.