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?
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|
The date attestation is due for this patient service.
Date the patient service begins.
|OBR^7^00241^Observation Date/Time| |RXA^3^00345^Date/Time Start of Administration|
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 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|
An indication that the diagnosis is confidential.
|DG1^18^00767^Confidential Indicator| |DRG^10^00767^Confidential Indicator|
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|
An indication that the patient service was declined.
The end date and time for the patient service.
|OBR^8^00242^Observation End Date/Time| |RXA^4^00346^Date/Time End of Administration|
Indicates the individual's family or significant other's comprehension of the service event.
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|
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|
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|
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?
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|
A code indicating a recurring service and the nature of the recursion.
|PV2^31^00732^Recurring Service Code|
The date the patient service is scheduled to begin.
|OBR^36^00268^Scheduled Date/Time|
Text that describes the service performed along with relevant details of the service.
Rationale: To differentiate this attribute from Service_event: service_event_desc.
A description of the service event.
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."
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|
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.
Rationale: Establish independence of service events from encounters.
Rationale: Establish Service_event as the evidence for a Service_reason.
Rationale: Establish Service_reason as the reason for a Service_event.