aethelwulffe wrote on Wednesday, February 08, 2012:
Yeah, prolly too ambitious. That’s why we do these brain-storming things…mostly to get rid of bad ideas than to get new ones. Yes, when just working on a scheduling basis, facilities can be very important, but I think the system (if room restrictions were added) could be useful for SOME applications such as imaging labs, operating rooms and the like, but I imagine clinics are in too much of a flux to crimp by restrictions, and often have more rooms than providers…and they shift around “Uh, hey, let’s talk in my office”.
That disclaimer made, along with previous disparagement of my relevant experience and general overall intelligence, I could see the calender interface as being more of a work-flow interface. Yes, this may be pie-in-the-sky, but I just like throwing insane ideas out there. Feel free to ignore the following:
First, when someone flagged as a provider looks at their calender, it defaults the scrolled view to center on the current system time.
Second, in the above situation, things like the small calender selection would be a horizontal sliding menu (hover, no click) because the provider doesn’t care about tomorrow when he is running around putting out today’s fires. The central view only shows a narrow abbreviated view of the appointment list.
Third, the provider should have three or so frames (or objects) on the right side that shows previous, current and next patient appointment status along with an interface to switch to that patient’s encounter that was created by the “arrived@” flag, (which should set the encounter session user to the scheduled provider, not the front office that set the status). This interface would have colored buttons that indicate and set the status of the patient. All workflow indicators and prerequisite checks (as configured for that particular practice) should function within the system: i.e. patient cannot be roomed until checked in, copays and verification etc…
When the doc finalizes the appointment or their portion of an encounter (or any other level of provider such as a phleb etc…) they sign off on the status by clicking the appropriate button. This also generates a list of encounters that the provider, biller, etc… can reference later so in case they have to complete notes, add lab results, or whatever at the end of the day, and then finalize the encounter.
Administrative types looking at the calender get a fairly frequent refresh (yes, expensive). They can see the current status of the patient directly from the calender, and can interface with that patient directly from the full calender display.
Yeah, pie-in-the-sky. What I can do, though my web app scripting skills are poo, is create a quick program (in a language I actually understand) that visually demonstrates an idea of how such an interface might appear (with static data of course). I’ll whip it up, and post a link here.