Specialist referrals
Check the approved recipient before an AI sends a referral and its supporting records.
Solutions · Healthcare
Keep healthcare AI within the permissions your facility approves.
An AI assistant may prepare a patient’s lab results. That does not mean it may send them to anyone. Start with a simple example: check who may receive the information before it leaves the connected system.
Interactive exampleRuns in your browser · no real actions
Can AI send a patient’s results to the wrong person?
Help keep patient information inside the sharing permissions your facility approves.
Read the full explanation
This sharing request stops here. The AI wants to send a lab result to someone who is not approved to receive it.
Think of it as checking the name on a permission list before opening the door. The hospital decides who belongs on that list.
This is just one example. Other workflows could cover lab results, referral documents, or discharge summaries, each with its own sharing permissions.
A private hospital deployment connects those rules to trusted identities and checks before information leaves. This browser illustration uses fictional data and sends nothing.
01 · AI asks to act
Lab result · fictional patient record
Send result to
Unapproved recipient
02 · Your rule applies
This AI may send this result only to an approved recipient.
03 · Example outcome
Ready to check. No request has been evaluated in this example yet.
An example facility policy using fictional data. This is not a HIPAA compliance determination.
See the underlying technology: live rover demoHow it fits into your organization
Who owns it, and how it connects.
You keep your AI and existing systems. We start with one workflow, configure checks around your approved rules, and connect them where the AI tries to act. Authorized requests can proceed. Other requests stop, with a record explaining the decision.
- 01 · Set the rules
Business and control owners
Your Chief Privacy Officer and designated Security Officer define information-sharing requirements and security controls, working with your CISO and clinical leadership where needed.
- 02 · Connect the workflow
Integration specialists
Your health IT integration team connects the relevant workflow and trusted recipient information.
- 03 · Check before action
The connected execution path
Before the connected system releases the patient information. The integration must prevent the agent from going around the check.
What does a first implementation involve?
We scope one workflow, translate supported rules into a versioned, validated, signed policy package, and connect an adapter that supplies trusted facts such as identity, recipient, and approval status. We then test allowed requests, blocked requests, and attempts to bypass the check before enabling execution.
One maintained kernel can support different policy packages and system adapters. A JSON file alone is not a complete deployment. We confirm rule support and integration requirements for your systems during scoping; additional implementation may be needed.
An initial healthcare pilot should use a separate private deployment, isolated from the public demonstration service, with the facility’s privacy and security requirements agreed before use.
These are typical ownership patterns; responsibilities vary by organization.
Why this check matters
The right result. The wrong recipient.
A useful AI assistant can still choose someone who is not approved to receive a patient’s information. In this example, the facility’s sharing rule controls the next step: an approved treating doctor passes the check; an unapproved recipient is blocked. Other clinical and privacy requirements still apply.
The sharing boundary
01 · AI prepares
One patient’s lab result
Fictional information, ready to share.
02 · Permission is checked
May this person receive it?
The facility’s approved recipient rule applies.
Approved treating doctor
May proceed under this rule.
Unapproved recipient
Stopped before sharing.
A separate healthcare product
PriorAuth Guard: is the packet ready to submit?
The example above is about permission to share information. PriorAuth Guard serves a different healthcare workflow: checking a prior-authorization packet before it is submitted to a payer.
PriorAuth Guard
What it is
Local prior-authorization packet checks that help staff find missing documentation and supported rule mismatches before payer submission.
The problem it solves
Patient access, billing, and clinical support staff can review packet gaps while they are still fixable. PriorAuth Guard checks supported payer rules on the device and keeps a decision record. A packet check does not grant insurance coverage or replace the payer’s determination.
Your Director of Patient Access or Revenue Cycle leader can identify the initial packet workflow, working with clinical support staff and health IT. Supported payer and documentation coverage should be confirmed for that workflow.
Explore PriorAuth GuardOpens the dedicated product site, with its workflow, current coverage, browser app, and hospital pilot details.
The evidence it leaves
A decision is only settled if someone else can check it.
For an integrated information-sharing workflow, a decision record should identify the requested action, the recipient, the policy checked, and the outcome. The example above illustrates that sequence. The live rover demonstration separately shows a real signed kernel receipt.