Patient Appointment Reminders

Summary: this is a proposal to support a Norwegian use-case for patient apointment reminders via SMS, which calls for a "user based trigger" Notification (i.e. a notification that's not status-change based).

Use case

We are about to implement a solution for patient appointment reminders through text messages on mobile phones.

The message is supposed to be sent the day before the actual appointment and is planned to contain the phone number and a short message. The sender will be required, but will not be passed through to the patient.

Proposes Changes

The Appointment Topic in the Scheduling domain has various "Notifications", but none seems to directly fit the above reason for sending it. This is not as much a matter of a new information model, but it would require a new trigger event and a new interaction (with the same RMIM as the existing notifications; or maybe just a subset thereof).

Note: A new trigger event S27 was added to version 2.7. Trigger event S27 (in v2) could be used to support the use-case described in this proposal; as such this proposal isn't breaking any new ground.

Proposed changes:

1. Add a new (user based) trigger event (and interaction) to the Appointment Topic in the Scheduling domain
   • New trigger event Appointment Reminder Notification, Type: user-based (no state change). Description: At a user-defined point in time prior to the appointment the Appointment Informer sends the appointment details to the Appointment Tracker.
   • New interaction: Appointment Reminder Notification, payload: Full Appointment R-MIM.

PAWG

1. • WG agrees that the proposal request for the ability to send an appointment reminder (notification) is a reasonable addition to the Scheduling Domain. However;
   • there appears to be a need for a new application role other than 'Appointment Tracker' with less responsibilities
   • appears to be a disconnect on what the RMIM payload should be - either a subset or the full appointment RMIM
   • trigger event in V2.7 (S27) does not really fit this use case. It is a Broadcast Notification and time based trigger (not a point to point Notification and user based trigger as suggested.
   • WG believes that should be "time-based" and not user based as suggested in the Proposed Changes
   • WG requires clarification and feedback from the submitter on the noted points above. If the submitter wishes this content to be included in the January 2012 DSTU ballot, feedback will need to be received by Friday September 22, 2011. Conference calls will be scheduled to discuss the proposal.