Is It Time for a Clinical Programming Language?

by Jerome Carter on December 16, 2013 · 2 comments

Programming languages are fascinating to me.   I like seeing how different language designers attempt to solve the same problem.   General programming languages like C are great, but often one can be more productive when the language used is closer in concept to the problem at hand.   Yes, anything can be written in C, but if one is heavily focused on using logic assertions to solve a problem, Prolog is the better choice.

As a fellow, I developed a deep interest in designing clinical software, and always thought life would be so much sweeter if a programming language dedicated to clinical systems existed.   If you are thinking MUMPS, uh…no.  MUMPS was designed for use in clinical systems, and works quite well, but it does not represent clinical concepts natively.  And by natively, I mean it does not have a data type or built-in support for concepts such problems or medications.   MUMPS is a good general purpose programming language, but it is not what I had in mind.

By the time my fellowship training came to an end, I already had a notebook filled with ideas about my ideal clinical language. I even came up with a name – Medical Thought Algorithm or METHA for short.  (I didn’t say it was a great name.)  Even so, as much as I wanted a clinical programming language, I could never figure out exactly how it would work.  Data management was a major stumbling block. This was the late 80s, after all, and my programming tools consisted of Turbo C, Turbo Prolog, Turbo Pascal and TopSpeed Modula-2.  I did manage to write a B+ tree filing system, but that was a far cry from a data management solution.

The biggest problem I wrestled with was deciding exactly what type of applications could be written in METHA.    Initially, it seemed that clinical decision support applications would be ideal.  However, CDS requires access to data, which of course was, in itself, a major problem.  Representing clinical concepts was also an issue.

A problem/diagnosis, for example, could be represented using a record data type (this was before OOP languages were readily available).   However, that still left the issue of how functions and procedures would operate on this data type.   Another challenge was determining which concepts were fundamental and which were derivative.   Eventually, I decided that the concepts patient, problem, intervention and provider were fundamental; beyond that, I never made any progress.  The more I worked on METHA, the more confusing the whole enterprise became.

By the early 1990s, I had started using FoxPro, which addressed most of the data management issues. It had built-in relational database support and a general programming language.  Using FoxPro, I wrote a few clinical applications for personal use.   There is a lot to be said for a programming language that has integrated relational database capability.    Experimenting with FoxPro convinced me that METHA was really best seen as a scripting language for a clinical data store.   I still think this is a great idea.   Consider how much easier it would be to expand the functionality of an EHR if coding did not require starting with a general purpose programming language.

Excel offers a good analogy.   Excel has a huge number of formulas that can be accessed easily, making it a great tool for a wide variety of number-crunching activities. What if instead of having a library of functions/formulas to choose from, every business using Excel had to pay for custom programming in order to gain access to that functionality?

A language with built-in clinical concepts and an integrated data store a la FoxPro would be quite useful.    It could be used to create EHRs as well as simpler clinical applications.  Very likely, it would push HIT adoption because the barrier to creating utility applications, say for example, a results management system, would be much lower.   Every popular programming language has a huge library of code that can be shared, extended, or simply dropped in and used “as is.”  It is difficult to overestimate the impact that a clinical programming language might have on clinical informatics and clinical practice.

Unfortunately, even after I decided METHA should be a FoxPro-like language, I made no progress.   Workflow and process support remained problematic until I discovered Petri nets.

Clinical programming has to account for processes.  Without proper representation for processes, creating systems that follow an activity over time or multiple steps becomes cumbersome.  The workflow patterns discussed in prior posts provide the information needed to formalize workflow constructs in clinical systems; they should work fine as a library.

With the discovery of Petri nets, my quest for METHA finally moved forward after nearly 20 years.   Should I, or anyone else, ever have the time and resources to pull it off, here are the features and capabilities METHA should have:

  • Very similar to Python.
  • Built-in or library support for standard workflow patterns as defined by Aalst, Russell, et al.
  • Integrated data storage capabilities and the ability to access external DBMS.
  • A clinical concept library that can be used to extend the base language.  The core library would define basic concepts (e.g., patient, gender, visit, problem, medication, encounter, etc.).   This would prevent concept drift in the base language. External libraries could add specialty (e.g., GI, cardiology) or domain-specific (e.g., public health) concepts.
  • Graphical modeling tools based on Petri nets.

After over 25 years, it is nice to have finally arrived at this point.  The problem is, I was hoping for 1989 at the very latest.  Well, better late than never…

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 2 comments… read them below or add one }

Clyde Bailey September 13, 2014 at 9:24 PM

I’m not sure I am in favor of creating a clinical programming “Language”. I think it would be more useful to create a set of specifications for interfaces for EHR systems. HL-7 is a start, but it is way too clutzy for my taste. What I’d like to do (when I retire, and have the time) would be to start a library of mix-and-match “Services”, which can be written in any number of languages, that work together and from which someone could build an HIM system that would do whatever combination of things you need done. I’m working mostly in support of clinical research, which may be more of a niche market than I realize, but I keep wishing that there was a system that I could just plug my special case test or report into, and I wouldn’t have to spend as much time on what I consider to be “Overhead” programming. I have built sort of such a system, but it isn’t ideal. I agree with you about FoxPro. That is what I was working in when I started this project 15 years ago, but the MD that I was working for at the time specified MS-Access, so that is what I have built my systems in.

Reply

Jerome Carter September 14, 2014 at 7:30 PM

Clyde, thanks for your comment. If the goal is moving data in and out of EHR systems, then I agree, a clinical programming language would be overkill. However, the current focus on EHR systems obscures the fact that not every clinical information system is an EHR, and that clinical computing need not be limited to entering and retrieving data from an EHR system. EHR systems are built with general purpose programming languages, making it difficult to experiment with clinical concepts computationally. A clinical language would make this kind of experimentation easier, and could possibly result in innovative clinical productivity software. Such a language would be a great tool for creating the top level of clinical care systems. Take a peek at these posts: http://ehrscience.com/2014/04/28/is-the-electronic-health-record-defunct/ and http://ehrscience.com/2014/08/11/building-clinical-care-systems-part-v-supporting-clinical-work/.

Jerome

Reply

Previous post:

Next post: