For my final post, I would like to comment on the OCT meeting I attended on Dec 13. This was an interesting opportunity to see behind the scenes. I remember when I first came into the hospital, I noticed a big push about everything EMR. There was always a new poster somewhere about what new advance was being introduced. And the net presenter usually have some new Cerner fix. So, being able to see how these decisions are made and by who was quite interesting.
The start of the meeting was filled with talk of the slowed performance times in Cerner. This was particularly a problem with patients who had been in the hospital for extended periods of time, such as in an ICU. I guess what happens is that there are so many data points entered in for the patients, such as vitals, pain scores, etc. This brings up the question in my mind as to if we actually need all the data we are recording. I remember scrolling through countless care-giver assessments and such to find the one pice of data I needed. Maybe we need to cut down on that stuff until we can get a system that can handle it.
They mentioned also that to gather data on this, there are people who follow providers around in the hospital and track how long it takes them to access the information. I'd never seen this, but it seems like an interesting way to know what is actually happening on the wards, instead of just relying on random reports from users.
Another topic touched on was that of communication. How to reach all the users to let them know of any changes. I'd never realized how big of an issues this really can be. If no one knows what the change is, then it doesn't matter that it was made. It seems the team does a good job of publicizing changes, through net presenter, the Cerner welcome screen and posters around the hospital.
One note about changes. De McKenna mentioned in our earlier meeting, that some hospital systems just use the same version of their EMR for many years, getting to become experts in that without making lots of changes. This is probably helpful, especially in instances where residents change every year, or where older physicians have difficulty learning new computer programs.
The safety dashboard was also mentioned. This is interesting, and helpful, especially for nursing staff to be able to go to one place to see if each patient is taken care of.
Finally, they touched on the central line checklist. I like checklists, especially for procedures or tasks that require many steps or many pieces of information. I don't think we should think that we can always remember every little detail and to do every step in a complex procedure, because we can't. Other industries use checklists and I think it's great that we are starting to implement them more. Dr Atul Gwande's Checklist Manifesto has an interesting view on this:
"It somehow feels beneath us to use a checklist, an embarrassment. It runs counter to deeply held beliefs about how the truly great among us - those we aspire to be - handle situations of high stakes and complexity. The truly great are daring. They improvise. They do not have protocols and checklists. Maybe our idea of heroism needs updating."
Overall, the meeting was very interesting to attend, and I got a feeling that wherever I end up, I would like to be involved in such meetings, helping to get the EMRs implemented correctly and helping the users get the most out of them that they can.
Friday, December 17, 2010
Ch 20: Clinical Decision-Support Systems
Clinical decision making is a hot topic in medical informatics. Just how many decision can be made, correctly, by a computer? Is there potential that someday the physician will be replaced? Do they really speed up workflow?
There are two types of decisions dealt with in the beginning of the chapter: diagnostic and management. Diagnostic means which questions to ask, tests to order or procedures to perform. Management decisions are after the diagnosis is made, knowing when and how to treat. I think clinical decision support systems can be useful in both of these areas. Given a patient's chief complaint, it might be helpful to enter that into a system and get guidance to arrive at a diagnosis. Also, it can be helpful to use when, given a diagnosis, it could point you to what the treatment should be.
An important thing to keep in mind with clinical decision support is that there are always many variables that cannot be figured into whatever algorithm or artificial intelligence the system is using. That is why I believe physicians will not be replaced for quite a while by computers.
The chapter chronicles many of the systems developed to help make clinical decisions.
I like the Leeds Abdominal Pain System. It is useful for working up a patient to calculate the probability of seven possible explanations: appendicitis, diverticulitis, perforated ulcer, cholecytitis, small-bowel obstruction, pancreatitis and non-specific. This system was correct in 91.8% of cases, where clinicians were correct in 65-80%. It is limited, though in that it only considers 7 conditions. So it would be useful as an initial diagnostic help, but then if it proved to be incorrect one would need to use other methods to arrive at a diagnosis.
System developed is the HELP system. This is for generating alerts "when abnormalities in the patient record are noted." This is a great advantage to physicians, and there are many more systems like this in place. Medicine is getting so complicated, that all providers cannot keep up to date with all of the med interactions and contraindications. Systems like this provide a safety net for the patients. Most docs I've seen are very grateful for things like this. It saves people's lives.
The chapter also notes that after a diagnosis is reached there are many more factors to be analyzed in treatment, costs and benefits being one of them. This is another area where algorithms may not be able to help much as the physician brings a lifetime of experience in many areas to reach a conclusion. Many of the social issues in medicine cannot be addressed with decision support systems.
These systems can give advice in different ways, passively or actively. I've seen many physicians get frustrated with too many warnings that are not personalized to the situation. This is dangerous, and the alert fatigue generated callouses the user to the prompts. I also wrote a little last time about this subject. There is the consulting model verses the critiquing model. Obviously, most physicians would prefer to consult decision support systems, maybe only having critiquing systems in place for serious situations.
All in all, this chapter was an interesting read, and educated me about the different types of systems out there. I haven't had a whole lot of experience with them, but I will be much more willing to try them when situations arise.
There are two types of decisions dealt with in the beginning of the chapter: diagnostic and management. Diagnostic means which questions to ask, tests to order or procedures to perform. Management decisions are after the diagnosis is made, knowing when and how to treat. I think clinical decision support systems can be useful in both of these areas. Given a patient's chief complaint, it might be helpful to enter that into a system and get guidance to arrive at a diagnosis. Also, it can be helpful to use when, given a diagnosis, it could point you to what the treatment should be.
An important thing to keep in mind with clinical decision support is that there are always many variables that cannot be figured into whatever algorithm or artificial intelligence the system is using. That is why I believe physicians will not be replaced for quite a while by computers.
The chapter chronicles many of the systems developed to help make clinical decisions.
I like the Leeds Abdominal Pain System. It is useful for working up a patient to calculate the probability of seven possible explanations: appendicitis, diverticulitis, perforated ulcer, cholecytitis, small-bowel obstruction, pancreatitis and non-specific. This system was correct in 91.8% of cases, where clinicians were correct in 65-80%. It is limited, though in that it only considers 7 conditions. So it would be useful as an initial diagnostic help, but then if it proved to be incorrect one would need to use other methods to arrive at a diagnosis.
System developed is the HELP system. This is for generating alerts "when abnormalities in the patient record are noted." This is a great advantage to physicians, and there are many more systems like this in place. Medicine is getting so complicated, that all providers cannot keep up to date with all of the med interactions and contraindications. Systems like this provide a safety net for the patients. Most docs I've seen are very grateful for things like this. It saves people's lives.
The chapter also notes that after a diagnosis is reached there are many more factors to be analyzed in treatment, costs and benefits being one of them. This is another area where algorithms may not be able to help much as the physician brings a lifetime of experience in many areas to reach a conclusion. Many of the social issues in medicine cannot be addressed with decision support systems.
These systems can give advice in different ways, passively or actively. I've seen many physicians get frustrated with too many warnings that are not personalized to the situation. This is dangerous, and the alert fatigue generated callouses the user to the prompts. I also wrote a little last time about this subject. There is the consulting model verses the critiquing model. Obviously, most physicians would prefer to consult decision support systems, maybe only having critiquing systems in place for serious situations.
All in all, this chapter was an interesting read, and educated me about the different types of systems out there. I haven't had a whole lot of experience with them, but I will be much more willing to try them when situations arise.
Chapter 5: Essential Concepts for Biomedical Computing
This chapter gets into the details of computing and the various aspects, including the make up of the computer itself, different computing devices, the internet etc. It gets quite detailed and some of the information might be more useful for the computer science student, but it is nice to get a background in this to understand, at least a little bit, what is going on in the computer, and what it requires to run a whole hospital on a network.
Networks can generate some huge headaches when they don't function properly. The hospital invests a lot of money to get them up and running. If they stop working, ultimately patient care is compromised. Around MCV they say that whenever Cerner is down, a patient dies due to errors. I don't know if I believe that, but I see it is vital to have a complete and functioning network.
It starts of talking about different devices that can be helpful to the medical professional. The good ol' desktop machine seems to be the classic replacement for the paperchart, but I question if that's the best choice. Laptops made a forage into the scene and they are more portable than desktops, but can be very awkward to carry around, especially if you like to have a separate, blue tooth mouse. Some laptops can be used as a tablet of sorts. But that can still be awkward. I think the best option is the new generation of tablets, including the iPad and Samsung Galaxy tablets. These are as portable as a paperchart, easier to use, and have games you can play when you're bored (like during rounds). It is important to have a good EMR, though. The layout and format has to be easy to navigate, intuitive, and simple enough to move through quickly. That's easier said than done.
The best EMR, probably, is one that spans many devices. It could be accessed from a desktop, laptop, tablet, and even smart phone. Web-based EMRs try to fill this need, but they can be slow, and not as responsive as a program running natively on the device.
The question of what type of input is best comes up too. The old mouse and keyboard isn't going away from desktops too soon, though Apple recently released a magic trackpack for use with desktop machines. some have tried pen devices, trackballs, joysticks. I think my favorite is just using my fingers on a good, responsive touch screen.
The article also mentions security. This is a behemoth that should not be ignored. A security breech can be a disaster. With more mobile use of EMRs, people can be logging in to the EMR anywhere there is a Wifi connection. This could prove troublesome at a public place, with a public Wifi. Potentially, someone could capture what you are doing with the EMR and view it. Not to mention steal your credit card info when you buy that Star Wars sleeping bag for the cold nights.
A final issues brought up is...OPERATING SYSTEM. This is a huge war going on. Do you want to run your hospital on the sleek and sexy iPad? What about the slimmer Samsung Galaxy? Mac OS, iPhone OS, Android, even Chrome OS, Windows? This lends another advantage to web-based EMRs. They can be used on most any operating system.
These issues are tough and aren't going away anytime soon.
Networks can generate some huge headaches when they don't function properly. The hospital invests a lot of money to get them up and running. If they stop working, ultimately patient care is compromised. Around MCV they say that whenever Cerner is down, a patient dies due to errors. I don't know if I believe that, but I see it is vital to have a complete and functioning network.
It starts of talking about different devices that can be helpful to the medical professional. The good ol' desktop machine seems to be the classic replacement for the paperchart, but I question if that's the best choice. Laptops made a forage into the scene and they are more portable than desktops, but can be very awkward to carry around, especially if you like to have a separate, blue tooth mouse. Some laptops can be used as a tablet of sorts. But that can still be awkward. I think the best option is the new generation of tablets, including the iPad and Samsung Galaxy tablets. These are as portable as a paperchart, easier to use, and have games you can play when you're bored (like during rounds). It is important to have a good EMR, though. The layout and format has to be easy to navigate, intuitive, and simple enough to move through quickly. That's easier said than done.
The best EMR, probably, is one that spans many devices. It could be accessed from a desktop, laptop, tablet, and even smart phone. Web-based EMRs try to fill this need, but they can be slow, and not as responsive as a program running natively on the device.
The question of what type of input is best comes up too. The old mouse and keyboard isn't going away from desktops too soon, though Apple recently released a magic trackpack for use with desktop machines. some have tried pen devices, trackballs, joysticks. I think my favorite is just using my fingers on a good, responsive touch screen.
The article also mentions security. This is a behemoth that should not be ignored. A security breech can be a disaster. With more mobile use of EMRs, people can be logging in to the EMR anywhere there is a Wifi connection. This could prove troublesome at a public place, with a public Wifi. Potentially, someone could capture what you are doing with the EMR and view it. Not to mention steal your credit card info when you buy that Star Wars sleeping bag for the cold nights.
A final issues brought up is...OPERATING SYSTEM. This is a huge war going on. Do you want to run your hospital on the sleek and sexy iPad? What about the slimmer Samsung Galaxy? Mac OS, iPhone OS, Android, even Chrome OS, Windows? This lends another advantage to web-based EMRs. They can be used on most any operating system.
These issues are tough and aren't going away anytime soon.
Tuesday, December 14, 2010
Meeting with Dr. Wolver
We met with Dr. Wolver Dec 7.
She gave us an interesting perspective, focusing more on the primary care aspect of how EMR is changing the whole aspect of how medicine is practiced in the ambulatory world. She mentioned lots of her work is done outside of the patient encounter even. She spends lots of time preparing for a visit researching history and messaging. All of this is made much more manageable by the EMR. There is no need to hunt down a chart.
She also brought up an interesting idea: the Social Media EHR. This is more than just a hospital having a facebook page, or twittering. There is a push for an inpatient records to be updated continuously, by a tweet-like mechanism. For example, the nurse gathers the vitals, she tweets is into the EMR. The resident phones the family to talk about end of life decisions, he tweets it on the EMR.
On the first look, this appears fascinating and I got excited about ti really quick. But then I thought about information overload. That's a huge problem today. I can find pretty much anything on google, but do I want to? Having all these tweets about a patient would need to be organized...very well. Where do you put the nurse's tweets, where do you put the resident's. What actually gets put in a daily progress note? do you even still have daily progress notes, or do you have a list of physical exams performed throughout the day that you can simply scroll through to see any changes? This is exciting, but I am wary of some of the complications.
Then is the issue of how are you paid. Do you bill for every tweet? Can you bill for every tweet? I presume not. For all of the new ways of doing medicine to really catch on, the reimbursement scheme needs to change, too.
This leads me to Hello Health. Dr. Wolver mentioned it and I just went to their website and looked it over. I like the patient portal and some of the other features. But what really caught my attention is they use many non-traditional ways of having patient encounters. They have video, email, phone built right in to their EMR. And they say they can bill for it. I would like to know the details of that.
Another problem with all this change is that if the patients don't subscribe to it. There will always be some who don't have email addresses, or don't use a computer. Can you build your practice around electronic media if the patient doesn't use it? Or can you simply adjust the way you do things for the small number of patients who don't use computers?
All in all, I look forward to continued changes in the way medicine is practiced, and the way it is documented. EHRs are inevitable I suppose, and their utility is great. Chris brought up a great point at the meeting, though. With the various EMR programs out there, there HAS to be cross-talk. We owe it to our patients to look for ways to be able to access their information regardless of where they have been in the past. The companies need to see that not everyone will use their EMR, so they need to make it compatible with others.
Some talk of just getting a standard EMR for everyone to use. I don't think I like that idea. It would eliminate many compatibility issues, but introduce others of who actually develops it? Who gets paid for keeping it up to date? And not all hospitals and physicians can agree on one way to have an EMR. Yes, I know it's very capitalistic of me to say this, yet I don't think I need to apologize for being capitalistic. It is what has led innovation in many fields, and keeps us fresh. Though we do have to put up with the money-hungry, but they will exist in any system.
She gave us an interesting perspective, focusing more on the primary care aspect of how EMR is changing the whole aspect of how medicine is practiced in the ambulatory world. She mentioned lots of her work is done outside of the patient encounter even. She spends lots of time preparing for a visit researching history and messaging. All of this is made much more manageable by the EMR. There is no need to hunt down a chart.
She also brought up an interesting idea: the Social Media EHR. This is more than just a hospital having a facebook page, or twittering. There is a push for an inpatient records to be updated continuously, by a tweet-like mechanism. For example, the nurse gathers the vitals, she tweets is into the EMR. The resident phones the family to talk about end of life decisions, he tweets it on the EMR.
On the first look, this appears fascinating and I got excited about ti really quick. But then I thought about information overload. That's a huge problem today. I can find pretty much anything on google, but do I want to? Having all these tweets about a patient would need to be organized...very well. Where do you put the nurse's tweets, where do you put the resident's. What actually gets put in a daily progress note? do you even still have daily progress notes, or do you have a list of physical exams performed throughout the day that you can simply scroll through to see any changes? This is exciting, but I am wary of some of the complications.
Then is the issue of how are you paid. Do you bill for every tweet? Can you bill for every tweet? I presume not. For all of the new ways of doing medicine to really catch on, the reimbursement scheme needs to change, too.
This leads me to Hello Health. Dr. Wolver mentioned it and I just went to their website and looked it over. I like the patient portal and some of the other features. But what really caught my attention is they use many non-traditional ways of having patient encounters. They have video, email, phone built right in to their EMR. And they say they can bill for it. I would like to know the details of that.
Another problem with all this change is that if the patients don't subscribe to it. There will always be some who don't have email addresses, or don't use a computer. Can you build your practice around electronic media if the patient doesn't use it? Or can you simply adjust the way you do things for the small number of patients who don't use computers?
All in all, I look forward to continued changes in the way medicine is practiced, and the way it is documented. EHRs are inevitable I suppose, and their utility is great. Chris brought up a great point at the meeting, though. With the various EMR programs out there, there HAS to be cross-talk. We owe it to our patients to look for ways to be able to access their information regardless of where they have been in the past. The companies need to see that not everyone will use their EMR, so they need to make it compatible with others.
Some talk of just getting a standard EMR for everyone to use. I don't think I like that idea. It would eliminate many compatibility issues, but introduce others of who actually develops it? Who gets paid for keeping it up to date? And not all hospitals and physicians can agree on one way to have an EMR. Yes, I know it's very capitalistic of me to say this, yet I don't think I need to apologize for being capitalistic. It is what has led innovation in many fields, and keeps us fresh. Though we do have to put up with the money-hungry, but they will exist in any system.
Reflection on Meetings
I know it's been a while since my last post. I started off good, but then I was only home two days these past two weeks. But that doesn't really matter. What does, is that I'm here, now, writing an epic review of my thought from the past few meetings.
On Nov 30 we met with Dr. McKenna. What he said at the beginning was interesting. He said that he didn't know much about electronic medical records when he started. But he saw a need, and wanted to put his efforts behind it due tot he importance of a EMRs. I remember Dr. Miller saying something similar. I think it's great that people who aren't already familiar with the field come into it. They can bring a fresh perspective and give vital feedback and ideas as to how the normal user experiences the product.
Maybe one of the problems with EMRs is they were initially developed by people who maybe weren't focusing on the user experience, but just making sure it had all the content. I guess I have to be careful in saying that, though. The pioneers of EMRs had little precedence to go on. So it's hard to criticize them for making it much like a paper chart, only electronic. It might be the job of second-generation users to get in there and make some fundamental changes that truly use the power of being able to step away from the paper chart.
Back to our meeting. He also talked a lot about implementing the Asthma Action Plan. It's a patient education document that should be given to all patients hospitalized for asthma. Compliance has been a bit of a problem, so he set about looking for a reminder in Cerner to prompt the physician to give a plan to the patient. We talked about where in the workflow the prompt would come from, what exactly the prompt should say, how it should be tracked.
We also talked about alert fatigue. That's the thing that really caught my attention. I use a computer hours a day. And I know all about alert fatigue. That's one of the reasons I prefer the Apple computers, they have fewer superfluous alerts that pop up (though when you start adding too much third-party software, those nasty alerts start creeping in). For me, an alert needs to first off be pertinent. Nothing is worse that an alert that looks important, but you do nothing about it, and you are still able to do what you wanted to do in the first place. Like the alerts that pop up while you're navigating to the folder where Cerner is located. The alert looks like some important feature is missing, but you can just cancel it and continue on. This poor, inane, use of alerts is why we have problems with people not using alerts.
Once an alert is pertinent, it needs to be written in a way that is quick and easy to discern what needs to be done. The example of Dr. McKenna's Asthma Action Plan alerts was something like this:
"The patient was admitted for asthma exacerbation. Because of this, the patient needs to be provided with an Asthma Action Plan.
Please provide the patient with an Asthma Action Plan."
Well, it is something like that. I think this alert is definitely pertinent. And it was written much better than I have recreated it. But I wonder if there might be a way to word it that would be quicker to read, only giving the user the reminder needed. The user knows the patient was admitted for asthma, and the user knows that an Action Plan needs to be provided, the user just needs a reminder. Maybe a good way of writing the alert would be this:
Don't forget:
-Asthma Action Plan
This boils the alert down to just the essential purpose of reminding, not teaching. It is very quick to read and know what is needed.
In addition to this, maybe there could be a standard alert that comes up during the discharge process at the same place in the workflow with every patient. So the user is expecting it. And the alert just adds things to the "Don't forget" list. It could be:
Don't forget:
-Asthma Action Plan
-Add asthma to patient's Problem List
Something like that. Again, this alert should only contain pertinent information that adapts to what is actually needed. If every time it tells you to add asthma to the Problem List, even if it was already performed, then the alerts loses credibility.
Anyways, there are some thoughts from meeting with Dr. McKenna. Tune in next time for my thoughts on meeting with Dr. Wolver.
On Nov 30 we met with Dr. McKenna. What he said at the beginning was interesting. He said that he didn't know much about electronic medical records when he started. But he saw a need, and wanted to put his efforts behind it due tot he importance of a EMRs. I remember Dr. Miller saying something similar. I think it's great that people who aren't already familiar with the field come into it. They can bring a fresh perspective and give vital feedback and ideas as to how the normal user experiences the product.
Maybe one of the problems with EMRs is they were initially developed by people who maybe weren't focusing on the user experience, but just making sure it had all the content. I guess I have to be careful in saying that, though. The pioneers of EMRs had little precedence to go on. So it's hard to criticize them for making it much like a paper chart, only electronic. It might be the job of second-generation users to get in there and make some fundamental changes that truly use the power of being able to step away from the paper chart.
Back to our meeting. He also talked a lot about implementing the Asthma Action Plan. It's a patient education document that should be given to all patients hospitalized for asthma. Compliance has been a bit of a problem, so he set about looking for a reminder in Cerner to prompt the physician to give a plan to the patient. We talked about where in the workflow the prompt would come from, what exactly the prompt should say, how it should be tracked.
We also talked about alert fatigue. That's the thing that really caught my attention. I use a computer hours a day. And I know all about alert fatigue. That's one of the reasons I prefer the Apple computers, they have fewer superfluous alerts that pop up (though when you start adding too much third-party software, those nasty alerts start creeping in). For me, an alert needs to first off be pertinent. Nothing is worse that an alert that looks important, but you do nothing about it, and you are still able to do what you wanted to do in the first place. Like the alerts that pop up while you're navigating to the folder where Cerner is located. The alert looks like some important feature is missing, but you can just cancel it and continue on. This poor, inane, use of alerts is why we have problems with people not using alerts.
Once an alert is pertinent, it needs to be written in a way that is quick and easy to discern what needs to be done. The example of Dr. McKenna's Asthma Action Plan alerts was something like this:
"The patient was admitted for asthma exacerbation. Because of this, the patient needs to be provided with an Asthma Action Plan.
Please provide the patient with an Asthma Action Plan."
Well, it is something like that. I think this alert is definitely pertinent. And it was written much better than I have recreated it. But I wonder if there might be a way to word it that would be quicker to read, only giving the user the reminder needed. The user knows the patient was admitted for asthma, and the user knows that an Action Plan needs to be provided, the user just needs a reminder. Maybe a good way of writing the alert would be this:
Don't forget:
-Asthma Action Plan
This boils the alert down to just the essential purpose of reminding, not teaching. It is very quick to read and know what is needed.
In addition to this, maybe there could be a standard alert that comes up during the discharge process at the same place in the workflow with every patient. So the user is expecting it. And the alert just adds things to the "Don't forget" list. It could be:
Don't forget:
-Asthma Action Plan
-Add asthma to patient's Problem List
Something like that. Again, this alert should only contain pertinent information that adapts to what is actually needed. If every time it tells you to add asthma to the Problem List, even if it was already performed, then the alerts loses credibility.
Anyways, there are some thoughts from meeting with Dr. McKenna. Tune in next time for my thoughts on meeting with Dr. Wolver.
Subscribe to:
Posts (Atom)