So, I’m taking a break from technical writing related thoughts and posts for a while. For the next two months, I’ll be focusing on the development of, I suppose you could call it, my side project for the past few years. While, I’ve been working on this for the past four years, or so, it’s starting to gain some momentum.
The piClinic Console.
The project’s website, http://piclinic.org, says,
“The piClinic is an open-source, patient-record automation solution designed for limited-resource healthcare clinics around the world. piClinic systems fill the gap between a paper-based patient-record system and a complete Electronic Health Record (EHR) system at a very low cost per system. The piClinic is built on the digital principles to provide an accessible, sustainable, and low-cost solution.”
No, seriously, what the heck is a piClinic Console?
Here’s the story.
The piClinic Console is a low-cost option for small, health clinics with limited resources and who keep their patient records on paper in file folders, to start automating those records and keep track of them with a computer.
Why do these clinics need a computer?
Well, they don’t, really, need a computer, but automating some aspects of their record keeping provides benefits that they can’t easily obtain with a manual system. For example, tabulating aspects of patient visits is tedious. Current systems include collections of logs and tally sheets that are tabulated manually. This is a system that does not scale well. Additional patients add more work. Additional summaries require new tabulations. Computerizing this would simplify the clinician’s work by moving it to the computer and software developer. Automating this data also has benefits for public health data collection and research.
Hasn’t this been done before?
Yes and no. I’ll be the first to say that the last thing the world need is another Electronic Health Record (EHR) system. EHRs have been around for quite some time. Patient record automation, in which only basic patient and visit information is computerized) has been around longer still. However, the systems on the market assume (or require) considerable access to a sizable technological infrastructure that includes such things as powerful computers, broadband Internet, cloud services, and more. For many of the clinics the piClinic Console intends to help, none of these are present. The piClinic Console doesn’t even assume it has reliable access to AC electric power. This approach is not described in the literature that I’ve reviewed.
Studying articles about the successes and failures of past EHR installations has shown that when the available infrastructure of services and resources is present and sufficient, success installing an EHR is possible, but difficult. When those services and resources are not available, success is unlikely. The piClinic Console is a solution that is sized to work with the available resources when there might be very few resources. What this translates to for the user: more available resources allow more functionality. However, with minimal resources, which means basically, AC power, the piClinic Console is still useful, usable, and desirable.
A user-centered design experience
The project has followed user-centered design (UCD) principles from the first observation of a customer need. So far, the UCD process has been successful, but it has also illustrated that you need to have the right definition of success for that to happen. If you define success as “build an X,” this project has been nothing but a string of failures. However, if you define success as “solve a customer problem,” the piClinic Console is on track to do that. However, that track has been anything but direct. If you define success as papers published (e.g. my academic associates), this project has been pretty successful, along that dimension as well. Keep an eye on my publications to watch those as they are published.
The piClinic Console development has consisted of a series of contextual inquiry, iterative design, user testing, and collaboration cycles of the past four years and the project is starting to come together. Watching that process unfold has been simultaneously maddening and delightful.
User-centered madness
Googling “Fail early and fail often” returns a mixed bag of articles saying it’s the best thing ever, and that it’s crazy talk.
They’re both right.
While UCD played heavily in my graduate studies, I don’t recall them focusing much on failing, per se. In the UCD process, failure is considered just another iteration–an expected part of the process. In business and academia, however, achieving the goal of an iteration (a.k.a. a setback) is rarely seen as a good thing. The presumption or expectation is that each iteration will produce an incremental improvement.
However, in an iterative design and implementation, each iteration should get you closer to making things better overall, but each iteration is not going to (nor should the expectation be that it will) always deliver the expected results. However, if done correctly, it will always deliver more information to inform the next iteration.
For each iteration, you should do as much as possible to deliver more value to the customer (i.e. solve a bit more of their problem each time). However, you also have to assume (and make clear) that you don’t know everything and can’t be perfect every time. Sometimes, you have to do the best you can to find out how you need to adjust.
That’s a summary of the piClinic Console path.
- Learning as much as possible.
- Trying something to see where it lands.
- Adjusting based on the observations.
- Repeat until solution is found.
Crazy yet?
For the piClinic Console, this process started in 2014 and will continue into the foreseeable future. As more solutions are developed, more are identified.
User-Centered Delight
After I got out of the mindset that I needed to deliver a specific device to succeed and that I needed to solve the customer’s problem (making the clinic operations a little smoother and easier among other things), I could reframe success so that each iteration was delightful! Sometimes delight came from delivering a solution that solved a problem (the easy case). Other times, success came from learning more to make the next iteration better (so that it could become an example of a customer success.
So, now I don’t fail fast, early, or often. The piClinic and I are learning and growing through a series of iterative experiments and delights!