Перейти к основному содержанию​​ 

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ ПО ЗАМКНУТОМУ ЦИКЛУ НАПРАВЛЕНИЯ (CLR)​​ 

Общая реализация​​ 

Может ли Департамент здравоохранения (DHCS) разъяснить, что означает, что DHCS начнет проводить проверки соответствия внедрения CLR планами управляемого медицинского обслуживания Medi-Cal (MCP) через год после даты запуска в июле 1, 2025? Ожидает ли DHCS, что MCP будут полностью соответствовать CLR к июлю 1, 2025?​​ 

DHCS предоставляет MCP льготный период для внедрения систем и процессов CLR после вступления политики CLR в силу 1 июля 2025. Хотя DHCS ожидает, что MCP внедрят CLR к июлю 1, 2025, DHCS признает, что может потребоваться дополнительное время для уточнения требований к эксплуатации и внедрению CLR, таких как методологии уведомления и отслеживания, обновления системы и рабочие процессы после даты запуска. В связи с этим DHCS начнет активный мониторинг соблюдения требований с июля 1, 2026.​​ 

Отслеживание рефералов участников​​ 

Врачи-терапевты иногда получают частую и ценную информацию о направлениях и статусе взаимодействия непосредственно от своих поставщиков услуг по расширенному управлению медицинской помощью (ECM). Можно ли включить альтернативные источники данных для выполнения требований отслеживания CLR в дополнение к упоминанию дополнительных претензий и данных о встречах?​​ 

MCP могут использовать альтернативные источники данных для дополнения источников отслеживания CLR, указанных в руководстве; однако MCP не могут требовать от поставщиков ECM/Community Supports предоставлять данные для отслеживания иными способами, чем файл обратной передачи (RTF).​​ 

Подтвердит ли DHCS, что MCP может закрыть цикл как «Услуги получены», если поставщик услуг ECM или поддержки сообщества подтвердит, что услуги оказаны или начаты с помощью данных, включенных в RTF? Термин «платная услуга» подразумевает, что MCP получила претензию, рассмотрение которой может занять шесть месяцев.​​ 

MCP могут закрыть цикл CLR как «Услуги получены» после того, как поставщик подтвердит, что услуги оказаны, с помощью элемента данных «Причина закрытия цикла направления» в RTF.​​ 

Каким образом требования CLR по отслеживанию и уведомлению применяются к вытрезвителям?  Требуется ли уведомление участника для круглосуточного обслуживания?​​ 

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

Может ли DHCS разъяснить предполагаемое использование значения статуса направления «Отклонено» поставщиками услуг ECM и поддержки сообщества?​​ 

Стандартные значения статуса направления CLR могут применяться в различных службах с течением времени. В настоящее время DHCS предполагает, что поставщики услуг ECM и Community Supports могут получить статус «Отклонено» по любой из следующих причин: у поставщика нет возможностей, участник не проживает в зоне обслуживания или по другим причинам. MCP должны сотрудничать со своими сетевыми провайдерами и предоставлять четкие документированные процедуры для определения допустимых причин отклонения направления в соответствии с политиками ECM и поддержки сообщества, а также того, как это должно быть отмечено в значении статуса направления. DHCS не подразумевает, что MCP должны принять новые политики, позволяющие сетевым провайдерам отклонять направления.​​ 

В Приложении DHCS к Руководству по политике PHM: Руководство по внедрению направлений в замкнутом цикле, Таблица 4: Обработка направлений содержит «Название поставщика услуг» и «Номер телефона поставщика услуг». Может ли DHCS пояснить, является ли это назначенным участнику ведущим менеджером по уходу за больными, и уточнить его номер телефона?​​ 

«Название поставщика услуг» и «Номер телефона поставщика услуг» — это название и номер телефона субъекта (т. е. поставщика услуг), который получает запрос на направление в ECM или службу поддержки сообщества от MCP или направляющего субъекта. Например, на страницах 23–24 Руководства по данным CalAIM: Руководство по обмену информацией на уровне участников между MCP и поставщиками ECM информация будет соответствовать полям «Название поставщика ECM» и «Номер телефона поставщика ECM». Цель полей — подтвердить, что MCP записал контактную информацию, которую он может использовать для поддержки направления и предоставления услуг Участнику для различных Поставщиков/Услуг, к которым применяются требования CLR.​​ 

