Circulation 60,475 • Volume 15, No. 4 • Winter 2000

Perioperative Data Collection

Chester Phillips, MD

In our perioperative run through, the first thing in our process is usually preanesthesia evaluation. In too many departments today, preanesthesia is considered to be the grunt work. We anesthesiologists naturally focus on the OR. We lose sight of the fact that preanesthesia is really very important. One reason it’s treated as grunt work is because nobody really has a handle on it. There are no standards. There is no process. There’s no obvious reward. It’s an activity that usually winds up at the end of the day standing between us and going home. In a lot of departments, we relegate this to the residents and tell them that it’s educational. So why is preanesthesia such a problem? It is important. It provides much of the data that we really need if we’re going to do meaningful safety research. There’s a synergy between safety and economics in preanesthesia. Computer communications that are a result of preanesthesia information can be used to promote safety. One of the points that we want to make today is that there’s a leadership role for organizations like APSF. In setting some preanesthesia data standards, engineering the preanesthesia system including informatics in the anesthesia curricula. It’s not currently being taught. We could emphasize the rewards of preanesthesia and the APSF has a role to play in facilitating the pooling of data for research.

What about the use of preanesthesia data in safety research? Dr. Caplan’s paper from 1988, "Unexpected cardiac arrest during spinal anesthesia. A Closed Claims analysis of predisposing factors," is one of my favorite papers of all time and one of the most meaningful to me in my 30-year anesthesia career. It’s one that I have quoted more times than I can tell you, detailing 14 young and healthy patients who arrested unexpectedly during spinal anesthesia and ultimately had bad outcomes, either severe brain damage or death. These were who were supposed to do well. It speaks to the fact that your hand kept records are not very worthwhile. Dr. Caplan excluded a number of additional cases because of the lack of data or faulty data (based on the recall of witnesses and hand kept anesthesia records) . A significant number of the anesthesia care givers admitted after the claim was closed that they were not paying attention at the time of the incident and later the following questions arose: Did cyanosis come first or did bradycardia come first? Did the patient arrest first? What happened? Who is susceptible? What do we look for? Is there a pattern? Could we prevent this? I think Dr. Caplan did a great job, but better data would have helped.

Thus, I was very pleased last year to find this abstract being presented at the ASA meeting. "Risk factors for bradycardia during neuroaxial anesthesia: A multivariate analysis." In this study, these investigators who have an anesthesia information system in their hospital and keep records on every case, at the time of this study had 57,240 continuous anesthetics online. They called out by query 6663 adults having non-OB spinal or epidural anesthesia without concomitant general anesthesia. They decided bradycardia would be less than or equal to a heart rate of 50 that had to last for at least one minute. They found 720 of these 6663 cases had at least one event. Now, if you look at the heart rate and the frequency of occurrence, you could say, well, a heart rate of 45-50, that’s low but it’s not that important. But there’s a significant number of really low heart rates here. Remember we’re talking about an occurrence that doesn’t happen every case. The meaning of this came even more to these investigators who published this paper. Dr. Lesser told me that shortly after he had sent the abstract in to the ASA, he was doing a case with a resident, and he walked into the OR to check on how it was coming and he looked at this computer screen and this is what he saw. He looked at that heart rate and he said, "My God, it’s happening right in front of my eyes!" And of course, he ran over and gave some drugs and the patient bounced right back. In such a case, careful attention to a few details would have warned of pending issuesÑoxygen saturations and cyanosis, change in oxygen saturation, blood pressures, heart rate. The underlying numeric values would indicate a slowing down in the heart rate over a period of 15 or 20 minutes.

