FHIR Chat · Fluit intake and Output Profile · implementers

Stream: implementers

Topic: Fluit intake and Output Profile


view this post on Zulip Pranitha Sruthi (Aug 16 2017 at 13:05):

Hi all, I need to create a profile for fluid intake(intravascular, oral etc) using the resource Observation and need to capture the duration (for example "fluid intake intravascular 1 hour") along with the type (lipid or medication). Do I need to create an extension for duration or use the element "effectivePeriod"? Thank you

view this post on Zulip Lloyd McKenzie (Aug 16 2017 at 13:37):

If you know the start and end times, then by all means use effectivePeriod. If you can't get the duration pre-coordinated into the Observation.code, then you'll need an extension. You might also submit a change proposal suggesting either a standard extension or new core element.

view this post on Zulip Robert McClure (Aug 16 2017 at 14:12):

@Pranitha Sruthi If this is like the other observation you asked about (I.E; drain ouput) and the DURATION period is not a specific known start/end, then LOINC would expect you to pre-coordinate the observation into a new LOINC code because the expectation is someone would request such an observation. I'm not completely on board with this assumption, but it's how I understand LOINC and UCUM work. I say DURATION versus RATE because there are exsisting LOINC codes focused on rate, such as 8976-3 Fluid intake intravascular 1 hour which has a unit that assumes a per hour rate and not so much a duration that communicates a specific single hour duration. I wonder how we communicate a specific duration when a specific start and end is not known. @Lloyd McKenzie - can you help me understand how this is to be done?

view this post on Zulip Lloyd McKenzie (Aug 16 2017 at 14:51):

We'd need a new data element - thus the recommendation to use an extension and to propose a change to the resource. I agree LOINC typically expects the duration to be pre-coordinated. However, sometimes "non-standard" durations get used and sometimes people use code systems other than LOINC. So a new data element is probably reasonable.

view this post on Zulip Lloyd McKenzie (Aug 16 2017 at 14:52):

It would be similar to Observation.methodCode - where that's also typically pre-coordinated into LOINC

view this post on Zulip Eric Haas (Aug 16 2017 at 16:35):

will be considering adding Timing as a choice which should handle duration?

view this post on Zulip Lloyd McKenzie (Aug 16 2017 at 19:39):

That would mean you couldn't capture any details about start or end if you do duration. Is that reasonable?

view this post on Zulip Eric Haas (Aug 16 2017 at 20:52):

For "Gave IV bolus 500ml for one hour on Thursday"

Timing.event = dateTime(Thursday)
Timing.repeat.count = 1
Timing.repeat.duration = 1
Timing.repeat.durationUnit= hr

view this post on Zulip Eric Haas (Aug 16 2017 at 20:55):

(I noticed the Timing elements descriptions are still future tense .... )

view this post on Zulip Eric Haas (Aug 16 2017 at 20:56):

if you know the start and end you would not need to use timing. timing is for fuzzy times and for repeating patterns

view this post on Zulip Eric Haas (Aug 16 2017 at 20:57):

If using for Observations

view this post on Zulip Lloyd McKenzie (Aug 17 2017 at 03:28):

I think there's some value in making duration explicit even if you have start and end, though agree it's less critical. I hadn't considered using Timing.event with Timing.repeat, though apparently that's allowed, so I guess that would be a legal representation.

view this post on Zulip Pranitha Sruthi (Aug 17 2017 at 06:45):

@Lloyd McKenzie thank you
@Robert McClure I also have to capture a modifier called "type" which specifies the type of fluid (lipid or medication) in the profile.

view this post on Zulip Jose Costa Teixeira (Aug 17 2017 at 09:58):

I noticed the "using observation".. If the fluid intake is medication, is that an observation? I don't know the context, but making an observation for fluid intake and then using "type" to say that it is a medication administration seems not interoperable.

view this post on Zulip Jose Costa Teixeira (Aug 17 2017 at 10:00):

@Eric Haas if the fluid is nutrition, this falls under the nutrition discussion, right? this was discussed a few days ago.
and I think we should look for a pattern for "administration/intake", of which these things are clearly guided specifications.
No implementer should have any doubt whether to use an administration or an observation.

view this post on Zulip Lloyd McKenzie (Aug 17 2017 at 14:51):

@Jose Costa Teixeira If your focus is measuring the amount of fluid in and out (and not the administration of any particular medication), then Observation is correct.
@Pranitha Sruthi Again, most typically this would be pre-coordinated into the code. If not, you could capture it as an Observation.component

view this post on Zulip Eric Haas (Aug 17 2017 at 15:04):

@Eric Haas if the fluid is nutrition, this falls under the nutrition discussion, right? this was discussed a few days ago.
and I think we should look for a pattern for "administration/intake", of which these things are clearly guided specifications.
No implementer should have any doubt whether to use an administration or an observation.

@Jose Costa Teixeira you are right. I didn't see the forest for the trees - to focused on the Timing datatype. IV fluid is a MedAdmin or MedStatement. An oral intake ( I drank a glass of water yesterday ) would have to be observation right now but we are looking at a NutritionIntake resource that is modeled after MedAdmin for this.

view this post on Zulip Pranitha Sruthi (Aug 18 2017 at 05:16):

@Lloyd McKenzie ok thank you


Last updated: Apr 12 2022 at 19:14 UTC