RIM core edits for Harmonization April 08
Act
A record of something that is being done, has been done, can be done, or is intended or requested to be done.
Examples: The kinds of acts that are common in health care include (1) clinical observations, (2) assessments of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) acts of assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others.
Rationale: Acts are the pivot of the RIM: domain information and process records are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.
Ownership of and responsibility for the Act-object are not the same as ownership of and responsibility for 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 distinct Acts, each 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 to say that "the other requirements for a medical record, e.g., 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 and 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 indicative statements, representing other grammatical moods, including requests and orders (imperative) and criteria and definitions (subjunctive).
An activity in the real world may progress from definition, through planning and ordering to execution: these stages are represented as the moods of the Act. Even though one might think of a single activity as progressing through these stages, the “attributable statement” model of Act entails that this progression be reflected by multiple Act-instances, each having one and only one mood, and that this mood not change during 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 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 recipients of the information to compare actions with their earlier specifications. Act-instances that describe this progression of the same real world activity are linked through the ActRelationships (of the relationship category "sequel").
Acts as statements are the only representations of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through the 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. A factual statement may be made about recent (but past) activities, authored (and signed) by the performer of such activities, e.g. a surgical procedure report, clinic note, etc. Similarly, a status update may be made about an activity that is presently in progress, authored by the performer (or a close observer), and later superseded by a full procedure report. Both status update and procedure report are acts, distinguished by mood and state (see Act.statusCode) and completeness of information: neither has any epistemological priority over the other except as judged by the recipient of the information.
Usage Notes: Acts connect to Entities in their Roles through Participations, and they connect to other Acts through ActRelationships. Participations indicate the performers, authors, and other responsible parties as well as subjects and beneficiaries (including tools and material used in the performance of the act, which are also subjects). The moodCode distinguishes among Acts that are meant as factual records, records of intended or ordered services, and other modalities in which acts can be recorded.
One of the Participations that all acts have (at least implicitly) is the primary author, who owns the act statement. The author is responsible for the content of the statement, as the content is attributable to the author. The author is also responsible for modifications to the status of the Act-instance, if appropriate.
Act . classCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: ActClass Strength: CNE
Definition:
A code specifying the major class of Acts to which an Act-instance belongs.
Constraints:Every Act-instance must have a classCode. If the act class is not further specified, the most general Act.classCode (ACT) is used.
Usage Notes: For Act-instances that have an Act.code, the Act.code must be a specialization of the Act.classCode. The Act.code, however, cannot alter the meaning of the Act.classCode.
Issue:
Act . moodCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: ActMood Strength: CNE
Definition:
A code indicating the intended use of the Act statement: as a report of fact, a command, a possibility, a goal, etc.
Constraints:An Act-instance must have one and only one moodCode value.
The moodCode of a single Act-instance may not change.
Rationale:In order to support and distinguish the several uses to which statements may be put, Acts require the notion of "mood," largely as understood in natural language grammar. Rather than rely on the moods peculiar to a specific natural language, moodCode uses a richer set of moods informed by modal logic.
Usage Notes: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 must be assigned to a valid code, and the mood assignment cannot 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).
Issue:
"Definition: 'whether' suggests a distinction between 'indicative' and 'other'; rewritten to suggest variety of possibility
Rationale: "judged as appropriate or defective" removed: it's the use, and only incidentally judging correctness
Moods fall into two groups: Completion Track and Predicate. Completion track moods (definition, intent, request, and event) are or can be assigned to Act-instances in sequence, describing real-world events. Predicate moods (criterion and goal) are never realized; they are used to evaluate completion track acts for decision-making.
[where does query fall?]"
Act . id
Datatype: SET<II> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A unique identifier for the Act.
Usage Notes: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.
Issue:
Act . code
Datatype: CD Mandatory: 0 Cardinaltiy: 0..1 Domain: ActCode Strength: CWE
Definition:
A code specifying the particular kind of Act that the Act-instance represents within its class.
Examples:Physical examination, serum potassium, inpatient encounter, charge financial transaction, etc.
Constraints:Act.code, if used, must be a specialization of the Act.classCode.
Usage Notes: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.
The kind of Act 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.
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.
Design Comments: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.
Issue:
when is it appropriate to use code vs. definition or other technique
Act . negationInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An indicator specifying that the 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, e.g., "if patient has NO chest pain for 3 days ...," or "if systolic blood pressure is not within 90-100 mm Hg ..."
Usage Notes: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.
Issue:
"most act relationships are not negated": we need specificity here. I propose a solution but don't know if it's correct"
Act . derivationExpr
Datatype: ST Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
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.
Usage Notes: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.
Constraints:The derivation expression is represented as a character string.
Open Issues: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.
Issue:
note refers to effort with a target of 2003
Act . title
Datatype: ED Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
A word or phrase by which a specific Act may be known among people.
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.
Constraint: 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".
Usage Notes: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.)
Ballot Comment: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.
Issue:
Act . text
Datatype: ED Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
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.
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.
Usage Notes: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 must 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 MUST include all information which is in such attributes or associations, with the exception of those identified above.
Act.text SHOULD NOT be used for the sharing of computable information. Computable information must 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 should 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.
Issue:
Examples: are these the only moods where text is used?
Act . statusCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ActStatus Strength: CNE
Definition:
A code specifying the state of the Act.
Usage Notes: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.
Rationale: 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.
Issue:
Act . effectiveTime
Datatype: GTS Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
The clinically or operationally relevant time of an act, exclusive of administrative activity.
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.
Usage Notes: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.
Issue:
shall Gello be removed?
Act . activityTime
Datatype: GTS Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
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.
Usage Notes: 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.
Issue:
inert comment not clear: inert with respect to what?
Act . availabilityTime
Datatype: TS Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
The point in time at which information about Act-instance (regardless of mood) first became available to a system reproducing this Act.
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.
Usage Notes:The availabilityTime is metadata describing the record, not the Act. It 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.
Issue:
"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 availablity 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." "Includes," perhaps; "refers to" opens up cardinality of this unary attribute, without tools to indicate which potential referrer is the one this attribute has in mind. If this is the intent, perhaps an attribute of actRelationships would be better suited."
Act . priorityCode
Datatype: SET<CE> Mandatory: 0 Cardinaltiy: 0..* Domain: ActPriority Strength: CWE
Definition:
A code or set of codes specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.
Examples: Routine, elective, emergency.
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, hence the open cardinality.
Issue:
Act . confidentialityCode
Datatype: SET<CE> Mandatory: 0 Cardinaltiy: 0..* Domain: Confidentiality Strength: CWE
Definition:
A code that indicates the appropriate disclosure of information about this Act, regardless of mood.
Usage Notes: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 constructed from the 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.
Managing the display of confidential information is a task for clinical applications, but the data structure must support the ability to indicate the existence of such information to appropriate persons. To mitigate some of the inference-risk, aggregations of data should assume the confidentiality level of the most confidential action in the aggregation.
Issue:
"Re "aggregations of data should assume the confidentiality level of the most confidential action in the aggregation.": where do we draw the boundary? The observation? The message? The EHR?"
Act . repeatNumber
Datatype: IVL<INT> Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
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.
Usage Notes: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.
Issue:
Act . interruptibleInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An indicator specifying whether Act is interruptible by asynchronous events.
Usage Notes: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.
Issue:
Act . levelCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: ActContextLevel Strength: CWE
Definition:
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.
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 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.
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).
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 (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.
Issue:
not edited. If kept, much of this text will be an 'open issue.' Clarification required on how one code indicates both level and contextual information for component acts.
Act . independentInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
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.
Example:An order may have a component that cannot be aborted independently of the other components.
Usage Notes: 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.
Issue:
Act . uncertaintyCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: ActUncertainty Strength: CNE
Definition:
A code indicating whether the 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).
Usage Notes: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.
Issue:
Act . reasonCode
Datatype: SET<CE> Mandatory: 0 Cardinaltiy: 0..* Domain: ActReason Strength: CWE
Definition:
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.
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."
Usage Notes:
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.
Issue:
Is it realistic to expect a system to generate an act to refer to a law? The instruction might indicate a preference for a relationship without dictating that it be used
Act . languageCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: HumanLanguage Strength: CWE
Definition:
The primary language in which this Act statement is specified, particularly the language of the Act.text.
Issue:
ActRelationship
A directed association between a source Act and a target Act.
Examples: 1) An electrolyte observation panel may have sodium, potassium, pH, and bicarbonate observations as components. The composite electrolyte panel would then have 4 outbound ActRelationships of type "has component," which would be inbound to their target sodium, potassium, pH, and bicarbonate observations.
2) The electrolyte panel event has been performed in fulfillment of an observation order. The electrolyte panel event has an outbound ActRelationship of type "fulfills" with the order as target.
3) A Procedure "cholecystectomy" may be performed for the reason of an Observation of "cholelithiasis." The procedure has an outbound ActRelationship of type "has reason," which would be inbound to the cholelithiasis observation.
Usage Notes:The ActRelationship class is used to construct systems of acts to represent complex observations, action plans, and to represent clinical reasoning or judgments about action relationships. Prior actions can be linked as the reasons for more recent actions. Supporting evidence can be linked with current clinical hypotheses. Problem lists and other networks of related judgments about clinical events are represented by the ActRelationship link.
Every ActRelationship instance is like an arrow with a point (headed to the target) and a butt (coming from the source). The functions that source and target Acts play in that association are defined for each ActRelationship type differently. For instance, in a composition relationship, the source is the composite and the targets are the components. In a reason-relationship the source is any Act and the target is the reason or indication for the source-Act.
The relationships associated with an Act are considered properties of the source act object. This means that the author of an Act-instance is also considered the author of all of the act relationships that have this Act as their source, (though not necessarily of the target Acts of those relationships). There are no exceptions to this rule.
The meaning and purpose of an ActRelationship is specified in the ActRelationship.typeCode attribute: see this attribute for more information about of the different kinds of ActRelationships.
ActRelationship . typeCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: ActRelationshipType Strength: CNE
Definition:
A code specifying the meaning and purpose of every ActRelationship instance. Each of its values implies specific constraints to what kinds of Act objects can be related and in what way.
Usage Notes: 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 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.”
Issue:
"Sequel: Does target always precede source in this scenario?
Precondition: confirm directionality"
ActRelationship . inversionInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An indicator specifying that the ActRelationship.typeCode should be interpreted as if the roles of the source and target Acts were reversed.
Issue:
ActRelationship . contextControlCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ContextControl Strength: CNE
Definition:
A code that specifies how this ActRelationship contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see ActRelationship.contextConductionInd).
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.
Usage Notes: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.
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.
Issue:
"The attribute requires clarification in concert with Indicator. It seems Indicator is used to determine whether conduction happens, Code to define the manner of conduction, hence the complementary usage: no AR in the example uses both. If true, this distinction should be made explicit.
The definition does not state the direction of the propagation, which is presumably from source to target. The indicator is also present on participations: congruence should be addressed. In the example, it seems the dispense event would carry the author from the composite order."
ActRelationship . contextConductionInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An indicator determining whether associations in the parent act are to be conducted across the ActRelationship to the child act.
Usage Notes:Refer to ActRelationship.contextControlCode for rationale and examples.
Issue:
"the explanation of precedence seems to depend on serialization: this seems out of line with the design goal of separating semantics from technical implementation. Is conduction not from source to target?
Is there a constraint between code and indicator--if indicator is false, code should be null; if true, code cannot be null? Which is to say, is this indicator really necessary?"
ActRelationship . sequenceNumber
Datatype: INT Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An integer specifying the relative sequential ordering of this relationship among other like-types relationships having the same source Act.
Usage Notes: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.
Issue:
ActRelationship . priorityNumber
Datatype: REAL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
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.
Usage Notes: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.
Issue:
ActRelationship . pauseQuantity
Datatype: PQ Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
A quantity of time that should elapse between when an Act is ready for execution and the actual beginning of the execution.
Usage Notes: 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.
Constraint:Units must be comparable to seconds.
Issue:
Constraint:Units must be comparable to seconds.
Comparable? Meaning, units of time?"
ActRelationship . checkpointCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ActRelationshipCheckpoint Strength: CNE
Definition:
A code specifying when, in the course of an Act, a precondition for the Act is evaluated: e.g., before the Act starts for the first time, before every repetition, after each repetition but not before the first, or throughout the entire time of the Act.
Usage Notes: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.
Issue:
ActRelationship . splitCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ActRelationshipSplit Strength: CNE
Definition:
A code specifying how branches in an action plan are selected from among other branches.
Usage Notes: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.
Issue:
ActRelationship . joinCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ActRelationshipJoin Strength: CNE
Definition:
A code specifying how concurrent Acts are resynchronized in a parallel branch construct.
Usage Notes: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.
Issue:
ActRelationship . negationInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An indicator that asserts that the meaning of the link is negated.
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.
Usage Notes: 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.
Issue:
ActRelationship . conjunctionCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: RelationshipConjunction Strength: CNE
Definition:
A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exlusive-or).
Usage Notes: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.
Issue:
ActRelationship . localVariableName
Datatype: ST Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
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.
Issue:
ActRelationship . seperatableInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
Indicates whether or not the source Act is intended to be interpreted independently of the target Act.
Usage Notes: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 the default for this attribute will typically be "True." Also 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.
Issue:
ActRelationship . subsetCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ActRelationshipSubset Strength: CNE
Definition:
An indication that the target of the relationship will be a filtered subset of the total related set of targets.
Usage Notes: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.
Issue:
It seems that such a specification would necessarily be limited to subjunctive moods. If true, this point would help clarify usage.
ActRelationship . uncertaintyCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: ActUncertainty Strength: CNE
Definition:
A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.
Examples:A particular exposure event is suspected but not known to have caused a particular symptom.
Usage Notes: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.
Issue:
Entity
A physical thing, group of physical things or an organization capable of participating in Acts while in a role.
Usage Notes: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, materials, and places and their specializations. Entity stipulates the thing itself, not the the Role it plays: the Role of Patient, e.g., is played by the Person Entity.
Entity . classCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: EntityClass Strength: CNE
Definition:
A code specifying the major class of Entities to which an Entity-instance belongs.
Examples:Person, Animal, Chemical Substance, Group, Organization
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.
Issue:
Entity . determinerCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: EntityDeterminer Strength: CNE
Definition:
The degree of specificity of an Entity.
Examples:1 human being (an instance), 3 syringes (quantified kind) or the population of Indianapolis (kind of group)
Rationale:An Entity may at times represent information concerning a specific instance (the most common), a quantifiable group with common characteristics, or a general type of Entity.
Issue:
"The example for Kind ("population of Indianapolis") seems like a specific population, not a kind.
This attribute could use a usage note explaining the use of the examples."
Entity . id
Datatype: SET<II> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A unique identifier for the Entity.
Usage Notes: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.
Issue:
Entity . code
Datatype: CD Mandatory: 0 Cardinaltiy: 0..1 Domain: EntityCode Strength: CWE
Definition:
A code specifying the specific kind of Entity to which an Entity-instance belongs.
Examples:A medical building, a Doberman Pinscher, a blood collection tube, a tissue biopsy.
Usage Notes: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.
Issue:
Should the CDC vaccine manufacturer code not be an ID rather than a code?
Entity . quantity
Datatype: SET<PQ> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
The number or quantity of the Entity, with appropriate units.
Examples:[Insert basic example.] With undetermined kinds, the quantity is a reference quantity for the specification of the proportion of ingredients or components (e.g., in a composite Entity through a has-part, has-ingredient, or has-content Role). For example, a kind of group with 60% females is Person (quantity = 100) has-part Person (quantity = 60; sex = female). Amoxicillin 500 mg. per tablet is Material (Tablet, quantity = 1) has-ingredient Material (Amoxicillin, quantity = 500 mg). Glucose 5% (D5W) is Material (D5W, quantity = 1 kg) has-ingredient Material (Glucose, quantity = 50 g).
Usage Notes:When the Entity instance is a portion of a substance, the quantity specifies the amount of that substance comprised by that portion. For an undetermined substance (kind) the quantity serves two purposes at the same time: (a) it provides a means of relations between quantities specific for that substance, and (b) it is a reference quantity for the specification of ingredients or components. In all cases, the quantity indicates an extensive quantity in a dimension indicated by its units (e.g., number, length, volume, mass, surface area, energy, etc.). Note that most relative or fractional quantities are not extensive quantities. In particular, mass fraction, substance concentration, mass ratios, percentages, etc. are not extensive quantities and are prohibited values for this attribute.
Constraints: Quantity MUST be congruent with the value of Entity.determinerCode. For Entities with determinerCode = INSTANCE, the quantity is 1. For an Entity with determinerCode = QUANTIFIED_KIND, the quantity is the number of individual members in the group; for an Entity with a determinerCode = KIND, the value is undetermined, unless used in a composite Entity for the purposes of defining a ratio.
Issue:
"Examples should start with the simple and then explain the indeterminate cases after the basic operation is clear.
Is it true that proportions are to be modeled with arbitrary absolute magnitudes? The second example paragraph asserts that multiple specifications are to be considered equal, but does not state why, if they are equal, more than one is necessary, nor what a recipient should do if in receipt of two that are not equal. The two purposes of quantity in an undetermined entity are not clearly distinguished Constraint seems to miss the scenario of measurement, e.g. of a laboratory sample"
Entity . name
Datatype: BAG<EN> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A non-unique textual identifier or moniker for the Entity.
Examples: Proper names, nicknames, legal names of persons, places or things.
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.
Issue:
Entity . desc
Datatype: ED Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
A textual or multimedia depiction of the Entity.
Usage Notes: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.
Issue:
Entity . statusCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: EntityStatus Strength: CNE
Definition:
A value representing whether the information associated with an Entity is currently active or inactive for the purpose of participation in acts.
Design Comments:
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.
Issue:
Entity . existenceTime
Datatype: IVL<TS> Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An interval of time specifying the period in which the Entity physically existed.
Examples:ManufactureDate / DisposalDate
Usage Notes: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.
Issue:
Entity . telecom
Datatype: BAG<TEL> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A telecommunication address for the Entity.
Issue:
Entity . riskCode
Datatype: SET<CE> Mandatory: 0 Cardinaltiy: 0..* Domain: EntityRisk Strength: CWE
Definition:
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.
Issue:
Entity . handlingCode
Datatype: SET<CE> Mandatory: 0 Cardinaltiy: 0..* Domain: EntityHandling Strength: CWE
Definition:
A value representing special handling requirements for the Entity.
Examples:Keep at room temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright.
Usage Notes:This attribute is used to describe required special handling.
Issue:
Participation
An association between an Act and a Role.p>
Examples: 1) Performers of acts (surgeons, observers, practitioners)
2) Subjects of acts (patients, devices, materials)
3) Locations
4)Ancillaries (Author, co-signer, witness, informant)
5) Addressee, information recipient
Usage Notes: Each Entity involved in an Act is linked to the Act by one Participation-instance. The kind of involvement in the Act is specified by the Participation.typeCode.
The Entity’s Role interposes between the Entity and the Participation. While Roles represent the competence of an Entity, Participations represent performance, so a Participation is scoped by its specific Act, and only incidentally by its Entity. Conversely, Roles describe an innate quality of an Entity (i.e., how it may principally participate in acts), irrespective of any individual Act.
The professional credentials of a person (Role) may be quite different from what a person actually does (Participation). A common example is interns and residents performing anesthesia or surgeries under (more or less) supervision of attending specialists: the role of intern does not specify the nature of the participation.
An Act can have multiple participations of the same type: this indicates collaborative activities or group involvement. The notion of multiple performing Participations may also be represented as sub-activities (Act components): the presence of multiple actors may be represented as an act composed of sub-acts where each act has only one performing actor, or as a single act with many participations.
For example, a record of a surgical service may include the actors of type (a) consenter, (b) primary surgeon, and (c) anesthetist, and these three Roles might have separate Participation relationships to the surgery. Alternatively, these three actors really perform different tasks, which can be represented as three related acts: (a) the consent, (b) the surgery proper, and (c) the anesthesia act in parallel to the surgery. If we used the sub-acts, the consenter, surgeon and anesthetist could simply be of actor type "performer." Thus the more sub-acts we use, the fewer different actor types we need to distinguish; conversely, the fewer sub-acts we use, the more distinct actor types (and Participation instances) we need.
As a rule of thumb, sub-tasks should be preferred to multiple actors when the sub-tasks require special scheduling, or billing, or if overall responsibilities for the sub-tasks are different. In many cases, however, this detail is not urgent enough to support its collection: human resources are scheduled in teams (rather than as individuals), billing tends to lump sub-tasks together, and overall responsibility often rests with an attending physician, chief nurse, or head of department. While the ActRelationship class supports detailed decomposition, the Participation class supports multi-actor "lumping" of sub-activities into a primary act.
Participation . typeCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: ParticipationType Strength: CNE
Definition:
A code specifying the kind of Participation or involvement the Entity playing the Role associated with the Participation has with regard to the associated Act.
Issue:
Participation . functionCode
Datatype: CD Mandatory: 0 Cardinaltiy: 0..1 Domain: ParticipationFunction Strength: CWE
Definition:
An optional code specifying additional detail about the function that the Participation has in the Act, if such detail is not implied by the Participation.typeCode.
Examples:First surgeon, second surgeon (or first assistant surgeon, the one facing the primary surgeon), second assistant (often standing next to the primary surgeon), potentially a third assistant, scrub nurse, circulating nurse, nurse assistant, anesthetist, attending anesthetist, anesthesia nurse, technician who positions the patient, postoperative watch nurse, assistants, midwives, students, etc.
Constraints:This code, if specified, MUST NOT conflict with the Participation.typeCode.
No HL7 standard specification may be written to depend on the functionCode. When such a constraint is deemed necessary, it is to be defined in the Participation.typeCode.
Usage Notes:This code can accommodate a variety of functions greater than that which can be managed in the tightly controlled typeCode. The numbers and kinds of functions applicable depend on the specific kind of act, e.g., each operation may require a different number of assistant surgeons or nurses.
Since Participation functions refer to what people do in an Act, they are effectively sub-activities that may all occur in parallel. If more detail needs to be captured about these activities than who does them, component acts should be used instead.
Issue:
Participation . contextControlCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ContextControl Strength: CNE
Definition:
A code that specifies how this Participation contributes to the context of the current Act, and whether it may be propagated to descendent Acts whose associations allow such propagation (see ActRelationship.contextConductionInd).
Usage Notes:Refer to ActRelationship.contextControlCode for rationale, discussion and examples.
Issue:
Participation . sequenceNumber
Datatype: INT Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An integer specifying the relative order of the Participation in relation to other Participations of the same Act.
Example:The sequencing of covered party participations to establish a coordination of benefits sequence in insurance claims.
Issue:
Participation . negationInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
Indicates whether the specified participation did not, does not, or should not occur, depending on mood.
Rationale:This attribute has two primary uses: (1) To indicate that a particular Role did not or should not participate in an Act, and (2) To remove a participant from the context being propagated between Acts.
Usage Notes:A participation with a negationInd set to true takes precedence over one with a negationInd of false, in the event of a conflict.
Examples:Dr. Smith did not participate; Patient Jones did not sign the consent.
Issue:
does this mean instead of (i.e. equivalent to) using a negative context conduction indicator on the original graph, or as an emendation in a revision of the graph?
Participation . noteText
Datatype: ED Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
A textual or multimedia depiction of commentary related to the participation.
Usage Notes:This note is attributed to the immediate participant only.
Issue:
Participation . time
Datatype: IVL<TS> Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
The time during which the participant is involved in the act through this Participation.
Rationale:Participation time is needed when the participant's involvement in the act spans only part of the Act's time. This means that Participation.time indicates the time at which certain common sub-activities occur that may not be worth recording in acts, but which are implicitly modeled by the participation type.
Examples:1) The time data was entered into the originating system is the Participation.time of the "data entry" participation.
2) The end of the Participation.time of an author is the time associated with the signature.
3) The Participation.time of a co-signing participation is the time of that co-signature.
Issue:
the definition made some point of reiterating that it's an interval: can the span not be zero, as, say, for the coauthor example?
Participation . modeCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: ParticipationMode Strength: CWE
Definition:
A code specifying the modality by which the Entity playing the Role is participating in the Act.
Examples:Physically present, over the telephone, written communication.
Usage Notes:For author (originator) participants, this is used to specify whether the information represented by the act was initially provided verbally, (hand-)written, or electronically.
Issue:
exclusively for authoring, or are there other scenarios? Examples needed, or a constraint.
Participation . awarenessCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: TargetAwareness Strength: CWE
Definition:
A code specifying the extent to which the Entity playing the participating Role is aware of the associated Act.
Examples:For diagnostic observations, is the patient, family member or other participant aware of the patient's terminal illness?
Usage Notes:Because this attribute typically indicates that awareness is in question, it normally describes a target Participation (e.g., that of a patient). If the awareness, denial, unconsciousness, etc. is the subject of medical considerations (e.g., part of the problem list), explicit observations should be employed: this simple attribute in the Participation cannot represent information sufficient to support medical decision-making.
Issue:
example requires more context: why is family being modeled?
Participation . signatureCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: ParticipationSignature Strength: CNE
Definition:
A code specifying whether the participant has attested participation through a signature or whether such a signature is needed.
Examples:A surgical Procedure act object (representing a procedure report) requires a signature of the performing and responsible surgeon, and possibly other participants. (See also Participation.signatureText.)
Issue:
There are only three values: it seems that if the attribute is present in the graph it must be either intended, required, or signed. There is no provision for 'not required.' Because it is an attribute of participation instances, it may only be elicited in one of these states--a signature that is not required would never be modeled, so three values suffice. It may be useful to make that point explicitly.
Participation . signatureText
Datatype: ED Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
A textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act as specified in the Participation.typeCode.
Examples:1) An "author" participant assumes accountability for the truth of the Act statement to the best of his knowledge.
2) An information recipient only attests to the fact that he or she has received the information.
Discussion:The signature can be represented either inline or by reference according to the ED data type. Typical cases are
1) Paper-based signatures: the ED data type may refer to a document or other resource that can be retrieved through an electronic interface to a hardcopy archive.
2) Electronic signature: this attribute can represent virtually any electronic signature scheme.
3) Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
Issue:
Participation . performInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
Indicates that the resource for this Participation must be reserved before use (i.e., it is controlled by a schedule).
Usage Notes:This attribute serves a very specific need in the context of resource scheduling: it is not needed in the majority of participation expressions. In most circumstances, it applies to the participation of a particular location or piece of equipment whose use is controlled by a scheduler.
Issue:
Participation . substitutionConditionCode
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: SubstitutionCondition Strength: CWE
Definition:
The conditions under which a participating item may be replaced with a different one.
Issue:
Participation . subsetCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: ParticipationSubset Strength: CNE
Definition:
An indication that the participation is a filtered subset of the total participations of the same type associated with the Act.
Usage Notes:Used when there is a need to limit the participations to the first, the last, the next or some other filtered subset.
Issue:
This would seem to be appropriate to DEF or ORD moods, but it's not clear. An example would help, as would some usage guidance and a defined vocabulary domain.
Role
A competency of the Entity that plays the Role as identified, defined, guaranteed, or acknowledged by the Entity that scopes the Role.
Usage Notes: An Entity participates in an Act in the guise of a particular Role. Note that a particular entity in a particular role can participate in an act in different ways. Thus, a Person in the role of a practitioner can participate in a patient encounter as a rounding physician or as an attending physician. The Role defines the competency of the Entity irrespective of any Act, unlike Participations, which are limited to the scope of an Act.
Each role is "played" by one Entity, called the "player" and is "scoped" by another Entity, called the "scoper". Thus the Role of "patient" may be played by a person and scoped by the provider organization from which the patient will receive services. Similarly, the employer scopes the "employee" role.
The identifier of the Role identifies the Entity playing the role in that role. This identifier is assigned by the scoper to the player. The scoper need not have issued the identifier, but may have re-used an existing identifier.
Most attributes of Role are attributes of the playing entity while in the particular role.
Role . classCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: RoleClass Strength: CNE
Definition:
A code specifying the major class of Role to which a Role-instance belongs.
Issue:
Role . id
Datatype: SET<II> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A unique identifier for the player Entity in this Role.
Issue:
this attribute may need language similar to that in Act to address the cardinality
Role . code
Datatype: CE Mandatory: 0 Cardinaltiy: 0..1 Domain: RoleCode Strength: CWE
Definition:
A code specifying the specific kind of Role to which an Role-instance belongs.
Usage Notes:Role.code must conceptually be a proper specialization of Role.classCode. Role.code does not modify Role.classCode. Rather, each is a complete concept or a Role-like relationship between two Entities, but Role.code may be more specific than Role.classCode.
The Role.code may not be coded if only an un-coded name for the type of role is commonly used.
Issue:
"Is the specialization requirement a constraint? Can it be enforced?
Does the comment "may be uncoded" mean left null, or is this an instance where the CD datatype may include original text without a code value?"
Role . negationInd
Datatype: BL Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An indicator specifying that the Role is a competency that is specifically not attributed to the Entity playing the Role.
Examples:1) This Person is not our Employee
2) This Mouthwash does not have Alcohol as an ingredient.
Usage Notes: This attribute defaults to FALSE.
Issue:
Should this default to False or Null?
Role . name
Datatype: BAG<EN> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A non-unique textual identifier or moniker for the playing Entity intended for use principally when playing the Role.
Examples: Names used as an employee, as a licensed professional, etc.
Usage Notes:In general, names are specified using Entity.name. Role.name is only used when the standard wishes to distinguish names that are appropriate for use when referring to the Entity in one Role as opposed to other Roles..
Issue:
Role . addr
Datatype: BAG<AD> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A postal address for the Entity while in the Role.
Issue:
Role . telecom
Datatype: BAG<TEL> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A telecommunication address for the Entity while in the Role.
Issue:
Role . statusCode
Datatype: CS Mandatory: 0 Cardinaltiy: 0..1 Domain: RoleStatus Strength: CNE
Definition:
A code specifying the state of this Role as defined in the state-transition model.
Design Comments: This attribute was defined in the original RIM as repeating, owing to the presence of nested states in the state machines. In 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.
Issue:
Role . effectiveTime
Datatype: IVL<TS> Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An interval of time specifying the period during which the Role is in effect, if such time limit is applicable and known.
Issue:
Role . certificateText
Datatype: ED Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
A textual or multimedia depiction of a certificate issued by the scoping Entity of a Role certifying that this Role is indeed played by the player Entity.
Examples:
1) Paper-based certificate: a document or file that can be retrieved through an electronic interface to a hardcopy archive.
2) Electronic certificate: this attribute can represent virtually any electronic certification scheme, such as an electronically (including digitally) signed electronic text document.
3) Digital certificate (public key certificate): in particular, this attribute can represent digital certificates, as an inline data block or by reference to such data. The certificate data block would be constructed in accordance to a digital certificate standard, such as X509, SPKI, PGP, etc.
Usage Notes:The certificate subject is the Entity that plays the Role. The certificate issuer is the Entity that scopes the Role. The certificate can be represented in many different ways, either inline or by reference, according to the ED data type.
Issue:
Role . confidentialityCode
Datatype: SET<CE> Mandatory: 0 Cardinaltiy: 0..* Domain: Confidentiality Strength: CWE
Definition:
An indication of the appropriate disclosure of information about this Role with respect to the playing Entity..
Usage Notes:
Hiding information can have serious implications for care provision, and should be undertaken with care.
Confidentiality of the medical record cannot be achieved solely through confidentiality codes to mask individual record items from certain types of users. Filtered sensitive information can often be inferred given information that is 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. To mitigate inference-risk, aggregations of data should assume the confidentiality level of the most confidential action in the aggregation.
Issue:
Role . quantity
Datatype: RTO Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
A ratio (numerator : denominator) specifying the relative quantities of the Entity playing the Role in the Entity scoping the Role, used for Roles that represent composition relationships between the scoping and playing Entities.
Examples:1) This syrup's (scoper) ingredients include 160 mg (numerator) Acetaminophen (player) per tablespoon (denominator).
2) This herd (scoper) consists of 500 (numerator) cattle (player).
3) A VAX 6630 computer (scoper) has 3 (numerator) CPUs (player) as parts.
4) This package (scoper) contains 100 (numerator) pills (player).
Discussion:In composition-relationships (e.g., has-parts, has-ingredient, has-content) the Role.quantity attribute specifies that a numerator amount of the target entity is comprised by a denominator amount of the source entity of such composition-relationship. For example, if a box (source) has-content 10 eggs (target), the relationship quantity is 10:1; if 0.6 mL contain 75 mg of FeSO4 the ingredient relationship quantity is 75 mg : 0.6 mL. Both numerator and denominator must be amount quantities (extensive quantities, i.e., a count number, mass, volume, amount of substance, amount of energy, etc.).
Issue:
Need to distinguish when to use composition of multiple entities and when to use role quantity
Role . positionNumber
Datatype: LIST<INT> Mandatory: 0 Cardinaltiy: 0..* Domain: Strength:
Definition:
An integer specifying the position of the Entity playing the Role with respect to the Entity that scopes the Role.
Usage Notes:This attribute is primarily used with containment roles. For example, some containers have discrete positions in which content may be located. Depending on the geometry of the container, the position may be referenced as a scalar ordinal number, or as a vector of ordinal numbers (coordinates). Coordinates always begin counting at 1.
Some containers may have customary ways of referring to the positions; some have no way at all. In the absence of any specific regulation for a specific container type, the rule of thumb is that the coordinate that is changed first is positioned first. For an automated blood chemistry analyzer with a square shaped tray, this means that the first coordinate represents the direction the tray moves at each step, while the second coordinate represents the direction in which the tray moves only periodically.
Issue:
RoleLink
A connection between two roles expressing a dependency between those roles and permitting the authorization or nullification of a dependent role based on status changes in its causal or directing role.
Examples: 1.) A role of assignment or agency depends on another role of employment, such that when the employment role is terminated, the assignments are terminated as well. This is the dependency of the assignment role on the employment role, or in other words, the assignment is "part of" the employment.
2.) One role has authority over another (in organizational relationships). For example, an employee of type "manager" may have authority over employees of type "analyst" which would be indicated by a role link for "direct authority."
Discussion: RoleLink specifies the relationships between roles, not between people (or other entities). People (or other Entities) are primarily related by the player/scoper relationships for player's Role and more generally through their interactions (i.e. their participations in acts).
RoleLink . typeCode
Datatype: CS Mandatory: -1 Cardinaltiy: 1..1 Domain: RoleLinkType Strength: CNE
Definition:
A code specifying the kind of connection represented by this RoleLink, e.g., has-part, has-authority.
Issue:
RoleLink . priorityNumber
Datatype: INT Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An integer specifying the relative preference for considering this relationship before other like-typed relationships having the same source.
Examples:For multiple backups, specifies which backup is considered before others.
Specifies which is the preferred ServiceDeliveryLocation for a Physician working on behalf of a particular Health Authority.
Usage Notes: RoleRelationships with lower priorityNumber values take priority over those with higher values. 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.
Issue:
RoleLink . effectiveTime
Datatype: IVL<TS> Mandatory: 0 Cardinaltiy: 0..1 Domain: Strength:
Definition:
An interval of time specifying the period during which the connection between Roles is in effect.
Issue:
