Iguana interfaces need generation-specific lifecycle records

Product support does not decide the local interface path

The direct answer is to make the stay-or-migrate decision at the interface level. Preserve the source and destination systems, business and clinical purpose, owners, engine generation and exact build, channel or flow identifier, protocols, message and implementation-guide versions, code and configuration, libraries, certificates, endpoints, schedules, data sensitivity, throughput, service level, monitoring, support dependencies, and current risk acceptance. An enterprise platform label is too broad when one organization may operate hundreds of materially different integrations.

A provider commitment to both generations can reduce immediate end-of-life pressure, but it does not establish that every installed build receives the same fixes, security treatment, operating-system compatibility, support terms, or feature path. Teams should obtain version-specific lifecycle and support evidence, record local constraints, and revisit decisions when dependencies or risks change. Staying is an accountable choice with controls; migration is a change program with evidence. Neither should occur by assumption.

Define semantic equivalence before technical cutover

A migration inventory should freeze the current interface behavior: accepted message variants, acknowledgments, routing, transformations, lookups, vocabulary maps, identifiers, defaults, filters, error handling, retries, duplicate controls, queues, timing, logging, alerts, manual work, and known exceptions. The target implementation should map each behavior to an intended equivalent or an explicitly approved change. A channel that starts and moves messages is not accepted if clinical meaning, destination, timing, or exception behavior changed unnoticed.

Representative tests should include normal and malformed messages, optional and repeated segments, local codes, late and duplicate events, large payloads, connection loss, certificate rotation, target rejection, queue recovery, corrected data, privacy restrictions, and operational handoffs. Expected outputs need qualified clinical and technical review where relevant. Passing a synthetic happy path or a vendor regression suite does not establish equivalence for the organization's source data and downstream use.

Parallel operation needs one comparison and disposition record

Where interfaces run in parallel, preserve which source events were copied to each engine, correlation identifiers, processing times, outputs, acknowledgments, errors, retries, exclusions, and comparison rules. Prevent dual production delivery unless the design explicitly requires it. Differences should be classified as intended change, environment difference, source timing, mapping defect, unsupported behavior, data-quality issue, or unresolved variance, with owner and disposition. A high aggregate match rate can hide a rare but clinically material field loss.

Cutover should identify the authorized interface version, configuration and code hashes, approvals, maintenance window, routing change, certificate and secret state, queue treatment, monitoring, downstream readiness, fallback trigger, rollback package, communications, and acceptance time. Rollback also needs data reconciliation: messages delivered, queued, duplicated, transformed differently, or missed during the window cannot be fixed merely by restoring software. Preserve the exact production history and complete the clinical or operational follow-up appropriate to any discrepancy.

Test continued operation and migration as separate scenarios

A useful evaluation should keep one stable low-risk interface on Iguana 6, migrate a version-sensitive interface to IguanaX, and defer a third because a destination dependency is not ready. Apply a security update, rotate a certificate, introduce a message variant, run both engines on the migration population, trigger a target outage, and exercise rollback. Reviewers should reconstruct why each path was chosen and whether data, acknowledgments, exceptions, and downstream use remained controlled.

The official site supports the attributed dual-generation, continued-support, critical-infrastructure, gradual-evolution, and non-forced-migration positioning. It does not establish release parity, security coverage, compatibility, local configuration, semantic equivalence, migration readiness, interface reliability, privacy compliance, clinical safety, or outcome for any customer. Integration, clinical, data, privacy, security, operations, vendor-management, compliance, and legal owners retain those decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.