We are now a week and a half post-upgrade. My stomach acid level is starting to decrease.
As expected, we had some problems with the printers. In my office, my prescriptions wouldn't print from the application. I took screen shots and printed those, then hand signed them.
The problem was due to the Java program. It doesn't work properly with the new version. Java allows me to sign my prescriptions and consult letters on my Tablet. I found that when I disabled this feature, I could print; some pharmacists are going to be happy--I can't sign on the tablet any more.
In order to determine what the problem was, Helpdesk had to remote into my tablet to test things, which took about an hour. I have spare laptops, so I could keep working while this was going on. I told them that I could live without the signature for now; that can be fixed later.
We then had trouble connecting to the EMR on Friday. Everyone assumed it was because of the upgrade, but in fact it was SSHA (now called eHealth Ontario) that had a service breakdown; it took quite a while for our IT guy to determine what the issue was. Late on Friday afternoon, he reported that the issue at SSHA was "flapping vanes" (I have no idea what that is), and that they had resolved it.
By Monday, the system was working again.
I then started to have a look at what is new in the EMR. We have a pretty good method of generating lists of rostered patients meeting different criteria (not previously available). I could more easily generate a list of percentages of elderly patients who have had their flu shots this year; we are currently at 77.9% average for 12 physicians (2,965 eligible patients), with 50% of the physicians having given shots to over 80% of their eligible patients. Last year, we ended up with 71% of patients vaccinated.
We have until the end of January to complete our flu vaccinations, so I expect us to go over 80% as a group.
We mailed letters of invitation once the shots came in; we had our clinics set up, with the help of FHT nurses. In early December, our FHN admin sent a reminder letter to all patients who had not had a shot yet. I think our preventive group project is working well.
The new upgrade includes automatically generated and tracked lists of patients overdue for Fecal Occult Blood screening, similar to the four preventive services (flu, paps, mammos, Kids vaccines) we currently track and manage as a FHN. We previously had to program FOB screens individually. I think I will use the Summer Students to enter the initial data, and then we'll add this service to our current regular mailing, which is done every 3 months.
I will be having a look at the other goodies in the next few weeks, and then will plan an EMR booster for the group in the new year. I think EMR upgrades are all like that; expect some initial glitches, work to solve them, then go on to figure out what is new and how to implement it.
Our FHT clinical pharmacist is currently under-used. I think the problem is that she doesn't come to the different offices on a regular basis, so we don't always think of her. This is a new service in family medicine, so it will take a while to work in; talking to the pharmacist in person is pretty vital to integrating her into the practice.
We negotiated this with our FHT medical director. She agreed to have the clinical pharmacist spend a morning every second week in my practice. I am ready to let her prescribe for my patients, as she has the skills and knowledge to do so. We have worked on medical directives together, and I am ready to sign the document allowing her to prescibe. I will also have to change her EMR permissions with respect to prescription rights. One of the problems that I foresee is that community pharmacists may not be familiar with directives, and may not accept a prescription signed by a clinical pharmacist. What worked in another FHT is having the pharmacist call the prescriptions in after issuing them (but not printing them) in the EMR. We can do that as well, or the FHT pharmacist can assign the call to my front staff electronically. We'll have to practice this in January.
We have applied as a group to QIIP, the Quality Improvement and Innovation Partnership. I will be going with our FHN administrator, my RN, our dietitian, our clinical pharmacist, and perhaps our Social Worker as well. The plan is to use the Team to improve office efficiencies, care for diabetes, and colorectal screening. Although they say an EMR is not a requirement for this, I think it is pretty hard to really implement quality improvement without electronic tools--especially those that allow measurement of quality.
Michelle
Sunday, December 21, 2008
Sunday, December 07, 2008
Upgrading our EMR software
Our EMR software needs to be upgraded. The version we are currently on does not conform to the new OntarioMD requirements (Clinical Management Systems Version 2.0). We are getting the upgrade next Tuesday.
I view upgrades with both anticipation and trepidation. The anticipation is about the new features (improved medication management, vastly enhanced ability to search the record). The trepidation is about the unknown problems that we will face: will our printers and labelers still work? Are there bugs that we are not aware of?
These programs are now so complex that it is impossible to predict what changing things will do. As well, each province sets its own requirements for EMRs, and the software applications are programmed to meet these requirements. The requirements are usually tied to funding, and are thus more important than user requests; you get the system you plan for.
I understand that it is quite expensive for each EMR company to meet the requirements, on the order of $200,000 to $300,000 per province. This will make some of the smaller companies drop out of the market (not necessarily a bad thing in the long run). However, there does not seem to be a rigorous process for testing the new software, which means that physicians and other front line users are exposed to what is essentially an untried product. Even Microsoft can have missteps with new releases (see Vista).
Another issue is the interoperability factor. Some large physician groups have managed to negotiate a connection between their system and their hospital's system. However, these are currently one-off solutions, meaning that they cannot be replicated. The difficulty here is that the software upgrade needs to be tested in the environment it is currently in to guarantee continued interoperability. Two things can happen:
1. Testing does not happen, and interoperability (or parts of it) fails with the upgrade, or
2. Testing does happen, but only after a long delay; that group is now several versions behind their colleagues
I hear that these issues are common in the business world as well. Even large, enterprise-level databases (such as Oracle or SAP) cannot be completely tested; the results of new implementations can be dropped customer orders, difficulties connecting electronically to large external customers, materials being shipped in twice the quantity ordered due to software bugs, and difficulty with planning production due to missing/incorrect information. Testing can take so long that implementations are rushed in due to deadlines, with unknown consequences.
It takes time, money and work to fix the universal initial software problems, and these may be less available in small medical offices than in large corporations.
We received a 47 page document a few days ago on what is available in the new version of our EMR, as well as a 10 page document on medication enhancements. I am going through the documentation in preparation for the upgrade. However, I am concerned about my FHN colleagues; most of us are unprepared, and have had no training with the new version (and may not have the time to go over the documentation). I think what will happen is we'll get the upgrade, I'll give it a few weeks to see what the issues are, and then we'll schedule a booster learning session for my FHN. I think some formalized training may be useful: it is not necessary to train the whole group; having a web session for the "super-users" may be what's needed, as we can then spread the knowledge to our colleagues.
Michelle
I view upgrades with both anticipation and trepidation. The anticipation is about the new features (improved medication management, vastly enhanced ability to search the record). The trepidation is about the unknown problems that we will face: will our printers and labelers still work? Are there bugs that we are not aware of?
These programs are now so complex that it is impossible to predict what changing things will do. As well, each province sets its own requirements for EMRs, and the software applications are programmed to meet these requirements. The requirements are usually tied to funding, and are thus more important than user requests; you get the system you plan for.
I understand that it is quite expensive for each EMR company to meet the requirements, on the order of $200,000 to $300,000 per province. This will make some of the smaller companies drop out of the market (not necessarily a bad thing in the long run). However, there does not seem to be a rigorous process for testing the new software, which means that physicians and other front line users are exposed to what is essentially an untried product. Even Microsoft can have missteps with new releases (see Vista).
Another issue is the interoperability factor. Some large physician groups have managed to negotiate a connection between their system and their hospital's system. However, these are currently one-off solutions, meaning that they cannot be replicated. The difficulty here is that the software upgrade needs to be tested in the environment it is currently in to guarantee continued interoperability. Two things can happen:
1. Testing does not happen, and interoperability (or parts of it) fails with the upgrade, or
2. Testing does happen, but only after a long delay; that group is now several versions behind their colleagues
I hear that these issues are common in the business world as well. Even large, enterprise-level databases (such as Oracle or SAP) cannot be completely tested; the results of new implementations can be dropped customer orders, difficulties connecting electronically to large external customers, materials being shipped in twice the quantity ordered due to software bugs, and difficulty with planning production due to missing/incorrect information. Testing can take so long that implementations are rushed in due to deadlines, with unknown consequences.
It takes time, money and work to fix the universal initial software problems, and these may be less available in small medical offices than in large corporations.
We received a 47 page document a few days ago on what is available in the new version of our EMR, as well as a 10 page document on medication enhancements. I am going through the documentation in preparation for the upgrade. However, I am concerned about my FHN colleagues; most of us are unprepared, and have had no training with the new version (and may not have the time to go over the documentation). I think what will happen is we'll get the upgrade, I'll give it a few weeks to see what the issues are, and then we'll schedule a booster learning session for my FHN. I think some formalized training may be useful: it is not necessary to train the whole group; having a web session for the "super-users" may be what's needed, as we can then spread the knowledge to our colleagues.
Michelle
Subscribe to:
Posts (Atom)