Billing British Columbia (Canada)

Each of Canada's 10 provinces has their own claim submission, claim remittance, and file transfer standards. Other (e.g. federal) health "payers" exist, billings to some of whom can be routed through the local provincial system.

British Columbia

Draft specification for gm2mediclaim connector to the Mediclaim commercial billing service

Introduction

This represents a potential billing solution for GNUmed in British Columbia.

Among the many companies in British Columbia that provide medical billing software, one hosts a browser-based web service (Mediclaim internet-based billing) and is developing a connector (a stateless web service). The web service would have no knowledge about the client and it would provide a simple interface which would allow a client to post and get data on an as needed basis.

Overview of what is needed for a gm2mediclaim connector:
  • transmit suitable billables, from the billables table, to Mediclaim, in a format compliant with iso standard JSON (Javascript Object Notation, Python module, recipe, better module, third one)
  • determine, from Mediclaim, the state of previously-transmitted billables and update these in GNUmed
  • deliver back, from Mediclaim, any additional messages delivered from their end, perhaps into a new table billing_returninfo
  • perform the above upon user request, and also as a cron job that checks for new billables at suitable intervals (say 15 min)

Specifics (tba):

Q & A with a Mediclaim developer

'> Depending in how the Mediclaim-side connector would work, I am
'> wondering whether the following processes could all be available to
'> the billing clerk or doctor "user":

To answer your questions, it might simplify things to point out that the "connector" is actually just a stateless web service. The web service would have no knowledge about the client and it would provide a simple interface which would allow a client to post and get data on an as needed basis.

'> i) could the user, while working on an individual patient, and after
'> creating the EMR records which constitute "billable items", trigger a
'> process under which just this patient's unbilled items get
'> communicated to Mediclaim (and the status of any
'> previously-transferred billables updated)?

This would be a client specific problem (in your case I would assume that to be GNUmed), but certainly, the data to be transmitted is within the scope of what the web service will eventually consume.

'> ii) could the user invoke a process in which a larger subset (e.g. all
'> of one doctor's), or all of the as-yet unbilled EMR items, would get
'> communicated to Mediclaim
'>
'> iii) could the communication process also run independently
'> (automatically) e.g. as crontab assuming that credentials would need
'> to be included in the script?

As in the case of i) these problems would be dealt with on the client end. The web service is simply idle until it is invoked by an authenticated client which is capable of transmitting data in the expected format, which will be the iso standard JSON (Javascript Object Notation)

'> Coming back at the above:
'>
'> 1. would there by anything about this connection process that would
'> make the Mediclaim frontend unavailable, or could it be possible for
'> the secretary to stay logged in with her own account, and therefore
'> able to check on any patient's claims, even while the message handler
'> was busy polling the EMR for new billable items and in the process of
'> adding these to the Mediclaim database?

Typical problems such as network lag, server outages could render the web service unavailable, in which case, the client would be responsible for dealing with that exception.

'> 2. if a doctor would create a billable item, and the communication
'> process were to be triggered, have you any idea whether the latency
'> before these records would show up and be accessible in Mediclaim
'> would be 15 - 60 seconds or 1 - 5 - 20 (or more) minutes?

The data would become available on Mediclaim immediately, upon receipt of the records (the transmissions would processed in real time)

'> 3. apart from the user-initiated triggering (assuming it was
'> feasible), and assuming that queries that fetched no new billables
'> would refrain from making pointless connections to Mediclaim, what
'> would be the reasonable maximum frequency (shortest interval) for
'> Mediclaim to handle an incoming connection from the EMR... 5 minutes?
'> 10 minutes? more?

This point has not really been fleshed out. I think the maximum frequency is perhaps not as important as the minimum frequency(if the minimum frequency is to small, that could have performance implications.

Data file specification (commercial service <--> payers' broker)

This provides some idea of the constraints for what the commercial service must exchange with the BC payers' broker.

  • the standards are based on MS-DOS ASCII file transmission
  • connection to the government electronic broker "Teleplan" is either browser-based, or via API (PERL code available)
  • Teleplan serves as the broker for claims intended to be paid by any among:
    • the provincial health Medical Services Plan
    • the provincial auto Insurance Corporation of BC
    • the provincial Workers' Compensation Board
    • the above payers use the same record format and data except for the content, and internal format, of a few fields
  • supports MODULUS CHECK DIGIT ROUTINES e.g. for the provincial healthy ministry "Personal Health Number"
  • ASCII data is arranged in a fixed field sequence, field length (zero- or space-filled) with each record separated by CR/LF.
  • Each transmission must begin with the sequence number of the last record of the last successful transmission incremented by one.
  • Each record in a transmission must have a sequence number sequentially one higher than the previous record.
  • All sites start with one (0000001) on their first transmission, this number then increases by one until you reach the limit of 9,999,999 at which point you must start at one (0000001) again.
  • The first record within each uploaded transmission file must also contain standard information identifying e.g. the software by which the file was generated
  • within each transmission, records after the first will contain data identifying the patient, provider and service information
  • the next record will either contain additional ("note") information concerning the record above, or will denote a different claim
  • where the next record is a "note" type, it supports 400 characters that can be used in a variety of ways to serve the data requirements of different payers
  • claims for services that are being resubmitted (for example were refused originally on account of missing or invalid info or ineligibility) can be sent in the same file as claims being sent the first time, and in any order, subject only to having to obey the requirement for sequential numbering and the requirement that when data for any particular claim is being sent as multiple records, these records are sequenced together (one after the other)
  • limit, in any one transmission file, on the total number of records is 3,000, and total amount being billed is $Can 9 million
  • For fields which could be negative, negative value representation needs to appear as a non-numeric character in the rightmost position of the amount field, where "0,1,2...9" becomes "},J,K,L,M,N,O,P,Q,R"
  • more at http://www.health.gov.bc.ca/msp/infoprac/teleplanspecs/
Topic revision: 10 Mar 2009, KarstenHilbert
 
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