Almost two years ago, the team at Obvious got an opportunity to build Simple, an app that leverages technology to help busy clinicians manage hypertensive patients by tracking their blood pressure measurements and medications. The first project from India to ever win the top prize of the “Best in Show” category at the 2020 IxDA Awards, this free and open-source project is a fast and disruptive mobile based application that is currently deployed in more than 1300 facilities in India and Bangladesh and manages 400,000+ patients with hypertension.
When we first commenced work on this project, one of our key goals was to protect patient data. And as a part of this, one of the decisions we made early on was to not require any government issued ID when registering a patient in the system, something that has not changed at all till now.
However, this introduced a new problem around how to help users of the app efficiently find a patient when they return for a follow-up visit. Healthcare systems have always struggled with looking up patients and ensuring that they are matched to their own medical information across institutions and time accurately, especially on a greater scale. We therefore tested several existing methods, each with varying degrees of success.
Searching for a patient by name
We implemented a “fuzzy” searching mechanism built on top of Levenshtein distance, in order to account for variations in name spellings, typos, and more.
While it seemed to work at the outset, we soon came across a hurdle when we discovered a number of patients with the same names. A particularly bad case was a certain district in Punjab where over 20,000 patients were registered in the span of a few months all of whom had the exact same name, making it impossible for the nurse to find the right patient
Searching for a patient by phone number
We (optionally) allow users to register a patient with their phone number. This lets users call or send reminders via SMS to the patients and remind them about their upcoming appointments. We then administered a search mechanism that allowed users to look up patients by their phone numbers.
While this worked really well, it had its own limitations due to the fact that we do not mandate collection of phone numbers and don’t want to either. Moreover, patients sometimes do not have phone numbers, don’t remember them or change their numbers periodically as well, not guaranteeing a 100% identification of the patients.
The birth of BP Passport
After much consideration, we decided to employ a physical patient ID card, called the “BP Passport”. This intended to not only solve the problem of finding return patients effortlessly and quickly and maintaining a longitudinal record but also ensure that the right patient gets the right care by avoiding duplication.
Each BP Passport has a QR code printed on it, which encodes a full UUID that is the passport ID. Since patients tend to lose their cards quite often, we decided to have a card ID instead of a patient ID so that a patient can be associated with different QRs and can have multiple cards. The BP Passport also has a 7-digit number printed on it, called the “short code” that is nothing but the first 7 digits of the Passport ID.
Technical summary on creating BP Passports in this link
The nurse can scan a BP Passport and assign it to a patient during registration, which the patient then carries to all their appointments. We designed this in a manner that introduces as little friction as possible and integrates into the workflow of the nurse. The Simple application is then capable of scanning these BP Passports to look up a patient within seconds.
P.S. Here’s a quick video of how it all works together.
Generating BP Passports at Scale
The next step was to print and ship these BP Passports ahead of time
to our users so that they could spend their time doing what was
important: patient care.
The problem:
The high rate at which the patients were getting registered in the
system entailed printing and shipping thousands of BP Passports at one
go, to ensure that they would last the facility for a few months. The
roadblock that we ran into hence was the problem of generating these BP
Passports at scale.
The trial:
We initially used Adobe InDesign and specifically, the Data Merge feature. We would create UUIDs in a spreadsheet that had formulas to produce the short code from the UUID. This spreadsheet would then be imported into InDesign and used to generate the BP Passports.
What we quickly found out however was that this only worked for
generating a small number of passports, since InDesign froze when
working with a large number of passports and took hours to process them.
This meant that we would have to manually generate them in small
batches and save the final PDFs to be printed manually, which definitely
did not act as a long term, usable solution.
The solution:
When we consider a BP Passport, there are two sections: A static section that does not change from one passport to another, and a dynamic section (the QR code and the short code) that could differ between passports.
The clear sections in the image above are the “static” sections of a BP Passport, i.e, the parts that do not change.
The clear sections in the image above are the “dynamic” sections of a BP Passport, i.e, the parts that change.
Therefore, what we needed was a tool that would accept a BP Passport which has the static section filled in and the dynamic sections left blank (which we call the Passport template) and would be able to generate passports of a given number to be then sent for printing.
We settled on writing our own tool to solve this specific problem and chose to use Apache PDFBox and the JVM (partly because it was a platform that the team was already familiar with, and partly because PDFBox had support for generating PDFs with CMYK color space, which was essential for the print material) in the Kotlin programming language.
The tool was written specifically to take advantage of multi-core processors and generate large numbers of passports in parallel. On a modern MacBook Pro, we could now generate around 40,000 BP Passports in just around 30 seconds!
This translated into us being able to print and ship over 450,000 BP Passports to five states – Punjab, Maharashtra, West Bengal, Andhra Pradesh and Karnataka in multiple languages such as Punjabi, Marathi, Bengali, Telugu, Kannada and Hindi – all between October 2019 and May 2020!
150,000 BP Passports we shipped to Maharashtra, motor vehicle for scale.
Being able to manufacture such a large number of BP Passports ensures our clinicians are empowered, and can focus their efforts on improving hypertension control and preventing heart attacks and strokes.
As with all the software by Simple.org, the source code of the tool is available at https://github.com/simpledotorg/bppassportgen.
Like what you read? You'd probably love working with us, then! Head to our hiring page if you want to join the team, or check out our services if you'd like to hire us for a project instead.
