Virtually Priceless Thoughts

Reflections on Health, Informatics, and Research

Archive for the ‘cognition’ tag

Falling Down does not Mean Failing

with one comment

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.

(click for a larger picture)

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.

Written by priceless

September 23rd, 2010 at 9:16 am

Posted in Uncategorized

Tagged with ,

Clinical Archtect and User Centred Design

without comments

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.UserCentredDesign.graffle.png

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.

Written by priceless

March 19th, 2010 at 11:43 am

Children’s Parties

without comments

Here’s a wonderful You Tube video that relates too well to my life and work – both tongue and cheek and spot on.

Written by priceless

October 30th, 2009 at 10:29 am

Posted in Uncategorized

Tagged with

Reverse Engineering Activity Diagrams

without comments

Right now my research is focusing on creating activity diagrams to describe functionality of EMR systems. Specifically, I’m “reverse engineering” the activity diagrams from an already published list of EMR functional requirements. Several provinces have published EMR requirements as part of various RFPs over the past year. There appears to be overlap between a lot of them and I understand that is by design and re-using the standard set of requirements.

EMRCoreFunctionalRequirements-Flow1h.graffle_ Dashboard-1-1.jpg

After spending some time coding a set of EMR requirements to see what format might make sense, it was clear that activity diagrams were a good choice. My reasons include:

  • Content mapping confirmed that the published functional requirements covered most “processes” or “things,” which is as expected for functional requirements.
  • The “things” were not well defined. That is it would be difficult to create a data model from the content within the functional requirements (some groups have defined data elements separately, which is a good start for interoperability).
  • In my research, physicians will be reviewing activity diagrams. They are somewhat familiar with activity diagrams as they are similar enough to care flow decision trees. They won’t require a weekend course on how to read the diagrams to be able to interpret them.
  • They are commonly used and part of the UML standard, so many requirements engineers will be familiar with them (good for future application)
  • My learning curve is not as great and I can focus on content development.

Interestingly, how the requirements are written (see Saskatchewan Ministry of Government Services website – Competition Number 2462), have made swim lanes difficult to create the requirements do not typically specify which user can do what — see the example below from Saskatchewan.

The Solution should provide standard clinical tools that support clinical documentation and decision making and can be accessed when doing clinical notes.

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.

Written by priceless

May 2nd, 2008 at 8:26 am

Name in Lights – a New Textbook

without comments

I received a package this week. Inside was the textbook:
Human, Social, and Organizational Aspects of Health Information Systems.

Turning to page 23, as I read the title to Chapter 2, I cannot help but grin. “A Bio-Psycho-Social Review of Usbility Methods and their Applications in Healthcare”

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.

Written by priceless

April 27th, 2008 at 5:48 am

Posted in Medicine,PhD,Software

Tagged with , , ,

Brain Science

without comments

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.

Written by priceless

November 24th, 2007 at 10:06 am

Posted in Uncategorized

Tagged with ,