It isn’t often that I come across an article that truly resonates with me, but Next-Generation Phenotyping of Electronic Health Records, by Hripcsak and Albers, did just that. While the authors’ main focus is EHR data quality, they make this intriguing observation/suggestion:
It will require study of the EHR as if it were a natural object worthy of study in itself (emphasis mine), and it may be helpful to employ the general paradigm of physics, which involves modeling and aggregation. It will be helpful to pull in expertise and algorithms from many fields, including non-linear time series analysis from physics, new directions in causality from philosophy, psychology, economics, of course our usual collaborators in computer science and statistics, and even new models of research that engage the public.
I absolutely agree–it is time to start treating EHR systems as more than front ends to data stores. Considering the role that EHR systems are expected to play in improving healthcare quality and safety while lowering or stabilizing costs, the design of clinical systems is rarely discussed in the literature. As I have mentioned in previous posts, most EHR-related standards address the content and features EHR systems should have, but specifically disclaim any concern about how systems should be built. It’s almost as if the prevailing attitude is that EHR design and architecture are straightforward and require little real intellectual input. This raises another issue that I think deserves discussion—the intellectual work of software development.
Now, consider what goes into creating a clinical system on top of mastering these basic technologies. Developers must comprehend the computational properties of clinical concepts as well as clinical informatics constructs such SNOMED, RxNorm, MU, and various HL7 technologies. When one adds to all of the above software design concepts such as coupling/cohesion, dependency injection, design patterns, layering, etc., it becomes obvious that creating complex clinical software is a real challenge.
Often, calls for more innovation, whether the goal is improved usability, tighter security, or data quality assurance à la Hripcsak and Albers, seem to assume that creating ever more complex software is simply a matter of hiring more programmers –NOT! Software development necessarily starts with requirements, but requirements are nothing more than wishes until someone turns them into working software. A sophisticated software system built from scratch is not simply a completed project; it is also an intellectual and creative accomplishment.
Creating the EHR systems required to move healthcare to the next level requires a much greater cross-pollination between the informatics and the software engineering communities. How many informaticists can comfortably debate the merits of software design choices such as inheritance vs. interfaces? On the other hand, how many software engineers understand the differences between drug allergies, interactions, and side effects? Yet, building a modern EHR requires deep knowledge of software design principles and clinical concepts, both at the level of clinical practice and as computable entities–both knowledge sets are equally important.
As things currently stand, the knowledge of how to build EHR systems rests mainly in the private sector. Whatever research private companies perform is devoted to their products and is not generally shared freely with others. Yes, there are open-source EHR projects, but they tend to focus on building software (e.g., OpenEMR, VistA) not basic research in clinical software design. The openEHR initiative, however, does address some key issues. Reviewing the informatics literature highlights the lack of attention to EHR system design. Articles in informatics journals tend to focus on data/content issues (e.g., SNOMED, RxNorm, SNOMED, HL7 V3 RIM) and the effects of HIT (e.g., patient outcomes, productivity, errors, implementation woes) while rarely, if ever, touching in any substantive way on how these issues are intimately related to specific software architectural/design choices. I think a major reason for the lack of such publications is the separation that exists between EHR system users and builders, between clinical thinking and engineering thinking.
As EHR adoption moves forward, data problems such as those described by Hripcsak and Albers, along with usability, security, interoperability, and implementation issues, are making it obvious that building systems that meet expectations is neither simple nor obvious. I heartily agree with the authors. We need to treat electronic health record systems as objects worthy of study, having their own mathematics, algorithms, theories, and engineering principles–sort of an EHR science, so to speak. Has a nice ring to it, doesn’t it?