Sometimes I feel like a lone wolf...

I'm sitting here at the 2009 annual meeting of the American Medical Informatics Association. This is my first time at this meeting. I was disappointed to see such a sparse pathology presence here, but given my limited interaction with the organization and its website, I wasn't terribly surprised. It is a problem which needs to be corrected especially given the influence that this organization has on national policy.

Having said (written) that, the meeting has been great so far. The buzz mostly surrounds the HITECH portion of the American Recovery and Reinvestment Act (ARRA). David Blumenthal gave a keynote address, and during the question session afterwards, one gentleman whose name I unfortunately don't have, gave a wonderful analogy to a situation that I find myself struggling with on an almost daily basis. He said that HITECH should have been constructed much more like the Clean Water Act. In the Clean Water Act, those companies who are producing the pollution as a result of manufacturing are responsible for introducing measures to reduce it. Everyone who lives downstream of the water which has been polluted are not required to do anything because, while they are consuming the water (after its been treated, obviously), they are not creating the pollution. Unlike the Clean Water Act, HITECH and HIPAA puts the burden of compliance with the federal regulations on the end user of the technology rather than on the vendors producing and designing it. This is akin to requiring everyone who lives downstream of polluted water to clean it up because they are consumers of it.

I went to a talk put on by the Certification Commission for Health Information Technology (CCHIT - www.cchit.org). I think that certification for information systems sounds like a great idea. It would make it much easier for me and my institution, as consumers of these systems, to make educated choices without spending huge amounts of time doing research. CCHIT obviously has its flaws, but I think that the concept is good. However, when I checked the CCHIT website, there is no Laboratory or Pathology working group. Radiology and Pharmacy are also missing. Pathology (which, for clarification, as far as I am concerned always includes Laboratory Medicine), Pharmacy and Radiology are usually the three biggest utilizers of health information technology because of the information management demands (I like to refer to them as the Big Three). CCHIT does have medical subspecialty groups, though, because cardiovascular health and dermatology are both represented by their own working groups. If CCHIT gets deemed status, such as what the College of American Pathologists (www.cap.org) has for inspection and certification of laboratories under the Clinical Laboratory Improvement Act (CLIA), then I have grave concerns that the information needs of the Big Three are going to be unrealistic or insufficient. In the laboratory as in other medical areas, we have very specialized needs which CCHIT and HITECH have not yet addressed.

For example, is there any plan to require certification of middleware and instrument software? These applications house protected health information (PHI) just like electronic medical records (EMRs), but in my experience there are much less likely than laboratory information systems to be compliant with the HIPAA Final Security rule, even though that rule was in force as of April 2003. This puts me in a bit of a pickle because, in some cases, the only instrument that is available to provide the medical care that our patients need has associated software which breaks the rules. This is not an uncommon situation, and it takes quite a bit of discussion with a vendor to get them to realize that this is a problem. This is a huge time drain. Sitting between the end users in the lab who really want the instrument and the instrument vendor whose software has serious problems is not a fun place to be, and I am finding myself there more and more frequently. Simply from a time perspective, it would be nice if certification extended to these other medical applications so that I could spend my time doing things that are much more productive, like research and development of new cool tools.

I am concocting some plans to help change this situation, but if anyone has any constructive suggestions on how not to be a lone wolf crying in the darkness, I would be happy to hear them. I've gotten a few so far, one from the former National Director of Health Information Technology and others from members of the AMIA Policy Committee. All of them are sure to make me very unpopular, but when has that ever stopped me?

Where is proficiency testing for information systems?

In the laboratory, there are several components to bringing up and subsequently maintaining a laboratory test for patient care.

1. Validation: Laboratories are required to perform validation testing on prior samples to ensure that the new test or new method is performing in a clinically meaningful manner.
   
2. Post Implementation monitoring: In the initial period after a test becomes available for prospective testing on clinical patients, most laboratories perform a higher than normal level of monitoring of test performance in order to ensure that there are no problems or that any problems are resolved.
3. Proficiency testing: Laboratories are required by College of American Pathologists and CLIA to perform periodic testing of the performance of the assay to ensure that the test that was initially validated is still performing as expected for the samples tested.

With Information Systems, regulations and accreditation hold information system support staff and faculty responsible for validation and for post-implementation (go-live) monitoring of any change to the Information systems.

However, where is the proficiency testing? We can show logs of what we have done to validate and monitor our systems, but how does any regulatory agency know that any information system is adequate for its use?

• Can the information system handle the volume of information that it is currently being given? What if there is a sudden increase in volume?
• What are the disaster recovery plans for the information system? Do they have backups? How quickly are those backups able to be restored? Do they have redundant hardware in case of a hardware failure?
• How many downtimes does a system have? Why? How long are they? Is this reasonable?
  
