What is the best approach to build OpenMRS Distribution for Nigeria?

CDC in colaboration with other non profit Implementing partners/NGOs are working on the idea of a standard national EMR for all its partners in Nigeria . The EMR will start small with an ART module and scale up to support other diseases in the future.

MY BACKGROUND/EXPIRIENCE

Am a Java Programmer (done some J2SE programming) . Have been involved in the development/deployment of OpenMRS in over 200+ ART clinics, Have also built lots of forms using the OpenMRS html form entry module on OpenMRS version 1.83.

OUR SPECIAL REQUEST TO OPENMRS COMMUNITY

We will need lots of guidiance from the OpenMRS community especially in the following areas;

  1. Should we use the Reference version or bahmni version or build a new ui around the OpenMRS 2.0.6 platform, Standalone or enterprise?

  2. I have been granted access to the MVP-CEIL dictionary thanks to @akanter for the support.

  3. What are the technologies an OpenMRS module developer needs to master in other to develop custom modules in OpenMRS (e.g SpringMVC, Hibernate etc)

  4. What is the best approach to set up a development system? (Heard about OpenMRS sdk)

  5. Can pure html form entry module meet all our needs or do we need to learn a little JSP/Servlets

  6. What is the best way to integrate a disease specific Patient Monitoring Tool (e.g ART PMM or TB monitoring tools) into an EMR that is mearnt for a general hospital.

  7. What are the pitfalls to avoid in managing a group of developers to accomplish this task?

Hoping to get as many sugestions as posible as this project will make a big impact in patient care in Nigeria.

Thanks

1 Like
  1. The standalone is mostly used for evaluation purposes. So i recommend enterprise. As for Reference Application vs Bahmni, it depends on the use case. If your requirements are satisfied by the reference application, then go for it. But if you find that you need more than what the reference application offers, and that it is already provided by bahmni, then go for bahmni. I would not recommend building a new ui without first evaluating existing solutions. Concrete advice will need more details on your practical requirements.

  2. Good to hear.

  3. Most of the time you will be using client side technologies to build Open Web Apps for the user interface. Once in a while you may need to add server side REST end points to either the existing REST web services module, or to a custom module. So the technologies that you need to learn will depend on the approach you will have to take, basing on the use case.

  4. You got this right. https://wiki.openmrs.org/display/docs/OpenMRS+SDK

  5. For data entry forms, the htmlformentry module should meet your needs. If you face a scenario where it does not, ask the community for guidance. If you decide to use bahmni, it uses a different forms technology that also has a form designer which will not require you to even learn HTML.

  6. I would need more context infomation to understand this requirement.

  7. Avoid working with them in isolation. All of you should engage the community and make your activities as visible as possible to maximize community support and sharing of lessons learn’t from those who have been there before, and hence avoid falling into the trap of reinventing the wheel. Avoid requiring them to first learn Java, Spring, Hibernate, Liquibase, etc before they can get started. Let them start now, and what they will have to learn will depend on the requirements at hand, as guided by the community. Avoid being an unnecessary blocker for them by encouraging them to ask questions publicly on talk instead of privately, such that it does not always have to be you to answer them. Avoid being the only one to review their work by requiring them to review it among themselves, before you step in. On presenting to them a problem or requirement, first give them a chance to propose a solution, before you step in. That way, you will make them feel in control, hence promote creativity and innovation. Do not shy away from modern software development methodologies, but also remember that you have the freedom to modify them here and there, whenever you find them disabling instead of enabling your team to deliver. Do not micro manage your developers, but also watch to ensure that they do not abuse this. :slight_smile:

5 Likes

@brightoibe are you assessing OpenMRS or has it been officially selected by the consortium of partners working in collaboration with the CDC?

About 5. note that HFE (HTML Form Entry) implies that you have chosen to put together a Ref App based distribution. Bahmni does not use HFE.

Thanks @mksd. The consortium of partners has agreed to use OpenMRS. I have no expirience working with Bahmni version. I only have expirience working with the OpenMRS 1.83 html form entry module. We will likely evaluate the two versions before selecting one.

Some diseases have special paper tools called “National tools” used in documenting services provided some patients with some disease conditions. Example HIV has the Care Card and TB also has the TB Card. How do we integrate these tools into a hospital’s EMR interfaces. E.g every HIV patient is required to have WHO stagging which is not required by a malaria patient. How do we integrate disease specific observations into a hospital’s full EMR . Especially a hospital that serves patients with multiple disease conditions.

I thought you would just create those as different htmlforms.

