Hi Jim: I have to agree with you on that point. Meditech has spread its
programmers too thin and they do not have enough knowledgeable people to do the
work that needs to be done. It also takes a long time to learn what needs to be
done and how to do it, so if you have someone who is good at something, you
need to treat them kindly enough that they want to run away. Pharmacy is hard
enough to comprehend for a pharmacist. It is usually easier, however, for a
pharmacist to learn some of the computer workings than for an I.T. person to
learn the pharmecokinetics of drugs and the federal drug laws and all the
different allergy causing moieties of various compounds. The problem is that
there is a gap between what the pharmacist knows and can explain and what the
programmer
doesn't know and doesn't quite understand. And for the programmer to really
understand, I think that he has to have a working pharmacist sitting there next
to him to physically show him where the problems are and what the should/should
not look like. That means Meditech must actually EMPLOYEE and PAY a
pharmacist. who knows what they are doing - they need someone who works in
oncology, in home health care and another who works exclusively in inpatient and
one who is clinically oriented and one who does mostly retail dispensing. They
need to understand that, while the pharmacist and the doctors
may need to see different information some of the time and different ordering
screens some of the time, there are other times when they need to see the same
information. There may be times when the flags should be the same and times
when they should be different. The inconsistencies just blow me away.
For example, if a physician is entering a prescription in RXM and a drug has a
dead NDC number, he will get a flag that says "No interaction checking will
take place against this drug because of an invalid ndc number". In pharmacy, if
we try to enter an order using a drug with an invalid ndc number, we get
zilch - absolutely nothing - except in 5.6 if the drug with the invalid NDC
number is entered in AOM as a prescription or as a home med on a patient, the
pharmacist entering the inpatient orde will get a flag that says "no
interaction checking will take place against these drugs" - It doesn't say why
- just
says it won't happen.
Does anyone talk to each other or look at other parts of the systems programs
at the company to ensure some consistency? Take for example the use of the
word "deactivate" in pharmacy as opposed to using the word "hold (which
everyone understands). Or Meditech's use of the word "FORMULARY", which does not
mean the hospital's PT formulary -
In the PHA module it means a drug in the pharmacy drug dictionary which
Meditech expects you will only put there if it is on your formulary (not true).
Most users will use the restricted function n the 7th page to mark their
non-formulary (non-PT committee approved) drugs. Thus, not knowing what words
mean to the users, leads Meditech to use words incorrectly and users to find
uses for functions that they are not intended for. In other words, because a
function is not provided or does not work as it should, and Meditech will not
make it work as users expect it to work, a facility will invent a work around.
This may work fine for a couple of years, and then the facility gets a new
module or an upgrade and blammo, their work around no longer functions and
Meditech still has made no provision for the function that never functioned,
because the programmer never sat down with the pharmacist to see exactly what
the problem was and how it was that pharmacy expected it to work.
Arranging the meeting between the pharmacists and the programmers is the
manager's job.
Finding bugs in upgrades, reporting them and getting the DTS's installed for
them that already exist - implying that the bugs were obviously known -
otherwise there would not be DTS's --------- SHOULD NOT BE THE END USER"S JOB.
This should be the vendor's job. I believe this is part of the point Charlie
is trying to make. If there are bugs and there are DTS's to fix the bugs, how
is it that you can get an upgrade without the DTS's to fix the bugs?. Suppose
you have had specific customs programmed into your system and then you get an
upgrade and the customs are installed with the upgrade, but there were also a
couple of fixes done along with the customs but the "fixes" are not installed
along with the customs until the problem repeats itself and you have to report
it before you also get the "fixes" installed. Where is the logic in that?
This e-mail message, including its attachments, is for the sole use of the
intended recipient(s) and may contain confidential or privileged information.
Any
unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender
by reply e-mail and destroy all copies of the original message.
"Lehl, Jim" <[EMAIL PROTECTED]>
Sent by: [email protected]
To
"Charlie Downs" <[EMAIL PROTECTED]>, [email protected]
06/20/2007 09:25 AM
cc
Subject
RE:
[MEDITECH-L] Buggy Meditech programming of DTS's
Charlie:
I would like to think that Meditech is as conscious about quality as any
corporation in this business, but obviously there is room to speculate.
Interesting that the issue you site is related to Pharmacy. I have been
absolutely amazed over the past 4 years of the number problems we have
experienced
with this module. I also get the impression that over the past 5 years
Meditech has had difficulty retaining programmers for this module and the
dedicated
programmers they do have get spread thin with coding for integrated
applications like POM, RXM, eMAR, etc. I know how important employee retention
is when
it comes to supporting complicated systems like pharmacy and laboratory, but I
imagine retention takes on a new meaning of importance when it comes to
programming for these applications.
One challenge we seem to face at home is how to articulate and convince our
local leadership why it is so important to resource and retain dedicated and
talented people to support these applications in light of the growing
complexity of these systems and growing problems as a consequence of poor
quality
coming out of Meditech. I guess I'm not too optimistic that there will be an
overnight change in the quality of programming coming out of Meditech, not
because of the programmers, but more because of the response by Meditech's
management. I honestly appreciate the dedicated programmers at Meditech who
stay
in the trenches to grind out the problems they face. I think we owe them much
gratitude for what they do, and perhaps more important, we owe them our
support to work with them as a member of a team by doing things like thoroughly
testing DTS, frequently auditing data integrity, and accurately diagnosing
and documenting problems when they are discovered.
I'm not about to suggest quality measures for Meditech themselves; however it
would seem to me that one possible and accessible measure of quality we could
use locally would be the quantity of correction DTS Meditech has to code to fix
what is broken in any module, or perhaps a ratio of correction DTS and
enhancement DTS. This could give us a measurable indication of quality over
time, with limitations, that may be useful when communicating to our local
leadership the need for local support as well as volume control for their
booming voices as they speak out to Meditech. The risk we face when we venture
down these paths is assuming that the grass must be greener with another
vendor. I'm not so sure that it is even though their sales people might make it
sound like it is or we into the conclusion that their systems are better just
because they "look" better on the surface. Its hard to compare Meditech to
other vendors when it comes to the "quality" of programming without some
universal measure -- it this exists, I'm not aware of it.
One thing I hope will not be lost out of this dialogue you've initiated on the
L is respect for the hard working people at Meditech -- we need them! Too
often we, the L, fall into griping about Meditech in ways that just don't make
any difference and serves more to pull us all down into a spear chucking
contest rather than lifting up anyone to make a real difference.
Should be fun seeing the responses ;~}
Jim
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie
Downs
Sent: Wednesday, June 20, 2007 7:44 AM
To: [email protected]
Subject: [MEDITECH-L] Buggy Meditech programming of DTS's
I don’t know about everyone else, but I feel that was as Meditech users,
really need to get Meditech to improve on their programming accuracy. I’ve
run into more and more programming problems that have totally unintended
consequences unrelated to the problems that they were supposed to fix. Below
is an e-mail that I sent to our VP of IT this morning. I would like to
see some discussion on the L as to how to go about getting Meditech to change.
Thanks, Charlie
We had a huge problem which we discovered last week, but only
realized the
consequences this weekend from a DTS which Meditech moved to Live on
Thursday. Pharmacy
Issue #5294828 was a problem that one had to give a reason when
re-processing a billing
error when we should have not been prompted for a reason. For some
reason, this tied to the
drug dictionary where one had to give a reason when updating it. This was
totally unrelated
to billing, yet when they moved this to live, it not only caused Pyxis
billing to stop, but
each time an item was removed, it credited a previously removed item.
When I called on
Thursday, Meditech denied that this was what was causing my problem. I've
pasted what they
found was the problem below:
Rebhan,Maria (MEDITECH) - Jun 18, 2007 - 0948 EDT: Brian, there is a
problemwith the DTS
we delivered. It was patched correctly but, the code from it iswrong.
I've fixed this
Inhouse and will just need change control for TEST. Tx
If this issue would have been a billing issue, I would have tested it
thoroughly before
having them move it to live, but it was not a billing issue. I am seeing
more and more of
this that when Meditech moves a DTS to test or live, it has uninteded
consequences that are
often not noticed until we are live with it, because no amount of testing
will pick up an
unintended change entirely unrelated to the DTS. Another example is
Pharmacy Issue
#5237726. It was supposed to fix a problem with a field not defaulting
from the formulary
service when adding a new drug (FirstDataBank). After this was moved to
live, I noticed
that we could not look up drugs as we had before and instead had to use
extra keystrokes
for look-ups.
The hours to correct all of the billing problems is huge. I strongly
feel that Meditech
needs to be held accountable for what I see as increasingly sloppy
programming. I would
like to see us file a formal complaint with Meditech over this issue
since this is one of
many times that I have seen this happen in pharmacy and cause huge
problems. Meditech does
not even have a Pyxis machine to test out the Pyxis fixes, and instead is
relying on the
users to test the fixes. In addition, they need to thorougly test other
programming changes
more thoroughly instead of using their customers as basically alpha test
sites.
Unfortunately, sometimes we only find out about these programming errors
after the fact,
which is not right.
Hopefully, by filing a formal complaint, we can get their attention,
but I would hold
my breath. We had an interesting discussion at MUSE about how to get
Meditech to change
their business practices, and short of a large group of users agreeing to
withhold
maintenance payments, I don't see them changing. Perhaps it is time for
Meditech users to
band together and consider such action.
Charles Downs PharmD
Washington County Hospital
251 E. Antietam Street
Hagerstown, MD, 21740
301-790-8904
***** CONFIDENTIALITY NOTICE ***** This message contains confidential
information and is intended only for the individual named. If you are not the
named addressee you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
To subscribe or unsubscribe to the meditech-l, visit MTUsers.NET.
To check the status of the meditech-l, visit MTUsers.NET.
For help, email [EMAIL PROTECTED]
Visit the MTUsers WikiPedia at MTUsers.NET/mwiki
______________________________________
meditech-l mailing list
[email protected]
http://mtusers.com/mailman/listinfo/meditech-l
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
To subscribe or unsubscribe to the meditech-l, visit
http://mtusers.com/mailman/listinfo/meditech-l_mtusers.com
To check the status of the meditech-l, visit MTUsers.NET
For help, email [EMAIL PROTECTED]
Please visit and add information to the MTUsers WikiPedia at MTUsers.NET/mwiki
______________________________________
meditech-l mailing list
[email protected]
http://mtusers.com/mailman/listinfo/meditech-l_mtusers.com
