HL7 Reference Information Model

The anatomic site where the Access (cannula, line or drain) first enters the body and, if applicable, a routing from the first entrance to the target site.

Rationale:

Since accesses are typically placed for a considerable period of time, and since the access is used as a resource of many acts, the access approach site becomes an important identifying attribute of the access itself (as opposed to merely being an attribute of the placement procedure).

Examples:

An arteria pulmonalis catheter targeting a pulmonary artery, with the access approach site being the vena carotis interna at the neck, or the vena subclavia at the fossa subclavia.

FormalConstraint:

The coding system is the same as for Procedure.approachSiteCode; indeed, the Access.approachSiteCode has been copied from the Procedure class into the Access role class. The value of the Access.approachSiteCode should be identical to the value of the Procedure.approachSiteCode of an associated access placement procedure.

The site or body compartment into which access is being provided, (i.e., the compartment into which material is administered or from which it is collected).

Rationale:

Since accesses are typically placed for a considerable period of time, and since the access is used as a resource of many acts, the target site becomes an important identifying attribute of the access itself (as opposed to merely being an attribute of the placement procedure). The target site is important information that determines what kinds of substances may or may not be administered (e.g., special care to avoid medication injections into an arterial access).

Examples:

For a pulmonary artery catheter, the target site "arteria pulmonalis."

FormalConstraint:

The coding system is the same as for Procedure.targetSiteCode; indeed, the Access.targetSiteCode has been copied from the Procedure class into the Access role class. The value of the Access.targetSiteCode SHOULD be identical to the value of the Procedure.targetSiteCode of an associated access placement procedure.

The inner diameter of the access.

Examples:

The lumen of the tube.

The sum total of the debit and credit transactions that have posted to the account.

UsageNotes:

The balance of an account will generally be communicated in the currency identified as the account's currencyCode. However, one MAY communicate the balance in alternative currencies.

The currency that the account is managed in.

UsageNotes:

Specific amounts might be reported in another currency, but this attribute represents the default currency for activity in this account.

The rate of interest that the account balance may be subject to.

UsageNotes:

This may represent interest charged (e.g., for loans, overdue accounts, etc.) or credited (investments, etc.) depending on the type of account.

Examples:

0.10/1a (10%/year); 0.0005895/1d (.05895%/day)

FormalConstraint:

Unit of the denominator PQ data type SHALL be comparable to seconds; i.e., the denominator must be measured in time.

An interval describing the minimum and maximum allowed balances for an account.

UsageNotes:

These are not necessarily 'hard' limits (i.e., the account may go above or below the specified amounts), however, they represent the 'target' range for the account, and there may be consequences for going outside the specified boundaries. It is not necessary to specify both upper and lower limits (or either) for an account.

Examples:

Stop loss limits, credit limits

The acknowledgement as defined in an enumerated set of acknowledgement types.

Examples:

The receiving application successfully processed message; the receiving application found error(s) in message

The sequence number of the message within a set of messages.

The number of messages the acknowledging application has waiting in queue for the receiving application.

UsageNotes:

These messages would need to be retrieved via queries. The message count facilitates receiving applications that cannot receive unsolicited message (i.e., polling).

Examples:

If there are 3 low priority messages, 1 medium priority message and 1 high priority message, the message waiting number would be 5, because that is the total number of messages.

The highest level of importance in the set of messages the acknowledging application has waiting in queue for the receiving application.

UsageNotes:

These messages would need to be retrieved via queries. This facilitates receiving applications that cannot receive unsolicited messages (i.e., polling). The specific code specified identifies how important the most important waiting message is and may affect how soon the receiving application is required to poll for the message. Priority may be used by local agreement to determine the timeframe in which the receiving application is expected to retrieve the messages from the queue

The kind of information specified in the acknowledgement message.

Examples:

Error, warning, information.

The type of acknowledgement, from an enumerated set of acknowledgement types.

DesignComments:

Original examples seem to indicate text, not code, by including specific attributes, dates. New examples supplied from concept domain.

Examples:

Required attribute missing; unsupported interaction; invalid code system in CNE.

Additional diagnostic information relevant to the message.

UsageNotes:

This may be free text or structured data (e.g., XML).

Examples:

Java exception, memory dump, internal error code, call-stack information

Definition: The position within the message being acknowledged that is related to the acknowledgement message.

UsageNotes:

Only messages with localized errors will have this attribute populated. Open Issue: The specific format for the string that defines the message location needs to be identified. This might be "XPath" or possibly "OCL".

Examples:

Location of missing required attribute; location of invalid code in CNE; location not valued for unsupported interaction.

The major class of Acts to which an Act-instance belongs.

UsageNotes:

For Act-instances that have an Act.code, the Act.code SHALL be a specialization of the Act.classCode. The Act.code, however, cannot alter the meaning of the Act.classCode.

This attribute provides a tightly controlled vocabulary of Act class "types" that is balloted with the RIM, and can be used to represent a type enumeration that might have been represented as a physical class in the RIM, but was not because while it had unique meaning, it did not require unique attributes or unique patterns of associations. The "code" attribute defines a specific sub-type of this Act type, and is intended to allow use of rich terminologies such as LOINC and SNOMED to represent these sub-types.

FormalConstraint:

Every Act-instance SHALL have a classCode. If the act class is not further specified, the most general Act.classCode (ACT) is used.

