18.6 PLACER APPLICATION REQUESTS AND TRIGGER EVENTS (10.3)

Placer request and filler response transactions are the messages and trigger events used between placer applications and filler applications. The placer application initiates transactions using the SRM message, requesting that the filler application modify its schedule(s) with the given trigger event and information. The filler application responds to these requests, using the SRR message, to either grant or deny the requests from the placer application.

When initiating a request, the placer application will generate and send an SRM message containing all of the information necessary to communicate the desired action to the filler application. All required segments and fields (both explicitly required and conditionally required) should be provided to the filler application, as defined in this chapter. When the filler application receives the transaction, it acknowledges it with the appropriate accept acknowledgment using an ACK message (assuming that the enhanced acknowledgment mode is in use). After processing the request at the application level, the filler acknowledges the transaction with the appropriate application acknowledgment in an SRR message (again assuming that an application acknowledgment was requested under the enhanced acknowledgment mode, or that the original acknowledgment mode is in use). Applying the explanations of the various application acknowledgment codes in the context of this chapter, an application accept from the filler means that the request was processed and accepted by the filler. An application error from the filler means that the request was processed and denied. An application reject from the filler means that the request was not, and could not, be processed due to one or more reasons unrelated to its content (for example: it fails the basic application protocol validation, the filler system is down, or there was an internal error). When appropriate, an SRR message with an application accept acknowledgment will contain further information on the request that was processed.

There are no unsolicited messages initiated from a filler application defined in this set of trigger events. Those messages and trigger events are defined below, in Section 10.4, "FILLER APPLICATION MESSAGES AND TRIGGER EVENTS UNSOLICITED."

All of the trigger events associated with placer request and filler response transactions use a common message definition that follows:

Note that in the abstract message definitions for both the SRM and SRR, the patient information segments (segments PID through DG1) are both optional as a group, and repeating as a group. The optionality allows for transactions that relate to a patient, and for those that do not. The ability to repeat the patient information allows for those transactions in which one activity must be scheduled for multiple patients (e.g., for family or group therapy).

In contrast, a transaction may specify no more than (and no less than) one activity. Note that neither the ARQ segment (in the SRM message) nor the SCH segment (in the SRR message) are allowed to repeat, and that they are required. Neither the optionality nor the ability to repeat patient information allows a transaction to specify more than one activity.

The trigger events that use this message definition are listed below.

18.6.1 Request New Appointment Booking (Event S01) (10.3.1)

A placer application sends a transaction with this trigger event to a filler application to request that a new appointment be booked. If it is successful, the filler application returns an application acknowledgment (if requested under the enhanced acknowledgment mode, or if the original acknowledgment mode is in use). The acknowledegment may optionally contain an SCH segment and related detail segments describing the actual appointment that was booked.

18.6.2 Request Appointment Rescheduling (Event S02) (10.3.2)

A placer application uses this trigger event to request that an existing appointment be rescheduled. The new Requested Start Date and Time, Appointment Duration, Repeating Interval, Repeating Interval Duration, and/or Priority are provided in the ARQ segment, along with the existing placer and filler identification numbers. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the new information for the rescheduled appointment.

This transaction should not be used to reschedule an appointment that has begun but has not been completed. In such cases, and only if it is logical to do so, the appointment should be discontinued and a new schedule request should be submitted. Likewise, this transaction should not be used to reschedule a parent appointment, in which one or more children have begun or have already occurred. Again, the parent appointment should be discontinued, and a new schedule request should be made. This procedure removes any ambiguity between applications that may arise with an attempt to modify an appointment that is in progress.

18.6.3 Request Appointment Modification (Event S03) (10.3.3)

This message transmits a request for modification of an existing appointment to a filler application. This trigger event is used to request the modification of information on an existing appointment, outside of the need to reschedule, cancel, discontinue or delete the appointment, or to add, modify, cancel, discontinue, or delete services and/or resources on the appointment. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the new information for the modified appointment.

18.6.4 Request Appointment Cancellation (Event S04) (10.3.4)

The request appointment cancellation trigger event is sent by the placer application to the filler application to request that an existing appointment be canceled. A cancel event is used to stop a valid appointment from occurring. For example, if a patient scheduled for an exam cancels his/her appointment, then a request to cancel the appointment is sent. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the canceled appointment.

This trigger event can be used to cancel a parent appointment, in which none of the children of the appointment have either begun or have been completed. Any child appointments that exist on the filler and placer applications should be considered canceled. If one or more child appointments have begun or have been completed, then this trigger event should not be used. Instead, the S05 (request appointment discontinuation) event should be used.

18.6.5 Request Appointment Discontinuation (Event S05) (10.3.5)

The request appointment discontinuation is sent by the placer application to the filler application to request that an appointment in progress be stopped, or that the remaining occurrences of a parent appointment not occur as scheduled. If none of the child appointments of a parent appointment have occurred, then a cancel trigger event should be sent instead. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the discontinued appointment.

18.6.6 Request Appointment Deletion (Event S06) (10.3.6)

A request appointment deletion is sent by the placer application to the filler application to request that an appointment that had been entered in error be removed from the system. A delete trigger event should only be used when an appointment has been erroneously requested, and must be removed from the schedule so that it does not affect any statistical processing. A delete trigger event differs from a cancel trigger event in that a delete acts to remove an error, whereas a cancel acts to prevent a valid request from occurring. This trigger event should not be used for any appointment that has already begun, or has already been completed. Likewise, it should not be used on any parent appointment if any child appointments have either begun or been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the deleted appointment.

The delete trigger event should be implemented with careful forethought, as it typically has different effects and repercussions in various applications. In some applications, a delete event cannot be undone. This means that if a delete transaction was sent erroneously, recovery will be difficult or impossible. In other applications, a delete transaction will not result in the physical deletion of the record(s), but will set a status or a flag. In these cases, the filler and/or placer appointment identifiers (the numbers or codes that uniquely identify the scheduled appointment or request to the placer and filler applications) probably cannot be reused. Since these applications maintain a record of deleted appointments, the reuse of an identifier will likely cause a conflict in the applications' processing of transactions.

18.6.7 Request Addition of Service/Resource on Appointment (Event S07) (10.3.7)

The request addition of service/resource is triggered by the placer application to request that a new service or resource be added to an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.

18.6.8 Request Modification of Service/Resource on Appointment (Event S08) (10.3.8)

The request modification of service/resource is triggered on the placer application to request that information pertaining to an existing service or resource be changed for an existing appointment. Services and resources are represented by the AIS, AIG, AIL, and AIP segments on an HL7 scheduling interface transaction. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.

This trigger event should not be used when an existing resource or service must be replaced or rescheduled for an existing appointment. The following fields on the indicated segments should not be changed by this trigger event: the first three fields of the AIS, the first four fields of the AIG, the first four fields of the AIL, and the first four fields of the AIP. Instead, use two trigger events to accomplish the replacement or rescheduling of a service or resource: S09 (request cancellation of service/resource on appointment), as well as S07 (request addition of service/resource on appointment).

18.6.9 Request Cancellation of Service/Resource on Appointment (Event S09) (10.3.9)

This trigger event requests that a service or resource be removed from an existing scheduled appointment that has not yet begun. A cancel event is used to stop a valid service or resource from participating in the appointment. For example, if a portable X-ray machine scheduled for an exam is no longer needed, then the placer application requests that the resource be canceled on the filler application. This trigger event should only be used for appointments that have not been completed, or for parent appointments whose children have not been completed. If it is successful, an application acknowledgment is returned, optionally containing an SCH segment and related detail segments describing the modified appointment.