Case study
Hospital falls analysis
Analysis, visualisation and predictive modelling on a hospital falls dataset, taking a clinical data problem from raw records through to a working prediction.
Overview
A comparison of medication and treatment patterns between hospital patients who had suffered a fall and those who had not, across seventeen linked clinical tables joined on patient identifier: demographics, diagnoses, medications, vital signs and lab results, running to several hundred megabytes.
The brief was deliberately open. The client had done some descriptive work already, wanted analysis, visualisation and a predictive model on top, and said explicitly that he was leaving the choice of questions to me.
Complexities tackled
Being handed the judgment is the actual work. “Use your best discretion” sounds like freedom and is really the hardest part of a brief, because a wrong question produces a correct answer nobody needed. I answered it with a menu: around fifty-six candidate questions organised by theme, from cohort demographics and most-prescribed medications through to the same questions filtered by comorbidity, so the client could choose knowingly rather than approve a plan he had no way to evaluate. He picked seven, and was invited to add his own.
Refusing three of the client’s own choices. Two of the questions he selected resolve to a single number. A single number is a fact, not an analysis, and there is nothing to plot. I proposed rephrasing both as comparisons between the two cohorts, which is what he actually wanted to see. A third was a duplicate of one he had already chosen, reworded. Saying so cost me a paid question and produced a better deliverable.
Choosing models out loud, and naming the cheaper one. Both prediction targets were binary: will this patient fall, will this patient be readmitted. That rules out linear regression whatever its popularity, and points at logistic regression for the first and an ensemble for the second, since a single decision tree over clinical data with this many correlated features will overfit. I set that reasoning out, then offered decision trees for both as a cheaper alternative with the weakness stated plainly. The client took the cheaper option, which was his to take once he could see the trade.
Volume shaped the approach before any analysis started. Two of the seventeen files are over two hundred megabytes each. Loading everything into memory and exploring interactively is not available, so the joins and filters have to be decided in advance and applied on the way in rather than discovered afterwards.
Correcting a payment in my own favour. The client reviewed the first stage, said it looked good and paid for it. One of the revised questions had not yet been updated, so I told him before doing anything else.
Stack
Python with Pandas and NumPy over the linked clinical tables, Matplotlib for the visualisations, scikit-learn for the classification models.
Client feedback
Verbatim from the public review left on the completed contract. Clients are not named because the contract record does not carry names.
Nice guy. Skilled at coding. Would recommend that you bring your project to him far ahead of due date to give him ample time to work.
Working on something similar?
Tell me what you are building and what is in the way. I will tell you honestly whether I am the right person for it.