CC BY
88
Валидация электронных систем сбора данных «Оценок Результатов Пациентами» — Рекомендации для клинических исследователей:
отчёт Целевой Группы ISPOR по надлежащей исследовательской практике валидации ePRO систем
Arthur Zbrozek1, Joy Hebert2, Gregory Gogates3, Rod Thorell4, Christopher Dell5, Elizabeth Molsen6, Gretchen Craig7, Kenneth Grice8, Scottie Kern9, Sheldon Hines10
1 — Global Health Economics, CSL Behring, Biotherapies for Life, King of Prussia, PA, USA
2 — PHT Corp, Boston, MA, USA
3 — CRF Health, Plymouth Meeting, PA, USA
4 — PHT Corp, Charlestown, MA, USA
5 — ERT, Philadelphia, PA, USA
6 — ISPOR, Lawrenceville, NJ, USA 7—ERT, Inc., Pittsburgh, PA, USA
8 — Global Electronic Data Capture, Bayer HealthCare Pharmaceuticals, Inc., Montville, NJ, USA
9 — Sacaja Consulting Ltd., Wiltshire, England, UK
10 — ICON Late Phase & Outcomes Research, Durham, NC, USA
Переводчики:
Павлыш Андрей Владиславович — к.м.н., докторант Первого Санкт-Петербургского государственного медицинского университета им. акад. И.П. Павлова, г. Санкт-Петербург, Российская Федерация
Топоров Александр Андреевич — студент Первого Санкт-Петербургского государственного медицинского университета им. акад. И.П. Павлова, г. Санкт-Петербург, Российская Федерация
Рецензенты:
Вербицкая Елена Владимировна — к.ф.-м.н., ассистент, Первый Санкт-Петербургский государственный медицинский университет им. акад. И.П. Павлова, г. Санкт-Петербург, Российская Федерация
Колбин Алексей Сергеевич — д.м.н., профессор, Первый Санкт-Петербургский государственный медицинский университет им. акад. И.П. Павлова, г. Санкт-Петербург, Российская Федерация
Резюме. Литература об исследовании исходов лечения изобилует примерами высококачественных, надёжных данных оценок результатов пациентами (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 используют те способы валидации системы и реализации процессов, которые гарантируют, что системы и сервисы работают надёжно на практике, производят точные, полные и целостные данные (файлы данных), поддерживают административное управление и соответствуют текущим регуляторным требованиям. Более того, этот короткий отчёт улучшит понимание требований пользователя к технической валидации, что ведёт к более информированным и сбалансированным рекомендациям или решениям по вопросам методов сбора электронных данных.
Ключевые слова: сбор электронных данных, ePRO, PRO, валидация системы
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
Abstract. Outcomes research literature has many examples of high-quality, reliable patient-reported outcome (PRO) data entered directly by electronic means, ePRO, compared to data entered from original results on paper. Clinical trial managers are increasingly using ePRO data collection for PRO-based endpoints. Regulatory review dictates the rules to follow with ePRO data collection for medical label claims. A critical component for regulatory compliance is evidence of the validation of these electronic data collection systems. Validation of electronic systems is a process versus a focused activity that finishes at a single point in time. Eight steps need to be described and undertaken to qualify the validation of the data collection software in its target environment: requirements definition, design, coding, testing, tracing, user acceptance testing, installation and configuration, and decommissioning. These elements are consistent with recent regulatory guidance for systems validation. This report was written to explain how the validation process works for sponsors, trial teams, and other users of electronic data collection devices responsible for verifying the quality of the data entered into relational databases from such devices. It is a guide on the requirements and documentation needed from a data collection systems provider to demonstrate systems validation. It is a practical source of information for study teams to ensure that ePRO providers are using system validation and implementation processes that will ensure the systems and services: operate reliably when in practical use; produce accurate and complete data and data files; support management control and comply with any existing regulations. Furthermore, this short report will increase user understanding of the requirements for a technology review leading to more informed and balanced recommendations or decisions on electronic data collection methods.
Keywords: electronic data collection, ePRO, PRO, systems validation
Опубликовано: Arthur Zbrozek, Joy Hebert, Gregory Gogates, Rod Thorell, Christopher Dell, Elizabeth Molsen, Gretchen Craig, Kenneth Grice, Scottie Kern, Sheldon Hines. 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. // Value in Health 16 (2013) 480-489.
История создания Целевой Группы
Целевая Группа 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 Outcomes, PRO)) в программу клинических исследований, поскольку это помогает измерить эффект медицинского продукта на такие факторы как тяжесть симптома и физическая или психическая функция. Данные 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 и, соответственно, к их предложениям об услугах и давать более сбалансированные рекомендации для принятия решений по вопросам систем электронного сбора данных.
Кроме того, данный отчёт поможет в понимании усилий, требуемых от спонсора, чтобы дополнить процесс валидации, которые предлагает системный провайдер. Когда системный провайдер еРИО просто предлагает устройство и систему данных, но не предлагает своих услуг по её валидации, груз выполнения этих обязательств ложится на спонсора. Заметим, что в настоящем отчёте термин «спонсор» относится к группе клинического исследования, работающей с поставщиком еРИО. Эти рекомендации пригодятся в равной мере контрактно-исследовательской организации (СИО) и любой другой организации, сотрудничающей с системным провайдером еРИО, чтобы создать систему еРИО, которую можно будет использовать в предрегистрационных исследованиях медицинских продуктов. Общие принципы, изложенные в этом отчёте, могут быть применены и к другим исследования, в которых субъекты используют электронные средства для ввода данных в виде ответов на вопросы.
И наконец, в отчёт включены подходящие регуля-торные правила, так как в данном случае требуется
строгое соответствие стандартам в этих процессах и во время проведения самого исследования. Приложение 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) как группой исследования, так и поставщиком ПО будут заданы одинаковые ожидания к системе, понятные в равной мере всем участникам. Это особенно важно при тестировании системы на приемлемость для пользователя (иАТ) и использовании системы в исследовании (подробнее будет изложено ниже).
Прочие названия для этой документации.
Также этот раздел, помимо прочего, может называться «требованиями пользователя», «функциональными требованиями», «спецификацией пользователя». Документация может представлять собой один или несколько документов. Вне зависимости от её состава, для обеих сторон важно, чтобы в документации было предельно ясное и подробное описание всех аспектов системы [13, 14].
Вовлечённость группы клинического исследования
Участие этой группы необходимо на стадии составления требований и подбора определений, независимо от того, будет ли система еРИО разрабатываться внутренне или её будет разрабатывать внешний поставщик.
Те группы клинических исследований, у которых нет опыта написания документов по системным требованиям, для того, чтобы его написать, обычно, опираются на опыт системного провайдера еРИО, консультанта или технических экспертов в собственной организации. Группа клинического исследования предоставляет указанным экспертам Протокол клинического исследования. В большинстве случаев, группа встречается с авторами документа о системных требованиях, чтобы определить, как система должна работать, чтобы соответствовать требованиям Протокола, а также требованиям пользователей в клинических сайтах, целевой аудитории пациентов и заинтересованные стороны от организации-спонсора. Заинтересованные стороны от организации-спонсора включают клинические процедуры, менеджмент данных, биостатистику, исследование исходов или анализ стоимости лечения и соответствие нормативным требованиям [14].
С группой клинического исследования обсуждаются вопросы, которые включают в себя последова-
тельность экранных изображений (индивидуальный дизайн страниц для более точного отображения элементов PRO), изменение полей ввода данных, требования по переносу данных, формат файла данных, требования безопасности и соответствие Правилу 21 CFR часть 11 FDA об электронных записях [15], электронные подписи и множество других деталей. Спонсор должен перевести регуляторные требования на язык системной функциональности от доступа к данным до составления отчётов и сроке их хранения для аудита и проверок [6].
Когда предварительная версия документа о системных требованиях готова, необходимо, чтобы группа клинических исследований провела его вдумчивое рассмотрение и подготовила обратную связь, чтобы запросить любые необходимые изменения. Эти изменения по требованию спонсора должны быть внесены в соответствии с оговорёнными сроками, чтобы не менять срок поставки продукта. Если группа клинических исследований и системный провайдер ePRO удовлетворены документом о системных требованиях, считая, что он полностью и точно включает в себя все детали информации о системе, основные члены исследовательской группы подписывают этот документ, подтверждая таким образом своё согласие и удовлетворение. Основные члены команды системного провайдера также подписывают этот документ в знак подтверждения их согласия и готовности предоставить систему в описанном виде [13, 14].
Почему это важно? Документация о системных требованиях — это основа всех последующих процессов валидации системы и получаемых результатов. Если её разделы описаны неразборчиво, двояко или вовсе отсутствуют, их можно будет интерпретировать по-разному, что приведёт к недопониманию между группой клинического исследования и группой системного провайдера ePRO. Эта разница обнаружится только позже, на стадии тестирования на приемлемость для пользователя, что может закончиться задержкой при наборе пациентов, создаёт риск для обеспечения качества и стабильности ПО, и вызовет проблемы с функциональностью и недостатками работы ПО во время проведения исследования. Таким образом, крайне важно, чтобы этот документ был точным, ясным, правильным и полным [13, 14, 16].
Минимальное содержание
Документация с системными требованиями должна включать в себя всё необходимое для обеспечения чёткого, детального описания системы. Как минимум, они должны показывать и/или точно описывать все аспекты системы, влияющие на пользователей, включая выбранный инструментарий, снимки экрана (карманный персональный компьютер (КПК), планшет или другое сетевое устройство), голосовые подсказки (система интерактивного го-
лосового управления), поля ввода данных, проверку редактирования, сообщения об ошибках, логику навигации, поведение всех кнопок (КПК, планшета или другого сетевого устройства), алгоритмы, сигнализацию, тайм-ауты, функции безопасности, контрольный журнал, электронные подписи, предупреждения (сообщения о необходимости обратить внимание) субъектов, сотрудников сайта и дизайн отчёта. Текстовые описания этих элементов должны идти в сопровождении графики, если это необходимо для полной ясности.
Независимо от технологии, используемой в исследовании, идеальная документация с системными требованиями должна включать в себя следующие разделы:
1) цели и задачи;
2) определения;
3) справочные документы;
4) допущения;
5) системы и технологические потоки, в том числе блок-схемы, которые показывают последовательность экранов и связанную с ними логику всей системы;
6) функциональные требования. Последний раздел — «сердце» документа — может быть длиннее прочих, зачастую за него отвечает группа пользователей (например, Системные требования для сотрудников клиники), но может быть составлен в любой форме, которая делает его лёгким для понимания.
Краткое описание функциональных требований в документации о системных требованиях — пример того содержимого, которое стоит ожидать на первом экране в разделе, описывающем последовательность экранов для пациентов. За каждым элементом в структуре следует чёткое и подробное описание.
Функциональные требования
Раздел 1 — последовательность экранов для пациента
1. Первый экран — логин пациента
a. Снимок экрана
b. Данные на баннере экрана
1) Дата
2) Время
c. Поля ввода данных
• PIN-код пациента
• Проверка на 4-х-символьное цифровое сообщение об ошибке
• Проверка, совпадает ли PIN-код и сообщение об ошибке
ё. Кнопки навигации
• Кнопка «Отмена»
1) Данные не сохраняются
2) Система возвращает пользователя к предыдущему экрану
• Кнопка «ОК»
1) Проверка номера введённого ПИН-кода
2) Система переводит пользователя на следующий экран
Важные процессы управления качеством проекта, о которых следует знать
Первый важный шаг в разработке высококачественных системных требований для группы системного провайдера и исследовательской группы — внимательно прочитать и изучить Протокол исследования и другие документы, описывающие исследование и стандарты спонсора. После чего основные члены группы системного провайдера должны провести подробное и продуманное обсуждение предъявляемых требований, чтобы определить, как именно группе клинических исследований необходимо, чтобы программа работала, чтобы поддерживать этот Протокол, качество и целостность данных, клинические сайты и персонал [13, 14]. Отдельно следует напомнить участникам, что нужно найти компромисс между сроками, стоимостью и качеством. Чем больше функций будет включено в систему, тем больше времени займет её разработка и проверка, и тем дороже это обойдется.
Обсуждение требований должно сопровождаться созданием первого чернового варианта документа системных требований. Этот первый черновик должен быть внимательно прочитан членами обеих групп. Ещё одно совместное обсуждение должно повлечь за собой решение вопроса, где и каким образом группа клинического исследования будет обеспечивать обратную связь и запросы о внесении изменений [6, 13, 14]. Процедура сбора требований, как правило, требует, по крайней мере, две ревизии первого черновика, чтобы создать окончательную документацию системных требований. Если рамки утверждённой системы требований превышают первоначальные предположения при планировании проекта, в план проекта могут быть внесены изменения, которые могут повлиять на график и бюджет исследования. Системный провайдер должен обеспечить контроль качества при производстве документации системных требований таким образом, чтобы независимая сторона ознакомилась с финальной версией документации системных требований прежде, чем её представят группе клинического исследования.
Дизайн (проект) системы
Что это такое? Этап проектирования включает в себя разработку проектной документации системы, обеспечивающей полное, чёткое, подробное техническое описание, каким образом система еРИО будет разрабатываться с учётом удовлетворения
потребностей Протокола и пользователей. Проектная документация необходима, чтобы объяснить разработчику, что должно быть включено, а что выходит за рамки системы. Эта документация должна охватывать как контекст, в котором система будет работать, так и детали, необходимые, чтобы освободить разработчика от неопределённости в вопросе построения системы [13, 14].
Системный провайдер ePRO отвечает за разработку большей части этой документации. Спонсору или CRO, ответственным за «подгруздку» данных ePRO в базу данных исследования, может потребоваться предоставить спецификации для переноса файлов данных системному провайдеру ePRO, чтобы их можно было использовать при создании/настройке модуля передачи данных.
Специалисты по разработке программного обеспечения используют проектную документацию системы, чтобы писать программы и/или задавать значения технических параметров для системы ePRO. Некоторые системы ePRO используют базовую систему, настроенную для использования в конкретном исследовании с применением параметров и настроек, с минимальными изменениями исходного кода в дополнение к базовой системе.
Первоначальная концепция требований к жизнеспособной системе может пересматриваться, как только система будет создана и подвергнута модульным тестам. После создания системы, авторам проектной документации необходимо эффективно общаться с группой клинического исследования и группой разработчиков программного обеспечения, чтобы гарантировать, что проект системы, введённый в эксплуатацию, по-прежнему соответствует требованиям пользователей [17].
Проектная документация
Документация по системному дизайну должна описывать три основные функции, которые соответствуют непосредственно следующим модулям в типичной системе ePRO:
• сбор и хранение данных (сбор данных по любой из нескольких технологий, которые будут храниться на сервере, контролируемом провайдером системы ePRO);
• веб-портал и оповещения (позволяющие исходным данным на сервере отображаться, отчётам создаваться, а предупреждениям — запускаться и рассылаться пользователям);
• трансфер данных (преобразование сохранённых данных в файлы передачи для отправки спонсору или его CRO).
Другие названия для этой документации. Она также может быть известна как проектная спецификация программного обеспечения, техническая спецификация проекта или документация по спецификации системы.
Роль группы клинических исследований. Роль группы клинических исследований складывается из проведения проверки и принятия проектной документации системы. Эта роль должна быть определена в начале жизненного цикла проекта, чтобы избежать непредвиденных задержек в развитии системы. Группа клинических исследований должна стремиться прояснить области, где системный провайдер неправильно истолковал требования в проектной документации или представил неполное описание решения. В тех случаях, когда документацию трудно интерпретировать, группа клинических исследований должна обратиться за помощью к техническим экспертам по данному вопросу, а не предполагать, что спецификация полностью и достоверно соответствует требованиям.
Почему это важно? Проектная документация системы является мостом между требованиями системы и разработчиками программного обеспечения. Создание этой документации является важным шагом для того, чтобы усилия по разработке программного обеспечения привели к решению, устраивающему пользователей системы и совместимому с клиническим протоколом [6, 13, 14].
Минимальное содержание. Документация должна охватывать все три модуля, описанных выше, в идеале с наличием отдельного документа или раздела для каждого из них. В случаях, когда используется базовая система, и технические характеристики базовой системы не меняются, системный провайдер ePRO должен сделать соответствующие части этой документации доступными для группы клинического исследования.
Раздел документации о проектировании модуля «системы сбора данных» необходим, чтобы упорядочить детали, которые ещё не вошли в документацию системных требований по таким темам, как:
• алгоритм обработки экранов;
• алгоритм контроля входа пользователя в систему и контроль процессов перехода между экранами / скриптами;
• редакционные проверки, которые препятствуют введению неверных данных или команд;
• оповещения пользователей;
• прочие алгоритмы работы с ошибками.
Кроме того, проектная документация должна содержать следующие детали, которые не вошли в документацию системных требований:
1) детали процессов отправки данных на сервер, алгоритмы и методы, доступные для отправки данных, в том числе процессов управления для обеспечения того, чтобы отправляемые данные являлись полными, точными и не дублировались;
2) детали процессов обработки частичного/неполного сохранения данных на сервер (например, в случае «отката системы»).
Раздел «веб-портал» должен освещать следующие вопросы документации, которые ещё не вошли в документацию системных требований проекта:
• вход в систему и пароль безопасности;
• группы безопасности и их влияние на доступ к данным;
• отображение клинических данных, в том числе необработанных данных, метаданных и аудита;
• отображение отчётов и переходов между ними, стандартного и кастомизированных (разработанных по запросу пользователя);
• оповещения для пользователей и логика их переключений;
• другие процессы (такие как автоматизация логистики устройства или запросов на изменение данных).
Раздел «передача данных» должен содержать следующие детали, которые не вошли в документацию системных требований:
• синхронизация, частота и способ передачи данных;
• множество элементов данных для передачи и их формата;
• процесс преобразования данных в формате, определённом спонсором или его СИО;
• процессы управления для обеспечения того, чтобы переданные данные являлись полными, точными и не дублировались.
Важные процессы управления качеством проекта, которые следует иметь в виду
Системный провайдер должен обеспечивать контроль качества при производстве проектной документации системы таким образом, чтобы независимая сторона, знающая системные требования, предоставила отзыв на документацию, прежде чем документация будет предоставлена группе клинического исследования.
Кодирование/адаптация/разработка программного обеспечения
Что это такое? Процесс кодирования/адаптации/разработки ПО представляет собой процесс написания кода ПО на языке программирования или сборки и настройки модулей кода, которые уже были разработаны для удовлетворения потребностей данного конкретного исследования.
Почему это важно? Эти процессы являются блоками создания компьютерной системы, которая будет использоваться в клиническом исследовании. Правильное исполнение и документирование процесса поможет в создании систем, которые относительно просты в обслуживании и легко могут пройти проверку третьими лицами [12].
Вовлечённость группы клинического исследования. Отсутствует. Группа клинического исследо-
вания в процессе не участвует, поскольку процесс носит сугубо технический характер. Как правило, группа клинического исследования общается с разработчиками через менеджера и/или аналитика проекта, который гарантирует, что проектные требования правильно переведены на язык спецификаций для разработчиков.
Важные моменты управления качеством проекта, о которых следует знать. Как и в любом процессе, цель заключается в выявлении каких-либо проблем или дефектов как можно раньше и обеспечении их скорейшего решения [11]. В разработке должна присутствовать проверка выполненного кода, которая может быть выполнена одним или несколькими техническими экспертами, которые понимают языки и стандарты используемого метода разработки (так называемый «просмотр кода»). До введения нового фрагмента кода в общую структуру проекта исследования, разработчику (или его коллегам) следует проверить отдельные модули на предмет того, выполняются ли они должным образом и отвечают ли требованиям проекта, ограничениям и изначальным предположениям (так называемый «юнит-тестинг» или «тестирование модулей») [18].
Обнаружение каких-либо ошибок, вызванных качеством процесса при разработке программного обеспечения, должно быть задокументировано с указанием информации об условиях, при которых ошибки произошли, для возможности их последующего воспроизведения. См. Приложение 2, Описание процесса обеспечения качества, в Дополнительных материалах на http://dx.doi.Org/10.1016/j. )уа1.2013. 04.002. Ошибкам должен быть присвоен определённый статус (например, открыт/назначен/исправлен/закрыт), чтобы они могли быть исправлены в системе и проверены второй стороной, прежде чем они могут считаться решёнными. Пока система находится в разработке, должна существовать возможность проследить за создаваемым кодом или модулями, использованными в отдельных элементах дизайна.
Тестирование ПО системным провайдером
Что это такое? Тестирование по всем пунктам, описанным в документации системных требований, имеет решающее значение для того, чтобы убедиться, что новая система соответствует всем ранее оговорённым требованиям. План тестирования описывает такую стратегию тестирования окружающей среды и подходы, которые имитировали бы реальные условия. Он также содержит полный набор тестов для покрытия всех потребностей системы [7, 13].
Вовлечённость группы клинического исследования. Отсутствует. Группа клинического исследования не участвует в процессе тестирования; это ответственность системного провайдера.
Почему это важно? Программы, необходимые для обеспечения систем для клинических исследований, состоят из многих тысяч комплексно взаимосвязанных строк кода. Даже при участии опытных, преданных делу программистов, которые осуществляют высококачественный процесс кодирования, сложность большинства систем для клинических исследований практически гарантирует, что ранние версии системы не будут работать в полном соответствии с документацией по системным требованиям. Каждая часть системы должна быть тщательно проверена.
Тестирование системы осуществляется после составления детального плана тестирования и самих тестов. Тщательно выполненный план тестирования гарантирует, что система в течение клинических исследований будет работать как положено [7, 13].
Минимальное содержание. Наиболее важными разделами плана тестирования качества являются стратегия тестирования и примеры тестов.
• Стратегия тестирования. В этом разделе, как правило, разработанном лидерами команды тестирования, должна быть задокументирована стратегия тестирования системы в условиях, максимально приближенных к реальному исследованию. Например, если исследование с зачислением пациентов в 10 странах продлится 12 месяцев с 2-недельным периодом подготовки и 9-месячным периодом лечения, стратегия тестирования должна описать, как будет создана тестовая среда, как данные будут собраны и проверены на этапе тестирования, чтобы сымитировать эти условия, и как обеспечить точность и высокий уровень уверенности, что система будет работать надёжно в ходе исследования. Кроме того, стратегия тестирования должна документировать метод тестирования, чтобы указать, как будут учтены все системные требования.
• Примеры тестов. Также известные как примеры тестовых скриптов, они являются основой стратегии тестирования. Они помогают определить, совпадает ли именно эта система с заявленными требованиями. Каждый тест содержит пошаговые инструкции для инже-нера-тестировщика о том, как ввести набор предопределённых данных, а также подробное описание ожидаемых результатов. При выполнении каждого теста, инженер-тести-ровщик будет должен чётко указать, совпали ли фактические результаты с ожидаемыми и, таким образом, пройден тест или «провален». Если «провален», инженер будет подробно документировать отклонение от ожидаемых результатов в выпускном отчёте, чтобы программист смог определить причину сбоя, решить её, и задокументировать это решение.
Важные варианты тестирования, о которых нужно знать
Необходимо использовать несколько вариантов тестирования. Это сведёт к минимуму риск системных сбоев и ошибок файлов данных при использовании системы в реальных условиях. Процесс тестирования должен включать следующие проверки каждого из требований:
• положительное тестирование. Широкий спектр допустимых значений и параметров, проводится, чтобы гарантировать, что допустимые значения будут приняты системой;
• граничные испытания. Записи делаются только в пределах граничных значений (например, при ограничении по возрасту) и сразу за пределами граничных значений, чтобы подтвердить, что в поле «редакторские проверки на соответствие» показаны правильные результаты;
• отрицательное тестирование. Делаются допущения и/или неправильный ввод данных, чтобы удостовериться, что все возможные ошибки обрабатываются корректно;
• нагрузочное тестирование. Большой набор предопределённых достоверных данных вводится и проверяется как на локальной системе и на удалённых системах (например, хранилищах данных/серверах), куда данные будут передаваться в течение всего процесса, путём сравнения с предопределёнными ожидаемыми наборами данных. Размер набора данных должен быть достаточно большим для того, чтобы обеспечить всем связанным системам — локальной системе, удалённым системам, системе телекоммуникаций, и т.д. — возможность легко вместить существенно превосходящий ожидаемый объём данных для изучения, и всё равно выдавать точные результаты. Нагрузочное тестирование является жизненно важным для свидетельства того, что системы будут функционировать должным образом и в клиническом исследовании;
• регрессивное тестирование. Это очень важно после решения программистом одного или нескольких вопросов. Целью регрессивного тестирования является подтверждение, что изменение кода не повредило другим частям системы, которые были разработаны ранее. Регрессивное тестирование необходимо, потому что изменения в коде часто имеют непредвиденные последствия для других областей программного обеспечения. В случаях существенных изменений в коде, вся система должна быть проверена повторно для того, чтобы она продолжала работать на должном уровне. Когда изменения кода очень незначительные, например, исправления орфографи-
ческих ошибок или других мелких ошибок, регрессивное тестирование может проводиться в меньших масштабах. Группа тестирования должна очень хорошо просчитать уровень риска, возникающий вместе с изменением кода, и использовать стратегию регрессивного тестирования, что позволит значительно минимизировать риск.
Важные процессы управления качеством, о которых нужно знать. Тестовые стратегии, планы и тестовые случаи должны пройти несколько проверок качества управления и несколько итераций (повторений) в команде системного провайдера. При выполнении тестов часто обнаруживаются вопросы или ошибки, которые должны быть тщательно задокументированы и отслеживаются системой тестеров. Программисты будут создавать и документировать новую версию системы, которая содержит изменения, внесённые, чтобы решить ошибки и проблемы системы. Потом будет создана новая стратегия тестирования для каждой новой версии системы. Эта новая стратегия тестирования должна учитывать риск того, как отразятся изменения программного обеспечения на ранее выполненных системных функциях. На основе этой оценки рисков, стратегия тестирования должна будет учесть все тестовые случаи, которые будут перезапущены, чтобы гарантировать, что все ошибки были решены, и для того, чтобы регрессивное тестирование было проведено адекватно, необходимо в полной мере учитывать риск изменения программного обеспечения и обеспечения надёжной работы системы в условиях исследования [7, 13].
Если качество процессов было соблюдено системным провайдером верно, потребуется от двух до трёх итераций стратегии тестирования и тестовых случаев. Заключение — это успешное прохождение теста на приемлемость для пользователя группой исследования, и получение системы, работающей так, как предполагается в течение клинического исследования.
Трассировка (traceability)
Что это такое? Трассировка (прослеживае-мость) играет роль контроля качества путём установления, что программное обеспечение удовлетворяет потребностям пользователя. Это гарантирует, что все элементы в документации системных требований должным образом «трассируются» в другие процессы и документы проверки критически важных систем.
Матрица трассировки показывает, что каждый пункт в системных требованиях был учтён при разработке документа, а также в случаях тестирования или скриптах. Она может быть использована для отслеживания:
1) требований дизайна (пользователя) к функции системы;
2) требований программного обеспечения (функциональных), определённых для удовлетворения требований пользователя;
3) тестовые примеры, которые используются для проверки того, что конечный продукт отвечает требованиям программного обеспечения и пользовательским требованиям.
Тестовые матрицы могут принимать различные формы. Например, трассировка может быть проведена с юнит-тестирования требований дизайна, таких как тестирование фрагмента кода разработчиком, чтобы увидеть, работает ли он в изоляции. Другой пример — трассировка с тестового случая (формальное тестирование конкретной спецификации программного обеспечения) на требование программного обеспечения.
Почему это важно? Матрица трассировки гарантирует, что каждое системное требование было разработано и закодировано в программном обеспечении и включено в тестовую программу. Матрица трассировки также гарантирует, что все требования были апробированы в рамках системного и пользовательского тестирования [13, 14, 17]. Обеспечение прозрачности трассировки в течение всего рабочего процесса необходимо, чтобы все элементы дизайна были не только надлежащим образом протестированы, но и позволяли проводить анализ в дальнейшем, когда инспектор будет проводить валидацию путём тестирования записей по критическим функциям дизайна.
Чаще всего не существует прямой корреляции между проектными требованиями, требованиями к программному обеспечению и тестами. Например, на одно проектное требование может приходиться несколько функциональных требований, чтобы охватить всю функцию; на одно функциональное требование может потребоваться несколько тестов, чтобы убедиться, что всё работает правильно. Таким образом, матрица трассировки документирует эти зависимости между функциональными требованиями пользователей и техническими требованиями программного обеспечения.
Минимальное содержание. За счёт матрицы трассировки каждое требование системы к элементу конструкции и тестовым примерам является минимальным. Матрица может быть самостоятельным документом или кратко излагаться в утверждённом испытательном отчёте, показывающем, каким образом тесты проверяют все требования к конструкции.
Вовлечённость группы клинического исследования. Отсутствует. Трассировка является обязанностью системного провайдера. Спонсор может проверить и подтвердить эту работу в рамках аудитов.
Пример исследования - спецификация проекта еР1ТО к требования матрицы трассировки Щ Спецификации проекта_____
Сп исок тре бований Спец-1 Спец-2 Спец-3 Спец-4 Спец-5 Спец-6 Спец-7 Спец-8 Спец-9 Спец-10 Покрытие требований
Треб-1 • • • 100%
Треб-2А • 100%
Треб-2В • • 50%
Треб-2С • 100%
Треб-3 • 100%
Треб-4А • 100%
Тре 6-4 В • 100%
• 75%
Рис. 1. Пример матрицы трассировки *
Примечание: в некоторых случаях, одна спецификация полностью покрывает все нужды. Однако временами для покрытия требований требуется исполнение нескольких спецификаций. (См. Спец-1 в таблице). Требования 2B и 5 не удовлетворены полностью. Будет необходимо вернуться на шаг назад и пересмотреть документацию, переделав её таким образом, чтобы полностью соответствовать требованиям спонсора.
Важные процессы управления качеством, о которых нужно знать. Тщательная подготовка матрицы трассировки на этом этапе может помочь предотвратить ошибки в проектировании, исправление которых будет более сложным и дорогостоящим в течение жизненного цикла системы. Как и все процессы и системы, подлежащие контролю качества, матрица трассировки должна быть изучена сотрудниками системного провайдера, независимыми от команды разработчиков.
Тестирование на приемлемость для пользователя (user acceptance testing, UAT)
Что это такое? UAT — это процесс, при котором группа клинического исследования определяет, соответствует ли система ожиданиям и работает ли в соответствии с документацией системных требований. При существовании несоответствия между ожиданиями группы клинического исследования и системы, они будут выявлены на этом этапе. UAT можно начинать после того, как системный провайдер представит письменное подтверждение выполнения своих обязательств по валидации системы. Следует отметить, что UAT — это не полная перепроверка системы, предпринимаемая группой клинического исследования. Скорее, это сфокусированный, риск-ориентированный подход к тестированию, который позволяет группе клинического исследования определить, соответствует ли система ключевым требованиям к системе (которые отражает Протокол).
Другие названия для этой документации. UAT также известно как тестирование пользователями сайта.
Вовлечённость группы клинического исследования. Группа клинического исследования должна принимать активное участие в разработке стратегии для UAT. Это не может находиться только в ответственности системного провайдера или третьей стороны.
Авторы Протокола, формулировавшие требования к системе, вначале должны проверить и подтвердить соблюдение этих требований [6].
Как правило, в группе клинического исследования присутствует несколько членов, участвующих в выполнении тестовых скриптов. Группа клинического исследования играет решающую роль в рассмотрении, готова ли система к выпуску, за счёт проверки расхождений, выявленных в UAT и способов их решения (их либо устраняют, либо соглашаются, что расхождения не требуют исправления). После того как группа клинического исследования определяет, что система готова к производству, она должна подготовить и подписать официальный документ, который определяет систему, как утверждённую для выполнения поставленных задач [6, 7].
Следует отметить, что UAT заметно отличается от юзабилити-тестирования. В отчёте рабочей группы ISPOR по ePRO от 2009 года [1], юзабили-ти-тестирование было определено как проверка, «могут ли респонденты из целевой группы населения использовать программное обеспечение и устройства соответствующим образом. Этот процесс включает в себя формальную документацию способности респондентов использовать навигацию электронной платформы, следовать инструкциям и отвечать на вопросы». Проще говоря, юзабилити-тестирование позволяет определить, могут ли субъекты провести компьютеризированную оценку как предполагалось?
Юзабилити-тестирование включает в себя участие представителей населения, вовлечённых в клиническое исследование. Например, в юзабили-ти-тестировании системы ePRO для педиатрического исследования, которое включает собственный отчёт ребенка, должны участвовать дети. UAT не задействует субъекты целевой популяции; оно проводится между группой клинического исследования и провайдером ePRO. Хотя и UAT, и юзабилити-тестирование необходимы и важны для общего успе-
ха исследования, UAT имеет решающее значение для определения, соответствует ли программное обеспечение требованиям документации для пользователя и письменным спецификациям.
Почему это важно? UAT является важным шагом для проверки того, что система была построена в соответствии с первоначальным документом о требованиях пользователя. Тщательные усилия по проведению UAT также предоставляют группе клинического исследования возможность увидеть, как система будет функционировать и самообучаться на деталях, необходимых для ответа на вопросы исследовательских сайтов и аудиторов, как только система будет запущена в работу. Кроме того, это помогает укрепить уверенность группы клинических исследований, что система будет надёжно функционировать в течение всего процесса.
После успешного завершения UAT даст ответы на три основных вопроса:
1. Была ли система спроектирована и построена в соответствии с первоначальными требованиями пользователя?
2. Соответствуют ли первоначальные требования всем ожиданиям команды клинического исследования?
3. Создан ли правильный дневник субъектов для использования в этом исследовании? [17].
Хотя у группы клинического исследования может возникнуть желание положиться на валидацию системы провайдером и пропустить UAT, это запрещено правилами Международной конференции по гармонизации технических требований к регистрации фармацевтической продукции применяемой для людей в надлежащей клинической практике (The International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use Good Clinical Practice) [19], которые требуют, чтобы спонсор брал на себя полную ответственность за качество и целостность данных исследования. Спонсор несёт ответственность за внедрение и поддержание системы обеспечения качества и системы контроля качества с помощью письменных Стандартных Операционных Процедур (СОП), чтобы быть уверенным, что испытания проводятся и данные генерируются, документируются (записываются), и передаются в соответствии с Протоколом, надлежащей клинической практикой (GCP) и нормативными требованиями [19]. Увеличить процесс разработки на несколько недель — это небольшая цена за предотвращение потока неприятных находок во время проверки регуляторной инспекцией.
Минимальное содержание. Чтобы правильно выполнить UAT, группа клинического исследования документирует стратегию тестирования в тестовом плане UAT [20]. Эта стратегия будет направлять раз-
витие сценариев тестирования, задавать соответствующий набора тестеров, и определять тестовый период (в том числе повторное тестирование в случае необходимости). Это похоже на стратегию тестирования внутренней проверки системным провайдером, но не так обширно.
Тестовый план иАТ должен касаться и тех областей, которые требуют тщательного тестирования и тех, которые требуют лёгкого тестирования, основанного на восприятии риска [12]. Например, требование о том, чтобы программное обеспечение вычисляло суммарный балл на основе ответов в новом дневника, где эта оценка используется для определения того, будет ли субъект рандомизирован в исследование, будет иметь большое значение; такая задача потребует тестовых примеров, определяющих условия как для успешной рандомизации, так и для невключения субъекта. Требование, чтобы будильник на устройстве звучал точно в 5:00 вечера, будет нуждаться только в беглом тестировании во время иАТ, поскольку будильник, как правило, является стандартной функцией базового программного обеспечения.
Важные процессы управления качеством, на которые надо обратить внимание. Надёжность иАТ можно повысить путём использования матрицы трассировки для уст тестов иАТ к исходным требованиям. Матрица — это эффективный способ определить, все ли изначальные условия удовлетворены за счёт иАТ. Кроме того, необходим независимый контроль качества тестовых скриптов, чтобы свести к минимуму риск использования скриптов, которые не могут выполнить функцию в соответствии с проектом или не достигнут своих конкретных целей тестирования [13].
иАТ иногда приводит к тому, что группа клинического исследования понимает, что система функционирует как записано и спроектировано, но не удовлетворяет задокументированным требованиям или ожиданиям, включённым в Протокол. Если группа клинического исследования уверена в необходимости внесения изменений в то, как система в настоящее время функционирует, то команда обязана инициировать «изменения в масштабах и сфере деятельности» проекта. Требования переписывают, и повторяется весь процесс жизненного цикла системы, пока следующий иАТ не покажет необходимого результата. Следует отметить, что группа клинического исследования может поднимать вопрос о пересмотре требований на таком позднем этапе только при наличии времени, бюджета и по-настоящему важного несовпадения, так как эти изменения могут повлиять на выбор первого субъекта/первую дату визита.
Качество нельзя внедрить в систему за счёт тестирования. иАТ служит в качестве контрольного фильтра. Если процесс документирования требований
системным провайдером, проектирования системы или её создания в соответствии с проектной документацией нарушается, необходима обратная связь между спонсором и системным провайдером, чтобы, в первую очередь, ускорить процесс внесения улучшения качества. Такая обратная связь может быть реализована путём проведения встреч об «извлечённых уроках», и требует совместных усилий спонсора и провайдера по устранению негативных находок, обнаруженных до начала нового проекта.
Процесс должен быть организован так, чтобы получить формальное документирование усвоенных уроков и шагов, которые были предприняты по их решению. Такой подход поможет системному провайдеру сделать существенные улучшения в процессе валидации системы, которые должны привести к более гладкому проведению иАТ в будущих проектах. Наконец, иАТ системы еРИО не завершает процесс валидации системы. До момента, пока система еРИО не будет запущена на рабочем месте конечного пользователя, этот процесс не считается завершенным [7, 8, 13].
Менеджмент установки/конфигурации
Что это такое? Менеджмент установки/конфигурации представляет собой процесс, когда системный провайдер устанавливает полностью протестированное ПО, используя методы, описанные выше, на устройство еРИО. Он включает в себя локализацию системы для конечного пользователя, предоставляя ему инструкции по эксплуатации и план технической поддержки системы. Он также включает в себя базовые и специфические, связанные с исследованием, установки сервера. Чтобы убедиться, что правильная версия исследования будет применяться в правильной локации, требуется надёжный процесс управления конфигурацией/установкой. Это верно как для исследовательских серверов, так и для клиентских компонентов. После однократной установки на целевых средах, система может рассматриваться как «валидированная» [7].
Почему это важно? Поскольку многие клинические испытания являются глобальными, установка еРИО с правильной версией программного обеспечения и локальными настройками может быть сложной. Процесс настройки очень важен для того, чтобы «окончательная», «прошедшая тестирование» версия системы и настройки были правильно локализованы (например, версия для Пенджаба должна быть установлена на правильном языке (языках) и в часовом поясе, верном для Пенджаба, Индия). Важно также убедиться, что физические аксессуары, такие как источники питания, подходят для исследовательского сайта (места проведения исследования), и что материалы обучения или пользования предоставлены на соответствующем языке (языках).
Вовлечённость группы клинического исследования. Группа клинического исследования должна быть осведомлена о процессах провайдера еРИО для управления конфигурацией, установки и логистики поставки на многочисленные глобальные сайты. Вовлечение группы клинического исследования необходимо для того, чтобы на сайт поставлялся соответствующий локализованный продукт.
Важные моменты управления качеством, которые нужно иметь в виду. Установка еРИО провайдером и конфигурационная группа должны использовать тщательно разработанный контрольный список качества, чтобы управлять процессом установки программного обеспечения для каждого решения еРИО. Контрольный список содержит документацию для настроек каждого устройства, внутренних проверок качества настроек и отчётность персонала, ответственного за установку и конфигурацию.
И, наконец, рекомендуется контрольная выборка качественной статистики по устройствам для проведения валидации на выборке субъектов для статистического контроля качества, чтобы удостовериться, что устройства и аксессуары, предназначенные для конкретного региона, являются правильными. Конечный результат заключается в обеспечении уверенности, что группа клинического исследования установила систему еРИО для сбора данных от субъектов по всему миру, и она может пройти регулятор-ную проверку [7, 13].
Выведение из эксплуатации
Что это такое? Выведение из эксплуатации — это процесс, осуществляемый системным провайдером, когда система для ввода данных и сервисов выводится из эксплуатации или списывается по окончании клинического исследования. Процесс вывода из эксплуатации гарантирует, что все открытые вопросы сняты с рассмотрения и закрыты. Этот последний шаг в процессе валидации состоит из следующих этапов:
1. Завершение работы с данными: гарантия того, что все данные пациента, которые были собраны, загружены из устройств пациентов в центральную базу данных провайдера еРИО. Это сопровождается отключением дальнейшей загрузки данных и блокировки базы данных для скачивания в соответствии с потребностями группы исследования.
2. Возвращение устройств (конкретно — КПК): подсчёт возвращённых устройств, а также их очистка (как от основного ПО, так и от сопутствующих), переработка для последующих исследований или утилизация.
3. Документация: гарантии, что инвентаризация всех необходимых документов проверки и записи находятся в архивном хранилище поставщика.
4. Уведомления: уведомление всех внутренних и внешних сторон поддержки и отказ от услуг, которые более не потребуются.
Почему это важно? Вывод из эксплуатации гарантирует, что устройства, системы и услуги, настроенные для исследования, больше не находятся в использовании, что все собранные данные были переданы исследовательской группе, и остались только официальные копии.
Вовлечённость группы клинического исследования. Группа должна быть осведомлена о процессах вывода системы из эксплуатации провайдером ePRO. Это подтверждает конфиденциальность и позволяет избежать непреднамеренного или ошибочного сбора данных.
Важные процессы управления качеством, о которых нужно знать. Выводящая ePRO из эксплуатации команда провайдера должна использовать тщательно разработанный контрольный список, который обеспечивает документирование процесса на каждом устройстве, внутреннюю оценку качества процессов и отчётность сотрудников, исполняющих эти процессы [7, 13].
Выводы
Валидация электронных систем для сбора данных PRO является критически важным компонентом для получения разрешения регуляторных органов на проведение клинического исследования. В этом отчёте рассматриваются технические аспекты систем сбора данных ePRO и процесса их валидации, а также распределение обязанностей при совместной разработке системы группой клинического исследова-
Литература
ния и системным провайдером. В результате, отчёт должен улучшить понимание требований к проверке технологий спонсорами клинических исследований, чтобы обеспечить основу для сравнения различных поставщиков систем ePRO и их соответствующих предложений об услугах.
Благодарности
Авторы искренне благодарны следующим членам ISPOR за их вклад в разработку этих совместных надлежащих исследовательских практик, указанных в данном отчёте: Katy Benjamin, Stephen Coons, Sonya Eremenco, Ancilla Fernandes, Alison Greene, Parul Gupta, Syed Umer Jan, Sandra Kane-Gill, Smita Kothari, Tamar Lasky, Yvonne Lis, Damian McEntegart, Wilhelm Muhlhausen, Hannah O'Gorman, Raymond Panas, Yong Joo Rhee, Bob Smith, Jun Su, Etta J. Vinik, and Shaowei Wan.
Источник финансовой поддержки
В поддержку этого исследования не было вложено никаких средств.
Дополнительные материалы
Дополнительные материалы к этой статье можно найти в онлайн-варианте по гиперссылке http:// dx.doi.org/10.1016/j.jval.2013.04.002
Или, при необходимости строгой копии статьи: www.valueinhealthjournal.com/issues (выберите том, тему и статью).
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/Device-RegulationandGuidance/ 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., BranningR.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].
