Live data from Hacker News

Open source software for developing world hospitals

hospitalrun.io

81–90 of 119 posts

Re: Open source software for developing world hospitals

#81
post #75
post #44

Sorry another story about my journey with my son while he battled cancer. Closed Proprietary image formats and systems HURTS patients. We used the local hospital for Chemo and everything else at the Children's Hospital 1.5 hours away for his legs and lungs. I would always have to wait 20-30 minutes to get a DVD of the studies (PET, CT Scan or MRI even ultrasound, but those are worthless) and then bring them to the do…

I'm shocked and also confused in reading this. Why? Because the standards are there! The ACR/NEMA standard dates back to 1985(!) and is nowadays known as DICOM. Here in Germany/Europe, the medical imaging systems as well as the archive systems (PACS) are designed to follow that standard. DICOM covers everything, from the exact flavour of lossless(!) image compression, to the metadata structure which covers fiels more…

Having worked with medical software, especially dicom: Where's the incentive?

I absolutely agree it's ridiculous when they don't follow the standard, but the appeal of vendor lock-in is just too much. I don't know how to change that, unfortunately.

The data flows down (Disclaimer: I am not an xray/mri/hospital tech in any way, and might be wrong): IME, there's not much "importing" of patient data into the medical devices, so there's no reason for vendors to play along. The data flows from the machine, to the dr/patient/whoever, so the vendor has the ability to dump it out in any format they want.

Re: Open source software for developing world hospitals

#82
post #28
post #9

Imagine if this got better than systems that are on offer when this requirement goes out to tender for the NHS institutes in the UK? So long as it doesn't do over night batching, it's already decades ahead. I wish I was joking.

Is it one of these things, that there are so many edge cases, regulations, domain knowledge involved that makes it perceived as too big to change? Because I'd believe that you can't just make something that looks better and sell like you'd sell a typical SaaS product, there must be tons of regulations. On other hand, while studying in the UK, I briefly met a PhD student who was making offline-first web apps to calcul…

A huge amount of the work is just making the software work for any given workflow or organizational structure. For perspective, Epic has a couple dozen people working full time on just the user management parts of their software.

Re: Open source software for developing world hospitals

#83
post #59

Earlier quoted context omitted.

I think it's too easy to blame proprietarism as such. It's a lack of universal sophistication in computer technology that makes designing systems living up to real medical concerns great efforts. When the "manufacturing techniques" of computer software is modernized, and enables more widespread implementation of these types of systems, proprietary formats simple won't be able to compete.

We know how to do this. Plenty of other industries have solved this problem. It takes organizational will to make it a priority.

That's not the point, the point is that the effort required makes it harder to innovate and that not only does that limit competition but it also enable proprietarism.

In a perfect world you could just e-mail the data without any concerns of authenticity, privacy, robustness etc. But you can't, so you would have to bring in a huge firm that is going to spend a lot of money and effort getting everything right or at least certified. Of course with all that effort they now have a huge incentive to keep thing proprietary since they want to recuperate their cost and the large barrier to entry make it even more advantageous because there will be little competition.

Innovation often requires COTS components to be available at a sufficient standard. No one would doubt this when it comes to something like AWS or how Tesla could make such a high level car in a relatively short time. Of course if you question the state of software you get downvoted into oblivion without reason on HN.

And if it wasn't clear, these (proprietary) systems very much exists.

Re: Open source software for developing world hospitals

#84
post #52

Nice project... here are my observations thus far - login screen takes several seconds to load - not usable on screens/mobile devices - seems like every click makes multiple server requests (and loads for up to several seconds) Also, would like to hear your thoughts on building a new system vs building on top of the many available open source medical systems.

> Also, would like to hear your thoughts on building a new system vs building on top of the many available open source medical systems.

Thanks for asking. I'm sorry in advance that this reply is lengthy. I'll try to be succinct.

Starting HospitalRun in 2014 was a very intentional, deeply-considered decision on our part, made after reviewing a wide spectrum of the available open source and commercial solutions for our network of developing world charitable hospitals at CURE International.

We simply couldn't find a solution that we felt could both meet our requirements and be successfully deployed across our network. So without saying anything for or against other health system projects from the past or present, I'll say that the following were the driving factors for the decision to build HospitalRun.

1) Taking usability very seriously. For us, that doesn't just mean UX and clinical usability or even just administrative usability (since there's a lot more than just the doctors we're trying to serve). It also means easy to setup, easy to administer, and (and we're definitely not there yet) easy to contribute code. A developer is already doing A TON for a project like this by absorbing a totally unfamiliar set of business requirements. We want to make the experience of contributing to HospitalRun delightful. Like I said, that's aspirational - not reality yet... but that's part of what we think "1.0" looks like.

2) Architecture choices: we're committed to modern, cloud solutions while working in environments where Internet access is unreliable at best. Additionally, deployment devices need to be not just low cost but easy to setup and remotely manageable. In practice, we're deploying our early releases of HospitalRun with a small cloud instance paired with a local souped-up Mac mini with a battery backup. CouchDB gives us replication for free and some DNS magic makes it possible for a client device to never need to know if they're in the network or out on the Internet.

