Shared Messages

The Act Generic Reference is used to convey generic information related to an Act and its associated classes. This is used for messages which adjust the status of an Act, by application level acknowledgement accept/reject messages, by act registry messages, and by act-related query response messages. Refer to the the R-MIM walkthroughs for clarification for details on these uses.

Note to Technical Committees: Technical committees can either use one of the shared messages as defined in this domain, or create a new R-MIM based on the D-MIM contained in this domain.

The base class of the D-MIM is ActGenericReference based on the Act class. Refer to the R-MIM walkthrough for the clone name used for derived messages from that R-MIM. This class and its associations contain generic information, which is why the descriptions below are generic in nature.

Note: The reason for this interaction is identified in the Trigger Event Control Act.

The following attributes are contained in the ActGenericReference act:

• classCode: A code specifying the class or category of Acts that the specific Act represents (required)

• moodCode: Specifies whether the Act is an activity that has happened, can happen, is happening, is intended to happen, or is requested/demanded to happen (required)

• id: A unique identifier for the Act (required)

• code: A code specifying which particular kind of Act that the Act represents within its class.

• text: The text attribute can be used to convey a textual or multimedia description of the Act.

• statusCode: A code specifying the state of the Act

• effectiveTime: The data and time the act occurred; the clinically relevant date and time.

• activityTime: The date and time the act occurred; the date and time relevant for administrative purposes, scheduling or billing.

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

The following associations are defined for the ActGenericReference class:

• authorOrPerformer: There are zero to many parties recorded as author or performer for the act. The author of any act is the person who takes responsibility for its creation. In some cases, it is desirable to indicate a performer as well as an author, for an act. The performer is the party who actually performs the act. At the same time, while it is generally assumed that only a single author is allowed, many performers can be specified. The authors or performers identified via this participation are the authors/performers of the act that is effected by the status change; not the authors/performers of the status update request. Note: The authors/performers of the status update request are identified by means of the authorOrPerformer participation associated with the Trigger Event Control Act.

• recordTarget: Indicates the patient(s) whose medical record(s) holds the documentation of the ActGenericStatus act. This is especially important when the subject of a service is an assoicated patient.

• overseer: There are zero to many overseers for the act. In some cases but by no means all, it is relevant to record information about a person who oversees the work of the acts author or performer. This is particularly relevant in instructional situations. It is possible, but unlikely for there to be many parties acting as overseer. The overseers identified via this participation are the overseers of the act that is effected by the status change; not the overseers of the status update request. Note: The overseers of the status update request are identified by means of the overseer participation associated with the Trigger Event Control Act.

• dataEnterer: If relevant, the party who enters data associated with the act may be recorded. It is possible for multiple parties to provide data entry. The data enterers identified via this participation are the data enterers of the act that is effected by the status change; not the data enterers of the status update request. Note: The data enterers of the status update request are identified by means of the dataEnterer participation associated with the Trigger Event Control Act.

• componentOf: Identifies the encounter to which this pertains.

• definition: Defines the service. Example: contains an identification of the service taken from a service catalog.

• inFulfillmentOf: Identifies zero or more Acts that are fulfilled by the focal Act of this message. In most cases the Act that is fulfilled will be an order, a promise or an appointment. Example: a lab result fullfills both the lab order as well as the lab promise acts.

Other Classes:

• ActIntent: Identifies the Act to which this pertains. Typically this will be used to identify the Request (Order) if the ActGenericReference is the Observation related to the request.

• ActDefinition: Identifies the act by means of a reference to a master file record. Typically this will be used to identify a specific service (e.g., diagnostic/laboratory test, medication, procedure).