Yaser's Blog

A few tips about what to do on the final day of the hackathon

Day 2 Wrap-up

Pre-event

Opening night of hacking health was great. Lots of enthusiasm and excitement with everyone ready to help. Stay tuned for more updates & tips.

We are so excited to announce Toronto’s 4th Random Hacks of Kindness (RHoK.org) on June 1 – 3, 2012.

Last week I attended the Idea Jam Night for Random Hacks of Kindness (RHoK) here in Toronto. The event was held in preparation of our upcoming hackathon on June 2nd and 3rd. In a hackathon, subject matter experts submit problems they are facing in their field of expertise where there is potential for technological solutions. Over the course of a weekend, they are grouped with interested developers to work on building a working prototype of the proposed solution. I am happy to be a part of the organizing committee for this hackathon and even happier that one of the problems presented was healthcare-related. The idea was submitted by Leanne Tran who conducts radiology research in Toronto.

The problem:

Approximately 80% of maternal deaths globally are due to obstrectic complications such as haemorrhage, sepsis, etc. 99% of those deaths are in developing countries, and most of them are highly preventable with the right obstetric care. (Chuni, 2008). Taking Nepal as an example, obstructed labour is the second highest leading cause of maternal deaths. Often these soon-to-be mothers do not have access to specialized care and don’t discover potential complications such as feto-pelvic disproportion (when the size of the fetus’ head is larger than the pelvic) until it’s too late. The problem as outlined by Leanne was two-fold 1) lack of specialized training in operating ultrasound devices, as the accuracy and quality of ultrasound scanning is highly operator-dependent and 2) lack of access to radiologists and OBGYNs to interpret those scans.

Read the rest of this entry

Imagine if you worked at an organization where every department operated in isolation of the rest of the organization, where 6 forms exist to capture the same piece of information but each with different labels/structure and level of details, where many of your key staff members are really self-employed and have more influence on your work and reputation than you do, where it is claimed that customers come first but in fact staff come first, where knowledge of how things are done exists only in someone’s head and things fall apart when he/she goes on vacation. If you’re nodding your head in agreement as you read this then congratulations, you work at a hospital.

From what I’ve noticed since I finished my undergrad studies and started working in healthcare is that while healthcare organizations claim that the patient comes first, sadly what I’ve seen in many cases is the exact opposite; it’s all about what the doctor wants. While it is not the case for all organizations, it does seem to be somewhat of a pattern where doctors and hospital staff have the last say over what processes to follow based on what’s more convenient for them rather than what’s actually good for the patient. On top of that, consider the fact that physicians here have their own practices within hospitals rather than being directly employed by the hospitals. This gap in the structure opens room for the adoption of many internal processes based on each practice’s preference. Read the rest of this entry

During the last semester of my post-grad studies, my group and I were asked to conduct an interview with someone who was involved in the system analysis & design processes for software in healthcare. Naturally I took to the Twitterverse and reached out to a couple of my contacts. I got a positive response from @colin_hung, Vice President of Operations at RL Solutions and an online interview was scheduled over Skype. Before I get to the interview, I would like to thank Colin for taking time out of his busy day to do the interview and also would like to thank my colleagues Matthew Maragnos & Rebecca Parker for collaborating with on this paper.

Abstract:

The tools used and methodologies followed by a System Analyst in any project have a direct influence on the quality of the developed system. If a system analyst does not collect the right requirements, with the appropriate level of details, and does not prioritize those requirements accurately, the effects will be sever during development, implementation, and post-implementation. Examining the methodologies and documentation used during the System Development Life-Cycle (SDLC) by RL Solutions allowed us to understand their Agile approaches to developing and customizing their systems.

Method:

Our primary source of information for this paper was an online interview over Skype with Colin Hung, VP Operations and Andy Yang, Senior Software Developer, which took place on October 14 2011. A list of potential questions were emailed in advance and only relevant points were discussed during the interview. After the interview, we have outlined 9 major themes/topics which were discussed: 1) Agile Software Development, 2) User Stories, 3) Software Testing, 4) Data/Process Modelling Tools (MS Visio), 5) Sequence Diagrams, 6) Use Cases, 7) User Manuals, 8 ) System/User Mock-ups, and 9) Data Flow Diagrams.

For each concept, we listed our questions and the interviewees’ answers. After each answer, we provide a definition for each concept and list advantages, disadvantages, and the relevance of those topics for a system analyst. This information was gathered from multiple academic and non-academic sources as well as drawing on the team’s personal experience in system analysis and design.

Read the rest of this entry

Recently I came across a research paper titled “Utility of Quantitative Computerized Pain Drawings in a Sample of Spinal Stenosis Patients” (Felix et al, 2010). The paper intrigued me, and as those who know me personally know how obsessed I am with quantifying and measuring everything around me. Areas where math does not work aside, I remember at a previous job when I was working on the nursing module of the EMR, one of the items that the nurses used to track for inpatients was pain.

Naturally they used the 1 to 10 scale. I always felt like that scale was not a true representation of the patient’s actual pain, because every patient has a different threshold and type of pain, each of which might indicate a different reason/source. Using a standard 1 to 10 scale does not really represent the nature/severity of pain. What I might classify as five might be for other people seven or three, so the 1 to 10 scale is never really reliable on its own. That’s why I found the Computerized Pain Drawings (CPDs) approach to be fascinating, and definitely a step in the right direction.

Now let us examine the above mentioned paper itself. Read the rest of this entry

Recently the South West Local Health Integration Network in Ontario released a video featuring their CEO Michael Barrett discussing highlights from 2011 and a look ahead to 2012. I came across the video in a tweet by Julie White, SWLHIN’s Director, Communications and Customer Service. I replied to Julie’s tweet stating that I liked the video and wished it included more statistics. Naturally, within a couple of minutes, Julie responded with a link to SWLHIN’s Performance section on their website. Power of Social Media aside, in the Performance page, I came across a report titled “Quarterly Stocktake Report” published in November 2011. I found this report interesting and wanted to share my thoughts on parts of it, specifically the section related to ER wait times at Pay for Results sites.

One of the problems addressed the fact that 50% of ER visits were non-urgent or less urgent than to require an ER visit. For that, a goal was set to reduce ER demand. The Bar Graph provided the number of unscheduled ER visits by quarter per 1,000 population. In the first quarter of fiscal year 2010/2011, ER visits were 146 per 1,000 population (or 14.6%) and 149 in 2011/2012 (14.9%). This shows that the goal was not met. However, the comparison might not be valid when comparing exact numbers, especially if the total population around the SWLHIN has changed. This problem is not unique to the SWLHIN, as the figures above were actually taken from CIHI and the MoHLTC. Read the rest of this entry

1. Introduction

As healthcare costs keep increasing and governments are encouraging to adopt EMRs, healthcare organizations are currently at variant stages in their automation with the goals of reducing costs and increasing operational efficiency. One challenge they face is how to adapt their current business processes to a computer-centred model of operations. Merely taking existing business processes and transferring them from paper to computer will not yield a high return on investment (ROI). This ROI, while eventually can be translated into monetary value, can also be looked at as increase in efficiency, reduction of medical errors, and reduction of process time. Recent studies show that waste in the U.S. healthcare system costs as much as $700 billion annually (Poole, 2010).

In this paper, the focus is on the role the Systems Analyst (SA) can play in contributing to identifying problems with current business processes and designing the right systems that will yield the desired results. Furthermore, it is proposed that SAs familiarize themselves with Lean Quality Management approaches, specifically Six Sigma, and apply it during the requirements gathering, analysis, and system design phases of the System Development Life Cycle (SDLC). Six Sigma is being used more each day in all aspects of healthcare ranging from applying it to improve diagnostics of chest pain (Kumar & Thomas, 2010) to improving surface precision of optical lenses in the injection-molding process (Lo, Tsai, & Hsieh, 2009).

With a significant number of tasks being automated, the role of a SA and a business analyst can merge together, and therefore, the system analyst must be capable of performing the role of a business analyst, with the added benefit of the deep understanding of technology. This helps the SA assess the potential value of automation and design the system accordingly. Read the rest of this entry