How do folks handle inventory management, if you don’t have a large on-site team to set up a heavy-duty ERP system?
Can Odoo be used for small scale sites?
Asking since for #ethiohri this is functionality we need to figure out (both dispensing and inventory management/ stock mgmt). And I know we have been hesitant to build inventory management into the EMR itself, as we would like to stay focused on our core competency and recognize the competency of other focused systems.
IMHO Odoo doesn’t work well for small sites, and we are keen to identify alternatives for such use cases.
@grace you brought up yourself in our private conversations the fact that ERPNext had been selected at a site in Kenya, however that was a big site. We will investigate ERPNext as an alternative offering of Ozone, I’m not sure yet if that is the “Odoo for small sites” or not (but I’m really excited about ERPNext nonetheless.)
@here in UgandaEMR we have a mini dispensing which utilizes Orders and Observation as a way of fulfilling orders. We do not have inventory stock management. Our strategy was to have an external inventory that we can connect to. But for small Sites its becoming evident that we might need something bundled in.
Thanks so much for sharing your experience @slubwama, that is very very interesting. I was kind of imagining the same strategy of something external but your comment is making me rethink. Do you think this external integration could still be possible for small sites, if we were to find a light enough solution that could somehow still be bundled?
@grace Yes, that can be done. As a matter of fact, we have been working on a generic way to share fhir resources to any receiving system that accepts fhir and we have seen some great success on that. We built this in mind as a future plan to share orders to the pharmacy system using the MedicationReuqsts that work might work well. So I believe on our side this is possible if a system is ready to receive fhir resources.
This is really helpful!! @slubwama does this mean you guys have already basically mapped the OMRS Data Model to FHIR MedicationRequests and/or MedicationStatement and/or MedicationDispense and/or Adverse Event?
I ask because it just so happens that (as mentioned in this post today), we somewhat urgently need the OMRS FHIR API to support all of those examples. So I’m wondering if we can really benefit from this work you’ve already done Could you share a link to any relevant repos, docs etc?
@grace We actually leverage FHIR2 Module in our UgandaEMR Sync Module for generating the resources. So whatever fhir offers is what we get. At the moment the FHIR2 Module supports the MedicationRequest. AdverseEvent and MedicationDispense are not yet building in.
Yes. And we are using our module as a testing point for possible Additions of resources which later we can easily migrate into the fhir2 module. Like we have been testing how EpisodeOfCare can Map to programs. This has come in handy in raising requests that help shape core to alight to fhir. Case in point [TRUNK-6070] Add Patient Program to Patient Identifier - OpenMRS Issues. We are seeing patterns that really need improvements and we keep contributing for the greater good of OpenMRS even when it has immediate benefits for us.
Yes! And it is live in at least 3 countries. Over 20,000 prescriptions have been dispensed in the first go-live site in Sierra Leone by PIH; the tech lead being @mogoodrich .
Like for managing stock we have to use Stock/Inventory
Then based on Stock/Inventory, availability of prescribed things could be checked and using dispensing module it would be dispanced
And finally based on dispensing, bill and payment would be done by Billing module
Is my understanding right? also but not sure, i understand that these are handled by some custom omods , like small back-end modules to make it light weight and usable for small clinics ?
And if someone wants to use Odoo or ERPNext in that case these would be replaced by same ?
So, yes and no Currently those 3 modules are not inter-dependent. You can choose to use all 3 (because as you rightly point out, they are normally interconnected workflows), but it is not required. Each one is being built by a different community “Squad”, though the individual people working on each overlap. I believe some of the 3 squads are planning some flow between these modules but as I said, it’s not required now.
These 3 are intentionally “lite” modules, meant for limited use cases (e.g. light and usable for small clinics, just like you imagined!) since if you need more functionality, we encourage people to connect their OpenMRS Medical Record with a fit-for-purpose system with more detailed functionality exactly like you have rightly suggested. This very much includes Odoo and/or ERPNext. If that is your use case, then I would suggest using the new open-source Ozone Interoperability Layer, which is developed and maintained by OpenMRS community members and includes pre-built options for Odoo and ERPNext. Info on that here:
Thanks @grace for writing in detail. I am exploring ozone as well, so was little bit confused how these are different from what ozone is providing.
Now i got the idea, these are more of very light weight modules/apps and covering limited scenarios/use-cases required for small clinic, as for small clinics, using Odoo or ERP-Next might be over-kill.
Thanks again !
Hie @grace and @mogoodrich,
Would you be so kind to take us through the Dispensing module? I work with Lighthouse Trust, an HIV service provider in Malawi located in 5 major central hospitals and we are looking for a dispensing module that will assist us in drug management.
Could you share a link to any relevant repos, docs etc?
Currently those 3 modules are not inter-dependent. You can choose to use all 3 (because as you rightly point out, they are normally interconnected workflows), but it is not required. Each one is being built by a different community “Squad”, though the individual people working on each overlap. I believe some of the 3 squads are planning some flow between these modules but as I said, it’s not required now.