Коллеги, ещё одна типовая ошибка при составлении Руководства по качеству — желание прописать всё и сразу.
Причём всё — это по каждому требованию стандарта, по каждой запятой.
Желание, конечно, похвальное 😊 Но если у Вас уже есть отдельная процедура, в которой весь процесс детально описан, с формами, ролями и маршрутами — зачем дублировать всё это в РК?
📌 Пример: раздел 7.3 «Проектирование и разработка». Там аж 10 подпунктов. Но в самом начале — требование: должна быть документированная процедура.
Вот и дайте ссылку на неё! А в РК напишите по-человечески, например так:

- Процесс проектирования и разработки регулируется процедурой СОП 7.3, в которой описан порядок планирования, исполнения и мониторинга.
- Формы записей — обязательные и рекомендуемые — указаны в самой процедуре.
- Проектированием занимается отдел главного конструктора.
- На этапах верификации и валидации подключаются ОТК и регуляторный отдел.
- На стадии технологической подготовки — производственный отдел.

И никаких простыней на 3 страницы 👌

Коллеги, уже не в первый раз сталкиваюсь с производителем медицинского изделия, у которого помимо ISO 13485 ещё и внедрён ISO 9001. И каждый раз задаюсь одним и тем же вопросом: зачем?
Вот реально — что движет Вашим руководством, когда оно решает повесить на себя дополнительные требования, дополнительные проверки, дополнительные риски несоответствий? Какие тут логические или хотя бы экономические мотивы?
Я вот недавно для одного такого предприятия готовил пояснительную записку на тему целесообразности исключения ISO 9001 из области применения СМК — прилагаю ниже. Может, кому пригодится для внутреннего диалога с "убеждёнными сторонниками двух стандартов сразу". 😊

Прошёл Я тут недавно обучение по ГОСТ IEC 62304-2022, Спасибо Михаилу Виноградову 😊 Теперь вот понимаю что в 99 процедурах по управлению записями из 100 которые я у кого-либо встречал есть вот этот вот проблема которую только что я тут одному клиенту описал:
------------
Основные записи СМК в Вашей компании, по сути, — это, на мой взгляд, именно те записи, которые сопровождают разные стадии разработки, внедрения и поддержки ПО. Особенно если речь идёт о медизделиях с ПО — тут без этого никуда.
Чтобы разобраться, какие именно записи критичны, стоит обратить внимание на стандарт ГОСТ IEC 62304-2022. Я вставил ниже несколько ключевых определений из этого стандарта — они, на мой взгляд, имеют максимальное значение именно для управления записями в контексте жизненного цикла ПО. В идеале, в данной процедуре следовало бы раскрыть специфику управления такими записями: как обеспечивается прослеживаемость, какие документы считаются записями, где и как они хранятся, как защищаются от изменений, и как осуществляется доступ к ним.
Сейчас же в процедуре даже Jira (или другой аналогичный инструмент, который наверняка используется при разработке) не упоминается вообще… ☹️ Это делает процедуру довольно «отвязанной» от реальных процессов сопровождения жизненного цикла ПО.
Если компания всерьёз планирует реализовывать IEC 62304, стоит как минимум подумать над включением:
- понятий вроде «артефакт жизненного цикла ПО», «запись о жизненном цикле ПО», «управление конфигурацией ПО», «результаты тестирования ПО»;
- описания, какие записи формируются на каждой стадии разработки (требования, проектирование, верификация, тесты, исправления);
упоминаний об инструментах (таких как Jira, Git, Confluence), через которые ведутся эти записи — даже если на уровне ссылки или примечания;
- того, как эти записи попадают в СМК, кто их регистрирует, кто за них отвечает, и как они проверяются при аудитах.
Без этих дополнений процедура, скорее, относится к "бумажной" СМК, а не к современной инженерной системе управления разработкой программных компонентов медицинских изделий.

Коллеги, если вы пишете процедуру по валидации программного обеспечения с целью выполнения требований пунктов 4.1.6, 7.5.6 и 7.6 стандарта ISO 13485, то рекомендую рассмотреть следующее дополнения к определению понятия "программное обеспечение":
Также к программному обеспечению, подлежащему валидации, приравниваются:
− индивидуальные или групповые скрипты, макросы, шаблоны обработки данных (в том числе Excel, Word, Python, R и др.), если они участвуют в критичных для качества процессах;
− агенты искусственного интеллекта (например, голосовые помощники, чат-боты, системы автоклассификации), применяемые в операциях, влияющих на соответствие продукции;
− облачные сервисы с постоянным доступом и обработкой/хранением производственных, проектных, контрольных или регуляторных данных;
− интеграционные платформы, API-шлюзы и другие средства автоматического обмена данными между системами;
− специализированные веб-приложения и личные кабинеты, используемые для взаимодействия с поставщиками или регуляторными структурами, если они участвуют в операциях, влияющих на качество.
Программное обеспечение, установленное на мобильных устройствах (планшетах, смартфонах), под-лежит валидации в случае, если оно используется в производственных, контрольных или вспомогательных процессах, а также в операциях, влияющих на качество продукции или функционирование СМК. К таким случаям могут относиться, например, мобильные приложения для сбора производственных данных, проведения инспекций, контроля параметров окружающей среды или доступа к документации.
Исключение и ПО для валидации: каналы коммуникации, такие как чаты, группы и мессенджеры (например, WhatsApp, Telegram), не подлежат валидации как программное обеспечение, но подлежат регламентации и контролю в рамках процедур управления информацией, в том числе в части защиты персональных и конфиденциальных данных.

