DrugCite is a database hosted by the FDA that houses all the reported side effects associated with a drug. According to the website:

“One of the primary ways that the United States Food and Drug Administration monitors the safety of marketed drugs is the collection and analysis of reported adverse events (an event that was not the intended outcome of the prescribed drug and has a negative impact on health) through the Adverse Events Reporting System (AERS). These reports are submitted by physicians, healthcare consumers, lawyers amongst others, and then the FDA scientific staff will assess these events in the context of other databases to determine if a particular safety concern is associated, and possibly caused by, exposure to a particular drug. Since this is a public database and useful to prescribers and patients alike to know if “has what I’m experiencing been described in patients taking this drug before?” DrugCite has created a more friendly interface to answer that question. Use of this data should in no way be confused with the FDA’s rigorous process of evaluating the potential link of adverse events to drugs as causal but merely represents a portal into what is currently being reported to the Agency.”

It’s a neat concept, but please take the information with a grain of salt. Remember that the FDA will list anything that is reported while an individual is on a medication, whether or not the drug is truly the offending agent or not. For example, I searched for acetaminophen and received the graphs below. Looks pretty scary on the surface, but I consider acetaminophen to be one of the safest medications on the U.S. market when used properly. Something to consider when using this tool.

The data were on the physician’s external hard drive, officials said. Though the hard drive was encrypted, a piece of paper with the password was nearby and is also missing. The physician notified UCLA the next day and officials began identifying patients affected.”

I am continuously amazed at the number of security breaches involving patient healthcare information caused by careless use of portable storage media like external hard drives, flash drives, and even laptop hard drives. Patient information should never be stored or transported this way. I believe that utilizing cloud computing with simple browser access is a much better solution. 

What makes this particular incident so bad is the cause; reckless behavior by a physician. This wasn’t UCLA’s fault, per se. Sure, the medical center must accept a share of the responsibility, the lion’s share of the blame falls in the lap of the physician. Not only did the physician have sensitive patient information on an external hard drive, but was dumb enough to have the password to access the drive on a piece of paper next to it. Kind of defeats the purpose of encryption and passwords, doesn’t it.

For an eye-opening look at the magnitude of data loss and security breaches drop by DataLossDB.org sometime. It’s scary stuff.

• 80% were concerned with stolen personal information
• 64% were concerned with lost, damaged or corrupted files
• 62% were concerned with the misuse of information”

I’m not surprised by the numbers. In general people are afraid of change and the unknown. With that said, I think all you need to do is walk a patient through the paper processes that we use now to give them some insight into how bad things really are. Stolen and lost personal and medical information is a major problem within the current healthcare system. It’s not uncommon in any given week to hear about patient records that have been lost or stolen. And as far as misuse of information, well lets just say that’s all too common as well.

The advantages to an EHR outweigh the concerns listed above. Just sayin’.

Data surrounds us. It’s in everything we do, from the bank statements we receive in our personal life to the mountains of data collected by every healthcare institution. Regardless of the data collected, there are basically three things that can be done with it. Data can be ignored, it can be archived or it can be used. Unfortunately only one of those three things is truly useful; using it. Many people chose to ignore or archive data not because the information isn’t valuable, but because they are overwhelmed with the amount of information they receive and the way that the information is presented.

Presentation is everything when it comes to data. The methods we chose to present information can make the difference between the information being useful or being useless. The significance of such a problem creates a quagmire for pharmacists as theirs is a data driven environment. Pharmacists spend a great amount of time emerged in data; patient data, lab data, micro data, kinetics data, drug data, usage data, nursing data, physician data, and so on.

Data visualization and dashboards can help. They provide us with the tools to better understand the information around us, and therefore improve efficiency in the process.

Data visualization
Acording to an article by Michael Friendly in 2008 (1) data visualization is “information which has been abstracted in some schematic form, including attributes or variables for the units of information”. In other words it’s data that’s put on display in a format that’s easier for the end user to understand, i.e. the use of an image to represent tables full of data.

