Or a FHIR API. The same thing could be done in FHIR as:
/ws/fhir2/R4/MedicationDispense/$create-from-request?request=MedicationRequest/<uuid>
The FHIR2 module should be able to handle OMODs adding new resources and operations, although the closest thing on documentation for how to do so is at the bottom of this post.
Ah, great @ibacher … and that’s “a generally okay” practice? ie adding lots of business logic via adding custom FHIR resources?
Yes, definitely. The usual idea is to try to stick to things defined in the spec or an implementation guide, but this is one of the ways that FHIR is built to be extensible.
I agree that the business logic should be in the backend.
@burke @ibacher @mseaton @ddesimone @grace and others… I’ve started to write up a proposed plan forward here:
https://wiki.openmrs.org/display/projects/Medication+Dispense+Module
I would be interested in others thoughts when you get a chance, especially on the questions I’ve asked.
The API page (Medication Dispense API - Projects - OpenMRS Wiki) is still rather light on content, pending better clarification of the use cases and screen designs, but I got fairly details with the data model (Medication Dispense Data Model - Projects - OpenMRS Wiki), basing it around the existing FHIR module. I’m hoping we might be able to get going on that even before we have all the use cases fleshed out.
Take care! Mark
- Better name for the module? Should it be called “Pharmacy” or “Dispensing” (would have to to deprecate the existing “Dispensing” module)
It depends on your goal for the module. Are you aiming to start with dispensing and eventually evolve the module to handle other aspects of pharmacy workflow (e.g., inventory, packaging, prescription labeling, refill requests, refill reminders, supplier & manufacturer information, expiry management, point of sale, medication returns, etc.)
- Or do we want to consider building this in OpenMRS Core directly?
The ability to record and recall recorded dispensing events could go in core; however, you probably want to iterate on it faster than our current pace of annual Platform releases.
But dispensing management software (part of a pharmacy system) doesn’t belong in OpenMRS core. OpenMRS is an electronic medical record, not a pharmacy management system, lab information system. radiology information system, etc.
- Should we build out RESTful API in OpenMRS REST or FHIR (or some combination)
FHIR has several advantages:
- Do have a means/pattern for deploying a MFE via a Module? Do we even want this? If not, how do we “bundle” the MFE with the OpenMRS module? Or is it okay (or even beter) to keep these two things separate?
ESMs (ECMAScript Modules, the standard for frontend – i.e., browser-based – modules) will be packaged separately, in part because ESMs – at least for now – must be incorporated at build-time. We’ll have a Talk post very soon to discuss the proposal for OpenMRS Packages.
All sounds good, thanks @burke !
I would think we should strongly consider building on / evolving the existing dispensing module at openmrs/openmrs-module-dispensing, even if that means a new major version that is a complete rewrite.
Makes sense @mseaton … it gets a little confusing if we have to keep some of the old stuff around at the same time (I think we might be running both at the same time for a while) but it’s probably worth it vs starting a whole new module… I can take a closer look.
fyi, I’ve finally gotten back to this and started a new thread here:
Hi. I am new to OpenMRS and want to begin by contributing to this project. Can I have the GitHub repo’s link and JIRA board/project plan ? Also, on other project’s pages, I see a link to slack and weekly meetings, but I was unable to find it on https://wiki.openmrs.org/display/projects/Medication+Dispensing Thank you.
This is currently in design. There is no code or Jira issues yet.
Thank you. I will have a look at the design and stay updated with the project 