How to get “add to calendar” wrong

Back before the Internet happened, the way that a patient interacted with his or her primary care physician was, well, who can remember?  It was so long ago.  I guess it was mostly telephone calls, postal mail, and the occasional in-person visit.  Nowadays for most of us, the chief mode of interaction is the “patient portal”.   Recently my health insurance changed, and so I found myself interacting with a new (new to me) patient portal.  Whoever designed this particular portal made a dumb mistake in the programming of its “add to calendar” function.  The result was that when I showed up on time to my first get-acquainted appointment with my new primary care physician, I was told that I was an hour late and had missed my appointment.  I will describe the programming mistake. 

One of the functions of a patient portal is scheduling of appointments.  Once a patient has scheduled an appointment, it might be convenient for the patient to be able to add the appointment to the patient’s personal calendar.  As it turns out, there is a standard way to do this, called the iCalendar standard (Wikipedia article).  The idea is that a first system can provide a data file formatted in a particular way to a second system, and the calendar event is communicated in an unambiguous way.  Such data files typically have file names ending with “.ics”.  The internal format of such files is defined in RFC 5545, which is the the Internet standard for calendar data exchange.

In the beginning of March I had booked a doctor appointment for the beginning of April.   Shortly after booking the appointment, I logged in at this new (new to me) patient portal which is branded with the name of the medical center where my primary care physician is located.  But of course the medical center did not do the system design and computer programming to create the patient portal.  The medical center did what any doctor’s office will do, namely they outsourced the patient portal function to one of the many competing providers of patient portal services.  As I learned while clicking around in the patient portal, it is called FollowMyHealth and it comes from a company called Allscripts Healthcare.

Let’s remind ourselves how helpful an “add to calendar” function can be.  When I book an airplane trip, it is handy to add the itinerary to my calendar.  Of course the departure time and arrival time might be in different time zones.  The way to avoid getting something like that wrong is, of course, to store the information in some way that is guaranteed to be unambiguous.  The correct answer, as defined in RFC 5545, is to store the departure and arrival times in Zulu time (also known as Coordinated Universal Time or, for old-timers like me, Greenwich Mean Time).  The idea is that if the calendar then happens to be rendered in some particular time zone, the time of the event (such as the flight departure or the flight arrival) will be rendered according to that time zone.  This will generally be some offset number of hours, and of course the amount of the offset may further be a function of pesky things like Daylight Saving Time.

The “guaranteed to be unambiguous” aspect will benefit from a bit of emphasis.  Suppose I am going to be teaching a webinar.   Common sense tells us that the attendees will almost certainly not all be in the exact same time zone as the time zone where I am located.  Indeed for my recent series of fifteen webinars in which I gave advanced training on the Patent Cooperation Treaty, the attendees were from 84 countries across six continents.  Some of the webinars were before March 13, 2022 (which is when most of the US made a DST change) and some were after that date.  The only conceivable way to communicate the starting time of such fifteen webinars unambiguously was to specify the starting time for each of the fifteen webinars in Zulu time.  It would then be up to each attendee to work out for himself or herself what that Zulu time means in his or her own local time zone, and for each date that we are talking about.  Many of my attendees were in places where March 13, 2022 meant nothing because they were in places where either there is no such thing as DST, or if there is, the DST change happens on some other date.  (In most of Europe, for example, the DST change happened on March 27, 2022.)  Of course for most attendees, the “add to calendar” function made this computation simple and seamless.

Which brings us back around to the dumb mistake made by somebody at Allscripts Healthcare.

It was on around March 3, 2022 that I was logged in at this FollowMyHealth patient portal, and in the portal I was able to see my doctor appointment which was scheduled for April 1, 2022.   I was also able to see an “add to calendar” icon.  So I clicked on the “add to calendar” icon.  As I expected, what happened next is that the portal generated an “.ics” file and it downloaded the “.ics” file to my computer.  I then did a couple of mouse clicks to add that event to my Google Calendar.  Here is an excerpt from the actual “.ics” file that I am talking about:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//jardogs/followmyhealth//EN
BEGIN:VEVENT
UID:nnn@followmyhealth.com
STATUS:CONFIRMED
TRANSP:OPAQUE
SUMMARY:Appointment with nnn
DESCRIPTION:Patient: Carl Oppedahl\nProvider: nnn\nDepartment: nnn\nDownloaded from FollowMyHealth®
DTSTART:20220401T160000Z
DURATION:P0DT0H30M0S
LOCATION:nnn
END:VEVENT
END:VCALENDAR

(emphasis added.)  The alert reader will have long ago figured out where I am going with this.  But let’s just go through it step by step.

First let’s decode the time-of-day portion of this calendar event.  The time of day starts with “T” and continues with 160000Z which in plain language means 4PM at the Greenwich Observatory in England.  

