17.04.2026 10:21
KonkovaElena 0 3500 Источник

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

Январь 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.ts
export interface ConstructDesignRequest {  caseId: string;  rankedCandidates: RankingRationale[];  deliveryModality?: DeliveryModality;
}
export interface IConstructDesigner {  designConstruct(request: ConstructDesignRequest): Promise<ConstructDesignPackage>;
}

// src/ports/IHlaConsensusProvider.ts
export 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, тут десятки кейсов в неделю. В этой ситуации простота чтения дороже бенчмарков.

Цифры

Показатель

Число

Тесты

440 в 22 наборах

Покрытие строк

95.00%

Покрытие ветвей

83.44%

Покрытие функций

94.94%

Доменные порты

17

Адаптеры

20 (16 в памяти + 4 интеграционных)

Состояния кейса

15

Уязвимости в рабочих зависимостях

0

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 - минимальное юридическое трение при максимальной патентной защите.

Ландшафт:

Проект

Что делает

Чего не делает

Moderna/Merck

mRNA-вакцины, фаза III

Не с открытым исходным кодом

Genentech/BioNTech

autogene cevumeran, фаза II

Не с открытым исходным кодом

pVACtools

Предсказание и ранжирование неоантигенов

Не управляет рабочим процессом

Nextflow/nf-core

Оркестрация пайплайнов

Не управляет клиническим процессом

Benchling

Лабораторный процесс

SaaS, не специализирован, закрытый

OpenRNA

Слой управления для RNA-вакцинного процесса

Не пайплайн, не предсказатель

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

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

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

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

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

POST /api/cases/:caseId/workflows
x-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 покрывает инфраструктурное ПО - но управление рабочими процессами для персонализированной терапии под это описание подпадает или нет?

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

Ссылки

Комментарии (0)