Proposal for linking Dosage Forms to Routes of Administration

Community
,
1

This post is about basically the same problem outlined in this earlier discussion. Basically, when we have an OpenMRS Drug entry, it tells us the form that drug is in but not the valid ways that that drug can be administered. While we might need—in some cases—specific per-drug mappings, it’s also convenient for us to be able to express things like “you cannot order a capsule to be given intravenously”.

We had a start of a discussion around this on the O3 Squad call yesterday, which lead to a now very long Slack thread where we seem to be narrowing in on a way to represent this, so it’s time to bring this up for the broader community to discuss how we’re envisioning being able to support mapping from drug forms to a list of allowable routes, ideally without needing to add new metadata tables.

Our goal here is to leverage metadata that’s available in RxNorm that maps between drug forms, drug form groups, and valid routes of administration. This ends up looking something like this (I’ve stolen this from @akanter in the Slack thread):

Dose Form (examples) Dose Form Group (DFG) Derived Route(s) Notes
Tablet, Capsule, Solution Oral Product Oral Most reliable mapping
Chewable Tablet, Oral Suspension Oral Product Oral Pediatric variants
Sublingual Tablet Oral Product Sublingual Sometimes separated
Buccal Tablet/Film Oral Product Buccal Distinct mucosal route
Injection, Injectable Solution Injectable Product IV / IM / SC Ambiguous
Prefilled Syringe Injectable Product IV / IM / SC Context needed
Infusion Solution Injectable Product Intravenous More specific
Cream, Ointment, Gel Topical Product Topical Skin
Lotion, Foam Topical Product Topical Skin
Transdermal Patch Transdermal Product Transdermal Systemic absorption
Ophthalmic Solution Ophthalmic Product Ophthalmic Eye
Otic Solution Otic Product Otic Ear
Nasal Spray Nasal Product Intranasal
Inhaler, Nebulizer Solution Inhalant Product Inhalation Pulmonary
Rectal Suppository Rectal Product Rectal
Enema Rectal Product Rectal
Vaginal Cream, Tablet Vaginal Product Vaginal
Irrigation Solution Irrigation Product Irrigation Procedural use
Dialysis Solution Dialysis Product Intraperitoneal Specialized
Implant Implant Product Implantation Long-acting
Powder for Reconstitution (Injection) Injectable Product IV / IM / SC Still ambiguous
Oral Powder Oral Product Oral Depends on labeling

Basically this will allow us to take an existing CIEL concept like Tablet (CIEL:1513) and say this is an “Oral Product”, which means it can be given, e.g., “Orally”, “Sublingually” or “Buccally”.

Concretely, what we’ll be adding is:

  • A new concept class for drug routes and presumably dosage forms
  • Mappings in CIEL for the various Dosage Forms to appropriate Dosage Form Groups
  • The Dosage Form Groups and their mappings to the valid routes
  • An extension to the Drug REST API to facilitate retrieving the valid routes for a specific drug from those mappings

We will endeavor to ensure that future updates to the O3 UI (and the O2 UI) that may leverage this information fallback correctly (basically allowing all routes for cases where dosage form groups are missing or their mappings to valid routes are missing).

Thanks to @chibongho, @mogoodrich, @burke, and @akanter for the discussion around this. Please feel free to correct me if I’ve summarized any of this incorrectly or if my understanding here is wrong.

2 Likes
2

Also flagging @mseaton for review

3

Thanks so much for writing this all out, and generally sounds good, though interested in having others weigh in.

One point (which doesn’t affect the overall modelling, just the implemetnation),:

One thing to note is that although a Drug has a “Dosage Form” property, it appears that in the UI we generally don’t restrict the end users from changing that form when placing an order. If that’s intentional (or something we don’t want to change) then in the UI we need to base the “valid routes” on the “dosage form” the user actually selected, not the “Valid Routes” for the Drug (which would assumedly be based on “Dosage Form” for the drug)?

4

We should probably fix the UI to enforce that. I think if we’re saying a specific drug has a dosage form (and it seems to be a required field) we should be treating the drug as restricted to that dosage form.

5

That does seem right to me. Not sure of repercussions. @mseaton @fanderson @ddesimone thoughts? (Effectively, “Dose Unit” would become uneditable).

6

Also, the example table needs to be expanded to include ALL reasonable routes of administration for a form group (as mentioned above, ORAL can mean any of the oral routes). I would also point out that these relationships are coming off the drug CONCEPT in the dictionary (which for CIEL are ingredients, multi-ingredients and some specific ingredients) and not the DRUG rows. I can’t remember whether O3 draws only from the DRUG table for those prescriptions/orders, or whether it uses concepts + metadata selections to generate a prescription where the dispensing module takes over and maps to drugs. If you are directly searching and selecting from the DRUG table, then we have another join back to concept to worry about.

1 Like
7

I’d think the most useful information for determining valid routes of administration for a drug form would be a many-to-many mapping from dose form to drug route. The dose form group might be informative, but creates ambiguity. For example, I would expect “sublingual” to be the only valid route and “oral” and “g-tube” to be invalid routes for a sublingual tablet; whereas, most immediate-release tablets or capsules have multiple valid routes (oral, g-tube, j-tube).

In any case, creating a getValidRoutes(Drug) method in the Drug API would allow us to encapsulate this business logic, create a decent 1.0 version for now, and then improve it over time.

Some additional, less common, routes to consider:

  • NG tube – nasogastric tube
  • G-tube - gastric tube
  • J-tube - jejunal (directly into small intestine) tube
  • Intratracheal – some drugs are given intratracheally in emergencies
  • Intra-arterial – sometimes chemotherapy or diagnostic meds are given directly into an artery
  • Epidural
  • Intraosseus – injected directly into marrow, typically an emergency situation
  • Intracardiac – rare
  • Intra-articular – treatments into joints
  • Intravitreal – injections directly into the eye
1 Like
8

Currently, the dose units that are possible is pretty open-ended. I have seen forms that have select lists containing units like Tablets and Capsules alongside units like “Milligrams” and “Grams”, without really any particular opinion over which should be preferred.

So @ibacher we would be changing this such that a drug like Albendazole, 200mg chewable tablet, which has a dosage form of Tablet, would be restricted to Tablet at the dosingUnits within the DrugOrder, and one would not be able to choose mg? So all orders would need to be in “number of tablets” vs. “number of milligrams” per dose? Is this something we can and should broadly enforce across the board?

I don’t have any problem with this, but what is it buying us that the current approach of having all valid dosing units in a Dosing units concept set and all valid drug routes in a Routes of administration concept set doesn’t already buy us? How is this helping to address the underlying issue?

It would be good to lay this out in with one or two actual examples of what specific concepts and mappings would be present and how these would be used. If we can leverage information embedded into RxNorm, that’s great, but would be good to see how that looks in practice.

Is this something like:

  • RxNorm has a concept of Route for Tablet
  • Implementations would then add a NARROWER-THAN:RX-NORM:Route for Tablet to their Oral concept?
9

I’m probably not the most experienced here to add to this convo but

We need to be careful not to break strength-based prescribing.

Isn’t it clinically safer to allow the prescriber to order the therapeutic dose (e.g., 1g, twice daily for 7 days) and let the dispenser/pharmacy calculate the physical quantity (tablets/capsules)? If we strictly enforce the ‘Dosage Form’ as a unit at the time of the order, we risk forcing clinicians into dispense-based prescribing (e.g., ordering ‘2 tablets’ instead of ‘1g’). This could severely complicate pediatric weight-based dosing (mg/kg) and limit pharmacy inventory flexibility.

10

Well, the Drug data model implies that there’s one dosage form per drug, which currently isn’t meaningful. The questions you raise here are, I think, something we’re soliciting feedback on.

I don’t think it necessarily helps with this problem, but it does seem like good metadata hygiene. Currently all those concepts are all classed as “Misc”. It’s more about signalling to user’s what those concepts are intended for.

11