Oh my interesting just when I was thinking of a blog post about this (more detail coming soon), leveraging from the lessons from developing, rolling out and customizing for UgandaEMR over the last 2.5 years: In summary here are my thoughts and recommendations

  1. Start with the latest OpenMRS Reference Application version currently 2.7.0 - you can update modules as new functionality comes out

  2. Develop a custom module - openmrs-module-nigeria (or whatever name you want to use) where you will store all customizations and metadata that you need for your implementation which will include:

    • Encounter types, identifiers, locations
    • Concepts (see #4 below)
    • HTML forms
    • CSS and JS
  3. This is my personal fanatical mantra which seems to be working: “All custom code belongs in OpenMRS core or modules”, basically if you need a custom flow, or feature, find where it fits in OpenMRS modules or core and work on it there, as it benefits both the community and gives you an opportunity to leverage all other implementors. There are enough pieces for you to start, look at extending in a generic way so that your implementation is only configuration

  4. Concepts:

    • Use CIEL (openconceptlab.org) as the primary source
    • If not available in CIEL - then create your own, but work with @akanter for modeling (this process is painful at the start but gets better with time)
  5. User Interface - Reference Application is moving to OWAs (we are having a design call tonight to see which features can be added in Reference Application 2.8 - so you can join and listen in. This is the approach I would recommend for you to go as you can leverage work done by others

  6. Use the OpenMRS SDK to build your environment and create packages - its the best thing since fried rice

  7. Keep your repositories opensource - this sounds too much but you will gain from others being able to see what you are doing

  8. The defacto software development lifecycle (SDLC) issues apply, and I think the OpenMRS model works very very well, so if your team can follow it - then you are on the right track

  9. Ask questions and do not give up if no answers are forthcoming as fast as u need them, share your progress, show case your work!

You are welcome to the community and we are always happy to help

@slubwama @slubwama1 @jmpango Do add anything I may have left out

1 Like

Sounds like an exciting project @brightoibe!

Bahmni is more complete solution.

It includes things we don’t have in the OpenMRS Reference Application such as drug prescriptions, lab orders, multiple configurable patient dashboards, and appointment scheduling.

Bahmni also covers all of the typical workflows in a typical health facility, e.g. it integrates an ERP which can do stock management and billing (and has lots of plugins for even things like HR management that you’d never want to end up building yourself), as well as Lab and PACS systems.

So you get a lot more out of the box, and it is a better solution for the “EMR meant for a general hospital” use case. The basics of implementing Bahmni rely on a lot more configuration via JSON and SQL, and less outright programming. Though you’d surely need to do some development work to add some features there too.

With the Reference Application you would certainly be more consistent with what Uganda has been doing (as @ssmusoke describes), and since it supports HTML Form Entry you’d probably find it more familiar. The dev community for the refapp on these forums is much more mature and more talkative than the Bahmni ones, which are newer. (You can see #dev versus #software:bahmni for example.)

I would suggest you take a close look at the https://www.bahmni.org website, and its Feature Guide. They would give you some background as to what Bahmni is and how it differs. (Under the hood, Bahmni is running OpenMRS though.)

Disclosure: I work on the Bahmni team, though I’ve also done lots of work with the Reference Application.

Take brief note of this work that I’m trying to organize: “OCL for OpenMRS” application

This will probably be relevant for you in a few months, but not yet today.

Back-end modules need Java, Spring, and usually Hibernate.

The current reference application code uses a non-ideal mix of Groovy templates with Java controllers, along with some Angular 1.x code (but also some older JS code as well).

Bahmni is mostly written in AngularJS 1.x.

Going forward there seems to be a significant movement in both projects to use ReactJS for new front-end apps.

On the topic of Bahmni vs the Reference Application, Bahmni allows you to go further with “just configuration”, e.g. in addition to the data capture forms you can also set up dashboards and patient queues.

In the big picture your team will definitely need to more than just defining forms, but not everyone needs to.

And, per #3, we’re very much trying to move away from JSP/Servlets, and towards HTML+JS+REST technologies wherever possible.

See http://radar.openmrs.org/ for lots of recommendations of what technologies to use. (“Adopt” means definitely try this. “Hold” means stay away.)


+1 to everything that @dkayiwa said.

+1 to 95% of what @ssmusoke said. :slight_smile:

Whatever distribution you choose, definitely you want to start with the latest version, and you want to have a plan to take regular updates, so that you can regularly get new functionality and bugfixes. (Your upgrade cycle might only be once per year, though modern CI/CD techniques could help you speed this up, but definitely plan for upgrades instead of thinking you’ll pick one version now and stick to it forever.

1 Like

Only thing I would add to the contributions so far is: think ahead about your concepts and concept management. It is a real PAIN to go back and reconfigure your data and/or reports because you got the concept dictionary wrong the first time. A little preparation up front will save you lots of headaches in the future! Thanks to @ssmusoke for the plug on CIEL concepts :slight_smile:

1 Like

Hello Sir, How do you prevent duplicate form entry in html form entry module? If I want to prevent a provider from submitting duplicate clinical forms of the same date . I tried disallowMultipleEncountersOnDate=‘block’ but its not working. Thanks

Hi There

We look forward to hearing more about your efforts at our upcoming Open Day in September.

You can participate by following the information given here OpenMRS Open Day aka Scrum of Srums Event September 2018

Looking forward to hearing more! Cynthia