Cms самописная: плюсы и минусы (мнение бизнесмена)

Содержание

плюсы и минусы (мнение бизнесмена)

Автор статьи

МАКСИМ КОЛМОГОРОВ

Соучредитель, технический директор vverh.digital

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

Дисклеймер

Автор статьи – разработчик с пятилетним опытом работы, а также совладелец двух стартапов. Автор умеет в разработку сайтов (разной сложности) и мобильных приложений. В контексте данной статьи понятие CMS и “движок” будут соединены, что не совсем корректно, но, раз статья пишется, в первую очередь, для предпринимателей, данной действие уместно для упрощения усвоения информации.

Что такое CMS

Если не знаете, что такое CMS, прочитайте эту статью. Если лень переходить по ссылке, кратко опишем термин ниже.

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

Что такое самописная CMS (движок для сайта)

Самописная CMS – это не конструктор или готовая CMS, это некая интеллектуальная собственность, написанная “под заказ” для сайта клиента. Обычно самописные CMS разрабатываются программистами с нуля на каком-либо серверном языке программирования (PHP, Node.js, Java, Python, Go) или фреймворке (читать как инструмент), в котором есть некий набор готового кода, чтобы разработчик немного сэкономил время.

Готовый код – это не готовые модули (каталог, блог), а просто ряд функций, которые программист может использовать, чтобы уж совсем все с полного нуля не писать. Например, парсер excel документа или методы для работы с базами данных.

Минусы самописных CMS

Самописная CMS как будто говорит: “Эй, программист, делай все сам”.

Нет плагинов и привычных вещей из коробки

Все нужно написать самостоятельно программисту. Создание страниц, товаров, блог – все это пишется вручную веб-разработчиком. Если Вы привыкли к Битриксу и WordPress, привыкли к их удобному интерфейсу (его ведь годами делали) и некоторым внутренним функциям, то придется немного расстроится – этого из коробки нет.

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

Стоимость кусается

Раз многие привычные вещи отсутствуют и их нужно реализовывать с нуля, это влечет за собой большие временные затраты. Все предприниматели знают: время – это деньги. И именно Вы (предприниматели) будете платить деньги за работу программистов. Хотите выделять несколько страниц галочками? Платите за данный функционал. Хотите конструктор страниц? Платите.

Интерфейс может быть неудобным с самого начала

Панель управления (CMS) вначале может быть неудобной, придется что-то доделывать и переделывать, придется привыкать к новому. Да, рано или поздно этот “сшитый на заказ костюм” будет сидеть как надо, хотя потребуется время.

Плюсы самописных CMS

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

Бешеная скорость

Сайты на самописных движках (чаще всего) очень быстрые. Все привыкли, что Битрикс сам по себе медленный из-за кучи разных модулей и модификаторов, написанных разработчиками. WordPress, обвешанный плагинами, вообще бомба замедленного действия, мало того, что он медленный, так еще некоторые плагины “дырявые” и через них сайты ломают только так.

Посмотрите на Ozon или Wildberries, это очень быстрые сайты, даже не смотря на то, что там миллионы товаров. А все потому, что там свое программное обеспечение, программисты имеют полный контроль над системой, это позволяет разбить проект на микросервисы.

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

Новейшие технологии

Веб-технологии развиваются быстро, сейчас на смену обычным сайтам приходят сайты с реактивным интерфейсом. Реактивный интерфейс – это работающий без привычных загрузок интерфейс, примеры: Ozon, Додо Пицца, Тинькофф Инвестиции, Пицца Сан.

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

Полный контроль и удобство доработки

Свою систему легко дорабатывать, Вы и Ваши разработчики знают внутри все как свою родную мать. Именно поэтому разработчики более легко решают нетривиальные задачи, они ведь сами это породили.

Многие готовые CMS написаны программистами на массмаркет (на большую аудиторию), поэтому там присутствует некая “логика”, которая Вам не нужна в проекте. Ненужная логика может мешать, она порождает проблемы, а проблемы надо решать. Весь этот лишний мусор сильно мешает создать стрессоустойчивую систему, которая будет выдерживать огромный трафик. А в рамках крупного бизнеса все это важно.

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

API

API – (если просто) это приложение, которое позволяет сайту, базе данных связываться с другими сайтами и мобильными приложениями. Например, эквайринг у разных банков, он реализован через API, чтобы программисты могли легко добавить на любой сайт интернет оплату.

Если Вы создаете мобильное приложение, то API это обязательный атрибут, ведь у каждого приложения своя бизнес-логика, и 90% готовых CMS могут в нее не попадать.

Полный кастом

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

Вывод

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

Если Вы хотите сделать MVP сайт или просто протестировать нишу, или нужен сайт ради сайта, то, конечно, можно и нужно (дешевле же) остановится на обычных готовых CMS.

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

12 причин не использовать самописные CMS на сайте

Подробности
Просмотров: 19597

Чаще всего, самописные системы возникают как «наш ответ Чемберлену» — в пику уже существующим CMS. И этим «заболеванием» страдают 99% разработчиков сайтов — в какой-то момент, в порыве инфантильного максимализма программист, многие десятки часов проведший «в обнимку» с кодом какой-либо системы, восклицает —«Доколе! Сколько можно возиться с этим убожеством?! Я же знаю как сделать лучше!» и мало-помалу «я знаю!» превращается в твердую уверенность «я могу!» и вот уже, глядишь, строчка за строчкой начинает вырисовываться костяк нового детища.

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

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

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

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

1. Жесткая привязка к одному разработчику

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

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

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

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

2. Аудит безопасности

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

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

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

3. Малая распространенность системы

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

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

4. Проработка системной архитектуры

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

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

по материалам Википедии

Учитывая, что заказчик обычно не способен оценить корректность архитектуры системы по причине закономерной недостаточности знаний в этой области, естественно этот вопрос остается на совести разработчика. Но как и в случае с безопасностью — вундеркинды встречаются крайне редко, а потому вопрос построения архитектуры самописной системы чаще всего раскрывается по методике — «не нужно изобретать велосипед». Разработчик берет за основу архитектуру одной из уже существующих популярных систем, вносит пару-тройку правок (но абсолютно не факт, что нужных и полезных) и говорит: «смотрите, моя новая архитектура революционна!».

5. Качество кода

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

6. Программистам для программистов

Давайте вспомним, почему Windows, при всей своей проблемности и ошибочности, до сих пор занимает лидирующее место среди операционных систем, используемых пользователями? По простой, в сущности, причине — она проста для освоения и не требует специфических знаний.

От многих пользователей я часто слышу — «административная часть Joomla для меня сложна, а я не хочу разбираться». А, в сущности, в ней нет ничего экстраординарного — ее интерфейс лишь немного отличается от привычных «деревоподобных» интерфейсов. Но для многих уже и это становится проблемой.

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

7. Отсутствие полноценной пользовательской документации

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

Остальные же 95%, в лучшем случае описывались разрозненными статьями на тему «Как сделать…» или же инструкциями уровня «нажмите левую кнопку мыши», а в худшем — просто ничем, предоставляя пользователю самостоятельно догадываться о назначении того или иного элемента «методом научного клика».

8. Отсутствие API

Почему Twitter в одночасье стал настолько популярен? Почему Yandex.Карты с некоторых пор можно встретить практически повсеместно? Ответ прост — полноценный API, который позволяет программистам разрабатывать на его основе сторонние приложения.

Интерфейс прикладного программирования (иногда интерфейс программирования приложений) (англ. Application Programming Interface, API [эй-пи-ай]) — набор готовых классов, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для её использования во внешних программных продуктах.

по материалам Википедии

И хотя API не является обязательным атрибутом CMS, его наличие ощутимо упрощает разработку сторонних приложений для сайта, таких как, например — связь с внутренними системами компании (SAP, SRM, модули электронной торговли и документооборота).

9. Проблема наличия лазеек

Разработчикам популярных Open Source или же проприетарных систем невыгодно оставлять какие-либо «черные ходы» по той простой причине, что в Open Souce системе они будут быстро найдены пользовательским сообществом, а в платных CMS с закрытым кодом — аудитом. Кроме того, если в отношении системы любого типа лицензирования хотя бы несколько раз будет поднят вопрос лазеек и будут приведены доказательства их наличия, то с популярностью и прибылью можно будет попрощаться раз и навсегда.

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

10. Отсутствие профессионального сообщества и службы поддержки

Популярные Open Source CMS хороши своими открытыми сообществами, в которых можно быстро найти ответ на большинство типовых задач. Поддержка проприетарных систем управления всегда обеспечивается службой поддержки и help desk. А к кому обращаться в случае использования самописной системы?

11. Отсутствие поддержки сторонних специалистов (бес- и платных)

Ок, давайте даже попробуем оставить в стороне глобальное понятие сообщества и определить — кто же может выступать в качестве хотя бы уж советчика в вопросах использования самописной системы? И снова — только сам ее автор. Банально — кому задать вопрос, если что-то не получается? Однако учитывая то — сколько уже профессий должен совмещать в себе этот человек, трудно себе представить наличие у него еще и способности заниматься одновременно разработкой и поддержкой большого количества пользователей.

12. Отсутствие профессиональных тестировщиков

