Class: Service_event

Description of: Service_event

Class steward is Orders/Observation
Interested committees Patient Administration
The rendering of a Healthcare service to a patient.

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.

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|

consent_code

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|

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|

name

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

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|

Connection 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) :: 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.

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)

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

Rationale: Establish Service_event as the evidence for a Service_reason.

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)

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