Preview

Качественная клиническая практика

Расширенный поиск

Валидация электронных систем сбора данных «Оценок Результатов Пациентами» - Рекомендации для клинических исследователей: отчёт Целевой Группы ISPOR по надлежащей исследовательской практике валидации ePRO систем

Полный текст:

Аннотация

Литература об исследовании исходов лечения изобилует примерами высококачественных, надёжных данных оценок результатов пациентами (Patient-Reported Outcomes, PRO), введённых исключительно электронными методами, ePRO, которые сравниваются с данными, вводившимися с «бумажных носителей». Менеджеры клинических исследований всё чаще используют сбор данных с помощью ePRO для получения результатов, основанных на PRO. Проверка регуляторных документов позволяет определить правила, которым необходимо следовать, чтобы собирать данные с помощью ePRO в соответствии с требованиями ведения медицинской документации. Критический компонент соблюдения нормативных требований - это свидетельство о валидации (evidence of the validation) системы сбора электронных данных. Валидация (validation) электронных систем - это процесс в отличие от сконцентрированной деятельности (focused activity), которая совершается в определённый момент времени. Валидация программного продукта для сбора данных предусматривает описание и выполнение в условиях его целевой среды следующих восьми шагов: описание требований к системе (requirements definition), дизайн (design), кодирование (coding), тестирование (testing), прослеживание процесса (tracing), тестирование на приемлемость для пользователя (user acceptance testing), установка (installation) и конфигурирование системы (configuration), а также списание (decommissioning). Указанные элементы согласуются с последними руководствами регуляторных органов по валидации систем. Этот отчёт был написан, чтобы объяснить, каким образом процесс валидации работает для спонсоров, клинических исследователей и прочих пользователей устройств по сбору электронных данных, ответственных за проверку качества данных, вводимых в реляционные базы данных посредством подобных устройств. Это руководство устанавливает 2 документальных требований, необходимые системному провайдеру системы сбора данных для демонстрации валидности системы. Это практический источник информации для исследовательских групп, позволяющий убедиться, что поставщики ePRO используют те способы валидации системы и реализации процессов, которые гарантируют, что системы и сервисы работают надёжно на практике, производят точные, полные и целостные данные (файлы данных), поддерживают административное управление и соответствуют текущим регуляторным требованиям. Более того, этот короткий отчёт улучшит понимание требований пользователя к технической валидации, что ведёт к более информированным и сбалансированным рекомендациям или решениям по вопросам методов сбора электронных данных.

Для цитирования:


Zbrozek A., Hebert J., Gogates G., Thorell R., Dell C., Molsen E., Craig G., Grice K., Kern S., Hines S., Павлыш А.В., Топоров А.А., Вербицкая Е.В., Колбин А.С. Валидация электронных систем сбора данных «Оценок Результатов Пациентами» - Рекомендации для клинических исследователей: отчёт Целевой Группы ISPOR по надлежащей исследовательской практике валидации ePRO систем. Качественная клиническая практика. 2015;(2):3-18.

For citation:


Zbrozek A., Hebert J., Gogates G., Thorell R., Dell C., Molsen E., Craig G., Grice K., Kern S., Hines S., Pavlysh A.V., Toporov A.A., Verbitskaya E.V., Kolbin A.S. Validation of Electronic Systems to Collect Patient-Reported Outcome (PRO) Data - Recommendations for Clinical Trial Teams: Report of the ISPOR ePRO Systems Validation Good Research Practices Task Force. Kachestvennaya klinicheskaya praktika. 2015;(2):3-18. (In Russ.)

История создания Целевой Группы

Целевая Группа ISPOR по надлежащей исследовательской практике валидации ePRO-систем была сформирована из созданной ранее рабочей группы по данному вопросу и утверждена советом директоров ISPOR в марте 2011 года. Руководящая часть Целевой Группы состояла из экспертов в области электронных систем сбора данных с опытом работы в разработке дизайна, контроле качества и регуляторных вопросах, а также имеющих опыт работы в клинических исследованиях. Группа встречалась дважды в месяц для разработки общей схемы достижения конечной цели: информирования пользователей о требованиях к уровню качества и содержанию валидированных систем сбора данных. Авторы работали группами и поодиночке над разными частями отчёта, которые позже были рассмотрены Целевой Группой в полном составе для комментариев и замечаний.

Как только был подготовлен первый вариант отчёта, его отправили на ознакомление 400-м членам наблюдательной группы ISPOR PRO и представителю FDA (Управления по контролю качества пищевых продуктов и лекарственных средств), знакомому с темой. Кроме того, к этому моменту работа была представлена для комментариев в виде презентации на 16-м конгрессе ISPOR в Балтиморе, США. Члены ISPOR внесли свой вклад в этот отчёт, добавив письменные комментарии во время ознакомления и устные комментарии во время презентации. Авторы ещё несколько раз вычитывали отчёт и отправили финальную версию членам наблюдательной группы ISPOR PRO, одновременно с этим пригласив к ознакомлению ISPOR в полном составе.

