Health and medical app review evidence checklist

Inventory claims before reviewing features

List every health phrase in the app name, subtitle, screenshots, onboarding, paywall, notification copy, support articles, and in-app results. Include implied claims such as 'detects', 'diagnoses', 'treats', 'prevents', 'clinical grade', 'doctor approved', 'emergency', and 'FDA cleared'.

Then connect each claim to the feature that produces it. A screenshot can create the same review risk as the app logic. If the product says it identifies a condition but the feature only logs self-reported symptoms, the mismatch belongs in metadata cleanup before binary QA.

Classify the safety risk of each claim

• Wellness: habits, reminders, journaling, education, and general progress without clinical outcome promises.
• Informational: reference content that does not create a personalized medical conclusion.
• Clinical or diagnostic: output that may influence care decisions or disease interpretation.
• Device-connected: hardware, sensors, measurements, or third-party medical-device data.
• Emergency or crisis: any promise that a user might rely on during urgent harm.

Attach evidence to the highest-risk words

Apple's safety rules require more than a friendly warning when an app could affect health decisions. Keep documentation for clinical references, practitioner involvement, regulatory status, device clearances, data source limits, and user-facing disclaimers. The evidence does not need to be dumped into Review Notes, but the team should know which claims can be defended.

AppReviewReady interpretation: if a claim cannot be backed by a source or clearance, rewrite it as a narrower product behavior. 'Tracks self-reported headache patterns' is easier to review than 'detects migraine triggers' when the app has no validated diagnostic model.

Make metadata match the actual safe use

1. Remove diagnosis, treatment, prevention, or emergency wording that the app cannot substantiate.
2. Ensure screenshots show representative outputs, not the most dramatic possible result.
3. Place disclaimers near decisions, not only in Terms or an account screen.
4. Verify support and privacy pages describe health data collection, sharing, retention, and deletion.
5. Test denial states for HealthKit, location, camera, Bluetooth, and notification permissions if used.

Write reviewer notes that explain scope

A good note narrows the app. It tells the reviewer what to verify and what the product intentionally does not claim. Avoid legalistic language that sounds like a substitute for product behavior.

Health review scope:
Primary function: [habit tracking, education, device companion]
What the app does not do: [diagnosis, treatment, emergency response]
Evidence or clearance: [citation or status]
Sensitive permissions: [HealthKit, camera, Bluetooth]
Sample path: [how to reach health output]
Test account data: [fictional sample profile]

Block release on unsupported health claims

Use a release checklist item that specifically asks whether any new copy, screenshot, notification, or generated result changed the health claim ledger. Health products often fail review because growth copy changes faster than clinical evidence. Treat claim drift as a release blocker, not a copy edit.