The intended use of the Act statement: as a report of fact, a command, a possibility, a goal, etc.

UsageNotes:

To describe the progression of a business activity from definition to planning to execution, etc., one must instantiate Act-instances in each of the required moods and link them using ActRelationship of general type "sequel." (See ActRelationship.typeCode.)

Since the mood code is a determining factor for the meaning of an entire Act object, the mood must always be known. This means that whenever an act object is instantiated, the mood attribute SHALL be assigned to a valid code, and the mood assignment SHALL NOT change throughout the lifetime of the act object.

The Act.moodCode modifies the meaning of the Act class in a controlled way, just as in natural language, grammatical form of a verb modifies 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.

As the meaning of an Act-instance 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.

Acts have two kinds of act properties, inert and descriptive. Inert properties are not affected by the mood, but 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 describe what the Act statement expresses. Descriptive properties of the Act class answer 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 ActRelationships. The interpretation of a descriptive attribute is aligned with 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, e.g., specimen, facility, equipment, etc. involved. The Observation.value specifies the absolute domain (range) of the observation (e.g., 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 (e.g., 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 "please measure blood glucose." The Participations identify the people actually and supposedly involved in the act, especially the order placer and the designated filler, and the objects actually or supposedly involved in the act (e.g., 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 measured." Participations indicate the people actually involved in the act, and the objects actually involved (e.g., specimen, facilities, equipment). The Observation.value is the value actually obtained (e.g., 80 mg/dL, or <15 mg/dL).

In Event Criterion (not to be confused with 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 (e.g. > 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 those in Intent mood, especially the author of the goal and the patient for whom the goal is made. The Observation.value is the range which defines when the goal is met (e.g. 80-120 mg/dl).

OpenIssue:

In the May 2009 ballot, a strong Negative vote was lodged against several of the concept definitions in the vocabulary used for Act.moodCode. The vote was found "Persuasive With Mod", with the understanding that M&M would undertake a detailed review of these concept definitions for a future release of the RIM

A unique identifier for the Act.

UsageNotes:

Successful communication only requires that an act have a single identifier assigned to it. However, it is recognized that as different systems maintain different databases, there may be different instance identifiers assigned by different systems.

The particular kind of Act that the Act-instance represents within its class.

UsageConstraint:

Act.code, if used, SHALL be a specialization of the Act.classCode.

UsageNotes:

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. Even without reference to an act definition, the act may be readily described by other attributes, ActRelationships 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.

This attribute defines a specific sub-type of a given Act type (determined by the "classCode" attribute). It allows the use of rich terminologies such as LOINC and SNOMED to represent sub-types of the limited set of Act types defined by "classCode."

Act.classCode and Act.code are not modifiers of each other. The Act.code concept should 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.

DesignComments:

The superstructure of the ActCode domain should reflect the structure of ActClass domain, in order that individual codes or externally referenced vocabularies within ActCode be subordinated to the ActClass structure.

Explain criteria for when it would be appropriate to use code rather than ActRelationship.

Examples:

Physical examination, serum potassium, inpatient encounter, charge financial transaction, etc.

An indicator specifying that the Act statement is a negation of the Act in Event mood as described by the descriptive attributes.

UsageNotes:

The actionNegationInd works as a negative existence quantifier on the actual, intended or described Act event. In Event mood, it indicates the defined act did not occur. In Intent mood, it indicates the defined act is not intended/desired to occur. In Criterion mood, it indicates that the condition is based on the non-occurrence of the event. It is nonsensical to have a negationInd of true for acts with a mood of definition.

The actionNegationInd 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 document characteristic properties such as Act.id, Act.moodCode, Act.confidentialityCode, and particularly the Author-Participation are not negated. These document characteristic properties always have the same meaning: i.e., the author remains to be the author of the negative observation. Also, most ActRelationships (except for components) are not included in the negation. Refer to the attribute isDocumentCharacteristic property and the ActRelationshipType and ParticipationType code system isDocumentCharacteristic properties for specific guidance.

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 actionNegationInd is still a statement about the specific fact described by the Act. For instance, a negated "patient had an appendectomy on July 1" means that the author positively denies that appendectomy occurred 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, the action 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, e.g., a negated order is an order not to do the described act, not just the lapidary statement that there is no such order. Such lapidary statements are handled by negating the control act that created the subject act. I.e. "An order of this type (DEFN mood) with an author of Dr. Smith was not created."

Note that for Observations, actionNegationInd indicates that the act itself did not occur. I.e. no observation took place. To indicate that an observation did occur but the finding was negative, use Observation.valueNegationInd.

Examples:

When used with event mood, allows communicating "Surgery was not performed" or "Consent was not given". When used in order mood, allows communicating "Do not administer this substance". When used in EVN.CRIT mood allows you to say "If the patient is not admitted . . ."

This attribute was deprecated for future use in HL7 Design Models at the September, 2008 Working Group Meeting, effective with RIM release 0221. The semantics of this attribute have been divided between the new actionNegationInd attribute and the Observation.valueNegationInd attribute. For existing models, designers should examine the model documentation and usage to determine which set of semantics apply. New models and new versions of existing models SHALL NOT use this attribute. This attribute will be removed from the RIM as part of the 2011 Normative Edition.

An indication that the Act statement is a negation of the Act as described by the descriptive attributes.

UsageNotes:

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. Of ActRelationships , only components are 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 limit the effective scope of the negation. 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 does not prohibit medication at any other dose.

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, negationInd 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, e.g., a negated order is an order not to do the described act, not just a statement that there is no such order.

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, e.g., "if patient has NO chest pain for 3 days ...," or "if systolic blood pressure is not within 90-100 mm Hg ..."

This attribute was deprecated for future use in HL7 Design Models at the March 2011 Harmonization Meeting. Data types R2, to which this model is bound, contains the EXPR data type that subsumes the use of the previous Act.derivationExpr attribute. As described in the data types R2 standard, EXPR is: "A generic data type extension used to specify an expression that can be used to derive the actual value of T [another data type] given information taken from the context of use." It may be used as part of the data type constraint of any attribute.

A character string containing a formal language expression that specifies how the Act's attributes are, should be, or have been derived from input parameters associated with derivation relationships.

UsageNotes:

Derived observations can be defined through association with other observations using ActRelationships 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: the derivation expression value encodes the formula: MCH = HGB / RBC.

FormalConstraint:

The derivation expression is represented as a character string.

OpenIssue:

The syntax of that expression is yet to be fully specified. Update status of this effort.

A word or phrase by which a specific Act may be known among people.

UsageNotes:

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

Examples:

Name of a research study (e.g., "Scandinavian Simvastatin Study"), name of a court case (e.g., "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.

FormalConstraint:

Previous to release 2.05 of the RIM, this attribute bore the datatype ST. From release 2.05 onwards, the datatype was extended to a constrained restriction of the ED datatype. The constraints to be imposed are identical to those for the ST datatype, except that the mediaType shall be "text/x-hl7-title+xml" or "text/plain". The intent is to allow sufficient mark-up to convey the semantics of scientific phrases, such as chemical compounds. This markup must not be used to convey simple display preferences. The default mediaType should be "text/plain".

A renderable textual or multimedia description (or reference to a description) of the complete information which would reasonably be expected to be displayed to a human reader conveyed by the Act.

UsageNotes:

The content of the description is not considered part of the functional information communicated between computer systems. 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.

Free text descriptions are used to help individuals interpret the content and context of acts, but all information relevant for automated functions SHALL be communicated using the proper attributes and associated objects.

A user SHOULD be able to read Act.text alone, without seeing any of the encoded information, and have no risk of misinterpreting or lacking full understanding of the full content of the Act. For example, II.root, or CD.codeSystem would not normally be displayed to a human and thus would not need to be exposed as part of Act.text.

The rendering is expected to include all 'descendent' ActRelationships and Participations, recursively navigating child Acts as exposed in that particular 'snapshot.' However, there are several data elements which are NOT expected to be included in the rendering. These are

• Component Sections (ActRelationship=COMP, classCode <= DOCSECT)

• The title attribute

• Anything attached to ActRelationship=XFRM)

• Previous versions (ActRelationship=RPLC)

Act.text MAY include information that is not in the other attributes/associations, but SHALL include all information that is in such attributes or associations, with the exception of those identified above.

Act.text SHALL NOT be used for the sharing of computable information. Computable information SHALL be conveyed using discrete attributes. Any information which Act.text contains not elsewhere exposed in encoded information will be opaque to computer systems. For this reason, Act.text SHALL not be used to contain information which negates or significantly modifies the understanding of information encoded in discrete attributes.

To communicate "supplemental text," an act relationship (e.g. "component" or "subject of") should be created to a separate Act with a bare Act.text attribute to convey the supplemental information, possibly with a code indicating "annotation" or some similar concept.

UsageNotes:

Clarify strength of "Act.text SHALL NOT be used for the sharing of computable information": should this be a constraint?

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.

The state of the Act.

UsageNotes:

The status reflects the state of the activity. In the case of an Observation, this is the status of the activity of observing (e.g., "new," "complete," "cancelled"), not the status of what is being observed (e.g., disease status, "Active" allergy to penicillin). To convey the status of the subject being observed, consider coordinating it into the code or value attribute of the Observation or using a related Observation.

The clinically or operationally relevant time of an act, exclusive of administrative activity.

UsageNotes:

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 not be available for 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 (as activityTime), but it does not matter from the perspective of the payload's transportation and is excluded from effectiveTime. Another example: 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 part of the working time.

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 (e.g., 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.

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. 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 function by providing a more inclusive time to be anticipated in scheduling.

UsageNotes:

The activityTime is primarily 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 is reported to have occurred. Thus the activityTime may be entirely different from the effectiveTime of the same Act. However, even apart from clinical use cases, designers should first consider effectiveTime as the primary relevant time for an Act.

ActivityTime indicates when an Act occurs, not when it 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.

ActivityTime is a descriptive attribute: like effectiveTime, it always describes the Act event as it does or would occur. For example, when a procedure is requested, the activityTime describes the requested total time of the procedure, which may differ from the time recorded for the resulting event. 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.

The point in time at which information about Act-instance (regardless of mood) first became available to a system reproducing this Act. The availabilityTime is metadata describing the record, not the Act.

UsageNotes:

The availabilityTime is added (or changed) by any system that receives 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.

A system evaluates availabilityTime on receipt (or creation) of information, and must be able to produce the availabilityTime of the information if and when it communicates that information further.

Rationale:

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 (e.g., nitrate administration) were taken, even though they may not have been appropriate in light of the more recent knowledge.

DesignComments:

Clarify: Does the act acquire a new availability time with each transmission? Does this value indicate to which system it refers? Or is it always defined as the availability time for the transmitting system in the context of a message, any further transmission either dropping or overwriting it, and recording, if necessary, previous transmission times as separate observations?

Deleted text indicates availabilityTime is "attributed to the author of an act that includes or refers to the act." It is not clear why this attribute should require special conduction rules: are they different from the rules for other attributes?

The urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.

UsageNotes:

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, hence the open cardinality.

Examples:

Routine, elective, emergency.

Constraints around appropriate disclosure of information about this Act, regardless of mood.

An interval of integer numbers stating the minimal and maximal number of repetitions of the Act.

UsageNotes:

This attribute is a member of the workflow control suite of attributes.

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, unless the time exceeds the maximal Act.effectiveTime, at which point the repetitions will terminate

On an Act in Event mood, the repeatNumber is usually 1. If greater than 1, the Act represents a summary of several event occurrences occurring over the time interval described by effectiveTime. These occurrences are not otherwise distinguished.

To distinguish occurrences of acts within a sequence of repetitions, use distinct instances of Act related by ActRelationships using ActRelationship.sequenceNumber.

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.

An indication that the Act is interruptible by asynchronous events.

UsageNotes:

This attribute is part of the suite of workflow control attributes. Act events that are currently active can be interrupted in various ways. Interrupting events include (1) an explicit abort request against the Act, (2) expiration of the time allotted to this Act (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) a containing Act is 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.

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

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. The levelCode signifies the position within such a containment hierarchy and the applicable constraints.

UsageConstraint:

The constraints applicable to a particular level may include differing requirements for participations (e.g. 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.

UsageNotes:

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 (e.g. a multiple patient communication may be subdivided by a super-ordinate level of subject areas).

DesignComments:

Pending deprecation decision: this attribute does not seem to have been maintained.

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.

An indicator specifying whether the Act can be manipulated independently of other Acts or only through a super-ordinate composite Act that has this Act as a component.

UsageNotes:

By default the independentInd should be true. 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.

Examples:

An order may have a component that cannot be aborted independently of the other components.

An indication that the Act statement as a whole, with its subordinate components has been asserted to be uncertain in some way.

UsageNotes:

Uncertainty asserted using this attribute applies to the combined meaning of the Act statement established by all descriptive attributes (e.g., Act.code, Act.effectiveTime, Observation.value, SubstanceAdministration.doseQuantity, etc.), and the meanings of any components, not uncertainty regarding the value of Observation.value or any other particular attribute. These should be specified by applying the PPD or UVP data type extensions to the specific attribute. Uncertainty regarding a quantitative measurement value must still be represented by a PPD<PQ> in the value; differential diagnoses enumerated or weighed for probability must use the UVP<CD>. The use of the uncertaintyCode is appropriate only if the entirety of the Act and its dependent Acts is questioned.

There is no relationship between uncertaintyCode and negationInd. One may be very uncertain about an event, but that does not mean that one is certain about the negation of the event.

If this attribute is left unspecified or is omitted from a particular model, it SHALL be inferred that the attribute has the semantic of “stated with no assertion of uncertainty”.

No default value shall be declared for this attribute with a semantic that differs from “stated with no assertion of uncertainty”, though defaults may be asserted that convey this semantic in any desired code system.

Examples:

Patient might have had a cholecystectomy procedure in the past, but isn&apost sure: stated with uncertainty. Patient stipulates a cholecystectomy procedure in the past: stated with no assertion of uncertainty.

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.

UsageNotes:

Most reasons for acts can be clearly expressed by linking the new Act to another prior Act record 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 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), such a representation is preferable to the reasonCode.

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

The primary language in which this Act statement is specified, particularly the language of the Act.text.

If true, indicates that the data conveyed by the act, including outbound associations, represent "criteria" for some other act, not a "real" act. I.e. If an Act exists with a classCode of ACT and a moodCode of RQO and isCriterionInd is true, it does not represent an order for an act. Rather, it represents a criteria that will match on all orders.

Constraint: Act-relationships directed to any Act with "isCriterionInd=true" SHALL have "conductible=false" unless the source Act also has isCriterionInd=true.

The meaning and purpose of the ActRelationship instance.

UsageNotes:

The ActRelationship class is used to construct a variety of semantic structures, including panels, action plans, and representations of clinical reasoning or judgments. 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. The typeCode implies specific constraints on what kinds of Act objects can be related and in what way.

The types of act relationships fall under 6 categories:

1) Composition, with composite (source) and component (target). 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, may be defined by a specific implementation; others, such as blood pressure, seem to naturally consist of systolic and diastolic pressure.

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 source Act is the same, with varying degrees of detail uncovered in the de-composition relationship.

2) Sequel, which includes follow-up, fulfillment, instantiation, replacement, transformation, etc., for which source and target are Acts of essentially the same kind but with variances in mood, and where the target exists before the source.

3) Pre-condition, trigger, reason, contraindication, with the conditioned Act ("give aspirin") at the source and the condition or reason Act ("if fever above threshold") 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) Workflow. The composition and sequence relationships can be arranged in a sequence to form temporal and conditional (non-temporal) action plans (e.g., care plan, critical path, clinical trials protocols, drug treatment protocols). There is a group of attributes in both Act and ActRelationship called the "workflow Control suite of attributes" that allow the detailed specification of executable action plans. These attributes are

• Act.repeatNumber

• Act.interrubtibleInd

• ActRelationship.sequenceNumber

• ActRelationship.pauseQuantity

• ActRelationship.checkpointCode

• ActRelationship.splitCode

• ActRelationship.joinCode

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.pauseQuantity allow one to explicitly time an action plan. Act.repeatNumber allows specifying act to repeat (loop), while Act.interruptibleInd determines whether an Act can be interrupted by related Acts.

The ActRelationship type has-precondition allows plan steps to be conditional on the status or outcome of previous actions. The ActRelationship.checkpointCode specifies when pre-conditions of acts are tested during the flow of control. See the individual attribute entries in this model for more information.

The composition ActRelationship allows these constructs to be organized in nests and layers 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. All workflow plans are established through sequencing components (steps) in a composite act (block) consistent with structured programming principles.

6.) A host of functional relationships including support, cause, derivation, etc. generalized under the notion of "pertinence."

OpenIssue:

The property "isDocumentCharacteristic" is currently assigned to selected codes in ActRelationshipType, and is populated based on expected behaviour around negation. However, the values seem inappropriate when considering document behaviour. This property needs further analysis to determine whether a single property can suffice for both the negation and document characteristic use cases.

An indicator specifying that the ActRelationship.typeCode should be interpreted as if the roles of the source and target Acts were reversed.

DesignComments:

Define Default annotation. Clarify why an indicator would be preferable to swapping source and target.

Identifies the type(s) of ActRelationships that are not permitted to conduct across this ActRelationship.

UsageConstraint:

This attribute can only be used if the serializable model in which it appears has a contextConductionStyle property of "V (vocabulary-based)".

UsageNotes:

If one or more codes are specified, all other ActRelationships with typeCodes that match one of the specified codes or that are specializations of one of the specified codes will not conduct. All other ActRelationships with typeCodes having a "conductible" property of "true" or whose ancestor has a "conductible" property of "true" will conduct. Conducted ActRelationships behave such that the Act being navigated to is treated as though it had the same association(s) as the Act being navigated from. Refer to the Core Principles specification for more information.

Identifies the type(s) of Participations that are not permitted to conduct across this ActRelationship.

UsageConstraint:

This attribute can only be used if the serializable model in which it appears has a contextConductionStyle property of "V (vocabulary-based)".

UsageNotes:

If one or more codes are specified, all other Participations with typeCodes that match one of the specified codes or that are specializations of one of the specified codes will not conduct. All other Participations with typeCodes having a "conductible" property of "true" or whose ancestor has a "conductible" property of "true" will conduct. Conducted Participations behave such that the Act being navigated to is treated as though it had the same association(s) as the Act being navigated from. Refer to the Core Principles specification for more information.

Blocks conduction of act attribute values across this act relationship when true.

UsageNotes:

If true act attribute values are not conducted across this act relationship. If false the values of Act attributes having a "conductible" property of "true" will conduct. Conducted Act attribute values are treated as propagating and overriding.

This attribute is deprecated from further use for RIM versions later than version 2.30. This attribute and those that worked with it have been superseded by the attributes ActRelationship.blockedContextActRelationshipType and ActRelationship.blockedContextParticipationType, together with the "conductible" property on concepts in the ActRelationshipType and ParticipationType code systems.

The manner in which 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).

UsageNotes:

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 overrides and replaces the contextual assertion made by an Act relationship (e.g., identifying a sole author, independent of the containing item). It also indicates whether the association applies to only the immediate target act (non-propagating) or to derived acts as well (propagating).

This attribute works in concert with ActRelationship.contextConductionInd, which determines whether information will actually be conducted to a child Act, whatever the manner of conduction indicated by the contextControlCode.

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 the data 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.

Rationale:

Humans often 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.

DesignComments:

In the example, it seems the dispense event would carry the author from the composite order.

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 (1) is created containing a pharmacy order (2) as well as requests for several lab tests (3). The composite order has participations for patient (4) and author (5), and an act relationship to a diagnosis (6), all marked as "additive, propagating." The "component" association (7) between the composite order (1) and the pharmacy order (2) is marked as conductive (contextConductionInd is True). The pharmacy order has an author participation (8) marked as "additive, non-propagating" (AN), and a reason relationship (9) to a diagnosis, marked as "overriding, propagating" (OP). The pharmacy order (2) further has a relationship to a dispense event (10), marked as conductive, and an association (11) to a drug protocol marked as non-conductive (contextConductionInd is False). The meaning would be as follows:

The pharmacy order (2) is interpreted as having the patient (4) from the composite order (1), and having two authors (the one from the composite order, and the one on the pharmacy order itself). The diagnosis for the pharmacy order relationship (9) would be the only diagnosis specified on the pharmacy order (2), not the one specified on the composite order (6). The dispense event (10) would carry the patient from the composite order (4) and the diagnosis from the pharmacy order (9), but no author. The drug protocol (11) would not be associated with a patient, diagnosis or author.

This attribute is deprecated from further use for RIM versions later than version 2.30. This attribute and those that worked with it have been superseded by the attributes ActRelationship.blockedContextActRelationshipType and ActRelationship.blockedContextParticipationType, together with the "conductible" property on concepts in the ActRelationshipType and ParticipationType code systems.

An indicator determining whether associations in the parent act are to be conducted across the ActRelationship to the child act.

UsageNotes:

Refer to ActRelationship.contextControlCode for rationale and examples.

An integer specifying the relative sequential ordering of this relationship among other like-types relationships having the same source Act.

UsageNotes:

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.

An integer specifying the relative preference for considering this relationship before other like-typed relationships having the same source Act. Relationships with lower priorityNumber values are considered before and above those with higher values.

UsageNotes:

For multiple criteria, this attribute specifies which criteria are considered before others. For components with the same sequence number, it specifies which ones are considered before others. Among alternatives or options that are being chosen by humans, the priorityNumber specifies preference.

The ordering may be a total ordering, in which all priority numbers are unique, or a partial ordering, in which the same priority may be assigned to more than one relationship.

A quantity of time that elapses or should elapse between the source act and the target act.

UsageNotes:

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 any step with preconditions is executed, these conditions are tested: if the test is positive, the Act has clearance for execution. At that time, if the act has a pauseQuantity, the pauseQuantity timer is started: 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.

FormalConstraint:

Units SHALL be a type of time.

The point in the course of an Act when 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.

UsageNotes:

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 checkpointCode specifies when the precondition is to be checked; it 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.

The manner in which branches in an action plan are selected from among other branches.

UsageNotes:

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 "try once" 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 "wait" 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.

Examples:

Exclusive wait, inclusive wait, exclusive try once.

The manner in which concurrent Acts are resynchronized in a parallel branch construct.

UsageNotes:

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 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 prevent a kill-branch from being aborted.

Examples:

Detached, kill, exclusive wait.

An indicator that asserts that the meaning of the link is negated.

UsageNotes:

This attribute is used primarily for clarifying statements. 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.

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.

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.

The logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exlusive-or).

UsageNotes:

This attribute is used for criteria, typically in definition or goal mood.

Upon evaluation, the criterion is passed if all "and" criteria are 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 as necessary.

A character string name for the input parameter from which the source Act of this ActRelationship derives some of its attributes. The local variable name is bound in the scope of the Act.derivationExpr with its value being an Act selected based on the input parameter specified by this attribute.

An indication that the source Act is intended to be interpreted independently of the target Act.

UsageNotes:

The indicator cannot prevent an individual or application from separating the Acts, but indicates the author's desire and willingness to attest to the content of the source Act if separated from the target Act. Note that this attribute is orthogonal and unrelated to the RIM's context/inheritance mechanism. If the context of an Act is propagated to nested Acts, it is assumed that those nested Acts are not intended to be interpreted without the propagated context.

