This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Patient Appointment Reminders"

From HL7Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by 3 users not shown)
Line 8: Line 8:
  
 
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.
 
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.
 
==Storyboad==
 
The storyboard demonstrates cases where a health provider has decided to send notification to patients reminding them of scheduled appointments that are going to happen soon.
 
The payload for this reminder will be the to the full appointment R-MIM (PRSC_RM01000UV) with status code “active”.
 
 
 
  
 
==Proposes Changes==
 
==Proposes Changes==
Line 44: Line 38:
 
MOTION: to approve the proposal, and request that those that brought the proposal forward create  
 
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)
 
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:
 +
 +
#Patient Appointment Informer (PRSC_ARaaaaaaUV01)
 +
**In this role, the application notifies a patient tracking system that an appointment is scheduled to happen soon.
 +
#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==
 +
 +
* [[Patient_Administration|Return to PA Main Page]]
 +
 +
© 2011 Health Level Seven® International.  All rights reserved.

Latest revision as of 01:38, 21 January 2012

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

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