Querencia Data Mapping

Implementation review: 20 September 2026. Scope: the current iPhone-first development app. Source implementation and simulator evidence do not replace signed-device release validation.

Clinical record

• Source: symptom values, medication configuration, dose actions, baseline information, diagnosis/appointment dates, lab records, and any historical imported daily summaries.
• Path: SwiftUI forms or authenticated App Intents → SwiftData → local app database. There is no developer upload.
• Purpose: history, scheduling, descriptive calculations and appointment reports.
• Retention: records persist until removed. Users can edit/delete individual symptom, dose, and lab logs. Confirmed medication deletion also removes that medication’s dose history in the same save transaction; unrelated records remain. An empty medication list is supported. A symptom edit consolidates its legacy correction family; deleting it removes the family so old values cannot reappear. Deletion clears app-managed temporary exports. Delete all local data erases the complete store and returns to onboarding; a failed full deletion remains closed for retry.
• Protection: the existing database location is preserved. Store directories, SQLite files/sidecars, and external binary storage receive Complete file protection and backup exclusion. The app entitlement sets Complete as the default. CloudKit is disabled with no optional cloud-store path.
• Implementation: QuerenciaStore, RecordSession, RecordGovernance, RecordEditing, versioned schemas, and feature save transactions. Editors use isolated contexts, explicit saves, and stale-snapshot checks. Edits and medication deletions roll back on failure. Medication deletion resolves inverse dose relationships inside its private transaction before removing records, preserving the stored medication and doses for retry if saving fails. Unchanged dates preserve their stored local-day keys.

Historical Apple Health summaries

• Current collection: none. Authorization requests, the import service and the unused background analysis job are removed. No HealthKit entitlement or Health usage description is shipped.
• Retained values: existing DailyMetrics rows can contain daily sleep hours, HRV, resting heart rate, steps, local-day/time-zone identifiers and update dates. They are preserved for the user to export or remove.
• Control: Remove imported Health summaries requires device authentication and removes all such local rows plus temporary exports. It does not touch other clinical record types or original Apple Health samples. No imports recreate removed rows.

Preferences and authentication

• Ordinary preferences: onboarding completion, notification-detail choice and cleanup/deletion progress stay in app preferences. They carry no health values.
• Security preference: enabled state and immediate/one-minute/five-minute timeout are stored in a Keychain item with WhenUnlockedThisDeviceOnly accessibility. Migration removes the older defaults lock flag only after a successful Keychain save. Read failures keep access closed.
• Authentication: LocalAuthentication device-owner policy with biometric or passcode verification. Fresh authentication is required for security-setting changes, enabling notification details, complete export, imported-summary removal and complete erasure. The app receives only success/failure.
• Lifecycle: inactive app content has a separate cover window above its presentations. UI and App Intents share the access policy. Outstanding operations use a store generation to reject stale access during deletion.
• Removal: in-app full erasure removes the lock Keychain item and record/privacy preferences. Keychain items can otherwise outlive uninstall. The alternate app icon remains a separate device presentation choice.

Local reminders

• Source: user-editable regimen, clock times, interval dates and early/late window preferences, projected on-device. Optional interval preferences stay in the existing medication schedule JSON. Pausing excludes a medication from new reminders while preserving its history.
• Path: app → UNUserNotificationCenter → iOS notification presentation or paired-device mirroring. No push server.
• Default content: generic title/body, opaque UUID/time identifiers; no medication name or dose.
• Optional details: explicitly enabled after device authentication. Names/doses/window information can then appear under iOS preview and mirroring settings.
• Retention: changing the notification-detail choice clears pending and delivered requests and rebuilds the schedule. Dose/history and medication edits refresh scheduling; unavailable notification permission clears stale requests. Daily notifications repeat as clock-based schedule cues; marking a daily dose taken or skipped does not suppress that day’s repeating notification. Full erasure stops outstanding scheduling before clearing both. Foreground/background work checks protected-data availability; scheduling is serialized to prevent an older refresh from restoring a removed preview.

Siri and Shortcuts

• Source: user-supplied symptom/dose parameters and local next-dose calculations.
• Boundary: every action requires local-device authentication and the shared app-access check before any record lookup or mutation. Asynchronous dose lookup rechecks the store generation and access before returning a dialog.
• Output: a next-dose or logging dialog may name a medication after authorization. Apple handles Siri/Shortcuts input and output under its own policies and settings; no offline-processing guarantee is made.

Reports and complete export

• Interval reports: one inclusive local-day scope applies to symptoms, scheduled-day dose counts, confirmed labs and derived flags. Discontinued medications with dose events in the interval can be included. PDF and text use the same report value. Counts describe stored dose events, not an inferred complete history of expected medication use.
• Complete archive: fresh authentication → one synchronous clinical snapshot → versioned JSON containing all six model types. Includes corrected symptoms, discontinued medication definitions, orphan/linked doses, unconfirmed labs and imported summaries. It excludes security secrets and UI preferences. There is no archive import UI.
• Archive format: formatVersion: 2; dates are JSON numbers in seconds since 2001-01-01T00:00:00Z, identified by dateEncoding. IDs and original day/time-zone fields are preserved. Medication scheduleData is base64 of its stored JSON schedule encoding, preserving even unreadable legacy values. Version 1 partial-export utilities remain separate and are not advertised as a full export.
• File lifecycle: explicit file-export action → unique opaque directory in app temporary storage → system share sheet. Complete protection and backup exclusion are applied. Completion/cancellation removes that share’s file. A launch sweep removes interrupted files aged at least 24 hours, excludes active sessions and removes legacy report files. Cleanup failures are surfaced; Privacy offers a retry.
• External retention: receiving apps/services govern copies the user saves or sends. Files contain readable health information and are not recipient-encrypted by Querencia.

Dormant scan and CSV components

The current navigation exposes neither scanning nor CSV export. Camera construction is gated on a purpose description, device support and authorized record access. The current app has no camera purpose description. The OCR component redraws only pixels into a bounded image, passes text rather than source images to its callback, writes no image file, and fails rather than returning unsanitized source material. It uses the Swift Vision request API available from iOS 18. Synthetic metadata tests cover GPS and camera-make removal. A complete capture/confirmation flow needs review before release.

Legacy CSV utilities quote CSV syntax and prefix formula-like text, including leading whitespace/control characters, so it is treated as literal cell content. CSV remains separate from the complete JSON archive.

Backups, websites and support

• Device backups: current clinical files are excluded; CloudKit is disabled. Existing backups made by earlier builds are not deleted. Ordinary preferences may still be backed up. Device protection and backup behavior need a final signed-device check.
• Reference links: ordinary website requests; no attached clinical record.
• Policy websites: static GitHub Pages, without Querencia-added tracking scripts. GitHub handles hosting/security information under its policy.
• Support: voluntary GitHub submissions reach GitHub and the developer and include account-linked content. Public issues and private security reports have different visibility. Use synthetic examples, never a real health record.

Privacy manifest and release review

The app declares no tracking, no tracking domains and no collected data types. Required-reason declarations match own-app UserDefaults (CA92.1) and app-owned export modification dates used for retention cleanup (C617.1). The unused disk-space declaration was removed.

“Data Not Collected” remains a proposed native-app App Store answer, not a submitted label or a security certification. Review the final signed artifact, support-channel disclosure scope, App Privacy Report, device authentication/Siri, notification mirroring, cover behavior and protected files on a real iPhone before release. A simulator does not provide physical-device Data Protection evidence.

This mapping and the privacy policy change together. See the history or report a discrepancy.