Pepub edits for PCF 1.0.0-comment

input/pagecontent/Consent-ex-consent-advanced-normal-focused-psy-notes.md

@@ -2,7 +2,7 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. This case allows treatment access to normal data, and carves out mental health data as accessible only to [Practitioner](Practitioner-ex-practitioner.html). The oAuth token would be expressing a general permit for most users to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. This case allows treatment access to normal data, and carves out mental health data as accessible only to [Practitioner](Practitioner-ex-practitioner.html). The oAuth token would be expressing a general permit for most users to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
@@ -12,11 +12,11 @@ For Users that are not [Practitioner](Practitioner-ex-practitioner.html), the to
 For the User [Practitioner](Practitioner-ex-practitioner.html), the token **result** will be:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to just normal data would need to be expressed:
   - First as a forbid everything
   - Second as a permit normal data
-- Third is to permit Mental Health data
+  - Third is to permit Mental Health data
 
 ```json
 "extensions" : {

input/pagecontent/Consent-ex-consent-advanced-normal-focused-psy-or-sex-notes.md

@@ -2,21 +2,21 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. This case allows treatment access to normal data, and carves out mental health data and sexual health data as accessible only to [Practitioner](Practitioner-ex-practitioner.html). The oAuth token would be expressing a general permit for most users to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. This case allows treatment access to normal data, and carves out mental health data and sexual health data as accessible only to [Practitioner](Practitioner-ex-practitioner.html). The oAuth token would be expressing a general permit for most users to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
-For Users that are not [Practitioner](Practitioner-ex-practitioner.html), the token **result** will be no different than consent to [allow NORMAL data access](Consent-ex-consent-advanced-normal.html)
+For Users that are not [Practitioner](Practitioner-ex-practitioner.html), the token **result** will be no different than consent to [allow NORMAL data access](Consent-ex-consent-advanced-normal.html).
   - ITI-71 [access token](Consent-ex-consent-advanced-normal.html#notes)
 
 For the User [Practitioner](Practitioner-ex-practitioner.html), the token **result** will be:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to just normal data would need to be expressed:
   - First as a forbid everything
   - Second as a permit normal data
-- Third is to permit Mental Health data and Sexual Health Data
+  - Third is to permit Mental Health data and Sexual Health Data
 
 ```json
 "extensions" : {

input/pagecontent/Consent-ex-consent-advanced-normal-not-restricted-notes.md

@@ -2,16 +2,16 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the restriction to normal data is at the root, it means that nothing BUT normal data is allowed. This case also has explicit deny on restricted data. This restriction would be implied, but here it is explicit, so we will show how to make it explicit in the oAuth token. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the restriction to normal data is at the root, it means that nothing BUT normal data is allowed. This case also has explicit deny on restricted data. This restriction would be implied, but here it is explicit, so we will show how to make it explicit in the oAuth token. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to just normal data would need to be expressed:
   - First as a forbid everything
   - Second as a permit normal data
-- Third is a redundant forbid of restricted data
+  - Third is a redundant forbid of restricted data
 
 ```json
 "extensions" : {

input/pagecontent/Consent-ex-consent-advanced-normal-notes.md

@@ -2,7 +2,7 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the restriction to normal data is at the root, it means that nothing BUT normal data is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the restriction to normal data is at the root, it means that nothing BUT normal data is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 

input/pagecontent/Consent-ex-consent-advanced-normal-restricted-notes.md

@@ -2,12 +2,12 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the restriction to normal data is at the root, it means that nothing BUT normal data is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the restriction to normal data is at the root, it means that nothing BUT normal data is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to just normal data would need to be expressed:
   - First as a forbid everything
   - Second as a permit normal data

input/pagecontent/Consent-ex-consent-basic-treat-notes.md

@@ -2,12 +2,12 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following PCF specific element to inform the **Consent Enforcement Point**. 
 
- In this case there is no residual, as the Consent expresses that authorization be given for a given purpose of use. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources. No token would be issued by ITI-71 for users not authorized, or requests beyond the set of purpose of use.
+In this case there is no residual, as the Consent expresses that authorization be given for a given purpose of use. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources. No token would be issued by ITI-71 for users not authorized, or requests beyond the set of purpose of use.
 
 - The restriction to the given purpose (FooBar) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
-- The consent is indicated in the `ihe_pcf`.
-  - no `residual` element is provided, indicating that no residual rules need be enforced.
+  - The other `ihe_iua` extension parameters are not shown below
+- The consent is indicated in the `ihe_pcf`
+  - no `residual` element is provided, indicating that no residual rules need be enforced
 
 ```json
 "extensions" : {

input/pagecontent/Consent-ex-consent-expired-treat-notes.md

@@ -1,3 +1,3 @@
 #### IUA Access Token
 
-Provided an [ITI-71](other.html#updates-to-iti-71) is requested prior to expiration, then the resulting token would be the same as [Basic Consent to sharing for Treatment policy](Consent-ex-consent-basic-treat.html#notes). If the request is after expiration then [ITI-71] responds with an error response as defined in the OAuth 2.1 Authorization Framework [OAuth 2.1, Section 5.2].
+Provided an [ITI-71](other.html#updates-to-iti-71) is requested prior to expiration, then the resulting token would be the same as [Basic Consent to sharing for Treatment policy](Consent-ex-consent-basic-treat.html#notes). If the request is after expiration, then [ITI-71] responds with an error response as defined in the OAuth 2.1 Authorization Framework [OAuth 2.1, Section 5.2].

input/pagecontent/Consent-ex-consent-intermediate-authoredby-notes.md

@@ -2,12 +2,12 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the authored by filter is at the root, it means that nothing BUT the information authored by the given practitioner is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the authored by filter is at the root, it means that nothing BUT the information authored by the given practitioner is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to data authored by the given practitioner would need to be expressed:
   - First as a forbid everything
   - Second as a permit that which is authored by the given practitioner

input/pagecontent/Consent-ex-consent-intermediate-data-notes.md

@@ -2,12 +2,12 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the data filter is at the root, it means that nothing BUT the data is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the data filter is at the root, it means that nothing BUT the data is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to the given set of data would need to be expressed:
   - First as a forbid everything
   - Second as a permit that specific data

input/pagecontent/Consent-ex-consent-intermediate-encounter-notes.md

@@ -2,12 +2,12 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the encounter filter is at the root, it means that nothing BUT the information related to the encounter is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case, given that the encounter filter is at the root, it means that nothing BUT the information related to the encounter is allowed. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to data related to the encounter would need to be expressed:
   - First as a forbid everything
   - Second as a permit that data related to the encounter

input/pagecontent/Consent-ex-consent-intermediate-not-authoredby-notes.md

@@ -2,12 +2,12 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case the oAuth token and scope will address a general permit, and thus the `residual` need only express the forbid to information authored by the given practitioner.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case the oAuth token and scope will address a general permit, and thus the `residual` need only express the forbid to information authored by the given practitioner.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to forbid data authored by the given practitioner would be expressed
 
 ```json

input/pagecontent/Consent-ex-consent-intermediate-not-data-notes.md

@@ -2,12 +2,12 @@
 
 Provided an [ITI-71](other.html#updates-to-iti-71) results in a PERMIT access token issued. That token would have the following residual element to inform the **Consent Enforcement Point** that it needs to restrict the results.
 
- Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case one resource should be forbidden. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
+Given that the token will express the permit portion, the `residual` would need to express the refinement. In this case one resource should be forbidden. The oAuth token would be expressing a general permit for the given user to the given patient data. Possibly with scope restrictions based on other business rules, such as a subset of actions (CRUDE) and resources.
 
 The token would need to include an `ihe_pcf` extension to point at this consent, and that would include a `residual` to express the refinement. Shown as followed:
 
 - The restriction to the given purpose (Treatment, Payment, and Operations) would be expressed in the `ihe_iua` extension
-  - The other `ihe_iua` extension parameters are not shown below.
+  - The other `ihe_iua` extension parameters are not shown below
 - The restriction to the given one data resource would need to be expressed:
 
 ```json