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.
Wednesday, July 5, 2017
Wednesday, February 8, 2017
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:
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.
- "NS" - failed search
- "Normal saline" - failed search
- "Saline" - failed search
- "NaCl" - failed search
- "Sodium chloride" - successful search
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.
Sunday, January 29, 2017
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.
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.
Subscribe to:
Posts (Atom)