This hurt to read (paragraphs are your friend), but is a very good
point.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, July 02, 2007 8:36 PM
To: Lehl, Jim
Cc: [email protected]
Subject: Re: [MEDITECH-L] Buggy Meditech programming of DTS's
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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
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
