Testland
Browse all skills & agents

hipaa-test-patterns

Reference catalog of HIPAA Security Rule-aligned test patterns - administrative safeguards (45 CFR §164.308: workforce training, access management, contingency planning), physical safeguards (§164.310: facility access, workstation security, device disposal), technical safeguards (§164.312: access control, audit logs, integrity, transmission security); PHI handling assertions in fixtures; minimum-necessary tests per §164.502(b); BAA-scope boundary verification. Use when authoring HIPAA-readiness tests for any product handling Protected Health Information.

Install with skills.sh (any agent)

npx skills add testland/qa --skill hipaa-test-patterns
View source

hipaa-test-patterns

Reference catalog of test patterns by HIPAA Security Rule section (45 CFR §164). Pair with audit-trail-test-author for §164.312(b) audit-log requirements. Anchors: hhs.gov/hipaa (opens in new window) and NIST SP 800-66.

When to use

  • Product is a Business Associate handling PHI for a Covered Entity (or is itself a Covered Entity).
  • BAA (Business Associate Agreement) signed; need test evidence.
  • HIPAA risk assessment requires test coverage evidence.
  • New feature touches PHI (medical records, billing, scheduling, clinical decision support).

What is PHI?

Per HHS, PHI = individually identifiable health information + created/received/maintained/transmitted by a covered entity. The 18 HIPAA identifiers per §164.514(b)(2) (Safe Harbor):

1. Name
2. Geographic subdivisions smaller than state (ZIP codes need restrictions)
3. All elements of dates (except year) for dates directly related to an individual
4. Telephone numbers
5. Vehicle identifiers + license plates
6. Fax numbers
7. Device identifiers + serial numbers
8. Email addresses
9. Web URLs
10. SSN
11. IP addresses
12. Medical record numbers
13. Biometric identifiers (fingerprints, voiceprints)
14. Health plan beneficiary numbers
15. Full-face photos + comparable images
16. Account numbers
17. Any other unique identifying number / characteristic / code
18. Certificate / license numbers

Test fixtures for HIPAA-scope systems MUST avoid these 18 identifiers (or use synthetic-pii-generator in the qa-test-data plugin to generate safe substitutes).

How to use

  1. Confirm your role - Business Associate or Covered Entity - and pull the signed BAA's allowed purposes; they bound every access test.
  2. Scrub fixtures of all 18 Safe Harbor identifiers (above); generate substitutes with synthetic-pii-generator.
  3. Pick the Security Rule sections the feature touches (access control, audit, integrity, transmission, minimum-necessary, disposal, BAA scope).
  4. Copy the matching pattern from references/security-rule-test-patterns.md and point it at your framework's client + models.
  5. For every PHI read or write, assert an audit record with a tamper-evident hash per §164.312(b); pair with audit-trail-test-author.
  6. Assert minimum-necessary per role (§164.502(b)) - a positive access check AND negative checks for out-of-role PHI types.
  7. Run in CI; the pass/fail history is itself risk-assessment evidence.

Test patterns by Security Rule section

Full per-section patterns live in references/security-rule-test-patterns.md, covering administrative safeguards (§164.308 workforce access management, workforce training), physical safeguards (§164.310 device + media disposal), technical safeguards (§164.312 access control, audit controls, integrity, transmission security), the §164.502(b) minimum-necessary standard, and §164.504(e) BAA-scope boundaries. Each entry is a copy-ready pytest-style test keyed to its CFR section.

Worked example

A billing clerk's role is added to the scheduling service. The team runs the §164.502(b) minimum-necessary pattern against /patient/123/billing-summary with the billing-clerk token. The response asserts amount_due and insurance_provider are present and that clinical_notes, medications, and genetic_test_results are absent. The negative assertion fails: the summary serializer eager-loads the full patient record, leaking medications. The team narrows the serializer to billing fields, re-runs, and the test passes, proving the role sees only the minimum-necessary PHI, with the read logged via the §164.312(b) audit pattern.

