Experimentation is essential to the development of any new field. In the case of Biomedical informatics, and clinical software in particular, the ability to test ideas in concrete form as functioning software provides a much-needed reality check on expectations and claims. There are many aspects of software systems that must be properly aligned to make it useful and feasible to implement those systems.   The difference between a specification, what can be built, and what works (cost-effective, maintainable, extensible, etc.) in the real world can be substantial.   After all, specifications are merely wishes until someone figures out how to render them in working code. Thus, just as I consider workflow analysis to be an essential informatics skill, being able to grok, to some degree, the gap between specification and useful real-world software is similarly valuable.

Now that clinical care is increasingly dependent on software systems, the need for clinical informaticists to have a deeper knowledge of software systems is growing as well. Discussions of usability, safety, workflow, and interoperability at some point must result in specifications in order to effect any positive change.   Acting as go-betweens with clinicians on one side and software engineers on the other requires the ability to understand the jargon and mindsets of both sides. No, I am not suggesting that informaticists should be expert coders. However, as software issues evolve from feature/function requests that can be addressed with a few code adjustments and tweaks to more complex issues, such as usability, which may require changes across the entire architecture, greater familiarity with the inner workings of software systems could result in more effective communications with developers.

Object-oriented programming provides a good example.   Many informatics degree programs offer database and programming courses (usually Java).   In Java, everything is an object, so building an application in Java will acquaint one with classes, interfaces, methods, and properties. However, building complex object-oriented software requires more than familiarity with OO language constructs.   Knowledge of design patterns and software architecture principles is also required. More importantly, clinical concepts must be rendered in code.   Consider the difference between a problem list that is simply an ordered list of terms taken from a database table as opposed to one in which the problems in the list can interact in real-time with other patient data. One replicates the actions of paper; the other can form the basis of a CDS system. The former, anyone can code with a little practice, the latter requires knowledge of data structures, algorithms, and clinical care.

Recurrent themes on EHR Science – software design, data quality, workflow, usability, and even interoperability – can be explored with free tools that are readily available. For my fellow informatics geeks, here are a few suggestions for building an informatics exploratorium.

Data Stores
Data stores are essential informatics tools.   For most, relational databases are the default data storage option. No doubt, RDBMs are versatile, but reducing everything to two-dimensional tables can be tedious and may not be the best option for storing information. Seeing the world through non-relational eyes is difficult when all one has used are relational stores, but there is value in having more than one way to approach data storage.   Two aspects of data storage where the limits of two-dimensional tables become obvious are storing objects and modeling relationships.

Well-designed OO software works as a confederacy of interacting objects. These objects contain data of arbitrary complexity, and moving data from objects to tables can be a pain.   While object-relational mappers exist (tools that automate code creation to move data from an object to a database and back), the code can, at times, require tweaking.   The bigger issue, though, is whether one should have even used an RDBMS to begin with.   Saving an object to a document store such as MongoDB is easy.

Relationships are another modeling problem that should be rethought before automatically using a relational database. By relationships, I mean a graph such as a map where cities are nodes and roads are edges.   Graph databases, such as Neo4j, make it very easy to build, store, and query graphs. Graphs are everywhere. We encounter graphs on a regular basis, but never think of them as graphs. Workflows are directed graphs; diseases and symptoms can be represented easily as graphs; a network of friends (likes, dislikes, related to) forms a graph; and hierarchal terminologies are likely to be graphs as well.

Each kind of data store has use cases for which it is best suited. MongoDB and Neo4j have free editions. Experiment and make sure you are not using a RBDMS as the proverbial hammer…

Software Design/Development
Modern software development features a few recurrent themes: object-oriented programming, APIs/REST/Web services, mobile applications, and Web applications.     There are so many tools to choose from that it can be overwhelming. From an informatics perspective, algorithms are the most interesting aspects of software development, at least for me.   For example, given an EHR data set, what algorithm would be most accurate in discovering undiagnosed cases of a specific disease?   Often, such questions are posed as direct database queries. However, this ignores the value of having algorithms built into clinical systems that can ask questions or monitor patient populations.

Experimenting with algorithms requires programming and a good development environment. Fortunately, the open source movement has made sophisticated development tools easy to come by and pushed major companies to provide tools at no cost.     Apple (Xcode), Microsoft (Visual Studio), and Google (Developer Tools) make their tools available at no cost for those who wish to experiment with mobile, desktop, and web development.   NetBeans is a good cross-platform development environment that I really like.

For programming languages, aside from the usual (C#, Java, PHP), I have developed a decided preference for Python and, more recently, Swift.   Python makes it easy to create algorithms and explore data structures. In addition, the number and quality scientific libraries that exist for Python make it a great tool for informatics explorations.   Swift has playgrounds, which makes it just as flexible and easy to use as Python.   Using Swift on my Mac feels likes developing on a desktop 20 years ago, but with better debugging, hints, and language features.

Workflow technology
Now that the concept of “workflow” is evolving from “what people do” to “what people do that software should support,” figuring out just how software can support what people do has gained currency.   One way of supporting workflows in software is to hard-code them into the software, and then change the code every time the workflows change.   The other (sane) way is to use workflow technology. Fortunately, workflow tools are available that a quite capable and free.

YAWL is a complete workflow management suite that has great documentation — and a book, should you want a more substantial introduction to the system. The YAWL Foundation has an active community working to maintain and expand the system.   YAWL can be used to explore every aspect of workflow technology.

BonitaSoft is an open source business process management suite that can be used to explore workflow technology. It has been around nearly 15 years and has a vibrant community as well.

EHR Design
For those who would like to try their hands at EHR design, open source systems are available to dissect and remodel. OpenEMR is MU Stage I certified, and full source code is available. Even better, the download comes with a Xampp, a PHP/MySQL development platform.   Add NetBeans, and you’re good to go. For those who are partial to Java, OpenMRS is available.

Lately, there has been a lot of discussion about what is wrong with EHR systems.   Pointing out deficiencies is easy.   However, fixing them and creating a vision for next-generation EHR systems is hard.   Translating clinical care support into working code requires a few translation steps. Informaticists experienced in clinical care and familiar with the deeper aspects of software design are critical.   Fire up your computer and explore!

(For a list of helpful books, check out the EHR Science bookshelf.)



  1. python is great, and has some great snomed libraries.

    what do you think of the smart modular approach https://smartplatforms.org/
    how far do you think we are from basic interoperability to support this kind of development? currently i’m running at least 3 windows of browsers when i’m seeing patients. my ehr, our hospital’s ehr, and our prototype system, and at times our HIE registry. i don’t actually mind having all these up and running as the gesture control on the mac makes swapping applications trivial. logging in and accessing each patient can be tedious, but i don’t need to do so for all patients.

    1. Jim, thanks for your comment. The SMART approach is interesting. Modular designs are essential moving forward. Monolithic software has no place in today’s clinical environments.

Leave a Reply

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