The Informaticist-Programmer Interface: What Do You Mean By That…?

An oft-voiced sentiment in HIT discussions is that there is a need for better EHRs.  Few seem to disagree with this sentiment, but, as with many things, creating better EHRs is easier said than done.   After all, vendors are not deliberately trying to create less-than-ideal products.   Rather, I think that anyone who has tried to create a software application will agree that ideas taken from paper require a good deal of rethinking before they work well in electronic media.    Thinking about how to create better software made me recall my work on the UAB EHR project.

Early on, the team consisted of two developers and me. Both had master’s degrees in engineering and neither had a background in health care.  The first challenge we faced was developing a set of shared concepts;  I explained  clinical concepts to them, and  they, in turn, explained various technical concepts to me.  It took about six months of daily discussion and examples before we could move forward with a set of commonly-held notions of what the software we were creating should do and how it should be designed.

I recall one day, a year or so into the project, when a new team member who held a master’s degree in health informatics, frustrated over creating a database schema,  asked me, “Dr Carter, why isn’t there a book explaining how to do this?”   This remains a problem. There are no definitive guides on fundamental clinical algorithms, clinical data structures, or design patterns that are common to clinical software.  We have SNOMED, HL7, ASTM and the like, but little about how to design, build, and test systems. In other words, there is no handbook of clinical software engineering.

Lacking such guides, where can one find the expertise required to  create better clinical software?   The obvious answer is the growing pool of clinical informaticists. However, this addresses only part of the problem.  Sure, clinical informaticists understand clinical concepts, but how many have been trained to understand and communicate the computational aspects of clinical concepts to software engineers?    Acting as a resource requires sharing a common vocabulary. When programmers ask questions informaticists must understand what is being asked and vice-versa.   I’ll use the problem list, a simple clinical information structure, to illustrate my point.

On paper, a problem list is a simple construct.  One can add to the list, strike through, or place a “stop date” to indicate resolution of a problem—functionality that is easy to understand and use.  Now, move this to a computer.  Adding, updating, and deleting are functions that are still easy to understand and perform.  However, the question one has to ask is whether the electronic version is capable of informational/computational uses that exceed those available with a paper list.  It is this very question that, if answered well, leads to “better” software.  When answered poorly, the result is cumbersome software that is harder to use than paper while offering minimal additional capability. Sound familiar?

Let’s look at some of the potential informational/computational aspects of electronic problem lists.

Basic Properties
Informational Dates (added/resolved/updated), Code, Name,  Acute/chronic, Active/resolved, Gender-based/neuter, Confirmed/unconfirmed, Organ system, Provider (owner or one entering information)
Computational Add, delete, update, sort by basic property, group by basic property, change owner
Advanced Computational Properties
Triggers Adding problem/diagnosis triggers decision support (e.g., new medications, suggested tests, public health reporting)
Reference sources Queries for clinical research or preventive care purposes
Status changes Problem becomes a confirmed diagnosis (e.g., headache becomes migraine with aura)
Linkages Problem becomes linked in an association network (e.g., Initial problems: headache, amenorrhea is updated to link with diagnosis: prolactinoma)

Table 1. Informational/computational/ aspects of problem lists

Utilizing a problem list’s informational properties computationally requires consideration of database schemas, data structures, and algorithms.  Programmers are, of course, familiar with all three. However, an informaticist has to supply the rules that constrain computations.  For example, which job role may add a diagnosis or problem (i.e. should primary care clinicians be allowed to enter a diagnosis of schizophrenia or a psychiatrist, Graves disease)?    Checking a patient’s gender when adding a problem/diagnosis is another example of a computational use of an informational property.

The data structures are important as well.  A problem list that exists as a simple two-dimensional array will have computational properties that differ from one held in memory as a collection of interconnected objects.

A poorly designed database may make cross-referencing the problem list with other patient data difficult.   For example, a database schema that links problems/diagnoses via transactions to medications, will make querying  of drugs used for specific diagnoses easier to determine than designs that require indirect matching using visit dates or other occurrence proxies.

Moving beyond basic informational properties yields additional challenges such as how the problem list interacts with decision support/workflow algorithms.   In addition, dependencies and priorities for features must be set.  For example, feature “X” may be easier to build, but is not as useful as feature “Y”,  which may take twice as long to complete.  Which goes first?  There may also be important dependencies when managing properties (e.g., determining the correct programming steps required to remove an incorrect diagnosis/problem and then alert providers who may have made decisions using the incorrect data).

Computational strategies are another important concern.   Data structure and algorithm selections can affect performance and, once encoded, may be difficult and costly to alter.   If problems can undergo status changes and be linked in association networks (see table), the resulting linkages could act as a window into clinicians’ thinking and intervention selection.   Would this work best in a relational database where all data are stored in two-dimensional tables, or a graph database that could maintain the relationships directly?   Relational is a no-brainer, but a graph DB might confer a real advantage.   Choosing the best storage medium requires consideration of both clinical and technical issues.

Creating better EHRs requires informaticists working closely with software engineers.  In order to do so effectively, each group must understand what the other is saying. Ultimately, this means that informaticists must learn more about software design and software engineers must become more familiar with clinical concepts.  I enjoyed working with my team at UAB. It was fun, and I would gladly do it again.  But, you know, I really do wish there was a book!



Leave a Reply

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