Guidance on displaying medication side effects in pharmacy workflow

Development
1

Hi everyone,

We’re working on a feature to display medication side effects to clinicians (in the Order Form) and dispensers (in the Dispense Prescription panel) during the pharmacy workflow.

Before we start building, I wanted to check if anyone has done something similar or knows of existing modules/approaches we could leverage.

What we need:

  1. Display side effects for medications in the patient order form and dispensing details.
  2. Classify side effects as “common” or “severe/unusual.”
  3. A way for admins to manage/update this side effect list (as it will grow/change over time).
  4. A configuration setting to toggle the visibility of these side effects specifically for the dispenser view.

Questions:

  1. Does MRS have any built-in support for drug metadata/attributes like this?
  2. Are there existing modules (or work-in-progress) that handle drug information/side effects?
  3. For the data model, would you recommend extending the Drug entity, using Concept mappings, or creating a dedicated module?

Thanks in advance for any pointers!

2 Likes
2

No

Not that I’m aware of, but there may be something out there.

I’d probably think about this as a dedicated module.

3 Likes
3

Thanks @ibacher for the feedback. To wrap up the architectural design, I have two more technical questions:

  1. Should we link the side effects to the Drug entity (the specific product) or to the Concept (the active ingredient)? What’s the recommended approach here?
  2. Since we gonna build a new module, does it make sense to map this data to FHIR ClinicalUseDefinition resource? Or is there anything else you would recommend for clinical metadata?
4

I think that requires the opinion of a pharmacist or practitioner and that it may depend on whatever data source is being used to populate the side-effect information and how it structures data. My guess is that concept-level is ok as long as combined medications are represented via a separate concept, but that’s just a guess.

That would be the right resource to use. It probably makes sense to implement in FHIR, but heavily depends on how you’re intending to query it.

1 Like
5

Thank you for the clarification, it helps a lot.

6

@olewandowski Any findings that we could share with the community on this topic?

7

Nothing to share yet at this stage. I’m currently working on the HLD for the feature, and once that is ready, we’d definitely welcome community input.

8

There is one thing worth mentioning, actually. This might be important here, so I just wanted to share it: I’ve discussed this with the MSF team, including pharmacists, and they indicated that it would be much more convenient for them to have side effects bundled with the specific drug rather than at the substance level.

9

Hi @ibacher @dkayiwa @dennis

We are returning to this topic and have started working on the implementation to not waste time and show you some concrete results of what it could look like, from UI perspective and backend side as well.

We prepared High Level Design document with out ideas:

Medication Side Effects Module - High-Level Design.pdf (1.7 MB)

In a nutshell we got request that end users that they wanted to be able to define drug side effects and display them in two places. Side effects are divided into two categories: common and serious. Side effects (usually the serious ones) can also have a recommended action to take, which we also want to display.

1st place where we want to display it - drug order form:

image
image421×799 35.9 KB

2nd place - dispensing app in prescription details:

image
image1775×497 46.9 KB

When you hover/click on the warning icon, the recommended action is displayed:

image
image894×378 27.8 KB

These side effect panels are configurable so they can be easily hidden/shown.

On the backend as we established above we created a new dedicated module - openmrs-module-medicationmetadata (if you prefer a different name, let me know, but anyway a new repository for this module will be needed).

Apart from that we made changes in 4 other repositories: fhir2, initializer, esm-patient-chart (esm-patient-medications-app), esm-dispensing-app

Here’s the short summary of what changes we have made and how these changes are related to each other -

medication-side-effects-overview.pdf (654.8 KB)

@ibacher @dkayiwa @dennis could you take a look when you have a moment and let me know what do you think? We’d like to move this forward. Thank you in advance!

10

@ibacher @dkayiwa @dennis

bumping this thread.

I know that is a quite complex topic but maybe in addition to my description and explanation above, I could push my pull requests so you can see what it looks like in the code. But if so, I’d need a new repository to push the new module. Thanks in advance

11

A few things:

  1. The scope of the FHIR2 module is mostly defining mappings for the core OpenMRS data model; it’s not intended as a bucket for implementing FHIR stuff. It would better to do these via your proposed new backend module (which should be fine).
  2. FHIR R5 is not supported at this time and there’s no realistic prospect of getting on a version of HAPI that supports R5 in a short time frame because we’ve got other things happening. However, I think everything you proposed needing is in R4B, which should be supported.
  3. I think we’d want to separate the UI out of the medications or dispensing apps and into their own thing, at least assuming we don’t have a community-supported source for the metadata to populate this, so changes to the medications and dispensing app should be restricted to ensuring there’s an appropriate slot. This also fits with our notion of microfrontends; we shouldn’t be duplicating views in two different places, but making the view in a single microfrontend.
  4. The proposal suggests using Initializer’s API 2.7 submodule, but this doesn’t seem to be required. I would just use the API submodule.
1 Like
12

Thanks @ibacher !

My new remarks according to your response:

Regarding FHIR:

R5 not supported → use R4B: ClinicalUseDefinition only exists from R4B onward, there is hapi-fhir-structures-r4b needed that exists only from HAPI 6.2.0 but HAPI 6.X requires Java 11. Current openmrs-module-fhir2 is on HAPI 5.7.9/Java 8 exposing only R3 and R4. hapi-fhir-base 5.7.9 has FhirContext.forR5() but no forR4B().

So on the current fhir2/HAPI stack R4B is not actually servable - enabling it would mean upgrading fhir2 to HAPI 6.2+/Java 11 (the same kind of larger change you mentioned is not feasible short-term)

Looking for the best alternative in R4 seems that MedicinalProductUndesirableEffect would be the most suitable, but I still don’t know if it’s the right resource and if it will cover everything.

What do you think would be the best?

  1. Use FHIR R4 with MedicinalProductUndesirableEffect on the existing R4 servlet - no changes to fhir2 and no HAPI upgrade. Downsides: heavier/“regulatory” resource, deprecated in R5, references MedicinalProduct rather than Medication.
  2. Stay on the R5 draft (works on the current HAPI, but unsupported per your note)
  3. Just skip FHIR here and expose the data via the new module’s own REST API
  4. something else?

Regarding UI:

So you would like to create component once, register extensions (name-component-slot) and just use these extension slots in patient-chart and dispensing apps, right? Should we have a completely new dedicated esm app for it (just for this one component) or is there any existing UI repo/package where you would prefer to put it?

Thank you for advance

13

bumping this

@ibacher

14

bumping @ibacher

15

@ibacher can you take a look at my reply on your comment? It would allow me to speed up the implementation process. Thanks in advance

16

@druchniewicz Apologies. I’ve been somewhat away from thinking about OpenMRS design for a couple of weeks. You’re right that the R4B classes basically don’t matter, so it’s probably best for now to skip the FHIR setup here and create something similar in REST. While I have plans to get on a newer version of HAPI, it requires careful coordination, if only because dropping support for Java 8 is necessarily a breaking change and we have two other large-scale refactors of FHIR2 happening right now.

Should we have a completely new dedicated esm app for it (just for this one component) or is there any existing UI repo/package where you would prefer to put it?

The frontend is designed to be microfrontends and that means that we generally want each “app” to own a “concern”. Embedding a “feature” in multiple apps breaks that assumption and makes it harder to treat this as a single feature. I don’t love having a bunch of community modules lying around, but both as I’m not sure this is a feature the broader community will want (I’m the only person replying here) and as it’s reliant on metadata we don’t have a well-defined mechanism for handling, that seems like the cleanest option.

Again, apologies for the time it’s taken me to get back to this. I assume you want some repos in the openmrs GitHub org setup for this? Who will be working on this?

17

Thanks @ibacher. No problem. Maybe @dkayiwa and @dennis will also take a look at this topic.

I will be working on this. So according to your answer we drop idea with FHIR and we’ll build REST resources in a new module.

I assume you want some repos in the openmrs GitHub org setup for this?

Yes, I would need one new backend repo (openmrs-module-medicationmetadata) and new esm-app for this.

This would allow me to at least push the first pull requests so the community would have a clearer view of whole idea and could do code reviews.

@ibacher Could you help me and create these repositories?

18

bumping this thread @ibacher

19

Here’s a backend repo: openmrs/openmrs-module-medicationsideeffects · GitHub and the frontend repo: openmrs/openmrs-esm-medication-side-effects · GitHub. I’ve invited you as a collaborator on both.

20

Great, thank you @ibacher !