CC BY
137
©КОЛЛЕКТИВАВТОРОВ,2015 УДК 004.65:615.1
Валидация фармацевтических информационных систем: базы данных и лабораторные информационные менеджмент-системы
К.А. Кошечкин, Е.В. Гладкая, Я.Ю. Кондратьева
Федеральное государственное бюджетное учреждение «Научный центр экспертизы средств медицинского применения» Министерства здравоохранения Российской Федерации, 127051, Москва, Россия
Резюме: В статье описаны основы проведения валидации баз данных и лабораторных информационных менеджмент-систем, используемых в фармацевтических организациях. Принципы оформлены на основе международных требований системы OMCL и международных стандартов системы ISO. Представлены общие подходы к валидации для этих типов информационных систем, оценку выбора аппаратного и программного обеспечения, требования к порядку их установки и настройки. Описаны требования к проверочным наборам данных и общей методологии проведения валидационных тестов. Также описана возможность валидации не только нового программного обеспечения, но и уже используемого.
Ключевые слова: валидация; информационные системы; информатизация здравоохранения; автоматизированные информационные системы; вычислительные информационные системы; персональный компьютер.
Библиографическое описание: Кошечкин КА, Гладкая ЕВ, Кондратьева ЯЮ. Валидация фармацевтических информационных систем: базы данных и лабораторные информационные менеджмент-системы. Ведомости Научного центра экспертизы средств медицинского применения 2015; (3): 23—27.
VALIDATION OF PHARMACEUTICAL INFORMATION SYSTEMS: DATABASES AND LABORATORY INFORMATION MANAGEMENT SYSTEMS K.A. Koshechkin, E.V. Gladkaya, Ya.Yu. Kondratieva
Federal State Budgetary Institution «Scientific Centre for Expert Evaluation of Medicinal Products» of the Ministry of Health of the Russian Federation, 127051, Moscow, Russia
Abstract: The article describes the basic principles of validation of the databases and laboratory information management systems used by pharmaceutical organizations. The principles are arranged on the basis of international OMCL network requirements and ISO standards. The article presents the general approaches to validation of these types of information systems and evaluation of soft- and hardware choices, and the requirements to the procedure of installation and the settings of those. It contains the requirements to test data sets and general methodology for conducting the validation tests. Additionally, it covers the possibility to validate not only new software, but also the software currently in use.
Key words: validation; information systems; computerization of healthcare; automated information systems; computable information systems; personal computer.
Bibliographic description: Koshechkin KA, Gladkaya EV, Kondratieva YaYu. Validation of pharmaceutical information systems: databases and laboratory information management systems. Scientific Centre for Expert Evaluation of Medicinal Products Bulletin 2015; (3): 23-27.
Все программное обеспечение, представляющее собой средства взаимодействия с базами данных, где хранятся результаты испытаний, и имеющее средства формирования отчетов, должно проходить процедуру валидации. Если система основана на использовании коммерческого программного продукта для управления базами данных, например, Microsoft Access, она может считаться валидированной по основным параметрам. Тем не менее, минимальный перечень данных должен быть собран и актуализирован в досье каждого такого программного продукта. В них входят следующие позиции:
- схематическое представление базы данных;
- перечень форм, запросов, макросов, типов полей, изменение которых может оказать влияние на результат работы системы и которые, следовательно, должны отслеживаться;
- каждый пользователь должен иметь индивидуальную учетную запись, защищенную паролем;
- права пользователей должны быть разграничены;
- правила использования системы должны быть зафиксированы в документации;
- каждое изменение для внесения исправлений или устранения ошибок должно документироваться.
Общие подходы к валидации для этих типов информационных систем заключаются в масштабировании объемов проводимых работ на основе управления рисками. Управление рисками включает в себя анализ возможностей влияния информационной системы на качество и целостность получаемых данных.
Валидационные документы и результаты тестов, проводимые поставщиком программного обеспечения, могут быть перенесены на собственный процесс валидации. Эти работы и тесты не требуется повторять на стороне покупателя информационной системы. Поставщик должен быть предварительно оценен путем опросного листа или при помощи проведения аудита.
Для гарантии корректного проведения валидации должен быть создан валидационный план. Он включа-
Ведомости НЦЭСМП
ет все действия, необходимые для проведения валида-ции, такие как изучение требований пользователей, изучение плана разработки, стратегии тестирования, проверка верности переноса данных, изучение валидацион-ной документации и тестирование пригодности всей системы.
План включает в себя даты, ответственных лиц и критерии оценки для каждой позиции или хотя бы ссылки на сами тесты, содержащие критерии оценки в своем составе. План валидации утверждается ответственным лицом перед началом процедуры. Тестовые данные и инструкции по их проведению могут быть подготовлены позднее, если работа ведется по этапам.
Процесс валидации электронных баз данных представляет собой часть работы по валидации комплексных информационных систем, использующих базы данных в своей работе. Валидацию баз данных можно представить как процесс, состоящий из нескольких этапов.
Этап первый включает в себя оценку выбора программного и аппаратного обеспечения. Основным принципом при оценке является соответствие требованиям пользователей. Необходимые пользователям возможности должны быть зафиксированы в виде документа, описывающего функциональные, технические и организационные требования, которые предъявляет заказчик к системе. В соответствии с ними система должна быть реализована и в дальнейшем оцениваться.
Требования к системе должны отражать определенную информацию:
- описание используемого программного обеспечения, например используемый тип базы данных Excel, Access, Oracle;
- требования к аппаратному обеспечению и операционной системе;
- описание функций, которые выполняет база данных;
- Описание свойств данных, хранимых в системе;
- терминология, используемая в документации, особенно касающаяся полей для ввода данных;
- схема базы данных с указанием типов полей и связей между таблицами;
- описание макросов, формул и команд управления;
- описание входных данных с указанием формата, разделителей, единиц измерения;
- перечень обязательных для заполнения полей;
- описание способов защиты фильтров, рабочих таблиц и других элементов базы данных от изменения пользователем;
- план переноса данных, если это необходимо;
- описание интерфейсов для связи с другими компонентами системы, если они есть.
В случае простой базы данных вместо схемы таблиц может быть представлен набросок потоков данных.
Полученная спецификация, содержащая требования заказчика к базе данных, должна быть утверждена ответственным лицом. Внесение изменений в перечень требований возможно, однако все изменения должны прослеживаться. Спецификации требований должны иметь уникальные номера версий. Новые требования или изменения старых должны быть доведены до сведения всех участников работы системы.
Второй этап валидации электронных баз данных включает в себя установку и запуск в эксплуатацию. Корректность установки системы и интеграции ее в
информационно-техническое окружение должна быть проверена и подтверждена документально. В Акте установки должны быть отображены требования к операционной системе и аппаратным комплектующим. Также фиксируются сведения о реальных характеристиках среды, где была произведена инсталляция. В большинстве случаев база данных, административная информационная система, лабораторная информационная система или электронный журнал лаборатории сопрягаются через сетевые интерфейсы для работы с другими программами и оборудованием. Корректность интеграции должна быть подтверждена вместе с подтверждением работоспособности системы.
В ходе проведения установки формируется акт, который должен отображать ряд параметров:
- проверка требований к системным ресурсам, таким как производительность процессора, свободное место на диске, права доступа для выполнения установки;
- документация на все компоненты системы, или хотя бы описание компонент, их модели и версии с указанием даты установки;
- перечень пользователей или групп пользователей, имеющих доступ в систему, включая тип имеющегося доступа;
- проверка интеграции или наличия связи, которая проводится за счет передачи на обработку во внешнюю среду пакета данных с известным результатом его обработки. После выполнения необходимых действий в ва-лидируемой системе проводится сравнение результатов с заранее известными корректными результатами обработки тестового набора данных.
В случае сопровождения установки разработчиком или сторонним подрядчиком данные проверки могут быть выполнены исполнителем работ с составлением соответствующего документа после их окончания.
Запуск системы сопровождается формированием акта ввода в эксплуатацию, который должен отображать ряд следующих позиций:
- проверка схемы базы данных;
- проверка соответствия функциональным требованиям, которая проводится при помощи заранее сформированных опытных наборов исходных данных;
- проверка на ввод значений, выходящих за описанные в требованиях интервалы. Система должна корректно обрабатывать ошибки при несоответствии требованиям к исходным данным;
- проверка вывода сообщений о других типах ошибок;
- проверка защиты от неавторизованного доступа к вводу данных и управлению системой;
- проверка защиты от опечаток при вводе типичных видов данных, например, даты;
- тест на восстановление системы из резервной копии;
- подтверждение переноса данных, если такие работы планировались;
- подтверждение соответствию требованиям по защите данных, если такие были предъявлены;
- тест системы в целом при помощи пакета данных, с известным результатом по манипуляции с ними. При этом должно учитываться соответствие спецификации на основе требований пользователей.
Количество проверочных наборов исходных данных, используемых для проверки функционала систе-
мы, зависит от определенного класса системы на основе управления рисками. Должно быть использовано не менее двух наборов значений, находящихся в пределах рабочего диапазона. Для проверки работы системы со значениями, выходящими за требуемые интервалы, должны использоваться отдельные наборы для критически низких и высоких величин. Аналогичные подходы могут быть использованы для проверки сообщений об ошибках.
В случае валидации базы данных с большим количеством функций может быть принято решение о снижении количества тестов для проверки функциональных требований. Это решение принимается на основе управления рисками и должно быть зафиксировано документально. Также возможно проведение обобщенных тестов с известным набором данных, соответствующих наиболее важным задачам, которые выполняются базой данных, вместо проверки каждой функции по отдельности.
Для проверки интегральной целостности базы данных должны быть проведены попытки неавторизованного ввода данных, а также ввод некорректных данных. Проверка полноты переноса данных может выполняться в объеме от 6 записей до 100% от переносимой информации. Точное количество определяется на основе класса системы в управлении рисками. Данные в установленной системе сравниваются с данными источника. Такое сравнение может быть проведено программными методами.
Третий этап включает в себя периодическую проверку функциональных возможностей, а также проверку после внесения изменений в систему или ее окружение или в случае выявления ошибок в работе. Периодические проверки с использованием известных наборов данных выполняются с заранее заданным интервалом и необходимы для гарантии корректной работы системы на всем протяжении периода ее эксплуатации.
При проведении этой проверки готовится ряд дополнительных документов, отражающих особенности ее проведения:
- описание базы данных, включающее графическую схему таблиц, описание процессов, связей ячеек и таблиц, макросов, функций и т.д;
- экранные копии соответствующих рабочих таблиц и фильтров;
- спецификация требований пользователей, хотя бы последняя ее версия;
- акты установки системы и проверки, выполненной после установки, включающие информацию об установленной конфигурации;
- описания проверочных тестов, записи результатов их прохождения;
- отчет о валидации, если ранее проводилась;
- уникальный идентификатор версии базы данных;
- планы и отчеты о проведении обучения, если запланировано и проводилось;
- инструкции пользователя, если имеются;
- инструкции по проведению обслуживания, если имеются.
Документация должна позволять отследить валида-цию, обслуживание и разработку базы данных в любой момент ее жизненного цикла лицом, не участвовавшим в этих процессах. Каждое изменение в документах из данного перечня должно быть прослеживаемым.
Управление базами данных не является напрямую частью валидационного процесса, однако эти принципы во многом влияют на проведение валидации и формирование спецификаций пользовательских требований к системе.
Электронная база данных является надежным источником данных на протяжении всего периода эксплуатации, если гарантированно проводятся необходимые процедуры по ее обслуживанию:
- управление конфигурацией проводится каждый раз вместе с изменением конфигурации информационной системы, частью которой она является. Эти изменения должны быть отражены в соответствующих журналах, включая дату интеграции и версии базы данных и всей информационной системы;
- контроль изменений должен вестись относительно всех изменений в структуре, связях или свойствах полей. Все изменения должны фиксироваться в журнале базы данных с указанием изменений и ответственного лица;
- управление исправлениями и обновлениями в операционной системе должно вестись в виде журнала установленных исправлений и обновлений. Должны быть сформулированы правила установки обновлений и исправлений с указанием интервала, например, «ежедневно ночью», или «в выходные». После установки обновлений и исправлений необходимо проведение тестирования с известным набором данных;
- управление ошибками — процесс, который включает в себя сбор данных о выявленных ошибках. Результаты должны быть оформлены в виде списка с указанием корректирующих действий и действий по предотвращению;
- организация службы поддержки пользователей, при наличии такой возможности;
- резервное копирование базы данных с контролем целостности резервных копий. Указывается также тип резервного копирования, инкрементное или полное, периодичность создания резервных копий;
- контроль безопасности доступа, проверка перечня учетных записей, безопасности их паролей и правила предоставления доступа;
- проверка плана по исправлению неисправностей в случае наличия аварий с учетом разных типов происшествий;
- порядок обучения, если оно проводится.
В случае простой базы данных требования к управлению электронными базами данных могут быть сокращены с учетом концепции управления рисками. Полный список проверок необходимо проводить для комплексных баз данных.
Важным является разграничение ответственности по настройке и управлению базами данным между внутренним информационно-техническим подразделением и использующим систему персоналом. Это особенно важно при управлении установкой обновлений и исправлений в системе, а также для резервного копирования.
Основой любой ЛИМС является база данных. Все требования, которые предъявляются к электронным базам данных, должны быть соблюдены при валидации ЛИМС. Принципы валидации ЛИМС являются наиболее полными по сравнению с другими видами информационных систем. Они также могут применяться при ва-лидации электронных лабораторных журналов и адми-
Ведомости НЦЭСМП
нистративных информационных систем в сокращенном объеме, адекватном выполняемым валидируемой системой задачам.
Валидация ЛИМС также может быть разделена на несколько этапов.
Первый этап включает в себя оценку программного и аппаратного окружения информационной системы. Должна быть сформирована спецификация требований пользователей к системе, которая должна включать в себя весь требуемый функционал, технические и организационные сведения. Она должна охватывать вопросы информационной безопасности и защиты данных.
Каждое требование должно быть записано отдельной строкой с уникальным номером. Этот номер требования должен прослеживаться как при разработке системы, так и при последующей валидации.
Второй уровень включает в себя установку и ввод в эксплуатацию. Процесс установки должен быть детально описан. Установку должен проводить только квалифицированный персонал. При установке должен быть заполнен протокол, где необходимо фиксировать каждый шаг установки и критерии оценки корректности его выполнения. Это необходимо для возможности прослеживания установки и оценки ее корректности.
При проведении валидации должны учитываться следующие аспекты:
- информационная сеть должна соответствовать требованиям спецификации и обеспечивать необходимую производительность;
- конфигурация рабочих мест пользователей должна быть зафиксирована документально и соответствовать требованиям;
- серверы установки ЛИМС или ЭЛЖ должны соответствовать требованиям спецификации по своей конфигурации и производительности;
- периферийные устройства и интерфейсы связи, при установке каждый из них должен быть проверен;
- исходный код, правила разработки, инструменты разработки должны быть доступны и возможность ими воспользоваться должна быть гарантирована;
- должна быть подтверждена целостность данных на основе сравнения обработанных и исходных материалов, также должны быть проверены ограничения доступа к данным и способы проверки этих параметров;
- инструкции и руководства должны быть представлены для всех процедур. Например, описание программного обеспечения, инструкция по установке системы, руководство по валидации, руководства по обучению, инструкции пользователей, инструкция по об-
ЛИТЕРАТУРА_
1. OMCL guideline on Validation of computerised systems. Core document (PA/ PH/OMCL (08) 69). Available from: https://www.edqm.eu/medias/fichiers/ Validation_of_Computerised_Systems_Core_Document.pdf.
2. ISPE Glossary of Pharmaceutical and Biotechnology Terminology - Good Automated Manufacturing Practice (GAMP). International Society for Pharmaceutical Engineering. 25 September 2011. Retrieved 28 February 2012.
3. ГОСТ ИСО/МЭК 17025-2009. Общие требования к компетентности испытательных и калибровочных лабораторий.
4. Guidance for the management of computers and software in laboratories with reference to ISO/IEC 17025:2005 (Technical Report № 2/2006, October 2006, eurolab).
5. Меркулов ВА, Сакаева ИВ, Кошечкин КА и др. Опыт создания системы управления качеством в лабораториях на примере практики внедрения Лабораторной информационной системы. Ведомости Научного центра экспертизы средств медицинского применения 2012; (4): 11-8.
служиванию, инструкция по созданию и восстановлению резервных копий, руководства по управлению системой и документация для разработчиков также должны быть подготовлены;
- поставщик системы также должен быть оценен;
- персонал должен быть обучен и квалифицирован, для обучения должны быть подготовлены планы и графики.
Третий этап включает в себя плановые проверки и проверки после изменений, внесенных в систему или ее окружение. В рамках него должны проводиться проверки на основе наборов исходных данных для проверки основных функций системы. Для каждой функции должен использоваться отдельный набор.
Ранее речь шла о валидации новых информационных систем, которые могут быть валидированы с момента сбора требований для их разработки. Однако существует необходимость валидации уже используемого программного обеспечения. Основными критериями при этом должны быть следующие позиции:
- проведение оценки рисков;
- составление описи доступных документов, таких как описание системы, концепция работы;
- проверка корректности установки системы, например, требований к операционной системе;
- создание отчета об эксплуатации, в котором должно быть описано общее состояние системы, как долго она эксплуатируется, какие встречаются неполадки в работе;
- восполнение отсутствующих документов, например, может быть проведен реверсный инжиниринг функциональных возможностей и описание их в виде кратких спецификаций;
- общий тест с обычным сравнением полученных и ожидаемых результатов;
- формальный допуск в работу.
Соблюдение международных стандартов обеспечения качества работы информационных систем в сфере оценки лекарственных средств медицинского применения позволит привести отечественную систему фармацевтических лабораторий на уровень выполнения работ, который необходим для международного признания результатов исследований. Валидация представляет собой непрерывный процесс, подготовка к которому должна начинаться с этапа создания информационной системы и который должен регулярно повторяться на всем протяжении ее эксплуатации. Соблюдение требований к информационным системам позволит повысить общий уровень ответственности при выполнении исследовательских работ в лабораториях.
REFERENCES_
1. OMCL guideline on Validation of computerised systems. Core document (PA/ PH/OMCL (08) 69). Available from: https://www.edqm.eu/medias/fichiers/ Validation_of_Computerised_Systems_Core_Document.pdf.
2. ISPE Glossary of Pharmaceutical and Biotechnology Terminology - Good Automated Manufacturing Practice (GAMP). International Society for Pharmaceutical Engineering. 25 September 2011. Retrieved 28 February 2012.
3. State Standard ISO/MEK 17025-2009 General requirements for the competence of testing and calibration laboratories.Moscow; 2009 (in Russian).
4. Guidance for the management of computers and software in laboratories with reference to ISO/IEC 17025:2005 (Technical Report № 2/2006, October 2006, eurolab).
5. Merkulov VA, Sakaeva IV, Koshechkin KA, et al. The experience in establishing Quality Management System in laboratories as exemplified by introducing Laboratory Information System. Vedomosti Nauchnogo tsentra ekspertizy sredstv meditsinskogo primeneniya 2012; (4): 11-18 (in Russian).
6. Validation of computerised calculation Systems: example of validation of in-house software PA/PH/OMCL (08) 87 2R. Available from: https://www. edqm.eu/medias/fichiers/NEW_Annex_1_Validation_of_computerised_ calculation.pdf.
7. Validation of databases (db), laboratory Information management systems (lims) and Electronic laboratory notebooks (eln). Available from: https:// www.edqm.eu/medias/fichiers/NEW_Annex_2_Validation_of_Databases_ DB_Laboratory_.pdf.
8. Validation of computers as part of test Equipment. Available from: https:// www.edqm.eu/medias/fichiers/NEW_Annex_3_Validation_of_computers_ as_part_of_tes.pdf.
9. Smith P (1 December 2008). 20th Anniversary Special Feature: Validation and qualification. Pharmaceutical Technology Europe 20 (2). Retrieved 28 February 2012.
10. DeSpautz J, Kovacs KS, Werling G (11 March 2008). GAMP Standards For Validation Of Automated Systems. Pharmaceutical Processing. Retrieved 28 February 2012.
ОБ АВТОРАХ:_
Федеральное государственное бюджетное учреждение «Научный центр экспертизы средств медицинского применения» Министерства здравоохранения Российской Федерации. Российская Федерация, 127051, Москва, Петровский бульвар, 8.
Кошечкин Константин Александрович. Начальник управления информатизации, канд. биол. наук.
Гладкая Елена Владимировна. Начальник управления обеспечения качества. Кондратьева Ярослава Юрьевна. Заместитель начальника управления обеспечения качества.
6. Validation of computerised calculation Systems: example of validation of in-house software PA/PH/OMCL (08) 87 2R. Available from: https://www.edqm. eu/medias/fichiers/NEW_Annex_1_Validation_of_computerised_calcula-tion.pdf.
7. Validation of databases (db), laboratory Information management systems (lims) and Electronic laboratory notebooks (eln). Available from: https:// www.edqm.eu/medias/fichiers/NEW_Annex_2_Validation_of_Databases_ DB_Laboratory_.pdf.
8. Validation of computers as part of test Equipment. Available from: https:// www.edqm.eu/medias/fichiers/NEW_Annex_3_Validation_of_computers_ as_part_of_tes.pdf.
9. Smith P (1 December 2008). 20th Anniversary Special Feature: Validation and qualification. Pharmaceutical Technology Europe 20 (2). Retrieved 28 February 2012.
10. DeSpautz J, Kovacs KS, Werling G (11 March 2008). GAMP Standards For Validation Of Automated Systems. Pharmaceutical Processing. Retrieved 28 February 2012.
AUTHORS:_
Federal State Budgetary Institution «Scientific Centre for Expert Evaluation of Medicinal Products» of the Ministry of Health of the Russian Federation, 8 Petrovsky
Boulevard, Moscow, 127051, Russian Federation.
Koshechkin KA. Head of Office of informatization. Candidate of Biological Sciences.
Gladkaya EV. Head of Office of quality assurance.
Kondratieva YaYu. Deputy head of Office of quality assurance.
АДРЕС ДЛЯ ПЕРЕПИСКИ:
Кошечкин Константин Александрович; Koshechkin@expmed.ru
Статья поступила 31.07.2015 г.
Принята к печати 17.08.2015г.
