Персональная вакцина от рака: зачем я пишу координационный слой с открытым исходным кодом для mRNA-терапии

Я помню момент, когда это перестало быть абстракцией.

Январь 2024 года. Команда Moderna и Merck публикует обновленные данные по KEYNOTE-942: в первичном анализе персонализированная mRNA-вакцина V940 в комбинации с пембролизумабом показала снижение риска рецидива меланомы на 44% (HR 0.561; 95% CI 0.309-1.017; двустороннее p=0.053), то есть результат на границе статистической значимости. Публикация в Lancet, 157 пациентов. Это не пресс-релиз с конференции и не слайд из инвесторской презентации, а рецензируемая статья в одном из самых строгих медицинских журналов. Потом картина стала только убедительнее: в 3-летнем наблюдении (ASCO 2024, абстракт LBA9512) сообщалось о 49% снижении риска рецидива или смерти (HR 0.510; 95% CI 0.288-0.906; двустороннее номинальное описательное p=0.019). В 5-летнем обновлении, опубликованном как корпоративное сообщение Moderna, эффект тоже описывался как сохраняющийся; в сообщении приводилось одностороннее номинальное p=0.0075.

А дальше все пошло быстро. К моменту публикации статьи в Lancet Moderna уже запустила третью фазу испытаний INTerpath-001. По записи ClinicalTrials.gov у исследования NCT05933577 дата первой публикации в реестре — 6 июля 2023 года; это фиксирует запуск уже в июле 2023-го. В протоколе — 1089 пациентов и, по данным запуска программы, 38 центров в 14 странах. Исследование по коду NCT05933577 находится сразу; статус — “active, not recruiting”. Параллельно Genentech вместе с BioNTech двигают вторую фазу autogene cevumeran по раку поджелудочной, NCT05968326, в комбинации с атезолизумабом и mFOLFIRINOX. Это заболевание, где пятилетняя выживаемость по срезу SEER для всей категории рака поджелудочной составляет 13.3% (интервал 2015-2021), а для PDAC профиль риска обычно еще хуже. В расширенном наблюдении первой фазы по раку поджелудочной (Sethna, Guasp et al., Nature, 2025; полный текст по платной подписке) у пациентов-респондеров на вакцину медиана выживаемости без рецидива не была достигнута при медиане наблюдения 3.2 года — против 13.4 месяца у нереспондеров (p = 0.007).

Два года назад я бы сказала “перспективное направление” и пошла дальше. Сегодня я смотрю на эти цифры и понимаю: это уже конвейер. Каждый пациент — отдельная серия производства. Секвенирование опухоли, предсказание неоантигенов, дизайн mRNA-конструкта, упаковка в липидные наночастицы, введение. В публичных коммуникациях Moderna фигурирует цель цикла порядка нескольких недель; в ряде выступлений речь шла примерно о 4 неделях. И на каждом шагу — документация, прослеживаемость, ворота качества.

Биоинформатические инструменты для этого есть: Nextflow + nf-core/sarek + pVACtools. Предсказание неоантигенов — NetMHCpan, MHCflurry, десяток альтернатив. Дизайн mRNA — LinearDesign, mRNAid. А вот открытого инструмента, который управлял бы всей цепочкой — от поступления образца до введения вакцины и мониторинга иммунного ответа, — я не нашла. Фарма пишет проприетарные системы за закрытыми дверями. Академия пишет пайплайны. Открытого специализированного слоя управления между одним и другим я не увидела.

Именно это меня и зацепило. Так я начала писать OpenRNA — координационный слой с открытым исходным кодом для персонализированных неоантигенных RNA-вакцин. TypeScript, Node.js, Express 5, Zod 4, 440 тестов в 22 наборах (по последнему верифицированному срезу репозитория), покрытие строк 95%, Apache-2.0. Это не пайплайн и не предсказатель, а оркестратор клинического рабочего процесса.

Десять шагов, из которых два покрыты

Представьте конкретного пациента. Меланома, стадия IIIB, резекция позади, нужна адъювантная терапия персонализированной вакциной. Дальше начинается длинная дорога:

1. Согласие пациента на обработку генетических данных (управление согласием). Без него ничего не стартует.

2. Регистрация биоматериала: опухолевая ДНК, нормальная ДНК, опухолевая РНК. У каждого образца — свой тип анализа (WES, WGS, RNA-seq) и происхождение.

3. Запуск Nextflow-пайплайна: детекция соматических вариантов, фильтрация, HLA-типирование.

4. Результаты HLA-типирования от нескольких инструментов нужно свести в консенсус. OptiType говорит одно, HLA-HD другое, arcasHLA третье. Если расхождение выходит за операторский порог, заданный политикой исследования, кейс уходит на ручной разбор.

5. Контроль качества: качество секвенирования, глубина покрытия, процент дуплексов. Не прошел — стоп, возврат к шагу 2 с новым образцом.

6. Ранжирование неоантигенов: pVACtools выдает список, его нужно сохранить и привязать к кейсу.

7. Дизайн конструкта: выбор модальности (mRNA, saRNA, circRNA), стратегия линкеров между эпитопами, генерация пакета для производства.

8. Экспертная панель: врачи рассматривают всю доказательную базу, утверждают или отправляют на доработку.

9. Передача на производство: пакет документов с полной прослеживаемостью от образца до конструкта.

10. Введение вакцины, мониторинг иммунного ответа, клиническое наблюдение.

Nextflow прекрасно справляется с шагом 3. pVACtools — с шагом 6. А для остальных восьми шагов открытого специализированного инструмента я не нашла.

И тут самое неприятное: каждый из этих восьми шагов находится под регуляторным надзором. FDA (21 CFR Part 11, CBER BLA), EMA (потенциально режим ATMP), ICH Q8-Q12. Это не та ситуация, где можно написать Jupyter-ноутбук и обойтись.

Фарма решает это по-своему: полгода разработки, NDA, команда из 20 человек на поддержке. Но для исследовательской группы из пяти человек, которая хочет запустить инициативное клиническое исследование, такой путь — тупик.

17 портов и ни одного new Service()

Когда я садилась проектировать OpenRNA, первый вопрос, который меня по-настоящему мучил, был не про хранение данных и не про фреймворк. Вопрос был другой: через три года, когда самоамплифицирующаяся РНК дозреет до второй фазы в онкологии, или когда кто-нибудь наконец придумает, как наладить cGMP-производство circular RNA — сколько из написанного мной кода придется выбросить?

Я хотела, чтобы ответ был: ноль.

Бизнес-логика не должна знать, какой именно HLA-тайпер стоит за интерфейсом. Не должна знать, Nextflow там или Snakemake. Не должна знать, pVACtools или MHCflurry. Она должна знать только одно: что эти вещи существуют и умеют делать определенные операции. А какие именно вещи и как именно — это уже детали адаптера.

Отсюда выросли 17 доменных портов. Интерфейсы, живущие в src/ports/:

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

// src/ports/IHlaConsensusProvider.tsexport interface IHlaConsensusProvider {  produceConsensus(    caseId: string,    inputs: HlaTypingInput[],    referenceVersion: string  ): Promise<HlaConsensusRecord>;  getConsensus(caseId: string): Promise<HlaConsensusRecord | null>;}

11 портов для научного и рабочего потока: IConstructDesigner, IHlaConsensusProvider, IModalityRegistry, INeoantigenRankingEngine, INextflowClient, IOutcomeRegistry, IQcGateEvaluator, IReferenceBundleRegistry, IWorkflowDispatchSink, IWorkflowOrchestrator, IWorkflowRunner.

5 портов для слоя управления: IAuditSignatureProvider, IConsentTracker, IFhirExporter, IRbacProvider, IStateMachineGuard.

И IEventStore для реплея доменных событий.

Все адаптеры инъектируются через единую фабрику AppDependencies. Ни одного new в бизнес-логике — это принцип, который я себе пообещала не нарушать:

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

