Forwarded from Мустафина Про медизделия | Регистрация | Сертификация | Лицензия | Закупки | Маркировка | РФ и ЕАЭС
Календарь отечественного производителя медицинских изделий
Сохраняйте этот календарь, чтобы не пропустить важные сроки подачи отчетов и документов.
Основные даты и события
→ Отчетность
• 20 января, 20 апреля, 20 июля, 20 октября – подача отчета в Росстат по приказу № 240. 🔗Подробнее об отчете
• До 1 февраля – подача отчета ПКМ для медизделий классов риска 3 и имплантируемые 2б. 🔗 Подробнее об отчете
• Отечественные производители также должны подавать отчетность по приказу РЗН 11020 в течение 15 рабочих дней после ввода изделий в обращение (не отражено в календаре) 🔗Подробнее об отчете
→ Регистрация и внесение изменений
• До 28 февраля 2025 г. – документы рассматриваются по правилам ПП РФ 1416.
С 1 марта по 30 декабря 2025 г.:
• документы рассматриваются по новым правилам ПП РФ 1684
• прием документов на внесение изменений будет доступен в электронном виде через личный кабинет
• старт приема документов на особенную процедуру регистрации для медизделий отечественного производства
→ Клинические исследования
• До 31 августа 2025 г. – результаты клинических исследований принимают в обычном формате.
• С 1 сентября 2025 г. – результаты клинических исследований медизделий должны загружаться в АИС РЗН через личный кабинет медорганизации.
Важно: проверьте, что исполнитель клинических исследований подал соответствующее уведомление до 01.09.2025, иначе результаты клиники придется переделывать. 🔗Подробнее о требованиях
→ Дедлайны
1 марта 2025 г. - приостановление действия регистрации МИ классов риска 3 и имплантируемые 2б, если не подан отчет ПКМ. 🔗 Подробнее об отчете
30 декабря 2025 г. – последний день приема документов на регистрацию по национальным правилам ПП РФ 1684.
Завтра выходит календарь зарубежного производителя.
→ Нужна помощь с подготовкой отчетов или регистрацией медизделий?
Свяжитесь со мной для консультации и начала работы:
📧 am@promedizd.com
📞 @mamovivo
+7-985-369-18-10
Telegram-канал "Про медизделия" @promedizd
Сохраняйте этот календарь, чтобы не пропустить важные сроки подачи отчетов и документов.
Основные даты и события
→ Отчетность
• 20 января, 20 апреля, 20 июля, 20 октября – подача отчета в Росстат по приказу № 240. 🔗Подробнее об отчете
• До 1 февраля – подача отчета ПКМ для медизделий классов риска 3 и имплантируемые 2б. 🔗 Подробнее об отчете
• Отечественные производители также должны подавать отчетность по приказу РЗН 11020 в течение 15 рабочих дней после ввода изделий в обращение (не отражено в календаре) 🔗Подробнее об отчете
→ Регистрация и внесение изменений
• До 28 февраля 2025 г. – документы рассматриваются по правилам ПП РФ 1416.
С 1 марта по 30 декабря 2025 г.:
• документы рассматриваются по новым правилам ПП РФ 1684
• прием документов на внесение изменений будет доступен в электронном виде через личный кабинет
• старт приема документов на особенную процедуру регистрации для медизделий отечественного производства
→ Клинические исследования
• До 31 августа 2025 г. – результаты клинических исследований принимают в обычном формате.
• С 1 сентября 2025 г. – результаты клинических исследований медизделий должны загружаться в АИС РЗН через личный кабинет медорганизации.
Важно: проверьте, что исполнитель клинических исследований подал соответствующее уведомление до 01.09.2025, иначе результаты клиники придется переделывать. 🔗Подробнее о требованиях
→ Дедлайны
1 марта 2025 г. - приостановление действия регистрации МИ классов риска 3 и имплантируемые 2б, если не подан отчет ПКМ. 🔗 Подробнее об отчете
30 декабря 2025 г. – последний день приема документов на регистрацию по национальным правилам ПП РФ 1684.
Завтра выходит календарь зарубежного производителя.
→ Нужна помощь с подготовкой отчетов или регистрацией медизделий?
Свяжитесь со мной для консультации и начала работы:
📧 am@promedizd.com
📞 @mamovivo
+7-985-369-18-10
Telegram-канал "Про медизделия" @promedizd
👍3🙏1
Коллеги, 03–06 марта 2025 года я провожу очно-дистанционный семинар (4 дня в Санкт-Петербурге) по теме: «Требования стандарта ISO 13485:2016/ГОСТ ISO 13485-2017 и другие регуляторные требования. Внутренний аудит процессов производства медицинских изделий». Проработаем все системные вопросы СМК и ключевые вопросы аудита. Хочу на этой группе опробовать свой новый тест 😊.
Кого заинтересовало - пишите в личку, пришлю заявку для подготовки договора
Кого заинтересовало - пишите в личку, пришлю заявку для подготовки договора
👍3
Коллеги, не стесняйтесь запрашивать в органе по сертификации резюме аудитора(ов), которого(х) они направляют к Вам на проверку. Вам же не только сертификат для украшения стены нужен 😉 , но и какая-то польза для процессов? 🥰
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Что такое "формирующее оценивание"
https://www.perplexity.ai/search/chto-takoe-formiruiushchee-ots-iUdUOhovRuKatkIPzZfphQ#0
https://www.perplexity.ai/search/chto-takoe-formiruiushchee-ots-iUdUOhovRuKatkIPzZfphQ#0
Perplexity AI
Что такое "формирующее оценивание"
Формирующее оценивание — это педагогическая технология, направленная на оценку процесса обучения, а не только его результатов. Оно включает в себя постоянную...
Ситуация:
Недавно столкнулся с интересным примером из практики. Консультант из ВНИИИМТа в рамках их проекта «одно окно» при внедрении СМК убедил клиента в том, что все запланированные мероприятия должны оформляться как предупреждающие действия, а любые незапланированные изменения — через процедуру корректирующих действий.
Клиент теперь, следуя этой рекомендации, любое изменение в процессах или документации оформляется через соответствующие формы, предусмотренные в его процедуре САРА по п.п. 8.5.2 и 8.5.3 стандарта ISO 13485.
Формально рекомендация была дана в рамках консалтинга, однако в ближайшее время клиент ожидает инспекционный аудит от той же организации — ВНИИИМТ. И, не исключено, что проверку будет проводить тот же специалист или его коллега. В итоге "совет" консультанта воспринимается как обязательное условие: иначе могут быть проблемы…
Оставим в стороне мигающий в этой ситуации аварийным цветом конфликт интересов - обратимся к СМК.
Нарушения требований ISO 13485 здесь нет — оформление предупреждающих и корректирующих действий действительно требуется стандартом. Однако ситуация демонстрирует методологическое смешение понятий и приводит к чрезмерной формализации: даже плановое изменение теперь требует запуска процедуры CAPA.
В нормальной практике корректирующие действия — это реакция на выявленные несоответствия и причины проблем. Предупреждающие действия — это ответ на потенциальные риски. Не каждое изменение в СМК связано с несоответствиями или рисками. Например, обновление инструкции, внедрение нового шаблона документа или плановое улучшение процесса вполне могут быть частью регулярной работы и оформляться в рамках обычного управления изменениями.
Следование букве, а не духу стандарта, превращает СМК в машину по производству бумаг. Сотрудники тратят время на формальные процедуры, которые не добавляют реальной ценности. В результате — больше бюрократии, меньше гибкости и результативности.
Этот случай — хороший повод обсудить важный методологический вопрос: в чём разница между корректирующими/предупреждающими действиями и просто изменениями в СМК? Как не перегрузить систему, не нарушая требований стандарта? Где граница между управлением несоответствиями и обычной деятельностью по улучшению?
Буду рад услышать мнение коллег: как Вы разграничиваете эти понятия у себя на практике?
Недавно столкнулся с интересным примером из практики. Консультант из ВНИИИМТа в рамках их проекта «одно окно» при внедрении СМК убедил клиента в том, что все запланированные мероприятия должны оформляться как предупреждающие действия, а любые незапланированные изменения — через процедуру корректирующих действий.
Клиент теперь, следуя этой рекомендации, любое изменение в процессах или документации оформляется через соответствующие формы, предусмотренные в его процедуре САРА по п.п. 8.5.2 и 8.5.3 стандарта ISO 13485.
Формально рекомендация была дана в рамках консалтинга, однако в ближайшее время клиент ожидает инспекционный аудит от той же организации — ВНИИИМТ. И, не исключено, что проверку будет проводить тот же специалист или его коллега. В итоге "совет" консультанта воспринимается как обязательное условие: иначе могут быть проблемы…
Оставим в стороне мигающий в этой ситуации аварийным цветом конфликт интересов - обратимся к СМК.
Нарушения требований ISO 13485 здесь нет — оформление предупреждающих и корректирующих действий действительно требуется стандартом. Однако ситуация демонстрирует методологическое смешение понятий и приводит к чрезмерной формализации: даже плановое изменение теперь требует запуска процедуры CAPA.
В нормальной практике корректирующие действия — это реакция на выявленные несоответствия и причины проблем. Предупреждающие действия — это ответ на потенциальные риски. Не каждое изменение в СМК связано с несоответствиями или рисками. Например, обновление инструкции, внедрение нового шаблона документа или плановое улучшение процесса вполне могут быть частью регулярной работы и оформляться в рамках обычного управления изменениями.
Следование букве, а не духу стандарта, превращает СМК в машину по производству бумаг. Сотрудники тратят время на формальные процедуры, которые не добавляют реальной ценности. В результате — больше бюрократии, меньше гибкости и результативности.
Этот случай — хороший повод обсудить важный методологический вопрос: в чём разница между корректирующими/предупреждающими действиями и просто изменениями в СМК? Как не перегрузить систему, не нарушая требований стандарта? Где граница между управлением несоответствиями и обычной деятельностью по улучшению?
Буду рад услышать мнение коллег: как Вы разграничиваете эти понятия у себя на практике?
👍10
Почему_не_все_изменения_в_СУК_должны_оформляться_через_CAPA_pdf.docx
163.8 KB
Рассмотрев ситуацию которую я описал выше пришлось подготовить специальный гайд. Используйте, критикуйте, улучшайте!
👍6
Компания производящая медизделия зачем-то навязала себе требования ISO9001 ☹️
Я понимаю когда бизнес делал это 10 лет назад - тогда про специфический стандарт для производителей МИ мало кто слышал и во многих тендерах в качестве критерия наличия СМК упоминалась только девятка. Но теперь-то!
Анализирую документы такой компании..
Вот, классическое несоответствие вызванное противоречием имеющем место в упомянутых выше двух стандартах:
😱 В РК (включая разделы, посвящённые политике качества, планированию, анализу рисков и ответственности руководства) используется термин «риск» без уточнения его смысла. Не проводится разграничение между понятием «риск» как неопределённость, влияющая на результативность процессов СМК (ISO 9001) и «риск, связанный с безопасностью медицинских изделий» (ISO 13485, ISO 14971). Кроме того, во фразах о планировании действий в отношении рисков отсутствует упоминание о возможностях, что является обязательным согласно ISO 9001:2015, п. 6.1.
Я понимаю когда бизнес делал это 10 лет назад - тогда про специфический стандарт для производителей МИ мало кто слышал и во многих тендерах в качестве критерия наличия СМК упоминалась только девятка. Но теперь-то!
Анализирую документы такой компании..
Вот, классическое несоответствие вызванное противоречием имеющем место в упомянутых выше двух стандартах:
😱 В РК (включая разделы, посвящённые политике качества, планированию, анализу рисков и ответственности руководства) используется термин «риск» без уточнения его смысла. Не проводится разграничение между понятием «риск» как неопределённость, влияющая на результативность процессов СМК (ISO 9001) и «риск, связанный с безопасностью медицинских изделий» (ISO 13485, ISO 14971). Кроме того, во фразах о планировании действий в отношении рисков отсутствует упоминание о возможностях, что является обязательным согласно ISO 9001:2015, п. 6.1.
👍7
Коллеги, один и тот же косяк встречается у каждого четвёртого — а может быть и у каждого третьего — в Руководстве по качеству.
Вместо того чтобы кратко и по делу объяснить, как Вы выполняете то или иное требование стандарта, или хотя бы дать ссылку на документ, где это описано, Вы пишете декларации типа «мы выполняем требование X».
То есть берёте норму из стандарта и переписываете её в утвердительном наклонении. Было: "организация должна...", стало: "организация выполняет..."😇
Запишите афоризм от вашего покорного слуги:
👉 Руководство по качеству — это не пересказ стандарта, а ответ на вопрос “Как именно мы это делаем?”
Вместо того чтобы кратко и по делу объяснить, как Вы выполняете то или иное требование стандарта, или хотя бы дать ссылку на документ, где это описано, Вы пишете декларации типа «мы выполняем требование X».
То есть берёте норму из стандарта и переписываете её в утвердительном наклонении. Было: "организация должна...", стало: "организация выполняет..."
Запишите афоризм от вашего покорного слуги:
👉 Руководство по качеству — это не пересказ стандарта, а ответ на вопрос “Как именно мы это делаем?”
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13
Коллеги, ещё одна типовая ошибка при составлении Руководства по качеству — желание прописать всё и сразу.
Причём всё — это по каждому требованию стандарта, по каждой запятой.
Желание, конечно, похвальное 😊 Но если у Вас уже есть отдельная процедура, в которой весь процесс детально описан, с формами, ролями и маршрутами — зачем дублировать всё это в РК?
📌 Пример: раздел 7.3 «Проектирование и разработка». Там аж 10 подпунктов. Но в самом начале — требование: должна быть документированная процедура.
Вот и дайте ссылку на неё! А в РК напишите по-человечески, например так:
- Процесс проектирования и разработки регулируется процедурой СОП 7.3, в которой описан порядок планирования, исполнения и мониторинга.
- Формы записей — обязательные и рекомендуемые — указаны в самой процедуре.
- Проектированием занимается отдел главного конструктора.
- На этапах верификации и валидации подключаются ОТК и регуляторный отдел.
- На стадии технологической подготовки — производственный отдел.
И никаких простыней на 3 страницы 👌
Причём всё — это по каждому требованию стандарта, по каждой запятой.
Желание, конечно, похвальное 😊 Но если у Вас уже есть отдельная процедура, в которой весь процесс детально описан, с формами, ролями и маршрутами — зачем дублировать всё это в РК?
📌 Пример: раздел 7.3 «Проектирование и разработка». Там аж 10 подпунктов. Но в самом начале — требование: должна быть документированная процедура.
Вот и дайте ссылку на неё! А в РК напишите по-человечески, например так:
- Процесс проектирования и разработки регулируется процедурой СОП 7.3, в которой описан порядок планирования, исполнения и мониторинга.
- Формы записей — обязательные и рекомендуемые — указаны в самой процедуре.
- Проектированием занимается отдел главного конструктора.
- На этапах верификации и валидации подключаются ОТК и регуляторный отдел.
- На стадии технологической подготовки — производственный отдел.
И никаких простыней на 3 страницы 👌
👍21
Аргументы_по_удалению_ISO_9001_из_области_действия_системы.docx
16.4 KB
Коллеги, уже не в первый раз сталкиваюсь с производителем медицинского изделия, у которого помимо ISO 13485 ещё и внедрён ISO 9001. И каждый раз задаюсь одним и тем же вопросом: зачем?
Вот реально — что движет Вашим руководством, когда оно решает повесить на себя дополнительные требования, дополнительные проверки, дополнительные риски несоответствий? Какие тут логические или хотя бы экономические мотивы?
Я вот недавно для одного такого предприятия готовил пояснительную записку на тему целесообразности исключения ISO 9001 из области применения СМК — прилагаю ниже. Может, кому пригодится для внутреннего диалога с "убеждёнными сторонниками двух стандартов сразу". 😊
Вот реально — что движет Вашим руководством, когда оно решает повесить на себя дополнительные требования, дополнительные проверки, дополнительные риски несоответствий? Какие тут логические или хотя бы экономические мотивы?
Я вот недавно для одного такого предприятия готовил пояснительную записку на тему целесообразности исключения ISO 9001 из области применения СМК — прилагаю ниже. Может, кому пригодится для внутреннего диалога с "убеждёнными сторонниками двух стандартов сразу". 😊
🔥9
Прошёл Я тут недавно обучение по ГОСТ IEC 62304-2022, Спасибо Михаилу Виноградову 😊 Теперь вот понимаю что в 99 процедурах по управлению записями из 100 которые я у кого-либо встречал есть вот этот вот проблема которую только что я тут одному клиенту описал:
------------
Основные записи СМК в Вашей компании, по сути, — это, на мой взгляд, именно те записи, которые сопровождают разные стадии разработки, внедрения и поддержки ПО. Особенно если речь идёт о медизделиях с ПО — тут без этого никуда.
Чтобы разобраться, какие именно записи критичны, стоит обратить внимание на стандарт ГОСТ IEC 62304-2022. Я вставил ниже несколько ключевых определений из этого стандарта — они, на мой взгляд, имеют максимальное значение именно для управления записями в контексте жизненного цикла ПО. В идеале, в данной процедуре следовало бы раскрыть специфику управления такими записями: как обеспечивается прослеживаемость, какие документы считаются записями, где и как они хранятся, как защищаются от изменений, и как осуществляется доступ к ним.
Сейчас же в процедуре даже Jira (или другой аналогичный инструмент, который наверняка используется при разработке) не упоминается вообще… ☹️ Это делает процедуру довольно «отвязанной» от реальных процессов сопровождения жизненного цикла ПО.
Если компания всерьёз планирует реализовывать IEC 62304, стоит как минимум подумать над включением:
- понятий вроде «артефакт жизненного цикла ПО», «запись о жизненном цикле ПО», «управление конфигурацией ПО», «результаты тестирования ПО»;
- описания, какие записи формируются на каждой стадии разработки (требования, проектирование, верификация, тесты, исправления);
упоминаний об инструментах (таких как Jira, Git, Confluence), через которые ведутся эти записи — даже если на уровне ссылки или примечания;
- того, как эти записи попадают в СМК, кто их регистрирует, кто за них отвечает, и как они проверяются при аудитах.
Без этих дополнений процедура, скорее, относится к "бумажной" СМК, а не к современной инженерной системе управления разработкой программных компонентов медицинских изделий.
------------
Основные записи СМК в Вашей компании, по сути, — это, на мой взгляд, именно те записи, которые сопровождают разные стадии разработки, внедрения и поддержки ПО. Особенно если речь идёт о медизделиях с ПО — тут без этого никуда.
Чтобы разобраться, какие именно записи критичны, стоит обратить внимание на стандарт ГОСТ IEC 62304-2022. Я вставил ниже несколько ключевых определений из этого стандарта — они, на мой взгляд, имеют максимальное значение именно для управления записями в контексте жизненного цикла ПО. В идеале, в данной процедуре следовало бы раскрыть специфику управления такими записями: как обеспечивается прослеживаемость, какие документы считаются записями, где и как они хранятся, как защищаются от изменений, и как осуществляется доступ к ним.
Сейчас же в процедуре даже Jira (или другой аналогичный инструмент, который наверняка используется при разработке) не упоминается вообще… ☹️ Это делает процедуру довольно «отвязанной» от реальных процессов сопровождения жизненного цикла ПО.
Если компания всерьёз планирует реализовывать IEC 62304, стоит как минимум подумать над включением:
- понятий вроде «артефакт жизненного цикла ПО», «запись о жизненном цикле ПО», «управление конфигурацией ПО», «результаты тестирования ПО»;
- описания, какие записи формируются на каждой стадии разработки (требования, проектирование, верификация, тесты, исправления);
упоминаний об инструментах (таких как Jira, Git, Confluence), через которые ведутся эти записи — даже если на уровне ссылки или примечания;
- того, как эти записи попадают в СМК, кто их регистрирует, кто за них отвечает, и как они проверяются при аудитах.
Без этих дополнений процедура, скорее, относится к "бумажной" СМК, а не к современной инженерной системе управления разработкой программных компонентов медицинских изделий.
👍8🔥1