Moku Privacy Policy

Document version: v1.3 Effective date: 2026-09-22 Last updated: 2026-09-30

1. Who We Are and What This Policy Covers

Moku (operated by Arbor Ray, Inc., "Moku," "we," "our," or "us") is a consumer health-education app that helps you understand your own medical records. Your records reach Moku two ways: you can upload documents you already have — lab reports, imaging reports, discharge summaries, visit notes — or you can connect a health system and have your records retrieved for you, at your direction. Either way, we extract structured information, organize it, and generate educational explanations and suggestions for you to discuss with a clinician.

This Privacy Policy describes what we collect, how we use it, who we share it with, how long we keep it, and the rights you have over your information. It applies to your use of the Moku mobile app, web app, and any related services we provide.

If you are managing records on behalf of another person (a parent, adult child, spouse, or other adult family member you care for), this policy also describes our expectations of you as a caregiver. See Section 8.

2. Our Position on HIPAA

Moku is not a HIPAA covered entity, business associate, or healthcare provider. We do not have a treatment relationship with you, we do not bill insurance, and — apart from the optional data-sharing with a participating healthcare organization described in Section 9, which happens only when you join through such an organization and separately authorize it — we do not transmit health information to insurance companies or healthcare providers on your behalf. Under 45 CFR §160.103, the three types of HIPAA covered entities are health plans, health care clearinghouses, and providers who transmit health information in electronic form in connection with covered transactions. Moku is none of these.

(References to "healthcare provider" here are in the HIPAA sense. California's medical-confidentiality law (CMIA) may treat a consumer app that holds your medical information as a "provider of health care" for that law's confidentiality purposes only — which does not make Moku your treating clinician or a HIPAA covered entity.)

These statements describe our relationship with you as a consumer user of Moku. If you encounter Moku through your employer, health plan, or healthcare provider, separate terms govern that organization's relationship with us — under which Moku may be a HIPAA business associate of that organization. If you simply join through a participating healthcare organization's enrollment link as an individual, you remain a consumer user under this Privacy Policy and the Terms of Service, plus the optional Healthcare Organization Data-Sharing Authorization — those separate organizational terms do not displace your consumer account. See Section 13 of our Terms of Service.

HIPAA does not directly apply to your use of Moku. Because we handle health information outside HIPAA's scope, our breach-notification obligations are governed by the U.S. Federal Trade Commission's Health Breach Notification Rule (16 CFR Part 318) rather than HIPAA's. See Section 10.

HIPAA does not require this of us — we do it anyway. We voluntarily implement the controls a HIPAA covered entity would be required to implement, including:

Business Associate Agreements with every vendor that processes your health information on our behalf
Encryption of your data in transit (TLS 1.3) and at rest (AES-256) on HIPAA-eligible cloud infrastructure
Row-level access controls so that one account's data is isolated from another's
Audit logging for sensitive access events, including internal access by our team
Minimum-necessary access — only authorized personnel under confidentiality obligations can reach your data, and we keep that group as small as possible
Workforce training on privacy and security
Defined retention windows, with prompt deletion when retention purposes are exhausted

In several areas we go beyond what HIPAA would require. Three specific practices distinguish Moku from the baseline a HIPAA covered entity would have to meet:

