Design Comments: An act, situated in another model, that is associated with a product reporting related activity. For example, an adverse event or reaction.

UsageNotes: ActRef is used to refer to a full instance of any clinically relevant statement. This also includes reaction instances captured in the base model. The classCode and moodCode of the reference shall have the same values as the act to which reference is being made. According to the context of use the referenced Act may be in the current communication or in a previously communicated message and available from a shared repository

Design Comments: Makes it possible to provide information about the performer of a cited act.

Design Comments: Makes it possible to provide information about the author of a cited act.

Design Comments: Makes it possible to provide information about the location of a cited act.

Design Comments: The relationship between an act event, and definitional information that characterizes acts of a particular type.

Design Comments: An act relationship that makes it possible to link a product reporting related act to an act reference. The act reference is used to create a link to acts external to the model, for example to an adverse event or reaction.

Design Comments: The recursive, target Of, association makes it possible to provide information about acts that further define and/or provide information about, acts that are provided in order to shed light on an adverse event or product report. Note, that two similar recursive associations - sourceOf and targetOf - are provided. When it is necessary to join two types of act, the choice of sourceOf or targetOf act relationship is based on the semantics of the act relationship type code used to characterize the association between the two.

Design Comments: An observation associated with an investigation subject which is relevant in the context of the adverse event or product problem report.

Design Comments: A type of procedure that involves a performer introducing or otherwise applying a material into or to the subject (Note the performer and the subject may be the same individual)

Examples: Substance administration may be used to represent

Administration of a measurable quantity of an external force (e.g. radiotherapy)

Administration of a measurable quantity of a substance or force as part of an investigative procedure (e.g. glucose administered in a glucose tolerance test).

Chemotherapy regimens (multiple substance administrations)

Drug prescription

Vaccination record

Tube feeding of a patient

Agricultural field spraying

Oiling a machine

Medicating a herd in a feedlot via food additives

Usage Notes: Substance administration is distinguished from an exposure by the participation of a performer in the act.

The substance administered by a performer physically interacts with the subject or is otherwise "taken in" by the subject during the act of administration.

Detailed information about the supplied substance is represented using the entity class or one of its subtypes.

The performer of a substance administration may be another entity such as a person, device, plant, e.g. poison ivy, animal, e.g. mosquito bite, or it may be the same entity as the subject, as in self-administration.

For purposes of this definition, photons and other models of radiation or light energy are considered substances.

Substances may also include living entities such as live virus vaccines and other materials containing infectious agents, e.g. saliva, blood products, etc. (Note: if the infectious agent is the subject of the substance administration, then the infectious agent is modeled as a "Living Subject.")

Design Comments: Provision of a material by one entity to another.

Examples: Ordering bed sheets; Dispensing of a drug; Issuing medical supplies from storage.

Design Comments: A procedure is "An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject." The class will include those procedures that are relevant to adverse event and product problem reporting.

Design Comments: The model includes encounter information relevant to adverse event and product problem reporting. A patient encounter is defined as "An interaction between a patient and care provider(s) for the purpose of providing healthcare-related service(s). Healthcare services include health assessment."

Design Comments: A record of something that is being done, has been done, can be done, or is intended or requested to be done. The class is used to represent acts that are not further specialized as an observation, procedure, etc.

UsageNotes: Product Defect Discovery act information is captured here.

Design Comments: An act which acts as an "Organizer of entries." It is Navigational, and is expected to have no semantic content. Knowledge of the section code is not required to interpret contained observations, however, the code will be useful within the adverse event and product problem reporting context. The act represents a heading in a heading structure, or "organizer tree".

Design Comments: 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 association allows such propagation.

Design Comments: 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 association allows such propagation.

Design Comments: The role of assigned entity is played by the responsible organization or person.

UsageNotes: The classes related to entity will be replaced with the AssignedEntity CMET when the needed change - to support the place for a license has been made in that CMET.

Design Comments: A identifier for the responsible person or organization in the context of the assigned entity role.

Design Comments: A code that more fully describes the assigned entity role.

Design Comments: A person who plays the role of assigned entity, or contact in the context of product reporting related information.

Design Comments: An organization that is involved with a product reporting related activity as either a service delivery location, or an assigned entity.

Design Comments: A identifier for the person.

Design Comments: A text name used by the person.

Design Comments: A telecommunications address, e.g., phone, fax, email, for the person.

Design Comments: A postal address used by the person.

Design Comments: Provides infomation about licenses granted to persons who participate in care and other activities.

Design Comments: The license number or identifier.

Design Comments: An indication of the type of license, e.g. doctor's license that is being granted.

Design Comments: The place, e.g. state, country, for which the license was issued and within which it is primarily valid. Note, in many cases, a license issued in one jurisdiction will be treated as valid in other related jurisdictions.

Design Comments: A code value that identifies the place.

