We have used proximity badges in conjunction with a terminal server to accomplish what is needed. A nurse goes into a room the proximity badge logs on to the pc and starts a terminal server session. Here a user can access Meditech from the terminal server. If they are called out the proximity badge logs them out of the pc and locks the terminal server session. If the user goes to a different pc that has the same terminal server / proximity card settings the user is logged onto the pc and rejoins the terminal server session where they were last at in Meditech. We did not like the particular proximity card we were using so we ended up not staying with it but imagine there have been improvements since we checked. I cannot speak for many of the inconsistencies that I am sure exist with the little Meditech bugs.
Shane -----Original Message----- From: meditech-l@MTUsers.com [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, June 21, 2007 7:16 AM To: meditech-l@MTUsers.com Subject: meditech-l Digest, Vol 32, Issue 33 Send meditech-l mailing list submissions to meditech-l@MTUsers.com To subscribe or unsubscribe via the World Wide Web, visit http://mtusers.com/mailman/listinfo/meditech-l or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of meditech-l digest..." Today's Topics: 1. RE: Access to eMAR (Stewart, Donald) 2. RE: Buggy Meditech programming of DTS's (Jay Gilmore) 3. RE: Buggy Meditech programming of DTS's (Lehl, Jim) 4. RE: {Spam?} (Elizabeth A. Nye) ---------------------------------------------------------------------- Message: 1 Date: Wed, 20 Jun 2007 09:05:37 -0400 From: "Stewart, Donald" <[EMAIL PROTECTED]> Subject: RE: [MEDITECH-L] Access to eMAR To: "Davis Daniel - Southern Hills" <[EMAIL PROTECTED]>, "Kenny Whiteside" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <meditech-l@MTUsers.com> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" What a problem for Windows PCs! It doesn't sound like as much of a problem for *nix PCs, however. You would actually be logging into your own session on a server, locking it, and then coming back to it. Don't think Meditech works with the *nix systems yet, though. Donald F. Stewart -----Original Message----- From: meditech-l@MTUsers.com [mailto:[EMAIL PROTECTED] On Behalf Of Davis Daniel - Southern Hills Sent: Tuesday, June 19, 2007 2:01 PM To: Kenny Whiteside; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; meditech-l@MTUsers.com Subject: RE: [MEDITECH-L] Access to eMAR Now that's a neat trick if you can do it! Think of the logistics involved with grabbing the complete state of everything on a PC and then recreating that on a different PC anywhere on the network. That would nearly require that the PC reboot for each user, and all of that data would have to be transmitted across the network to that new PC (that is if you could even figure out a way to store it in the first place). Wow! What a problem. Daniel Davis -----Original Message----- From: meditech-l@MTUsers.com [mailto:[EMAIL PROTECTED] On Behalf Of Kenny Whiteside Sent: Tuesday, June 19, 2007 9:57 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; meditech-l@MTUsers.com Subject: RE: [MEDITECH-L] Access to eMAR Perhaps! I'm not an IT person... but my understanding of proximity cards is that they simply lock the computer or automatically log the user off. That might help prevent the need for additional authentication once logged in if no one else can access that computer until the logged in user returns. But that creates additional problems. And the second part of what I believe nurses need is to be able to walk up to ANY other computer and the session that they are logged into is "brought" to that computer for them exactly where they were rather than having to start back at the beginning of the log-in process. You see, the problem is that the process of "logging in" that we use was designed for an office environment. Healthcare is migratory in nature! And that is especially true for nursing! Thanks, Kenny Whiteside >>> "Saira Somani-Mendelin" <[EMAIL PROTECTED]> 06/19/07 10:36 AM >>> Would proximity cards not be helpful in the situations you describe? -----Original Message----- From: meditech-l@MTUsers.com [mailto:[EMAIL PROTECTED] On Behalf Of Kenny Whiteside Sent: Tuesday, June 19, 2007 8:16 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; meditech-l@MTUsers.com Subject: RE: [MEDITECH-L] Access to eMAR I can see the need for the additional authentication (although as a nurse I would prefer that this not be necessary!) The difference in paper versus electronic documentation is that on paper, you have an opportunity to examine handwriting to determine whether the documentation was forged by another person. Not true with electronic documentation. Image a computer at the bedside of a computer savy patient. The nurse is documenting the physical assessment when there is a code blue two doors down. Do you think she will log-out before responding? It would be bad if the patient viewed HIPPA protected information. But it could be a patient safety issue if they documented that meds were given that were not! And there would be no way in the record to determine that it was NOT the nurse who documented this information! Until the healthcare environment has reliable technology to automatically disable the nurse's session when she walks away from a computer and then return that session to any computer that she walks up to.... this will continue to be a problem. I look forward to the day that there is a good solution to this. My humble opinion! Thanks, Kenny Whiteside >>> "Kimberly Frick" <[EMAIL PROTECTED]> 06/18/07 10:21 AM >>> I thought that an additional level of authentication was unnecessary too, but our State Pharmacy Board requires it. This level of security doesn't exist in the paper MAR world, so why is it so restrictive in the electronic version? Our State Board of Pharmacy requires us to enter our pin last, so we did not have a choice for that either. The only advantage I can see of entering it last is that you can access the e-mar to view the MAR, run MAR reports or do anything else except document without entering your pin. The "enter pin" prompt only comes up when you document something. Kim Frick, RN Project Coordinator Licking Memorial Health Systems Phone: 740-348-4114 Fax: 740-348-4769 [EMAIL PROTECTED] www.LMHealth.org -----Original Message----- From: meditech-l@MTUsers.com [mailto:[EMAIL PROTECTED] Behalf Of Sharon LaDuke Sent: Monday, June 18, 2007 7:36 AM To: Kenny Whiteside; Deborah L O'Briant; meditech-l@MTUsers.com Subject: RE: [MEDITECH-L] Access to eMAR I recently worked for a multi-facility organization which did not require anything additional for eMAR access. No problems that I ever heard of. Sharon -----Original Message----- From: meditech-l@MTUsers.com [mailto:[EMAIL PROTECTED] On Behalf Of Kenny Whiteside Sent: Friday, June 15, 2007 2:42 PM To: Deborah L O'Briant; meditech-l@MTUsers.com Subject: Re: [MEDITECH-L] Access to eMAR Deborah, We just had this discussion this afternoon also! If your nurses ALWAYS log off when they walk away from their computers.... I would say that the redundancy would be insane. But I also know that in the fast-paced, pulled in every direction at once world of hospital nursing... that's not likely to happen. For this reason, we chose to require the user's password when entering the eMAR from the Status Board. But who knows, maybe someday we will decide that this is not necessary! Have a good weekend, Kenny Whiteside >>> "O'Briant, Deborah L" <[EMAIL PROTECTED]> 06/11/2007 11:38 PM >>> Hello All, I am trying to gauge how the majority of sites live with the eMAR set up their password/pin options in MIS. We are currently using the NUR Status Board and the Project lead for nursing wants to take out any additional requirement to authenticate the user signing on to the eMAR. The thought is that the original request for a user mnemonic/password to log onto Meditech is sufficient and asking for the password again if accessing the eMAR, once in the Status Board, is redundant (we've set it up so all inpatient nurses get the Status Board upon successful sign-in). Our State Board of Pharmacy does not currently have any specific guidelines (yet) for us to follow. Has anyone experienced problems (ie, diversion) with the eMar and what security was in place at the time? I am trying to think of every scenario where having no additional requirement to access the eMAR might get us into trouble. I greatly appreciate anyone taking a minute to answer this posting! Thanks in advance! Deborah O'Briant Sr. Project Manager IT Applications Arkansas Children's Hospital (501) 364-3643 [EMAIL PROTECTED] ------------------------------------------------------------------------ ------ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ======================================================================== ====== -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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 -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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 -- This message has been scanned by the Securiant SpiderISA for spam and viruses, and is believed to be safe and clean. -- This message has been scanned by the Securiant SpiderISA for spam and viruses, and is believed to be safe and clean. ------------------------------ Message: 2 Date: Wed, 20 Jun 2007 10:13:51 -0400 From: "Jay Gilmore" <[EMAIL PROTECTED]> Subject: RE: [MEDITECH-L] Buggy Meditech programming of DTS's To: "'Charlie Downs'" <[EMAIL PROTECTED]>, "MEDITECH-L" <MEDITECH-L@mtusers.com> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Hi Charlie, I am in agreement with you 100%. There was a BAR issue that was opened several months ago that was supposed to fix an issue that was happening when screening a claim. When they moved the changes in to "fix" this problem, users noticed that when they went to edit or view a claim, they were getting kicked out of the system. I notified MEDITECH by a phone call AND opening a ticket, asking them to get this fixed ASAP, because our internal auditor had a deadline she needed to meet by the end of the day, and she needed to be able to view some claims. It was not fixed until the next day. Not only that, but we have also purchased their Scanning & Archiving solution and are in the middle of setting this up. We just had to cancel the Apps visit, because we had 17 tasks open with them relating to problems that I have found so far while setting this up. There was no point in having Apps training when their product is not functioning correctly in TEST. Also, the archiving functionality was described differently when they were selling the product as opposed to when we went to dictionary training. I have also discovered "functionality" that was mentioned in the demo training is not working correctly. I opened a task about it.to summarize, when he told me that it would not work, I told him what we said to our CFO at the demo visit regarding this issue, because she was the one asking questions about it. In the end, the specialist said that he had spoken with development, who said that this functionality was not available, and that he was incorrect of his understanding of the functionality. Every time I take 2 steps forward, I get knocked 3 steps back. I go to set up one part of the product, and I find that something is not working correctly. I open a task to get the problem corrected. And the cycle repeats itself. They definitely oversold this "unfinished" product. They told us things that would happen that are not going to happen. Our HIS director is peeved. Her department is in desperate need of this product, because they are running out of space keeping up with medical records. She realizes that we are not the problem, but that MEDITECH is the problem, and she is VERY unhappy with them. I could go on and on about things I am displeased with concerning this product, other issues, and with MEDITECH, but I could be here all day typing, and you could be here all day reading. I will mention one more thing.I get very annoyed when I have to reset the modems for MEDITECH to dial in and fix something, because other people who dialed in previously did not log out correctly!! Jay Gilmore Systems Analyst Crisp Regional Hospital (229) 276-3173 [EMAIL PROTECTED] _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Downs Sent: Wednesday, June 20, 2007 8: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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://prosonic.iserver.net/pipermail/meditech-l/attachments/20070620/e63fdc 2d/attachment.html ------------------------------ Message: 3 Date: Wed, 20 Jun 2007 09:23:23 -0500 From: "Lehl, Jim" <[EMAIL PROTECTED]> Subject: RE: [MEDITECH-L] Buggy Meditech programming of DTS's To: "Charlie Downs" <[EMAIL PROTECTED]>, MEDITECH-L@MTUSERS.COM Message-ID: <[EMAIL PROTECTED] alth.net> Content-Type: text/plain; charset="us-ascii" 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://prosonic.iserver.net/pipermail/meditech-l/attachments/20070620/699b84 38/attachment.htm ------------------------------ Message: 4 Date: Wed, 20 Jun 2007 13:35:54 -0400 From: "Elizabeth A. Nye" <[EMAIL PROTECTED]> Subject: RE: [MEDITECH-L] {Spam?} To: "Lawrence, Mitchell" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <meditech-l@mtusers.com> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" I don't know if this is possible but when I did a search for Berkshire Medical Center it is in Pittsfield Massachusettes. Can that possibly be true in the same state that Meditech is based in?! Liz ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence, Mitchell Sent: Wednesday, June 20, 2007 1:09 PM To: [EMAIL PROTECTED]; meditech-l@mtusers.com Subject: Re: [MEDITECH-L] {Spam?} 1. Meditech should assist you in meeting your state's requirements. 2. Your state should join the rest of us in the 21st century. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 11:53 AM To: meditech-l@mtusers.com Subject: [MEDITECH-L] {Spam?} We are a CS 5.5.2 site. As we continue to move forward with the advanced clinicals, (PCS,eMAR,EDM, PCM, RXM etc.) Medical records is finding it increasingly difficult to produce a printed copy of the record upon discharge. Our state does not currently recoginize the electronic record as the legal medical record. This leaves medical records printing the chart upon discharge. First, there is no one place that MR can go to print the entire record, leaving them to go to the individual modules which is quite time consuming. Second the quality of the printed record, organization, font size etc just does not lend itself to readability. Are there solutions out there that people are using that allows for one stop printing of the record in a readable, easy to follow and readable format? Thanks for any help you can give with this issue. Danielle J. Peppard RN Clinical Systems Consultant For Berkshire Medical Center ________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com <http://www.aol.com?ncid=AOLAOF00020000000437> . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://prosonic.iserver.net/pipermail/meditech-l/attachments/20070620/82b878 8f/attachment.htm ------------------------------ _______________________________________________ meditech-l mailing list meditech-l@MTUsers.com http://mtusers.com/mailman/listinfo/meditech-l End of meditech-l Digest, Vol 32, Issue 33 ****************************************** =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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 meditech-l@MTUsers.com http://mtusers.com/mailman/listinfo/meditech-l_mtusers.com