Originals kept in a separate vault. The original PDF or image you upload, and the raw records retrieved from a connected health system, are copied shortly after they arrive (normally the same day) into a separately secured vault (its own storage, its own encryption keys, its own access controls; no ordinary part of our service can read it; only a single, separately authorized vault component, and — for a specific problem, as Section 7 describes — an individually authorized team member). We access vault copies only as needed to provide and improve the features you use. The vault copy is deleted when you delete the profile or your account. The working copies our processing systems use are short-lived. The working copy of an uploaded document is deleted from our processing systems typically within 7 days of the time we finish processing it, and never before its vault copy has been verified. The working copy of a connected record is de-identified in place typically within 7 days of import, and never before its vault copy has been verified (where the vault applies — see Section 6). We never delete or de-identify a working copy before its vault copy is verified, so a vault problem cannot lose your record. HIPAA permits identifiable records to stay in ordinary working systems indefinitely as long as safeguards are in place; we keep them out of our working systems after that window and hold the originals only in the vault. (Section 6 explains which records the vault applies to and how deletion works.)
De-identification of downstream data. Before our systems extract or interpret the medical content of your records — our extraction pipelines, the AI providers that reason over that content, and our internal review tooling — our automated pipeline works to replace direct identifiers in the text we extract from your records. (The automated steps that prepare a document — recognizing its text, checking that recognition, checking that the first page of an upload belongs to the profile it was added to, and classifying and splitting the pages of a multi-page file — and the automated step that finds the identifiers to replace necessarily see identified content; each runs under a Business Associate Agreement. See Section 5.) Full names, full dates of birth, phone numbers, email addresses, mailing addresses, medical record numbers, and Social Security numbers are tokenized (replaced with placeholders like [pt_name], [pt_dob], [pt_phone_1]) so that downstream systems work with the tokenized text instead. Among the identifiers that originate from your medical records, only your first name, year of birth, sex, your relationship to the person whose records you are organizing, and the dates of your medical events are retained in identifiable form in our long-lived account database. (Your account email and other account-management data are stored as you would expect for any account-based service; that is account information, not medical-record content.) HIPAA permits identifiable PHI to flow through derived systems under the Privacy and Security Rules; we tokenize direct identifiers by default.

Our de-identification is automated and best-effort. It is designed to catch the direct identifiers above wherever they appear, but no automated process is perfect, and it may occasionally miss an identifier embedded in the text of a record. That is one of the reasons every vendor that touches your health information on our behalf operates under a Business Associate Agreement (see Section 5), and why your data is encrypted at every stage regardless.

When we say data is "de-identified" in this policy, we mean data that has been through this automated identifier-removal process (best-effort, as described above). Such data may still include clinical details and the dates of medical events; we do not represent it as de-identified under any specific legal standard (such as the HIPAA Safe Harbor or Expert Determination methods).

If a feature ever needs your identifying details to do its job, we'll ask for your explicit consent first. (See Section 15.)
Zero Data Retention where the provider supports it. Every vendor that processes your health information does so under a Business Associate Agreement. For the AI model calls where the provider offers a Zero Data Retention mode — currently OpenAI — we contractually require it and enforce it in code, so those inputs and outputs are not retained by the provider. Other providers operate under a BAA with contractual retention and security controls rather than ZDR (for example, Google Cloud performs OCR, and AWS provides HIPAA-eligible storage). HIPAA requires only the BAA; we add ZDR wherever a provider supports it.

3. What Data We Collect

We collect the following categories of information:

Documents you upload. Medical records, lab reports, imaging reports, discharge summaries, visit notes, and similar files.
Medical records from connected health systems. If you choose to connect a hospital, clinic, or other healthcare organization, we receive copies of your medical records from that organization's systems in structured electronic format (FHIR), retrieved at your direction by our record-retrieval vendor. See "Connecting your medical records" below.
Information we extract from your records. Structured fields and findings derived from your uploads and connected records — diagnoses, medications, lab values, dates of service, providers, facilities, and other clinical information.
Profile information. What you tell us about each person whose records you are organizing, including first name, year of birth, sex, and the relationship between you and that person (yourself, parent, child, spouse, other).
Questions, prompts, and notes. Anything you type into the app, including questions you ask, instructions you give, and any free-text notes you add to a profile (such as conditions, allergies, or reminders).
Outputs we generate for you. Summaries, educational explanations, suggested topics to discuss with a clinician, and other content Moku produces from your data.
Account information. Your email address, login credentials, account settings, and language preference.
Product usage telemetry. Pages viewed, features used, and similar product-usage signals; plus device and browser information needed to operate the product. We do not capture the content of form fields, and URLs containing identifiers are normalized before being recorded.
Communications with us. Messages you send to our support team and our responses.
Security logs. Login events, access logs, and audit records used to keep your account and data secure.
Payment and transaction information. When you make a purchase, we receive what is needed to complete and record the sale — the amount, date, product, a transaction or receipt identifier, and (for web purchases) limited card metadata such as the card brand and last four digits returned by our payment processor. We do not receive or store your full payment-card number. For purchases made through the Apple App Store, Apple processes the payment and we receive only a transaction or receipt identifier. We also keep the reason you provide when you request a refund (see "Communications with us"). If we refund you outside Apple's or Stripe's normal flow (for example, when Apple declines an App Store refund), we may also collect the details needed to send you that refund. This payment information is not your medical records or the clinical content we extract, but — because it is linked to your use of a health-record service — we treat it as personal information that can be sensitive, and protect it accordingly.

We do not knowingly collect government identifiers (Social Security numbers, driver's license numbers) directly from you. If a record contains these identifiers in its text, we tokenize them before downstream processing (see Section 2 and Section 7).

Connecting your medical records

You can link a hospital, clinic, or other healthcare organization to Moku and have your records imported automatically. Here is how it works and who is involved:

Our vendor retrieves the records, at your direction. The connection is operated by Fasten Health, Inc., our record-retrieval vendor, under a Business Associate Agreement with us. Fasten retrieves your records only when you ask to connect an organization, and delivers them to Moku.
You will review Fasten's own terms. During the connect flow, you will be asked to review and agree to Fasten's own Terms of Use and Privacy Notice. What happens inside that flow is governed by Fasten's documents; this policy governs your records from the moment they reach Moku.
Two ways to connect. You can sign in to your own patient portal (for example, MyChart) — we never see your portal password — or you can use a nationwide record search. The nationwide search requires identity verification first: Fasten's identity-verification partners (such as CLEAR or ID.me) confirm who you are, which may involve a government ID and a selfie. Those steps are governed by Fasten's and the partner's own notices. If you prefer not to verify your identity that way, you can still connect by signing in to your patient portal directly.
The same rules apply once your records arrive. Records imported from a connected health system get the same treatment as records you upload: the same automated de-identification, on the same schedule, and the same protections described in this policy. (See Section 6 for how retention works for each route: the working copy of an uploaded file is deleted; the working copy of a connected record is de-identified in place; the original of each is kept in the vault.)
You can disconnect at any time. Disconnecting a health system in the app stops future retrievals. Records already imported remain in your profile until you delete them.

4. How We Use Your Information

The short version, in plain language:

We minimize the identifying data we keep. The working copy of an uploaded file is deleted typically within 7 days of the time we finish processing it, and never before its vault copy has been verified. The working copy of a record from a connected health system is de-identified in place typically within 7 days of import, and never before its vault copy has been verified, after which our working systems hold only that de-identified copy. The original is kept only in the separately secured vault described in Section 2 (see Section 6). From the medical text we process, our automated pipeline works to remove direct identifiers — full names, full dates of birth, phone numbers, email addresses, mailing addresses, medical record numbers, and Social Security numbers — before our systems extract or interpret its medical content (best-effort; see Section 2). The only personal identifiers we keep in our account database are your first name, year of birth, sex, your relationship to the profile subject, and the dates of your medical events. (We retain the clinical content and the dates of medical events from your records so the product works — but only after the identifier-removal step above.)
We will never sell your data. Not now. Not ever. We do not share your data with data brokers, and we do not use it for targeted advertising.
We may use de-identified data to improve our products. Once your data has been through the identifier-removal process described in Section 2, we may use it to improve Moku's accuracy, evaluate quality, and develop new features. We do not use your data to train third-party AI providers' foundation models (see Section 5).

The longer version: we use the information described in Section 3 to operate Moku and provide you the product, including to:

Read the text and images in your records and turn them into structured medical information
Generate educational summaries, explanations, and suggested topics for you to discuss with a clinician
Organize your profile so that you and any authorized caregiver can navigate it
Let you review what we extracted and provide copies of your data on request
Improve the accuracy, reliability, and usefulness of Moku, using de-identified data and product-usage telemetry (see Section 7)
Respond to your support requests
Maintain the security, reliability, and integrity of the product
Comply with our legal obligations

We do not use your information for purposes unrelated to providing and improving the product without your separate consent, except as required by law.

5. AI and Third-Party Processing

Moku uses third-party AI providers to power parts of the pipeline. These AI steps apply to your records however they reach us — whether you uploaded them or connected a health system. We have selected providers that operate under signed Business Associate Agreements with us and that offer contractual restrictions on data retention and use for training.

Sub-processors we currently use. Each operates under a signed Business Associate Agreement (BAA) with us:

Google Cloud (Vertex AI / Gemini) — What we send: the record itself, because optical character recognition (OCR) and the related document-preparation steps — checking the OCR output, checking that the first page of an upload belongs to the profile it was added to, and classifying and splitting the pages of a multi-page file — require it. Protections: BAA-covered; used only to perform those document-preparation steps for us; not used to train Google's models.
OpenAI — What we send: de-identified, structured text (extracted fields, snippets, JSON), with direct identifiers tokenized first (see Section 2), for the reasoning, summarization, and explanation steps; and, for the identifier-finding step only, the recognized text of a record before de-identification, so that the identifiers can be located and replaced. Protections: BAA-covered, with Zero Data Retention enforced and no training on your content.
Amazon Web Services (AWS) — What we send: your records and the extracted data we derive from them, for HIPAA-eligible cloud storage and hosting in the United States. Protections: BAA-covered; encrypted in transit (TLS 1.3) and at rest (AES-256); not used to train any models.

Equal protection. We require each of these providers, by contract, to protect your information at least as protectively as this Privacy Policy requires, to use it only to perform the service for us, and not to use it for their own advertising or to train their general-purpose models.

We may add or replace providers over time, and we update our sub-processor list (see Section 9) when we do. Any new AI provider operates under the same Business Associate Agreement and equal-protection requirements described above. Where we access an AI model through a hosting provider (for example, a cloud provider's managed model service), those calls run inside that provider's environment under our existing Business Associate Agreement, and the company that built the model does not receive your data. We will not add a category of recipient that meaningfully changes how your data is processed without notifying you and, where required, obtaining your consent.

What is sent to providers, and what is not:

For document preparation — OCR, checking the OCR output, checking that the first page of an upload belongs to the profile it was added to, and classifying and splitting the pages of a multi-page file — we send the record itself to the OCR provider because those steps require it.
For identifier-finding, we send the recognized text of a record, before de-identification, to an AI provider (currently OpenAI, under Zero Data Retention) whose only job in that step is to locate the identifiers we then replace. Records from a connected health system go through the same identifier-finding step.
For every other AI step — entity detection, extraction, abstraction, quality evaluation, educational explanations, and suggested topics to discuss with a clinician — we send de-identified structured data (extracted fields, snippets, JSON) rather than the raw record. Direct identifiers are tokenized first (see Section 2).
We do not allow AI providers to use your content to train their general-purpose models. Where the provider supports Zero Data Retention, we enforce it.
Some providers may temporarily retain inputs and outputs for limited operational, security, abuse-monitoring, debugging, or legal-compliance purposes. We rely on the provider's contractual terms to limit that retention.

We do not use your identifiable health information for external research, advertising, or training of foundation models — ours or anyone else's — without your separate consent.

Withdrawing your consent. You can stop this AI processing at any time by deleting the relevant profile or your account (see Sections 6 and 11). Deletion ends future processing and, as explained in Section 6, removes the vault copy of your originals. Independently of any deletion, the working copy of an uploaded document is deleted typically within 7 days of processing, and the working copy of a connected record is de-identified typically within 7 days of import, and never before its vault copy has been verified (see Section 6); and content already sent to a provider cannot be unsent.

6. Data Retention

We hold different categories of data for different periods:

Original uploaded documents (PDFs, images): the working copy is deleted from our processing systems typically within 7 days of the time we finish processing it, and never before its vault copy has been verified (where the vault applies — see "Vault copies of originals" below). A copy of the original is kept in the vault (see below).
Raw records from connected health systems (FHIR): the working copy is de-identified in place typically within 7 days of import, and never before its vault copy has been verified — our automated process replaces direct identifiers in that copy (best-effort, as described in Section 2), and from then on our processing systems hold only that processed copy, which we keep while your account or the relevant profile is active. A copy of the raw record as retrieved is kept in the vault (see below).
Vault copies of originals: kept in the separately secured vault described in Section 2 while the profile and your account exist. We access vault copies only as needed to provide and improve the features you use. The vault applies to records added after you accept this version of the policy (a profile you create under this version counts as acceptance); records added before that have no vault copy and remain governed by the version of this policy in force when they were added (the working copy of an uploaded document is deleted typically within 7 days of processing; the working copy of a connected record is de-identified typically within 7 days of import). The vault copy is kept until you delete the profile or your account. Deleting a single record removes it from your profile and from our processing systems, but its vault copy stays until the profile is deleted. If you ask us to delete specific records under your rights in Section 11 (or the Consumer Health Data Privacy notice), we delete their vault copies as well. When you delete a profile or your account, we destroy the encryption key for that profile's vault copies, which makes every copy, including copies in backups, unreadable; that becomes irreversible once the backup window described under "Backups" below has passed. The unreadable encrypted remnants may persist in storage.
Extracted, de-identified text and structured findings: retained while your account or the relevant profile is active, so that you can keep reviewing what we found and ask follow-up questions. Deleted when you delete the profile or your account.
Profile information (first name, year of birth, sex, relationship): retained while your account is active; deleted when you delete the profile or your account.
Account information: retained while your account is active; deleted when you close your account.
Telemetry: retained for a limited period for product analysis and then aggregated or deleted.
Audit logs: retained longer than user data, as required for security and compliance, even after a profile or account is deleted. Audit logs record access events; they do not contain the underlying medical content.
Vault access log: every read of a vault copy, and every refused attempt, is recorded — reads by our own systems in the vault access log (which system, when, which record, and the reason); human access is recorded in our cloud provider's independent access trail (and, when made through our tools, in the vault access log as well) and alerts our team. These records are retained with our audit logs, on the same terms, and do not contain the underlying medical content.
Backups: deleted data may persist in encrypted backups for a limited rolling window before being overwritten on backup rotation.
AI provider-side retention: governed by the provider's contractual terms with us. See Section 5.
Support messages: retained for a limited period to maintain a record of your requests and our responses.
Payment and transaction records: retained as long as required for accounting, tax, and legal-compliance purposes (typically longer than we keep your health data), and otherwise handled under the payment processor's own terms. These records contain transaction metadata, not your medical content.

When you delete a profile or your account, we delete active-system copies of the corresponding records and extracted data within a reasonable period, subject to the backup and audit-log retention above. Deletion of active-system data ends future processing but does not undo processing that has already occurred — for example, content already sent to an AI provider cannot be unsent.

7. How We Protect Your Data

We use a layered set of safeguards, including:

Encryption. Your records, extracted data, and account information are encrypted in transit (TLS 1.3) and at rest (AES-256) on HIPAA-eligible cloud infrastructure operated by AWS in the United States.
De-identification at source. Our automated process tokenizes direct identifiers in the text of your records before our systems extract or interpret the medical content of your records — a best-effort step, as described in Section 2. If a feature ever needs your identifying details to do its job, we'll ask for your explicit consent first.
Access controls. Row-level security in our databases isolates one account's data from another's. Only authorized Moku personnel under confidentiality obligations can reach your data, and we work to keep that group as small as possible.
Audit logs. Sensitive access events are logged, including internal access by our team.
Vendor controls. Contractual Business Associate Agreements with every vendor that processes your health information on our behalf, with no training on your content and Zero Data Retention enforced where the provider supports it (currently OpenAI for the AI model calls) — see Section 5.
Workforce training. Our personnel are trained on privacy, security, and handling of health information.
Telemetry minimization. Form-field values are not captured by our product telemetry, and URLs containing identifiers are normalized before being recorded.
Incident response. We have procedures for investigating and containing security events, and a process for notifying affected users under the legal regimes described in Section 10.

Limited raw-record access for issue resolution. While a working copy of a raw record is in our processing systems — an uploaded document within its 7-day window, or a connected record before de-identification — and for as long as a vault copy exists, an authorized Moku team member may view it only if we have identified, or you have reported, an issue with how it was processed — for example, an extraction error. We commit to:

Using raw-record access only to diagnose a specific identified or reported issue, and viewing only the portions necessary
Restricting raw-record access to a small set of authorized team members under confidentiality obligations
Audit-logging every raw-record access, including the team member, timestamp, record identifier, the reason for access, and whether any copy, export, or download occurred

We do not allow casual browsing of your records. Once the working copy of an uploaded document has been deleted or a connected record has been de-identified, the raw version is readable only from the vault: by our own systems, only as needed to provide and improve the features you use, or, when we have identified or you have reported a problem with how a record was processed, by a small number of authorized team members on a minimum-necessary basis: only the portions needed to resolve it, with every access logged — who, when, which record, the reason, and whether anything was copied or exported. Every read by our own systems is recorded in the vault access log, and human access is recorded in our cloud provider's independent access trail (and, when made through our tools, in the vault access log as well) and alerts our team (see "Vault access log" in Section 6).

No system is perfectly secure, and we cannot guarantee absolute security. We commit to handling your data with care and to the safeguards above.

8. Caregiver and Proxy Records

Moku is designed for use by an adult reviewing their own records or by an adult family caregiver reviewing the records of another adult. The profile subject — the person whose records you are bringing in — must be 18 years of age or older. Moku does not support pediatric records.

If you upload records — or connect a health system — for someone other than yourself, you confirm that you have legal authority, or that person's informed consent, to do so. Examples of legal authority include holding a valid healthcare power of attorney, being a court-appointed guardian for an adult, or acting as the personal representative of an estate.

You are responsible for using the information in Moku appropriately on behalf of that person and for honoring their wishes about how their information is handled. If the person whose records you manage asks you to delete their data, you can do so at any time by deleting that profile.

We may at any time ask you to confirm your authority to manage records for another person.

9. Who We Share Data With

We share data only with the following categories of recipients, and only as needed to provide and improve the product:

Cloud hosting and infrastructure providers — to store and process your data
AI and model providers — as described in Section 5
Electronic health record connectivity providers — to retrieve, at your direction and with your authorization, copies of your medical records from healthcare institutions' systems so you can bring them into Moku. Our current provider is Fasten Health, Inc., which operates under a Business Associate Agreement with us (see Section 3, "Connecting your medical records")
Your enrolling healthcare organization and its provider — only if you authorize it — if you joined through a participating healthcare organization (such as a clinic, medical group, or health system) and signed the separate Healthcare Organization Data-Sharing Authorization, we make the organized information in your account viewable read-only to that one organization and the provider there — never another organization, provider, employer, health plan, or insurer. Optional and revocable at any time; anything the organization has already saved in its own systems is then governed by that organization's privacy practices.
Error and security monitoring providers — to detect bugs, crashes, and security events
Customer support tooling — to respond to your support requests
Payment processors — to take payment and process refunds. On the web, our processor is Stripe; in the iOS app, purchases are processed by Apple. These providers receive only the billing and transaction information needed to complete your purchase — not your medical records or the health information we extract from them. For an App Store refund request, we may send Apple limited transaction and delivery/consumption status about the purchase so Apple can evaluate the refund — again, no medical records or extracted health data. If we send you a separate-channel refund (for example, after Apple declines a refund), we may also share the payout details you give us with the payment service or financial institution used to send that reimbursement — billing information only, never health data
Legal and compliance recipients — when we are legally required to disclose information (for example, in response to a valid subpoena or court order), or when necessary to protect rights, safety, or the integrity of the product

We maintain a current list of the specific sub-processors that handle your data on our behalf. You can request our current sub-processor list by contacting us at the address in Section 17.

We do not sell your data. We do not share it with data brokers. We do not use it for targeted advertising.

Text messages. If you give us your mobile number for care texts and calls, we use it only to send the messages you agreed to. We do not share, sell, or provide your mobile phone number or text-messaging consent to third parties or affiliates for marketing or promotional purposes. Service providers that deliver our messages receive your number only to send them.

10. Breach Notification

Because Moku is not a HIPAA covered entity (see Section 2), our breach-notification obligations are governed by the U.S. Federal Trade Commission's Health Breach Notification Rule (16 CFR Part 318), not HIPAA. If we discover a breach of unsecured personally identifiable health information, we will:

Notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery.
Notify the FTC in accordance with the timing and threshold requirements of 16 CFR §318.5, including the heightened notice requirements that apply when a breach affects 500 or more individuals.
Notify prominent media in any state or jurisdiction where 500 or more individuals are affected, at the same time as the individual notice.

We will also comply with any breach-notification obligations imposed by applicable state law, including those listed in Section 11.

11. Your Rights by Jurisdiction

Your rights over your information depend on where you live. The rights described below are in addition to the controls Moku gives every user — you can review what we have extracted, request a copy of your data, disconnect a health system, delete your profile, and withdraw your consent at any time through the app or by contacting us.

California residents have rights under both the Confidentiality of Medical Information Act (CMIA) and the California Consumer Privacy Act / Privacy Rights Act (CCPA/CPRA), including the right to access, correct, and delete your personal information; the right to limit our use of sensitive personal information; and a private right of action under CMIA for certain violations. We treat health information as sensitive personal information under CPRA.

Washington residents have rights under the My Health My Data Act (RCW 19.373), including the right to confirm whether we are collecting your consumer health data, the right to withdraw consent, the right to delete your consumer health data, and a private right of action. We collect Washington residents' consumer health data only with your prior consent, and we do not sell it.

Nevada residents have rights under SB 370 (consumer health data, codified in NRS 603A), including the right to know what consumer health data we collect and the right to have it deleted. Nevada law generally requires affirmative consent to collect or share consumer health data and written authorization to sell it; we do not sell consumer health data, and where Nevada law requires separate consents for collection and for sharing, we obtain them.

Connecticut residents have rights under the Connecticut Data Privacy Act, including opt-in consent for processing of consumer health data, the right to access and delete, and the right to opt out of targeted advertising and profiling (we do not engage in either with your health data).

Colorado and Texas residents have rights under the Colorado Privacy Act and the Texas Data Privacy and Security Act, including opt-in consent for processing of sensitive personal information, the right to access, correct, and delete, and the right to opt out of certain processing.

Other U.S. states with consumer privacy laws may grant you similar rights. We honor those rights to the extent the laws apply.

European Economic Area, United Kingdom, and Switzerland residents. Moku is currently offered to residents of the United States. We do not actively serve users in the European Economic Area, the United Kingdom, or Switzerland, and we have not designated an Article 27 representative or established the formal transfer mechanisms (such as Standard Contractual Clauses or the EU-U.S. Data Privacy Framework) that EU/UK/Swiss data-protection law would require for routine processing of EU/UK/Swiss residents' personal data. If you access Moku from one of these jurisdictions, you do so at your own initiative and you understand that your data will be processed in the United States under U.S. law.

To exercise any of these rights, contact us at the address in Section 17. We will respond within the timeframes required by applicable law.

12. Children's Privacy

Moku is for adults only. Both the account holder and the profile subject (the person whose records are being managed) must be at least 18 years old. We do not knowingly collect personal information from individuals under 18, and we do not allow records belonging to individuals under 18 to be brought into a Moku profile — by the user themselves or by a caregiver acting on their behalf.

If we learn that we have collected personal information from a person under 18 or that pediatric records have been added in violation of this policy, we will delete that information promptly and may restrict the account. If you believe we have collected such information, contact us at the address in Section 17.

13. International Data Transfers

Moku is operated from the United States, and the cloud infrastructure we use to store and process your data is located in the United States. Some of our service providers may process data in other locations, as described in their own notices; every vendor that handles your health information on our behalf is bound by a Business Associate Agreement wherever it operates. We do not currently offer Moku in jurisdictions outside the United States, and we use region-based access controls intended to block access from the European Economic Area, the United Kingdom, Switzerland, mainland China, Hong Kong, and Macau. If you access Moku from outside the United States, you understand that your information will be transferred to, stored, and processed in the United States, which may have different data-protection laws than your country of residence. See Section 11 (European Economic Area, United Kingdom, and Switzerland) for jurisdiction-specific considerations.

14. Business Transfers and Wind-Down

If Moku is involved in a merger, acquisition, financing, reorganization, sale of assets, bankruptcy, or wind-down, your information may be transferred to a successor or acquirer as part of that transaction, but only subject to this Privacy Policy (or one at least as protective) and any consents you have given. If no successor assumes the Service, we will delete or de-identify your medical-record content rather than transfer it to an unrelated third party, except where retention is required by law. We will notify you (in the app or by email) before your information becomes subject to a materially different privacy policy, and give you the opportunity to delete your account first.

15. Changes to This Policy

We may update this Privacy Policy. When we make a material change, we will:

Bump the Document version at the top of this page and update the Last updated date
Notify you in the app or by email before the change takes effect, where the change is material to how we handle your information
Keep a record of prior versions and material changes in our version history

Where a change would let us keep identifiable health information longer, collect a new category of it, use it for a new purpose, or introduce a feature that needs your identifying details, we will ask for your affirmative consent in the app before it applies to you; until you accept, the previous version keeps governing your data. Where we ask for that consent in the app, you will need to accept before continuing to use Moku; if you prefer not to, you can delete your account instead, and everything you have already added stays under the previous version until then. For other changes, and subject to any consent that applicable law separately requires, your continued use of Moku after the change takes effect constitutes your acceptance of the revised policy. If you do not agree with a change, you may close your account before it takes effect.

16. Version History

v1.3 — 2026-09-22 (clarified 2026-09-30: adds a text-message statement to Section 9 — your mobile number and text-messaging consent are never shared for marketing) — Originals are kept in a separate vault instead of being deleted: the original of each uploaded document and each raw connected record is copied shortly after arrival into a separately secured vault with its own storage, encryption keys, and access controls, and is deleted when you delete the profile or your account; the working copy of an uploaded document is deleted and the working copy of a connected record is de-identified, typically within 7 days, and never before the vault copy is verified (Sections 2, 4, 5, 6, 7). Applies only to records added after you accept this version. Our systems access vault copies only as needed to provide and improve the features you use; human access keeps the existing trigger — an identified or reported processing issue — with minimum-necessary scope (Section 7). Restates the connected-records route sentence for the vault (Section 3), adds the dates of your medical events to the list of identifiers we retain (Sections 2, 4), adds the vault access log to retention (Section 6), states plainly how vault deletion works (Section 6), clarifies that de-identification applies before our systems extract or interpret the medical content of your records and discloses the document-preparation and identifier-finding steps that see identified content (Sections 2, 5), commits to explicit consent before any feature that needs identifying details (Sections 2, 7), honors record-level deletion requests made under your legal rights by deleting the vault copies too (Section 6), and commits to asking for your affirmative consent in the app before any change that would keep identifiable health information longer, collect a new category of it, use it for a new purpose, or introduce a feature that needs your identifying details (Section 15).
v1.2 — 2026-06-18 — Adds payment and transaction data handling alongside the new paid features: what payment information we collect (Section 3), the payment processors we share it with — Stripe and Apple — and the limited consumption/transaction status we may share with Apple (or a payout provider) to process a refund (Section 9), and the retention of financial records (Section 6). Updates a cross-reference to the renumbered Terms of Service. Adds an optional, patient-authorized, read-only data-sharing carve-out for a participating healthcare organization you join through (Sections 2 and 9), governed by the separate Healthcare Organization Data-Sharing Authorization, and notes that California's CMIA may treat Moku as a "provider of health care" for that law's confidentiality purposes only (Section 2).
v1.1 — 2026-06-05 — Adds the connected-health-system route for bringing in records (retrieved at your direction by our record-retrieval vendor, Fasten Health, Inc.), a Business Transfers and Wind-Down section, and clarified de-identification and retention language covering both ways records reach Moku.
v1.0 — 2026-05-27 — Initial general-availability Privacy Policy. Supersedes the prior waitlist-era Privacy Policy and the v1.0-alpha Data Use, Privacy & Product Safety Acknowledgement.

17. Contact Us

If you have questions about this Privacy Policy or your information, or to exercise any of the rights described above, contact us at:

Moku (Arbor Ray, Inc.) Email: info@mokuhealth.ai

We aim to respond to all privacy inquiries within the timeframes required by applicable law and, in any event, without undue delay.