Design Comments: The name of the place. To be used when a code value is not available.

Design Comments: An identifier for the organization.

Design Comments: A text name for the organization.

Design Comments: A telecommunications address, e.g., phone, fax, email, for the organization.

Design Comments: A postal address for the organization.

Design Comments: 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 association allows such propagation.

Design Comments: Definitional information about an act.

Design Comments: An identifier for the activity definition.

Design Comments: If true, associations in the parent act are conducted across the ActRelationship to the child act.

The identification of an Act as a parent or child (and therefore the direction context will be conducted) is determined by how the association is traversed when it is serialized. The first act to be encountered is considered to be the parent. Context conducts across the ActRelationship to the second (child) Act.

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

Design Comments: Provides information about a pause, or cap in time, between a pair of acts assocated via an act relationship.

Design Comments: An indicator that asserts that the meaning of the link is negated. 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.

Design Comments: A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or).

Design Comments: An act, situated in another model, that is associated with a product reporting related activity. For example, an adverse event or reaction.

UsageNotes: ActRef is used to refer to a full instance of any clinically relevant statement. This also includes reaction instances captured in the base model. The classCode and moodCode of the reference shall have the same values as the act to which reference is being made. According to the context of use the referenced Act may be in the current communication or in a previously communicated message and available from a shared repository

Design Comments: If true, associations in the parent act are conducted across the ActRelationship to the child act.

The identification of an Act as a parent or child (and therefore the direction context will be conducted) is determined by how the association is traversed when it is serialized. The first act to be encountered is considered to be the parent. Context conducts across the ActRelationship to the second (child) Act.

Design Comments: Indicates the sequence to be used in considering or interpreting the relationship of a parent act to the collection of children act related in the same way (that is sharing the same act relationship code value).

Design Comments: Provides information about a pause, or gap in time, between a pair of acts assocated via an act relationship.

Design Comments: An indicator that asserts that the meaning of the link is negated. 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.

Design Comments: A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or).

Design Comments: 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.

Design Comments: If true, associations in the parent act are conducted across the ActRelationship to the child act.

The identification of an Act as a parent or child (and therefore the direction context will be conducted) is determined by how the association is traversed when it is serialized. The first act to be encountered is considered to be the parent. Context conducts across the ActRelationship to the second (child) Act.

Design Comments: Indicates the sequence to be used in considering or interpreting the relationship of a parent act to the collection of children act related in the same way (that is sharing the same act relationship code value).

Design Comments: Provides information about a pause, or gap in time, between a pair of acts assocated via an act relationship.

Design Comments: An indicator that asserts that the meaning of the link is negated. 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.

Design Comments: A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or).

Design Comments: An identifier for the act. It is only expected to be used within the context of a single ICSR to provide needed references.

Design Comments: An indicator specifying that the Act statement is a negation of the Act as described by the descriptive attributes. Used with an Observation event, it allows one to say "patient has NO chest pain". Used with other types of acts, it allows one to say "The patient did not take codeine."

Design Comments: A text description of the observation. The attribute is used when the entire process of making the observation needs to be described. Textual results are captured in observation.value as are all results.

Design Comments: A time expression specifying the focal or operative time of the act.

Design Comments: A code that controls the disclosure of information about this Act, regardless of mood

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

Design Comments: Information that is assigned or determined by the observation action. Note, the datatype of the observation value is determined by the context.

Design Comments: One or more codes specifying a rough qualitative interpretation of the observation, such as "normal", "abnormal", "below normal", "change up", "resistant", "susceptible", etc.

Design Comments: A code that provides additional detail about the means or technique used to ascertain the observation.

Design Comments: A code specifying detail about the anatomical site or system that is the focus of the observation if this information is not already implied by the observation definition or Act.code.

Design Comments: A linkage between an observation and a reference range providing normal, abnormal, etc. values for observations of that type.

Design Comments: If true, associations in the parent act are conducted across the ActRelationship to the child act.

The identification of an Act as a parent or child (and therefore the direction context will be conducted) is determined by how the association is traversed when it is serialized. The first act to be encountered is considered to be the parent. Context conducts across the ActRelationship to the second (child) Act.

Design Comments: Information used to interpret the outcome of an observation. The Observation Range indicates the values which are to be interpreted as high, low, normal, etc.

Design Comments: If the Boolean indicator is valued, it indicates the specified value is not to be given the stated interpretation.

Design Comments: An identifier for the act. It is only expected to be used within the context of a single ICSR to provide needed references.

Design Comments: An indicator specifying that the Act statement is a negation of the Act as described by the descriptive attributes. Used with an Observation event, it allows one to say "patient has NO chest pain". Used with other types of acts, it allows one to say "The patient did not take codeine."

Design Comments: A text description of the substance administration.

Design Comments: A code that controls the disclosure of information about this Act, regardless of mood.

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

