It’s Not About The Box Improving Care at Group Health with People, Process and Technology

March 30, 2007

Physician’s Advisory Council Highlights

Filed under: Informatics Team — admin @ 7:47 am

Several significant issues emerged in this years Physician’s Advisory Council in Madison. Again there was confirmation that Group Health is a leader and innovator in using our EMR but in the same vein, many other groups are catching up and are surpassing us in some areas of functionality. There is cool stuff on the horizon.

Drs’ Grossman and Eytan gave a great talk on Momentum and I talked about Advance Directive notification. The Epic programmers admitted that they need to be more accountable to improving this process, always a great win when the host company learns from its own users.

Some notable take homes:

1. MetroHealth has developed a highly targeted and customizable BestPractice Alert system. They demonstrated ways to have BPA’s appear in many different places in the clinical workflow and how they intersect with HM modifiers. MetroHealth, our neighbors to the South, have also configured EpicCare to meet best practice standards, they have built low maintenance automation protocols and have built what they call ‘quiet’ BPA’s that can be worked on at a providers discretion. That is a nice feature in that providers could work on the BPA’s at their discretion, not only when in an active chart.

2. Note Writer, the radio button based charting tool, remains a real crowd pleaser in helping construct common notes. Accuracy and erroneous data entering remain as significant barriers, but I can see the benefits to a busy provider. They can be filled out by flow staff in the exam room as well, again improving efficiency.

3. Lastly, Geisinger has created a Diabetic Tool Kit for the Primary Care Physician consisting of an optimized ‘Diabetic Bundle’ of tools that cover order entry support with smart sets and prefilled consults and order panels. They have created inbred Decision Support tools, both BPA’s and HM alerts. They have created a nice diabetes Letter- a report card summery on the AVS and a Data/ Summary Review.

PAC continues to be one of the best learning grounds for our organization to see what others are doing. We have as much to offer as we have to learn. I will post the links to the power point presentation of the best of these talks and will work to weave some of this great work into the current CIS process.

March 28, 2007

Microsoft Vista compatability issues

Filed under: Technical Issues — admin @ 11:28 am

With Microsoft Vista sales ahead of expectations and GHP staff buying new computers, there are now known compatability issues with Vista/Citrix and Epic. Bottom line, if you buy a  new computer or upgrade to the Vista operating system, you will not be able to access Epic at home via Citrix at this time.  These issues are being worked on, time table for resolution is unclear.

For those interested in the “technical” description, here it is. 

“Here’s what we have from Epic.
Epic and Vista compatibility

Please note that while Spring 2007 (next year’s version) is compatible with Internet Explorer 7, Epic has not yet confirmed the compatibility of Windows Vista with any version of Hyperspace. Until we do, we ask that you do NOT deploy Vista on any systems intended to run Hyperspace. We have been testing Vista with Epic applications and are working to resolve issues. When we have further updates on Epic’s compatibility with Vista we will post it in the Newsletter.

Issue with ICA Client version 10.0 compatibility
We have been testing version 10.0 of the ICA client with Epic and have identified an issue with virtual channels. We do not yet know the extent of the issue and have escalated it with Citrix support. If you use Epic’s Cross Deployment Access or Pool Manager functionality, or any other third party devices or applications that depend on virtual channels, this issue may affect you on v10.0. When we have further updates on this issue we will post it here.”

Everett QIST- coding

Filed under: Coding,Everett — admin @ 10:12 am

This week at Everett we’re doing a QIST with our business office colleagues with a focus on improving coding and avoiding/preventing common mistakes that are occurring. What we code in Epic ultimately is what generates a “bill”…sometimes not a bill directly to a patient but rather a risk reimbursement (real dollars) from Medicare or other payors. To the extent providers code incorrectly, we either lose revenue from missing codes or we are billing illegally from using the incorrect codes. We’ve had some great discussions around ideas for improving this. Using IMO has helped by using more provider familiar language, but it still has limitations. For example, when seeing a patient who had a stroke last week and is pararlyzed on the right side, we should never use the “CVA” code, 434.91. This code is to be used when the patient is having a stroke today. This code leads to a significantly higher level of reimbursement….which is “illegal” if all we’re doing is seeing a post stroke patient in followup. Big medicare fines for things like this. For residual problems with a stroke, we should use the “Late Effects of….” codes, but that is not the most intiutive thing to remember. What we’re doing is building an alert that fires when the 434.91 code is entered saying (in essence) “This code is used for a stroke happening today, use the attached Smartset to capture an old stroke or damage from a previous stroke.” The Smartset has laid out with the various residuals (or no residual) and makes it easy to capture the correct diagnosis. Getting these diagnoses correct is important since we have the ability to edit diagnosis. For example, if you use the acute CVA code and change the wording to “Old CVA with left hemiaparesis” then enter that onto the Problem List, that systemtatically can lead to other providers choosing that code for a visit and multiple instances of billing/recording that “This patient is having another stroke today…”

