Moods in fhir

Introduction

An active debate.

content goes here....

see also [1]

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.