OpenRNA: coordination layer for mRNA vaccines in oncology

# OpenRNA: How an Open Coordination Layer Accelerates Development of Personalized mRNA Cancer Vaccines

Clinical data confirm the effectiveness of personalized mRNA vaccines in oncology, but their widespread adoption is hindered by the lack of standardized workflow management tools. OpenRNA is the first open-source project that combines bioinformatics pipelines, regulatory requirements, and clinical protocols into a unified orchestration system.

From Clinical Data to Systemic Challenges

Modern studies demonstrate a breakthrough moment in cancer therapy. Phase III trial data from KEYNOTE-942 (Moderna/Merck) showed a 49% reduction in melanoma recurrence risk when using the personalized mRNA vaccine V940 in combination with pembrolizumab. Similar results are observed in pancreatic cancer studies: responders have a median recurrence-free survival exceeding 3.2 years versus 13.4 months for non-responders. These figures point to a transition from experimental development to standardized production.

However, each patient requires a unique production cycle: tumor sequencing, neoantigen prediction, mRNA construct design, and packaging into lipid nanoparticles. With a target cycle of 4 weeks, automation of all stages is critically important. Existing solutions do not cover the full spectrum of tasks:

• Nextflow and nf-core/sarek handle bioinformatics pipelines
• pVACtools ranks neoantigens
• LinearDesign designs mRNA

At the same time, there is no system for managing the end-to-end process from sample receipt to immune response monitoring that complies with FDA regulatory standards (21 CFR Part 11) and EMA (ATMP).

OpenRNA Architecture: Domain Ports and Adapters

OpenRNA is built on clean architecture principles with 17 domain ports isolating business logic from technical details. Key interfaces are focused in two layers:

Scientific Workflow Layer:

• IConstructDesigner for generating constructs
• IHlaConsensusProvider for HLA typing consensus
• INeoantigenRankingEngine for epitope ranking
• IWorkflowOrchestrator for pipeline management

Regulatory Compliance Layer:

• IAuditSignatureProvider for audit trails
• IConsentTracker for consent management
• IStateMachineGuard for state transition control

Example implementation of a port for construct design:

// src/ports/IConstructDesigner.ts
export interface ConstructDesignRequest {
  caseId: string;
  rankedCandidates: RankingRationale[];
  deliveryModality?: DeliveryModality;
}
export interface IConstructDesigner {
  designConstruct(request: ConstructDesignRequest): Promise<ConstructDesignPackage>;
}

The system uses a single dependency factory, eliminating direct object creation via new in business logic:

export function createApp(dependencies: AppDependencies = {}) {
  const {
    modalityRegistry,
    constructDesigner,
    workflowRunner,
    store,
    // ...
  } = resolveAppDependencies(dependencies);
  // ...
}

By default, in-memory adapters are activated for development. For production environments, PostgreSQL adapters are connected via environment variables, without affecting domain logic.

Managing the Patient Lifecycle in a Regulatory Environment

Clinical processes require explicit modeling of all possible states. OpenRNA implements a finite state machine with 15 states, including intermediate stages and rollback scenarios:

INTAKING -> AWAITING_CONSENT -> READY_FOR_WORKFLOW -> WORKFLOW_REQUESTED
-> WORKFLOW_RUNNING -> WORKFLOW_COMPLETED -> QC_PASSED -> AWAITING_REVIEW
-> APPROVED_FOR_HANDOFF -> HANDOFF_PENDING
// Additional states for errors:
WORKFLOW_CANCELLED, QC_FAILED, REVISION_REQUESTED

Each transition generates a domain event with immutable attributes:

• correlationId for end-to-end tracing
• Timestamp with nanosecond precision
• Execution context (user, role, IP)

This meets FDA 21 CFR Part 11 requirements for electronic records and enables full reconstruction of each case's processing history. The IStateMachineGuard port blocks invalid transitions—for example, attempting to approve a vaccine without passing QC control.

RNA Modality Support: Strategy, Not Speculation

OpenRNA's architecture natively supports three delivery modalities:

• mRNA — base modality with Phase III data (30-100 μg/dose)
• saRNA — self-amplifying RNA (5 μg/dose, as in ARCT-154)
• circRNA — circular RNA with enhanced stability

The decision is backed by clinical prospects: while only mRNA has completed Phase III to date, saRNA already has approved drugs (ARCT-154 for COVID-19), and circRNA is under active development. In the system, modalities are managed via IModalityRegistry, where admins can enable/disable options:

const sampleTypes = [
  "TUMOR_DNA", "NORMAL_DNA", "TUMOR_RNA", "FOLLOW_UP"
] as const;

Zod typing ensures input data correctness at all stages. Business logic remains unchanged when switching modalities—only the construct generation adapter changes.

Key Takeaways

• Regulatory Readiness: OpenRNA complies with FDA 21 CFR Part 11 and EMA ATMP standards through immutable audit events and controlled state transitions
• Architectural Flexibility: 17 domain ports allow swapping components (Nextflow → Snakemake, pVACtools → MHCflurry) without rewriting business logic
• Clinical Relevance: Support for three RNA modalities accounts for current data and future developments, with mRNA as the foundation

The project shows how an open-source approach can tackle challenges previously locked behind proprietary pharma systems. With 440 tests and 95% code coverage, OpenRNA gives research teams a tool to launch investigator-initiated clinical trials without multimillion-dollar budgets. For developers, it's an example of applying clean architecture in highly regulated environments—where missing a single step could cost a patient their life.

— Editorial Team