Draft Individual Access Services Provider Privacy and Security Notice and Practices SOP

Common Agreement Section 10.3.1.(i): “Be publicly accessible and kept current at all times, including updated versions”

AHIP appreciates the opportunity to comment in response to the SOP. We support the substance and intent of this section in the SOP. One question arises regarding how Individuals may access or retrieve prior versions of the policy, particularly if questions, a dispute, or a data breach occurs and at issue is what the policy stated at the time of a prior event. Individuals will often rely on the policy as electronically posted as opposed to filing paper copies. To the extent changes are made, the SOP should discuss how an Individual may obtain a prior version of a policy. We recommend that the SOP or subsequent guidance from the RCE address this issue.

Common Agreement Section 10.3.1.(ii): “Be shared with an Individual prior to the Individual’s use/receipt of services from [the IAS Provider]”

AHIP supports this section of the SOP. We note that more specificity would be helpful to explain whether “flow-down” entities/Signatories would be required to issue and amend Privacy Notices. For example, Health Insurance Portability and Accountability Act (HIPAA) covered entities would currently have a Privacy Notice, but if a non-HIPAA entity were to offer IAS, then a Notice would need to be put in place. In the TEFCA environment, it is foreseeable that HIPAA and non-HIPAA covered entities could be involved with IAS in some form so we recommend that the RCE clarify that: (1) a TEFCA entity will not have to have more than one Notice in place; and (2) the “flow down” requirements should apply to IAS – meaning contracting entities will be required to conform their Privacy Notices and to make updates as needed as directed by the Qualified Health Information Network (QHIN), Participant or Subparticipant.

Common Agreement Section 10.3.1.(iii): “Be written in plain language and in a manner calculated to inform the Individual of such privacy practices”

“AHIP supports this section of the SOP. The SOP should clarify what, if any, additional languages other than English may be necessary and be made available to comply with this section. The SOP references the “customer base” of the IAS Provider. Spanish is listed in the draft SOP as a required language, but that may not be suitable for all IAS providers. In addition, it is unclear whether the IAS Provider will know the individual language needs. For example, will the SOP require IAS providers to seek out this information? Will an alternate language always be required if one customer does not read English or Spanish, or is a certain percentage of customers required to trigger this standard? We recommend the use of a definitive standard (e.g., 5% of the population of the customer base, as used in the U.S. Department of Health and Human Services (HHS) Office for Civil Rights guidance).

In addition, the SOP cites the use of the Federal Plain Language Guidelines but does not discuss references or guidance for commonly used readability scales (e.g., Flesch-Kincaid/Flesch Reading, the Fry Graph Readability Formula, the SMOG Readability Formula). We recommend the SOP clarify that the use of such commonly used readability scales would suffice for compliance.”

Common Agreement Section 10.3.1.(iv): “Include a statement regarding whether and how the Individual’s TI may be accessed, exchanged, Used, and/or Disclosed by [the IAS Provider] or by other persons or entities to whom/which [the IAS Provider] Discloses or provides access to the information, including whether the Individual’s TI may be sold at any time (including the future)”

“This and other SOPs use the reference “TI” without defining the acronym at the outset of the document. We encourage the RCE to update this SOP and other TEFCA documents that “stand alone” and will be referenced without referencing back to the Common Agreement. Anecdotally, some believed it referred to “Technical Information,” others believed it meant “Technical Infrastructure,” some referred to it as “TEFCA Information” or “TEFCA Infrastructure,” and some were unsure to what “TI” referred. The RCE can promote understanding by listing the complete term at the outset of the document.

In addition, we strongly encourage this SOP to include a direct statement that this section (and others) will be interpreted to be consistent with and in compliance with HIPAA. Such a statement will promote compliance with the privacy and security rules and expectations in the TEFCA environment.

The SOP could be improved by explaining to what entities the expectations will apply. The cover page lists “IAS Providers.” We believe it is unclear whether other entities will be held to the procedure (i.e., flow-down entities, HIPAA Covered Entities that may operate as Participants or Subparticipants). In our experience, many of the consent models in operation today are different and have various levels of functionality. We expect that these models will need to come together to promote consistency in individual patient access, which does not currently exist. We urge the RCE to discuss the vision for electronic patient consent in the TEFCA environment broadly and within this policy specifically. Promoting more education and understanding of consent models will help build a proper infrastructure.

