Health IT

<i>From our technical staff</i>The problem with CMS systems is they are designed to be online all the time. I would think a "queued" intranet infrastructure would better support main
systems. For example, if the CMS generated an email, the mail server would
accept the message, queue it, and send it once the internet was available.
Moving forward, any additional applications could rely on this "queued" infrastructure.

Hi Oliver,

Thanks for the message. It's useful to hear what other organizations are
using, given that we have been struggling with all the same problems in
Nepal.

A brief overview of our system:
-Email: Gmail-based system that also utilizes an organization-wide Gmail
archive that is open-access to everyone (so that everyone can read all org
business to stay up to date etc)

-Wiki: has been crucial for maintaining intra-org communication at a
low-bandwidth. http://wiki.nyayahealth.org/

-Documents: Google Docs -- mixture of both publicly-accessible and private
docs depending on confidentiality etc

-Protocols: Evernote -- as you say Oliver, this has been crucial for us in
terms of updating docs offline, sync'ing later on etc -- the low-bandwidth
desktop client is especially useful for our Nepal team

-Other files: Windows LiveSync -- has been very useful for maintaining org
online hard drive so to speak -- helps with organizational memory and
documentation (everything from old grants to MOUs etc)

-Major bottlenecks / implementation problems:
-Electricity -- our internet satellite dish is currently dependent upon a
rather unreliable electricity grid. When the electricity goes out, not only
can we not use the internet, but we also quickly run out of laptop battery
power. Currently working ...

Hi Oliver,

Thanks for the message. It's useful to hear what other organizations are
using, given that we have been struggling with all the same problems in
Nepal.

A brief overview of our system:
-Email: Gmail-based system that also utilizes an organization-wide Gmail
archive that is open-access to everyone (so that everyone can read all org
business to stay up to date etc)

-Wiki: has been crucial for maintaining intra-org communication at a
low-bandwidth. http://wiki.nyayahealth.org/

-Documents: Google Docs -- mixture of both publicly-accessible and private
docs depending on confidentiality etc

-Protocols: Evernote -- as you say Oliver, this has been crucial for us in
terms of updating docs offline, sync'ing later on etc -- the low-bandwidth
desktop client is especially useful for our Nepal team

-Other files: Windows LiveSync -- has been very useful for maintaining org
online hard drive so to speak -- helps with organizational memory and
documentation (everything from old grants to MOUs etc)

-Major bottlenecks / implementation problems:
-Electricity -- our internet satellite dish is currently dependent upon a
rather unreliable electricity grid. When the electricity goes out, not only
can we not use the internet, but we also quickly run out of laptop battery
power. Currently working to shift entirely to solar energy to circumvent
energy problems.

Thanks once again for starting this discussion. Looking forward to hearing
others' thoughts about ways to improve these nascent systems.
Cheers, -Dan

--
Dan Schwarz
Alpert School of Medicine | Brown University
Harvard School of Public Health

Executive Director | Nyaya Health
http://www.nyayahealth.org

I'm interested in innovations that can tackle the problem of limited bandwidth or unreliable connectivity. I like message queuing architectures that enable asynchronous communications.

One key challenge is figuring out how to interconnect and manage sub-networks of clinics in remote third-world regions where there is no guarantee of reliable connectivity to the broader internet.

Lightweight, open-source grid management tools can perhaps automate remote system administration in such environments. What are the best tools for automating IT support - i.e. remotely deploying OS patches, applications/upgrades?

I'm working on a project involving small clinics operating on-site at dive resorts/casinos in remote third-world areas so that tourists have access to their health records and remote consultations - via intermittent, asynchronous communications if necessary. Several cruise lines are interested in using this type of solution.

The systems within the local intranets will be offline most of the time, with only intermittent, low-bandwidth connectivity to the internet. There will be no onsite tech support.

Our top priority is finding a good open-source synchronization framework that can replicate files or other finer-grained patient health data across unreliable connections using asynchronous message queuing protocols. It requires a stable yet flexible canonical health information model ...

I'm interested in innovations that can tackle the problem of limited bandwidth or unreliable connectivity. I like message queuing architectures that enable asynchronous communications.

One key challenge is figuring out how to interconnect and manage sub-networks of clinics in remote third-world regions where there is no guarantee of reliable connectivity to the broader internet.

