This storyboard demonstrates the basic flow of a short stay encounter from scheduled, through active, to completed.

Exceptional events are described in other storyboards.

• Canceling a scheduled short stay encounter is covered in Cancel Short Stay Encounter Appointment.
• Abnormal termination of an active short stay encounter is covered in Abort Short Stay Encounter.
• Nullifying an erroneously reported short stay encounter is covered in Nullify Short Stay Encounter.

Interaction List

Short Stay Encounter Appointment Scheduled	PRPA_IN415001UV02
Short Stay Encounter Appointment Revised	PRPA_IN415002UV02
Short Stay Encounter Started	PRPA_IN405001UV02
Short Stay Encounter Revised	PRPA_IN405002UV02
Short Stay Encounter Completed	PRPA_IN405003UV02
Short Stay Encounter Revised	PRPA_IN405002UV02

This storyboard demonstrates canceling a short stay encounter appointment.

This storyboard demonstrates abnormal termination of a short stay encounter.

Interaction List

Short Stay Encounter Aborted

PRPA_IN405004UV02

This storyboard demonstrates nullifying an erroneously reported short stay encounter.

Interaction List

Short Stay Encounter Nullified

PRPA_IN405006UV02

A Short Stay Encounter Appointment Revision Informer sends appointment activate and revise notifications. Additional appointment notifications such as reschedule and cancel are sent by the Appointment Informer application role.

A Short Stay Encounter Appointment Revision Tracker receives appointment activation and revision notification messages. Additonal appointment notifications such as rescheduled and canceled are received by the Appointment Tracker application role.

A Short Stay Encounter Comprehensive Informer sends all notification messages for short stay encounters in the event mood.

A Short Stay Encounter Comprehensive Tracker receives all notification messages for short stay encounters in the event mood.

This trigger event signals that an appointment for a short stay encounter was scheduled.

This trigger event signals that an appointment for a short stay encounter was revised before the appointment began.

The Active Short Stay Encounter Appointment R-MIM defines the message used in notifications about active short stay encounter appointments. It is used by both "activate" and "revise" notifications. Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.

Encounter Attributes

The focal class (and entry point) is the EncounterAppointment class. The attributes of encounter appointment are:

• id - the unique identifier for this encounter appointment

• code = SS, says that is an appointment for an short stay encounter

• statusCode = "active"

• effectiveTime - the anticipated start and (optional) end time for the scheduled encounter

• priorityCode - the urgency for the scheduled encounter

• confidentialityCode - a set of codes that control the disclosure of information about this scheduled patient encounter

• reasonCode - a set of values specifying the administrative reasons for the encounter appointment. Examples are "Medical Necessity", "Patient's Request" and "Dependency". Medical reasons for the encounter are specified as associated diagnoses sent in A_ObservationDx CMET via the pertinentInformation act relationship described below.

• admissionReferralSourceCode - a code used to categorize the type of place or organization responsible for the patient immediately prior to their scheduled encounter; for example, in the United States, this is identified in UB-92 Form Locator 20, Source of Adm(ission). Detailed information about the admitted-from place or type of place is conveyed through the arrivedBy act relationship to the TransportationAppointment (see below).

• lengthOfStayQuantity - expresses the expected quantity of time for the scheduled encounter

• preAdmitTestInd - indicates whether tests are required prior to this encounter. The encounter(s) for the pre-admit tests can be related to this scheduled encounter with the reason act relationship (see below).

• specialCourtesiesCode - a set of values specifying special courtesies to be extended to the patient (e.g., no courtesies, extended courtesies, professional courtesy, VIP courtesies).

• specialArrangementCode - a set of values representing the types of special arrangements to be provided for this patient encounter (e.g., wheelchair, stretcher, interpreter, attendant, seeing eye dog).

Links to Encounters

An encounter appointment can be the reason for another encounter (either event or appointment) for tests. The focal encounter appointment (target) is the reason for the pre-admission encounter (source).

