Be compliant — and
prove it.
OMNARA tracks a live posture against the regulations that govern healthcare operations, and produces the tamper-evident evidence to demonstrate it. This overview is honest about what is built, what is deployment-time, and what requires a credentialed environment.
Readiness & evidence tracking — not a certification. Statuses below are computed from live system evidence and stated plainly. This document is an operational overview for evaluation, not a legal attestation or a substitute for a formal audit.
The frameworks we track
HIPAA Security Rule
Administrative, physical, and technical safeguards for electronic PHI — access control, audit controls, integrity, transmission security, and activity review.
HIPAA Privacy Rule
Uses and disclosures of PHI, the minimum-necessary standard, and an individual's right to an accounting of disclosures.
Interoperability & Prior Auth
The CMS Interoperability and Prior Authorization Final Rule — FHIR APIs, prior-auth decision timeframes, specific denial reasons, and metrics.
CMS-0057-F — ready for January 1, 2027
The rule obligates impacted payers (Medicare Advantage, Medicaid, CHIP, and QHP issuers) to stand up four FHIR APIs by January 1, 2027, and already requires — since 2026 — prior-authorization decision timeframes, specific denial reasons, and annual metrics. OMNARA is the provider-side platform: it is built to interoperate with those APIs and to meet the provider-side operational duties today.
- Prior-authorization decision-timeframe tracking (72h expedited / 7-day standard)
- Specific denial reasons captured on every denial
- Prior-auth metrics computed and exportable as evidence
- Electronic prior auth modeled on Da Vinci PAS / DTR, submitted through the action guard
- Prior Authorization API (FHIR)
- Provider Access API
- Payer-to-Payer API
- Enhanced Patient Access API (with prior-auth data)
These are payer obligations. OMNARA's context and interoperability layer is structured to consume them once a credentialed payer endpoint is connected.
Sourced from the CMS-0057-F fact sheet (cms.gov) and 89 FR 8758. Confirm the final rule text before relying on specifics for your own compliance planning.
Control posture
Each control is graded from live system evidence. Met = the mechanism exists and is active. Partial = the platform does its part; an operator completes it at deploy. Connector = modeled and governed, live once credentialed.
| Control | Citation | What addresses it | Status |
|---|---|---|---|
| Audit controls | §164.312(b) | Immutable, append-only audit trail of every action and PHI access | Met |
| Information-system activity review | §164.308(a)(1)(ii)(D) | Queryable, exportable audit log; audit-coverage SLI | Met |
| Access control (unique ID, RBAC) | §164.312(a)(1) | Per-user accounts, deterministic RBAC, tenant isolation (RLS) | Met |
| Integrity | §164.312(c)(1) | Append-only trail, provenance, tamper-evident export hashing | Met |
| Accounting of disclosures | §164.528 | Every PHI access logged; filterable accounting export | Met |
| Minimum necessary | §164.502(b) | RBAC scoping; PHI kept out of logs, URLs, and prompts | Met |
| Encryption & decryption | §164.312(a)(2)(iv) | Secrets encrypted at rest; PHI-at-rest/KMS is deployment-time | Partial |
| Transmission security | §164.312(e)(1) | Security headers, CORS, guarded egress; TLS at deploy | Partial |
| Prior-auth decision timeframes | CMS-0057-F | Live 72h / 7-day adherence tracking | Met |
| Specific denial reasons | CMS-0057-F | Reason captured + reported on every denial | Met |
| Electronic prior auth (FHIR PAS) | CMS-0057-F | Modeled on Da Vinci; guarded, simulated until credentialed | Connector |
Prior-authorization SLA
OMNARA records when each request was submitted and decided, and its priority, then reports live adherence against the regulatory limits — with at-risk and breached counts, per-priority rollups, and the share of denials carrying a specific reason. These are the exact CMS-0057-F metrics, exportable as evidence.
Data handling & safety
Tenant isolation
Row-level security in the database scopes every query to one organization — data never crosses tenants, enforced below the application, not just in it.
PHI hygiene
PHI is kept out of application logs, URLs, and model prompts. Audit detail carries ids, counts, and flags — never raw PHI values.
Governed automation
Every external effect runs through a deterministic action guard. High-risk steps require human approval; the AI proposes and is never the authority.
No autonomous money movement
Payroll, purchase orders, and vendor payments require human approval and post balanced double-entry journals. The ledger is the system of record.
Proving it — tamper-evident exports
Any dataset, the immutable audit trail, or a full compliance bundle exports in standard formats. Every export is SHA-256 hashed and that hash is written into the immutable audit trail — so a downloaded file can be re-hashed later and matched against the log to prove it was not altered. Exporting PHI is itself recorded as a PHI-access event (HIPAA accounting of disclosures).
- Tenant-scoped exports — an export can never cross organizations
- Streamed with bounded memory, so a multi-million-row export is practical
- Optional detached HMAC signature when a signing key is configured
Open items — stated plainly
These require a credentialed environment or a formal audit. They are deliberately not represented as complete.
- Live connectors — payer FHIR (Da Vinci PAS/CRD/DTR), clearinghouse/X12, bank/ACH, distributor EDI, and identity (SSO/SCIM) — are complete, governed abstractions running in simulation until contracted.
- Production TLS, KMS / PHI-at-rest encryption, a managed event broker, and object-storage export offload are deployment-time controls.
- A formal WCAG 2.1 AA accessibility audit and a third-party HIPAA security assessment are prerequisites for any external compliance or certification claim.
- Sustained multi-million-row throughput is validated on production-sized infrastructure as part of a deployment.
Bring your auditor. We'll show the trail.