Lightweight, open-source grid management tools can perhaps automate remote system administration in such environments. What are the best tools for automating IT support - i.e. remotely deploying OS patches, applications/upgrades?

I'm working on a project involving small clinics operating on-site at dive resorts/casinos in remote third-world areas so that tourists have access to their health records and remote consultations - via intermittent, asynchronous communications if necessary. Several cruise lines are interested in using this type of solution.

The systems within the local intranets will be offline most of the time, with only intermittent, low-bandwidth connectivity to the internet. There will be no onsite tech support.

Our top priority is finding a good open-source synchronization framework that can replicate files or other finer-grained patient health data across unreliable connections using asynchronous message queuing protocols. It requires a stable yet flexible canonical health information model that is not based on HL7. The solution needs to enforce fine-grained authorization and role-based access control on the detailed health information using an open standards-based permissions model.

All technologies need to be 100% open-source for security reasons, but not necessarily free. A dependable and financially sustainable support infrastructure for the tools is more important.

I don't have much to add to this conversation except to comment that I use dropbox as a way to synchronize files between different users and it has worked well in settings where I have intermittent internet signal. The system works by keeping local copies of the files across all computers and synchronizing them when there is an internet connection, so that you don't have to be online to have access to the file.

Joaquin

I agree with Heather, and taking advantage if the asynchronous nature
(read limited online connectivity) makes a lot of sense. There are a
few open source mail servers that can be readily installed and
deployed (any OS), and tweaking the retry and timeouts for mail
delivery, one can build the appropriate connectivity infrastructure
for a store-and-forward system. The advantage of using email as the
underlying communications infrastructure is a robust standards-
compliant system, a very good starting point for any open source
project such as this one. I built a proprietary system using this type
of setup a while ago in my previous job, and worked really well.

V.

Thanks all - definitely interesting to hear about future avenues for innovation, but would be great to hear more practical advice like Dan's.

The issue with the scattered solutions Dan describes is that while they may work well for very tech-savvy US-based/trained folks, our Rwandan team is unlikely to be able to navigate 5 or 6 sites and use them together effectively. We were really hoping for an easy-to-maintain single, low bandwidth solution.

Any thoughts?

Thanks Oliver. Indeed, we couldn't agree more.

While we do not have any solutions to offer, I'd just like to expand your
point a little: while our model is at least somewhat functional (but
definitely not perfect) for the highly-trained / US-based volunteer team, it
almost entirely excludes our local, less tech-savvy local Nepali staff. I
think it speaks volumes that even our two MBBSs (certainly the most highly
educated of our local staff) struggle to utilize all of the various
programs. The sad and difficult fact is that, as we have prioritized the
hiring of staff from the local village, who are far less likely to be as
educated as applicants from other areas of the country (it is an extremely
poor area, with a high percentage of Dalit populations who have been
historically marginalized from education), we have ended up with a team of
staff who are excluded from our IT system. Not only are they not computer
savvy, but many do not speak / read / write enough English to be able to
navigate the Anglophone software that we use.

A second, but also important drawback of our system is its redundancy and
seemingly unnecessary complexity. Our experience ...

Thanks Oliver. Indeed, we couldn't agree more.

While we do not have any solutions to offer, I'd just like to expand your
point a little: while our model is at least somewhat functional (but
definitely not perfect) for the highly-trained / US-based volunteer team, it
almost entirely excludes our local, less tech-savvy local Nepali staff. I
think it speaks volumes that even our two MBBSs (certainly the most highly
educated of our local staff) struggle to utilize all of the various
programs. The sad and difficult fact is that, as we have prioritized the
hiring of staff from the local village, who are far less likely to be as
educated as applicants from other areas of the country (it is an extremely
poor area, with a high percentage of Dalit populations who have been
historically marginalized from education), we have ended up with a team of
staff who are excluded from our IT system. Not only are they not computer
savvy, but many do not speak / read / write enough English to be able to
navigate the Anglophone software that we use.

A second, but also important drawback of our system is its redundancy and
seemingly unnecessary complexity. Our experience has been one of continually
adding another piece of software as we have grown and needed additional
functions. This sort of ad hoc health IT development, which has been done
out of response to needs as they develop, rather than adopting a
single/unified system at the outset that could accommodate growth and
development, is clearly not ideal. Even among our tech-savvy US-based
volunteer team who has been the architect of this scattered system, only
several of them are familiar with all of the programs -- many only interact
with a small component of that long list.

