I’ve been fiddling with the About page for the last few weeks trying to come up with a succinct explanation of what this blog is about.  When I started blogging, the focus and goal of EHR Science was clear—I wanted to discover new tech and interact with other geek informaticists.  Happily, that has happened.  However, something unexpected occurred as well—I now actually believe that a formal theory of clinical systems and clinical informatics is possible, and by formal, I mean mathematical.

You see, what began as an open-ended quest to try new technologies and learn about workflow representation has, as a result of studying discrete math,  morphed into a mild obsession (okay, maybe not so mild) with mathematical models of clinical processes, computable forms of clinical concepts, and EHR design.   Graphs, functions, sets, and relations now seem to be perfectly reasonable tools for describing clinical concepts and processes.

Delving into new technologies has altered my views of EHR design as much as studying discrete math has changed my views of clinical processes.  Object-oriented analysis, design patterns, NoSQL data stores, and architectural innovations such as REST have changed my way of looking at how clinical systems are designed.  I am not saying that procedural programming is bad or that relational databases are passé.  Rather, I have discovered how enlightening it can be to work through solving the same problem in different ways.

Solving a problem using a procedural language such as C requires a different strategy than what one might employ when using a purely OOP approach and Java.  Logic programming differs from both.   Web-oriented scripting languages provide yet another solution choice.  Having to consider different solutions helps one to develop an abstraction of the actual problem from existing implementation instances.

Envisioning new approaches to EHR design requires moving beyond thinking of an EHR as a relational database attached to a front-end.  (That is, we need to stop thinking of EHRs in terms of a specific implementation instance and, instead, begin thinking of them as an abstract concept that can be implemented in a variety of ways.)

Is there a best or ideal EHR architecture or design?  As far as I can tell, no.  There is very little in the literature that addresses these questions.  Likewise, there is a limited amount of research on the computational aspects of clinical concepts such as which data structures are best-suited to specific clinical concepts (e.g., Is there a best/ideal data structure for problem lists?).   Given the dominance of relational databases, it is surprising that there is so little discussion of schema designs and tradeoffs for EHR systems (I have found only a few).   There are numerous papers on the clinical and economic effects of EHR systems, but very little on how to model, design, and build them.  Why is that?  So many questions, so little time…

Reflecting on all of the above has led me to look for a means of unifying the various aspects of EHRs (or clinical systems in general) along a line that starts with mathematical abstractions and ends with working systems.  Between these two endpoints lie domain models, clinical process representations, architectural patterns, and clinical algorithms, among other things.  This is what EHR Science is about.

Blog Plans
Of course, I want to share my thoughts, and I hope to do so in the form of a few post series similar to those that focused on Petri Nets (Petri Nets and Clinical Information Systems) and clinical workflow analysis (Preventing Your EHR from Working Against You).  Each series will be comprised of three to five posts.    At present, three series are in the works. In no particular order, expect a series on workflow patterns, one on math concepts useful in describing clinical concepts, and one on graphs.  Others are possible, and they will appear if time and circumstances permit.

Lately, I have taken a greater interest in EHR data quality as both a design and a data modeling issue.   Standard datasets (see Wrestling with EHR Data Quality) seem like a very reasonable and objectively measurable starting point for defining quality metrics such as completeness and accuracy.   Having performed a few preliminary searches, I am considering making data quality searches a monthly activity.  If I do, you know what to expect…

Adding a Forum
EHR Science is an outreach project.  I started blogging because I wanted to connect with others interested in clinical information systems.   A forum seems like a simple way to provide more interactivity and allow readers to initiate discussions.   The question, of course, is how many people are interested in interacting.

One topic in particular that I thought might be great for a forum is clinical workflow analysis. The idea is that visitors could ask questions and share problems and experiences related to performing analyses in real-world situations.   Personally,  I would be interested in hearing more about EHR/CIS development projects and how developers solve specific architectural and design problems.   It would also be nice to hear of others’ experiences with NoSQL and REST in clinical settings.   Of course, a successful forum requires active participants; I’ll put it up and see what happens.

See you in two weeks…



    1. Jon, thanks for your comment. This is a great paper. I actually came across it a couple of years ago, as well as your site at the U of Sydney.

      I like the process-based, user-centered approach to CIS design the paper advocates as it matches my way of thinking. The question that drives me these days is how we can formalize all the best practices for CIS specification and development so that every new project does not end up reinventing the wheel.


  1. Chuck, I do intend to at some point. However, I am too swamped to try managing a Twitter account, at least the next few months or so.


Leave a Reply

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