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: MEDITECH-L@MTUSERS.COM
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
meditech-l@MTUsers.com
http://mtusers.com/mailman/listinfo/meditech-l
