Well now if you know that Epic is paying KLAS, do tell, and give evidence! Or is this another Oracle…
Curbside Consult with Dr. Jayne 6/4/12
Being an anonymous blogger, I never know when an idea is going to drop into my virtual lap. When I’m not in the healthcare IT trenches, I like to embrace certain summer pastimes – drinking mint juleps on the porch, gardening, and making the occasional trip to see some minor league baseball.
I was seated behind first base enjoying some Cracker Jack when the conversation turned to healthcare IT. A particularly tech-savvy friend of mine was talking about iPad apps. Knowing I’m a physician, he mentioned that his old college buddy recently showed him an electronic health record app that he’d been working on.
Turns out Joe College works for a major HIT vendor. My curiosity got the best of me. I asked my friend what he thought of the app. This was his response:
Well, he kept trying to show me a bunch of features that weren’t coded yet. It looked like something that was designed by an IT guy who may have talked to a doctor once and really didn’t have any idea how to do a good user interface.
Knowing the vendor in question, I’m not sure if I should be surprised or not. I didn’t have details on whether the app was for hospital or ambulatory scenarios so I don’t have a lot to go on, but it got me thinking about the role of physicians in software design.
Working for a major health system I’ve been exposed to many vendors. There is significant variation in whether they have physicians on staff, let alone physicians who participate in the design process. Some are very open about the docs on their teams and will connect clients with them for doc to doc conversations. I’ve found those valuable, especially when implementing new software and those “what were they thinking” questions arise from end users.
Others rarely mention whether they have physicians on staff. If you push them they may trot out one of a variety of archetypes:
- The physician who hasn’t practiced in decades but is great with software
- The physician who is a highly-trained informaticist but doesn’t understand office practice
- The physician who really knows what he or she is doing, but is far too busy to interact with clients.
After talking to a couple of my CMIO buddies, I think it’s time to have a little industry conversation about the role of physicians in design and usability testing.
Much like when Mr. H poses “state of the industry” questions to the leaders of the vendor space, I’m giving an opportunity for companies to speak up about how they use physicians and other clinical experts in design, implementation, and support. Here’s the hitch though – I’m not going to come begging for information.
This opportunity is for companies with staff that are loyal HIStalk readers. Let me know how your organization leverages licensed providers and at which stages of the game. I’ll feature the responses in an upcoming Curbside Consult. Priority placement will be given to companies with witty submissions. Extra credit will be awarded for photos of your physician team in action.
Got docs? E-mail me.
Another professional who needs to be involved from the design phase through implementation is the experienced health information manager (HIM). We are trained to know what is documented by whom and where to look for it. We are the advocate for the clinician in the electronic record, but are often overlooked when building the team.
While I’m not a vendor, an example of what they could/should be doing is here, and a less PC version is here, that cites a key article about participatory design of health IT, namely, “Participatory Design of Information Systems in Healthcare”, Sjoberg C, Timpka T: Journal of the Amer. Medical Informatics Assoc. 1998;2:177-183
I also agree with the vital role of the HIM specialists as Becky D states in the first comment.
Providers may assume a properly operating EHR matters and that most EHR systems do not implicitly fit their operations, just as successful technology folks might qualify providers that fit well with engineering and design.
IMHO, physicians who wish to avoid dynamic discourse with concern and conviction are TBA (To Be Avoided) in systematic efforts. I would imagine top collaborators as uncompromising and demanding professionals with Socratic tendencies; not because coders are lazy and can’t read minds, but because my imagined evidence would show getting yelled-at enhances my clarity better than conversation.
I’d even imagine other technology providers having an obvious lack of yelling during their product development. As if “When nobody cared enough to yell about it, you can tell.”
So unfailing my pretense, that I would be insulted if jaws didn’t drop with every release of new functionality. And people would love me (throw that in there) and after decades of success my motto would be “The next time we don’t amaze, will be the first.”
Well these copy machines are not going to crank themselves. My parting observation is that professionals who matter make themselves heard, those that demand things may be viable collaborators, and I might avoid those without conviction to explain things to competent professionals (or yell them at idiots.)
I could not agree more with Becky D!! Why HIM is left out of the planning/design process is ludicrous!
I think the list of physicians archetypes is interesting and it gets me thinking. I have the luxury of a great CMIO on staff and as a User Experience (UX) person, I can lean on him if my user research leaves questions to answer. I do not think using SMEs on staff as the only source of research for the design rationale is going to deliver an app with a good user experience much less be considered usable. A combination of starting with the archetype #3 as the source of real research (along with nurses etc) and leaning on the CMIO (mine is a combo of #2 and #3) to fill in the gaps is ideal.
So then it goes without saying (but i guess i will say it anyway:)), testing with real users is the way to go if you can get it. Using staff to pretend they are real users is something that should only be done if you are force into it. If that is your only way, you still have to worry about the data being confounded.
Thank for bringing up such a great topic.