Given to me by Brigadier General Dunn
This is a citation/medallion presented to me by Brigadier General Dunn. He handed them out to Dr. Hamm’s programming team at Walter Reed Army Medical Center, where he used to command before he was transferred out to the Western Regional Medical Command. After our oasis of development dried up at Versient and it became Shamrock Acquisitions. I discovered that my friend and former co-worker Adil Asik had found a new job programming at Walter Reed. He introduced me to his boss, Dr. Carolyn Hamm, and in short order I found myself working on her team. It was only a couple of years after 9/11/01 and most of the gates to the hospital had been blocked with concrete barricades; every day I passed through a checkpoint and had my briefcase or laptop bag searched by armed soldiers.
The challenge of medical data is not gathering it. The challenge is making sense of it. Each disease process has its own dangers, its own warning signs. To help physicians follow clinical practice guidelines, Dr. Hamm’s team was creating active server Web pages that interrogated the medical database and displayed patient data in a quickly-assimilated format. If a diabetes patient is being seen, for example, the information the doctor needs to gather and review is different than it is for a COPD patient or for someone diagnosed with Congestive Heart Failure (CHF).
The basic idea was the same for all 8 disease processes we were working on. Once a doctor has logged in and selected a patient, get that patient’s relevant records from the database and display it, prompting the physician to take more readings to update the data when appropriate.
So far, so good. But since the questions the doctor needs to ask each patient (and the tests to perform) are different with each disease process, Dr. Hamm’s team was working on 8 different medical “scorecard” web pages, one for each kind of disease. For purposes of rapid development, the “questions” on each kind of scorecard page were “hard-coded” (never changed) text like “Blood Pressure: ” but the “answers” were filled in from the data base.
I looked at this and realized that the disparate efforts could be combined. Just as we physicists like to say that all known forces are just aspects or versions of a single unified “superforce”, I felt that the different medical scorecards could be seen as merely differing versions of a single unified generalized medical scorecard. The solution was to put the questions in the database, too, as well as the answers — and to identify for each Question record just what kind of disease process it is associated with.
Let’s say I want a Diabetes scorecard for John Doe. As a physician, I log in and select John Doe from my patients. Naturally, the system knows that he has both Diabetes Mellitus and CHF scorecard data recorded. I select the Diabetes scorecard. When I click that link on the browser, it sends a request to the server; the server-side script runs and pulls (a) the text of QUESTIONS to display for any Diabetes scorecard, and (b) the records in the database that answer those questions for John Doe.
Once it has both the questions for Diabetes and the answers in the case of John Doe, the server can send out a completed web page summarizing the condition of John as last recorded, along with reminders for periodic updating. Glancing at the screen, I can see that his last blood sugar (HbA1c) reading and a note that a follow-up foot exam should be performed. If I had been looking at his CHF scorecard page, it would, instead, have displayed his most recent cholesterol and blood pressure readings, and so on.
The idea is simple, but powerful: pull it together and summarize only what the doctor needs to know about this disease for this patent. Don’t make me scroll down a list of all the test results and hope I find the correct patient’s numbers. Don’t make me flip from page to page to find the results of several different tests for the same patient in a chart or clipboard. Jut go get it all and put only what I need together, all on one page — and do it NOW.
I’m sure this is old news to many medical programmers, and you can see the obvious display opportunities, such as a tabbed page with a tab for each disease process the patient is involved with.
After we created the initial setup and transmitted copies of our source code to other military hospitals such as Madigan on the West coast, our next task was to find ways to mine the medical data to detect and display trends in the patient populations. The result of this was a paper presented at the IEEE conference on medical computing: “An Operational Data Store for Reporting Clinical Practice Guideline Adherence in Chronic Disease Patients,” IEEE Proceedings, Computer-Based Medical Systems 2004.
While I still wasn’t making much progress telling the world about Hypercube Speakers, my time was not wasted programming at Walter Reed. While I was on Dr. Hamm’s team we wrote some cool and useful code. But it would not last forever. The Army has a budget, and the Surgeon General of the Army has to make tough decisions sometimes. As a result of budget cuts, I said goodbye to Walter Reed and moved on in search of my next job.
–MRK
Sometimes I can’t help myself: I have to add ANOTHER category or section to the blog on top of all the things I am covering already.
But, again, why did they choose this particular bird to represent the god of Writing? Some believe that the earliest forms of writing, such as Sumerian cuneiform, arose near swamps and river valleys because the available weed stems and mud gave free writing materials. The Sumerians could break off a stem of the papyrus plant (also common in Egypt) and use its triangle-shaped cross section at the tip to poke various arrowhead-shaped holes in the mud, which was then dried in the sun or baked to fix it permanently in that shape.
