This wiki has undergone a migration to Confluence found Here
Difference between revisions of "CMHAFF call, Thursday, Oct 12"
Jump to navigation
Jump to search
| Line 3: | Line 3: | ||
MINUTES | MINUTES | ||
*Review short descriptions (most are new) of each section at the Heading 3 level (e.g., 3.4.1 User Authentication, 3.4.2 User Authorizations...). DONE THROUGH SECTION 3.4.5, Security for Data in Transit | *Review short descriptions (most are new) of each section at the Heading 3 level (e.g., 3.4.1 User Authentication, 3.4.2 User Authorizations...). DONE THROUGH SECTION 3.4.5, Security for Data in Transit | ||
| + | **NOTE: we agreed that the descriptions should not overlap with, or sound like, conformance statements. After the meeting, I have reworded them so they are purely descriptive and do not sound prescriptive at all (avoiding words like "should" and "require"). | ||
*We discovered a possible gap. While we talk about authorization/consent for collection and use of data, we may not have conformance statements regarding authorization for additional users on an account (e.g., primary user, secondary users). David and Nathan will check whether this concept is addressed, but we didn't see it in the Authentication and Authorization/Consent sections. | *We discovered a possible gap. While we talk about authorization/consent for collection and use of data, we may not have conformance statements regarding authorization for additional users on an account (e.g., primary user, secondary users). David and Nathan will check whether this concept is addressed, but we didn't see it in the Authentication and Authorization/Consent sections. | ||
*Comment DKT11: We decided to remove "Suggested Actor" from conformance tables. It would take too long, and not add enough value, to try to fill it out for all tables. In the few cases where it is important for the discussion (e.g., Product Development), it can be mentioned in the text, not in a dedicated table column. | *Comment DKT11: We decided to remove "Suggested Actor" from conformance tables. It would take too long, and not add enough value, to try to fill it out for all tables. In the few cases where it is important for the discussion (e.g., Product Development), it can be mentioned in the text, not in a dedicated table column. | ||
| − | Ran out of time. The following will be deferred till next week. | + | Ran out of time. The following will be deferred till next week. |
| + | *Finish review of short descriptions. | ||
*Review '''cMHAFF Label,''' a visual summary of key facts about an app and its conformance to cMHAFF (David) | *Review '''cMHAFF Label,''' a visual summary of key facts about an app and its conformance to cMHAFF (David) | ||
**Review of '''Label format and "consumer friendly language"''' descriptions (new Section 2.2 in cMHAFF document), including the notes that suggest how a section could be scored Green, Yellow, or Red, and who should decide (self-attestation vs inspection vs test vs ____?) | **Review of '''Label format and "consumer friendly language"''' descriptions (new Section 2.2 in cMHAFF document), including the notes that suggest how a section could be scored Green, Yellow, or Red, and who should decide (self-attestation vs inspection vs test vs ____?) | ||
**Work through two sections as examplars: '''Product Information''' and '''User Authorization (Consent) for Data Collection and Use''', to work through how the label score might be determined by assessment against conformance statements. | **Work through two sections as examplars: '''Product Information''' and '''User Authorization (Consent) for Data Collection and Use''', to work through how the label score might be determined by assessment against conformance statements. | ||
Latest revision as of 14:15, 13 October 2017
ATTENDEES: David Tao, Nathan Botts, Gary Dickinson, Adamu Haruna
MINUTES
- Review short descriptions (most are new) of each section at the Heading 3 level (e.g., 3.4.1 User Authentication, 3.4.2 User Authorizations...). DONE THROUGH SECTION 3.4.5, Security for Data in Transit
- NOTE: we agreed that the descriptions should not overlap with, or sound like, conformance statements. After the meeting, I have reworded them so they are purely descriptive and do not sound prescriptive at all (avoiding words like "should" and "require").
- We discovered a possible gap. While we talk about authorization/consent for collection and use of data, we may not have conformance statements regarding authorization for additional users on an account (e.g., primary user, secondary users). David and Nathan will check whether this concept is addressed, but we didn't see it in the Authentication and Authorization/Consent sections.
- Comment DKT11: We decided to remove "Suggested Actor" from conformance tables. It would take too long, and not add enough value, to try to fill it out for all tables. In the few cases where it is important for the discussion (e.g., Product Development), it can be mentioned in the text, not in a dedicated table column.
Ran out of time. The following will be deferred till next week.
- Finish review of short descriptions.
- Review cMHAFF Label, a visual summary of key facts about an app and its conformance to cMHAFF (David)
- Review of Label format and "consumer friendly language" descriptions (new Section 2.2 in cMHAFF document), including the notes that suggest how a section could be scored Green, Yellow, or Red, and who should decide (self-attestation vs inspection vs test vs ____?)
- Work through two sections as examplars: Product Information and User Authorization (Consent) for Data Collection and Use, to work through how the label score might be determined by assessment against conformance statements.
