Новая cms: iTrack — Рейтинг CMS — Разработчикам CMS

Содержание

Как перенести сайт и не потерять позиции

Причин для переезда на новый движок много. Вот самые частые сценарии:

  1. Сайт не соответствует потребностям бизнеса — как в функциональном, так и техническом аспекте.

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

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

  4. Текущая версия сайта работает на SaaS-платформе или конструкторе, а не на полноценной CMS.

  5. Большое количество технических ошибок / конфликтов в коде.

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

  7. Сайт создает большую статическую нагрузку на хостинг.

Теперь рассмотрим опасности, которые могут подстерегать вас после переезда на новый движок.


Присоединяйтесь к нашему Telegram-каналу!

  • Теперь Вы можете читать последние новости из мира интернет-маркетинга в мессенджере Telegram на своём мобильном телефоне.

  • Для этого вам необходимо подписаться на наш канал.


Риски при смене движка

Любое глобальное изменение на сайте — смена дизайна, изменение стандартного вида ссылок и т.п. — способно негативно повлиять на трафик и позиции. То же самое касается и переезда на новую CMS. Это очень серьезное изменение всех аспектов работы сайта.

Вот главные опасности смены движка сайта:

  1. Получение большого количества уязвимостей.

  2. Утрата многих инструментов и функциональной части старой CMS.

  3. Некорректное отображение контента — из-за изменения вида ссылок контент может отображаться частично или вовсе не отображаться после смены движка.

  4. Потеря накопленных позиций.

  5. Резкая просадка трафика.

  6. Утрата всей или большей части ссылочной массы. В идеале нужно настроить 301-е перенаправление для каждой страницы старой версии на URL новой версии сайта.

После смены CMS меняется глобальный вид ссылок. Изменение движка сайта приведет к недоступности всех старых страниц, а значит — они начнут выпадать из индекса. Чтобы решить эту проблему, нужно подготовить таблицы URL.

Например, до переезда ссылка категории выглядела так: abc.com/category/blog. После смены CMS она приобрела такой вид: abc.com/blog.html


Читайте также:

Что такое CMS: как работает, как выбрать CMS для сайта


Как сохранить позиции и трафик при переезде на новую CMS

Достичь этой цели можно соблюдением всего 3 правил:

  • Сохранение текущих url адресов страниц.

  • Сохранение контента страниц.

  • Сохранение структуры.

Да, вам потребуется воспроизвести полную копию вашего старого сайта на новом движке. Но только при таком сценарии риск потери достигнутых позиций будет стремиться к 0. И уже после переиндексации сайта на новом движке или с новым дизайном вы можете начинать менять структуру сайта и url адресов.

Если по каким то причинам у вас не получается реализовать этот вариант, ниже мы опишем вариант с использованием серверной переадресации 301 на новые url адреса.

Пошаговый алгоритм при переезде на новую CMS


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

Техническое задание: перенос сайта на новую CMS или на самописный движок
Если вы не хотите устанавливать новую CMS и осуществлять переезд самостоятельно, разумнее будет делегировать эти задачи разработчику. Придется составить техническое задание. При этом обязательно нужно предусмотреть следующие пункты:

  1. Метатеги для страниц нужно делать в виде шаблонов.

  2. Сохранение существующей поисковой оптимизации страниц.

  3. Сохранение структуры сайта и его главных разделов.

  4. Сохранение существующих типов страниц.

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

Далее мы посмотрим, как переехать на новую CMS самостоятельно — без разработчика.

Шаг №1 — сбор старых URL

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


Читайте также:

Кого выбрать — частного SEO-специалиста или агентство: советы владельцам сайтов


Парсинг старого сайта

Сперва нам необходимо сохранить текущие URL. Другими словами — нам нужны ссылки со старой версии сайта. Чтобы их собрать, вы можете воспользоваться автоматическими инструментами, например, сервисом Screaming Frog или любым другим, который имеет встроенный парсер данных.


Немного о выборе парсера: кроме хорошо зарекомендовавшей себя «лягушки», я могу посоветовать SE Ranking. Там также есть удобный парсер, который позволяет выгрузить все данные о страницах именно в таблице, которая нам и будет нужна в конечном итоге.