Anti-patterns

Anti-patternWhy it failsFix
Real PHI in test fixturesHIPAA violation in testssynthetic-pii-generator + de-identified data
Audit log without tamper-evidenceLogs can be modified post-incidentHash-chain or signed-batch log integrity (§164.312(b))
Role-based access without minimum-necessary checkOver-broad access; minimum-necessary violationPer-PHI-type test (Step §164.502(b))
Skip BAA scope testsVendor accesses PHI outside agreementStep §164.504(e) scope test
Allow plaintext HTTP for PHI even in devProduction drift; eventual leakAlways enforce HTTPS (Step §164.312(e))

Limitations

  • This skill targets HIPAA Security Rule. HIPAA Privacy Rule (45 CFR §164 Subpart E) has additional requirements (use/disclosure rules, accounting of disclosures); test patterns there are use-case specific.
  • HITECH Act (2009) added breach-notification + enforcement; tests intersect with §164.404 - §164.414.
  • State laws (e.g., California CMIA) may add additional requirements beyond HIPAA.
  • This skill doesn't replace a HIPAA risk analysis or compliance consultant.

References

  • hipaa-hhs (opens in new window) - HHS HIPAA reference
  • ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164 - HIPAA regulations text (45 CFR §164)
  • nist.gov/publications/sp-800-66-revision-1-introductory-resource-guide-implementing-hipaa-security - NIST SP 800-66 implementation guidance
  • nist.gov/publications/sp-800-88-revision-1-guidelines-media-sanitization - NIST SP 800-88 device sanitization
  • gdpr-test-patterns, ccpa-test-patterns - sister privacy-pattern catalogs
  • audit-trail-test-author - §164.312(b) audit log requirements
  • synthetic-pii-generator - cross-plugin: safe PHI fixture generation

HIPAA Security Rule test patterns

View source (opens in new window)

HIPAA Security Rule test patterns

Test patterns by HIPAA Security Rule section (45 CFR §164). Pair §164.312(b) audit-log patterns with audit-trail-test-author. Fixtures must avoid the 18 Safe Harbor identifiers; use synthetic-pii-generator.

§164.308(a)(3) - Workforce access management

def test_user_role_grants_only_minimum_necessary_phi():
    """§164.502(b) minimum necessary standard."""
    user = User.objects.create(role='billing-clerk')
    # Billing clerks access financial PHI but NOT clinical notes
    assert user.can_access(PhiType.BILLING)
    assert not user.can_access(PhiType.CLINICAL_NOTES)
    assert not user.can_access(PhiType.GENETIC_TEST_RESULTS)

§164.308(a)(5) - Workforce training

Test that training-completion is enforced before access grant:

def test_user_cannot_access_phi_without_training_completion():
    user = User.objects.create(role='nurse', hipaa_training_completed=False)
    response = client.get('/patient/123/records', headers={'Authorization': f'Bearer {user.token}'})
    assert response.status_code == 403
    assert 'training_required' in response.json()['error']

§164.310(d)(2) - Device + media disposal

def test_phi_overwritten_when_device_decommissioned():
    device = Device.objects.create(serial='ABC123', has_phi=True)
    decommission(device)
    # Device record marked as wiped + audit log entry
    device.refresh_from_db()
    assert device.status == 'wiped'
    assert device.wipe_method in ['NIST 800-88 Clear', 'NIST 800-88 Purge']
    assert AuditLog.objects.filter(action='device_wipe', subject=device.serial).exists()

§164.312(a)(1) - Access control

def test_phi_access_requires_unique_user_id():
    """§164.312(a)(2)(i) Unique User Identification - no shared accounts."""
    # System must reject login attempts on generic / shared accounts:
    response = client.post('/login', json={'username': 'admin', 'password': 'secret'})
    assert response.status_code == 403  # generic 'admin' account forbidden