Все комментарии, большинство из которых оказались существенными и конструктивными, были рассмотрены основателями Целевой Группы и сочтены уместными. Дальнейшие дополнения были внесены благодаря полученным отзывам, и как только все авторы между собой пришли к соглашению, окончательный вариант отчёта был опубликован в журнале «Value in Health».

Письменные комментарии и список рецензентов опубликованы на сайте ISPOR на странице Целевой Группы: http://www.ispor.org/sigs/ePROsystemvalidationsg.asp. Отчёт Целевой Группы и интернет-страницу можно также найти на домашней странице ISPOR (www.ispor.org), выбрав лиловое меню «Research Tools» (Инструменты исследования), а в нём раздел «Good Practices for Outcomes Research» (Надлежащая практика изучения исходов).

Введение

Опыт пациентов в оценке эффективности и безопасности медицинских продуктов, в особенности лекарственных средств и медицинских изделий, приобретает всё большее значение. Он дополняет применение клинических оценок, объективную статистику, к примеру, долю выживаемости, и прочие традиционные индикаторы клинической действенности и безопасности. Клинические исследователи постоянно включают «оценки исходов по отчётам пациентов» («оценки результатов пациентами» (Patient-Reported OutcomesPRO)) в программу клинических исследований, поскольку это помогает измерить эффект медицинского продукта на такие факторы как тяжесть симптома и физическая или психическая функция. Данные PRO могут быть первичной или вторичной конечной точкой в определении действенности лечения. В некоторых случаях, таких как оценка утомляемости или боли, PRO может оказаться единственной реальной конечной точкой, поскольку в этих случаях не существует маркеров болезни или активности лечения, которые смог бы измерить исследователь, наблюдатель или лаборатория [1].

Согласно определению FDA, PRO – это «любой отчёт о состоянии здоровья пациента, который исходит напрямую от пациента без интерпретации ответа пациента врачом или кем-либо ещё» [2]. Измерения можно проводить как в абсолютных (например, тяжесть признака, симптома или состояния здоровья), так и в относительных значениях – в рамках изменений со времени последнего измерения [2]. В статье ЕМА (Европейское Медицинское Агентство), отражающей регуляторные требования к использованию Шкал Оценки Качества Жизни, PRO определяется как «любой исход, напрямую оценивающийся пациентом и основывающийся на восприятии пациентом болезни и её лечения» [3]. Проще говоря, PRO – это последствия болезни и её лечения, о которых докладывает пациент [1].

В клинических исследованиях для органов контроля следующим по важности после вопроса о безопасности пациента является вопрос о качестве данных и их достоверности [4]. С точки зрения спонсора клинического исследования, целостность и качество данных имеют решающее значение в вопросе надёжности исследования, равно как и соблюдение требований FDA, EMA и прочих надзорных органов. Готовность FDA принять данные клинических исследований в целях принятия регуляторных решений зависит от их способности подтвердить качество и целостность данных во время инспекций и аудитов FDA [5].

Менеджеры клинических исследований всё чаще используют ePRO (электронный сбор данных PRO напрямую от пациентов) для формирования конечных точек на основе PRO. ePRO ведёт к улучшению качества и полноты данных, снижению субъективного и административного влияния, так же обработку алгоритмов перехода внутри данных (skip patterns) [1, 6]. Электронный сбор данных приносит более надёжную и точную информацию, позволяет проводить более глубокое тестирование объектов исследований и позволяет увидеть более правильную картину опыта пациента [6]. Регуляторные документы определяют правила, по которым должен проходить электронный сбор данных. Вне зависимости от того, использует ли специалист, проводящий исследование, электронный или бумажный опросник для сбора данных, основные принципы, касающихся точности данных (например, возможность оперативного контроля и отслеживаемость изменений) необходимы к соблюдению как в электронных, так и в бумажных версиях.

Для демонстрации того, что субъекты интерпретируют и отвечают на вопросы/элементы PRO одинаково вне зависимости от способа сбора данных, требуются доказательства [1, 5]. Процедура изменения способа сбора данных, а также оценка эквивалентности измерений обоими способами уже были описаны в предыдущем отчёте Целевой Группы ISPOR по PRO: «Рекомендации по мерам предоставления доказательств, необходимых для подтверждения эквивалентности измерений оценок результатов пациентами в электронном и бумажном виде: отчёт Целевой Группы ISPOR по надлежащей исследовательской практике в ePRO» [1].

Вне зависимости от типа администрирования (самостоятельно или с помощью интервьюера) или метода электронного сбора данных (приспособлений, использующихся для фиксирования данных: система интерактивного голосового управления (interactive voice response systems), ввод данных через интернет-портал (Web-based data entry) или устройство ePRO (ePRO devices)), валидация системы должна соответствовать стандартам FDA и EMA. Это происходит во время валидации процесса разработки, поддержки и работы устройства и компьютерной системы [5-7]. Проще говоря, должны существовать доказательства, что процесс идёт так, как должен. Например, если на экран с помощью устройства ввода данных или сенсорно вводится число «5», ответ субъекта должен точно соответствовать значению из базы данных – правильно фиксируясь как «5» в самой базе.

