This is something I wanted to ask from the community. I have met several people who would like to use OpenMRS. But when they asked for billing aspect of the OpenMRS, I couldn’t give a strong answer for that. I saw BAHMINI incorporate with a billing solution with OpenMRS and ERP system. But how standalone OpenMRS can used in terms of billing aspect?
I also think, OpenMRS objective is to provide free medical record system. But some small organizations in countries, there one major concern will be on how to bill a patient. So if we have strong module it will be a definite plus point.
I’m not sure it’s align with OpenMRS objectives and goals. Just to get some advice on this when someone ask for a solution with billing?
There have been several billing-related efforts (usually billing modules) over the years. I don’t recall anyone taking on the goal of creating a billing solution that is used in 2-3 or more unrelated implementations (i.e., something that could be re-used by others).
Billing, much like Lab, Pharmacy, Radiology, etc. is something that could be implemented in a simple form as a module and would likely scale (for an enterprise) to be a separate system, where the module (or other module(s)) would serve an integration role.
I too went through some existing billing module which is now maintain by hspa india which will no longer compatible with OpenMRS. I think if we take a step on this, we can take it as a reference. I think there are many situations, countries not always offer there healthcare activities for free. Having stable billing module which incorporate with the activities will be really good.
My opinion is that Bahmni is doing this correctly.
Other people/communities have already built billing systems (e.g. the
billing feature in OpenERP). I don’t think it’s worth duplicating this
effort in an OpenMRS module, when one can integrate with an external system
like Bahmni has done.
(Sometimes the “build a simple OpenMRS module for it” model works, but I
think billing is an example where you can’t just build a simple “80%”
module because people will need to handle all the tricky cases too, that we
presume an existing billing system has already discovered. Angshuman once
pointed out to me “would a simple OpenMRS billing module cover the case
where the patient needs to pay in multiple installments? Probably not. You
want a real billing system for this.”)
If you do want an in-OpenMRS module, you can check out the OpenHMIS
modules, which include a billing one.
My own recommendation to people is generally to look at Bahmni. If you want
to run OpenMRS in a facility, with “typical” workflows, covering not just
EMR but also HIS (+/- LMIS and radiology) then Bahmni includes this
already, whereas if you start from vanilla OpenMRS you really have a long
way still to go. The documentation and community support are insufficient
at present, but I know the Bahmni team is working on this…
I feel Bahmni with its bundling of OpenERP and OpenELIS along with OpenMRS is overkill for many small institutions and clinics. Managing data in 3 databases in different database servers in my opinion is difficult, particularly in places where there are not many IT people and server resources. So, I see a definite need for simple modules that support billing, radiology information systems and lab systems that are all as OpenMRS modules
I totally agree that dedicated independent systems for each aspect of hospital management is often overkill for small/medium-sized institutions. The modules my team (OpenHMIS) have created (Cashier and Inventory) are designed with that in mind and are intended to be general-purpose solutions that will work in a wide variety of institutional.
We chose cashier and inventory because are two of the more common HMIS features that are needed by small/medium institutions and because a simple, integrated solution can provide a big benefit. However, once you get into systems like Lab, Pharmacy, HR, and Finance, there isn’t as much to be gained from implementing within OpenMRS. For these systems (and for large institutions) we agree that connecting OpenMRS to other dedicated systems is a much better long-term solution. The Bahmni solution is an excellent example of this and I would highly encourage people who need that level of support to look at that solution. That being said, I do hope that we (that is, the greater OpenMRS community) can build/standardize a more general-purpose solution that utilizes HL7/FHIR, some kind of ESB (Mirth, Mule, Switchyard), and some standard connections to various lab, pharmacy, ERP, HR, etc systems.
I know that the KenyaEMR guys were developing a HL7/Mirth-based connection from OpenMRS but I don’t know how far along that is or what the future plans are for it. Are there any other groups doing similar work? The OpenHMIS team will be moving in that direction in 2016 and we would love to work with others who have similar goals.
@harsha89 Please feel free to ask me any OpenHMIS-related questions if you’re curious if/how it could be used in your setting.
Is there any discussion whether this applies to inpatient versus outpatient and whether the bill focuses on diagnoses or on procedures/professional charges? We clearly are working on including ICD-10/DRG? related content, but things like CPT for procedure charges or HCPCS for DME charges requires substantial licensing issues which CIEL cannot easily provide to the masses.
@darius is Bahmini is open source solution which anyone can setup by following documentation? Or do it requires to take the support from Bahmini. Is it accompanied with a licence cost?
@sunbiz@ibewes thanks a lot for the pointers. I didn’t notice about this modules before let me check on them quickly.
In general I too agree Bahmini is doing it correctly. But when small set of people or may be a organization going to setup OpenMRS, they will need small scale solution which integrate with OpenMRS.
From my vantage point, when we talk about “billing capability”, there’s a wide variance of use cases that someone could be talking about.
The scope and complexity of the use cases needed for a given facility then need to be measured against the technical complexity the facility would need.
I can imagine settings where having a robust standalone ERP would be in order.
I can also imagine settings where a simple OpenMRS module might be more ideal.
We will evolve as a community when we can start to better understand ways to describe these variances in ways that are comparable to each other and understood by all.
I think it’s a false dichotomy to compare a simple billing approach to an integrated approach like Bahmni. I often times have seen people “complain” about duplicative or stylistically different ways of coding EMR functionality, but in my opinion… sometimes those differences have value in different contexts.
I’d like to encourage a more detailed conversation around the settings we are talking about implementing billing functionality in, and start to compare/contrast them.
But in short:
>> is Bahmini is open source solution which anyone can setup by following
documentation?
yes. the documentation may be lacking in places, but you can also get on
the bahmni IRC channel or bahmni channel on openmrs talk. some details here
>> Or do it requires to take the support from Bahmini. Is it accompanied
with a licence cost?
no
I would only add two points.
You need to have only the databases for sub-systems that you use. So, in
this case two databases, for MRS and ERP (and not for lab that is). The
overhead of this can be overestimated usually. In my experience it is the
semantic overhead that matters lot more than technical overheads.
Billing is not just billing but also accounting to some extent which
gets overlooked.
We’re facing the same challenge here in Kenya with KenyaEMR. We are trying to explore what would be a suitable solution for a more enterprise-wide HMIS. That means not just billing integration but also PIS, LIS and some MPI implementation for unique patient identification.
I agree with the view that the choice between simpler solutions implemented within OpenMRS vs integration with more sophisticated external systems should be considered based on context. However, given that we currently have 341 implementations with evolving needs and common reporting requirements, there is definitely value in adopting a common solution.
These implementations vary from small dispensaries to large hospitals, and therefore the temptation is to go favor integration as it is likely to cover the widest scope of use cases. The risk, as some here have hinted at, is that maintaining 4 or 5 different systems is bound to be technically complicated and likely result in so many episodes of downtime and failure that the value of the entire solution is lost. This is doubly true when so many implementations are involved.
We are still in the process of determining which we to go so we are very interested in this conversation and understanding what others’ experiences have been.
I agree that sometimes it’s good enough to have “Simple Xyz” as an OpenMRS
module, and sometimes you need a dedicated external system. (Also, the more
clinical the use case, the better it fits as an OpenMRS module, in my
opinion. So I’m a big fan of using OpenERP for billing/accounting, stock
management, HR, etc, while doing things like radiology as OpenMRS modules.)
I also agree that smaller facilities need to have
relatively-simpler-to-manage systems. But “how many kinds of DB are
installed” and “how many webapps in tomcat” aren’t the only dimensions of
complexity. Generally speaking, the less IT support and dev capacity you
have, the more you should be using a “typical” OpenMRS distribution with as
little customization as you can manage.
The challenge for a distro like Bahmni is to let itself be installed,
managed, and supported as if it were a simple application. This is a
solvable problem, though, and generally I think that “run this VM” is
easier for the small clinic than “install OpenMRS + a variety of modules”.
I’m not opposed to building simplified OpenMRS module versions of what are
often external systems. And we should definitely do what we can to help
coordinate the efforts that people are trying in these areas.
But personally I think it’s a mistake to presume that “OpenMRS + lots of
modules” is going to be a simpler-to-manage solution to the problem of
“facility information system + EMR” than a distro that integrates multiple
systems, if that integrated solution is investing in making itself a
packaged product.