Zum Inhalt

HIPAA Readiness Gap Analysis — EPPA

EPPA is not currently HIPAA-ready

EPPA does not yet operate as a Business Associate or Covered Entity in any US deployment. This gap analysis maps the HIPAA Privacy Rule, Security Rule and Breach Notification Rule requirements to the current EPPA implementation state. Most requirements are marked not implemented. EPPA must not process identifiable PHI of US patients until a BAA is executed and the Security Rule safeguards listed below are in place.

1. Document identity

Field Value
Document title HIPAA Readiness Gap Analysis — EPPA
Document ID EPPA-HIPAA-001
Version 0.1 (draft)
Status Draft — not approved
Effective date n/a
Owner LABIS UCA — US Privacy lead (to be appointed)
Linked documents 00-overview.md, 30-gdpr-dpia.md, 50-secdev-checklist.md

2. Regulatory anchors

  • HIPAA Privacy Rule — 45 CFR Part 160 (general administrative requirements) and 45 CFR Part 164 Subparts A and E (privacy of individually identifiable health information).
  • HIPAA Security Rule — 45 CFR Part 164 Subpart C (security standards for electronic PHI).
  • HIPAA Breach Notification Rule — 45 CFR Part 164 Subpart D.
  • HITECH Act (2009) — strengthened enforcement; extended HIPAA obligations to business associates.
  • Omnibus Rule (2013) — final modifications to HIPAA implementing HITECH.

3. EPPA's role under HIPAA

In a US deployment, EPPA would most plausibly act as a Business Associate (BA) of a Covered Entity (CE), where:

  • The Covered Entity is the treating clinic (a "health care provider" per §160.103) or the research institution conducting clinical research.
  • EPPA / LABIS UCA processes PHI on behalf of the CE in the course of providing the postural-assessment software service.

A Business Associate Agreement (BAA) is required by §164.502(e) and §164.504(e) before any PHI may be shared with EPPA.

EPPA itself is not a Covered Entity (it is neither a health plan, a health care clearinghouse, nor a health care provider that transmits health information in electronic form in connection with a transaction covered by HIPAA — §160.103).

4. Administrative safeguards (§164.308) — gap table

Standard Implementation specification Required / Addressable EPPA status
§164.308(a)(1)(i) Security Management Process — Required Not implemented
§164.308(a)(1)(ii)(A) Risk Analysis — Required Not implemented (DPIA in 30-gdpr-dpia.md is GDPR scope, not HIPAA scope)
§164.308(a)(1)(ii)(B) Risk Management — Required Not implemented
§164.308(a)(1)(ii)(C) Sanction Policy — Required Not implemented
§164.308(a)(1)(ii)(D) Information System Activity Review — Required Not implemented — audit log planned in Epic E3
§164.308(a)(2) Assigned Security Responsibility — Required Not implemented — no Security Officer designated
§164.308(a)(3)(i) Workforce Security — Required Not implemented
§164.308(a)(3)(ii)(A) Authorization and/or Supervision — Addressable Not implemented
§164.308(a)(3)(ii)(B) Workforce Clearance Procedure — Addressable Not implemented
§164.308(a)(3)(ii)(C) Termination Procedures — Addressable Not implemented
§164.308(a)(4)(i) Information Access Management — Required Not implemented — RBAC planned in Epic E3
§164.308(a)(4)(ii)(B) Access Authorization — Addressable Not implemented
§164.308(a)(4)(ii)(C) Access Establishment and Modification — Addressable Not implemented
§164.308(a)(5)(i) Security Awareness and Training — Required Not implemented
§164.308(a)(5)(ii)(A) Security Reminders — Addressable Not implemented
§164.308(a)(5)(ii)(B) Protection from Malicious Software — Addressable Not implemented
§164.308(a)(5)(ii)(C) Log-in Monitoring — Addressable Not implemented
§164.308(a)(5)(ii)(D) Password Management — Addressable Partial — Argon2id hashing implemented (see 50-secdev-checklist.md)
§164.308(a)(6)(i) Security Incident Procedures — Required Not implemented
§164.308(a)(6)(ii) Response and Reporting — Required Not implemented
§164.308(a)(7)(i) Contingency Plan — Required Not implemented
§164.308(a)(7)(ii)(A) Data Backup Plan — Required Not implemented
§164.308(a)(7)(ii)(B) Disaster Recovery Plan — Required Not implemented
§164.308(a)(7)(ii)(C) Emergency Mode Operation Plan — Required Not implemented
§164.308(a)(7)(ii)(D) Testing and Revision Procedures — Addressable Not implemented
§164.308(a)(7)(ii)(E) Applications and Data Criticality Analysis — Addressable Not implemented
§164.308(a)(8) Evaluation — Required Not implemented
§164.308(b)(1) Business Associate Contracts — Required Not implemented — no US deployments yet

5. Physical safeguards (§164.310) — gap table