Yeah, reading the responses, it seems like although the model only allows one dosage form per drug, we tend to take that as a recommendation/default rather than a hard rule. And the main use case appears to when one wants to prescribe in, say, mg, instead of tablets.

That’s something we don’t need to solve/change to implement this feature… we really just need two of things @ibacher mentioned previously:

Plus:

  • An (API and/or RESTful) way to fetch all the valid routes for a given dosage form (instead of trying to map the routes all the way back to the drug)

Does this sound right (knowing that we are still trying to flesh out exactly how the mappings should look)?

12

I’m very much deferring to @akanter for how exactly these mappings should look.

But yeah, I think we can add that sort of API as well. I kind of like @chibongho’s idea of using a @PropertyGetter on the drug because I think we’re using the drug endpoint to populate the O3 order form (so at least in O3, it would cleanly give us the right data-per-drug), but I realize that for the HFE case it might be more convenient to have some kind of Java API mechanism as well, which might look more like something on the ConceptService rather than modifying the Drug domain directly.

13

The problem is (unless I’m misinterpreting something) if we aren’t enforcing that the only valid dosage form for a drug is the dosage form associated with the drug (and we aren’t enforcing this now and from preliminary feedback this seems to be intentional) how can we limit the routes based on this form? Or are we effectively saying that even if you change the dose form (ie from tablet to mg) the route still must be based on the valid routes for a tablet form? (Which I guess could be the right thing to do)

14

Probably this one. Although it does imply that we may want to restrict the allowable values in the “Dose unit” drop down.

15

I’m still trying to reconcile @burke ‘ s feedback and whether it makes sense to create the intervening dose form group. It would certainly make maintenance easier, but does leave wiggle room (which I think it probably OK since it doesn’t seem like we want to be too restrictive… it is more a convenience issue for the UI. I’m going to need to know soon if this is going to be in the next release (including adding the new class so these will no longer be classified as “misc”.

16

This is totally fair. I just wanted to bring it up since I don’t think it actually gets us any closer to solving the described problem. Yes, it’s more descriptive and it would probably be good to do, but if it doesn’t help link dosageForms → routes, then let’s ticket and discuss it separately.

What I am trying to get my head around is exactly how we are envisioning modeling this on the OpenMRS side. Clearly we will need some usage of concept mappings, and some usage of concept sets. Do we also need Concept Attributes per the proposal in the linked thread, or are we envisioning that we can use mappings to achieve the necessary linkage between a given Dosage Form concept and a given set of Route concepts?

Does anyone have a clear idea of this in their head that they can lay out here with a strawman that shows how this would be represented for a representative use case within the OpenMRS data model? @ian or @burke perhaps?

17

I think we’d be solving the part that that proposal was aiming to use attributes for with concept maps. Basically, it’s meant to be more or less what I showed on the table. I.e., the “Dose Form” concepts would have a “DOSE FORM GROUP” mapping that mapps to a Dose Form Group concept like “Oral Product”, “Injectable Product” and those Dose Form. Group concepts would have a “ROUTES OF ADMINISTRATION” mapping to the route concepts.

So something like:

Concept: CIEL:Tablet
Mappings:
...
DOSE FORM GROUP: CIEL:Oral Product
...

Concept: CIEL: Oral Product
Mappings:
...
ROUTES OF ADMINISTRATION: CIEL:Oral
ROUTES OF ADMINISTRATION: CIEL:Sublingual
...
1 Like
18

What @ibacher suggests sounds workable to me!

19

If a given dose form can be part of more than one dose form group, do you want me to only map it to the most specific group so that there is a 1:1 relationship? That would be more restrictive for route maps. If I go to broad categories, there will be more options for route. For example “oral spray” is part of the “oral spray group” and the “oral” group.

20

@burke Since we will now have more than one map from a concept to a CIEL code, we will need to create a new relationship type which won’t be confused with the SAME-AS CIEL maps… In this case dose forms will be mapped to a dose form group concept and the dose form group concept will be mapped to routes. Any suggestion for the relationship type(s) which won’t confuse validation?