Titin.net

Link to the official openEHR website.
This post is from a physician’s and not a developer’s point of view. Whenever I read more about openEHR, I appreciate the work put to in this opensource project but at the same time I get weary about its potential for success. OpenEHR promises to put the users (clinicians and other healthcare workers) in the driving seat[1]. This is done by allowing users determine what information should be collected and shared. My feeling is that uses like car drivers only care about reaching their goals in the most comfortable way. Users like drives don’t usually care what is under the hood as long as they reach their goals.
I hope I am not conveying a message that I think that openEHR is useless. To the contrary, openEHR main mission is to offer interoperability between different healthcare systems. The focus on the front line user, not like most if not all systems that focus on how to serve people in management [1,2]. It focuses on those human beings that need to see value for the effort they put in entering data into these systems. OpenEHR gives insights into how should health care systems should be developed. OpenEHR two layer architecture and spreading archetypes into observation, evaluation, instruction and action archetypes are just some proofs of this insight.
I have three concerns. I must say that my concern seems to have been thought of among openEHR developers. Read more »

Link to the original article.

This is a qualitative study where data was collected late 1998. The goal is to answer what are nurses’ and midwives’ experiences of using Computerised Patient Information Systems CPIS?
This study is an answer (getting back) to IT professionals who don’t believe in that customers are always right and claim that clinicians resistance is because of ‘resistant to change-period’ or ‘more education and training’ is needed. But, may be IT professionals do care for customers. But, these customers are not the clinicians that will use the new system. The customers are health care management and IT professionals that will choose and pay for the new system.
Researchers conducted 13 focus groups involving 53 practitioners across five Australian states. Although this study was conducted in late 1998 the experiences expressed are similar to the ones I experience.
CPIS developers advertise that these systems could help the complex clinical environments. But according to the the nurses and midwives in this study, these systems failed to capture these complexities. We know more then we can say, and say more then we can write. It seems that we can put in CPIS less then we can write.
Many expressed that CPIS felt like a big black hole. Clinicians exert effort to enter data but could not get this back when needed. Only the powerful groups in the organisation are severed with needed information.

Link to the original article.

Authors conducted task analysis and focus groups to study a Longitudinal Medical Record (LMR). They studied the usability of one of these LMR’s modules. This module is the results manager. This module allows physicians to follow up on their patients’ laboratory results. Physicians would assess these results and prepare letters for their patients. Based on the inputs from these two qualitative studies, the authors proposed modifications to the existing results manager module.
It was interesting for me to realise that the criticism I have to our totally different Electronic Medical Record were similar to the ones raised by physicians in this study. This means that systems’ developers are similar and though make similar systems. Here is a summarized list of findings with some commentary: Read more »

I keep complaining about healthcare systems not addressing interruptive nature of
health care environment. I do realize that solving this problem is impossible. We humans fail in multitasking. Prophet Mohammed (peace be upon him) said this in a figurative way when he stated that God did not create humans with two hearts. When multitasking we keep shifting between tasks. This shifting of attention cost time and can lead to mistakes. In a way, we are similar to the processors we designed. When we ask a processor to multitask the processor’s overhead increases with no benefit in the total time spent processing all the requests.

It is the job of clinicians to reduce the distractions in their environment. Two things that are hard to get rid of are the patient and the medical chart. Depending on where you practice, it could be extremely hard to shut out other distractions. The last thing we should do is to make the situation worse with a computer.

What I want to say is; although preventing health care systems from exacerbating distractions is impossible, it should be seriously addressed.

I am reading a very interesting article by Johnson, Johnson and Zhang (2004). This article has suggestions on how to redesign the interface of an existing healthcare system. The trigger to write this article is as stated “numerous health care systems are designed without consideration of user-centered design guidelines”. They point out the need to understand your users. They then go and divide users into expert users and novice users. Expert users need the rapid response time and shortcuts and the novice users need a lot of feedback. I do not think this sort of discrimination is necessary. Any user needs feedback, rapid response time and easier ways to do repetitive tasks (shortcuts). If you check Johan Redström winning article I commented on, there is no such thing as “a user” before the the system is in operation. There are only people we think would use the system we are developing. Discriminating between people in such a way is just to give excuses for developing suboptimal interfaces. The ground breaking iPhone interface proves this. There could be and interface that any person can understand and use.

The only way I see that a similar discrimination makes sense is if you focus on the tasks that the system will perform. There are systems that are meant to be used by system administrators and database administrators. These are mainly servers. These systems avoid the overhead of a Graphical User Interface (GUI). These systems need to squeeze the fastest response time possible out of the available hardware. But, the division here is based on the system task and not the people that will be using the system.

Ignoring Fitts’s law can exacerbate one of the unintended consequences of information technology in health care. This is juxtaposition errors.  This is when a user clicks the item next to the intended one. So, a physician can prescribing medicine to the wrong patient, because s/he clicked on the wrong patient. This is not theoretical. This was one of the errors elucidate by Ash, Berg and Coiera (2004) when they were discussing the errors induced by the highly interruptive environment in heath care.
You can listen to Jared Spool on the Usability Tools Podcast describing the use of Fitts’s law in computer interface design. In short, things you need users to click on should be big and close.
Surprisingly Fitts’s law is quite old. Paul Fitts, an American psychologist, published his paper in human motion in 1954. He developed his theory while trying to improve aviation safety. He may have realized that “juxtaposition errors” when made by pilots can be deadly! This is another development in aviation safety that health care should catch up with.

check my other related post

It is challenging to develop systems for the future. It is as hard to make worthwhile research. Everything in IT is changing. The technology is changing fast. It is al most hard to predict the future. It seems the only way to predict it is “to make it or to look for unevenly distributed technologies or phenomena.” (These two quotes are not mine)

We humans are also changing. We develop new skills and improved or loose our current ones. Even our brains’ networks are changing change.

Before mentioning my thoughts on design research, I must guide you to this superb description of design research on isworld.org .

Design research is somewhat similar to any other research. The only difference is that researchers come up with an artifact then test it as apposed to coming with a hypothesis.

I do believe that design researchers should focus on the concept and not the design itself. This may require just a mockup instead of a prototype. So, there should be a balance between the focus on the question needing an answer and between how elaborate is your design. For a question as: how much information should be displayed on the main page to support decision making? would not require a prototype. A mockup with multiple screens should allow us to perform required tests.

Design research is not good for every thing. But, it looks like a good tool to be used when the goal is to narrow the gap between what is known and practice.

Ontology, Epistemology and Methodology

This is a summary of my readings from module one in my course. Ontology, epistemology and methodology are three related concepts. Ontology is the building blocks of reality, or the nature of reality. Ontology can be objective, as the speed of light and can be subjective where different perspective are present as when we start our senescence with “it dependence”. Realist treat reality as objective and interpretivits treat reality as subjective. (Tansley 2004) We use epistemolgy to reach new knowledge that is based on our building blocks (ontology). Methodology is more practical; it deals with methods, systems and rules we use to conduct inquiries. This definition makes methodology somewhat similar to epistemology. Epistemology is more of a philosophical construct that would answer questions as “How can we be sure that we know what we know?” (Guba & Lincoln 2006) So, Epistemology is the “how”.

Paradigm

Paradigm is another concept. Paradigm is a collection of related concepts or a philosophical genre. (Weber 1997)