Я люблю работать с WebSite Auditor и далее покажу последовательность действий на примере этого инструмента.

  1. Устанавливаем WebSite Auditor на компьютер.

  2. Указываем домен старого сайта.

  3. Ждем пока сервис просканирует домен:



    4. Парсер обработал все страницы старого сайта

  4. Идем в раздел «Структура сайта» и открываем отчет по страницам:



    5. Открываем отчет по страницам

  5. Выбираем необходимые параметры, кликнув правой кнопкой в этой области:



    6. Настраиваем необходимые параметры, которые должны быть в таблице после экспорта

    Откроется контекстное меню, где нужно выбрать интересующие нас параметры.




    Так выглядит итоговый отчет с 5-ю необходимыми параметрами: страница, заголовок, код состояния, мета-описание, количество h2

  6. Экспортируем данные. Нажимаем на эту иконку:



    7. Экспортируем данные по всем страницам старого сайта в таблицу

  7. Указываем, куда сохранить таблицу:



    8. Сохраняем таблицу в формате .csv

Итак, как вы уже догадались, в таблице работать будем со следующими данными страницы:

  1. URL.

  2. Title.

  3. Description.

  4. h2.

Создание таблицы

Теперь нам нужно создать таблицу в Microsoft Office или в «Google Таблицах». В чистый лист вставляем данные, которые мы получили из парсера. Вы можете назвать эту таблицу «Составление URL»:

Из парсера мы получили URL, Title, код ответа, Description, количество h2 и новый адрес страницы

Новый адрес страницы пока не трогаем. Таким образом, мы создали таблицу «Составления URL» для старой версии сайта и успешно копировали в нее данные из парсера.

Парсинг нового сайта

Повторяем весь вышеописанный парсинг, но уже для новой версии сайта. Аналогичным образом экспортируем данные из парсера и возвращаемся в таблицу «Составление URL», где у нас ссылки на старый сайт. Нам нужно добавить новый столбик.

Вручную добавляем столбик «Новый адрес страницы»

Теперь нужно внимательно проверить корректность каждой новой страницы, сопоставить старый / новый адрес и вписать его в столбик «Новый адрес страницы». Сделать это нужно для каждой ссылки.


Частый сценарий: сопоставлять старую версию страницы в новой версии сайта просто не с чем, так как на новом движке такой страницы нет. В этом случае в таблице «Составления URL» можно просто сделать пометку «404-й ответ».


Читайте также:

Страница 404: 18+ примеров как оформить страницу ошибки


После того как таблица «Составления URL» полностью готова, можно приступать к созданию следующий таблицы — условно назовем ее «Формирование редиректов». Внимательно анализируем предыдущую таблицу («Составление URL»): проверяем каждую ссылку со старой версии сайта на новую, затем вносим ее в таблицу «Формирование редиректов», в столбик «Новый URL»:

В новой таблице (формирование редиректов) нужно сделать 3 столбца: «Старый URL», «Новый URL» и «Правило редиректа».

Обратите внимание: в столбике «Правило редиректа» может указываться не только 301-й редирект, но и другие виды перенаправлений.


Страницы, отдающие 404-й код, на старом сайте добавлять в таблицу «Формирование редиректов» не нужно. Иначе несуществующие страницы появятся и на новой версии сайта.

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

Шаг №2 — инсталляция новой CMS

Приступаем к развертыванию новой версии сайта. Здесь два варианта: выполнять все действия на локальном сервере или зарегистрировать для этих целей тестовый домен. В последнем случае его нужно будет закрыть для индексации в стандарте исключений для роботов. В robots.txt достаточно прописать такой код:

User-agent: *


Disallow: /

Перед релизом сайта на основной домен, файл robots.txt необходимо заменить на корректный или убрать из него запрещающую директиву Disallow: /. Иначе ваш сайт полностью выпадет из индекса.

Устанавливаем выбранный движок и проводим основную работу: кастомизируем внешний вид ссылок, настраиваем основные разделы сайта и структуру, изменяем дизайн, устанавливаем плагины.

Самые популярные CMS в России

Шаг №3 — копирование оптимизации и контента

Если вы работаете с разработчиком, обязательно передайте ему таблицу «Сопоставления URL» и таблицу «Формирование редиректов». Сложность переноса оптимизации и контента зависит от масштабов сайта. Если на вашем сайте тысячи страниц, то для импорта данных можно задействовать специально написанный для этого скрипт (сделать его поможет разработчик). Когда страниц мало, то можно обойтись и полностью ручным копированием контента.

Шаг №4 — настройка перенаправлений

