1. Regulatory Framework

Healthcare AI agents operate inside a dense regulatory perimeter, and each instrument imposes obligations on the agent itself rather than on the platform that happens to host it. The HIPAA Privacy and Security Rules govern what protected health information an agent may hold, disclose, and act upon, and require an accounting of disclosures that an agent must be able to produce. FDA 21 CFR Part 11 governs electronic records and electronic signatures, requiring that records of an agent's actions be attributable, contemporaneous, and tamper evident. The FDA's framework for AI and machine learning Software as a Medical Device, including the Predetermined Change Control Plan approach, expects that an agent which revises its own behavior does so along pre-authorized pathways with a recorded history of every change. The ONC Health IT Certification criteria, the United States Core Data for Interoperability for the clinical data classes a certified system must understand, FHIR for clinical data exchange, CDS Hooks for decision-support invocation, and IHE Profiles for cross-enterprise workflows together define what a healthcare agent must know and how it must interact. ISO 13485 medical-device quality-system obligations extend across the product lifecycle.

The convergent expectation across these regimes is that a healthcare agent must carry, as evidence, what it knows, what it is permitted to do, what it has done, and how it has been revised. Auditors and accreditation reviewers are not satisfied by a platform's assertion that controls existed; they expect the agent to carry the evidentiary properties of a regulated artifact, and to carry them when the agent crosses an institutional boundary.

2. Architectural Requirement

The architectural requirement that follows is a healthcare agent defined by structural fields rather than by platform conventions. The agent must carry, as embedded fields, the properties the regulatory framework demands evidence of. Under the Agent Schema disclosed in United States Patent Application 19/452,651, those properties map onto six canonical fields. The intent field encodes the clinical objective the agent pursues, such as surfacing a sepsis-risk alert or reconciling a medication list, as a semantic goal rather than a procedure. The context block records trust scope, originating institution, role classification, and deployment constraints relevant to which policies apply. The memory field retains clinical reasoning traces, prior evaluations, and validation outcomes as appended, auditable entries embedded in the agent rather than held in an external log. The policy reference field identifies the governing constraints, the HIPAA minimum-necessary scope, the disclosure rules, and the decision thresholds under which the agent may act. The mutation descriptor field defines the pre-authorized pathways along which the agent's behavior may be revised, which is the structural counterpart of the FDA Predetermined Change Control expectation. The lineage field references the agent's semantic ancestors, forming a traceable provenance graph across revisions and transfers.

The architecture must support portability across institutions, because clinical and operational realities move agents between hospital systems, reference laboratories, payer networks, and specialty providers. An agent reconciling medications at a referring hospital must carry its complete state into the receiving facility's system without losing governance, memory, or lineage at the boundary. The architecture must support stateless revalidation, because the receiving institution cannot be assumed to share the originating institution's session state, runtime, or orchestration layer. And the architecture must support governed self-revision, because adaptive clinical AI changes its behavior over time and each change carries regulatory consequence that demands a structural, not procedural, control.

3. Why Platform-Coupled Approaches Fail

The approaches in widespread use today do not satisfy the requirement. The dominant pattern is platform-resident agent state: a vendor's EHR or clinical-AI platform holds the agent's memory, governance, and audit trail in session-scoped state and application logic, and the agent is a runtime process inside that platform. When the agent must move to another institution, it is reconstructed from exports, with clinical memory truncated, governance reset to the receiving platform's model, and provenance restarted. The reconstructed agent satisfies neither the regulator's evidentiary expectation nor the receiving institution's continuity needs.

A second pattern is data-model standardization through FHIR resources and USCDI data classes. These standards are essential for exchanging clinical data, and they normalize what a patient record contains. They do not, however, define the agent's governing policy, its pre-authorized change pathways, its embedded reasoning memory, or its provenance across revisions. A FHIR bundle describes a medication list; it does not describe the reconciliation agent's policy scope, its mutation history, or its lineage. The data-model standards are necessary but insufficient because they standardize the record, not the agent.

A third pattern is audit-by-database: each platform keeps logs of an agent's actions, and the institution stitches those logs together at audit time. The pattern fails on cross-platform continuity, because each log is in its own format under its own service identity; on tamper evidence, because conventional database logs can be rewritten by a sufficiently privileged administrator; and on attributable authorship, because entries are signed by service accounts rather than under the authority and policy in force at the time of the action. When a HIPAA auditor or an FDA reviewer asks for the credentialed history of an agent's decisions and self-revisions, the institution produces logs, not lineage.

The structural failure underlying all three patterns is the same: the agent is defined by the platform, and the regulatory framework expects an agent defined by fields that survive the platform. No procedural overlay closes that gap.

4. The Agent Schema Primitive

The Agent Schema, disclosed in United States Patent Application 19/452,651, defines a semantic agent object as a structurally self-validating data object rather than a runtime process. It specifies six canonical fields (intent, context, memory, policy, mutation, and lineage) that collectively encode an agent's identity, operational constraints, and evolutionary traceability. A receiving node determines whether an agent object is structurally coherent based on the presence of these fields, and whether the present fields are structurally compatible based on rules that govern whether they may coexist. Critically, that determination is made based only on information embedded within the agent object, which is exactly the property a cross-institutional healthcare transfer requires: the receiving facility validates the agent from the object alone, without the originating platform's session state.

