A couple of years ago, I developed an ‘operational support system’ for anaesthesiologists
working in the OR. Other than the main goal of enhancing Patient Safety by helping the
docs remember to do all the things they need to do before, during and after a surgery, the
requirements for the product were quite vague. This wasn’t particularly surprising to me
as this concept, though not new, had never been implemented as a computer system that could
be used in operating rooms and while certainly ‘technical’ to some degree, my customer was
not versed in software development and really didn’t have many expectations beyond the
implementation of his core concept. Anyway, with that comforting level of detail, I set out
to design a system that would both meet the main goal while at the same time being able to
accommodate the inevitable “oh yeah, we should be able to do, too – that won’t take
too long, will it?”.
The overall uncertainty of the requirements, plus the academic/research nature of the project
suggested to me that a flexible, easily updated central datastore was probably in order, though
the customer had said he just wanted a standalone app. The fact that the end user devices (iPads) would be
used in the OR during surgeries and my assumption that there would be an ‘airline level’ of
superstition regarding the potential impact of WiFi capable devices actually
being online during surgery indicated that the end user device should only need to be able
to communicate with the central database when convenient, e.g. before/after surgery, during
cleaning, etc. As well, I figured that at some point my customer was going to want to actually
track how the product was being used and, eventually, correlate that usage to some
(hopefully positive!) impact on commission of medical errors, overall increase in
Patient Safety and, perhaps, a reduction in the institution’s malpractice related insurance
premiums. Considering all these requirements, the system architecture that emerged was as follows:
- central database supporting easy schema updates
- end-device resident database that could be updated from the central database as well as
be used to track app usage information - some method of propagating changes from the central store to the end-device and usage
information from the end-device to the central store
That last point was a bit worrisome: I’d worked on systems before where syncing databases
was a requirement and knew that developing a method of syncing could be both challenging and
time-consuming to implement (and we were on a tight budget). So, slightly concerned, I set
about Googling for an appropriate infrastructure,
preferably one that didn’t involve me writing a sync subsystem. Through a combination of decent
search term selection and clever marketing, I stumbled on the suite of products from
Couchbase. I was only vaguely aware of Couchbase at the time, but scanning quickly through the
text snippets on the Google results page, Couchbase looked very promising! Indeed, not only did
they have both server and mobile versions of their database, but they also offered a ‘Sync Gateway’
component that was supposed to do all the heavy lifting of syncing mobile and server databases.
Hallelujah!!!
Delving further, choosing Couchbase products as the infrastructure for this system seemed
like a solid decision:
- their documentation was decent
- both server and mobile versions of the database (and associated SDKs) seemed mature
enough for my purposes - the Couchbase organization itself looked relatively extensive and so not likely to
disappear in the near future. In any case, the source code for pretty much everything
I’d be using was open anyway - sample code was available and there appeared to be a lively community using the products
Long story short, I ended up committing to Couchbase products and have never looked back.
The mobile side of the project was implemented using Couchbase Mobile for iOS and the server
side was underpinned by Couchbase Server, with Sync Gateway joining them and, to my great
satisfaction, all working together correctly and reliably. I’ve had such positive results
with Couchbase that I’ve used the same suite of products to implement a simple medical record
system for Upright Africa, an organization providing much needed medical care in the
Democratic Republic of Congo. Early on, before Couchbase offered an encryption option for
Couchbase Mobile, I was able to extend the base mobile product to use SQLCipher, and so maintain
some enhanced control on the visibility of the data. This wouldn’t have been possible, of course,
if the mobile software had not been made openly available by Couchbase on Github. To Couchbase’s credit, their products continue to evolve and user-implemented enhanced encryption is no longer required.
Overall, I’ve been impressed with the quality and feature set and performance available in Couchbase products and wouldn’t hesitate to use them again in the future, should appropriate projects present themselves.
