You are here: Foswiki>Gnumed Web>BillingBritishColumbiaRu (08 Mar 2013, IvanLykov)EditAttach

Составление счёта в Британской Колумбии (Канада)

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

Британская Колумбия

Проектная спецификация для коннектора gm2mediclaim в коммерческой биллинговой службе Mediclaim

Введение

Является потенциальным решением составления счетов для GNUmed в Британской Колумбии.

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

Обзор необходимого для коннектора gm2mediclaim:
  • передает подходящее оплачиваемое из таблицы billables для Mediclaim в формате, совместимом со стандартом JSON - Объектная нотация Javascript (Javascript Object Notation , модуль Python, рецепт модуль лучше, третий)
  • определяет из Mediclaim состояние ранее переданного оплачиваемого и обновляет его в GNUmed
  • доставляет обратно от Mediclaim любые дополнительные сообщения, полученные с их стороны, возможно, в новой таблице billing_returninfo
  • выполнят указанное по запросу пользователя, а также как задания - проверяет наличие нового оплачиваемого с подходящими интервалами (скажем, 15 мин)

Особенности (tba):

В и О с разработчиком Mediclaim

'> В зависимости от того, как будет работать коннектор на стороне Mediclaim, мне
'> интересно, могут ли быть доступными все следующие процессы для
'> биллингового клерка или медицинского "пользователя":

Чтобы ответить на ваш вопрос, можно просто отметить, что "коннектор" на самом деле просто без веб-службы. Веб-сервис не знает о клиенте и предоставляет простой интерфейс, позволяющий клиенту отправлять и получать данные по мере необходимости.

'> i) может ли пользователь при работе с конкретным пациентом и после
'> создания записей EMR, представляющих собой "оплачиваемые пункты", инициировать
'> процесс, при котором только у этого пациента неоплаченные пункты получат
'> связь с Mediclaim (и статус любого
'> ранее переданного обновленного оплачиваемого)?

Это стало бы конкретной проблемой клиента (в вашем случае я предположил бы GNUmed), но, конечно, эти данные должны быть переданы в пределах области действия, в которой веб-служба, в конечном счете, употреблятся.

'> ii) может ли пользователь ссылаться на процесс с большим подмножеством (например,
'> всё от одного врача), или все еще неоплаченные пункты EMR, для получения
'> сообщения Mediclaim
'>
'> iii) может ли процесс сообщения также быть запущен независимо
'> (автоматически), например как crontab, предполагая, что полномочиям потребуется
'> включение в сценарий?

Как и в случае i) эти проблемы будут рассмотриваться на стороне клиента. Веб-сервис просто на холостом ходу, пока вызывается проверка подлинности клиента, которая осуществляет передачу данных в ожидаемый формат, который будет стандартом iso JSON (Объектная нотация JavaScript?)

'> Возвращаясь к вышеуказанному:
'>
'> 1. там ничего не будет о процессе соединения, который
'> делает интерфейс Mediclaim недоступным или даёт возможность
'> секретарю остановиться перед входом в свой ​​аккаунт, и поэтому
'> в состоянии проверить требования о любом пациенте, даже если обработчик сообщения
'> был избирательно занят EMR для новых оплачиваемых пунктов и в процессе
'> их добавления в базу данных Mediclaim?

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

'> 2. если врач создаёт оплачиваемый пункт, и процесс
'> соединения был вызван, есть ли идеи о задержке
'> перед тем, как эти записи будут показаны и доступны в Mediclaim,
'> 15 - 60 секунд или 1 - 5 - 20 минут (или больше)?

Данные станут доступными на Mediclaim сразу после получения записей (передачи будут обрабатываться в реальном времени)

'> 3. кроме срабатывания, инициированного пользователем (если оно было
'> возможно), и полагая, что запросы, которые не принесли никаких новых оплачиваемых,
'> воздержатся от бессмысленных подключений к Mediclaim, то для Mediclaim
'> будет разумна максимальная частота обработки входящего соединения
'> с EMR (наиболее короткий интервал) ... 5 минут?
'> 10 минут? больше?

Этот вопрос на самом деле не доработан. Я думаю, что максимальная частота, возможно, не так важна, как минимальная (если минимальная частота мала, она может повлиять на производительность.

Спецификация файла данных (коммерческая служба <--> брокер налогоплательщиков <>)

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

  • стандарты основываются на передаче файлов MS-DOS ASCII
  • соединение с правительственным электронным брокером "Teleplan", либо на основе браузера,либо через API (доступен код PERL)
  • службы Teleplan выступают брокером для требований, предназначенных для оплаты между:
    • планирование медицинских услуг провинциального здравоохранения
    • провинциальная корпорация по автострахованию Британской Колумбии
    • компенсация провинциального рабочего совета
    • указанные плательщики используют тот же формат записи и данные, за исключением содержания и внутреннего формата в нескольких полях
  • поддерживает МЕТОДИКИ МОДУЛЯ КОНТРОЛЬНОЙ ЦИФРЫ, например, для "Личного медицинского номера" в провинциальном министерстве здравоохранения
  • данные ASCII расположены в определенной последовательности полей, длины полей (нулевого или заполненного пространства) в каждой записи, разделенные CR/LF.
  • Каждая передача должна начинаться с порядкового номера последней записи в последней успешной передаче, увеличенной на единицу.
  • Каждая запись в передаче должна иметь порядковый номер, последовательно на единицу больше предыдущей записи.
  • Все сайты начинаются с единицы (0000001) в своей первой передаче, этот номер затем увеличивается на единицу, пока не достигнет предела 9999999, в этой точке должен начинаться с единицы (0000001) еще раз.
  • Первая запись в каждом загружаемом файле передачи должна также содержать стандартную информацию, идентифицирующую, например, программу, в которой был создан файл
  • в каждой передаче записи после первой будут содержать данные, идентифицирующие пациента, поставщика и служебную информацию
  • следующая запись будет, либо содержать дополнительные сведения об указанной записи ("примечание"), либо будет обозначать другое требование
  • если следующая запись представляет собой тип "примечание", то она поддерживает 400 знаков, которые можно использовать в различных формах для обслуживания требований к данным различных плательщиков
  • требования за услуги, которые проводятся повторно (например, первоначально были отказаны из-за отсутствия или недействительной информации, или неправомочности), могут быть отправлены в этом же файле, как направляемые в первый раз, и в любом порядке, при единственном условии необходимости соблюдать требование последовательной нумерации и, что при отправке в виде нескольких записей данных для любого конкретного требования, эти записи следуют вместе (одна за другой)
* ограничение одного файла передачи на общее число записей составляет 3000, а общая сумма их выставленного счета составляет 9 миллионов $Can * Для полей, которые могут быть отрицательными, отрицательные представления значения должны отображаться, как нечисловой символ в крайнем правом положении от поля суммы, где "0,1,2...9" становится "},J,K,L,M,N,O,P,Q,R"
Topic revision: 08 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