Archive for the ‘Research’ tag
I was in an pan-Canadian EMR Benefits Evaluation meeting today hosted by Canada Health Infoway. A little heated debate came up around the value of coding data. Some fell on the side of don’t bother coding, use free text and fix it later”. I fall on the other side of trying to do it right the first time. Clinicians can code and I think they should, so they can get some of the advanced feedback and functions of EMRs
I am a supporter of free text -d on’t get me wrong. Narrative is very important to our current recording practice. However, selective coding does have value in places like medications, allergies, problem lists (labs should have attached codes from the lab automatically).
However, if it takes the physician 30 seconds to properly code an item on the problem or if a user needs to memorize SNOMED CT codes likethen we are designing our EMRs wrong.
Rather than saying don’t bother coding, I suggest we should be asking:
How can we make the User Experience so elegant that coding is seamless?
Electronic Healthcare just published one of our papers on EMR Adoption
Great to see it in print!
I have, on occasion, thought about how one can apply agile software develop methods to research projects and other non-IT projects. I have been thinking about how our groups and projects could benefit from some of the agile methods. This seemed like a good enough trigger for me to write about scrum and research.
Craig Brown (on Better Projects) lists the elements of scrum as follows:
- Start with a goal. Break down the goal into incremental steps.
- Discuss the steps with the team who needs to deliver the solution.
- Set standard time boxes. Do your best to deliver something practical and useful each time boxed iteration.
- The team needs to take instruction from the customer at the beginning of each iteration and report on what got ‘done’ at the end of each iteration.
- The team must set aside a portion of time at the beginning of each iteration to plan their work.
- The team needs to set aside a regular and brief portion of each day to communicate progress and problems to one another.
- The team needs to commit to continuous improvement and should set aside a portion of time each iteration to reflect on what went well, not well and where they can improve.
- The planning, review and reflection sessions, and the daily team update all need to be set at regular times to help the team achieve a sense of rhythm.
Let’s go through the eight elements, applying a research lens. I will be thinking about some of the evaluation of health information systems, rather than
- Goal: Check. Research projects should have a clear question in the beginning. There’s a need to define a method, which really could be broken down into incremental steps.
- Determine who is responsible for which work products: Check.
- Research projects can be time boxed. The question of delivery is interesting and it depends on the methods. Some research protocols, such as randomized control trials do not lend themselves to using agile methods. They are more “waterfall” in their approach, if you will. You won’t know results until you have a large enough number of research subjects (although the set up activities can easily be time boxed). Other methods are more suited to thinking about them with agile methods.
- Instruction from the customer: for some studies the “customer” is not explicit. Is it the granting agency? Is it the end user? The more engaged we as researchers are with our customer, the more likely the knowledge gained is knowledge applied. So we can benefit from defining a customer who is engaged.
- Planning Time: Yes, this can be easily done. I would add, especially when working with students, that this is key and ties into #6 & #7.
- Daily Progress Report: Typically, research projects are run more autonomously. One of the challenges we have of adapting scrum and the importance of daily team meetings is simply the timelines for some studies. There are often long pauses (ethics review) where things are on pause until approval is received. Does this require redesigning the research team structure (e.g. have an ethics rep on the team) or does it mean that scrum activities are bound to periods of higher activity? I am not sure.
- Continuous Improvement: For all of us this is important. For students who are on such a trajectory of learning and growth, even more so. Regular reflection helps improve skills faster than just doing blindly. Here we can learn to better plan, assess our capacity for work, and highlight “hard parts” of projects. This helps the current project as well as future projects. I am a big supporter of reflection, so this is easy.
- Regular times led to productive rhythms.
In truth, many of the action oriented approaches are similar. Soft Systems Methodology also recommends iterations and reflections.
I think it is time to start more formally bringing in some of these ideas into the research plans that I am building now.