Задача несложная: нужно вручную настроить 301-й редирект для всех старых страниц. Самый простой способ это сделать — прописать перенаправление в htaccess, но есть и много других способов настроить редирект.


Читайте также:

Как сделать редирект — подробное руководство по настройке и использованию


Шаг №5 — тестирование

После установки новой CMS, переноса оптимизации и контента и настройки перенаправлений приступаем к тестированию работоспособности сайта. Наша задача — проверить корректность работы интерактивных элементов страницы. Если какая-то форма отправки данных или кнопка не работают, то исправляем этот момент.

Результат неудачного переезда. Вместо анонсов на главной показывается полный текст страницы

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

Обязательно обратите внимание на карточки товаров и фильтры — сразу же после переноса они должны формироваться корректно.

Шаг №6 — добавление скриптов

Если новая версия сайта работает корректно, можно приступать к добавлению скриптов веб-аналитики и других сервисов:

  • Google Search Console.

  • Google Tag Manager.

  • Google Analytics.

  • Google AdSense.

  • «Яндекс.Вебмастер»

  • «Яндекс.Директ»

  • «Яндекс.Метрика»

  • Любые другие инструменты, которые вы использовали на старой версии сайта.

Код сторонних сервисов, например — «Яндекс.Метрики», нужно вставлять как можно ближе к началу страницы. Лучше в тегах head или в пределах тегов body

Шаг №7 — формирование XML-карты

Для создания XML-карты можно воспользоваться любым сторонним инструментом: плагином или онлайн-сервисом. Например, для WordPress я рекомендую использовать плагин Google XML Sitemap Generator. Сгенерированную карту сайтов для роботов нужно загрузить в «Яндекс.Вебмастер» и Google Search Console.

Плагин для формирования карты сайта Google XML Sitemap Generator

Шаг №8 — работа с веб-аналитикой

После переезда очень важно следить за посещаемостью сайта. Просадка трафика в первый месяц после переезда или даже дольше — это нормально. Гораздо хуже, если вы теряете более 50% от привычной посещаемости. Значит, переезд выполнялся некорректно и стоит проверить самые важные моменты: как работают редиректы и настроены ли они вообще.

Бывает и так, что посещаемость начинает расти после переезда на новую CMS

Читайте также:

Веб-аналитика: что это такое, зачем она нужна, сервисы веб-аналитики


6 действий, которые нужно выполнить после первоначального переезда на новый движок

Если первый этап переезда на новый движок признан успешным, не спешите удалять старую версию сайта! Она может пригодиться еще неоднократно. Кроме этого, выполните следующие действия:

  1. Проверьте правильность привязки сайта в «Яндекс.Метрике» и Google Analytics.

  2. Проверьте стандарт исключения для роботов. Новая версия сайта должна быть открыта для индексации.

  3. Следите за позициями новой версии сайта. В идеале мониторить их нужно еще до начала переезда. Так вы сможете вовремя идентифицировать причину падения трафика, если она связана с утратой позиций сайта.

  4. После завершения всех работ просканируйте новую версию сайта парсером Screaming Frog. Нужно убедиться в том, что отсутствуют критические ошибки, нет дублирования страниц, все они отдают корректный код, а теги страниц переехали правильно. Следите за битыми ссылками на сайте. Сделать это можно в том же Screaming Frog (раздел «Bulk Export», сортируем страницы по «Response Code» и кликаем «Client Error 4xx Inlinks»).

  5. Просканируйте все цепочки редиректов при помощи Majento.

  6. Проверьте все внутренние ссылки (включая атрибутивные, canonical, ссылки в меню). Они должны вести на новую версию сайта.

Резюме + бонус: когда переезд на новый движок может быть не оправдан

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

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

Проверка цепочек редиректов при помощи WebMasta

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

Пытаясь решать мелкие проблемы с сайтом, не забывайте, что переезд — это глобальное изменение в работе ресурса. Легких переездов не бывает: сайт в любом случае придется дорабатывать метафорическим напильником.


Создание сайтов

  • Разработка эффективных сайтов для продаж в интернете.

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


Перенос сайта на CMS (другой движок)

  1. Главная
  2. Услуги
  3. Поддержка сайтов
  4. Перенос на новую CMS


