Archive for the ‘cognition’ tag
I have been known to say that falling down is part of learning and it does not mean failure.
Sometimes you fall down as you try to do things you haven’t done before. It is part of the process of growing. But if you fall, you need to get back up, as Leo from Zen Habits has said:
Sometimes, I don’t follow my own advice. I’m not perfect. I fall, but I try to get back up. And that’s what matters — not the falling, but the getting back up.
I have fallen many times along my way. I have tried to get back up as quickly as possible and reflected on what I had learned for each fall. Sometimes it took a while, but it has gotten a bit easier along the way.
My little boy has been teaching me this – acutely – over the last month as he has become a toddler. As hard as it is to see him fall, fall he does. Sometimes hard. Harder than any parent wants to see / hear. But he seems to know that it’s OK. Sure he gets bumped and hurt, but it does not stop him from getting back up.
And here’s the happy boy, with a big bandaid from one of his most dramatic falls.
By the way, he’s walking everywhere now and loving what he can do with his new found skills. I hope he keeps getting back up with the same vigour he shows now. I’ll do my best to help make the falls soft, as I know I won’t be able to prevent them all.
NOTE: This post is a follow up from the overall post on what does a clinical architect need to know.
Usability of systems in an important issue. Although it is not one that is first thought of when one thinks of architecture, which is a shame. User Centredness really should be a large part of what a Clinical Architect considers during design.
Of course, detailed user centred design work is not something that the clinical architect can do single handedly, especially in large organizations. Keeping the mantra in the forefront is important to making workable systems and that is something the Clinical Architect should do.
I think about user centredness at a few levels:
- The single user interacting with one information system
- How do the screens flow, does that support the work, is the right information where it is needed, are movements from keyboard to mouse and back streamlined, etc.
- The single user interacting with systemS (plural) or the greater system -
- Where does a user need to go to get information, what does their day look like, etc. Are they interfacing witn 3 systems to do one job, what are the greater outputs, are they hand modifying those outputs and why.
- The multi-user system -
- How does the CIS impact provider – patient interactions and how does it impact provider-provider interactions? What intentional changes are occurring and what UNintentional changes are occurring (or could occur) with the implementation.
Together these views can give an Architect a good view into how the systems work as a whole for a user in their day to day work. Typically, one would consider
I’ve written about the bio-psycho-social approach to usability before and it is a useful framework to consider usability as well as user centred design.
In healthcare, there is also the idea of being patient centred as well. This is an extremely important perspective to consider. My recent research has shown how fragmented a patient’s care is and how they information can be scattered across literally dozens of records (see broken records).
As a final note, here is a recently ISO / IEC 62366 summary from User Focus that discusses usability of medical devices.
Here’s a wonderful You Tube video that relates too well to my life and work – both tongue and cheek and spot on.
e.g. Framingham risk calculator, BMI calculator automatically placed next to height and weight fields.
Other than the swim-lane issue; however, the development of activity diagrams is proving to be achievable. In fact, I think not having the swim-lanes will likely make it easier for doctors to review them as they are more like the flow diagrams we are used to in clinical practice diagrams. As you can see from this BC Asthma Guideline (pic below)
Once the diagrams are complete they will be validated and compared to a set of published text requirements to ensure that they contain equivalent information. Then the experiments begin!
We are going to compare physician comprehension and reasoning using requirements in diagram form with the published requirements in text form. We’ll be asking the physicians to validate the requirements and describe any gaps.
What we are hoping to find is that one method proves to be a clearly better way of getting feedback from physicians for requirements than the other. Which method does not matter as much as discovering if one way is more impactful than the other.
I received a package this week. Inside was the textbook:
Human, Social, and Organizational Aspects of Health Information Systems.
My first book chapter.
Very exciting for me to see – I even had the opportunity to draw my own figures. All in all, it came together fairly well for a first chapter. Writing has never been natural for me (as my dear mother – an English professor – will sigh about), but it did come together.
The key to the chapter is that usability has many forms and can work at many levels. Like medicine, a reductionist view is powerful but not sufficient. We do much better today if we understand the biology of a disease, the personal impact of the illness, and the impact it has on the social network around a patient. For healthcare information systems (e.g. Electronic Health Records), it is the same. First we need to understand the bio (mechanical) aspects of systems – where the computers are, how big buttons are, etc. Next, the design impacts how a user (e.g. RN, MD) makes decisions and need to consider and observe the psychological (cognitive) impacts of design. Finally, medicine is a team sport. At the smallest, the team is the patient:provider pair, and increasingly the team is getting larger including people over time and over distance. Information systems need to support the group work – for improved effectiveness. If we design and test at all three levels, our systems will be more usable and more functional. The chapter is a review of some tools and work at each of the three levels.
So that was my contribution. And the rest book has a great collection of authors. I have had the opportunity to learn and work with several of them over the past several years. I am also honoured that I had a chance to help establish an 18-month primary care informatics fellowship a few years through UBC (thank you Peter!) that supported several BC family doctors learn more about informatics, that grew in collaboration with CIHR’s fellowship to include a primary care stream. Several of the fellows are are contributing authors.
Finally a quick thank you to the editors, Drs. Kushniruk and Borycki for inviting me to contribute a chapter to this book and for not making any snide comments on why “psycho” ended up the title of my chapter.
Jeff Hawkins of Palm fame on Ted Talks – he speaks about “brain science” and I found some of what he talked about close to many of the cognitive science discussions I’ve had with my supervisor around clinical decision making, mental scripts, etc. “Decision making in Action” is a good book on this subject as well.
Also provides a different side to Jeff than the guy known for walking around with a wood block in his pocket.