An indication that the target of the relationship will be a filtered subset of the total related set of targets.

UsageNotes:

This attribute is used when there is a need to limit the number of components to the first, the last, the next, the total, the average or some other filtered or calculated subset.

Examples:

First, maximum, summary.

An assertion that specific relationship between the source and target Acts is uncertain.

UsageNotes:

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.

Examples:

A particular exposure event is suspected but not known to have caused a particular symptom: stated with uncertainty.

An identifier for the attachment referenced by an ED attribute contained elsewhere in the interaction.

The data block that constitutes the attachment

A category of attentionLine parameter.

Examples:

Patient identifier, public health case type

A value associated with the key as provided in the AttentionLine.keyWordText attribute.

FormalConstraint:

The data type of the attribute SHALL be constrained to one of the following data types: BL, CV, II, URL, INT, REAL, TS, PQ, MO, IVL<TS>.

The control identifier of the batch when it was originally transmitted.

An identifier for the batch.

UsageNotes:

This attribute is used by the application processing the batch.

Comments related to the batch.

The count of individual transmissions contained within the batch, including nested batches.

The total number of messages in the batch.

UsageNotes:

In cases of nested batches, batchTotalNumber is specific to the immediate batch, whereas transmissionQuantity sums all nested totals.

DesignComments:

Confirm differentiation from transmissionQuantity

The type of content processing that the receiver of the batch is expected to undertake.

UsageNotes:

Default value is sequential.

Examples:

Sequential, unordered.

The role of an entity with respect to the transmission.

Examples:

Sender, receiver, respond-to party

The telecomm address that can be used to reach the entity in the identified role.

The functional capacity of the container.

The height of the container.

The outside diameter of the container.

The type of cap (closure) associated with the container that is the entity being described.

A material added to a container to facilitate and create a physical separation of specimen components of differing density.

Rationale:

The composition or nature of the separator material may have an effect on the analysis. Knowledge of the material aids interpretation of results.

Examples:

A gel material added to blood collection tubes that, following centrifugation, creates a physical barrier between the blood cells and the serum or plasma.

The distance from the point of reference to the separator material (barrier) within a container.

UsageNotes:

This distance may be provided by a laboratory automation system to an instrument and/or specimen processing/handling device to facilitate the insertion of a sampling probe into the specimen without touching the separator. See the Point of Reference definition or in NCCLS standard AUTO5, .

The distance from the Point of Reference to the outside bottom of the container.

UsageNotes:

Refer to Point of Reference in NCCLS standard AUTO5 .

A unique identifier for a report.

UsageNotes:

The setID remains constant across all revisions that derive from a common original.

A unique identifier for a version of a report.

UsageNotes:

The Modeling and Methodology Work Group will seek HL7 endorsement for a data type flavor of string that constrains the string to numerals only. This flavor, when available, can be used to constrain this attribute in such a way that users who prefer the previous "integer" version number can remain consistent with previous RIM releases of this attribute.

