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.
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 ActRelationship of general type "sequel". (See ActRelationship.type.)
This table controls values for structural elements of the HL7 Reference Information Model. Therefore, it is part of the Normative Ballot for the RIM.
These are moods describing activities as they progress in the business cycle, from defined, through planned and ordered to completed.
An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.
A planned Act for a specific time and place.
A request for the booking of an appointment.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
Periods of time on a schedule for a resource. Appointments occupy sets of one or more booked slots. A slot that is open for appointments is considered available and a slot that is held back for administrative purposes is considered blocked. A Resource slot that is "tentatively" booked is referred to as reserved.
A definition of a service (master).
Historical note: in previous RIM versions, the definition mood was captured as a separate class hierarchy, called Master_service.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
Any of the above service moods (e.g., event, intent, or goal) can be turned into a predicate used as a criterion to express conditionals (or queries.) However, currently we allow only criteria on service events.
A criterion or condition over service events that must apply for an associated service to be considered.
Expectation to make a specific observation with a desired value at a predefined future time
An option is an alternative set of property-value bindings. Options specify alternative sets of values, typically used in definitions or orders to describe alternatives. An option can only be used as a group, that is, all assigned values must be used together.
Historical note: in HL7 v2.x option existed in the special case for alternative medication routes (RXR segment).
A kind of service which is authorized to be performed.
A request for authorization to perform a kind of service.
Discussion: This is distinct from RQO which is a request for an actual act. PERMRQ is merely a request for permission to perform an act.
A grouping of Definition, Event. These specific moods are used in control wrapper override acts. The domain is restricted to acts that are possible to occur or have already occurred.
A definition of a service (master).
Historical note: in previous RIM versions, the definition mood was captured as a separate class hierarchy, called Master_service.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
A definition of a service (master).
Historical note: in previous RIM versions, the definition mood was captured as a separate class hierarchy, called Master_service.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
Used to enumerate the moods that an observation can take within the body of a clinical document.
An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.
A definition of a service (master).
Historical note: in previous RIM versions, the definition mood was captured as a separate class hierarchy, called Master_service.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
Expectation to make a specific observation with a desired value at a predefined future time
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
A constraint domain for RMIM design.
An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.
A planned Act for a specific time and place.
A request for the booking of an appointment.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
Periods of time on a schedule for a resource. Appointments occupy sets of one or more booked slots. A slot that is open for appointments is considered available and a slot that is held back for administrative purposes is considered blocked. A Resource slot that is "tentatively" booked is referred to as reserved.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
A grouping of Order, Promise. These specific moods are used in orders.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
A grouping of Order, Promise and Event moods.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
A planned Act for a specific time and place.
A request for the booking of an appointment.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
Used to enumerate the moods that an act can take within the body of a clinical document.
An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.
A planned Act for a specific time and place.
A request for the booking of an appointment.
A definition of a service (master).
Historical note: in previous RIM versions, the definition mood was captured as a separate class hierarchy, called Master_service.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
Used to enumerate the moods that an encounter can take within the body of a clinical document.
An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.
A planned Act for a specific time and place.
A request for the booking of an appointment.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
Used to enumerate the moods that a procedure can take within the body of a clinical document.
An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.
A planned Act for a specific time and place.
A request for the booking of an appointment.
A definition of a service (master).
Historical note: in previous RIM versions, the definition mood was captured as a separate class hierarchy, called Master_service.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.
Used to enumerate the moods that a substance administration can take within the body of a clinical document.
An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.
A service that actually happens, may be an ongoing service or a documentation of a past service.
Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.
An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.
A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer).
Rationale: The concepts of a "request" and an "order" are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. "Orders" are commonly refused for a variety of clinical and business reasons, and the notion of a "request" obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is "request."
Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the "local" business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept.
The critical distinction here, is the difference between this concept and an "intent", of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.