Return to contents

ActMood    NormativeStandard1

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.

Lvl Type, Domain name and/or Mnemonic code Concept ID Mnemonic Print Name Definition/Description
1 A: ActMoodCompletionTrack A10197

These are moods describing activities as they progress in the business cycle, from defined, through planned and ordered to completed.

2   S: ActMoodIntent (INT) S10199 INT intent

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.

3     S: ActMoodProposal (PRP) S16726 PRP proposal

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.

4       L:  (RMD) C21571 RMD recommendation

A non-mandated intent to perform an act where a level of professional responsibility is being accepted by making the proposal.

3     L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

3     L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

3     L:  (PRMS) C16728 PRMS promise

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.

3     L:  (RQO) C19973 RQO request

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.

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

1 A: ActMoodPredicate A10202

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.

2   L:  (GOL) C18864 GOL Goal

Expectation to make a specific observation with a desired value at a predefined future time

2   L:  (EVN.CRT) C10203 EVN.CRT event criterion

A criterion or condition over service events that must apply for an associated service to be considered.

2   L:  (EXPEC) C21574 EXPEC expectation

An anticipated act.

2   L:  (OPT) C10204 OPT option

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).

2   L:  (PERM) C21381 PERM permission

A kind of service which is authorized to be performed.

2   L:  (PERMRQ) C21382 PERMRQ permission request

A request for authorization to perform a kind of service.

This is distinct from RQO which is a request for an actual act. PERMRQ is merely a request for permission to perform an act.Discussion:

2   L:  (RSK) C21575 RSK risk

An undesirable act that is likely to occur.

1 A: x_ActMoodDefEvn A19375

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.

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

1 A: x_ActMoodDefEvnRqoPrmsPrp A19371
2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ActMoodDocumentObservation A18943

Used to enumerate the moods that an observation can take within the body of a clinical document.

2   L:  (GOL) C18864 GOL Goal

Expectation to make a specific observation with a desired value at a predefined future time

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ActMoodEvnOrdPrmsPrp A18965
2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ActMoodIntentEvent A16742

A constraint domain for RMIM design.

2   S: ActMoodIntent (INT) S10199 INT intent

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.

3     S: ActMoodProposal (PRP) S16726 PRP proposal

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.

4       L:  (RMD) C21571 RMD recommendation

A non-mandated intent to perform an act where a level of professional responsibility is being accepted by making the proposal.

3     L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

3     L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

3     L:  (PRMS) C16728 PRMS promise

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.

3     L:  (RQO) C19973 RQO request

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

1 A: x_ActMoodOrdPrms A16735

A grouping of Order, Promise. These specific moods are used in orders.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ActMoodOrdPrmsEvn A16730

A grouping of Order, Promise and Event moods.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ActMoodPermPermrq A19689

Enumerates the moods that an Act can take when describing privileges.

2   L:  (PERM) C21381 PERM permission

A kind of service which is authorized to be performed.

2   L:  (PERMRQ) C21382 PERMRQ permission request

A request for authorization to perform a kind of service.

This is distinct from RQO which is a request for an actual act. PERMRQ is merely a request for permission to perform an act.Discussion:

1 A: x_ActMoodRqoPrpAptArq A19372
2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ClinicalStatementActMood A19649
2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ClinicalStatementEncounterMood A19648
2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ClinicalStatementObservationMood A19644
2   L:  (GOL) C18864 GOL Goal

Expectation to make a specific observation with a desired value at a predefined future time

2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ClinicalStatementProcedureMood A19647
2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ClinicalStatementSubstanceMood A19645
2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_ClinicalStatementSupplyMood A19646
2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

1 A: x_DocumentActMood A19458

Used to enumerate the moods that an act can take within the body of a clinical document.

2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_DocumentEncounterMood A19459

Used to enumerate the moods that an encounter can take within the body of a clinical document.

2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_DocumentProcedureMood A19460

Used to enumerate the moods that a procedure can take within the body of a clinical document.

2   L:  (APT) C11626 APT appointment

A planned Act for a specific time and place.

2   L:  (ARQ) C11625 ARQ appointment request

A request for the booking of an appointment.

2   L:  (DEF) C10198 DEF definition

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.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.

1 A: x_DocumentSubstanceMood A19461

Used to enumerate the moods that a substance administration can take within the body of a clinical document.

2   L:  (EVN) C10201 EVN event (occurrence)

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.

2   L:  (INT) C10199 INT intent

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.

2   L:  (PRMS) C16728 PRMS promise

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.

2   L:  (PRP) C16726 PRP proposal

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.

2   L:  (RQO) C19973 RQO request

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.


Return to contents