The Handoff Is Part of the Drug

by Priya NairClinical and Regulatory Correspondent, HMND

Novartis has agreed to pay Abogen $575 million upfront, with the transaction potentially reaching $7.8 billion through development, regulatory, and commercial milestones. The deal covers ABO2203, an mRNA encoded CD19xCD3 T cell engager, along with options for additional programs built on Abogen’s RNA platform.

The headline describes a license. The operating reality is a shared evidence chain.

A scientist sees a response signal. A clinical team turns that signal into a protocol decision. CMC converts the selected construct into a controlled process. Quality asks whether each record can be reconstructed. Regulatory turns the accumulated evidence into a submission that must survive questions from people who were absent when the first observation was made.

Every transition changes the owner, the system, or both. Sometimes it changes the meaning without changing the value.

The evidence chain starts before the database

Imagine an Abogen study team reviewing an early ABO2203 result in Suzhou. The observation may begin in a laboratory information system, move through an analysis workspace, and enter a clinical review packet as a statement about exposure, pharmacology, or response. A scientist may attach a spreadsheet because the assay platform exports a file that the clinical data system cannot read. The spreadsheet becomes useful immediately and dangerous gradually.

The danger arrives when Novartis asks which version supported a dose decision.

A shared program needs more than exchanged files. It needs an identifiable path from source observation to interpreted result, from interpreted result to decision, and from decision to the manufacturing or submission record that relies on it. FDA guidance defines data integrity through completeness, consistency, and accuracy, and treats an audit trail as a secure, time stamped record that permits reconstruction of an electronic record’s history.

That definition reaches well beyond a laboratory database. It reaches the interface between two companies.

An API can move an assay result from an Abogen system into a Novartis clinical or quality environment, yet the transfer alone proves very little. The receiving record needs the source identifier, source version, timestamp, responsible role, validation state, unit, controlled term, and relationship to any correction. A payload that says “positive” without the originating method, threshold, and interpretation context may be technically complete while remaining scientifically thin.

The interface needs to carry meaning, not merely bytes.

The stalled handoff has an owner

Consider one specific scene. A Tuesday afternoon data review finds that a pharmacodynamic marker in the clinical review environment uses the term “B cell depletion,” while the source assay system uses a coded result tied to a different threshold and specimen time window. The API transfer succeeds. The dashboard refreshes. The clinical lead cannot reconcile the displayed value with the laboratory report, so the dose escalation decision waits.

The owner of that stalled handoff is Abogen’s data engineering lead for the source assay interface, working with the assay owner. Novartis can reject the record, pause the review, or request a correction, but it does not own the source mapping that created the ambiguity. If the agreement leaves that responsibility vague, the delay becomes a joint problem with no joint control.

Teams acquire a clean transfer log and an unowned decision.

The correction workflow matters just as much. A corrected result should preserve the original value, identify the person or service that made the change, state why it changed, record when the correction occurred, and show which downstream records were recalculated or reviewed. Quietly overwriting the value may make the screen look right. It also severs the evidence needed to explain why a clinical conclusion changed.

A correction is an event in the study history. The interface must treat it that way.

Controlled terminology carries scientific judgment

Controlled terminology sounds like administrative housekeeping until a manufacturing instruction inherits the wrong term.

ABO2203 combines an RNA construct with an in vivo production concept for a CD19xCD3 engager. The record may contain terms for construct identity, sequence version, lipid or delivery component, assay method, specimen type, dose unit, release attribute, and stability condition. Each term has a place in the evidence chain. A shared dictionary cannot be a static attachment to the quality agreement because new assay methods and process changes will arrive before the program does.

The parties need versioned terminology with an owner for each domain. Clinical data management should own clinical concepts. CMC should own material and process terms. Quality should control the effective date and approval state. Software teams should enforce the mapping rather than merely document it.

A mapping table that lives in a slide deck is a future deviation wearing office clothes.

The API also needs a security boundary that respects responsibility. Abogen may retain source systems and records created under its development work. Novartis may operate the clinical repository, quality system, or regulatory content platform used for the global program. A service account that crosses the boundary requires least privilege, certificate or token management, monitoring, and a clear answer to a basic question: which company can disable the connection, and what happens to records already transferred?

Retention creates a second boundary. A record copied into the receiving system may be governed by Novartis procedures, while its source metadata remains under Abogen control. The electronic copy must preserve the content and meaning of the original, including metadata, when used as a true copy under FDA’s data integrity expectations.

That requirement leaves little room for decorative interoperability.