Многие считают, что тестирование — довольно простое дело. Казалось бы, ну чего там — сел, прошелся по функциям системы, выписал ошибки и отдал программисту на исправление. Однако на практике все далеко не так просто. Я не буду детально останавливаться на методиках тестирования, интересующиеся могут почитать отдельную статью в Википедии, достаточно полно раскрывающую общие понятия и профессионального тестирования программного обеспечения.

13. Отсутствие четкого вектора монетизации или скрытый вектор (для бесплатных CMS)

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

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

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

Второй же вариант развития событий выглядит и вовсе удручающе — автору в какой-то момент попросту надоедает заниматься не приносящей прибылью деятельностью или в его жизни что-то меняется и ему требуются дополнительные финансы (женитьба, рождение ребенка, постройка дома — мало ли что), но внутренние убеждения не позволяют принуждать пользователей платить за использование системы, а времени на ее разработку остается все меньше и меньше. А на donation долго не проживешь — наши реалии отличаются от западных. Закономерным итогом станет полное прекращение поддержки и в лучшем случае найдется тот, кто перехватит падающий «флаг» и продолжит разработку, а в худшем — система благополучно канет в лету.

Выводы

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

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

Подумайте, стоит ли оно того?

Глеб Шапачников — Вебмастер.

Добавить комментарий

Протокол раскрытия информации о самонаправлении | CMS

Закон о защите пациентов и доступном медицинском обслуживании:

Раздел 6409 Закона о защите пациентов и доступном медицинском обслуживании (ACA) был подписан 23 марта 2010 г. Раздел 6409(a) ACA требовал, чтобы секретарь Департамента Службы здравоохранения и социальных служб в сотрудничестве с Генеральным инспектором Министерства здравоохранения и социальных служб разработать протокол раскрытия информации о самостоятельных обращениях в рамках программы Medicare, в котором изложен процесс, позволяющий поставщикам услуг и поставщикам самостоятельно раскрывать информацию о фактических или потенциальных нарушениях закон о самонаправлении врачей.

Провайдеры медицинских услуг и поставщики обязаны предоставлять всю информацию, необходимую CMS от имени Секретаря для анализа фактического или потенциального нарушения Раздела 1877 Закона о социальном обеспечении (Закон). Начиная с 1 июня 2017 г. , поставщики услуг и поставщики должны использовать формы, включенные в утвержденный OMB инструмент сбора данных под названием Протокол добровольного раскрытия информации о самонаправлении CMS (SRDP) (PDF), чтобы использовать SRDP . Для раскрытия информации о несоответствующих финансовых отношениях с более чем одним врачом раскрывающая организация должна представить отдельная форма сведений о враче для каждого врача. Документ CMS о добровольном самонаправленном раскрытии информации содержит одну форму информации о враче. Дополнительные автономные информационные формы для врачей можно найти по ссылкам ниже.

SRDP предназначен для облегчения решения только тех вопросов, которые, по разумной оценке раскрывающей стороны, являются фактическими или потенциальными нарушениями закона о самостоятельных обращениях врачей. Таким образом, раскрывающая сторона должна подать заявление в соответствии с SRDP с намерением разрешить свою ответственность за переплату за выявленное поведение. В соответствии с законом о самонаправлении врачей оплата за назначенные медицинские услуги, которые предоставляются в нарушение закона о самонаправлении врачей, не допускается. Раздел 6409(b) ACA дает секретарю HHS право уменьшить сумму, причитающуюся и причитающуюся за нарушение Раздела 1877 Закона.

Для получения дополнительной информации о SRDP и его требованиях см. ссылки ниже. После ознакомления с приведенным ниже материалом, если у вас возникнут дополнительные вопросы, обратитесь в Колл-центр CMS для врачей с самостоятельным направлением по электронной почте [email protected].

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

CMS предоставила специальные инструкции для отправки в CMS Протокол добровольного раскрытия информации о самонаправлении (SRDP), касающийся исключительно несоблюдения 42 CFR § 411. 362(b)(3)(ii)(C) (требуется, чтобы больницы, принадлежащие врачам, и сельские поставщики раскрывать на любом общедоступном веб-сайте больницы и в любой публичной рекламе информацию о том, что больница принадлежит врачам или в которую они инвестируют средства). Специальные инструкции доступны в Протоколе раскрытия информации о самостоятельных обращениях врачей — Специальные инструкции в отношении нарушений 42 C.F.R. раздел 411.362(b)(3)(ii)(C) (PDF) . Раскрытие информации о несоблюдении любого другого положения закона о самостоятельном направлении врача, включая раскрытие информации о смешанном несоблюдении § 411.362(b)(3)(ii)(C) и несоблюдение любого другого положения закона о самостоятельном направлении врача, должно продолжайте следовать стандартным инструкциям SRDP.

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

