Транзакция 835

Транзакция 835 — это стандартизированный электронный документ в формате EDI (Electronic Data Interchange), используемый в сфере здравоохранения США для передачи информации о платежах, произведённых страховой компанией (планёром) медицинскому учреждению или поставщику услуг, а также о соответствующих корректировках (списаниях, отказах, переплатах). Транзакция 835 служит аналогом бумажного расчётного листа (remittance advice) и является обязательным элементом электронного обмена данными между медицинскими организациями и страховщиками в соответствии с требованиями HIPAA (Health Insurance Portability and Accountability Act — федеральный закон США о переносимости и подотчётности медицинского страхования).

История и нормативная база

Разработка стандарта EDI 835 началась в 1990-х годах в рамках усилий по автоматизации административных процессов в здравоохранении США. В 1996 году был принят закон HIPAA, который предписал использование единых электронных форматов для транзакций между медицинскими учреждениями, страховщиками и правительственными программами (Medicare, Medicaid). С 2003 года все участники рынка обязаны поддерживать версию 4010A1 стандарта 835, а с 2012 года — версию 5010A2.

Транзакция 835 является частью набора транзакций X12N, разработанного комитетом по стандартизации электронного обмена данными (ASC X12). Она заменила собой множество различных бумажных и проприетарных электронных форматов, что значительно упростило взаиморасчёты и снизило количество ошибок.

Структура и содержание

Транзакция 835 представляет собой текстовый файл, состоящий из сегментов (блоков данных), каждый из которых начинается с определённого кода. Основные элементы включают:

• Заголовок (ST — Transaction Set Header): идентификатор транзакции, номер версии.
• Информация о плательщике (N1 — Loop 1000A): название страховой компании, адрес, идентификатор.
• Информация о получателе платежа (N1 — Loop 1000B): название медицинского учреждения или поставщика, налоговый номер.
• Сводка по платежу (BPR — Financial Information): общая сумма платежа, дата, способ перевода (через ACH, чек, карту).
• Детали по каждому счёту-фактуре (CLP — Claim Payment Information): номер счёта, сумма, статус (оплачен, частично оплачен, отклонён).
• Корректировки на уровне счёта (CAS — Claim Adjustment Group Code): коды причин уменьшения или отказа в оплате (например, код 45 — «превышение лимита», код 97 — «услуга не покрывается страховкой»).
• Детали по каждой позиции счёта (SVC — Service Payment Information): код услуги, сумма, количество.
• Корректировки на уровне позиции (CAS — Loop 2430): аналогично, но для конкретной услуги.
• Итоговые суммы (SE — Transaction Set Trailer): количество сегментов, контрольная сумма.

Классификация и типы

Транзакция 835 может быть классифицирована по нескольким признакам:

• По статусу платежа:
• Оплаченная (paid): полная или частичная оплата счёта.
• Отклонённая (denied): полный отказ в оплате с указанием причины (обычно код CAS).
• Скорректированная (adjusted): оплата с вычетами по различным основаниям (договорные скидки, штрафы, переплаты).
• По способу передачи:
• Прямая (direct): передаётся от страховщика поставщику через защищённые каналы (VPN, SFTP).
• Через клиринговую палату (clearinghouse): посредник агрегирует данные от нескольких страховщиков и передаёт поставщику.
• По формату данных:
• Стандартный EDI X12 835 (текстовый, с разделителями).
• XML-версия (реже используется, но поддерживается некоторыми системами).

Применение и значение

Транзакция 835 используется в следующих ключевых областях:

• Автоматическое зачисление платежей: медицинские учреждения получают файл 835, который автоматически сопоставляется с открытыми счетами в бухгалтерской системе (ERP, HIS). Это исключает ручной ввод данных и снижает риск ошибок.
• Управление дебиторской задолженностью: на основе данных 835 формируются отчёты о просроченных, отклонённых и частично оплаченных счетах. Коды CAS позволяют анализировать причины отказов (например, отсутствие предварительного разрешения, неверный код диагноза).
• Сверка с банковскими платежами: сумма в транзакции 835 сверяется с фактическим поступлением денег на расчётный счёт. Расхождения (например, из-за комиссий или задержек) фиксируются и требуют ручной обработки.
• Аудит и отчётность: данные 835 используются для формирования отчётности перед регулирующими органами (например, Medicare) и для внутреннего аудита финансовых потоков.
• Интеграция с системами управления доходами (RCM — Revenue Cycle Management): транзакция 835 является финальным этапом цикла дохода, подтверждая факт оплаты.

Примеры использования

Предположим, медицинская клиника выставила страховой компании счёт на $1000 за приём врача. Страховщик обработал счёт и сформировал транзакцию 835, в которой указано:

• BPR: сумма платежа $800, дата 15.03.2024.
• CLP: номер счёта 12345, сумма $1000, статус «частично оплачен».
• CAS: код 45 (превышение лимита) на сумму $200.

Клиника получает файл, система автоматически уменьшает дебиторскую задолженность на $800, а оставшиеся $200 помечаются как списание по причине «превышение лимита». Если пациент должен доплатить разницу, система выставляет ему счёт на $200.

Критика и ограничения

Несмотря на широкое распространение, транзакция 835 имеет ряд недостатков:

• Сложность формата: файлы EDI сложны для чтения человеком и требуют специализированного программного обеспечения для парсинга. Малые медицинские учреждения часто вынуждены нанимать посредников (клиринговые палаты) или использовать дорогостоящие ERP-системы.
• Ошибки в кодах CAS: страховщики не всегда корректно заполняют коды причин корректировок, что затрудняет автоматическую обработку и требует ручной проверки.
• Задержки в передаче: несмотря на стандарты, задержки в доставке файлов 835 (от нескольких часов до нескольких дней) могут нарушить цикл доходов.
• Несовместимость версий: переход с версии 4010A1 на 5010A2 в 2012 году вызвал значительные сложности у многих организаций, особенно у тех, кто использовал устаревшее ПО.
• Безопасность: хотя передача обычно шифруется, утечка файла 835 может раскрыть конфиденциальную финансовую и медицинскую информацию.

Источники

• HIPAA Administrative Simplification: Standardized Electronic Transactions (CMS)
• ASC X12 Standards for Electronic Data Interchange, Technical Report Type 3 (TR3) — 835 Health Care Claim Payment/Advice
• Medicare Claims Processing Manual, Chapter 24 — Electronic Data Interchange (EDI) Transactions
• Workgroup for Electronic Data Interchange (WEDI) — 835 Implementation Guide