Now, I don’t want to emphasize the study. That’s not my point. But the fact is, that data makes safety investigations much more meaningful. Computers are also capable, through the use of communications, of prompting us when there are safety considerations. I took some examples of some anesthesia alerts or questions that would come from your preanesthesia from asking the patient "Have you had problems in the past?" These notations would provide an alert to people who actually provide the anesthesiaÑwho may well NOT be the person who interviewed the patient. So, communication promotes safety, not only through the availability of medical records, but providing alerts. We also have a synergy between safety and economics. Economically, we’re all interested in preventing delays and cancellations because they’re upsetting and they’re expensive. But you know they’re also stressful to those of us who practice anesthesia. We have a lot of pressure on us to produce and to move the cases along. When important data is missing, we’re being pressured to move forward to the next case. Our goal here is to avoid letting a case get on the schedule if it isn’t ready.

So, if our goal is safety, what tactics can we use to promote safety? First of all, we need some standards for preanesthesia data. These are the basic standards for preanesthesia care from the ASA House of Delegates. As a data person, I can tell you these are not standards, these are vague guidelines. There is no standard here. What we need are standards of what type of data we want to collect based on the type of questions we want to ask. When there is no standard, every anesthesia department that puts in a system, wants to configure its own preanesthesia. And they all ask different questions. For the vendors, configurability is a great sales tool. "Oh, doctor, you know, hold the pickles, hold the lettuce, you can have it your way." But it makes it difficult to pool large groups of patients when you don’t have a standard for data. This is a data standard. Perhaps 10, 15, 20, binary data elements. Yes, no. Heart disease, lung disease, diabetes. Think about the types of questions you want to ask. How many patients with diabetes got bradycardic as opposed to others? The standard data set would allow us to pool data and make it much more available for doing some research. Then we have the process problem. Many of you may be familiar with the large German company, SAP which in English stands for Systems, Applications and Products. They’re the world leaders in enterprise resource planning. They have efficient well-designed software that can carry an enterprise business from soup to nuts. Their software is perfectly customizable. You can rewrite it to do anything you want to do. In the Wall Street Journal, they said that 65+% of their customersÑcustomers like Exxon, Mobil, Hewlett-PackardÑin fact, choose to re-engineer their companies to match the software.

We need to engineer a preanesthesia process to make it successful. Now you may ask why? What is the preanesthesia process? We have inpatient rounds, we have outpatient preanesthesia clinics, we have phone interviews. Some patients complete forms themselves. We have opportunistic interviews at any location. We have the holding area of course and then we have the door bangers who come from the emergency room right into the OR. My philosophy is that if you have seven systems, you have no system. We need to find a way of doing this. Organizations like APSF could promote the teaching of medical informatics in the anesthesia curricula. Right now it is not being taught. This is a preop note that I picked up in my travels around the country. It’s actually not a bad one. You can pretty much read it. As you see, this particular author likes the two-column format as opposed to the one-column format. I think it wouldn’t take a great stroke of genius to get all of you to realize that there is no easy way to turn this into data. Our personnel need to understand the meaning of data. They need to understand that free text paragraphs do not build databases. Even within my own private practice, I can’t tell you how many of my young partners will say to me, "I didn’t go to medical school to fill out a form, I’m a doctor, I write a note!" We have to get past this. We have to teach people to understand databases. We have to teach people to understand the kind of questions we want to ask and that data needs organization and structure. We can emphasize that there are rewards to doing a good job with preanesthesia by decreasing our stress level and making fewer mistakes.

The control of pooled data needs to be mentioned. The current situation for pooled data is that it is a vacuum. There’s nothing out there. You know, nature hates a vacuum and so there are vendors, and some institutions that are rushing in to fill this void. This will lead to the use of pooled data in ways that we in anesthesia don’t think are the right ways for it to be used. It’s only because no one in organized anesthesia is willing to undertake an initiative to get control of this. We want to have safety oriented patient data available perhaps over the Web. We want to identify and facilitate the pooling of data. But some organization needs to control it. Some organization that’s not a vendor and not an aggressive university. So, in conclusion, preanesthesia provides an important part of the data that we need for safety research and it can directly augment patient safety through prompting us about issues, through better preparation and through avoiding stress and mistakes. But we need leadership to establish data standards, engineer a process, encourage the teaching of medical informatics and control the pooling of data.