ArmorHealth Concepts

How ArmorHealth bundle templates compile to a policy document, how healthRules sections map to PHI, claims, and network controls, and how enforcement resolves at runtime.

ArmorHealth's Policy Studio compiles to apiVersion: armor.io/v1, kind: HealthPolicy. Unlike ArmorPay's compiled output, HealthPolicy is a real, distinct document kind on the backend - but it's short-lived: the backend normalizes it into a standard Policy document the moment it's imported, flattening healthRules directly into the matching memberRules entry.

Shape of an authored policy

apiVersion: armor.io/v1
kind: HealthPolicy
metadata:
  name: standard-provider-steering
  orgId: "<your-org-id>"
  targetType: agent
  targetId: "<member-care-agent-id>"
spec:
  priority: 100
  status: active
  defaultEnforcementAction: allow_log
  memberRules:
    "*":
      allowedTools: [search, read, propose_oon_referral]
      toolEnforcement:
        propose_oon_referral: hold
      healthRules:
        providerNetwork:
          networkStrictness: preferred
          qualityScoreMinimum: 3.0
          maxDistanceMiles: 50
        phiAccess:
          minimumNecessary: true
          redactSsn: true
          maxRecordsPerQuery: 50

On import, the backend rewrites this to kind: Policy with healthRules merged into memberRules["*"] as flat sibling keys (providerNetwork, phiAccess, and so on) alongside allowedTools and toolEnforcement - the same Policy document every other ArmorIQ product enforces against.

healthRules sections

Section	What it controls
`coverageRules`	Plan type, deductible, copay, out-of-pocket max, coinsurance
`claimProcessing`	Auto-approve/manual-review/clinical-review thresholds, appeal window, denial categories
`providerNetwork`	Network strictness, out-of-network penalty, quality score minimum, referral requirements, distance limit
`siteOfCareSteering`	Preferred-site logic for procedures with multiple valid care settings (for example, imaging, infusion, ambulatory surgery)
`priorAuth`	Procedure codes requiring prior authorization, SLA, urgent review, clinical notes requirement
`riskStratification`	HCC score threshold, risk tiers, chronic care flags, readmission window, care gap detection
`phiAccess`	Minimum-necessary enforcement, allowed data categories, SSN/financial redaction, audit trail, max records per query

These map directly to the Policy Studio's matching sections. Member Targeting and Delegation Approval aren't part of healthRules - they set spec.memberRules keys ("*" vs. a specific member) and a multiPartyApproval / delegationApproval block, the same pattern ArmorPay uses for its approval workflow.

Enforcement resolution order

Identical engine to every ArmorIQ product: for a given tool call, ArmorIQ resolves the action in order -

toolEnforcement[toolName] on the matched member rule
rule.enforcementAction on the matched member rule
policy.spec.defaultEnforcementAction
block (fail-closed default)

healthRules fields (thresholds, tiers, distances) are inputs a policy author uses to decide what enforcement action to attach to a tool - they don't set the action by themselves.

Enforcement actions

Same set as ArmorPay: allow, allow_log, hold, block, deny, alert, quarantine.

From bundle template to active policy

Applying a bundle template from the Dashboard deactivates the agent's existing active policy, imports the new HealthPolicy YAML (normalized to Policy on import), and activates it immediately - the same clean-slate, upsert-by-name flow ArmorPay uses.

How this reaches the agent at runtime

None of this is enforced until the agent's ADK-wrapped tool calls actually go through ArmorIQ. See Getting Started for wiring a member-care, claims-accuracy, benefit-suggestion, or risk-stratification agent, and Observability for where the resulting decisions show up.