It is one thing to be given the green light to explore possibilities. It is quite another thing to take that exploration and boil it into a single quest. No matter how obvious the need, if the solution defies people’s expectations, then the path becomes strewn with obstacles. I was doing sales training on Texas Instruments programmable calculators, and we had been having little success trying to bring programmables to the consumer market in large department stores. People were basically terrified of these devices. One bright associate at TI said that basically what we had to do was “de-terrify” people before they could appreciate programmability and become customers. Panasonic had an advertising slogan back then that was brilliant.
The slogan Panasonic used was “Just slightly ahead of our time.” This was a deterrifying slogan. People knew the technology Panasonic was offering was not so futuristic that they would not understand it or, even worse, look stupid trying to use it. It was many years later that the Business Analyst brought the TI programmable calculator into widespread use, and that was only after most of those customers already owned personal computers. It seems we humans don’t instantly make the connection between what we know, what we need, and what advancement you are proposing. A great deal of the process involves most people digging their heels in, resisting learning anything new. Customer Education then was the major problem with those extremely useful calculators TI was trying to sell.
Fresh off that resounding failure — with business people not knowing why they needed cube roots, and not wanting to admit they did not even know what a cube root was — I accepted the training manager job at the American Heart Association. There I began to see the need for an android CPR simulator. The path of CardioPulmonary Resuscitation (CPR) itself had been long and sketchy since it appeared as a painting in the ancient Egyptian Temple of Medicine and even in I981 was only just becoming respectable in lifesaving circles. The AHA was in Dallas, but Seattle, where I grew up, had created a mass outreach in training ordinary citizens how to respond to a heart attack with CPR, and from that example people everywhere began to understand that they might need CPR someday.
In no way did anyone anywhere know that they needed a simulator to proliferate CPR. Thus, parallel to making a piece of equipment that no one had ever envisioned, I had to make a case for something no one had ever voiced the need for. As a design pathway, I decided I would take all the problems that currently existed with teaching CPR to the millions who ( , according to the Gallup Poll,) said they wanted to learn it in the near future. Then – simple – I would flip each problem into a solution. That would set forth the basic design needs of the simulator. Here were the problems:
- Logistics – Whatever organization was teaching CPR had to find and schedule a room that would hold about 20 people for the lecture and hands on approaches. With small classes given at odd intervals, teaching millions of ordinary citizens would take an impossibly long time.
- Performance Feedback –Students did not have an easy method of understanding the effect of their performance in decision making and in manual application of CPR.
- Message Inconsistency – Whenever CPR was taught, even with one of the several manikins available, the material varied a slight bit, and sometimes a lot, depending on which instructor taught it.
- Testing Inconsistency – When testing was done on the students, the evaluation by the testers was highly variable even though they had checklists. Often other instructors, with their varying viewpoints, were the test evaluators.
- Performance Recording – Along with inconsistencies in Message and Testing, the records of which students attended when and received which scores becomes an immense record-keeping problem
- Instructor Burnout – Possibly the greatest detriment was volunteer instructor burnout. Instructor qualification took some time and dedication, but then the average number of classes each instructor taught was five, before they called it quits.
So this great, wonderful phenomenon of citizen CPR could assure that a capable person would be there the exact minute when a life was ebbing from the body down on a city sidewalk or at a wedding party. However, it was the problems, the obnoxious practicalities, that made CPR in ordinary citizens only a weak possibility. Logistics and continuity would doom its promise. That is why we needed a CPR Learning Simulator. Flight Simulators taught pilots to bring planes in safely. Why couldn’t a CPR simulator teach people to save lives, right at the spot of a heart attack and at the very moment the victim lost consciousness? The rest of a victim’s body could carry on much longer even with the heart stopped, but the brain was key. Many, many victims lost their brain function, forever, before the paramedics could arrive. The father, or uncle, or elder sister, or young girl in the pool — each had about five minutes until their brain began to die for lack of oxygen.
When I finally got my chance, just in time and with limited credibility, I presented the idea to the Emergency Rescue Working Group. The advantages of a CPR Learning System were clear. The vision was mine and with limited funding and 6 months to work on it before the midyear meeting, I got the opportunity to show it. I told them I would prototype the simulator with interactive videotape and be able to give everyone the clear idea that was possible. Notwithstanding the fact that interactive videotape had not been invented, and was thus an obvious design objective as well, here is how the final simulator had to solve the variety of problems we had observed.
- Logistics – If the CPR Learning System, based on simulation, could be available 24/7 in a small, dedicated room, vast amounts of scheduling and notification would not be needed, and thus many more students could be taught in a given week. The scale of CPR learners – and thus heart attack survivors – could be scaled upward with one-time investments, IF the equipment were affordable and available.
- Performance Feedback – The students should be able to see and feel the effects of their performance on a manikin in real time, and with that instant feedback on their every move, they could rapidly adjust their performance until it was satisfactory.
- Message Inconsistency – Although there were adequate textbooks and lesson plans, the variety of emphasis due to individual instructor differences, led at times to poor decision-making by somewhat confused students. A computer-learning program would be the same every time.
- Testing Inconsistency – Since CPR was beginning to be required by various paramedics, firefighters, police officers, and hospital workers, the end performance needed to be extremely consistent so that these various emergency workers, and hopefully ordinary citizens, would be compatible between anyone involved when there were seconds to spare in the life of the victim. A computer program based on input could solve this.
- Performance Recording – The difficulties in maintaining records, especially when CPR certification was required for various jobs, could mean people’s livelihood, in addition to complicating planning by emergency facilities. Computers are excellent at record keeping, and this presented a way to integrate a standard CPR on a broad scale.
- Instructor Burnout – The CPR Learning System could teach the students one on one without an instructor present, and thus the training could be in constant operation 24/7 through many weeks and months if the demand continued.
As it turned out, the interactive videotape for the instructional part could be controlled by an Apple 3 computer, with a special card that accessed individual frames in the way computer editing was conducted in making television programs. Not easy, and not even obvious. But doable. Clearly the straight video education could be presented. Also it could be interactive so that when the student touched the screen with a light pen, he or she could answer questions and if necessary, have remediation – in pictures and demonstrations – brought up immediately.
On the other hand, a truly difficult problem presented itself, the simulation of hands-on CPR with real results, with sensors in a manikin processing input data in nearly real-time, and showing ongoing results instantly on a second computer screen. We first attached a number of different sensors to an existing training manikin, Ruscussie-Annie, and made a display box with various lights for on-off touching and analog gauges for depth and length of compression. That way we could see the signals coming from our variety of sensors in the manikin. Friends and detractors alike came to call this supersensitive manikin the Anatomical Keypad. Then “cutting the cords” and attaching them to the special computer card to read and process them drew our modest cheers for ourselves. It was truly a birthing process of a new kind of training, and a sensitive manikin for CPR was born.
With 35 more years gone by now, the various toys and computer games make this challenge seem somewhat trivial, but at the time it was like playing God. It was truly the “laying on of hands” and we could actually tell, and document what would be happening to a victim, and evaluate a rescuers’ performance before a real victim lay before them.
Because real-time computer-graphic overlays of video pictures was not a reality yet, we needed two screens, one for the didactic instructions and decision-making protocols, and a second screen to show the graphic results of manual input to the manikin. The students would look up from his or her compressions and interact with a light pen on the screen, and be able to see their placement, depth, and timing in exactly the same moment they were performing CPR on the manikin.
When we returned to the 6-month meeting of the Emergency Rescue Working Group, the doctors were both fascinated and reticent. The real time graphics responding to their light pen were clearly impressive, but the doctors had two very serious reservations before we could move on. First, they said, we would need different CPR courses for nurses and cardiologists, of course, in addition to those for civilians and non-medical hospital workers. The first question, different course for different levels of medical knowledge could present death by complexity to the CPR Learning System. I immediately feared an infinite cacophony of levels of medical power impinging, creating a hierarchy of concerns and more separate course than I, or anyone, could put together to the satisfaction of the multitude of interest groups. I did not want to offend, but I answered as simply as I could:
“The victim doesn’t care.” I said. “The victim is unconscious and has only a few minutes to live.”
They seemed to focus on that. “ But one doctor said, “but there are special skills some of us know.”
I knew I could not let this CPR Learning System become an elitist toy. “I think the victim just wants to breathe, and just wants his heart to start pumping. If I am the only one there I will have to know enough to save him.”
Wrinkled eyebrows. How could I say these things not being a doctor?
“Look at it this way,” I said. “Johnnie Rutherford won the Indianapolis 500 four straight years. He is probably the best driver in the world and he lives right here in Texas, right over there in Fort Worth. And yet I am really glad that Johnnie Rutherford has to have the same Texas State drivers license that I do, because that means he’ll drive on his side of the road and stop for red lights, just like I will. And in CPR, if I am doing it with anyone, I want to know you are doing the same things I know have to be done, right then, right there, with no second opinions.”
Ok, they agreed, we’ll assume a standard vanilla course will be prepared at first. Whew!
Then secondly, they could not, even with my technical explanation see why we could not just use one screen. I was technically constrained to the two screen approach. The overlays and interleaving that we now take for granted were not possible then, on a small portable computer and a commercially available videodisc player. One screen took the light pen input, and held the pictures, video, and artwork on a videodisc, 54,000 frames to be managed by computer. On the second screen the computer gave easily understandable computer graphics that represented performance on the manikin. However, I knew that I needed a better answer, and pulled this one from somewhere.
“If a group of doctors were creating the first human being, someone would say ‘why not just one eye’ or ‘why not just one ear?’ Because our bodies needed to operate in 3 dimensions, and two eyes and two ears let us perceive in stereo.”
True, but two screens?
“Yes, it gives the student a stereo learning experience, a right brain for what they see and a left brain for the data they need.”
Well, they did not run me off for that. And in a few months I got the funding for what would be an early 1980s demonstration that machines and people could work together in learning CPR, something which on the streets, in broad daylight, was most crucial to life and death. There were more obstacles to come, as usual, but this much we knew to be true.
See the early CPR simulator in the World Book Encyclopedia.