It’s difficult to conceptualize the benefits of data visualization until you see it in action. This was recently demonstrated to me at the unSUMMIT in the form of a poster on data visualization by Charles Boicey, MS,RN-BC, PMP, Informatics Solutions Architect from the University of California, Irvine Medical Center. The poster demonstrated the value of data visualization by utilizing several different methods to present information collected from bar-code medication administration (BCMA) override scans. The information was displayed in table format along with various types of graphs and images. The tabular information was virtually useless as it was difficult to wade through the data and make sense of it. However, the visual representation of the data created a much more powerful statement that made the data easier to understand.

According to Vitaly Friedman (2) the “main goal of data visualization is to communicate information clearly and effectively through graphical means”. While the concept is simple, the application is more difficult and requires a keen eye and the ability to think in abstract ways. If you can get it right, it’s powerful stuff.

Dashboards
Dashboards take data visualization one step further by aggregating several different pieces of visual information in a single location. Think of it as an information control panel where the end user controls what information is gathered and how it’s presented. A simple search for “dashboards” in Google Images reveals several excellent examples.

Even though the concepts are useful and commonly used in business applications, the use of data visualization and dashboards remain relatively uncommon in healthcare, which is unfortunate because they could go a long way in helping pharmacists understand what’s really going on around them.

References:
(1) Michael Friendly (2008). “Milestones in the history of thematic cartography, statistical graphics, and data visualization”

(2) Vitaly Friedman (2008) “Data Visualization and Infographics” in: Graphics, Monday Inspiration, January 14th, 2008

As healthcare inches forward interoperability of systems will hold a key role in the success of the government’s plan for electronic health records. So as Rob and I discussed how to integrate various services and products we pondered how one goes about creating a standard that everyone can live with. Well, how does one create a standard that everyone will use? Heck if I know, but we decided that there are basically two approaches. The first is to create a standard and try to cram that standard down everyone’s throat. Microsoft has been fairly successful with this approach. With that said, few people have the resources that Microsoft has to throw at a problem. The second approach is to offer the standard as part of a free solution that comes with your product; this way people can use your product and use your free, open-source solution to tie the systems together. I assume this is the smart approach for companies that have limited resources; kind of a grassroots approach. Of course it would be wise to build this free, open-source solution on top of an existing standard that’s prominent in the market, otherwise you’re trying to re-invent the wheel. And we all know what happens when someone re-invents the wheel. Uh, you get a wheel. We don’t really need any more of those. Both approaches have pros and cons.

Now the question becomes which standard makes sense as you design your solution. If only I had a crystal ball. We’re at least a decade away from having a truly inter-operable healthcare system; optimistic, I know.  Ultimately, the standard of choice won’t be driven by what makes sense, but rather will be driven by adoption rates. Things often become a standard without even trying.

In the article a pediatrician that is also director of clinical informatics for Atrius Health is quoted as saying “At the moment I’m not convinced that there’s a secure enough place in the cloud or that the functionality exists for us to do everything that we need to do in the cloud. The cloud allows for a tremendous amount of interconnectivity between computers because it’s using data storage that’s free amongst different networks and I wouldn’t want healthcare information being scattered in a way that I couldn’t protect it appropriately.” I’m not sure I understand the perceived insecurity of the cloud as the existing infrastructure for storing patient information in healthcare is, by design, insecure.

I don’t think most of the fear swirling around the cloud is necessarily associated with the physical security of the servers or the lack of encryption, but rather the regulation attached to healthcare. Everyone wants to know that information is safe and they don’t want to get dinged by one of the regulatory agencies. Everyone is worried about being HIPAA compliant along with the fines associated with the HITECH Act for breaches of patient information. I can’t guarantee that every cloud provider meets HIPAA regulatory compliance, but that’s why you have a sit down with the cloud provider and understand what you’re getting yourself into before you jump in head first.

