Antibiotics are running out. We hear it (quietly) in the news frequently. As antibacterial drugs are used everywhere, superbugs evolve with a frightening resistance to even our newest pharmaceuticals. Stories warn of a future in which even knee surgeries become operations with tremendous risk of death. Someday, they warn, we may miss the decades in which cancer and heart disease were the number one killers, as we regress back to early deaths from TB and E.coli.

The most cost-effective treatment for a disease is not a drug, but a vaccine. The cost to society of polio is only in the thousands now; smallpox is nonexistent. In the modern day however, cost effectiveness makes little sense for a pharmaceutical company. Building a product that will put itself out of business may be good for society, but it’s hardly a survivable way to make a living.

Is there a financial instrument that can properly make transparent the health needs of society? Let’s make up an example.

Case study: disease

Let’s say a city has 10000 people. 20 of them get Disease A. Of those, 10 will die.

If we developed Vaccine A, at a cost of $5, only 2 people would get Disease A, and 1 would die. Assuming those 9 people saved would have added $1 to the economy each, we have now done $4 better than we would have before. However, no one person can pay for developing a vaccine such that it benefits themselves enough (9/10000 x $1) to cover the expense.

One possible financial instrument: Insurance

Let’s say we develop a fund such that anyone who dies of Disease A will get a payout of $2. Someone who buys this instrument has gone from an expected bad outcome of -$1 to $2, and any price with a proper weight under this outcome (9/10000 * $3) would justify spending this amount. Thus, everyone buys into this insurance plan, and the insurer makes, say, 9/10000 * $2.5 * 10000 = $22.5 in premiums.

However, the insurer must pay out 10 * $2 = $20 to the victims of this disease. This means they will only make $2.5 in profit. However, if the insurer takes the $5 expense to develop Vaccine A, they will reduce their required payout by 9 * $2 = $18, and thus make a hefty $15.5 instead.

Would this work? Some of the more obvious challenges to be overcome follow.

Problems with this:

  • Moral hazard. What if one insurer takes on this expense, and another insurer, sensing the benefit, offers their own insurance, charging less? Now the second insurer can potentially take the benefits from the first insurer without paying the cost. This is a dangerous proposition in the sense that, once it becomes less cost-effective, then the first insurer will not develop treatment, and both companies will become insolvent.
  • Another risk: What if, precisely because the vaccine is being developed, fewer people buy into the insurance plan? You might benefit from having a Kickstarter-like threshold model for purchasing insurance.
  • We don’t actually know the proper costs for a vaccine.

Question: Do insurance companies do this already? If so, how?

Could we use new financial instruments to improve society’s health? Which ones do we already use? These are questions that are worthy of investigation. It would be very unsurprising if someone has already done so!

Update

For example, ceftaroline fosamil, an antibiotic approved in the U.S. in 2010, costs around $600 for a seven-day course. Contrast that to yervoy, a new drug to treat melanoma, that costs $120,000 for a 12-week course.

“Society values antibiotics wrongly,” says David Payne, head of antibacterial research at GlaxoSmithKline. “These are lifesaving drugs—they don’t just give patients a few extra months.”

http://online.wsj.com/news/articles/SB10001424052702303465004579322601579895822

It wouldn’t surprise me if part of the eventual solution is that antibiotics end up costing a lot more.

During the planning stages of a presentation, does your computer function as a “bicycle for your mind,” amplifying your own capabilities and ideas? Or is it more like a “car for your mind” with prepackaged formulas that make your ideas soft? Your mind benefits when you use the computer like a bike, but it loses out when you rely only on your computer’s power the way you rely on your car’s power.

-Presentation Zen, 46

This analogy applies well to other types of software. When you design something, you should ask the question: Does this amplify the power of the people who use it? Or does it substitute for that power?

JSDoc 3 is opaque about how it chooses to document classes. This isn’t exactly surprising, since I would throw up my hands at the myriad number of ways a class can be declared in JavaScript. Here’s how you get a class to be autodocumented.

JSDoc automatically documents classes that are in the global namespace:

1
2
3
4
5
6
7
8
9
10
11
12
/**
* @classdesc This class will be documented automatically because it is not in
* another function.
* @constructor
*/
function TestClassGlobal() {
/**
* This is a public method and will be documented automatically.
*/
this.publicMethod = function() {
};
}
/**
* @classdesc This class will be documented automatically because it is not in
* another function.
* @constructor
*/
function TestClassGlobal() {
/**
* This is a public method and will be documented automatically.
*/
this.publicMethod = function() {
};
}

However, if you’ve been enclosing your classes in functions like a good programmer, JSDoc won’t include those anywhere:

1
2
3
4
5
6
7
8
9
10
define([], function() {
/**
* @classdesc This won't be automatically documented,
* because it's inside another function.
* @constructor
* @memberof Namespace
*/
function TestClassNamespace() {
}
});
define([], function() {
/**
* @classdesc This won't be automatically documented,
* because it's inside another function.
* @constructor
* @memberof Namespace
*/
function TestClassNamespace() {
}
});

There are two ways around this – you can explicitly add @global, or use @memberof to make the class belong to a namespace:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
define([], function() {
/**
* @classdesc This won't be automatically documented unless you add memberof,
* because it's inside another function.
* @constructor
* @memberof Namespace
*/
function TestClassNamespace() {
}
 
/**
* @classdesc This won't be automatically documented unless you add global,
* because it's inside another function.
* @constructor
* @global
*/
function TestClassForcedGlobal() {
}
});
define([], function() {
/**
* @classdesc This won't be automatically documented unless you add memberof,
* because it's inside another function.
* @constructor
* @memberof Namespace
*/
function TestClassNamespace() {
}

/**
* @classdesc This won't be automatically documented unless you add global,
* because it's inside another function.
* @constructor
* @global
*/
function TestClassForcedGlobal() {
}
});

Let’s say you have 12 different emails asking for appointments, and you’re not sure if they’ll conflict. Rather than (1) email everyone back one at a time, only to discover that I’ve scheduled one appointment over another, or (2) get so hung up trying to fit all the emails in my brain at the same time, I might try the following:

  • I write down all the proposed dates in Notepad or a piece of paper and look for conflicts, either with existing calendar appointments or with each other.
  • Once I’ve figured out how everything fits together, I send out all the emails at once.

Since you can’t undo an email, this system makes it much easier to not bump appointments into each other. This system is so good, in fact, that it’s similar to how databases work.

Databases often have to update several sets of records at the same time. One common example is debiting one checking account at the same time as crediting another (something you would never want to do halfway). Because of this, databases combine both the debit and credit into a transaction that effectively happens all at once.