01_Data_Safety_Disclosures
AMII Platform — Data Safety Disclosures
App Store Connect and Google Play Console submission worksheet
DRAFT FOR LEGAL, SECURITY, AND STORE-SUBMISSION REVIEW
Effective date: July 23, 2026. Replace all bracketed fields and verify the production build, hosting configuration, SDKs, permissions, and account-deletion workflow before publication.
1. Product Summary
AMII Platform is a role-based dental care coordination application for patients, dentists, and authorized AMII personnel. It supports account authentication, appointment requests, reservations, dentist availability, patient charts, treatment and follow-up workflows, insurance and identification document uploads, offers and promotions, education, notifications, and visit feedback.
The App handles personal and sensitive health-related information. It is not an advertising network, does not sell personal information, and must not use health, insurance, identification, treatment, or clinical data for behavioral advertising, cross-app tracking, data-broker activity, or unrelated marketing.
2. High-Level Store Disclosures
• User data collected: Yes.
• Sensitive or health-related data collected: Yes.
• Data linked to the user or account: Yes.
• Cross-app or cross-site tracking: No.
• Sale of personal information: No.
• Third-party advertising: No.
• Sharing with a selected dentist or dental provider: Yes, when necessary to process a patient-requested reservation, treatment, document review, follow-up, or related care workflow.
• Sharing with contracted service providers: Yes, only as needed to host, secure, authenticate, communicate, support, or operate the App.
• Encryption in transit: Required for production. Confirm all production API, web, media, and administrative traffic uses HTTPS/TLS.
• Encryption at rest: Confirm the final hosting and database configuration before selecting this statement in store forms.
• Account deletion: Required before public submission. The App must provide an in-app deletion request and a public web deletion mechanism.
3. Data Categories to Disclose
Contact Information
• First and last name.
• Email address.
• Phone number.
• Home, personal, work, mailing, city, state, and ZIP code information.
• Other contact information voluntarily supplied by the user.
Primary purposes: account setup, authentication, service delivery, reservation coordination, provider communication, support, security, and legally permitted communications.
Identifiers
• Internal user ID, role ID, patient or dentist account identifiers, membership or customer number, and reservation or chart identifiers.
• Authentication and security identifiers, session information, and tokens.
Primary purposes: authentication, account management, authorization, fraud prevention, security, and linking records to the correct user.
Health and Medical Information
• Dental treatment categories, requested services, tooth numbers or oral areas, reservation reasons, treatment plans, treatment status, follow-up status, clinical notes, chart logs, surgical status, lifecycle stage, and other care-related information.
• Patient chart information and dentist-authored observations.
• Reservation, appointment, treatment, surgery, and follow-up dates and status history.
• Visit ratings and written feedback that may describe a healthcare experience.
Primary purposes: appointment and care coordination, clinical documentation, provider review, treatment and follow-up management, patient communication, and service quality.
Insurance Information
• Insurance provider, policy number, group number, member ID, subscriber name, relationship to subscriber, expiration date, and no-insurance selection.
• Front and back images of insurance cards.
Primary purposes: reservation review, eligibility-related workflow, provider coordination, and requested dental services.
Identification Information
• Document type, document number, name on document, issuing state or country, expiration date, and validity status.
• Front and back images of identification documents.
Primary purposes: identity confirmation, fraud prevention, reservation review, and healthcare-provider requirements.
User Content
• Profile image.
• Uploaded insurance and identification images.
• Feedback, notes, support inquiries, and other information entered by the user.
App Activity and Diagnostics
• App interactions, feature usage, reservation and offer actions, notification actions, audit events, and administrative activity.
• Crash logs, performance information, error details, IP address, device or browser information, and security logs when collected by the production application or its service providers.
Primary purposes: App functionality, security, fraud prevention, troubleshooting, analytics, audit, and performance improvement. Only disclose analytics or diagnostics actually present in the final build.
Location
The current application uses addresses, cities, states, and ZIP codes supplied by users for provider matching, service-area logic, reservations, and promotions. It should not declare precise device location unless the production build actually requests or transmits GPS-level location. Manual address entry should remain available where practical.
4. Apple App Privacy — Proposed Classification
The following is a proposed App Store Connect privacy-label mapping based on the current application architecture. Reconcile it against every SDK and the production build before submission.
• Contact Info: Name, Email Address, Phone Number, Physical Address — collected, linked to the user, used for App Functionality and Product Personalization.
• Health & Fitness: Health — collected, linked to the user, used for App Functionality. Do not select advertising, marketing, or tracking purposes for clinical or health data.
• Sensitive Info: identification and insurance details may qualify as sensitive information — collected, linked to the user, used for App Functionality, Security, and Fraud Prevention.
• User Content: Photos or Videos and Other User Content — collected, linked to the user, used for App Functionality.
• Identifiers: User ID — collected, linked to the user, used for App Functionality, Authentication, Security, and Fraud Prevention.
• Usage Data and Diagnostics: disclose only if the production build or integrated SDKs transmit and retain these data.
• Tracking: No, provided the App does not link AMII data with third-party data for targeted advertising or advertising measurement and does not share with data brokers.
5. Google Play Data Safety — Proposed Classification
• Does the App collect or share required user data types? Yes.
• Is all user data encrypted in transit? Select Yes only after verifying HTTPS/TLS for all production endpoints.
• Can users request deletion? Select Yes only after the in-app and public web deletion mechanisms are operational.
• Data types likely requiring disclosure: Personal info, Health and fitness, Photos and videos, Files and documents, App activity, App info and performance, Device or other IDs, and identifiers.
• Purposes: App functionality, Account management, Security and compliance, Fraud prevention, Developer communications, and Analytics only where actually enabled.
• Required versus optional: profile and core reservation information may be required; profile images, feedback, some document fields, promotions, and marketing preferences may be optional depending on the workflow.
• Sharing: disclose transfers to independent dentists or healthcare providers when they are not acting solely as AMII service providers. Service-provider processing should still be described in the Privacy Policy and Subprocessor List.
6. Submission Blockers and Verification Checklist
• Implement in-app account deletion and a public deletion request page.
• Confirm the legal entity name in Apple and Google developer accounts matches the Privacy Policy.
• Confirm the public Privacy Policy and account-deletion URLs are accessible without login, geofencing, or a downloadable PDF.
• Inventory every production SDK, library, analytics package, crash-reporting package, notification provider, email provider, SMS provider, cloud host, database host, and file-storage provider.
• Verify Android manifest permissions and iOS privacy usage descriptions against actual functionality.
• Confirm whether push tokens, device IDs, IP addresses, crash data, or performance data are transmitted and retained.
• Confirm encryption at rest and backup retention with the final hosting provider.
• Ensure health, insurance, identification, treatment, and clinical data are excluded from advertising and unrelated marketing.
• Provide reviewers with working demo credentials and enough seeded data to test patient and dentist workflows.