The Destructive Recreation of Health Care

A dark wind is beginning to blow through the tortured landscape of health care in America. At the confluence of the corporate cold front with the warm front of technology innovation, a storm is brewing. A storm that may grow into gentle and much needed rain showers, or the grandest tornado ever experienced by mankind, and unlike the wondrous works of nature, the path taken here is completely within our control. The US government and all its federal, state and local branches spent over 1 trillion dollars of our tax money on health care for the poor, elderly and disabled last year and we spent well over 1.5 trillion dollars of our own on health care for everybody else. Most of these monies are going to medical service delivery systems, some is going to financial management intermediaries and a fraction is going to companies providing services to these corporate entities.

Obviously, this level of expenditure is unsustainable, and when we look at other developed countries, we realize that we could be spending a lot less for similar results. However, this is America, and while we must find a way to reduce the number of dollars spent on health care, we must do so without adversely affecting our health care corporate citizens.  This leaves us with two options. One is to simply not provide care to some of us some of the time, i.e. lower the volume and increase profit margins, and the other is to find cheaper ways to provide health care at higher volumes with lower margins. As long as the sum total of corporate profit remains unchanged (or happily improves), any combination of the above should work well for our purpose. Since we are a monetary democracy, we will have to carefully combine strategies so that moneyed citizens continue to enjoy the same levels of service, while the less savvy voting masses do not perceive significant rationing or cheapening of their health services. The non-voting folks are obviously free to perceive whatever they want.

The first thing to do is to change the discourse from all antiquated and touchy feely definitions of health care to a more modern conversation about consumer goods and services, which in a free society implies well understood variations in quality, availability and ability to purchase, based on one’s socio-economic status, closely mirroring our three groups of citizens described above.
  
The second thing to do is engage the fiery wave of information technology sweeping the planet. In the realm of consumer goods, information technology is accomplishing nothing short of magic by transforming traditional goods, like books, into electronic services, and by orchestrating the manufacturing and distribution of everything else. Many service industries, such as banking and travel, have also been transformed from labor intensive enterprises to largely computerized electronic transaction hubs, with very little human intervention needed, and mostly insensitive to geographic location. These transformations resulted in lower prices, lower expectations, increased availability and convenience for paying consumers, paired with record profits for corporations. Seems like the perfect solution for our health care puzzle.

So we begin by transitioning medical record keeping from paper to electronic format, and by standardizing medical transactions so they can be eventually captured by predictive algorithms that will accept standard inputs from consumers and industry knowledge bases, resulting in the dispensation of standard medical advice pretty much on demand. Very much like using Travelocity to book a vacation. If you are a physician, you are probably growing a bit uncomfortable at this point, because this is precisely the type of work you do now.  But wait, we are not as ignorant as you think. We completely understand that some medical transactions require human touch and that even the best medical algorithms still need some form of supervision, but do we really need an overeducated doctor for every routine medical encounter? For very simple things, the autonomous algorithms should be just fine, for medium complexity a trained technician oversight should do the trick, and for complex stuff, or for people with lots of money, a doctor can be added to the mix. This model of operations kills two birds with one stone. It immediately solves the artificially induced shortage of educated physicians, making more of them available for the wealthy, and it drastically reduces the cost of medical care for the masses because technicians don’t need formal education and uneducated workers can be both cheap and plentiful. We just need to secure a good supply of people without any formal education, by convincing everybody that absence of education is now the ticket to a good job and middle class status. And here is where our ominous meteorological event is now unfolding.

In a JAMA article almost a year ago, Drs. Emanuel and Fuchs began by defining the “obsolete” physician, “an incisive diagnostician and empathetic clinician, a productive researcher, and a scintillating teacher”, as a “triple threat” and terrified us all at the mere thought of encountering such a dangerous creature in real life. They then propose a new model based on the assumption that people are incapable of excellence, and “no physician can be a competent triple threat”, therefore why bother trying. Instead, we should apprentice most medical students to be practitioners of a narrow trade, and leave scientific research activities and critical thinking (a.k.a. autonomy) to a select few. This should shorten training periods, lower costs of training, and obviously we wouldn’t have to pay these guys as much, once the “threat” is eliminated. In a more recent article in the Atlantic, Jonathan Cohn is advancing the thesis one step further. After exploring the emerging wonders of algorithm driven medicine, and drawing from the expertise of medical quality beacons, such as Tanzania, India and Brazil, Cohn is suggesting that health care will prove to be the salvation of the “middle class”, because “[i]f technological aids allow us to push more care down to people with less training and fewer skills, more middle-class jobs will be created along the way”.  Middle class jobs, according to Mr. Cohn, are those that “don’t require college or a bachelor’s degree, just a technical program”. So our uniquely American solution to the health care problem is two pronged: eliminate as much expensive education from medicine as possible, and simultaneously ensure that the vast majority of citizens are devoid of enough education to know the difference.

This pioneering stance in health care is reverberating through other realms as well, and reinforcing the notion that technology has freed us from the need to educate ourselves and our children. The Economist for example is taking on the legal profession, which may not be as education intensive as medicine, but it still commands large consumer prices. Instead of educated attorneys, why not use computerized algorithms provided by ZumbaLaw.com at a fraction of the price? And most importantly we should allow investors to buy legal firms and employ (uneducated) lawyers so they can create a more efficient legal system for consumers. Sort of like the miracle solution now applied to health care, where professional people are forced to surrender their autonomy, and now their education, to shareholders and managers. The term efficient here, as in health care, means that ethics and obligations to put clients/patients first are superseded by financial needs of the few, and cheapness needs of the impoverished many. Having professionals stripped of their education and economic power is only half the job to be done. If we are to be successful in reducing prices of everything down to the new "middle class" levels of affordability, without significant civil unrest, we have to make sure that we maintain the ratios of educational attainment, between our new professionals and the typical consumer, constant. To that end, we must convince everybody that we are in an education “bubble” and sending our kids to college is detrimental to the realization of the American Dream in this technology era. Or as Mr. Charles Murray gently puts it in a CATO institute Quarterly Message on Liberty “the BA is the work of the devil”.

In a letter to Charles Yancey dating from 1816, Thomas Jefferson stated that “If a nation expects to be ignorant and free, in a state of civilization, it expects what never was and never will be.” The education Thomas Jefferson thought was necessary in his times had very little to do with picking cotton and making nails. Similarly, in our current “state of civilization” the prerequisite education to freedom has nothing to do with learning a technical trade to better serve the corporate masters of computer algorithms, which seems to be the preferred prescription of the educated elite, liberal and conservative alike, for everybody else. The only question remaining, before we swallow the pill of voluntary ignorance, which has been shown to work for the benevolent tyrants ruling the United Republic of Tanzania, is whether the long term side effects of this treatment are congruent with our expectations, or what’s left of Thomas Jefferson’s hopes for the nation.

De Novo EMR Design Part II: The Quest for Information

The Edwin Smith papyrus ca. 1500 BCE

In Part I of this series, we engaged in a design exercise for an imaginary software product that has no stated (or hidden) purpose other than to improve patient care. Following our initial definition of patient care, we formulated three general requirements and several constraints, none of which were specific enough to start building software tools from. The next step in our journey will break down each requirement into more specific tasks. What follows below will seem like an unnecessary and laborious statement of the obvious to some. However, I would submit that the careless bypassing of fundamental analysis is precisely what led us to where we are today, and even if we are forced to cut corners eventually, it is imperative that we define all corners prior to cutting them, instead of feigning shock and surprise after the fact. So without further ado, let’s start where we left off.

System shall assist with gathering information from various sources (TBD) at the point of care

The first thing we need to do before we begin gathering anything is to figure out the sources of information that may be able to contribute to patient care, and the essence of each contribution, which will serve as a guide to any prioritization efforts that may be required down the road.

1. The Patient – You cannot provide patient care without a patient, and any activities undertaken without adequate input from the patient (or proper surrogate) do not fit our definition of patient care.  Therefore the patient is the primary and most important source of information. Information gathered from the patient can be subjective or objective. Subjective is not a derogatory term that implies lack of importance, and quite the opposite is true in most cases. Subjective information is the patient’s point of view, without which it would be quite impossible to do anything that qualifies as patient care. Objective information is something observed or measured by someone other than the patient, but the lines can be blurred when observation depends on patient voluntary response (e.g. range of motion). Information from the patient is available through several modalities and can be solicited or unsolicited.
   1. Narrative – This is the patient’s story, historically delivered in person, but more recently also available through phones and now through electronic communications over the Internet. Originally, large parts of the patient story were known to the doctor who was part of the community he served, but to compensate for societal lack of wisdom, increasingly larger portions of the narrative are being solicited through paper forms, clerical assistants to physicians and most recently computer software (see below). In most cases, the patient still has the opportunity to relay unsolicited and unstructured information to the doctor, but the allotted time for this activity is shrinking by leaps and bounds. The patient narrative delivered in person has value beyond the story itself, as it exposes other forms of information that can be processed by humans, such as demeanor, tone of voice, body language, general appearance and even smell. It is worth noting here that this sensory exchange of information is bi-directional and the patient is also gleaning important information about the physician. Therefore, at this point in our analysis, we will make a note to consider this expanded definition of narrative when addressing our third general requirement dealing with patient-doctor relationship building. 
   2. Examination – The physical examination of the patient, once the hallmark of practicing medicine, is somewhat diminishing in its diagnostic importance nowadays. Palpation, auscultation and manual handling of the patient is being surpassed by machines that can accurately “see” inside the patient and analyzers measuring biophysical markers and functions that could only be hypothesized by inference or educated guess. Here we are going to use this new and expanded definition of patient examination to include input from any available equipment at the point of care (others will be considered in #3 below). However, as was the case with the narrative discussion above, the traditional “laying on of hands” has implications to our third general requirement. Since we are after all a type of animal, consensual agreement to intrusion by another person into our personal space (and beyond) implies the establishment of an uncommon level of trust and, in some cases, may have healing effects in and of its own. Therefore, we will make the same note as above.
   3. Remote asynchronous – Although historically doctors acquired quite a bit of information about their patients asynchronously, and largely unsolicited, by virtue of being part of the same social community as their patients, those days are mostly gone, and here we will consider newer electronic forms of communication. From email to text messages to patient portals and direct transmission of monitoring data, patients today have multiple asynchronous venues to relay information to their physicians. These communication channels are used, when available, mostly for inquiries and requests for service, but they can also contain information pertinent to patient care. Monitoring data in particular (e.g. glucose levels, blood pressure, peak flows, etc.), whether in electronic or paper format, and subject to our constraint stating that patient care is not equivalent to lifestyle coaching, is obviously pertinent to caring for an individual patient, and in all cases this form of communications has implications for our third general requirement. We note this, and move on to the next item on the list.
2. The Chart – Before the chart, we had “papers”, ledgers, index cards and other less common methods of recording the most salient points of encounters with patients over time. This source of information forces us to consider the corollary to information gathering, which is the voluntary recording of information by the user. This is a fork in our design road. We can assume that information created as a byproduct of patient care is recorded by an external product, or we can add this capability as another requirement for our patient care software. We choose the latter and therefore add a requirement as follows: System shall assist with information recording at the point of care. This requirement will need to be further broken down, in a future iteration, to account for information sources as outlined in #1 above.
3. Other Facilities – In the world of modern day medicine, and primary care in particular, physicians providing patient care must bring into account information generated by others currently or previously engaged in the same activities. This information may be solicited by the physician, in the form of orders to diagnostic facilities or specialty consults, or unsolicited if the patient sought and received treatment at other facilities in the past, which may or may not be pertinent to the care provided by our user. There are two general categories of medical information generators that should be considered:
   1. Diagnostic, Ancillary and Administrative Facilities – These include laboratory and imaging services purveyors as well as pharmacies and any other existing or future holders of information pertinent to patient care. Our product will be required to both solicit and accept unsolicited information from these entities.
   2. Care Providing Entities – This is the entire universe of medical service providers surrounding our physician and patient interaction. Inpatient facilities, long term care facilities and other physicians, are included in this category and we become acutely aware of the need to build our software in a way that it can communicate with a large and extremely ill defined spectrum of other software and traditional partners. Summarizing both categories leads us to state that the System shall retrieve and accept information from external sources.
   This item introduces another requirement originally put forward in the Holy Bible as “…all things whatsoever ye would that men should do to you, do ye even so to them” [Matthew 7:12]: System shall respond to all external legitimate requests for information. Note that here, and immediately above, we are not requiring the system to merely assist the user with this task, but instead we are requiring that the system takes full responsibility for exposing and/or sending appropriate information to other entities (the term appropriate or legitimate is an important constraint).
4. Literature – The final source of information pertinent to caring for patients is of course the science of medicine and the recorded experience of those similarly engaged in providing or receiving care from a medical professional. This body of knowledge is approaching magnitudes and velocities that are impossible to collect, analyze and entrust to human memory, particularly on the fly while caring for any one patient. We classify reliability and importance of clinical information, based on accepted practices, in descending order as follows:
   1. randomized controlled trials
   2. controlled trials, no randomization
   3. observational studies
   4. opinion of expert panel
   5. clinical practice guidelines & recommendations
   The first thing to note here is that unlike information to be gathered from all other sources, literature is not patient specific. To satisfy our fourth constraint prohibiting us from treating patient care as a commodity, information gathered from literature will require significant processing to make it useful when caring for an individual patient. We will therefore split this requirement into two parts: the first, System shall have the ability to access general published information, to be addressed here and the second, involving analysis and processing, to be addressed through our requirement pertaining to synthesis of gathered information. Although this is not the proper time to make technology decisions, we are noting here that gathering information from published materials is probably something we are going to buy off the shelf, instead of building our own module from scratch, as long as we can impose our requirements and, most importantly, our constraints on any commercially available software package. We will make a note to that effect here, and elaborate on it when considering our next general requirement which deals with information synthesis.

To summarize, our first requirement yielded several insights for future consideration and four sub-requirements as follows:

1. System shall assist with information recording at the point of care (needs more specificity)
2. System shall retrieve and accept information from external sources
3. System shall respond to all external legitimate requests for information
4. System shall have the ability to access published clinical information (consider buying)

Funny how certain things rise to the top and impose themselves on the software if patient care is the driving concern, and an orderly design process is undertaken.

And on this note, let’s pause, since we are quickly exceeding the boundaries of polite imposition on readers’ time. If you were expecting to be knee deep into buttons and font sizes by now, please understand that the user interface is the last thing to address in proper software design. If you paid close attention to the narrative so far, you should have noticed that we never mentioned buttons, screens, fields or anything of the sort. We cannot, and should not, define the problem in terms of its solution, just like you are not defining the patient complaint in terms of currently available prescription drugs. We will apply solutions, like buttons and pick lists, or maybe build new things that don’t exist just yet, after we completely understand the problem and the preferences of our users. The same can be said to those expecting discussion on standards, transport protocols and terminologies. We are not at a point where we should constrict our analysis to existing technology solutions, which by the way, are not serving us very well currently, this being the rationale for engaging in this thought exercise in the first place.

With this in mind, we will move on to Part III: A Better Haystack, where the need to synthesize and present the information we are gathering will be examined, forcing us to add specificity to our existing requirements (#1 should be most enlightening), before concluding our first design iteration in Part IV: Continuous Healing Relationships.

Dr. Watson is Not a Meaningful User

IBM’s Dr. Watson of Jeopardy! fame has finally completed its residency and fellowships and, presumably to its creators’ utter delight, is now a practicing Oncologist. The prodigy “cognitive system” completed its training in less than a year at the illustrious Memorial Sloan-Kettering Cancer Center, and although only proficient in lung cancer right now, Dr. Watson’s career as an advisor to oncologists everywhere is off to a great start. A recently released video demonstration shows Dr. Watson in action, researching, evaluating and treating a 37 year old woman with newly diagnosed stage IV lung cancer in his advisory capacity to a hurried and pretty uninspiring human oncologist. Regardless of the slightly weird scenario, it is worth noting that in a fraction of a second Dr. Watson, scours 3,469 text books, 69 guidelines, 247,460 journal articles 106,054 other clinical documents and 61,540 clinical trials, and evaluates their contents against the patient’s EMR to identify need for further diagnostic tests and treatment options for this patient. Being an exceedingly helpful advisor, Dr. Watson quickly reads the entire EMR and uses his trained processing power to eliminate all the clutter in the EMR, presenting to the human doctor only information pertinent to this particular diagnosis. Ouch.

On the other side of town, ONC is busy apologizing for the sorry state of what it calls “interoperability”, blaming everything from the lack of standards to people’s inability to agree on a restricted set of vocabularies for the medical profession. According to the ONC philosophy of interoperability, only “computable” data can be exchanged or analyzed in a meaningful way. In other words, all medical professionals must learn to express themselves in a standardized way which computers can understand.  To that end we have ICD-9, ICD-10, SNOMED-CT, LOINC, RxNorm and all sorts of other terminologies and vocabularies aimed at restricting the English language to the limited computational abilities of available EMR software. How do you say “Mr. Smith is a pleasant 82 year old gentleman with a sad demeanor” in SNOMED? You don’t. You dispense with the pleasantries (pun intended) and diagnose Mr. Smith with depression. The Sapir-Whorf linguistic relativity hypothesis is by no means a settled subject, but if it contains any truth and vocabulary does affect cognition, then how will restricting clinical vocabulary affect the cognitive abilities of its users over time? We don’t know, and frankly I am not interested in finding out.

The folks at IBM took a different route. Paraphrasing Sir Francis Bacon, loosely quoted as, “If the mountain won't come to Muhammad then Muhammad must go to the mountain”, Dr. Watson’s creators must have decided at some point that if the doctor won’t come to the computer then the computer must go to the doctor. Instead of framing the problem by asking how we can change human communications to better enable the current generation of computers to “understand” humans, IBM began by figuring out how to change computers to better enable them to understand current forms of human communications. Thus, Dr. Watson learned to read books and articles and all sorts of “unstructured” information, because no matter how hard the powers to be are trying to fit the square peg of human language into the round hole of computer language, and tragically vice versa, most information generated by people is in their natural language and Dr. Watson was programmed to process natural language. So if Dr. Watson is able to “read” half a million pieces of text of various heft in a second or so, how long would it take for it to read an old fashioned paper chart, or an electronic rendition thereof? I am pretty sure that if you ask nicely, Dr. Watson would be happy to rearrange it for you in any way you choose, while pointing out the most pertinent parts to your current objective, highlighting discrepancies, missing and redundant information, all in a picosecond or less. And interestingly enough IBM developers thought it wise to take a generalized path to Watson’s education, instead of creating specialized Watsons each with linguistic abilities specific to a domain. Seems more human friendly that way…

The IBM Watson software line is not an EMR, but it can process and analyze information in an EMR. It is really an attempt at artificial intelligence consisting of a gigantic contextual search engine, coupled with lots of very sophisticated and self-generating algorithms to both analyze and inform the search itself. Watson doesn’t need to have the smoking status check box clicked in order to infer that the patient is or is not a smoker and doesn’t need to have a new standard defined before it can read a patient’s family history. True, Watson is pretty new software and folks have been tinkering with natural language processing and artificial intelligence for half a century without much success, but things are beginning to coalesce now and technology in the next decade will look very different. Is it really wise for our government to spend so much money and invest so much effort in building and enforcing the use of tools that are becoming obsolete faster than they are created? My hat is off to the VA and DoD who gave up on the strange and expensive idea of building their own EMR from scratch (better late than never). I think it’s high time that other governmental agencies got out of the EMR design business as well, because there are companies out there whose core competency is technology and who have large enough innovation budgets to build the next generation of health IT. Consider this: What if Dr. Watson had a few less educated siblings serving as medical secretaries, summarizing, abstracting and relaying information back and forth, on demand? All of a sudden the shape, form, functionality, standardization and all “meaningful” bells and whistles in an EMR are rendered irrelevant, and using Microsoft Word for typing or dictating your note is as good as using a “certified” EMR, or much better, because the context is so much clearer and so much more forthcoming.

Whether it can pass a Turing test or not yet, Dr. Watson is not a real doctor, and it will not be one in our lifetime. Dr. Watson has no free will and everything it knows is dictated by the corpus of knowledge made available to it by its creators or employers. There will be huge ethical and legal questions raised by software capable of supplanting human decision making processes, and software that can be centrally deployed and manipulated to this end. Even before that future arrives, it is worth noting that Dr. Watson is simultaneously employed in oncology clinics and by payers, and in my opinion, Dr. Watson has one button too many – the direct button to the insurance company, which will automatically approve payment for Dr. Watson’s top recommendations, but presumably not so much for other choices. Like all technologies, Watson embodies hope for the greater good along with great new perils for ordinary people. Leaving these philosophical questions aside for a moment, the only certain thing is that Dr. Watson is starting its brilliant new career by introducing a cure for one very painful disease that is reaching pandemic proportions amongst medical professionals: clicking boxes.

De Novo EMR Design - Part I: Stating the Obvious

Our ancestors began using tools millions of years ago and humanity assumed control of the planet it lives on through a succession of tools ranging from sticks and stones all the way to iPhones and drones. The basic process for discovering or inventing tools hasn’t changed much over the millennia, and it follows two basic patterns. Either an existing artifact is examined for fitness to various purposes until one such purpose is discovered accidentally or through organized efforts, or a problem is identified and a tool is then invented, or located, to solve the problem. The problem itself could be something that was thought impossible before, such as flying, or a more mundane desire to reduce the effort and expand the capabilities associated with an existing activity, such as moving goods from one place to another. Tools can have limited effects, revolutionize an entire economic sector or can change history, and some tools can have harmful effects that must be balanced with the benefits they offer for the intended task. Tools usually undergo long processes of change, improvement and expansion, and sometimes the evolving tool looks nothing like the original invention. Why are we talking about tools here? Because programmable computers are tools. The computer hardware is like the hammer head and the programming software is like the hammer’s handle (more or less). And EMRs are one such handle.

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?

1. System shall assist with gathering information from various sources (TBD) at the point of care
2. System shall assist with synthesis of said information
3. System shall assist with patient-doctor relationship building

Note that since we are not building a replacement for the user, our system is an assistive technology system and nothing more. These requirements are not granular enough to start programming from, but are there to always look up to, and see if everything we do serves one of those basic goals. If it doesn’t, then it should not be built. Note also that we are not questioning the user’s “workflow”, wisdom or professional decisions. We are aiming to provide a limited service, and will leave “fixing health care” to more ambitious folks. To any set of basic requirements, I like to add the prime directive of software development, which is a general warning for subsequent designers, architects and programmers:  

4. System shall not make the task harder to perform for the user

The next phase of design will take our primary set of requirements and break them down into concrete software tasks (and no, #3 is not a joke). To do that, one should understand in minute detail, and preferably practice, patient care, particularly for the purpose of observing the constraint imposed by #4. The creators of Microsoft Word, and all other direct to consumer software builders, have a much easier time with this portion, since everybody writes. Those who build software tools for domains that they are not familiar with have a tendency to make too many assumptions based on random and infrequent encounters with said domain (e.g. I take my kids to doctors all the time, I had to go to the ER once and I know how it works, etc.). Translating the above requirements into concrete specifications should entail many months of research. Assuming we have that under our belt, we are ready to move on to the next step.

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).

And just in case we were not specific enough in our definitions, this software is for physicians administering care to an individual patient. We are not designing tools for staff, billers, payers, employers, federal or state agencies, and no, we are not building tools for patients. Although requirement #3 may drive us to address the patient perspective to the extent that it is pertinent to physician activities, our (paying) customer persona is the doctor (we’ll expose some APIs for the rest of the world…).

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….