Attribution survives the software layer

A user name is not attribution if five people share the same service account. A timestamp is weak evidence if systems record local time without a controlled time source. An approval is difficult to defend when a workflow displays a green status without storing the approver’s role, decision, and effective version.

Immutable audit history does not mean that every mistake becomes permanent on the screen. It means the system preserves the sequence of events while allowing a governed correction to create the current approved state. The user experience can show the latest value. The record must retain the path that produced it.

That distinction matters during a regulatory question. A reviewer may ask why a dose was selected, why a specification changed, or why a batch disposition relied on a revised assay result. The answer cannot depend on a developer reconstructing database transactions from backups after the fact.

The answer should be discoverable through the system of record.

Clinical operations need this history when a data review crosses a company boundary. Quality needs it when an exception touches a release decision. CMC needs it when process knowledge moves from development into a control strategy. Software operators need it when an integration retries a message and risks creating a duplicate result.

Each group sees a different failure. The interface produces one failure.

Manufacturing makes the boundary visible

The laboratory result eventually meets a material record. A selected RNA sequence becomes a controlled starting point. A process parameter becomes a target or a range. An assay method becomes part of release or characterization. A change made during development acquires regulatory significance when the same concept appears in a batch record, stability plan, or submission section.

Novartis may assume responsibility for global development and later submission activities, while Abogen continues to provide technical data, process knowledge, or manufacturing support. Contract language can divide tasks. The software still has to join them.

Suppose Abogen updates a construct sequence in its research repository, but the Novartis CMC system receives only the new sequence label. The receiving team sees a current value without the predecessor relationship, impact assessment, or approval event. A manufacturing instruction then references a material specification that appears unchanged because the identifier remained stable. The system has transmitted a value and lost the change.

The owner of the handoff is the change control owner for the originating construct record. The receiving CMC team owns the impact review after notification. Neither team owns the gap if the integration has no event for “superseded,” “effective,” or “requires assessment.”

At that point sponsor responsibility becomes inseparable from partner system design. Novartis can remain the submission sponsor on paper, but its ability to defend the submission depends on Abogen’s identifiers, timestamps, version logic, access controls, and correction history. Abogen can remain the scientific source, but its evidence becomes regulatory evidence only when the sponsor can retrieve, understand, and authenticate it.

Responsibility has crossed the contract boundary.

Validation cannot stop at the endpoint

A validated clinical system does not validate the message that enters it. An approved API specification does not prove that a source system emits the intended units. A successful test of a single payload does not test a delayed correction, a duplicate message, a revoked user, a changed terminology version, or a failed transfer during a critical review window.

Integration validation should follow the real workflow. A source result should travel through the API, arrive in the receiving system, appear in the review screen, support a decision, and remain traceable after correction. The test should include the failure scene because the failure scene is where ownership becomes visible.

Software teams often describe this as event design. Quality teams may recognize it as contemporaneous, attributable, complete, and consistent recordkeeping. Clinical teams experience it as confidence in a data review. CMC teams experience it as a defensible bridge between development knowledge and manufacturing control.

The vocabulary differs. The evidence does not.

The awkward work sits in the seams. Someone must define whether a late result updates a locked analysis, whether a corrected laboratory value triggers a new clinical review, whether a terminology change requires resubmission of a data package, and whether a system outage creates a deviation or merely an incident. Those decisions belong in operating procedures and tested workflows, with named owners who can act before a regulatory question forces the issue.

The future record will include the interface

ABO2203 is still an early therapeutic program, and the agreement includes options over additional assets rather than a single isolated handoff. That makes the interface more consequential. A pattern that works for one program may become the inherited architecture for several programs, each with different assays, constructs, sites, and submission paths.

The attractive fiction is that a global pharmaceutical company can absorb the partner’s data once the deal closes. Absorption does not erase provenance. It creates a larger obligation to preserve it.

Clinical, quality, CMC, and software operators already know where the strain appears. It appears when a result has two identifiers, when a correction arrives after a review, when a controlled term changes without an effective date, and when an audit trail records an edit without the reason for the edit. Those are operational facts, not philosophical concerns.

Regulation is not the villain here. The harder question is whether both companies will treat the interface as part of the product’s evidence, rather than as plumbing between products. The answer will emerge in the records that survive a query, a deviation, a batch decision, or a submission review. Somewhere in that record, the handoff will either have an owner or it will have a story.

If your systems are beginning to tell that story, hello@example.com is a sensible place to continue the conversation.