Transition from Reference Application to Bahmni

Software Bahmni
1

Hi Bahmni team,

We are opening the conversation to transition a hospital from the Ref App to Bahmni. And as a first step we would like to define the roadmap for this. So could you help us figuring out the major steps that would be required and also shed some light on the risks and hurdles?

Should this get approved and go ahead, we would be happy to help document such effort.

Thanks!

2

Hi @mksd Some initial thoughts and questions:

  1. Which version of openmrs are you using? Bahmni currently works on OpenMRS 1.12.0. So, the first step might be to upgrade the version of OpenMRS to what Bahmni Supports
  2. What are the various OMODs that are currently being used? Check for their compatibility with what is used in Bahmni. This project can help.
  3. Migrations - As soon as Bahmni is started, there will be some migrations that are run automatically. We will need to validate if there are some conflicts during the bahmni install on startup. This might be a manual activity.
3

Hi @bharatak,

Thank you, that is a very helpful set of key points to start with.
At first glance I think we would be able to get 1. and 2. going fairly easily. We are running a custom version of the Ref App distro 2.3 so it is all close enough. The biggest jump would be for the core to go from 1.11.4 to 1.12.0.

Could you explain in more details what ‘3. Migrations’ is about?

What about our custom registration and encounter forms, I suppose that this would have to be redone within Bahmni?

4

Hi @mksd, Once the Steps 1 and 2 are complete, I think of the following steps. Please use a development environment (and not production :slight_smile:) for running the below steps

  1. Take a backup of the current database and keep it ready after upgrading to 1.12.0.
  2. Clone the default-config repo and create your own <implementation_name>-config.
  3. Install bahmni on a CentOS machine (can be same machine on which ref app is available) by following the instructions here
  4. Restore the database (backed up in point 1) and update the /var/www/bahmni_config with your config (created in point 2)
  5. Start openmrs service -> service openmrs start
  6. Look for the logs at /var/logs/openmrs/openmrs.log 
 You might see some errors with respect to liquibase migrations. Bahmni comes out-of-the-box with some standard metadata like Concept, Encounter Types, Visit Types etc
 If your database already contains them, there might be a probability of failure which you can figure out in openmrs log.
  7. You can configure/customize the registration by following this wiki page
  8. You can configure/customize the forms in clinical app by following this wiki page

I agree that this is not a detailed list. Its just a very high level view.

1 Like
5

Yes of course!
I am not expecting this to be an afternoon job, I think this will actually take weeks or even months, depending on how intricate it is.

There are quite a few custom features that will have to be brought within Bahmni and this will make for further questions down the line.

But ok thanks already for highlighting some of the key steps. No decision has been made yet. We are assessing the possibility of a migration to Bahmni versus customising the Ref App a lot further (to eventually probably make it look like Bahmni anyway
)

6

@mksd I think apart from the technical steps which @bharatak has suggested above, I would recommend considering following aspects:

  • Map the current business process flows, current system flow and Bahmni supported process flow. Call out the differences and see which of these can be overcome through configuration or through work arounds. Seek agreement around process flows which are not supported and can’t be configured and hence need process change at hospital
  • Mapping your existing paper or system forms to Bahmni Registration form and Clinical Observation forms - will be useful to get buy-in on future state
  • Creating a list of features, forms, workflow, reports, existing integrations etc, would help in mapping these to Bahmni functionality. We can help in finding suitable alternatives and configurations. Determining which of these are “must have” will help determine if you are taking steps in right direction
  • Any custom features or modules that you have built in OpenMRS and require integration with Bahmni or needs to be exposed through Bahmni App framework - should check feasibility and effort involved
  • Bahmni being a product has a roadmap and a product direction. While it has lot of configurability and potential integration / extension points, it will impose certain limitations on what you can or cannot do. Having this agreed upon by all stakeholders is important in longer run. Obviously the community also gets to influence Bahmni roadmap and product features
  • Impact on Migration of current system data - master setup, patients, visits and other transactional data - This might be easier given Bahmni is built on OpenMRS
  • User re-training especially for those in Lab, Pharmacy, Billing etc, who need to learn new paradigm and UI of OpenELIS and OpenERP
  • For local admin / tech team, assess ability to support a more varied tech stack and databases.

Quite a few of these are not specific to just Reference App but are applicable to anyone moving to Bahmni from an existing system.

7

Thanks @pkanchankar, this is very much appreciated. We (@mksrom and I) really value all your comments and will pop back on this thread several times to ask more detailed questions.
It’s been confirmed that we need to dig further into Bahmni during the coming 1.5 week. Just to start getting the bigger picture better for now.

I have a question regarding modules that provide a UI to the Ref App. Can they still be used within Bahmni then, I see that UI Framework is part of the Bahmni distro?

8

What is the use of Visit Type in Bahmni?

9

Generally yes, though they won’t share the same UI styling. For example here are instructions for adding the Appointment Scheduling UI refapp module to Bahmni.

10

Great Darius, that’s very interesting. This means that Bahmni can just encompass UI components of the Ref App, right? And this encompassing would not necessarily go much further than linking to another page without really bringing anything new into Bahmni Apps.
If yes, then I guess we should always aim at a double release mechanism for our modules, to ensure that they can live in both distros: Ref App and Bahmni, correct?

In the article that you pointed me to, why is this mechanism of migration used to add the potentially missing patient attributes, why not just make use of Appointment Scheduling UI’s activator?

11

@mksd Your assumption is right about making the Ref App & Bahmni living side by side. It should work fine for all the existing modules developed till date. But eventually, we should arrive to a place where the work can be re-used by following a standard way of extending Bahmni. One suggestion could be to go by OWA (for client side) + OMOD (for server side) and be integrated it into OpenMRS. Interested to listen more approaches.

Regarding the appointment module, one of our customers had a requirement of Appointment Scheduling module and we just plugged-in what is available in openmrs world. It was developed in a way that expects those patient attributes to be available in the system.