I just read this article that talks about usability with EHRs. The writer says that EHR systems are too difficult for non-technical physicians to pick up and use on a daily basis. He claims that a lot of older physicians aren't using EHR systems because they don't know how to use computers well enough. He also claims that the government shouldn't force EHR systems on physicians.
While I agree that usability should be a huge concern for software developers, I think that the writer is a little extreme in thinking that the software is too hard to use. There's isn't much you can do at the software level if your user isn't comfortable with a mouse. At Karos Health, we put a lot of effort in creating easy to use software that would be intuitive for all users, with some good feedback from a lot of people. It's clear that there are plenty of physicians that have no problem with using software
We can't just let doctors do things the "stupid" way just because they don't want to learn something new. If they didn't learn new things we wouldn't have any medical imaging and we'd still be using whiskey as an anesthesia agent. Clearly this isn't the case.
So the question is should we allow physicians do things one way, when there is a better way? Especially if the better solution can reduce serious errors. There are other reasons why some doctors might not want to use EHRs, but should a learning curve be one of them?
I don't think so. I think it's very important for physicians to keep up with the times. Systems like EHRs are allowing physicians to do things that were once very difficult or impossible. They save lots of time and money, which ultimately leads to better service. The cost of an EHR is quickly made up when you consider the money you save by not hiring someone to collate paper charts and dealing with rooms full of paper files. It's also provides more security and helps reduce errors.
I agree with mandating use of EHRs, but I also think that software designers need to think more closely about usability, especially for less technical users.
Thursday, May 26, 2011
Wednesday, May 25, 2011
Design Strategies
I see two ways of designing a product.
The first is Technology-first design. This is where the group has a specific technology that provides some capabilities. The team takes a lot of time to flesh out exactly what the system is capable of doing, and how. This discussion gets pretty detailed (like talking about UX or implementation details). Once the team has a very good idea of how the technology can be used, they try to find a market for it. They try to "shop" around for problems in any industry that might be served well by this technology.
The other is User-first design. Here the group knows the overall capabilities of a technology, but they don't discuss the all the details. Instead, they focus on finding users first and then adapt the technology to the problem (instead of the other way around). Here, the group spends a lot of time discussing various markets and their problems. They talk to customers before they conduct in depth research into the technology itself.
Obviously, a successful project will need to consider both the use cases and the technological details, but the question is which one should a team consider first. In REAP, it seems that we are doing Technolgy-first design. That is, we are trying to fit a problem to our technology instead of the other way around.
While this approach is fine in general, I find that it might cause comprises in the final solution. If the team is focused on the details of the technology, they might be more inclined to morph the problem (and solution) to match the technology. A better solution would be to morph the technology to match the problem. This creates a better solution to the problem, since it is focused on user needs.
The first is Technology-first design. This is where the group has a specific technology that provides some capabilities. The team takes a lot of time to flesh out exactly what the system is capable of doing, and how. This discussion gets pretty detailed (like talking about UX or implementation details). Once the team has a very good idea of how the technology can be used, they try to find a market for it. They try to "shop" around for problems in any industry that might be served well by this technology.
The other is User-first design. Here the group knows the overall capabilities of a technology, but they don't discuss the all the details. Instead, they focus on finding users first and then adapt the technology to the problem (instead of the other way around). Here, the group spends a lot of time discussing various markets and their problems. They talk to customers before they conduct in depth research into the technology itself.
Obviously, a successful project will need to consider both the use cases and the technological details, but the question is which one should a team consider first. In REAP, it seems that we are doing Technolgy-first design. That is, we are trying to fit a problem to our technology instead of the other way around.
While this approach is fine in general, I find that it might cause comprises in the final solution. If the team is focused on the details of the technology, they might be more inclined to morph the problem (and solution) to match the technology. A better solution would be to morph the technology to match the problem. This creates a better solution to the problem, since it is focused on user needs.
Monday, May 23, 2011
New York!
I went to Sackets, New York with Dani this long weekend! I got to go to my very first wedding! It was so much fun!
I had scrum training with Declan Whelan as part of REAP on Friday. It ended at 7pm, so we had to leave pretty late to New York. The training was great! I'm very interested in seeing how the REAP team can apply Scrum, and it's concepts, to a non-software project. The whole team seemed to be very interested in pursing the idea of using Scrum for the project, so we'll probably get more training in the future. Awesome!
Anyway, we left Waterloo pretty late. We stopped by Toronto to get my passport (border laws >_<), and then chugged along to our hotel in Watertown, NY. We got there around 1:30am. I learned (slash remembered) that King sized beds are not a little bigger than a Queen sized bed. They are much, much bigger. It was awesome. Of course the first thing we did was jump on the bed. Go us.
Next morning, we went to the wedding in Sackets. They had a small (40 people) ceremony under a gazebo overlooking the harbor. It was quite pretty! The whole thing only lasted about 10 minutes. A good introduction to weddings for me. :P
After that, Dani and I sneaked off to eat some food, while everyone else took buttloads of pictures. It was good. Then we went to the reception...somewhere. lol. That was also fun. We actually got a chance to talk with the bride and groom. It was nice of them to take time to talk to all the guests. :)
After the wedding, we were both exhausted, so we went back to the hotel to relax. Dani fell asleep for 2 hours and then couldn't get to bed until 5am. Sweet deal.
Sunday was mostly uneventful. In the morning (well, "morning" = noon), we went for a drive around Sackets. It's a really nice city. It reminds me of cottage country. It's fun to see how american flags there are in that city. Literally every pole has a flag on it. You never see that in Canada.
After our morning joy ride, we went back to the hotel, watched a movie (My Big Fat Greek Wedding!), and then went on another late night joy ride! We went on a quest to find an open Dunkin' Dodo's (tm). We got lost. Surprise. It was another fun drive though.
All in all, it was a great weekend. My first wedding was excellent! Yay! :)
I had scrum training with Declan Whelan as part of REAP on Friday. It ended at 7pm, so we had to leave pretty late to New York. The training was great! I'm very interested in seeing how the REAP team can apply Scrum, and it's concepts, to a non-software project. The whole team seemed to be very interested in pursing the idea of using Scrum for the project, so we'll probably get more training in the future. Awesome!
Anyway, we left Waterloo pretty late. We stopped by Toronto to get my passport (border laws >_<), and then chugged along to our hotel in Watertown, NY. We got there around 1:30am. I learned (slash remembered) that King sized beds are not a little bigger than a Queen sized bed. They are much, much bigger. It was awesome. Of course the first thing we did was jump on the bed. Go us.
Next morning, we went to the wedding in Sackets. They had a small (40 people) ceremony under a gazebo overlooking the harbor. It was quite pretty! The whole thing only lasted about 10 minutes. A good introduction to weddings for me. :P
After that, Dani and I sneaked off to eat some food, while everyone else took buttloads of pictures. It was good. Then we went to the reception...somewhere. lol. That was also fun. We actually got a chance to talk with the bride and groom. It was nice of them to take time to talk to all the guests. :)
After the wedding, we were both exhausted, so we went back to the hotel to relax. Dani fell asleep for 2 hours and then couldn't get to bed until 5am. Sweet deal.
Sunday was mostly uneventful. In the morning (well, "morning" = noon), we went for a drive around Sackets. It's a really nice city. It reminds me of cottage country. It's fun to see how american flags there are in that city. Literally every pole has a flag on it. You never see that in Canada.
After our morning joy ride, we went back to the hotel, watched a movie (My Big Fat Greek Wedding!), and then went on another late night joy ride! We went on a quest to find an open Dunkin' Dodo's (tm). We got lost. Surprise. It was another fun drive though.
All in all, it was a great weekend. My first wedding was excellent! Yay! :)
Monday, May 16, 2011
Release Early, Release Often...Carefully
There's a lot of talk about the idea of releasing software early and often. The idea is that you get software out to your users faster, so you can get their feedback faster. Releasing software often also has the benefit of keeping your users constantly involved in the development of the application. In general, "Release early, release often" is a great idea... if you do it well.
The caveat is that people need to be really careful with what they release. It is okay to release a new version of your software with just one new feature. Releases lacking features are fine. Quality, on the other hand, should never be compromised. That is, you should never release untested software or software with major known problems. You should never think "That's okay, we'll just fix the bugs in the next release. We release often anyways". I find this incredibly annoying behaviour from software companies. Not only is it very frustrating, but it also makes me question the professionalism of the company. Releasing untested programs is never acceptable. It makes a very negative impact on the user's view on the company's stance on application quality. Users understand when your program is still in it's infancy and is missing features, but they shouldn't have to deal with bug-filled applications.
Keep that in mind when you are considering a release of your software. Quality should never be something that is put off for a later release.
The caveat is that people need to be really careful with what they release. It is okay to release a new version of your software with just one new feature. Releases lacking features are fine. Quality, on the other hand, should never be compromised. That is, you should never release untested software or software with major known problems. You should never think "That's okay, we'll just fix the bugs in the next release. We release often anyways". I find this incredibly annoying behaviour from software companies. Not only is it very frustrating, but it also makes me question the professionalism of the company. Releasing untested programs is never acceptable. It makes a very negative impact on the user's view on the company's stance on application quality. Users understand when your program is still in it's infancy and is missing features, but they shouldn't have to deal with bug-filled applications.
Keep that in mind when you are considering a release of your software. Quality should never be something that is put off for a later release.
Schedule Changes!
Some of you may or may not know that my schedule has been really messed up this semester. I started with 4 courses, one of which was Real-Time. I switched CO 480 (History of Mathematics) for CS 456 (Networks), because history of math was really interesting, but a lot of work. I am currently sitting in on the course though. Steven Furino, the history professor, is a very interesting person to listen to.
Then I realized that taking 4, fourth year CS courses including RT was stupid. Some of my friends in RT were only taking 2-3 other classes, all bird-y like History of Film. When I realized that 4 CS courses was silly, I dropped Distributed.
Then the weekend came. RT A0 was due Monday, and I spent most of my spare time in the RT lab. This is after spending 5-10 hours in there per day since the first day of classes. >_< I got most of A0 done, which was rewarding, I guess.
While Real-Time is very interesting and satisfying, the amount of work is unreal. It's sort of hard to convey. I suspect that it's more work than I did in all of first and second year combined. I could do the course, but I would have to give up literally everything else in my life, including other classes (and sleep!). I am also more interested in the material in my other courses (especially Networks/Distributed) than the Real-Time material. It seemed weird that I would miss out of learning that material for a subject that I didn't really care about in the first place. I didn't think it was worth it, so I dropped Real-Time.
Instead of Real-Time, I decided to pick up Distributed (again) and UI. Unfortunately UI was full, so I only got into Distributed.
So my final schedule, after 2 weeks of shuffling and being on wait lists, is Architecture, Networks, and Distributed.
I would have liked to take 4 courses, but it feels sort of nice to take only 3. I will pretty much treat this as a summer vacation. :P I could use a break, and I'd like to have time to actually enjoy summer for the first time in 3 years. I also have REAP, so I'll still be busy enough, but after that week of real-time, my other course loads seem pretty light.
I am a little sad about dropping Real-Time, but I'm also very relieved. I will actually learn stuff in my other courses now, and enjoy my semester. I think that I made the right choice.
Now if you'll excuse me, I have a sushi date with the Girl.
Then I realized that taking 4, fourth year CS courses including RT was stupid. Some of my friends in RT were only taking 2-3 other classes, all bird-y like History of Film. When I realized that 4 CS courses was silly, I dropped Distributed.
Then the weekend came. RT A0 was due Monday, and I spent most of my spare time in the RT lab. This is after spending 5-10 hours in there per day since the first day of classes. >_< I got most of A0 done, which was rewarding, I guess.
While Real-Time is very interesting and satisfying, the amount of work is unreal. It's sort of hard to convey. I suspect that it's more work than I did in all of first and second year combined. I could do the course, but I would have to give up literally everything else in my life, including other classes (and sleep!). I am also more interested in the material in my other courses (especially Networks/Distributed) than the Real-Time material. It seemed weird that I would miss out of learning that material for a subject that I didn't really care about in the first place. I didn't think it was worth it, so I dropped Real-Time.
Instead of Real-Time, I decided to pick up Distributed (again) and UI. Unfortunately UI was full, so I only got into Distributed.
So my final schedule, after 2 weeks of shuffling and being on wait lists, is Architecture, Networks, and Distributed.
I would have liked to take 4 courses, but it feels sort of nice to take only 3. I will pretty much treat this as a summer vacation. :P I could use a break, and I'd like to have time to actually enjoy summer for the first time in 3 years. I also have REAP, so I'll still be busy enough, but after that week of real-time, my other course loads seem pretty light.
I am a little sad about dropping Real-Time, but I'm also very relieved. I will actually learn stuff in my other courses now, and enjoy my semester. I think that I made the right choice.
Now if you'll excuse me, I have a sushi date with the Girl.
Wednesday, May 11, 2011
EMRs and Privacy
Today I got the chance to talk with a doctor at UW. I asked him what he though of EHRs that enabled data sharing between health care providers. He brought up some interesting points.
Basically, he didn't think it would be that useful for doctors. In fact, he thought that it would have some negative consequences. Specifically, he claimed that people would not be truthful if they knew a lot of people might have access to that information. Would you answer truthfully if someone asked you how many sexual partners you've had, if you knew a lot of people might have access to that information? Apparently, people are hesitant to give out that information even when they know that only the doctor will know about it. He thought that a more available EHR would just create more falsified records. This would make the EHRs unreliable.
He brought up another point about logistics. Where do you store this EHR? Do you associate it with your health card? Well in our case, that would only work in Ontario. Further, what happens when you lose your health card? I think the industry uses EMPIs for this right now.
This is coming from a doctor that's been working with these healthcare systems for over 30 years. It's an interesting point of view.
I think a lot of these problems can be solved by thinking carefully about the privacy concerns with EHRs. Patients should have the power to specify which information is available for others to see. I think a lot of these concerns may be solved by storing all the information with the patients. That way, patients are in control of their health care records.
In any case, I'm very curious to see how this pans out. I certainly don't have a solution for how to solve these problems, but I'm sure something interesting will emerge within the next 5-10 years.
Tuesday, May 3, 2011
Start Of The Term
The term started yesterday, and things are already getting busy. I think my blogging frequency is going to be much, much lower this semester. :/
The first Real-Time assignment is out, and it's very intimidating: 7 days to create a command line interface for the trains, including real-time displays for a lot of data about the train system. All this without an operating system. This is going to be a hell of a semester. Lessons learned so far:
1) makefiles suck
2) operating systems are useful
I changed my schedule a little. For one, I dropped History of Mathematics. Although it seems very interesting, I don't think that I could handle the work load with RT. Apparently the course involves a lot of researching and writing. I will however, sit in on the class. Listening to Steven Furino lecture is a pleasure, and I have a lot of time to kill between classes on those days. I also might pick up Networks. I'm currently on the waiting list for it, but I don't know if I actually want to take 4 courses or not. I've heard that networks is a pretty easy course, so we'll see.
The first REAP meeting is today too. I'm looking forward to meeting the whole team. I'm also looking forward to playing with these Microtiles. I watch about an hour long training video on them yesterday, but that's not as fun (or educational) as actually playing with them.
Looks like this will be a very busy, but fun, semester!
The first Real-Time assignment is out, and it's very intimidating: 7 days to create a command line interface for the trains, including real-time displays for a lot of data about the train system. All this without an operating system. This is going to be a hell of a semester. Lessons learned so far:
1) makefiles suck
2) operating systems are useful
I changed my schedule a little. For one, I dropped History of Mathematics. Although it seems very interesting, I don't think that I could handle the work load with RT. Apparently the course involves a lot of researching and writing. I will however, sit in on the class. Listening to Steven Furino lecture is a pleasure, and I have a lot of time to kill between classes on those days. I also might pick up Networks. I'm currently on the waiting list for it, but I don't know if I actually want to take 4 courses or not. I've heard that networks is a pretty easy course, so we'll see.
The first REAP meeting is today too. I'm looking forward to meeting the whole team. I'm also looking forward to playing with these Microtiles. I watch about an hour long training video on them yesterday, but that's not as fun (or educational) as actually playing with them.
Looks like this will be a very busy, but fun, semester!
Subscribe to:
Posts (Atom)