Given the real-time nature of the problem, the natural choice for programming the data acquisition part of the system (we would call it the "Collection" system) was assembler language.
The instruction set was natively 32 bit with 32-bit registers. It could handle double words and quad words, as well as bytes and halfwords. It resembled the 360, but indexing was more convenient, as accessing a doubleword array did not require multiplication of the index. The entire register set could be saved in with one instruction, and later restored. There was a set of stack instructions. Individual stacks could be defined by Stack Pointer Doubleword.
Thus, you could have many stacks.
This is a very nice instruction set, and one of my favorites, right up there with the PDP-10.
The analysis program was written in Fortran and at its core used a decision table. The inputs to this program were measurements of wave amplitude, duration, spacing, and slope.
As calls came in from hospitals all over the United States to our data center near O'Hare, the data would be written to tape and fed to the analysis program. The analysis program produced an English-language report on the interpretation of the ECG. This would be sent to the hospital to a printer within an hour, and later, within 10 minutes.
The alert reader will wonder if this is practicing medicine. It was made very clear in the representations to hospitals and everyone involved that this was not practicing medicine. It turns out that reading and ECG to the level that is classically done is not difficult and does not require a medical degree.
It is something that a non-medical person can begin to understand with a week's training.
Later, Telemed offered a service to have licensed doctors review the ECG and the report and give a professional opinion. This was called the "Overread" service.
We used two operating systems.
The real-time work was done under RBM for "Real Time Batch Monitor" and the other was BPM, a time-sharing/batch processing monitor.
The Collection system, which ran the ECG collection data, was up 24 hours each day. In the beginning, the analysis was done on the second computer. The Collection system would write the data to tapes and each our or so, the tape would be carried over to the analysis computer.
Later, we were able, after a fair amount of work, run the analysis on the Collection system. During the period of building this combined system, we would only get access to the development system at night.
Even though the RBM system was targeted to real-time data acquisition and control, it would occasionally mask all interrupts for a brief period. This was a challenge for us as we felt that this could delay our 2 millisecond acquisition interrupt enough to result in an erroneous sample in the part of the electrocardiogram with a steep slope, such as in the rise of the QRS wave .
I did an analysis that showed that the delay due to the timer lockout was enough greater than the quantization error. Thus, with each release of the operation system, I would need to find all of their interrupt masking instructions and modify them to not mask the timer interrupt. The intent of the mask was to be sure that there were no multi-thread errors--that is, no operating system requests would happen during the masked interval. Since we were in control of what happened under our timer interrupt, we could ensure that there were no operating system requests triggered directly by the timer interrupt code.
Since there were many telephone lines potentially simultaneously sending data, we needed to address our multi-processing problem, also called multitasking.
