Business Associate Agreement
This Business Associate Agreement (“BAA”) is between Solemark LLC, a Wyoming limited liability company (“Solemark”, “we”), and the organization that accepts it in its Pillwise account (“Customer”, “you”). It supplements the Pillwise Terms of Service (the “Terms”).
1. When this BAA applies
1.1 Acceptance. An authorized user accepts this BAA for Customer when attaching Pillwise Cabinet at checkout or in the account. We record who accepted, when, which version (with a SHA-256 fingerprint of its exact text), and the IP address and browser used. That record is the signature of both parties. Each party agrees that this electronic acceptance binds it as a signed writing would.
1.2 Effective date. This BAA takes effect when Cabinet is first enabled for any of Customer’s live tenants (the “Effective Date”). It covers Protected Health Information that Customer sends to Cabinet from then on. Customer must not send PHI to Pillwise before that date, or to any part of Pillwise other than Cabinet.
1.3 Customer’s role. Customer is a Covered Entity, or a Business Associate of one. If Customer is a Business Associate, Solemark is its subcontractor. In that case, “Covered Entity obligations” in this BAA are those Customer owes under its own business associate agreement, to the extent Customer has told Solemark about them in writing.
1.4 Scope. Only Pillwise Cabinet is meant to hold PHI. Pillwise Index, the sandbox, the websites, support email, and the account and billing pages are not designed for PHI. This BAA does not cover PHI that Customer puts there.
2. Definitions
Capitalized terms used here and not defined here have the meanings given in HIPAA: Breach, Business Associate, Covered Entity, Designated Record Set, Individual, Required by Law, Secretary, Security Incident, Subcontractor, and Unsecured Protected Health Information.
- “HIPAA” means the Health Insurance Portability and Accountability Act of 1996, the HITECH Act, and their regulations at 45 C.F.R. Parts 160 and 164, as amended.
- “PHI” means Protected Health Information, as defined at 45 C.F.R. § 160.103, that Solemark creates, receives, maintains, or transmits for Customer through Cabinet.
3. How we may use and disclose PHI
3.1 To provide Cabinet. We may use and disclose PHI only to provide Cabinet to Customer under the Terms and Customer’s documentation, and as this BAA otherwise allows or as Required by Law.
3.2 Management and administration. We may use PHI for our proper management and administration and to carry out our legal responsibilities. We may disclose PHI for those purposes only if:
- the disclosure is Required by Law; or
- we get reasonable assurances from the recipient that it will keep the PHI confidential, use or disclose it only as Required by Law or for the purpose of the disclosure, and tell us of any breach of confidentiality it knows of.
3.3 What we do not do. We do not:
- sell PHI;
- use PHI for marketing;
- de-identify PHI for our own use;
- aggregate PHI across customers;
- use PHI to train models or build products;
- let anyone outside the United States access PHI or store it there;
- try to identify any Individual, or combine PHI with other data to do so.
3.4 Used for Cabinet only. Cabinet records are kept separate from every other Pillwise dataset, including Index and usage data. We use them only to provide Cabinet to the Customer they belong to, and for the purposes in 3.2.
3.5 Minimum necessary. We limit our use and disclosure of PHI, and our requests for it, to the minimum necessary for the purpose.
3.6 Covered Entity obligations. If we carry out any of Customer’s obligations under Subpart E of 45 C.F.R. Part 164, we comply with the requirements of Subpart E that apply to Customer in performing them.
4. Safeguards
4.1 Security Rule. We comply with Subpart C of 45 C.F.R. Part 164 for electronic PHI. We use administrative, physical, and technical safeguards to prevent any use or disclosure of PHI that this BAA does not allow.
4.2 Current controls. These include:
- PHI is encrypted at rest, with a separate data key for each tenant, and encrypted in transit with TLS.
- Member identifiers that Customer sends are tokenized. Cabinet stores a generated member id, not the raw identifier.
- Access is logged to a tamper-evident, hash-chained audit trail. Its checkpoints are written to locked storage.
- Each Customer’s data is isolated by tenant in the database and in the API.
- Operational logs and analytics are designed to exclude PHI.
We may change these controls if the protection stays at least as strong.
4.3 Pseudonymous by design. Cabinet is built so that Solemark cannot tell who a member is:
- Customer identifies a member with its own member identifier. Cabinet uses that identifier only in memory, to compute a keyed token, and never stores or logs it.
- Each record is filed under a random member id that Cabinet generates. That id says nothing about the person.
- We hold no names, contact details, or other directory information about members. Only Customer can link a member id to a person, using its own records.
Cabinet records can still include medication details and dates that Customer sends. The parties therefore treat Cabinet records as PHI under this BAA. This section does not mean they are “de-identified” under 45 C.F.R. § 164.514.
5. Reporting
5.1 What we report. We report to Customer:
- any use or disclosure of PHI that this BAA does not allow;
- any Security Incident;
- any Breach of Unsecured PHI, as 45 C.F.R. § 164.410 requires.
5.2 When. We report a Breach without unreasonable delay, and no later than 10 business days after we discover it. We report other events in 5.1 within 10 business days of becoming aware of them. A delay that a law enforcement official requests under 45 C.F.R. § 164.412 is permitted.
5.3 What a Breach report contains. To the extent we know it, a Breach report includes:
- the Individuals affected;
- what happened, and when;
- the kinds of PHI involved;
- what we are doing about it;
- any other information Customer reasonably needs to meet its own notification duties.
We send updates as we learn more.
5.4 Unsuccessful attempts. This section is our notice, now and on an ongoing basis, of unsuccessful Security Incidents. These include pings, port scans, denied sign-in attempts, and denial-of-service attempts that do not lead to unauthorized access, use, or disclosure of PHI. We do not report these separately.
5.5 Mitigation. We take reasonable steps to mitigate any harmful effect of a use or disclosure of PHI by us that this BAA does not allow.
5.6 How we notify. We send notices by email to Customer’s account owners and to any security contact Customer names in its account.
6. Subcontractors
6.1 Same terms. Any Subcontractor that creates, receives, maintains, or transmits PHI for us must agree in writing to the same restrictions, conditions, and requirements that apply to us under this BAA.
6.2 Current Subcontractors. Our current Subcontractors for PHI are:
- Fly.io, Inc., which runs the hosting and compute;
- Neon, provided by Databricks, Inc., which runs the database.
Both store PHI in the United States: Fly.io in Ashburn, Virginia, and Neon in AWS us-east-1.
6.3 Changes. We publish the current list with this BAA. We give at least 30 days’ notice by email before a new Subcontractor receives PHI.
7. Individuals’ rights
7.1 Access. Customer can read its members’ Cabinet records through the API. If Customer needs our help to give an Individual access under 45 C.F.R. § 164.524, we provide it within 10 business days of Customer’s request.
7.2 Amendment. Customer can correct records through the API. If Customer needs our help to amend PHI under 45 C.F.R. § 164.526, we provide it within 10 business days of Customer’s request.
7.3 Accounting of disclosures. We keep the information needed for Customer to give an accounting of disclosures under 45 C.F.R. § 164.528. We provide it within 15 business days of Customer’s request.
7.4 Requests sent to us. If an Individual asks us directly for access, amendment, or an accounting, we forward the request to Customer within 5 business days. We do not respond to it ourselves.
8. Customer’s responsibilities
8.1 Notice of practices. Customer tells us of any limitation in its notice of privacy practices that affects our use or disclosure of PHI.
8.2 Changes in permission. Customer tells us of any change in, or revocation of, an Individual’s permission to use or disclose PHI, to the extent it affects us.
8.3 Restrictions. Customer tells us of any restriction it agrees to under 45 C.F.R. § 164.522 that affects us.
8.4 What Customer asks of us. Customer does not ask us to use or disclose PHI in a way that HIPAA would not allow Customer to.
8.5 What Customer sends. Customer sends only the PHI Cabinet needs, and only to Cabinet.
8.6 Customer’s own systems. Customer is responsible for the security of its own systems and API keys, and for what it does with PHI it receives back from Cabinet. That includes webhook payloads delivered to endpoints Customer registers.
9. Records available to the Secretary
We make our internal practices, books, and records relating to PHI available to the Secretary, to determine compliance with HIPAA.
10. Term and termination
10.1 Term. This BAA lasts while Cabinet is enabled for Customer. It also continues afterwards until we have returned or destroyed all PHI under Section 11.
10.2 Termination for breach. If either party learns that the other has materially breached this BAA, it may give written notice. If the breach is not cured within 30 days, it may terminate this BAA and the Cabinet portion of the Terms. If cure is not possible, it may terminate immediately.
10.3 Ending Cabinet. Cancelling Cabinet, or the plan Cabinet is attached to, ends Cabinet for Customer. Section 11 then applies.
11. Return or destruction of PHI
11.1 Export. For 30 days after Cabinet ends, Customer may export its Cabinet records through the API or ask us for an export.
11.2 Deletion. After that period, or sooner if Customer asks in writing, we delete Customer’s Cabinet records. We also delete Customer’s member tokens and the keys that decrypt its data. We confirm the deletion in writing.
11.3 Backups. Encrypted copies may remain in database backups and point-in-time history for up to 7 days afterwards, and then expire. Those copies cannot be read without keys we delete, or rotate, under 11.2.
11.4 Audit trail. The audit trail is kept to meet our and Customer’s record-keeping duties. It records actions and identifiers, not the contents of Cabinet records. We keep it for 6 years.
11.5 If return or destruction is not feasible. If returning or destroying any PHI is not feasible, we tell Customer why. We then extend this BAA’s protections to that PHI, and limit further use and disclosure to the purposes that make return or destruction infeasible, for as long as we keep it.
12. Changes to this BAA
12.1 Versions. Each version of this BAA has a version number and a permanent web address. Earlier versions stay published. Customer’s account shows the version Customer accepted and when.
12.2 Changes required by law. We may amend this BAA as needed to comply with a change in HIPAA. That amendment takes effect on the date the law requires.
12.3 Other changes. For any other change, we email Customer’s account owners at least 30 days before it takes effect. We also show it in the account, with a summary of what changed.
- Customer may accept the new version in its account at any time.
- If Customer neither accepts it nor ends Cabinet before the effective date, continued use of Cabinet after that date means Customer accepts it.
- If Customer objects, Customer may end Cabinet before the effective date. The version Customer last accepted then governs until its PHI is returned or destroyed.
12.4 Never retroactive. A change never applies to events before its effective date. It never reduces the protection of PHI below what HIPAA requires.
13. General
13.1 Order of precedence. If this BAA conflicts with the Terms on PHI, this BAA controls.
13.2 Interpretation. Any ambiguity is resolved to permit compliance with HIPAA.
13.3 No third-party beneficiaries. Nothing in this BAA gives rights to anyone other than Customer and Solemark.
13.4 Survival. Sections 5, 9, 11, and 13 survive termination.
13.5 Liability. Each party’s liability under this BAA is subject to the limitations of liability in the Terms. Solemark’s liability for Data Breach Costs, as defined there, is limited to three times (3×) the fees Customer paid to Solemark for Pillwise in the 12 months before the Breach.
13.6 Governing law. This BAA is governed by the laws of the State of Wyoming, except where federal law, including HIPAA, governs.
13.7 Notices. Notices to Solemark go to privacy@pillwise.dev. Notices to Customer go to its account owners’ email addresses.