Links to Other Acts

Encounter appointments can link to other acts:

• AccommodationAppointment: the patient's assigned location at the beginning of the encounter, ServiceDeliveryLocation, may be linked to one or more AccommodationAppointment acts via a locationOf participation. A patient may request or need a specific accommodation such as ward, private, or semi-private accommodations for (a part of) the encounter. The AccommodationAppointment.reasonCode tells if the accommodation is a medical necessity or the result of a patient request.

• TransportationIntent: the patient's expected arrival at the encounter site can be linked to the encounter via an arrivedBy: act relationship. The patient's mode of arrival is defined by a value from the ActPatientTransportationType domain sent in the TransportationIntent.code attribute, the admitted-from location in a R_LocationLocatedEntity CMET, and the time the patient is expected to arrive at the encounter site as the end of the TransportationAppointment.effectiveTime range.

• A_AccountGuarantor: the scheduled encounter can be linked to one or more patient accounts. Each account is sent in a separate A_AccountGuarantor CMET.

• A_ObservationDx: the scheduled encounter can be linked to one or more admission diagnoses . Each diagnosis is sent in a separate A_ObservationDx CMET. Multiple admission diagnoses can be rank ordered using the pertinentInformation.priorityNumber.

• A_Consent: the scheduled encounter can be linked to one or more consents granted by the patient or the patient's representative. Each consent is sent in a separate A_Consent CMET. Note, this s currently a placeholder CMET until the Medical Records TC completes work on medico-legal document modeling.

Direct Participations in the Scheduled Encounter

A number of entities play roles that participate directly in the scheduled encounter:

• admitter: the healthcare practitioner that required/authorized the scheduled encounter

• responsibleParty: a healthcare provider organization that will hold clinical responsibility for the patient at the start of the scheduled encounter

• location: the patient's assigned location at the start of the scheduled encounter

• performer: practitioner(s) who will principally carry out the actions in the scheduled encounter

• subject: the patient who is the subject of the scheduled encounter

• referrer: the healthcare practitioner who requested the scheduled encounter to take place

• consultant: an advisor who will participate in the scheduled encounter by performing evaluations and making recommendations

• attender: the healthcare practitioner who will have responsibility for overseeing the patient's care at the start of the scheduled encounter

• notificationContact: the patient's designated Emergency Contact for this scheduled encounter

The Active Short Stay Encounter R-MIM defines the message used to report that a new short stay encounter has started.

ShortStayEncounterEvent

This information model is for short stay patient encounters in the active state. In a short stay patient encounter the patient is admitted to a health care facility for treatment for a predetermined length of time, usually less than 24 hours.

The statusCode ("active"), and code ("SS") should be considered fixed. Status changes are communicated using the provided trigger events and a change in encounter type requires completing the existing encounter and activating a new encounter of the appropriate type.

In an active encounter the following, if valued, should be interpreted as anticipated values: the end of the effectiveTime interval, the end of the activityTime interval, the lengthOfStayQuantity, and the dischargeDispositionCode.

Descriptions for all the attributes in this and the other classes in this model can be found in the HMD and Message Type table views.

Links to Other Encounters/Care Events

Encounters can relate to other encounters in three ways:

• reasonOf: this can link the focal encounter (target) to one or more pre-admission patient encounters for tests (source). Note that the preAdmitTestInd for the focal encounter should also be set to "true".

• sequelTo: this can link the focal encounter (source) to a previous encounter (target) for the same patient. Examples include: (1) a patient in an ambulatory encounter is admitted as an inpatient after an evaluation of the seriousness of the patient's condition, (2) an inpatient is discharged from an inpatient encounter directly to an ambulatory encounter as part of the same episode of care, (3) a patient is re-admitted to a healthcare facility.

• componentOf: this can link the focal encounter (target) to a care event (source) of which it is a component. The care event represents someone (generally a health care practitioner) taking responsibility for some aspect of a patient's health; examples include primary/preferred care provider, case manager. Since Patient Encounter is a specialization of Care Encounter, the care event could also be another encounter.