3) Offline access to data in a web browser: Again, we're working in areas where Internet reliability is sketchy at best, so beyond the architecture, we wanted to create a portion of the app that works EVEN when there's no connectivity at all. That's where PouchDB comes in. The offline piece still needs a lot of work, but we get syncing, etc more or less "for free" b/c of the great work in PouchDB . The objective is to create the ability for clinicians to carry records into the field, even when they can't connect. This is a real-world requirement from our hospitals that I saw first-hand back in 2011 and inspired us to create both HospitalRun and a previous research database (still in use today) throughout the CURE International network. (ref: https://blog.newrelic.com/2013/11/19/cure-uganda-improving-c...)

4) It's more than just software. We have a goal of codifying the implementation process, and equipping people who want to deploy the solution for a given hospital with the tools to make their volunteerism effective and meaningful as well as the facility successful. Again, that's an aspirational goal.

5) Real-life customers. HospitalRun has an advantage of being an open source project that is being sponsored by charitable network of hospitals in the developing world, seeking to provide the highest quality surgical care to some of the least served populations. Many of the core team members are interacting with real people who are colleagues, which we generally all agree is good for the requirements process. Together, we're trying to build a solution that not only meets the needs of those hospitals but (hopefully) hundreds or thousands more across the majority world.

It's important to underscore that HospitalRun is not at a 1.0 release yet. We have modules of the system deployed in several CURE hospitals, but there's a lot to do before we'd encourage people to deploy it.

Hopefully, exposure like this will help us meet the people, etc that get the project where we think it can, could, and needs to go for the children and families we serve at CURE as well as the thousands of other facilities across the majority/developing world who can be positively effected by it.

Btw, many of these points are found in a paper we wrote to respond to this line of questioning (b/c we asked ourselves the same question before pressing "start") http://goo.gl/NCJDnJ

Re: Open source software for developing world hospitals

#85
post #47

Looks great. Why such emphasis on "Ember"? Does the target audience really care what front-end framework is used?

I applaud the efforts taken here, more than I've ever done, and it looks good. But wasn't there big talk of Ember's (JavaScript's) poor(er) performance on Android devices recently? It seems like this tech would be prime for Android users. I don't know if the performance is bad from a usability standpoint or just a pure numbers via specs point of view.

Ember is an excellent choice for offline-first mobile applications, like this one, because Ember can manage more on the client side.

You're likely recalling the recent article on HN that showed Ember taking longer to download the first time vs. React on a mobile phone.

In a third-world offline hospital records app, the first time difference isn't especially important, and also it's more likely the hospital record keepers will use tablets, not phones.

Re: Open source software for developing world hospitals

#86
post #7

Looks like it's way more open source than the two "open source" school MIS systems I looked at, one had no code available, the other an old version dumped on github, but not linked from their main page until you signed up.

Could you link to them please as I work at an MIS company that moved from open to closed source and wondering if our old codebase is still out there. This project looks good, but it does remind me of the issues with management systems for public services. With the level of requests we deal with from school users that "need" features to satisfy management/governors/government it makes it very hard to do open source an…

There's http://www.opensis.com/confirm and https://www.openemis.org/ although their commitment to the open source model seems lacking. OpenEMIS appears to be some well funded UNESCO project, but seems to have stalled, or gone in a new direction. OpenSIS has an out of date gitlab code dump, or a zip file for an english only later version. It's php, so the source is there, but not promising.

Re: Open source software for developing world hospitals

#87
I've been volunteering in hospitals in a developing country for a while now and the information systems they use here are really bad.

With an eye on replacing said information systems, I've had a look at the open source medical records / hospital management systems available. When I looked at the details these systems are often not great replacements. So you're replacing aging, poorly written information systems with aging / non user friendly / difficult to customise information systems.

I would like to suggest some things for you guys:

1. Instead of creating one large hospital management system from scratch, how about smaller systems that can be linked together? eg. patient records system / laboratory system / pharmacy dispensing system / billing system / etc. The systems I mention here have fairly minimal dependencies between each other. This gives you the time to create a best of breed system before moving onto other stuff. It also allows hospitals to be able to use your stuff without ripping out everything they already have!

2. Think about how a hospital would customise your system. New fields, forms, reports, workflows, logic, etc. And how these customisations would survive an upgrade of the core system.

Anyway, I hope you have success with the project and I wish you luck. I'll definitely be keeping an eye on it!

Re: Open source software for developing world hospitals

#88
post #44

Sorry another story about my journey with my son while he battled cancer. Closed Proprietary image formats and systems HURTS patients. We used the local hospital for Chemo and everything else at the Children's Hospital 1.5 hours away for his legs and lungs. I would always have to wait 20-30 minutes to get a DVD of the studies (PET, CT Scan or MRI even ultrasound, but those are worthless) and then bring them to the do…

I am sorry for your loss.

Really I have nothing else of value to add :-(

Re: Open source software for developing world hospitals

#90
post #44

Sorry another story about my journey with my son while he battled cancer. Closed Proprietary image formats and systems HURTS patients. We used the local hospital for Chemo and everything else at the Children's Hospital 1.5 hours away for his legs and lungs. I would always have to wait 20-30 minutes to get a DVD of the studies (PET, CT Scan or MRI even ultrasound, but those are worthless) and then bring them to the do…

There is no doubt in my mind that the standardization and openness of formats, especially in medicine, should be mandatory. Somebody I know, that work in procurement for a big hospital, explained to me how the manufactures of equipment play with this (in software and hardware) in order to capture the market. It's negligence by our legislators allow this kind of thing (I hope is negligence and not greed). Sorry for yo…

[deleted]
Post reply on HN