The Trouble With RxNorm SCDFs

When an outpatient provider writes a prescription, the strength of the tablet (capsule, etc) will be specified.  For example, the prescription will read, "Prednisone 20 mg tablet; Take 2 tablets by mouth every day".  This is a prescription for 40 mg of prednisone daily. 

For inpatient providers, the strength of the tablet (etc) is typically not specified.  They only want to specify the total amount of drug.  For example, "40 mg of prednisone by mouth daily".


RxNorm is the vocabulary that is used for medications.  It has various different types of term.  The "SCD" term type refers to "Semantic clinical drugs".  This is the type that specifies the specific type of drug tablet (etc).  For example, "Prednisone 20 mg tablet" has the RxNorm code "312615". As mentioned above, the SCD term type is not as useful for inpatient medication orders.  What type would be useful?  When originally examining RxNorm, the "Semantic Clinical Drug Form" (SCDF) seemed to be what I wanted.  It was essentially like the SCD terms, but without the specific strength.  For example, the SCDF code for "prednisone tablet" is "373585".

The Issues:
For one, the SCDF is actually a combination of REGULAR ingredients (IN) + the dose form.  By stressing "regular", I mean to point out that this does not use the "precise ingredients" (PIN).  (Quick example of regular ingredient vs precise ingredient : "metoprolol" is a regular ingredient, "metoprolol succinate" is a precise ingredient).  This will work for most medications, but when you have medications where the precise ingredient matters, you may find that the SCDF is inadequate if those precise ingredients use the same dose form.

Example--the SCDF for "Penicillin G injectable suspension" includes the following different medications:
* Penicillin G procaine
* Penicillin G benzathine
* Penicillin G procaine + penicillin G benzathine combo

 Another issue is that injections don't really fit the expected behavior.  Normal saline and hypertonic saline share the same SCDF, despite being dramatically different in their indications.

Example of EMR unusability - finding the correct order

Just an example of why current EMRs are so unusable is the difficulty in searching for the appropriate order in CPOE.  Just as an example, a few years ago I tried searching for normal saline in a popular EMR implementation:

• "NS" - failed search
• "Normal saline" - failed search
• "Saline" - failed search
• "NaCl" - failed search
• "Sodium chloride" - successful search

About halfway through that search list is when I wanted to throw the computer across the nursing station.

An EMR company may defend such results, saying that it is the client who is responsible for creating the orders and synonyms.  But my dictum is "Never let the client have a bad configuration."  Another way of saying that is, "Never let the client make your EMR software look bad."

Or "Don't invite comparisons between your software and Vista/CPRS".


EMR vendors should provide basic synonym support for orders.  And in addition to that, it should provide an automated test system, where each of these search terms is entered in and the results are evaluated for the expected order type.

EMR development's fundamental flaw

As I've said before, I think one of the core flaws in the typical process of EMR development is that the programmers do not actually use the software--they are not physicians/nurses/etc.  Let's contrast this with the development of word processing software--practically every programmer is also a potential user of the software, and so when something during the execution of the software is "off", the programmer will likely spot it him/herself, and go in and correct it.  Or if indenting something took an unusually large amount of mouse clicks, then they would catch on to this and fix it.  An even better example might be the programming of an IDE (ie software for programming software).  While I may have the occasional gripe about NetBeans or similar software, modern IDEs (with the possible exception of Apple's XCode) are incredible pieces of software.   

With EMR development, the programmer does not actually use the software, at least not in a real life kind of way.  Instead, they often rely on the advice of consultant physicians.  But this one degree of separation from use is very significant in my opinion.  While the physician knows the "it would be nice if it [did such-and-such]" things, the programmer knows the underlying data structures and what the EMR IS and IS NOT capable of doing.  While reconciling these two things (what is desired vs what is possible) can be done between two people, it is very inefficient.  When the programmer and the physician are the same person, this process is exceedingly more streamlined.

Moreover, the small things that a physician may find wrong with an EMR may just get ignored, because the process of explaining to the programmer why some part of the UI is annoying to use may be too much effort.  EMRs should actively solicit feedback from ALL users, not just paid consultants.  There should be an easy-to-access menu option that a user can select to provide such feedback--a suggestion box.  FEEDBACK, FEEDBACK, FEEDBACK is what is needed. 

UMLS errors

I frequently find errors in the UMLS.  The most recent one was this past week (version 2015AB).  The atom ID was 'A23834045';--a MTHSPL atom--and had the title:

 Phenytoin 50 g ORAL TABLET, CHEWABLE

"50 g" (ie 50,000 mg) is probably a fatal dose (for most horses).  This obviously was meant to be "mg".  And if someone were entering this by hand, then this mistake would be a little more acceptable (although in that case, they should have an algorithm that parses the strings and throws out warning signs if it does not appear to be valid.  And why are they doing it by hand?)  I'm not sure that this was hand entered.   I went and downloaded some DailyMed data that these entries are derived from, but this data did not have the error.  (It was released a few days ago, so it may have been corrected since then).  So how did the error make it into UMLS?  Perhaps I'll never know.


  

Intro

This is an informal blog dedicated to the topic of electronic medical records (EMRs).  While the title of this blog has EHR (electronic health record) in it, note that I (like most of the people I know in the industry) do not differentiate between the terms EHR and EMR.  The fact that the ONC (Office of National Coordinator) DOES differentiate between these suggests to me that these government officials are out of touch with reality.  Probably victims of vendor-speak...

As far as my background goes, I am a computer programmer as well as an internal medicine physician.  I am currently developing a prototype for my own EHR.  In medical school, I never thought I would want to pursue medical software professionally, but my experiences with EHRs in the second half of medical school as well as residency drove me to this.  In short, I feel that almost all medical record software is pretty lousy.  If the computer programmers who designed the software were forced to use the software they created, it would not be this bad. They would immediately notice the flaws and fix them.

A good EHR will:

1. Not be terrible.  This means it will present a user interface that supports efficient record retrieval and entry.  It should not take 5 minutes to find the patient's endoscopy reports.  
2. Go above and beyond and make the physician's life easier.  When a provider pulls up an outpatient's chart before the visit, it should alert the provider to all health maintenance items needed.  It should also make recommendations regarding what to do.  In other words, it should save the provider time. 

These are pretty broad objectives, but I am not aware of any existing EHR that accomplishes these successfully.

More to follow...