Now we start doing some math.  If it is 4PM in England, what time is it in Colorado (which is where my doctor’s office is located)?  It turns out that this is a trick question.  To answer this question, it is necessary to know what day of the year we are talking about.  And now we can see the stupid programming mistake that the people at Allscripts Healthcare made.  

On the day that I clicked this “add to calendar” icon, 4PM in England was the same as 9AM in Colorado.  And on the day that the doctor’s assistant booked the appointment (which was during a telephone call the previous day), 4PM in England was the same as 9AM in Colorado.

But the date of the doctor appointment was … you can see in bold-face font in the “.ics” file … April 1, 2022.  On April 1, 2022, if it is 4 PM in England, that is the same as 10 AM in Colorado.

Yes, now we remind ourselves that March 13, 2022 was the date of a DST change for most of the US, including Colorado.

On the date that I showed up at the doctor’s office for my “get acquainted” appointment, 1600 Zulu was the same as 10 AM.

It is also true that on the day that I booked my appointment by telephone, 1600 Zulu was the same as 9AM in Colorado.  It is also true that on the day that I clicked on the “add to calendar” icon, 1600 Zulu was the same as 9AM in Colorado.  But those facts about what 1600 Zulu meant on those days did not mean anything at all.  I imagine the patient portal system, from the doctor’s user interface point of view, probably continued to list the appointment as 9AM even after the DST change that happened on March 13.  

I frankly do not recall exactly what time of day was agreed upon during the telephone call at the beginning of March.  As I look back on these events, I am guessing it must have been 9AM.  What is quite clear, however, is that shortly after booking the appointment, I clicked the “add to calendar” icon and added the appointment to my Google calendar and it simply stored the 1600 Zulu time for April 1, 2022.  And I then relied on the 1600 Zulu time thereafter and for many weeks I was simply keeping close track of my upcoming 10AM appointment.

Prompted by my digging around to write this blog article, I went back and checked, and I do see in my spam folder a couple of email reminders telling me about a 9AM appointment.  So it seems clear that the appointment did get stored in the doctor’s system as a 9AM appointment on April 1, despite the “.ics” file specifying 1600 Zulu on April 1 which is without a doubt the same thing as 10 AM.

FollowMyHealth is a registered trademark with a claimed date of first use in 2001.  That is more than 20 year ago.  How can it possibly be that over the course of this period of more than 20 years, I am the only person to have shown up an hour late for a doctor appointment in the face of this programming mistake by Allscripts Healthcare?

Part of the answer is that Allscripts Healthcare could not have made this mistake in 2001.  The Internet standard for “.ics” files only goes back to 2009.  So the earliest that they could have gotten the idea of providing an “add to calendar” icon, along with making this programming mistake, was in 2009.

Another part of the answer is that this problem only smacks the user in the face if the appointment gets booked prior to a “spring forward” DST change (or maybe if the “add to calendar” icon gets clicked prior to that change) and if the appointment itself is for a date that falls after the DST change.  The vast majority of instances of somebody clicking the icon and the appointment date will be at other times of year when there is no spring DST change happening to fall between the two events.

Another part of the answer must surely be that most patients do not actually use the “add to calendar” function as such.  Instead, they enter the appointment manually into their phone or computer.  Or they hand-write it into a calendar.  

Still another part of the answer must be that some patients, even if they were “this close” to getting stung by the programming blunder made by Allscripts Healthcare because they did use the “add to calendar” function and did happen to use it shortly before a springtime DST change (as I did), and had an appointment after the DST change (as I did), would have been saved from getting stung by email reminders that did not get sent to a spam folder (as my two reminders did).

The alert reader will already have appreciated that the same kind of thing could go wrong with events happening around the fall DST change, but then the result would be a patient being told that he or she had arrived an hour early for a doctor appointment rather than being told that he or she had arrived an hour late.  

What needs to happen is that the Allscripts Healthcare company needs to fix this mistake.  When the “add to calendar” code is being executed, the code needs to pay attention to the date of the appointment.  The time zone offset where the doctor’s office is located that will be in effect on the date of the appointment needs to be taken into account when calculating the Zulu time to insert into the “.ics” file that is being constructed.  It is a mistake to use the Zulu time together with the time zone offset that happens to be in effect at the doctor’s office on the day that the “add to calendar” icon is being clicked or that happened to be in effect on the day that the appointment was booked.

In just a few weeks of use, I have already bumped into at least six ways that the FollowMyHealth patient portal system falls very far short when compared with other patient portal systems that I have used in the past.  This particular blunder in the programming of the “add to calendar” function is merely the most egregious problem among the half a dozen problems that I have encountered thus far in my first few weeks on this poor quality portal.  It would take quite a lot of work by the Allscripts Healthcare people to bring their FollowMyHealth portal up to what I think of as an average standard of quality and feature mix for a patient portal, from the patient perspective.

Does your doctor’s office use the FollowMyHealth patient portal system?  Please post a comment below.