I have now been a Federal Employee for a couple of months, the first time since I mustered out of the Army in 1983. Having spent all of my professional life in areas other than the federal government, I had previously viewed government’s work with suspicion and skepticism.
The challenges I faced as my career shifted, from direct patient care to the corporate environment, required that I adapt and shift focus. The broader perspectives that I developed supplanted the “us versus them” view I once held and helped me better understand the value of the new HHS initiatives to use health IT to support better care, smarter spending, and healthier people. So when the opportunity to bring my experiences to the federal government arose, I jumped at the chance.
Becoming an early adopter
I was an early adopter of health IT and used an early version EMR in my office. I thought I was pretty smart – smart enough to re-do all of the “canned templates” that came with the system. Turns out, though, I was guilty of what I now see many others doing: trying to modify the system to do something it was not designed to do. I ended up scrapping my “custom” templates and used the standard ones. I learned a lot from the experience, and my own mistakes (hint: validate that the backups actually work before you update the system). But, by using an EMR, my practice was able to better coordinate patient care. One of the real benefits I found was the ability to view notes from the midwives anywhere, anytime, through remote access. I also discovered, thanks to the EMR, why a few of my patients were not responding to treatment: an obscure drug-to-drug interaction reduced the efficacy of the primary medication being used.
Developer insights
After leaving clinical practice, I worked with several EHR developers and had my first run in with programmers. After trying to use the technology they had created, I asked “what were you thinking?” only to learn that a clinician had not been part of the front-end development. No wonder it was clunky!
One challenge I learned from this experience results from developers crafting a system to do something in one way, but when that same system is implemented, it fails to deliver a key functionality. For example, the CCDA export can generate a nice summary of care to share with the patient, but if implementation does not take into account the intended recipient(s), formatting may suffer, and usability does too. Same issue arises with a Transitions of Care (TOC) document because different specialties want to see different things. The fact that the data is there does not mean it will be filtered and displayed in the way I might want it displayed. This problem creates more noise than signal. Helping to move the needle (the right way!) and improving that signal to noise ratio is something I get excited about.
Engaging clinicians in hospital settings
I have been involved in several large EHR roll …read more
Source:: http://feedproxy.google.com/~r/healthitbuzzblog/~3/EyFhYC_wp-A/