The human designated moniker for a device, assigned by the manufacturer.

Examples:

Perkin Elmer 400 Inductively Coupled Plasma Unit

The moniker, version and release of the software that operates the device as assigned by the software manufacturer or developer.

Examples:

Agilent Technologies Chemstation A.08.xx

The state of control of the device.

Rationale:

A device can either work autonomously or it can be controlled by another system. The control status of a device must be communicated between devices prior to remote commands being transmitted. If the device is not in "Remote" status, external commands will be ignored.

Examples:

Local, remote

The current functional status of an automated device.

UsageNotes:

The value of the attribute is determined by the device.

Examples:

Normal, warning, critical

The date and time the device was last calibrated.

Rationale:

Devices are required to be recalibrated at specific intervals to ensure they are performing within specifications. The accepted interval between calibrations varies with protocols. Thus for results to be valid, the precise date and time of last calibration is a critical component.

The parameters of the task submitted to the device upon the issuance of a command (or configuring the schedule of spontaneously executed tasks).

UsageConstraint:

Parameters are only specified here if they are not included in a separate HL7-defined structure.

UsageNotes:

The parameters are data values interpreted by the device. The parameters should be typed with an appropriate HL7 data type (e.g., codes for enumerated values, REAL and INT for numbers, TS for points in time, PQ for dimensioned quantities, etc.). However, apart from data typing, the parameter semantics is opaque to the HL7 standard.

Rationale:

Some parameters for tasks are uniquely defined by a specific model of equipment. Most critical arguments of a task (e.g., container to operate on, positioning, timing, etc.) are specified in an HL7 standardized static information structure, and the parameter list would not be used for those. The parameter list is used only for those parameters that cannot be standardized because they are uniquely defined for a specific model of equipment. NOTE: This means that the semantics and interpretation of a parameterValue can only be made with an understanding of the specifications or documentation for the specific device being addressed. This contextual information is not conveyed as part of the message.

DesignComments:

The concept of an HL7 defined or standardized structure should be defined here or in the glossary and referenced.

The spatial relation between an imaged object and the imaging film or detector.

This attribute was deprecated along with its parent class at the August 2009 Harmonization Meeting. It is deprecated for future use in HL7 Design Models effective with RIM Release 2.28. In the future, this quantity can be conveyed by using a Content relationship with a quantity attribute expressing the "calories".

The supplied biologic energy (calories) per day.

FormalConstraint:

This physical quantity SHOULD be convertible to 1 kcal/d (or 1 kJ/d).

This attribute was deprecated along with its parent class at the August 2009 Harmonization Meeting. It is deprecated for future use in HL7 Design Models effective with RIM Release 2.28. In the future, this quantity can be conveyed using a Content relationship to an Entity with a code of "carbohydrate" and a quantity attribute on the content relationship.

The supplied amount of carbohydrates per day.

UsageNotes:

For a diabetes diet one typically restricts the amount of metabolized carbohydrates to a certain amount per day (e.g., 240 g/d). This restriction can be communicated in the carbohydrateQuantity.

DesignComments:

Units (g) was in definition, but there does not seem to be a constraint on PQ.

A code depicting the completion status of a report.

Examples:

Incomplete, authenticated, legally authenticated.

The storage status of a report.

Examples:

Active, archived, purged

The time a document is released (i.e., copied or sent to a display device) from a document management system that maintains revision control over the document.

UsageNotes:

The intent of this attribute is to give the viewer of the document some notion as to how long the document has been out of the safe context of its document management system.

FormalConstraint:

Once valued, this attribute cannot be changed.

A citation for a cataloged document that permits its identification, location and/or retrieval from common collections.

An employer-defined categorization of work.

UsageNotes:

This value is used primarily for payroll/remuneration purposes and is not necessarily indicative of an employee's specific work assignments, responsibilities and privileges.

Examples:

Accountant, programmer analyst, patient care associate, staff nurse

The title associated with the job held.

UsageNotes:

This is a local name for the employee's occupation that does not necessarily correspond to any scheme for categorizing occupation. Trading partners that need a coded standard should be using the Employee "occupation" attribute.

Examples:

Vice President; Senior Technical Analyst

The frequency or periodicity of employment.

Examples:

Examples: Full-time; part-time

A value that qualifies the classification of 'kind-of-work' based upon a recognized industry or jurisdictional standard.

A value representing the method used by an employer to compute an employee's salary or wages.

Examples:

Hourly, annual, commission

The amount paid in salary or wages to an employee.

UsageNotes:

This amount should be determined according to the computation method specified in salaryTypeCode, (e.g., if the salaryTypeCode is "hourly" the salaryQuantity specifies the hourly wage).

The hazards associated with the work performed by an employee for an employer.

Examples:

Asbestos; infectious agents

Protective equipment needed for the job performed by an employee for an employer.

Examples:

Safety glasses, hardhat

The major class of Entities to which an Entity-instance belongs.

Rationale:

Due to the extremely large number of potential values for a code set representing all physical things in the universe, the class code is a high level classifier to place the instance of Entity in appropriate context, which then constrains the eligible value domains for the Entity.code attribute.

Examples:

Person, Animal, Chemical Substance, Group, Organization

A code specifying whether the Entity object represents a universal (KIND) vs. a particular (INSTANCE).

Rationale:

An Entity may at times represent information concerning a specific instance (the most common) or a general type of Entity.

Examples:

One human being (instance); or citizens of Indianapolis (kind)

A unique identifier for the Entity.

UsageNotes:

An instance identifier is a unique identifier, not a classifier. For Materials, serial numbers assigned by specific manufacturers, catalog numbers of specific distributors, or inventory numbers issued by owners, may better be represented by the Role.id, which allows a more clear expression of the fact that such a code is assigned by a specific party associated with that material.

Rationale:

Successful communication only requires that an entity have a single identifier assigned to it. However, as different systems maintain different databases, there may be different instance identifiers assigned by different systems.

The specific kind of Entity to which an Entity-instance belongs.

UsageNotes:

For each Entity, the value for this attribute is drawn from one of several coding systems as suggested by the Entity.classCode, such as living subject (animal and plant taxonomies), chemical substance (e.g., IUPAC code), organization (e.g., CMS provider number), etc. It is possible that Entity.code may be so fine grained that it represents a single instance. An example is the CDC vaccine manufacturer code, modeled as a concept vocabulary, when in fact each concept refers to a single instance. The boundary cases distinguishing codes and identifiers are controversial: this specification allows a certain amount of flexibility.

Examples:

A medical building, a Doberman Pinscher, a blood collection tube, a tissue biopsy.

A physical quantity specifying the amount of the physical thing represented by the Entity object, either as a count of the members of a group, or as some other physical quantity. Describes the amount of the Entity, irrespective of potential Participations of the Entity as a whole or in parts. In order to explicitly identify a group of like entities, a static model design should constrain the PQ data type of this attribute to INT, thus providing a count of the entities in the group.

UsageConstraint:

The unit of quantity should make sense for the Entity.code and Material.formCode attributes where specified. For example, "10cm of tubing" is fine, while "10cm of cow" is not.

UsageConstraint:

Entity quantity should only be used for specifically identified Entities (such as the contents of beer keg #XP27-35) or in cases where the quantity is an intrinsic part of the specification of the entity (such as a specific portion of phosgene).

UsageNotes:

Just as the name of a Person may change, or even its gender, the quantity of any entity can be subject to change too. With material and bulk living subjects it is possible for the quantity to gradually diminish, or, for such an Entity to be portioned out into smaller amounts of the same kind of Entity (e.g. aliquoting in a laboratory or distributing a production lot in smaller amounts.) In the case of this portioning out of an amount into smaller amounts, the initial Entity instance of the large amount may cease to exist, yet the portions may still be traceable to the initial Entity of the large amount (as in patient for a specimen aliquot or lot for a vaccine).

Specifying Entity.quantity is often not necessary as one can specify quantity in relation to other Entities (Role.quantity), participations (Participation.quantity), and and in Acts which consume or produce such Entity (e.g. SubstanceAdministration.doseQuantity, Supply.quantity).

Examples:

1 human being, 2 cats, 500 cows, 20 mL of blood, 1 kg of yeast, 154 mmol of sodium chloride.

FormalConstraint:

Quantity must be an extensive amount, that is, a count number or an additive quantity, such as mass (1 kg), volume (1 L), amount of substance (1 mol), or another quantity of a kind suitable to describe an amount (catalytic activity).

OpenIssue:

Specifying quantity in terms of an arbitrary, procedure-defined kind of quantity (e.g., tuberculin-units) may not allow to reliably interpret such quantity statement.

A non-unique textual identifier or moniker for the Entity.

Rationale:

Most entities have a commonly used name that can be used to differentiate them from other Entities, but that does not provide a necessarily unique identifier.

Examples:

Proper names, nicknames, legal names of persons, places or things.

A textual or multimedia depiction of the Entity.

UsageNotes:

The content of the description is not considered part of the functional information communicated between systems. Descriptions are meant to be shown to interested human individuals. All information relevant for automated functions must be communicated using the proper attributes and associated objects.

Rationale:

Names and descriptions of entities are typically more meaningful to human viewers than numeric, mnemonic or abbreviated code values. The description allows for additional context about the entity to be conveyed to human viewers without affecting the functional components of the message.

A value representing whether the information associated with an Entity is currently active or inactive for the purpose of participation in acts.

UsageNotes:

This attribute was defined in the original RIM as repeating, owing to the presence of nested states in the state machines. In actual practice, however, there is never a need to communicate more than a single status value. Therefore, committees are advised to constrain this attribute to a maximum cardinality of 1 in all message designs.

An interval of time specifying the period in which the Entity physically existed.

UsageNotes:

Physical entities have specified periods in which they exist. Equipment is manufactured, placed in service, retired and salvaged. The relevance of this attribute is in planning, availability and retrospective analysis. This period may represent past, present or future time periods.

Examples:

ManufactureDate / DisposalDate

A telecommunication address for the Entity.

The type of hazard or threat associated with the Entity.

Examples:

Petrochemical or organic chemicals are highly flammable agents that pose an increased risk of fire under certain conditions. Entities with either natural or introduced radioactive character pose a risk to those handling them. Entities comprising specimens from diseased individuals pose an increased risk of infection to those handling them. Persons or animals of irascible temperament may prove to be a risk to healthcare personnel.

A value representing special handling requirements for the Entity.

UsageNotes:

This attribute is used to describe required special handling.

Examples:

Keep at room temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright.