Let’s imagine that we are software builders and we have a desire to help doctors deliver patient care. And let’s further assume that we, and our prospective customers, examined all the existing tools out there and found them not quite fit for purpose. Let’s also assume that we are not suffering from delusions of grandeur, have the humility to admit that we don’t know how to cure disease and have no interest in global social engineering initiatives. Let’s imagine that we are the misguided founders of a small social business interested in doing well by helping others do good things.
The following is a theoretical exercise in software product design for the shrinking market niche still subscribing to Sir William Osler’s views on medicine. Therefore our starting point will be fixed by the assumption that medicine is “a calling, not a business” and that medicine is to remain a “humanitarian and respected profession” concerned with “diminishing human suffering”. Since we are not out to develop drugs or devices, the overriding goal for our imaginary software is to improve patient care. But in order to improve something, we first need to at least understand what that something is. So what is patient care? For simplicity of illustration, let’s further constrain ourselves to primary care, because it is probably the most common and best understood type of patient care.
Patient care is a longitudinal activity occurring over varying periods of time, but it is not continuous; instead it is a chain of discrete units of service usually called encounters, which may or may not be dependent on each other. Encounters can be proactive, reactive, physical or virtual. The mechanics of a patient encounter in primary care is very simple. Patient comes in (or not), patient relates problems (if any) to physician, physician formulates diagnosis based on patient narrative, physical examination, diagnostic measurements and finally suggests therapies to resolve, alleviate or prevent suffering from problems. Patient may or may not agree with suggestion. There are three major parts to this process - gathering of information, synthesis of information and relationship building - and each part has a very clear purpose. Note that documenting the events is just a corollary to the main process. Sounds simple? Not quite.
While this is the current practice, many product designers are designing software for what they think patient care should be, adding and removing parts to and from the current process, or disregarding the existing process in its entirety. To understand why this is a problem, let’s think about Microsoft Word. Manny decades ago, writing consisted of a blank sheet of paper and a writing instrument, quill, pen or pencil. First the typewriter removed the work needed to shape each letter by hand, and then the computer removed the need to have a physical piece of paper, and instead gave us an infinite number of blank sheets, with obvious benefits to the user. What neither of these inventions did is to redefine the authoring process; you still have to pick something to write about, do your research and “write” it down. The word processor makes it easier and cheaper to write, to fix mistakes and to make your masterpiece look appealing. Now imagine what would have happened if the creators of Microsoft Word would have decided to be a bit more helpful and gave you a series of dropdowns and buttons to choose and refine the subject of your writing and then plopped in a prewritten article, which you can now edit to your liking. Who would have used this contraption? People who have no business writing in the first place. As is true with medicine, in software design sometimes less functionality is better functionality, particularly when the extra functionality is paternalistically dictated by the purveyors of software.
Back to our little project, what do we have so far in the way of requirements?
- System shall assist with gathering information from various sources (TBD) at the point of care
- System shall assist with synthesis of said information
- System shall assist with patient-doctor relationship building
- System shall not make the task harder to perform for the user
Even to the untrained eye, our first three basic requirements speak volumes. #1 looks like something computers can do very well. #2 looks like something that computers may be able to do very well in the future, but right now it embodies lots of difficulties and temptations best avoided. #3 looks ridiculous to some, but very promising to younger folks who define relationships through software apps. Another nifty thing that practically jumps out of the page is that we don’t have to satisfy all 3 requirements all at once in order to have a useful product. Thus our little project lends itself very well to an agile development model where we can have successive series of small releases that are useful to our users from the get go. Another look at those general goals reveals that we could benefit from placing some boundaries on the magnitude of our project to avoid the number one pitfall of all software projects – scope creep, or consistently succumbing to the temptation of adding one more little thing. To do that we should look, within our scope of service, at what patient care is not.
- Patient care is not a synonym for public health.
- Patient care is not a financial transaction.
- Patient care is not lifestyle coaching.
- Patient care is not a commodity (at least until people become a commodity as well).
So let’s tackle the biggest bang for the buck first, and get started from the top. Part II will attempt to define a manageable set of specifications for our imaginary product. In the meantime, feel free to contribute to this thought process….
Post a Comment