Blood Donation Delays Trickle Away with Lean Methods at Red Cross

While donating blood yesterday, A Red Cross administrator described a few ways they were implementing Lean methods to improve the donation process - for both the donors and the workers. Some highlights follow:

Big self-qualification poster at the entrance that can save a potential donor time waiting in line to sign-in and read the comprehensive qualification manual just to find out they can’t donate because they are on antibiotics, or travelled to Africa recently. About 12 common disqualifying reasons are listed.

Red or Green name tags indicated if the donor is a first time or repeat donor. That can sometimes be an indicator if they might have more questions or they may not be familiar with the process.

Ready, In-use, and Open signals to indicate to the workers when the donor is done with the computerized screening questionnaire, or the screening area is occupied or ready for another donor.

Work area re-layout to minimize worker walking distances, but still maintain confidentiality.

The administrator I spoke with was very positive about the improvements which indicates she believed the methods would allow them to better serve the donors while making their jobs easier as well.

“In other areas where they have implemented these changes, they have trimmed 10 to 17 minutes off a
blood donor’s process.”

According to the August 2009 Central North Carolina Red Cross newsletter

I ended up waiting 45 minutes to get my blood drawn even with an appointment, so there is obviously room for improvement, but it was encouraging to see the progress. This was a mobile team so they have several other challenges to overcome that frequently slow or hinder progress:

• every day they work with a different team of people coming from neighboring counties and states
• they have to tear down and rebuild their work areas daily, sometimes multiple times per day
• located in different venues with different floor plans, sizes, and entry/exit paths

Just knowing they are working on saving time for donors shows respect and makes me feel better about the Red Cross.

Healthcare Reform – Rewrite or Refactor?

Few people disagree that the healthcare system in the US needs to be reformed. How many people would agree about the best way to successfully accomplish it?

The article Understanding Healthcare Reform lists just a few of the elements of healthcare with links to several sub-categories within each of the following elements:

• coverage
• payment systems and costs
• patient safety
• health information technology
• medical research

For me the article is a reminder of just how complicated the healthcare system is. When a solution is required of a large scale system like healthcare, one has to consider whether it should be completely overhauled - or refactored* piece by piece. Without the right approach to the problem, it is conceivable that the solution could create substantially bigger problems than the current system. Joel Spolsky, a contributor to Inc magazine and owner of a New York software company, summarized it best in Things You Should Never Do, Part I, in reference to re-writing a software program from scratch.

“It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.”

If healthcare is to be reformed without the risk of creating more problems related to care, coverage, or cost, the system will have to either be refactored fixing one broken piece at a time - or piloted in a smaller representative area or areas and refined and scaled out until the system proves it meets everyone’s expectations.

 

* definition from wikipedia: Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior or existing functionality, in order to improve internal quality attributes of the software, for example to improve code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, to improve performance, or to improve extensibility.

Healthcare and software seem like completely different subjects, but there are many parallels between large complex software programs and other large complex systems from other industries like healthcare.