Может ли DHCS объяснить разницу между «Название организации поставщика услуг» и «Название поставщика услуг»?​​ 

«Название организации поставщика услуг» — это поставщик ECM (т. е. название организации). «Название поставщика услуг» — это ведущий менеджер по обслуживанию ECM, назначенный для предоставления услуг ECM (лицо в организации, назначенное участнику).​​ 

Требование о предоставлении информации о причине закрытия реферального цикла направляющим субъектам подразумевает предоставление защищенной медицинской информации (PHI) незастрахованным субъектам без разрешения Участника. MCPs считают, что это требование не соответствует HIPAA, и просят DHCS отменить его.​​ 

Закон о переносимости и подотчетности медицинского страхования 1996 года (HIPAA) разрешает субъектам, на которых распространяется действие договора, включая врачей общей практики, использовать или раскрывать «защищенную медицинскую информацию» (PHI) для определенных целей, включая лечение, оплату или операции в сфере здравоохранения (определенные административные, юридические, финансовые и мероприятия по улучшению качества, включая координацию лечения и ведение случаев), без разрешения пациента. Такое раскрытие информации может осуществляться как другим субъектам, на которые распространяется действие страховки (например, поставщикам медицинских услуг), так и субъектам, на которые не распространяется действие страховки (например, поставщикам жилья, общественным организациям (CBO)), при условии, что раскрытие информации необходимо для целей лечения, оплаты и оказания медицинской помощи.​​  

Причина закрытия реферального цикла и дата закрытия реферального цикла будут составлять PHI в соответствии с HIPAA; как субъекты, на которых распространяется действие HIPAA, MCP могут делиться этой информацией с субъектами, на которых не распространяется действие HIPAA, без индивидуального​​ двойное разрешение в целях координации лечения и ухода. 45 CFR 164.506(c)(1) предусматривает, что субъекты, на которых распространяется действие страховки, могут использовать и раскрывать защищенную информацию о состоянии здоровья для целей собственного лечения, оплаты и оказания медицинской помощи.​​ 

Может ли DHCS обеспечить переход для взаимодействия между новыми полями статуса CLR и существующими полями статуса в RTF, а также удалить новые требования к статусу CLR из ECM RTF и вместо этого использовать существующие статусы ECM для отслеживания CLR? ECM RTF уже отслеживает CLR с помощью установленных статусов, но новые статусы CLR не согласуются, что создает ненужную сложность. Их устранение уменьшит путаницу и административную нагрузку, сохранив при этом согласованность процессов.​​ 

DHCS не может удовлетворить запрос на удаление переменной Referral Status, поскольку это ключевое значение для стандартизации отслеживания CLR. Тем не менее, DHCS работает над возможными решениями, одновременно принимая во внимание отзывы MCP о последствиях удаления существующих месторождений.​​   

Может ли DHCS разъяснить разницу между статусами направления 1 — Принято и 3 — Ожидает рассмотрения, поскольку в текущем рабочем процессе ECM неясно, как их различать.​​ 

«Ожидание» — это статус направления по умолчанию для направления, сделанного поставщику услуг ECM или поддержки сообщества в рамках MIF, когда поставщик еще не просмотрел направление и не подтвердил, что он имеет возможность обслуживать участника и намерен инициировать взаимодействие. Статус «Принято» указывается после того, как Поставщик рассматривает направление и намеревается связаться с Участником, но еще не сделал этого. Дополнительное описание значений переменной «Статус направления» см. в таблице 11 Руководства по внедрению CLR.​​ 

Члены MCP обеспокоены тем, что DHCS позволяет поставщикам отклонять направления, что может привести к избирательному приему в члены и потенциальной дискриминации. Например, отказ обслуживать трансгендерных лиц или носителей определенных языков. Может ли DHCS пересмотреть этот вариант CLR или ввести меры защиты от дискриминации членов?​​ 

