[Gnumed-devel] Other FLOSS EMRs and GNUmed (from a Canadian context)

[Jim Busser]

I felt like doing a current-state update.

In Canada, OSCAR EMR is the only obviously-in-use free EMR. 

OSCAR EMR is, at this stage, a much broader (more fully-featured) solution than 
is GNUmed, providing (among other things):

1) appointment-making and

2) billing support in at least two out of ten Canadian provinces: in Ontario – 
OSCAR's province of origin – and British Columbia ("BC").

OSCAR has had some additional adoption in provinces in which billing may not 
yet be supported… though I am less clear on how such users manage their billing 
alongside OSCAR.

Accordingly there is, on the one hand, appreciation for what OSCAR has 
achieved, and a worry whether a less-fully featured EMR (as currently GNUmed 
stands) risks being too easily dismissed. Even despite that I found a billing 
program in my province of BC that will crudely interoperate with a 
not-yet-in-production GNUmed.

On the other hand, not everyone fully implement OSCAR (or any EMR) for all of 
what it *could* do.

Some groups choose a combination of old methods and/or OSCAR alternatives, plus 
part of OSCAR.

At least one doctor in BC (near retirement) maintains a paper practice, while 
using OSCAR "on the side" for medication management. He finds an EMR 
tremendously helpful just to:
1) maintain the information of what a patient is *supposed* to be taking and
2) printing an authorization (a prescription) for any combination of new 
medication, adjusted medication, and renewed medication

I understand that OSCAR's appointment-making was built on a blueprint that 
well-suited the practice around which OSCAR was modelled. This may less-well 
suit other approaches to appointment-making. However, it has required groups to 
adapt their appointment-making workflows to conform to OSCAR's requirements. 
There is an inevitability to do so, when it is a precondition to be able to use 
the billing as implemented in OSCAR or in any other EMR where billing is 
dependent to be "fed" from the entity "appointments". The alternative would be 
for the billing module to be fed from an alternative set of billable items as 
could be achieved, say, from:

        encounters as services
        events within encounters (say, "procedures") as services
        events after encounters (say, "reports") as services
                (capturable perhaps as a different encounter type)
        supplies consumed by – or provided to – patients

The above makes me think that whether it would be GNUmed – or maybe better 
sanely some other software – the most flexible (and therefore potentially 
widely-applicable) billing approach would be a rather MIRTH-like-BILLER, in the 
sense that it could accept multiple inputs. Even a single EMR could send 
multiple data streams (outputs) to the MIRTH-like-BILLER, where the aggregate 
of the source EMR's outputs could represent a sum total of billable items for 
that praxis. 

At the downstream end, the MIRTH-like-BILLER could work as follows. Based on a 
series of known definitions ("rules") of what each 
financially-responsible-agency (FRA) sets as preconditions for payment, the 
MIRTH-like-BILLER could flag deficient or rules-failing records, and flag these 
for iterative attention by the billing party. This the MIRTH-like-BILLER would 
also do for remittance information (acceptance or refusal of payment) which had 
been received back from the various FRAs.

There is some talk of whether the US VistA RPMS would be able to use the 
billing functionality that exists within OpenEMR in this sort of way. Also, I 
think Fred Trotter is contemplating to write some new billing program from 
scratch. The US stands to offer Fred as good or better economy of scale as he 
could achieve anywhere else. If a business case could be made to develop 
something, then maybe Canadian billing could work as an add-on.