Constructive feedback: this sentence should really be worked into the first line of text: "It covers the functionality of Electronic Medical Record (EMR), Hospital Management, and Health Information System (HIS)."
As of now, one has to scroll/read for a bit before learning what the project actually does.
It's intentional. The more buzzwords and vague ideas you can flout, without committing to anything in particular, the wider the audience. Just like politics.
Except I'm busy and don't have time to decipher what you do, so I'll bounce and find someone that can clearly articulate their service and how it helps me.
It's a little disappointing, usually software that's part of the GNU project is really good about this. This website looks more "designed" rather than someone typing something up in vim (or Emacs) just to give people a landing page/description/links.
Not to mention the design has an uncomfortably political slant. Why is the front graphic a bunch of "take the power back" fists raised in the air? They seem to be saying, "don't use our software unless you identify as Revolucionario anticapitalista"
Reading in the other comments how the screenshots indicate this is a repackaging of "Tryton", a fork of OpenERP, it leads me to wonder if these people are just co-opting the GNU name to advance tired meatspace politics (ala libreboot).
I'm sorry but you are missing a huge part of what GNU is about. It is explicitly about "meatspace politics" and the philosophies of Richard Stallman. Explicitly you seem to be confusing "open source software" with "free software":
I'm sorry but you are missing a huge part of what GNU is about.
No, I don't think I am. GNU supports building businesses on free software. That's why the GPL does not say "free for noncommercial use only" like many other licenses. It's meant to be sustainable.
Using iconography that says "businesses are bad, uprisings in the street are good" is counter to the GNU mission.
Perhaps it is because GNU Health doesn't really take the power back. It appears to entrench doctors rather than empowering individuals, which seems to be the opposite of what GNU typically does.
Yeah, it takes a bit of scrolling, kinda like the other EMR/HIS software that was on HN last week[1].
At the very least it isn't locked to CentOS 6.7 specifically, but GNU Health & Bahmni will likely never displace Epic or the other major players due to HIPPA & PCI/DSS compliance requirements, the latter of which causes most merchant processing platforms (like First Data) to outright reject any libre or shared source commerce system looking to integrate with them for payment processing.
See also http://hospitalrun.io as an example of a pretty substantial open source effort. They're funded by a nonprofit (https://cure.org) that operates charitable hospitals throughout the developing world.
The app itself is fully offline-capable and pretty neat.
This feels very rough around the edges, especially for a project with several releases. The documentation is very uneven and sparse, with certain sections like accounting, administration, etc having no documentation at all. Security is suspect even out of the box, with demo users added by default. Other problems are that you need to restart the server if you add a language package, a short support cycle -- two years is a tiny length of time for things like health care, synchronization is not real-time, etc. Yes, it's interesting in that it is open source, but I would very much not want to have to support this in production, it's just too admin and user unfriendly.
It's 8 years old. That's not a young project. Even a project like this that's 2-3 years old should have significantly better documentation. Bad documentation in any project should be treated as a bug.
>>> Tryton has taken a wildly different path than it's ancestor OpenERP
Could you elaborate ? I'm interested in knowing what are the differences, business wise (I think Odoo is now on the web and Tryton is not, but that's superficial for me)
Tryton's fork was motivated by disagreements on the technical and business directions.
1/ On technical side, both leaders had very different directions on lots of different details. The main one being: Odoo moved to the web, Tryton was attached to the GTK/rich client.
2/ On the business side (probably the biggest difference): Tryton had a purely community driven development approach (with an anti-commercial mindset of his initial community) and Odoo's goal is to build a great open source product but sustain that with a strong business model (for partners and Odoo Inc).
The Tryton founders were 2 ex-employees of Odoo back in 2008 before the fork. Odoo had 5 employees at that time. (66% of the devs left to work on a fork :)
Note that there are also medical apps on Odoo. GNU Health started as an Odoo Projects, some of their leaders moved to Tryton and others continued on Odoo. We deployed Odoo is several hospitals, and 3 of the top 5 medical NGOs worldwide run Odoo.
Beside other personal considerations, the main motivation was that we wanted to improve the quality of the codebase ( especially the data-model). There was no time and no wishes for that at the time, so we decided to leave TinyERP (the former name of OpenERP/Odoo) and do that ourselves.
(I'm one of the Tryton founder as you may have understood)
To be more precise about Tryton differences, it has both a desktop and a web client.
About the "anti-commercial mindset", indeed it is that the Tryton community does not allow lock-in mechanism into the project (at the opposite of Odoo with the business model of paying updates to new versions). But also it does not place a commercial entity as the center of the project but instead a non-profit Foundation.
"Odoo's goal is to build a great open source product", this is also the goal of Tryton project but everyone is free to choose its business model.
I implemented Odoo ERP's MRP capability for a supply chain stretching from Norway to Shenzen. It worked really good and we god transparency in our manufacturing process. We spent a lot of energy in making our production staff update the ERP as each phase of production was finalized, but in the end it was highly worth it. End result? 0 spreadsheets, almost maximum transparency. Improved Quality Process in production, more collaboration et cetera.
We also got a lot of value out of the other modules that almost magically comes out of the box :).
Completely unrelated to the ERP of course, the company is now out of business, but the website still remains http://bergesolutions.com
For all it's bloat and crappiness one thing that SAP provides is end to end process management. Want to process the bill with your banking provider and have that included in your tax returns automatically and plan the freeing of a bed with the emergency control room? Well SAP will do that (at a price and with consultancy). That's why SAP is what it is.
Hello World!!
This project should not be regarded as Hospital Information System (HIS) but as app for saving some clinical data.
This is not execlusive for GNU Health but for many other open source projects claiming that they provide HIS functionalities. Using the app demo I can confirm at least the following:
-missing the pharmacy module and instead provides very basic stock moves
-missing template designers for patient casesheet,lab and imaging investigations! How can we expect a Dentist or an ENT doctor to use the casesheet and what if a hospital has its own templates!
-missing workflow management for doctor orders,lab and imaging specialities
-missing Doctor module and provides some of its functions over unrelated screens
-missing the billing module and instead a simple and manual interface to ERP invoicing. This is crucial in any HIS in private and also public hospitals and why building upon an ERP framework if not utilising its accounting features!
-missing the inpatient (ward) module-the only thing i found is a (Hospitalised) check box!
-missing the contract management module(services,insurances,pricelists,..)
-missing the Equipment Interfacing for Lab and PACS interface for imaging(in fact lab and imaging modules are missing only investigation orders and results entry found)
I wonder if there is a good opportunity to fill this in with commercial services based around GNU Health? Billing for example, is very region specific.
Having done CSSD software I can safely say that it should be a stand alone product that could interact with GNU Health, it's way too complicated to just be module.
Looks like it's distributed under Apache 2.0, which means it's open source.
Whether they take contributions or not is not really relevant to open-sourceness -- under an appropriate license anyone can use the source to run their own project with whatever contribution policy they like -- but it looks like the main distributor is indeed open to contributions:
Interning at a pen testing company, they're always happy with hospitals and the like. "There's always plenty to be found there" I recently heard someone say. Usually you have to be on the internal network and that's why the state of affairs is that bad, but it's not like you are always accompanied by an employee while in the building.
I'd rather security increases than lowering costs, but ideally both of course. Maybe not even for myself: lower costs means being able to treat more people.
It seems like everything gets more expensive as of lately, not cheaper. So I wouldn't be surprised if they just pocketed the difference.
I seen on the news a few days ago that some hospitals are in network but the doctors there are out of network. Makes no sense. Seems like the medical industry is just one big money making the scheme. Doesn't even tell people the prices up front.
It's remarkable that the software comes with a FHIR server. Apparently there are a few features in the core module that are not mapped to FHIR resources.
I would love to see CCDA generation and interoperability support in there. Given the main purpose of helping healthcare in developing countries as stated in the wiki, I guess interop comes as a later step in the roadmap.
Please do not launch a me too foss/health service. There are I suspect hundreds, many of which are already OSS of some sort, and most of which stand a better chance of becoming the de facto platform in years to come.
We are past the point where a GNU sponsored project to rally around is useful.
You have won. You changed the entire landscape of computing Mr Stallman. You did it.
Focus on the new GOvernment digital services, lobby for the idea that all government funded software must must must be open and free.
GDS-style departments are affecting a lot of change, and the biggest ones are default-to-free and that is where I would like the FSF and gnu to focus.
It seems that healthcare is one space that would benefit greatly by open source collaboration yet this sector, at least in America, has demonstrated over the last 8 years during funding by the ACA that it largely refuses to do so. So, it's nice that GNU has its Health project but the people who would actually decide what technology to use have already crossed that bridge. They've used public funding to re-create the wheel a thousand times over.
The field of medical software is very different from everyday programming. You assume that somebody is lazily pocketing money. You are probably wrong.
Medical software is a highly regulated area and the software needs to be validated. There has to be proven documentation that the software functions correctly and does not endanger people or data. This is a good thing because we are dealing with sensitive privae information and the health of people.
Most hospitals and open source enthusiasts do not have the time, money and expertise to do these things. Thats why they buy software from vendors and probably let the vendors do some form of additional on-site validation.
It is very hard to "fail fast and fail often" in such an environment which makes development and improvment harder.
(And as an aside many corporations that do software validation do it in a braindead overly bureaucratic way and produce buggy software despite validation.)
One such standard that I find nicely executed and easy to understand ist GMAP5 https://en.wikipedia.org/wiki/Good_Automated_Manufacturing_P... Its methods work not only for automated manufacturing but can be applied to software development as well.
Edit:
It would be interesting to see more open source collaboration. Maybe you do not see it that much because all the people that have the expertise do not work for the hospitals but get snatched up by the vendors? Maybe you do not see that many start ups enering this sector because while individual contracts are lucrative there are fewer customers around than for consumer apps/products?
>There has to be proven documentation that the software functions correctly and does not endanger people or data.
Regulators are not sitting behind your engineers making sure every line of code is tested though. Documentation in this area would basically be QA documenting testing with pass/fail which is going to be similar in other enterprise projects with a QA department. You get functionality testing with, for example, prescription of controlled substances, but they are not reviewing the code for vulnerabilities or any sort of proof.
In more than one instance, I've seen updates from EMR vendors have needed hotfixes after they find some critical bug. This is pushed to production the next day so even if regulators were reviewing code, they couldn't review it that fast.
>Most hospitals and open source enthusiasts do not have the time, money and expertise to do these things.
The trouble for open source contributors is knowing what the demands of doctors/nurses are. Most EMRs have common functionality but workflows are incredibly varied between hospitals. This is not an industry where the software controls or teaches the workflow. Providers can and often ask for custom stuff built to handle their particular needs at the expense of the code base.
However, once you know these workflows, the code behind them is not that difficult technically for today's tools and methods.
The technical challenges facing certain EMRs today (that I have experience with) are really scaling issues. Most of the enterprise EMRs started a long time ago, so they are running into issues with bad design that needs patchwork fixes. Plus not blocking the UI thread for most operations.
Your coments about the application workflow are very true. And I think this strengthens my argument that it is hard for open source software to enter this market. The cosultants/companies that implement these systems for hospitals would have to get together to push open source. And I guess hat it would be very hard to find enough open source developers with the domain specific knowledge. This points to a development style with a single company behind such a software. These companies are often not as "open-sourcey" when it comes to documentation as "real" open source projects. And this would make it less interesting for the above mentioned consultants/companies to band together to push open source because only that single company that mainly develops the software and does consulting for it, would profit.
My comments on software validation were perhaps not as clear as I would have liked them to be. Of course the regulators are not looking at every line of code. It would have to be the buyer that would have to look at that documentation, so that everything is in order when an FDA inspection occurs (if at all). And maybe it is wishful thinking that the developers should take validation into account while developing, because you can only do so much with an operational/functional qualification on site.
Perhaps I am thinking that way because I am looking at it from the perspective of a research organization that develops some of its software in house (workflow!). Companies contracting with us certainly do want to see the validation documentation that was produced during development.
While not as much as I'd like, open source _is_ used in the healthcare sector, though usually not in safety-critical fields (an example that comes to my mind for example is HL7 messaging).
The main issue for more OSS is that for pure software-based solutions (i.e. not the software of a medical device), the biggest cost for an hospital is usually maintenance, not the license, since (obviously) the hospital will want someone responsible for any issue and ready to fix it right away.
This is a cost that is more difficult to share with others.
This is at least my experience with Italian public healthcare, which may be much different from the US market.
At least there is a lot of work on open protocols and interoperability [1], which is good because it can be another good way to reduce costs (by reducing lock-in).
> The main issue for more OSS is that for pure software-based solutions (i.e. not the software of a medical device), the biggest cost for an hospital is usually maintenance, not the license, since (obviously) the hospital will want someone responsible for any issue and ready to fix it right away. This is a cost that is more difficult to share with others.
That actually seems like it would make OSS more competitive, not less. The ability to sell services and maintenance contracts really lowers the barrier to open-sourcing your software. When the main thing that customers are buying is your company's expertise with the software, the barrier for releasing your software open source is much lower, and you can reap the benefits that come along with that.
Medical device programming may be different, but medical management systems like this are bog standard and don't have the same regulation. A lot of doctors offices and hospitals are running access and/or VB6 apps.
Does it run on Windows? The reason I am asking is that a practitioner or a hospital might be using Windows historically and may be wants to try this out rather than rebooting their infrastructure to Linux to try this?
It looks a bit messy to be honest. Would be nice if open source EHR's (this, Hospitalrun, some others) offered a good rest API to build web/mobile clients on top of.
I'm working on a clean, modern UI/UX front end for mobile/web EHR, will probably open source it. For the backend it would be nice to reuse something pretty good if it already exists.
FHIR is great. It's also a pretty complex data structure, but we use it internally and are generally happy with it. It has flaws, notably that it's not always clear what parameters to set on the resource (for example there are a bunch of different date fields that could mean similar things and could be set or not set depending on the implementation), but having a uniform data interchange format is pretty great for open source medical informatics.
Yes, it's as close to a standard as you can get. It delineates a data model for certain types of medical data and their transport but it itself is not a database.
So ... speaking as someone who a) supports the use of free software and open formats in all Government departments, and b) currently runs GNU/Linux ... is it just me or is the iconography on that page bordering on Communist?
Heh. It's also driven by the fact that my late mother was a Communist. That combined with my Libertarian leanings as an adult have led to me being extraordinarily sensitive to that style of political imagery.
Funny that a Vegan should be so into bullfighting and hunting.
... runs through Google Translate ...
Oh, right.
Fox hunting supports are "vile subhumans" apparently. I thought he was a socialist, not a fascist? He should just go the whole hog and use "untermenschen".
I don't see anything wrong with it. To me it just signals "stand together" which makes sense with the 'by the people for the people' theme. What does it have to do with a form of government?
How does this compare to VistA? (Well, one obvious example is this appears to be written in Python, whereas Vista is largely written in MUMPS; this I think uses PostgreSQL whereas VistA uses the MUMPS embedded database.)
There is a web client. You can test it at http://health.gnusolidario.org:8000/ with database: health30 Username: admin and password: gnusolidario
About the desktop client, ugly is a matter of taste but at least it is very efficient for intensive usage (like daily encoding)
As of now, one has to scroll/read for a bit before learning what the project actually does.