Links to Other Acts

Encounters can link to other acts:

• AccommodationEvent: the patient's assigned location during an encounter, ServiceDeliveryLocation, can be linked to one or more AccommodationEvent acts via a locationOf participation. A patient may request or need a specific accommodation such as ward, private, or semi-private accommodations for (a part of) the encounter. The AccommodationEvent.reasonCode tells if the accommodation is a medical necessity or the result of a patient request.

• TransportationEvent (arrivedBy): describes the patient's arrival at the encounter site. The patient's mode of arrival can be sent as TransportationEvent.code, the admitted-from location in an origin type location participation of R_LocationLocatedEntity CMET, locations transited on the way to the encounter site as via type location participations, and the time patient arrived at the encounter site as the end of theTransportationEvent.effectiveTime interval. Both the performer (person who transported the patient) and an escort can be sent in R_AssignedPerson [contact] CMETs. The name of a transportation service can be sent as the name of the Organization scoping the AssignedPerson role.

• TransportationIntent (departedBy): describes the patient's anticipated departure from the encounter site at the end of the encounter. The patient's mode of departure can be sent as TransportationIntent.code, the discharged-to location in an destination type location participation of R_LocationLocatedEntity CMET, locations expected to be transited as via type location participations, the time the patient is expected to depart from the encounter site as the start of theTransportationIntent.effectiveTime interval. Both the expected performer (person who will transport the patient) and an escort can be sent in R_AssignedPerson [contact] CMETs. The name of a transportation service can be sent as the name of the Organization scoping the AssignedPerson role.

• A_Appointment (inFulfillmentOf): the focal encounter can be linked to the appointment that scheduled it. The scheduled encounter and the actual encounter should have the same value for type in Encounter.code. Activation of the encounter event implicitly changes the status code of the appointment to completed.

• A_AccountGuarantor (reference): the encounter can be linked to one or more patient accounts. Each account is sent in a separate A_AccountGuarantor CMET.

• A_ObservationDx (reason): the encounter can be linked to one or more diagnoses. Each diagnosis is sent in a separate A_ObservationDx CMET. The encounter "activate" interaction would send an admission diagnosis (Observation.code of "ADMX" in the A_ObservationDx CMET). Multiple admission diagnoses can be rank ordered using the reason.priorityNumber.

• A_Consent (authorization): the encounter can be linked to one or more consents granted by the patient or patient's representative. Each consent is sent in a separate A_Consent CMET. Note, this is currently a placeholder CMET until the Medical Records TC completes work on medico-legal document modeling.

• ValuablesLocation (sourceOf): the encounter can be linked to one or more reports of patient valuables stored during the encounter. Each report is sent as a free text observation of the valuables and where they are stored during the encounter.

Direct Participations in the Encounter

A number of entities play roles that participate directly in the encounter:

• admitter: the healthcare practitioner that required/authorized the encounter, usually in the case of an inpatient encounter. Note: the admitter here must be the same as the author reported in the HL7 Trigger Event Control Act for the admission.

• responsibleParty: the healthcare provider organization that holds clinical responsibility for care of the patient during the encounter. The encounter "activate" interaction activates the initial responsibleParty participation.

• location: the patient's assigned location during the encounter. The encounter "activate" interaction activates the initial active location participation and, optionally, one or more pending location participations. ServiceDeliveryLocation is a role played by a place at which services may be provided. A service delivery location may be either an incidental service delivery location (a place at which services may be provided without prior designation or authorization) or a dedicated service delivery location (a place that is intended to house the provision of services). Dedicated service delivery locations can be further characterized as either clinical (DedicatedClinicalLocationRoleType) or non-clinical (DedicatedNonClinicalLocationRoleType).

• subject: the patient who is the subject of the encounter.

• referrer: the healthcare practitioner who requested the encounter to take place.

