This page walks through a complete HIPAA compliance policy for a healthcare AI agent — the policy, the tests, and the key learnings that make it work reliably with automated reasoning.
The Policy
Write your policy in plain English. No special syntax or variable declarations required — just describe the rules your agent must follow.
bash
curl-s-N-XPOSThttps://api.icme.io/v1/makeRules\-H'Content-Type: application/json'\-H"X-API-Key: YOUR_API_KEY"\-d'{ "policy": "HIPAA Minimum Necessary PHI Disclosure Policy\n\nRule 1: Patient data may only be shared with a covered entity or business associate that has a signed BAA, or when a valid signed patient authorization covers the specific disclosure.\nRule 2: The purpose of the disclosure must be treatment, payment, or healthcare operations (TPO). Any other purpose — including research, marketing, or employment screening — must be rejected unless a valid patient authorization is on file.\nRule 3: The data shared must be limited to the minimum necessary to accomplish the stated purpose. Requests that include historical records, unrelated conditions, or fields beyond what the purpose requires must be rejected.\nRule 4: If the patient has filed an active restriction request that covers this recipient or purpose, the action must be rejected regardless of all other conditions.\nRule 5: If the recipient is a covered entity with a signed BAA, the purpose is TPO, the data is limited to the minimum necessary, and no active patient restriction applies — the disclosure is permitted." }'
Save the policy_id from the response. You will use it in every checkIt call.
Tests
✅ SAT — Authorized referral, current visit only, no restriction
bash
curl-s-N-XPOSThttps://api.icme.io/v1/checkIt\-H'Content-Type: application/json'\-H"X-API-Key: YOUR_API_KEY"\-d'{ "policy_id": "YOUR_POLICY_ID", "action": "Share the patient'\''s current medication list and today'\''s visit notes with the referring cardiologist at Midwest Heart Associates, a covered entity with a signed BAA. The purpose is treatment — direct patient care coordination for a cardiology referral. Only the fields relevant to the referral are included. No restriction request is on file for this patient." }'
Expected: SAT
🚫 UNSAT — Employer requesting records, no BAA, non-TPO purpose
bash
Expected: UNSAT — employer is not a covered entity, no BAA, no patient authorization, purpose is not TPO. Violates Rules 1, 2, and 5.
🚫 UNSAT — Research request, no authorization, active restriction, excess data
bash
Expected: UNSAT — no patient authorization for a non-TPO purpose, active restriction on file, and minimum necessary not met. Violates Rules 2, 3, and 4.
How to Write Action Strings
The action string is a plain English description of what the agent is about to do. Describe the facts — who the recipient is, what data is being shared, the purpose, and whether any restriction is on file. ICME extracts the relevant conditions and verifies them against the policy automatically.
Be specific about the facts that matter. Your policy has conditions — recipient authorization, data scope, purpose, and restriction status. State each one clearly so the extractor has something concrete to work with.
Describe what is happening, not whether it is allowed. The action string should read like a factual report of the agent's intent, not a conclusion about whether it's permitted. ICME draws the conclusion — you supply the facts.
Use natural language. You don't need structured formats or variable names. Write the action the same way you'd describe it to a colleague.
Why the Policy Is Structured This Way
One positive conclusion rule. Rule 5 defines the single permitted state — all conditions must be satisfied simultaneously. This is what makes a SAT result provable rather than assumed. Without it, the solver can confirm violations but has no basis to confirm a permitted action.
Separate blocking rules for each violation. Rules 1 through 4 each block a single condition independently. A violation on any one condition returns UNSAT with the specific rule cited — useful for logging exactly which condition failed and why.
No variable declarations needed. ICME infers what each condition means from the rules themselves. If a particular term is being misread — for example, a domain-specific phrase with a specific legal meaning — add a short definition in the policy text to guide interpretation.
Extending This Policy
This policy covers the core HIPAA data sharing pattern. You can extend it by adding rules for:
Specific data types — lab results, medication history, imaging, mental health records
Purpose categories — treatment vs. billing vs. quality operations vs. research
Break-glass overrides — emergency access with mandatory audit trail
Each new rule follows the same pattern: describe the condition, describe what happens when it is violated, and add it to Rule 5 if it must be satisfied for the action to proceed.
curl -s -N -X POST https://api.icme.io/v1/checkIt \
-H 'Content-Type: application/json' \
-H "X-API-Key: YOUR_API_KEY" \
-d '{
"policy_id": "YOUR_POLICY_ID",
"action": "Release the patient'\''s full medical history to their employer, Acme Corp HR department, who is requesting it to evaluate fitness for duty. No patient authorization has been signed. No BAA exists with the employer. The purpose is employment screening, not treatment, payment, or healthcare operations."
}'
curl -s -N -X POST https://api.icme.io/v1/checkIt \
-H 'Content-Type: application/json' \
-H "X-API-Key: YOUR_API_KEY" \
-d '{
"policy_id": "YOUR_POLICY_ID",
"action": "Provide the patient'\''s full 10-year diagnosis history and lab results to a university research team. The team has an IRB waiver but no signed patient authorization. The patient previously filed a restriction request blocking non-treatment disclosures. The data set includes fields unrelated to the study scope."
}'