Design Comments: The detailed anatomical site where the medication enters or is applied to the subject.

Design Comments: The the physiological path or route for introducing the therapeutic material into or onto the subject.

Design Comments: The amount of the therapeutic agent or other substance given at one administration event. The dose may be specified either as a physical quantity of active ingredient (e.g., 200 mg) or as the count of administration-units (e.g., tablets, capsules, "eaches").

Design Comments: Identifies the speed with which the substance is introduced into the subject. Expressed as a physical (extensive) quantity over elapsed time (e.g., examples are 100 mL/h, 1 g/d, 40 mmol/h, etc.)

Design Comments: This attribute identifies the quantity that is expected to be consumed over a period of time (with mood="REQ", or that has been consumed (mood="EVN") within a time period. It is used as a verification check on the values specified for other values.

Design Comments: Identifies the maximum total quantity of a therapeutic substance that may be administered to a subject over the period of time.

Design Comments: A code for the administered thing taken from a larger whole. Used if the consumable material is specified as a larger whole but the doseQuantity relates to a specific portion of it rather than the entire consumable material. The ordering system only has a code for "Budesonide Metered Dose Inhaler" but the dose is to be measured in "number of actuations."

Design Comments: Makes it possible to provide information about a product used in a substance administration,

Rationale: The value, CSM, indicates that information related to a product consumed or to be consumed in a substance administration is being provided.

Design Comments: An identifier for the act. It is only expected to be used within the context of a single ICSR to provide needed references.

Design Comments: A code specifying the particular kind of Act that the Act-instance represents within its class.

Design Comments: 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.

Design Comments: A time expression specifying the focal or operative time of the Act, the primary time for which the Act holds, the time of interest from the perspective of the Act's intention.

Design Comments: A code that controls the disclosure of information about this Act, regardless of mood.

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

Design Comments: The amount that was or is to be supplied (depending on the moodCode)

Design Comments: Identifies the period time over which the supplied product is expected to be used, or the length of time the supply is expected to last.

Design Comments: A code specifying the particular kind of Act that the Act-instance represents within its class.

Design Comments: An indicator specifying that the Act statement is a negation of the Act as described by the descriptive attributes. Used with an Observation event, it allows one to say "patient has NO chest pain". Used with other types of acts, it allows one to say "The patient did not take codeine."

Design Comments: 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.

Design Comments: A code that controls the disclosure of information about this Act, regardless of mood.

Design Comments: Identifies the means or technique used to perform the procedure.

Design Comments: The anatomical site or system through which the procedure reaches its target (see targetSiteCode).

Design Comments: The anatomical site or system that is the focus of the procedure.

Design Comments: Makes it possible to provide information about a product participating as a device in a substance administration.

Design Comments: Makes it possible to provide information about a specimen that is created during or used within a procedure.

Design Comments: 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 association allows such propagation.

Rationale: 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 association allows such propagation.

Design Comments: 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 association allows such propagation.

Rationale: 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 association allows such propagation.

Design Comments: An indication of the order or sequence in which the specified products were created in the course of the procedure.

Design Comments: An identifier for the act. It is only expected to be used within the context of a single ICSR to provide needed references.

Design Comments: A code specifying the particular kind of Act that the Act-instance represents within its class.

Design Comments: 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.

Design Comments: A time expression specifying the focal or operative time of the Act, the primary time for which the Act holds, the time of interest from the perspective of the Act's intention.

Design Comments: A code that controls the disclosure of information about this Act.

Design Comments: Identifies the total quantity of time when the subject is expected to be or was resident at a facility as part of an encounter.

Design Comments: A code depicting the disposition of the patient at the time of discharge (e.g., discharged to home, expired, against medical advice, etc.).

Design Comments: An indicator specifying that the Act statement is a negation of the Act as described by the descriptive attributes. Used with an Observation event, it allows one to say "patient has NO chest pain". Used with other types of acts, it allows one to say "The patient did not take codeine."

Design Comments: A code that controls the disclosure of information about this Act.

Design Comments: Indicates that the assoicated product is the subject of the act. For the most part, the act will be the discovery of a product defect.

Design Comments: 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 association allows such propagation.

Design Comments: A unique identifier for the Act.

Design Comments: A code specifying the particular kind of Act that the Act-instance represents within its class.

Design Comments: 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.

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

Design Comments: A code that indicates the appropriate disclosure of information about this Act, regardless of mood.

Design Comments: The act relationship is used to capture acts which are recorded as components as an organizer class. This makes it easier to manage the context of acts which are provided within an adverse event or product problem message.

Design Comments: If true, associations in the parent act are conducted across the ActRelationship to the child act.

The identification of an Act as a parent or child (and therefore the direction context will be conducted) is determined by how the association is traversed when it is serialized. The first act to be encountered is considered to be the parent. Context conducts across the ActRelationship to the second (child) Act.