Regarding the sale of data, the provision should explicitly reference HIPAA’s existing prohibition on the sale of identifiable data. Consumers will not trust the process if they believe their data are being monetized for an entity’s benefit. If the RCE intends to allow the sale of identifiable data (as can be inferred from the current draft), more public dialog should be implemented to explain why and how this will be allowed and remain in compliance with the HIPAA privacy and security rules.

We also recommend that all definitions in the IAS remain aligned with the established HIPAA definitions. Patient granting access should not have to track and understand differences in terms used between TEFCA and HIPAA in regard to their data exchange.”

Common Agreement Section 10.3.1.(v): “Include a statement that [the IAS Provider] is required to act in conformance with the Privacy and Security Notice and must protect the security of the information it holds in accordance with Section 10 of [the] Common Agreement”

“AHIP agrees with the intent and substance of this section. We believe the SOP can be improved by explaining in subsection “v” whether the scope applies to technical services, support services, or both. The current draft discusses “a general description of the privacy and security practices that the IAS Provider requires of third parties that provide services on behalf of the IAS Provider and with whom they share Individually Identifiable information in connection with such services. The SOP should also clarify whether assurances are needed related to technical servers, as these may be in or outside of an IAS Provider or other entities (i.e., QHIN, Participant, Subparticipant).
Data encryption would also benefit from clarification. Encryption is appropriate for “in transit” or “at rest” data, but not during processing. It would be helpful to further define the terms (I.e., at rest, in transit, and processing) to ensure better understanding.”

Common Agreement Section 10.3.1.(vi): “Include information regarding whom the Individual may contact within [the IAS Provider] for further information regarding the Privacy and Security Notice and/or with privacy-related complaints”

Subparagraph “ii” states, “[m]aintain a process for documenting privacy-related complaints, as well as the IAS Provider’s response.” The SOP should explain whether this information will be made publicly available. We believe this information should be made publicly available.

Common Agreement Section 10.3.1.(vii): “Include a requirement by [the IAS Provider] to obtain express written consent to the terms of the Privacy and Security Notice from the Individual prior to the access, exchange, Use, or Disclosure (including sale) of the Individual’s TI, other than Disclosures that are required by Applicable Law”

As stated above, current consent processes used in healthcare have various levels of consent and functionality. We expect that these models will need to come together to promote consistency in individual patient access, which does not currently exist. We recommend that the RCE discuss the vision for electronic patient consent in the TEFCA environment broadly and within this policy specifically. Promoting more education and understanding of consent models will help build a proper infrastructure.

Common Agreement Section 10.3.1.(viii): “Include information on how the Individual may revoke consent”

As stated above, current consent processes used in healthcare have various levels of consent and functionality. We expect that these models will need to come together to promote consistency in individual patient access, which does not currently exist. We urge the RCE to discuss the vision for electronic patient consent in the TEFCA environment broadly and within this policy specifically. Promoting more education and understanding of consent models will help build a proper infrastructure.

Common Agreement Section 10.3.1.(ix): “Include an explanation of the Individual’s rights, including, at a minimum, the rights set forth in Section 10.4” [of the Common Agreement]

AHIP supports this section of the SOP.

Common Agreement Section 10.3.1.(x): “Include a disclosure of any applicable fees or costs related to IAS including the exercise of rights under Section 10.4 of [the] Common Agreement”

AHIP supports this section of the SOP.

Common Agreement Section 10.3.1.(xi): “Include an effective date” [of the written Notice and an effective date of any subsequent material changes to such Notice]

AHIP supports this section of the SOP.

Common Agreement Section 10.3.1.(iv): “Include a statement regarding whether and how the Individual’s TI may be accessed, exchanged, Used, and/or Disclosed by [the IAS Provider] or by other persons or entities to whom/which [the IAS Provider] Discloses or provides access to the information, including whether the Individual’s TI may be sold at any time (including the future)”

“Glad to see that you are address the requirements that the purposes of use be properly specified by the IAS provider. This is consistent with the general trends in data protection law to use the European approach – all data use purposes must be specified.

However, you may (or may not) be aware that general federal privacy law is heading to possibly more stringent requirements than what you currently have, and which would apply to IAS providers that are not regulated by HIPAA. Please check out the American Data and Privacy Protection Act, which is on the verge of passing the U.S. House of Representatives (see https://energycommerce.house.gov/committee-activity/markups/markup-of-six-bills-full-committee).

Among other things, the ADPPA would require entities that collect sensitive health information (equivalent to EHPI) limit such collection to that which is “”strictly necessary”” to provide the service (see section 102(a)(2)). ADPPA also mirrors the requirement you already have that affirmative express consent be obtained for data transfers (although it will be worth looking over the ADPPA definitions of what this kind of consent looks like – see definitions Sec. 2(1), which mentions requirements that consent be “”freely given, specific, informed and unambiguous””).

I raise this so that you can consider how the Draft Provider Notices can be tied to future changes like ADPPA in federal law that might “”raise the bar”” beyond TEFCA framework requirements. This may be as simple as including requirements of compliance with all applicable federal and state privacy law, but you may also want to call out some of the specifics captured in these new laws.

Happy to have further dialogue if this is helpful.”

Common Agreement Section 10.3.1.(iii): “Be written in plain language and in a manner calculated to inform the Individual of such privacy practices”

“We understand and agree that the Notice should be provided in a plain language manner to that the Individual is able to read and understand the Notice in a straightforward way. However, as a legal binding agreement with the Individual, we have heard from member organizations of Commonwell that a plain language version of the Notice may not always pass muster as a legal document. To balance these legal considerations with the RCE’s broader aim of promoting trust and transparency, we suggest modifying the SOP to include requirements that IAS Providers offer appropriate consumer education about their privacy and security practices, consistent with the policies and practices detailed in their privacy and security notice.

We also note the RCE’s reference to HHS and FTC statements referring to the lack of comprehensible privacy notices that are sometimes not easily understood by patients and consumers, and the need for a way to establish more of an apples-to-apples comparison between said notices. In that respect, some of our members also are members of the CARIN Alliance which has advanced the CARIN Code of Conduct that articulates fair information practice principles in the context of health data collection, use and disclosure outside the HIPAA framework. One possibility for the RCE to consider in terms of offering appropriate consumer education is to recommend to IAS Providers that they provide consumer education along the lines described in the CARIN UX Guide (see https://carinuxguide.arcwebtech.com/). Another possibility in terms of promoting an apples-to-apples comparison of data practices between different IAS Providers is to require IAS Providers to complete a data practice questionnaire – similar to what CARIN has developed in its CARIN App Registration IG (see https://www.carinalliance.com/wp-content/uploads/2021/07/CARIN-Alliance_App-Registration-IG_07222021.pdf) . These CARIN resources, which have benefited from widespread community input since the Code of Conduct was first released in 2017, could be effectively leveraged by the RCE to promote the same goals that inform the plain language requirements for the Notice.

We also ask the RCE to clarify if in addition to a plain language notice that a form of the notice written in a manner to satisfy legal conditions and concerns may also be provided given it does not vary in substance or content from the plain language notice. Further, we ask the RCE to address if the legal form of the Notice (if permitted to be provided to the Individual) may also be subject to the Individual’s agreement as the formal Notice that is signed as discussed in Common Agreement Section 10.3.1.(vii.a.iii).”

Common Agreement Section 10.3.1.(vii): “Include a requirement by [the IAS Provider] to obtain express written consent to the terms of the Privacy and Security Notice from the Individual prior to the access, exchange, Use, or Disclosure (including sale) of the Individual’s TI, other than Disclosures that are required by Applicable Law”

“Some of our members express concern about the meaning of a “written” consent, especially when paired with the SOP requirement that consent meet ESIGN requirements. By introducing the concept of a consent in writing, without elaborating on the meaning of “written”, some of our members are concerned that the SOPs will be interpreted as requiring a digital equivalent to a wet signature, even though the ESIGN Act contemplates a wide range of acceptable mechanisms for an individual to affirmatively indicate their intention – ranging from checking a box to use of signature software such as what is present in Adobe Acrobat or DocuSign. Some of our members express the perspective that an out-of-band or off-platform process not be required for an individual to communicate their intentions with respect to IAS Provider services.

We recommend that the RCE make it explicitly clear that by indicating written consent is required whether that can be done electronically such as often is done for consumer or user consents given online to similar notices by commercial web sites or if the consent must be done on paper. Additionally, if the manner of collection that is used is at the discretion of the IAS provider, this should be so stated. We also request that the RCE make it clear if consent must be collected only once at the time the Notice is administered to the individual until such time as the Notice materially changes or if consent must be re-obtained at regular intervals even absent material change to the notice. It also seems that multiple consents may be possible given that separate acts are described in section 10.3.1.(vii) of the SOP as sale of information would seem to be a singular event distinct from ongoing access and exchange. It is not clear even given the statement made in 10.3.1.(vii.a.iii) if multiple consents are required given the statement that express written consent is required prior to access, exchange, Use or Disclosure (including sale) of the Individual’s TI provided those actions are consistent with the manners claimed in the Notice. Is consent required to authorize each act of access, exchange, Use or Disclosure if done so in a manner consistent with the Notice or is only one general consent to the Notice required? Or are both statements true? Namely, one general consent is required for the notice, and specific consents are required for each instance of access, exchange, Use or Disclosure? Or are only certain specific actions inconsistent with the manners claimed in the Notice such as the sale of an individual’s TI subject to specific consent?

Perhaps it makes sense to consider the underlying goals of these new criteria. We’d like to offer the following goal for consideration, which is to ensure an express consent, when required, is not buried in a lengthy general consent, but offered in a manner that is reasonably calculated to collect an express and informed consent; meaning that individuals are provided with sufficient context at the time consent is requested to understand the consequences of their choices, that the consent requires an affirmative act, consistent with the ESIGN Act, and that the consent choice, when made, is maintained in a tamper-resistant, auditable log, sufficient to validate and verify their decision.

Finally, we recommend that the SOP make it clear what are the recordkeeping requirements for the consent that is collected from the Individual.”

Common Agreement Section 10.3.1.(iv): “Include a statement regarding whether and how the Individual’s TI may be accessed, exchanged, Used, and/or Disclosed by [the IAS Provider] or by other persons or entities to whom/which [the IAS Provider] Discloses or provides access to the information, including whether the Individual’s TI may be sold at any time (including the future)”

eHealth Exchange recommends providing the words for “TI” the first time it is used. “TEFCA Information (TI)”.

Download Letter Response (PDF)

Common Agreement Section 10.3.1.(iii): “Be written in plain language and in a manner calculated to inform the Individual of such privacy practices”

“We support the spirit and intent of the requirements in this section. However, many of the
requirements are open to interpretation. For example, when exactly does a sentence no longer qualify as “”short””? Including requirements such as these with “”MUST”” language in the SOP means that Common Agreement compliance could depend on an individual interpretation of what constitutes a short sentence.

Overall, we believe a reasonableness standard should be reflected in the language. We anticipate that the RCE will need to make a judgment call on the reasonableness of any IAS Provider’s Notice in the event of complaints or other contention about such a Notice, and do not see any practical way of fully codifying requirements to avoid this outcome. We suggest that the RCE draft most of the requirements in this section as guidelines, and describe a simple process for providing feedback on an IAS Provider’s Notice to that IAS Provider with respect to the Notice’s readability.

One requirement that could be fully codified would be to require a 6th grade reading level score using the Flesch-Kincaid Grade Level formula. While arguably imperfect and not sufficient on its own, this requirement would be clearly defined and IAS Providers could know with certainty that they were in compliance.”

Common Agreement Section 10.3.1.(vi): “Include information regarding whom the Individual may contact within [the IAS Provider] for further information regarding the Privacy and Security Notice and/or with privacy-related complaints”

We are supportive of the intent of Section 6.a.i. With respect to 6.a.ii, we would encourage the RCE and ONC to offer more information on their operational expectations with respect to if, how, and in what context the records of privacy complaints and responses would be shared with the RCE and/or ONC. This information would ensure that our operational processes were optimized both for our internal needs, and for these additional purposes.

Common Agreement Section 10.3.1.(ix): “Include an explanation of the Individual’s rights, including, at a minimum, the rights set forth in Section 10.4” [of the Common Agreement]

We support the spirit and intent of this section. While we do not disagree with the requirement set forth in 9.a.3, we suggest that it has a different operational scope than other aspects of the SOP and might be better suited for inclusion in the Common Agreement itself, such as an addition to the current Section 10.4. At such point as there are general updates being made to the Common Agreement, we suggest that this requirement be moved.

Common Agreement Section 10.3.1.(i): “Be publicly accessible and kept current at all times, including updated versions”

Regarding “Proactively make reasonable efforts to ensure that Individuals already enrolled with the IAS Provider receive an updated version ”, it should be acceptable to notify the individual the next time the login to the IASP.

Common Agreement Section 10.3.1.(vii): “Include a requirement by [the IAS Provider] to obtain express written consent to the terms of the Privacy and Security Notice from the Individual prior to the access, exchange, Use, or Disclosure (including sale) of the Individual’s TI, other than Disclosures that are required by Applicable Law”

Click to accept the terms must be a valid way to obtain express written consent.

Common Agreement Section 10.3.1.(viii): “Include information on how the Individual may revoke consent”

There are many types of consent. Be specific on which consents for which you require the individual be able to revoke. Additionally, they should have the right to set or revise an end date or to whom for which the consent is valid.

Common Agreement Section 10.3.1.(i): “Be publicly accessible and kept current at all times, including updated versions”

We are supportive of this requirement.

Common Agreement Section 10.3.1.(ii): “Be shared with an Individual prior to the Individual’s use/receipt of services from [the IAS Provider]”

We are supportive of this requirement.

Common Agreement Section 10.3.1.(iii): “Be written in plain language and in a manner calculated to inform the Individual of such privacy practices”

“We are very supportive of the Sequoia Project’s efforts to create standards for IAS Providers in order to ensure trust across the TEFCA network. Similar concerns about consumers needing to choose personal health apps without good, clear information about the app’s policies, procedures and safeguards drove us to develop the CARIN Alliance Code of Conduct, and we appreciate that you have referenced the Code and the CARIN UX Guide in the appendix of this SOP. We have a number of comments that we hope will strengthen the SOP.

As a threshold matter, we urge the Sequoia Project to limit this SOP to objective requirements that can be adopted by IAS Providers and that ideally can be measured without application of subjective judgement. Individual Access Services is a TEFCA purpose that is too often met with a great deal of suspicion and, in some cases, hostility. We agree with setting the bar high – but the bar should also not be set in a way that provides a mechanism for the SOP criteria to be applied inconsistently, or in ways that make it unreasonably difficult for IAS Providers to connect to the TEFCA. For example, the SOP should focus primarily on the plain language standards (https://www.plainlanguage.gov/guidelines/) required by the federal government versus setting an arbitrary grade 6 reading level threshold which is subject to a subjective standard. As another example, we note the requirement to make the privacy policy available in English, Spanish, and other languages spoken by users of the app. Who decides what other languages must be offered by the app? To avoid a subjective judgement call that an IAS Provider is ineligible to connect to TEFCA due to failure to have a privacy policy in a particular language, we urge Sequoia Project to set some objective standard such as ensuring IAS providers provide culturally appropriate language accommodations based on what populations the IAS Provider may be targeting for its services. For example, Medicaid follows a rule that says if 5% of the covered population speaks a given language then member materials and the website must provide support for those languages.

We agree that the privacy policies and terms of service for IAS Providers should be required to include certain elements, and much of what is in this draft SOP mirrors the CARIN Code of Conduct. That said, we’d like to draw your attention to added SOP criteria on top of the Common Agreement’s requirements, which create new areas for interpretation. For example, in connection with requiring express consent, the SOP criteria introduce the concept that consent be in writing without elaborating on the meaning of “written”. Perhaps a better approach would be to specify that the consent to authorize an IAS Provider to engage in Connectivity Services on an Individual’s behalf be presented unambiguously to the Individual as an opt-in choice, and not buried in a lengthy privacy policy.

Similarly, a new criteria requires a signature to meet federal e-signature requirements. The federal E-signature Act provides for a number of acceptable mechanisms for capturing an individual’s agreement in e-commerce, which can range from checking a box to use of signature software such as what is present in Adobe Acrobat or DocuSign. Most individuals interact with applications and other online tools by indicating their assent digitally, without the need for something that looks like a wet signature or requires the use of additional, out-of-band or off-platform processes. We understand this criteria to mean that any/all mechanisms appropriate under the ESIGN Act are appropriate for use in demonstrating the collection of a consent. If that is the RCE’s intended interpretation, perhaps the SOP could include more detail reinforcing this interpretation. Moreover, if the intent is to generate a consent artifact for audit or verification purposes, perhaps the SOP could include examples of how that could be accomplished.

Overall, we agree that it is important that consent for sharing data not be buried in a long, general consent to use the product. We agree that the consent be, to the extent possible, knowing, informed and collected in a way (and at a time) that gives Individuals appropriate context to make a voluntary and affirmative decision (not an “opt out”, for example). The Code of Conduct addresses these considerations by requiring separate, express consent for data sharing, including sharing for marketing purposes.

We also urge the RCE to focus on strengthening those aspects of the SOP that make it more likely that IAS Providers offer consumer education in addition to privacy policies and terms of service, so that consumers are informed about their rights under HIPAA and the Common Agreement. We appreciate the RCE’s reference to the CARIN UX Guide. The CARIN app community looks forward to helping to communicate the best practices captured by the Guide, which reflects CARIN’s belief that consumer-friendly education about an IAS Provider’s privacy and security practices is more meaningful than a required “Privacy and Security Notice” heading and more easily achieved than writing a privacy policy at a 6th grade reading level. In the end, the criteria should be whether IAS Providers make an effort to inform and empower their consumers, by ensuring key data practices are read and understood by individuals, and that individuals are actually permitted to make choices versus being forced into default data sharing arrangements.

Along similar lines, we urge the RCE to not limit its focus on just the privacy policy document when considering how an IAS Provider can be transparent and clear to all users about its policies regarding the information it collects and the rights granted to consumers using the product. Privacy policies are often asked to serve many purposes: first, to be a tool of transparency to users and the public, and second, to be a legal document regarding the standards to which the company offering the app will be held. Because of this second purpose – that the document is legally binding on the company – privacy policies and terms of service are often written by attorneys and often must explain the company’s policies on issues that are difficult to explain in plain language. A number of consumer-facing companies, recognizing that it can be difficult to serve both purposes with one document, have both a privacy policy and a separate section of their website that summarizes the key components of the policy using plain English and in easier-to-understand language. Further, apps attesting to the CARIN Code of Conduct answer a series of questions about their data practices that allow consumers to compare practices of different apps and focus on the questions and issues that are usually most important to individuals making choices about online services. We urge the RCE to allow IAS Providers to demonstrate adherence to the SOP through all consumer-facing educational resources and not just a focus on the legal documentation (privacy policy and terms of service), assuming there is no conflict between the legal documentation and the other materials.

Also, given the SOP’s citation to HHS and FTC statements seeking to make privacy policy statements “clearer, shorter, and more standardized to enable better comprehension and comparison of privacy practices,” we’d like to direct your attention to the standardized data practices questionnaire contained in the CARIN App Registration IG. We developed this questionnaire in response to guidance accompanying the CMS Patient Access and Interoperability Rule, in which CMS recommended its payers to adopt an app attestation workflow. The questionnaire provides a model framework – consistent with the CARIN Code of Conduct – that the RCE could require of IAS Providers, so that they will disclose their privacy and data practices in a consistent fashion. This approach will go far in providing a more meaningful apples-for-apples comparison standard in the RCE’s goal of setting a universal floor for interoperability.”

Common Agreement Section 10.3.1.(iv): “Include a statement regarding whether and how the Individual’s TI may be accessed, exchanged, Used, and/or Disclosed by [the IAS Provider] or by other persons or entities to whom/which [the IAS Provider] Discloses or provides access to the information, including whether the Individual’s TI may be sold at any time (including the future)”

We are supportive of this requirement.

Common Agreement Section 10.3.1.(v): “Include a statement that [the IAS Provider] is required to act in conformance with the Privacy and Security Notice and must protect the security of the information it holds in accordance with Section 10 of [the] Common Agreement”

We are supportive of this requirement.

Common Agreement Section 10.3.1.(vi): “Include information regarding whom the Individual may contact within [the IAS Provider] for further information regarding the Privacy and Security Notice and/or with privacy-related complaints”

We are supportive of this requirement.

Common Agreement Section 10.3.1.(vii): “Include a requirement by [the IAS Provider] to obtain express written consent to the terms of the Privacy and Security Notice from the Individual prior to the access, exchange, Use, or Disclosure (including sale) of the Individual’s TI, other than Disclosures that are required by Applicable Law”

Please review our comments in 10.3.1 (iii) regarding this topic especially the eSIGN provisions.

Common Agreement Section 10.3.1.(viii): “Include information on how the Individual may revoke consent”

We agree with this recommendation, however we believe it’s important to note that we do not want users to accidentally revoke access since this is a destructive action that could result in users losing access to core functionality of the 3rd party app. In our UX guide, we state that “Revoking should trigger a confirmation dialog to ensure the user does not revoke consent by accident and provide a way back to safety.”

Common Agreement Section 10.3.1.(ix): “Include an explanation of the Individual’s rights, including, at a minimum, the rights set forth in Section 10.4” [of the Common Agreement]

We are supportive of this requirement.

Common Agreement Section 10.3.1.(x): “Include a disclosure of any applicable fees or costs related to IAS including the exercise of rights under Section 10.4 of [the] Common Agreement”

We are supportive of this requirement.

Common Agreement Section 10.3.1.(xi): “Include an effective date” [of the written Notice and an effective date of any subsequent material changes to such Notice]

We are supportive of this requirement.