• consultant: an advisor participating in the encounter by performing evaluations and making recommendations.

• attender: the healthcare practitioner who has responsibility for overseeing a patient's care during the patient encounter. The encounter "activate" interaction activates the initial attender participation. If the encounter has more than one active attender then the sequenceNumber attribute should be valued.

• notificationContact: the patient's designated Emergency Contact for this encounter.

The Revised Short Stay Encounter R-MIM defines the message used to report that information about a short stay encounter has changed. The short stay encounter can be either active or completed.

Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.

Differences

The Revised Short Stay Encounter R-MIM differs from the Active Short Stay Encounter R-MIM in the following ways:

• The ShortStayEncounterEvent.statusCode attribute can be any value from the ActStatusNormal value set.
• The departedBy Transportation act can be in either intent or event mood.
• The discharger participation is added to the model since the model applies to active and completed encounters.

The Aborted Short Stay Encounter R-MIM defines the message used to report a short stay encounter was aborted prior to normal completion.

The Aborted Short Stay Encounter R-MIM includes only the encounter attributes and associations that can be changed by aborting an encounter. The reason the encounter was aborted is conveyed in the Trigger Event Control Act portion of the HL7 composite message. The reasonCode attribute of the ControlActProcess conveys a simple, coded reason. More comprehensive information about why the encounter was aborted may be conveyed in a A_DetectedIssue CMET associated with the ControlActProcess via a reasonOf act relationship.

Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.

• The ShortStayEncounterEvent.statusCode is set to "aborted".
• The ShortStayEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
• The ShortStayEncounterEvent.activityTime is more likely to contain a value.
• The ShortStayEncounterEvent.lengthOfStayQuantity, if valued, contains the actual, calculated quantity (the actual days quantity cannot be simply calculated from the admission and discharge dates because of possible leaves of absence) instead of the expected length of stay.
• The ShortStayEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
• The departedBy act relationship links ShortStayEncounterEvent to TransportationEvent.
• The patient's notificationContact is included to permit sending the emergency contact who was notified when the encounter was aborted.

The Completed Short Stay Encounter R-MIM defines the message used to report that a short stay encounter has ended normally.

Descriptions for all classes, attributes and associations in this model can be found in the HMD and Message Type table views.

The Completed Short Stay Encounter R-MIM includes only the encounter attributes and associations that can be changed by encounter completion:

• The ShortStayEncounterEvent.statusCode is set to "completed".
• The ShortStayEncounterEvent.effectiveTime contains actual values for both start and end date-times instead of an anticipated end date-time.
• The ShortStayEncounterEvent.activityTime is more likely to contain a value.
• The ShortStayEncounterEvent.lengthOfStayQuantity, if valued, contains the actual, calculated quantity (the actual days quantity cannot be simply calculated from the admission and discharge dates because of possible leaves of absence) instead of the expected length of stay.
• The ShortStayEncounterEvent.dischargeDispositionCode, if valued, contains the actual discharge disposition instead of the expected discharge disposition.
• The departedBy act relationship links ShortStayEncounterEvent to TransportationEvent.
• There is a discharger participation in ShortStayEncounterEvent. The discharger is the healthcare practitioner that required/authorized the ending of an encounter.
• The reason act relationship can convey one or more discharge diagnoses. Each diagnosis is sent in a separate A_ObservationDx CMET. The reason.priorityNumber specifies rank order if more than one discharge diagnosis is sent. Note that reason refers to the reason for the encounter itself, not the reason for the discharge; that reason would be conveyed in the Trigger Event Control Act.

This HMD defines notification messages about active short stay encounter appointments.

Base Hierarchical Message Description   

Message Type List

Active Short Stay Encounter Appointment

PRPA_MT415001UV02

Description 

This notification occurs after a previously reported Short Stay Encounter Started notification interaction is nullified. Note that the payload is the Act Generic Status - Event message type from the Shared Messages domain.