However, consider the results of a recent survey conducted by New London Consulting and FairWarning in which nearly one-third of survey respondents stated that their organizations were not currently in compliance with or feel that they will be in compliance with the HITECH requirements. How is that a good thing?

On the other hand, it’s in a cloud service provider’s best interest to be in full compliance with state and federal laws if they plan on staying in business. This could be a win-win, especially for healthcare systems that need someone to help control their data.

Based on available cloud models one could argue that data is more secure in the cloud than it is with many “in-house” systems. Cloud service applications are developed with cloud platforms in mind and use a common security model. Cloud providers tend to be aware of technology and security trends before the typical end-user. In other words, they pay more attention to issues such as physical security, access controls and perceived threats. It’s what they do, people.

Many consider data control and security in the current healthcare model a myth. It consists of data located in various places split among computerized storage and paper files. Do you really think this is a safe, secure and efficient way of storing healthcare information? A more important consideration might be whether or not the people arguing against cloud storage models understand the current state of healthcare data integrity.

Many people in various locations need access to healthcare information. In the current healthcare model this results in duplicate information found in paper charts stored by the thousands. It’s not uncommon to find these files lying around in various places like nursing units, physicians desks, etc. Don’t even get me started on what can happen when a hard copy of a record gets lost in transit to another location. And let’s not forget that some facilities may not have a readily available backup of these paper records.

Unfortunately, the problem with data integrity and security isn’t limited to paper records. Electronic records inside facilities are at risk as well. Medical records are accessed by many people for lots of legitimate reasons, but what happens when a physician or other healthcare provider walks through your door with a flash drive, an external hard drive, or even a laptop with patient data on it? That’s a walking HIPAA nightmare.

Laptops are everywhere and some physicians use them to transport patient data back and forth. In addition, laptops remain a mainstay for home health nurses and hospice care outside the hospital. They are both an indispensable tool and a tremendous security risk for healthcare institutions. If you don’t believe me just do a cursory online search for “lost laptop with healthcare data” and see what pops up. You’ll be shocked and horrified by what you read.

Information from a 2009 report by the Ponemon Institute indicated that Approximately 10,000 laptops go missing in airports every week. Some get recovered, but many don’t. The loss of these laptops is not only a security breach when they contain sensitive healthcare data, but they create a financial burden as well. It’s not just the cost of replacing the hardware itself, which we know is cheap, but the cost of detection, forensics, the loss of productivity and the possible fines associated with the data breach.

According to the Ponemon report, the average value of a lost laptop for all industries is $49,246. That’s a bargain when compared to healthcare where it’s actually around $67,873. Sure you can encrypt the data and take steps to minimize data breaches on these stolen or lost devices, but doesn’t it make more sense to simply avoid it all together? I think so.

A cloud model means that your information doesn’t need to be moved around and it doesn’t need to be copied or transferred from one system to another because the end user has the information available to them at any time from any device with internet connectivity. Pick your device: smartphone, laptop, iPad, it doesn’t make any difference as long as the device is web enabled and can see the information in the cloud.

Regardless of the situation – pharmacy needs information about a patient’s allergies or a patient gets admitted to the hospital and you need the old chart or you’re a physician on call that needs to know what a patient is taking or what their most recent labs are – as long as you have web access you can see that information. With the increasing availability of wireless connectivity it’s only a matter of time before having access at anytime from anywhere won’t be a slogan, but a reality. In addition the information remains safe because it’s not stored locally on the device. You’re simply using the device as a window to view the data.

A 2009 report on “Cloud Computing: Benefits, risks and recommendations for information security” by the European Network and Information Security Agency actually took an independent look at the technical and legal aspects associated with the issues of ‘cyber security’ and determined that “The scale and flexibility of cloud computing gives the providers a security edge.” Their reason for making such a bold statement was that they felt that service providers had the flexibility to instantly correct security issues, apply patches or implement additional security features if necessary.

