One of the most difficult aspects of creating clinical systems is rendering clinical concepts in a way that allows computers to reason with them.    This is the central challenge in areas such as decision support, workflow management, and interoperability.   Building smart EHRs requires computable concepts.

Let’s consider a simple example using test orders.   Version 1.0 of a system allows clinicians to order tests by selecting them from a drop-down list.   Inside the computer, the list appears as nothing more than a series of terms as seen below.

Complete Blood Count
Prostate Specific Antigen

Obviously, the computer does not know the meaning of the words, so it will happily allow a provider to order a PSA on a women or a screening mammography on a man—not very smart.   The system can be made more intelligent by attaching gender information to the tests and creating programming code that uses that information.

Test Name Gender
Complete Blood Count N
Mammography F
Prostate Specific Antigen M

Now the test file contains information detailing the appropriateness of tests by gender.   The programming code to use this information might be rendered as:

FUNCTION Order_Tests
IF (GenderOfPatient=GenderOfTest)  OR  (GenderOfTest=N)
      Allow Test to Be Ordered
     Do Not Allow Test to Be Ordered
    Give Warning (“Test not appropriate for the gender”!)
END Order_Tests

By adding additional information to the test file, such as cost, normal ranges for results, critical values, etc., it is possible to create programming code that automatically flags patients with abnormal results or computes the total cost of tests for each patient.   Similar approaches can be used for any clinical information.  For example, if the criteria for diagnosing a disease are provided, an EHR can look through its patient data to see who might have a particular disease, which is analogous to what these researchers did.

The benefits of adding additional information to a test’s profile are obvious and relatively easy to realize.  However, when tackling more complex activities, such as workflow and clinical decision support, additional concept representation problems appear.   Time is a good example.

Before, during, and after describe human concepts of the temporal relationships between two or more events.   Consider a CBC result entered into Mr. Doe’s results file on 5/7/12 at 10:03:47 AM.    Using the time stamp, before is 10:03:46 AM and earlier, during is 10:03:47 AM, and after is 10:03:48 AM and later.    Now suppose we want to use test results to determine if a drug may be causing anemia.   Drug orders will have date and time stamps that are analogous to those used for test results.  In this case, the patient’s drug file indicates that drug  X was given on 5/5/12 at 8:12:21 AM.  What is required to answer the question, “Did Mr. Doe develop anemia during the time he was taking drug X?”

Obviously, a person looking at a patient’s medication list and noting that drug X was started on 5/5/12 at 8:12:21 AM would see the connection since the drug use continues up to the present.    However, a  database query using just time stamps would  miss this connection because the drug’s administration and  the blood test would be seen as non-overlapping events that occurred at 5/5/12 at 8:12:21 AM and 5/7/12 at 10:03:47 AM, respectively.   Thus, obtaining an acceptable answer to this query requires a means of rendering before, during and after in computer-understandable forms.

Since there are no hard-and-fast rules for rendering clinical concepts in a computable form, system designers are on their own.  Ontologies and executable guideline systems are examples of attempts to address the need for computable clinical concepts; however, this is still very much an open research issue.   Meanwhile, system designers do the best they can when adding decision support and clinical workflow management functions to EHRs.

This is an admittedly brief post for such a complex topic; yet it should provide sufficient insight to understand why no one has built the ultimate smart, easy-to-use EHR —it’s hard.  No, make that very hard.



  1. Hi Jerome, a student of mine who now works for my company tackled this problem for his PhD for ICU notes which are even tougher than the database solution you have posited here.
    His system is still running there after a few years but people weren’t all that interested in it.
    I think there is a serious gap between what doctors say they want and what they are prepared to use independently of usability issues. It is something to do with entrenched processes and not wanting deviate from established methods yet it is very evident they are happy to use new technology. I think some of the issue comes from the “ostensible source” e.g. Apple vs a PhD Student even when the latter does much superior work.

    1. Jon, there are so many instances of novel, high-quality work not being recognized for its true value. Aside from whether clinicians use the software, it still has value in helping to create/understand/test the design principles and methods I mention so often. It would be so wonderful to have a Journal of Clinical Care Systems Design where work like that you mention could be shared, recognized, and debated. Today, the focus is on products, not principles, which is unfortunate.

Leave a Reply

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