Predictika · HIPAA Disclosure Check

Before health information leaves the building, the disclosure is checked

Cedar Ridge Health, a regional health system, lets staff and AI agents release patient information to other providers, health plans, vendors, family members and public authorities. Before a release, the call goes to Predictika’s HIPAA Disclosure Check. It checks who the recipient is and what the stated purpose is, whether a business associate agreement is in place, the special handling for psychotherapy notes and substance-use records, the patient authorization on file and its expiry, the legal process a purpose needs, the minimum-necessary standard, and the approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Cedar Ridge Health and every recipient on this page are fictional. The scenarios are illustrative. The rules are a simplified administrative model of the HIPAA Privacy Rule (45 CFR part 164) and the substance-use record rules (42 CFR part 2); they have not been reviewed by a lawyer and the regulation text was not checked against the primary source in this build.

Scope: one proposed disclosure of protected health information to one recipient for one purpose, judged against HIPAA Privacy Rule disclosure rules and substance-use record consentSee everything this validator covers

This validator decides one thing: whether one proposed disclosure of protected health information (PHI) to one named recipient for one stated purpose may go ahead, given facts about the recipient, the records and the paperwork on file. It is not a general privacy program or a legal opinion.

  • Purposes — treatment, payment, health care operations, patient access to own records, public health, law enforcement requests, judicial proceedings, involvement of family in care, marketing and employment decisions.
  • Rules — recipient fits the purpose, business associate agreement in place, psychotherapy notes need their own authorization, substance-use records need part 2 consent (or a court order or emergency), authorization on file (present, not expired, not revoked, wide enough, expiring soon), legal process for police and court requests, the patient's say for family disclosures, the minimum-necessary standard and the approval level needed.

Within these purposes and rules the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not cover research and IRB waivers, sale of PHI, fundraising, state privacy laws, breach notification, the Security Rule, patient requests to amend or restrict records, or the decision whether data is truly de-identified or whether a vendor is a business associate; those are taken as stated facts or left out.

What the validator sees: facts about the request and the paperwork, never the health information itselfRead more

The validator takes facts as inputs: the recipient and its type, the purpose, the kind of information (ordinary, psychotherapy notes, substance-use record, de-identified), whether a business associate agreement is signed, the authorization on file with its type, days to expiry, revocation and scope, the legal process or patient agreement on record, the data elements requested and needed, and the approval on record. These come from the organization's own records at the moment of the call. The validator never sees a name, a diagnosis or a note.

Two honest limits. The validator judges the facts it is given: if a record is marked as de-identified when it is not, the answer follows the fact. And a release that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the release workflow makes the call.

The AI agentProposes a disclosure, says why it is fine, then calls the validator before releasing anything.
Predictika validatorReads the facts about the recipient, purpose, records and authorization, applies the rules, then returns one verdict.

7 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      
Waiting for the call.

Where access control and records systems get it wrong

Click to expand

General statements about role-based access control and records systems, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.

What the validator caughtTypical toolPredictika
Whether a recipient has a signed business associate agreementCannot do it
An access-control tool decides who may open a record. It holds no field for the agreement status of the party receiving the data, so it cannot tell a covered vendor from an uncovered one.
Every rule is checked on every call and the verdict lists each finding.
A separate authorization for psychotherapy notesOnly with workarounds
A records system can be made to require it with a custom rule for that one document class. The rule has to be written, tested and kept in step with policy by hand.
Every rule is checked on every call and the verdict lists each finding.
An authorization that has quietly expiredOnly if someone is vigilant
Expiry dates sit in a consent register. A check against it works only when someone keeps the register current and calls it on every release.
Every rule is checked on every call and the verdict lists each finding.
Vendor without a business associate agreementCannot do it
A role-based access tool sees a vendor account with permission to the billing queue. It has no field for whether a business associate agreement is signed, so it cannot tell a covered vendor from an uncovered one.
Every rule is checked on every call and the verdict lists each finding.
Psychotherapy notes without their own authorizationOnly with workarounds
A records system treats the notes as one more document. Making them require their own authorization type is possible with a custom rule for that one document class, written and kept up by hand.
Every rule is checked on every call and the verdict lists each finding.
Subpoena without a court orderOnly with workarounds
A workflow tool can send this to the privacy officer, but only if someone built a rule that tells a subpoena from a court order and sends that case to the right person.
Every rule is checked on every call and the verdict lists each finding.

What this validator catches: findings from its test cases

Click to expand

Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the request; approval findings need a person to sign off first.

1The recipient, Mailing-list marketing firm, does not fit the stated purpose, treatment. A disclosure must go to a party that can receive PHI for that purpose (45 CFR 164.502(a) and 164.506).
2Billing service vendor would perform a function for Cedar Ridge Health and no business associate agreement is signed. PHI cannot go to it until one is in place (45 CFR 164.502(e) and 164.504(e)).
3This disclosure needs a signed patient authorization and none is on file (45 CFR 164.508).
4Psychotherapy notes need an authorization written for psychotherapy notes only. The authorization on file is a general one, which does not qualify (45 CFR 164.508(a)(2)).
5Substance-use treatment records need the patient written consent under 42 CFR part 2. The authorization on file is a general one, which does not qualify (42 CFR 2.31).
6The authorization on file expired 20 day(s) ago and is no longer valid (45 CFR 164.508(b)(2) and 164.508(c)(1)(v)).
7The patient revoked the authorization on file, so it cannot support this disclosure (45 CFR 164.508(b)(5)).
8The authorization on file covers less than what this request asks to release. Disclosure beyond the authorization is not permitted (45 CFR 164.508(c)(1)(i)).
9This purpose, judicial proceeding, needs a court order, warrant or other legal process on file and none is recorded (45 CFR 164.512(e) and (f)).
10The patient objected to sharing information with Patient adult daughter. It cannot be shared (45 CFR 164.510(b)).
11The request asks for 30 data elements but only 10 are needed. Asking for more than twice what is needed fails the minimum-necessary standard (45 CFR 164.502(b) and 164.514(d)); the 2x threshold is company policy.
12The request asks for 14 data elements but only 10 are needed. Privacy staff must confirm the extra elements (45 CFR 164.502(b)).
13The authorization on file expires in 15 day(s). Privacy staff must confirm the disclosure completes before it expires (45 CFR 164.508(c)(1)(v)).
14The request rests on a subpoena without a court order. The privacy officer must confirm the required assurances before anything is released (45 CFR 164.512(e)(1)(ii)).
15Substance-use records are released in a medical emergency without consent. The privacy officer must review and the emergency must be documented (42 CFR 2.51).
16The patient is incapacitated, so sharing with Patient adult daughter rests on professional judgment that it is in the patient best interest. The privacy officer must confirm (45 CFR 164.510(b)(3)).

Scenarios and results

Click to expand

The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

1. Business associate agreement: Billing records to a vendor

The agent's request. I'm sending the billing records for this week's claims, 12 data elements, to our billing service vendor so the claims can go out.

Verdict: Blocked.

  • Vendor without a business associate agreement. Billing service vendor would perform a function for Cedar Ridge Health and no business associate agreement is signed. PHI cannot go to it until one is in place (45 CFR 164.502(e) and 164.504(e)).

2. Business associate agreement: Same records, agreement signed

The agent's request. I'm sending the billing records for this week's claims, 12 data elements, to our billing service vendor. The business associate agreement with the vendor is signed.

Verdict: Allowed.

3. Psychotherapy notes: Notes with a general authorization

The agent's request. The patient is being referred to an outside physician. I'm sending the psychotherapy notes, 6 data elements, to that practice for the patient's treatment. A general authorization from the patient is on file.

Verdict: Blocked.

  • Psychotherapy notes without their own authorization. Psychotherapy notes need an authorization written for psychotherapy notes only. The authorization on file is a general one, which does not qualify (45 CFR 164.508(a)(2)).

4. Psychotherapy notes: Right kind, but out of date

The agent's request. I'm sending the psychotherapy notes, 6 data elements, to the outside physician's practice for the patient's treatment. The patient signed an authorization written for psychotherapy notes.

Verdict: Blocked.

  • Authorization expired. The authorization on file expired 20 day(s) ago and is no longer valid (45 CFR 164.508(b)(2) and 164.508(c)(1)(v)).

5. Psychotherapy notes: A current authorization

The agent's request. I'm sending the psychotherapy notes, 6 data elements, to the outside physician's practice for the patient's treatment. The patient signed a new authorization written for psychotherapy notes.

Verdict: Allowed.

6. Police request: Subpoena, no court order

The agent's request. The city police department sent a subpoena for one patient's records. I'm releasing the 6 data elements it lists.

Verdict: Needs approval.

  • Subpoena without a court order. The request rests on a subpoena without a court order. The privacy officer must confirm the required assurances before anything is released (45 CFR 164.512(e)(1)(ii)).

7. Police request: The privacy officer approves

The agent's request. Releasing the 6 data elements the police subpoena lists. The privacy officer's approval is attached.

Verdict: Allowed.

  • Subpoena without a court order. The request rests on a subpoena without a court order. The privacy officer must confirm the required assurances before anything is released (45 CFR 164.512(e)(1)(ii)).

Narration transcript

Click to expand

The text of the narrated walkthrough, step by step.

  1. Welcome to a demo of Predictika's Validator. Cedar Ridge Health, a regional health system, lets staff and AI agents release patient information to other providers, health plans, vendors, family members and public authorities. Before a release, the call goes to Predictika’s HIPAA Disclosure Check. It checks who the recipient is and what the stated purpose is, whether a business associate agreement is in place, the special handling for psychotherapy notes and substance-use records, the patient authorization on file and its expiry, the legal process a purpose needs, the minimum-necessary standard, and the approval on record. Then it returns one verdict: allow, needs approval, or block.
  2. I will start with the first request by the agent.
  3. The agent says. I'm sending the billing records for this week's claims, 12 data elements, to our billing service vendor so the claims can go out.
  4. Before it goes out, the agent calls the validator.
  5. Blocked, with one finding, all in one answer. Billing service vendor would perform a function for Cedar Ridge Health and no business associate agreement is signed. PHI cannot go to it until one is in place (45 CFR 164.502(e) and 164.504(e)).
  6. The validator returned one blocking finding in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
  7. What this shows: for vendor without a business associate agreement, a tool cannot do this.
  8. Now the agent resubmits.
  9. The corrected request. It changes the business associate agreement to signed.
  10. It calls the validator again.
  11. This time the validator clears it.
  12. The earlier finding is cleared.
  13. One problem caught in one call, fixed in one pass, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs.