A Dr. Dobb’s Journal for Clinical Software Development

Recently, when scrolling through Twitter, I learned that Dr. Dobb’s Journal was ceasing publication.   I was relieved to discover that although no new content would be added, the site would remain available. Even so, this is still saddening.

I learned a lot from DDJ. Back in the days when access to programming knowledge was limited by the inventory of the local B. Dalton or Walden Books, DDJ was an invaluable source of practical programming advice.  Even in the age of Amazon when locating books became much easier, DDJ continued to fill a void. DDJ made deep programming knowledge accessible to the masses. Want to write a language parser, understand how to code disk access routines in C, or put together a mini-graphics tool kit? There was likely a DDJ article explaining how to do it with step-by-step instructions and ready-to-compile source code.

Magazines like DDJ and Computer Language made it possible for guys like me to rub elbows with the wizards.  Those interactions extended beyond reading the latest issue. More than a few times, I used my CompuServe account to contact authors and always got a reply. DDJ even once gave me permission to reprint a Prolog article for a newsletter I published. All it took was a note to the editor.   Looking back, I realize how DDJ and similar publications introduced me to important computer science and software engineering concepts, though, at the time, I considered what I learned to be just nifty programming tips.   In any field, there is a need for resources that help practitioners move from theory and concepts to real-world applications. DDJ did this for me with programming in much the same way that the Washington Manual of Medical Therapeutics did with internal medicine. Thinking about the fate of DDJ led me to considering the issue of moving from theory/concept to practice in informatics.  Where is the Dr. Dobb’s Journal for clinical informatics?

There is no shortage of academic informatics journals, which is great considering that I remember when there were only a few.   However, academic journals focus on experiments and outcomes and not so much on the skills involved in practicing informatics or even how to apply experimental knowledge to specific problems.   For example, conducting research on usability complaints is a different skill set than designing more usable systems. Similarly, knowing the pharmacological properties of various antihypertensives is not the same as being able to treat a patient with hypertension. Research evidence must be applied by skilled practitioners.

The first edition of my book, Electronic Medical Records: A Guide for Clinicians and Administrators (renamed for the second edition), was conceived as a practical handbook for those doing clinical informatics. My experiences in trying to learn software design/development and implementation significantly influenced the book’s content.   It was very much a reflection of every problem I had encountered, researched, and survived. The goal was to make the book as much a “how-to” guide as a reference.   While I love books, they are not the best way to keep abreast of a rapidly changing field. For that, one needs periodicals, preferably electronic, and a community.

EHR adoption has increased significantly, and as more providers use EHR systems during patient interactions, more new problems are discovered. Usability complaints are increasing, patient safety is a concern, CDS is harder than expected, interoperability is much harder than expected, data quality is not a given, and the importance of workflows is beginning to sink in.   Academic journals are beginning to reflect these issues, which is nice. However, they all boil down to EHR design issues at some level, and there are no publications that focus on the practical aspects of clinical software design.

Every hospital has a doctors’ lounge, and this is a great place to get advice.   In medicine, there are too many situations where there is no evidence or absolute “best answer” and being able to discuss options with colleagues can be a lifesaver.   Such exchanges are an essential part of professional practice. The same is true of software development. Books only go so far, but software design requires solving new problems on a regular basis.   Translating research evidence and user complaints into requirements, and finally code, requires creativity. It also takes a “village.”

Consider the many skills required to design good clinical software — everything from database design to user experience with process awareness, interoperability, and security in between.  A team, including practicing clinical professionals, is required.  A central gathering place is needed to share ideas.

The AMIA listserv fulfills this function to some degree. One commonly sees requests for information or pointers to resources—I have certainly asked my share of questions. However, more is required, something more formal with a DDJ-esque quality.   What is needed is a way to share substantive articles on the full range of topics that crop up as a by-product of using clinical care systems.   I would love to see a publication with articles such as:

  • Object modeling for CDS alerts
  • A workflow model for a well-baby visit
  • A search strategy for finding human factor and usability literature for EHR systems

Everyone knows that we need better clinical care systems. The question is how to get them. The fact that there are hundreds of products on the market and still so many complaints is prima facie evidence that more of the same is not the answer. Certainly, one starting point is development of a cadre of professionals who are focused on the problems of clinical software design. And those professionals need a place to exchange ideas, where apprentices can learn from wizards, and where new techniques can be vetted and tools reviewed. We need a Dr. Dobb’s Journal for informatics.



    1. Thanks! The article about failure is a great read.

  1. Jerome, Always enjoy reading your stuff. Maybe you need to spearhead creating the “village”. As I had commented while on a recent webinar, we often speak in abstracts and jargon, and we some times need to associate these with concrete examples so that the concepts align. Maybe this “village” could have coders responding to clinician issues with data entry and workflow. Beautiful concept. John D

    1. John, glad you enjoy the blog! I believe that creating better software requires cooperation and respect for everyone’s skill set. An ongoiong dialog between clinical profesionals and the wide range of HIT professionals is essential. HIT professionals have to appreciate that clinical professionals covers a huge number of expertise domains, and on the clinical side, there must be a understanding that HIT covers many expertise domains as well. Medical doctors are not the only clinicians and not every HIT pro is a programmer. A key issue is how we all learn to talk to one another in a common language.

      Currently, most software development issues are handeled via vendor user feedback. Clinical software design is too important to be given over completely to commerical endeavors.

Leave a Reply

Your email address will not be published. Required fields are marked *