По умолчанию все поднимается на адаптерах в памяти — удобно для разработки и тестов. Нужен PostgreSQL? Подключаешь CASE_STORE_DATABASE_URL, и PostgresCaseStore тихо занимает место InMemoryStore. Бизнес-логика об этом не узнает.

20 адаптеров в сумме: 16 в памяти для локальной работы, 4 для PostgreSQL и интеграции с Nextflow.

15 состояний одного пациента

Когда рисуешь на салфетке жизненный цикл онкологического кейса, сначала кажется, что хватит пяти-шести состояний. Потом вспоминаешь про отказы, про QC-провалы, про ревизии. Потом про то, что консилиум может отправить кейс обратно на доработку. В итоге получилось 15:

INTAKING -> AWAITING_CONSENT -> READY_FOR_WORKFLOW -> WORKFLOW_REQUESTED-> WORKFLOW_RUNNING -> WORKFLOW_COMPLETED -> QC_PASSED -> AWAITING_REVIEW-> APPROVED_FOR_HANDOFF -> HANDOFF_PENDING

(Плюс WORKFLOW_CANCELLED, WORKFLOW_FAILED, QC_FAILED, REVISION_REQUESTED, REVIEW_REJECTED — на каждом этапе что-то может пойти не так, и это нужно моделировать явно.)

Каждый переход порождает доменное событие: case.created, sample.registered, workflow.started, qc.evaluated, board.packet.generated… Полная трассируемость от первого образца до клинического исхода.

Почему конечный автомат, а не простой статус-флаг? Честно говоря, я долго колебалась. Статус-флаг проще, быстрее пишется, быстрее отлаживается. Но FDA хочет видеть журнал аудита. Каждая мутация кейса должна быть иммутабельным событием с correlationId, временной меткой и контекстом. И если кто-то попытается перепрыгнуть из INTAKING сразу в APPROVED_FOR_HANDOFF, минуя согласие, рабочий процесс и экспертную оценку, порт IStateMachineGuard это запретит. Не из паранойи, а потому что в клиническом контексте пропущенный шаг — это реальный риск для реального пациента.

Три модальности с первого дня (и почему это не переусложнение)

Наверное, самый спорный выбор в архитектуре — поддержка трех модальностей RNA с самого начала. Меня справедливо спросят: зачем, если в третью фазу испытаний пока вышла только обычная mRNA?

У меня есть на это ответ, и он не про перфекционизм. Он про математику доз.

Обычная mRNA — 30-100 мкг на дозу. Для saRNA в доклинических и ранних разработках часто обсуждают очень низкие дозы, но клинически одобренная ARCT-154 (разработчик платформы — Arcturus; коммерциализация в Японии — через партнерскую связку CSL Seqirus и Meiji Seika Pharma) для COVID-19 использует дозу 5 мкг, и это уже рабочая платформа, а не теория. Circular RNA (circRNA) — замкнутое кольцо, устойчивое к экзонуклеазам, потенциально с более длительной экспрессией. Но cGMP-производство circRNA пока никто толком не наладил.

Gritstone Bio вела несколько онкологических программ: персонализированную GRANITE (в клинике — гибридный формат adenoviral prime + saRNA boost) и отдельную программу SLATE для общих неоантигенов. В 2024 году компания прошла через процедуру банкротства. При этом GRANITE в клинике была в первую очередь программой для MSS-колоректального рака, а не для PDAC. Судя по публичным отчетам, проблема была не только в платформе доставки, а в сочетании клинических результатов, выбранной стратегии и финансовой нагрузки. Модальность жива. Бизнес-модель конкретной компании — нет.

Так вот: базовая модальность в OpenRNA — обычная mRNA. Единственная, за которой стоят данные третьей фазы. saRNA и circRNA — записи в IModalityRegistry, включить и выключить которые может только администратор. А конструкт-дизайнер принимает deliveryModality?: DeliveryModality, и бизнес-логика одна и та же — меняется только адаптер.

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

Типизация жесткая, Zod на каждом входе API. TUMOR_DNA — ДНК из опухолевой ткани, NORMAL_DNA — герминальная контрольная, TUMOR_RNA — для экспрессионного профилирования. FOLLOW_UP — постлечебные образцы для мониторинга иммунного ответа.

