Every solution needs a problem
Time to stop tech-tinkering and look at the problem. Nothing worse than a solution looking for a problem. There were three things that the clinician wanted to identify: blood values that were out of range, deteriorating trends in blood values, and people who didn’t attend for testing when expected (DNAs). It was true (and still is) that the laboratory flagged up abnormal results, but their ranges were too crude (male/female), and more granularity was needed. So there was a requirement to identify results specifically for the patients he wanted to monitor. And then configure rules in the database that would check for abnormals, trends, and DNAs. Oh, and that rule setting had to be flexible – clinician wanted to be able to set up his own drugs and monitoring profiles. And add patients and so on. No black box technology that required expensive ‘programmer’ support.
Inconvenient for patients
So the requirements were reasonably clear, and the results were available. But there was another problem. The patients that the clinician was interested in had to come to the hospital for their bloods to be taken, otherwise the laboratory didn’t know which results to send out. And sending all patient results out, every day, was complete overkill (until some years later, when it became the norm). Besides, it was time-consuming and inconvenient for the patients and the hospital to have them come in just for a blood test. A more community-based approach was required.
A bit more investigation and engagement with GP-based phlebotomy services and a novel solution was found. A special code (RheMOS) was added to every physical blood sample form taken by the community-based phlebotomy service. That code was entered into the lab system on receipt of the physical sample and the electronic result found its way to the RheMOS system by virtue of the code. And the best bit for patients? No more visits to the hospital for blood testing – just pop into their local surgery.