Перенос сайта на другой движок выполняется в том случае, если владельца не устраивает текущая система управления. Наиболее распространённая причина — такое расширение функционала ресурса, для которого старая CMS не предназначена. Например, ресурс работает на WordPress и вы хотите добавить возможности интернет-магазина. «Вордпресс» для этого не подходит. Поэтому приходится искать другую платформу, чтобы выполнить переезд. Также перенос сайта на новую CMS выполняется в целях экономии, тем более что платные движки не всегда лучше бесплатных. Бывают и другие причины, но важнее разобраться в проблемах, которые возникают при переезде.

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

  • Работу по текстовой оптимизации на новой CMS придётся выполнять заново, а для этого нужно иметь в штате или пригласить толкового SEO специалиста. Перенос текстов не обязательно должен быть точным, но ключевые фразы нужно сохранять, иначе потеря позиций в выдаче Гугла и Яндекса неминуема.
  • Потребуется заново создать шаблоны URL страниц, поскольку оставить их без изменения после переезда не получится. А доверять эту процедуру движку тоже нельзя из-за слишком больших возможных расхождений в структуре. Работа со страницами заслуживает отдельной статьи, поскольку здесь много нюансов. Например, настройка редиректа со страниц старого сайта, что требует работы с инструментами Google Analytics, Яндекс.Метрика.
  • Сохраните старые метатеги (тайтлы, дескрипшны, заголовки, ключевые слова).

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

Из других сложностей, связанных с переездом, отметим необходимость работы над дизайном, поскольку не всегда можно корректно перенести шаблоны с одной CMS на другую. Впрочем, бывает так, что дизайн требует обновления — тогда это делается вместе с работой над новым интерфейсом, поскольку дизайн с интерфейсом всегда идут «рука об руку».

Обязательно нужно сделать резервную копию (бэкап файлов и базы данных). С этим помогут специальные инструменты — например, phpMyAdmin, программное обеспечение, предназначенное для веб-разработчиков и администраторов ресурсов. Также позаботьтесь о сохранении доступов и синхронизации данных, что особенно важно, если у вас интернет-магазин или крупный информационный ресурс. Нюансов много, а для того, чтобы избежать проблем с доступностью ресурса на новой системе управления, можно доверить эту работу профессионалам. Наши сотрудники с радостью помогут вам выполнить переезд и сделают это в кратчайшие сроки и по умеренным ценам. Стоимость зависит от объёма переносимых данных и выбранной системы управления, а также от наличия дополнительных услуг. Это может быть, например, изменение дизайна сайта, текстовая оптимизация, наполнение каталога и другие услуги.

Повышение функциональной совместимости и совершенствование процессов предварительного разрешения Предлагаемое правило CMS-0057-P: Информационный бюллетень

Центры услуг Medicare и Medicaid (CMS) продолжают продвигать наши цели по функциональной совместимости и решать проблемы процессов, связанные с предварительным разрешением, для повышения эффективности здравоохранения. забота. Предложения установят новые требования к организациям Medicare Advantage (MA), государственным программам Medicaid и CHIP с оплатой за услуги (FFS), планам управляемого медицинского обслуживания Medicaid и организациям управляемого медицинского страхования Программы медицинского страхования детей (CHIP), а также квалифицированному плану медицинского обслуживания (QHP). ) эмитентов на федеральных биржах (FFE) (совместно именуемые «затрагиваемые плательщики») для улучшения электронного обмена данными о здравоохранении и оптимизации процессов, связанных с предварительным разрешением. Чтобы побудить поставщиков принять электронные процессы предварительного разрешения, это предлагаемое правило также добавит новую меру для отвечающих критериям больниц и больниц критического доступа (CAH) в рамках Программы содействия взаимодействию Medicare и для системы поощрительных выплат на основе заслуг (MIPS). клиницистов в категории «Содействие функциональной совместимости» MIPS.

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

Это правило официально отменяет предложенное правило CMS Interoperability и Предварительное разрешение от декабря 2020 г. (85 FR 82586), но включает отзывы, которые мы получили от общественных комментаторов.

Это предлагаемое правило включает пять ключевых положений и пять запросов на информацию:

Предложения

Интерфейс прикладного программирования (API) для доступа пациентов

), мы завершили политику, требующую от некоторых затронутых плательщиков внедрения Health Level 7 ® (HL7 ® ) Fast Healthcare Interoperability Resources ® (FHIR ® ) API доступа к пациенту. В этом правиле, начиная с 1 января 2026 г., через уже созданный API доступа к пациентам мы предлагаем потребовать, чтобы регулируемые плательщики включали информацию о решениях пациентов о предварительной авторизации, чтобы помочь пациентам лучше понять процесс предварительной авторизации их плательщика и его влияние на их забота.

