Healthcare AI Agent Portability

Regulatory Framework

HIPAA's Privacy Rule (45 CFR Part 164 Subpart E) governs uses and disclosures of protected health information; the Security Rule (Subpart C) imposes administrative, physical, and technical safeguards including access control, audit controls, integrity, person-or-entity authentication, and transmission security. Any AI agent that touches PHI is a constituent of the covered entity's or business associate's compliance posture and must inherit those safeguards by construction.

FDA 21 CFR Part 11 governs electronic records and electronic signatures for any system whose records substitute for paper under predicate FDA regulations. Clinical AI agents that contribute to records used in FDA-regulated processes must produce time-stamped audit trails, support electronic signatures with the required components, and demonstrate validation. The FDA's 2023 guidance on Predetermined Change Control Plans (PCCP) for AI/ML-enabled Software as a Medical Device formalizes how a manufacturer may pre-specify modifications and a Modification Protocol that govern post-market updates without re-clearance, provided the modifications stay inside the declared envelope. The PCCP requires the device to carry, in inspectable form, the description of the planned changes and the methods used to implement them.

ONC's Health IT Certification Program, under the 21st Century Cures Act and the ONC HTI-1 final rule, certifies health IT modules including decision-support interventions and requires Decision Support Intervention transparency attributes (the so-called source attributes), bias-evaluation summaries, and risk-management practices. USCDI v3 specifies the data classes and elements that a certified module must support. FHIR R4 is the wire-level standard for exchanging those classes; CDS Hooks defines the synchronous invocation pattern for decision support; IHE Profiles such as XDS, XCA, and PIX/PDQ define cross-enterprise document and identity workflows. ISO 13485 governs the quality management system of any organization placing a medical device on the market, including the design controls under which a clinical AI agent is produced.

The aggregate effect is that a healthcare AI agent is simultaneously a HIPAA covered-data processor, a Part 11 electronic-records producer, a SaMD subject to PCCP-bounded change control, an ONC-certified DSI exposing source attributes, a FHIR R4 client, a CDS Hooks responder, and a controlled output of an ISO 13485 quality system. Portability of such an agent is portability of all of these obligations together.

Architectural Requirement

Translating the regulatory perimeter into architecture produces a structural requirement: every agent must carry, as intrinsic typed fields, the governance under which it operates, the memory that constitutes its clinical knowledge and patient context, the lineage that records its decisions and data accesses, the execution eligibility that determines whether it may act in the present clinical context, the change-control envelope that bounds its post-market modification, and the certification attributes that ONC and FDA inspections will demand. These fields must be platform-independent, because the platform of record for a healthcare agent is not stable over the agent's lifecycle: an agent validated at one institution must be transferable to another, an agent deployed on one vendor's runtime must be migratable to another vendor's runtime without losing its compliance history, and an agent revised under a PCCP must remain inspectable across the revision boundary.

The architecture must additionally support the FHIR R4 data model, CDS Hooks invocation contracts, USCDI v3 data classes, and IHE Profile workflows as binding interfaces of the agent rather than as platform features. It must support HIPAA minimum-necessary determinations as queries against the agent's governance field rather than as platform configurations. It must support Part 11 audit retrieval as a query against the agent's lineage rather than as a platform log extraction. It must support ONC DSI source-attribute disclosure as inspection of typed fields. The architectural requirement is therefore that the agent is a first-class persistent object with structural properties that satisfy the regulatory framework directly, not derivatively through the platform that hosts it.

Why Procedural Compliance Fails

The current procedural pattern is to satisfy each regulatory instrument separately and to compose the satisfactions into an aggregate posture. HIPAA safeguards are handled by the platform's identity and access management. Part 11 audit trails are emitted to the platform's logging tier. SaMD documentation is maintained in the manufacturer's quality system. ONC DSI source attributes are surfaced in user-interface tooltips. FHIR exchange is mediated by the platform's interoperability gateway. CDS Hooks responses are produced by the platform's invocation framework. The agent itself is a vendor-specific bundle of weights, prompts, configuration, and orchestration glue whose compliance properties are inherited from the platform rather than carried by the agent.

This pattern fails portability on every axis. First, agent migration becomes agent reimplementation. Moving a sepsis detection agent from one vendor's platform to another requires reconstructing the governance, re-emitting the audit trail in a new format, re-mapping the FHIR access patterns, re-binding the CDS Hooks responses, and reproducing the ONC DSI source attributes inside the new platform's user interface. The accumulated clinical experience, validation history, and PCCP envelope of the original deployment cannot be transferred because they exist as platform state rather than as agent state.

Second, cross-institutional sharing is foreclosed. A sepsis agent validated at one academic medical center cannot be transferred to a community hospital running a different vendor without reimplementation, even though the clinical content and the FDA clearance are unchanged. Procedural composition makes the agent a function of its host, so the host change is a re-clearance event in practice if not in regulation.

Third, FDA PCCP inspections require the manufacturer to demonstrate that post-market modifications stayed inside the declared envelope. When the agent's lineage is fragmented across the host platform's logging tier, the modification history is reconstructed from logs whose retention, access, and integrity properties are platform-specific. A PCCP modification protocol that was validated against one platform's logging guarantees does not automatically hold against another's. ONC DSI source-attribute disclosure faces the same problem: the attributes are platform-rendered rather than agent-borne, and an agent's certification at one vendor does not transfer with the agent.

Fourth, HIPAA business-associate diligence has to be repeated per platform because the safeguards inhere in the platform, not in the agent. Fifth, IHE cross-enterprise profiles assume a stable identity for the participating actor, but a vendor-bound agent does not have a stable identity across enterprises; it has a series of platform-local re-incarnations whose lineage is broken at every boundary. Sixth, ISO 13485 design controls assume traceability from requirement through implementation to deployed device; when the deployed device is a platform-bound bundle, the traceability ends at the platform boundary.

What the AQ Primitive Provides

The canonical agent schema defines six typed, inspectable fields that every healthcare agent carries. The governance field encodes the HIPAA constraints applicable to the agent's PHI access, the institutional policies under which it was deployed, the FDA-cleared indications and contraindications, the IRB protocols where research is involved, the ONC certification status and DSI source attributes, the ISO 13485 design-history file references, and the jurisdictional overrides that vary across deployments. The memory field carries the agent's clinical knowledge, parameterized weights or rules, and per-patient context bound to the FHIR R4 resource model and USCDI v3 classes. The lineage field is an append-only, time-stamped, signed record of every clinical decision, every PHI access, every FHIR read or write, every CDS Hooks response, and every state mutation, with sufficient detail to satisfy Part 11 audit-trail requirements and ONC DSI transparency obligations.

The execution eligibility field expresses, as a typed predicate, whether the agent is authorized to act in the current clinical context: is the patient inside the cleared indication, is the requesting clinician within the agent's deployment scope, is the institutional policy field consistent with the active workflow, is the PCCP envelope still binding for the current model version. The change-control field records the FDA PCCP envelope, the modification protocol, and the history of post-market modifications with their evaluation evidence, so that the agent itself carries the documentation FDA inspections require. The certification field carries ONC HTI-1 attributes, USCDI v3 conformance assertions, FHIR R4 capability statements, CDS Hooks service descriptors, and the IHE actor-and-transaction declarations the agent supports.

Portability becomes a structural operation. When the agent moves from platform A to platform B, the six fields move with it. The receiving platform validates the governance against its own policy surface, inspects the lineage for Part 11 conformance, evaluates the execution eligibility against its own workflow context, and resumes operation. The clinical knowledge in the memory field is not lost. The validation history in the lineage field is not discarded. The PCCP envelope in the change-control field continues to bind post-market modifications across the migration. The ONC certification attributes in the certification field are inspectable by the receiving institution's compliance officers using the same tools they used at the prior site.

Cross-institutional sharing becomes structurally feasible. A sepsis detection agent validated at one institution carries its validation history, its PCCP envelope, its FDA-cleared indications, and its ONC certification attributes inside its own fields. A receiving institution evaluates the agent against its own governance by inspecting the canonical fields, not by reverse-engineering platform-specific telemetry. IHE cross-enterprise workflows acquire a stable agent identity because the agent's identity is intrinsic to its schema rather than assigned by the host.

Compliance Mapping

The canonical fields map directly onto the regulatory instruments. HIPAA Privacy and Security Rules map to the governance field's PHI-access constraints and to the lineage field's audit controls; minimum-necessary determinations are queries against governance. FDA 21 CFR Part 11 audit-trail and electronic-signature requirements are satisfied by the lineage field's append-only, time-stamped, signed structure; Part 11 retention obligations map to the substrate's retention on the agent object. The FDA AI/ML SaMD PCCP guidance maps to the change-control field, which carries the predetermined change envelope, the modification protocol, and the modification history as inspectable artifacts of the agent itself rather than of the manufacturer's external quality system.

ONC Health IT Certification, including HTI-1 DSI transparency, maps to the certification and governance fields, where the source attributes, intervention risk classifications, and feedback-mechanism descriptors are typed values rather than user-interface artifacts. USCDI v3 conformance maps to the memory field's bound resource model and to the certification field's conformance assertions. FHIR R4 capability statements and CDS Hooks service descriptors are part of the certification field; the agent's interface contract travels with it.

IHE Profiles such as XDS for cross-enterprise document sharing, XCA for cross-community access, and PIX/PDQ for patient identity rely on stable actor identities and well-formed transaction logs; the canonical agent schema supplies the stable actor identity through the governance field and the well-formed transaction logs through the lineage field. ISO 13485 design controls map to the change-control and governance fields, where the agent carries traceable references to its design-history file, its risk-management file, and its quality-system records. The aggregate effect is that compliance becomes a property of the agent's structure rather than a property of the agent's hosting environment.

Adoption Pathway

Adoption begins with new-build agents rather than retrofits. An institution issues procurement requirements that mandate the canonical agent schema for any clinical AI agent introduced after a stated date. Vendors that conform deliver agents whose six fields are inspectable by the institution's compliance, security, and clinical-validation teams using a single uniform tool surface. Vendors that do not conform either adopt the schema or are excluded from new procurement. The first generation of canonical-schema agents establishes the inspection tooling, the FHIR R4 binding patterns, the CDS Hooks descriptors, and the lineage retention policies that subsequent generations inherit.

The second stage extends the schema to high-value retrofits. Sepsis detection, deterioration prediction, radiology triage, and similar agents whose validation cost is high are migrated onto the canonical schema by extracting their governance, memory, and lineage from the host platform and re-binding them as canonical fields. The retrofit cost is justified by the resulting portability: a retrofitted agent is no longer captive to its original vendor and can be migrated, shared with affiliated institutions, or rehosted under a different ONC-certified module without re-clearance.

The third stage formalizes cross-institutional sharing. Health systems, research consortia, and public-health agencies establish exchanges in which canonical-schema agents are transferred among participants, validated against the recipient's governance, and operated under the recipient's PCCP envelope where the FDA framework permits site transfer of cleared SaMD. The exchange's contractual layer is thin because the structural compliance properties of the agents are carried in their schemas; legal review focuses on the governance field overlay and the lineage field retention policy rather than on full agent reimplementation. At maturity, the canonical agent schema is the unit of clinical AI portability the regulatory framework already implicitly requires, and procurement, deployment, and oversight all operate against the agent's intrinsic structure rather than against the accidents of the platform that built it.