Moods in fhir

Introduction

An active debate.

content goes here....

see also [1]

How do we handle "definitions" and possibly other moods?

We're going to need definitions of most stuff for ClinicalTrials, and at least some things for various masterfiles (lab, drug protocols, etc.) Also, we'll need "requests" for many things, promises for some of them, etc. We should handle this consistently, but still in a way "intuitive" to implementers.

• Jean: Do we really need this? Mood is one of the sillier things that HL7 v3 implementers have to deal with. And in almost all cases, the mood is fixed and determined by the behaviour being requested. On the NCI caEHR project, we actually ignored mood and implied it by the service being called. So if I am querying for a resource, the resource mood is EVN or DEF and I don't really care.
• LM: Agree we should avoid introducing moodCode if at all possible. I don't think we can avoid having resources for requests, definitions or promises though (where actually needed). From a business perspective, I think we need to handle these as distinct resources. Because the constraints are going to be different in the different moods and squishing multiple moods into a single resource is going to confuse the heck out of people.
• GG: I've been thinking that this is furphy. moodCode is a lower level issue driven by modeling at a particular level. What kind of resource would have a mood, and where the mood would not change it's content? I think we have an ordering cycle that needs a general pattern. And we have care plan that needs a pattern. I don't know whether the pattern is the implementation yet
• Jean: We've got this discussion going on in two places. I think we're heading towards a solution that there is no 'moodCode' attribute. But we will need to allow resources to support different conformance statements based on how the resource is being used. The outstanding problem as I see it, is if the use/definition of an attribute changes depend on the use of the resource. As an example, the formCode on a Prescription could be a list of allowed forms when being sent as a definition but would be restricted to a single repetition and indicate what form was actually prescribed when sent as a request or event. (Contrived but I think it gets the point). I'd hate to see "if used as X, then means Y" in the ontology.
• LM: I disagree. I think we need totally separate resources for different moods. One for prescription, one for promise, one for dispense, one for administration. Trying to cram these into a single resource would be a mistake. It results in yucky complexity in terms of conformance profiles, and is confusing to business experts and implementers. And the only reason to do it is to avoid the "overhead" of defining the same structures multiple times. In practice, they're rarely the same structures. The detail required to encode dosage in a prescription is often not the same as required on a dispense. There are attributes on dispenses that aren't on prescriptions and vice versa.
• Jean: Well, your listing isn't one resource in different moods - it's three different resources plus the promise. An administration has completely different attributes from a dispense. So that's not the problem. The problem is how to handle the ordering of a dispense, the promise to dispense something, and the statement of what actually was dispensed. I think that within that set of moods, the complexity is actually quite smaller. I suspect we'll have to try it to see though.
• LM: Dispense order and dispense event are quite different. Defining one resource definition for both would be problematic. Dispense order and dispense promise are much closer. However, there's still an issue of how to keep them distinct. We could take the approach of saying that all promises are actually "internal" orders. Thus, you could have one system that creates an order, and another system that creates a more "encoded" version of that resource as its own internal order, using the same underlying resource definition. So long as we allow orders to fulfil orders, that can work. But order, definition and event will need to be separate resource types.
• GG: Where do we actually need "definition" on a resource? - I very doubt it's ever been used anywhere
• LM: Canada uses DEF mood for SBADM to define allowed/recommended dosages as part of a drug monograph. RCRIM uses DEF to define allowed acts as part of a clinical trial design.
• Right, but are these *resources*? I don't think so

archive skype

• E: Did you see the discussion about mood? I think we both agree on having a set of Request/Promise/Event resources which refer to the actual thing requested/promised. Or at least trying out that idea in stead of mood codes.
• E: I don't like to make mood a phase-variable at all. It's not a variable.
• E: BTW: did you see Google's turing machine on the search screen?
• G: amazing
• G: with regard to mood, yes, I think that that's direction to go.
• G: what we need now is a wiki page gathering requirements
• G: for those process resources
• G: what can you order? what is the possible outcomes? does what you order change the contents or the workflow of the order?
• E: We could call them "Action", "Instruction", ... ;)
• E: That last question is very interesting.
• E: Also, pharamcy is a good group to try that idea
• E: Supplying wheelchairs is probably a breeze after that.
• G: what can you order:
• G: medication
• G: diagnostic test
• G: diet
• E: procedure
• G: misc supplies
• G: one tricky issue you remind me of: order transitions into referral
• G: or refer someone to a specialist for a procedure - overlaps with I order a procedure
• G: relates to the tricky issue of who can countermand the order and why
• G: or, when is an order a request.
• G: http://en.wiktionary.org/wiki/order
• E: I think referrals to a specialist and orders for a procedure should be separate things...but I'm not really expert on this matter...
• G: oh yes, they should be. but what about the overlap?
• G: and I'll put on my Lloyd hat and ask you about orders for referrals and referrals for orders, and orders for orders
• E: hahahaha
• E: don't forget about promising to order a referral
• E: Well, we can now nEST!
• E: NEST!
• G: a NESTful interface?
• E: new Promise( new Order ( new Referral() ) )
• E: so not only can you order medication, you can order orders too.
• E: ;)
• G: so one thing that will challenge us here is the REST notion
• E: yes
• G: I create and/or update an order with you
• G: that's not the same as actually placing an order with you
• E: Not in rest
• G: what turns it into an actual order?
• E: Putting it on the stack of the correct person
• E: which is equivalent to...
• E: Mmmmm
• G: context and/or trading partner agreement, I think
• E: Is an Order resource that what we track about an order, or the "order" artifact that someone turns in to do an order.
• G: well, in the case of a lab order, there's a resource called a lab request
• G: this tells a lab what to actually do.
• G: peform the following tests on the patient x because of y, paying for it using method z, and report to doctors a b and c
• G: one workflow is, I push those lab requests to the lab system, and it files them away. doesn't do anything with them
• G: then, when the specimen turns up at the lab, it carries the id of the request resource, and the user scans the request, and the system automatically retrieves the lab request
• G: i.e. the actual order is implicit. So there's no order resource.
• E: The actual order is implicit. What we exchange is information about the state of the ordering process.
• G: another is, the lab collates the requsts that it gets, and then builds a bleeding round list, and goes and actually gathers the specimens
• G: there's still no order.
• G: lab is odd because there's specimens and everything revolves around them
• G: perhaps a better way to think of lab is that there's a lab request. The details are posted with the lab server. But there's an order that goes to the nurse station to actually register the need for them to go collect the specimens
• E: But the question is, I think, if the actual act of writing and submitting an order is in or outside our scope. There will be a system where someone submits an order. An actual order artifact. That systems then starts a proces and signals, using FHIR, that a process has been started and includes data-after-the-fact. The event is that this has happened, not that FHIR is used to send something to starts the process.
• G : so are these things inherently transactional? only ever in messages that trigger actual state transitions?
• G: A process resource...?
• E: You'd get that feeling.
• E: At this point, I realize you're always getting down into philosphy.
• G: I need to go about my day. I'm going to move this to the wiki, and start thinking about a process-tracker resource as an alternative too
• E: That's why I made that big wiki page about modelling.

Lloyd's concerns

I'm not sure I follow what's proposed here. Are you saying that you'll have a "Procedure" resource, and then you'll have a separate resource instance attached to that procedure resource instance that tells you whether you're dealing with an order, promise, event, definition, etc.? If so, I object - strongly. The data elements that are in the 80% for ordering something are distinct from those in the 80% for defining it or capturing the actual occurrence. I really think we need distinct resources for each combination. Ordered procedures vs. procedure definitions vs. procedure records. Note that the granularity may well be different. I suspect we can handle most types of ordered things via a generic structure. There will only be a few exceptions like drugs and lab where things get more complicated. And I suspect that we'll treat protocol definitions as a single resource, rather than the stitching together of a whole bunch of different types of resources.

Resolution

We'll use distinct resources for distinct moods. Rationale:

• Trying to force re-use across moods to reduce numbers isn't going to work and isn't necessary. We're not going to end up with everything in every single mood.
• Definitions will live in those few places we need master files and in ordersets. Intents will live in Care Plan. Maybe in referral, though I think Referral may reference CarePlan.
• We won't end up with 100s of them. I doubt we'll see more than 10. And they can (and should) safely live as distinct resources.
• Sharing a bit of commonality does not mean they're the same thing.
• They're used by different systems, they're queried differently, they have different life cycles. They're considered distinct things by implementers. The 80% *will* vary. They're not the same.
• It may be that in a few cases we might find value in a re-usable chunk that spans multiple resources, but I suspect that will be rare if it occurs at all.