Стандартные значения статуса направления CLR могут применяться в различных службах с течением времени. В настоящее время DHCS предполагает, что поставщики услуг ECM и Community Supports могут получить статус «Отклонено» по любой из следующих причин: у поставщика нет возможностей, участник не проживает в зоне обслуживания или по другим причинам. MCP должны сотрудничать со своими сетевыми провайдерами и предоставлять четкие документированные процедуры для определения допустимых причин отклонения направления в соответствии с политиками ECM и поддержки сообщества, а также того, как это должно быть отмечено в значении статуса направления. DHCS не подразумевает, что MCP должны принять новые политики, позволяющие сетевым провайдерам отклонять направления.​​ 

Может ли DHCS подтвердить, что определение «CLR, которые были открыты в течение длительного периода времени» остается на усмотрение MCP?​​ 

Подтвержденный. DHCS предполагает, что это может зависеть от известных потребностей участника и типа услуги. В соответствии с Руководством по внедрению CLR все статусы направлений должны обновляться не реже одного раза в месяц.​​ 

Может ли DHCS пояснить, что означает «ответить на запрос» в требовании «MCPs должны ответить на запрос в течение одного рабочего дня»?​​ 

MCP обязаны как минимум подтвердить получение запроса и предоставить статус CLR в течение одного рабочего дня. Например, MCP может уведомить направляющую организацию или участника о том, что направление было авторизовано и передано поставщику услуг для распространения [Дата], если это последнее обновление статуса направления, имеющееся у MCP. Цель этого требования — улучшить понимание статуса реферала партнером-рефералом более оперативно, чтобы он мог оказать участнику наилучшую поддержку. В настоящее время DHCS не намерено делать исключения из этого требования.​​ 

Каким образом DHCS будет контролировать соблюдение требования отвечать на запросы членов в течение одного рабочего дня?​​ 

DHCS начнет проводить проверки соответствия CLR MCP через год после даты внедрения в июле 1, 2025. DHCS может рассмотреть возможность запроса специальной документации, проведения аудита или принятия других мер для обеспечения выполнения этого требования и заранее уведомит об этом MCP.​​ 

У DHCS запрошено разъяснение относительно ожиданий в отношении последующих действий в отношении членов, которым отказано в услугах из-за несоответствия требованиям. Может ли DHCS предоставить наглядный пример процедуры, отвечающей этому требованию?​​ 

Целью данного требования является повышение вероятности того, что потребность, которая привела к первоначальному направлению в ECM или Community Supports, по-прежнему будет удовлетворена для участника. В случае отказа в разрешении на ECM из-за несоответствия требованиям следующим шагом для MCP может стать рассмотрение заявки на CCM для удовлетворения потребностей участника и предложение CCM в качестве альтернативы или уведомление D-SNP участника о его потребности в управлении уходом и подтверждение того, что участник получил поддержку от D-SNP в управлении уходом.​​ 

Большинство направлений ECM обходят план и направляются напрямую к поставщикам ECM, которые предположительно регистрируют участников. Каким образом планы могут отслеживать минимальный набор данных для CLR без прозрачности происхождения направления? Если отслеживание необходимо, это значительно увеличит отчетную и административную нагрузку на нашу сеть поставщиков ECM.​​ 

Инструкции по кодированию направлений/запросов на авторизацию, поступающих от поставщиков ECM в MCP в рамках соглашений о предполагаемой авторизации, см. в Приложении B, Разделе 1.A.3. Руководства по внедрению CLR.​​ 

Какой уровень статуса ожидает от MCP, по мнению DHCS?​​ 

Полные спецификации и элементы данных, которые MCP обязаны отслеживать для услуг в соответствии с требованиями CLR (ECM и поддержка сообщества), см. в разделе «Отслеживание» Руководства по внедрению CLR. В приложении B приведены дополнительные сведения о значениях ключевых переменных отслеживания, таких как «Статус направления», а также о том, как следует собирать данные от поставщиков услуг ECM и поддержки сообщества с помощью ежемесячного RTF. Шаблоны JSON Phase 4, выпущенные в феврале, содержат подробные элементы данных для отчетов мониторинга CLR.​​ 

Какой уровень вмешательства ожидает DHCS, если направления остаются нерассмотренными в течение длительного периода? Нужно ли это отражать в Меморандуме о взаимопонимании (МОВ) с каждым агентством?​​ 

Список примеров действий, которые могут предпринять MCP для поддержки поставщиков услуг ECM и поддержки сообщества в работе с ожидающими рассмотрения направлениями, а также рекомендации по последующим действиям с участником и направляющей организацией в этих случаях, см. в разделе II.B.2 «Поддержка ожидающих рассмотрения и повторных направлений» Руководства по внедрению CLR.​​ 

Что делать, если каждое агентство запрашивает у MCP различные вмешательства (например, WIC требует уведомлять в течение пяти рабочих дней о ожидающих направлениях, Региональный центр требует уведомлять в течение 30 рабочих дней и т. д.)​​ 

В настоящее время требования CLR применяются только к направлениям к MCP для ECM и поддержки сообщества. Требования CLR Noticing определяют ожидания для Noticing Referring Entities (например, Бюджетные организации, поставщики услуг, врачи первичной медико-санитарной помощи (ВМП) по решению о выдаче направления в соответствии со сроками, требуемыми в APL 21-011, и по причине закрытия направления в установленные сроки. Подробные требования к уведомлению MCP CLR см. в разделе II.BI Руководства по внедрению CLR.​​ 

Поскольку MCP обязаны использовать форму направления DHCS для ECM/Community Supports, могут ли MCP изменить эту форму, включив в нее «адрес электронной почты» для целей электронного уведомления?​​ 

Стандарты направления ECM уже включают «адрес электронной почты направляющего лица» в качестве обязательного элемента в Таблице 2 стандартов направления ECM. Для сбора этой информации обновления не требуются.​​ 

Как MCP будут подходить к повторным направлениям от одного и того же участника на одну и ту же услугу? Пожалуйста, предоставьте дополнительные указания по этому вопросу.​​ 

Ниже приведены примеры сценариев:​​ 

    • Сценарий 1: Направление на услугу, на которую участник уже уполномочен. В случае, если MCP получает направление (например, ECM), а у участника уже есть открытое разрешение на ECM, MCP должен записать ключевую информацию о направлении при получении направления (дату, направляющую сущность, услугу) и соответствующее определение разрешения (например, отклонено), а также предоставить направляющей сущности необходимый контекст в уведомлении о действии (NOA) об отклонении (например, участнику отказано, поскольку у него уже есть активное открытое разрешение на ECM). MCP также должны предоставить контактную информацию, по которой ссылающаяся организация/участник может связаться с MCP, если они захотят запросить смену Поставщика для своей текущей открытой авторизации, если это применимо.​​ 
    • Сценарий 2: Направление на услугу, на которую у участника есть другое открытое направление в процессе обработки. MCP также должен регистрировать ключевые элементы отслеживания CLR по второму направлению в случае, если для Участника одновременно открыты два направления на одну и ту же услугу (например, дата направления, направляющая организация, услуга, статус авторизации). Ожидается, что MCP по-прежнему будет выполнять требования CLR по уведомлению для второго ссылающегося субъекта. DHCS требует от MCP регистрировать информацию по обоим направлениям, поскольку MCP по-прежнему ожидают поддержки направления посредством связи с направляющей стороной и поддержки любой необходимой координации с участником, если дублирующие направления создают неопределенность в отношении назначения соответствующего поставщика услуг. Например, если два разных поставщика ECM направляют рекомендации для Участника, MCP необходимо будет скоординировать действия Участника и направляющих поставщиков ECM, чтобы назначить Участнику предпочтительного поставщика ECM.

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

CLR замечает​​ 

Если MCP определяет лицо как имеющее право на ECM или общественную поддержку, используя свои внутренние данные (т. е. «Тип направления» — «2. Определено MCP»), применяются ли требования уведомления?​​ 

В этом сценарии MCP является ссылающейся стороной, и требования уведомления не применяются. Однако в качестве передовой практики DHCS призывает MCP информировать членов о том, что они имеют право на получение услуги и направлены на нее, чтобы повысить вероятность участия членов.​​ 

MCP часто требуется время для приема и очистки данных RTF от поставщиков. Когда начинается отсчет двух рабочих дней для закрытия цикла направления?​​ 

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

Не мог бы DHCS подтвердить, каким образом MCP должен действовать, уведомляя, является ли ссылающаяся организация участником? Опекун или попечитель члена? Семья, друг или сосед участника?​​ 

В случае, если Участник, его опекун/попечитель или член семьи, друг или сосед подает направление и запрос на получение разрешения ECM/Community Supports, MCP все равно уведомят Участника о решении о выдаче разрешения. Других требований к уведомлению не применяется.​​ 

Каковы ожидания относительно уведомления участника, если он отказался от получения письменных уведомлений от MCP?​​ 

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

Применяются ли требования об уведомлении Участника, если в разрешении на ECM отказано из-за того, что Участник уже зарегистрирован в ECM?​​ 

Да, все направления в ECM и Community Supports являются запросом на авторизацию и подпадают под требования уведомления APL 21-011. В соответствии с APL 21-011 MCP должны использовать соответствующий шаблон NOA, который должен включать краткое объяснение причин принятия решения. В случае отказа в предоставлении ECM из-за существующей авторизации MCP должны четко указать причину отклонения и предложить способ связи с MCP для запроса на смену поставщика ECM, если это необходимо.​​ 

Может ли DHCS разъяснить, кто считается самообращенным? Например, будет ли сосед или учитель считаться обратившимся самостоятельно в целях соблюдения требований CLR по уведомлению? Чего ожидает DHCS от документирования такого типа направлений?​​ 

Направления, сделанные Участником, его соседом, членом семьи, другом или опекуном/попечителем, считаются самонаправлениями. В случае самостоятельного обращения за разрешением на ECM/Community Supports MCP все равно должны уведомить участника о решении по разрешению. Никаких других требований по уведомлению ссылающихся субъектов не применяется. MCP должны отслеживать, поддерживать и контролировать все направления, сделанные в ECM и службы поддержки сообщества, включая самонаправления. Учителя в своей профессиональной деятельности выполняют функции Члена и не классифицируются как «самостоятельно направленные или направленные опекуном», поэтому на них распространяются требования об уведомлении для Направляющих организаций.​​ 

DHCS требует, чтобы MCP использовали электронные методы (не включая факс) для передачи уведомлений ссылающимся субъектам, если иные неэлектронные методы не согласованы между сторонами. Это требование вызывает правовые опасения относительно возможности обмена информацией по электронной почте.​​ 

Руководство о том, что считается безопасным электронным методом, приведено в​​  Приложение G к контракту MCP, Дополнение к договору о деловом партнерстве, § 9.2. В этот раздел включены обязательства, связанные с гарантиями и безопасностью защищенной медицинской информации, включая соблюдение подраздела C части 164 45 CFR.  DHCS рекомендует MCP ознакомиться с часто задаваемыми вопросами по здравоохранению и социальным услугам (HHS):​​  Разрешает ли Правило безопасности отправку электронной защищенной медицинской информации (e-PHI) по электронной почте или через Интернет? Если да, то какие меры защиты необходимо применять?​​ 

В своем ответе Министерство здравоохранения и социальных служб США (HHS) заявляет, что «Правило безопасности прямо не запрещает использование электронной почты для отправки электронной защищенной медицинской информации (e-PHI). Однако стандарты контроля доступа (45 CFR § 164.312(a)), целостности (45 CFR § 164.312(c)(1)) и безопасности передачи (45 CFR § 164.312(e)(1)) требуют от охватываемых организаций внедрения политик и процедур для ограничения доступа, защиты целостности и предотвращения несанкционированного доступа к e-PHI. Стандарт безопасности передачи данных (§ 164.312(e)) также включает адресуемые спецификации для контроля целостности и шифрования. Это означает, что подпадающая под действие соглашения организация должна оценить использование ею открытых сетей, определить доступные и подходящие средства защиты электронной защищенной медицинской информации при ее передаче, выбрать решение и задокументировать решение. Правило безопасности позволяет отправлять электронную защищенную информацию по открытой электронной сети при условии ее адекватной защиты».​​ 

DHCS рекомендует MCP проконсультироваться со своим юрисконсультом для определения безопасных средств электронной передачи на основе настоящих рекомендаций HHS.​​  

Может ли DHCS пояснить, применяются ли требования к уведомлению, подробно изложенные в APL 21-011 для поставщиков (т. е. MCP обязана уведомить поставщика в течение 24 часов с момента принятия решения), также к ссылающимся организациям, как определено DHCS в Руководстве по внедрению CLR?​​ 

Все направления в службы ECM и Community Supports являются запросом на авторизацию и подпадают под действие требований APL 21-011. В соответствии с APL 21-011, MCP должны использовать​​  соответствующий шаблон уведомления о действии (NOA), который должен включать краткое объяснение причин принятия решения. Эти требования применяются ко всем CLR, созданным ссылающимися субъектами.​​ 

Запрошено письменное разъяснение от DHCS, чтобы подтвердить, что врачи-терапевты могут передавать защищенную медицинскую информацию, включая сведения о серьезных психических заболеваниях (SMI)/расстройствах, связанных с употреблением психоактивных веществ (SUD), а также информацию о состоянии благополучия ребенка, направляющим организациям, которые не являются застрахованными организациями, без разрешения пациента.​​ 

DHCS рекомендует указать, разрешены ли ECM или поддержка сообщества, а также причину отказа, если применимо.​​  Для предоставления общего обслуживания (ECM/Community Supports) и решения о выдаче разрешения не требуется обмена информацией SMI/SUD или информацией о благополучии детей. MCP также могут следовать своим существующим процедурам для выполнения требований DHCS по уведомлению в соответствии с APL-21-011 для ECM и поддержки сообщества с момента запуска услуги в 2022 году. DHCS рекомендует MCP проконсультироваться со своим юридическим консультантом, чтобы определить, необходимы ли дополнительные сведения, касающиеся SMI/SUD или благополучия ребенка, и можно ли их предоставить посредством уведомления в соответствии с существующими федеральными и государственными инструкциями.​​ 

Запрос на подтверждение DHCS относительно того, должны ли новые письма-уведомления CLR для членов включать следующие приложения: NOA, Ваши права, слушание на уровне штата и форму IMR.​​ 

Уведомление членов должно соответствовать существующим полным требованиям APL 21-011. Требования к уведомлению членов CLR не отличаются от APL 21-011.​​ 

Потребует ли DHCS планов по представлению писем новым членам CLR на рассмотрение? Если да, то каковы будут сроки рассмотрения и одобрения?​​ 

MCP должны использовать существующие шаблоны уведомлений для авторизованных услуг в соответствии с APL 21-011, чтобы соответствовать требованиям к уведомлениям членов.​​ 

Высказываются опасения, что многочисленные уведомления членов могут иметь противоположный эффект, вызывая путаницу вместо ясности. В настоящее время в соответствии с APL 21-011 участники получают одно письмо при одобрении или отказе в предоставлении услуг ECM. При использовании CLR они могут получить три или более писем с NOA, что может вызвать ненужное беспокойство.​​ 

Кроме того, врачи-терапевты часто обнаруживают, что члены семьи даже не знают, что их вообще направили на ECM. Если бы поставщик ECM связался с вами до отправки письма NOA, это был бы более ориентированный на клиента подход, гарантирующий, что он поймет суть направления и чего ожидать. Может ли DHCS изучить способы оптимизации этого процесса, чтобы уменьшить путаницу и улучшить качество обслуживания участников?​​ 

Руководство по внедрению CLR было обновлено с целью отразить только одно обязательное уведомление для членов во время авторизации в соответствии с требованиями APL 21-011. С момента своего создания в 2022 году ECM подчиняется требованиям APL 21-011 по уведомлению участников.​​ 

Приведенный пример того, как члены не знали о направлении, направленном от их имени в ECM, представляет собой возможность технической помощи для MCP с направляющими субъектами для улучшения практики направляющих субъектов по обсуждению направлений с членом до завершения направления, как указано в Руководстве по внедрению CLR.​​ 

DHCS требует от MCP использовать электронные методы для сообщения статуса CLR, явно исключая факсы и порталы. Это вызывает беспокойство, поскольку отраслевой стандарт для уведомлений о предварительном разрешении в сфере UM основан на проверенных контрактных линиях факсимильной связи.  Хотя мы ценим усилия DHCS по отказу от факсимильной связи, внедрение этого требования к 1 июля без наличия необходимых технологий создаст значительные трудности для MCP в достижении соответствия.​​ 

Для направляющих поставщиков, не имеющих контракта, мы просим разъяснить, что считается безопасным электронным методом, за исключением факса и портала. Как DHCS определяет «электронный метод» и может ли оно привести примеры безопасного электронного обмена защищенной медицинской информацией с субъектами, у которых нет проверенных номеров факсов или адресов электронной почты?​​ 

Руководство по тому, что считается безопасным электронным методом, приведено в Приложении G к контракту MCP, Дополнении к Соглашению о деловых партнерах, § 9.2. В этот раздел включены обязательства, связанные с гарантиями и безопасностью защищенной медицинской информации, включая соблюдение подраздела C части 164 45 CFR. DHCS рекомендует MCP проконсультироваться со своим юридическим консультантом, чтобы определить безопасные способы электронного обмена информацией для соблюдения требований CLR к уведомлениям. MCP могут пожелать изучить защищенную электронную почту или аналогичные методы и разработать шаблоны уведомлений, которые содержат минимально необходимую информацию для соответствия требованиям APL 21-011 и Руководства по внедрению CLR.​​ 

У DHCS запрошены разъяснения относительно ожиданий в отношении уведомлений/коммуникаций для членов, находящихся в заключении.​​ 

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

Запросы на обслуживание (направления) регулярно отправляются поставщиками услуг поддержки сообщества с целью направления участников в соответствующие организации для получения услуг поддержки сообщества. Назначенные поставщики услуг поддержки сообщества, которые оказывают услуги, являются Реферирующей организацией. То же агентство, которое инициировало направление, будет предоставлять обновления CLR через RTF. Требуются ли в этих случаях уведомления CLR при замыкании цикла? Если это так, то уведомление поставщика услуг поддержки сообщества/направляющей организации представляется излишним и добавляет административную нагрузку на MCP, связанную с отправкой уведомления поставщику услуг поддержки сообщества/направляющей организации, которые уже знают о закрытии цикла направления, поскольку они являются той же организацией, которая уведомила MCP о статусе направления посредством отправки RTF.​​  

Да, требование об уведомлении CLR при закрытии цикла рефералов по-прежнему применяется в случае, когда реферирующая сущность также является конечным поставщиком услуг. DHCS сохраняет это требование по следующим причинам:​​ 

    • Некоторые направления от поставщиков услуг общественной поддержки могут быть направлены на другие услуги общественной поддержки или могут быть назначены альтернативным поставщикам услуг общественной поддержки. В обоих случаях уведомление о закрытии цикла направления пациентов важно для осведомленности Поставщика и постоянной координации медицинской помощи с Участником.​​ 
В случае, если направление направлено на поддержку сообщества, а направляющая сторона также является поставщиком услуг, соблюдение требований по уведомлению для закрытия цикла направления обеспечивает важную проверку качества данных как для MCP, так и для поставщиков. Кроме того, требования CLR к мониторингу и поддержке CLR подчеркивают роль MCP в рассмотрении причин закрытия цикла направления поставщиком услуг для выявления пробелов в подходах к взаимодействию и передовой практике. Наконец, требования CLR к уведомлению о закрытии реферального цикла не подпадают под действие APL 21-011 и предоставляют MCP гибкость в отправке пакетных электронных уведомлений ссылающимся субъектам с большим объемом закрытий реферального цикла каждый месяц.​​ 

В соответствии с APL 21-011 в настоящее время MCP направляет письма с решением о выдаче разрешения ссылающимся субъектам. В случае отклонения запроса на обслуживание направляющие субъекты получают письмо, информирующее их об отклонении и причине отклонения. Таким образом, отправка уведомления о закрытии CLR и письма с решением о выдаче разрешения ссылающимся субъектам будет дублирующей, поскольку эти два сообщения будут отправлены одновременно. Может ли DHCS пояснить, должны ли MCP отправлять отдельные уведомления CLR ссылающимся субъектам для статуса CLR: закрыто, причина закрытия CLR: отклонена аутентификация службы?​​  

Если MCP отказывает в авторизации услуги, то достаточно уведомления об отказе в авторизации, направленного ссылающемуся субъекту. Таким образом, в случае закрытия CLR из-за отказа в авторизации отдельное уведомление о закрытии CLR не требуется.​​ 

Форма направления ECM​​ 

Пожалуйста, уточните, является ли форма направления ECM запросом на авторизацию, поскольку в форме нет места для кодов ECM или качества единиц.​​ 

Да, Стандарты направления ECM и Шаблон формы служат в качестве направления ECM к MCP от имени Участника, которое инициирует запрос на авторизацию для ECM. В Руководстве по политике ECM DHCS подчеркивает, что направления ECM запускают сроки рассмотрения авторизации и требования к уведомлению, предусмотренные APL 21-011.​​  

Политика DHCS заключается в том, что MCP не могут просить партнеров по сообществу или поставщиков ECM предоставлять дополнительную документацию, выходящую за рамки Стандартов направления ECM, для принятия решений о выдаче разрешения ECM. Например, направляющие организации не обязаны предоставлять дополнительные контрольные списки соответствия требованиям, формы авторизации на выездную работу, коды МКБ-10, доказательства отсутствия постоянного места жительства, формы запроса на авторизацию лечения (TAR) или другую дополнительную информацию, выходящую за рамки того, что указано в Стандартах направления на ECM, для подтверждения соответствия требованиям и авторизации ECM (подробнее см. в разделах «Направления и авторизации» в Руководстве по политике ECM (стр. 107)).​​ 

Многие направления/запросы на авторизацию ECM исходят из источников, находящихся за пределами самих поставщиков ECM, и DHCS не включает коды или единицы авторизации в Стандарты направлений ECM. Мы понимаем, что некоторым командам MCP ECM может потребоваться сотрудничество со своими командами UM для описания новых требований и корректировки процессов UM с целью их соответствия.​​ 

Несколько дополнительных ресурсов, имеющих отношение к авторизации и кодированию ECM:​​ 

    • Для разрешений ECM требуется первоначальный период действия в 12 месяцев:​​ 
    • (Обновлено в июле 2023 г.) Стандартные сроки авторизации ECM: для всех участников, получивших разрешение на получение ECM от своего MCP, первоначальный период авторизации составит 12 месяцев, а период повторной авторизации — 6 месяцев. MCP не могут устанавливать дополнительные требования для авторизации услуг ECM, выходящие за рамки критериев соответствия целевой аудитории, указанных DHCS. Например, врачи-терапевты не могут отказать в выдаче разрешения до тех пор, пока не будет завершен план лечения. (Страница 108, ECM PG)​​ 
    • Руководство ECM HCPCS – Стандартизированные коды для претензий и обращений​​ 

Отчетность в формате JSON​​ 

Может ли DHCS пересмотреть запрос на предоставление отчетов JSON по элементам CLR по крайней мере до января 1, 2026? Было бы разумно перенести отчетность CLR JSON по крайней мере на январь 1, 2026, чтобы обеспечить полную и надлежащую реализацию процесса и обмена данными.​​ 

Шаблоны JSON фазы 4 CLR, включающие элементы данных CLR для мониторинга данных, были переданы MCP в феврале 2025 года вместе с соответствующим графиком тестирования, а окончательное руководство по JSON фазы 4 было опубликовано в марте 28, 2025. Все руководства по обновлению ECM и инструментов обмена информацией Community Supports (MIF, RTF и ASF) были выпущены в декабре 2024 года, при этом в документах были изложены конкретные обновления для поддержки CLR.​​  

DHCS настоятельно рекомендует MCP продолжить работу по обновлению Руководства по обмену информацией об участниках в соответствии с требованиями, опубликованными в декабре 2024 года, а также оказать техническую помощь и поддержку поставщикам услуг ECM и поддержки сообщества для вступления в силу нового Руководства по обмену информацией об участниках в июле 1, 2025.​​ 




Дата последнего изменения: 5/29/2025 2:45 PM​​