For the last ten years, I worked for a health center that serves several underserved populations: the gay and lesbian community, HIV positive patients, and patients that lack sufficient health care. Over that time, we have built a complex and extensive information system to help support the mission of the organization.
This series is about how technology can be integrated into the delivery of health care, and the problems that come up along the way in getting the technology to work. I suspect that technology causes suffering for some in spite of our best efforts to the contrary. But our purpose in implementing technology is to reduce suffering by passing repetitive tasks to the computer while increasing the amount of time available to people to do what they are good at (like doctoring, lawyering, and so on). Within healthcare, automation can also reduce patient suffering by reducing errors (for example, by ensuring accurate prescriptions, or reducing the number of times the same data must be entered into systems that support patient care), which should improve the quality of care that patients receive from their physicians. When used properly, technology should also bring relevant knowledge to the user as they are doing their job (by making negative drug interactions known to a prescriber, for example).
But technology can cause trouble for users that were perfectly happy with their paper documents. The transition to an electronic system from paper can be tricky; moving from one computer system to a newer one can also pose real challenges. This series is meant to help technologists and users out there in the world to avoid some of the common pitfalls with technology as both start full steam in implementing health IT to take advantage of the incentives in the ARRA.
This series is also about the place where the rubber of our lofty humanitarian and economic goals meet the road of personality disorders, unreasonable expectations, and inefficiency – which is to say the path to get a computer system working for the people that will ultimately use it. For the technologist, I do not think you can avoid the road (there are not yet helicopters in the arena of health IT implementation – though one day there may be), but you may at least find some solace in the fact that you are not the only one to have traveled this path. For end users that might happen to read this book, you might perhaps recognize a peer or yourself in this book and gain some insight into why your IT staff always seem to grumpy.
While others have contributed to the subject matter, any mistakes in this series remain solely those of the author. Please feel free to contribute by making comments on the blog. And good luck to those of you implementing technology.