164.502 Uses and disclosures of PHI — general rules draft
A covered entity, or a business associate acting on its behalf, may use or
disclose protected health information only as permitted or required by the
Privacy Rule.
Pryv platform facilitated
Pryv's permission model
is the technical enforcement layer for Article 502: an app or
counterparty can only read or write streams its access permits.
The "permitted or required by the Privacy Rule" determination —
which use cases are TPO, when authorization is required, what
minimum-necessary means in your workflow — is your programmatic
decision; Pryv enforces whatever scope you grant.
HDS facilitated USCH
On top of Pryv's permission model, HDS operates the platform that
enforces it: as a business associate, HDS uses or discloses PHI only as
its BAA and the covered entity's instructions permit. The substantive
determination of which uses are permitted remains the covered entity's.
detail
Every workforce, app, and counterparty action on PHI is mediated by an
access whose permissions bound the streams and levels reachable. HDS
configures no use or disclosure of customer PHI for its own purposes, and
the audit log makes each use attributable to a specific access at a
specific time.
- 🔒 hipaa/policies/uses-and-disclosures available on request
Implementer
covered-entity documented
Decide which uses and disclosures are permitted under the Privacy Rule
and configure access scopes accordingly.
business-associate documented
📄 baa
Use or disclose PHI only as your BAA and the covered entity's
instructions permit.
individual out-of-scope
164.506 Uses and disclosures for treatment, payment, healthcare operations (TPO) draft
Use and disclosure of PHI is permitted for the entity's own treatment,
payment and healthcare operations, and under defined conditions for another
entity's TPO.
Pryv platform facilitated
TPO is the largest category
of permitted uses. Pryv lets you mint accesses tagged with the
TPO purpose in `clientData` (e.g., `purpose: "treatment"`); the
permission model enforces the scope. The TPO-vs-not
classification of any specific workflow is your programmatic
judgement; Pryv carries it forward into the audit trail.
HDS facilitated USCH
HDS provides the means to mint per-purpose accesses tagged with the TPO
purpose, each independently revocable and auditable. The classification
of any given workflow as TPO is the covered entity's judgement, which HDS
carries forward into the audit trail.
detail
A common pattern separates accesses by purpose — one per treatment,
billing and operations workflow — so the TPO classification becomes a
durable artefact rather than a verbal claim. HDS stores the purpose tag
and preserves it across the access version chain.
- 🔒 hipaa/policies/uses-and-disclosures available on request
Implementer
covered-entity documented
Classify your workflows as TPO or not and provision purpose-tagged
accesses accordingly.
business-associate documented
📄 baa
Act on TPO data only within the scope your BAA permits.
individual out-of-scope
164.508 Uses and disclosures requiring authorization draft
Uses and disclosures not otherwise permitted require a written
authorization from the individual that meets defined content requirements.
Pryv platform implemented
The authorization Pryv mints when your subject grants an access IS
the §164.508 authorization record — versioned, immutable per
version, with the granted scope (permissions) and the authorization
text (clientData or a `consent/request-cmc` event) inseparable.
Withdrawal is a single API call. For cross-account / cross-entity
authorizations, the CMC plugin carries the negotiation state.
HDS facilitated USCH
HDS exposes consent primitives (the @pryv/cmc consent flow and access
grant) so the authorization captured when an individual grants an access
is a versioned, immutable record binding the granted scope to the
authorization text. Withdrawal is a single API call.
detail
The §164.508(c) elements map onto access and client-data fields: the
information disclosed onto permissions, the recipient onto the access
counterparty, the signature equivalent onto the auditable grant act, the
expiration onto the access expiry, and the right to revoke onto access
deletion. HDS ships the primitives; presenting the §508(c) elements at
the grant moment is the covered entity's UX responsibility.
- 🔒 hipaa/policies/authorizations available on request
Implementer
covered-entity documented
Ensure your consent surface presents all §508(c) authorization elements
and retains the authorization record.
individual facilitated
You grant and revoke authorizations through the consent flow; each act
is recorded.
business-associate documented
📄 baa
Honour and record authorizations as instructed by the covered entity.
164.510 Uses and disclosures requiring opportunity to agree or object draft
Disclosures to family or friends, or for facility-directory purposes, may
proceed if the individual is given the opportunity to agree or object and
no objection is reasonably inferred.
Pryv platform facilitated
The opportunity-to-agree-or-
object construct is operational. Pryv lets you record the
offered choice and the individual's response as durable
artefacts (clientData on the relevant access, or a
`consent/notice-cmc` / custom event), so the §164.510
reasonable-inference becomes a record rather than recollection.
HDS facilitated USCH
HDS provides durable storage for the offered choice and the individual's
response as client-data on the relevant access or as a consent event, so
the reasonable-inference standard rests on a record rather than
recollection. The operational offer itself is the covered entity's.
detail
The opportunity-to-agree-or-object construct is operational and
circumstance-driven. HDS stores the offered choice and the recorded
response so the §164.510 determination is reconstructable later.
- 🔒 hipaa/policies/uses-and-disclosures available on request
Implementer
covered-entity documented
Offer the opportunity to agree or object and record the individual's
response.
individual out-of-scope
164.512 Uses and disclosures for which authorization or opportunity is not required draft
Twelve categories of disclosures are permitted without authorization
(public health, law enforcement and others), each subject to specific
conditions.
Pryv platform facilitated
Section 512 disclosures are
operationally driven by the circumstances (subpoena, public-
health request, etc.). Pryv's contribution is durability: every
such disclosure must still go through an access, and the audit
log captures it. Recording the §512 category and rationale in
`access.clientData.legal_basis` makes the disclosure
justification recoverable later.
HDS facilitated USCH
HDS contributes durability: every §164.512 disclosure still rides on an
access and is captured in the audit log, and the §512 category and
rationale can be recorded against the access. Whether a disclosure
qualifies is the covered entity's legal determination.
detail
The recommended pattern mints a purpose-specific access per §512
invocation, records the disclosure category and statutory basis, executes
the disclosure, then revokes the access. The audit trail shows the full
lifecycle attached to the legal-basis claim.
- 🔒 hipaa/policies/uses-and-disclosures available on request
Implementer
covered-entity documented
Determine whether each disclosure qualifies under §512 and record its
category and statutory basis.
individual out-of-scope
164.514(a) De-identification of PHI draft
PHI de-identified by the Safe Harbor method or by Expert Determination is
no longer subject to the Privacy Rule.
Pryv platform facilitated
Pryv stores whatever event
content you write; de-identification is a transformation you
perform on the data before storage (or before disclosure).
Custom event types + the per-stream design let you keep an
identified and a de-identified copy under separate permission
scopes, simplifying §514(a) workflows.
HDS facilitated USCH
HDS stores whatever event content is written and lets identified and
de-identified copies sit under separate permission scopes, simplifying
§514(a) workflows. The de-identification determination and transformation
are the covered entity's.
detail
A typical layout keeps identified events on a restricted clinical stream
tree and de-identified projections on a parallel tree accessible to a
broader analyst group. The de-identification logic is the covered
entity's application code; HDS stores its output.
- 🔒 hipaa/policies/de-identification available on request
Implementer
covered-entity documented
Choose the de-identification method, perform the transformation, and
retain the determination record.
individual out-of-scope
164.514(d) Minimum necessary use, disclosure and requests draft
Reasonable efforts must be made to limit PHI to the minimum necessary to
accomplish the intended purpose.
Pryv platform implemented
Per-stream permissions are the minimum-necessary primitive: each
access carries only the streams + levels needed for its purpose,
so by construction the holder cannot see more PHI than granted.
Your stream layout + permission-design choices determine the
granularity at which "minimum necessary" can be enforced
technically.
HDS facilitated USCH
Per-stream, per-level access tokens are the minimum-necessary primitive
HDS exposes: each access carries only the streams and levels its purpose
needs, so by construction the holder cannot see more PHI than granted.
The granularity of "minimum necessary" follows the covered entity's
stream and permission design.
detail
HDS facilitates a stream topology where distinct purposes live on
distinct subtrees and per-purpose accesses point at the smallest
necessary subtree, avoiding blanket permissions except for stated
unrestricted roles.
- 🔒 hipaa/policies/minimum-necessary available on request
Implementer
covered-entity documented
Design stream topology and permission scopes so each access is limited
to the minimum necessary, and document the rationale.
business-associate documented
📄 baa
Request only the minimum-necessary scope for your processing.
individual out-of-scope
164.520 Notice of privacy practices draft
A notice must be provided that adequately describes the entity's uses and
disclosures of PHI and the individual's rights.
Pryv platform facilitated
The notice itself is your
editorial content. Pryv preserves the notice text shown to each
subject — typically on `access.clientData.privacy_notice` or as
a dedicated event — so the same words presented are recoverable
per subject per time. The customer-facing `app-web-auth3`
template is the surface where the notice typically appears.
HDS facilitated USCH
HDS preserves the notice text shown to each individual, on the relevant
access client-data or as a dedicated event, so the exact words presented
are recoverable per individual and per time. The notice content is the
covered entity's editorial responsibility.
detail
The customer-facing authentication surface is where the notice typically
appears at grant time. HDS stores the presented notice as a durable
artefact bound to the individual's session.
- 🔒 hipaa/policies/notice-of-privacy-practices available on request
Implementer
covered-entity documented
Author and maintain your notice of privacy practices and present it to
individuals as required.
individual out-of-scope
164.522 Right to request restriction; confidential communications draft
An individual may request restrictions on uses and disclosures and may
request to receive confidential communications by alternative means or at
alternative locations.
Pryv platform configurable
A granted restriction is a scope-down on the relevant access
(`accesses.update` to narrower permissions) or a revocation
(`accesses.delete`). The access-version chain proves what state
was in force before the restriction and from when it applies.
Confidential-communications choices (alternate address, phone)
live in `account.clientData` or a dedicated event.
HDS configurable USCH
A granted restriction is configured as a scope-down or revocation of the
relevant access, and the access version chain proves what state was in
force before and from when the restriction applies. Confidential-
communication preferences are stored as account client-data or a
dedicated event.
detail
Post-HITECH §522(a)(1)(vi) makes restrictions on disclosure to a health
plan for out-of-pocket-paid services mandatory on request; the
configuration pattern is identical, but the covered entity must apply it
without discretion when that condition is met.
- 🔒 hipaa/procedures/restriction-requests available on request
Implementer
covered-entity documented
Evaluate restriction and confidential-communication requests and apply
the corresponding access changes.
individual facilitated
You request restrictions and alternative-communication preferences,
which are recorded against your account.
business-associate out-of-scope
164.524 Right of access by the individual draft
An individual has the right to inspect and obtain a copy of their PHI in a
designated record set, in the form and format requested if readily
producible.
Pryv platform implemented
Your subject, holding a personal token, reads everything via the
standard Pryv API — events, streams, accesses (with history),
audit records, attachments — in the canonical event-type schemas.
Wrap that in a subject-portal app and you have §164.524 covered
end-to-end. The 30-day response timeline is your process target,
not a software latency.
HDS implemented USCH
Pryv is user-centric: the individual owns their data and, holding a
personal token, reads everything through the standard API — events,
streams, accesses with history, audit records and attachments. HDS
operates this access capability end-to-end across both regions.
detail
Events return as canonical JSON validated against the data-type schemas —
structured, machine-readable and consumer-friendly — and attachments
download in their stored MIME type. The 30-day response timeline is the
covered entity's process target, not a software latency, and any
non-native export format is produced by the implementer's portal.
- 🔒 hipaa/procedures/individual-right-of-access available on request
Implementer
individual facilitated
You access and export your own PHI directly through the standard API or
a subject portal built on it.
covered-entity documented
Run the access-request process and meet the response timeline; provide
any requested non-native export format.
business-associate documented
📄 baa
Make PHI available to the covered entity to satisfy access requests.
164.526 Right to amend draft
An individual has the right to have a covered entity amend PHI or a record
about the individual in a designated record set.
Pryv platform implemented
`events.update` is the amendment primitive; event versioning
preserves the prior content so the amendment trail is auditable.
The §164.526 process (request → decision → action → notice) is
yours to run; the technical record-keeping is shipped.
HDS facilitated USCH
HDS exposes event update as the amendment primitive, with event
versioning preserving prior content so the amendment trail is auditable.
The §164.526 process of request, decision, action and notice is the
covered entity's to run.
detail
For denied amendments where the individual files a statement of
disagreement, the statement can be stored as a separate event on the
designated-record-set stream linked back to the original, so the
disagreement travels with the data on subsequent disclosures.
- 🔒 hipaa/procedures/amendment-requests available on request
Implementer
covered-entity documented
Run the amendment request, decision and notice process and record
accepted amendments and statements of disagreement.
individual facilitated
You request amendments; accepted changes and any disagreement statement
are preserved with version history.
business-associate out-of-scope
164.528 Accounting of disclosures draft
An individual has the right to an accounting of disclosures of their PHI
made in the six years prior to the request, with specified exceptions.
Pryv platform implemented
Pryv's audit log is the §164.528 substrate: every API method call
attributed to an access (with version) is recorded. Filtering by
access category — TPO accesses, §164.512 disclosures, etc. — lets
you derive the §164.528-eligible subset (which excludes TPO).
Six-year retention of the audit log is your operator-side
configuration.
HDS facilitated USCH
The audit log is the §164.528 substrate: every API method call attributed
to an access and version is recorded, and filtering by access category
lets the covered entity derive the accountable subset. Six-year retention
of the audit log is an HDS-operated configuration on both regions.
detail
Each accounting field has an audit-log source: date from the row
timestamp, recipient from the access holder or counterparty, description
from the recorded API method and path, and purpose from the access
purpose tag. The audit log does not capture request bodies, so the
description is at the API-shape level — sufficient under §164.528 and
favourable for data minimisation.
- 🔒 hipaa/procedures/accounting-of-disclosures available on request
Implementer
covered-entity documented
Compile and deliver the accounting, applying the §164.528 exceptions and
your retention policy.
individual facilitated
You request an accounting; the audit log provides the underlying
disclosure record.
business-associate documented
📄 baa
Provide the covered entity with the disclosure records you hold.
164.530(a) Privacy officer / contact person draft
A covered entity must designate a privacy official and a contact person
responsible for receiving complaints.
Pryv platform facilitated
Designation is organizational.
Pryv's contribution is indirect: the audit log gives the
privacy official a concrete artifact to review when investigating
complaints or auditing internal use.
HDS documented USCH
Designation of a privacy official is the covered entity's organizational
decision. HDS's contribution is indirect: the audit log gives that
official a concrete artefact to review when investigating complaints or
internal use. HDS maintains its own privacy contact under its BA role.
detail
HDS operates as a business associate and names its own responsible
contact, but the covered entity's privacy-official designation is a
programme element outside HDS's scope.
- 🔒 hipaa/policies/privacy-program-governance available on request
Implementer
covered-entity documented
Designate and document your privacy official and complaint contact.
individual out-of-scope
164.530(b) Training draft
A covered entity must train all workforce members on its privacy policies
and procedures.
Pryv platform facilitated
Training itself is your
programme. Pryv's contribution to operationalizing it: the
audit log + observability data make training-effectiveness
measurable (e.g., does role X exercise access patterns matching
policy after training?). The training content + record-keeping
are yours.
HDS documented USCH
Workforce privacy training is the covered entity's programme. HDS trains
its own workforce on its privacy and security policies as a business
associate and retains the training records; the customer's programme is
out of HDS's scope.
detail
Audit and observability data can make training effectiveness measurable
by revealing whether access patterns match policy after training, but the
training content and record-keeping belong to the implementer.
- 🔒 hipaa/procedures/workforce-training available on request
Implementer
covered-entity documented
Train your workforce on your privacy policies and retain the training
records.
business-associate documented
📄 baa
Train your own workforce on safeguarding PHI under your BAA.
individual out-of-scope
164.530(c) Safeguards draft
A covered entity must have appropriate administrative, technical and
physical safeguards to protect the privacy of PHI.
Pryv platform facilitated
Section 530(c) is the
Privacy Rule's pointer to the Security Rule and to physical /
administrative safeguards. See the HIPAA-Security rows for the
technical safeguards Pryv contributes; §164.310 (Physical) for
the operator's hosting environment. Together those rows
constitute the §530(c) answer for this Pryv deployment.
HDS facilitated USCH
Section 530(c) points to the Security Rule and to physical and
administrative safeguards. HDS supplies the technical and hosting
safeguards documented in the HIPAA-Security scope — access control,
audit, encryption in transit and at rest, regional residency — that
partly answer §530(c) for an HDS deployment.
detail
See the HIPAA-Security rows for the technical safeguards HDS operates and
the physical-safeguard coverage of the hosting environment. Together they
constitute the §530(c) technical and physical answer; the administrative
safeguards remain the covered entity's.
- 🔒 hipaa/policies/privacy-safeguards available on request
Implementer
covered-entity documented
Maintain administrative safeguards and document how the technical and
physical safeguards meet §530(c).
individual out-of-scope
164.530(f) Mitigation draft
A covered entity must mitigate, to the extent practicable, any harmful
effect of a use or disclosure in violation of its policies or the Privacy
Rule.
Pryv platform facilitated
Audit log + access version
chain let you scope what was disclosed to whom and when — the
first step in any mitigation. `bin/backup.js --restore` is
available if mitigation involves rolling back data state;
`accesses.delete` is the primitive to revoke access from the
offending counterparty.
HDS facilitated USCH
Audit log and access version chain let the covered entity scope what was
disclosed, to whom and when — the first step in any mitigation. HDS
provides access revocation and operates backup and restore should
mitigation require rolling back data state.
detail
HDS exposes access deletion to revoke an offending counterparty and
operates the backup-restore capability across both regions; the mitigation
decision and any breach notification follow the covered entity's process.
- 🔒 hipaa/procedures/incident-mitigation available on request
Implementer
covered-entity documented
Investigate violations, decide and execute mitigation, and run any
required notifications.
business-associate documented
📄 baa
Report incidents to the covered entity and assist mitigation per your
BAA.
individual out-of-scope
164.502(b) Minimum necessary uses, disclosures and requests draft
Reasonable efforts must be made to limit PHI to the minimum necessary,
subject to enumerated exceptions including treatment disclosures,
disclosures to the individual, authorized disclosures and disclosures
required by law.
Pryv platform implemented
Same primitive mapping as §164.514(d) minimum-necessary: per-
stream permissions are the technical control; the holder cannot
see more PHI than the granted scope permits. §502(b)(2)
exceptions are programmatic — the implementer leaves those
accesses unscoped per the exception's permission, and the audit
log records the broader access for accountability.
HDS facilitated USCH
Per-stream permissions are the same minimum-necessary control as
§164.514(d): the holder cannot see more PHI than the granted scope
permits. The §502(b)(2) exceptions are programmatic, and the audit log
records any broader access for accountability.
detail
Where an exception applies, the implementer leaves the access scoped per
that exception's permission; HDS records the broader access so it remains
accountable. The substantive minimum-necessary policy is the covered
entity's.
- 🔒 hipaa/policies/minimum-necessary available on request
Implementer
covered-entity documented
Apply minimum-necessary scoping and document where exceptions are
invoked.
business-associate documented
📄 baa
Limit your requests and uses of PHI to the minimum necessary.
individual out-of-scope
164.502(e)(1) Disclosures to business associates draft
A covered entity may disclose PHI to a business associate, and allow it to
create, receive, maintain or transmit PHI on its behalf, only with
satisfactory assurances — typically a written BAA — that the business
associate will appropriately safeguard the information.
Pryv platform facilitated
The technical disclosure is
mediated by the access primitive — mint a BA-specific access
with `clientData.role = "business_associate"` + `clientData.baa_id
= "<contract-ref>"`, scoped to the subjects / streams covered
by the BAA. Cross-platform BA arrangements (where the BA runs
their own Pryv) inherit the CMC capability pattern for cross-
account flow.
HDS facilitated USCH
HDS offers a Business Associate Agreement and the technical disclosure
mechanism: a BA-specific access tagged with its role and contract
reference, scoped to the subjects and streams the BAA covers. HDS itself
signs a BAA when it acts as the business associate.
detail
Cross-platform business-associate arrangements inherit the cross-account
capability pattern. The access carries its business-associate role and
contract reference so disclosures are attributable to the BAA, while the
contract itself is signed between the parties.
- 🔒 hipaa/registers/baa-register available on request
Implementer
covered-entity documented
📄 baa
Execute a BAA with each business associate before disclosing PHI and
scope their access to what the BAA covers.
business-associate documented
📄 baa
Sign the BAA and flow obligations down to any subcontractors.
individual out-of-scope
164.530(d) Complaints to the covered entity draft
A covered entity must provide a process for individuals to complain about
its policies, procedures or compliance, and must document complaints
received and their disposition.
Pryv platform facilitated
A complaint-intake workflow
stores each complaint as an event on a designated
`complaints/*` stream with `clientData.disposition` tracking
outcome. The audit log captures the timestamp + actor on each
disposition update — making the §530(d)(2) documentation
requirement an automatic byproduct of normal record-keeping.
HDS facilitated USCH
HDS provides the means to store each complaint as an event on a dedicated
stream with a disposition field, and the audit log captures the timestamp
and actor on each disposition update. The complaint-handling process is
the covered entity's.
detail
Storing complaints and dispositions as data makes the §530(d)(2)
documentation requirement a byproduct of normal record-keeping. The
intake workflow and response are the implementer's.
- 🔒 hipaa/procedures/complaint-handling available on request
Implementer
covered-entity documented
Operate the complaint process and document complaints and their
dispositions.
individual out-of-scope
164.530(e) Sanctions draft
A covered entity must have and apply appropriate sanctions against
workforce members who fail to comply with its privacy policies and
procedures.
Pryv platform out-of-scope
Sanctions are an HR / disciplinary process. No software role at
the sanction-decision layer; the audit log gives the underlying
evidence ("did this person actually access X?") that HR
processes evaluate.
HDS documented USCH
Sanctions are an HR and disciplinary process with no software role at the
decision layer. HDS maintains its own workforce sanction policy as a
business associate; the audit log supplies the underlying evidence that
disciplinary processes evaluate.
detail
HDS documents and applies sanctions for its own workforce, but the
covered entity's sanction programme is outside HDS's scope.
- 🔒 hipaa/policies/workforce-sanctions available on request
Implementer
covered-entity documented
Maintain and apply your workforce sanction policy and document
enforcement.
business-associate documented
📄 baa
Maintain sanctions for your own workforce under your BAA.
individual out-of-scope
164.530(g) Refraining from intimidating and retaliatory acts draft
A covered entity may not intimidate, threaten, coerce, discriminate against
or retaliate against an individual for exercising any right under the
Privacy Rule.
Pryv platform out-of-scope
Anti-retaliation is an organizational policy + culture commitment;
no software role.
HDS out-of-scope USCH
Anti-retaliation is an organizational policy and culture commitment with
no software role. It rests entirely with the covered entity's programme.
detail
HDS provides no technical control bearing on this requirement; it is a
conduct obligation of the covered entity.
Implementer
covered-entity documented
Maintain and enforce an anti-retaliation policy.
individual out-of-scope
164.530(i) Policies and procedures draft
A covered entity must implement policies and procedures designed to comply
with the standards and implementation specifications of the Privacy Rule.
Pryv platform facilitated
Same pattern as HIPAA-
Security §164.316(a): policies-as-data on a
`compliance/policies/*` stream get versioning + retention +
audit. The drafting + approval + review-cycle procedure is the
privacy officer's. Cross-link to §164.316(a) preserves the
Security Rule's parallel obligation.
HDS facilitated USCH
As with the Security Rule's documentation requirement, HDS provides the
means to hold policies as versioned, retained, audited data on a
dedicated stream. The drafting, approval and review cycle is the privacy
officer's, and HDS maintains its own privacy policies as a BA.
detail
Policies-as-data on a dedicated compliance stream inherit versioning,
retention and audit. The covered entity's policy programme is its own;
HDS documents the policies governing its operations.
- 🔒 hipaa/policies/privacy-policy-management available on request
Implementer
covered-entity documented
Author, approve and periodically review your privacy policies and
procedures.
business-associate documented
📄 baa
Maintain policies and procedures for safeguarding PHI under your BAA.
individual out-of-scope
164.510(b) Disclosures for involvement in care and for notification purposes draft
A covered entity may disclose to a family member, relative, close friend or
other person identified by the individual PHI directly relevant to that
person's involvement in the individual's care or payment for care.
Pryv platform facilitated
The §510(b) "directly
relevant" determination + relationship verification are
clinical-workflow concerns. Pryv pattern: mint a time-bounded
access for the involved person with permissions narrowed to
"directly relevant" streams + `clientData.relationship`
capturing the §510(b)(1) basis (family member name, role,
individual's opportunity-to-object record).
HDS facilitated USCH
HDS supports minting a time-bounded access for the involved person, with
permissions narrowed to the directly-relevant streams and client-data
capturing the relationship and the §510(b) basis. The directly-relevant
determination and relationship verification are clinical-workflow
concerns of the covered entity.
detail
The access records the relationship, the involved person's role, and the
individual's opportunity-to-object record. HDS stores and enforces the
narrowed scope; the disclosure decision is the implementer's.
- 🔒 hipaa/policies/uses-and-disclosures available on request
Implementer
covered-entity documented
Determine directly-relevant scope, verify the relationship, and record
the disclosure basis.
individual facilitated
You identify the persons involved in your care and may object.
business-associate out-of-scope
164.512(b) Uses and disclosures for public-health activities draft
A covered entity may disclose PHI for public-health activities to
authorities authorized by law to collect or receive it, including disease
and injury reporting, vital-event reporting and public-health surveillance.
Pryv platform facilitated
Public-health-authority
recipient is recorded on the access's
`clientData.recipient_authority` + `clientData.statute` for the
§512(b) statutory basis. Audit log anchors the disclosure to a
specific timestamp + event range. The "authorized by law"
determination is the covered entity's legal judgement.
HDS facilitated USCH
HDS lets the recipient authority and statutory basis be recorded on the
access, and the audit log anchors the disclosure to a timestamp and event
range. The authorized-by-law determination is the covered entity's legal
judgement.
detail
A per-instance access carries the public-health-authority recipient and
the statutory basis; the audit trail preserves the disclosure. HDS makes
no public-health disclosure of customer PHI on its own initiative.
- 🔒 hipaa/policies/uses-and-disclosures available on request
Implementer
covered-entity documented
Confirm the public-health authority's legal basis and record the
disclosure.
individual out-of-scope
164.512(f) Uses and disclosures for law-enforcement purposes draft
A covered entity may disclose PHI for law-enforcement purposes under
specific conditions, such as court order or warrant, administrative
request, identification and location, victim of crime, or decedent.
Pryv platform facilitated
§512(f) categories drive
vocabulary for `clientData.law_enforcement_basis` (e.g.,
`"f_1_i_court_order"`, `"f_2_ii_subpoena"`, `"f_4_victim"`).
Per-instance disclosure access minted + revoked; audit log
preserves the chain. The decision of whether the request
qualifies under §512(f) is legal counsel's, not Pryv's.
HDS facilitated USCH
HDS supports recording the §512(f) category as the law-enforcement basis
on a per-instance access that is minted and revoked around the
disclosure, with the audit log preserving the chain. Whether the request
qualifies under §512(f) is legal counsel's decision.
detail
The access carries the specific §512(f) basis vocabulary; HDS stores and
audits the disclosure but makes no law-enforcement disclosure of customer
PHI on its own initiative outside legal process served on it.
- 🔒 hipaa/procedures/law-enforcement-requests available on request
Implementer
covered-entity documented
Evaluate law-enforcement requests against §512(f) conditions and record
the basis.
individual out-of-scope
164.524(b) Right of access — requests and responses draft
A covered entity may require written access requests within reasonable
limits and must act within 30 days, with one 30-day extension permitted on
written notice.
Pryv platform facilitated
Request-intake workflow
stores each request as an event on a designated
`access-requests/*` stream with `clientData.due_by` computed
from receipt timestamp. The 30/30-day operational cadence is
the covered entity's process; once the response is ready, the
individual exercises §524 directly via the standard Pryv API
(see the §164.524 parent row).
HDS facilitated USCH
HDS supports storing each access request as an event on a dedicated
stream with a computed due date, so the 30/30-day cadence is trackable.
The operational cadence and decision remain the covered entity's; for
individuals who can self-authenticate, the app-portability self-service
tool bypasses the 30-day clock entirely (the individual obtains the data
immediately, without a written-request intake).
detail
The request-intake artefact records receipt time and the resulting due
date. The substantive response is delivered through the §164.524 access
capability described in the parent row. Self-service via app-portability
eliminates the need for a §524(b)(2) timely-response procedure on the
individual-direct path; the timeline obligation remains operative on the
partner-mediated path (covered entity intake → HDS-as-BA fulfilment).
- doc: https://demo-portability.datasafe.dev
- doc: https://portability.hds.ngo
- 🔒 hipaa/procedures/individual-right-of-access available on request
Implementer
covered-entity documented
Operate the request intake and meet the §524(b) response timeline.
individual facilitated
You submit access requests, which are tracked to a due date.
business-associate out-of-scope
164.524(c) Right of access — provision of access draft
A covered entity must provide access in the form and format requested if
readily producible, otherwise in readable hard copy or another agreed form,
and must provide a summary if the individual agrees in advance.
Pryv platform implemented
The Pryv API delivers events in canonical JSON (data-types
schemas) — "readily producible" in the §524(c) sense.
Implementer's portal can transform to PDF / printed format
where requested. Summaries are application-layer constructions
from the same source events.
HDS implemented USCH
The HDS-operated API delivers events in canonical JSON validated against
the data-type schemas — readily producible in the §524(c) sense — across
both regions. The app-portability self-service web app gives individuals
a one-click ZIP download of their full PHI dump; transformation to PDF
or print and summary construction remain application-layer work on the
same source events.
detail
HDS operates the standard read path that returns structured,
machine-readable PHI. The app-portability tool (portability.hds.ngo)
packages it into ZIPs the individual can keep or forward to another
covered entity. Non-native formats and summaries are built by the
implementer's portal from the same source events.
- doc: https://demo-portability.datasafe.dev
- doc: https://portability.hds.ngo
- doc: https://github.com/healthdatasafe/app-portability
- 🔒 hipaa/procedures/individual-right-of-access available on request
Implementer
individual facilitated
You obtain your PHI in canonical JSON or a format your portal produces.
covered-entity documented
Provide requested formats and summaries and agree applicable fees in
advance.
business-associate out-of-scope
164.502(g) Personal representatives draft
A covered entity must treat a personal representative as the individual for
uses and disclosures of PHI, subject to exceptions for abuse, neglect or
endangerment concerns.
Pryv platform facilitated
Pryv pattern: the personal
representative holds an `app` or `shared` access to the subject's
data with full scope (the effective "treat as individual"
technical permission). The access's
`clientData.representative_relationship` +
`clientData.legal_basis` capture the relationship; the
revocation-by-exception pattern is `accesses.update` to narrow
/ `accesses.delete` to remove. The "abuse / neglect /
endangerment" determination is clinical / legal judgement.
HDS facilitated USCH
HDS supports the representative holding an access to the individual's data
with the appropriate scope — the technical "treat as the individual"
permission — with the relationship and legal basis recorded as
client-data. The abuse, neglect and endangerment exceptions are clinical
and legal judgements of the covered entity.
detail
The exception pattern narrows or deletes the representative's access. HDS
stores the representative relationship and legal basis; the determination
of whether an exception applies is the implementer's.
- 🔒 hipaa/policies/personal-representatives available on request
Implementer
covered-entity documented
Verify representative status, grant appropriate access, and apply
exceptions where warranted.
individual facilitated
A verified personal representative may act on your behalf with recorded
basis.
business-associate out-of-scope
164.512(a) Uses and disclosures required by law draft
A covered entity may use or disclose PHI to the extent required by law,
limited to the relevant requirements of that law.
Pryv platform facilitated
"Required by law" disclosures
still ride on accesses; record the statutory basis in
`clientData.statute` so the audit chain ties the disclosure to
the legal authority. The compliance burden of the cited law is
separate.
HDS facilitated USCH
Required-by-law disclosures still ride on accesses, and HDS lets the
statutory basis be recorded so the audit chain ties the disclosure to its
legal authority. The compliance burden of the cited law is the covered
entity's.
detail
The access carries the statute reference; the audit trail preserves the
disclosure. HDS responds to legal process served on it as a business
associate per its BAA and applicable law.
- 🔒 hipaa/policies/uses-and-disclosures available on request
Implementer
covered-entity documented
Confirm the legal requirement, limit the disclosure to it, and record
the basis.
business-associate documented
📄 baa
Disclose as required by law and notify the covered entity per your BAA.
individual out-of-scope
164.514(b) De-identification — implementation specifications draft
De-identification may use Expert Determination that re-identification risk
is very small, or Safe Harbor removal of the 18 enumerated identifiers with
no actual knowledge of residual re-identifiability.
Pryv platform out-of-scope
Choice of method + execution are app-side. Pryv stores the
output of either method as ordinary events on the de-identified
streams.
HDS documented USCH
The choice of method and its execution are application-side decisions of
the covered entity. HDS stores the output of either method as ordinary
events on the de-identified streams and provides no de-identification
determination of its own.
detail
HDS documents that de-identification is the covered entity's
responsibility; the platform simply persists whatever events the
implementer's de-identification process produces.
- 🔒 hipaa/policies/de-identification available on request
Implementer
covered-entity documented
Select and execute Expert Determination or Safe Harbor and retain the
documentation.
individual out-of-scope
164.514(c) De-identification — re-identification draft
A covered entity may assign a re-identification code to de-identified
information, provided the code is not derived from information about the
individual and is not used or disclosed for any other purpose.
Pryv platform facilitated
When re-identification is a
workflow requirement, the code-to-PHI mapping is a tightly
scoped resource: keep it on a dedicated `re-id-map/*` system-
stream-adjacent subtree with access permitted only to the
re-identification administrator role. The code generation
method (random / hash-of-non-PHI) must not encode PHI per
§514(c)(1)(ii) — that's an editorial requirement on the
implementer.
HDS facilitated USCH
When re-identification is needed, HDS supports keeping the code-to-PHI
mapping as a tightly scoped resource reachable only by the
re-identification administrator role. The code-generation method must not
encode PHI, which is the covered entity's editorial requirement.
detail
The mapping lives on a dedicated subtree with access permitted only to the
re-identification role. HDS enforces the scope and stores the mapping;
ensuring the code is random or derived from non-PHI is the implementer's.
- 🔒 hipaa/policies/de-identification available on request
Implementer
covered-entity documented
Generate codes that do not encode PHI and restrict their use to
re-identification.
individual out-of-scope
164.528(b) Accounting of disclosures — implementation specifications draft
Each accounting entry must include the disclosure date, the recipient, a
brief description of the PHI disclosed, and a brief statement of purpose or
a copy of the written request.
Pryv platform implemented
Each §528(b)(2) field has a Pryv source (date / name / PHI
description / purpose) — see the §164.528 parent row for the
mapping. The pre-computed accounting report pattern (storing
results on a dedicated stream) keeps the §528 response window
tractable.
HDS facilitated USCH
Each §528(b)(2) field has an audit-log source — date, recipient, PHI
description and purpose — as mapped in the parent accounting row. HDS
operates the audit log that supplies these fields across both regions.
The audit log is included verbatim in every app-portability backup
(`audit_logs.json`), so individuals receive the raw §528 source data
alongside their PHI in a single self-service download.
detail
Pre-computing per-subject accounting reports and storing them on a
dedicated stream keeps the §528 response window tractable. Compiling and
delivering the accounting is the covered entity's process. The
app-portability tool ships the unfiltered audit-event stream (with
timestamps, requesting access tokens, methods invoked) — sufficient
source material for the covered entity to assemble the formal
§528(b) accounting.
- doc: https://demo-portability.datasafe.dev
- doc: https://portability.hds.ngo
- 🔒 hipaa/procedures/accounting-of-disclosures available on request
Implementer
covered-entity documented
Compile each accounting entry's required fields from the audit log and
your records.
individual facilitated
You receive an accounting containing the §528(b) fields.
business-associate documented
📄 baa
Provide the covered entity with the disclosure details you hold.
164.504(e) Organizational requirements — business associate contracts draft
A covered entity may permit a business associate to create, receive,
maintain or transmit PHI on its behalf only with satisfactory assurances
via a written contract meeting the BAA content requirements of
§164.504(e)(2).
Pryv platform facilitated
The §164.504(e) BAA content
is contractual. Pryv-side support for executing the contract
terms: BA access tagged with `clientData.baa_id` +
`clientData.role = "business_associate"`, scope narrowed to
subjects + streams covered by the BAA, audit-log accountability
for every action under the BA access.
HDS facilitated USCH
HDS offers a BAA template and the technical means to execute its terms: a
business-associate access tagged with the contract reference and role,
scoped to the covered subjects and streams, with full audit-log
accountability. The contract content itself is contractual.
detail
HDS signs BAAs as a business associate and flows obligations down to its
own subcontractors. The access tags and audit log support enforcement and
evidence of the §164.504(e) terms.
- 🔒 hipaa/registers/baa-register available on request
Implementer
covered-entity documented
📄 baa
Execute a BAA meeting §164.504(e)(2) before any business associate
handles PHI.
business-associate documented
📄 baa
Sign the BAA and execute back-to-back subcontractor agreements with
downstream processors.
individual out-of-scope
164.504(g) Organizational requirements — group health plans draft
A group health plan may disclose PHI to a plan sponsor only after receiving
certification that the plan documents have been amended to incorporate the
§164.504(f) restrictions.
Pryv platform out-of-scope
Group-health-plan / plan-sponsor arrangements are organizational
/ contractual. No software role.
HDS out-of-scope USCH
Group health plan and plan-sponsor arrangements are organizational and
contractual, with no software role. HDS provides no technical control
specific to this requirement.
detail
The plan-document amendment and certification are entirely the covered
entity's contractual obligations.
Implementer
covered-entity documented
Obtain the plan-sponsor certification before disclosing PHI to the
sponsor.
individual out-of-scope
164.502(j) Disclosures by whistleblowers and workforce-member crime victims draft
A workforce member's or business associate's disclosure of PHI to a
regulatory, oversight or law-enforcement authority is not a violation where
made in good-faith belief of unlawful conduct and meeting the §502(j)
conditions.
Pryv platform out-of-scope
Whistleblower protections are legal framing. No software role;
the disclosing person's audit-trail evidence under their access
may be cited in subsequent proceedings.
HDS out-of-scope USCH
Whistleblower protection is a legal framing with no software role. The
audit-trail evidence of a disclosing person's access may be cited in
subsequent proceedings, but HDS provides no control specific to this
requirement.
detail
HDS neither enables nor restricts good-faith whistleblower disclosures
beyond ordinary access controls; the protection is a matter of law.
Implementer
covered-entity documented
Recognize the §502(j) protection in your policies and non-retaliation
handling.
business-associate documented
📄 baa
Understand the §502(j) good-faith disclosure protection.
individual out-of-scope