Danny Lieberman, founder of Pathcare; the private social network for a doctor and his patients goes back in time to 1973 and talks about a multi-trauma patient management system – developed in Israel during the war as a response to the challenges of locating patients with multiple injuries as they rapidly transfer between hospitals and departments in hospital.
This article is cross-posted from the Pathcare Blog.
As families and loved ones came to visit injured soldiers, the hospital staff found themselves unable to reliably know exactly where the soldier was hospitalized.
This was a frightening situation for the families and the hospital staff. Perhaps their son was no longer alive? Perhaps he was alive but had been transferred from the ER to orthopedics? Perhaps he had been transferred to Hadassah in Jerusalem? No one knew.
It is now 39 years since the Yom Kippur war.
Saturday (Shabat) October 6, 1973 found me in a synagogue near the apartment where I was staying, about a 20′ bike ride from the university campus. Born and raised in America, I was a foreign student in the second year of a graduate program in solid-state physics. The school year was due to start beginning of November.
Over 2500 soldiers would be killed, and over 8,800 injured in the Egyptian-Syrian surprise attack on that Yom Kippur.
It is impossible to describe the feelings of frustration I had, living in Israel and not serving in the Israeli Army. This year, 39 years later, the evening of Yom Kippur 2012, I found myself telling my own personal story to my Israeli-born wife for the first time.
This is the story of how a physics student, a statistics professor and a programmer/analyst from Canada developed a full-blown electronic health records system for multi-trauma patient management in a week.
That fateful Shabat morning, in synagogue, two men behind me were talking. I turned to them and asked what was going on. They told me “Don’t you know, there is a general callup, our sons have been called up into the Army”.
Later that afternoon, air-raid sirens went off and Saturday night, at the end of the fast, I went back to my apartment and turned on the radio to hear the terrible news of the Eyptian-Syrian surprise attack on Israel.
The first day, I holed up and listened to the radio. The next day, Monday, I took the bus to Tel Aviv and forcibly volunteered at the Ichilov Hospital – they didn’t have much for me to do besides directing traffic at the entrance to the emergency ward. After a day at Ichilov, they threw me out and I trawled for more volunteer positions and found myself a job substitute-teaching math at a high school in Tel Aviv.
After a tough day with a class of 7th grade boys, whose dads had been called up, the principal and I agreed that they didn’t really want or need me and I went to the campus looking for a gainful volunteer job.
At the unversity computing center, I ran into my statistics professor, Mitch Snyder and Professor Bruno Lunenfeld. Lunenfeld, a physician specializing in endocrinology and a trail blazer in treating female infertility, was in peace-time, founder and head of the Bar Ilan life science department . During the war Professor Lunenfeld served as a reserve officer in the medical corps and had been appointed spokesman for the Tel Hashomer military hospital.
I joined their conversation uninvited. Lunenfeld spoke with pain and emotion of the large number of casualties flowing into the hospital and how they were quickly losing control.
Snyder suggesting data entry of forms and printing daily patient location reports using SPSS at the university computing center. And – that is what we did for the first 3 days before we became overwhelmed with punch cards and paper.
At that point – I suggested to Snyder and Lunenfeld that we develop a system for multi-trauma patient management using APL, a language that I happened to be proficient in at the time. The version of APL we were using on the unversity IBM mainframe (a 360/60 running MFT) didn’t support a file system.
Snyder pointed out to me that not having a file system was a show-stopper for developing an application which required database management.
Not knowing what was impossible or not, I retorted that we could use APL*PLUS, which had been developed by IP Sharp in Toronto. Snyder told me “ok, hot shot, but how do you plan to use APL*PLUS, especially since the list price is $250,000 for a license?”. I told him, “no problem, we’ll call up Ian Sharp this afternoon and ask him for a license.”.
That afternoon, we called IP Sharp offices in Toronto and I asked to be transferred to Ian Sharp. After a moment on hold, I had Ian on the line and explained the situation. Ian, to his eternal credit, did not hesitate for a second and said “I’ll do better than provide you with a license, I’ll send a programmer/analyst with the tape and he’ll help you develop the application”.
Three days later, on a Monday, 10 days after the start of the war, Shaya Petroff (who was working at the time at IP Sharp) landed in Tel Aviv and we setup a base camp in the mens’ dormitory on campus.
First thing, I tried installing the APL*PLUS system from the tape and it didn’t work. Of course it didn’t work, but I had a friend who worked in the system group. The university had a stellar system programmer, David Lesser, who had been called up and was bolted down to a terminal in the Army computing center. I tracked down Lesser’s phone number in the Army and in a series of phone conversations between Bob Bernecky in Toronto and David Lesser in Ramat Gan, we worked through the night; I installed the necessary PTFs to get APL*PLUS to work on our IBM mainframe.
The next day, was spent designing a multi-trauma patient management system for Tel Hashomer hospital – in a dormitory room on campus.
Shaya and I coded day and night, and a week later, we had a working system which was immediately pressed into operation with terminals at the university computing center and in the hospital.
We were in production by October 25, just in time for the first cease-fire. Within just a few days of operation, we were accurately tracking the movements in the hospital of thousands of injured soldiers using the system.
After the first cease-fire, I will never forget naively asking Lunenfeld “what happens now??”. He coolly said, “even after the cease-fire, we are now admitting over 500 military casualties a day from traffic accidents” (from soldiers rushing to an from the fronts for short leaves with their families). “Now, we need to make sure that the information of how we treated these patients is not lost, this is a terrible but unique situation that must not be wasted.”.
And so, here is the story of how we developed a full-blown EHR system for multi-trauma patient management in a week.
What is a multi-trauma patient?
A multi-trauma patient is one who is suffering from injuries to different systems in the body. For example, a victim in an automobile accident may have a head injury, a wounded eye, and chest trauma with damage to internal organs, with an abdomen which seems to be hard.
From the point of view of hospital admission there are two basic differences between this kind of patient and the ordinary hospital patient.
One is that the ordinary patient is usually expected beforehand. A file has been opened, a bed is ready, and the staff know fairly well which resources and services he will need and for how long.
The second, is that the ordinary patient is usually admitted for a disorder on one system only (or a number of related systems) and therefore spends his entire hospital stay within one department only.
The multi-trauma patient shows up unexpectedly, often incapable of helping the administration to open a file or of verbally assisting the medical staff to diagnose all of his disorders. The hospital has to decide what is the primary disorder that requires first priority attention in order to set-up a medical team (usually a surgical team) accordingly. Also, the patient will probably be moved from one department to another during the course of his hospital stay.
In the example mentioned above, the Neurosurgery Department would be primarily responsible for the treatment of the head injury, Ophthamology for the wounded eye, Chest Surgery for the chest, and the General Surgeon will have to be consulted for the abdomen.
When a disaster occurs, the hospital is suddenly faced with large numbers of such patients. For example, an earthquake, a tornado, an avalanche, a railroad accident, a shipwreck, a bus collision, an explosion, a riot or a war would send large numbers of multi-trauma patients to one or more hospitals.
Medical rescuers on the spot would have to make preliminary diagnoses and decide to which hospital to send which patients.
In this paper, we are not concerned with the medical problems involved in the diagnosis and treatment but rather with the administrative problems involved in deciding destination, record-keeping and following the movement of these patients.
We are also concerned with the ability to analyze statistically the wealth of information gathered in such instances.
Because of the relative infrequency of multiple injuries, it is difficult to obtain statistical information on the effectiveness of various treatment methods. But when a disaster occurs, large numbers of patients are treated for several concomitant disorders over an extended period of time (including the rehabilitation period).
The data made available should be stored in a database in such a way that statistical analyses may be performed to shed new light on the effects of various treatment methods.
These data must be stored anyway, for purposes of administrative control on each patient. It would be desirable if they were stored in such a way as to afford scientific study of each of the items of information.
The system described in this paper was written in APL Plus and enabled hospital management to cope with the admission problems, keep track of patient movement and provide medical researchers with valuable data for analysis.
Tasks for multi-trauma patient management
The tasks of managing a multi-trauma patient may be classified according to four time periods:
- Before the patients are sent to the hospital at the site of the disaster
- When the patient is admitted to the Casualty Dept.,
- Before the ward physician’s or consultant’s rounds, and
- Whenever a change in the patient’s status occurs.
The first on site task is to determine a preliminary diagnosis for each victim and which type of medical team will probably have to treat him first.
Then a priority has to be determined for the order in which victims are sent to the hospitals.
The next decision to be made is to which hospital to send each victim. This decision depends on the preliminary diagnosis, on the availability at the hospital of an appropriate medical team, the availability of hospital facilities (e.g. operating theaters, beds), and the time of transport to the hospital (which may depend on the existence of a heliport or dock at the hospital).
Thus, it is necessary that the on-site rescuers should have up-to-date information on the availability of medical teams and facilities for each hospital. They should also be able to communicate to the hospital relevant information on each victim who is to be sent, so that the hospital can prepare itself for him.
At the hospital,the patient is reexamined, diagnosed and assigned a first medical team. He is also assigned to a bed in a department. The hospital must then remove from the availability lists whatever resources the patient is now using (e.g. surgical team, operating theater, bed in a department). A permanent record is also opened for the patient.
Before rounds, the physician must be handed up-to-date information on all of the patients in his department. Thus, as patients move from one department to another, their records must “move” with them. In addition, it is imperative that the information desk also be notified of transfers so that family members and loved ones may be directed accordingly and callers may be notified of the patient’s general condition.
Whenever a patient’s condition changes, or a new disorder is detected, or an old one improves, or the patient is transferred to a new location, his electronic health record must be updated as soon as possible.
Requirements for the multi-trauma patient management system
The system had to be a fully interactive application, with flexible data management and access.
First, many hospitals and departments are involved and the ability to know where a patient is currently located is crucial from the perspective of families and staff.
Second, queries to the data base are required by the on-site rescue team, by the information desk when visitors arrive, and by physicians at any time.
Third, new medical records should be opened as soon after admission as possible.
Fourth, the patient’s record should be updated as soon as possible after the physicians have completed their rounds or a patient has been transferred.
Technical implementation constraints
The language of implementation had to be practical for both administrative and scientific applications.
We wanted to perform updates and report generations as well as statistical analyses on the same data base. This is a rather difficult requirement.
Usually, administrative data models have flat table structures where search is the most frequently performed operation and data is either required or set with a default value.
On the other hand, statistical survey data are usually stored in a matrix form (e.g. subjects by variables) where missing data are indicated by blanks or some other symbol that takes up space.
Arithmetic operations are much more frequently performed than searches or sorts.
The system also had to have several levels of privacy in order to guarantee medical confidentiality.
Considering the time and application constraints, APL PLUS was chosen as the most suitable development environment we could find at the time.
The full paper including a description of the data model was first presented at the APL 75 conference in Pisa, Italy by the author (Danny Lieberman). The original PDF can be downloaded here HOSPITAL ADMINISTRATION OF LARGE NUMBERS OF MULTI-TRAUMA PATIENTS.
Danny
Danny Lieberman is the authority in applying threat analysis to Governance, Risk, and Compliance (GRC) in healthcare. He is a sought-after speaker, prolific blogger on healthcare technology, and advisor on software security and privacy compliance issues to healthcare and medical device vendors. He is passionate about Pathcare: the private social network for a doctor and her patients. Danny is a solid-state physicist by training, professional programmer by vocation and avid amateur saxophonist and biker.
Join with Google
Join with Facebook
I enjoy what you guys are usually up too. This type of
on April 24, 2013 at 6:36 pm coffee beanclever work and exposure! Keep up the fantastic works guys I’ve included you guys to our blogroll.