1 октября 2019 Блог

Почему платформа для проведения клинического исследования не может быть бесплатной или дешевой?

Часть 1. Валидация

Как и все прогрессивное сообщество, вовлеченное в проведение клинических исследований, я с нескрываемой радостью наблюдаю за работой комиссии по противодействию фальсификации научных исследований РАН. Коллеги последовательно и методично отстаивают принципы доказательной медицины и популяризируют клинические исследования (КИ).  В свою очередь мы, производители инструментов, обеспечивающих проведение клинического исследования в соответствии с регуляциями и протоколом, сталкиваемся с такими же точно проблемами и такими же до боли знакомыми по общему небрежному отношению к доказательной медицине, вызовами.  Мне стало больно, что инструментальная часть до сих пор остается в тени, поэтому я решил написать цикл статей в наш корпоративный блог. 
 
Программное обеспечение, предназначенное для сбора, обработки и анализа данных КИ, не только должно соответствовать формальным (например, GCP), логическим и отвечающим здравому смыслу требованиям по функционалу: обеспечивать целостность и непротиворечивость данных, содержать документальный след, устаревание пароля, строгий доступ и т. п. ( [1],[2]). Не менее важно, чтобы такой софт был валидирован.  Несколько предыдущих десятилетий научили инженеров, что валидация - это не только аккуратное тестирование программного продукта и даже далеко не сама программа. Причина очень простая: работа с рисками. Качество любой инженерной системы равно качеству ее самого низкокачественного элемента. Вы можете создать великолепный продукт, разработать его от и до по всем канонам классической V-модели, обложить с ног до головы тестами, но не обучить исследователя работе с ним. Риск? Формальный - серьезная находка инспекции. Реальный - неправильно собранные данные, потеря драгоценного времени и, как следствие, денег, затраченных на КИ. Поэтому, когда говорят о валидации, всегда подразумевают - нет, не саму программу, - а компьютеризированную систему.
 
Что такое компьютеризированная система?
 
1. Это команда - аналитики, архитекторы, инженеры, программисты, тестировщики, а также Product Owners, Scrum Masters, консультанты, проектные менеджеры, координаторы и, конечно, специалисты по качеству и валидации, а также другие члены команды, которые правильным образом прошли обучение, на периодической основе подтверждают свои знания, правильным образом квалифицированы, и это определенным образом обосновано. Что не менее важно, сама система, с помощью которой они получают новые знания или проходят переобучение, тоже должна быть валидирована. Как говорится, поделись рекурсией своей, и она к тебе не раз еще вернется.

2. Это определенным образом выстроенная система качества - те самые SOP’ы, формализованные процессы обучения, процедуры доступа к данным, требования к IT системам, безопасности, правила работы и даже действия на случай непредвиденных обстоятельств. И многое другое.

3. Это инфраструктура. IT Environment. И это не значит, что если вы установили свой сервер (контролируемую среду) в дата центре уровня Tier III, то волшебным образом это будет надёжным решением и обеспечит вам инфраструктурный уровень валидации. Весь этот процесс начинается от сложного обоснования выбора методологии распределенного и безопасного хранения. Затем стратегии резервного копирования с процедурой оценки риска при выборе вендоров. А заканчивается детальным логированием доступа и строгим периодическим тестированием по Disaster Recovery Procedure. Это разделение сред - Dev, QA, Pre-prod, Production и т. д. Обычно сюда же относят соответствие IT-инфраструктуры применимому законодательству, например о защите персональных данных в определенной локации (для Европы - GDPR, для России - ФЗ-152).

4. Само по себе приложение. Помимо следования стандартному и утвержденному набору функционала ([1]), оно должно быть правильным образом документировано, описано, систематизировано, разработано, протестировано, опубликовано, отработано (привет, валидированная Jira). Определенным образом на всех этапах должны быть оценены риски.  Это инструкции. Это сценарии тестирования. Это риск-обоснованная процедура внесения изменений в приложение, это контроль. Это достаточно строгий формализованный пакет документов (см. GAMP 5 [3]). И многое, нет, многое-многое другое.

5. Это конечный пользователь - если во всей этой прекрасной действительности конечный пользователь не обучен правильной работе с системой и не имеет немедленного доступа к службе поддержки (да-да, система службы поддержки тоже должна быть валидирована) и к руководству пользователя на понятном ему языке - система разваливается. Чтобы система гордо носила статус валидированной, пользователь должен быть включен в общий процесс.
 
Что еще немаловажно. Как нельзя быть немножко беременной, так и нельзя быть частично валидированным. Ни о какой "валидированности" продукта не может идти речи, если хотя бы один из этих пунктов не соблюдён. Более того, производители, которые утверждают, что их софт уже валидирован, мягко говоря, лукавят - хотя бы потому, что один из важнейших процессов и неотъемлемая составляющая той самой компьютеризированной системы - конечный пользователь.
 
Ваша система НЕ валидирована, если:
 
1. Не был обоснован и формализован процедурами компании выбор поставщика, в подавляющем большинстве случаев включающий проведение аудита провайдера программного обеспечения;
2. Компания не получила пакет валидации [4];
3. Не был пройден UAT [5];
4. Не проведено обучение всех пользователей системы;
5. В системе качества компании, использующей программный продукт, не приняты процедуры, описывающие весь цикл использования системы.
 
 
Не обсуждая все остальные компликации по созданию сложной инженерной системы, может ли система, создаваемая и требующая подобных подходов к реализации и обслуживанию, стоить дешево? Вопрос риторический. К сожалению, в РФ мы часто встречаемся с альтернативной реальностью. Бесконечно больно, когда в клиническом исследовании, даже с качественным и продуманным протоколом, мы видим сбор и обработку данных в хорошем, но совершенно не отвечающем требованиям отрасли, а порой и здравому смыслу, Microsoft Excel. Или использование ворованных систем - абсолютное большинство условно-бесплатных платформ для КИ предназначены только для некоммерческого использования в академической науке. И одна из причин в том, что даже хорошо оттестированное приложение не эквивалентно валидированному. Не менее грустно выглядят хорошие платформы, кое-как установленные доморощенными эникейщиками по наитию в эрзац-сервер в офисе.
 
Хотя валидация на старте выглядит как проект, сопоставимый по объемам со строительством БАМа, при должном желании вполне реализуема. В следующих статьях я постараюсь подробнее раскрыть детали валидации компьютеризированных систем для использования в клинических исследованиях. Описать регуляции, работу с рисками, рассказать о подготовке к аудитам и инспекциям, а также методологию и подходы в разработке программного обеспечения для нашей отрасли.
  
[1] FDA Title 21 CFR Part 11
[2] ГОСТ Р 52379-2005 Надлежащая клиническая практика
[3] ISPE GAMP® 5 Guide: A Risk-Based Approach to Compliant GxP Computerized Systems
[4] https://datamanagement365.com/services/validation/
[5] User Acceptance Testing 

Тимур Галимов