The Need for the API Strategic Summit - Part 2 of 2

For part two of this blog, I have incorporated data from the API Strategic Summit committee, chaired by J. Mark Tuthill, MD.

Right now, for reasons both understandable and not, the federal government has been focusing on meaningful use and certification of Electronic Health Records (EHRs).  It would seem that laboratory information systems (LISs) have largely been left out of this equation, seemingly relegated to merely a data feeder to the EHR.  Under current regulations, the only way to "certify" an LIS is when it is a module within an EHR.  Regardless of where a LIS sits (either as an EHR module or a independent system), the importance of high quality and highly-specialized laboratory systems cannot be over-emphasized.  

The API Strategic Summit will take place June 7-8, 2012, in Pittsburgh, PA.  It is entitled "The Future of the LIS and Pathology Informatics in the Era of the EMR".  During the summit, we will address the following questions:

• What is the value of the LIS to pathology departments and how is it documented and demonstrated? How to improve the inadequate understanding on the part of hospital CMIOs and CIOs of clinical labs operations and functionality requirements of the LIS?
• How can Departments of Pathology work together on information standards (and mandates) that affect Pathology?

We have commitments from major LIS corporations to attend this meeting.  This is an unparalleled opportunity to strategize with multiple vendors at the table on how we can ensure our collective ability to provide patients and providers with the most up-to-date, accurate, rapid and safe laboratory testing through our LISs.  

Interested parties should contact Nova Smith with the Association of Pathology Informatics for information on how you can attend the summit.  I hope to see you there.

The Need for the API Strategic Summit - Part 1 of 2

Laboratory Information Systems are at a cross-roads.  With the passed and impending legislation surrounding health information technology, the primary focus has been on Electronic Health Records (EHRs).  Laboratories generate vast amounts of data.  The reason why we generate vast amounts of data is because providers order laboratory tests on patients at almost every encounter.


If laboratories don't have high quality and highly specialized systems to support the work that they do, providers will find it very difficult to take care of of patients.  Here's why:

• Laboratories generate a huge amount of data, and much of that data, while not seen by providers, is critical to store, manage and review as part of our quality and compliance processes.  These are data generated by intermediate steps during the testing process.  These data are often more important than the final result when trying to troubleshoot a problem that occurs at the time of testing or at a later date.  I estimate that the final result (the piece that providers see) comprises only about 20% of the actual data that is produced and stored by the laboratory during the performance of a simple test.  For highly complex tests, this estimate goes down to 5% or less.  Laboratories that cannot utilize their information system to store critical pieces of testing data such as this must resort to paper worksheets which are subject to retrieval and permanent loss.  Use of paper worksheets can facilitate:
• Manual data entry errors
• Delays in turnaround times (when compared to automatic batch run generation in an appropriately configured information system)
• Errors in manual calculations
• The workflow within an individual laboratory is largely managed by the routing of the specimen in the information system.  When the workflow in the laboratory does not match that of the information system, the results typically cause confusion, delays in turnaround time, and rarely patient-to-specimen mismatches.
• Just as patients do not always present with the typical by-the-book signs and symptoms of a particular disease, neither do their laboratory results.  Laboratories need systems that can flex to the strange and unexpected, and those systems should be able to communicate those results to EHRs in clear and unambiguous ways. 
• Providers make a LOT of decisions based on the data that laboratories provide them.  If we can't provide the right test and right result at the right time, then patients suffer.  Laboratories are full of smart people who want to help others.  Imagine what it is like to try and do that when the computer is fighting you at certain steps in the process.

The Association for Pathology Informatics (API) is working to help laboratories get the very best information systems for their laboratories.  Over and over again, we hear stories of laboratories being "burned" by unanticipated problems in functionality, resulting and mis-interpretation of those results by a provider due to poor display of those results in the EHR.  These are all being compounded by new technologies that providers need and want for their patients that current information systems are struggling to house.  Standard molecular tests, next generation sequencing, whole slide imaging, proteomics, and high-throughput image analysis with the future promise of combined imaging/molecular analyses are either currently in use in some laboratories or will be in the next five years...and laboratories currently using those modalities are having to work-around the deficiencies in their information systems to bring this needed technology to patients.  See my next blog entry for more on some of the exciting activities that API is working on to help laboratories work with vendors to bring in the next generation of systems.

So What is Pathology Informatics?

Imagine my chagrin when, after my last post, my father informs me that he found my blog.

Oops.