В случае с ePRO это осложняется тем фактом, что существующие правила и руководства изначально разрабатывались для бумажных опросников и дневников. В настоящий момент единого метода разработки и внедрения, предписанного к использованию регуляторами этой сферы, нет. В связи с отсутствием специальных правил или руководств от этих органов о том, как именно должна проводиться валидация систем ePRO, было решено опираться на похожие стандарты из других руководств по схожим темам, например, таким как валидация систем, используемых для разработки медицинских устройств. (Дополнительные материалы о правилах в отношении клинических исследований, разработки и валидации систем ePRO можно найти по ссылке http://dx. doi.org/10.1016/j.jval.2013.04.002.)

Существует два способа поставки программного обеспечения (ПО) для ePRO, каждый из которых нуждается в собственном методе валидации. Первый – это традиционный метод заказного ПО – для каждого клинического исследования разрабатывают отдельное ПО. Допустимо использование частей кода существующего ПО. Вся система проходит через набор жёстких валидационных тестов, прежде чем ее устанавливают для использования в исследовании [8]. Второй вариант – это платформа, созданная подрядчиком, которую адаптируют и перенастраивают для каждого исследования. Платформа такого рода проходит весь набор строгих валидационных тестов во время изначальной разработки. Этот метод позволяет валидировать только процедуры адаптации платформы к конкретному исследованию. Оба метода поставки имеют свои преимущества. Один позволяет сохранять полную гибкость, но за большую стоимость, и процесс разработки требует больше времени; в то время как другой позволяет ускорить разработку и снизить затраты, за счёт ограничения гибкости системы.

Основная цель этого отчёта – помочь понять техническую природу систем ePRO и процесса проверки систем ePRO, в связи с тем, что техническая сторона валидации систем ePRO и регуляторные требования к валидации могут быть не вполне ясны спонсорам проекта и членам исследовательской группы. Процесс валидации ePRO определяет ответственность, которую делят между собой системный провайдер ePRO и спонсор, который использует ePRO. Важно понимать природу этой ответственности, и каким образом она должна быть разделена.

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

Кроме того, данный отчёт поможет в понимании усилий, требуемых от спонсора, чтобы дополнить процесс валидации, которые предлагает системный провайдер. Когда системный провайдер ePRO просто предлагает устройство и систему данных, но не предлагает своих услуг по её валидации, груз выполнения этих обязательств ложится на спонсора. Заметим, что в настоящем отчёте термин «спонсор» относится к группе клинического исследования, работающей с поставщиком ePRO. Эти рекомендации пригодятся в равной мере контрактно-исследовательской организации (CRO) и любой другой организации, сотрудничающей с системным провайдером ePRO, чтобы создать систему ePRO, которую можно будет использовать в предрегистрационных исследованиях медицинских продуктов. Общие принципы, изложенные в этом отчёте, могут быть применены и к другим исследования, в которых субъекты используют электронные средства для ввода данных в виде ответов на вопросы.

И наконец, в отчёт включены подходящие регуляторные правила, так как в данном случае требуется строгое соответствие стандартам в этих процессах и во время проведения самого исследования. Приложение 1 в Дополнительных материалах, которые можно найти по ссылке http://dx.doi.org/10.1016/j.jval.2013.04.002, включает в себя международные стандарты проведения клинических исследований, а также основные правила и инструкции FDA и EMA относительно разработки систем ePRO и их валидации для клинических исследований.

Основные принципы и определения валидации

В Руководстве FDA по общим принципам процесса валидации от 1987 г. содержится следующее определение валидации:

  • установление документального свидетельства, подтверждающего высокий уровень уверенности, что данный конкретный процесс на постоянной основе производит продукт, который удовлетворяет всем предварительно заданным спецификациям и атрибутам качества [9].

Руководство 2011 года «Отраслевой процесс валидации: общие принципы и практика», подтверждает эти основные принципы и вносит в них изменения, соответствующие XXI-му веку. В настоящее время определение валидации выглядит так:

  • сбор и проверка данных, с момента разработки концепции до выхода коммерческого продукта, который является научным свидетельством, что процесс способен на постоянной основе производить качественный продукт. Процесс валидации состоит из серии мероприятий, предпринимающихся на протяжении всего времени существования продукта и процесса [10].

Процесс валидации системы охватывает полный жизненный цикл разработки системы, от возникновения идеи до разработки, тестирования и релиза, с учётом последнего этапа – вывода из эксплуатации (списания). Согласно Руководству по надлежащей производственной практике (Good Manufacturing Practice, GMP) в ЕС, компьютеризованное руководство к системе, документация о валидации и отчёты должны описывать каждый шаг жизненного цикла системы. Производители ПО (в данном случае поставщики ePRO), должны иметь возможность подтвердить свои стандарты, протоколы и критерии приемлемости процедур и записей на основе оценки рисков [11]. Руководство FDA говорит о том же, рекомендуя объединить управление жизненным циклом ПО и управление рисками с проверкой и верификацией действий, предпринятых на протяжении всего жизненного цикла ПО [12].

Важно заметить, что валидацию не прекращают, когда ПО готово к выпуску или находится «на полке». Валидация – это не последний этап действий в какой-то конкретный момент, а статус соответствия, поддерживаемый системой управления качеством на протяжении всего цикла жизни ПО [7, 12]. Чтобы поддерживать статус валидации, необходимо с вниманием отнестись к документированию любых изменений и повторному исполнению любых необходимых валидационных процедур, пока система находится в действии – вплоть до момента выведения её из эксплуатации.

Валидация последовательно начинается с составления документации с описанием требований к системе и включает следующие шаги: дизайн (design), кодирование (coding), тестирование (testing), отслеживание исправления данных (tracing), тестирование на приемлемость для пользователя (user acceptance testing, UAT), установка (installation) и конфигурация (configuration), выведение из эксплуатации (decommissioning). Любые разработки ePRO должны соответствовать стандартному списку проектных документов, представленных в описанной ниже очередности.

Процесс валидации: основные составляющие. Жизненный цикл развития системы – это последовательность действий, задач, обязательств и отчётных материалов, необходимых для разработки высококачественной валидированной системы электронного сбора данных. Методология жизненного цикла развития системы, используемая поставщиком ePRO, должна быть тщательно изучена, чтобы определить, включает ли она в себя как минимум следующие критически важные элементы:

  1. Требования системы (системные требования).
  2. Дизайн системы.
  3. Кодирование/адаптация/разработка ПО.
  4. Трассировка (прослеживание).
  5. Тестирование на приемлемость для пользователя.
  6. Управление установкой/конфигурацией.
  7. План выведения из эксплуатации.

Требования системы

Что это такое? Цель создания документации требований системы – описать все аспекты системы, вне зависимости от использованной технологии. Получившаяся документация покроет нужды Протокола исследования, целевой группы пациентов и персонала медицинского учреждения. Её нужно будет формально утвердить до начала разработки системы [13].

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

1) группе клинического исследования требовать внесения изменений в тот момент, когда ePRO существует только на бумаге – т.е., когда внести изменения можно быстро, малорискованно и недорого;

2) команде системного провайдера получить ясное и полное описание системы, которую потребуется спроектировать, разработать и произвести. Например, программистам, авторам стратегии тестирования и разработчикам нужна детальная картина каждого аспекта системы, чтобы выполнить свои обязательства по валидации системы и убедиться, что их собственные отдельные компоненты совпадают с компонентами других членов команды должным образом, что позволит разработать для исследования высококачественную систему;

3) как группой исследования, так и поставщиком ПО будут заданы одинаковые ожидания к системе, понятные в равной мере всем участникам. Это особенно важно при тестировании системы на приемлемость для пользователя (UAT) и использовании системы в исследовании (подробнее будет изложено ниже).

Прочие названия для этой документации.

Также этот раздел, помимо прочего, может называться «требованиями пользователя», «функциональными требованиями», «спецификацией пользователя». Документация может представлять собой один или несколько документов. Вне зависимости от её состава, для обеих сторон важно, чтобы в документации было предельно ясное и подробное описание всех аспектов системы [13, 14].

Вовлечённость группы клинического исследования

Участие этой группы необходимо на стадии составления требований и подбора определений, независимо от того, будет ли система ePRO разрабатываться внутренне или её будет разрабатывать внешний поставщик.

Те группы клинических исследований, у которых нет опыта написания документов по системным требованиям, для того, чтобы его написать, обычно, опираются на опыт системного провайдера ePRO, консультанта или технических экспертов в собственной организации. Группа клинического исследования предоставляет указанным экспертам Протокол клинического исследования. В большинстве случаев, группа встречается с авторами документа о системных требованиях, чтобы определить, как система должна работать, чтобы соответствовать требованиям Протокола, а также требованиям пользователей в клинических сайтах, целевой аудитории пациентов и заинтересованные стороны от организации-спонсора. Заинтересованные стороны от организации-спонсора включают клинические процедуры, менеджмент данных, биостатистику, исследование исходов или анализ стоимости лечения и соответствие нормативным требованиям [14].

С группой клинического исследования обсуждаются вопросы, которые включают в себя последовательность экранных изображений (индивидуальный дизайн страниц для более точного отображения элементов PRO), изменение полей ввода данных, требования по переносу данных, формат файла данных, требования безопасности и соответствие Правилу 21 CFR часть 11 FDA об электронных записях [15], электронные подписи и множество других деталей. Спонсор должен перевести регуляторные требования на язык системной функциональности от доступа к данным до составления отчётов и сроке их хранения для аудита и проверок [6].

Когда предварительная версия документа о системных требованиях готова, необходимо, чтобы группа клинических исследований провела его вдумчивое рассмотрение и подготовила обратную связь, чтобы запросить любые необходимые изменения. Эти изменения по требованию спонсора должны быть внесены в соответствии с оговорёнными сроками, чтобы не менять срок поставки продукта. Если группа клинических исследований и системный провайдер ePRO удовлетворены документом о системных требованиях, считая, что он полностью и точно включает в себя все детали информации о системе, основные члены исследовательской группы подписывают этот документ, подтверждая таким образом своё согласие и удовлетворение. Основные члены команды системного провайдера также подписывают этот документ в знак подтверждения их согласия и готовности предоставить систему в описанном виде [13, 14].

Почему это важно? Документация о системных требованиях – это основа всех последующих процессов валидации системы и получаемых результатов. Если её разделы описаны неразборчиво, двояко или вовсе отсутствуют, их можно будет интерпретировать по-разному, что приведёт к недопониманию между группой клинического исследования и группой системного провайдера ePRO. Эта разница обнаружится только позже, на стадии тестирования на приемлемость для пользователя, что может закончиться задержкой при наборе пациентов, создаёт риск для обеспечения качества и стабильности ПО, и вызовет проблемы с функциональностью и недостатками работы ПО во время проведения исследования. Таким образом, крайне важно, чтобы этот документ был точным, ясным, правильным и полным [13, 14, 16].

Минимальное содержание

Документация с системными требованиями должна включать в себя всё необходимое для обеспечения чёткого, детального описания системы. Как минимум, они должны показывать и/или точно описывать все аспекты системы, влияющие на пользователей, включая выбранный инструментарий, снимки экрана (карманный персональный компьютер (КПК), планшет или другое сетевое устройство), голосовые подсказки (система интерактивного голосового управления), поля ввода данных, проверку редактирования, сообщения об ошибках, логику навигации, поведение всех кнопок (КПК, планшета или другого сетевого устройства), алгоритмы, сигнализацию, тайм-ауты, функции безопасности, контрольный журнал, электронные подписи, предупреждения (сообщения о необходимости обратить внимание) субъектов, сотрудников сайта и дизайн отчёта. Текстовые описания этих элементов должны идти в сопровождении графики, если это необходимо для полной ясности.

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

1) цели и задачи;

2) определения;

3) справочные документы;

4) допущения;

5) системы и технологические потоки, в том числе блок-схемы, которые показывают последовательность экранов и связанную с ними логику всей системы;

6) функциональные требования. Последний раздел – «сердце» документа – может быть длиннее прочих, зачастую за него отвечает группа пользователей (например, Системные требования для сотрудников клиники), но может быть составлен в любой форме, которая делает его лёгким для понимания.

Краткое описание функциональных требований в документации о системных требованиях – пример того содержимого, которое стоит ожидать на первом экране в разделе, описывающем последовательность экранов для пациентов. За каждым элементом в структуре следует чёткое и подробное описание.

Функциональные требования

Раздел 1 – последовательность экранов для пациента

  1. Первый экран – логин пациента
  2. Снимок экрана
  3. Данные на баннере экрана

1) Дата

2) Время

  1. Поля ввода данных
  • PIN-код пациента
  • Проверка на 4-х-символьное цифровое сообщение об ошибке
  • Проверка, совпадает ли PIN-код и сообщение об ошибке
  1. Кнопки навигации
  • Кнопка «Отмена»
  • Данные не сохраняются

2) Система возвращает пользователя к предыдущему экрану

  • Кнопка «OK»

1) Проверка номера введённого ПИН-кода

2) Система переводит пользователя на следующий экран

Важные процессы управления качеством проекта, о которых следует знать

Первый важный шаг в разработке высококачественных системных требований для группы системного провайдера и исследовательской группы – внимательно прочитать и изучить Протокол исследования и другие документы, описывающие исследование и стандарты спонсора. После чего основные члены группы системного провайдера должны провести подробное и продуманное обсуждение предъявляемых требований, чтобы определить, как именно группе клинических исследований необходимо, чтобы программа работала, чтобы поддерживать этот Протокол, качество и целостность данных, клинические сайты и персонал [13, 14]. Отдельно следует напомнить участникам, что нужно найти компромисс между сроками, стоимостью и качеством. Чем больше функций будет включено в систему, тем больше времени займет её разработка и проверка, и тем дороже это обойдется.

Обсуждение требований должно сопровождаться созданием первого чернового варианта документа системных требований. Этот первый черновик должен быть внимательно прочитан членами обеих групп. Ещё одно совместное обсуждение должно повлечь за собой решение вопроса, где и каким образом группа клинического исследования будет обеспечивать обратную связь и запросы о внесении изменений [6, 13, 14]. Процедура сбора требований, как правило, требует, по крайней мере, две ревизии первого черновика, чтобы создать окончательную документацию системных требований. Если рамки утверждённой системы требований превышают первоначальные предположения при планировании проекта, в план проекта могут быть внесены изменения, которые могут повлиять на график и бюджет исследования. Системный провайдер должен обеспечить контроль качества при производстве документации системных требований таким образом, чтобы независимая сторона ознакомилась с финальной версией документации системных требований прежде, чем её представят группе клинического исследования.

Дизайн (проект) системы

Что это такое? Этап проектирования включает в себя разработку проектной документации системы, обеспечивающей полное, чёткое, подробное техническое описание, каким образом система ePRO будет разрабатываться с учётом удовлетворения потребностей Протокола и пользователей. Проектная документация необходима, чтобы объяснить разработчику, что должно быть включено, а что выходит за рамки системы. Эта документация должна охватывать как контекст, в котором система будет работать, так и детали, необходимые, чтобы освободить разработчика от неопределённости в вопросе построения системы [13, 14].

Системный провайдер ePRO отвечает за разработку большей части этой документации. Спонсору или CRO, ответственным за «подгруздку» данных ePRO в базу данных исследования, может потребоваться предоставить спецификации для переноса файлов данных системному провайдеру ePRO, чтобы их можно было использовать при создании/настройке модуля передачи данных.

Специалисты по разработке программного обеспечения используют проектную документацию системы, чтобы писать программы и/или задавать значения технических параметров для системы ePRO. Некоторые системы ePRO используют базовую систему, настроенную для использования в конкретном исследовании с применением параметров и настроек, с минимальными изменениями исходного кода в дополнение к базовой системе.

Первоначальная концепция требований к жизнеспособной системе может пересматриваться, как только система будет создана и подвергнута модульным тестам. После создания системы, авторам проектной документации необходимо эффективно общаться с группой клинического исследования и группой разработчиков программного обеспечения, чтобы гарантировать, что проект системы, введённый в эксплуатацию, по-прежнему соответствует требованиям пользователей [17].

Проектная документация

Документация по системному дизайну должна описывать три основные функции, которые соответствуют непосредственно следующим модулям в типичной системе ePRO:

  • сбор и хранение данных (сбор данных по любой из нескольких технологий, которые будут храниться на сервере, контролируемом провайдером системы ePRO);
  • веб-портал и оповещения (позволяющие исходным данным на сервере отображаться, отчётам создаваться, а предупреждениям – запускаться и рассылаться пользователям);
  • трансфер данных (преобразование сохранённых данных в файлы передачи для отправки спонсору или его CRO).

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

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

Почему это важно? Проектная документация системы является мостом между требованиями системы и разработчиками программного обеспечения. Создание этой документации является важным шагом для того, чтобы усилия по разработке программного обеспечения привели к решению, устраивающему пользователей системы и совместимому с клиническим протоколом [6, 13, 14].

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

Раздел документации о проектировании модуля «системы сбора данных» необходим, чтобы упорядочить детали, которые ещё не вошли в документацию системных требований по таким темам, как:

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

Кроме того, проектная документация должна содержать следующие детали, которые не вошли в документацию системных требований:

1) детали процессов отправки данных на сервер, алгоритмы и методы, доступные для отправки данных, в том числе процессов управления для обеспечения того, чтобы отправляемые данные являлись полными, точными и не дублировались;

2) детали процессов обработки частичного/неполного сохранения данных на сервер (например, в случае «отката системы»).

Раздел «веб-портал» должен освещать следующие вопросы документации, которые ещё не вошли в документацию системных требований проекта:

  • вход в систему и пароль безопасности;
  • группы безопасности и их влияние на доступ к данным;
  • отображение клинических данных, в том числе необработанных данных, метаданных и аудита;
  • отображение отчётов и переходов между ними, стандартного и кастомизированных (разработанных по запросу пользователя);
  • оповещения для пользователей и логика их переключений;
  • другие процессы (такие как автоматизация логистики устройства или запросов на изменение данных).

Раздел «передача данных» должен содержать следующие детали, которые не вошли в документацию системных требований:

  • синхронизация, частота и способ передачи данных;
  • множество элементов данных для передачи и их формата;
  • процесс преобразования данных в формате, определённом спонсором или его CRO;
  • процессы управления для обеспечения того, чтобы переданные данные являлись полными, точными и не дублировались.

Важные процессы управления качеством проекта, которые следует иметь в виду

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

Кодирование/адаптация/разработка программного обеспечения

Что это такое? Процесс кодирования/адаптации/разработки ПО представляет собой процесс написания кода ПО на языке программирования или сборки и настройки модулей кода, которые уже были разработаны для удовлетворения потребностей данного конкретного исследования.

Почему это важно? Эти процессы являются блоками создания компьютерной системы, которая будет использоваться в клиническом исследовании. Правильное исполнение и документирование процесса поможет в создании систем, которые относительно просты в обслуживании и легко могут пройти проверку третьими лицами [12].

Вовлечённость группы клинического исследования. Отсутствует. Группа клинического исследования в процессе не участвует, поскольку процесс носит сугубо технический характер. Как правило, группа клинического исследования общается с разработчиками через менеджера и/или аналитика проекта, который гарантирует, что проектные требования правильно переведены на язык спецификаций для разработчиков.

Важные моменты управления качеством проекта, о которых следует знать. Как и в любом процессе, цель заключается в выявлении каких-либо проблем или дефектов как можно раньше и обеспечении их скорейшего решения [11]. В разработке должна присутствовать проверка выполненного кода, которая может быть выполнена одним или несколькими техническими экспертами, которые понимают языки и стандарты используемого метода разработки (так называемый «просмотр кода»). До введения нового фрагмента кода в общую структуру проекта исследования, разработчику (или его коллегам) следует проверить отдельные модули на предмет того, выполняются ли они должным образом и отвечают ли требованиям проекта, ограничениям и изначальным предположениям (так называемый «юнит-тестинг» или «тестирование модулей») [18].

Обнаружение каких-либо ошибок, вызванных качеством процесса при разработке программного обеспечения, должно быть задокументировано с указанием информации об условиях, при которых ошибки произошли, для возможности их последующего воспроизведения. См. Приложение 2, Описание процесса обеспечения качества, в Дополнительных материалах на http://dx.doi.org/10. 1016/j.jval.2013.04.002. Ошибкам должен быть присвоен определённый статус (например, открыт/назначен/исправлен/закрыт), чтобы они могли быть исправлены в системе и проверены второй стороной, прежде чем они могут считаться решёнными. Пока система находится в разработке, должна существовать возможность проследить за создаваемым кодом или модулями, использованными в отдельных элементах дизайна.

Тестирование ПО системным провайдером

Что это такое? Тестирование по всем пунктам, описанным в документации системных требований, имеет решающее значение для того, чтобы убедиться, что новая система соответствует всем ранее оговорённым требованиям. План тестирования описывает такую стратегию тестирования окружающей среды и подходы, которые имитировали бы реальные условия. Он также содержит полный набор тестов для покрытия всех потребностей системы [7, 13].

Вовлечённость группы клинического исследования. Отсутствует. Группа клинического исследования не участвует в процессе тестирования; это ответственность системного провайдера.

Почему это важно? Программы, необходимые для обеспечения систем для клинических исследований, состоят из многих тысяч комплексно взаимосвязанных строк кода. Даже при участии опытных, преданных делу программистов, которые осуществляют высококачественный процесс кодирования, сложность большинства систем для клинических исследований практически гарантирует, что ранние версии системы не будут работать в полном соответствии с документацией по системным требованиям. Каждая часть системы должна быть тщательно проверена.

Тестирование системы осуществляется после составления детального плана тестирования и самих тестов. Тщательно выполненный план тестирования гарантирует, что система в течение клинических исследований будет работать как положено [7, 13].

Минимальное содержание. Наиболее важными разделами плана тестирования качества являются стратегия тестирования и примеры тестов.

  • Стратегия тестирования. В этом разделе, как правило, разработанном лидерами команды тестирования, должна быть задокументирована стратегия тестирования системы в условиях, максимально приближенных к реальному исследованию. Нап

Об авторах

Arthur Zbrozek
Global Health Economics, CSL Behring, Biotherapies for Life, King of Prussia, PA
Соединённые Штаты Америки


Joy Hebert
PHT Corp, Boston, MA
Соединённые Штаты Америки


Gregory Gogates
CRF Health, Plymouth Meeting, PA
Соединённые Штаты Америки


Rod Thorell
PHT Corp, Charlestown, MA
Соединённые Штаты Америки


Christopher Dell
ERT, Philadelphia, PA
Соединённые Штаты Америки


Elizabeth Molsen
International Society for Pharmacoeconomics & Outcomes Research (ISPOR)
Соединённые Штаты Америки


Gretchen Craig
ERT, Inc., Pittsburgh, PA
Соединённые Штаты Америки


Kenneth Grice
Global Electronic Data Capture, Bayer HealthCare Pharmaceuticals, Inc., Montville, NJ
Соединённые Штаты Америки


Scottie Kern
Sacaja Consulting Ltd., Wiltshire
Великобритания


Sheldon Hines
ICON Late Phase & Outcomes Research, Durham, NC
Соединённые Штаты Америки


А. В. Павлыш
Первый Санкт-Петербургский государственный медицинский университет имени академика И.П. Павлова
Россия


А. А. Топоров
Первый Санкт-Петербургский государственный медицинский университет им. акад. И.П. Павлова
Россия


Е. В. Вербицкая
Первый Санкт-Петербургский государственный медицинский университет им. акад. И.П. Павлова
Россия


А. С. Колбин
Первый Санкт-Петербургский государственный медицинcкий университет имени акад. И.П.Павлова; Санкт-Петербургский государственный университет
Россия


Список литературы

1. Coons S.J., Gwaltney C.J., Hays R.D., et al. Recommendations on evidence needed to support measurement equivalence between electronic and paper-based patient-reported outcome (PRO) measures: ISPOR ePRO Good Research Practices Task Force Report. // Value Health 2009;12:419-29. Available from: http:// www.ispor.org/workpaper/patient_reported_outcomes/ Coons.pdf. [Accessed March 26, 2013].

2. US Food and Drug Administration. Guidance for industry: patient reported outcome measures: use in medical product development to support labeling claims. December 2009. Available from: http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatory Information/ Guidances/ UCM193282.pdf. [Accessed February 19, 2011].

3. European Medicines Agency. Reflection paper on the regulatory guidance for the use of health related quality of life (HRQL) measures in the evaluation of medicinal products. 2005. Available from: http://www.emea.europa.eu/docs/en_GB/document_library/Scientific_guideline/2009/09/WC500003637.pdf. [Accessed February 22, 2011].

4. Paty J., Stokes T. Electronic diaries, part 1: what is a subject diary, and how do regulations apply. // Appl Clin Trials 2002. Available from: http://www. appliedclinicaltrialsonline.com/ appliedclinicaltrials/article/articleDetail.jsp?id=83521. [Accessed March 23, 2011].

5. Hufford M.R., Stokes T.E., Paty J.A. Collecting reliable and valid real-time patient experience data. // Drug Inf J 2001;35:755-65.

6. Paty J., Stokes T. Electronic diaries, part 2: the role of the clinical protocol in developing and implementing electronic diaries. Appl Clin Trials 2003. Available from: http://www.appliedclinicaltrialsonline.com/appliedclinicaltrials/article/articleDetail.jsp?id=90715. [Accessed March 23, 2011].

7. Chamberlain R. Computer Systems Validation for the Pharmaceutical and Medical Device Industries. (2nd ed.). Libertyville, IL: Alaren Press, 1994.

8. Gogates G.D. Software validation in accredited laboratories: a practical guide. June 2010. Available from: ftp://ftp.fasor.com/pub/iso25/validtion/adequate_ for_use.pdf. [Accessed July 5, 2012].

9. US Food and Drug Administration. Guideline on general principles of process validation. 1987. Available from: http://www.fda.gov/ MedicalDevices/DeviceRegulationandGuidance/ PostmarketRequirements/QualitySystemsRegulations/MedicalDeviceQualitySystemsManual/ucm122439.htm. [Accessed September 3, 2011].

10. US Food and Drug Administration. Guidance for industry process validation: general principles and practices. 2011. Available from: http://www.fda.gov/ downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/UCM070336.pdf. [Accessed September 3, 2011].

11. European Commission Health and Consumers Directorate-General. The rules governing medicinal products in the European Union, volume 4: good manufacturing practice: medicinal products for human and veterinary use, annex 11: computerised systems. June 2011. Available from: http://ec.europa.eu/ health/files/eudralex/vol-4/annex11_01-2011_en.pdf. [Accessed September 1, 2011].

12. U.S. Food and Drug Administration. General principles of software validation: final guidance for industry and FDA staff. January 2002. Available from: http:// www.fda.gov/downloads/RegulatoryInformation/Guidances/ucm126955.pdf. [Accessed August 12, 2011].

13. Stokes T. The Survive and Thrive Guide to Computer Validation. Buffalo Grove, IL: Interpharm Press, Inc., 1998.

14. Stokes T., Branning R.C., Chapman K.G., et al. Good Computer Validation Practices: Common Sense Implementation. Buffalo Grove, IL: Interpharm Press, Inc., 1998.

15. US Food & Drug Administration. Guidance for industry part 11, electronic records; electronic signatures - scope and application. August 2003. Available from: http://www.fda.gov/downloads/Drugs/GuidanceComplianceRegulatoryInformation/Guidances/ucm072322.pdf. [Accessed August 15, 2011].

16. Cardie M.L., Tucker N.G., Weiss L.M. Computer system validation. GMP Rev 2005;4:20-2.Fig. 1 - Sample of traceability matrix.488 // Value Health 16 (2013) 480 - 489.

17. Stokes T., Paty J. Electronic diaries, part 3: developing and validating electronic diaries: roles for the technical and clinical teams. // Appl Clin Trials 2003;6:68-78.

18. PIC/S. Good practices for computerised systems in regulated “GXP” environments, section 13 “testing” report PI 011-3, Pharmaceutical Inspection Convention, Geneva. September 2007. Available from: http://www.picscheme.org/publication.php?id=8. [Accessed August 12, 2012].

19. European Medicines Agency (EMA) ICH Topic E 6 (R1) Guideline for good clinical practice. July 2002. Available from: http://ichgcp.net/pdf/ich-gcp-en.pdf. [Accessed September 21, 2012].

20. Atkins T. User acceptance testing: finally some validation? Silverpath Technologies. 2009.Available from:http://silverpath.com/resources/Silverpath-UserAcceptan ceTestingWhitepaper-090203.pdf. [Accessed March 26, 2013].


Для цитирования:


Zbrozek A., Hebert J., Gogates G., Thorell R., Dell C., Molsen E., Craig G., Grice K., Kern S., Hines S., Павлыш А.В., Топоров А.А., Вербицкая Е.В., Колбин А.С. Валидация электронных систем сбора данных «Оценок Результатов Пациентами» - Рекомендации для клинических исследователей: отчёт Целевой Группы ISPOR по надлежащей исследовательской практике валидации ePRO систем. Качественная клиническая практика. 2015;(2):3-18.

For citation:


Zbrozek A., Hebert J., Gogates G., Thorell R., Dell C., Molsen E., Craig G., Grice K., Kern S., Hines S., Pavlysh A.V., Toporov A.A., Verbitskaya E.V., Kolbin A.S. Validation of Electronic Systems to Collect Patient-Reported Outcome (PRO) Data - Recommendations for Clinical Trial Teams: Report of the ISPOR ePRO Systems Validation Good Research Practices Task Force. Kachestvennaya klinicheskaya praktika. 2015;(2):3-18. (In Russ.)

Просмотров: 143


Creative Commons License
Контент доступен под лицензией Creative Commons Attribution 4.0 License.


ISSN 2588-0519 (Print)
ISSN 2618-8473 (Online)