SaaS and the Enterprise

Posted on by

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?

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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?

EHR Certification is a Black Box

Posted on by

The EHR vendors have not been sharing HOW their products are being certified. Currently, it is a black box. This is VERY frustrating. Especially since hospitals and doctors are supposed to be using the EHRs as cerified. Often there are many ways for an EHR to accomplish a testing objective. The current certification just produces a check box and a pretty certificate.  How do we deploy and use the product in a certified way is a mystery. My EHR vendors have not been forthcoming with this informtation (slippery is a term that comes to mind).

During a HIMSS meeting with an ONC official, it became apparent to me that ONC now realizes this is a problem. There was a discussion that the vendors should provide screen shots for each step to share this with their customers. ONC can compel them to do this, but I would like to see the vendors do this on their own.

For me, this is one more reason to take the self certification route.

Replacing David Blumenthal

Posted on by

It appears everyone was surprised by the announcement from ONC HIT Coordinator Dr. David Blumenthal that he will be departing his government post to return to academic life. By all accounts he is a great guy and I wish him all the best.

[edit: One of our Clinical Informaticians pointed out that this has been rumored for some time and Blumenthal himself said his stay would be limited. So, in the sentence above when I say “everyone was surprised” – I guess I meant I was surprised]

I would suggest that when Dr. Blumenthal is replaced, the administration should appoint someone that has a more intimate knowledge of the reality of health care IT operations and what it really takes to achieve healthcare IT objectives. Another candidate from academia would not be the right choice. I would suggest someone with hands-on, in the trenches, implementation experience in a variety of healthcare provider settings is what is needed now.

Many of the current rules for EHR incentives just don’t make sense or lack necessary definition. There is too much focus on alphabet soup, and not enough on common sense. Just to be clear I support the implementation of standards, but they have to be relevant standards and they have to further the goals. Let me give you some examples of EHR incentive rules that seem to be rules, for rules sake:

  • Problem lists are great and needed. But the certification requirement that problem lists use ICD-9 or SNOMED coding is wrong-headed. There is a ton of time being spent mapping ICD-9 codes to problems for no true benefit. The mapping is highly subjective and the end result does not create something that is reliably shared between providers that are not sharing the same EHR implementation. This time could be better spent developing care plans and interventions that help patients get to goal reliably and less expensively.
  • I love the patient portal concept and the notion of giving patients access to their medication list, allergy list, problem list, etc. But, the certification requirement that one must do this using the emerging CCD or CDR formats is using the wrong tool for the job. These standards, once mature, should be great for sharing records between providers. However, this is useless to a patient and another place where we are spending time on something that is not getting us closer to the goal.
  • Why are the NIST specifications for quality reports written using SNOMED codes? Nobody has this information in their EHR coded in SNOMED. Now the burden is on each hospital and doctor to map these codes to ICD-9. A total waste of time.

I am hopeful that an ONC HIT Coordinator with more direct experience can:

  • write sensible rules, that are not ambiguous;
  • keep the scope of the objectives achievable in the set time frames; and
  • make sure all of the work required is work that gets us closer to the goals of more safe, effective and efficient care.

Since I am posting this on Super Bowl Sunday, I have to say: Go Pack Go. This is a big day here in Wisconsin.