This chapter defines several trigger events used to communicate scheduling information between applications. In addition, it also defines, suggests, or allows for several statuses that scheduled activities may hold, several reasons a scheduled activity may occur, and several types of scheduled activities. The distinction between these four concepts is important for understanding the information in this chapter.
The trigger events for this chapter are defined in Section 10.2, "PLACER APPLICATION REQUESTS AND TRIGGER EVENTS, " 10.3, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED," and 10.4, "QUERY TRANSACTIONS AND TRIGGER EVENTS." Traditionally, trigger events define the transition of some entity from one state to another. [ HL7 trigger events are not strictly limited to this definition; however, most trigger events do define state transitions.] Typical trigger events may be listed as follows: new, cancel, modify, discontinue, reschedule, and delete.
The status of a scheduled activity describes where that activity is in its life cycle. A status differs from a trigger event in an important way: a status describes the current condition of an entity, whereas a trigger event is generated to "move" the entity from one state to another. All status fields in this chapter are defined with respect to the application acting in the role of a filler, unless otherwise (and specifically) indicated. Therefore, a status in a scheduling interface transaction is only truly meaningful if the transaction was generated by the application assigning or maintaining that status.
Typical statuses for a schedule transaction might include the following: pending, wait-listed, confirmed, canceled, discontinued, deleted, started, completed, overbooked (booked for a resource along with another conflicting appointment), blocked, etc.
This chapter defines two kinds of reasons used with transactions. The first is an appointment reason that indicates why the appointment is being bookedand ultimately why the activity is going to occur. The second is an event reason that describes why a particular trigger event has been generated. Reasons tend to be static, whereas statuses tend to change. In contrast, trigger events describe an action to be performed.
Appointment reasons tend to be relatively static for the life of the scheduled activity. Typical examples of appointment reasons include the following: routine, walk-in, check-up, follow-up, emergency, etc.
Event reasons are static as well, but only for the life of a particular trigger event. Typical examples of event reasons include the following: no-show (e.g., when an appointment is canceled), at patient request, at caregiver request, etc.
Rather than describing why an appointment has been scheduledas the appointment reason doesthe appointment type describes the kind of appointment recorded in the schedule. This information tends to be administrative in nature. Typical appointment types might include: normal, tentative (or "penciled in"), STAT, etc.