Is a doctor a doctor? It’s a question with an obvious answer – or is it?

When it comes to health information technology, usability of software is a hot topic. While technical usability indisputably has room to evolve, the root cause really is the answer to the above question – doctors are all different. Software crafted by doctors for doctors can still be deemed unusable by doctors because of this fact.

As doctors, we all start in the same place: in my case, anatomy lab in medical school. Even then, it was apparent that some people really enjoyed cadaver dissection, and others preferred to read about it in a book. For the record, I never missed a day of anatomy lab. Fairly quickly, differentiation starts to occur. By the time we near the transition from medical student to doctor, we already begin to segment into four major categories long ago defined, and yet not clearly defined at all, by organized medicine: physicians, surgeons, both, and neither.

As medical school graduates, we all get a degree that mints us as doctors, and then choose a further training path to specialize. This training path often then leads to an even more focused career path. The resulting doctors who all started out together ultimately have highly divergent skill sets, work goals, and daily activities. A general surgeon in community practice is quite different than an OB/GYN in an academic medical center, who is also quite different than a military orthopedic surgeon, who is also quite different than an internist in solo practice, who is also…well, you get the picture. In essence, there is no “model” doctor upon which to base any single software suite meant to encompass all doctors.

“Workflow” has become a trendy term in the age of health IT. Many a software developer has been baffled by the lack of standardization in workflow among doctors, and the subsequent challenge in building a software application to match. Others have created focused applications to great early acclaim, only to underperform when they attempt to scale their customer base of doctors outside the original niche. This phenomenon has been particularly visible with electronic medical records but is certainly not limited to those applications in healthcare.

The solution for some has been to build “patient-centric” technology, since of course the patient is the one constant that ties together all useful health-related information. While important for data management, this approach still fails to solve the issue of usability. The fallacy here, inevitably, is that there is no “model” patient either. Indeed, the variables are even more numerous, and the variability is thus even more extreme. Match the variability of patients with the variability of doctors, and the math gets to be dizzying.

Reflective of the coupled art and science of medicine, effective health IT strikes a balance between standardization and customization. No single technology application can be all things to all people at all times. Rather, HIT developers should focus on standardizing the inherent framework of health IT to match certain basic, universal principles – not unlike the standardization of medical school degree programs – while creating an environment that allows for adaptability and multiple paths off of that framework to enable the inevitable secondary and tertiary development that naturally and essentially must evolve. HIT that does not enable that kind of adaptability and flexibility will inevitably generate challenges for both doctors and their patients who try to use it to their fullest desire.

In the end, doctors are different. Our patients are different. Our technology needs are divergent. Nonetheless, the harmony in intersecting art and science in medicine can also influence a balance of standardization and customization in HIT that ultimately leads to a positive experience between doctor and patient. Progress in HIT usability will come neither from forcing doctors into standardized workflows to accommodate software nor from minutiae in managing screen views, but rather by crafting adaptable software platforms for a varied environment. Then, as doctors, we can all be unique while all being the same.

Unable to cast object of type 'System.DBNull' to type 'System.String'.   at McKesson.ImageHelper.getImageDesc(String URL)

About the author

Summerpal Kahlon, M.D., is vice president of business development for RelayHealth Pharmacy Solutions, a business unit of McKesson Corp. Dr. Kahlon is focused on enhancing connectivity and communication between prescribers and pharmacy on behalf of patients and their medication needs.