Class: Service_event

Description of: Service_event

Class steward is Orders/Observation
Interested committees Patient Administration
The performance of a health related action provided by one or more active participants on behalf of one or more target participants.

This includes medical as well as non-medical services. A patient can be both target and active participant of the service: - a clinical test - an assessment of health condition (such as problems and diagnoses), - the setting of healthcare goals - the performance of treatment services, such as medication, surgery, physical and psychological therapy. - assisting, monitoring or attending - training and education services to patients and their next of kins - notary services, such as advanced directives or living will

Examples of active participants are nurses, doctors, family members, and notary publics. Target participants may include, the patient, the patient's spouse, family, or community, a specimen drawn from the patient or from any object of interest. As patients do play active roles in their own healthcare, the patient can be both an active participant and a target participant at the same time (self-administered or reflexive services.) A service_event can have multiple active participants and multiple target participants, their specific role is distinguished in the "type_cd" of the respective instance of the participation class (see there [HREF]).

The service_event is the documentation of a rendered service including its detailed context, as opposed to the formulation of an intended service. A service event includes the "results," "answers" or "procedure products" gained during the service. In this model, "results" do not exist without a service, and every clinical result, including those results gained accidentially, are service_events.

ISSUE: Should there be an Observation Service Event specialization Patient Service Event?

Attribute definitions for: Service_event

attestation_dttm

The date the service provider attests that the patient service was delivered as documented.

Rationale: To support the Problem requirement for specificity of attestation timing.

|DG1^19^00768^Attestation Date/Time|

attestation_due_dt

The date attestation is due for this patient service.

begin_dttm

Date the patient service begins.

|OBR^7^00241^Observation Date/Time| |RXA^3^00345^Date/Time Start of Administration|

charge_to_practice_amt

Monetary amount for the charge to the ordering entity for the studies performed when applicable.

Rationale: previously unmatched V2.3 field

OpenIssue:

|OBR^23^00256^Charge To Practice|

charge_to_practice_cd

Charge code for the charge to the ordering entity for the studies performed when applicable.

Rationale: previously unmatched V2.3 field

OpenIssue:

|OBR^23^00256^Charge To Practice|

confidential_ind

An indication that the diagnosis is confidential.

|DG1^18^00767^Confidential Indicator| |DRG^10^00767^Confidential Indicator|

consent_cd

A code depicting the type of consent that was obtained for permission to treat the patient. May not represent consent from the patient.

|PR1^13^00403^Consent Code|

declined_ind

An indication that the patient service was declined.

end_dttm

The end date and time for the patient service.

|OBR^8^00242^Observation End Date/Time| |RXA^4^00346^Date/Time End of Administration|

family_awareness_txt

Indicates the individual's family or significant other's comprehension of the service event.

filler_id

The patient service unique identifier This is often assigned by the filler, but may be assigned by other processes. This attribute must use the EI datatype in all messages.

|FT1^23^00217^Filler Order Number| |OBR^3^00217^Filler Order Number| |ORC^3^00217^Filler Order Number| |TXA^15^00217^Filler Order Number|

filler_order_status_cd

Status of the fulfillment of an order. This status is originated by the filler. This is different from the status of the order itself, which is represented by ORC/ Order Control. This is NOT a trigger event.

Rationale: represents the ORC order control code, not the ORC Order Status (status of order fulfillment by the filler).

OpenIssue:

|ORC^5^00219^Order Status|

filler_order_status_dttm

Indicates the date and time that a status, as defined in Order Status, is entered or changed. Note: Order Status represents the status of order fulfillment by the filler. This is different from Order Control Code, which reflects the status of the order from the placer's viewpoint.

Rationale: to represent the use of this V2.3 field as the date and time of change in ORC/ order status.

OpenIssue:

|OBR^22^00255^Results Rpt/Status Chng - Date/Time|

individual_awareness_cd

This field contains the individual's comprehension of the service event (e.g., full, marginal, partial, etc.).

OpenIssue: Is this code or text? Should this be renamed to Patient_awareness_cd?

nm

patient_sensitivity_cd

Indicates whether patient considers this service to be confidential.

Rationale: Code data type allows more structure to the representation of confidentiality. The use of the word "sensitivity" parallels usage in class Problem

|DG1^18^00767^Confidential Indicator| |DRG^10^00767^Confidential Indicator|

recurring_service_cd

A code indicating a recurring service and the nature of the recursion.

|PV2^31^00732^Recurring Service Code|

scheduled_start_dttm

The date the patient service is scheduled to begin.

|OBR^36^00268^Scheduled Date/Time|

service_desc

Text that describes the service performed along with relevant details of the service.

Rationale: To differentiate this attribute from Service_event: service_event_desc.

service_event_desc

A description of the service event.

specimen_action_cd

A code depicting the action taken upon the specimen in the context of a service event.

Rationale: Each service event uses only one specimen. Reflects current usage of "specimen" rather than "analyzed object."

specimen_received_dttm

The data and time the specimen was received for use in the service event.

Rationale: Each service event uses only one specimen.

|OBR^14^00248^Specimen Received Date/Time|

Association definitions for: Service_event

is_associated_with (0,n) :: Financial_transaction :: pertains_to (1,1)

is_documented_by (0,n) :: Clinical_document_header :: documents (0,n)

is_performed_at (0,1) :: Master_patient_service_location :: is_location_for (0,n)

Rationale: support references to facilities in OBR; the parts of a pharmacy_service_event may be performed at several locations, which will be represented by relationships from each of the parts.

is_source_for (0,n) :: Service_event_relationship :: has_as_source (1,1)

is_target_for (0,n) :: Service_event_relationship :: has_as_target (1,1)

is_assigned_to (0,1) :: Patient_encounter :: has_assigned_to_it (0,n)

Rationale: Establish independence of service events from encounters.

fulfills (0,1) :: Service_intent_or_order :: is_fulfilled_by (0,n)

has_as_target (0,n) :: Target_participation :: is_target_of (0,1)

is_charged_to (0,1) :: Patient_billing_account :: has_charges_for (0,n)

is_evidence_for (0,n) :: Service_reason :: has_as_evidence (0,1)

Rationale: Establish Service_event as the evidence for a Service_reason.

has_as_active_participant (0,n) :: Active_participation :: participates_in (0,1)

has_as_reason (0,n) :: Service_reason :: is_reason_for (0,1)

Rationale: Establish Service_reason as the reason for a Service_event.

delivers (1,1) :: Master_service :: is_delivered_during (0,n)