Когда три инструмента HLA-типирования не согласны друг с другом

Это один из моментов, который меня по-настоящему тревожит. HLA-типирование — фундамент предсказания неоантигенов. Ошибешься с HLA-генотипом пациента, и все предсказания связывания пептид-MHC окажутся мусором. А вакцина, собранная на основе этого мусора, просто не сработает.

Проблема в том, что разные инструменты дают разные результаты. OptiType (целочисленное линейное программирование по NGS-данным, в том числе WES и RNA-seq) покрывает только HLA класс I. HLA-HD, построенный на Bowtie2, работает с обоими классами, но иногда расходится с OptiType по HLA-A. arcasHLA (количественный анализ RNA-seq) добавляет третье мнение, которое может не совпадать ни с первым, ни со вторым.

Bauer et al. (Brief Bioinformatics, 2018; doi:10.1093/bib/bbw097) при систематической оценке вычислительных программ предсказания HLA-генотипов по геномным данным показали общую проблему расхождения между HLA-тайперами и ограничений по точности для клинического применения. Важно, что HLA-HD и arcasHLA в ту работу еще не входили: она иллюстрирует не прямое сравнение именно этих трех инструментов, а более общую проблему несогласованности HLA-типирования. Для платформы, где от типирования зависит выбор эпитопов, а от выбора эпитопов — подействует ли вакцина, это не абстрактная проблема. Это разница между иммунным ответом и его отсутствием.

Поэтому IHlaConsensusProvider принимает массив результатов от разных инструментов:

interface HlaTypingInput {  toolName: string;  alleles: string[];  confidence: number;  rawOutput?: string;}

И сводит их в консенсус с расчетом расхождений между инструментами. Если расхождения значимые — кейс не продвигается дальше автоматически и остается на ручном разборе. Это принципиальное решение. Не принудительное согласование, не голосование большинством, не “берем самый уверенный”. Честный флаг: данные противоречивы, человек должен посмотреть.

Мне было бы проще написать автоматический расчет консенсуса по мажоритарному голосованию. Но если этот инструмент когда-нибудь окажется в клиническом контексте, решение о HLA-генотипе должен принимать специалист, глядя на все данные сразу.

Журнал аудита и регуляторная реальность

21 CFR Part 11, параграф 11.10: меры для закрытых систем. Журнал аудита, ограничение доступа, проверка последовательности и полномочий. Звучит сухо. Но за этими словами стоит простая мысль: если софт участвует в процессе, который касается здоровья пациента, каждое действие в нем должно быть отслеживаемым и необратимым. Кто, когда, что сделал, почему.

Для персонализированных вакцин это особенно остро. Каждый кейс — потенциально (когда-нибудь, если повезет) регуляторный документ.

В OpenRNA каждая мутация кейса порождает иммутабельный CaseAuditEventRecord:

const caseAuditEventTypes = [  "case.created",  "sample.registered",  "artifact.registered",  "workflow.requested",  "workflow.started",  "workflow.completed",  "workflow.cancelled",  "workflow.failed",  "qc.evaluated",  "hla.consensus.produced",  "artifact.derived",  "candidate.rank-generated",  "payload.generated",  "outcome.recorded",  "board.packet.generated",  // ...] as const;

Correlation ID пробрасывается через весь запрос:

app.use((req, res, next) => {  const correlationId =    req.header("x-correlation-id") ?? `corr_${randomUUID()}`;  res.locals.correlationId = correlationId;  res.setHeader("x-correlation-id", correlationId);  next();});

Граф прослеживаемости строится из этих событий: от образца через артефакты и запуски пайплайнов до конструкта и клинического исхода. Порт IAuditSignatureProvider зарезервирован под электронные подписи, когда (если, не буду загадывать) дойдет очередь до валидированной системы.

А вот честная часть, которую я не хочу прятать. Электронных подписей в текущей реализации нет. 21 CFR Part 11 — карта соответствия в документации разделяет “реализовано” и “пробел” явно. Я не стану писать “соответствует Part 11” — это было бы ложью. Журнал аудита реализован, контроль доступа через RBAC с запретом по умолчанию, корреляционный идентификатор на каждом запросе. Но Part 11 — это не только про логирование. Это про подтверждение личности подписанта, уникальность учетных данных, привязку подписи к записи, двойную авторизацию выпуска. Этого пока нет, и я хочу, чтобы об этом знали все, кто будет смотреть на репозиторий.

Три зависимости в рабочей сборке

Вот мой package.json:

{  "dependencies": {    "express": "^5.2.1",    "pg": "^8.20.0",    "zod": "^4.3.6"  }}

Три пакета. Express 5 (наконец-то с нативной обработкой async-ошибок), pg (PostgreSQL-клиент для надежного хранения), Zod 4 (рантайм-валидация на каждом входе).

Node.js 24 в статусе Active LTS (по состоянию на апрель 2026 года). TypeScript 6.0.2, строгий режим типизации, module: "nodenext". Это переходный релиз, мост к TypeScript 7.0 и нативному Go-порту, а не обычный «еще один мажор». Тесты на встроенном node:test — без внешних тестовых фреймворков. На аудированном срезе от апреля 2026 года это 440 тестов в 22 наборах, и они проходят за секунды. Я засекала. И каждый раз немного радуюсь.

В devDependencies живут tsx, supertest, pg-mem (PostgreSQL в памяти для тестов). Но в рабочей сборке — три пакета, и точка.

npm audit --omit=dev --audit-level=high — чисто. CycloneDX SBOM генерируется скриптом. В CI стоят CodeQL SAST, проверка зависимостей на PR и прослеживаемость цепочки поставок через GitHub attestation + Sigstore.

Почему Express 5, а не Fastify, Koa или Hono? Потому что Express 5 наконец нормально ловит async-ошибки, а код читается любым, кто хоть раз работал с Node.js. Координационный слой не обслуживает 10K RPS, тут десятки кейсов в неделю. В этой ситуации простота чтения дороже бенчмарков.

Цифры

95% покрытия строк — побочный эффект, а не цель. Я не гонялась за процентами. Каждый доменный порт протестирован через свои адаптеры, каждый переход конечного автомата проверен, каждый API-эндпоинт прогнан в supertest. Оставшиеся 5% — это аварийная остановка, граничные случаи PostgreSQL-адаптеров при потере соединения и миграционные скрипты. Правильные 5%.

Покрытие ветвей 83.44%, и я не пытаюсь его искусственно натянуть. Непокрытые ветки — в основном защитные проверки на невалидный ввод, который Zod срезает раньше. Тесты должны проверять поведение, а не добивать цифру ради красивого отчета.

Чего нет (и от чего я не буду отмахиваться)

На Хабре не верят разработчику, который рассказывает только о хорошем. И правильно делают.

• Предсказание неоантигенов — не реализовано. Порт INeoantigenRankingEngine принимает результат от внешнего инструмента, а не запускает предсказание сам. OpenRNA — координационный слой, не биоинформатический конвейер. Я не пишу NetMHCpan, я оркестрирую работу с его выводом.

• Электронные подписи (21 CFR Part 11) — зияющий пробел. Журнал аудита есть, электронных подписей нет. Это разница между “мы записываем, кто что сделал” и “мы можем доказать, что это действительно был тот человек”.

• RBAC с привязкой к ресурсам — текущий RBAC дает запрет по умолчанию на уровне операций, но не на уровне конкретных кейсов или тенантов. Врач из клиники A не должен видеть пациентов клиники B — и этого пока не обеспечено.

• Надежное хранилище событий — доменные события живут в памяти. PostgreSQL-журнал событий — в дорожной карте.

• Двойная авторизация выпуска — для GMP-производства нужно. В текущей реализации нет.

• Реальные пациентские данные — код тестировался только на синтетических данных.

Регуляторная карта

OpenRNA проектировался с оглядкой на регуляторику, а не задним числом. Но между “проектировался с оглядкой” и “прошел валидацию” — пропасть. Я хочу, чтобы разница была понятна.

Что архитектурно покрыто уже сейчас:

• Журнал аудита на каждую мутацию кейса (§ 11.10)

• Авторизация с запретом по умолчанию (§ 11.10)

• Блокировка по согласию: запись в кейс невозможна без оформленного согласия

• Корреляционный идентификатор на каждом запросе — прослеживаемость от начала до конца

• Цепочка прослеживаемости от образца до конструкта (ICH Q8 Quality by Design)

• Структурированный контракт ошибок с операторскими кодами

Чего не хватает для того, чтобы назвать это валидированной системой:

• Электронные подписи (§§ 11.50, 11.70, 11.100, 11.200)

• IQ/OQ/PQ квалификация

• Описание предназначения (intended use)

• Матрица прослеживаемости пользовательских требований

• Валидированная база данных (по умолчанию — в памяти)

• Процедура двойной авторизации выпуска

Это не мелочи, это не “доделаем потом”. Это разница между софтом, у которого правильная архитектура для будущей регуляторной валидации, и софтом, который эту валидацию прошел. Первое — да. Второе — нет.

Открытый код в фарме и кто конкурирует

Стандартный аргумент, который я слышу регулярно: фарма никогда не поставит решения с открытым исходным кодом в клинический процесс.

В исследовательском контексте и в клинических исследованиях — уже ставит.

Nextflow (Apache-2.0) работает в Seqera и десятках фармкомпаний. sarek из nf-core используется для детекции соматических вариантов в клинических исследованиях. pVACtools (BSD-3-Clause-Clear, лаборатория Griffith в WashU) — основной конвейер предсказания неоантигенов в академическом и клиническом применении. ViennaRNA (академическая лицензия Венского университета: бесплатна для исследований и образования; включение в коммерческий продукт — по согласованию с авторами) — золотой стандарт для предсказания вторичной структуры мРНК, больше 10 000 цитирований. MHCflurry (Apache-2.0) конкурирует с NetMHCpan с открытым кодом и открытыми данными для обучения.

OpenRNA не первый инструмент с открытым исходным кодом в этой цепочке. Он занимает пустое место между инструментами, которые уже стоят в чьих-то пайплайнах.

Apache-2.0 я выбрала осознанно. Коммерческое использование, модификация, распространение — без ограничений, patent grant включен. BSD-3-Clause-Clear (как у pVACtools) не дает patent grant, а AGPL требует раскрытия модификаций при сетевом использовании. Для фармкомпании, которая захочет взять OpenRNA и адаптировать под свои нужды, Apache-2.0 — минимальное юридическое трение при максимальной патентной защите.

Ландшафт:

Слой управления между пайплайнами и клинической доставкой — ниша, которую пока никто не занял. Ни Nextflow, ни pVACtools не отвечают за согласие пациента, консилиум, передачу на производство или мониторинг исхода.

Три технических решения, которые я выбрала осознанно

Идемпотентная отправка на запуск

Запуск рабочего процесса — потенциально дорогая операция. Nextflow-пайплайн может считать часами на GPU. Двойной запуск — это не просто потеря денег, это провал аудита: два запуска на один кейс, два набора результатов, какой правильный?

Заголовок x-idempotency-key в OpenRNA опционален, но для безопасной дедупликации повторных отправок его лучше передавать всегда:

POST /api/cases/:caseId/workflowsx-idempotency-key: req_abc123

Повторный запрос с тем же ключом не запускает новый пайплайн, а возвращает результат предыдущего.

Опрос вместо вебхуков

Nextflow-пайплайн может работать часами. Вебхуки тут хрупки: сервер перезапустился — колбэк потерян, состояние непонятно. Я выбрала контур опроса: IWorkflowRunner периодически опрашивает Nextflow API, обновляет жизненный цикл запуска, маркирует провалы с категорией: executor_error, pipeline_error, timeout, infrastructure_error. Таймауты конфигурируемы. Не самое элегантное решение в мире, но надежное и предсказуемое.

Консилиум и ручной контроль

Консилиум получает пакет доказательств со всей информацией по кейсу: HLA-консенсус, ранжированные неоантигены, QC-результаты, артефакты. Экспертная панель выносит решение: approve, revision_requested или rejected. Каждое решение — аудитное событие. Пакет передачи на производство генерируется только после одобрения.

Никакой автоматической отправки на производство. Это не ограничение реализации — это осознанный выбор. Вакцину для конкретного пациента нельзя отдать в производство без одобрения живых врачей, видящих живые данные.

---

Код: github.com/KonkovaElena/OpenRNA.

Я описала технику, архитектуру и честно перечислила дыры. Но за всем этим остается один вопрос: доживет ли это до клиники?

И пять других вопросов, на которые у меня пока нет ответов:

1. Скорость. 4-8 недель на одну вакцину — узкое место. Moderna заявляет цель в 4 недели. Где реальное узкое место: секвенирование, предсказание, дизайн конструкта, GMP-производство? Что можно параллелить, а что нельзя в принципе?

2. Масштаб. INTerpath-001 — 1089 пациентов. Если V940 получит одобрение (по текущей записи ClinicalTrials.gov расчетная дата завершения первичной конечной точки — 26 октября 2029 года; расчетная дата полного завершения исследования — сентябрь 2030 года), масштаб вопроса перестанет быть академическим. Успел ли кто-нибудь подсчитать, сколько параллельных единичных серий производства нужно на один онкологический центр?

3. Валидация. GxP-валидация софта для персонализированных биопрепаратов — это классический IQ/OQ/PQ или Computer Software Assurance? Руководство FDA 2023 года толкает к риск-ориентированному подходу, но конкретных прецедентов для ПО неоантигенных платформ я не нашла.

4. Модальности. saRNA выживет в онкологии после банкротства Gritstone? Проблема с активацией врожденного иммунитета от dsRNA-интермедиатов — решаемая или фундаментальная?

5. Открытый код в GxP. Кто реально работает с компонентами с открытым исходным кодом в GxP-среде и как это оформлено? GAMP 5 покрывает инфраструктурное ПО — но управление рабочими процессами для персонализированной терапии под это описание подпадает или нет?

Если вы работаете в этой области или рядом — мне правда интересно услышать ваш опыт.

Ссылки

• KEYNOTE-942 (Lancet, 2024), PubMed: https://pubmed.ncbi.nlm.nih.gov/38246194/

• KEYNOTE-942, 3-летнее обновление (ASCO 2024, абстракт LBA9512): https://ascopubs.org/doi/10.1200/JCO.2024.42.17_suppl.LBA9512

• KEYNOTE-942, 5-летнее обновление (корпоративный формат, newsroom Moderna): https://news.modernatx.com/

• ClinicalTrials.gov: INTerpath-001 (NCT05933577): https://clinicaltrials.gov/study/NCT05933577

• ClinicalTrials.gov: IMCODE003 / программа при раке поджелудочной железы (NCT05968326): https://clinicaltrials.gov/study/NCT05968326

• SEER Cancer Stat Facts (Pancreatic Cancer, 5-year relative survival 13.3%, 2015-2021): https://seer.cancer.gov/statfacts/html/pancreas.html

• BioNTech, контекст по программе IMCODE003 при PDAC: https://www.biontech.com/int/en/home/pipeline-and-products/pipeline.html

• eCFR Title 21 Part 11 (displaying title up to date as of 4/14/2026; title last amended 4/09/2026): https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11

• ARCT-154 / KOSTAIVE (Nature Communications, 2024; данные по дозе 5 мкг): https://www.nature.com/articles/s41467-024-47722-z

• Sethna, Guasp et al. (Nature, 2025; autogene cevumeran, PDAC, расширенное наблюдение первой фазы): https://www.nature.com/articles/s41586-024-08508-4

• Bauer et al. (Brief Bioinformatics, 2018; оценка инструментов HLA-типирования по данным геномного секвенирования): https://doi.org/10.1093/bib/bbw097