Epic and the other big medical software providers have this market on lockdown. I do not see a path to this seriously challenging the major players any time soon in the US, even though it could be done.
Additionally, the software dependencies (CentOS v6.7 & Java 7) that say breakage occurs with newer versions is very sketchy IMO, ignoring the HIPPA & PCI compliance work that needs to be done (the latter costs $40k a year to maintain).
True that. But the intention of building Bahmni is different. It's primary focus was to get the EMR for resource constrained (in terms of money, computer skilled people).
I was part of the team which build it for about an year and can definitely say it did change the medical eco-system in such places
They are adamant that it's a "HOSPITAL SYSTEM FOR LOW RESOURCE SETTINGS".
I'm familiar with another big medical software provider, and it's a cludgy mess, but it's all about the RFP and how the software can help in billing and meeting Meaning(ful|less) Use targets.
Same thing in germany: you won't get a hospital to use this, ever. Selling to hospitals is enterprise sales ^10 - we see sales cycles between 3 to 8 years (that is from initial lead to project delivery).
It might have a chance in developing countries with less regulation in place.
Google Deepmind is doing some great work with NHS in the UK, both on deep learning of medical images, but also on electronic health records (and mobile apps for doctors). What I've seen so far literally obliterates Epic user interface (which is not a high bar). But I'm not sure Google will open source the work, I think they will turn it into a profit stream. Still a win for doctors and taxpayers, less doctor time wasted fighting ancient software.
I've been working on something to help with data security. If your software project runs into PCI, HIPAA or other data security/compliance issues, we have a solution that can offload the risk and compliance work from your system without any code changes on your end. We have several customers using it in production and are profitable. If you're interested, my email is in my HN profile. I'd love to chat.
I am curious why so much needs to be done for HIPPA compliance anytime something is held in electronic form.
What if you have a computer, unconnected to the internet, simply sitting in a doctors office with billing information on it.... does this system need more 'protection' and regulation than the one it replaced of paper files, and sticky notes?
There are many layers of HIPAA outside of of just electronic data security. You must train your staff on security protocols (e.g not sniffing for celebrity records, etc).
I am pretty sure even if your office is all paper charts you still fall under certain HIPAA guidelines such as notifying patients if there was a breach (e.g physically stealing records from the office). This happened in Rocklin, CA a few years ago.
One of the major EHR systems used in the United States, VISTa, was developed by the Veteran's Administration and is open source. It's sufficiently successful that it's been adopted not just by other government agencies but a number of private hospitals. Most instances still seem to be based on a commercial M implementation, but some use the fully free GT.M stack
It's M based and in general not on the cutting edge of technology, but it's long service life has shown that it fits the need. I've worked with it once at the Indian Health Service and while not exactly Web 2.0 it is quite powerful and familiar to the staff there.
Just to provide an additional data point, a family member who is a physician and previously used this system before his workplace switched to one of the proprietary private alternatives still occasionally laments on how good it was in comparison.
But the datastore itself reminds me of some of those early NoSQL object stores. It isn't JSON, but you can throw anything in there and get it back -- pretty efficiently!
It's hard to table-ize a lot of clinical data - at least with a standard/universal table. GT.M gives you a solid enterprise quality way to store "stuff".
Getting US hospitals to use your software is super hard. Majority of them are using Epic, and won't entertain you much if you don't provide Epic integration. And Epic is almost a closed system, they've done their best to make sure that integration with them is almost impossible for small companies.
The thing that pisses me off about HIPAA and startups is the cost of being HIPAA compliant! You must run on dedicated instances. So your AWS bill is minimal thousands of dollars and that's just the start!
Sure there are starts doing HIPAA compliant IaaS but Paying $99 for 1 GB container is still pricey.
The first implementation of Bahmni took place at Jan Swasthya Sahyog (JSS), a hospital that has been instrumental in pioneering this open source work. Bahmni is named after a village 70km north of the small town of Bilaspur, India where one of three village health centers of JSS hospital is located. The work being done by JSS at Bahmni village is very inspirational to us and hence the name was chosen.
As a Medical Doc and a health tech entrepreneur current living in Bilaspur. I find this fascinating. But I think the village where JSS is located is called as Ganiyari ??
This is one of the great products I have friends working on. ThoughtWorks has a big team working on this product. It's amazing to see it working well in so many countries.
Please give examples of how this is working well in other countries with case studies. It does not appear to be a technically innovative product, just bundling of some open-source products together.
Very proud of this product. The target is not the US domestic market, but developing areas that have no resources for electronic health records. I have seen this being implemented places where the traditional software would be cost prohibitive.
Good for humanity. Please contribute patches!
There is no way this will be successful in the US specifically because it's based in India which hospitals in the US are extremely resistant to.
Also, it looks exactly like Epic and now I understand why they are so careful with their Intellectual Property.
Thanks for that bit. We are working on an integration project with Epic, but I've never really even seen it.
(Epic throws some SOAP data at us, then we pop up a sub-view of a web app with a form to complete which Epic puts in a frame or something like a frame)
Bahmni isn't meant for US hospitals. It can't compete with biggies like Epic for the US markets, and neither does it want to do that. It's meant for low resource settings and places which can't afford expensive softwares like these. Check out their client list: http://bahmni.org/implementations/
Quite similar to OpenMRS philosophy. Fully open source. AGPL.
I wonder if a hospital can really use an open source hospital information system for several years without the need to change much of the workflow to the point where modifying it will make it impossible to update from the its original source.
One of the key things about Bahmni that differentiates it is that most of the EMR screens / fields in Bahmni are configurable via JSON / Administrator UI. You don't need to fork / code / branch to make these changes. In some places you can also change the order in which screens get rendered via configuration. So, your Bahmni config stays separate from the "product", which allows you to upgrade and get new features without having to manage your own version of Bahmni. All you need to manage is the metadata.
Additionally, the software dependencies (CentOS v6.7 & Java 7) that say breakage occurs with newer versions is very sketchy IMO, ignoring the HIPPA & PCI compliance work that needs to be done (the latter costs $40k a year to maintain).