Dinosaur Doc posted awhile back about how she managed to keep track of a patient who was failing to follow through on a mammogram. Dino holds the charts of patients with pending studies on a special shelf in the file room, where they stay till the study comes back.
Dino’s got a tried and true tickler system, and it works.
My Old Paper Tickler System
I had a my own little tickler system before we went to an Electronic Medical Record. For labs and path, I had a cloth-bound log book, where my tech simply checked off the results as they came back each day before handing the pile of reports over to me for review. If the results didn’t come back, she called the lab. For radiology, we had a series of manila forders, one for each month of the year. When a radiology test was scheduled, the third NCR copy of the requisition was slipped into the pocket corresponding to the month in which the test was to be performed. As results came back, my secretary pulled the requisistions for the folder, and at the end of the month, anything left in the folder was overdue, and we contacted the patient. On my desk, I had a rack for the charts for patients who worried me or from whom I was waiting for call backs, and the chart stayed there until the issue was resolved or the game of phone tag was over.
My system was simple, it was fast and efficient, and it worked.
Tickling with the EMR
I’ve been electronic almost 3 years now, and have to admit, I still miss my old tickler system. What I’ve replaced it with is a bit more complicated. Here’s how it works (and anyone who has ideas on how I can do it better, please feel free to comment) –
Labs
This part’s easy. Most of my patients have labwork at our hospital, and the few who don’t go to Quest or Lab Corp, both of whom can send results electronically to our lab. I just head into my In Box to see their results. I go to the Overdue Results Folder once a week, sort it by type of test, and forward the overdue tests to my secretary. She then calls the lab or the patient (who occasionally skips out without their bloodwork).
If I am unable to reach a patient on the first try about an abnormal result in my In Box, I forward that result to myself as a Result Note, and those notes stay in a separate folder on the desktop till I hear back from the patient.
Rads
I handle radiology results in my In Box the same way as labs. But overdue rads are a whole ‘nuther story.
Today, after spending my entire Sunday cleaning up the Overdue Results Folder, I came up with an idea, and I can’t wait to try it tomorrow to see if it works. I’m going to order all my radiology as future orders, with an anticipated date around the time I expect it to be done. (I don’t know why I didn’t think of this before…) Of course, it’s now going to take me longer to place these orders, but I am hoping it will save me time at the back end and give me back a meaningful radiology tickler system.
Path
As for pathology, those reports come back quickly and pair nicely with their orders. But they lose their formatting when they come over from the path lab system to the EMR. Gone are the nice paragraphs separating the meat from the gravy, making it difficult to scan a report quickly to determine if it is normal or abnormal. As a result, I’ve actually missed a few abnormals since we went live with the EMR. Fortunately, our path lab still sends us a paper printout once a month of all our abnormal pap smears, and I caught my mistakes right away. Good old paper…..
Good Old Paper
Speaking of which, I find I still need a paper tickler system for those few patients I don’t want to lose track of. It’s quite a complex system – a lined paper pad that I keep on my desk. If I see a patient I am worried about, or get back a mammogram or abnormal pap that needs follow up testing, I write the patient’s name on the pad with a little box next to it. That box gets checked off when I get her colposcopy or breast biopsy results back, or whenever the issue at hand is resolved. I work through that list every 3-4 weeks or so, crossing things off and recopying the few remaining items to a new page in the pad to start all over again.
I wish our EMR would let me create my own folders for tracking my problem patients this way, but it does not. So I use paper.
I am not writing this post to whine or complain (Well, maybe a little…)
Our EMR is fantastic, and our programmers are top notch. As I sit in my bed at night reviewing labs or catching up on that day’s notes, or catch a medication interaction that I would have missed in the old days, I am forever grateful for the fact that my practice is electronic.
The problem remains, however, that we are still struggling to get our EMR optimized. It’s a patchwork created from different systems, each designed to do what they do well, but not necessarily all speaking the same language. As a clinician, I remain frustrated that we still can’t get them to talk fluently to one another. And that is why, in my humble opinion, we are not yet ready for mandated electronic medical records.
A Government-mandated EMR or Tower of Babel?
The current EMR did not just spring up anew one bright day. It has evolved over decades – decades in which the laboratories, radiology practices, hospital billing systems and some upstart clinical practices each took their operations to the computer, using propietary software systems developed specifically for their own niche. Dermatology and infertility practices each have online systems that were designed for the kinds of work flows unique to their business. Hospitals also have their own inpatient systems, which don’t necessarily translate easily into the physician office, and vice versa.
With all these separate systems out there, and more coming every day, I think we need to stop and take a deep breath before our national quest for an EMR becomes a government-mandated Tower of Babel. I don’t think any doc should be mandated to have an EMR until we have EMRs that can talk to one another. And our initial investment should not spending money on willy-nilly mandated installation of Walmart’s and other vendor’s systems, but on first developing a unified code and language to be used for all EMRs. Then we can see which of the currently used systems will fit into that paradigm, and spend our dollars tweaking existing systems or scrapping them for new ones that are up to code.
Perhaps we can take our cues from the banking systems. Those systems all talk to one another with a common language that has to work, or someone loses money. I don’t know how theses systems evolved, who set the standards or how they got universal agreement, but someone out there must know. Let’s get those guys onto our medical records task forces and see what they come up with.
Until then, I’ll be plowing through my Patchwork EMR Tickler system…
- Thanks to Chris Bandover for the Elmo Video
- Read more from TBTAM on Electronic Medical Records
Most programmers are really good at figuring out a way to implement what you tell them to do.
Most programmers are really poor at figuring out what you need as opposed to what you said. They don't read minds well.
Most existing EMR systems are a combination of data collection and storage (the facts) and the workflows associated with these facts (e.g the follow-ups, ticklers etc.). The facts can be standardized but the workflows will vary from practice to practice and physician to physician.
Most existing EMRs handle workflows as if every physician/practice were identical.
To make mandated EMRs work they need to be focused on standardized facts.
There is a whole separate class of software products with names like workflow management or business process management which are focused on how facts flow between people and what happens when flows are interrupted (e.g. ticklers & follow-ups).
The advantage of these products is that since the flows are expressed in business terms they can be understood by, for example, physicians.
Most programmers hate these products as they are certain they can do the same job more efficiently, and they can; provided, of course, that they understand what's needed. Of course, if a change of course is needed later you have to make programming changes as opposed to re-describing the business process.
Full disclosure: my current employer makes such a workflow product (in a different division) and I've seen it in action in the context of a global credit approval system.
In that one, the idea was that you never got a request to approve credit until all the relevant facts had been gathered and the people responsible for gathering the facts got nagged on a regular predetermined basis (with escalations) until it happened.
When the rules changed, the business people got together and changed the flow with little (if any) programming needed.
Once you've seen a general workflow system in action you never want to go back to workarounds like paper.
While I read Grand Rounds I rarely read individual medical blogs; if you want clarifications, my personal email is Tom [the a in the circle] Littauer [dot] com.
I have fairly aggressive spam filters. If I don't answer immediately assume your post got eaten and make the subject line less generic. I review all spam rejections daily.
Thanks for an interesting read,
Tom Littauer