While Jono Bacon's book was a great starting point for building my online community of patient advocates, my community had several characteristics different from an open source software community. The first, as I referenced in my last post, was that technology did not come naturally to most of my advocates. New software tools needed to be rolled out mindfully. Another important distinction was that my advocates were not volunteer software developers, they were independent contractors building their own businesses. Engaging as the work was for many of them, this wasn't a hobby.
To better customize my community building efforts, I turned to my sister-in-law Tammy Romage, who is a National Sales Director with Mary Kay. She leads hundreds of independent contractors, which is what I wanted to set the groundwork to aspire to. She has also been doing this long enough that building an online community was not really a consideration when she started out, which made her a rich source of low-tech community building solutions.
One of her community building tools is her weekly open conference call that she has held at the same time every week without fail for years. She has developed multimedia onboarding materials (including pre-recorded phone messages) and writes a weekly newsletter. She is public with praise and celebrates the success of her consultants.
She spoke of the need to develop leaders within the community - for example, her leaders can step up and hold the weekly call if she falls ill. They can also be early adopters and promoters - "first followers" - supporting her when she wants to roll out new tools or initiatives. Her first followers give her traction and support when she kicks off community activities like having 200 selfies uploaded to her Facebook community page by the end of the month.
Her message was to keep the contracting work in the context of the consultant. She designs all of these materials and activities remembering that she must use them to add value or save time for the contractors. Coach and support the the contractors, but allow them to work for themselves. Let them embody their own strengths and grow their own businesses. Her advice was to be a fire underneath, not a blanket over top.
Wednesday, August 20, 2014
Friday, August 15, 2014
American Physician vs. the National Health Service
I recently found a blog post where an American physician on vacation in London needed to take his son to the emergency room. He was apprehensive about trying to deal with the UK National Health Service (NHS) as a foreigner.
The author speaks of his surprise that the care his son received was comparable to what he's previously seen in the US, but free of charge. He goes on to speculate what these services would have cost in America. Unfortunately, costs to the patient in the United States go beyond just the bill.
For the services described in the article, patients in the US would have received at least four bills - a facility bill for the ER, a professional bill for the ER doctor, and facility and professional bills for the ophthalmologist services. Additionally, they would have received four more pieces of documentation that looked like bills from their health insurance company called "explanations of benefits" or "EOBs".
These eight documents would all trickle in individually over the course of the next 2-6 months, and often do not contain enough information to tell what services you are being billed for, figure out if you are getting a fair price, or determine if your health insurance benefits have been applied correctly. If you're lucky, you might end up with enough information to figure out how much you are actually being charged and where you need to send payment.
During this process, you might receive premature bills from your providers, incorrectly charging you for balances which your health insurance company is still in the process of paying. You might receive and pay the ophthalmologist's bill and think you are done until the next three bills come in. There will quite possibly be errors in this bureaucratic mess that you will not have enough information to identify - e.g. perhaps the emergency room is erroneously charging you for supplies which should have been included in your room charge (this is called "unbundling"). It's easy to pay too much for the services you received.
And it doesn't stop with this one visit. You might find out later that your insurance did not process these claim correctly, perhaps by not applying the right amount to your policy's annual deductible. As a result, you might be incorrectly overcharged for future medical services.
The non-monetary costs of our healthcare system are astounding.
***If you are lucky enough to have a health insurance policy where you only need to pay copays, you won't typically have to deal with this, as the hospital and health insurance companies will do this inefficient dance without involving you (usually). It will just trickle down to you in the form of higher premiums.
The author speaks of his surprise that the care his son received was comparable to what he's previously seen in the US, but free of charge. He goes on to speculate what these services would have cost in America. Unfortunately, costs to the patient in the United States go beyond just the bill.
For the services described in the article, patients in the US would have received at least four bills - a facility bill for the ER, a professional bill for the ER doctor, and facility and professional bills for the ophthalmologist services. Additionally, they would have received four more pieces of documentation that looked like bills from their health insurance company called "explanations of benefits" or "EOBs".
These eight documents would all trickle in individually over the course of the next 2-6 months, and often do not contain enough information to tell what services you are being billed for, figure out if you are getting a fair price, or determine if your health insurance benefits have been applied correctly. If you're lucky, you might end up with enough information to figure out how much you are actually being charged and where you need to send payment.
During this process, you might receive premature bills from your providers, incorrectly charging you for balances which your health insurance company is still in the process of paying. You might receive and pay the ophthalmologist's bill and think you are done until the next three bills come in. There will quite possibly be errors in this bureaucratic mess that you will not have enough information to identify - e.g. perhaps the emergency room is erroneously charging you for supplies which should have been included in your room charge (this is called "unbundling"). It's easy to pay too much for the services you received.
And it doesn't stop with this one visit. You might find out later that your insurance did not process these claim correctly, perhaps by not applying the right amount to your policy's annual deductible. As a result, you might be incorrectly overcharged for future medical services.
The non-monetary costs of our healthcare system are astounding.
***If you are lucky enough to have a health insurance policy where you only need to pay copays, you won't typically have to deal with this, as the hospital and health insurance companies will do this inefficient dance without involving you (usually). It will just trickle down to you in the form of higher premiums.
Thursday, August 14, 2014
Learning from Open Source Software Communities
I knew we needed to build a community, but where to start? How to set up a framework where strangers would be empowered and encouraged to work together and build relationships and improve overall performance? I needed to find examples of other successful planned communities and learn from them.
The first place I turned was Open Source software communities. I've been an avid user of Ubuntu since 2006 and have closely watched its development into the premiere Linux distribution. Ubuntu's prominence is due in no small part to it's powerful online community. Even in its early days, there was an air of helpfulness. Hard work and collaboration over several years has resulted in an innovative operating system built for humans.
This community was not accidental and was a result of the efforts of Jono Bacon, the former Community Manager of Canonical (the corporation which spearheads Ubuntu). Conveniently, he wrote a book about how to build engaged volunteer communities called The Art of Community. This book spells out important features of successful, productive, collaborative communities ranging from channels of communication to community governance to hosting live events.
Reading this book was an invaluable first step to planning out the community I wanted to build and helped me draft a battle plan. Many of my later posts will review this plan in more detail. However, as expected, this book's narrative focuses heavily on building technical communities. Patient advocacy is not a profession that requires computer literacy. I knew that if technical hurdles were in the way (e.g. installing new software), my efforts would not result in the engagement I sought. I needed to find a way to temper this information for a less technical community.
The first place I turned was Open Source software communities. I've been an avid user of Ubuntu since 2006 and have closely watched its development into the premiere Linux distribution. Ubuntu's prominence is due in no small part to it's powerful online community. Even in its early days, there was an air of helpfulness. Hard work and collaboration over several years has resulted in an innovative operating system built for humans.
This community was not accidental and was a result of the efforts of Jono Bacon, the former Community Manager of Canonical (the corporation which spearheads Ubuntu). Conveniently, he wrote a book about how to build engaged volunteer communities called The Art of Community. This book spells out important features of successful, productive, collaborative communities ranging from channels of communication to community governance to hosting live events.
Reading this book was an invaluable first step to planning out the community I wanted to build and helped me draft a battle plan. Many of my later posts will review this plan in more detail. However, as expected, this book's narrative focuses heavily on building technical communities. Patient advocacy is not a profession that requires computer literacy. I knew that if technical hurdles were in the way (e.g. installing new software), my efforts would not result in the engagement I sought. I needed to find a way to temper this information for a less technical community.
Subscribe to:
Posts (Atom)