Currently, the FHIR API maps this to the appropriate FHIR as follows:

frequency: (frequency_per_day)
period : 1
periodUnit: days

So, currently for instance, â€śtwice dailyâ€ť and â€śevery 12 hoursâ€ť would both be mapped to

frequency: 2
period: 1
periodUnit: days

While in the proper FHIR module the, â€śevery 12 hoursâ€ť would be recorded like this:

frequency: 1
period: 12
periodUnit: hours

A couple thoughts, questions:

Seems like long-term (or even mid or short-term?) we should expand the order frequency table to more closely match the FHIR module and allow us to distinguish between the different levels of granularity

In the short-term, would it make sense, when frequency > 1 to attempt to map to a period of hours?

ie:

if (frequency > 1 and 24 % frequency == 0) then
frequency = 1
period = 24 / frequency
periodUnits = hours

FYI, technically twice daily and q12h are not the same thing. Clinically, q 12 hours is literally every 12 hours. Twice a day is typically less specific and can be two times during waking hours (breakfast and dinner, for example) which would not be exactly 12 hours. Therefore the documentation should be twice daily for one and once every 12 hours for the other.

It would be nicer if we had a defined concept set for this we could use for both the OpenMRS side and the FHIR side, ideally supporting something like this value set, that way we can unambiguously state things like BID and Q12H.

@mogoodrich As a short-term solution I think your proposal is fine, but it should look like this:

if frequency == 1:
period = 1
periodUnits = days
else:
period = 24 / frequency
periodUnit = hours

@akanter@mseaton@ibacher agree that we should work in the short-to-mid term on expanding OpenMRS so that we distinguish between twice daily and every 12 hours, but also in the very short-term we translate both into â€śevery 12 hoursâ€ť. (Right now we translate both into â€śTwice dayâ€ťâ€¦ it seems â€śmore dangerousâ€ť to translate â€śevery 12 hoursâ€ť into â€śtwice a dayâ€ť that â€śtwice a dayâ€ť into â€śevery 12 hoursâ€ť)

And, ack, thanks for catching the typo @ibacher , period units should be hours. And you are correct about frequent == 1, I hadnâ€™t listed that part about my sudo code.

I also reconsidered my approach to not translating into hours if the frequency doesnâ€™t divide properly into 24 hours and I like your example where we divide in all cases except where frequency = 1â€¦ this is because it looks like frequency must be an int, but it looks like period does not.

I started looking into implementing this today and wanted to circle back here with some questions. Iâ€™m not totally sure this approach will work out.

The main issue to address is whether or not we intend or need to do bidirectional mapping between the OpenMRS data model and FHIR. From what I can tell, what we currently support in the FHIR2 module is relatively limited, and many resources (eg. Dosage) is only currently mapped from OpenMRS â†’ FHIR, not the other way around. Looking at the MedicationRequestTranslatorImpl, one can see that there are several properties (most notably Dosage Instructions) that are mapped out from OpenMRS â†’ FHIR but not from FHIR â†’ OpenMRS.

Assuming we need and want this bi-directional mapping, we really need to properly map between elements of the FHIR Dosage Timing (assuming this is the right element) and the OrderFrequency (as well as some other properties).

There is no way of knowing from the FHIR resources exactly which Order Frequency they map to, as several OrderFrequencies will be configured with the same â€śfrequency_per_dayâ€ť data.

Perhaps the most straightforward thing would be to add an orderFrequency extension to MedicationRequest, which can map to a Concept, preferably by SNOMED-CT mapping. This would allow us to exactly represent our OpenMRS data using FHIR. We could also add the frequency_per_day in addition to this, if useful for consumption by the frontend application, but this would not be the means to uniquely try to understand what this frequency represents.

I agree with leaning toward this FHIR value set, adding additional values as needed and using free text ordering when the desired frequency is not available.

â€śFrequency per dayâ€ť can be a useful attribute of a frequency concept to use for calculations, but weâ€™re never going to be able to go the other direction (i.e., you canâ€™t represent the range and nuance of frequencies in a frequency_per_day field):

â€ś12â€ť is the correct frequency per day value for both â€śtwice dailyâ€ť, â€śevery 12 hoursâ€ť, â€śbefore breakfast and dinnerâ€ť, â€śafter breakfast and lunchâ€ť, â€¦ but those are not identical frequencies (as @akanter pointed out)

â€ś0.5â€ť would be a valid value frequency_per_day for â€śevery other dayâ€ť or â€śevery Monday, Wednesday, and Fridayâ€ť or â€śevery Tuesday, Thursday, and Saturdayâ€ť

So, I would abandon trying to devise a frequency from frequency_per_day other than as a temporary hack. Ideally, weâ€™d have a concept set of order frequencies. Each frequency would be a concept, allowing us to leverage localization, preferred names to auto-convert to the safest versions (â€śtwice dailyâ€ť instead of â€śBIDâ€ť), synonyms (let somebody enter â€śBIDâ€ť and we convert it to â€śtwice dailyâ€ť), create UCUM mappings for FHIR use to-from FHIR, and use a concept attribute for â€śfrequency_per_dayâ€ť that, when defined, could be used to perform calculations.

That should probably be â€śOnceâ€ť (a â€śfrequencyâ€ť meaning do this one time) and not â€śSTATâ€ť, which is an urgency, not a frequency. Any order with any frequency could be assigned the urgency of â€śSTATâ€ť to indicate the first instance should be done immediately.

Ideally, we do want to support bi-directional mappings, though with MedicationRequest, it was not a priority largely because, IIUC, OpenMRS requires orders to have an OrderContext to be created and it wasnâ€™t clear to me how we could derive that from the FHIR data. Hence, most of the medication stuff is currently just mapped from OpenMRS â†’ FHIR. Basically, thereâ€™s little point in providing a bidirectional mapping on a resource if we canâ€™t save the resulting OpenMRS object. (MedicationDispense changes the calculus somewhat and gives us a reason to support mapping FHIR â†’ OpenMRS for the Dosage construct).

I agree with Burkeâ€™s suggestion that weâ€™d ideally map this to a concept of some kind.

We already have all this. This is what the current OpenMRS model represents, with an â€śorder_frequencyâ€ť table that maps a frequency Concept to a numeric frequency_per_day.

So the question is - if the right way to model this in FHIR is as a frequency concept - where in the FHIR model should this happen? @ibacher ?

Can we just populate Timing.code for this and not try to populate the Timing.repeat ?

Thanks @mseaton for digging a lot deeper into this.

I havenâ€™t reviewed the PR yet, but this sounds correct to me, and I like the idea of switching to just using a codeâ€¦ as @ibacher suggests, we will need bidirectional mappings once we start creating dispensing events via the Dispensing O3 app.