Design Comments: The record target indicates whose record holds the documentation of this public health statement.

UsageNotes: R_Subject universal

Design Comments: The person or organization that has primary responsibility for the public health statement. The responsible party is not necessarily present in an action, but is accountable for the action through the power to delegate, and the duty to review actions with the performing actor after the fact.

UsageNotes: R_AssingedParty universal

Design Comments: The person or organization that originates the public health statement and therefore has responsibility for the information given in the Act and ownership of this Act. The author may be either an investigative subject or a assigned party (person or organization).

UsageNotes: ProviderPatientOrRelated choice

Design Comments: Identifies the person transcribing the data, details of which are carried in the AssignedPerson CMET.

UsageNotes: R_AssignedPerson universal

Design Comments: A source of reported information (e.g., a next of kin who answers questions about the patient's history).

UsageNotes: ProviderPatientOrRelated choice

Design Comments: A clinical statement may be associated with a location.

UsageNotes: LocationChoice

Design Comments: The precondition class, derived from the ActRelationship class, is used along with the Criterion class to express a condition that must hold true before some other activity occurs.

Design Comments: Each Act may have one or more component ProcessSteps. Virtually any workflow step associated with the target act can be communicated here. The statusCode attribute has been provided to allow the filler to indicate the state of a process step (including completion).

Design Comments: This act relationship allows virtually any relationship between a public health act and the A_SupportingClinicalStatement CMET. Note that if the ActReference class is used from the A_SupportingClinicalStatement CMET, then the contextConductionInd in the act relationship must be set to false.

Design Comments: This act relationship allows virtually any relationship between acts to be expressed in this model. The souorce act is a clinical statement conformant act. The target is any act.

Rationale: This act relationship between the clinical statement comformant acts and non-clinical statement conformant acts is necessary because not all HL7 models conform with clinical statement, yet may contain information relevant to public health.

Design Comments: This act relationship allows virtually any relationship between acts to be expressed in this model. The reader is directed to the Clinical Statement domain for further documentation on the use of this act relationship.

Design Comments: This act relationship allows virtually any relationship between acts to be expressed in this model. The target act is a clinical statement conformant act. The source is any act.

Rationale: This act relationship between the clinical statement comformant acts and non-clinical statement conformant acts is necessary because not all HL7 models conform with clinical statement, yet may contain information relevant to public health.

Design Comments: The Act (ACT) choice is a derivative of the RIM Act class, to be used when the other more specific classes are not appropriate. This class should not be used if there is a more appropriate class in the Act Choice or the SupportingClinicalStatement CMET.

Many activites of interest to public health which are not directly related to health care may be modeled using the Act class. For instance if a case of food poisoning occurs during a picnic (bad potato salad perhaps) the picnic can be modeled as an Act, and the people at the picnic would be documented as participants in the picnic.

Design Comments: The InvestigationEvent class captures information directly related to the investigation and pulls together the rest of the relevant information.

The subject of an investigation may be an einty (in the role of an investigative subject) or another act such as an exposure. Investigations normally use the trigger (TRIG) or reason (RSON) act relationship to document the activities that caused the investigation to occur.

Design Comments: The InvestigationIntent class carries basic information regarding wither a request to perform an investigation or a promise to perform an investigation. The RQO (request or order) mood indicates that this is a request and use of the PRMS (promise) mood indicates a promise to perform an investigation. Other attributes include id, code, text, statusCode, effectiveTime, priorityCode and reasonCode.

Design Comments: The Incident class describes some core information about the incident as a whole. This includes its type, when it occurred and any textual description of the incident.

Incident is an event that occurred outside of the control of one or more of the parties involved. Includes the concept of an accident.

Design Comments: A public health case is an Observation representing a condition or event that has a specific significance for public health. Typically it involves an instance or instances of a reportable infectious disease or other condition. The public health case can include a health-related event concerning a single individual or it may refer to multiple health-related events that are occurrences of the same disease or condition of interest to public health. An outbreak involving multiple individuals may be considered as a type of public health case. A public health case definition (Act.moodCode = "definition") includes the description of the clinical, laboratory, and epidemiologic indicators associated with a disease or condition of interest to public health. There are case definitions for conditions that are reportable, as well as for those that are not. There are also case definitions for outbreaks. A public health case definition is a construct used by public health for the purpose of counting cases, and should not be used as clinical indications for treatment. Examples include AIDS, toxic-shock syndrome, and salmonellosis and their associated indicators that are used to define a case.

Design Comments: An outbreak represents a series of public health cases. The date on which an outbreak starts is the earliest date of onset among the cases assigned to the outbreak, and its ending date is the last date of onset among the cases assigned to the outbreak.

Design Comments: Exposure is an interaction that provides opportunity for transmission of an agent from an exposure source entity to an exposure target entity. The agent is a physical (including energy), chemical or biological substance. (Note: This class deals only with opportunity and not the outcome of the exposure, i.e. not all exposed parties will necessarily acquire the agent nor will all who acquire the agent necessarily experience actual harm or benefit.)

Design Comments: An Organizer (ORGANIZER) choice is a derivative of the RIM Act class, which can be used to create groupings of other clinical statements that share a common context for navigational purposes. An Organizer can contain other Organizers and/or other clinical statements, by traversing the component relationship. An Organizer can refer to acts by reference or by value via the component relationship. An Organizer cannot be the source of the sourceOf1, sourceOf2, definition or conditions relationships.

The record entries relating to a single clinical session are usually grouped under headings that represent phases of the encounter, or assist with layout and navigation. The organizer represents a heading in a heading structure, or "organizer tree" and does not itself have any semantic content. Clinical headings usually reflect the clinical workflow during a care session, and might also reflect the main author's reasoning processes. Knowledge of the heading is not required to interpret contained clinical statements. Much research has demonstrated that headings are used differently by different professional groups and specialties, and that headings are not used consistently enough to support safe automatic processing of the EHR.

The value for Act.ClassCode may be taken from the ActClassContainer vocabulary domain. Several specific types of collection are recognized (folder, composition, topic, category, cluster and battery), although individual communications will restrict the types that may be used for individual communication use cases.

NOTE: The ActClassContainer title was changed to ActClassRecordOrganizer at the July 2007 harmonization meeting. The Entry code was changed to Grouper and the Organizer was changed to Container. When this change is added to the RIM the messaging tools and the vocabulary for this class will be changed to ActClassRecordOrganizer.

An Organizer typically can be assigned a SNOMED CT concept identifier appropriate to its type (for example a category might be identified as 'investigations' and a battery might be identified as 'Full blood count'). However, any kind of concept identifier can be used, such as in the case of the HL7 CDA R2 Implementation Guides where LOINC is frequently employed.

The Organizer may be used to harmonize hierarchical RECORD_COMPONENTs within and ENTRY object under either the CEN/ISO 13606 or openEHR standard with a Clinical Statement.

Design Comments: The interval of time during which the party is responsible for the associated public health statement.

Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only.

Design Comments: The time at which the author is involved in the act through this Participation.

Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act.

Design Comments: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed.

Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability.

Design Comments: A person that is the subject of an investigation. This role is scoped by the organization responsible for the investigation.

Design Comments: A code further describing the type of identified subject.

Design Comments: An interval of time specifying the period during which the InvestigatePerson role is in effect, if such time limit is applicable and known.

Design Comments: An interval of time specifying the time during which the transcriber is involved in the Act through this Participation.

Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act.

Design Comments: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed.

Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability.

Design Comments: A code specifying additional detail about the function that the informant has in the Act.

Design Comments: An interval of time specifying the time during which the informer is involved in the act through this Participation.

Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act.

Design Comments: A place that has been identified by the scoping organization.

Design Comments: Relates a place (player) to a location (scoper) at which it is present in some way.

Design Comments: A code further identifying the type of identified location.

Design Comments: Identifier(s) for this hierarchical relationship of two places.

Design Comments: A code further identifying the type of hierarchical relationship of two places.

Design Comments: A located palce may be the subject of spatial corrdinate observations.

Design Comments: A criterion or condition over service events that must apply for an associated act to be considered.

Design Comments: A code further identifying the type of observation criterion.

Design Comments: TBD

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: A requirement to be true before an act is performed. The target is an observation in criterion mood. For multiple pre-conditions a conjunction attribute (AND, OR, XOR) is applicable.

Design Comments: This is used for sequencing purposes only.

Design Comments: Each Act may have one or more component ProcessSteps. Virtually any workflow step associated with the target act can be communicated here. The statusCode attribute has been provided to allow the filler to indicate the state of a process step (including completion).

Design Comments: An id for this process step instance.

Design Comments: A word or phrase by which a specific process step may be known among people.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The operationally relevant time of the process step, exclusive of administrative activity.

Design Comments: A person or organization that actually and principally carries out the action.

UsageNotes: ProviderPatientOrRelated choice

Design Comments: Associates a participant with a public health statement. The particticipant typeCode should be further refined to something more specific.

UsageNotes: ParticipantChoice

Design Comments: Identifies the "master" or "service catalog" entry of the act. Use this alone or in conjunction with code or text in the source act.

UsageNotes: ActDefinition

Design Comments: A ProcessStep may have one or more component ProcessSteps.

Design Comments: The act may be the subject of zero to many ControlActEvents. These Control Acts communicate the trigger event and other "action" information regarding the associated act. This structure is useful for historical query responses and management of changes of state of acts.

UsageNotes: SubjectOf ControlActEvent

Design Comments: A code specifying additional detail about the function that the performer has in the Act.

Design Comments: An interval of time specifying the time during which the performer is involved in the act through this Participation.

Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act.

Design Comments: A code specifying additional detail about the function that the Participation has in the Act, if such detail is not implied by the Participation.typeCode.

Design Comments: Used for sequencing purposes only.

Design Comments: Indicates whether the specified participation did not, does not, or should not occur, depending on the associated Act mood.

Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only.

Design Comments: An interval of time specifying the time during which the participant is involved in the act through this Participation.

Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act.

Design Comments: A code specifying the extent to which the Entity playing the participating Role is aware of the associated Act.

Design Comments: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed.

Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability.

Design Comments: Indicates that the resource for this Participation must be reserved before use (i.e., it is controlled by a schedule).

Design Comments: The conditions under which a participating item may be replaced with a different one.

Design Comments: An indication that the participation is a filtered subset of the total participations of the same type associated with the Act.

Design Comments: A competency of the Entity that plays the Role as identified, defined, guaranteed, or acknowledged by the Entity that scopes the Role.

Design Comments: A unique identifier for the player Entity in this Role.

Design Comments: A code specifying the specific kind of Role to which an Role-instance belongs.

Design Comments: An indicator specifying that the Role is a competency that is specifically not attributed to the Entity playing the Role.

Design Comments: A non-unique textual identifier or moniker for the playing Entity intended for use principally when playing the Role.

Design Comments: A postal address for the Entity while in the Role.

Design Comments: A telecommunication address for the Entity while in the Role.

Design Comments: A code specifying the state of this Role as defined in the state-transition model.

Design Comments: An interval of time specifying the period during which the Role is in effect, if such time limit is applicable and known.

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

Design Comments: An indication of the appropriate disclosure of information about this Role with respect to the playing Entity.

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

Design Comments: An integer specifying the position of the Entity playing the Role with respect to the Entity that scopes the Role.

Design Comments: he ActDefinition class represents the definition (master file) for the associated Act. Typically this definition is drawn from the local service catalog.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: This is used for sequencing purposes only.

Design Comments: These Control Acts communicate the trigger event and other "action" information regarding the associated act. This structure is useful for historical query responses and management of acts.

Design Comments: The identifier that has been designated for the control act or notification.

Design Comments: A code specifying the motivation, cause, or rationale of the Act. The reasonCode should only be used for common reasons that are not related to a prior Act or any other condition expressed in Acts. Example reasons that might qualify for being coded in this field might be: "routine requirement", "infectious disease reporting requirement", "on patient request", or "required by law". The reasonCode attribute identifies types of reasons, or broad categories of reasons. It is not to be used for the identification of fine-grained reasons for the Act.

Design Comments: This is used for sequencing purposes only.

Design Comments: A real number or 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.

Design Comments: A quantity of time that should elapse between when an Act is ready for execution and the actual beginning of the execution.

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

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

Design Comments: A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.

Design Comments: This is used for sequencing purposes only.

Design Comments: A real number or 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.

Design Comments: A quantity of time that should elapse between when an Act is ready for execution and the actual beginning of the execution.

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

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

Design Comments: A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.

Design Comments: This is used for sequencing purposes only.

Design Comments: A real number or 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.

Design Comments: A quantity of time that should elapse between when an Act is ready for execution and the actual beginning of the execution.

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

Design Comments: A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.

Design Comments: AnyAct is used to convey information about a non-cl;inical statement compliant act.

Rationale: This non-clinical statement conformant act is necessary because not all HL7 models conform with clinical statement, yet may contain information relevant to public health.

Design Comments: The id attribute is used to carry an identifier for the act. The datatype for this attribute has been designated as SET<II> so that the act can be described using multiple identifiers (e.g. from the local system, from a regional system and from a national system).

Design Comments: A code futhure classifying the type of investigation.

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

Design Comments: This attributte is retained for backward compatibility only. It has been replaced by actionNegationInd.

Design Comments: The AnyAct.derivationExpr attribute is used to communicate the algorithmic expression used to derive the act.

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

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The status reflects the state of the activity. Values are drawn from the act state machine.

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

Design Comments: A time expression specifying when an Act occurs, or, depending on the mood, is supposed to occur, scheduled to occur, etc.

Design Comments: The point in time at which information about Act-instance (regardless of mood) first became available to a system reproducing this Act.

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

Design Comments: A code that indicates the appropriate 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: An indication that the Act is interruptible by asynchronous events.

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

Design Comments: A code indicating whether the Act statement as a whole, with its subordinate components has been asserted to be uncertain in any way.

Design Comments: 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. The reasonCode should be used only for administrative reasons for the act. Clinical reasons should use the RSON act relationship to a separate act.

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

Design Comments: The principle target of the public health statement.

UsageNotes: R_Subject universal

Design Comments: Identifies one or more individuals who verify the content of the Public Heralth Statement, details of which are carried in the AssignedEntity CMET.

UsageNotes: R_AssignedPerson universal

Design Comments: The SourceOf5 act relationship allows virtually any relationship between acts to be expressed in this model.

Design Comments: This is used for sequencing purposes only.

Design Comments: An interval of time specifying the time during which the subject is involved in the act through this Participation.

Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act.

Design Comments: A code specifying the extent to which the subject is aware of the associated Act.

Design Comments: A textual or multimedia depiction of commentary related to the participation. This note is attributed to this participant only.

Design Comments: A code specifying the modality by which the Entity playing the Role is participating in the Act.

Design Comments: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed.

Design Comments: A textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified in the Participation.typeCode and that he or she agrees to assume the associated accountability.

Design Comments: When 'true' reverses the direction of the relationship e.g. 'Cause of' becomes 'Caused by'. The inversionInd is used in this model instead of providing a separate Target recursive act relationship.

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 (see ActRelationship.contextConductionInd). The default value of AN (additiive non-propagating) has been associated with this act relationship.

Design Comments: If the indicator is true, associations in the parent act are conducted across the ActRelationship to the child act. The default value of 'true' has been associated with this attribute.

Design Comments: This is used for sequencing purposes only.

Design Comments: A real number or 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.

Design Comments: A quantity of time that should elapse between when an Act is ready for execution and the actual beginning of the execution.

Design Comments: An indicator that asserts that the meaning of the link is negated. when 'true' allows the sender to specifically state that the relationship does not apply e.g.. An observation was not caused by a medication

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

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

Design Comments: Indicates whether or not the source Act is intended to be interpreted independently of the target Act.

Design Comments: A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.

Design Comments: This is used for sequencing purposes only.

Design Comments: A real number or 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.

Design Comments: A quantity of time that should elapse between when an Act is ready for execution and the actual beginning of the execution.

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

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

Design Comments: A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.

Design Comments: This is used for sequencing purposes only.

Design Comments: A real number or 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.

Design Comments: A quantity of time that should elapse between when an Act is ready for execution and the actual beginning of the execution.

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

Design Comments: A code indicating whether the specific relationship between the source and target Acts has been asserted to be uncertain in any way.

Design Comments: when set to "true", is a positive assertion that the descriptive attributes of the Act as a whole are negated. The inert properties such as Act.id, Act.moodCode, and the participations are not negated. These inert properties always have the same meaning: i.e., the author remains the author of the negative Act. 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.

Design Comments: The point in time at which information about Act-instance (regardless of mood) first became available to a system reproducing this Act.

Design Comments: The Act.priorityCode is defined by HL7 as: "A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen".

The priorityCode attribute has a potential overlap with some vocabularies. This potential conflict is resolved as follows:

* priorityCode should be used to indicate the priority as it relates to workflow management. It is also used to indicate priority assigned by the originator of a request or result or to indicate the priority with which the communication recipient should respond to the information in the Act. For example, the request for a procedure should be treated as 'urgent'. * Where the vocabulary used in the message has a priority attribute, then this should be used in coded expressions where the priority significantly alters the Act.code, or in the case of an Observation, the Observation.value attribute. For example, the concept 'an Emergency appendectomy' should be expressed totally within vocabulary expression used in Procedure.code.

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

Design Comments: A code indicating whether the Act statement as a whole, with its subordinate components has been asserted to be uncertain in any way.

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

Design Comments: The id attribute is used to carry an identifier for the investigation. The datatype for this attribute has been designated as SET<II> so that the investigation can be described using multiple identifiers (e.g. from the local system, from a regional system and from a national system).

Design Comments: TBD - RIM definintion is in the process of being changed.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The InvestigationEvent.effectiveTime is the time during which the investigation is conducted, exclusive of administrative activity. For instance an investigator may spend some time travel to and from the site of an investigtation. This travel time is not part of the effective time associated with the investigation. The time spent at the location conducting the investigation is the effective time in this case. Note that the effectiveTime uses the GTS data type since the actual effective time of the investigation may actually be the sunion of multiple intervals of time.

Design Comments: The InvestigationEvent.activity time includes all time spent related to the investigation, including administrative time not included in effective time. This is a GTS data type for the same reason as effective time, it may be the union of multiple intervals of time.

Design Comments: Provides information on the date/time of the most recent information included in the InvestigationEvent.

Design Comments: InvestigationEvent.priorityCode is used to document the actual priority used to perform the investigation.

Design Comments: A code that indicates the appropriate disclosure of information about this investigation.

Design Comments: The primary language in which this InvestigationEvent is specified, particularly the language of the text attribute.

Design Comments: An InvestigationEvent may be in fulfillment of an InvestigationIntent (order or promise).

Design Comments: This is used for sequencing purposes only.

Design Comments: The InvestigationIntent class carries basic information regarding wither a request to perform an investigation or a promise to perform an investigation. The RQO (request or order) mood indicates that this is a request and use of the PRMS (promise) mood indicates a promise to perform an investigation. Other attributes include id, code, text, statusCode, effectiveTime, priorityCode and reasonCode.

Design Comments: The InvestigationIntent.title attribute is used to convey a common title or name for the requested or promised investigation.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The InvestigationIntent.effectiveTime documents the time the requested or promised investigation should take place.

Design Comments: The InvestigationIntent.priorityCode attribute documents the urgency or priority which the filler of the request should associate with the investigation request or promise. In request mood priorityCode documents the urgency with which the placer believes the requested investigation should be initiated. In promise mood the priorityCode documents the urgencywith which the filler intends to initiate the investigation.

Design Comments: The InvestigationIntent.reasonCode is used to document any "administrative" reasons for the request or promise. Clinical reasons for the request or promise should be documented using the RSON (reason) act relationship to an act documenting the clinical reason. An example would be requesting an investion with the reason being a Public Health Case reporting an instance of a notifiable disease.

Design Comments: TBD. Negation ind is changing in the RIM due to harmonization.

Design Comments: The PublicHealthCase.id attribute is used to distinguish this case from all other public health cases. Multiple ids are supported to allow inclusion of both a snapshot id as well as a business id.

Design Comments: The PublicHealthCase.code attribute is used to categorize the type of case associated with this class.

Design Comments: TBD

Design Comments: A character string containing a formal language expression that specifies how the Public Health Case attributes are, should be, or have been derived from input parameters associated with derivation relationships.

Design Comments: A word or phrase by which a specific Public Health Case may be known among people.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The PublicHealthCase.statusCode attribute is used to report the status of the Public Health Case record. It should not be used to carry the clinical state of the case.

Design Comments: For public health case, the effectiveTime is the time at which the case holds (is effective) for the subject.

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

Design Comments: A code indicating whether the public health case as a whole, with its subordinate components has been asserted to be uncertain in any way.

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

Design Comments: The value attribute is used to identify the primary condition or disease associated with the case.

Design Comments: One or more codes specifying a rough qualitative interpretation of the PublichealthCase.value.

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

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

Design Comments: Code for the method by which public health was made aware of the case. Includes provider report, patient self-referral, laboratory report, case or outbreak investigation, contact investigation, active surveillance, routine physical, prenatal testing, perinatal testing, prison entry screening, occupational disease surveillance, medical record review, etc.

Design Comments: Code for the mechanism by which disease was acquired by the living subject involved in the public health case. Includes sexually transmitted, airborne, bloodborne, vectorborne, foodborne, zoonotic, nosocomial, mechanical, dermal, congenital, environmental exposure, indeterminate.

Design Comments: Code that indicates whether the disease was likely acquired outside the jurisdiction of observation, and if so, the nature of the inter-jurisdictional relationship. Possible values include not imported, imported from another country, imported from another state, imported from another jurisdiction, and insufficient information to determine.

Design Comments: A public health case is the subject of a CaseStatus observation.

Design Comments: The CaseStatus class is used to document the clinical status of a Public Health Case.

Design Comments: A unique identifier for the Outbreak.

Design Comments: TBD

Design Comments: A word or phrase by which the Outbreak may be known among people.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The status of this record of the Outbreak.

Design Comments: Outbreak.activityTime describes the interval of time during with the outbreak occurs, inlcuding time spent administratively. for instance an outbreak may be declared as completed, but the administrative work of documenting and cleaning up after the outbreak may go on for some time after the outbreak is declared over. Activity time takes into account this administrative time, but the effective time of the outbreak does not.

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

Design Comments: A code indicating whether the outbreak as a whole, with its subordinate components has been asserted to be uncertain in any way.

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

Design Comments: The value attribute is used to identify the primary condition or disease associated with the outbreak.

Design Comments: Code for the method by which public health was made aware of the outbreak.

Design Comments: Code for the mechanism by which disease was acquired by the living subjects involved in the outbreak. Includes sexually transmitted, airborne, bloodborne, vectorborne, foodborne, zoonotic, nosocomial, mechanical, dermal, congenital, environmental exposure, indeterminate.

Design Comments: An id for this exposure act.

Design Comments: A code further describing the type of exposure. Examples include exposure to radiation, drug administration, inhalation of peanut aerosol or viral particles.

Design Comments: TBD

Design Comments: A word or phrase by which a specific exposure may be known among people.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The Exposure.statusCode attribute should be interpreted as the state of the Exposure business object (e.g., active, aborted, completed) and not the clinical status of the exposure (e.g., probable, confirmed). The clinical status of the exposure would be associated with the exposure via a subject observation.

Design Comments: The clinically relevant time of the exposure. This typically will be the time of the exposure. The GTS data type is used since the expsoure time may be the union of multiple intervals of time (i.e., multiple exposures over a period of time.)

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

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

Design Comments: A code indicating whether the exposure, with its subordinate components has been asserted to be uncertain in any way.

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

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

Design Comments: A qualitative measure of the degree of exposure to the causative agent. This includes concepts such as "low," "medium" and "high." This quantifies how the quantity that was available to be administered to the target differs from typical or background levels of the substance.

Design Comments: Code for the mechanism by which exposure agent was exchanged or potentially exchanged by the participants involved in the exposure.

Design Comments: The entity playing the associated role is the physical (including energy), chemical or biological substance that is participating as the exposure agent in the exposure. For example in communicable diseases, the associated playing entity is the disease causing pathogen.

Design Comments: The exposure participant is used when its not know whether a particular entity was involved in the exposure as an exposure target or as an exposure source. Early in an exposure investigation it may not be know what entities are the source of the exposure vs. targets of the exposure. As the exposure investigation progresses, the specific ways that entities participated in the exposure may become better identified, resulting in particular entities participation being changed to the more specific exposure target or exposure source.

Design Comments: The exposure agent carrier participates in the exposure act as an exposure source (EXSRC).

Design Comments: The exposure target participation idenfies those investigative subject(s) that are known to be the target of an exposure. In public health these entities are often called "contacts".

Design Comments: This is used for sequencing purposes only.

Design Comments: Indicates whether the specified exposure agent exposure did not, does not, or should not occur, depending on mood.

Design Comments: The time during which the exposure agent participant is involved in the exposure through this Participation.

Design Comments: The exposure agent instance (INST) role is scoped by the type of entity acting as the exposure agent in the exposure. The role is played by an instance of the type of entity scoping the role. Often the instance of the entiy is not known, rather only the type of entity is known. The playing entity must use determinerCode = INSTANCE and the scoping entity must use the determinerCode = KIND.

Design Comments: This is used for sequencing purposes only.

Design Comments: If true, the negationInd would communicate that this investigative subject is known to not be a exposure participant. This would include that the investigative subject is neither an exposure source or target.

Design Comments: The time during which the exposure participant is involved in the exposure through this Participation.

Design Comments: A code specifying the extent to which the investigative subject is aware of the associated exposure.

Design Comments: This is used for sequencing purposes only.

Design Comments: TBD

Design Comments: An interval of time specifying the time during which the exposure agent is involved in the exposure through this Participation.

Design Comments: A code specifying the extent to which the Entity playing the exposure agent carrie Role is aware of the associated exposure.

Design Comments: This is used for sequencing purposes only.

Design Comments: If true, the negationInd would communicate that the investigative subject is known not to be a target of the exposure.

Design Comments: The time during which the investigative subject is involved in the exposure as the exposure source..

Design Comments: A code specifying the extent to which the investigative subject is aware of the associated exposure.

Design Comments: An id for the organizer.

Design Comments: A code further identifying the type of organizer.

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. Please see the RIM Act.text description for further clarification of the use of this attribute.

Design Comments: The clinically or operationally relevant time of the organizer, exclusive of administrative activity.

Design Comments: The point in time at which information about organizert-instance first became available to a system reproducing this organizer.

Design Comments: A code or set of codes specifying the urgency under which the organizer happened or is happening.

Design Comments: A code that indicates the appropriate disclosure of information about this organizer.

Design Comments: An Organizer can contain other Organizers and/or other clinical statements, by traversing the component relationship. An Organizer can refer to acts by reference or by value via the component relationship.

Design Comments: This is used for sequencing purposes only.

Design Comments: This attribute indicates whether or not the source Act is intended to be interpreted independently of the target Act. 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. 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. The default value for this attribute has been set to 'true'.