Hacker News new | comments | ask | show | jobs | submit login

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.

Responsive work is on the roadmap and coming soon. However, the current intent is for the project to be fully usable on tablets, but not necessarily on phones. The hospital staff in our use cases will all be using the software from either a laptop or tablet.

Understood. I'm on a laptop, and unless the window is full screen the UI isn't great.

Yeah, that's a fair criticism. Still a lot of work left to do on that effort.

> 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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact