5ba31fac03
lead-sttil drafted, ops-steward independently reviewed (6 findings fixed). Entity name corrected to KJF Professional Services LLC dba STTIL Solutions. Formation state left as attorney question 1. LOI/NDA v3 live in STTIL-Vault/Projects/Legal. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
224 lines
15 KiB
Markdown
224 lines
15 KiB
Markdown
# BUSINESS ASSOCIATE AGREEMENT (Template v1)
|
|
|
|
> **DRAFT, for attorney review before use. Not legal advice.**
|
|
> Prepared 2026-07-07. Generalized from the a prior supplier-specific BAA into a reusable STTIL Solutions template. This is a FORWARD-LOOKING instrument. See "Status and posture" immediately below before reading the operative terms.
|
|
|
|
---
|
|
|
|
## STATUS AND POSTURE (read first, attorney)
|
|
|
|
This BAA template is prepared as a forward-looking instrument, not a description of the current live environment. As of 2026-07-07:
|
|
|
|
- Real PHI is BLOCKED. The Product operates on mock and de-identified data today; no real protected health information is in active exposure (Signal current-state.md, 2026-07-07).
|
|
- The current pilot stack (Supabase, Railway, Vercel, Clerk) does NOT have executed subprocessor BAAs in place. The subprocessor table in Section 2.5 describes the pilot stack, not a BAA-covered chain.
|
|
- AWS is the compliant migration path. An AWS BAA was signed and became active 2026-05-27; RDS and S3 are provisioned but parked, not in active build until post-funding. If and when a Covered Entity relationship requires real PHI, the Product migrates to the AWS (or equivalent BAA-capable) environment before any PHI is processed, and the subprocessor table is updated accordingly.
|
|
|
|
Counsel should review this template as the instrument STTIL would execute at the point real PHI enters the system, and advise on the threshold question in Attorney Review Note 1 (whether a BAA is required at all given the crosswalk-stays-with-supplier architecture).
|
|
|
|
---
|
|
|
|
**Effective Date:** __________ , 20__
|
|
|
|
**Between:**
|
|
- **KJF Professional Services LLC d/b/a STTIL Solutions** ("Business Associate"), a [STATE, confirm formation state with counsel] limited liability company, Kisa Fenn, Managing Member
|
|
- **[COVERED ENTITY FULL LEGAL NAME]** ("Covered Entity"), [SIGNER NAME], [SIGNER TITLE]
|
|
|
|
Each a "Party" and together the "Parties."
|
|
|
|
---
|
|
|
|
## Recitals
|
|
|
|
Covered Entity is [a durable medical equipment supplier / a healthcare provider / other] subject to the Health Insurance Portability and Accountability Act of 1996 and its implementing regulations ("HIPAA"). Business Associate provides a documentation readiness platform (the "Service"), described in the Pilot Letter of Intent between the Parties (the "LOI") and its Exhibit A. In connection with the Service, Business Associate may receive, create, maintain, or transmit data on behalf of Covered Entity that may constitute Protected Health Information ("PHI") as defined under HIPAA. The Parties enter into this Agreement to satisfy the Business Associate Agreement requirements of 45 C.F.R. Part 164, Subpart C.
|
|
|
|
---
|
|
|
|
## 1. Definitions
|
|
|
|
Terms used in this Agreement have the meanings assigned under HIPAA and its implementing regulations, including the HITECH Act amendments, as of the Effective Date.
|
|
|
|
**"Protected Health Information" or "PHI"** means individually identifiable health information created, received, maintained, or transmitted by Business Associate on behalf of Covered Entity, in any form or medium.
|
|
|
|
**"Minimum Necessary"** means the least amount of PHI required to accomplish the intended purpose of a given use, disclosure, or request.
|
|
|
|
**"Security Incident"** means the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations in an information system.
|
|
|
|
---
|
|
|
|
## 2. Obligations of Business Associate
|
|
|
|
### 2.1 Permitted Uses and Disclosures
|
|
|
|
Business Associate may use or disclose PHI only:
|
|
|
|
(a) To perform the Service described in the LOI and its Exhibit A, specifically: receiving order-management data uploaded by Covered Entity limited to the minimum-necessary fields specified in the LOI, calculating documentation readiness status per record, and returning a prioritized worklist to Covered Entity staff;
|
|
|
|
(b) As required by law; or
|
|
|
|
(c) For the proper management and administration of Business Associate's own operations, provided that any such disclosure is required by law or Business Associate obtains reasonable assurances that the information will be held in confidence and used or further disclosed only as required by law or for the purpose for which it was disclosed.
|
|
|
|
Business Associate will not use or disclose PHI in any manner that would violate HIPAA if done by Covered Entity directly.
|
|
|
|
### 2.2 Minimum Necessary
|
|
|
|
Business Associate will make reasonable efforts to use, disclose, and request only the minimum necessary PHI to accomplish the intended purpose.
|
|
|
|
### 2.3 Safeguards
|
|
|
|
Business Associate will implement and maintain appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of PHI it creates, receives, maintains, or transmits on behalf of Covered Entity, in accordance with 45 C.F.R. Part 164, Subpart C (Security Rule).
|
|
|
|
Business Associate's safeguards include:
|
|
|
|
- HTTPS enforced on all data transmission surfaces
|
|
- SHA-256 hashing of patient_id before storage in any log or database record
|
|
- Row Level Security restricting data access by organization
|
|
- JWT authentication required on all API endpoints
|
|
- No storage of patient names, dates of birth, Social Security numbers, addresses, or contact information at any time
|
|
- The patient identity crosswalk (supplier's internal patient_id to real patient identity) is maintained solely by Covered Entity staff and is never transmitted to or stored by Business Associate
|
|
|
|
*Attorney note: this safeguards list reflects the current pilot architecture. When the Service migrates to a BAA-capable host for real PHI (see Status and posture), this list is updated to reflect the production environment, including encryption at rest.*
|
|
|
|
### 2.4 Reporting
|
|
|
|
Business Associate will report to Covered Entity, without unreasonable delay and in no event later than 30 calendar days of discovery:
|
|
|
|
(a) Any use or disclosure of PHI not permitted by this Agreement of which Business Associate becomes aware;
|
|
|
|
(b) Any Security Incident of which Business Associate becomes aware, including breaches of Unsecured PHI as required by 45 C.F.R. Part 164, Subpart D;
|
|
|
|
(c) Any attempted but unsuccessful Security Incident of which Business Associate becomes aware, to the extent practicable.
|
|
|
|
Reports will be made to Covered Entity's designated contact in writing.
|
|
|
|
### 2.5 Subcontractors
|
|
|
|
Business Associate will ensure that any subcontractor or agent to which it provides PHI on behalf of Covered Entity agrees in writing to the same restrictions, conditions, and requirements that apply to Business Associate under this Agreement, before any PHI is provided to that subcontractor.
|
|
|
|
Business Associate's current subprocessors are:
|
|
|
|
| Subprocessor | Purpose | Data Touched |
|
|
|---|---|---|
|
|
| Supabase | PostgreSQL database hosting | Hashed patient_id, device_type, shipment_date, payer, doc status fields |
|
|
| Railway | Backend API hosting | Processes upload requests in transit; does not persist PHI |
|
|
| Vercel | Frontend hosting | No PHI; serves static application only |
|
|
| Clerk | Staff authentication | No PHI; stores staff identity only |
|
|
|
|
*Attorney note: none of the subprocessors listed above currently has an executed subprocessor BAA. Real PHI is blocked today (see Status and posture). Before any real PHI is processed, Business Associate will either (a) obtain an executed BAA from each subprocessor that will touch PHI, or (b) migrate the PHI-touching functions to a BAA-capable environment (an AWS BAA is signed and active as of 2026-05-27; AWS RDS and S3 are provisioned and parked). This table is updated to reflect the production chain at that point.*
|
|
|
|
Business Associate will notify Covered Entity of any material change to subprocessors that will touch PHI, and will obtain Covered Entity's written approval before adding any new subprocessor that will receive or process PHI.
|
|
|
|
### 2.6 Access to PHI
|
|
|
|
To the extent Business Associate maintains PHI in a Designated Record Set, Business Associate will make such PHI available to Covered Entity as necessary to fulfill Covered Entity's obligations under 45 C.F.R. Section 164.524 within 15 business days of a written request.
|
|
|
|
### 2.7 Amendment
|
|
|
|
To the extent Business Associate maintains PHI in a Designated Record Set, Business Associate will make such PHI available for amendment and will incorporate any amendments requested by Covered Entity as required by 45 C.F.R. Section 164.526.
|
|
|
|
### 2.8 Accounting of Disclosures
|
|
|
|
Business Associate will maintain a record of disclosures of PHI and will make such information available to Covered Entity as necessary to respond to a request for an accounting of disclosures under 45 C.F.R. Section 164.528.
|
|
|
|
### 2.9 Government Access
|
|
|
|
Business Associate will make its internal practices, books, and records relating to the use and disclosure of PHI available to the Secretary of the U.S. Department of Health and Human Services for purposes of determining compliance with HIPAA.
|
|
|
|
---
|
|
|
|
## 3. Obligations of Covered Entity
|
|
|
|
Covered Entity agrees to:
|
|
|
|
(a) Notify Business Associate of any limitation in Covered Entity's Notice of Privacy Practices that would affect Business Associate's permitted uses or disclosures;
|
|
|
|
(b) Notify Business Associate of any changes in, or revocations of, authorization by individuals that would affect Business Associate's permitted uses or disclosures;
|
|
|
|
(c) Not request Business Associate to use or disclose PHI in any manner that would not be permissible under HIPAA if done by Covered Entity directly;
|
|
|
|
(d) Ensure that any data uploaded to the Service is limited to the minimum-necessary fields specified in the LOI: an internal patient identifier (patient_id), device type, shipment date, quantity, and payer name, plus any optional documentation-status fields the Parties agree to. Covered Entity will not upload patient names, Social Security numbers, dates of birth, addresses, or direct contact information to the Service at any time.
|
|
|
|
---
|
|
|
|
## 4. Term and Termination
|
|
|
|
### 4.1 Term
|
|
|
|
This Agreement is effective as of the Effective Date and continues until the later of: (a) the termination of the LOI or any subsequent formal agreement between the Parties; or (b) the date on which Business Associate has completed its data return and destruction obligations under Section 4.3.
|
|
|
|
### 4.2 Termination for Cause
|
|
|
|
Either Party may terminate this Agreement immediately upon written notice to the other Party if the other Party has materially breached a provision of this Agreement and has not cured the breach within 10 business days of written notice identifying the breach.
|
|
|
|
### 4.3 Return or Destruction of PHI
|
|
|
|
Upon termination of this Agreement for any reason:
|
|
|
|
(a) Business Associate will return to Covered Entity or destroy all PHI received from or created on behalf of Covered Entity, including PHI in the possession of subcontractors, within 10 business days of the effective termination date;
|
|
|
|
(b) Business Associate will certify in writing to Covered Entity that all such PHI has been returned or destroyed;
|
|
|
|
(c) If return or destruction is not feasible, Business Associate will extend the protections of this Agreement to such PHI and limit further use or disclosure to the purposes that make return or destruction infeasible, for as long as Business Associate maintains the PHI.
|
|
|
|
---
|
|
|
|
## 5. Miscellaneous
|
|
|
|
### 5.1 Regulatory References
|
|
|
|
Any reference in this Agreement to a section of HIPAA includes the most recent amendment or regulatory guidance applicable to that section.
|
|
|
|
### 5.2 Interpretation
|
|
|
|
This Agreement is intended to comply with HIPAA as amended. Where this Agreement conflicts with HIPAA, HIPAA controls. Where this Agreement is silent, HIPAA controls.
|
|
|
|
### 5.3 No Third-Party Beneficiaries
|
|
|
|
Nothing in this Agreement confers any right, remedy, or claim upon any third party, including any patient whose PHI is involved.
|
|
|
|
### 5.4 Governing Law
|
|
|
|
This Agreement is governed by the laws of the State of [STATE, confirm formation state with counsel], without regard to conflict of law principles.
|
|
|
|
### 5.5 Entire Agreement
|
|
|
|
This Agreement, together with the LOI and the mutual NDA between the Parties, constitutes the entire agreement with respect to PHI and supersedes all prior understandings on the subject.
|
|
|
|
---
|
|
|
|
## Signatures
|
|
|
|
**KJF Professional Services LLC d/b/a STTIL Solutions (Business Associate)**
|
|
By: ___________________________
|
|
Name: Kisa Fenn
|
|
Title: Managing Member
|
|
Date: _________________________
|
|
Email: [KISA EMAIL]
|
|
|
|
**[COVERED ENTITY FULL LEGAL NAME] (Covered Entity)**
|
|
By: ___________________________
|
|
Name: [SIGNER NAME]
|
|
Title: [SIGNER TITLE]
|
|
Date: _________________________
|
|
Email: ___________________________
|
|
|
|
---
|
|
|
|
## Attorney Review Notes
|
|
|
|
Each load-bearing factual claim is labeled GROUNDED (cited source) or GRAFTED (assumption for counsel to confirm). Items to confirm before this Agreement is executed with any Covered Entity:
|
|
|
|
1. **LOAD-BEARING: Is a BAA required at all? (GRAFTED as applied.)** Confirm whether Business Associate's receipt of Covered Entity's internal patient_id (a supplier account number, one of HIPAA's 18 identifiers) makes STTIL a Business Associate requiring this Agreement, or whether the Service's de-identification architecture (no names, no DOBs, no SSNs; the crosswalk stays with Covered Entity) satisfies the Safe Harbor or Expert Determination de-identification standards such that no BAA is triggered. GROUNDED that patient_id is an account number and the sole crosswalk key, and that names/DOBs/SSNs are refused at the normalizer (Signal CLAUDE.md, PHI Architecture; data-handling.md). Whether that architecture avoids Business Associate status is GRAFTED and is the single most important question in this bundle.
|
|
|
|
2. **Subprocessor agreements (GROUNDED posture, GRAFTED requirement).** GROUNDED that the current pilot stack (Supabase, Railway, Vercel, Clerk) has no executed subprocessor BAAs and that an AWS BAA is signed and active as of 2026-05-27 (Signal current-state.md; KG Signal). Confirm which of the subprocessors, in the production PHI configuration, legally requires its own BAA, and confirm the AWS migration path satisfies the subcontractor obligation in 45 C.F.R. 164.308(b) and 164.314.
|
|
|
|
3. **Accounting of disclosures scope (GRAFTED as applied).** Confirm the scope of Section 2.8 as applied to a software service that processes de-identified or minimum-necessary data only.
|
|
|
|
4. **State-specific requirements (GRAFTED).** Confirm which state's health-data statutes (beyond HIPAA) apply once formation state and Covered Entity location are known. A prior supplier-specific version governed under Pennsylvania; this template uses a placeholder. Confirm no additional state-law obligations attach.
|
|
|
|
5. **Governing law and entity alignment (GROUNDED that documents disagree).** The v1 LOI and NDA said Delaware; the a prior supplier BAA said Pennsylvania; an executed letter of intent states Florida. Entity name is now "KJF Professional Services LLC d/b/a STTIL Solutions." Confirm the correct legal name and formation state and align Section 5.4 with the LOI and NDA.
|
|
|
|
6. **Forward-looking status (GROUNDED).** Real PHI is blocked/mock today (Signal current-state.md, 2026-07-07). Confirm this template is the correct instrument to execute at the point real PHI enters the system, and advise whether any interim data-handling addendum is needed for a pilot that stays inside the de-identified minimum-necessary field set before that point.
|
|
|
|
---
|
|
*Document prepared for attorney review. Not legal advice.*
|
|
*Related: STTIL-pilot-LOI-template-v3, STTIL-NDA-template-v3*
|