12 февраля 2016 г. CMS опубликовала окончательные правила отчетности и возврата переплат («окончательные правила переплат»). См. 81 FR 7653. Это правило вступило в силу 14 марта 2016 г. Среди прочего, окончательное правило о переплате установило 6-летний ретроспективный период для отчетности и возврата переплат в соответствии с положениями 42 CFR 401.305(f). До 14 марта 2016 г. CMS использовала временные рамки, установленные в соответствии с правилами повторного открытия в 42 CFR 405.9.80(b) в качестве руководства для определения временных рамок SRDP. Таким образом, временные рамки SRDP были ограничены 4 годами с даты, когда раскрывающая сторона представила раскрытие в SRDP, если только не существовало надежных доказательств мошенничества или аналогичной ошибки. На переплаты по самостоятельным обращениям, о которых сообщалось CMS в соответствии с SRDP до 14 марта 2016 г., не распространяется 6-летний ретроспективный период, указанный в окончательном правиле переплаты. Сюда входят как зарегистрированные, так и возвращенные переплаты (через компрометацию и урегулирование), а также те, о которых сообщалось и которые все еще находятся в процессе рассмотрения в рамках SRDP. Провайдеры и поставщики, которые сообщали о переплатах по самонаправлению в SRDP до 14 марта 2016 г., не должны возвращать переплаты с пятого и шестого года. Провайдеры и поставщики, сообщающие о переплатах в SRDP 14 марта 2016 г. или позже, подлежат 6-летнему ретроспективному периоду, указанному в окончательном правиле переплаты.

Если вы не можете загрузить документ(ы) по приведенным здесь ссылкам, сохраните документ/ссылку на рабочий стол в формате Adobe PDF. Вам нужно будет открыть файл из ваших сохраненных документов (т. е. не как «скачать»).

CMS объявляет об исторических изменениях в правилах самонаправления врачей

  • Врачи

Сегодня Центры услуг Medicare и Medicaid (CMS) завершили внесение изменений в устаревшие федеральные правила, которые обременяют поставщиков медицинских услуг дополнительными административными расходами и препятствуют переходу системы здравоохранения к возмещению расходов на основе стоимости. Закон о самонаправлении врачей, также известный как «Закон Старка», обычно запрещает врачу направлять юридическое лицо для получения определенных медицинских услуг, если у врача есть финансовые отношения с юридическим лицом. Старые федеральные правила, которые интерпретируют и реализуют этот закон, были разработаны для системы здравоохранения, которая возмещает расходы поставщикам на основе платы за услугу, где финансовые стимулы заключаются в предоставлении большего количества услуг. Тем не менее, американская система здравоохранения 21-го века все больше движется к финансовым механизмам, которые вознаграждают поставщиков услуг, успешно поддерживающих здоровье пациентов и выходящих из больницы, где оплата привязана к стоимости, а не к объему.

Обеспокоенность по поводу бюрократических барьеров, связанных с правилом Старка, была одной из главных проблем, высказанных провайдерами, когда CMS провела сеансы прослушивания в 2017 году в рамках своей инициативы «Пациенты вместо бумажной работы». Миллионы долларов и сотни часов времени, потраченные на соблюдение административного бремени правила, были названы значительным бременем, препятствующим уходу за пациентами. Поскольку поставщики берут на себя ответственность за полную стоимость ухода за своими пациентами, изменились риски, связанные с самонаправлением. Однако неясности в законе Старка заморозили многих провайдеров на месте, опасаясь, что даже выгодные договоренности могут нарушить закон, что может привести к ужасным и дорогостоящим последствиям. Это привело к тому, что поставщики медицинских услуг тратят миллионы долларов на соблюдение загадочных правил вместо того, чтобы направлять эти деньги на лечение пациентов. Это также препятствует переходу к ценности не только в Medicare, но и среди всех плательщиков, включая Medicaid и частные планы медицинского обслуживания.

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

Этим окончательным правилом CMS гарантирует, что правила, толкующие Закон Старка, допускают изменения, которые помогут модернизировать систему здравоохранения. Правило завершает многие из предложенных политик из уведомления о предлагаемом нормотворчестве, выпущенного в октябре 2019 года, в том числе:

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

Если иное не указано в правиле, все положения этого правила вступают в силу через 60 дней с даты публикации правила в Федеральном реестре.

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

Дополнительную информацию об окончательном правиле можно найти по адресу https://www.federalregister.gov/public-inspection/2020-26140/medicare-program-modernizing-and-clarifying-the-physician-self-referral-regulations

.

Для получения дополнительной информации посетите: https://www.cms.gov/newsroom/fact-sheets/modernizing-and-clarifying-physician-self-referral-regulations-final-rule-cms-1720-f

# ##

 Подпишитесь на новости CMS на cms.