Can the Compassion of “The Crowd” Reduce Suicide?

HodlerDespondency1887WinterthurA web

Hodler, Despondency, 1887, Winterthur

Something we think a lot about here at Body1 is how to “Connect People with the Health Information that Matters Most to Them”.   In fact, we’ve made that our Mission.   We seek to apply it in our work, and in the ideas which we share.

Here’s one idea.  There’s a huge social opportunity to leverage digital for suicide prevention. Especially so, since suicide is a huge mental health issue that is largely unresolved.   It is a top 10 cause of death in America, 3rd behind only cancer and heart disease in years of life lost.   In the most recent full reporting year (2012), the US Centers for Disease Control and Prevention (CDC) report 40,600 suicides, equivalent to someone dying every 13 minutes.

Given the immediacy of the need and the ubiquitous of smartphones, digital could offer a solution.  A 24 hour/day, 7 day/week, 365 day/year (24×7, 365) app that video links to a trained peer counselor is one possible approach.

There are some big questions to be answered first, including (but not limited to):

1. How to staff with appropriately trained personnel?
(one approach- could be drawn from a pool of *trained* volunteers with a round robin telephone routing),

2. How to market & distribute
(possibly via health plans, Apple, Google, telco’s, etc);

3. Who funds?
(options include CDC, state Health depts, crowdfunded?)

This seems to us like a wonderful way for digital to contribute to the social good.  Thoughts? Comments?

7 Deadly Mistakes which Kill Templated Medical Websites

Templated sites from WordPress (WP), Magento, and others have become popular.   We at Body1 even deploy these for small healthcare clients launching their first sites.   They are cheap.  They are convenient.  And they can be dangerous.

Here are seven common mistakes that we’ve seen.  We’re often brought in to fixed “shattered” software projects, where a project starts and then cannot finish because of added complexity due to poor planning and unexpected scope creep.

1. Modifying a template without planning. Template-driven systems like WP or Magento are fine but customization adds considerable complexity.  Adding or deleting features changes the overall code base.  Separate parts of the site will break, suddenly incorporate random pieces of code, or reformat the page, among other unexpected issues.  To address this, Body1 systematically scans the entire site in a staging environment after every major code push, with the ability to selectively roll back and adjust potentially problematic changes.

2. Ignoring QC and testing.  The activities of quality control (QC) and testing actually are as important as coding.  Coding is only 50% of successful website or marketing software deployment.   Once a site is coded it has to be thoroughly checked and the code updated to fix issues.  This step is often skipped on templated sites- and then the owner is surprised when the site breaks.  Automated link checkers, load simulators, and browser emulators are useful tools.  On sites Body1 builds we use such tools to check issues prior to launching but inevitably there are still issues which can only be caught by a smart pair of human eyes.

3. Not deploying a separate “stage” site.  It’s easy to develop in a folder on the planned live site.   It’s harder to set up a separate, password-protected “staging” site with a process to cleanly copy the files over to the planned live site.  But that is best practice.   Completely separating the development from the live code ensures that:

  • all the functionality can be confirmed as working before deployment,
  • code in the development & live folders does not conflict, and
  • issues in deployment can be quickly and easily fixed.

4. Ignoring the hosting environment details.  Understanding and control of the hosting environment is critical to successful programming.  Issues in hosting often cause problems with the site performance that masquerade as software problems. This is why Body1 controls its hosting environment.  We were called by a panicked customer with a Magento site (eCommerce web template from eBay) whose log-on was failing and their “Magento programmer” couldn’t figure it out.  It turned out it was caused by the host running out of disc space (see below).  Without disc space the programs will fail.  This was especially acute for this eCommerce site where there was a 4gb catalog and multiple development folders.

5. Hiring a low cost developer to start with a quality development team on stand-by.   This is the classic “penny-wise, pound-foolish” trap.   Coming in to clean-up in a crisis situation is not ideal for anyone.   Starting with a low cost developer (often one with heavily discounted rates who works out of state or overseas but is “always available via Skype”) is a sure way to slow or break your website.  Such a process also ensures that a high quality development team will have to be brought in at the last minute, on a rush basis, to decipher code and re-architect a site under intense deadlines.  Since it is always more complex and takes longer to unravel someone else’s code, problems are invariably missed.  This results in the development process being more time consuming and expensive.

6. Retaining the cheap talent to work on perceived “easy parts” of the website while the top talent fixes the problems.  This is the classic “Too many cooks in the kitchen spoil the broth” situation.  We’ve seen firms do this to try to reduce costs on shattered projects.   However it inevitably ends up not being cost-effective as the coordination needs increase significantly and the coding efforts end up conflicting.  If the project is “shattered”, the cheap outsourced programmer costs, rather than saves, money.  Using a top development firm on a templated site facilitates control of the hosting environment, properly staged projects, and leverage of automated testing tools and QC.

7. Eschewing site monitoring and maintenance after launch.   A templated site is not a high-availability site, nor is it fool-proof site.  Automated monitoring and planned on-going maintenance of websites is valuable.  This is especially so for healthcare sites.  Automated monitors can detect problems before they before obvious to the end user.  Monitors even can be set up that follow every order through the purchase funnel for sites selling health products or services.  Besides real-time QC, those monitors then provide a tool to analyze consumer buying behavior.

Maintenance plans allow these problems to be fixed proactively without impacting the their live environment.  Because web browsers (such as Explorer, Chrome, Safari, and Firefox) and operating systems (such as Windows, OS, and Android) evolve, it is inevitable that the unmaintained templated website will break.  A good rule of thumb is to allocate 20-25% of an initial web budget to ongoing maintenance.

Avoiding the 7 deadly mistakes of templated medical websites is not hard.  A little forethought, a dash of prudence, and the willingness to invest initially is the best way. Besides on time and on budget website launches, there is an added benefit- maintaining one’s own emotional equilibrium.

Chris Messina

Gene Tests, Delivery Drones, & Avoiding Regulatory Meltdowns on the Web

There are some interesting parallels in the FDA’s recent action telling the firm 23andMe to “cease & desist” all marketing of its personal genomics test with the recent news about Jeff Bezos and the Amazon “delivery drones”.  Both are new technologies which will require regulatory understanding and adaptation.

However, by contrast, Amazon has floated (figuratively & maybe literally…) the drone idea, launching public discussion and regulatory contemplation.  By contrast, 23andMe blazed ahead.  Brave? Hubristic? Both?

The FDA’s approach is almost always to prioritize the prevention of harm.  Is there potential harm (like unnecessary prophylactic organ removal) from misinterpretation? Probably.  Can it be mitigated?  Surely, but the FDA will want to be part of crafting the solution if it’s potentially accountable for the potential harm.

My experience running an orthopedic device firm taught me that firms consult with the FDA retroactively at their peril. Even now it is surprising how few medical & wellness firms have a regulatory control process in place for public-facing web content and mobile apps.

What are the practical lessons here?

  1. Both are new technologies, which will require regulatory understanding and adaptation.
  2. Both are best served by proactive vs. reactive regulatory engagement
  3. Amazon has approached the regulatory environment more cleverly by “floating” its idea early.
  4. It’s possible to re-engage after facing regulatory problems, but more difficult.
  5. Inadequate or missing systems for regulatory content management is another area where many firms fail.

I hope 23andMe works things out with the FDA. It would have been far better to fully engage them earlier, but there is still hope.

Chris Messina