Helping refugees find free healthcare providers

Application Name: Reference Application (via docker-compose)

Version: 2.9

About me/us:

Hi,

I am from Germany and here in Germany we have a self organised non-profit group called “Medibüro” which helps people getting in touch with doctors for free. http://www.medibuero-hamburg.org/english

This is mostly, but not exclusively, used by refugees. Anyone who kinda fell through the cracks or hasn’t managed to gain a solid footing including papers and basic health care can come to us and we will try (and most of the time succeed) to find a doctor willing to help for free. No questions asked, no papers, no problem.

This has been going quite well since 1994. But well, everything is on paper. And when someone comes in we have to sift through old file cards to find a doctor that treats the problem of our client, speaks his/her language and hasn’t been annoyed by us too often lately.

I don’t want to get into too many details because then no one will read this. I’m sorry if I omitted too many details.

Our problem:

OpenMRS solves most of the problems the MediBüro has. One specific thing however is different from other OpenMRS use cases.

Every hospital usually has a very clear timetable. You have your doctors, nurses, clerks and the all have specific abilities and they all can enter their shifts and you can define how long what sort of appointment will take. So when a patient walks in, you search for someone treating problem X in some time-range and book an appointment without asking the provider.

In our case we need to search for a provider based on language and abilities, ranked by how many appointments they already have, whether they do it for free or need to be paid with our donations and whether they are reachable due to holidays and so on. And once we have found a suitable provider, we would call the medical practice, make an appointment and note it in the app. At least that’s the idea.

What I tried:

I tried to mingle in the provider add on but kinda broke everything. My best guess was to go through the “Provider Management Module” > “Manage Other Settings” and see if I can show a custom field such as “Language” from the person/provider but that didn’t work. I think the closest I got was a list of all possibilities via “Language:provider.attributes.firstElement”.

I tinkered a bit with the source code as well by adding an extra selectable option for “Set the person attribute type to include on the advanced search page” in the openmrs-module-providermanagement file “/omod/src/main/webapp/pages/manageOtherSettings.gsp” which worked in the UI but did not offer any search results.

I tried other similar stuff as well but sadly I did those things before an extended holiday so I can’t get too specific or technical without getting back into the code for a while and basically going though most of the trial and error pain again.

Question:

What I’d like to ask though is whether I’m on the right track at all? Should I try to extend the feature set of the provider module? Should I try to build something different with the HTML form editor? Should I aim at building a completely different add on? Is there some distribution already aiming at a problem similar to ours? Any general tips?

I hope I posted this in the right corner of the forum and managed to explain our goal and problem properly.

Kind regards Paul

1 Like

Extending the provider module looks like the right direction. You could start by searching through these tickets to see if one already exists for the features that you want to add. If not, you can create new ones such that even volunteers within the community can help you with some. If you feel courageous enough, you can even design a sprint for those features.

1 Like

@pjost Thanks for the description of a great project.

I would suggest looking at the appointment scheduling module. It handles appointment scheduling with providers with different specialties. It is lacking the providers fluency with language AND payment, so you would need to add that to the code. I suppose to you could rig something so that you can include an appointment block called “Pediatrician - no cost - German, French, Swahili”

image

@tgreensweig @mogoodrich and other developed the module

1 Like

Thank you @dkayiwa. I checked the open issues but couldn’t find any tickets relating to my ideas. I may even feel brave enough to create a sprint. I will have to think of features and their dependencies to each other first. I already checked what I can do and it seems I am not able to create tickets for PROV but only for “Data Filter Module (FILTER)”? Do I need special permissions?

Thank you @ball as well for the appointment module suggestion. I fear the appointment scheduling module would need to integrate some more with the provider module for this to work. We only have a list of health care providers that gave us their contacts in the past and sometimes we need to update things like frequency, languages, services, vacation or small side notes after we try to book an appointment.

Some have an open arrival policy and will take care of as many as they can fit each Thursday from 8am to 11am. Others only accept two people per month and we never know when they have time because we have to call first and ask. Last time we even had a case where the provider we called had stopped existing. We just hadn’t noticed because it had been a few months since we had called them. Other times we call and just get an answering machine notifying us of their vacation time. So we can’t really create appointment blocks beforehand. Even worse, sometimes we call and they’re already closed so we just make a mark “potentially booked for unknown date” and call them on our private phones the next morning and then inform the patient about their appointment.

A feature for the appointment scheduling module could be a search for providers instead of appointment blocks. So the workflow could look like this:

  1. Register patient (exists)
  2. Start visit (exists)
  3. Schedule appointment (exists)
  4. Filter providers by skills (can only filter single service type)
  5. Show providers ranked by price and/or open spots per month (provider search only exists in provider admin view)
  6. Select the provider and call (manual process)
  7. Book appointment with selected provider for current patient at time xx:xx (currently cannot book appointment without previously defined block)

Do you think I could create a sprint including both projects? I fear that these features may break other peoples workflow so this kind of would need some sort of feature toggle as well.

And how do I contribute to already existing tickets? I found this translation ticket which would be rather easy for me. I am a native speaker and even worked as a translator for a few years beforehand. I could even offer my services as a regular translator if those are still needed.

And of course after creating a ticket or even sprint I probably want to work on it myself and contribute to the best of my abilities :slight_smile:
I usually do operations and my coding abilities are mostly based on a general understanding of IT and a lack of fear but I will try my best :no_mouth:

Yes we have had sprints that include more than one project.

We can deal with these on a case by case basis. Create the tickets and we have some design discussions around them.

https://wiki.openmrs.org/display/docs/Pull+Request+Tips

https://wiki.openmrs.org/display/projects/Translating+the+Reference+Application

This makes you awesome!

That’s a relief and sounds quite easy going. In that case I will think of all necessary features/changes and create a sprint. Maybe it will even become its own module or it will be a feature integrated in more than just two projects. I can’t tell with my level of experience but the discussion will hopefully show.

Sweet. I just registered and checked it out. Pretty straight forward. Let’s see whether I can make it a habit and contribute regularly.

Thank you. And you’re awesome for giving me all those tips!

Here is the sprint announcement I just posted. I hope I did everything right.