This week, I decided to add some functionality to the web application that I use to run my office. The ability already existed to pass a date or frequency for the next visit to the scheduling staff but the option to include what type of appointment was lacking. The system would just gather the default appointment type for the particular client and apply it. But there were times when it was necessary to schedule for a different type of appointment or to change the type of appointment if a next appointment already existed. I thought this would be pretty simple because the root functionality already existed. I was wrong.
First, the variable that was being passed was a simple string and because I wanted to piggy-back on that I decided that I would just take that string and convert it into a comma-separated string that could be split, when needed, into the individual components of the scheduling detail - the date or frequency and the type.
A little background on the path that this variable takes would add a little more context here:
At the notes screen, there existed the way to indicate when the next appointment should happen. From here, it would pass through:
- the notes form handler, to
- the checkout verification handler, to
- the posting screen (where charges are entered), to
- the scheduling screen where the scheduling was performed.
The first, most quickest way to see if the changes I wanted to make would break the system was to just add the new variable and send it through the path and see what would happen.
At the first stop the "notes form handler", there had to be significant modification because the form handler didn't really know what to do with the new field because it's job is to combine specific form elements into fields. Since this variable had no previous assignment, it followed the default logic to be combined into the notes, which was not where I needed it to land. Logic had to be written to take the new variable (appt type) and combine it with the existing variable (appt date) and separate them with comma's (as 'appt_date, appt_type'), now to be referred to as "CSV" and pass them along as a single field. This portion of the alteration is complete. The form handler performs as it needs to.
The next step, the "checkout verification handler" which reviews a TON of information ... not necessary to the discussion here ... before being sent to the scheduling staff, didn't really need any alteration because it already was passing a single field to the next step - the "posting screen".
This is where charges are entered for the date's services as well as other financial configurations, client data management - really the nerve center of the checkout and scheduling process. Breaking it is catastrophic and will result in a barrage of phone calls about what the staff is not able to do. Extensive testing is required for even the smallest change. The posting screen already displays the information differently based on the existence of other future appointments or the absence. Now it had to also display an additional difference if an existing appointment type was different than the provider just directed and sent from the notes. The updated display needed to be able show the type, if the type needed to change and the CSV was split into it's individual values, the date and type. I decided that a "red" accent to the information would be enough to call attention that something needed to change.
From the posting screen, the scheduling staff chooses a "button" and the "scheduling screen" appears, prepopulated with the information provided, as it passed from notes, to handler, to checkout, to posting and now to scheduling (we'll call this the "pipeline"). The existing functionality would automatically choose the appointment type from the client default (which is set by polling the previous appointment type or if a specific type was manually set - but I'm not going into that logic here) and show the available times for the date that was passed - through the pipeline. But now the appointment type was being passed in externally. This meant that the CSV had to be split into its components and the display had to be updated to show the "pipelined" appointment type. If it was the same as the default, then the change is unnoticeable. If it does not match, the display would update as needed and the available times would be populated based on the date and appt type. If there was an existing appointment, then the information from that appointment was loaded (date and current time) so that when the appointment change was made - if necessary (different appointment types have different appointment durations and arrival times) then the appointment could be rescheduled at that point and the existing appointment information would no longer exist. This is critical because if an existing appointment is accidentally duplicated, there WILL be confusion about which one is the accurate one, if any, and which one has the information that the client been given. All of this confusion requires unnecessary (and embarrassing) communication with the client in order to clarify. The idea of the system is to enhance efficiency, not hinder it.
Ultimately, it was successful and a welcome function addition. Now what would have required flow interruption and manual instruction can now be automated and, since part of the existing functionality was already there (and the process was completely there) this was added seamlessly. Of course I watched by remote control for the day to monitor and correct any bugs that occurred. There were only a few and mainly involved the visual display. No underlying function interference occurred. It was a good day. :)
Top comments (0)