Это предлагаемое правило также требует, чтобы затронутые плательщики сообщали CMS ежегодные показатели об использовании пациентом API Patient Access.

Provider Access API

Чтобы облегчить координацию лечения и поддержать переход к моделям оплаты на основе стоимости, мы предлагаем потребовать от пострадавших плательщиков создать и поддерживать API доступа к провайдеру для обмена данными пациентов с поставщиками в сети. с кем пациент состоит в лечебных отношениях. Мы предлагаем, чтобы они подавали жалобы пациентов и встречались с данными (за исключением информации о расходах), элементами данных, указанными в Базовых данных США для взаимодействия (USCDI) версии 1, а также предварительными запросами на авторизацию и решениями, доступными для внутрисетевых поставщиков с 1 января. 2026.

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

Обмен данными между плательщиками по FHIR ®

медицинской информации и поддерживать эту информацию, таким образом создавая продольную медицинскую карту пациента, которая ведется с их текущим плательщиком. Хотя мы призывали плательщиков использовать FHIR API для такого обмена данными, мы не требовали этого. В декабре 2021 года CMS объявила о возможности принудительного применения этой политики до тех пор, пока выявленные проблемы реализации не будут решены в ходе разработки правил в будущем; мы стремимся решить эти проблемы в предлагаемом правиле.

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

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

Улучшение процессов предварительного разрешения

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

Требования к предварительной авторизации, документация и решение (PARDD) API : Мы предлагаем потребовать от затронутых плательщиков создания и поддержки API FHIR (API PARDD), который автоматизировал бы процесс для поставщиков, чтобы определить, требуется ли предварительная авторизация, определить информацию о предварительном разрешении и требования к документации, а также облегчить обмен запросами на предварительное разрешение и решениями из их электронных медицинских карт (EHR) или системы управления практикой. Мы отмечаем, что в соответствии с HIPAA субъекты, на которые распространяется действие HIPAA, должны использовать текущий принятый стандарт для транзакций с предварительной авторизацией, который представляет собой X12 278 версии 5010. Это предлагаемое правило не предлагает каким-либо образом изменить правила HIPAA и не будет препятствовать использованию того стандарта.

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

Сроки предварительной авторизации : Мы предлагаем потребовать от затронутых плательщиков (не включая эмитентов QHP на FFE) отправлять решения о предварительной авторизации в течение 72 часов для ускоренных (то есть срочных) запросов и семи календарных дней для стандартных ( т. е. несрочные) запросы. Однако мы также ищем комментарии относительно альтернативных временных рамок с более короткими сроками обработки, например, 48 часов для ускоренных запросов и пять календарных дней для стандартных запросов.

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

В случае окончательной доработки эти политики предварительного разрешения вступят в силу 1 января 2026 г., а первоначальный набор показателей предлагается представить до 31 марта 2026 г. (КАН)

Мы предлагаем новую электронную меру предварительного разрешения для врачей, отвечающих требованиям MIPS, в рамках категории эффективности MIPS «Продвижение совместимости», а также для соответствующих больниц и больниц критического доступа (CAH) в рамках программы Medicare Promoting Interoperability Program. Чтобы выполнить эту меру, предварительное разрешение должно быть запрошено в электронном виде через API PARDD с использованием данных сертифицированной технологии EHR (CEHRT).

В соответствии с этим предложением врачи, отвечающие требованиям MIPS, соответствующие больницам и CAH должны сообщать о количестве предварительных разрешений на медицинские товары и услуги (за исключением лекарств), которые запрашиваются в электронном виде из API PARDD с использованием данных CEHRT.

Стандарты функциональной совместимости для API

В предложенном правиле CMS и предварительной авторизации от декабря 2020 г. (85 FR 82586) мы предложили потребовать использования определенных руководств по внедрению (IG) для реализации API в предложенное правило.

После тщательного рассмотрения этих IG, их циклов разработки и роли CMS в продвижении функциональной совместимости и поддержке инноваций, мы считаем, что хотя эти IG будут продолжать играть решающую роль в поддержке функциональной совместимости, мы не готовы предлагать их в качестве требование. Эти IG будут продолжать совершенствоваться с течением времени, поскольку у заинтересованных сторон будет возможность протестировать и внедрить свои технологии. Мы продолжим отслеживать и оценивать развитие IG, а также принимать во внимание будущее нормотворчество. Поэтому, хотя мы настоятельно рекомендуем плательщикам использовать определенные IG для доступа к пациенту, доступа к поставщику, API «плательщик-плательщик» и PARDD API, мы не предлагаем требовать их использования.

