At-a-glance summary
This summary is provided for convenience and is not a substitute for the rest of this Privacy Policy. Where the summary appears to conflict with a later section, the later section controls.
- We collect identity, contact, demographic, self-reported health, connected-source health, communications, device, location, and audit-log information. Categories are itemized in Section 5.
- Most of what we hold is sensitive personal data: health, biometric, and (where you connect them) genetic, mental-health, reproductive, and substance-use records. We treat all of it as sensitive regardless of jurisdiction.
- De-identified health data does train our models, and the collective is what makes them accurate for everyone. Data that could identify you never enters training. Your personal baseline is computed inside your own account from your own history. See Section 8.
- Identifiable data is not sold or rented, and is not shared with insurers, employers, or marketers in identifiable form (subject to limited Sponsor scoping you opt into; see Section 10).
- De-identified or anonymized data may be licensed or sold to research, pharmaceutical, life-sciences, and public-health partners under the rules in Section 12. You are included by default and can opt out at any time.
- We are HIPAA-aware and GDPR-aware, and we are building toward the U.S. state consumer-health-data standards described in Section 15. That section states plainly where our current practice already meets those standards and where it does not yet.
- The Services are in a limited beta. This policy describes the software as it actually runs today, not a planned end-state architecture. Section 18 and Section 21 are the places that difference matters most.
- You can access, correct, port, and delete your record. See Section 22.
Definitions
The capitalized terms below have the following meanings throughout this Policy.
- “Aler,” “we,” “our,” “us”: Aler Health, Inc., a Delaware corporation, and its affiliates.
- “Services”: the Aler website at aler.ai, the Aler application (web, mobile, and API), our clinical-intelligence engine, and any related products or services we offer.
- “Personal Data” / “Personal Information”: any information that relates to an identified or identifiable natural person, as defined under the GDPR / UK GDPR, the California Consumer Privacy Act / California Privacy Rights Act (“CCPA / CPRA”), and other applicable laws.
- “Sensitive Personal Data” / “Sensitive Personal Information”: categories given heightened protection by law, including health, biometric, genetic, mental-health, reproductive, sexual-orientation, immigration-status, precise-geolocation, racial/ethnic origin, religion, union membership, citizenship/immigration status, financial account, government-ID, and login-credential information.
- “PHI” (Protected Health Information): individually identifiable health information held or transmitted by a HIPAA-covered entity or its Business Associate, as defined at 45 C.F.R. § 160.103.
- “Consumer Health Data”: personal data linked or reasonably linkable to a consumer that identifies past, present, or future physical or mental health status, as defined under Washington’s My Health My Data Act (RCW 19.373) and analogous state laws.
- “De-identified Data”: information that does not identify and cannot reasonably be used to identify a particular individual, derived using HIPAA Safe Harbor or Expert Determination methods (45 C.F.R. § 164.514(b)) or analogous statistical de-identification standards.
- “Sponsor”: a healthcare provider, hospital, health plan, employer, government program, or other organization that contracts with Aler to make the Services available to a defined population (its members, employees, patients, etc.).
- “BAA”: Business Associate Agreement under HIPAA.
- “Sub-processor”: a third party engaged by Aler to process Personal Data on its behalf.
- “Connected Source”: a third-party system (wearable, EHR, lab vendor, pharmacy, genetics service, etc.) that you authorize to transmit your data to Aler.
- “you,” “your”: the individual whose Personal Data is being processed, including a Sponsor User where context permits.
Scope of this policy
This policy applies to all individuals who interact with Aler: visitors to aler.ai, people on our waitlist, account holders, individuals whose health information is connected to an account by themselves or a clinician, individuals enrolled in a Sponsor-administered program, and any other natural person whose Personal Data we process in connection with the Services. The plain-language summary at /trust/privacy describes the spirit of these practices; this document is the binding text.
Additional or controlling agreements. Where the Services are offered through a Sponsor, additional terms in our agreement with that Sponsor (including a BAA when applicable) may apply in addition to this policy. To the extent there is a conflict between this policy and a BAA with respect to PHI, the BAA controls. To the extent a separate HIPAA Authorization signed by you authorizes a specific disclosure, that Authorization controls within its scope.
Out of scope. This policy does not apply to: (i) the practices of Connected Sources or other third parties whose products you use; (ii) any data you provide directly to a Sponsor that the Sponsor does not transmit to Aler; (iii) employee or job-applicant data, which is governed by our internal HR notices.
Who is the controller
For purposes of EU/UK GDPR and similar laws, the controller of your Personal Data is Aler Health, Inc., a Delaware corporation with a notice address provided in Section 32. For information processed on behalf of a Sponsor under a BAA, that Sponsor is the controller (or “covered entity”) and Aler is the processor (or “business associate”).
We have designated a Privacy Officer (responsible for HIPAA), a Data Protection Officer (responsible for GDPR and similar laws), and a Security Officer (responsible for the HIPAA Security Rule and overall information security). Their contact information is in Section 32. The same individual may hold more than one role.
Aler maintains an EU representative under Article 27 of the GDPR and a UK representative under Article 27 of the UK GDPR; their contact details are listed at Section 32 once appointed and otherwise available on request.
Information we collect
The categories of Personal Data we collect, mapped to the eleven CCPA / CPRA categories (Cal. Civ. Code § 1798.140), are listed below. We have collected each of these categories within the preceding twelve (12) months.
5.1 Identifiers
- Name; email address; optional phone number; profile photo; postal address; date of birth.
- Account identifiers (user ID, session ID, device ID), a hashed password, session and refresh tokens, and password-recovery information. Where you sign in with Google or Apple, we receive the identifier and email address that provider returns and do not receive or store a password.
- IP address and user-agent string. A device fingerprint derived from device and session characteristics, used to detect sign-ins that do not look like you and to bind a session to a device.
- An inventory of the health applications installed on your device, where you grant the permission that exposes it. We use it to show you which sources you could connect and to attribute incoming records to the app that produced them.
- We do not collect or receive advertising identifiers, and we do not run advertising in the Services.
5.2 Customer-records information
- Support-request records and any correspondence you send us.
- Payments are not enabled. The Services are in a limited beta and we do not currently charge for them. We have no payment processor engaged, we do not collect payment-card numbers, billing addresses, or bank details, and no billing records exist. If we introduce paid plans, we will name the payment processor on our sub-processor page and update this policy before taking any payment.
5.3 Protected classification characteristics
- Date of birth (age); sex assigned at birth; gender identity (where you provide it); race / ethnicity / national origin (where you provide it). We collect these only where they are clinically relevant or required for Sponsor reporting; processing is limited to the purposes described in Section 8.
5.4 Commercial information
- Subscription history, transaction records, support-ticket records.
5.5 Internet or other electronic-network activity
We do not run product analytics. There is no analytics, session-recording, or behavioral-tracking software in the Services, and no third-party crash or error-reporting vendor. We do not record which screens you view, which features you use, or your click and tap events for analysis. What we do record is:
- Server request logs (method, path, status, timing, IP, user-agent), used to run and debug the service.
- Client errors. When the application encounters an error in your browser or on your device, it posts the error and a stack trace to an endpoint Aler operates. It does not go to a third party. These reports are scrubbed of health content before they are written.
- The audit log described in Section 5.13, which is an access-control record, not analytics.
5.6 Geolocation data
- Coarse location at sign-in. We capture an approximate location derived from your IP address each time you sign in, so we can show you your own session history and flag a sign-in from somewhere unexpected.
- Precise location, on an ongoing basis, when you grant the permission. If you allow location access on your device, the application collects your coordinates continuously in the background so that environmental context (air quality, pollen, ultraviolet index, weather, elevation, drinking-water quality) can be matched to where you actually are and correlated with your health signals.
- Travel mode. The setting that enables continuous location and travel detection is on by default for new accounts. You can turn it off in your settings at any time, and turning it off stops ongoing collection. It does not by itself delete location history already recorded; use the deletion controls in Section 22 for that.
- Home or reference addresses you enter yourself.
- Coordinates are sent to third-party reference services to resolve environmental context. What each of those services receives is itemized on our sub-processor page.
5.7 Sensory data
- Voice input is transcribed on your device. When you speak to Aler, speech recognition runs locally on your device and only the resulting text is sent to us. Your audio is not uploaded to Aler and is not sent to a transcription vendor.
- Spoken replies. When you ask Aler to read a reply aloud, the text of that reply is sent to Google Cloud Text-to-Speech, which returns synthesized audio. The audio is played on your device. Your voice is never involved in this path.
- Photographs and documents you upload, for example labels of medications and supplements, lab reports, or images of a finding you want recorded.
5.8 Professional or employment-related information
- For clinician users: NPI, role, organization affiliation, license jurisdictions. For Sponsor administrators: employer / role.
5.9 Education information
- Not generally collected. Collected only if voluntarily provided by clinician users for credentialing.
5.10 Inferences
- Inferences drawn from any of the above to create a personal-baseline profile and to score deviations from baseline. This includes risk scores, trend annotations, and AI-generated summaries. Inferences about your health are sensitive and are treated as Sensitive Personal Information.
5.11 Sensitive Personal Information
See Section 6.
5.12 Information from Connected Sources
The list below is the set of sources the Services can actually connect to today. A source not named here is not connected, whatever a general description elsewhere might suggest.
- Wearables and home devices you authorize: Whoop, Oura, Withings, Polar, Wahoo, Fitbit and other devices reachable through Google Health, Android Health Connect, and Apple Health. Depending on the device, this includes heart rate, heart-rate variability, SpO₂, respiration, body and skin temperature, sleep stages and duration, activity, steps, workouts, weight, body composition, blood pressure, glucose, menstrual-cycle data, and any other stream the device exposes to that platform.
- Health records through Android Health Connect (FHIR R4). Where you grant medical-records access, we receive structured clinical records from the apps that write to Health Connect: allergies and intolerances, conditions, laboratory results, medications, practitioner and provider details, pregnancy records, procedures, social history, vaccinations, visits and encounters, and vital signs.
- Genetics, by file upload. Genetics is not an account connection. You upload a raw data export from 23andMe or AncestryDNA yourself, and we parse it. We have no login relationship with any genetics service and cannot pull new data on our own.
- Your calendar, where you connect Google Calendar. We hold read access to your events, the ability to create and manage events in a dedicated “Aler Health” calendar we create, and your email address. We do not have access to your inbox. Note that events Google itself generated from your email, for example flight and hotel confirmations or appointment reminders, appear in your calendar and are therefore visible to us even though we hold no mail permission. That is a real path by which travel and appointment information reaches us, and we would rather name it than have you discover it. We deliberately do not write daily medication doses into your calendar, because a calendar entry naming a drug is readable by anyone you share your calendar with.
- Email you send into your own vault. You can forward records to a dedicated address to have them filed into your account. We receive whatever you send, including attachments and the message body.
- Clinicians and care teams: identity, role, encounter notes, and any orders or recommendations they share with you through Aler.
- Laboratory connections exist in the software but are not enabled. They require credentialing we have not completed, so no lab is currently connected. Pharmacy systems, claims feeds, and direct hospital electronic-health-record connections are also not built. If we enable any of them, this section will say so before your data flows.
5.13 Information collected automatically
- Audit-log data. Each read or write of a record containing PHI is logged with actor, action, target record, timestamp, IP, and user-agent. The audit log is retained per Section 17 and is not used for analytics, marketing, or model training.
- Cookies and similar technologies. See Section 27.
Sensitive categories
The following categories receive heightened protection under one or more applicable laws and under Aler’s internal policy. We process them only with explicit consent or another lawful basis specifically applicable to that category, and never use them for cross-context behavioral advertising. Where these categories are included in a de-identified dataset, the additional safeguards in Section 12.3 apply.
- Mental-health information, including diagnoses, medications, therapy notes, and self-reported symptoms.
- Reproductive and sexual-health information, including pregnancy status, fertility-related inputs, menstruation tracking, contraceptive use, abortion-related care, sexually-transmitted-infection results, and gender-affirming care. We will not disclose this category to law enforcement except under a valid, legally-binding court order or warrant, and we will challenge any request whose face appears facially invalid or overbroad.
- HIV / AIDS information, including diagnoses, viral load, ART regimens.
- Substance-use-disorder records. We do not have the separate consent, redisclosure-notice, and segmented-audit machinery that 42 C.F.R. Part 2 requires for records from federally assisted substance-use treatment programs, and we are not currently connected to any source that transmits Part 2 records to us. We are not holding ourselves out as a Part 2 compliant recipient. If you enter substance-use information yourself, it is treated as sensitive under this section and under our internal policy, but the specific Part 2 protections are on our pre-launch list rather than in place today.
- Genetic information, as further described in Section 28.
- Biometric information, including templates derived from voice, gait, photographs, or other biometrics. We do not currently use biometric identifiers for authentication; if we ever do, we will obtain a separate written release as required under the Illinois Biometric Information Privacy Act, the Texas CUBI, and similar laws, before collection.
- Precise geolocation below the level of city or postal code.
- Records concerning minors, see Section 25.
- Communications content, including the content of messages with Aler Intelligence or with a clinician.
- Account credentials and security questions.
Sources of information
We collect Personal Data from the following sources:
- Directly from you: when you create an account, complete onboarding, enter notes, message support, respond to in-product surveys, or upload documents.
- From Connected Sources you authorize: the wearables, device platforms, and calendar listed in Section 5.12. The third party’s own privacy notice governs its collection from you.
- From files you upload: genetics exports, lab reports, images, and documents, including anything you forward to your vault by email.
- From Sponsors: where a Sponsor enrolls you in an Aler-supported program (e.g., a hospital’s post-discharge program, an employer’s wellness benefit), the Sponsor’s notices and consents apply to the data they transmit to us. No Sponsor program is live today.
- From clinicians and care-team members you authorize.
- From public reference sources that we query rather than collect from, such as drug and supplement databases, the national provider registry, and public environmental and geographic services. These are itemized on our sub-processor page.
- Automatically when you interact with the Services, as described in Section 5.
How and why we use it
We use Personal Data only for the purposes described below. Each purpose maps to one or more lawful bases under Section 9.
8.1 Provide the Services
- Create and maintain your account; build your personal baseline; generate alerts, briefings, and summaries; track medications and supplements and check them for interactions; resolve environmental context for your location; support care-team workflows you authorize; respond to your messages and support requests.
- Generating a reply involves sending your data to a model provider. When you ask Aler a question, we assemble the context needed to answer it and send that context to a third-party model provider. That context routinely includes your profile, your medications, your conditions, your lab values, your recent metrics, and your question. The provider is contractually prohibited from training on it. The specific provider, and the exact contractual position including where it falls short today, are stated on our sub-processor page.
- Titles are derived from content. The title shown on a saved conversation is generated automatically from what you wrote in it. If you share your screen or hand someone your unlocked device, a list of conversation titles can reveal what you asked about.
8.2 Personalize and develop features
- Your baseline is yours. The personal baseline and deviation scoring that drive your alerts are computed inside your own account, from your own history. Nobody else’s data is used to produce your baseline, and your identifiable record is not used to produce anyone else’s.
- The model is shared, and it is trained on de-identified data. De-identified health data does train our models. That is deliberate: the collective is what makes a model accurate for everyone, including you. Data that could identify you is removed before anything enters training, under the standards in Section 12.1. See Section 12.4 for how to opt out.
- We also evaluate model quality, design new features, and conduct internal research and development.
8.3 Operate, monitor, and secure
- Detect and prevent fraud, abuse, and security incidents; debug issues; maintain audit logs; meet legal and contractual obligations; manage backups; perform capacity planning.
8.4 Communicate
- Send transactional messages (account, security, billing); respond to support inquiries; deliver alerts and briefings; if you opt in, send product updates and educational content.
8.5 Comply with law and protect rights
- Respond to lawful government requests; satisfy retention requirements; enforce our agreements; protect the rights, property, or safety of any person, including, in genuine emergencies, with first responders.
8.6 Generate de-identified and aggregated information
See Section 12.
8.7 Things we explicitly do not do
- We do not use identifiable Personal Data for cross-context behavioral advertising, and we do not run advertising in the Services.
- We do not sell or rent identifiable Personal Data.
- We do not train any model on data that could identify you.
- We do not run product analytics, session recording, or behavioral tracking, and we do not send your data to an analytics or attribution vendor.
- We do not sell or transfer Personal Data of consumers we know to be under 16 without explicit opt-in (CCPA / CPRA opt-in for minors).
- We do not use Sensitive Personal Information for purposes other than those reasonably necessary to provide the Services, as the term “reasonably necessary” is defined under the CPRA.
- We do not share or disclose your data in identifiable form to insurers, employers, or marketers (Sponsor programs you opt into are scoped to the data the program needs).
Lawful basis under GDPR / UK GDPR
If you are in the European Economic Area, the United Kingdom, or Switzerland, we rely on the following lawful bases under Articles 6 and 9 of the GDPR / UK GDPR:
| Purpose | Article 6 basis | Article 9 basis (special categories) |
|---|---|---|
| Account creation and provision of the Services | Performance of a contract (Art. 6(1)(b)) | Explicit consent (Art. 9(2)(a)) |
| Personal-baseline modeling and clinical insights | Performance of a contract (Art. 6(1)(b)) | Explicit consent (Art. 9(2)(a)); where applicable, healthcare provision (Art. 9(2)(h)) under a clinician relationship |
| Security, fraud prevention, audit logging | Legitimate interests (Art. 6(1)(f)); legal obligation (Art. 6(1)(c)) | Substantial public interest / safeguarding (Art. 9(2)(g)) |
| Compliance with legal obligations | Legal obligation (Art. 6(1)(c)) | Reasons of public interest in public health (Art. 9(2)(i)) where applicable |
| De-identified data licensing for research and product development | Once anonymized, not applicable; while pseudonymous, legitimate interests (Art. 6(1)(f)) and explicit consent (Art. 6(1)(a)) | Explicit consent (Art. 9(2)(a)); scientific research with safeguards (Art. 9(2)(j)) |
| Direct marketing communications | Consent (Art. 6(1)(a)) | N/A |
Our balancing assessment supporting any reliance on Art. 6(1)(f) (legitimate interests) is documented and available on request. You may withdraw your consent at any time, which stops further processing based on that consent but does not affect the lawfulness of processing performed before withdrawal.
Sub-processors & vendors
We maintain an up-to-date list of sub-processors who process Personal Data on our behalf at /legal/sub-processors (or available on request to [email protected]). At a minimum, the list specifies the sub-processor’s name, the function they perform, the categories of data they process, and the country in which processing occurs.
Categories of sub-processors we currently engage:
- Model inference. Providers that generate replies and summaries. They receive the health context described in Section 8.1. They are contractually prohibited from training on prompts or completions, and retention is limited to a short abuse-monitoring window. No Business Associate Agreement is in place with an inference provider today.
- Speech synthesis. A provider that turns reply text into audio when you ask Aler to read something aloud.
- Transactional email and mobile push delivery.
- Edge network and site delivery, which sees connection metadata for requests to our domains.
- Reference and environmental lookups, some of which receive your coordinates and some of which receive only a search term. Which is which is itemized on the sub-processor page.
- Development and staging infrastructure operated by a cloud provider, separate from production.
- Waitlist form handling for the marketing site.
Categories we deliberately do not engage. There is no product-analytics, session-recording, or behavioral-tracking vendor. There is no third-party crash or error-reporting vendor. There is no advertising, attribution, or marketing-automation vendor. There is no payment processor, no SMS provider, no identity-verification vendor, no customer-support helpdesk holding your records, and no managed security-monitoring, SIEM, or DLP vendor. Moving any vendor out of this list is a material change and is subject to the notice period below.
What is not sub-processed. The application, the primary database, the job queue and cache, and the files you upload all run on infrastructure Aler operates in the United States. They are not hosted by a third-party cloud provider.
Notice of change. We will notify subscribed users at least thirty (30) days before adding or replacing a sub-processor that materially expands the categories of data processed outside the U.S. You can subscribe to sub-processor change notifications at [email protected].
De-identified data licensing
This is one of the most important sections of this Policy. Read it carefully.
We may create De-identified Data from any information we collect through the Services and license, share, or sell those datasets to research institutions, pharmaceutical and life-sciences companies, public-health agencies, and other commercial partners. Revenue from this licensing supports our operations and the continued development of the Services.
Where this stands today. During the beta we build and hold de-identified datasets, and we use them to train and improve our own models. We have not yet licensed or sold a dataset to an outside party. The standards below are the conditions that must be satisfied before any dataset leaves Aler, and they bind us whether or not money changes hands.
12.1 De-identification standards
- HIPAA Safe Harbor or Expert Determination. Where the source data was PHI, de-identification follows 45 C.F.R. § 164.514(b): either removing all eighteen Safe Harbor identifiers, or obtaining a qualified expert’s determination of very small re-identification risk and documenting that determination.
- Aggregation and obfuscation. Record-level outputs apply date shifting (calendar offsets), geographic rounding (no zip below 3-digit), and small-cell suppression (cells < 11 individuals are suppressed).
- Differential-privacy noise is applied where appropriate to high-cardinality numeric attributes.
- Free-text safety. Free-text fields (notes, summaries) are run through a PHI-scrubber and a manual quality gate before inclusion in any record-level licensed dataset.
- Contractual restrictions. Recipients are contractually prohibited from attempting re-identification, from combining the data with other data in a way that would enable re-identification, and from using the data to make adverse decisions about specific individuals.
- No re-association by us. Once data has been de-identified for licensing, Aler does not maintain the keys necessary to re-associate it with you.
12.2 Examples of how De-identified Data may be used
- Sale or licensing of population-level datasets (e.g., aggregate cardiovascular trends, glucose-response distributions, sleep-architecture norms by age and sex) to pharmaceutical and life-sciences companies, medical-device manufacturers, payors, public-health agencies, and academic researchers.
- Building, training, evaluating, and improving Aler’s machine-learning models, including foundation models, baseline learners, risk models, and natural-language interfaces.
- Publishing scientific research, white papers, and blog posts that include aggregate statistics or de-identified case examples.
- Benchmarking and quality reporting for population-health initiatives.
12.3 Sensitive-category handling
Datasets that include information from the categories in Section 6 (mental health, reproductive, HIV/STI, genetic, substance-use, etc.) are subject to additional safeguards including: (a) heightened expert-determination thresholds; (b) recipient diligence including a research ethics review where applicable; (c) prohibition on use for marketing, insurance underwriting, or employment decisions; (d) right to revoke licensing for cause.
12.4 Your control
You are included by default and can opt out at any time. Creating an account accepts our Terms, and the research-contribution section of those Terms opts your account in. The setting is on when your account is created. You can turn it off in your account settings at any time, opting out does not affect any other feature, and turning it off both stops future contribution and removes your past contributions from the datasets we hold. Because a dataset already delivered to an outside recipient is no longer associated with you, we could not recall it from that recipient; as stated above, no dataset has been delivered to an outside recipient to date.
We want to be straight with you about the shape of this. Opt-out by default is a weaker consent posture than the affirmative opt-in that Washington’s My Health My Data Act, Nevada SB 370, and the GDPR contemplate for health data. We have chosen to state the default plainly here rather than describe a consent flow we do not run. See Section 15.
12.5 EU / UK users
If you are in the EEA or the UK, the GDPR ceases to apply to data once it has been anonymized. While data is still pseudonymous, we treat it as Personal Data and rely on the lawful bases described in Section 9, including your explicit consent. You may withdraw your consent at any time, with the effect described above.
HIPAA & our role as a Business Associate
Aler is generally not a HIPAA-covered entity, and today most of what we hold is consumer data you or your devices give us directly rather than PHI received from a covered entity. Where we are engaged by a clinical practice, we operate as that practice’s Business Associate and execute a BAA, and the BAA together with this Policy governs our use and disclosure of PHI received from it. We describe ourselves as HIPAA-aware. We are not HIPAA-certified, and no such certification exists.
Treatment, Payment, and Healthcare Operations (TPO). Where authorized under HIPAA, we may use and disclose PHI for treatment, payment, and healthcare operations purposes consistent with the BAA. We do not use PHI for marketing or sale (each as defined under HIPAA) without an HIPAA Authorization (see Section 14).
Minimum necessary. Aler limits requests, uses, and disclosures of PHI to the minimum necessary to accomplish the intended purpose, except for treatment-related disclosures and disclosures required by law.
Where Aler is the covered entity. If you obtain Aler-provided clinical services directly through Aler (for example, a future tele-care or remote-monitoring service offered directly to consumers), Aler may itself become a covered entity for that data. In those cases, Aler will provide a separate Notice of Privacy Practices and obtain authorizations as required.
If you only ever use Aler with consumer wearables and self-reported information, HIPAA may not technically apply to that data. We hold ourselves to the same encryption, access-control, and audit standards regardless.
Consumer-health data laws (WA MHMD, NV SB 370, CT PSD, etc.)
15.1 Washington: My Health My Data Act (RCW 19.373)
We are building toward the Washington My Health My Data Act (“MHMDA”) standard for Washington residents and for any consumer health data we receive from a Washington resident. Here is where each piece actually stands.
- In place. We provide a separate Consumer Health Data Privacy Policy reachable from our homepage and from this document at /legal/consumer-health-privacy.
- In place. We do not sell consumer health data. We will not seek the separate written valid authorization that RCW 19.373.060 requires for a sale of identifiable consumer health data, because we do not intend to make one.
- In place. We honor the rights of access, deletion, withdrawal of consent, and appeal described in Section 22.
- Not yet. Consent to collect consumer health data is obtained through acceptance of our Terms at signup rather than through a separate, standalone affirmative consent, and the research-contribution setting starts on. MHMDA contemplates consent that is separate from a general terms of service. Reworking that flow is on our pre-launch list. Until it ships, this section says so rather than claiming a consent posture we do not have.
15.2 Nevada: SB 370
For Nevada-resident consumer health data we follow Nevada Senate Bill 370 (NRS 603A). We do not sell consumer health data, so the affirmative-consent-before-sale requirement is not one we rely on an exception to. The same gap noted above about consent at collection applies here.
15.3 Connecticut: Personal Data and Online Monitoring Act
We follow the consumer-health-data provisions added to the Connecticut Data Privacy Act, including the right-to-delete obligations applicable to consumer health data.
15.4 Other jurisdictions
We monitor consumer-health-data and biometric laws in additional U.S. states (including Maryland’s “Maryland Online Data Privacy Act” for sensitive data and any successor or analogous statutes) and aim to treat the strictest applicable standard as our default.
Automated decision-making & profiling
Aler uses automated processes (including machine-learning models and large language models) to compute personal-baseline trends, score deviations, and surface alerts. These processes are decision-support: they inform you and any clinician you authorize but do not, by themselves, produce legal or similarly significant decisions about you. We do not use automated decision-making to determine eligibility for care, insurance, employment, credit, or housing.
If we ever introduce processing that constitutes solely automated decision-making within the meaning of GDPR Article 22 with a legal or similarly significant effect, we will obtain explicit consent, provide meaningful information about the logic involved and the envisaged consequences, and offer the right to obtain human intervention, express your point of view, and contest the decision.
How long we keep it
We retain Personal Data only as long as necessary to provide the Services, comply with legal obligations, resolve disputes, and enforce our agreements. The default retention windows are below; specific retention rules are documented in our internal Records Retention Schedule, available on request.
| Category | Default retention | Notes |
|---|---|---|
| Active account data (profile, baseline, summaries) | Duration of account | On account closure the record is scheduled for deletion with a 30-day window. See the note below the table. |
| Connected-source data (wearables, device platforms, health records) | Duration of account | You may delete individual records earlier. |
| Location history | Duration of account | Turning travel mode off stops collection; deleting the history is a separate action. |
| Conversations with Aler | Duration of account | You may delete individual conversations earlier. |
| Audit logs | 6 years from creation | Append-only and insert-only. Restricted store; never used for analytics. |
| Server request logs and client error reports | Short operational window | Health content is scrubbed before these are written. |
| Support correspondence | 3 years | For dispute purposes. |
| Waitlist and marketing email | Until you unsubscribe + 60-day suppression list | Suppression list is the minimum data required to honor your unsubscribe. |
| Backups | Rolling 35 days | Backups are restored only in disaster scenarios. |
| De-identified datasets | Indefinite | Once de-identified, no longer associated with you. Opting out under Section 12.4 removes your past contributions. |
| Records subject to legal hold | Until hold lifted | Notwithstanding other rules. |
A note on deletion. When you close your account we mark the record for deletion and remove your research contributions immediately. The automated purge worker that erases the marked record at the end of the 30-day window is not built yet, so today that final erasure is performed manually. We would rather tell you that than describe an automated guarantee we do not have. Building the purge worker is on our pre-launch list.
Security
We protect Personal Data with administrative and technical safeguards modeled on the HIPAA Security Rule. This section is split between what is in place today and what is on the pre-launch roadmap, because we do not want to claim a control we have not built.
In place today.
- Encryption. Sensitive fields are encrypted one column at a time (Fernet, which is AES-128 in CBC mode with an HMAC), on top of encrypted volumes, using one rotatable key. TLS in transit. Backups are encrypted.
- Identity and access. Role-based access control with least-privilege defaults. Two-factor authentication is mandatory for clinician accounts. Passwords are hashed, never stored in readable form. Sessions are bound to a device and can be listed and revoked by you.
- Isolation. Your record is isolated per account: every query is scoped by your account identifier, and a request in one account cannot read another account’s rows. On the clinical side, practices are hard-isolated from one another. To be precise about the mechanism, this is row-level isolation inside a shared database, not a separate database per customer.
- Audit. An append-only, insert-only audit log of reads and writes against records containing health information, with actor, action, target, timestamp, IP, and user agent.
- Logging hygiene. Health content is stripped from application logs and from client error reports before they are written.
- Application security. Peer review on changes, dependency and secret scanning in continuous integration, and no third-party analytics or tracking code in the client to widen the attack surface.
- Network. Production is reachable only through an authenticated edge tunnel. There are no directly exposed database or administrative ports.
On the pre-launch roadmap, not in place today.
- A SIEM and retained security-event pipeline, and anomaly detection on access patterns.
- An annual third-party penetration test.
- SOC 2 and HITRUST assessments. We hold neither and do not claim either.
- Multi-zone redundancy with published recovery objectives.
- Vendor Business Associate Agreements, including with our model-inference provider.
- Formal quarterly access reviews and a written sanctions policy.
No system is perfectly secure. The full security posture, in plain language, is at /trust/security.
Breach notification
If we discover a security incident affecting your Personal Data, we will:
- Notify affected individuals without unreasonable delay and in any event no later than sixty (60) days after discovery for HIPAA-reportable breaches, in accordance with 45 C.F.R. §§ 164.404-164.410.
- Notify the relevant supervisory authority within seventy-two (72) hours of becoming aware for GDPR / UK GDPR notifiable breaches, in accordance with Article 33.
- Notify state attorneys general and consumer-reporting agencies as required by applicable U.S. state breach-notification laws.
- Notify covered entities for whom we are a business associate within the timeframes set in our BAAs.
- Provide identity-monitoring or other remediation services where appropriate.
- Publish a post-incident report describing root cause and corrective actions for material incidents.
International transfers
Aler is based in the United States. If you access the Services from outside the United States, your information will be transferred to and processed in the United States or other countries where we or our service providers operate. These countries may have data-protection laws different from those in your country.
For transfers from the European Economic Area, the United Kingdom, or Switzerland, we rely on the European Commission’s 2021 Standard Contractual Clauses (Modules 1 and 2 as applicable), the UK International Data Transfer Addendum, and the Swiss FDPIC equivalent. We apply supplementary technical and organizational measures consistent with the EDPB’s post-Schrems-II guidance, including encryption, pseudonymization, and contractual prohibitions on government access requests inconsistent with EU law. A copy of the operative SCCs and our Transfer Impact Assessment summary is available on request from [email protected].
Data residency
Everything is in the United States. Production data is stored on infrastructure Aler operates in the United States. Backups are kept in the United States. Our development and staging environment is in a U.S. cloud region.
There is no EU residency option today. An earlier version of this page said data for EEA and UK users was stored in a European region. That was never true and it has been removed. If you are in the EEA, the UK, or Switzerland, your data is transferred to and processed in the United States under the safeguards in Section 20. Regional residency is something we would have to build, and we will not describe it as available until it is.
Model inference. Requests to our model provider are served from that provider’s United States infrastructure.
Sponsor residency. If we enter a Sponsor agreement that specifies particular regions, the most restrictive applicable residency requirement controls. No Sponsor program is live today.
Your rights
22.1 Rights everyone has
- Access: request a copy of the Personal Data we hold about you.
- Correction: ask us to correct inaccurate or incomplete data; we either correct it or annotate the record.
- Deletion: delete individual records at any time, or close your account and have your record scheduled for deletion with a thirty (30) day window, subject to legal retention requirements. See the note under Section 17 for exactly how that runs today.
- Export / portability: receive your record in a machine-readable, FHIR R4-compatible export.
- Withdraw consent, including consent to de-identified data licensing and to processing of sensitive categories, at any time.
- Lodge a complaint with us first, and with your local supervisory authority.
22.2 GDPR / UK GDPR rights
If you are in the EEA or UK, you also have the right to object to processing based on legitimate interests, the right to restrict processing, the right to data portability in a structured, commonly used, machine-readable format, the right not to be subject to a decision based solely on automated processing producing legal or similarly significant effects (Section 16), and the right to lodge a complaint with your local supervisory authority. To exercise these rights, contact [email protected].
22.3 California privacy rights (CCPA / CPRA)
If you are a California resident, you have the right to: know what categories and specific pieces of Personal Information we have collected, the categories of sources, the business purposes, and the categories of third parties we have shared it with; delete; correct; opt out of sale or sharing; limit use of Sensitive Personal Information; and not be retaliated against. We do not “sell” or “share” identifiable Personal Information for cross-context behavioral advertising as those terms are defined under the CCPA / CPRA. To the extent that licensing of De-identified Data is treated as a “sale” under California law, that licensing involves only data that has been de-identified consistent with HIPAA, and recipients are contractually prohibited from re-identification. To submit a request, contact [email protected] or use the rights-request webform linked from /legal/privacy-policy. Because Aler operates exclusively online, we do not maintain a toll-free telephone line for privacy requests, as permitted under Cal. Code Regs. tit. 11, § 7026(b). We will not discriminate against you for exercising these rights, and we will not provide financial incentives that are unjust, unreasonable, coercive, or usurious.
22.4 “Shine the Light” (Cal. Civ. Code § 1798.83)
We do not share Personal Information with third parties for those third parties’ direct-marketing purposes, so the disclosure right under Cal. Civ. Code § 1798.83 does not apply. You may still ask us in writing to confirm this.
22.5 Other U.S. state rights
We honor the rights provided to residents of states with comprehensive privacy laws (including but not limited to Virginia, Colorado, Connecticut, Utah, Texas, Washington, Oregon, Montana, Tennessee, Indiana, Iowa, Delaware, New Jersey, New Hampshire, Kentucky, Minnesota, Maryland, and Rhode Island). Where consumer-health-data laws apply, we treat the information they cover with the protections in Section 15.
22.6 Appeals
If we deny a rights request in whole or in part, you may appeal by replying to our denial. We will respond within sixty (60) days. If we deny the appeal, we will provide instructions for filing a complaint with your state attorney general or supervisory authority.
22.7 Authorized agents
You may designate an authorized agent to make a request on your behalf. We will require written authorization from you and verification of the agent’s identity.
Verifying identity for rights requests
To protect Personal Data from unauthorized disclosure, we verify the identity of the requester before fulfilling an access, correction, deletion, or portability request. We typically use a combination of the following, calibrated to the sensitivity of the request:
- Knowledge of account credentials and a successful login.
- Confirmation of unique account information we already hold (e.g., signed-in device match).
- Email-based or in-product confirmation challenge.
- For high-risk requests (large data exports, deletion requests from a non-account email), additional confirmation through a channel already associated with the account. We do not use a third-party identity-verification vendor and we do not ask you to send us a government-issued identity document.
We will not charge a fee for the first request in any twelve-month period unless the request is manifestly unfounded or excessive, in which case we may charge a reasonable fee or refuse to act, as permitted by law.
Marketing communications
Marketing communications are sent only to individuals who have opted in, with a one-click unsubscribe in every email and an account-level marketing-preferences page. We do not condition the Services on receiving marketing communications. We do not engage in “targeted advertising” as that term is defined under U.S. state privacy laws. We may send transactional or service messages (account, security, billing) regardless of marketing preferences, as those are essential to the Services.
Children & teens
The Services are not directed to children under 13 in the United States, nor to children under the equivalent age of digital consent in your jurisdiction (16 in many EU member states). Our Terms require you to be 18 or older to hold an account.
How that is enforced today, stated plainly. There is no automated age gate at signup. We ask for your date of birth because it is clinically relevant, but the application does not currently block account creation based on it. That means our knowledge of a user’s age depends on what they tell us. We do not knowingly collect Personal Data from a child under 13, and if you are a parent or guardian and believe your child has provided us with Personal Data, contact [email protected] and we will delete it. Adding an enforced minimum-age check is on our pre-launch list.
Pediatric Sponsor flows. Pediatric features are not offered. If we offer them, they will be made available only through a Sponsor with appropriate parental consent and a separate notice. We honor the Children’s Online Privacy Protection Act (COPPA) for any data we come to hold from a U.S. child under 13.
Teens. For users between the age of 13 and 17 in the United States, we treat their data with the same heightened protections we apply to Sensitive Personal Information generally, and we obtain opt-in consent for any sale, sharing, or use of Sensitive Personal Information consistent with CPRA and analogous state laws.
Deceased users
On verified notice of a user’s death, Aler will (i) suspend the account, (ii) preserve the record under legal hold for the longer of one (1) year or any retention period required by law, (iii) accept access, copy, or deletion requests from a personal representative who provides the documentation we reasonably require (death certificate, proof of authority such as letters testamentary), and (iv) thereafter erase the record according to Section 17. Deceased-user records are not used for de-identified data licensing during the legal-hold period unless the personal representative consents.
Genetic information (GINA & state laws)
Genetic information is sensitive. We process it only with your explicit, separately-disclosed consent. We do not use it to make adverse decisions about you, do not share it with insurers or employers, and do not sell or license identifiable genetic information.
How genetic data actually reaches us. Genetics is a file upload, not an account connection. You export your raw data file from 23andMe or AncestryDNA yourself and upload it to Aler, and we parse the variants in it. We hold no login or authorization with any genetics service, we cannot fetch new data on our own, and we do not receive polygenic risk scores, ancestry reports, or microbiome results from any provider. Nothing genetic enters your account unless you put it there.
- The federal Genetic Information Nondiscrimination Act (“GINA”) prohibits health insurers and employers from using genetic information against individuals; while Aler is not in either category, we adopt GINA’s prohibitions as our own internal floor.
- For California residents, we comply with the California Genetic Information Privacy Act (“GIPA”), including its requirement of separate, distinct authorization for the sale of identifiable genetic information. We will not seek that authorization.
- For Florida residents, we comply with HB 833 and successor statutes restricting the use of DNA samples and genetic information by life, disability, and long-term-care insurers.
- Identifiable genetic information is excluded from de-identified data licensing unless and until we obtain affirmative, separate, opt-in consent that specifically references genetic data.
Insurance & accountability
Aler intends to carry cyber-liability insurance at coverage levels appropriate to the volume of Personal Data we hold, reviewed at least annually. Binding that coverage is part of our pre-launch work, and we will state here when it is in force rather than implying it already is. Where a Sponsor or clinical partner requires evidence of coverage as a condition of an agreement, we will provide it before that agreement takes effect.
Records. We maintain documented privacy and security policies and an internal compliance register that tracks, item by item, what is built and what is not. We do not claim alignment with the NIST SP 800-53 Moderate baseline or the HITRUST CSF, and we hold no SOC 2 report. A Records of Processing Activities register under GDPR Article 30 and a formal HIPAA risk analysis under 45 C.F.R. § 164.308(a)(1) are on our pre-launch list.
Changes to this policy
We may update this policy. Material changes will be announced in the product, by email to active users, and on this page at least thirty (30) days before they take effect, except where a faster change is required by law or to address a security risk. The “Effective” date and version number above always reflect the current policy. Prior versions are archived and available on request from [email protected].
Material changes that materially expand our use of Personal Data (including any change to the de-identified data licensing rules of Section 12) require renewed affirmative consent for processing of Sensitive Personal Information.
Complaints
If you have a concern about how Aler is handling your Personal Data, contact our Privacy Officer at [email protected]. We will acknowledge within five (5) business days and respond substantively within thirty (30) days. If you remain dissatisfied:
- U.S. residents may file a complaint with the U.S. Department of Health and Human Services Office for Civil Rights at hhs.gov/hipaa/filing-a-complaint or with your state attorney general.
- EU/UK residents may file with their local supervisory authority. A directory is at edpb.europa.eu/about-edpb/board/members_en for EEA, and ico.org.uk for the UK.
- The European Commission’s online dispute resolution platform is at ec.europa.eu/consumers/odr.
How to contact us
Aler Health, Inc.
Notice address: 1209 Orange Street, Wilmington, DE 19801, USA
Privacy Officer (HIPAA): [email protected]
Data Protection Officer (GDPR / UK GDPR): [email protected]
Security Officer: [email protected]
Legal: [email protected]
EU representative (GDPR Art. 27) and UK representative (UK GDPR Art. 27): to be appointed; current contact details available on request from [email protected].
