You are here: Foswiki>Gnumed Web>BillingProposalRu (17 Mar 2013, IvanLykov)EditAttach

Платежное предложение

Эти настройки конфигурации GNUmed были добавлены, чтобы позволить автоматическое создание платёжных событий, полученных из
  • платных обращений
  • оплачиваемых задач (предстоит)
  • имени демона маршрутизации по умолчанию (например, gm2mediclaim для Британской Колумбии CA, или простых счетов-фактур)

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

Предполагая, что автоматическое создание включено, то, как только обращение пациента создано и encounter_type завершен, ключевое значение для поля таблицы encounter_types create_billable будет определять любое автоматическое создание записи в таблице billables следующим образом:
  • create_billable = true, например, с настоящими физическими посещениями
    • запись по оплате создаётся со значением bill_this = TRUE
  • create_billable = false, например, результирующее из обзоров карты
    • не утруждайтесь созданием платёжной записи
  • create_billable = null, например, когда невозможно знать, как и при некоторой телефонной помощи
    • запись по оплате создаётся со значением bill_this = null

В таблице billables
  • nulls останутся необработанными, пока значение bill_this не будет обновлено
  • trues, вероятно, потребуется
    • ключ для обращения (если получено обращение)
    • ключ для пациента (если получено не обращение)
    • ключ для практикующего, кому оплачивать (если получено не обращение)
    • дата и время (на которое утверждена услуга)
    • bill_comments (RFE или другой свободный текст для руководства клерка по платежам)
    • bill_formatted (пользовательский плагин должен распознать это)
    • bill_documentation (где для включения может протребоваться отчёт; в BC это могут быть дополнительные диагнозы в комплексных консультациях)
    • bill_statusinfo (возвращает сведения, которые пользовательский плагин должен распознать)
    • amount_billed (цифровое или валютное, как поступает обратно от биллинговой программы)
    • total_received (цифровое или валютное, как поступает обратно от биллинговой программы)
    • состояние ("оригинал", "завершено", "передано", "оплата", "посредничество", "признано", "отказано", "пересчитано", "списано", "частично оплачено", "оплачено")
    • демон маршрутизации (хотя никогда не знаешь, может будет только один на установленный GNUmed,)
  • ложные платежи, когда любой созданный можно сделать по умолчанию скрытым и снова видимым в случае, когда запись должна быть сделана оплачиваемой

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

Плагин должен позволять создавать новые платежы, потому что
  • автоматическое создание может быть не включено на уровне системы или на уровне отдельного encounter_type
  • некоторые обращения могут предотвращать более одной оплаты
  • некоторые платежи могут быть непривязанными, например, не связаны с обращением

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

Плагин должен разрешать значения bill_this для изменения и (при обновлении) обеспечить надлежащие ключи обращения, пациента, практикующего.

Поле bill_formatted может быть одинарным, в котором содержимое переменной может храниться в зависимости от различных биллинговых модулей. Каждый плагин может управлять своей собственной спецификацией, как внутренне форматированы данные (HL7, ad hoc carat (^)-delimited) в поле bill_formatted. Плагин может выполнять поиск по фильтру, чтобы помочь выбрать наборы диагностических кодов для использования (или наборы платёжных кодов). Плагин может принимать к обработке только пункты, отмеченные для конкретного плательщика или (если "умный") может принять во внимание требования по назначенному плательщику. Альтернативой плагинов на основе плательщика будет такое взаимодействие с Mirth, чтобы Mirth выполнял основе плательщика получение данных от EMR.

Любой, кто управлял выставленными счетами, понимает важность, чтобы не упустить платёж. Именно для этого умолчания в определенных типах обращений... чтобы убедиться, что люди не просто забыли оплатить, будет необходимо выполнять запросы по всем платежам пациента в целях выявления возможных оплачиваемых пунктов (пустых), по которым никаких решений еще не сделано, а также которые еще не одобрены для принятия коннектором, которому необходимо перенести пункты в биллинговую систему. Этот IMO должен быть другим плагином (плагин "отчёта по платежам").

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

В зависимости от внешней биллинговой системы в GNUmed XML-RPC может быть применяем или нет. В случае с веб-сервисами (см. пример) XML-RPC может быть неуместен. Пользователь может, однако, быть в состоянии вызвать, из каждого детализацию оплаты и плагины отчёта по платежам, сценарий или подсистему, которые бы запросили платежи и передали соответствующие во внешнюю систему платежа. Я бы даже вообразил какой-то приоритет, в котором запускал изнутри пациента для отметки своих платежей с приоритетом "немедленной передачи", так что подсистеме при встрече с любым пунктом высокого приоритета в его запросе будет в текущей итерации передавать только их, сохранив пункты обычного приоритета для следующей итерации. Я думаю, что это может сократить время для ожидания пациента, если он на стойке регистрации, и его попросили подождать, пока оплатит то, что он должен заплатить сам. Mirth вполне вписывается в это и предусмотрен проектом WorldVista для улучшения передачи информации в OpenEMR для пользователей WorldVista, которые могут пожелать использовать платежи в OpenEMR.

соображения по bill_formatted

Содержимое этого поля может включать:
  • уникальные идентификаторы для оплачиваемого, пациента, специалиста этого GNUmed
  • идентификатор плательщика, который должен оплатить этот пункт (BC: BC, RCP-province, ICBC, WCB)
  • идентификатор услуги, либо инвентарного объекта для оплаты (BC: код оплаты)
  • дату (или диапазон), на которую этот пункт должен быть востребован
  • продолжительность или единицы измерения расходов на основе времени (например, расходы после часа, посещения в больнице по всему диапазону дат)
  • величину (количество дней или единиц измерения)
  • суммарные поля (базовая цена, примененная цена, скидка, taxField1, taxField2, всего, получено)
Topic revision: 17 Mar 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark