Mood

The Mood of an Act Class is a code distinguishing whether an Act is conceived of as a factual statement or in some other manner as a command, possibility, goal, etc.

Constraints: An Act-instance must have one and only one moodCode value. The moodCode of a single Act-instance never changes. Mood is not state, the state of an Act-instance can go though all state transations as defined in the RIM.

• Note: D-MIMs may contain Acts that don't have a fixed mood. R-MIMs are supposed to limit their scope such that each Act class has a fixed mood. Act-instances (on the wire in an interaction) have to have a fixed mood.

To describe the progression of a business activity from defined to planned to executed, etc. one must instantiate different Act-instances in the different moods and link them using ActRelationships.

See also: EVN Mood, RQO Mood.

FAQ

• If an act in INT/RQO mood has the status "completed", can one always (by definition) infer from this that the act has an associated EVN act which also has a completed status?
  • (Gregg) I would not expect the associated EVN act to necessarily be only of completed status. Certainly it might be aborted, active or suspended. The RIM-istas will need to say whether it might be somewhere on the new, held, cancelled axis.
  • (Anita B) I can speak for APT. We do not message for completed appointments because we assume a create act will message about the act in event mood. If the appointment is represented after the act has started, it would have a mood of APT and a status of "completed". This does not mean that the act itself (mood = EVN) has completed, only the appointment.
  • (Austin K) You also have to take into consideration that the associated event, may actually be decomposed into multiple acts by whatever service is producing the event that fulfills the intent. I certainly agree with Gregg that completion of the intent does not require that the associated event be completed. Completion of the intent is really a decision the application managing the intent decides. The application managing the intent may decide the intent is complete as soon as the application filling the intent promises to fill the intent. Of course that may lead to the intent needed to be re-activated later if the filling application later cancels the promise. In that case, there may never be an associated event.
  • (Tom de Jong) an Act in RQO mood is considered completed (usually implicitly) when all the events that it requested have taken place (i.e. when the objective of the request/order has been reached). An order for a series of activities isn't complete until the series has reached the last occurrence. By deduction, that means that an open-ended order (say, for inpatient medication) can only complete explicitly (with a 'stop' order).
  • (Lloyd McKenzie) My personal definition of "complete" orders corresponds with Tom - all requested action has been completed. I.e. A prescription isn't complete until the patient pops the last pill. A lab order isn't complete until the last test is finished, etc. However, the reality is that an order will go to complete when it receives the last fulfillment act it can reasonably expect, combined with additional timing information. For example, a community prescribing system never knows when a patient takes a pill. The best it can know is when the prescription was last dispensed. From that point, based on dosage instructions, it can guess when the patient should be finished the drug and stop taking it. In the case of a referral for an encounter, if the only notification you expect to get is the scheduling, then I suppose you could change the referral to complete, but it wouldn't make sense to do so until after the appointment was scheduled to be completed. It's important to note that there's a difference between "no longer fulfillable" and "complete". Once a referral has been scheduled, it may be no longer fulfillable (at least unless the appointment is canceled), but the order isn't complete until the requested action has actually been done.