§164.312(b) - Audit controls

Cross-ref audit-trail-test-author:

def test_phi_access_creates_audit_record():
    """§164.312(b): record + examine activity in info systems containing PHI."""
    user = User.objects.create(role='nurse')
    client.get(f'/patient/{patient.id}/records', headers={'Authorization': f'Bearer {user.token}'})

    audit = AuditLog.objects.filter(
        actor=user.id,
        action='phi_access',
        subject=f'patient:{patient.id}',
    ).first()
    assert audit is not None
    assert audit.timestamp is not None
    assert audit.tamper_evident_hash is not None   # required for integrity

§164.312(c)(1) - Integrity

def test_phi_modification_requires_authentication_and_audit():
    """§164.312(c)(1): protect ePHI from improper alteration / destruction."""
    user_unauth = User.objects.create(role='intake-staff')
    response = client.put(
        f'/patient/{patient.id}/records',
        json={'diagnosis': 'modified'},
        headers={'Authorization': f'Bearer {user_unauth.token}'},
    )
    assert response.status_code == 403  # intake staff cannot modify clinical
    # Even authorized modification is logged:
    user_doc = User.objects.create(role='physician')
    response = client.put(
        f'/patient/{patient.id}/records',
        json={'diagnosis': 'updated'},
        headers={'Authorization': f'Bearer {user_doc.token}'},
    )
    audit = AuditLog.objects.filter(
        action='phi_modify',
        subject=f'patient:{patient.id}',
        actor=user_doc.id,
    ).first()
    assert audit.before_value == 'original'
    assert audit.after_value == 'updated'

§164.312(e)(1) - Transmission security

def test_phi_transmitted_only_via_encrypted_channels():
    """§164.312(e)(2)(ii): encryption in transit for PHI."""
    # Plaintext HTTP must redirect or refuse:
    response = http_client.get('http://api.example.com/patient/123')
    assert response.status_code in [301, 308, 403]
    # HTTPS must use TLS 1.2+ + secure ciphers:
    tls_info = inspect_tls('https://api.example.com')
    assert tls_info.protocol >= 'TLSv1.2'
    assert tls_info.cipher in ALLOWED_CIPHERS

§164.502(b) - Minimum necessary standard

def test_query_returns_only_minimum_necessary_fields():
    response = client.get(
        '/patient/123/billing-summary',
        headers={'Authorization': f'Bearer {billing_clerk_token}'},
    )
    body = response.json()
    # Billing summary should NOT include clinical notes or sensitive fields:
    assert 'amount_due' in body
    assert 'insurance_provider' in body
    assert 'clinical_notes' not in body
    assert 'medications' not in body
    assert 'genetic_test_results' not in body

§164.504(e) - Business Associate Agreement scope

def test_phi_only_processed_for_baa_purposes():
    # Test fixture: BAA scope = appointment-scheduling only
    baa = BusinessAssociateAgreement.objects.get(partner='SchedulingVendor')
    assert baa.allowed_purposes == ['appointment_scheduling']

    # Vendor SHOULD NOT be able to access PHI for non-scheduling purposes:
    vendor_user = User.objects.create(employer='SchedulingVendor')
    response = client.get(
        '/patient/123/billing',
        headers={'Authorization': f'Bearer {vendor_user.token}'},
    )
    assert response.status_code == 403

Related skills

audit-trail-test-author

Build-an-X for audit-log tests across compliance frameworks - required-events catalog (auth events / privilege change / data access / admin action / config change / export / impersonation); structured-log-format assertions per OWASP A09:2021; tamper-evident chain (hash-chain + signed-batch patterns) for HIPAA §164.312(b) + PCI Req 10 + SOC 2 CC7.3; immutability + retention per framework; query-replay tests for forensic reconstruction. Use when authoring audit log tests for any compliance framework (HIPAA / PCI / SOC 2 / GDPR / etc.).

ccpa-test-patterns

Reference catalog of CCPA + CPRA-aligned test patterns - do-not-sell-or-share opt-out via Global Privacy Control (GPC) signal; data-disclosure category tests per Cal. Civ. Code §1798.110; sensitive personal information (SPI) handling per CPRA §1798.121; deletion-request workflows per §1798.105; CPRA's right to correct (§1798.106) + limit-use (§1798.121). Use when authoring CCPA/CPRA-readiness tests for any product processing California consumer data.

compliance-coverage-scoring

Scores existing tests and evidence against a named compliance framework's criteria list (GDPR, CCPA/CPRA, SOC 2 Trust Services Criteria, HIPAA Security Rule, PCI DSS, ISO/IEC 27001), marking every criterion met, partial, not met, or not applicable with a stated evidence requirement per state, and recording each scope exclusion with its criterion reference, reason, named approver, and re-review date. Produces a readiness self-assessment only: not certification, not an audit opinion, not legal advice. Use when a framework version has been named and an evidence set already exists, and someone needs a per-criterion readiness score before an observation period opens, before a qualified assessor arrives, or in response to a regulator inquiry.

compliance-evidence-generator

Build-an-X workflow that produces auditor-facing evidence packages from automated test results: maps control IDs to test outcomes across any compliance framework (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, FedRAMP); generates the control-evidence matrix, timestamped evidence bundles (screenshots, log excerpts, CI exports), and chain-of-custody notes per NIST SP 800-72. Distinct from soc2-evidence-collector (SOC2-only raw log harvest) and from read-only coverage gap analysis that produces no artifacts. Use when an audit engagement requires auditor-ready evidence packages built from existing automated test output.

gdpr-test-patterns

Reference catalog of GDPR-aligned test patterns - data-subject-rights workflows (Art. 15 access, Art. 16 rectification, Art. 17 erasure / "right to be forgotten", Art. 18 restriction, Art. 20 portability, Art. 21 objection); consent recording + revocation per Art. 7; data-residency assertions per Art. 44 - 50 international transfers; breach-notification timing tests per Art. 33 (72 hours); data-minimization assertions in fixtures per Art. 5(1)(c). Use when authoring GDPR-readiness tests for any product processing EU personal data.

iso27001-test-patterns

Reference catalog of ISO/IEC 27001:2022 Annex A test patterns: testable technical controls with code-level assertions for access control (A.8.2-A.8.5), logging and monitoring (A.8.15-A.8.16), cryptography (A.8.24), and secure development (A.8.25-A.8.31), plus evidence patterns for Stage 1 and Stage 2 certification audits and Statement of Applicability scoping. The full 93-control Annex A index (four themes: organizational A.5, people A.6, physical A.7, technological A.8) and the exhaustive per-control test code live in references/. Use when authoring ISMS test coverage for an ISO 27001:2022 certification engagement or gap assessment.

pci-dss-control-test-author

Build-an-X for PCI DSS v4.0 scope verification - cardholder data environment (CDE) boundary tests, segmentation tests (PCI Req 1), prohibited-data-storage assertions per Req 3 (no full track data, no CVV/CAV2/CVC2/CID, no PIN/PIN block post-authorization), key-management tests per Req 3.6, encryption-of-transmissions per Req 4. Use when authoring PCI DSS scope-reduction + control tests for any system handling payment-card data.

soc2-evidence-collector

Build-an-X for SOC 2 Type II evidence collection - per-Trust-Services-Criterion test artifacts (Common Criteria CC1.1 - CC9.2; plus Availability A1, Confidentiality C1, Processing Integrity PI1, Privacy P1 - P9 if in scope); auto-collection from CI logs + audit trails + access logs + change-management records; alignment with Vanta / Drata / Secureframe evidence shapes; observation-period sampling. Use when the team is preparing for SOC 2 Type II audit and needs continuous evidence collection automation.