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.
|Complete Blood Count||N|
|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 ELSE Do Not Allow Test to Be Ordered Give Warning (“Test not appropriate for the gender”!) ENDIF 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.