CMHAFF call, Thursday, Oct 19
- Finish review of short descriptions (3.4.6 and following)
- 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.
- Review and decision on specific comments:
- DKT8 -- Environmental Scan
- DKT9 -- Are all aspects of the product development life cycle appropriate to mention, if there are not corresponding conformance criteria for all of them?
- DKT11 -- Secure Coding practices reference
- DKT22 -- Liability discussion. Frank disputes this one. Appropriate?
- DKT31 -- Strong authentication options
- DKT49 -- Initial set of definitions. Check for important missing terms.
- DKT50 -- Platform-specific considerations
- Review of changes made, based on Adamu's recommendations from U.K. PAS277 Guidelines. Comments have been added, but specific wording has not all been incorporated yet. Adamu also sent an email on October 6th that we should consider (copied below)
Adamu's Oct 6th Email
Hi all, Coming back to PAS document and the general discussion about cMHAFF .
I think in general we need to figure out how we could leverage or incorporate or complement PAS as whole ( without UK specific standards) into cMHAFF . Not for this ballot session but may be during the resolution of the comments after January. PAS has a bit different style from all the specs we’ve looked at, in a sense that it looks at the project life cycle of the apps.. Product development in fact will become highly relevant in light of FDA precertification program : https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/Default.htm and some companies have already been selected : https://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm577480.htm
In essence, FDA will follow & check your SW design and process and certifies it (like ISO certification ) so they don’t have to certify each individual product coming from that company. Any product from that will go directly to the market and FDA will go straight to post market data collection phase. This makes SW process/product development life cycle very key or central here …and that is where PAS comes in for health and wellness apps.
cMHAFF covers almost everything from PAS i.e. from the consumer or market perspective => translated backwards to what developer should do before releasing the product/app to the market . I think we can plug PAS ( or some part of it ) in 3.2 to guide the developer on what process to follow to meet cMHAFF conformance at the front end . Or we can also check PAS Annex A (informative ) : relation between PAS and IEC 62304 i.e. how PAS selected keys parts and light version of IEC 62304
I don’t know how in practice we can do this but definitely we should not re-do the work but smartly reference or incorporate or point to the developer what process to follow in product development …( liaison or work together to pick some parts into cMHAFF annex or direct reference)
Please , let’s have a look as general task outside the current ballot preparation . I think after January we need to see how to proceed to position cMHAFF to not only address current FDA direction but a “go to” framework for various app stakeholders in the consumer health industry
My two cents…