CMHAFF call, Monday, March 13

Attendees: David Tao, Nathan Botts, Beth Pumo, Paul Terwilger (Columbia U. HIT program), Vanessa Batoon (VHA/DoD IPO)

• We reviewed Beth Pumo's comments that scope needs to be clearly defined. We agreed that the three Use Cases give examples of scope, but that it would be best to have a "SCOPE" section that states that cMHAFF includes consumer health apps ranging from standalone apps, to apps that connect to devices and possibly exchange data with PHRs, and to apps that exchange data with covered entities (e.g., EHRs).
• We should clarify the difference between "offered by a Covered Entity" (HIPAA required) vs "recommended or endorsed by a CE" (HIPAA not mandated)
• We need to add a "How To Use This Guide" to explain the best way to read (don't get bogged down in the reference links immediately: get the big picture, then follow applicable links).
• A "decision tree" set of questions would help readers better understand what applies and what doesn't. The FTC Tool (helping MH app developers know which laws apply to them) is an example that we can model after. OWASP Mobile Top 10 is also an interactive tool that could provide ideas of how to structure the decision tree.
• The long list of risks that I added to the document, following Use Case C, is hard to integrate in its entirety into the narrative, because then the story would become so complex. However, it would be worthwhile to take 2-3 of the top bullets and integrate them into the narrative, then refer to a separate Risk Assessment Considerations section for more.
• Nathan provided an example of Use Case C, where the consumer app is not offered by a provider, but still would be useful if vetted. For a patient where exercise activity is prescribed, the physician wants summarized Fitbit information imported into the EHR for use in the Care Plan, and wants assurances that the data is secure and valid.
• We need to decide for sure whether this is Informative or STU (on the way to being a normative standard). Beth suggested that the language might be different if Informative, that it might not use the SHALL/SHOULD/MAY conformance verbs that it uses now.
• Beth also suggested that there could be low, medium, and high baselines of structure controls on apps. David said that is possible, but that cMHAFF is not divided into "tiers" like low, medium, and high. Rather, it has many conditional (SHALL[IF]) statements that apply if certain conditions are met.
• Nathan will follow up to see if Sync4Science has guidelines that we could use. Johnathan Coleman, co-chair of CBCC, recommended that.