HIPAA + HRSA + FTCA + OSHA at an FQHC: One Compliance Stack, Four Rulebooks

#hipaa #healthcare #compliance #fqhc

FQHCs run on a four-rulebook compliance regime — HIPAA, HRSA OSV, FTCA deeming, OSHA. The mistake we see most often is treating them as four separate compliance functions, with four separate spreadsheets, four separate trainings, four separate evidence-collection workflows, and four separate panic responses when the auditor calls.

They don't have to be. The four rulebooks have substantial overlap in what they want documented, who's responsible, and what evidence proves it. A reasonable engineering goal is one compliance stack with four output views.

This post walks the four rulebooks, the overlap, and what a single-stack architecture looks like in practice.

1. HIPAA 2026

What it requires from an FQHC, in engineering terms:

Annual Security Risk Assessment with documented findings and remediation tracking. The 2026 Security Rule moved the SRA from "do it once a year" to "the spine of the program."
BAA inventory with subcontractor flow-down. Every vendor that touches PHI — including the EHR, the cloud backup, the appointment reminder vendor, the transcription service, the IT MSP — needs a current BAA on file.
Workforce training with role-based content and completion records tied to SRA findings.
Audit trail of access to PHI in the EHR and other PHI systems, queryable by date range.
Breach response runbook with a tested communications path.

The data model: SRA findings, controls, evidence records, BAA records, training completion records, breach incidents.

2. HRSA Operational Site Visit (OSV)

HRSA's OSV looks at the full Section 330 program requirements for FQHCs — governance, financial systems, clinical performance, and management/finance compliance. From a compliance-stack perspective, the HIPAA-adjacent items are:

Governance documentation — board composition, board minutes, board oversight of compliance and quality.
Financial systems — sliding fee schedule administration, billing accuracy, sliding-fee documentation.
Clinical — credentialing and privileging records, quality improvement program, clinical performance metrics.
HIPAA-adjacent items in OSV — confidentiality/privacy policies, workforce training documentation, breach notification procedures, IT security overview.

The overlap with HIPAA: the workforce training records, the BAA inventory, the breach-response runbook, and the asset inventory all feed directly into OSV documentation requests. If your HIPAA evidence is in good shape, the HIPAA-adjacent OSV items are effectively pre-staged.

The non-overlap: OSV's clinical and financial items live outside the HIPAA stack and need their own data sources (EHR clinical reports, billing system reports, board documents).

3. FTCA deeming

FTCA covers FQHCs and their providers for medical malpractice claims as if they were federal employees. To maintain deeming, an FQHC has to demonstrate annually that it has, among other things:

An active risk management program with documented risk assessments and remediation tracking.
Quality improvement and quality assurance processes with documented activities.
Credentialing and privileging of providers per the deeming requirements.
Claims management processes including timely reporting of potential claims.

The HIPAA overlap is at the risk-management documentation layer. Your HIPAA SRA, the remediation tracking, and the documented governance review of compliance findings are all evidence that supports the FTCA risk-management requirement. The same SRA tool that produces HIPAA findings can, with the right evidence model, produce the risk-management documentation FTCA wants.

The non-overlap: credentialing and privileging is a separate workflow, usually owned by clinical operations, and lives outside the compliance stack.

4. OSHA

The OSHA rulebooks that matter at an FQHC:

Bloodborne Pathogens Standard (29 CFR 1910.1030) — exposure control plan, annual training, hepatitis B vaccination offer documentation, sharps injury log, post-exposure follow-up.
Hazard Communication (HazCom) — chemical inventory, SDS access, labeling, training.
Workplace Violence Prevention — under the OSHA healthcare-specific WPV rule, FQHCs need a written WPV prevention program, a hazard assessment, training, and incident logging.
Recordkeeping (300/300A logs) if applicable to size.

The HIPAA overlap: training cadence and recordkeeping. Bloodborne pathogens, HazCom, and WPV training are all annual; HIPAA training is annual; new-hire onboarding triggers all four. If your training platform can handle role-based content for HIPAA, it can handle the OSHA modules too — and the completion records belong in the same audit trail.

The non-overlap: the sharps-injury log, the SDS library, and the WPV incident log are OSHA-specific data that doesn't fit cleanly into a HIPAA SRA tool.

One compliance stack architecture

The four rulebooks have four different auditors, but they keep asking for the same six artifacts:

Single asset inventory — one source of truth for devices, systems, and locations. Feeds HIPAA SRA, HRSA OSV IT review, OSHA hazard assessment.
Single training platform — role-based, with one completion record per person per module. Feeds HIPAA training requirement, HRSA workforce training documentation, OSHA bloodborne / HazCom / WPV training.
Single BAA / vendor repository — every vendor with renewal tracking, scope of access, and subcontractor flow-down. Feeds HIPAA BAA inventory and HRSA's contract-review items.
Single risk-management workflow — one SRA / risk-assessment process that produces findings, remediation tasks, and a governance review trail. Feeds HIPAA SRA, FTCA risk-management documentation, HRSA QI/QA.
Single audit trail — append-only, queryable by date range and record class. Feeds OCR investigations, OSV evidence requests, FTCA deeming applications.
Single incident log — one place where breaches, sharps injuries, WPV incidents, and adverse events get logged with a consistent schema. Different rulebooks pull different views.

The architecture point: the four rulebooks are four output views over a small, shared set of underlying data. A compliance platform built for the healthcare vertical (and FQHCs specifically) should treat them that way. A general-purpose GRC platform built for SOC 2 will not, because the underlying data model doesn't include the FQHC-specific objects.

The practical test: if your compliance platform can answer "show me all training completion records for Jane Doe across HIPAA, bloodborne pathogens, HazCom, and WPV in 2026, with timestamps" in a single query, you have one stack. If it requires four separate exports and a spreadsheet merge, you have four stacks pretending to be one.

Reading list