|
I believe that, at the very least, a log
should be kept of the functionality that was bypassed so it can be reviewed at
some point down the road. However, I have a concern when a department is
content to stay right where they are and chooses not to grow and expand. Change
simply for the sake of change isn’t good – but staying with what
has worked in the past just to avoid change has equally negative implications.
One email signature line I have seen says, “If there were no change, we
wouldn’t have butterflies”. Another issue that can come up within a
system like Meditech is that a new functionality may appear in this version and
is optional. But, as programmers move down the road they program additional new
functionality that springs off that first item. So, by skipping some stuff and
burying it under all the other stuff we deal with a department may find
themselves having to retool or reorganize in order to get back up to speed at
some future time. Usually new “features” within
Meditech are designed to address some issue brought to light by someone. So, I
would think that most new features should be implemented when they become available.
However, a specific department could elect to wait a version or two to allow
Meditech time to get the kinks worked out of a particular feature. Daniel
Davis, RN From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Bob Hooper Can anyone tell me what method they use at their hospital to
gain consensus as to the enhancements and features of MEDITECH they will
implement? Our hospital, like most, reviews the list of enhancements
and features with our customer departments prior to every upgrade to determine
which ones we need to test and implement. Some departments may not be
willing to implement a new feature or enhancement, because they are content
with the way they have always done business. They are not looking to
change their ways. The problem lies in the fact that an enhancement that is
implemented in one department, although it may represent a change for that
department, may reap benefits for other areas of the hospital. It is like
the physician that does not want to spend the extra time entering in orders
into MEDITECH. They think of their own time and efforts, without
realizing the benefits that are gained by others in the hospital (pharmacy and
patients in the form of legibility and patient safety). The end result is that we do we not implement that feature
or enhancement at the time of the upgrade, we tend to forget about it, and we
never re-evaluate its usefulness at a later date. I thought that we could form a MEDITECH Steering Committee
to evaluate these enhancements and features. We would make a
determination to implement each based upon the good of the entire hospital (not
just the good of the department). I am concerned, however, that members
of this committee would get bored if we discussed items that 80 percent of the
time were not relevant to their own department. I am looking for guidance on the make up of the group, the
approach that is used, the level of detail that is discussed with a group, and
the method used for building consensus. Any suggestions or guidance that you may have would be
appreciated Thank you, Bob
Hooper Corporate Director of
Applications/MIS 301-896-2529 [EMAIL PROTECTED] |
====================================== All messages should be posted in plain text. HTML will be converted to attachments.
The meditech-l web site is MTUsers.com ______________________________________ meditech-l mailing list [email protected] http://mtusers.com/mailman/listinfo/meditech-l
