This image above shows an example of automated data capture with the EMR; I am now tracking data on my visits for several different diagnoses. I can see that my annual check ups are stable, visits for common colds have seasonal patterns, and that I have changed my practice towards more chronic disease management and away from the treatment of acute, minor conditions.
The chart above is for the number of visits billed for hypertension; these are clearly declining. This is interesting to me, because it reflects the outcome of a number of changes I have made in my management of hypertension.
I use an automated BP machine in my practice; my staff do the BP readings, not me. I think the quality of BP readings in my office has improved as a result. Patients come in every 6 months if their BP is stable, consistent with current evidence. If BP reading is above goal, they are asked to drop by on a Friday (I am not in the office that day) to obtain an additional BP reading from the machine. These visits are not billed. I see the result remotely, and can send a message to obtain one more reading if needed, or to ask my secretary to book an appointment for medication optimization.
I also use home BP machines much more often. I have two loaner machines in my office.
The end result is good BP control, but fewer visits with the physician (see graph above). I don't think that routine BP measurement is a good use of my time, but I have switched from Fee for Service to a capitated payment system; this rewards efficiency instead of service intensity--there are pros and cons to that.
I can look at my data and plan further improvements because I now have "Well-Tempered charts". What I mean by that is that I have tried to enter good data, and to enter it consistently so that I can search it later. It was a learning process for me; I knew that my data would not be very good in the first year, and would then improve. I now enter "250" (diabetes) only when the patient is diabetic, and not when Impaired fasting glucose (or "pre-diabetes") is present. If I think the patient has angina, but I'm not sure, I will code the diagnosis as 785 (chest pain not yet diagnosed), comment "possible angina"; I code for angina, 413, only once I have the diagnosis. When I search my records, I now know that my diagnoses are highly specific (finding a code for diabetes means that the patient is truly diabetic). The searches may be less sensitive (may miss some diabetics), because some of my patients with pre-diabetes actually have the disease but have not been diagnosed yet.
This coding schema in my brain applies to important chronic conditions, because I really do want to identify patients with on-going problems that I want to manage better. I am less careful with minor conditions, such as colds; I may identify a cold as laryngitis or acute bronchitis (when they get an antibiotic).
Even though the EMR system allows me to use free text for conditions, I have limited this. I think trying to search for "DM II", "diabetes", "T2D" etc has far less value that coding the problem properly--even if you never misspell the condition.
Every prescription is entered in the EMR database; I avoid "free text" prescriptions whenever possible. Once I built my list of drug favourites, prescribing through the Multum database became much faster. All phone repeats are entered as prescriptions. I can now search through my prescriptions with a great deal of reliability.
Entering data is a pain; getting data out is the real gain. We need to think about the minimal requirements for the Well-Tempered chart, and I have outlined what I did above. I think coding correctly for about 10 common chronic conditions (DM, HT, depression, Asthma, COPD to start with) is a good start. Using the EMR to prescribe is helpful. Switching to labs that provide electronic results is a very good idea. None of this is terribly difficult, but it does take some effort to learn how to do it, and some discipline to enter data consistently.
JS Bach showed us that well thought out, orderly musical compositions are pleasing to the ear. I think we can learn from the Master, and apply his principles to the content of our records.
Michelle
Saturday, October 25, 2008
Saturday, October 18, 2008
Age of the Machine: managing hardware
Using an EMR means having a lot of machines around.
I recently took stock of what we have. In an office of three family physicians, all part time (4 days a week, 3 days a week, and 2.5 days a week), we now own:
3 Tablet PCs
1 laptop
5 desktop PCs
Total: 9 computers in the office
As well, there are 8 laser printers, four label printers, and two scanners. There is a wireless transmitter, a Small Office firewall, two broadband internet routers (a main one and a backup), and a failover router. There is an external hard drive for storage, and an external DVD writer for larger scale back-ups.
Some of the printer are attached to desktops, others are network printers. The scanners act as photocopying machines and faxes; we also have a "regular" fax machine. We have several UPS devices in case of power failures.
On any given day, any of this can fail. My wireless has gone down, the internet access has failed, various computers have crashed, printers have disconnected, and labelers have printed little necklaces of labels with nonsense on them. I have learned to try for the best, and plan for the worst. Sometimes it feels like being in Samuel Shem's "House of God": the first thing I do in a crisis is take my own pulse--then I call my IT Guy.
Here is how I manage my PCs. All computers have anti-virus software, set to run scans on a weekly basis. I periodically defragment the computers, and check that Windows updates have been installed. Everyone has been taught to use "Winkey-L" to lock their workstations when they leave.
We run a small peer to peer network; I set this up to have shared documents on the front computer and external hard drive. My old charts have been scanned to the external drive, and then shredded. Those paper forms that the outside agencies simply won't give up have been scanned to the shared folder on the front computer; I made a copy on the external hard drive. Every PC can access all the printers that are likely to be useful at that station.
We run a small peer to peer network; I set this up to have shared documents on the front computer and external hard drive. My old charts have been scanned to the external drive, and then shredded. Those paper forms that the outside agencies simply won't give up have been scanned to the shared folder on the front computer; I made a copy on the external hard drive. Every PC can access all the printers that are likely to be useful at that station.
Much of my hardware was installed at the beginning; I added extra parts as needed-- some after a problem occurred. Whenever I added something new, there was always work to make sure it functioned properly; no hardware or sofware component ever works perfectly out of the box.
Looking at this, it does seem like a lot of work. However, much of what needs to be done (once installed) is simple maintenance, like a preventive health exam or taking the car in for a tune-up. This is still so new to small practices that we don't have good preventive routines yet; many physicians may not be all that computer literate, so machine failures get magnified because they can't be fixed quickly. I don't know how many of us have access to a good IT guy (instead of the neighbour's teenaged son); I know we didn't when my group started.
When things malfunction, the process of diagnosing computer problems is a bit like what we do for our patients. You try to figure out the likely cause of the problem by taking a history and formulating differential diagnoses, you run some tests, and then you try various things to fix the issue. The problem here is that this happens on top of patient care during a busy office, and the physician may be functioning at the level of a medical student in term of IT knowledge (especially at the beginning). I think it really helped us to function as a group so we could help each other out.
Interestingly, most of this hardware actually works pretty well, most of the time. Here are the things that can help:
1. do some preventive maintenance (antivirus etc)
2. have a good IT guy that you can call
3. buy good machines (not the cheapest ones)
4. keep all your CDs (drivers, software) in one place in case you need to find them
5. try to form a collaborative group with colleagues so you have someone you can call if you can't figure out what to do
And, if all fails, go and have a cappuccino--after all, these are just machines.
Michelle
Looking at this, it does seem like a lot of work. However, much of what needs to be done (once installed) is simple maintenance, like a preventive health exam or taking the car in for a tune-up. This is still so new to small practices that we don't have good preventive routines yet; many physicians may not be all that computer literate, so machine failures get magnified because they can't be fixed quickly. I don't know how many of us have access to a good IT guy (instead of the neighbour's teenaged son); I know we didn't when my group started.
When things malfunction, the process of diagnosing computer problems is a bit like what we do for our patients. You try to figure out the likely cause of the problem by taking a history and formulating differential diagnoses, you run some tests, and then you try various things to fix the issue. The problem here is that this happens on top of patient care during a busy office, and the physician may be functioning at the level of a medical student in term of IT knowledge (especially at the beginning). I think it really helped us to function as a group so we could help each other out.
Interestingly, most of this hardware actually works pretty well, most of the time. Here are the things that can help:
1. do some preventive maintenance (antivirus etc)
2. have a good IT guy that you can call
3. buy good machines (not the cheapest ones)
4. keep all your CDs (drivers, software) in one place in case you need to find them
5. try to form a collaborative group with colleagues so you have someone you can call if you can't figure out what to do
And, if all fails, go and have a cappuccino--after all, these are just machines.
Michelle
Friday, October 10, 2008
Helpdesk Tango
Working with your EMR company's Helpdesk is a bit like dancing the Tango. If done well, it can be quite good, but if your partner drops you during a dip, it can be a disaster.
We have had our ups and downs with the Helpdesk. They were very helpful at the beginning (we got to know several people by name); then there was a period when the phones were not being answered. Now we live in an uneasy truce with them.
There seems to be a fair amount of turnover in that department. I think it must be a very stressful job: when a physician or staff member calls, there is something wrong and they're not happy. New releases always seem to cause problems and everyone calls at once, so the helpdesk is overwhelmed and messages get re-routed to call answer; people are even less happy.
Having a super-user around decreases the number of calls to Helpdesk. We can often help our colleagues faster than they can, as we are familiar with our local setting. I now seem to be in charge of managing our VPN access. As well, I send periodic updates on how to use the software. A colleague in a very well managed large group practice told me that his group made a decision as to who calls their Helpdesk, so that they don't get the same calls repeatedly; his EMR company rewards groups with less than the average number of calls financially--not a bad idea. I wish Helpdesk kept a list of key contacts for each group and managed those calls a bit better.
We had an issue with our label printers not working properly after one of the upgrades. Our FHN administrator figured out what the issue was; she sent out an email, and was able to help several offices fix the problem.
If the EMR went down, we often didn't know who to call. The failure could be because the SSHA Internet connection was down (call SSHA), because the application was causing a problem (example, running a report that was too large), or because the server needed to be re-booted. Over time, between our two FHNs, we worked out processes to deal with this. Each FHN has one person responsible for calling (and a back-up in case the physician is away or not available). If there is no service, we log in to Google (check the Internet). If that works, then it is the server or the application. It is not always possible for us to know; our IT guy told us to phone him first, as he can check the server remotely. If the server is ok, then we notify the EMR company.
We sometimes have problems with our labs coming in. To get lab results, the server uses what I have been told is a very old, phone-based application (Winblast). This application can get easily turned off, and sometimes seems to go off on its own. If it is off, then no labs come in. Helpdesk then get calls and emails, and they have to go in to turn the program back on; due to security issues, we don't have direct access to this program. This has happened repeatedly. Our IT guy finally put together a small program that automatically checks and turns the phone application back on; problem solved.
We are trying to manage as many issues as we can; we don't like calling Helpdesk. Calling takes time that could be spent on patient care, and they can't always help. However, when we do call, we don't want to be dropped on our back. It took quite a long time for us to figure out the processes we now use; perhaps EMR companies should develop a list of common issues, and help physician groups develop workflows to make things work more smoothly when problems do occur (an ounce of prevention). Some problems are likely very common; I am sure Helpdesks keep call statistics (or they should). Sending out information about common problems and solutions may help; helping the local super-user help their colleagues, and investing in the development of local skills certainly will help.
As users, we have had to learn to manage our Helpdesk. I think this department must be expensive for the EMR company, and they are certainly a cost centre (every call costs them money). There are things they can do to manage those costs without antagonizing physicians through deficient service, but this requires planning. Perhaps one of the factors for survival in the current EMR wars will be service: how to keep users satisfied without having Helpdesk costs go through the roof. Only the smartest companies will survive.
Michelle
We have had our ups and downs with the Helpdesk. They were very helpful at the beginning (we got to know several people by name); then there was a period when the phones were not being answered. Now we live in an uneasy truce with them.
There seems to be a fair amount of turnover in that department. I think it must be a very stressful job: when a physician or staff member calls, there is something wrong and they're not happy. New releases always seem to cause problems and everyone calls at once, so the helpdesk is overwhelmed and messages get re-routed to call answer; people are even less happy.
Having a super-user around decreases the number of calls to Helpdesk. We can often help our colleagues faster than they can, as we are familiar with our local setting. I now seem to be in charge of managing our VPN access. As well, I send periodic updates on how to use the software. A colleague in a very well managed large group practice told me that his group made a decision as to who calls their Helpdesk, so that they don't get the same calls repeatedly; his EMR company rewards groups with less than the average number of calls financially--not a bad idea. I wish Helpdesk kept a list of key contacts for each group and managed those calls a bit better.
We had an issue with our label printers not working properly after one of the upgrades. Our FHN administrator figured out what the issue was; she sent out an email, and was able to help several offices fix the problem.
If the EMR went down, we often didn't know who to call. The failure could be because the SSHA Internet connection was down (call SSHA), because the application was causing a problem (example, running a report that was too large), or because the server needed to be re-booted. Over time, between our two FHNs, we worked out processes to deal with this. Each FHN has one person responsible for calling (and a back-up in case the physician is away or not available). If there is no service, we log in to Google (check the Internet). If that works, then it is the server or the application. It is not always possible for us to know; our IT guy told us to phone him first, as he can check the server remotely. If the server is ok, then we notify the EMR company.
We sometimes have problems with our labs coming in. To get lab results, the server uses what I have been told is a very old, phone-based application (Winblast). This application can get easily turned off, and sometimes seems to go off on its own. If it is off, then no labs come in. Helpdesk then get calls and emails, and they have to go in to turn the program back on; due to security issues, we don't have direct access to this program. This has happened repeatedly. Our IT guy finally put together a small program that automatically checks and turns the phone application back on; problem solved.
We are trying to manage as many issues as we can; we don't like calling Helpdesk. Calling takes time that could be spent on patient care, and they can't always help. However, when we do call, we don't want to be dropped on our back. It took quite a long time for us to figure out the processes we now use; perhaps EMR companies should develop a list of common issues, and help physician groups develop workflows to make things work more smoothly when problems do occur (an ounce of prevention). Some problems are likely very common; I am sure Helpdesks keep call statistics (or they should). Sending out information about common problems and solutions may help; helping the local super-user help their colleagues, and investing in the development of local skills certainly will help.
As users, we have had to learn to manage our Helpdesk. I think this department must be expensive for the EMR company, and they are certainly a cost centre (every call costs them money). There are things they can do to manage those costs without antagonizing physicians through deficient service, but this requires planning. Perhaps one of the factors for survival in the current EMR wars will be service: how to keep users satisfied without having Helpdesk costs go through the roof. Only the smartest companies will survive.
Michelle
Subscribe to:
Posts (Atom)