[mmkhd]

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?

[FLUX-YOU]

>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.

[mmkhd]

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.

[mrighele]

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).

[1] http://ihe-europe.net/

[x1798DE]

> 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.

[flukus]

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.