Mark changes 1., 3.,  and 4.  as Draft content for publication of version 1.1.0 and Subject to Ballot for 1.2.0-Ballot (September Ballot) Change POU input element in the Task Profile from Must Support  to  Optional (pre-applied)  update documentation from: “Purpose of Use for the requested data is communicated between the Payer and Provider using codes from the CDex Purpose of Use Value Set in Task.input. Examples using these codes are provided below.”        to: The current state of healthcare data exchange is typically limited to a single, well-known and pre-established purpose-of-use (POU). The CDex Task Data Request Profile defines an optional element that represents the purpose of use( POU) for the requested data with a CDex Purpose of Use Value Set containing a small number of codes . The intent of this element is to define a potentially new way to exchange data with a dynamically defined POU.  If this element is supported by the Data Source, it permits  POU codes to be communicated dynamically in the individual Task based queries which may even differ from the ‘default’ purpose of use for that data consuming system. It allows the The Data Source to make necessary decisions about whether to provide the information at all or whether/how to filter the information. The examples illustrate how this input element is used. 2. Update the Task Based query documentation to avoid implication that this authorization is an oauths based process.        From: Whether a specific Authorization is needed The Access to the data is limited (for example due to patient privacy concerns the data needs to be reviewed and/or filtered )        to: The Access to the data is restricted and a specific authorization is needed (for example due to patient privacy concerns the data needs to be reviewed and/or filtered ) 3. Update the Security and Privacy General Considerations  section    From: User scopes  SHALL  be used as defined in  SMART App Launch  to restrict access to the relevant patients for a given Data Consumer.    To: User scopes shall be used as defined in  SMART App Launch  to restrict access to the relevant patients for a given Data Consumer. Organizational user access scopes are typically pre-negotiated and documented via business agreements. These agreements shall be translated into the appropriate  SMART App Launch  scopes. 4. Update Security and Privacy Purpose of Use  section      From: In some cases, it may be important to transmit the purpose of use when soliciting data. Specifically, when the purpose of use differs from the ‘default’ purpose of use for that data consuming system (generally ‘payment and operations’ for payers and ‘treatment’ for providers), the data source needs to be able to make decisions about whether to provide the information at all or whether/how to filter the information. For the Task based approach, representing purpose of use is documented here. However, when using standard RESTful queries, such information cannot be conveyed directly. There is work in progress in FHIR SMART v2 (Granular Controls) and the FHIR Data Segmentation for Privacy (ballot version) on standardizing how this information can be conveyed using OAuth. Once a suitable approach has been agreed upon and published, it will be referenced in a future version of this guide. In the interim, implementers should consult with their compliance department to determine what requirements exist and how best to satisfy them, whether with in-band or out-of-band communications.     To: The purposes for which data may be used by or on behalf of an organization is known as the Purpose of Use (POU). It is important part of data sharing agreement between Data Consumers and Data Sources because privacy policies and consent directives dictate the response to data requests.  Typically, a single POU is assigned for a client applications when the app is registered and broadly defined POU types such as those listed in the NHIN Purpose Of Use Code System are used.  For example, a Payer’s POU is typically “OPERATIONS” and a Provider’s is “TREATMENT”.   Therefore it is implicit when the Data Consumer makes a direct query or an “automatically fulfilled” Task to the Data Source using that app. For Task based queries, the POU for the requested data MAY  be also communicated between the Payer and Provider for each Task using codes from the CDex Purpose of Use Value Set in the  POU Task.input element . The intent of this element is to define a potentially new way to exchange data with dynamically defined POUs.