Patient Appointment Reminders

Summary

This is a proposal to support a Norwegian use-case for patient appointment reminders to be sent via for example 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.

From a technical perspective the communication is from a Scheduling system to a gateway, a gateway which has processing rules as to when it should use SMS/text , or e-mail, or other delivery method.

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, WGM September 2011

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.

  • PA discussion: add Patient Appointment Informer, Patient Appointment Tracker
• 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.

  • PA discussion: full R-MIM. Statuscode will always be 'active', this will have to be documented in the storyboard and the interaction documentation.
• 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) Both the S27 as wll as this new use-case require the time-based sending of notifcations to a receiver. All messages/interactions in HL7 are point-to-point, there is no support in HL7 for 'broadcast'.

  • ACTION: to add this use-case to the description op S27
• 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.

MOTION: to approve the proposal, and request that those that brought the proposal forward create pubication ready artefacts, to be sent to PA before November 1st, with the intent to include it into the january 2012 DSTU. (9-0-0)

Publication material

Storyboad

add one new storyboards:

Narrative Storyboard #1

Every afternoon the booking system has a scheduled task (Appointment Reminder Scheduled Notification (PRSC_TExxxxxUV01)) that scans through next day’s appointments with the purpose of sending each patient a notification about the appointments that are scheduled next day. All patients that have agreed that they can receive information from the hospital will receive this notification. The format they receive the notification in can be either SMS (text message) or e-mail. The preference of an individual patient is known to the booking system.

Application Roles

add two new application roles:

1. Patient Appointment Informer (PRSC_ARaaaaaaUV01)

• • In this role, the application notifies a patient tracking system that an appointment is scheduled to happen soon.

1. Patient Appointment Tracker (PRSC_ARbbbbbbUV01)

• • In this role the application is only a receiver of a notification of an appointment that is going to happen soon . The application might forward information to a receiver (the subject) in a format that that the subject has specified (e.g. SMS).

Trigger event

One new trigger events:

• Appointment Reminder Scheduled Notification (PRSC_TExxxxxUV01)
  • Type: Time Based (User Based)

Interactions

new interaction

• Appointment Reminder Notification (PRSC_INzzzzzzUV01)
  • The payload model will be equal to the full appointment R-MIM (PRSC_RM01000UV)
  • The status code will always be active

Navigation

• Return to PA Main Page

© 2011 Health Level Seven® International. All rights reserved.