I have a different take on this - and none of it is simple. I worked 13 years at Meditech in clinical development as a programmer. In all of those years I only met 1 in-house clinician - Dr. Pope - who worked mostly on PCI. I worked mostly on LAB/MIC/BBK. At one point - as we developed the NPR version of these products - I suggested that I take a course in Microbiology. Much to my surprise this was deemed irrelevant to my work. On the other hand, during this development period - we did go out on several site visits - and this proved lucrative to the work we were doing. I would have liked to do this more often. Additionally, noting that many clinicians have differing opinions, we did build into the LAB systems a lot of flexibility. For instance, result ranges could be defined by physician - so a panic value for one physician need not be a panic value for another physician. Though nice, I have never seen this used. More customer contact would be nice. Since Meditech has pulled out of MUSE it seems to me that the contact is less.
In general the pace was fairly fast, and on a number of occasions I was told not to spend too much time perfecting certain pieces of code - since there was always something else that needed to be done. To some degree this is a managerial issue, and I tend towards perfectionism - but other times I felt that if we did it right the first time it wouldn't come back to haunt us. There was a lot of top down pressure of a one way sort. Though there is an internal tracking system but it's like all testing is - both in-house and by the customers. It's often the edges and the exceptions that need the most testing, and these usually get the tested the least. The major functionality is often intact (in testing), but once you go live, a lot of unexpected things occur that one wouldn't have thought of in a million years. Flexibility that is built into the system can add to this - on the end user side I have seen all sorts of bizarre ways in which this flexibility is used. Then, like any software, the more complex it gets the more you can get unexpected side effects. One seemingly simple change can please everyone in your room - but next door they're howling in agony. NPR has been around a long time, and with layer upon layer - by different programmers - it can get messy. Often this has been reversed by starting from scratch ($T to NPR for instance) - but somehow I doubt the transition to Magic FS is going to be anything close to pretty. I don't think there's a lot of longevity to the programmers - although I'm willing to bet that when the stats are pulled out it's on par with industry standards. Still, around the time I left there were a lot of disgruntled programmers who also left - most of them with long years of service. Meditech has to watch out for this - newbies can produce awful code, and I have seen my share of it. Concerning Pharmacy - when I was there - there was a real problem finding good programmers. I remember distinctly one programmer. For every `fix' he would make there would be two things broken. One of their finest Pharmacy programmers left just a bit before me. So it's kind of a mixed bag. I don't really have any proposed solution. It would probably take a lot of thought and would be a combination of quite a number of solutions. >>> Mary Everett <[EMAIL PROTECTED]> 07/03/07 10:14 AM >>> Hi, I just wanted to reply to this message. I worked for Meditch for 5 years as a support rep. I supported Pharmacy and we did have a Pharmacist on staff. As far as I know, he is still there. When problems are called in, we tested the problems in the customer's TEST directory at Meditech and on site. We then tested the problem in the development directory. If it was a problem there, we would send the problem (now an issue in the Development Tracking System (DTS)) to the Pharmacist that worked in Development. This is when the Pharmacist and support person would work out if it's a real issue or not. If it is and a change needed to be done, the Pharmacist and Programmer would work on the issue. One problem we always had was that Pharmacist at different hospitals think things should work differently. We had a group of Pharmacist saying that something should work one way and another saying they should work a different way. This is when we recommend that people go to MUSE and work out the issues there. Trust me when I say I feel your frustration. Another problem that we encountered a lot was testing of the DTS's. We would send out an upgrade to be tested. The customer would not test anything (we could go in and check, and trust me.. most of them never even signed into the test system). The customer would tell us to move everything live and we would. All of the sudden they had tons of issues in LIVE and wondered why. These problems would have been caught if they tested. Each customer needs to test their issues individually due to customizations. I thinks sometime DTS's don't make it into your system is because by the time Meditech gives you your testing notes and by the time you actually go live, it could be months. Many more DTS's were created in that time frame. They can't just put them in your system, because you need to test them. I started at Meditech in 1990 with a bunch of Pharmacy programmers. They are all still there, so trust me, after 17 years of working with the Pharmacist and Programming, you know the system and you are experienced. I do understand your frustration though. Once something becomes a DTS it could take years for you to actually get it into your system. I always felt so bad for customers in this respect. Hope this helps clear things up a little! Mary Everett Senior Consultant Lucida Healthcare IT >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 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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
