Pyvorin and HIPAA

Pyvorin is a Python compiler toolchain, not a system that stores, processes, or transmits protected health information. It does not sit in a clinical workflow, touch an EHR, or handle patient records. That framing matters, because it means the honest HIPAA question is not "is Pyvorin compliant" — no build tool certifies anything — but "can I use Pyvorin inside a HIPAA-regulated development environment without weakening my safeguards". For pyvorin-native 1.0.9 the verified answer is yes, with two deliberate caveats this page will not bury.

Why a compiler enters a HIPAA conversation at all

Code in regulated environments often carries PHI-shaped material in places that are easy to forget: test fixtures with synthetic-but-realistic patient records, anonymisation scripts that reference real schemas, notebooks against production-shaped data. When a developer tool sends source to a vendor's server, that material leaves your boundary and your risk analysis inherits a vendor subprocesser you never chose. So the first property that matters is where compilation happens. Under pyvorin-native, it happens in-process on the developer's machine: the compiler sources contain no HTTP client, and runtime interception of every outbound request during verification captured exactly two endpoint families — licence checks and telemetry — neither carrying source code. Your repository contents stay inside your environment.

The caveat that keeps this honest: a sibling package, pyvorin-thin, submits source to a remote compile endpoint by design. The package name in your requirements file is a HIPAA-relevant configuration decision. If PHI-shaped literals could exist in the codebase, pin pyvorin-native and treat a thin install as a finding.

Mapping to the Security Rule's technical safeguards

§164.312 lists the technical safeguards a covered entity's systems must have. Pyvorin-native is not itself a covered system, but where it runs inside one, its verified behaviour either supports or stays out of the way of each family:

Two rows deserve a closer look, because earlier drafts overstated both. The audit row: sampled telemetry at 1% is not an audit trail, and we do not present it as one. The integrity row: the hash table is enforced, but the manifest's Ed25519 signature is inactive in 1.0.9 — an on-host attacker who edits both a binary and its hash entry is not caught by the package's self-check, so regulated deployments should protect the install tree with the file-integrity monitoring they already run for everything else. That gap, and the command to verify it yourself, is documented in protected component delivery.

BAAs and the vendor question

A business associate agreement becomes relevant when a vendor creates, receives, maintains, or transmits PHI on your behalf. Under pyvorin-native, the vendor receives a licence key, a device fingerprint, and sampled event metadata — no source, no payload data, no PHI by construction. Our position is that the compile path does not make us a business associate of yours, and the strongest support for that position is not our legal analysis but the packet capture you can rerun yourself. That said, whether your specific deployment creates a covered relationship is a question for your counsel, and we will not pre-empt it on a documentation page. If your compliance team wants a BAA conversation, route it through the licensing contacts at app.pyvorin.com rather than assuming one exists; no agreement is in place by default, and none is claimed here.

Offline and air-gapped operation

Healthcare environments routinely include networks with no internet route. pyvorin-native degrades gracefully there: an offline-valid licence keeps passing the gate even when online revalidation fails, and after lease expiry each tier has a fixed grace window — 24 hours for demo and trial, 72 hours for basic and professional, 90 days for enterprise, with server-issued offline permits extending enterprise operation further. Compilation itself needs no network at any point. The practical pattern for a sealed environment: activate once from a connected segment, let the lease and grace windows cover the maintenance cycle, and renew during scheduled connectivity. The mechanics are covered end to end in activation and entitlement and in the air-gapped environments article in this section.

Data at rest, on developer machines

One subtlety worth a paragraph in any environment where laptops leave the building. Pyvorin keeps derived artefacts of your code in two places: the disk compile cache inside the install tree (<site-packages>/.pyvorin_cache/disk_compile), keyed by a SHA256 of the source, and a kernel cache under ~/.pyvorin_cache. These are compiled binaries, not source text, but they are derived from it and in principle recoverable information about your code. They are also entirely local. If your safeguard set already requires full-disk encryption on developer machines — and most HIPAA security programmes do — these artefacts are covered by that control without any Pyvorin-specific policy. If it does not, this is one more reason to adopt it, not a Pyvorin gap to manage separately. And because every cached artefact is keyed by a source hash and checksum-validated on use, clearing the cache is a routine operation rather than a purge of unaccountable state.

A practical checklist for regulated deployments

Pulling the page into something you can hand to a security officer:

• Pin the package. Install pyvorin-native specifically; the thin variant submits source remotely and does not belong in a PHI-adjacent codebase.
• Review the egress rule. One hostname, api.pyvorin.com, for licensing and telemetry. Nothing else should appear, and anything else is worth investigating.
• Decide telemetry centrally. Set the privacy level at interpreter start-up if your risk analysis says the sampled event stream should not leave; do not rely on per-developer behaviour.
• Protect the install tree. The package self-checks its binaries on every import; your file-integrity monitoring covers the residual scenario where an attacker edits both a binary and its hash-table entry.
• Verify, then file. Run the checks in protected component delivery during onboarding and after every upgrade, and keep the output with your vendor assessments.

None of these items is exotic. That is rather the point: the toolchain slots into safeguards a HIPAA programme already has, instead of inventing new ones.

What we cannot evidence

Three limits, stated for your risk register. Pyvorin has not been independently audited against HIPAA, HITRUST, or any health-sector framework as of 1.0.9 — no attestation exists and none is claimed. Telemetry defaults to the standard privacy level and can only be reduced via an in-process API call, so disabling it fleet-wide is your deployment control, not a shipped switch. And the product's own self-verification, while real, does not cover the one sophisticated on-host tampering scenario described above. Each of these has a compensating control on your side; none of them is hidden.

Where to go next

• Security and source privacy — the payload-level analysis behind every "no source leaves" statement here.
• Protected component delivery — integrity verification, the lease signature, and the known gap.
• Network requirements — the complete endpoint inventory for your firewall and egress review.
• Activation and entitlement — the gate, device binding, and grace periods in detail.

Last reviewed 9 February 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal: outbound traffic captured by runtime interception, integrity and licensing implementation read directly, gate behaviour executed on an unlicensed machine. Pyvorin is not a covered entity or business associate, holds no HIPAA attestation, and nothing on this page is legal advice.