Doing Something Different (Go Brewers!)
I have been writing this blog for 8+ years. This is the first time I recall going completely off topic. I want to talk about baseball. Tonight all of us in Wisconsin are celebrating the Brewers advancing to the National League Championship Series.
There was a play in the top of the 9th inning that drives me crazy. The Diamondbacks had runners at the corners with 2 outs. The Brewers Betancourt scooped up a slow bouncer and raced to 2nd base, ariving a split second before a sliding Justin Upton.
Why does Upton slide into second base? I would argue that sliding slowed Upton down enough to allow him to be forced out. What if instead, he were to run through 2nd base to avoid the force? Sure he would be tagged out before he could reach 3rd base. But the runner at third would have already crossed the plate before he could be tagged. I am gad that didn’t happen because that run would have likely eliminated the Brewers.
If a runner is forced out for the final out another runner crossing the plate will not score, even if the runner crosses home before the force out. If the runner is tagged out after reaching the base, then it becomes a matter of what happened first – the final out or the runner touching home plate. Because the runner at third usually has a bigger lead, they typically can cross home plate at the same time the force out occurs. Even if Upton were immediately tagged after running through second, the Diamondabacks would have scored the winning run.
Maybe someone will post a comment telling me why I am wrong. Maybe there is a rule that requires the runner to slide. But I think Upton slid because, for over 100 years, every player in the same situation has slid.
Is there something in your IT operation that you do because it has always been done that way? Is there a simple but unconventional change that you can make to get a better results?
Maybe this post wasn’t off topic after all.
The short list of great American inventors
Alexander Graham Bell (March 3, 1847 – August 2, 1922)
Thomas Alva Edison (February 11, 1847 – October 18, 1931)
Henry Ford (July 30, 1863 – April 7, 1947)
Steven Jobs (February 24, 1955 – October 5, 2011)
These people radically changed the lives of every American alive in their lifetime. It was awesome for me.
SaaS and the Enterprise
I hate desktop software. Every new application is a potential conflict with mission critical software. Then you have the effort of installing and updating. It is a terrible model for the enterprise. Wherever possible I am looking for Software as a Service (SaaS) option.
Adobe has a potentially great service in their CreatePDF SaaS offering (once they add the ability to manipuate PDFs online). The need to create and manipulate PDFs is wide-spread in my organization, but I don’t want to take on the burden of installing Acrobat or some similar app on hundreds of desktops.
Unfortunately Adobe is rolling CreatePDF as a consumer offering. A separate credit card for each use is not a model that works for the enterprise. People like me would be lining up for this service if there were a front-end where our Provisioning team could easily add and remove users and we could receive a quarterly invoice based on the number of users.
I think Adobe is missing the boat. DropBox is another cool app that does not have an enterprise model (box.net seems like a good enterprise alternative).
Bring Your Own Device in Healthcare?
The NY Times has a good article on the increasing popularity of Bring Your Own Device (BYOD) policies. This is appealing to many employees, and interesting to me. I want to further empower our tech savvy employees. But, I don’t think it won’t work in our environment at this time.
It is probably no mistake that the company cited in the article is Citrix Systems. I am sure that they have had a corporate IT purchasing policy for years that restricted purchased applications to those that work well in their Citrix environment. I think an environment where are applications are served via Citrix is a key requirement for a BYOD policy. All that is required is the IT to make sure that the Citrix client is running on the employee’s device. This leads me to…
Reason #1 that BYOD doesn’t work in a typical healthcare environment: Most applications don’t run well on a Citrix.
At Ministry Health Care and Affinity Health System we have literally hundreds of apps that we cannot deliver on Citrix. In fact so many, that we don’t try to deliver apps via thin client technologies unless there is a specific need to do so. Because most of our client applications run locally on the employee’s PC, we need to tightly control that environment to avoid conflicts and other things that keep people from doing their job.
It is probably reasonable to assume that the employees at Citrix Systems are more technologically savvy than the average employee base. Consequently the IT department at Citrix Systems doesn’t have to worry about the devices being in a usable state. That is not the case for our employee base, while we have many IT savvy employees many others, especially our caregivers, spend more time thinking patient care than computers. Many need a lot of help with basic PC support.
Reason #2 that BYOD doesn’t work in a typical healthcare environment: Many of our users require a lot of support from IT just to make sure their computers are in a working condition. IT cannot efficiently support hundreds of different device models.
I have seen it all, from browsers with a dozen installed toolbars to deleted system files. I would love to allow users to install their own software and customize their computers, but history has proven that there are far too many disruptions to the work environment when a liberal desktop management approach is used.
The story also quotes that Citrix Systems has reduced its device cost by 20%. But I am sure that doesn’t include the multi-year investment in Citrix software and servers required to deliver the applications to the desktops. That is hundreds of thousands of dollars and a significant new support requirement for organizations like ours.
In the future we might be able to offer such a policy to a certain group of users (managers and analysts). But there would be a lot of work in developing a plan to move that model and right now there this does not arise to the level of the most strategically important issue for Ministry to tackle. Needs like improved clinical information systems come first.
Google’s Outage Is A Lesson In Excellent IT Operations
Google had an outage this week. Google Docs, which I use at home, was down for about an hour. They wrote a post about the outage on their blog.
I think this post is a great lesson in effective IT Operations. Our IT organization is working on improving all of these areas, but we have more work to do to get to Google’s level of kung fu:
- Effective, transparent communications: They are very transparent about the incident. They want their customers to know that such events are unacceptable; they take it seriously; and they are taking measures to improve service.
- Change Management: They understand that these problems are almost always caused by unsuccessful changes. By looking for the failed change, their troubleshooting is very quick. They resolved the problem by rolling back the change that caused the problem within 30 minutes.
- Monitoring: Their monitoring tools uncovered the problem within 30 minutes.
- Downtime Status: They talk about the Apps dashboard which is a tool for customers to see the status of their services.
- Root Cause Analysis: They quickly completed a Root Cause Analysis and are quickly moving to implement process based changes to minimize the likelihood of a repeat occurrence.
The fact of the matter is: outages happen. The most successful IT organizations don’t kid themselves about eliminating outages through redundancy or other means. They use the means above to minimize the customer impact.
Meaningful Use Rant 3: ICD-9 Coding of the Problem List
I am all for standards. The more we define and codify the practice of medicine, the better and more interoperable our EHRs become. But a standard, for the sake of a standard, takes us backwards.
I believe the writers of the Final Rule that defined Meaningful Use of an EHR took us backwards when they specified two different standards for coding the problem list (SNOMED and ICD-9). Most organizations appear to be using ICD-9 to code the problem list. I believe that this is because SNOMED is way too complicated and there is no decent implementation reference.
But ICD-9 coding of problem lists does not make sense. Firstly, this country is in the process of migrating away from ICD-9 codes. Why make that process more laborious by creating one more conversion? Let’s skate to where the puck will be.
More importantly, ICD-9 codes do not describe problems in the hospital. ICD-9 codes are medical billing codes. Sure, they are based on a disease classification system, but problems are not always analgous with a disease or condition. For example, an important problem to note during a hospital stay is that the patient is “at risk for fall” based on a fall assessment. What is the ICD-9 code for this?
ICD-9 codes collected as part of creating the problem list will not provide any additional data beyond the ICD-9 codes that are already abstracted as part of the billing process. So, this pseudo-standard does not provide any new insights. Furthermore, I don’t believe this codification will do anything to improve the interoperability between providers and systems. In the end this is work for work’s sake. Busy work keeps us from implementing the rest of meaningful use that has true benefit to the patient and those that pay for care.
At least this is the way I see it. Am I missing something?
Augmenting the IT Department’s Offerings
I think that part of being a productive employee in the 21st century is finding online services and mobile appps to meet your needs that are not met by the IT department’s standard offerings. Since Internet service and a modern browser are typically standard offerings, this opens up a whole world of offerings. Browsing simplespark.com gives you a sense for the IT services that are available.
Using web based services is not the same as asking the IT department to install software on corporate devices. That ultimately creates a support burden on the IT department. People don’t understand why we don’t want to buy and install their $100 application. It isn’t the $100. These are the things that IT managers hate about one-off software installs:
- we need to reinstall that ap every time we upgrade or fix the user’s PC.
- the help desk team members need to have knowledge of the applications when they call the user
- in a short period of time we will get a call telling us the software version is no longer supported and we need to purchase the upgrade, convert the data and train the user
But more importantly, locally installed software is increasingly unneccessary as Software as a Service (SaaS) makes everything accessible from the browser. Our corporate QuickBase account gives our user base a simple but powerful way to meet many of their needs for dabases and basic workflow. This is why our employees have created over 7,000 applications. This is 7,000 times that employees were able to meet their own needs instad of requesting software and services from IT.
One of my favorite web-based services is Toodledo. Toodledo.com is a web based to do list (there are iPhone and iPad apps) to. I like it betther than Outlook tasks. I like the usability and there are some cool features like automatic prioritization based upon due date and prioirty. Mostly I like that I can access it anywhere without launching a Citrix session. This is important becuse I use it to manage my work tasks and my personal life too. I use the paid version because it allows me to store attachments with my tasks. But the free version is impressive.
Meaningful Use Rant 2: Hospital Growth Charts
So this is the second in a series of rants regarding some of the more silly aspects of the Meaningful Use Stage 1 Final Rule. Let’s visit core obective 7 for hospitals (pg 257 Fed Reg):
(7)(i) Objective. Record and chart changes in the following vital signs:
(A) Height.
(B) Weight.
(C) Blood pressure.
(D) Calculate and display body mass index (BMI).
(E) Plot and display growth charts for children 2–20 years, including BMI.
The writers of the Meaningful Use rules were on a good roll there. A through D are totally reasonable. I believe every EHR should capture these things and hospital should be document these vital signs for most inpatient stays.
My best friend’s Dad ran a manufacturing plant. I remember him saying that the way to find the optimal setting on a piece of equipment is to turn the dial until it breaks, then go back one setting. I kind of feel that is what happened with this objective. They should have stopped at (D). Growth charts are great, every pediatric practice should maintain one for each child, and in this day and age they should be computerized. But why would a growth chart be a requirement for a hospital stay? Does that make any sense? I have spoken to a few pediatricians and none of them have stated that there is a medical need for a growth chart in the hospital stay.
This looks like a sloppy cut and paste from the Eligible Provider Objectives to the hospital objectives without thinking through the different environments.
Meaningful Use Rant: Quality Measures
I am writing this post, with the intent on writing a series of rants about the Meaningful Use objectives that must be met in order to secure the EHR Incentives made available by the economic stimulus bill.
Let’s start with the Meaningful Use Quality Measures. I believe this is a huge missed opportunity. We will accomplish them using the same tired back-end abstracting approach that we have always used.
I believe the quality measures will fail to be a tool for caregivers to monitor safety and quality; nor will they create a means by which payors, government or consumers can compare quality.
All of the report specifications are written using SNOMED codes and we do not use that medical nomenclature today. In fact, virtually nobody uses SNOMED. Why not write the quality measures using medical descriptions?
But, the real kicker is that everyone is rushing to measure something without talking about the clinical processes and the appropriate place and way to capture the data in real-time. If we want to be able to have good comparisons, we need to have comparable clinical processes.
Each measure requires thousands of hours of work to design the right clinical workflow and IT processes. But, instead of having objectives that define best practice for managing care and capturing data in real time, we jump straight to measurement. We skipped the most important step.
Simple example: 8 of the 15 hospital EHR Incentive quality measures deal with stroke. At what point do we know that a patient is a stroke patient? Is it when a stroke nurse completes a stroke assessment? Is it when the radiologists reads the brain scan? Is it when the attending physician reviews the CT interpretation and makes the diagnosis and instructs the nurse to begin a plan of care?
Assuming one of these is correct, then a hospital’s EHR would need:
- a codified stroke assessment form;
- the ability for the record representing the CT scan of the brain to be flagged by the radiologist (or rad tech) as indicating stroke; and/or
- the the creation of a stroke plan of care.
There are NO meaningful Use objectives for any of this. Are hospitals using EHRs to monitor stroke in real-time and take corrective action when proper care is not given? Almost none. Instead, a human being will read the hand-written notes and dictated physician reports then key ICD-9 codes into the EHR. Those will then be translated into SNOMED codes to populate reports.
All of this will take place long after the patient has left the hospital.
The Live Huddle
Affinity Medical Group’s EHR pilot went live on GE Centricity EMR this week. It has been a well run project throughout and I had the honor of joining our bright, hard-working team for their end of day huddle. They did a few things that I really liked. This is not exhaustive list. I would love to hear from others on their ideas to run the Live Huddle.
Issues
The primary focus of the Live Huddle is the issues that have been surfaced during the day. The issues are typically categorized something like this:
- Critical infrastructure or application problem that is having a negative impact on business operations (bad)
- Unanticipated issues that need a near term resolution
- Workflow issues
- Suggestions for improvement
As always the documentation of the issues is key: detailed descriptions, good examples and no abbreviations. One day I will blog about what constitutes a good issues list (tip 1: you can’t use Excel to manage issues). A great issues list is one of a handful of key project controls required for project success.
During the AMG huddle today I saw the team was using paper forms so they could jot down issues on the fly. Later they entered them into the project issues tool. Ultimately the live issues need to get into the same tracking tool as the rest of the project issues.
Statistics
During AMG’s huddle they shared some key stats about the day. I really loved this because it made the use of the system more tangible, building on the sense of accomplishment. Here are some stats from today’s huddle:
- refill requests processed: 27
- labs ordered: 64
- phone notes: 125
- visit notes: 129
Mood
The other creative thing that this group did was create a form that gauged everyone’s mood. Everyone was encouraged to complete the VERY SHORT form, including IT, managers and especially users. I think this can serve as a good early warning sign if the project is heading south.
What are your tips for a goo Live Huddle?
