Having been circulating among pharmacies over the past dozen years, I have come upon several varieties of pharmacy-based operating systems, most of which have been designed by engineers and programmers without the slightest inkling of the primary operations of a pharmacy.
Invariably, these systems are chosen by department managers looking only at the bottom line cost, and rarely, if ever, with consideration for those who have to actually make use of the product. The old canard "oh, there's always a learning curve," is usually invoked, when for the users, it's more of a "learning cliff." And patients, trained for instant gratification and regarding a pharmacy as just a variation on McDonald's, don't give a rat's patootie that workers are gnawing their arms off during a conversion to an 'improved' system.
The software marketers create handsome websites extoling all of the functions of their systems, but - and I find this very interesting - never really show what their system looks like in practice.
Two systems in particular - one called 'Prodigy' (no relation to the old pre-internet online service) and the other called 'RX30' - are classic examples of this mindset.
Prodigy is an odd collection of jumbled screens, originally designed for nursing home 'cycle fills' (a process that quickly becomes a billing nightmare), unmatched fonts, complicated by a nonlinear work flow that has the user moving back and forth in the process of filling a prescription. Its choice is usually by those who want a centralized access for billing, from several off-sites, for which it seems well suited. However, for a user, it serves only to add about 50% to the processing time of a prescription, just in the back and forth of the workscreens. A mouse is required, something that really ruins any workflow. Operating two terminals, two trained and experienced employees, going breakneck, can process a max of 140 prescriptions in 9 hours (that's just processing, not filling, by the way).
RX30 suffers from similar drawbacks. The screens are inconsistent in their layout, with function keys being especially challenging, as each one opens a set of menu options which then change depending on the screen. Changing a spelling error in the prescription label, for example, means F1 > Workflow (the tenth selection in the menu options) > Edit/label > F2 > toggle or mouse to instruction field > make change > F4 set (not just 'enter' - you have to 'set' the change with a function key) > F5 reprint (or is it the other way around? Again, process over outcome). For any clinical tracking, it has a 'comment field' that can be altered or deleted at will or whim (so useful progress notes will have to be kept separately in a word processor document set up on your own). Getting a reprint on a label is another 4-5 step process. The pharmacy being introduced to this system usually does about 200 Rxs per day. The backlog of unprocessed Rxs by 11am was about 50. The POS process with the system is additional software, with a completely different set of menu screens, with lots of mousing and touch screens (and don't we just love the 24 hour virus life cycle on a touch screen device in a healthcare setting), and nearly a doubling of clicking processes. It is obvious that RX30 just bought an existing setup for their POS - there is no integrated workflow with the pharmacy operating system.
It is apparent that these packages, while not inherently evil and possessed of some level of functionality, are at best poor examples of creating a useful or efficient workflow. Neither of them have been developed by programmers who seem to 'get' the purpose of a retail pharmacy setting - to fill new prescriptions and refill existing ones. There is far too much time wasted in twiddling and fiddling, almost as if they were developed by teams trained in algorithms of computer games rather than the stark, dull, workaday need to grind out prescriptions quickly and efficiently. A stark example is that neither filling nor refilling a prescription are among the top choices of their opening menus.
And, it is interesting that it takes a team of trainers several days to 'educate' pharmacists (with 6 years of college) and their certified technicians (again, they are the ones who have to do this all efficiently) on how their systems operate. That is a huge flag right there. Systems can follow an intuitive design and flow. Neither of these do.
When we hear 'oh it's only a few seconds extra time' for each prescription, these programmers need to understand that a few seconds, multiplied by 200, is a considerable amount of time during an already hectic workday. They get paid by the hour - we get paid by the prescription.
Invariably, these systems are chosen by department managers looking only at the bottom line cost, and rarely, if ever, with consideration for those who have to actually make use of the product. The old canard "oh, there's always a learning curve," is usually invoked, when for the users, it's more of a "learning cliff." And patients, trained for instant gratification and regarding a pharmacy as just a variation on McDonald's, don't give a rat's patootie that workers are gnawing their arms off during a conversion to an 'improved' system.
The software marketers create handsome websites extoling all of the functions of their systems, but - and I find this very interesting - never really show what their system looks like in practice.
Two systems in particular - one called 'Prodigy' (no relation to the old pre-internet online service) and the other called 'RX30' - are classic examples of this mindset.
Prodigy is an odd collection of jumbled screens, originally designed for nursing home 'cycle fills' (a process that quickly becomes a billing nightmare), unmatched fonts, complicated by a nonlinear work flow that has the user moving back and forth in the process of filling a prescription. Its choice is usually by those who want a centralized access for billing, from several off-sites, for which it seems well suited. However, for a user, it serves only to add about 50% to the processing time of a prescription, just in the back and forth of the workscreens. A mouse is required, something that really ruins any workflow. Operating two terminals, two trained and experienced employees, going breakneck, can process a max of 140 prescriptions in 9 hours (that's just processing, not filling, by the way).
RX30 suffers from similar drawbacks. The screens are inconsistent in their layout, with function keys being especially challenging, as each one opens a set of menu options which then change depending on the screen. Changing a spelling error in the prescription label, for example, means F1 > Workflow (the tenth selection in the menu options) > Edit/label > F2 > toggle or mouse to instruction field > make change > F4 set (not just 'enter' - you have to 'set' the change with a function key) > F5 reprint (or is it the other way around? Again, process over outcome). For any clinical tracking, it has a 'comment field' that can be altered or deleted at will or whim (so useful progress notes will have to be kept separately in a word processor document set up on your own). Getting a reprint on a label is another 4-5 step process. The pharmacy being introduced to this system usually does about 200 Rxs per day. The backlog of unprocessed Rxs by 11am was about 50. The POS process with the system is additional software, with a completely different set of menu screens, with lots of mousing and touch screens (and don't we just love the 24 hour virus life cycle on a touch screen device in a healthcare setting), and nearly a doubling of clicking processes. It is obvious that RX30 just bought an existing setup for their POS - there is no integrated workflow with the pharmacy operating system.
It is apparent that these packages, while not inherently evil and possessed of some level of functionality, are at best poor examples of creating a useful or efficient workflow. Neither of them have been developed by programmers who seem to 'get' the purpose of a retail pharmacy setting - to fill new prescriptions and refill existing ones. There is far too much time wasted in twiddling and fiddling, almost as if they were developed by teams trained in algorithms of computer games rather than the stark, dull, workaday need to grind out prescriptions quickly and efficiently. A stark example is that neither filling nor refilling a prescription are among the top choices of their opening menus.
And, it is interesting that it takes a team of trainers several days to 'educate' pharmacists (with 6 years of college) and their certified technicians (again, they are the ones who have to do this all efficiently) on how their systems operate. That is a huge flag right there. Systems can follow an intuitive design and flow. Neither of these do.
When we hear 'oh it's only a few seconds extra time' for each prescription, these programmers need to understand that a few seconds, multiplied by 200, is a considerable amount of time during an already hectic workday. They get paid by the hour - we get paid by the prescription.
No comments:
Post a Comment