public interface ActRelationship extends InfrastructureRoot
Examples: 1) An electrolyte observation panel may have sodium, potassium, pH, and bicarbonate observations as components. The composite electrolyte panel would then have 4 outbound ActRelationships of type "has component".
2) The electrolyte panel event has been performed in fulfillment of an observation order. The electrolyte panel event has an outbound ActRelationship of type "fulfills" with the order as target.
3) A Procedure "cholecystectomy" may be performed for the reason of an Observation of "cholelithiasis". The procedure has an outbound ActRelationship of type "has reason" to the cholelithiasis observation.
Discussion: Consider every ActRelationship instance an arrow with a point (headed to the target) and a butt (coming from the source). The functions (sometimes called "roles") that source and target Acts play in that association are defined for each ActRelationship type differently. For instance in a composition relationship, the source is the composite and the target is the component. In a reason-relationship the source is any Act and the target is the reason or indication for the source-Act.
The relationships associated with an Act are considered properties of the source act object. This means that the author of an Act-instance is also considered the author of all of the act relationships that have this Act as their source. There are no exceptions to this rule.
See ActRelationship.typeCode for more overview of the different kinds of ActRelationships.
The ActRelationship class is used to construct action plans and to represent clinical reasoning or judgments 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 judgments about clinical events are represented by the ActRelationship link.
One of the most commonly used ActRelationship types is "has component" to describe the composition and de-composition of Acts. The relationship type allows specifying detail of Acts to varying degrees.
The composition relationship 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.
The composition relationships can be arranged in a sequence to form temporal and conditional (non-temporal) action plans (e.g., care plan, critical path, clinical trials protocol, drug treatment protocols). There is a group of attributes in both Act and ActRelationship that we refer to as the "workflow Control suite of attributes", and which allow the detailed specification of executable action plans. These attributes are:
ActRelationship.sequenceNumber arranges the components of an Act as a sequence or as concurrent collections of components, expressing logical branches as well as parallel tasks (tasks carried out at the same time). The ActRelationship attributes splitCode and joinCode control how branches are selected or executable in parallel.
Act.activityTime and ActRelationship.pauseQty allow one to explicitly time an action plan. Act.repeatNumber allows specifying act to repeat (loop).
The ActRelationship type has-precondition allows plan steps to be conditional on the status or outcome of previous actions. The ActRelationhsip.checkpointCode specifies when pre-conditions of acts are tested during the flow of control.
The composition ActRelationship allows these constructs to be organized in multiple layers of nesting to fully support workflow management. This nesting and the workflow control attributes are designed in analogy to a block-structured programming language with support for concurrency (fork, join, interrupts), and without "goto" statements. It is important to note that ALL plans are established through sequencing components (steps) in a composite act (block) as can be depicted in "Nassi-Schneiderman" diagrams (also known as "Chap Charts" or "Structograms"), not by chain-linking acts as in a flowchart diagram.
With the composition relationship, the detail of Acts can be revealed to different levels for different purposes, without the structure of the Act hierarchy needing to be rearranged. This allows supporting multiple viewpoints on the same business processes. For instance, a billing-viewpoint of a laboratory test battery may be as a single billable act. A clinician's view of the same laboratory test battery is as a set of individual observations, where the ordering among the observations is irrelevant. The laboratory's view of this act will be more detailed, including action plan steps that are never reported to the clinician (e.g., centrifugation, decantation, aliquoting, running certain machines etc.). The laboratory's viewpoint warrants a thorough specification of action plans (that can be automated). During this specification, more and more nested sub-activities will be defined. Still the Act is the same, with varying degrees of detail uncovered in the de-composition relationship.
We described the nature of varying detail saying that Acts are "fractal", ever more decomposable, just as the movements of a robotic arm can be decomposed in many fine control steps.
Observation| Modifier and Type | Method and Description |
|---|---|
CS |
getCheckpointCode()
A code specifying when in the course of an Act a precondition for the Act
is evaluated (e.g., before the Act starts for the first time, before
every repetition, after each repetition but not before the first, or
throughout the entire time of the Act).
|
CS |
getConjunctionCode()
A code specifying the logical conjunction of the criteria among all the
condition-links of Acts (e.g., and, or, exclusive-or).
|
BL |
getContextConductionInd()
If true, associations in the parent act are conducted across the
ActRelationship to the child act.
|
CS |
getContextControlCode()
A code that specifies how this ActRelationship contributes to the context
of the current Act, and whether it may be propagated to descendent Acts
whose association allows such propagation (see
ActRelationship.contextConductionInd).
|
BL |
getInversionInd()
An indicator specifying that the ActRelationship.typeCode should be
interpreted as if the roles of the source and target Acts were reversed.
|
CS |
getJoinCode()
A code specifying how concurrent Acts are resynchronized in a parallel
branch construct.
|
ST |
getLocalVariableName()
A character string name for the input parameter from which the source Act
of this ActRelationship derives some of its attributes.
|
BL |
getNegationInd()
An indicator that asserts that the meaning of the link is negated.
|
PQ |
getPauseQuantity()
A quantity of time that should elapse between when an Act is ready for
execution and the actual beginning of the execution.
|
INT |
getPriorityNumber()
Deprecated.
Use getPriorityNumberV2()
|
REAL |
getPriorityNumberV2()
A real specifying the relative preference for considering this
relationship before other like-typed relationships having the same source
Act.
|
BL |
getSeperatableInd()
This attribute indicates whether or not the source Act is intended to be
interpreted independently of the target Act.
|
INT |
getSequenceNumber()
An integer specifying the relative sequential or temporal ordering of
this relationship among other like-types relationships having the same
source Act.
|
Act |
getSource()
Gets the source act of the
ActRelationship. |
Act |
getSource(ActFetch actFetch)
Gets the source act of the
ActRelationship that matches the
criteria. |
CS |
getSplitCode()
A code specifying how branches in an action plan are selected among other
branches.
|
Act |
getTarget()
Gets the target act of the
ActRelationship. |
Act |
getTarget(ActFetch actFetch)
Gets the target act of the
ActRelationship that matches the
criteria. |
CS |
getTypeCode()
A code specifying the meaning and purpose of every ActRelationship
instance.
|
CE |
getUncertaintyCode() |
void |
setCheckpointCode(CS checkPoint) |
void |
setConjunctionCode(CS conjunction) |
void |
setContextConductionInd(BL indicator) |
void |
setContextControlCode(CS contextControl) |
void |
setInversionInd(BL inversionIndicator) |
void |
setJoinCode(CS joinCode) |
void |
setLocalVariableName(ST variableName) |
void |
setNegationInd(BL negationIndicator) |
void |
setPauseQuantity(PQ pauseQuantity) |
void |
setPriorityNumber(INT priorityNumber)
Deprecated.
Use setPriorityNumberV2(REAL priorityNumber)
|
void |
setPriorityNumberV2(REAL priorityNumber) |
void |
setSeperatableInd(BL separatableIndicator) |
void |
setSequenceNumber(INT sequenceNumber) |
void |
setSplitCode(CS splitCode) |
void |
setUncertaintyCode(CE uncertaintyCode) |
getControlAct, getToken, setTokenAct getTarget() throws HDRRimException
ActRelationship.ActHDRRimException - Act getTarget(ActFetch actFetch) throws HDRRimException
ActRelationship that matches the
criteria.actFetch - ActFetch object containing the search criteriaAct act matching the specified fetch map.HDRRimExceptionAct getSource() throws HDRRimException
ActRelationship.ActHDRRimException - Act getSource(ActFetch actFetch) throws HDRRimException
ActRelationship that matches the
criteria.actFetch - ActFetch object containing the search criteriaHDRRimExceptionCS getTypeCode()
Discussion: The types of act relationships fall under one of 5 categories:
1.) (De)-composition, with composite (source) and component (target).
2.) Sequel which includes follow-up, fulfillment, instantiation, replacement, transformation, etc. that all have in common that source and target are Acts of essentially the same kind but with variances in mood and other attributes, and where the target exists before the source and the source refers to the target that it links back to.
3.) Pre-condition, trigger, reason, contraindication, with the conditioned Act at the source and the condition or reason at the target.
4.) Post-condition, outcome, goal and risk, with the Act at the source having the outcome or goal at the target.
5.) A host of functional relationships including support, cause, derivation, etc. generalized under the notion of "pertinence".
ActRelationship while it is being added to the
Act.BL getInversionInd()
void setInversionInd(BL inversionIndicator) throws HDRRimException
HDRRimExceptionCS getContextControlCode()
Rationale: In the interest of reducing duplication, humans tend to rely on context when interpreting information. For example, when reading a report taken from a folder containing a patient's medical record, the reader will infer that the report deals with the patient, even if there is no direct reference to the patient on the form. However, other pieces of information such as the author of the folder (the hospital that maintains it) may sometimes apply to the contents of the folder (e.g. a report generated by a doctor at the hospital) and other times not (e.g. a copy of a report from another institution). Humans are quite good at making the necessary inferences about what context should be propagated from an item to something within that item. However, incorrect inferences can occur (perhaps the report in the patient's record deals with a relative). Furthermore, computers have substantially more difficulty making such inferences, even though they can be essential for decision-support systems.
Discussion: This attribute allows the clear specification of whether an association adds to the context associated with a particular item (e.g. adding an additional author) or whether it replaces (overrides) part of the context associated with a particular item (e.g. identifying a sole author, independent of the containing item). It also indicates whether the association applies to only this act (non-propagating), or whether it may apply to derived acts as well (propagating).
This attribute is closely linked with ActRelationship.contextConductionInd which determines whether associations that have been marked as propagating will actually be conducted to a child Act. For example, an author participation might be marked as propagating, but still not conducted to a hyperlink to an external document.
If no value or default is specified for this attribute (i.e. it is null), no inference can be made about context. Systems must make their own assumptions on the basis of what data is being represented. (For this reason, HL7 committees are encouraged to specify a default or fixed value for this attribute as part of their designs to ensure consistency of interpretation.)
Examples: An observation event has a patient participation marked "additive, propagating" (AP) and has component observation events linked through act relationships that are marked propagating. This means that the patient participation behaves as a patient participation of those component observation events in addition to the parent observation event.
A composite order is created containing a pharmacy order as well as requests for several lab tests. The composite order has participations for patient and author, and an act relationship to a diagnosis, all marked as "additive, propagating". The "component" association between the composite order and the pharmacy order is marked as conductive (contextConductionInd is TRUE). The pharmacy order has an author participation marked as "additive, non-propagating" (AN), and a reason relationship to a diagnosis, marked as "overriding, propagating" (OP). The order further has a relationship to a dispense event, marked as conductive, and an association to a drug protocol marked as non-conductive (contextConductionInd is FALSE). The meaning would be as follows:
The pharmacy order is interpreted as having the patient from the composite order, and having two authors (the one from the composite order, and the one on the pharmacy order itself). The diagnosis for the pharmacy order would only be the diagnosis specified on the pharmacy order, not the one specified on the composite order. The dispense event would carry the patient from the composite order and the diagnosis from the pharmacy order, but no author. The drug protocol would not be associated with a patient, diagnosis or author.
Observation,
Participationvoid setContextControlCode(CS contextControl) throws HDRRimException
HDRRimExceptionBL getContextConductionInd()
Discussion: Only associations that have been added to the context of an Act and are marked "propagating" will be conducted. (See contextControlCode on ActRelationship and Participation)
The identification of an Act as a parent or child (and therefore the direction context will be conducted) is determined by how the association is traversed when it is serialized. The first act to be encountered is considered to be the parent. Context conducts across the ActRelationship to the second (child) Act.
Refer to ActRelationship.contextControlCode for rationale and examples.
Act,
Participationvoid setContextConductionInd(BL indicator) throws HDRRimException
HDRRimExceptionINT getSequenceNumber()
Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Multiple components with the same sequenceNumber make a branch. Branches can be exclusive (case-switch) or can indicate parallel processes indicated by the splitCode.
If value is null, the relative position of the target Act is unspecified. (i.e. it may occur anywhere.)
Use the ?priorityNumber? attribute to indicate relative preference instead of order of occurrence.
void setSequenceNumber(INT sequenceNumber) throws HDRRimException
HDRRimExceptionINT getPriorityNumber()
Examples: For multiple criteria specifies which criteria are considered before others. For components with the same sequence number, specifies which ones are considered before others. Among alternatives or options that are being chosen by humans, the priorityNumber specifies preference.
Discussion: The ordering may be a total ordering in which all priority numbers are unique or a partial ordering, which assigns the same priority to more than one relationship.
void setPriorityNumber(INT priorityNumber) throws HDRRimException
HDRRimExceptionREAL getPriorityNumberV2()
Examples: For multiple criteria specifies which criteria are considered before others. For components with the same sequence number, specifies which ones are considered before others. Among alternatives or options that are being chosen by humans, the priorityNumber specifies preference.
Discussion: The ordering may be a total ordering in which all priority numbers are unique or a partial ordering, which assigns the same priority to more than one relationship.
void setPriorityNumberV2(REAL priorityNumber) throws HDRRimException
HDRRimExceptionPQ getPauseQuantity()
Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Before each step is executed and has preconditions these conditions are tested and if the test is positive, the Act has clearance for execution. At that time the pauseQuantity timer is started and the Act is executed after the pauseQuantity has elapsed.
As a precondition (e.g. administer 3 hours prior to surgery), pause quantity is allowed to be negative provided that it is possible to predict the occurrence of the target condition.
Constraint: Units must be comparable to seconds.
Actvoid setPauseQuantity(PQ pauseQuantity) throws HDRRimException
HDRRimExceptionCS getCheckpointCode()
Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Before each step is executed, those with preconditions have their conditions tested; where the test is positive, the Act has clearance for execution. The repeatNumber may indicate that an Act may be repeatedly executed. The checkpointCode is specifies when the precondition is checked and is analogous to the various conditional statements and loop constructs in programming languages "while-do" vs. "do-while" or "repeat-until" vs. "loop-exit".
For all checkpointCodes, except "end", preconditions are being checked at the time when the preceding step of the plan has terminated and this step would be next in the sequence established by the sequenceNumber attribute.
When the checkpointCode for a criterion of a repeatable Act is "end", the criterion is tested only at the end of each repetition of that Act. When the condition holds true, the next repetition is ready for execution.
When the checkpointCode is "entry" the criterion is checked at the beginning of each repetition (if any) whereas "beginning" means the criterion is checked only once before the repetition "loop" starts.
The checkpointCode "through" is special in that it requires the condition to hold throughout the execution of the Act, even throughout a single execution. As soon as the condition turns false, the Act should receive an interrupt event (see Act.interruptibleInd) and will eventually terminate.
The checkpointCode "exit" is only used on a special plan step that represents a loop exit step. This allows an action plan to exit due to a condition tested inside the execution of this plan. Such exit criteria are sequenced with the other plan components using the ActRelationship.sequenceNumber.
Actvoid setCheckpointCode(CS checkPoint) throws HDRRimException
HDRRimExceptionCS getSplitCode()
Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Branches exist when multiple components have the same sequenceNumber. The splitCode specifies whether a branch is executed exclusively (case-switch) or inclusively, i.e., in parallel with other branches.
In addition to exclusive and inclusive split the splitCode specifies how the pre-condition (also known as "guard conditions" on the branch) are evaluated. A guard condition may be evaluated once when the branching step is entered and if the conditions do not hold at that time, the branch is abandoned. Conversely execution of a branch may wait until the guard condition turns true.
In exclusive wait branches, the first branch whose guard conditions turn true will be executed and all other branches abandoned. In inclusive wait branches some branches may already be executed while other branches still wait for their guard conditions to turn true.
Actvoid setSplitCode(CS splitCode) throws HDRRimException
HDRRimExceptionCS getJoinCode()
Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Branches exist when multiple components have the same sequenceNumber. Branches are parallel if the splitCode specifies that more than one branch can be executed at the same time. The joinCode then specifies if and how the branches are resynchronized.
The principal re-synchronization actions are (1) the control flow waits for a branch to terminate (wait-branch), (2) the branch that is not yet terminated is aborted (kill-branch), (3) the branch is not re-synchronized at all and continues in parallel (detached branch).
A kill-branch is only 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 aborted shortly after it is started). Since a detached branch is unrelated to all other branches, active detached branches do not protect a kill-branch from being aborted.
Actvoid setJoinCode(CS joinCode) throws HDRRimException
HDRRimExceptionBL getNegationInd()
Examples: If the relationship without negation specifies that Act A has Act B as a component, then the negation indicator specifies that Act A does not have Act B as a component. If B is a reason for A, then negation means that B is not a reason for A. If B is a pre-condition for A, then negation means that B is not a precondition for A.
Discussion: As the examples show, the use of this attribute is quite limited, notably contrast this with the Act.negationInd that actually requires that the described Act not exist, not be done, etc. whereas the ActRelationship.negationInd merely negates this relationship between source and target act, but does not change the meaning of each Act. This is mostly used for clarifying statements.
Note also the difference between negation and the contrary. A contraindication is the contrary of an indication (reason) but not the negation of the reason. The fact that lower back pain is not a reason to prescribe antibiotics doesn't mean that antibiotics are contraindicated with lower back pain.
Actvoid setNegationInd(BL negationIndicator) throws HDRRimException
HDRRimExceptionCS getConjunctionCode()
Constraints: All AND criteria must be true. If OR and AND criteria occur together, one criterion out of the OR-group must be true and all AND criteria must be true also. If XOR criteria occur together with OR and AND criteria, exactly one of the XOR criteria must be true, and at least one of the OR criteria and all AND criteria must be true. In other words, the sets of AND, OR, and XOR criteria are in turn combined by a logical AND operator (all AND criteria and at least one OR criterion and exactly one XOR criterion). To overcome this ordering, Act criteria can be nested in any way necessary.
Actvoid setConjunctionCode(CS conjunction) throws HDRRimException
HDRRimExceptionST getLocalVariableName()
Actvoid setLocalVariableName(ST variableName) throws HDRRimException
HDRRimExceptionBL getSeperatableInd()
Actvoid setSeperatableInd(BL separatableIndicator) throws HDRRimException
HDRRimExceptionCE getUncertaintyCode()
A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.
Examples: A particular exposure event is suspected but not known to have caused a particular symptom.
Constraints: Uncertainty asserted using this attribute applies only to the relationship between two acts. The certainty of the acts themselves should be conveyed via Act.uncertaintyCode.
Discussion: Note that very vague uncertainty may be thought related to ActRelationship.negationInd, however, the two concepts are really independent. One may be very uncertain about whether a relationship exists (e.g. not sure whether a drug contains an ingredient) an event, but that does not mean that one is certain about the negation of the relationship (e.g. A drug definitively does not contain an ingredient).
Actvoid setUncertaintyCode(CE uncertaintyCode) throws HDRRimException
HDRRimExceptionHDR Glossary HDR Concept Lists HDR Exceptions HDR Programmer's Guide HDR Implementation Guide HDR Profile Options
Copyright © 2016, 2018, Oracle. All rights reserved