# Plans for integrated prescribing/dispensing workflow

**URL:** <https://talk.openmrs.org/t/plans-for-integrated-prescribing-dispensing-workflow/34345>\
**Category:** Implementing\
**Tags:** drug-order, drug-dispense, drugs\
**Created:** [August 9, 2021, 7:03pm UTC](https://talk.openmrs.org/t/plans-for-integrated-prescribing-dispensing-workflow/34345 "2021-08-09T19:03:47Z")\
**Posts on this page:** 1\
**Showing post:** 21

<div class="post-metadata">

**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\
**Post date:** [August 30, 2021, 8:32pm UTC](https://talk.openmrs.org/t/plans-for-integrated-prescribing-dispensing-workflow/34345/21 "2021-08-30T20:32:57Z")

</div>

> [@mogoodrich](#):
>
> do still we foresee new business logic being provided by writing (Java) OpenMRS omods, but instead of the UI interacting via a OpenMRS Service API, the OpenMRS omod will expose it’s API via custom OpenMRS REST endpoints like what you mocked up above?

Or a FHIR API. The same thing could be done in FHIR as:

```auto
/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](https://talk.openmrs.org/t/fhir2-release-1-2-0/33507/16).

---

_[View the full topic](https://talk.openmrs.org/t/plans-for-integrated-prescribing-dispensing-workflow/34345)._