Standard Implementation specification EPPA status
§164.310(a)(1) Facility Access Controls — Not implemented — depends on hosting provider
§164.310(a)(2)(i) Contingency Operations Addressable Not implemented
§164.310(a)(2)(ii) Facility Security Plan Addressable Not implemented
§164.310(a)(2)(iii) Access Control and Validation Addressable Not implemented
§164.310(a)(2)(iv) Maintenance Records Addressable Not implemented
§164.310(b) Workstation Use Required Not implemented — clinic-controlled
§164.310(c) Workstation Security Required Not implemented — clinic-controlled (full-disk encryption is a recommended control)
§164.310(d)(1) Device and Media Controls Required Not implemented
§164.310(d)(2)(i) Disposal Required Not implemented
§164.310(d)(2)(ii) Media Re-use Required Not implemented
§164.310(d)(2)(iii) Accountability Addressable Not implemented
§164.310(d)(2)(iv) Data Backup and Storage Addressable Not implemented

In a cloud-hosted deployment, the physical safeguards are inherited from the hosting provider's HIPAA-eligible service (e.g. AWS HIPAA-eligible services, Cloudflare's HIPAA capability — BAA-bound).

6. Technical safeguards (§164.312) — gap table

Standard Implementation specification EPPA status
§164.312(a)(1) Access Control Required Partial — Argon2id password hashing implemented; RBAC planned in Epic E3
§164.312(a)(2)(i) Unique User Identification Required Planned — Epic E3 user model
§164.312(a)(2)(ii) Emergency Access Procedure Required Not implemented
§164.312(a)(2)(iii) Automatic Logoff Addressable Not implemented — idle timeout planned
§164.312(a)(2)(iv) Encryption and Decryption Addressable Partial — TLS in transit; pgcrypto at rest planned (Epic E3)
§164.312(b) Audit Controls Required Planned — AuditLog model in Epic E3
§164.312(c)(1) Integrity Required Not implemented — image hash at upload planned
§164.312(c)(2) Mechanism to Authenticate ePHI Addressable Not implemented
§164.312(d) Person or Entity Authentication Required Planned — Epic E3 auth
§164.312(e)(1) Transmission Security Required Partial — TLS 1.3; HSTS planned
§164.312(e)(2)(i) Integrity Controls Addressable Not implemented
§164.312(e)(2)(ii) Encryption Addressable Partial — TLS 1.3

7. Business Associate Agreement (BAA) boilerplate

Required content per §164.504(e)(2). The boilerplate below is a starting point; all BAA execution requires legal review.

BUSINESS ASSOCIATE AGREEMENT

This Business Associate Agreement ("Agreement") is entered into by
[Covered Entity], a HIPAA Covered Entity ("CE"), and LABIS UCA / EPPA
("Business Associate" or "BA"), effective as of the date last signed below.

1. Definitions. Terms used but not defined herein shall have the meanings
   set forth at 45 CFR §§ 160.103 and 164.501.

2. Obligations of Business Associate. Business Associate agrees to:

   (a) Not use or disclose PHI other than as permitted by this Agreement or
       as required by law (§164.504(e)(2)(ii)(A)).

   (b) Use appropriate safeguards, and comply with Subpart C of 45 CFR
       Part 164 with respect to electronic protected health information
       (§164.504(e)(2)(ii)(B)).

   (c) Report to CE any use or disclosure of PHI not permitted by this
       Agreement (§164.504(e)(2)(ii)(C)), including breaches of unsecured
       PHI as required at §164.410, without unreasonable delay and in no
       case later than [10 / 15 / 30 — to be negotiated] calendar days
       after discovery.

   (d) In accordance with §164.502(e)(1)(ii) and §164.308(b)(2), if
       applicable, ensure that any subcontractors that create, receive,
       maintain or transmit PHI on behalf of BA agree to the same
       restrictions, conditions and requirements that apply to BA with
       respect to such information (§164.504(e)(2)(ii)(D)).

   (e) Make available PHI in a designated record set to CE as necessary to
       satisfy CE's obligations under §164.524 (access)
       (§164.504(e)(2)(ii)(E)).

   (f) Make any amendment to PHI in a designated record set as directed
       or agreed to by CE pursuant to §164.526 (amendment), or take other
       measures as necessary to satisfy CE's obligations under §164.526
       (§164.504(e)(2)(ii)(F)).

   (g) Maintain and make available the information required to provide an
       accounting of disclosures to CE as necessary to satisfy CE's
       obligations under §164.528 (accounting of disclosures)
       (§164.504(e)(2)(ii)(G)).

   (h) To the extent that BA carries out CE's obligation(s) under Subpart
       E of 45 CFR Part 164, comply with the requirements of Subpart E that
       apply to CE in the performance of such obligation(s)
       (§164.504(e)(2)(ii)(H)).

   (i) Make its internal practices, books and records relating to the use
       and disclosure of PHI received from, or created or received by BA on
       behalf of, CE available to the Secretary of Health and Human Services
       for purposes of determining CE's compliance with HIPAA
       (§164.504(e)(2)(ii)(I)).

3. Permitted Uses and Disclosures by Business Associate. BA may use or
   disclose PHI only to perform the postural-assessment services and as
   permitted or required by this Agreement.

4. Term and Termination. (a) Term: this Agreement shall be effective until
   terminated. (b) Termination for Cause: upon CE's knowledge of a material
   breach by BA, CE shall provide an opportunity for BA to cure or, if cure
   is not possible, terminate. (c) Effect of Termination: BA shall return
   or destroy all PHI received from, or created or received by BA on behalf
   of, CE, or, if return or destruction is not feasible, extend the
   protections of this Agreement to such PHI.

5. Miscellaneous. Regulatory References; Amendment; Survival; Interpretation.
   This Agreement is governed by HIPAA and the law of [State].

[Signature blocks for CE and BA]

8. Breach notification (§164.404 to §164.414)

A breach is an impermissible use or disclosure of PHI that compromises the security or privacy of the PHI (§164.402). A "low probability of compromise" exception applies if a four-factor risk assessment supports it (§164.402(2)).

8.1 Notification obligations

Recipient Timeline Reference
Affected individuals Without unreasonable delay and in no case later than 60 calendar days after discovery §164.404(b)
HHS Secretary — for breaches affecting < 500 individuals Annual log, no later than 60 days after the end of the calendar year in which the breach was discovered §164.408(c)
HHS Secretary — for breaches affecting ≥ 500 individuals Without unreasonable delay and in no case later than 60 calendar days §164.408(b)
Prominent media outlets — for breaches affecting ≥ 500 residents of a state or jurisdiction Without unreasonable delay and in no case later than 60 calendar days §164.406
Covered Entity (by Business Associate) Without unreasonable delay and per BAA (typically ≤ 30 calendar days) §164.410

8.2 Notification content (§164.404(c))

  • Brief description of what happened.
  • Description of types of unsecured PHI involved.
  • Steps individuals should take to protect themselves.
  • Brief description of what the CE is doing to investigate, mitigate and protect against further breaches.
  • Contact procedures.

9. 18 PHI identifiers — Safe Harbor de-identification (§164.514(b)(2))

For Safe Harbor de-identification, all of the following identifiers of the individual or of relatives, employers or household members of the individual must be removed:

  1. Names.
  2. All geographic subdivisions smaller than a state, including street address, city, county, precinct, ZIP code and equivalent geocodes, except the first three digits of a ZIP code if certain conditions are met.
  3. All elements of dates (except year) directly related to an individual (birth date, admission date, discharge date, date of death); all ages over 89 and all elements of dates indicative of such age (subject to aggregation rules).
  4. Telephone numbers.
  5. Fax numbers.
  6. Email addresses.
  7. Social security numbers.
  8. Medical record numbers.
  9. Health plan beneficiary numbers.
  10. Account numbers.
  11. Certificate / licence numbers.
  12. Vehicle identifiers and serial numbers, including licence plate numbers.
  13. Device identifiers and serial numbers.
  14. Web URLs.
  15. IP addresses.
  16. Biometric identifiers, including finger and voice prints.
  17. Full-face photographs and any comparable images — load-bearing for EPPA.
  18. Any other unique identifying number, characteristic or code, except as permitted by §164.514(c).

9.1 Impact on EPPA

Item 17 is dispositive for EPPA: EPPA captures and processes full-face photographs (in the anterior and lateral views, faces are visible). EPPA-processed images therefore cannot be Safe-Harbor de-identified in their raw form.

Options:

  • Face blur preprocessing before any image leaves the controller's perimeter — this addresses R1 in the GDPR risk register (30-gdpr-dpia.md §4) and is mandatory for any HIPAA Safe Harbor de-identification.
  • Expert Determination pathway (§164.514(b)(1)) — a qualified statistician certifies that the risk of re-identification is "very small". This is cumbersome for image data.
  • Limited Data Set + Data Use Agreement (§164.514(e)) — a less stringent de-identification standard, but full-face photographs are not permitted in a Limited Data Set either.

The practical conclusion: any non-research disclosure of EPPA images requires face-blur or written authorisation under §164.508.

10. Roadmap to HIPAA readiness

Phase Deliverables Owner
Phase A Designate Security Officer; complete §164.308(a)(1)(ii)(A) risk analysis US Privacy lead
Phase B Implement RBAC + MFA + audit log (Epic E3) Software lead
Phase C Encrypt PHI at rest with pgcrypto; KMS-rotated keys Software lead
Phase D Backup / DR plan with tested restore; sanction policy; workforce training Operations
Phase E Execute BAA template with legal; engage HIPAA-eligible hosting Legal + Operations
Phase F First US deployment under BAA, with limited rollout and post-implementation Privacy Rule audit Operations + Privacy

11. Open questions

  1. Confirm CE vs BA scoping per deployment. In a research-institute deployment, the institute is typically the CE; in a direct-to-clinic deployment, the clinic is the CE.
  2. Confirm hosting provider. Cloudflare, AWS, GCP and Azure offer HIPAA-eligible services under BAA; choose one before any US PHI handling.
  3. Confirm scope of audit log. §164.312(b) requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI" — define what events are logged and the retention.
  4. Confirm de-identification policy for research datasets. Safe Harbor vs Expert Determination, in light of the face-photograph constraint.

References