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 Response

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

  Rene - well, a Tracker has very little responsabilities, but this could be subject of discussion. Application Roles are not even normative, so in order to solve the use-case a new AR won't have any impact.

• appears to be a disconnect on what the RMIM payload should be - either a subset or the full appointment RMIM

  Rene - this use-case doesn't require the full R-MIM, but one could envision related scenarios where it would be useful to have the full information. Re-use of an existing R-MIM will probably be easier both from a standards development as well as an implementation perspective.

• 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.

  Rene - I beg to differ .. (A) AFAIK there are only 3 trigger event categories: status change, interaction based, user based. Time-based is one of the examples of a user based trigger event, which is why that (user based) is used in this proposal. (B) Bothe S27 as wll as this new use-case require the time-based sending of notifcations to a receiver. Whether batch or not doesn't matter that much.

• WG believes that should be "time-based" and not user based as suggested in the Proposed Changes

  Rene - see above

• 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.