
Open source software for developing world hospitals - daleharvey
http://hospitalrun.io/
======
baldfat
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 doctor. The doctor would be forced to
use whatever the portable image viewing program that came on the DVD and then
they had to be sent to the IT Department to be imported into their system.

We would be there to remove some horrible tumor but before half his surgeries
(I can't count how many surgeries he had) we would have to go in the day
before (3 hour round trip) to get the expensive scan done again. One time I
had a scan at 11 PM - Midnight and then drive home around 2 AM and be back at
the hospital at 7 AM check in for a 10 hour surgery. ALL BECAUSE THE FORMATS
ARE CLOSED and SYSTEMS could not connect so that my son's records were all the
same every where. I carried 20 DVDs with me all the time just in case.

In case you are wondering my son unfortunately passed away after almost 5
years of fighting. If you are ever interested in giving to a cancer society
please consider stbaldricks.org. Most charities give 0% or 2% to pediatric
research and that is why we went over 20 years without a new chemo for
children till last year, which St Baldrick's funded the research for this
amazing new drug to fight a different type of cancer my son did not have.

~~~
vog
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 than you ever need to describe the patient,
up to the archiving of data. There are even Free Software / Open Source
clients which do a great job in visualizing those datasets (OsiriX is a well
known example).

I thought that this is an international standard. How can any hospital afford
to buy crap medical devices that don't care about such an important 30-year
old standard?

Did I get something wrong about DICOM?

~~~
acveilleux
Until the early 2000s, DICOM was often an expensive option. Especially in
"single vendor" shops where all hardware was from $VENDOR. BTW, the euro
player were also fond of this.

Even with DICOM, not all encodings (either low-level, like value
representations, or high-level like transfer syntaxes and image compression
algorithms) are supported by all viewers/PACS.

Finally, every system assign patients their own local ID and does their own
local numbering/coding for precedure IDs and so on. This adds delays and work
when loading foreign images into a PACS.

I won't get into the bugs. I work in the field and I've seen some low-level
DICOM handling functions riddled with quirks, exceptions and work-arounds for
buggy imaging machines. With all that, we still see images that are utterly
broken and only openable in the original system.

When doing the transfer over a network, it's often possible to negotiate down
to explicit VR and Big-Endian uncompressed images which is required to be
implemented and gets workable (if large, 500+MB for CT) images. With a CD/DVD,
you're at the mercy of whatever syntax the creating device felt like using.

If you include PET and similar, then you also need proprietary PET/CT or
PET/MR fusion software to actually make use of the images.

------
radoslawc
That reminded me about story my friend told me some time ago. He's IT
specialist in hospital, they were having some problems with x-ray machine with
server based on windows XP and thin clients as viewing stations. Eventually it
was replaced with debian based workstations and haven't look back ever since.
After this he told me about interesting case with it, there was patient
complaining about middle foot pains, on previous setup x-ray photos showed
nothing, after switching to debian workstations they were using aeskulap dicom
viever
([http://aeskulap.nongnu.org/index.html](http://aeskulap.nongnu.org/index.html))
which had more adjustments for viewing those files, like hue, saturation,
color and so on, so after opening those photos with aeskulap and fiddling a
bit with parameters it clearly showed that patient has broken bone in foot but
in unweighted position it was almost invisible line on black and white default
viewer.

~~~
irremediable
Stuff like this shows the gulf between research and clinical practice. I'm
doing a PhD in medical imaging, and we have carte blanche to run whatever we
want. We generate a lot of amazing visualisations.

But almost all hospitals are stuck running out-of-date software that wasn't
even good when it was released.

~~~
phodo
How does a healthcare system or private clinic acquire such software? What is
the solution? Are the bottlenecks monetary, political, access?

~~~
irremediable
Good questions, and I don't claim to fully know the answers.

Some such software is released open-source, e.g. NifTK, FSL, MedINRIA. Some is
spun out and then sold through vendors as a service, e.g. Siemens, icoMetrix,
many others.

Why aren't things used more? I'd say the main bottlenecks are monetary,
political and cultural. Doctors are often set in their ways, and hospital
management staff are risk-averse. Moreover, because of legal liability issues,
a lot of this stuff has not been formally approved for clinical use -- so
hospitals won't touch it. This is especially true of the open-source software.
Getting approved is an expensive and time-consuming process. Service contracts
with approved software are expensive, mostly as a result of this.

Heck, look at the struggle involved in digital patient records, which is
supposedly a simpler problem than imaging. In the UK, we've spent billions on
that without getting anything usable. There are uniquely bad political reasons
for that, but it's illustrative nonetheless.

------
melbourne_mat
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!

~~~
zkirill
This comment should be at the top. I love what this project is aiming to
accomplish but also think that the task is gargantuan and the project's users
would be better served if it was divided into independent modules.

------
UserRights
[https://en.wikipedia.org/wiki/List_of_open-
source_health_sof...](https://en.wikipedia.org/wiki/List_of_open-
source_health_software)

Please avoid too much diversification by reinventing wheels, instead please
contribute to one of these projects.

Mobile first is a basic requirement in developing countries.

~~~
jglovier
>Mobile first is a basic requirement in developing countries.

When you say "mobile first is a basic requirement" you're thinking about a
specific context of software intended for the general population of people in
those countries.

However, with projects like HospitalRun, the general population is not the
audience, Hospital staff and administrators are, and even in developing
countries they still primarily use laptops and tablets at the Hospital.

~~~
rattray
Agreed. For them, offline-first is very likely to be more important.

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

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

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

------
Maarten88
This is a great initiative, I logged in the beta and tried a few things, which
mostly worked, although somewhat slow. Probably a lot of hospital
administrators active now :-)

What surprised me most is that the UI does not seem to be mobile responsive,
and does not work well on smartphones. I would have guessed that in developing
countries mobile use would be hugely important?

~~~
dublinclontarf
Are they likely to have smart-phones to use?

~~~
iends
I just spent a week in La Gonave, Haiti. Everybody had smart phones...which
was particularly impressive because electricity is hard to come by.

~~~
NetStrikeForce
That's precisely why - You don't need 5 hours of electricity to get 5 hours of
use on your smartphone, but you do need constant juice for a desktop PC.

A laptop would also give you more time, but not as much as a smartphone.

------
diptanu
How does this compare to OpenMRS? Hospitals because they have to obey a lot of
goverment regulations needs to customize a lot of things, records and
reporting so we did a lot of work around the plugin architecture in OpenMRS,
does this have similar extension mechanisms too?

------
paulojreis
I'd be very, very happy to contribute to this.

It seems you have a nice focus in usability - efficacy, efficiency and
satisfaction. For me, it seems vital to make IT useful and not a burden,
reducing clinicians wasted time on non-clinical duties and their general
_distaste_ with the software they have to use. I'm a UX PhD, I have experience
working with very particular groups of users, and I would be very motivated in
working for better healthcare.

~~~
sanotehu
Amen. As a doctor I have to deal with a lot of crappy computer interfaces.
Data entry in hospitals (at least the sort that gets the hospitals money) ends
up being done by non-medical personnel because the medical personnel are too
busy trying to do their job to care whether they coded something wrong on the
computer system.

------
DadFoundMy
At quick glance this seems to be fantastic! Software like this is what brings
out the great nature of open source. This project reminds me of the eye
tracking system that gained popularity a few weeks ago.

EDIT: Here's a link to the referred to project
[https://github.com/OptiKey/OptiKey/wiki](https://github.com/OptiKey/OptiKey/wiki)

~~~
traduz
That was the first thing that came to my mind after reading this. I was at
reddit when the author of OptiKey posted it, the responses were amazing.

------
guatebus
While I don't agree with many of the specifics of the HL7 spec[1], I guess the
community behind this project should decide if this system will conform or
not.

[1]
[http://www.hl7.org/implement/standards/](http://www.hl7.org/implement/standards/)

~~~
cmiles74
IMHO, the HL7 specification isn't particularly strong. Different vendors
support different message types, some vendors fill in this field, some
another. Most of the work I did with HL7 was making sure System A could read
the messages we were passing it from System B by "translating" the HL7
messages.

That said, there are open HL7 message "interface engines" and integrating with
something like Mirth[0] shouldn't be too difficult.

[0] [https://www.mirth.com/Products-and-Services/Mirth-
Connect](https://www.mirth.com/Products-and-Services/Mirth-Connect)

------
dubcanada
I can't seem to login, I enter the doctor username and password press submit
and it refreshes the page and nothing shows.

~~~
thirdsun
Same here - suspected a problem with my iOS content blocker, but that doesn't
seem to be the case.

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

~~~
gedrap
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 calculate the dosage of the medicine etc and
hospitals in the UK where actually using them (and paying him to develop).

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

------
mtgx
They should look into these technologies to better protect patients data:

[http://research.microsoft.com/pubs/258435/ManualHE.pdf](http://research.microsoft.com/pubs/258435/ManualHE.pdf)

[https://css.csail.mit.edu/cryptdb/](https://css.csail.mit.edu/cryptdb/)

[https://css.csail.mit.edu/mylar/](https://css.csail.mit.edu/mylar/)

------
siculars
I worked in this space for a very long time. Here are my thoughts on health
data integration [0]. In a nutshell:

"At it's core the government need only do one thing to encourage innovation in
the interoperability space and it is this:

The government, by means of regulation and incentive, ensure that any vendor
of data systems that create or store data make adequate interoperability
features and documentation available for said system.

I call this the Core Mandate. The core mandate must be unequivocal with no
loopholes. What do I mean by "interoperability features"? Simply:

\- If a system creates data, the ability to read that data is fully described
in documentation.

\- If a system stores data, the vendor will provide an API and/or SDK, with
accompanying documentation, such that authenticated requests may create, read,
update or delete that data programmatically as appropriate.

A system is defined as any software application or hardware device."

[0] [http://siculars.posthaven.com/health-data-integration-
regula...](http://siculars.posthaven.com/health-data-integration-regulation-
and-incentivization)

------
burrox
Ohh wow this looks very nice. Unfortunately I can't login for some reason.

So I am actually finishing the development of a similar system for a group of
anesthesiologists that needed a custom app to keep track of their patients and
their pain medication.

Had I known of this project before I would have actually considered
contributing/forking it to handle their use cases. See this hits pretty close
home since I'm Colombian and hospitals here have terribly outdated systems.

I love the idea of the app working offline and syncing when internet is
available since mobile networks here aren't verye reliable. One problem is,as
others have mentioned, having it work on mobile is very important. I don't
think it really is because of lack of PCs and desktops it's just that doctors
are always running all over the place and it's more convienent for them to log
the information on a smartphone/tablet.

Anyways my next project is also on the medical field and will have a wider
scope so I'll keep an eye on this project for when the time comes, I'd love to
contribute eventually.

------
daleharvey
Quite proud to see PouchDB being used for things like this, it looks like
pretty much a perfect use case.

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

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

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

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

------
sidcool
Great effort. A similar open source campaign is being run under OpenMRS,
called Bahmni ([http://www.bahmni.org/](http://www.bahmni.org/))

------
mathiasrw
I like the "Why HospitalRun?" at the bottom of the link...

[https://docs.google.com/document/d/1OhlxZY__spF_3ZnXLd5ga9vO...](https://docs.google.com/document/d/1OhlxZY__spF_3ZnXLd5ga9vOdX9xNqHGUASdVxAdLLc/preview#)

------
privong
I'm not in this area, so I don't know much about it, but can anyone compare
this with GNUHealth[0]? At first glance, they seem to be trying to do many of
the same things.

[0] [http://health.gnu.org/](http://health.gnu.org/)

------
solankv1
First off, I would like to say this is exactly the kind of thing that has the
potential to have a monumental impact on global healthcare, not just in the
developing world. We could definitely do with this type of initiative in the
UK.

The reality is that some of the biggest vendors (US and UK based) actually
ship some of the worst software and charge hundreds of millions of pounds for
it. Ultimately, its the patients that pay the price. It's a complete myth that
bigger vendors build safer systems.

I agree with a previous poster in that given more visibility, I'm sure there
are thousands of developers that would love to contribute to this type of
project (myself included).

It's also pretty clear that mobile will be a key requirement for this type of
solution. Not just a responsive website but full native implementations. I
realise that this can be expensive, but if it's open source, I'm sure there
are developers that would love to get involved. Maybe you would consider an
API? This might encourage an ecosystem of client solutions to flourish.

Finally, do you think there is a role for a patient login here? There is a
world-wide movement to encourage patients to play a more active role in
managing their healthcare and giving patients mobile access to their health
records is a great first step towards this.

------
nickysielicki
Anyone else remember this CVE? Open (eg: passwordless) telnet on a blood
infuser.

[http://webcache.googleusercontent.com/search?q=cache:3ygj10u...](http://webcache.googleusercontent.com/search?q=cache:3ygj10uTWqYJ:https://web.nvd.nist.gov/view/vuln/detail%3FvulnId%3DCVE-2015-3459+&cd=1&hl=en&ct=clnk&gl=us)

------
martijn_himself
This is great. I recently had to create a prototype application for a charity
with offices in a developing country and this would have been a perfect fit. I
don't have access to GitHub at the moment but I wonder how far along their
implementation of the 'off-line first' sync mechanism is, this is a non-
trivial thing to implement.

I had a quick look at the demo and it looks like the development is in the
early stages- a bit of (hopefully constructive) feedback: I think they (you?)
may be trying to attempt to do (and cover) too many clinical disciplines at
the same time- maybe implement individual modules (like patient registration)
and test them in all (old!) browsers in more detail before moving on to the
next. Also think long and hard about how you implement your data model
(clinical indicators e.g. blood pressure often have a context and are temporal
values, how do you model these?). This is a great effort and has lots of
potential.

EDIT: also, the name seems to suggest to me like there is a run on hospitals-
but that may be a personal thing.

~~~
daleharvey
> I wonder how far along their implementation of the 'off-line first' sync
> mechanism is, this is a non-trivial thing to implement.

The are using PouchDB + CouchDB for offline first / syncing which is how I
came to notice it (I am a maintainer for PouchDB). So their ability to sync
should be reliable and well tested and if not then its bugs for us to fix :)

~~~
nrjames
We recently used Kobo Toolbox
([http://www.kobotoolbox.org](http://www.kobotoolbox.org)) for a health
related survey in a developing country... The Ministry of Health required the
data stored locally to be encrypted on the device and during sync (not just
over https), which caused some problems for deployment. That will be an
absolute requirement from any gov that looks to adopt the tech. Not sure if it
was a PouchDB or Kobo shortcoming.

~~~
daleharvey
I am not certain Kobo uses PouchDB, I dont remember seeing them mentioned, but
its certainly possible to encrypt data that is synced with Pouch/CouchDB.
Heres 2 projects (both written by Pouch maintainers) to help do that.

[https://github.com/calvinmetcalf/crypto-
pouch](https://github.com/calvinmetcalf/crypto-pouch)
[https://github.com/nolanlawson/transform-
pouch](https://github.com/nolanlawson/transform-pouch)

------
pjmlp
While this is a good idea, how are the health compliance requirements
enforced?

~~~
frabcus
I'm struggling to understand the question - by testing for compliance like
other software?

I'm assuming there'd need to be a services business installing and maintaining
the software, and adding improvements particular customers need.

~~~
datenwolf
> I'm struggling to understand the question - by testing for compliance like
> other software?

Medical software is a different beast, compared to, say, your next online shop
or bloggin plattform.

Bugs in medical software can (and will) kill people. My work takes me to
medical software development courses on a regular base and they usually
consist of looking at the ways, medical software can kill people; sadly often
enough by example.

One case for example was a PACS system where due to a bug in the way the
database managed timestamps only the very first of a series of pictures was
shown to the user. And since once could not navigate the pictures via
"previous" and "next", but one always had to go through a purely text based
menu (this was in the mid 1990-ies, where memory was scarse) it was not
immediately apparent that only the first image in a time series was shown.
Enter the patient with a tumor; when it was finally realized the images the
medtech took were not the same the specialist saw it was already too late for
the patient and tumor growth progression too far advanced.

So your medical database software kills someone (prescription error due to
wrong dataset shown or such), how do you determine whose liability it is/was?
Medical software certification is in large part about identifying what harms
to a patient could be done and which parts of the software may cause it. You
don't even rule out in a "this can't happen" way, but it goes like:

\- patient dies: no matter how well it was tested, these are the possible
offenders in the program \- patient gets seriously harmed: no matter how well
it was tested, these are the possible offenders in the program \- patient gets
injured: no matter how well it was tested, these are the possible offenders in
the program

The bottom line is you're ending up with something that is either close to or
outright is waterfall.

And even more important: These are the components a program uses, what
possible failure modes are there that could harm patients. So they're using
CouchDB? Well, is CouchDB medically certified (AFAIK not), so this is
considered SOUP (Software Of Unknown Pedigree) which means that to legally use
this in medical applications you have to certify the SOUP yourself.

Oh and putting medical records into the Cloud? What could possibly go wrong…

~~~
lifeisstillgood
From my perspective, this is not "don't use FOSS in medical situations" but
"ensure the SDLC and code base meet requirements"

Unless we are talking foolish regulation, FOSS backed by taxpayer development
money is likely to produce better and more open, transparent and testable code
than proprietary companies competing against each other.

Government regulation perhaps should focus on building automated test suites
as a first high level bar.

------
daveguy
A somewhat related commentary article on why electronic health records (EHR)
are difficult to work with: they are focused on billing not patient care.
Doctors would prefer a care-oriented system. This could be a great inroad for
open source.

~~~
daveguy
Now with actual link: [http://www.cio.com/article/3011576/ehr/why-electronic-
health...](http://www.cio.com/article/3011576/ehr/why-electronic-health-
records-arent-more-usable.html)

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

~~~
morelikeborelax
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 and be suitable.

~~~
castell
You seem not to understand what open source means. Code released to the public
under common free open source licenses mean someone can fork the code and put
it on Github any time. If the company chooses to close source further
development, then it's their unfortunate choice, nevertheless already released
older open sourced code will stay open source.

~~~
morelikeborelax
Ahh, you misunderstood me. It was open source many years ago and that body of
code doesn't seem to exist anywhere now.

Things have long moved on from that period, but a few of us are just curious
to see if the code is still around from that time or if our product is one
mavhc was talking about (unlikely).

------
srameshc
This is a great initiative and I hope entire world adopts to such open
standards for patient record management which can be freely transferable to
other hospitals/doctors when needed or when approved by patients.

------
Coxa
Just after a first glance this looks really interesting! Brilliant idea.

------
aayala
Anybody remember Care2x ?

------
hienchu
Why is it so similar to codio.com homepage?

~~~
jglovier
Because design patterns, basically. I designed this page and have never seen
codio.com before so I'd say it's just a reflection of common design paradigms
for marketing pages.

------
andrewclunn
This can only be done in developing markets because the health privacy
regulations and mandatory screening laws cripple the ability of the Western
medical industry to adopt open source solutions.