It is a good thing that my dad has a sense of humor. He then took the opportunity to inform me that after whining poetical about how no one understands what I do for a living, I still managed not to explain what I do for a living.

Touché.

So, dad, this beer, I mean blog, is for you.

Let's start with informatics. The American Medical Informatics Association (AMIA) defines informatics as “A general term used to refer to biomedical informatics and its many areas of application and practice (e.g., bioinformatics, clinical informatics, public health informatics).” They subsequently go on to define biomedical informatics as “the interdisciplinary, scientific field that studies and pursues the effective uses of biomedical data, information, and knowledge for scientific inquiry, problem solving and decision making, motivated by efforts to improve human health.” Additional definitions can be found on AMIA’s glossary page.

Pathology Informatics is essentially biomedical informatics practiced by pathologists within the scope of pathology practice.  Unknown to many in the non-medical profession, the scope of pathology practice is huge. Surgical pathology, cytopathology, chemistry, transfusion, microbiology, hematology, molecular diagnostics, immunology, transplant immunology and autopsy medicine all fall within our purview.

Laboratories generate enormous amounts of discrete data on patients every hour of every day. Providing faculty oversight for the acquisition, management, storage and retrieval of this data in our laboratories is my job. In order to get an idea of the weight of the responsibility that I feel, let’s review how much data we are talking about…

If you work in a hospital, think about the numbers of lab results that you use to manage your patients on an hourly basis. Now multiply that across all patients in all of our facilities 24 hours a day, 7 days a week. Now, just to make it more fun and to complicate matters, let’s tweak, change out or add new computer systems (a.k.a. information systems) here and there constantly to improve the care we deliver to patients. Existing care cannot stop during these changes, and our patients’ data have to be delivered on the right patient at the right time to the right provider. We have hundreds of systems running at my multi-facility institution, and most of them are tied to one another via interfaces. Information is flowing at super-speeds between these systems. The laboratory alone has numerous systems humming with data being brought in, updated, and sent back out to the tune of billions of data elements each year. Ensuring that a patient’s data is transferred accurately and quickly from one system to another is a very complex task in this environment, especially when some but not all of the systems may be undergoing changes which could affect the transfer of the data. Checking and rechecking systems before changes are released into production can be very tedious and requires immaculate attention to detail. Fortunately for me, I work with a group of laboratory information system support personnel who are very good at doing this.

So, if I have personnel to do the checking, what is my role? As a physician who specializes in pathology and a techno-nerd with knowledge of healthcare computing, I review the design and implementation of new and updated systems using my hybrid experiences in pathology and information technology in these and other areas:

• Hardware infrastructure
• Data models
• Network design and security
• Software design, display and security
• Result reporting
• Interfaces
• Barcoding
• Digital imaging and image analysis

It also includes other not-so-fun but necessary things such as:

• Reviewing information technology contracts
• Trying to explain to various individuals that yes, we really do have to comply with local, state and federal laws such as HIPAA, HITECH, CLIA and others and what that means for application X that they want to install
• Ensuring that our laboratory information practices meet or exceed the standards put forth by the aforesaid regulations as well as by the College of American Pathologists Laboratory Accreditation Program, the Joint Commission and other programs.
• Preventing medical errors due to poor data management or design before they happen.

However, there are a lot of truly fun things that I get to do:

1. Improve patient care and prevent errors that can hurt people
2. Help develop new tools to improve data retrieval and management so that our work is safer and easier
3. Teach residents and fellows
4. Give talks at meetings about my activities with #1 and #2
5. Collaborate with my pathology informatics colleagues
6. Travel lots of places to see and learn new things

At some point, when Emory finishes overhauling massive laboratory information systems, I hope to inspire a new generation of pathology informaticists/informaticians, some of whom I hope will share my admittedly wacky sense of humor. 

Oh, the irony…

Let's talk about pathology informatics…the ironic side of pathology informatics, that is. Let's start this discussion by providing some background.

So much of what a pathology informatician does is very serious. One false step and you could be on your way to mishandling the data for tens to hundreds to thousands of patients at one time. The stress alone can make some of us very cranky. OK, really cranky. Despite the fact that what we do is very important, it is often under-appreciated and usually under-recognized because it is in the background of many health care operations. That is, of course, until something goes wrong…

However, outside of work, describing what I do for a living to my friends and family, many of whom are not in the medical or information technology (IT) profession, has been…well...uh...an interesting experience.

