OpenMRS: A Open Source Platform for Addressing Healthcare Technology needs across continents and cultures

Facilitated by Darius Jazayeri, OpenMRS

Session Description

Darius will introduce this health information platform that is powering medical records management all over Africa and beyond.

Session Notes

interest

civicrm community development small projects, interested in hearing about bigger ones medical project interest and small project that has gotten smaller vietnam - whole thing gets replaced when changing systems, which is very wasteful. interested in checking out this project to recommend to friends

mostly talking about community

what do we do?

what our projects do shape the community

history - build an opensource medical framework, an architecture. there is an application that you can install, but that is not what we are about. we hope people embed our framework and use the api.

got started b/c 2 groups were reaching limitations of what each of our customized systems were. v2.0 - openmrs was available domain name.

initial timeline was 2 programmers and 3 months

desire of some to build a true platform, took a lot longer. well meaning people and a lot of luck.

partners in health, int'l ngo doing medical care in lots of countries. want to do the best medical intervention possible. custom tool worked for the 2 projects, but growth to 5 ab=nd then 9 made the tool not useful.

peru, haiti and rwanda experience which gave lots of use cases. other project was working in kenya, which seemed similar (treating aids in africa), but had a university collaboration piece.

technical tangent - database table for physical exam, with columns for specific data. new fields you added new columns. did not scale well.

needed a data dictionary - one ... separating data in a scalable way.

also needed to make it modular. allowing people to extend, override, etc.

most of the reasons things worked or didn't has not been about the technology.

initial people, some were programmers, others were genarlly geeky but spent time developing the vision, the future goals, etc

give and take was a process. "quick hacks are bad" vs deadline looming.

sketch out vision re: community

wanted to build something that everyone could use and noone would have issues

pie is small and everyone is fighting for their share. there were a bunch of competitors who built applications that they built for one country that they were asking people to use in another country.

we were trying to write a platform that no one owned.

it is not really about the software. having perfect software only gets you to 10% of a successfull installation. need the people tp role it out, train people well, make it self sustainable.

implementors can form their own community and answer each other's questions. founs money to bring people together, to have implementor community meetings.

having data managers able to talk to each other about how they supported their staff was invaluable.

also did sprinting and trainings. also created a trainer program in rwanda, teaching java, etc.

also set up developer and implementor mailing lists. having a physical meeting reinforced the community. not everyone could attend and it was only once a year.

were people reluctant to share on mailing lists?

never reply directly to an email. if delicate ask if they can post to the list. otherwise just cc the list when you respond to someone. force evrything to the mailinglist. has a person who manages the lists. example, no design conversations in the ticket system. if they start there, "police" will move the conversation to the list.

set up wiki, mailing lists, forum, ticketing system. made all of it public.

other people in the project have done their research on best practices for open source communiyty building.

no negative posts in the lists. people are gracious, supportive. we have cultivated the idea that the reply "read the effing manual" is not useful. if you are going to reply that then do not reply. someone else, later in the day, will look up the page on the manual and respond.

small size of the community has made that possible, so far. recognizing that the person who needs to read the manual might have a satellite connection that makes it really difficult for them to read the manual.

people answering each other's questions has not turned out to be true. most people on the mailing list feel fine asking a question, don't like answering them. feel like they might be wrong or not an expert. this is conjecture, there is no data. "the people i know best are too busy, have too much going on."

a lot fo the contributors do recognize that they are getting things for "free." they submit tickets and it gets solved and they tend to contribute more.

is one of your goals, milestones that more of this work is shared? one of our goals is that companies develop those internal capacities.

openmrs creates but does not install. good for the tech but bad for the funding. installations is where the funding is. we want the installers to contribute more to support.

how big? 1.7 release has had 50 people contribute code. were 4, now 3, openmrs paid developers.

random volunteers, projects that use openmrs, company philanthropy things that have donated programmer time, core paid developers.

current top challenges:

have grant funding from rockerfeller to start org as proper 501c3. once we have formed that, how big does that need to be? do we need to have core developers employed by openmrs?

how does it sustain itself once the grant is done? especially since we are not doing the piece of the puzzle that no one gets paid for.

spinoff will continue to not implement, just be the stewards of the platform. in order to support that we want to do capacity building and trainings. we need to be doing trainings and people should pay for them. they also need to be geographically spread out.

civicrm - 6 years, hears a lot of familiarity.

we are coming to the conclusion that we need to wind down. our concern is that the funding will not be there. how do we move the platform to the community that has developed. we would do trainings, etc.

more vaguely defined set of missions that our project is serving. some human rights groups that are using it that are very sexy but ...

need to stengthen the commercial ecosystem.

what did civi do to strengthen that development?

in person training, code sprints, book sprints. able to start developing relationships with core team and people using the platform. some ecosystem out there, a matter of making connections, helping them understand the platform, how to fix problems.

set up a clearinghouse for commercial server providers.

do get requests for referrals often, not handled in an objective way.

is the clearinghouse moderated? do people need to get certified?

moderation: form for people to submit info, links to case studies with work they have done with the platform. within 3 months you need to have the case studies. informally check out their websites. added module that allows for ratings, that has not gotten much use yet.

divided those service providers into 2 sections: active contributors and everyone else.

criteria, subjective so far, for active contributors. someone in your org needs to be helping people in irc or forums. contributing patches, bug reports with some frequency. running a meetup. host a training event. participate in a coding sprint.

not a whole lot of pushback yet. seeing some groups that have made a lot of money with the platform and not giving back much yet, but starting to step up.

civi community very diverse: sectors, individuals, large orgs. individual who installed it.

one challenge is having consultants who do a terrible job.

dancing around certification. plusses and minuses.

how big do you project the commercial ecosystem could be? relative to the wealth of the places... in absolute numbers, not so big. in places where programmers get paid 10k a year... presumably 2-3 companies per regions. 2-3 in west africa, 2-3 in east africa. already a shop in south africe. people being trained in rwanda. in 2-3 years from now there could be 5-6 shops in africa.

civi - one of the things we are trying to figure out: trained our community over the 5-6 years that if they need a new feature they ask for it and we do it. trying to retrain them that if they need something new they need to contribute to the process.

been an interesting process trying to make that transition. not committed to it fully, not consistent. some cases b/c we feel we can do it right, others b/c we can't believe we forgot that.

consistency, transparency has been one of the current issues for ptp.

openmrs - having a public roadmap of what features are coming and when, knowing that they are approximate. people being able to see the upcoming trajectory has been helpful in getting people to adopt the tool.

having pre-written projects, to answer the "what can i do" question. different ranges: this wiki page needs to be cleaned up, rewrite our module architecture to be osgi (open source gateway interface) compliant (which someone picked up).

if there are features that need to be done and you know how to do it, you should write down enough to convery that knowledge.

our idea is that we have some resources and a roadmap, which we apply resources to do. if someone wants to do something that we have not gotten to yet, we will let them pay for one of our developer's times. if it is something we do not want to do, we will help them post that job and find someone to do it.