Class: Patient_encounter

Description of: Patient_encounter

Class steward is Patient Administration
Interested committees Patient Care
An interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient. For example, outpatient visit to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call.

OpenIssue: This MUST be discussed with Patient Care in the context of Episode and Service Event definitions. Episode and Encounter definitions needs to be discussed.

OpenIssue: The status_cd attribute as the state attribute may not be in the right place in the Gen/Spec tree.

OpenIssue: States of patient encounter (#234).

Attribute definitions for: Patient_encounter

active_tmr ::

The date and time range that the patient encounter is valid. Encompasses what is often referred to as admit and discharge date and time.

ExRef: UB92 FL 17, UB91 FL 18

|PV1^44^00174^Admit Date/Time| |PV1^45^00175^Discharge Date/Time|

actual_discharge_disposition_cd ::

A code depicting the actual disposition of the patient at the time of discharge (e.g., discharged to home, expired, against medical advice, etc.). This attribute and the expected_discharge_disposition_cd attribute use the same table of values.

Rationale: Clarification of definition

|PV1^36^00166^Discharge Disposition|

acuity_level_cd ::

A code depiciting the acuity (complexity of patient care, resource intensiveness of the patient care) of a patient's medical condition upon arrival. Values may be derived from formal acuity coding schemes such as RBS.

OpenIssue: PAFM and PC must work together on defining the concept of severity in the model.

OpenIssue: PAFM and PC must work together on defining the concept of severity in the model.

administrative_outcome_txt ::

Type of further action, if any, planned as part of the care of the patient (e.g., appointment given, appointment to be given, admission arranged, patient admitted, . . .).

birth_encounter_ind ::

A indication that the person is a newborn baby.

|PV2^36^00737^Newborn Baby Indicator|

cancellation_reason_cd ::

A code depicting the reason for cancellation of an encounter.

OpenIssue: Need example values.

classification_cd ::

A code categorizing the encounter at a high level (e.g. inpatient, outpatient, emergency).

OpenIssue: Current x-ref is from Patient Type and Patient Class. Should this be two attributes?

|FT1^18^00148^Patient Type| |PV1^18^00148^Patient Type|

desc ::

A textual description of the patient encounter.

|PV2^12^00713^Visit Description|

discharge_location_id ::

An identifier assigned to the discharge location.

|PV1^37^00167^Discharged to Location|

encounter_classification_cd ::

A code to further categorize the encounter based on site-specific needs (e.g. teaching case, cancer study case).

expected_discharge_disp_cd ::

A code depicting the expected disposition of the patient at the time of discharge (e.g., discharged to home, expired, against medical adfice, etc.). This attribute and the actual_discharge_disposition_cd attribute use the same table of values.

Rationale: Clarification of definition

|PV2^27^00728^Expected Discharge Disposition|

expected_insurance_plan_qty ::

A count of the number of insurance plans that may provide Healthcare benefit coverage for this patient encounter.

|PV2^20^00721^Expected Number of Insurance Plans|

first_similar_illness_dttm ::

The date the patient first experienced a similar illness. Used to determine pre-existing conditions

|PV2^29^00730^First Similar Illness Date|

follow_up_type_cd ::

A code indicating the type of follow-up required after completion of the patient encounter.

OpenIssue: Need example values.

id :: II

A unique identifier assigned to the patient encounter.

|PV1^19^00149^Visit Number| |PV1^50^00180^Alternate Visit ID|

medical_service_cd ::

A type of medical management area in which care is scheduled to be delivered.

OpenIssue: This may need to be a repeating field with a type code to differentiate the entries to clarify scheduled, actual, administrative, etc. Clarify how this code is relevant to purpose_cd.

patient_valuables_desc ::

Text describing the patient valuables left for safe keeping.

|PV2^5^00185^Patient Valuables|

pre_admit_test_ind ::

An indication that pre-admission tests are required for this patient encounter.

|PV1^12^00142^Preadmit Test Indicator|

publicity_constraint_cd ::

A code indicating the level of publicity allowed for external release about a patient encounter. Examples are general acknowledgement, limited acknowledgement, no acknowledgement. This attribute applies to administrative information.

|PV2^21^00722^Visit Publicity Code|

purpose_cd ::

A code depicting the purpose of the patient encounter.

OpenIssue: Need example values.

readmission_ind ::

An indication that the inpatient encounter is a readmission.

|PV1^13^00143^Readmission Indicator|

reason_cd ::

A code depicting the type of referral associated with this patient encounter.

OpenIssue: Need example values.

|PV2^3^00183^Admit Reason|

referral_cd ::

A code depicting the type of referral associated with this inpatient encounter.

OpenIssue: Need example values.

source_cd ::

A code indicating the source category associated with this patient encounter.

OpenIssue: Need to clarify description and add example values.

|PV1^14^00144^Admit Source|

special_courtesies_cd ::

A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, VIP courtesies.

|PV1^22^00152^Courtesy Code|

status_cd ::

A code depicting the states of the patient encounter (e.g. scheduled, active, discharged).

|PV2^24^00725^Patient Status Code|

triage_classification_cd ::

The triage classification of the patient during an encounter.

Rationale: This attribute is related to an encounter rather than to the patient in general

urgency_cd ::

A code depicting the urgency of the patient encounter (elective, urgent, emergency).

ExRef: UB92 FL 19

|PV1^4^00134^Admission Type| |PV2^25^00726^Visit Priority Code|

valuables_location_desc ::

Descriptive text identifying where valuables of patient is located.

|PV2^6^00186^Patient Valuables Location|

Association definitions for: Patient_encounter

involves (1,1) :: Patient :: is_involved_in (0,n)

is_scheduled_by (0,1) :: Appointment :: schedules (0,1)

OpenIssue: This may have to be changed after we figure out what tis "encounter" thing really is.

involves (1,1) :: Patient_provider_association :: is_involved_in (0,n)

OpenIssue: Committee should consider instead adding an association between Patient_encounter and Healthcare_service_provider. Can we find a way to collapse this from 3 to 2 classes.

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

OpenIssue: Association naming is very broad: "has assigned to" does not say what this assignment means.

has (0,n) :: Administrative_patient_accident :: is_present_in (1,n)

Rationale: Allows removal of generalization (patient_clinical_item) with single specialization

follows (0,n) :: Patient_encounter :: precedes (0,1)

is_authorized_by (0,1) :: Preauthorization :: authorizes (1,n)

has_as_participant (1,n) :: Encounter_practitioner :: is_associated_with (1,1)

has (1,n) :: Location_encounter_role :: pertains_to (1,1)

utilizes (0,n) :: Transportation :: is_utilized_during (1,1)

OpenIssue: This may not work properly with just the one association to cover both arrival and departure; the committee must examine other options such as more than one association, or a coding solution in the universal service id or some other mechanism to fix this problem.

has (0,n) :: Risk_management_incident :: pertains_to (1,1)

precedes (0,1) :: Patient_encounter :: follows (0,n)

Whole-part definitions for: Patient_encounter

has_parts (0,n) :: Administrative_birth_event :: is_part_of (1,1)

is_part_of (1,1) :: Episode_of_care :: has_parts (1,n)

This association should not be instantiated if the alternate association to condition mode is instantiated.

Rationale: This association serves the queries "give me encounters which deal with this episode."

OpenIssue: Are we certain that a Patient_encounter can be part of only one Episode of Care? And does an Episode_of_care have to have at least one Patient_encounter, or is this optional?