public interface Act extends InfrastructureRoot, Versioned
Examples: The kinds of acts that are common in healthcare are (1) a clinical observation, (2) an assessment of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) and notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others.
Discussion and rationale: acts are the pivot of the RIM; all domain
information and processes are represented primarily in acts. Any profession
or business, including healthcare, is primarily constituted of intentional
actions, performed and recorded by responsible actors. An
Act-instance is a record of such an intentional action.
Intentional actions are distinguished from something that happens by forces
of nature (natural events). Such natural events are not acts by themselves,
but may be recorded as observed (Observation).
Acts connect to entities in their roles through participations and connect to
other acts through act relationships. Participations are the authors,
performers and other responsible parties as well as subjects and
beneficiaries (which includes tools and material used in the performance of
the act, which are also subjects). The moodCode distinguishes
between acts that are meant as factual records, vs. records of intended or
ordered services, and the other modalities in which act can appear.
One of the participations that all acts have (at least implicitly) is a
primary author, who is responsible of the Act and who "owns" the
act. Responsibility for the act means responsibility for what is being stated
in the Act and as what it is stated. Ownership of the act is
assumed in the sense of who may operationally modify the same act. Ownership
and responsibility of the Act is not the same as ownership or
responsibility of what the Act-object refers to in the real
world. The same real world activity can be described by two people, each
being the author of their Act, describing the same real world
activity. Yet one can be a witness while the other can be a principal
performer. The performer has responsibilities for the physical actions; the
witness only has responsibility for making a true statement to the best of
his or her ability. The two Act-instances may even disagree, but
because each is properly attributed to its author, such disagreements can
exist side by side and left to arbitration by a recipient of these
Act-instances.
In this sense, an Act-instance represents a "statement"
according to Rector and Nowlan (1991) [Foundations for an electronic medical
record. Methods Inf Med. 30.] Rector and Nowlan have emphasized the
importance of understanding the medical record not as a collection of facts,
but "a faithful record of what clinicians have heard, seen, thought, and
done." Rector and Nowlan go on saying that "the other requirements for a
medical record, example, that it be attributable and permanent, follow
naturally from this view." Indeed the Act class is this
attributable statement, and the rules of updating acts (discussed in the
state-transition model, see Act.statusCode) versus generating
new Act-instances are designed according to this principle of
permanent attributable statements.
Rector and Nolan focus on the electronic medical record as a collection of
statements, while attributed statements, these are still mostly factual
statements. However, the Act class goes beyond this limitation
to attributed factual statements, representing what is known as "speech-acts"
in linguistics and philosophy. The notion of speech-act includes that there
is pragmatic meaning in language utterances, aside from just factual
statements; and that these utterances interact with the real world to change
the state of affairs, even directly cause physical activities to happen. For
example, an order is a speech act that (provided it is issued adequately)
will cause the ordered action to be physically performed. The speech act
theory has culminated in the seminal work by Austin (1962) [How to do things
with words. Oxford University Press].
An activity in the real world may progress from defined, through planned and
ordered to executed, which is represented as the mood of the
Act. Even though one might think of a single activity as
progressing from planned to executed, this progression is reflected by
multiple Act-instances, each having one and only one mood that
will not change along the Act-instance's life cycle. This is
because the attribution and content of speech acts along this progression of
an activity may be different, and it is often critical that a permanent and
faithful record be maintained of this progression. The specification of
orders or promises or plans must not be overwritten by the specification of
what was actually done, so as to allow comparing actions with their earlier
specifications. Act-instances that describe this progression of
the same real world activity are linked through the act relationships (of the
relationship category "sequel").
Act as statements or speech-acts are the only representation of
real world facts or processes in the HL7 RIM. The truth about the real world
is constructed through a combination (and arbitration) of such attributed
statements only, and there is no class in the RIM whose objects represent
"objective state of affairs" or "real processes" independent from attributed
statements. As such, there is no distinction between an activity and its
documentation. Every Act includes both to varying degrees. For
example, a factual statement made about recent (but past) activities,
authored (and signed) by the performer of such activities, is commonly known
as a procedure report or original documentation (example, surgical procedure
report, clinic note etc.). Conversely, a status update on an activity that is
presently in progress, authored by the performer (or a close observer) is
considered to capture that activity (and is later superceded by a full
procedure report). However, both status update and procedure report are acts
of the same kind, only distinguished by mood and state (see
statusCode) and completeness of the information.
Participation,
Entity,
Role,
ActRelationship| Modifier and Type | Method and Description |
|---|---|
void |
addConfidentialityCode(CE confidentialityCode)
Oracle: This is a convenience method.
|
ActRelationship |
addIBActRelationship(CS arType,
Act source)
Adds a new inbound act relationship to this act.
|
void |
addId(II id)
Adds an instance identifier to the set of instance identifiers for the
act.
|
ActRelationship |
addOBActRelationship(CS arType,
Act target)
Adds a new outbound act relationship to this act.
|
Participation |
addParticipation(CS partType,
Role target)
Adds a new participation to this act.
|
void |
addPriorityCode(CE priorityCode)
Oracle: This is a convenience method.
|
void |
addReasonCode(CE reasonCode)
Oracle: This is a convenience method.
|
GTS |
getActivityTime() |
TS |
getAvailabilityTime()
The point in time at which information about
Act-instance
(regardless of mood) first became available to a system reproducing this
Act. |
CS |
getClassCode()
A code specifying the major type of
Act that this
Act-instance represents. |
CD |
getCode()
A code specifying the particular kind of
Act that the
Act-instance represents within its class. |
SET<CE> |
getConfidentialityCode()
A code that controls the disclosure of information about this
Act, regardless of mood. |
ST |
getDerivationExpr()
A character string containing a formal language expression that specifies
how the
Act's attributes are derived from input parameters
associated with derivation relationships. |
GTS |
getEffectiveTime()
A time expression specifying the focal or operative time of the
Act, the primary time for which the Act holds,
the time of interest from the perspective of the Act's
intention. |
Iterator |
getIBActRelationships()
Provides navigational queries on inbound act relationships.
|
Iterator |
getIBActRelationships(ActRelationshipFetch actRelationshipFetch)
Provides navigational queries on inbound act relationships.
|
SET<II> |
getId()
A unique identifier for the
Act. |
BL |
getIndependentInd()
An indicator specifying whether the
Act can be manipulated
independently of other acts or whether manipulation of the
Act can only be through a super-ordinate composite
Act that has this Act as a component. |
BL |
getInterruptibleInd()
An indicator specifying whether
Act is interruptible by
asynchronous events. |
CE |
getLanguageCode()
The primary language in which this
Act statement is
specified, particularly the language of the Act.text. |
CE |
getLevelCode()
Code specifying the level within a hierarchical
Act
composition structure and the kind of contextual information attached to
composite acts ("containers") and propagated to component acts within
those containers. |
CS |
getMoodCode()
A code distinguishing whether an
Act is conceived of as a
factual statement or in some other manner as a command, possibility,
goal, etc. |
BL |
getNegationInd()
An indicator specifying that the
Act statement is a negation
of the Act as described by the descriptive attributes. |
Iterator |
getOBActRelationships()
Provides navigational queries on outbound act relationships.
|
Iterator |
getOBActRelationships(ActRelationshipFetch actRelationshipFetch)
Provides navigational queries on outbound act relationships.
|
Iterator |
getParticipations()
Gets all the retrieved participations for this act.
|
Iterator |
getParticipations(ParticipationFetch participationFetch)
Gets participations returned based on this fetch object for the act.
|
SET<CE> |
getPriorityCode()
A code or set of codes (example, for routine, emergency), specifying the
urgency under which the
Act happened, can happen, is
happening, is intended to happen, or is requested/demanded to happen. |
SET<CE> |
getReasonCode()
A code specifying the motivation, cause, or rationale of an
Act, when such rationale is not reasonably represented as an
ActRelationship of type "has reason" linking to another
Act. |
IVL<INT> |
getRepeatNumber() |
CS |
getStatusCode()
A code specifying the state of the
Act. |
ED |
getText()
A textual or multimedia description of the
Act. |
ST |
getTitle()
A word or phrase by which a specific
Act may be known among
people. |
CE |
getUncertaintyCode()
A code indicating whether the
Act statement as a whole, with
its subordinate components has been asserted to be uncertain in any way. |
void |
setActivityTime(GTS time) |
void |
setAvailabilityTime(TS time) |
void |
setConfidentialityCode(SET<CE> confidentialityCode) |
void |
setDerivationExpr(ST derivationExpr) |
void |
setEffectiveTime(GTS time) |
void |
setIndependentInd(BL independentInd) |
void |
setInterruptibleInd(BL interruptibleInd) |
void |
setLanguageCode(CE languageCode) |
void |
setLevelCode(CE levelCode) |
void |
setNegationInd(BL negationInd) |
void |
setPriorityCode(SET<CE> priorityCode) |
void |
setReasonCode(SET<CE> reasonCode) |
void |
setRepeatNumber(IVL<INT> repeatNumber) |
void |
setStatusCode(CS statusCode) |
void |
setText(ED text) |
void |
setTitle(ST title) |
void |
setUncertaintyCode(CE uncertaintyCode) |
getControlAct, getToken, setTokencreateNewVersion, getVersionNum, isCurrentVersionCS getClassCode()
Act that this
Act-instance represents.
Constraints: The classCode domain is a tightly controlled
vocabulary, not an external or user-defined vocabulary.
Every Act-instance must have a classCode. If
the act class is not further specified, the most general
Act.classCode is used.
The Act.classCode must be a generalization of the specific
Act concept (example, as expressed in
Act.code), in other words, the Act concepts
conveyed in an Act must be specializations of the
Act.classCode. Especially, the classCode is
not a "modifier" or the Act.code that can alter the meaning
of a class code. (See Act. code for contrast.)
Act
factory.CS getMoodCode()
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.typeCode.)
Discussion: The Act.moodCode includes the following notions:
(1) event, i.e., factual description of an actions that occurred; (2)
definition of possible actions and action plans (the master file layer);
(3) intent, i.e., an action plan instantiated for a patient as a care
plan or order; (4) goal, i.e., an desired outcome attached to patient
problems and plans; and (5) criterion, i.e., a predicate used to evaluate
a logical expression.
The Act.moodCode modifies the meaning of the Act class in a
controlled way, just as in natural language, grammatical form of a verb
modify the meaning of a sentence in defined ways. For example, if the
mood is factual (event), then the entire act object represents a known
fact. If the mood expresses a plan (intent), the entire act object
represents the expectation of what should be done. The mood does not
change the meaning of individual act properties in peculiar ways.
Since the mood code is a determining factor for the meaning of an entire
Act object, the mood must always be known. This means,
whenever an act object is instantiated, the mood attribute must be
assigned to a valid code, and the mood assignment cannot change
throughout the lifetime of an act object.
As the meaning of an act object is factored in the mood code, the mood
code affects the interpretation of the entire Act object and
with it every property (attributes and associations). Note that the mood
code affects the interpretation of the act object, and the meaning of the
act object in turn determines the meaning of the attributes. However, the
mood code does not arbitrarily change the meaning of individual
attributes.
Inert vs. descriptive properties of acts: acts have two kinds of act
properties, inert and descriptive properties. Inert properties are not
affected by the mood, descriptive properties follow the mood of the
object. For example, there is an identifier attribute
Act. id, which gives a unique identification to an act
object. Being a unique identifier for the object is in no way dependent
on the mood of the act object. Therefore, the "interpretation" of the
Act.id attribute is inert with respect to the act object's
mood.
By contrast, most of the Act class' attributes are
descriptive for what the Act statement expresses.
Descriptive properties of the Act class give answer to the
questions who, whom, where, with what, how and when the action is done.
The questions who, whom, with what, and where are answered by
participations, while how and when are answered by descriptive attributes
and act relationships. The interpretation of a descriptive attribute is
aligned to the interpretation of the entire act object, and controlled by
the mood.
Examples: To illustrate the effect of mood code, consider a "blood glucose" observation:
The DEFINITION mood specifies the Act of "obtaining blood
glucose". Participations describe in general the characteristics of the
people who must be involved in the act, and the required objects,
example, specimen, facility, equipment, etc. involved. The
Observation.value specifies the absolute domain (range) of
the observation (example, 15-500 mg/dl).
In INTENT mood the author of the intent expresses the intent that he or
someone else "should obtain blood glucose". The participations are the
people actually or supposedly involved in the intended act, especially
the author of the intent or any individual assignments for group intents,
and the objects actually or supposedly involved in the act (example,
specimen sent, equipment requirements, etc.). The
Observation.value is usually not specified, since the intent
is to measure blood glucose, not to measure blood glucose in a specific
range. (But compare with GOAL below).
In REQUEST mood, a kind of intent, the author requests to "please obtain
blood glucose". The participations are the people actually and supposedly
involved in the act, especially the placer and the designated filler, and
the objects actually or supposedly involved in the act (example, specimen
sent, equipment requirements, etc.). The Observation. value
is usually not specified, since the order is not to measure blood glucose
in a specific range.
In EVENT mood, the author states that "blood glucose was obtained".
Participations are the people actually involved in the act, and the
objects actually involved (example, specimen, facilities, equipment). The
Observation.value is the value actually obtained (example,
80 mg/dL, or < 15 mg/dL).
In
e
vent-CRITERION mood, an author considers a certain class of "obtaining
blood glucose" possibly with a certain value (range) as outcome. The
participations constrain the criterion, for instance, to a particular
patient. The Observation.value is the range in which the
criterion would hold (example, > 180 mg/dL or 200-300 mg/dL).
In GOAL mood (a kind of criterion), the author states that "our goal is
to be able to obtain blood glucose with the given value (range)". The
participations are similar to intents, especially the author of the goal
and the patient for whom the goal is made. The
Observation. value is the range which defined when the goal
is met (example, 80-120 mg/dl).
Rationale: The notion of "mood" is borrowed from natural language grammar, the mood of a verb (lat. modus verbi).
The notion of mood also resembles the various extensions of the logic of
facts in modal logic and logic with modalities, where the
moodCode specifies the modality (fact, possibility,
intention, goal, etc.) under which the Act-statement is
judged as appropriate or defective.
ActRelationship,
ObservationAct by the
Act factorySET<II> getId()
Act.
Oracle: Identifiers are only required to be unique within specific
domains. acts created by the ActFactory always contain one
Identifier generated by HDR.
CD getCode()
Act that the
Act-instance represents within its class.
Constraints: The kind of Act (example, physical examination,
serum potassium, inpatient encounter, charge financial transaction, etc.)
is specified with a code from one of several, typically external, coding
systems. The coding system will depend on the class of Act,
such as LOINC for observations, etc.
Conceptually, the Act.code must be a specialization of the
Act.classCode. This is why the structure of
ActClass domain should be reflected in the superstructure of
the ActCode domain and then individual codes or externally
referenced vocabularies subordinated under these domains that reflect the
ActClass structure.
Act.classCode and Act.code are not modifiers of
each other but the Act. code concept should really imply the
Act.classCode concept. For a negative example, it is not
appropriate to use an Act. code "potassium" together with
and Act.classCode for "laboratory observation" to somehow
mean "potassium laboratory observation" and then use the same
Act.code for "potassium" together with
Act.classCode for "medication" to mean "substitution of
potassium". This mutually modifying use of Act.code and
Act.classCode is not permitted.
Discussion: Act.code is not a required attribute of
Act. Rather than naming the kind of Act using
an Act.code, one can specify the Act using only
the class code and other attributes and properties of the
Act. In general and more commonly, the kind of
Act is readily specified by an ActRelationship
specifying that this Act instantiates another
Act in definition mood. Or, even without reference to an act
definition, the act may be readily described by other attributes, act
relationships and participations. For example, the kind of
SubstanceAdministration may be readily described by
referring to the specific drug, as the Participation of an
Entity representing that drug.
ActRelationshipAct code is set on the
Act by the Act factoryBL getNegationInd()
Act statement is a negation
of the Act as described by the descriptive attributes.
Examples: Used with an Observation event, it allows one to
say "patient has NO chest pain". With an Observation
criterion it negates the criterion analogously, example, "if patient has
NO chest pain for 3 days ...", or "if systolic blood pressure is not
within 90-100 mm Hg ..."
Discussion: The negationInd works as a negative existence
quantifier. This is best explained on acts in criterion mood, and then
translates into all other moods. In criterion mood without negation, one
usually only specifies a few critical attributes and relationships
(features) of an Act, i.e., only those that are needed to
test the criterion. The more features one specifies, the more constrained
(specific) is the criterion. For example, to test for "systolic blood
pressure of 90-100 mm Hg", one would use only the descriptive attributes
Act.code (for systolic blood pressure) and
Observation.value (for 90-100 mm Hg). If one would also
specify an effectiveTime, i.e., for "yesterday", the criterion would be
more constrained. If the negationInd is true for the above criterion,
then the meaning of the test is whether a systolic blood pressure of
90-100 mm Hg yesterday does not exist (independent of whether any blood
pressure was measured).
The negationInd negates the Act as described by the
descriptive properties (including Act.code,
Act.effectiveTime, Observation. value,
Act.doseQty, etc.) and any of its components. The inert
properties such as Act.id, Act.moodCode,
Act.confidentialityCode, and particularly the
Author-Participation are not negated. These
inert properties always have the same meaning: i.e., the author remains
to be the author of the negative observation. Also, most act
relationships (except for components) are not included in the negation.
For example, a highly confidential order written by Dr. Jones, to
explicitly not give "succinyl choline" for the "reason"
(ActRelationship) of a history of malignant hyperthermia
(Observation) negates the descriptive properties "give
succinyl choline" (Act.code), but it is still positively an
order and written by Dr. Jones and for patient John Smith, and the reason
for this order is the patient's history of malignant hyperthermia.
However, additional detail in descriptive attributes will be part of the
negation which then limits the effectiveness of the negated statement.
For example, had the order not to give a substance included a
doseQuantity, it would mean that the substance should not be
given at that particular dose (but any other dose might still be
O.K.).
An act statement with negationInd is still a statement about
the specific fact described by the Act. For instance, a
negated "finding of wheezing on July 1" means that the author positively
denies that there was wheezing on July 1, and that he takes the same
responsibility for such statement and the same requirement to have
evidence for such statement than if he had not used negation. Conversely,
negation indicator does not just negate that the fact was affirmed or
that the statement had been made. This holds for all moods in the same
way, example, a negated order is an order not to do the described act,
not just the lapidary statement that there is no such order.
ActRelationship,
Observationvoid setNegationInd(BL negationInd) throws HDRRimException
HDRRimExceptionST getDerivationExpr()
Act's attributes are derived from input parameters
associated with derivation relationships.
Discussion: Derived observations can be defined through association with
other observations using act relationships of type "derivation". For
example, to define a derived Observation for Mean
Corpuscular Hemoglobin (MCH) one will associate the MCH observation with
a Hemoglobin (HGB) observation and a Red Blood cell Count (RBC)
observation. And the derivation expression encodes the formula: MCH = HGB
/ RBC.
The derivation expression is represented as a character string.
[Note: The syntax of that expression is yet to be fully specified. There would be a single standard expression language rather than an optional choice between many expression languages. The syntax would be based on a de-facto standard for many object-oriented languages, such as C++, Java, OCL etc. A concrete specification of this expression language is being worked on now and drafts can be expected within the year 2003.]
Observationvoid setDerivationExpr(ST derivationExpr) throws HDRRimException
HDRRimExceptionST getTitle()
Act may be known among
people.
Example: name of a research study (example, "Scandinavian Simvastatin Study"), name of a court case (example, "Brown v. Board of Education"), name of another kind of work project or operation. For acts representing documents, this is the title of the document.
Discussion: This is not a formal identifier but rather a
human-recognizable common name. However it is similar to the id attribute
in that it refers to a specific Act rather than a 'kind' of
act. (For definition mood, the title refers to that specific definition,
rather than to a broad category that might be conveyed with
Act.code)
Note: This attribute was not in the normative content balloted and approved for the first release of HL7's Reference Information Model Standard. The attribute will be considered when the RIM is prepared for balloting the second release. The attribute is being used in current HL7 Version 3 designs.
void setTitle(ST title) throws HDRRimException
HDRRimExceptionGTS getEffectiveTime()
Act, the primary time for which the Act holds,
the time of interest from the perspective of the Act's
intention.
Examples: For clinical observations, the effectiveTime is
the time at which the observation holds (is effective) for the
patient.
For contracts, the effectiveTime is the time for which the
contract is in effect.
For consents, the effectiveTime is the time for which the
consent is valid.
For substance administrations, the effective time is the time over which the substance is to be administered, including the frequency of administration (example, TID for 10 days)
For a surgical procedure (operation), the effectiveTime is the time relevant for the patient, i.e., between incision and last suture.
For transportation acts, the effective time is the time the transported payload is en route.
For patient encounters, this is the "administrative" time, i.e., the encounter start and end date required to be chosen by business rules, as opposed to the actual time the healthcare encounter related work is performed.
Discussion: The effectiveTime is also known as the "primary"
time (Arden Syntax) or the "biologically relevant time" (HL7 v2.x). This
attribute is distinguished from activityTime.
For observations, the time of the observation activity may be much later than the time of the observed feature. For instance, in a Blood Gas Analysis (BGA), a result will always come up several minutes after the specimen was taken, meanwhile the patient's physiological state may have changed significantly.
For essentially physical activities (surgical procedures,
transportations, etc.), the effective time is the time of interest for
the Act's intention, i.e., since the intention of a
transportation is to deliver a payload from location A to B, the
effectiveTime is the time this payload is underway from A to B. However,
the Act usually also includes accidental work which is
necessary to perform the intention of the Act, but is not
relevant for the Act's purpose.
For example, the time a driver needs to go to the pick-up location A and then return from drop-off location B to some home base, is included in the physical activity, but does not matter from the perspective of the payload's transportation. Another example is: a person's work hours (effectiveTime) may be from 8 AM to 5 PM, no matter whether that person needs 10 minutes for the commute or 2 hours. The commute is necessary to be at work, but it is not essential for the work hours.
Observationvoid setEffectiveTime(GTS time) throws HDRRimException
HDRRimExceptionGTS getActivityTime()
A time expression specifying when an Observation, Procedure, or other Act occurs, or, depending on the mood, is supposed to occur, scheduled to occur, etc. It tells you when the labor was done for an Act. The activityTime includes the times of component actions (such as preparation and clean-up)For Procedures and SubstanceAdministrations, the activityTime can provide a needed administrative / scheduling function by providing a more complete time that needs to be anticipated for particular acts.
Discussion: The activityTime is more of administrative rather than clinical use. The clinically relevant time is the effectiveTime. When an observation of a prior symptom is made, the activityTime describes the time the observation is made, as opposed to effectiveTime which is the time the symptom occurred. Thus the activityTime may be entirely different than the effectiveTime of the same Act. But even apart from clinical use cases, designers should first consider effectiveTime as the primary relevant time for an Act.
The activityTime is a descriptive attribute, i.e., like effectiveTime, it always describes the Act event as it does or would occur, even when working with different moods. For example, when a procedure is requested, the activityTime describes the requested total time of the procedure. By contrast, the author Participation.time is inert, i.e., author participation time on an order specifies when the order was written and has nothing to do with when the event might actually occur.
ActivityTime indicates when an Act occurs, not when an Act is recorded. Many applications track the time an observation is recorded rather than the precise time during which an observation is made, in which case Participation.time (e.g. of the Author) should be used. These recorded observations can take place during an encounter, and the time of the encounter often provides enough information so that activityTime isn't clinically relevant.
Observationvoid setActivityTime(GTS time) throws HDRRimException
HDRRimExceptionTS getAvailabilityTime()
Act-instance
(regardless of mood) first became available to a system reproducing this
Act.
Examples: An Act might record that a patient had a
right-ventricular myocardial infarction effective three hours ago (see
Act.effectiveTime), but we may only know about this unusual
condition a few minutes ago (Act.availabilityTime). Thus,
any interventions from three hours ago until a few minutes ago may have
assumed the more common left-ventricular infarction, which can explain
why these interventions (example, nitrate administration) may not have
been appropriate in light of the more recent knowledge.
Discussion: The availabilityTime is a subjective secondary piece of
information added (or changed) by a system that reproduces this
Act, and is not attributed to the author of the act
statement (it would not be included in the material the author would
attest to with a signature). The system reproducing the Act
is often not the same as the system originating the Act, but
a system that received this Act from somewhere else, and,
upon receipt of the Act, values the availabilityTime to
convey the time since the users of that particular system could have
known about this Act-instance.
When communicating availabilityTime to another system, the
availabilityTime of an Act A is attributed to
the author of another Act B, that refers to or includes A.
For example, if a medical record extract is compiled for reporting
adverse events, availabilityTimes are attributed to the
author who compiles that report.
void setAvailabilityTime(TS time) throws HDRRimException
HDRRimExceptionCS getStatusCode()
Act.
void setStatusCode(CS statusCode) throws HDRRimException
HDRRimExceptionIterator getIBActRelationships()
Provides navigational queries on inbound act relationships. An inbound
act relationship has this act as the target of the act relationship.If
multiple fetch objects were attached in the query, then this method would
return the union of all the results that the individual fetch objects
have returned. If this method is called on an Act obtained
through ActFactory then this would return inbound
Act Relationships added locally. If this method is called on
an Act versioned through createNewVersion call,
then this would return all the carried forward inbound act relationships
plus any inbound act relationships added locally and minus any inbound
act relationships deleted. locally.
ActRelationship,
ActFactoryIterator getIBActRelationships(ActRelationshipFetch actRelationshipFetch) throws HDRRimException
Provides navigational queries on inbound act relationships. An inbound
act relationship has this act as the target of the act relationship. If
this actRelationshipFetch object was used in the query, then
this method would return the inbound act relationships fetched due to
this fetch object. Otherwise it would return null.
actRelationshipFetch - fetch object containing the search criteria.HDRRimException - under following conditions:
actRelationshipFetch parameter is passed as
null.Act object is not a queried object (i.e.
obtained through ActFactory or createNewVersion
method).ActRelationship,
ActFactoryIterator getOBActRelationships()
Provides navigational queries on outbound act relationships. An outbound
act relationship has this act as the source of the act relationship. If
multiple fetch objects were attached in the query, then this method would
return the union of all the results that the individual fetch objects
have returned. If this method is called on an Act obtained
through ActFactory then this would return outbound act
relationships added locally. If this method is called on an
Act versioned through createNewVersion call,
then this would return all the carried forward outbound act relationships
plus any outbound act relationships added locally and minus any outbound
act relationships deleted locally.
ActRelationship,
ActFactoryIterator getOBActRelationships(ActRelationshipFetch actRelationshipFetch) throws HDRRimException
Provides navigational queries on outbound act relationships. An outbound
act relationship has this act as the source of the act relationship. If
this actRelationshipFetch object was used in the query, then
this method would return the outbound act relationships fetched due to
this fetch object. Otherwise it would return null.
actRelationshipFetch - Fetch object containing the
search criteria.HDRRimException - under following conditions:
actRelationshipFetch parameter is passed as
null.Act object is not a queried object (i.e.
obtained through ActFactory or
createNewVersion method).ActRelationship,
ActFactoryvoid addId(II id) throws HDRRimException
Adds an instance identifier to the set of instance identifiers for the act.
id - the identifier to add to the existing set of identifiers. The
II is unique across a broad class (Act, Entity, non-owned Role) rather
than across the finer grained classes of HL7.HDRRimExceptionIterator getParticipations()
Gets all the retrieved participations for this act. If multiple fetch
objects were attached in the query, then this method would return the
union of all the results that the individual fetch objects have returned.
If this method is called on an Act obtained through
ActFactory then this would return participation added
locally. If this method is called on an Act versioned
through createNewVersion call, then this would return all
the carried forward participations plus any participations added locally
and minus any participations deleted locally.
ActFactory,
ParticipationIterator getParticipations(ParticipationFetch participationFetch) throws HDRRimException
Gets participations returned based on this fetch object for the act. If
this participationFetch object was used in the query, then
this method would return the participations fetched due to this fetch
object. Otherwise it would return null.
participationFetch - fetch object containing the search criteria.HDRRimException - under following conditions:
participationFetch parameter is passed as
null.Act object is not a queried object (i.e.
obtained through ActFactory or createNewVersion
method).ActFactoryActRelationship addIBActRelationship(CS arType, Act source) throws HDRRimException
See addParticipation method for an example of how relationships are removed.
arType - The ActRelationship Typesource - The source ActActRelationship with this Act as
the target and the given act relationship type and the source act.HDRRimException - under following conditions:
arType parameter is passed as null.source parameter is passed as null.Act object is a queried object (i.e. not
obtained through ActFactory or createNewVersion
method).ActFactoryActRelationship addOBActRelationship(CS arType, Act target) throws HDRRimException
See addParticipation method for an example of how relationships are removed.
arType - The ActRelationship Typetarget - The target ActActRelationship with this Act as
the source and the given act relationship type and the target act.HDRRimException - under following conditions:
arType parameter is passed as null.target parameter is passed as null.Act object is a queried object (i.e. not
obtained through ActFactory or createNewVersion
method).ActRelationship,
ActFactoryParticipation addParticipation(CS partType, Role target) throws HDRRimException
The following is an example of iterating through list of participations
associated with an act and deleting all Verifier (VRF) participations as
might be done when updating an Observation.
// Assume act had been retrieved via a query to HDR
Act act = (Act)act.createNewVersion();
//Get an iterator to the participations (this method allows filtering, but we'll
//ignore that to show more details of how this works)
Iterator iter = act.getParticipations();
while (iter.hasNext())
{
Participation part = (Participation) iter.next();
if (part.getTypeCode().equals(CSParticipationType.VRF))
{
iter.remove();
}
}
// Submitting the act to HDR will remove
partType - The participation typetarget - The target roleHDRRimException - under following conditions:
partType parameter is passed as null.target parameter is passed as null.Act object is a queried object (i.e. not
obtained through ActFactory or createNewVersion
method).Observation,
ActFactorySET<CE> getPriorityCode()
Act happened, can happen, is
happening, is intended to happen, or is requested/demanded to happen.
Discussion: This attribute is used in orders to indicate the ordered priority, and in event documentation it indicates the actual priority used to perform the act. In definition mood it indicates the available priorities.
void setPriorityCode(SET<CE> priorityCode) throws HDRRimException
HDRRimExceptionvoid addPriorityCode(CE priorityCode) throws HDRRimException
Oracle: This is a convenience method. All datatypes, including collections, are immutable. Therefore, this function will create a new collection with the new item appended (added) to it.
HDRRimExceptionSET<CE> getConfidentialityCode()
Act, regardless of mood.
Discussion: It is important to note that the necessary confidentiality of the medical record cannot be achieved solely through confidentiality codes to mask individual record items from certain types of users. There are two important problems with per-item confidentiality: one is inference and the other is the danger of holding back information that may be critical in a certain care situation. Inference means that filtered sensitive information can still be assumed given the other information that was not filtered. The simplest form of inference is that even the existence of a test order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not known. Very often, diagnoses can be inferred from medication, such as Zidovudin for treatment of HIV infections. The problem of hiding individual items becomes especially difficult with current medications, since the continuing administration of the medication must be assured.
To mitigate some of the inference-risk, aggregations of data should assume the confidentiality level of the most confidential action in the aggregation.
void setConfidentialityCode(SET<CE> confidentialityCode) throws HDRRimException
HDRRimExceptionvoid addConfidentialityCode(CE confidentialityCode) throws HDRRimException
Oracle: This is a convenience method. All datatypes, including collections, are immutable. Therefore, this function will create a new collection with the new item appended (added) to it.
HDRRimExceptionIVL<INT> getRepeatNumber()
An interval of integer numbers stating the minimal and maximal number of repetitions of the Act.
Examples: An oral surgeon's advice to a patient after tooth extraction might be: "replace the gauze every hour for 1 to 3 times until bleeding has stopped completely." This translates to repeatNumber with low boundary 1 and high boundary 3.
The number of repeats is additionally constrained by time. The act will repeat at least the minimal number of times and at most, the maximal number of times. Repetitions will also terminate when the time exceeds the maximal Act.effectiveTime, whichever comes first.
Usage: On an Act in Event mood, the repeatNumber is usally 1. If greater than 1, the Act is representing a summary of several event occurrences occurring over the time interval described by effectiveTime
To distinguish occurrences of acts within a sequence of repetitions, use ActRelationship.sequenceNumber
void setRepeatNumber(IVL<INT> repeatNumber) throws HDRRimException
HDRRimExceptionBL getInterruptibleInd()
Act is interruptible by
asynchronous events.
Discussion: Act events that are currently active can be
interrupted in various ways. Interrupting events include: (1) when an
explicit abort request is received against the Act (2) when
the time allotted to this Act expires (timeout); (3) a
"through condition" ceases to hold true for this Act (see
ActRelationship.checkpointCode); (4) the Act is a component
with the joinCode "kill" and all other components in that
same group have terminated (see Act.joinCode); and (5) when
a containing Act is being interrupted.
If an Act receives an interrupt and the Act
itself is interruptible, but it has currently active component-acts that
are non-interruptible, the Act will be interrupted when all
of its currently active non-interruptible component-acts have
terminated.
ActRelationshipvoid setInterruptibleInd(BL interruptibleInd) throws HDRRimException
HDRRimExceptionCE getLevelCode()
Act
composition structure and the kind of contextual information attached to
composite acts ("containers") and propagated to component acts within
those containers. The levelCode signifies the position
within such a containment hierarchy and the applicable constraints.
Discussion: Readers should be aware that this attribute may be declared
"obsolescent" in the next normative release of the HL7 RIM. An alternate
representation of this concept using a specified hierarchy of
Act class code values is being considered. If the change is
adopted, HL7's RIM maintenance procedures state that the
levelCode would be declared "obsolescent" in the next RIM
release, and then become "obsolete" in the release following that. Users
are advised to check with the latest HL7 internal definitions of the RIM,
before using this attribute.
The levelCode concepts have been defined to meet specific
health record transfer requirements. While these concepts are known to be
applicable to some other types of transactions, they are not intended to
be a complete closed list. Options exist for other sets of orthogonal
levels where required to meet a business purpose (example, a multiple
patient communication may be subdivided by a super-ordinate level of
subject areas).
Examples: The "extract level" and the "folder level" must contain data about a single individual, whereas the "multiple subject level" may contain data about multiple individuals. While "extract" can originate from multiple sources, a "folder" should originate from a single source. The "composition" level usually has a single author.
Constraints: The constraints applicable to a particular level may include
differing requirements for participations (example, patient, source
organization, author or other signatory), relationships to or inclusion
of other acts, documents or use of templates. The constraints pertaining
to a level may also specify the permissible levels that may be contained
as components of that level. Several nested levels with the same
levelCode may be permitted, prohibited (or limited).
Instances of the next subordinate level are usually permitted within any
level but some levels may be omitted from a model and it may be
permissible to skip several layers.
void setLevelCode(CE levelCode) throws HDRRimException
HDRRimExceptionBL getIndependentInd()
Act can be manipulated
independently of other acts or whether manipulation of the
Act can only be through a super-ordinate composite
Act that has this Act as a component. By
default the independentInd should be true.
Examples: An Act definition is sometimes marked with
independentInd=false if the business rules would not allow this act to be
ordered without ordering the containing act group.
An order may have a component that cannot be aborted independently of the other components.
void setIndependentInd(BL independentInd) throws HDRRimException
HDRRimExceptionCE getUncertaintyCode()
Act statement as a whole, with
its subordinate components has been asserted to be uncertain in any way.
Examples: Patient might have had a cholecystectomy procedure in the past (but isn't sure).
Constraints: Uncertainty asserted using this attribute applies to the
combined meaning of the Act statement established by all
descriptive attributes (example, Act.code,
Act.effectiveTime, Observation.value,
SubstanceAdministration.doseQuantity, etc.), and the
meanings of any components.
Discussion: This is not intended for use to replace or compete with
uncertainty associated with Observation. value alone or
other individual attributes of the class. Such pointed indications of
uncertainty should be specified by applying the PPD, UVP or UVN data type
extensions to the specific attribute. Particularly if the uncertainty is
uncertainty of a quantitative measurement value, this must still be
represented by a PPD<;PQ>
in the value and not using the uncertaintyCode. Also, when
differential diagnoses are enumerated or weighed for probability, the
UVPuncertaintyCode.
The use of the uncertaintyCode is appropriate only if the
entirety of the Act and its dependent acts is
questioned.
Note that very vague uncertainty may be thought related to negationInd, however, the two concepts are really independent. One may be very uncertain about an event, but that does not mean that one is certain about the negation of the event.
Patient,
Observationvoid setUncertaintyCode(CE uncertaintyCode) throws HDRRimException
HDRRimExceptionSET<CE> getReasonCode()
Act, when such rationale is not reasonably represented as an
ActRelationship of type "has reason" linking to another
Act.
Examples: Example reasons that might qualify for being coded in this field might be: "routine requirement", "infectious disease reporting requirement", "on patient request", "required by law".
Discussion: Most reasons for acts can be clearly expressed by linking the
new Act to another prior Act using an
ActRelationship of type "has reason". This simply states
that the prior Act is a reason for the new Act
(see ActRelationship). The prior act can then be a specific
existing act or a textual explanation. This works for most cases, and the
more specific the reason data is, the more should this reason
ActRelationship be used instead of the
reasonCode.
The reasonCode remains as a place for common reasons that
are not related to a prior Act or any other condition
expressed in acts. Indicators that something was required by law or was
on the request of a patient etc. may qualify. However, if that piece of
legislation, regulation, or the contract or the patient request can be
represented as an Act (and they usually can), the
reasonCode should not be used.
ActRelationshipvoid setReasonCode(SET<CE> reasonCode) throws HDRRimException
HDRRimExceptionvoid addReasonCode(CE reasonCode) throws HDRRimException
Oracle: This is a convenience method. All datatypes, including collections, are immutable. Therefore, this function will create a new collection with the new item appended (added) to it.
HDRRimExceptionCE getLanguageCode()
Act statement is
specified, particularly the language of the Act.text.
void setLanguageCode(CE languageCode) throws HDRRimException
HDRRimExceptionED getText()
Act.
Examples: For act definitions, the Act.text can contain
textbook-like information about that act. For act orders, the description
will contain particular instructions pertaining only to that order.
Constraints: No restriction on length or content is imposed on the
Act.text attribute.
The content of the description is not considered part of the functional information communicated between computer systems.
Free text descriptions are used to help an individual interpret the content and context of the act, but all information relevant for automated functions must be communicated using the proper attributes and associated objects.
For acts that involve human readers and performers, however, computer
systems must show the Act.text field to a human user, who
has responsibility for the activity; or at least must indicate the
existence of the Act.text information and allow the user to
see that information.
Act information as an EDvoid setText(ED text) 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