Regardless of current feelings toward cloud computing, it is apparent to me that the consumer market is driving adoption. The InformationWeek article goes on to say “Nevertheless, last month two major announcements may have been the clearest indication yet that vendors believe there is promise in offering cloud computing to healthcare delivery organizations, especially among small and medium-size physician practices. In June, GE Healthcare introduced Centricity Advance, a new Web-based, SaaS platform that offers a combination of EMR, practice management, and patient portal solutions for small, independent physician practices. Last month also saw Dell announce a partnership with SaaS provider Practice Fusion to offer an electronic medical record package for small and medium-size medical practices.” We’re headed toward the cloud whether we like it or not. The market will eventually force healthcare to adopt the model, and being forced into something is never a good thing. While I believe in improving and optimizing existing systems, I also believe it’s important to explore future technology and decide where you want to be. Just a thought.

Here’s an HL7 feed from a ketorolac order. Note the red lettering:

PID|||0000194291^9^M10^KDHCD^PN~3017197^^^KDHCD^MR|3017197|ZZZTESTINGDRAEGRXXXX, ZZZTESTING||19740525|F|||361 N ABC AVE^^VISALIA^CA^93291|||||S|UNK|00001942919|||
PV1||I|3N^29^A||||TEST, A DOCTOR|||OP|||||||TEST, A DOCTOR |||||||||||||||||||||||||||200810231335||||||
ORC|NW|1|||||^Q6H&0600,1200,1800,2400&^^201004292400^201004302400^^^11111110||201004281226||JFT|TEST, A DOCTOR|||201004290000||
RXE||543^KETOROLAC TROMETHAMINE^2502190|30||MG|VIAL|THIS IS ONLY A TEST…..|||1|||AM1405427|JFT|||||||||||
NTE|||EVERY 6 HOURS|RXR|IV||||

Pyxis doesn’t recognize 2400 as a “real” time, and rightfully so. For those of you that don’t know, 2400 hours doesn’t exist in military time. Midnight is 0000 hours. Why would Siemens use 2400 hours to represent midnight? I have no idea, but Pyxis didn’t like it so it refused to deal with the order and simply discontinued it. The fix was a programmatic change by Siemens.

The idea of standardization isn’t new or limited, yet its use continues to elude healthcare. The concept is applicable to not only data, but processes as well. Unfortunately not everyone buys into the idea. I’ve even heard some argue that standardization removes clinical decision making from healthcare. What? That doesn’t even make sense. Standardized processes can actual create clinical decision making time by simplifying a repetitive task and creating consistency designed to prevent errors.

I spent several wonderful years working in a compounding pharmacy in the Bay Area; 3 years as an intern and about 2 years as a pharmacist. Many extemporaneous compounding formulas are complex so the owner of the pharmacy, whom I had tremendous respect for, had a rule that ingredients were placed to the left of a compound prior to use and to the right after use. If you’ve ever worked in a busy pharmacy then you understand interruptions and how easy it is to forget something in a hectic environment. The rule was a simple one, but saved my bacon on more than one occasion. And it certainly didn’t impair my clinical judgment. Similar standardized systems are used in hospital cleanrooms where attention to ingredient detail is paramount.

Other standardized processes that I’ve found beneficial over the years include:

• Standardized doses for pediatrics. I spent a few years working in a pediatric ICU. The facility I worked for had a robust set of policies that allowed the pharmacist to round doses ordered in mg/kg to the nearest “standardized dose”. For example let’s say a physician orders metoclopramide 0.15 mg/kg in a 1.85kg child. The resulting dose is approximately 0.28mg. As a pharmacist I was allowed to round that dose to 0.3mg, which was an available standardized dose. The advantages were obvious: fewer dosage sizes meant less waste, less labor for preparation and fewer opportunities for error, i.e. grabbing the wrong dose. In addition, many of the dosing increments requested were too small to be accurately measured by a syringe and would have been an estimate anyway.
• Standardized drip concentrations. Many hospitals use standard drip concentrations for pressors and other vasoactive medications, i.e. dopamine, norepinephrine, dobutamine, etc. This makes order entry easier and faster, reduces waste, reduces the risk of programming errors on pumps and creates a less complex process for drug dictionary maintenance on smart pumps.
• Standardized administration times. I love the use of standardized administration times. What’s a standardized administration time? I’m glad you asked. That’s when a hospital defines the times a drug will be administered based on the latin sig used, i.e. Q6H may be represented by 0000, 0600, 1200, 1800 or TID may be 0700, 1300, 1800. There are many possibilities. The use of standardized administration times has many advantages including easier and quicker order entry, consistency among nursing staff and less variability for the patient. Those that argue that this is a bad idea because it is difficult to get on a standardized schedule, just give me a call. There is absolutely no pharmacokinetic or pharmacodynamic reason why medications cannot be administered on a standardized schedule while in an acute care setting. You can try to argue that you can’t wait an extra 12 hours to give a multi-vitamin or that you can’t give cefazolin 2 hours early, but you won’t win based on any science that I’ve studied.

One thing to remember when creating a standardized process is to keep it simple. We often forget that complicated processes are fraught with opportunity for error. Everything we do should be broken down into the fewest possible steps and still remain safe and effective. Personal experience tells me that we’ve done a poor job of simplification in healthcare. We tend to complicate a process more often than simplify it; double and triple checks with multiple initials, paper trails, sign-off sheets, pharmacokinetic tracking forms, SBAR forms, manual lot number tracking, etc. If you’re using a paper form in this age of technology, you’re doing something wrong.

Don’t feel bad, we’re not the only ones responsible for creating a bloated and oftentimes overly complex system. Every time something goes wrong in healthcare the federal, state and local governments enact new regulatory processes that requires a barrage of paperwork and complex procedures. It’s an all-out assault on simplification, standardization and common sense.

Have you ever wondered why it takes so long to train a pharmacist after they’ve been hired? Every pharmacist has a similar core skillset that can be applied to most situations, right? Right. Their lengthy on the job training has nothing to do with their drug knowledge or decision making skills, but everything to do with learning all the idiosyncrasies associated with practicing pharmacy in an acute care setting. They have to spend time learning the rules, then the exceptions to the rules, then the exceptions to the exceptions and so on down the line. I’ve worked in six different hospitals during my benign career, so believe me when I tell you that it’s true. Some of the systems I’ve been exposed to were so old and complex that no one could remember when they were implemented, but everyone was afraid to change them.

It has been a busy month, so I won’t make any promises, but over the next couple of weeks I hope to present a couple of additional examples of where standardization is needed in pharmacy and why it’s necessary. Stay tuned.

The blog speaks specifically to the ownership of personal data versus allowing companies to sit on it and possibly hold it hostage secondary to a lack of compatibility with other systems. The information you throw onto the internet defines who and what you are, more now than ever before, and you need to be able to move it around anytime from anywhere.

Louis calls for people to host their own data in a standardized format instead of having data stored by one service provider or another. He goes on to say:

If I chose to log in with GMail one day, I would authenticate who I was, and GMail would pull down my e-mail stream, complete with e-mail activity history (such as replies and forwards). The data would not be stored on GMail, but instead be more like a read-only process, whereby changes to data, including sent items, would not be stored in GMail, but written back to my personal “cloud”, if you will.

Hosting one’s own personal cloud with our own data is not an end run around large corporations in fear of Big Brother, but instead, for real, true, portability. In this situation, a longtime iPhone user could pick up an Android phone, enter my own personal ID (be it through OpenID or some other standard), and pull down my details into all of Google’s native applications.

My brother, Robert spoke of something similar back in June of 2009 when he questioned how to identify and distinguish oneself from all the other people roaming the internet.

I find it interesting that Robert and Louis both mention OpenID as a possible standard. OpenID is a decentralized standard for telling websites who you are. It’s a very interesting concept; one that healthcare could benefit from. Think of carrying your electronic ID with you from place to place. No more learning ten new user id’s and passwords each time you change jobs. How nice would that be? Another option would be to have only one user id and password that gave you access to all the data you were looking for from a centralized hub.

