|
|
Class steward is Orders/Observation
The Service relationship class is a recursive associative class with two associations to the Service class, one named "source" the other named "target". Consider every Service_relationship instance an arrow with a point (headed to the target) and a butt (coming from the source.) For each relationship type the functions (or roles) of source and target Service are different as specified in Table 13 below.
In principle the assignment of functions (roles) to each side of the relationship "arrow" is completely arbitrary. However since a service is the core element of a medical record, proper attribution of the medical record items is an important issue. The relationships associated with a Service are considered properties of the source service object. That means, that the originator of the information reported in a service object is not only responsible for the attribute values of that object, but also for all its outgoing relationships.
The rule of attribution is that all service relationships are attributed to the responsible actor of the Service at the source of the Service_relationship (the "source service".)
With this recursive service relationship one can group actions into "batteries," e.g., LYTES, CHEM12, or CBC, where multiple routine laboratory tests are ordered as a group. Some groupings, such as CHEM12, appear more arbitrary; others, such as blood pressure, seem to naturally consist of systolic and diastolic pressure.
Actions may also be grouped longitudinal, in a sequence of sub-actions to for temporal and conditional (non-temporal) action paths (e.g., care plan, critical path, clinical trials, drug treatment protocols).
Actions may be explicitly timed, and may be conditioned on the status or outcome of previous actions. Concurrent collections of actions allow expressing logical branches as well as parallel tasks (tasks carried out at the same time.) These constructs can be organized in multiple layers of nesting, to fully support workflow management.
The relationship class is not only used to construct action plans but also to represent clinical reasoning or judgements about action relationships. Prior actions can be linked as the reasons for more recent actions. Supporting evidence can be linked with current clinical hypotheses. Problem lists and other networks of related judgements about clinical events are represented by the service relationship link too.
The Service_relationship.type_cd identifies the meaning and purpose of every service relationship instance.
Indicates when associated pre-conditions are to be tested. The following values are defined:
entry S= Condition is tested once before the service is executed (IF condition THEN service). beginning B= Condition is tested every time before execution of the service (WHILE condition DO service.) end E=Condition is tested at the end of a repeated service execution. The service is repeated only if the condition is true (DO service WHILE condition.) throughT= Condition must be true throughout the execution and the service is interrupted (asynchronously) as soon as the condition turns false (asynchronous WHILE loop.) The service must be interruptible. exit X= Condition is a loop checkpoint, i.e. it is a step of an activity plan and, if negative causes the containing loop to exit.
In a bundle of precondition or outcome relationships, this code indicates the logical conjunctions of the criteria.
The inversion indicator is used when the meaning of the relationship type must be reversed. For example, we define a relationship type reason to express the reason for an action as in
a) "A cholecystectomy was performed because of symptomatic cholelithiasis without signs for cholecystitis." (cholecystectomy has-reason cholelithiasis)
This statement of rationale is attributed to the responsible performer of the cholecystectomy. Now consider the following statement:
b) "The finding of symptomatic gall stones (cholelithiasis) with no signs of acute cholecystitis suggests a cholecystectomy."
While sentence a) declares a reason for an action, sentence b) suggests an action. Reason and suggestion links are reciprocal, i.e., if X has-reason Y, then Y suggests X. The second statement would have been made by the originator of the cholelithiasis finding.
In the "network" of interrelated services, we need to make sure that we do not lose proper attribution of statements to originators ("who said what?") Since attribution is so important, we adopt a very simple rule for it: a service relationship is always attributed to the originator of the source service. No exceptions to this rule are permitted whatsoever. If attribution needs to be different one can invert the relationship type by setting the inversion_ind attribute to true.
If the inversion indicator is true, source and target service swap their roles, that is, the reason and the suggested action swap their roles, so that cholecystectomy can be the source and colelithiasis can be the target. Note that the attribution rule is always unchanged, i.e., the service relationship is always attributed to the responsible author of the source service, no matter what the inversion_ind value is.
In a parallel branch construct the join code indicates how the concurrent activities are resynchronized.
Concept Code Definition wait W Wait for this branch to terminate. kill K When all other concurrent branches are terminated, interrupt and discontinue this branch. exclusive wait X Wait for any one of the branches in the set of exclusive wait branches to terminate, then discontinue all the other exclusive wait branches. detached D Detach this branch from the other branches so it will not be resynchronized with the other branches.
A kill branch will only be executed if there is at least one active wait (or exclusive wait) branch. If there is no other wait branch active, a kill branch is not started at all (rather than being discontinued shortly after it is started.) A detached branch will be unrelated to all other branches, thus a kill branch will be discontinued no matter whether there are detached branches still running.
For conditions and criteria links indicates whether the meaning is negative (condition must not be true.) Normally all conditions are interpreted as affirmative, i.e., the condition must be true. The negation_ind is part of the condition so that the Boolean outcome of the condition XOR-ed with the negation_ind of the condition link must be true. We thus say the "condition is true" even if the test was negative if the negation_ind is true.
The time that should elapse after this activity has got clearance to execute and the actual begin of execution. Any entering pre-conditions are tested before the slot is entered, so the pause specifies a minimal waiting time before the service is executed after its pre-conditions become true.
This integer number allows to specify another kind of ordering amongst the outgoing relationships of a service. This is used to represent the priority ordering of conditional branches in service execution plans, or priority ranking in pre-condition, outcome or support links, and preferences among options.
The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle (a relationship bundle is a sub-set of the relationships originating in the same service instance and usually having the same relationship type) has a distinct priority number. If, however, some relationships in the bundle share the same priority number, we have a partial ordering. Those links with the same priority will have undefined ordering of consideration.
This integer number allows one to specify an ordering amongst the outgoing relationships of a service. This is used to represent sequences of actions in execution plans. The ordering may be total or partial. A total ordering exists if every relationship in a relationship bundle has a distinct sequence number. (A relationship "bundle" is a sub-set of the relationships originating in the same service instance and usually having the same relationship type). If, however, some relationships in the bundle share the same sequence number, we have a partial ordering. In such a case the services with the same sequence number are concurrent.
When an activity plan has a branch (indicated through multiple steps with the same item number) the split code specifies how branches are selected for execution. The values are defined as follows:
exclusive try once E1=The pre-condition associated with the branch is evaluated once and if true the branch may be entered. All other exclusive branches compete with each other and only one will be selected. This implements a COND, IF and CASE conditionals, or "XOR-split." The order in which the branches are considered may be specified in the Service_relationship.priority_nmb.
exclusive wait EW= A branch is selected as soon as the pre-condition associated with the branch evaluates to true. If the condition is false, the branch may be entered later, when the condition turns true. All other exclusive branches compete with each other and only one will be selected. Each waiting branch executes in parallel with the default join code wait (see below.) The order in which the branches are considered may be specified in the Service_relationship.priority_nmb.
inclusive try once I1=A branch is executed if its associated preconditions permit. If associated preconditions do not permit, the branch is dropped. Inclusive branches are not suppressed and do not suppress other branches.
inclusive wait IW=A branch is executed as soon as its associated conditions permit. If the condition is false, the branch may be entered later, when the condition turns true. Inclusive branches are not suppressed and do not suppress other branches. Each waiting branch executes in parallel with the default join code wait
Determines the meaning of a relationship between two Services. This attribute is probably the most important attribute in this entire model besides the Service.mood_cd. It is a "structural" attribute inasmuch as each of its values implies specific constraints to what kinds of Service objects can be related and in which way. Refer to the USAM specification document for defined service relationship types and examples of their use.