Запросы на информацию (RFI)

Ускорение принятия стандартов, связанных с данными о факторах социального риска

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

Электронный обмен информацией о поведенческом здоровье

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

Улучшение электронного обмена информацией в Medicare Fee-for-Service (FFS)

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

Продвижение платформы доверенного обмена и общего соглашения (TEFCA)

Ранее в этом году Управление национального координатора по информационным технологиям здравоохранения (ONC) объявило о выпуске версии 1 схемы доверенного обмена и общего соглашения (TEFCA). Мы считаем, что возможность для заинтересованных сторон подключаться к сетям, обеспечивающим обмен в рамках TEFCA, может поддерживать и продвигать требования к плательщикам, которые мы предлагаем в этом правиле. Нам нужны комментарии о том, как предоставление возможности обмена в рамках TEFCA может поддержать эти предложения, а также политики CMS 9. 0005 Совместимость и доступ пациентов Окончательное правило. Мы также просим прокомментировать наш подход к стимулированию или поощрению плательщиков к обмену в рамках TEFCA.

Продвижение функциональной совместимости и совершенствование процессов предварительного разрешения на материнское здоровье

Администрация Байдена-Харриса уделяет приоритетное внимание решению национального кризиса охраны материнства, при этом Белый дом и CMS издают свои скоординированные подходы к преодолению кризиса. Мы просим общественность прокомментировать политику, основанную на фактических данных, которую мы могли бы проводить, используя информационные технологии здравоохранения, обмен данными и функциональную совместимость для улучшения показателей материнского здоровья. Мы также просим прокомментировать использование USCDI для решения проблем материнского здоровья, а также улучшить политику предварительного разрешения, которая может негативно повлиять на результаты материнского здоровья.

С предлагаемым правилом можно ознакомиться сегодня по адресу: https://www.federalregister.gov/public-inspection/2022-26479/medicare-and-medicaid-programs-advancing-interoperability-and-improving-prior-authorization

.

Для получения дополнительной информации посетите: https://www.cms.gov/regulations-and-guidance/guidance/interoperability/index.

###

Стратегическое направление | Инновационный центр CMS

Справочная информация об обновлении стратегии CMS Innovation Center 2021 – все пациенты в центре внимания

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

Инновационный центр CMS, проанализировав уроки, извлеченные за первое десятилетие своего существования и более 50 моделей, намечает путь на следующие десять лет к ценностно-ориентированной помощи, которая улучшит систему здравоохранения для всех пациентов.

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

Стратегические цели Инновационного центра CMS

Пять стратегических целей будут определять реализацию видения Инновационного центра CMS.

Drive Accountable Care

Цель: Увеличение числа бенефициаров в отношениях по уходу с ответственностью за качество и общую стоимость ухода.

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

Измерение прогресса:

  • К 2030 году все получатели льгот по программе Medicare с оплатой за услуги будут нести ответственность за качество и общую стоимость ухода.
  • К 2030 году подавляющее большинство получателей помощи по программе Medicaid будут нести ответственность за качество и общую стоимость ухода.

Улучшение справедливости в отношении здоровья

Цель: Внедрение справедливости в отношении здоровья во все аспекты моделей инновационного центра CMS и усиление внимания к малообеспеченным группам населения.

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

Измерение прогресса:

  • Все новые модели потребуют от участников сбора и представления демографических данных своих бенефициаров и, при необходимости, данных о социальных потребностях и социальных детерминантах здоровья (данные будут собираться таким образом, чтобы PHI соответствует HIPAA и другим применимым законам).
  • Все новые модели будут охватывать пациентов из групп населения, которые исторически недостаточно обслуживались, и поставщиков социальных услуг, таких как общественные медицинские центры и больницы с непропорционально большой долей.
  • Определите области для сокращения неравенства на уровне населения, такие как госпитализация, которой можно избежать, и установите цели для сокращения этого неравенства.

Поддержка инноваций в сфере ухода

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

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

