Wednesday, April 23, 2008

Summer students

University students are now finishing their last exams. High school students will be out in two months.

Getting some help from students is very common during the transition to EMR; my partner hired two students for data entry. The students are entering the CPP, and my partner then reviews those for accuracy and completeness. Several other physicians in my group did this when we initially started the EMR.

It is not bad to start the EMR transition in the spring; the office is quieter then. As well, you have some idea of what the EMR looks like by the summer, as you hire your student help.

However, CPPs are not the only thing that bright students can help with. Data entry for the preventive services for my group, last summer, was done with student help. It worked, so we discussed a diabetes quality improvement project at our recent FHT meeting, with funds allocated for data entry. There was consensus that we should go ahead. This is the project:

1. Get a list of all diabetics for each practice
2. Verify the list
3. Put in an electronic flowsheet in each practice location
4. Put the flowsheet in every diabetic's e-chart
5. Put in reminders to look at the flowsheet, every 3 months

It looks simple, but it is actually fairly complicated. Not everyone is entering the ICD code for diabetes (250) in the CPP or in encounters. As well, this code is sometimes used for Impaired Fasting Glucose ("pre-diabetes"), or Gestational Diabetes (diabetes only during pregnancy). These patients don't have diabetes. What I will do is get the list of all patients with 250, together with "comments". We often enter a comment like "IFG" if the patient does not qualify for diabetes. If the Diabetes list is poorly populated (I expect about 10% of adults for each practice), I can extract the billing code specific for diabetes.

Once the list looks reasonable, it gets faxed to my colleague's office for review and approval. We proceed with putting in flowsheets only when the list has been approved.

The advantage of electronic flowsheets is that much of the data is automatically populated. Vitals and labs go in automatically; the vitals go in straight from the encounter, and the labs straight from the e-results. I don't have to re-enter this data twice.

However, like everything else, this is not perfect. The labs all use different databases, and patients don't always go to the same company's lab. What I did for my group was meld the databases: in our Enterprise module, there is a place where you can say "this test from lab A is the same as that test from lab B". For some reason, it works very well for two of the three electronic lab companies, and not all that well for the third. It doesn't work at all for paper-based lab results, like the hospital's. When it works, results from any lab just go into the flowsheet.

To get around this problem, I have a cell called "notes" in the flow sheet. I just type the non-electronic tests there. I also give patients a handout with their lab form, with locations and hours of the two preferred lab sites, along with the URLs for lab locations. We do most of my lab tests in my office. We really need to have a common nomenclature for lab tests, as well as a common way to store and transmit lab results electronically; I keep hearing this will happen (OLIS), but I see nothing happening yet at my end (maybe this year?).

There are blank areas in the flowsheet to record other things, such as foot exam and monofilament testing. I ordered some free monofilaments last month from LEAP, and distributed them at our recent FHN meeting.

The students will take the approved lists, and enter a flowsheet in each chart. They will also put in a reminder to look at the flowsheet and check diabetic parameters, every three months. Finally we have a code that we bill every year for managing diabetes and reviewing flowsheets. The students will do a billing list for every physician, and if this works, we will bill this yearly as a group.

I don't yet know what problems I will encounter with this summer student project; I learned a lot from last summer's project, and I think I'll be able to figure out ways to fix things as they happen. Because we all access a common database remotely, all this will be done from my office, with no disruption to any practice; there are some very significant advantages to remote access.

What I hope to achieve is:
-a registry of all diabetics for my whole FHN
-use of flowsheets for every diabetic

My resident is almost finished her two years in my practice, and will be graduating as a full-fledged family physician soon. We will miss her. We get a new resident in July; one of the things that residents have to do is a practice audit; my resident did one for me on my diabetics two years ago. Audits are now a lot faster with EMR; I think I will ask the new resident to audit my practice, and if it is really quick, we'll ask some of my FHN colleagues for permission to remotely audit their practice. We can probably get some very good baseline and on-going data that way. I think I may get to find out if this little diabetes quality improvement project works.

My FHN is growing, and we now have 14 physicians. All three hybrid practices (EMR/paper) in my group are now going to be EMR only, as all practice partners have joined the FHN. We will go from a 12,000 patient base to about 16,000 patients. I expect that we care for about 1200 to 1400 diabetics (there are 89 diabetics in my practice). I think we can use EMR tools to make a real difference in their care, and I plan to have our summer students put in some building blocks to enable this over the next few months.



Ian Furst said...

nice work Michelle -- we've extracted pt lists like this before by doing wildcard word searches in multiple queries then combining the queries to have a complete list. Eg, in whatever table holds the medication search for the common meds a diabetic is on. Or I guess the same could apply in the labs section if it's not just text format.

Michelle Greiver said...

Thanks, Ian. We are just at the beginning of trying to organize our data into registries. I have the lists of diabetics now, and this works (somewhat). As clinicians, we don't enter things so that they can be searched later, we enter things because we see, diagnose and try to manage our patients' health conditions. Clinical data entry and clinical data queries are two different things; that is why "Diabetes, rule out" gets picked up by the searches as "diabetes". We have to figure out how to do both at the same time, which is not easy for us.

I am now pretty careful with what I code in my diagnoses; I won't code "asthma, rule out" (ICD 493) any more, because I know it will get picked up later in a code query. Instead, I code "resp problem NYD" (ICD 78*), with comment: possible asthma. The query picks up the code and not the comment. I don't code for a chronic condition that I am likely to search for until I have a definite diagnosis. That is the way I have found to do both data entry and data queries at the same time.