The schema supports partial agents. A healthcare agent need not carry all six fields to be structurally valid; an object satisfying a minimum threshold of at least two coherent canonical fields remains valid, with missing fields resolved through deterministic, policy-bound scaffolding whose outcomes are recorded in the memory field. This matters in practice, because a referral agent may legitimately carry context, policy, and lineage while deferring intent resolution to the receiving institution, and a reflective audit agent may carry only memory and lineage. Field-based role typing follows from composition: an agent carrying intent, memory, and a mutation descriptor is structurally a mutator agent capable of governed self-revision, while an agent carrying context, policy, and memory without a mutation descriptor is an evaluator that observes and applies thresholds without independently initiating change. Roles are not externally assigned; they are read from structure.

Governed self-revision is load-bearing for adaptive clinical AI. Mutation is evaluated against the agent's own mutation descriptor field in conjunction with its policy reference field and context block, so an agent may only revise its behavior along pre-authorized pathways, the memory update recording the change is mandatory, and the derived agent's lineage field references its predecessor without overwriting prior lineage. Where a mutation descriptor is absent, the schema treats the agent as immutable until authorization is explicitly granted, which prevents uncontrolled drift in a clinical setting. Serialization preserves field boundaries and validation metadata so the agent can be transmitted and revalidated across stateless and heterogeneous environments, and the specification notes that integrity verification may optionally bind field contents and lineage references to verifiable signatures or hashes, supporting the tamper-evident provenance that Part 11 expects, without coupling the schema to any specific cryptographic implementation.

5. Compliance Mapping

The structural properties of the Agent Schema map directly onto the regulatory framework. HIPAA minimum-necessary and disclosure-accounting obligations are addressed by the policy reference field, which scopes what protected health information the agent may hold and disclose, and by the memory field, which records each evaluation and disclosure as an appended, auditable trace embedded in the agent. FDA 21 CFR Part 11 attributable, tamper-evident electronic records are addressed because every action and revision is recorded in the memory field under the policy and lineage in force at the time, and may optionally be cryptographically bound. The FDA Predetermined Change Control expectation for adaptive AI is addressed by the mutation descriptor field, which confines self-revision to pre-authorized pathways, and by the lineage field, which preserves a complete, non-overwriting history of every revision.

ONC certification, USCDI, FHIR, CDS Hooks, and IHE expectations are addressed because the agent's clinical interactions are governed by its policy field and recorded in its memory field, while the underlying clinical data continues to flow through FHIR and USCDI; the schema is the agent contract that rides above the data-exchange standards rather than competing with them. ISO 13485 lifecycle-quality obligations are addressed because the lineage graph provides a traceable, auditable record of the agent's evolution across its service life and across institutional boundaries. Each regulatory expectation maps onto a specific structural property of the agent object, and the institution's defensive posture is stronger than any platform-resident definition can produce, because the evidence travels with the agent.

6. Embodiments and Deployment Options

The application admits several embodiments. In a referral embodiment, a medication-reconciliation agent is serialized at a referring hospital with its intent, context, policy, memory, and lineage fields populated, transferred with a patient referral, and revalidated structurally at the receiving facility from the object alone; the receiving facility's node confirms field coherence, applies its own policy scaffolding where the referring policy does not resolve locally, and records the resolution in memory. In a health-information-exchange embodiment, partial agents carrying only context, policy, and lineage propagate across a network of providers as delegate agents that inherit governance scope without initiating clinical action. In a payer-provider embodiment, an evaluator agent carrying context, policy, and memory observes claims-adjacent clinical conditions and applies decision thresholds without independently mutating, while a separate mutator agent performs governed revisions under explicit authorization. In an adaptive-model-update embodiment, a clinical-AI vendor distributes revisions as schema-authorized mutations whose descriptors and lineage entries constitute the Predetermined Change Control evidence trail.

Deployment options scale from a metadata overlay, in which existing platform-resident agents acquire the six canonical fields populated from current EHR, policy, and audit-log sources, to native participation, in which EHR and clinical-AI platforms read and write the canonical fields directly and cross-institution transfer operates through the schema rather than through bespoke export-import logic. The schema is independent of any particular programming language, messaging protocol, storage technology, or cryptographic primitive, so an institution may adopt it without displacing its existing clinical systems.

7. Adoption Pathway

Adoption proceeds in three stages calibrated to an institution's existing EHR, clinical-AI, and health-information-exchange stack. Stage one is canonical-field overlay: existing healthcare agents acquire the six canonical fields as a structured layer over their current platform-specific definitions, populated from the institution's existing policy, audit-log, and clinical-AI sources. The overlay does not replace the platforms; it produces the embedded-lineage and structural-governance records that HIPAA, Part 11, and the FDA change-control framework expect, drawing on data the platforms already hold. Stage two is platform participation: EHR and clinical-AI platforms begin to read and write the canonical fields natively, cross-institution agent transfer begins to operate through the schema and stateless revalidation rather than through export-import reconstruction, and procurement teams require schema participation as a condition of new platform contracts. Stage three is full substrate adoption: every new healthcare agent defaults to canonical-schema definition, legacy agents migrate at refresh points, and the institution's agent population becomes structurally portable across the platform changes and cross-organization referrals that would previously have caused memory truncation and governance reset. At each stage the institution gains evidentiary strength that survives the boundary, which is precisely what platform-resident approaches cannot provide.

8. Disclosure Scope

This article is a public, dated disclosure of how the Agent Schema applies to portable healthcare AI agents. The underlying technology, the canonical six-field semantic agent object, structural validity of full and partial agents, field-based role typing, schema-governed mutation and lineage, and validation based solely on object-embedded information, is disclosed in United States Patent Application 19/452,651. The healthcare regulatory framing, the deployment scenarios, and the adoption pathway described here are application context built on that disclosed technology and are intended to enable a skilled implementer to apply the schema to clinical agent portability. Nothing in this article should be read to disclaim subject matter claimed in United States Patent Application 19/452,651.