Измерение прогресса:

  • Установите цели для повышения эффективности участников модели по показателям опыта пациентов, таким как здоровье и функциональное состояние, или подмножество потребительской оценки поставщиков медицинских услуг и систем (CAHPS®, зарегистрированная торговая марка Агентство медицинских исследований и качества) меры, которые оценивают укрепление здоровья и образование, совместное принятие решений и координацию помощи.
  • Все модели будут учитывать или включать результаты, о которых сообщают пациенты, как часть стратегии измерения эффективности CMS Innovation Center.

Улучшение доступа путем решения проблемы доступности

Цель: Проводить стратегии по снижению цен на медицинские услуги, их доступности и сокращению ненужной или дублирующей помощи.

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

Измерение прогресса:

  • Поставить цели по сокращению к 2030 году доли бенефициаров, которые отказываются от ухода из-за затрат.
  • Все модели будут учитывать и включать возможности повышения доступности дорогостоящего ухода для бенефициаров.

Партнер для достижения трансформации системы

Цель: Согласование приоритетов и политик CMS и активное привлечение плательщиков, государств-покупателей и бенефициаров к повышению качества, достижению справедливых результатов и снижению затрат на здравоохранение.

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

Измерение прогресса:

  • Там, где это применимо, к 2030 году для всех новых моделей будет доступно согласование с несколькими плательщиками.
  • Все новые модели будут собирать и интегрировать взгляды пациентов на протяжении всего жизненного цикла.

Вопросы и отзывы

Отправляйте вопросы или отзывы о стратегии по адресу [email protected]. Кроме того, подпишитесь на список рассылки Центра инноваций CMS, чтобы получать регулярные обновления о Центре инноваций CMS, включая возможность участия в слушаниях о стратегии и обновлениях о тестировании моделей.

Оценки

Последний отчет об оценке

  • Инновации, ориентированные на человека – обновленная информация о реализации стратегии инновационного центра CMS (PDF)  | Дополнительный технический документ (PDF)

Предстоящие мероприятия

  • Прослушивание CMS Innovation Center по стратегии специализированной помощи — четверг, 1 декабря 2022 г., с 13:00 до 14:00 по восточному поясному времени — регистрация открыта

Прошедшие мероприятия

  • Второй круглый стол по вопросам участия поставщиков социальных сетей в моделях CMS Innovation Center — 3 ноября 2022 г. : слайды (PDF)  | Стенограмма (PDF)  | Запись (MP4)
  • Веб-семинар — Подход Инновационного центра CMS к личностно-ориентированному уходу: взаимодействие с бенефициарами, оценка того, что имеет значение – 20 сентября 2022 г. – Дополнительная информация  | Слайды (PDF)  | Стенограмма (PDF)  | Запись (MP4)
  • Сеанс прослушивания — Усиление равного доступа к расширенной первичной медицинской помощи — 26 апреля 2022 г.:  Слайды (PDF)  | Стенограмма (PDF)
  • Круглый стол, посвященный участию поставщиков услуг социальной защиты в моделях инновационного центра CMS — 16 марта 2022 г.: слайды (PDF)  | Стенограмма (PDF)
  • Сеанс прослушивания – учет мнений бенефициаров при тестировании, внедрении и оценке модели – 9 февраля 2022 г.: слайды (PDF)  | Стенограмма (PDF)
  • Круглый стол по стратегии CMS Innovation Center по обеспечению справедливости в отношении здоровья — 8 декабря 2021 г.: слайды (PDF)  | Стенограмма (PDF)
  • Сессия для прослушивания — Первая сессия для прослушивания стратегии инновационного центра CMS — 18 ноября 2021 г. : слайды (PDF)  | Стенограмма (PDF)
  • Веб-семинар «Управление трансформацией здравоохранения: стратегия на второе десятилетие инновационного центра CMS» — 20 октября 2021 г.: слайды (PDF)  | Запись (MP4)  | Стенограмма (PDF)

Публикации

Перечислены публикации, авторами которых были руководство и/или сотрудники CMMI:

  • Инновационный центр CMS запускает новую инициативу по продвижению справедливости в отношении здоровья  —  Вопросы здравоохранения (3 марта 2022 г.)
    • Автор: Дора Линн Хьюз
  • Основываясь на стратегическом видении CMS: совместная работа для укрепления Medicare  —  Вопросы здравоохранения  (11 января 2022 г.)
    • Авторы: Мина Сешамани, Элизабет Фаулер, Чикита Брукс-Ласур
  • Инновации в центрах услуг Medicare и Medicaid: перспектива на следующие 10 лет  —  Вопросы здравоохранения  (12 августа 2021 г.