If you look a little deeper though, you’ll find that Robert and Louis stumbled upon a common problem in the healthcare industry; how to handle the stream of data coming form patients and how to standardize it and distinguish it from everyone else’s data. Let’s face it, pharmacy is all about data. We collect it, store it, mine it and analyze it. When you’re looking at a patient’s lab work you’re looking at data; when you’re looking at a patients medication list you’re looking at data. How about their medical history, allergies, radiology results, endoscopy report? Yep. Data, data, data and oh yeah, data.

The problem with healthcare in general, and specifically pharmacy, is lack of a standard to collect, house and access this mountain of data. Some talk about HL7 and XML, but that’s just the box that moves the data from place to place. It’s just a standardized shuttle craft.

Some organizations, like ASHP, are discussing the use of standardized nomenclature systems like SNOMED CT and RxNorm to control the structure of the information inside the shuttle. Like Louis’ GMail and smartphone examples from above, a patient should be able to access their data from any device at anytime in a format that can easily be read by any commercial healthcare system in the world. Of course healthcare would have to adopt some form of centralized data storage, but that’s just part of the solution. Imagine no longer transporting medical records to your physician or having to give your medication history to a pharmacist at the 24 hour Walgreens because the mom & pop pharmacy you usually go to is closed. It’s something to think about. With all the money the government is throwing around to increase the use of health information technology the timing is right to build a foundation like the one Louis writes about. Just a thought.

PandoraVIA is the next generation of data crunching software from the company. According to the PDS website “PandoraVIA is the new, full-featured reporting system from Pandora Data Systems. It’s designed to be a highly scalable and affordable platform built with Microsoft’s latest technologies. These technologies take the full functionality from our Pandora (Legacy Edition) and PandoraSQL products and move them to the next level.”

The new software framework is designed to accommodate various modules depending on the needs of the customer. The system currently supports Pyxis, AcuDose, Omnicell, MedDispense and Cerner. However, after spending some time with the Pandora representatives at AHSP Midyear they informed me that their new system could add custom data from almost any source based on need.

PandoraVIA utilizes XML, SOAP, and WSDL to meet the needs of the healthcare system, and is capable of a host of reports that can be exported in a variety of formats.

A system that can aggregate data from many different sources offers real value to many healthcare disciplines, especially pharmacy which is often driven by data. Data mining is important, but not always easy because of the myriad of systems utilized and the general poor quality of integration. In addition, many IT departments aren’t equipped with the necessary resources to handle a project of this magnitude; believe me, I’ve tried.

Data I would like pulled into such a system include our Alaris Smart Pump data, our pharmacy information system (Siemens Pharmacy) data, our automated dispensing cabinet (Pyxis) data, our carousel, packaging and inventory control (Talyst) data, and our bar code medication administration data. Aggregate data from these systems could be mined for an infinite number of possible trends and uses.

Posted via email from fahrni’s posterous

Like many other professions, pharmacists don’t particularly like change. So when I offered to relieve them of their 3×5 index cards with a more high tech solution they were a little hesitant. It took some persuasion, but I was finally able to convince them that all the information they needed was readily available in electronic format. Unfortunately the information was scattered throughout several systems, requiring multiple clicks and views. The solution was to create a “rounds report” that would pull information from the various systems and display it in a single location.

I’m certainly not an expert with database design, but I can get around ‘ok’. The report displayed below is the final version of the pediatric rounds report that was created. I also created one for ICU rounds. The information displayed in the report is pulled from various SQL tables on the back end of the pharmacy system in addition to a little visual basic used to grab the most recent lab values from the laboratory system. With a little encouragement I was even able to get the pharmacists to use the “Notes” section in our pharmacy system to leave information for each other regarding the patient. Paired with a tablet PC, the report has given the pharmacist a giant, electronic, real-time index card. Sweet!