Добрый день коллеги, хочу вернуться к вопросу внедрения требований ISO 9001 на предприятиях занимающихся МИ...
Я выше уже писал некоторые соображения на эту тему, сейчас хочу добавить принципиальный момент связанный с этими двумя стандартами в вопросе проектирования. Прикрепляю здесь слайд который я вставил свою презентацию по обучению СМК. Критикуйте! 😎

Про медизделия...

У деда походу кардиостимулятор на корпус пробивает

👉ШУТ - подписаться

Коллеги, Извините, но всё-таки похвастаюсь ☺️ Очень интересная формулировка в отзыве попалась 😍
Закончился двухдневный семинар по спецпрограмме составленной самим клиентом . По сути, получилось что-то среднее между семинаром и консультацией...
В свою очередь тоже хочу выразить благодарность всем участникам за интересные вопросы и даже некоторые новые для меня знания которые я непременно вставлю в свой материал.

Чтобы наблюдение аудита получилось понятным, полным, "вкусным" 😊 рекомендую использовать при описании глаголы в настоящем времени - вот как будто вы стоите там рядом с объектом наблюдения и в режиме онлайн описываете что видите и что люди делают

Коллеги,
Позвольте сделать несколько объявлений по ближайшим обучающим мероприятиям с участием вашего покорного услуги - занесите себе в календарь 😊

17–19 июня 2025 "Директор по качеству" - авторский семинар который я провожу один раз в год в июне в очно-дистанционном формате. Семинар не имеет отраслевой привязки, я рассказываю на нём о том как понимать процессный подход, риск-менеджмент, как всё это увязывать с инструментами СМК, с целеполаганием и рефлексией, как распределять функции, полномочия и ответственность... За последние 4 года как я его провожу, на нём побывали представители Росатома, РЖД и других крупных трансроссийских холдингов. Учитывая мою специализацию на медицинской технике, очень много привожу примеров именно из этой отрасли. Крайне рекомендую приехать в Санкт-Петербург. У нас в это время самый разгар белых ночей 😊

7-8 июля 2025 г. (онлайн-семинар) - "Аудит поставщика для производителей медицинских изделий» с выдачей сертификата «Аудитор второй стороны» с занесением в Реестр профессионалов в области управления Евразийской ассоциации по оценке соответствия и сертификации (ECA) – член APAC. Подробнейшим образом разберём пункты 7.4 и 4.1.5. Расскажу чем аутсорсинг отличается от трансфера, а трансфер от экспедайтинга 😊

Возможно будут ещёпара открытыых семинаров в сентябре - следите за рассылкой и информацией в телеграмм-группе https://t.me/FAQ_QMS

🎯 FAQ по СМК — коротко, по делу, без галстука

Подготовил очередную 47-ю подборку реальных вопросов, которые мне часто задают в переписке и на семинарах. Отвечаю просто и по существу:
🔍 Можно ли совмещать функции ОТК и менеджера по качеству?📝 Кто должен подписывать мастер-файл?📂 Как фиксить актуальность документов?📊 PMS-отчёт: на каждую модель или можно один общий?⚠️ Что писать про риски в корректирующих действиях?
С примерами, комментариями и ноткой полевого юмора от аудитора, который всё это видел своими глазами 😊
📌 Полезно для тех, кто внедряет ISO 13485, и для тех, кто просто хочет навести порядок в документации.
📮 Получите файл, подписавшись на мою рассылку новостей по СМК и ответов на ваши самые интересные вопросы — http://getcemark.ru(на сайте короткая анкета — заполняется за 1 минуту)

Поступил такой вопрос: Можно ли назначить представителя руководства по качеству (ПРК) по ISO 13485 из внешней организации, по договору?
мой ОТВЕТ: Да, можно.Стандарт ISO 13485:2016 не требует, чтобы ПРК был штатным сотрудником. Главное — чтобы у него были официально оформленные полномочия, ответственность и подотчётность высшему руководству.
⚠️ Но важно:
* ПРК должен реально участвовать в управлении СМК.
* Его доступность и вовлечённость нужно закрепить в договоре.
* Ответственность за СМК остаётся на производителе — это не "аутсорсинг ответственности", а делегирование полномочий.
📌 Подходит для малых компаний и региональных представительств.

Получил вот такой вопрос от одного клиента:
"Хотела уточнить по поводу файлов юзабилити или эксплуатационной пригодности. Как показывает практика, это должен быть отдельный файл или можно сделать часть с описанием юзабилити в файле менеджмента рисков? Или можно сделать это частью тех.файла на аппарат?"
Мой короткий ответ такой:
А. Что требуют нормативы:
- IEC 62366-1:2015 + A1:2020, пп. 4.1 и 4.2 ― должен оформляться Usability Engineering File (UEF); при этом записи UEF «могут быть частью других документов и файлов», включая файл по управлению рисками.
- ISO 14971:2019, п. 4.5 ― Risk Management File (RMF) обязан содержать/ссылаться на все результаты риск-менеджмента и обеспечивать прослеживаемость по каждому опасному фактору; формат свободный.
- ISO 13485:2016, п. 4.2.3 ― на каждое изделие создаётся Medical Device File, где должны быть (или на которые должны ссылаться) RMF и UEF.
B. Практика, проверенная на аудитах:
1. UEF как самостоятельный файл: удобно для глубокого анализа рисков связанных с человеческим фактором; минус – дублирование данных с RMF.
2. UEF как раздел RMF: единый источник достоверной информации по всем вопросам эксплуатационной пригодности и управления рисками, идеальная прослеживаемость; минус – RMF-файл становится «тяжёлым», если не используются гиперссылки на связанные документы и записи СМК.