Posts
Dear Reader,
VISTA is too important to healthcare to leave its fate in the hands of managers, programmers, politicians, or entrepreneurs. Really, only VISTA's actual users - nurses, doctors, pharmacists, lab techs, radiologists, and other medical and support personnel - know precisely how they use VISTA second-by-second every day, so only they can really know how it falls short in supporting their work. Of all the people involved with VISTA they are also the only ones directly contributing to patient care, which after all is the point of this entire enterprise.
Therefore, in the VISTA lifecycle model, although anyone can request VISTA changes, user requests trump all other priorities. Directly. Not as interpreted for them by managers, experts, committees, or other bureaucratic forms of user disempowerment. User requests are collected and used directly as the marching orders for the VISTA development teams.
Users are the fourth and most important element of the VISTA model of authority. It is the users who decide what each team works on, and not by sorting through or voting on priorities but simply by reporting the problems they are having and requesting bug fixes or enhancements. As the reports accumulate, the urgent problems identify themselves and do not require committees or expert panels to identify.
Many people find this element of the VISTA lifecycle idealistic, but since all of their proposed alternatives have failed over and over to the tune of billions of dollars wasted, and since this model not only worked for seventeen years but produced the greatest productivity and responsiveness the VISTA world has ever seen, I find the idea of doing anything other than user-driven VISTA development ridiculously idealistic. A properly organized VISTA lifecycle very nearly runs itself, using specialized tools and techniques of information management.
Yours truly,
Rick
4 comments:
At what point do we decide that the proponderance of problems is enough to make a bug fix? With one report, ten, a hundred? At some point in this the fourth point of the lifecycle, we have to set a benchmark. We have to decide that the justification for manhours is when n number of hospitals report the same x number of problems.
Your take on the users controlling the development is correct - that is why the best programmers for lab were former lab techs. The best programmers for radiology were former xray techs and so on. They understand the problems, and there is no (or little) loss in communication between tech/programmers and tech/users.
Not exactly:
Seems to me the issue addressed by Point 4 is the need to achieve a tight coupling between the users and the EHR support team.
But as far as setting standards for what needs a fix, consider:
A problem that irritates a hundred users should be fixed
...after the one slows down ten nurses
...after the error that threatens physical harm to a single person.
That is precisely how you frame your benchmark:
After x number of non-critical error; or
After 1 critical error.
Then you just have to haggle over your definition of "critical" and "non-critical". Is the possibility of harm to a patient "critical"? - I would say, "Absolutely yes!". After a problem slows down ten nurses - doing what, and slows them down how?
Good point, and plenty of room for discussion.
Dear Rodney and John Leo,
Amen to that! Maybe the stack of priorities looks something like this:
1. patient care
2. patient confidentiality
3. legal requirements
4. helping the medical staff do their job
5. helping the nonclinical staff do their jobs
6. dealing with other technical problems the programmers find
7. experiments, techno-fads, and other nonessential explorations
but I think John Leo said it better.
The funny thing is that the advocates of centralized control harp on the problem of figuring out the priorities, but in my experience developing VISTA it was never that hard to figure out the priorities. Occasionally we needed a manager to whack us on the head to notice something important we had to address, but not usually.
Educated and empowered users are often their best advocates, and when they weren't we still had the application coordinators, local IRM programmers, and national field support to advocate on their behalf. And as Rodney points out, if most of your developers begin their careers as users, the developers themselves end up helping to advocate for the users' needs.
Under the VISTA software lifecycle as I understand and am presenting it, prioritizing the work is not a primary management function. That's not why we need managers. That particular problem solves itself when the system is flowing properly.
Yours truly,
Rick
Post a Comment