Pathology Informatics is a science whose terminology is still not well understood by most members of the medical community unless it is part of their practice. Hence, describing what one does for a living as a pathology informatician can be especially difficult outside of the medical environment (and sometimes within it). After I explain that, yes, pathologists are physicians, and no, pathologists don't just do autopsies, and no, working in a laboratory is almost nothing like what is presented in popular television crime shows (my personal favorites are the ones where Congo red stains can be performed with a few dips of an already stained H&E slide, with the cover slip still on I might add, and the ones that have dark laboratory working spaces with pink and blue back lighting), the conversation usually dies (no pun intended) or is suddenly changed in subject if I'm speaking with a casual acquaintance. After all, I've just dashed their hopes that crime scene investigation is glamorous, fashionable and has no odor. Exchanges with my loved ones and close friends, on the other hand, bear striking resemblances to the following:

Interested Loved One or Friend: "So, how's work?"
Me: "Fine."
Interested Loved One or Friend: "So, what is it exactly that you do again?"
Me: "Pathology Informatics."
Interested Loved One or Friend: "So, what is it exactly that you do again?"

This conversation, if for the first time with the interested loved one or friend, is usually followed by my attempt to explain in greater detail of what pathology informatics is. I use terms that I think are fairly simple like "providing faculty level oversight over the laboratory computer system", "helping people manage laboratory data," etc. This is sometimes countered with "don't they have IT people to deal with all that?" With some people, I've literally had this conversation, the same conversation, multiple times. With my parents, neither of whom are in the medical profession, it is sometimes followed by vague hints of uncertainty as to what purpose my medical education actually served, especially since said parent(s) contributed financially to such education to some degree. I think at this point that they are just happy that I'm gainfully employed.

Within the medical community, however, the difficulty lies elsewhere. While there is usually recognition of the term informatics as something to do with computers and management of health care data, identifying oneself as a pathology informatician meets with certain risks.

First, after overcoming any preconceived notions of the stereotypical pathologist which resembles something akin to a hermit hiding behind a microscope, a corpse or both (actually an unnamed emergency medicine physician made the mistake of passing along a phrase he had heard to me because he thought he could get away with it..."a weasel behind a hedge in front of a bank"), a pathology informatician may have to hurdle additional assumptions associated with being an information technology (IT) nerd. You know...pocket protectors, no fashion sense, no social skills and physical coordination skills envied by well...no one.

OK, so I have to admit that while I was persistently, and I do mean persistently, the last one picked for kickball teams in elementary school (including but not limited to some events where team captains actually argued about who had to have me), believe it or not, at least some of these assumptions certainly don't apply to me, nor do I think that they would in most pathology informaticians.

As my primary example of the irony of stereotypes vs. real life, let's take the cross cutting assumption that both pathologists and IT nerds lack social skills. You would think, with that double whammy, that none of us would even be able to venture outside of our offices for fear of actually having to speak with something that wasn't conversing primarily in binary.

I confess that I had the same assumption. I had an interest in computers as a pathology resident and managed to get a CAP Foundation award to attend the then-called Advancing Pathology Informatics, Imaging and the Internet (APIII) meeting. As the time to attend the meeting drew near, I began to have serious concerns about the possibilities for social interaction while there. I mean, I had already been on some interviews for residency where I was literally sitting in front of an attending pathologist who gave one word answers to every question I asked and who was happy to sit and say nothing for long periods during the interview. Yikes.

However, as I soon discovered on that trip to Pittsburgh back in 2000, nothing could have been further from the truth. Pittsburgh was not only beautiful, but conversations at the meeting were lively, even without the open bar, and as some may know, earlier APIII conferences involved a Quake tournament with prizes handed out for the winner. Unfortunately, I was just as bad at that as I was at kickball, but I had fun playing regardless.

I soon came to the conclusion, especially after starting my practice at Emory, that there was a very good reason why people were so engaging at that and every subsequent meeting. To be an informatician, good social and communication skills are absolutely necessary if you want to stay sane. Of course, one's crankiness from the stress of trying to ensure that implementations of new technology are safe for patients can have some impact on how...ahem...well received your communications are, but for the most part, if you aren't adept at communicating IT lingo and issues to the medical community and medical needs to the IT community, you aren't going to be very effective or happy as an informatician.

With the non-medical, non-IT community, however, the difficulty in communicating effectively is more than doubled because you have to explain both IT and medical jargon to a group that isn't familiar with either. This is a challenge that I haven't mastered yet, but perhaps, if someone is reading this blog, he or she can comment as to what they've found that works.

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.