HIPAA Compliance & No-BA Architecture

The legal basis — 45 CFR §160.103

HIPAA defines a "Business Associate" as a person or entity that, on behalf of a Covered Entity, creates, receives, maintains, or transmits Protected Health Information. The applicable regulation is 45 CFR §160.103.

RecordIQ's architecture does none of those four things:

Because RecordIQ meets zero of the four statutory tests, RecordIQ Software LLC does not establish a Business Associate relationship with its customers under HIPAA. This is the same legal category occupied by shrink-wrapped desktop software such as Microsoft Word or Adobe Acrobat — widely used by Covered Entities for PHI-containing documents without a BAA, because the vendors themselves never touch the data.

What data leaves the customer's machine

For transparency, here is every byte RecordIQ transmits outside the customer environment:

• License activation: a cryptographic license key plus a 16-character hexadecimal device identifier, used solely to validate entitlement. No PHI, no document content.
• Application update checks (optional): a version string is sent to our release server to determine whether a newer build is available. No PHI, no document content.
• Crash reports (opt-in only): stack traces with PHI redaction applied. Disabled by default. Customer controls this in settings.

That's it. No telemetry, no analytics, no phone-home with customer content, and no background PHI transmission of any kind.

Why this matters — compliance as an advantage

Most medical-records review tools on the market today are cloud SaaS platforms. They must sign BAAs with every Covered Entity customer because PHI is in the vendor's custody by architecture. That creates ongoing compliance overhead: vendor breach notification obligations, subprocessor management, cloud access audits, and shared-responsibility debates during incident response.

RecordIQ's on-premises architecture removes all of that. The Covered Entity's PHI stays exactly where it already was — inside their own network perimeter, subject to their existing HIPAA security controls. RecordIQ does not expand the Covered Entity's attack surface, does not introduce a new subprocessor, and does not require the Covered Entity to extend its HIPAA vendor-management regime to a cloud provider.

Standards this architecture aligns with

• HIPAA Security Rule (45 CFR §164.306–.318) — technical safeguards applied locally on the Covered Entity's systems: AES-256 encryption at rest, immutable HMAC-chained audit logging, role-based access, automatic logoff.
• HIPAA Privacy Rule (45 CFR §164.514) — PHI redaction (18 HIPAA Safe-Harbor identifiers) is built into the Privacy / Redaction feature, used at the customer's discretion.
• NIST 800-66 Rev. 2 — the federal guidance for HIPAA Security Rule implementation recognizes on-premises tools running entirely within the Covered Entity's administrative, physical, and technical controls.
• SOC 2 CC7.2 / audit trail — every action is logged with ISO 8601 timestamps to a tamper-evident chained audit log local to the customer.

Customer policy still requires a BAA — here's what we do

Some Covered Entities have internal procurement or IT policies that reflexively require a signed BAA from every vendor, irrespective of the architectural analysis above. We respect those policies and do not want them to slow down the evaluation.

For those cases, we provide a pre-drafted Business Associate Agreement at /baa. The BAA we offer explicitly recognizes that RecordIQ does not receive, store, or transmit PHI, and its effect is primarily to confirm the architectural boundary. It exists to remove procurement friction — not because our architecture creates a BA relationship that would otherwise trigger one.

Common questions

Does RecordIQ process electronic Protected Health Information (ePHI)?

ePHI is processed on the Covered Entity's own workstation by RecordIQ software running locally, using the Covered Entity's compute, storage, and network resources. RecordIQ Software LLC does not have access to that processing.

Are you designed with HIPAA safeguards in mind?

"designed with HIPAA safeguards in mind" is a property of a Covered Entity or Business Associate — not a piece of software. RecordIQ is neither, so the label does not apply to us directly. However, RecordIQ is designed with HIPAA safeguards in mind: its controls (encryption at rest, audit logging, access control, PHI redaction tooling) are built to support the Covered Entity's own HIPAA Security Rule compliance.

What about subprocessors?

RecordIQ does not engage subprocessors with access to PHI. Our only subprocessors handle non-PHI functions (license issuance, update distribution, payment processing). None of these ever receive customer documents or PHI.

What about incident response / breach notification?

Because RecordIQ does not hold PHI, a breach of RecordIQ Software LLC's infrastructure cannot involve customer PHI. Customer PHI incident response remains the Covered Entity's responsibility under their own policies, with RecordIQ providing technical support for log review as requested.

Is this the same as "conduit" exception?

Not exactly. The HIPAA "conduit" exception (HHS guidance) addresses transmission services like couriers or ISPs that transport but don't meaningfully access PHI. RecordIQ is further outside the BA regime than a conduit — it never transports PHI at all, because PHI never leaves the Covered Entity's network.

Can you sign our BAA instead of yours?

Yes. We'll review your organization's BAA in good faith. If any terms conflict with our architecture (e.g., subprocessor disclosure, PHI-custody representations), we will propose redlines that preserve the substance while reflecting the on-premises reality.