We are building improvements to the Preference Lists for Diabetes diagnosis/complication capture, entering “past history..” codes (Labeled “Personal History” in ICD language, no wonder whenever I type “past h” I don’t get anything….) and additions to easily capture Family History issues of importance onto the Problem List (colon cancer, breast cancer, etc). Basically, you’ll type “p h” and see the Past History codes and “f h” to get the Family History codes. Using these correct codes is also very important for compliance/billing and being legal. Entering174.9 “Breast Cancer” onto a visit diagnosis is incorrect when a patient had breast cancer years ago and we want to note that as an issue. In using that code, we are saying “I am treating this patient for active breast cancer today.” The correct code is V10.3…this will be easily visible typing “p h” and choosing the “Personal History of Breast Cancer” code.

Medication management and unlocking new features in EpicCare

Filed under: Medications — admin @ 8:03 am

Group Health is being visited this week by experts from Epic Systems, Inc., and in concert with our Epic team and Pharmacy experts, are working to streamline the maintenance of medication data within our EpicCare System.

In 2006, we managed four (4) Emergency Response Team incidents related to medication data in EpicCare. We discovered opportunities to look at the way we load this data to ensure accuracy, and this is what is being worked on this week. It’s a complex process to update these files and keep them in sync with all of our systems.

In addition to this primary work, we’ve requested a look at unlocking some features that are present in our upgraded system:

  • Calculated end dates on medications – this will allow medications that are unlikely to be continued beyond a certain therapeutic timeframe will automatically drop off of medication lists
  • Designation of “chronic, long term” medications on medication lists. This is around the area of “alert prevention,” because it would allow providers to tell EpicCare that a medication should be continued indefinitely and should not drop off of the med list even when not refilled
  • Duplicate Rx checking – when a provider reorders or orders a new strength or product of the same medication, Epic would assist by offering to stop / delete the same medication if it appears elsewhere on the list

This unlocking is not the primary focus of the work this week; however, the team will look at what conversions or setup is required to get us there. We would like there to be assistance every step of the way in prescribing and managing med lists.

March 26, 2007

When the safety net fails: lethal phenytoin dose in Florida Hospital

Filed under: Safety — admin @ 5:28 am

In Florida recently, a physician order for 800 mg of phenytoin was translated into 8,000 mg. 10 times the prescribed dose was administered, with the nurse grabbing 32 vials (instead of 3.2) from three electronic drug dispensing machines, and hanging two IV bags, one for each arm, delivered to cause cardiac arrest and death within minutes. The lethal dose of phenytoin is 2-5 grams.

Click here to read the story

It does not say if there was a computerized order entry system in place. The article does say that there were not hard stops on the drug dispensing machines, or limits in quantity of drug on the floor, which might have raised questions.

There is a nice commentary about this on one of the LEAN blogs that I follow. I agree that safety is a part of the system, as well as of the culture (“Establish a culture where people don’t have to be heroes, where they can ask questions and question things or ask for help without being viewed as lame or weak or incapable.”) In our lives outside of the medical center, we do this quite readily – if I see someone in distress in a public place, I have no qualms about interrupting and asking if I can help. What about within the hospital?

Our unusual occurrence reporting system helps with that. We recently added a location of the issue of “Epic” (as opposed to just one medical center) within the system such that if there’s felt to be a systemic safety issue from the EpicCare system itself, that can now be reported. The analysis of these requires clinical input from a physician on our team, which we are happy to do. I also personally review any unusual occurrence report that brings up questions around the way Epic is designed. Generally speaking, the reports I have reviewed provide ideas for opportunities to improve safety in ways we could not prior to EpicCare.

One example is the new positive alert system for RTAS. I would like to see that system broadened to critical pathology results as well.

Older Posts »

Powered by WordPress