Comparing HAS GPG to cMHAFF Criteria

Here are suggestions for a loose process to follow when comparing French HAS Good Practice Guidelines (GPG) to cMHAFF, looking for potential gaps in cMHAFF.

• Read cMHAFF, if you have not already, at least at a high level.
• Read pages 14-16 of the HAS GPG to understand their categories and how they write their criteria
• Look at the High level diagram for the category (e.g., Category "Usability/Use" Subcategory "Integration/Import" starting on page 37).
  • Look at each requirement within the category (e.g., there are six for Integration/Import).
  • Consider the strength of requirement for each criterion, C=Compulsory (equivalent to SHALL), R=Recommended (SHOULD), D=Desirable (MAY). Focus primarily on the Compulsory, secondarily on the Recommended, and look at the Desirable in case you think they actually should have higher strength.
    • Is it appropriate to guide an app DEVELOPER, not just for someone assessing existing apps?
    • Is it appropriate as CORE requirements, or should they be deferred for future consideration?
    • Is it too burdensome?
    • Is it limited to be applicable to only a few types of apps? (If not universally applicable, but very important for some types of apps, consider whether they deserve to be conditional requirements, SHALL[IF] in cMHAFF
    • Is it realm-specific (e.g., specific to one country)? Even so, can it be generalized to be appropriate in a universal standard?
    • If you think the requirement is worthy for cMHAFF, assess whether it already exists in cMHAFF (it PROBABLY does not, for the assigned "red" categories).
      • If yes, state where it can be found in cMHAFF.
      • If no, state whether it should be assigned to an existing cMHAFF category, or whether cMHAFF will need a new category for it.
• The end results of your assessment should be that you triage each requirement as follows:
  • 1. Yes: recommend inclusion in cMHAFF (recommend whether it fits into an existing cMHAFF category, or the suggested new category)
  • 2. Yes with qualification: recommend inclusion with modifications (and describe the modifications)
  • 3. Defer. Possible future consideration, but not Core.
  • 4. No: do not recommend for inclusion