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.

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.