Clearly a better system would be singular / unified and perform all of these
functions together. More importantly though, as you highlight Oliver, if we
truly want to develop community-based health IT from a social justice
perspective, we must find some way of simplifying these systems such that
our local staff who have not benefited from the education that many of our
expat staff have, can be included in this work, and indeed, hopefully
directing it.

Very important questions. Thanks for continuing this.

Oliver,

We use a tool called "TiddlyWiki" to support a mixture of offline and online use. TiddlyWiki consists of a single html file which includes a fair bit of JavaScript that provides a full wiki experience. The html file can be loaded directly from an online site or downloaded and then opened off of the local disk or from a USB drive. When running locally, any changes get saved back into the same html file. When a network connection is available, the local copy can be synchronized with an online wiki. The online wiki can be a MediaWiki site, a Wikispaces site, or a number of other wikis that have API support.

In other words, you can have an online wiki set up in, for example, Wikispaces and then download TiddlyWiki versions of that wiki which can be used when offline. When connectivity is available, the local version can be synchronized (local changes uploaded, remote changes downloaded). We use exactly this set up in our Student Notebook pilot project at Queens University where the teacher created the initial wiki and then each student got their own local copy. As an additional benefit, students can make their own notes within their ...

Oliver,

We use a tool called "TiddlyWiki" to support a mixture of offline and online use. TiddlyWiki consists of a single html file which includes a fair bit of JavaScript that provides a full wiki experience. The html file can be loaded directly from an online site or downloaded and then opened off of the local disk or from a USB drive. When running locally, any changes get saved back into the same html file. When a network connection is available, the local copy can be synchronized with an online wiki. The online wiki can be a MediaWiki site, a Wikispaces site, or a number of other wikis that have API support.

In other words, you can have an online wiki set up in, for example, Wikispaces and then download TiddlyWiki versions of that wiki which can be used when offline. When connectivity is available, the local version can be synchronized (local changes uploaded, remote changes downloaded). We use exactly this set up in our Student Notebook pilot project at Queens University where the teacher created the initial wiki and then each student got their own local copy. As an additional benefit, students can make their own notes within their local version of the wiki (their "notebook") which are not necessarily shared with the larger class. There's also a large number of plug-ins developed by the community that can be used to customize each individual's notebook.

This setup turns out to be very lightweight and flexible. Since TiddlyWiki runs in most browsers (Firefox, IE, etc), it usually does not require installing any software and runs on almost any PC out there that can browse the web. The major drawback is that the browser security settings usually pop up a warning message before allowing the TiddlyWiki file to write changes back to the local hard drive. It can sometimes be a challenge for users to understand how to stop the annoying pop ups and also to learn to use the "Save" link in the document instead of the browser's "SaveAs" File menu item. (Because of the way the browsers work their "save" function does not properly write the TiddlyWiki to disk. Instead TiddlyWiki uses it's own JavaScript to write changes back to the original file and optionally makes a backup copy.)

TiddlyWiki would not meet your needs for email lists, but it might address many of your other requirements and constraints. Note that it is, of course, open source and freely available for use. Along with you and Dan, I too would like to see an IT infrastructure that really supports community based health whether it is based on TiddlyWiki or something else.

In addition to our Student Notebook project, we've been evaluating this approach as a means of distributing health information from the Hesperian Foundation, such as "Where There Is No Doctor", targeted for community health workers. If you're interested, we (the non-profit UnaMesa Assocation) would be happy to help you set up a test or pilot site, answers any questions you have, or provide other kinds of support. In the long run we'd like to provide the type of infrastructure that PIH and similar organizations need to improve health care and education. Working with you would be a great opportunity to get feedback and really understand your needs in detail which can be fed back into the community based development process.

The basic TiddlyWiki background and distribution can be found at: http://tiddlywiki.com/
More details on the Student Notebook project here: http://studentnotebook.projects.unamesa.org/

I'd be happy to answer any questions either on this site or via direct email.
-Greg

It sounds as if your team requires two big functionalities: 1) better email communication; 2) file-sharing. Both of these should be very easy-to-use and accessible over low BW. They should be accessible offline given unstable internet connections.
Regarding the ability of staff to use them, admittedly no software exists that can overcome language and computer literacy. That can only be accomplished through training. The only suggestion would be to pick one or two approaches/strategies and work with staff to value computers/software as important skills and provide them with opportunities to integrate the technologies into their work. Focusing down and implementing serially a core, simple strategy to begin with can help staff gain computer skills and not overwhelm them. That is to say, I would worry less about the specific software you choose (though of course choose wisely) but more about the organizational support/culture you provide to staff in learning the tools.
That said, I’ll put forth my thoughts on the specific apps to consider:
My suggestion for email would be google apps gmail accounts. You can use the free educational edition of google apps. Through google apps, a trained computer literate (but non-techie) manager can on-site ...

It sounds as if your team requires two big functionalities: 1) better email communication; 2) file-sharing. Both of these should be very easy-to-use and accessible over low BW. They should be accessible offline given unstable internet connections.
Regarding the ability of staff to use them, admittedly no software exists that can overcome language and computer literacy. That can only be accomplished through training. The only suggestion would be to pick one or two approaches/strategies and work with staff to value computers/software as important skills and provide them with opportunities to integrate the technologies into their work. Focusing down and implementing serially a core, simple strategy to begin with can help staff gain computer skills and not overwhelm them. That is to say, I would worry less about the specific software you choose (though of course choose wisely) but more about the organizational support/culture you provide to staff in learning the tools.
That said, I’ll put forth my thoughts on the specific apps to consider:
My suggestion for email would be google apps gmail accounts. You can use the free educational edition of google apps. Through google apps, a trained computer literate (but non-techie) manager can on-site create users and email listserves (which happen to also be google apps groups, but for the most part I'd say avoid groups and stick within the gmail browser). Staff themselves need appropriate email training. You can set up google gears to give you offline email.
My suggestion for the file-sharing would be evernote. Evernote is extremely low-BW and has a very easy online/offline feature. You can download the offline version onto organizational computers. It is also about as simple to use as a word document. It is not exactly a wiki, but I'd say prioritize the file sharing/institutional memory part that evernote affords. You can see ours here (although note the offline version is much more navigable than the online one that will pop up when you click the link, and we actually don't use the web browser version):
http://www.evernote.com/pub/nyayahealth/operations

Again, this problem is less going to be solved by some certain software program-- any number of paths will work-- but more by an organizational priority to get staff the training they need, and establish an organizational culture in which tech is used efficiently/effectively. As Dan mentioned, this is not an easy task even among staff/volunteers who have language and computer literacy. But the long-term organizational structural changes you are establishing will pay dividends for sure.

A quick follow-up comment -

Check out the Dropbox forum discussions about using Tiddlywiki. It's a pretty interesting and lightweight solution to the problem of collaborative authoring using wikis in an environment with intermittent connectivity, where some level of access control needs to be enforced.

Another option is outlined here:
http://www.mcs.vuw.ac.nz/comp/graduates/archives/bitt/2006/kim.pdf

Confluence may be better as an enterprise solution, and it has a robust security model built in. It's also free to nonprofits, etc., and they're doing a $10 special at the moment for small organizations.

It would be cool if there was an organization willing to provide a decent, low-cost hosting solution along the lines of the community licensing model. Perhaps a cloud computing provider like Amazon or Google could get interested.

Also, continuing work on the synchronization plugin described in the research paper would be cool.

It might also be worth evaluating their open-source platform as a potential patient care solution, especially when combined with Jira and their other components - for federated identity mgmt, etc.. The issue-tracking workflow could be a good starting point for a patient care solution.

Just a quick update - as we've reached out to everyone and worked to come up with potential solutions, the majority of the advice we received pointed us to Google Enterprise as a potential solution. We're digging into it now and testing, but will let everyone know the results as we move forward. Thanks for the advice!

Regarding file and calendar sharing: Aptivate (non-profut IT consultancy) has developed an open-source intranet application in PHP for the Nigerian SPARC project, with bandwidth use specifically in mind. SPARC was very impressed by its speed and ease of use. You are free to use it. If you are interested we can set up a demo site for you.

Regarding email with offline capacility: Thunderbird, Evolution and Microsoft Outlook all have the ability to cache remote IMAP folders and queue sent mail for delivery when connectivity resumes. Therefore any of these should be able to function with an intermittent connection. If you need communications in places with no connectivity at all, you might look at Frontline SMS as a way to link SMS and email.