rxinformatica's blog

One of the seemingly insurmountable challenges that face CPOE, pharmacy, and e-Prescribing is alert fatigue. Alert fatigue results when something like drug drug interactions (DDIs) are highly insensitive or have a high rate of false positives. When a clinical information system imports DDIs from a commerical provider like FirstDataBank (FDB), you get every single possible interaction that may occur. This paradoxically results in a situation where noisy alerting may impede clinical decision support rather than facilitate it. In Greenberg and Ridgely's JAMIA commentary, Clinical Decision Support and Malpractice Risk, they poignantly highlight:

"CDS represents a situation in which malpractice and products liability can too easily lead to a perverse equilibrium in which the law has a detrimental effect on technology and in which patients, physicians, institutions, and the government are all made worse off as a result."

Happy new years! With a new year and 6 solid months of pharmacy informatics experience, it is time to re-visit "Internal Med? There's an app for that!" with an another perspective.

--

Timothy Cole asked an intriguing question on ASHP Connect regarding an "Apple friendly Hospital":

Hello everyone!

I'd like to know if anyone out there knows of or has worked for an Apple based hospital or at least an Apple friendly hospital? The hospital I work at uses Meditech and PCs and it just seems like there HAS to be a better way to do things.
What is your experience / opinion of the most user friendly EMR / PHA module / system? What about one that is the most consistent or the most efficient?

Clinical decision support is equal parts aiding the clinician to 'automagically' make the right decision and presenting options in a way that is intuitive. Being afforded the luxury to design the user interface of clinical design support advisors also brings up unique challenges. The clinical information may be very precise and accurate, but there is a need to present it in a way that facilitates a good user experience.

Speaking to programmers and developers, there is one usability book that is universally recommended: "Don't Make Me Think" by Steve Krug.

I'm going to pick up a copy and review it shortly.

Whether you hate Apple or love them, they also have a very good set of usability guidelines here.

via rxinformatica

I'm near the end of my clinical pediatric rotation and have had a unique opportunity to look at how clinical information systems (CIS) are used in peds. Everytime I've encountered pediatric medicine someone has stated the dogma of "peds are not tiny adults." That certainly makes sense from a pharmacokinetic perspective, but how do we teach that to our information systems?

Since we use the same computerized provider order entry (CPOE) system and pharmacy system for pediatrics and adults, it creates all sorts of havoc that we must solve. Examples:

• Should you barcode breast milk? If so, how?
• Up until birth, the mother and fetus are treated as '1' patient in the record, do you create another patient record upon birth (*hint* yes, you should)? If so, how? How does this affect your admission, discharge, and transfer (ADT) system?
• How do you handle a drug (eg., cefotaxime) that is formulary for peds and non-formulary for adults in the same system?
• What happens when a drug (eg., desmopressin) intended to be used one route (nasal) is actually used for another (oral)?

These questions if not addressed appropriately can create all sorts of therapeutic and safety problems. A majority of pharmacy related issues specifically concern clinical decision support (CDS) and drug file manipulations.

Learning a variety of computer and markup languages can be very useful in helping understand interoperability in the informatics world. Lately, since so much of the clinical decision support I work on deals with a web interface, knowing HTML, CSS, and javascript is a must. Along this line, I have also gotten to understand XML a little better. There's no doubt you've probably heard of "XML"; it ranks with "Web 2.0" in regards to one of the most hyped terms of the last decade. So what's the big deal with XML?

XML, or Extensible Markup Language, provides a foundation for creating data and data documents. XML is great in terms of interoperability because it is very standardized, yet simple. Multiple systems can all understand well formed XML without having to convert it into another (often proprietary) format.

It is called extensible because XML provides a solid standard which other standards may incorporate. For example, look at the following XML code:

<XML>
<pharmacy_orgs>
<title>American Pharmacists Association</title>
<abbreviation>APhA</abbreaviation>
</pharmacy_orgs>
</XML>

XML is self descriptive; the individual element tags can be named whatever the developer desires. This leads to the code being easier to understand without actual programming knowledge. Depending on what document type definition (DTD) is declared, specific rules are then evoked in order to parse or make sense of the XML. Where HTML concerns itself with displaying data, XML is used as a way to store it.

XML also stores data in a hierarchal structure. In the above example, it would look like:

Not long ago, the IT department in an institution held all the power. In an era of emerging technology, users were at the mercy of the whims of people who controlled the business IT infrastructure. When there was a change process, IT did not consult with departments; they just went ahead and made changes. Now, with increased user awareness and technical competence, along with a greater presence of competing outsourcers, there is an greater focus on IT as a service. The concept of aligning your IT department and the services it provides to users' businesses became known as Information Technology Service Management (ITSM).

I've been reading up on literature regarding Computerized Provider Order Entry (CPOE) implementation strategies and ran into this article. It's quite old but significant and controversial. When the article was published, it was during a time when CPOE was still very young with relatively little solid data to back it up. This paper from Children's Hospital of Pittsburgh serves as a good case study of how bad things may happen to good technology.

In essence, the hospital retrospectively showed that the unadjusted mortality rate rose from 3.86% pre-CPOE to 6.57% post-CPOE in an intensive care setting. The reasons stated why CPOE didn't work did not seemed like they were issues with CPOE itself, but rather the hospital's infrastructure and work processes.

The article states "[a]fter CPOE implementation, order entry was not allowed until after the patient had physically arrived to the hospital and been fully registered into the system, leading to potential delays in new therapies and diagnostic testing." It's hard to believe the software would do this; was this a tech issue or a policy problem?

Furthermore, they complained that the "...physical process of entering stabilization orders often required an average of ten “clicks” on the computer mouse per order, which translated to 1 to 2 minutes per single order as compared with a few seconds previously needed to place the same order by written form." UI design is very important, but they didn't state the technological "savy-ness" of the user. 10 clicks = 1 to 2 minutes?! I've seen some Twittered-frenzied residents microblog 140 characters faster than I could hand write my own name.