FHIR Chat · Dose rate · implementers

Stream: implementers

Topic: Dose rate

Rik Smithies (Oct 04 2018 at 16:07):

How is a dosage rate of 10ml per hour sent?
As a rateRatio, numerator=10ml, denominator=1h
or as a rateQuantity, value=10, unit=ml/h
Are "ratio units" like this (ml/h) expected?

Alexander Henket (Oct 04 2018 at 16:12):

@Arianne van de Wetering @Marten Smits

Jean Duteau (Oct 04 2018 at 16:19):

the latter - rateQuantity

Rik Smithies (Oct 04 2018 at 16:24):

thanks. Then a rateRange can also use "ratio units", and give from 10ml/h to 20ml/h. What is rangeRatio for then? For non-time ratios, like per kg of body weight?

Jean Duteau (Oct 04 2018 at 16:31):

rateRatio is used when you want to have the denominator without a unit quantity. i.e. 150ml / 10 h. Which is equivalent to a rateQuantity of 15ml/h.

Oliver Egger (Oct 04 2018 at 16:33):

range is low, high. I need to exactly model a quantity from x ml/h to y ml/h. I'm working on an modifierExtension for that, or is there another way?

Scott Robertson (Oct 04 2018 at 18:54):

x ml/h to y ml/h:
range [
low [
quantity [
value = x
unit=ml/h
]
high [
quantity [
value=y
unit=ml/h]
]
]

Scott Robertson (Oct 04 2018 at 18:54):

(my indenting didn't work)

Arianne van de Wetering (Oct 08 2018 at 11:46):

rateRatio is used when you want to have the denominator without a unit quantity. i.e. 150ml / 10 h. Which is equivalent to a rateQuantity of 15ml/h.

My use case for using rateRatio over rateQuantity is different.

Our requirements state that the amount of product in the numerator should be communicated in a codeSystem different than UCUM (reason is that business rules regarding medication safety are also stated in this particular codeSystem). So we use rateRatio even with a denominator quantity of 1:

<rateRatio>
                  <numerator>
                     <value value="0.5"/>
                     <unit value="milliliter"/>
                     <system value="urn:oid:2.16.840.1.113883.2.4.4.1.900.2"/>
                     <code value="233"/>
                  </numerator>
                  <denominator>
                     <value value="1"/>
                     <unit value="uur"/>
                     <system value="http://unitsofmeasure.org"/>
                     <code value="h"/>
                  </denominator>
</rateRatio>

This cannot be done in rateQuantity, can it?

I then get to the issue of how to represent a variable rate, like 0.2 to 0.5 ml/h, but then using the alternate codeSystem as stated above.

The only way I found to do this is using rateRange ánd UCUM.

<rateRange>
                  <low>
                     <value value="0.2"/>
                     <unit value="ml/h"/>
                     <system value="http://unitsofmeasure.org"/>
                     <code value="ml/h"/>
                  </low>
                  <high>
                     <value value="0.5"/>
                     <unit value="ml/h"/>
                     <system value="http://unitsofmeasure.org"/>
                     <code value="ml/h"/>
                  </high>
</rateRange>

How can I do this using a different codeSystem than UCUM?

Scott Robertson (Oct 08 2018 at 21:32):

This cannot be done in rateQuantity, can it?

No. Since rateQuantity only allows a single value, then complex units (e.g., ml/hr) must be used. There is no means to include a value for the denominator

How can I do this using a different codeSystem than UCUM?

from the FHIR build for Quantity.code

Comments
The preferred system is UCUM, but SNOMED CT can also be used (for customary units) or ISO 4217 for currency. The context of use may additionally require a code from a particular system.

You should be able to use your code system for the Quantity elements.

Arianne van de Wetering (Oct 09 2018 at 08:51):

You *should* be able to use your code system for the Quantity elements.

How would this work for a variable rate, like 0.2 to 0.5 ml/h ? Where I need a different codesystem for the numerator?

I think that what I am looking for is:

<rateRange>
    <low>
        <numerator>
            <value value="0.2"/>
            <unit value="milliliter"/>
            <system value="urn:oid:2.16.840.1.113883.2.4.4.1.900.2"/>
            <code value="233"/>
        </numerator>
        <denominator>
            <value value="1"/>
            <unit value="uur"/>
            <system value="http://unitsofmeasure.org"/>
            <code value="h"/>
        </denominator>
    </low>
    <high>
        <numerator>
            <value value="0.5"/>
            <unit value="milliliter"/>
            <system value="urn:oid:2.16.840.1.113883.2.4.4.1.900.2"/>
            <code value="233"/>
        </numerator>
        <denominator>
            <value value="1"/>
            <unit value="uur"/>
            <system value="http://unitsofmeasure.org"/>
            <code value="h"/>
        </denominator>
    </high>
</rateRange>

Lloyd McKenzie (Oct 09 2018 at 14:14):

If your code system can't epress ml/h, then you're going to have a problem

Arianne van de Wetering (Oct 09 2018 at 14:58):

So why was the rateRatio invented?

Rik Smithies (Oct 09 2018 at 15:41):

Apparently so that you can express 10ml per 2 hours, which cannot use ml/h even if your system can express it.

Arianne van de Wetering (Oct 09 2018 at 15:43):

Apparently so that you can express 10ml per 2 hours, which cannot use ml/h even if your system can express it.

So I understood. So suppose you have a variable rate per 2 hours. 6 to 10 ml per 2 hours. How do you express that?

Jean Duteau (Oct 09 2018 at 15:45):

You can't today without an extension because Range only accepts SimpleQuantity for low and high. You'd have to do it as 3ml/h to 5ml/h.

Alexander Henket (Oct 09 2018 at 15:46):

So should we create a ticket to create a new datatype then?

Jean Duteau (Oct 09 2018 at 15:49):

i suppose. that requirement does seem to need it.

Rik Smithies (Oct 09 2018 at 16:13):

That would be tricky I expect.

As it happens I had a similar requirement for the draft substance ingredient resource

http://build.fhir.org/medicinalproductingredient.html

See Strength.presentation, which can be a ratio, or a range of ratios.

It needs URG<RTO<PQ,PQ>> (just like the good old days).

This doesn’t exist and I didn’t think a new datatype would ever be granted.

So I modelled it as two data items. “presentation” is for when there is one value, or as a high value. And you can use the presentationLowLimit if there is a low value.

I don’t really like this but without a datatype couldn’t find a better way.

It could be an extension instead, probably a modifier extension.

Grahame Grieve (Oct 09 2018 at 16:39):

well, hang on... before we have a ticket to create a new data type, let's have plenty of analysis.

Grahame Grieve (Oct 09 2018 at 16:39):

the request is for 2 different things here: a range of ratios, and an uncertain ratio.

Grahame Grieve (Oct 09 2018 at 16:40):

is this problem dosage specific? or is it wider?

Jean Duteau (Oct 09 2018 at 16:41):

i think the initial requirements come from dosage, but it could be wider. i think that, in both cases, we need to express a range of ratios where the ratio can't be expressed as a quantity, i.e. 6mg / 2hrs to 10mg / 2hrs

Grahame Grieve (Oct 09 2018 at 16:46):

range is min..max? But if you can't express it as a quantity, you can't meaningfully talk about min and max...

Alexander Henket (Oct 09 2018 at 16:51):

I can use Ratio for simple cases e.g. numerator 12 ml denominator 2 h.

I cannot express 12 - 15 ml per 2 h using Range because the required code system (!= UCUM) does not support ml/2h. This code system is what makes medication safety checking click in The Netherlands. A statement like "why not change that all to UCUM" is a big thing to ask

Alexander Henket (Oct 09 2018 at 16:53):

Basically: if the case can be made for Range (IVL_PQ), then why could there not be a case for RateRange (IVL_RTO)?

Grahame Grieve (Oct 09 2018 at 17:07):

maybe a case can be made. I'm just seeking understanding here. Is the denominator fixed with a min/max numerator? or is life more complicated?

Alexander Henket (Oct 09 2018 at 17:38):

Not sure what you're asking? Just like with the units on Range, you may expect that denominator would be the same for low and high. Is that your answer?

Lloyd McKenzie (Oct 09 2018 at 17:38):

Also, in considering the change request, be sure to evaluate whether most systems would support this.

Alexander Henket (Oct 09 2018 at 17:39):

So something like 10 ml/h to 10 ml/2h would not happen.

Alexander Henket (Oct 09 2018 at 17:41):

@Lloyd McKenzie I can only speak for The Netherlands. Variable ratios are normally clinical/inpatient type of things, e.g. not expected from the GP. Any clinical/inpatient system in the Netherlands would be expected to support this. I expect the use case to be global, but I don't know about structured recording/exchange of this.

Grahame Grieve (Oct 09 2018 at 17:43):

also part of the analysis: how would this be represented in CDA or v2?

Alexander Henket (Oct 09 2018 at 19:02):

v2: don't know. we seldom do any pharmacy in v2
v3: is on our todo list as it stands today. v3 is going to be an issue because rateQuantity is IVL_PQ and as we already know that is not going to cut it. Also v3 requires UCUM, so at minimum UCUM should be implemented. A first stab from the top of my head and knowingly not semantically sound:

<rateQuantity xsi:type="IVL_PQ">
    <low value="12" unit="ml/2h">
        <translation value="10" code="233" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="Milliliter"/>
        <translation value="2" code="123" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="Uur"/>
    </low>
    <high value="15" unit="ml/2h">
        <translation value="15" code="233" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="Milliliter"/>
        <translation value="2" code="123" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="Uur"/>
    </high>
</rateQuantity>

Grahame Grieve (Oct 09 2018 at 19:10):

great. it's ok that something isn't supported on v2/v3 (well, it is from FHIR's viewpoint. Just need to check that that analysis is ok)

Grahame Grieve (Oct 09 2018 at 19:11):

procedurally, I don't think a new data type is a candidate for R4 even as informative. Though I think there's room for debate on this

Alexander Henket (Oct 09 2018 at 19:14):

Understood. We will need a solution in STU3 first anyway. It's going to be through extensions in a place where you rather not have them. Core extensions would likely be beneficial since our use case is not "Dutch", just less common.

Grahame Grieve (Oct 09 2018 at 19:16):

"extension" : [{
  "url" : "http://....",
  "extension" : [{
     "url" : "minNumerator",
     "valueQuantity" : { ...}
  },{
     "url" : "maxNumerator",
     "valueQuantity" : { ...}
  },{
     "url" : "denominator",
     "valueQuantity" : { ...}
  }]
}]

Grahame Grieve (Oct 09 2018 at 19:18):

going to be something like this

Alexander Henket (Oct 09 2018 at 19:22):

The element to work with is Dosage.rate. So we either extend rateRatio or rateRange. Seems most reasonable to go with rateRange.

• rateRange will carry low 12 ml/2h and high 15 ml/2h.
• For both low and high we can then extend with a complex extension of datatype Ratio that carries the expression compatible with our Dutch code system.

Alexander Henket (Oct 09 2018 at 19:23):

In your solution: would you forego the Dosage.rate element altogether or would you go with:

<rateRange>
   <extension (as you suggested)>
   <low>
  <high>
</rateRange>

Alexander Henket (Oct 09 2018 at 19:26):

I think that extending rateRange with your extension is easier and more elegant and likely to be interpreted better by systems that do not follow the extension

Alexander Henket (Oct 09 2018 at 19:28):

I'd probably suggest lowNumerator and highNumerator to stay close to Range. I like your 1 denominator because it saves enforcing an invariant.

Jean Duteau (Oct 09 2018 at 19:30):

yes, i agree with your agreement of Grahame's extension. :)

Alexander Henket (Oct 09 2018 at 19:31):

Are you mocking me sir? :-)

Grahame Grieve (Oct 09 2018 at 19:32):

it might be tempting to do some inplace extension inside Ratio, but that won't play well once you get a real data type for this.

Grahame Grieve (Oct 09 2018 at 19:32):

..assuming that will happen

Alexander Henket (Oct 09 2018 at 19:34):

... counting on it :-) After all this: are we ready to file a ticket and what would best serve the case at hand? A datatype, a core extension, something else? Or just file a clarification request to how to best handle the use case and let the WGs decide?

Grahame Grieve (Oct 09 2018 at 19:36):

I'm not convinced we're done on the analysis yet. how would that extension play out for Rick's work? Is it the right information?

Grahame Grieve (Oct 09 2018 at 19:42):

.. and the ticket will probably say:

• define an extension for this for R4 (which could also be used in R3)
• define a data type for this in R5

Jean Duteau (Oct 09 2018 at 19:43):

From what I know of the Strength.presentation (and Strength.concentration), this would work for him. I'm not sure if he has different denominators for the low and high, but the IDMP examples that I have don't.

Alexander Henket (Oct 09 2018 at 19:45):

Ok. I'll wait for Riks input before moving forward.

Lloyd McKenzie (Oct 09 2018 at 21:17):

Do you have a need for a denominator value of 1? Do you actually need anything other than the denominatory unit?

Jean Duteau (Oct 09 2018 at 23:02):

We do need a simple quantity for the denominator because it is expressing (5ml - 10ml) / 2h

Rik Smithies (Oct 10 2018 at 11:52):

Ingredient presentation strength could need non-unitary denominator (e.g. a low and high possible amount in a 5ml spoonful) but not different denominators for low and high. So it looks like that extension would work.

Yunwei Wang (Oct 10 2018 at 15:48):

Apparently so that you can express 10ml per 2 hours, which cannot use ml/h even if your system can express it.

I am little bit confused. Why cannot this be rateQuantity 5 ml/hr?

Lloyd McKenzie (Oct 10 2018 at 16:20):

ml/hr isn't a supported code in the code system they want to use.

Grahame Grieve (Oct 10 2018 at 17:01):

5mL/hr is equivalent to but not equal to 10mL/2hr and also there is a clinical safety issue in that people operationally often miss the unit. but you can do 10mL/2hr in UCUM:

{
  "value" : "10",
  "code" : "mL/2.hr",
  "system" : "http://unitsofmeasure.org"
}

Arianne van de Wetering (Oct 16 2018 at 06:43):

Rik seems ok with this solution

Ingredient presentation strength could need non-unitary denominator (e.g. a low and high possible amount in a 5ml spoonful) but not different denominators for low and high. So it looks like that extension would work.

Are we ready for a ticket as per @Grahame Grieve's suggestion?

.. and the ticket will probably say:
define an extension for this for R4 (which could also be used in R3)
define a data type for this in R5

Grahame Grieve (Oct 16 2018 at 06:43):

yes I think we are now

Arianne van de Wetering (Oct 16 2018 at 07:44):

Tracker item: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=19416

Craig McClendon (Nov 07 2018 at 20:22):

@Grahame Grieve To express 10ml every 2 hours, would't the UCUM code need to have parentheses around the denominator? i.e. mL/(2.h) ?

Grahame Grieve (Nov 08 2018 at 01:15):

yes you're right

Rik Smithies (Aug 07 2019 at 15:33):

hi GF#19416 was closed on 2019-Jan-29 but what happened to it please? Was an extension or datatype created? Did it become a todo item? @Arianne van de Wetering @Jean Duteau @Alexander Henket

Grahame Grieve (Aug 07 2019 at 21:47):

status is "Resolved, change required" - so yes, a todo item

Rik Smithies (Aug 08 2019 at 08:11):

thanks, but how is that tracked if not in the tracker?

Grahame Grieve (Aug 08 2019 at 08:31):

it is in the tracker - look at the status

Rik Smithies (Aug 08 2019 at 09:58):

thanks. I had seen that but I assumed that the "resolved" part, and the fact that the tracker has a close date, meant this tracker was now done with. A closed tracker can still be active as change request I take it?

Lloyd McKenzie (Aug 08 2019 at 18:53):

"Resolved" is something that happens automatically and is largely irrelevant. What we care about is the status.

Rik Smithies (Aug 10 2019 at 14:07):

The status is "Resolved - Change required". But the item has a close date, so is presumably closed. Are we saying that the close date is irrelevant?

Lloyd McKenzie (Aug 10 2019 at 15:04):

We categorize "Resolved - Change required" as "closed". It's not truly "done" until it gets to "published" though.

Lloyd McKenzie (Aug 10 2019 at 15:05):

"closed" represents the work group decision perspective, not the editor perspective.

Last updated: Apr 12 2022 at 19:14 UTC