• Is the system business-continuous? Shouldn't all systems have some impetus to gain true business-continuity since healthcare is a 24/7 business with frequent time-sensitive needs to gain information?
• How does a test order look in the entry system? Does the system require that certain fields be completed before the order is sent? Does the provider have an easy way to get help if the order that he/she is looking for is not available in the order catalog?
• For paper orders, does the information system flag the person entering the order into the system to gather any missing information, effectively preventing them from going further until the information is acquired?
• For non-CPOE systems, does the system allow a user to attach an order to a generic "non" physician in the ordering provider field? If it does, is there some sort of reminder to the user at a later time to update the information when possible so that the specimen can be processed in the immediate term but still reminds them to get the correct provider in a timely manner? For communication about critical or unexpected results, it is imperative to know with whom to communicate.
• For interfaced systems, what are the limitations of the interface? What results are not crossing and cause medical staff to have to search for results on paper rather than in the LIS or EMR?
• Do providers (including pathologists) have access to all retrospective data on all patients and not just a small subset of laboratory or other history?

These are just a few things that a well-designed proficiency testing program could objectively evaluate and grade. Grading and accrediting these systems according to best practices, regulations and standards (HIPAA, HL7, barcoding, etc.) could provide impetus for vendors to improve their software products to gain certification/accreditation that could then be used for marketing while improving the tools that laboratorians and others have to use to provide needed care to patients in an efficient and meaningful manner.

Task Management - Does anyone really have the answer?

I've read a lot of books on organizational skills, time management and project management, and yet I still struggle with task management. Because I'm managing a multitude of projects, I often, despite my best efforts, find myself in crisis management mode which leaves me feeling less than accomplished at the end of the day.

How does one balance working on a project, which for me requires uninterrupted time to focus, with multiple daily interruptions and a bunch of single straggler tasks that also need to be done outside of projects? Some of the books will tell you that you should start saying no to projects in order to lighten your load and to increase the efficiency with which you can complete the projects to which you have already agreed. In health care, this is an inordinately difficult task to accomplish, in my opinion. There is always the risk that if something doesn't get done, then patient care could hypothetically suffer. This is true of directing and maintaining information systems and services just as it is in providing direct clinical service to patients. While the impact of not providing direct clinical service has much more immediate impact to an individual patient, the impact of not correcting information system issues can have both an immediate and far more wide-reaching impact to much larger numbers of patients.

Electronic and paper-based management systems each have their own advantages and disadvantages. Calendars are definitely best left electronic, in my opinion, because of the advantages of others in my organization being able to query my calendar for meeting time. While this may seem like facilitating the interruptions previously moaned about, on the flip side these meetings would get scheduled anyway, and at least this way I don't have to take the time to search my calendar to find potential times for a meeting, e-mail that back to the sender, get the time and date for the meeting from the sender, and then manually schedule it in my calendar. Of course, sometimes we go through multiple iterations of the sending back and forth by e-mail when the electronic scheduling assistant is not used, and this is, quite frankly, highly annoying.

Task management systems, however, are another story. Most calendaring programs provide good task management for people who have less than 100 tasks in their master task list. For people with 40 projects and about 2000 tasks to be completed, these applications are lacking in that they don't have master task and child task capability that is formatted in an indented manner. If you are a Microsoft shop, as we are, then you know that Microsoft provides this capability, but it requires Microsoft Project Server Accounts which many institutions don't have. These have the additional advantage of tying in all of the people on your project to the same project planning file.

So what do you do when you don't have this? More importantly, what do you do to keep up when you don't have access to a computer to keep things up to date? PDAs can be helpful. My PDA is synced to our Exchange server; but I find that looking at tasks on my PDA is frustrating because of the limited view, difficulty in adding new tasks using the stylus (takes a lot longer than typing), and the amount of time it takes to pull 2000 tasks up into view.

I'm still in search of a good task management system that balances trying to complete about 40 projects at one time (some of which are quite large and time consuming; others not) with daily clinical service, teaching and research responsibilities. If anyone who reads this blog has any good suggestions, I'm all ears.

The First Blog

The idea for this blog came from my daily work life.

I'm a pathologist, and I specialize in Informatics. Informatics is a very broad term, which as many know is defined differently by seemingly every person to whom you ask the question "What is Informatics?" (an official definition has been posted on the American Medical Informatics Association web site). For me, Informatics is just what I do every working day, and that is to provide faculty-level oversight for the laboratory information systems (LIS) as well as the ancillary support systems operating within our laboratories. Decisions have to be made frequently...some good and some...well...let's just say that I've learned more than a few things. Everything is relative, but the term "trial by fire" at times feels appropriate and hence the title of my blog.

I learned much of what I know about Informatics during my training. However, there are some things (okay, maybe a lot of things) that you just don't find out until you are the one who is charged with making the decisions, or at least greatly influencing them. Since I started in my current position, I've reflected upon the fact that these types of decisions are faced by many pathologists. After all, practically every laboratory in the United States has some sort of information system which has to be managed, and medical input into that management is critical to its success.

Could other pathologists learn from what I have been through? I don't know, but I hope so. Some will undoubtedly find this topic boring...until they get hit with a HIPAA audit. So here goes...

By the way, the opinions expressed in this blog are my own. Completely. Entirely. No exceptions. They certainly do not represent the opinions of anyone other than myself or any entity, including any organization in which I hold membership, for whom I work or with whom I have had the opportunity to conduct business.