CONNECTED DATA & PERMISSIONS
Connected Health Data & Permissions
Permission, provenance, source-specific restrictions, revocation, sharing, and model-use rules for future wearable, health-platform, and medical-record integrations.
Status: Prelaunch governance standard. The public RestartingTheHeart.com website does not currently accept external health records or wearable-health feeds through these future product workflows. This notice defines controls that must be in place before the described capability is activated.
1. User-controlled connections
RTH's connected-health architecture is permission-based. A user chooses whether to connect a supported source and, where the platform allows, which categories the source may share. No connected source should be treated as blanket permission to access unrelated information.
2. Planned source classes
Future integrations may include Apple Health, Google Health Connect, Samsung, Garmin, Oura, WHOOP, other wearables, user-authorized medical-record sources, or additional health-data providers. Availability, data categories, and permitted uses depend on the provider's current technical and legal requirements.
3. Source terms can be stricter than user consent
User consent cannot override a provider's API, developer, limited-use, licensing, or data-use restrictions. RTH will maintain a source-use registry and will not use connected data for model training, evaluation, advertising, resale, or another purpose when the source terms prohibit that purpose.
4. Provenance is mandatory
RTH intends to preserve device/provider identity, metric type, timestamp, measurement context, transformation history, and confidence or validation state where available. Data from different devices or algorithm families should not be silently averaged into one value when doing so could erase meaningful differences.
5. Calibration and interpretation
Where a feature uses an individual baseline, calibration requirements must be disclosed and the system must distinguish an insufficient-data state from a valid interpretation. A missing or conflicting signal must not be converted into false certainty merely to keep a score available.
6. Data minimization
RTH will request only connected-health permissions needed for the feature the user chooses. A future feature that requires a new category of data should trigger a new permission or notice rather than silently expanding an earlier grant.
7. Disconnection and deletion
A user may disconnect a supported integration through the applicable product or source settings. Disconnection stops future access after processing but does not automatically erase data already imported. Deletion is handled separately under the product's retention and deletion controls.
8. Sharing and export
RTH may allow a user to export or direct a summary to another person or service. The user should be shown the destination, data scope, and consequence before the transfer. RTH should not imply continued control over information after a user directs it to an independent recipient.
9. Training restrictions
Connected-source data is excluded from training or fine-tuning a general-purpose RTH model by default. Any exception requires explicit source permission, legal and governance approval, a separate user-facing basis, and inclusion in the training-data provenance record. If provider terms prohibit training or evaluation, the prohibition controls even if a user separately requests the use.
Privacy and data requests: privacy@restartingtheheart.com. Do not send medical records, passwords, authentication codes, government identifiers, or other unnecessary sensitive information by ordinary email.
General questions may use the RTH contact page.