FHIR Chat · OrderSets · implementers

Stream: implementers

Topic: OrderSets

Andrew Ross (Mar 17 2016 at 15:37):

We're making a CDS system that recommends templates for sets of treatments. We're planning on using OrderSet to represent these recommendations because it seems tailored to do just that. However, these treatment set templates need codings because they need to be mapped across different systems. We're thinking of using OrderSet.action.concept for those codings. Just want to sanity-check all of that -- does that seem sound?

Bryn Rhodes (Mar 17 2016 at 15:43):

Hi Andrew, yes, that's the intent of that element, to provide meaning to the action so it can be shared between different systems.

Bryn Rhodes (Mar 17 2016 at 15:43):

And I don't know if you saw it yet, but I added the relatedAction element there to support relationships between actions, I still owe you an example there, but does that element look like it will support the relationships you need?

Andrew Ross (Mar 17 2016 at 15:45):

cool. The other question we have is -- let's say the doctor decides to use this particular OrderSet. We'd want to then create a CarePlan based off of the OrderSet

Andrew Ross (Mar 17 2016 at 15:45):

We could programmatically construct the exact CarePlan, but we'd actually prefer to just make a POST with a reference to the OrderSet

Andrew Ross (Mar 17 2016 at 15:46):

How would you recommend structuring that CarePlan POST request to reference the OrderSet?

Andrew Ross (Mar 17 2016 at 15:47):

maybe just CarePlan.activity.detail.code?

Andrew Ross (Mar 17 2016 at 15:48):

er, or CarePlan.activity.reference?

Bryn Rhodes (Mar 17 2016 at 16:05):

So, typically with the order sets that we've encountered, there are choices that the practitioner makes as part of using the order set. Do you have that in your order sets?

Andrew Ross (Mar 17 2016 at 17:29):

@Bryn Rhodes could you clarify what you mean by that? we're considering each order set (each template of treatments) as an individual choice, and the doctor just picks one of them. it's possible there could be sub-choices/sub-options eventually within the order set, so i guess if we structured everything to support that possibility it wouldn't be the end of the world

Andrew Ross (Mar 17 2016 at 17:30):

but even so, what the practitioner would be choosing is still something like a full OrderSet

Bryn Rhodes (Mar 17 2016 at 17:39):

Okay, that makes sense, but I wonder if it wouldn't be an operation against the OrderSet? Something like OrderSet/XYZ$place...?

Bryn Rhodes (Mar 17 2016 at 17:39):

That operation would then be where the realization of the OrderSet actually occurred.

Andrew Ross (Mar 17 2016 at 17:40):

Sure, that makes sense

Bryn Rhodes (Mar 17 2016 at 17:40):

I'll mock something up then so we can have an example to discuss further.

Andrew Ross (Mar 17 2016 at 17:40):

it wouldn't be POST /OrderSets, because we're not creating an OrderSet, but it could be POST /OrderSets/:id/place? with patient params

Andrew Ross (Mar 17 2016 at 17:40):

ok

Bryn Rhodes (Mar 17 2016 at 17:41):

Right, exactly.

Andrew Ross (Mar 17 2016 at 17:41):

but the resource that gets created probably would be a CarePlan, at least in our case

Andrew Ross (Mar 17 2016 at 17:41):

maybe not in every case

Lloyd McKenzie (Mar 17 2016 at 17:41):

The intention is to update CarePlan (and all other "requestish" resources to be able to point to a "Protocol/Orderset" they're based on. Note that this won't generate a fully populated care plan. If you want that, you'll need an operation, not a simple POST.

Andrew Ross (Mar 17 2016 at 17:41):

ok

Andrew Ross (Mar 17 2016 at 17:42):

that makes sense to me

Bryn Rhodes (Mar 17 2016 at 17:42):

Right, this would be an operation, but against the OrderSet that may generate a CarePlan.

Andrew Ross (Mar 17 2016 at 17:42):

i feel like it's more RESTful to POST to the resource you're hoping to create

Andrew Ross (Mar 17 2016 at 17:42):

but perhaps both could be supported?

Andrew Ross (Mar 17 2016 at 17:43):

for "template" resources like this it needs to be clear how to create the realized resource given the necessary patient/time/practitioner context

Bryn Rhodes (Mar 17 2016 at 17:43):

Well, I think the POST to a CarePlan would be if you manually realized the OrderSet, but if you want the server to realize it, seems like an operation would be necessary.

Andrew Ross (Mar 17 2016 at 17:46):

right. i guess in our case the main server we're integrating with already knows how to draft a care plan (or its internal representation of this type of care plan) from a reference to the order set

Andrew Ross (Mar 17 2016 at 17:46):

but we want to structure that request in a way that will be compatible with other systems we integrate with

Andrew Ross (Mar 17 2016 at 17:47):

all of whom will have pretty formalized representations of this type of care plan (template), but not necessarily identical ones

Andrew Ross (Mar 17 2016 at 17:54):

also -- apologies, this is a very nitpicky question, but ActionDefinition.concept appears to be an array (0..* elements) even though each element is itself a CodeableConcept with 0..* elements in coding. Is there any reason why we should have an array of arrays of codings on an ActionDefinition?

Andrew Ross (Mar 17 2016 at 17:56):

and another nitpicky question -- it looks like OrderSet.action is a 0..* array too. we were hoping to use OrderSet.action.concept to represent the entire order set's coding, but if there can be multiple actions, shouldn't that codeable concept be at the top level?

Andrew Ross (Mar 17 2016 at 17:58):

if there was always _one_ top-level action (which could have 0..* sub-actions), that would work, but i guess it would be best to just have OrderSet.concept.

Andrew Ross (Mar 17 2016 at 18:00):

that or have moduleMetadata.concept

Bryn Rhodes (Mar 17 2016 at 18:10):

The reason there are multiple concepts on the action is that each Coding within a given CodeableConcept should be equivalent, so to express two different concepts, you'd need two different CodeableConcepts. And you may have multiple meanings (from different perspectives) that you want to attach to each action within the order set.

Bryn Rhodes (Mar 17 2016 at 18:10):

As far as a concept to represent the entire order set, yes, that would be more appropriate in the metadata.

Andrew Ross (Mar 17 2016 at 18:10):

ok

Andrew Ross (Mar 28 2016 at 20:30):

@Bryn Rhodes , from before -- any updates on how relative timings of actions should be specified

Bryn Rhodes (Mar 28 2016 at 20:52):

Hi @Andrew Ross, yes, the relatedAction element of the ActionDefinition that is used to specify the actions of an order set can be used to define relative timings between items in the order set:

Bryn Rhodes (Mar 28 2016 at 20:52):

https://hl7-fhir.github.io/actiondefinition-definitions.html#ActionDefinition.relatedAction

Bryn Rhodes (Mar 28 2016 at 20:53):

Each action defines an identifier that you can use to point to it.

Bryn Rhodes (Mar 28 2016 at 20:53):

The relationship allows you to specify before/after and a relative offset.

Andrew Ross (Mar 28 2016 at 20:53):

great, thank you!

Andrew Ross (Mar 29 2016 at 14:11):

hi @Bryn Rhodes , one more question about action definitions and timings. Right now I've found a really good way to represent everything about the relative timings of my actions, except for the total length of time of an action. And I have a way of getting around it but it makes things less modular.

Let me give a bit more detail -- I'm working with chemotherapy regimens, and there are 2 "courses" of chemotherapy, each of which I want to represent as their own top-level action. The second course starts after the first course. What I would like to do is say that the second course has a related action equal to the first course, and it starts after the first course ends. However, it seems like I have no way of specifying exactly how long the first course lasts (the first course has subactions with relative offsets, but its full length is a little bit longer than the longest offset).

I could get around this by just creating a parent action that represents both courses, then giving the second course a relative offset of the exact amount of time of the first course. However, it feels hacky, because I'm specifying the length of the first course on the second course, and also if the first course ends up being lengthened for any reason, the second course would be delayed, so I'd like to express it more semantically.

Any thoughts? I can make what is there work (and once again, it's awesome), but I feel like the current spec is missing a "duration" attribute for action definitions.

Andrew Ross (Mar 29 2016 at 14:16):

also... if i wanted to be really greedy, I would also ask for a "repeat" attribute as well, but it's not as necessary

Andrew Ross (Mar 29 2016 at 14:17):

that one might not make as much sense, maybe. but the duration seems important

Bryn Rhodes (Mar 29 2016 at 14:32):

What are the targets of your action? MedicationAdministration?

Andrew Ross (Mar 29 2016 at 14:32):

yes

Andrew Ross (Mar 29 2016 at 14:32):

or MedicationOrder, not sure which is more appropriate

Bryn Rhodes (Mar 29 2016 at 14:35):

MedicationOrder, which would then be converted to a MedicationAdministration by the workflow of actually doing the administering. Or at least, that's my reading of it. So you're using the Timing within the MedicationOrder, but it doesn't allow you to specify both the overall duration and the timing of the specific instance, right?

Bryn Rhodes (Mar 29 2016 at 14:36):

Because it's something like "administer this medication weekly for 12 weeks"?

Andrew Ross (Mar 29 2016 at 14:36):

something like that. i think it's fine for us to just make 12 separate sub-actions for each order

Andrew Ross (Mar 29 2016 at 14:37):

but we want to say "this whole cycle is 12 full weeks"

Andrew Ross (Mar 29 2016 at 14:37):

because the last sub-action takes place at the start of the 12th week

Andrew Ross (Mar 29 2016 at 14:37):

not the end

Andrew Ross (Mar 29 2016 at 14:37):

and then we want the next cycle to start at the start of the 13th week

Bryn Rhodes (Mar 29 2016 at 14:39):

Yeah, would be nice to be able to model that with a repeat somehow so you don't have to repeat each action.

Andrew Ross (Mar 29 2016 at 14:39):

it's true, but sometimes there are slight differences in later repeats

Andrew Ross (Mar 29 2016 at 14:39):

so it might be too complicated

Andrew Ross (Mar 29 2016 at 14:39):

and it's maybe harder for implementers

Andrew Ross (Mar 29 2016 at 14:39):

but -- the main thing is to say that the second cycle should start after the first cycle

Andrew Ross (Mar 29 2016 at 14:40):

i guess the "anchor"ing doesn't make sense without the duration

Bryn Rhodes (Mar 29 2016 at 14:40):

Right, so put all the first cycle actions within a containing action, and then set up the relationship to that container.

Andrew Ross (Mar 29 2016 at 14:40):

right, that works, but it requires specifying the second cycle relative to the root

Andrew Ross (Mar 29 2016 at 14:40):

rather than the first

Andrew Ross (Mar 29 2016 at 14:41):

e.g. saying the second cycle starts 13 weeks after the start

Andrew Ross (Mar 29 2016 at 14:41):

so we're effectively defining the length of the first cycle but only on the second cycle

Bryn Rhodes (Mar 29 2016 at 14:46):

I see, you could set it to be after the last action of the first cycle though, right?

Bryn Rhodes (Mar 29 2016 at 14:47):

So each action in the first cycle starts after the previous one by a week.

Andrew Ross (Mar 29 2016 at 14:55):

it's true, but it feels a bit icky to me

Andrew Ross (Mar 29 2016 at 14:55):

semantically, the second cycle starts after the end of the first one

Andrew Ross (Mar 29 2016 at 14:55):

that's what the current modeling seems to encourage

Andrew Ross (Mar 29 2016 at 14:55):

it's just missing a way to say when "the end of the first one" is

Andrew Ross (Mar 29 2016 at 14:56):

if you're going to have a concept of anchoring something to the end of an action, there needs to be a way to specify when that action ends

Bryn Rhodes (Mar 29 2016 at 14:57):

Yeah, the reason I didn't put that in though was that's dependent on the type of the target. So a MedicationOrder has a Timing that says how long it is.

Andrew Ross (Mar 29 2016 at 14:57):

right, it's true

Andrew Ross (Mar 29 2016 at 14:57):

that works when the action is a single resource

Andrew Ross (Mar 29 2016 at 14:58):

anyway, it's just a suggestion -- we can work around it by adding a parent action

Bryn Rhodes (Mar 29 2016 at 14:58):

I realize that then becomes an implementation complexity, but I wanted to avoid introducing a redundant element if possible.

Andrew Ross (Mar 29 2016 at 14:58):

yeah

Andrew Ross (Mar 29 2016 at 14:58):

i just feel like it completes what's there, logically

Andrew Ross (Mar 29 2016 at 14:59):

but maybe it's worth sitting and thinking about it more

Bryn Rhodes (Mar 29 2016 at 15:00):

Yeah it makes sense and the chemotherapy order sets are particularly detailed so it's a great use case and I appreciate you working through it. I'll look at adding a duration there. With the repeat it would allow for some economy there too.

Andrew Ross (Mar 29 2016 at 15:02):

sounds good, and thanks.

Ian McNicoll (Mar 29 2016 at 15:06):

Is this chemotherapy use case published / available anywhere? I am working on an equivalent openEHR medication order /timing model for use inside systems, but high expectation that FHIR will be used for data exchange, and I am trying to ensure that we stay closely aligned. The chemo test case would be a helpful 'stress test'.

Andrew Ross (Mar 29 2016 at 15:08):

@Ian McNicoll i might be able to send you some of what we've been working on, and we've been talking to other organizations that are doing the same thing. let me get back to you after i check if it's okay

Ian McNicoll (Mar 29 2016 at 15:09):

@Andrew Ross many thanks

Andrew Ross (Mar 30 2016 at 15:13):

@Ian McNicoll and @Bryn Rhodes -- here is a gist where I laid out how we're thinking of representing and querying chemotherapy templates as order sets: https://gist.github.com/asross/e32c7735e20f356d34fc16b49c261cb9

Andrew Ross (Mar 30 2016 at 15:14):

let me know what you think. i did add duration to ActionDefinition because it made the representation more concise, let me know what you think

Andrew Ross (Mar 30 2016 at 15:14):

also important is whether we're using moduleMetadata.identifier and moduleMetadata.topic correctly

Andrew Ross (Mar 30 2016 at 15:15):

...and finally, if there's any update on how a CarePlan might eventually point back to the OrderSet it was placed from, let me know (cc @Lloyd McKenzie )

Lloyd McKenzie (Mar 30 2016 at 16:56):

There's an intention that all "request" type resources, including CarePlan will have the ability to point to a protocol. That was recently approved for CarePlan by PC. It will point to Questionnaire, Protocol and OrderSet (though there's some rationalization that needs to happen for Protocol/OrderSet)

Bryn Rhodes (Apr 01 2016 at 01:16):

@Andrew Ross Very nice, I commented on the gist. And I have on my list to bring up adding a duration element to the action definition.

Andrew Ross (Apr 02 2016 at 00:59):

Thanks @Bryn Rhodes . I replied with a few more thoughts.

Lee Surprenant (Apr 11 2016 at 21:13):

@Andrew Ross thanks for putting together the sample. I'm working with NCCN to express their order templates in FHIR and we have similarities and differences with your approach. In particular, I have some concerns with the 'flattening' of the schedule data

Lee Surprenant (Apr 11 2016 at 21:16):

two different reasons
1. in definitional resources like these we often have optionality that makes it hard to flatten.
example: 14- or 21-day cycle for 2 – 4 cycles
2. ongoing/pattern-based definitions where you repeat some cycle indefinitely or until some condition is met

Lee Surprenant (Apr 11 2016 at 21:17):

@Bryn Rhodes I discussed our current approach with Andrew where we use Timing datatype to represent the cycle definition. Wondering if it would make sense to add that datatype to your ActionDefinition so that it could still be used to express the definition of some repeating schedule

Bryn Rhodes (Apr 12 2016 at 02:27):

Hi @Lee Surprenant thanks for the suggestion, I will add it to the discussion for Wednesday morning's CQF-on-FHIR call, as well as bring it up in the CDS WG.

Andrew Ross (Apr 12 2016 at 13:50):

@Bryn Rhodes @Lee Surprenant one difficulty i foresee with that kind of optionality is that it makes the OrderSet $place operation ambiguous unless you provide additional parameters to resolve it

Andrew Ross (Apr 12 2016 at 13:51):

e.g. if the second chemo course is 2-4 cycles, you need to pass or be able to pass some kind of structured parameter to nail it down

Andrew Ross (Apr 12 2016 at 13:51):

as an architectural question, what should a "template" require to be realized?

Andrew Ross (Apr 12 2016 at 13:52):

right now i think the vision is that OrderSet just needs a patient and some basic clinical context to generate a CarePlan

Andrew Ross (Apr 12 2016 at 13:53):

but we are encountering looser concepts of templates that might require more parameters

Andrew Ross (Apr 12 2016 at 13:59):

it's also worth noting that the medication quantities in these regimens are expressed over patient weight or patient body surface area (or other characteristics) -- so to be translated into a "real" care plan, they need to potentially query patient observations and do unit-aware multiplication

Lee Surprenant (Apr 12 2016 at 14:03):

I have heard from others that these medications are often ordered this way as well (by mg/m2)...not sure when it finally resolves to an actual amount

Andrew Ross (Apr 12 2016 at 14:04):

ah, ok. i guess if they don't need to be resolved before ordering, we don't need that as a parameter

Lee Surprenant (Apr 12 2016 at 14:05):

but I think your point about other optionality is still spot-on. in my example above the 14 or 21 day cycle bit could probably be split into two different regimen options, but I don't think we'd want to do that with the 2-4 cycles part

Andrew Ross (Apr 12 2016 at 14:05):

we have had to deal with that issue in our CDS system a few times, e.g. when computing the expected cost

Andrew Ross (Apr 12 2016 at 14:05):

right

Andrew Ross (Apr 12 2016 at 14:05):

especially if there are multiple axes of optionality, the total number of options will combinatorically explode

Andrew Ross (Apr 12 2016 at 14:08):

realistically though, i think in the systems we've worked with where we're actually dealing with placing orders, we might help pick the regimen but the doctor is still taken to a (domain-specific) order placing page where they resolve all of the ambiguities themselves, and can finalize the order. so ultimately the final details of the chemotherapy aren't being set through a standards-based API, the doctor is entering them on an application-specific UI screen

Andrew Ross (Apr 12 2016 at 14:10):

but we want to try to get past that if we can

Bryn Rhodes (Apr 12 2016 at 15:14):

That's true. The intent of the OrderSet was always to enable that kind of functionality though. I do like the idea of having different levels of support, so a consuming system could work with the level of Order Set appropriate to their capabilities.

Oliver Krauss (Apr 20 2016 at 11:10):

Hello, I have questions concerning OrderSet/Protocol.

Should Protocol/OrderSet also support organizational processes such as tumor boards or is there a different Resource planned for this?

Should we think about process-abstraction? For example re-usable process steps/activities in Protocol, similar to how ActionDefinition is reusable in OrderSet. To my recollection we didn't talk about reusability yet in the workflow-calls.

Lloyd McKenzie (Apr 20 2016 at 13:46):

See discussion here: https://chat.fhir.org/#narrow/stream/workflow/subject/Protocol

Lee Surprenant (May 05 2016 at 14:58):

just finished first attempt at mapping nccn chemo order template to OrderSet resource: https://gist.github.com/lmsurpre/1c0e38ab868b503b37df352dddc39626

Lee Surprenant (May 05 2016 at 14:58):

main differences from what @Andrew Ross did earlier are
1. included additional info like indications / emetic risk schedule / cautionary notes
2. used a timing extension in the parent activity instead of attempting to flatten the schedule
3. included relativeTime extension on the medicationOrder resources instead of putting all timing data into the action attribute

Andrew Ross (May 05 2016 at 15:32):

@Lee Surprenant awesome, thanks for sharing. the only thing i feel a little strange about is how the MedicationOrder combines days 1 and 8 (and requires a reference to periodStart outside of the ActionDefinition). i feel like, especially for systems that have already implemented MedicationOrder processing using FHIR, it would be hard to make that work. instead I would just list two actions within the ActionDefinition section, with offsets of 1 and 8 days, since there's already support for that within that resource

Andrew Ross (May 05 2016 at 15:33):

i do like the cycle extension within the ActionDefinition though, and I think that's a great candidate for inclusion in the actual spec

Andrew Ross (May 05 2016 at 15:34):

if ActionDefinition supports cycles with variable length/repeats, then I think we can represent everything else without the need for any more timing-related extensions

Lee Surprenant (May 05 2016 at 15:34):

I really wonder how these things are 'ordered' in practice. Are they ordered 1 day at a time?

Lee Surprenant (May 05 2016 at 15:34):

what if it was days 1-4

Andrew Ross (May 05 2016 at 15:35):

right, would you really want to list out four orders?

Andrew Ross (May 05 2016 at 15:35):

that doesn't seem terrible to me, but it could get worse

Andrew Ross (May 05 2016 at 15:35):

i can ask people that actually work on that part of the EHR we're interfacing with

Lee Surprenant (May 05 2016 at 15:35):

that would be awesome

Lee Surprenant (May 05 2016 at 15:36):

i can ask around a bit as well

Andrew Ross (May 05 2016 at 15:36):

cool. might take me a little bit of time to get back but i should be able to get input from them within a week or so.

Lee Surprenant (May 05 2016 at 15:36):

great

Lee Surprenant (May 05 2016 at 15:36):

you planning to attend WGM next week in Montreal?

Lee Surprenant (May 05 2016 at 15:36):

or maybe Daniel/someone else from the group gonna be there?

Andrew Ross (May 05 2016 at 15:37):

i was hoping to go, but i've got family in town that weekend

Andrew Ross (May 05 2016 at 15:37):

i'm not sure if anyone else from our group is going

Andrew Ross (May 05 2016 at 15:37):

definitely seems like it would be super useful

Lee Surprenant (May 05 2016 at 15:37):

ok, we made last-second decision to go. would be pretty cool to meet up if someone is gonna be there (wednesday looking best)

Andrew Ross (May 05 2016 at 15:38):

hmm, middle of the week might be more plausible. i'll check in with folks here again and see if something can happen

Andrew Ross (May 05 2016 at 15:38):

if there's any more detailed schedule information about oncology-specific FHIR things happening, let me know

Lee Surprenant (May 05 2016 at 15:39):

k. i'm not that well hooked in, just know that CDS has convo with CarePlan on wed 3Q that Bryn thinks it would be good to attend (think i copied you on that note)

Lloyd McKenzie (May 06 2016 at 22:33):

We could organize an informal "birds of a feather" session on OrderSet/Protocol Wed. Q6 as well (after the reception)

Andrew Ross (May 10 2016 at 20:18):

@Lee Surprenant here's my attempt at structuring an OrderSet with cycles, using only one very basic extension: https://gist.github.com/asross/65077e4237f43692f519794fe171b768

Lee Surprenant (May 10 2016 at 20:22):

Thanks, Andrew. Looks like you were able to represent 'Days 1 and 8' using the standard Timing datatype (via a period of 7 days)

Lee Surprenant (May 10 2016 at 20:22):

Bryn and I discussed that as well, it may be a possibility but some of these regimen get pretty complicated

Lee Surprenant (May 10 2016 at 20:22):

Days 1 – 4, 9 – 12, and 17 – 20

Lee Surprenant (May 10 2016 at 20:23):

Days 1, 2, 4, 5, 8, 9, 11, and 12

Andrew Ross (May 10 2016 at 20:24):

ah, right. it would be nice if Timing could support a list of offsets like that -- and it ought to, if that's how individual orders are represented in EHRs

Lee Surprenant (May 10 2016 at 20:24):

so, there is a pattern to all of the ones I've looked at so far, but expressing those just via period seems a quite tricky

Lee Surprenant (May 10 2016 at 20:24):

maybe a question for your colleagues?

Andrew Ross (May 10 2016 at 20:24):

i can ask if a regimen to be administered on days 1 – 4, 9 – 12, and 17 – 20 would still be represented by a single order

Lee Surprenant (May 10 2016 at 20:25):

yeah, good quesiton

Andrew Ross (May 10 2016 at 20:26):

it still really feels like those "on days" timings are a concern of the MedicationOrder, while cycle start date, "on day of cycle," and "in cycles" are all concerns of the OrderSet/Protocol

Daniel Lanphear (May 10 2016 at 20:26):

days 1 – 4, 9 – 12, and 17 – 20

That would most commonly be one order

Lee Surprenant (May 10 2016 at 20:27):

@Daniel Lanphear that matches what NCCN pharmacists have told me as well

Lee Surprenant (May 10 2016 at 20:30):

which i think would make it hard to support with the 'period' construct of the current timing datatype...

Lee Surprenant (May 10 2016 at 20:31):

pardon the pseudo-code, but hopefully a bit easier to see the structure than full json/xml:

action
  <!-- would be nice if actionDefinition supported this type of timing info directly -->
  extension cycle
    valueTiming
      repeat count=6 duration=21 durationUnit=d

  actionIdentifier
    http://nccn.org/ordertemplates/KDN5/1
  textEquivalent "21-day cycle for 6 cycles"
  behavior
    type "cardinality"
    value "multiple"
  action
    detail
      code http://www.nlm.nih.gov/research/umls/rxnorm/12574 gemcitabine
      dosageInstruction
        text "1250 mg/m² IV over 30 minutes on days 1 and 8"
        timing
          extension relativeTime
            base periodStart
            offset 0d, 7d
          repeat
            duration 30 min
        route "IV"
        doseQuantity 1250 mg/m²

  action
    detail
      code http://www.nlm.nih.gov/research/umls/rxnorm/40048 CARBOplatin
      dosageInstruction
        text "AUC 5 IV over 30 minutes on Day 1"
        timing
          extension relativeTime
            base periodStart
            offset 0d
          repeat
            duration 30 min
          route "IV"
          doseQuantity AUC 5 http://snomed.info/sct/413573002

Lee Surprenant (May 10 2016 at 20:32):

then, a system that knows how to convert an orderset to a set of MedicationOrder would probably need to resolve that relativeTime extension down into actual days

Lee Surprenant (May 10 2016 at 20:41):

@Bryn Rhodes ^ above is what i put together after our talk today. ideally each action in OrderSet could define its own timing using a relativeTime which some order placement system/service could help the physician to place for a particular patient with absolute timings (using Timing.event)

Lee Surprenant (May 10 2016 at 20:44):

that would allow actions to repeat without having a different action for each repetition

Lloyd McKenzie (May 10 2016 at 20:52):

My thought on offsets is that there should be a standard extension for datetime that allows you to express both an offset and either a URI or a code to indicate "offset from what". Because offsets are going to be needed pretty much anywhere we allow datetime (including inside Period and inside Timing) and we can't really argue that's a core property for those types.

Andrew Ross (May 10 2016 at 20:53):

@Lloyd McKenzie we actually don't need to reference "offset from what" for this example, because the "what" is the top-level date of the medication order. all we need is the ability to specify an arbitrary number doses to be administered at specific offsets from that top-level date

Andrew Ross (May 10 2016 at 20:53):

(which is defined by the actionDefinition that references the order)

Lloyd McKenzie (May 10 2016 at 20:55):

Which date is that? The creation date? How does someone know that's the intended anchor point for an arbitrary resource?

Andrew Ross (May 10 2016 at 20:57):

hmm. I was thinking MedicationOrder had an effectiveDateTime but that's MedicationAdministration

Andrew Ross (May 10 2016 at 20:58):

nevertheless, if you have a MedicationOrder now whose timing has a repeat with count equal to 2 and period equal to 7 days, what does that mean?

Andrew Ross (May 10 2016 at 20:58):

if there's a problem with what i'm proposing, there's also a problem with the standard as-is

Andrew Ross (May 10 2016 at 21:00):

does that make sense @Lloyd McKenzie ?

Andrew Ross (May 10 2016 at 21:02):

unless all MedicationOrders are supposed to be "effective immediately", or at least until dateEnded

Andrew Ross (May 10 2016 at 21:03):

it could also be relative to dispenseRequest.validityPeriod

Andrew Ross (May 10 2016 at 21:03):

that actually might make the most sense

Andrew Ross (May 10 2016 at 21:05):

so, to reiterate, we're thinking it would make sense to be able to schedule 1..* doses to be administered 0-N days after dispenseRequest.validityPeriod.start, or maybe reusing the same anchoring structure

Andrew Ross (May 10 2016 at 21:06):

and i guess that could be made relative pretty easily, but it seems easiest from an EHR implementation perspective if the medication order is somewhat self-contained

Lee Surprenant (May 10 2016 at 21:11):

i think 'bounds' *could* be used for start period as well, but i guess your point is valid that if its not there then the repeat is sort of just a pattern without an explicit base (i took it to mean effective immediately unless a bounds is provided)

Lee Surprenant (May 10 2016 at 21:11):

anyway, in this case I was more focused on the OrderSet resource (presuming we go with the Protocol approach of putting the details in-line rather than referencing an external/contained resource like MedicationOrder)

Andrew Ross (May 10 2016 at 21:12):

ah, yes, i guess it should be bounds.

Lee Surprenant (May 10 2016 at 21:16):

BTW, for me I think a standard relativeTime extension *could* work...but part of me still wondering if there is a way to do it in 'core' for Protocol/OrderSet since it seems so common in this definitional space

Lee Surprenant (May 10 2016 at 21:17):

especially if that relativeTime could be resolved to events as part of the $place operation

Lee Surprenant (May 10 2016 at 21:19):

@Lloyd McKenzie another question Bryn raised: is 'relativeTime' extension on Timing even allowed? modifierExtensions not allowed on dataTypes but i could argue this doesn't modify meaning of other attributes. still, it would be rather important to understand. is it possible for an extension to be marked as mustSupport without it being a modifier?

Lee Surprenant (May 10 2016 at 21:25):

https://www.hl7.org/fhir/profiling.html#mustsupport makes it sound like a yes...we just need to declare it as such in a profile

Lloyd McKenzie (May 10 2016 at 23:59):

The start time for most prescriptions, in the absence of a value in dosageInstruction.timing.repeat.bounds.start is "when the patient gets their hands on the med", which in a hospital setting is usually shortly after authorship and could be several days in a community setting.

Lloyd McKenzie (May 11 2016 at 00:01):

My concern with having a relative expression that doesn't anchor the relativity is there's no way to know what the anchor should be. Is it MedicationOrder.dateWritten? MedicationOrder.dispenseRequest.validityPeriod.start? MedicationOrder.dosageInstruction.timing.repeat.bounds.start? Something else?

Lloyd McKenzie (May 11 2016 at 00:03):

And the rules could be different for each attribute in each resource

Andrew Ross (May 11 2016 at 17:30):

It seems like MedicationOrder.dosageInstruction.timing.repeat.bounds is the most intuitive/possibly only sensical choice for anchoring. dateWritten clearly has no relationship to when the medication should be administered, and while dispenseRequest.validityPeriod probably overlaps with dosageInstruction...bounds, it's really about when the medication can be dispensed, not when it should be taken.

Andrew Ross (May 11 2016 at 17:32):

basically i think the anchoring has to be to a start or end time within MedicationOrder.dosageInstruction for its timing to make sense without needing to reference other resources

Lloyd McKenzie (May 12 2016 at 01:51):

But what if the expression was on dispenseRequest.validityPeriod? What would the anchor point be then? The point is that the anchor point could potentially be different for each attribute you chose to make "relative" and would be different for each resource. And while you could hope that recipients would make the same presumption about the anchor point as you did, it's hard to guarantee that.

Lloyd McKenzie (May 12 2016 at 01:52):

We could certainly define distinct extensions for each attributes and embed within the definition of the extension what the extension was relative to, but that's a lot of extensions, and a lot of complexity for systems to deal with in other ways.

Last updated: Apr 12 2022 at 19:14 UTC