Changing the Language of Healthcare from Cost to Outcomes and Productivity

The US healthcare system has been warped by reimbursements for care.  In Sharin's piece "The End of Hospital Cost Shifting", he talks about the impact on hospitals of the Medicare cutting reimbursements to hospitals based on work done by Austin Frakt

  • Cost shifting: Increasing the prices it charges commercially-insured individuals to compensate for reduced Medicare reimbursement.
  • Cost cutting.  Reduce cost for all patients to ensure average profitability across the entire Medicare/commercial payer mix.
  • Reduce profit margins.  Reduced Medicare reimbursement could simply eat away at hospital profits.

And he notes that cost cutting is the most likely result and that would impact patient outcomes:

Wu and Shen (2011) found that hospitals that faced large payment cuts from the 1997 Balanced Budget Act cut operating costs and staff and experienced increased mortality rates of heart attack patients relative to those seen at hospitals that faced smaller cuts.  They calculated that a 1 percent cut in payment results in a 0.4 percent increase in heart attack mortality rates.

And he concludes:

Such a trade-off calls to mind what Mark Pauly expressed in a 2011 paper in Health Affairs, “Perhaps a little less quality for a lot less money might be acceptable to consumers and taxpayers, as we work to keep medical spending from siphoning off funds required for other needs” (Pauly 2011). Whether it is acceptable or not, it may be what consumers and taxpayers get.

Let me break it down: Lower quality = worse patient outcomes = increased mortality = more people die.   And that's o.k. because it costs less.

And that's where the vocabulary is just wrong.  Nowhere does he focus on productivity improvement, resource utilization and the impact on outcomes.  They just don't think like that.  But every other industry does, except healthcare.  

I don't accept that more people dying in hospitals or post acute care is an acceptable tradeoff for lowering costs and I hope you don't either.


It's time to retire CPT® in health care

CPT (Current Procedural Terminology) is a medical billing coding system created by the American Medical Association (AMA) with the sole purpose of charging insurance companies for health care services and putting royalty money in the AMA's pocket.  Cpt-2014-professional-pIt's an artifact of the pay for service reimbursement system that has caused the US to spend the most on healthcare while delivering mediocre patient results.

If a CPT code does not exist for a service, chances are your physician won't do it.  Wonder why adverse drug reactions are under reported?  There is no CPT code for that. 

There is absolutely no relationship between good CPT coding and good patient care.  And there is no relationship between CTP code reimbursement rates and what those services actually costs a provider.  (Just ask the CEO of any hospital how much it costs them to perform a hip replacement.)

Sad but true.

The insurance companies are basically a cost plus business, so they focus on reducing the price paid per CPT.  The American Medical Association makes a from licensing the codes, so they have no incentive to change it.

Hopefully new "pay for performance" mandates in PPACA will shift the power to patient care quality / results from this very broken system.  And the AMA will have to find other ways to make money. 

CPT® is registered trademark of the American Medical Association.


Encyrption is easy: Key management is hard

Encryption basically has two use cases:


1. Moving information from point A to point B and not letting anyone else be able to see it during transit.
2. Making sure that when the information is at rest (data, email, etc.) that unauthorized people cannot use it or read it.

You often hear claims like "AES 256 bit encryption" or "We use military grade encryption".  Doesn't mean much.  All encryption uses keys.  These keys are mathematical constructs, when used properly, Keys provide the amount of security necessary.  Who ever has access to the keys, can see your information.

Key management is a very big deal.  Your first consideration is who generates the keys and how do they do it.   For instance, if you are storing data off site, and the service provider generates and stores the key, you have to ask yourself "Do I trust them"? 

This is the model of Google Drive for instance.  In that case you are at the mercy of rogue Google employees, stolen equipment, or unknown subpoenas from government agencies.

Amazon Web Services also will generate the key for you, but not store it.  That's a little better, but you are vulnerable if a copy is being made surreptitiously.

The best case scenario is you generate your own keys using a proven key generation mechanism (a topic for discussion in itself). 

Now comes the hard part.  Whoever has the key can read the information.  How are you protecting and distributing those keys?  What is your access control and audit?  What happens if an employee leaves and has a key?

The best scenario is to assess the balance of risk and usability.  If it is too difficult it won't be used.  One of the slickest methods I've seen for protecting a user / application communicating to a server works like this:

1) The user / application starts a secure session using a public key (PKI uses a lot of overhead)
2) After the connection is made, a single use symetrical key is created (very fast)
3) The session switches to using the same symmetrical key

This gets more interesting when you're talking about backups and disaster recovery.  To fail over to a cloud warm site, that site needs your key to restore the data.  One way to get around this is to have the service provider hold the key and have that key encrypted.  To release the key, you would simply log into the recovery site, enter your credentials and now the key would be released.  They don't need to store your password, just an encrypted hash of the password to verify (and maybe 2 factor authentication to your cell phone).

This is all doable and well worth the time to think through the process from beginning to end.

 


Saving Healthcare in the US: Focus on Efficiency, Efficacy and Motivation

I won't bore you with the statistics on how the US spends more and gets less than any other industrial nation in the world and consumed about 17.9 percent of GDP last year.  Instead I want to focus on the goal of colleagues of mine who are serious about shaving 1% of GDP in healthcare.

How to do this?

First off, you need to measure precisely how much you actually spend on each patient.  Then you need to examine how much utilization of resources you actually are using for patient care (not how much you bill).  Focus on maximazing work flow and resource utilization and you now improve efficiency and save money.

But that does not mean you are doing the right thing by the patient.  Next you need to measure efficacy to see if you are getting the best results for what you did.  By doing so we found in occuptational health that patient outcomes improved while physician visits decreased by 40%.

While this is all well and good, it doesn't matter if no one uses it.  So you need to have the proper motivation.  Many times this means a cultural change in the organization.  For example we had a case where an organization could save $8M a year by employing these methods.  The medical director killed the project becauses he did not want his patient outcomes measured.

Efficiency, efficacy and motivation, when implemented, will change the landscape of healthcare.


HealthIT 2.0: Time for the Hospitalist?

Imagine taking care of 15 patients a day.  And you've never met them before.  And coordinating care among three shifts of nurses, labs and specialists.  That is the plight of the hospitalist. 

HealthIT 1.0 has failed them.  Patient histories from multiple sites of care?  Disparate PAC systems, care coordination?  Medication reconciliation?  There are bits and pieces but no system does it all.

Instead the 1.0 vendors try to bolt on new functionality to very old legacy systems.  Epic is based on MUMPS that was developed in 1967.  And they are the leaders.

The next generation 2.0 vendors will disrupt the establishment by focusing exclusively on the physician / care providers and the patient.  And we're seeing examples of this from outfits like Doximity, Practice Fusion, Hello Health and Image32

It will get better.

 


Why I started programming

A friend of mine asked me this week about how I started out as a developer.  Did I go to school for it?

The short answer is no.  I taught myself initially because it helped me do my job better.  In the early 80's I worked at US Gypsum building plants.  Curing drywall takes a lot of energy and some plants were coal fired.  Depending on where the coal was mined it had different BTU's, sulfur pollution and cost.  ThWe had to calculate how many tons of coals from which sources to meet minimum BTU, maximum sulfur and at the least cost.  This was an optimization model with 18 variables.  A lot of paper, calculus and a slide rule.

Then came the TRS-80 Radio Shack computer.  We could write a program in Basic that would do all the calculations in 2 seconds.  Around the same time the NASA project manager for Skylab Images came to work for us and taught me how to do project management using a computer.  I was hooked and went back to school for an MBA with a focus on computer systems. 

Since then I've always believed that whatever you wanted to do, you could figure out a way to make it easier with software.  I have not been disappointed.

 


Jump Starting to Double your Sales in a Tech Company

Twice this year I've talked to two companies who have the same challenge: After a decade of getting to $20-$50M in sales , senior management has been tasked by the board to "GET BIG NOW".

I have noticed the same strategy by both companies:

  1. Hire a lot of people
  2. Use the word "Cloud" or "Mobile" in their new strategy
  3. Move to a larger building

After a decade in business they both have a lot of creaky Microsoft based legacy software and a decent sized installed base.  In reality, they have two paths to growth:

  1. Suck up the existing market through acquisition and consolidation.
  2. Leverage their knowledge base to create new products / services to accelerate growth.

Acquisition may get you through the first couple of years, but you need to be planning for the long view after that. Once you own 60% of the market, then what?

Even if you do that you eventually end up at option 2: Leverage your knowledge and customer base.  Doc Searls called it "the because effect":

The because effect is a kind of jujitsu. While other people look to make money with something, you're finding ways of making money because of something.

Kathy Sierra has this great video: "Building the minimum Badass User".  While you may be a fan of techniques such as Pragmatic Marketing, that only improves what you are already doing.  By focusing on how to make users be really great at their jobs will give you new ways to refocus your products and services to new uses.


Patient Portals and the Identity Crisis

Meaningful use stage II is requiring a certain percentage of patients to be able to view their patient health information.  At HIMSS in New Orleans there was a lot of conversation about this.  And many vendors talking about their solutions.  InteliChart is a good example of these portals.  What happens if a patient goes to different doctors?  Different portals.  And most of the security is username + password.  Not much 2-factor authentication in place. 

Then layer in the requirements for the Health Information Exchanges.  Each patient needs to be perfectly matched to every EMR where their records reside.  Name + date of birth does not work so well if you are John Smith or Maria Garcia.  And who has access to these records?  And how does the patient know?  Again, many vendors have their unique solutions requiring everyone to sign up for their particular system.

These systems are being built bass-ackwards.  Here's a novel concept: Have the patients in control of their own identities and they decide when and where other people (or their surrogate like their primary care physician)  can access their information.  And the patient knows everytime who accessed what information and for what purpose. 

Universal identity cards will work as well as a social security number.  They won't.  Instead, patient supply their own credentials and each entity verifies if they indeed trust that that patient is who they say they are.  Can this be done programmaticly?  Yes and it's not that hard.

Look at project VRM:
http://blogs.law.harvard.edu/vrm/2013/03/09/the-vrm-perspective/
http://cyber.law.harvard.edu/research/projectvrm

Create a personal private cloud for each patient.  Then create an oAuth service that each provider entity and HIE can connect.  The trick here is that all authentication and access flows through the individual patient's personal cloud.  Use a certificate authority to create irrefutable credentials and use for 2 factor authentication (added bonus - public /private key encryption)

Time to build it.


Embedding a PowerPoint or Keynote Slide Deck Presentation in a website

A pdf just doesn't cut it in today's websites.  Try looking at them on your smartphone.   But how do you handle those slide decks?  I've seen plugins etc. but that was just too much work.  Turns out Keynote on Mac has an export to HTML (and it does a good job of importing those PowerPoint slides).  After you export it, you get all the files and JavaScript all in tidy folders.  Just FTP them to a folder on your website and you are ready to go.

I especially like the part where it detects if you are running an iPad or iPhone.  It then enables finger swipes.  A side benefit is you are forced to simplify the content of your presentation so you can view it on a smart phone.