About eight months ago a few friends and I launched HealthSherpa, a website to help people find and buy health insurance. Over the last few months, HealthSherpa has been able to help many individuals get covered with what I believe to be the best health insurance buying experience available. Developing and launching HealthSherpa was an incredible experience.

Now that open enrollment has ended (the annual timeframe in which individuals can freely switch between insurance plans), I’ve decided to leave the company I’ve helped create.


About a year and a half ago, before working on HealthSherpa, I set out to find the most globally impactful projects I could undertake in Healthcare. While HealthSherpa has become a solid business, I’ve realized that I would prefer to spend my time focused on individuals and the ways in which they receive care. I love working with doctors and individuals, and hope to find projects that more directly improve their lives. Health Insurance is clearly an important topic, in need of focus and change, but at its core, it is specific to the United States. In addition, its purchase on one site verses another, much more user-friendly, site doesn’t dramatically impact the quality or longevity of an individuals’ life.

On HealthSherpa

HealthSherpa’s team is incredibly capable and I have no doubt that they will continue to grow and succeed. I wish George, Ning, and Ben all the best as they move forward, and expect to see them do great things. My leaving is not a reflection of HealthSherpa’s abilities or potential, but rather a reflection of my own goals.

What’s Next?

First off, I’ll likely be sticking around in San Francisco for now. I’ve already started helping a number of Health IT companies build out their technical teams and integrate their software with Electronic Medical Records at hospitals in the area. Long term, I’ll be exploring a number of different options before choosing what to do next. Will it be another product or returning to consulting? I really don’t know yet. However, I’ve got a number of good options to consider, and I am excited to get started.

I’d love to hear your thoughts. Send me a note if you’d like to chat.

About two months ago, George Kalogeropoulos, Ning Liang, and myself posted www.TheHealthSherpa.com on Hacker News. We received 8,800 visitors to the site on the first day. A day later, Connor Simpson at The Atlantic Wire wrote a piece on our site. That weekend we received 12,800 unique visitors. We were amazed by the traffic. I booked a ticket to San Francisco that weekend. We needed to figure out what to do with our new project and the clear public interest. While in SF, CBS Evening News interviewed us and started what was to be 5-10 national TV interviews, and many more radio interviews and written pieces. We now see a relatively large volume of people visiting our site daily.

HealthSherpa’s time has come. The best way to describe the experience of starting the site would be that it’s like we’ve caught on to the tail of a huge whale and are along for the ride. I’ve spent the last year focused on learning about healthcare in the US. I worked on 5-10 different projects, each in completely different areas of Healthcare. Each with it’s own potential and many feeling like they were solving a real problem. HealthSherpa has been, by an incredible margin, the positive outlier in terms of potential.

I’m excited to have the opportunity to improve the way millions of people find healthcare. In the short term, I hope we can dramatically improve the way people shop for insurance. In the long term, I hope we can enable broad, industry-wide changes that want to happen. Individuals, clinicians, employers, insurers, and the US Government all want these changes. HealthSherpa is our platform to enable this substantial and positive change.

This is all possible because the fantastic team I’m working with. I strongly believe in my co-founder’s as well as our employees. We have the desire and means to enable these changes.

As a result of all of this (and despite my earlier thoughts on Seattle vs SF), I’m moving to San Francisco later next week to work on HealthSherpa full time. I love Seattle, and hope to be back someday, but I’m incredibly excited to work with the HealthSherpa team and potentially become an agent of change in Healthcare.

I’ve spent a chunk of time over the last 8 months thinking about Personal Health Records (PHR). Personal Health Records for the uninitiated are a way for individual patients to have access to what their healthcare provider has recorded on them. This generally includes: current medications, lab results, current health issues, and allergies. In some cases it includes upcoming and previous appointment details/ notes, recorded vitals (weight, height), your care team’s members and other functionality that might make sense (secure messaging for example). While many may not be aware its available to them, PHR functionality has become common place over the last few years.

This is at least partially due to Medicare incentives programs (Meaningful Use). The federal government, through Meaningful Use, will pay hospital systems that enable this functionality (through several core requirements of Meaningful Use).

Given my personal experience with building PHRs, I’ve found that most people I interact with (mostly healthy people in 20s-30s) don’t care about their health records by themselves. This said, I have found three key scenarios in which a basic PHR can be monumentally helpful. In my opinion, anyone building a PHR today should attempt to cater to these groups:

  1. Individuals with multiple-chronic conditions. Individuals here frequently do or should have many appointments, procedures, medications, and labs. Keeping track of it all is pretty hard. Think of a PHR as a auto-organizing filing cabinet of important medical documents and reminders for important tasks and events. Also, a PHR can act as the first line of health information exchange between clinicians at different locations. A patient can come in to the office and brings their health records (lab results, medication etc) with them.
  2. Families with kids and new-borns. There’s so much going on and its a ton of work to keep track of several childrens’ medical needs. Have they had their immunizations for school, have they had all the appointments they should have had to ensure they are healthy? What are the lab results? A unified tool to manage a family’s healthcare can be a huge burden lifted.
  3. Children of aging parents. As the generation of baby-boomers get older, their medical needs have increased. Many may not have the support they need to ensure they receive preventative care. They also may have more technologically connected children. Children could use a PHR to track their parents’ labs, medications, and appointments to help ensure they stay healthier, longer.

This said, I really deeply feel all the major PHR vendor’s have missed these core use cases. Bad software, complex paper work, and privacy policies of hospital systems prevent these scenarios from being catered to.

I honestly feel that the Medicare incentives programs are part to blame. PHR software just needs to meet specific requirements and thats it. Someone like Epic (largest EMR vendor in the US) gets paid per-patient signup but many hospitals are blindly trying to sign everyone up to meet Meaningful Use. The hospitals getting paid by Medicare don’t need to launch ‘useful’ software, just software that meets the minimums. This said, the data is now out there (also largely thanks to Meaningful Use) which enables others to build better software on top of this data.

Ultimately, I’m very hopeful. I know of many really sharp people out there working on their own takes on a PHR. I hope we see great things in the next few months given a new generation of startups at it.

About 3 months ago I needed clinician information in the US. A medical system I was talking with wanted to have a searchable index of their physicians for patients to look through. Problem was, they didn’t have this list themselves — they had lists for HR but no actual patient facing index of their own providers! The HR list had all their employees but no information that specified which were clinicians. While doing research, I found the NPPES (National Plan & Provider Enumeration System) which has created the NPI (National Provider Identifier). The NPI is similar to a Social Security number for clinicians. Realistically, if a clinician accepts insurance or prescribes medications they have an NPI. This was a great starting point for bootstrapping a searchable site for this medical system.

The NPI is downloadable and is made up of basic demographics (name, sex), location information (business address, practice address), affiliations, and details of their practice (taxonomy codes). It is maintained by Cognosante for the federal government. Weekly disseminations are available at http://nppes.viva-it.com/NPI_Files.html. The total size of the NPI is about 4.5 Gigabytes.

The problem: The data isn’t huge, but its too big for excel or to just casually include in an application.

At first I thought I could just find someone else’s work to query the NPI, but I quickly found that all existing tools to query the NPI cost money (while still being low quality), were closed source and/or were not high performance. If their NPI search product went down, the medical system’s provider search service would go down. At the same time I noticed the NPI was a prerequisite for may other cool projects in healthcare.

With this in mind, a few others and myself created BloomAPI. BloomAPI is a free (as in speech), self-hostable, API that automatically downloads and keeps a current copy of the NPI dissemination data. BloomAPI will never have stale data. It can also be used as a quick lookup tool. To see a hosted version of BloomAPI, check it out at www.bloomapi.com.

As of today BloomAPI v0.1.0 is available for use/ download. Find documentation for using the API or deploying your own at www.bloomapi.com/documentation. Find the MIT-licensed source at github.com/untoldone/bloomapi. While learning to use the API, or while you prototype projects, feel free to use the hosted version of the API at http://www.bloomapi.com.

I hope that BloomAPI can be used in many future cool healthcare projects. I have a few of my own in mind but please let me know what you think/ how you’re using it!

  • Long term trust and relationships
  • Lowering costs or increasing revenue
  • Little to no impact on existing workflow or staff
  • Understanding of how the IT department operates

While I might say these are important in most B2B products, it seems particularly important in Healthcare.

I’ve found that the longer I know people in the Healthcare industry, the more respect they have for my effort and the more they would like to help me succeed (especially when it helps them succeed).

Someone once described business in Germany in the 80s as very similar. He was selling parts to auto manufacturers. He said, it took about 8 years before his business started to take off. People delayed purchasing explicitly until it was clear that he was in it for the long run. He was able to maintain his business through smaller deals until that transition happened.

I’m thinking healthcare is much the same way (though I am certainly hoping I’ll start finding product/market fit in a shorter than 8yr timeline). I will continue searching for the right products to fit the needs of patients and hospital systems but I’m under the impression this is going to be a long journey. Opinions on the company’s morality aside, Epic is a great example of this. They stuck with it and, in time, got buy in. Also worth noting is their strong ‘we don’t sell’ philosophy — strong long term relationships (helps) lead to long term wins.

Just writing out some of my thoughts this morning — I’ll try to dig into some of the other points in later posts.

To most the term, Personal Health Records (PHR), is pretty meaningless. To the Healthcare industry it means patient facing health records. It generally implies software that enables very easy access to all the appointment notes, medications, lab results, immunizations, allergies, and current medical conditions currently on file with your healthcare provider on yourself. Obamacare’s ‘Meaningful Use’ program also defines PHR as such. In the past, Google Health and Microsoft HealthVault tried to push for mass adoption of such software – improving the lives of everyone with digital health records in the process. However, Google has since shutdown their service and there are very few who have adopted these technologies. This said I’ve found myself obsessed with it over the last two months.

I’ve been focused on it because I don’t buy into the conclusions of Google and there are large flaws with Microsoft’s strategy. Today, I’m working to build a unified Personal Health Record system with two large hypothesis:

  • There is a personal health record software that could exist that would compel individuals to login at least once after every encounter with a healthcare professional (the average American visits the doctor 3.1 times per year)
  • There is a presentation of individual’s health records that will compel them to take action to prevent future chronic health conditions.

I believe these two hypothesis to be true but I am actively working to validate them.

Google Health and Microsoft Health Vault

Google announced that they were discontinuing their PHR software June 24th 2011 after being launched in 2008. Google stated Google Health did “not having the broad impact that we hoped” (http://googleblog.blogspot.com/2011/06/update-on-google-health-and-google.html). Microsoft Health Vault has been online since October 2007 but has not seen wide-spread adoption. I believe the core issues with both of these services are their lack of health provider support. That is, neither have integrated with a large number of healthcare providers (virtually none). In the case that they couldn’t import data from your healthcare provider they would allow users to manually type in their records – a long and potentially non-valuable endeavor. In addition, they did not have health provider’s recommending the use of the application to their patients – limiting the trust individuals had in the applications. All of this prevented Google and Microsoft from ever exploring the real value of a PHR system – improved preventative healthcare.

So why do I think I can actually move the dial here? What do I have that Google and Microsoft don’t? How will I attempt to validate my hypothesis? Its a secret for now… stay tuned for your health records…

Computer Science Students,

With the recent start to Code Fellows in Seattle, I’ve started to think about how I was formally taught Computer Science. It’s not uncommon to see numbers as high as 90% of Computer Science undergraduates being placed in jobs immediately after school. This said, very few Computer Science students graduate with basic knowledge of the tools they will likely use post-graduation. I feel like the vast majority of my graduating class at the University of Maryland in 2008 had never used source control – a tool used by every legitimate software shop.

I think there’s many important things students get from college – I’m not of the opinion that the average person benefits from skipping college and going through trade programs such as Enstitute. This said, I do think Computer Science students should have a superset of the skills gained from such a program. Many today graduate without this. Not only will you be more attractive to companies hiring, but you will almost certainly be more capable of evaluating the companies you might have job offers from. More importantly, going to college for some amount of time will make you a well-rounded, functional person. For me, college exposed me others’ points of view in a way nothing else has.

The importance of this skillset is especially true if your goal is to land a job at a small tech shop that either has a high hiring bar or that will make you figure out things for yourself. The first questions I ask when I’m starting on existing software projects are: how do I get the code, how do I run it locally, how do I deploy it. If you can’t do these things — it’ll be much harder to start having a meaningful impact on the software projects you participate in.

What are some of the basics that are frequently missed? Source control, complex build systems (beyond  simple Makefiles), launching a web app/ desktop app/ mobile app from scratch to name a few.

At University of Maryland I took a Software Engineering class (actually I took it 4 times) that changed my perspective on what makes real software. CMSC335 taught by Jim Purtilo (http://www.cs.umd.edu/~purtilo/) matched teams of 4-7 students with real ‘customers’ in the area such as the Montgomery County Police Department and John’s Hopkins Applied Physics Laboratory. These groups might not have the budget for app development, but would take the time to define requirements for students to implement over 3-4 months. The students must communicate with each other or they will fail to build anything. They must use source control, build tools, and develop an app end-to-end. We launched apps such as http://map.umd.edu/ through this class. I would say that I personally got more out of this class than any other class at UMD.

I suspect the benefits of Code Fellows will be similar to that of my Software Engineering at UMD but it certainly wont be a replacement for college. If you are a Computer Science student in college — Find a class that makes you use source control and deploy an application end-to-end. Strive to find internships that have you developing software on a team. Make yourself a Computer Scientist that is ready to enter the world.

As I dug further into a few new project ideas, I took a moment to evaluate the merits of starting a Health IT company in different locations.  The contenders:

  • Seattle
  • San Francisco
  • Washington, DC

Today I live in Seattle and I started and sold Raveld (my previous company) all in this area. I think between startup types/ entrepreneurs the answer would generally be obvious: move to SF to start a company and stuff will just happen for you! I live in Seattle and grew up near Washington, DC – I know people who I would tap for help on starting a company and have lived in both places long enough to know the areas pretty well. As of today, I’m opting to stay in Seattle. Here’s why:

There’s a glut of accelerator programs with legitimately impressive records in the bay area. However, I’ve started two companies before – I know the basics of operating and the logistics of hiring employees. While accelerators do a lot of things to help startups – there’s a category of things that others would be starting without. I do think I should have gone the accelerator route with previous startups and didn’t – today I don’t think the benefit is large enough to be required for creating a successful company.

I know people that would like to work with me today. I don’t know these people in SF or the DC area. Microsoft employees and Amazon employees would love to try their hand at something different but really don’t have the same opportunity to join a startup in Seattle as employees of SF companies.  people, in my opinion, are the most important part of building a company. In any other city I’d be starting from scratch.

I have not found any clear competitive advantages to other cities over Seattle for Health IT. In the end of the day I can travel if I need to raise money to accelerate my company. In terms of finding customers: the Seattle community is very supportive of new health startups. While other cities are also supportive – I don’t see how SF would bring better customers to the table for product development purposes.

Lastly, cost of living in Seattle vs quality of life is much higher here. I’d probably pay double what I am now in rent + food which makes up most of my monthly expenses today. This would dramatically impact my personal runway.

If I lived in the middle of nowhere today — there would be clear reasons for me to move to SF over Seattle. Given that I’m in Seattle today – the support structures I have here will give me the greatest leverage while I launch my next company.

About a month ago, I started researching medical IT. Before now, my background has been in what I’d call IT for IT professionals. Recently, I’ve felt a need to contribute to society in a more meaningful way. I’ve never really spent much time looking at healthcare until now.

The first area that caught my eye was software around Electronic Medical Records (EMR). An EMR solution will generally try to record all things related to a patient in a hospital or doctor’s office (ambulatory + acute care and others). Frequently EMR is also used as an umbrella term to include other specific categories of software such as Revenue Cycle Management (RCM), Admin & Practice Management (PMS) and more specialized clinical functionality. The problem it solves tends to be different depending on who is using it. For example, at a hospital EMR might track what prescriptions have been administered to a patient in and seeing a single list of prescriptions in an EMR can help physicians quickly identify issues. Another use would be to track all the diagnoses and interventions taken by a doctor for submission to insurance companies.

My first realization was that EMR is actually a very broad set of solutions. It does very different things for different types of organizations. For example, a large HMO such as Kaiser has very different need than that of a small 10 person practice – but both can benefit from the digitization of medical records (from say a paper based system).

Below are my first reactions to specific software offerings I’ve found that are of interest.

Low Cost, ‘New’ EMR

In particular, two companies stood out to me here: Practice Fusion and Dr. Chrono. Both companies have launched their first low-cost/ free EMR products in the last 5 years and I would describe them as different from the traditional software in this space. While many other new EMR companies target specific types of practice – these two companies seem to aim at providing all practices a baseline EMR solution. If I were to guess, each of these company’s main customer has less than 100 physicians in its office. I’d also guess that these companies mainly address ambulatory care (e.g. regular doctors office) rather than acute care (hospitals etc).

In terms of total usage – it’s hard to guess. Dr. Chrono just yesterday sent out an email to all it’s users stating they have 35,000 doctors using their product. I’m a little skeptical of this number myself as I’m not a doctor yet am signed up for the service since its free to try (and I’m willing to bet I’m counted as one of those 35,000 doctors).

I have more to research in this area. I’m particularly curious to learn how many doctors practice ambulatory care total and how many currently use software like Dr. Chrono on a daily basis.

Epic, Cerner, McKesson and others

Epic is a privately held company building mainly EMR technology, consulting, enterprise types of customization and training. They had an estimated $1.2B in revenue in 2011 according to Wikipedia. Cerner is a publicly traded company who sell a number of software and services related to EMR and other hospital related systems. The selling point of these company’s software are their ability to plug in and manage every part of a hospital. Smaller EMR companies can’t afford the cost of supporting as large a system that is as highly customizable.

The general reaction I’ve heard from doctors is that the software from these types of companies is pretty bad from a usability perspective. Some doctors I’ve talked to say that the usability is so bad that it compromises the value of having EMR at all.

This software seems to be pretty typical Enterprise Software.  The companies selling this software frequently seem to be plugged into hospitals in a big way. And this goes beyond software. Training and certification programs mean that nurses and others take weeks to become skilled power users of the system – the cost to retrain is very high. The data formats used by the software are largely unstandardized and undocumented – transitioning old data is near impossible unless you have relatively large budgets to move (order of magnitude seems to be as high as deploying and training in the first place – this can cost $100s of millions).

My impression is that once a hospital commits to software like this, it’s nearly impossible to move away from it. The value of this software comes from the total integration of many different departments and functions and Cerner’s + Epic’s ability to customize the product to the workflows of the specific hospital systems.

Veterans Affairs (VA) EMR

The Office of Veteran Affairs open sourced their EMR solution in 2011 (http://www.va.gov/opa/pressrel/pressrelease.cfm?id=2153). Even before the press release, the Freedom of Information Act (FOIA) was used to successfully request copies of the software. OSEHRA (www.osehra.org) was started to be a place where interested parties could contribute to the project.

The VA is the largest medical system in the US by revenue. Back in the 80s the VA started to create the EMR solution that eventually became VistA. VistA is comprised of 160 different sub-modules including scheduling, basic notes, pharmacy management, imaging, billing and many others. Despite the open sourcing of the project I’m guessing there are very few organizations outside of the US Government that make use of VistA and related packages today. I would say there are 3 big reasons why this is the case:

  1. The open sourced VistA is very much so specific to the VA. E.g. patients have records on if they are still in active duty and what their agent orange registration number is. In addition, it seems the billing components for the VA are dramatically different than most other hospitals.
  2. There is no company offering a high enough level of enterprise support. The VA’s system is frequently cited as being one of the best EMR solutions out there, but hospitals still need support in terms of training, operating and transitioning from existing systems. Without this, deploying VistA would be very daunting for any hospital/ care provider.
  3. No single source of information exists to setup all components related to VistA. Information is spread between hundreds of documents and despite the OSEHRA website, I still think there is no centralized authority on Vista setup/ operations/ training materials. 

This said there are still many interesting efforts to keep an eye on in regard to VistA. Namely, there are forks of the Vista code such as WorldVista and companies such as Astronaut VistA who are trying to make the VA’s award-winning EMR solution more approachable.


In the coming months, I’ll be trying to identify how I can improve healthcare given my background. Given the importance of EMR I’m sure it will be a repeating theme.

EMR is a very fragmented today. I’m starting to see it as a much more nebulous concept than I first thought it to be. There are hundreds of dramatically different EMR solutions for different types of practices + hospitals. This said, while EMR technology has a long way to go, it is clearly improving the quality of care across the board.

I would like to introduce the .Net Cloud Automation Toolkit.  This Apache 2.0 licensed code is meant to help with automating tasks related to managing cloud computing infrastructure.  This first version is limited to being a .Net client to the Windows Azure Management API documented here but there are many more items on the todo list for this project.

What types of things can you do with this?  Perhaps automate deployment for development, testing and production on your own terms.  Use this as the framework to help develop and managing your personal or organization’s cloud computing needs.  Several things I’m planning in the near future include:

  • Windows Workflow Foundation Activities to manage Azure
  • Windows Workflow Foundation Activities to manage Amazon Web Services (AWS)
  • Windows Azure Windows Workflow Worker Role

Realistically, how might this functionality benefit you?

Perhaps it could help you deploy a development Azure service as part of your build process.

Maybe it is used to provision instances for automated testing in a real Azure environment.

It could also be used to help manage applications in production including custom tools to version your application with zero down time in an automated way with no guess work.

The reality is that there’s large numbers of applications here that have yet to be discovered.  My guess is that Microsoft may release some of this functionality in the future, but it isn’t here today.  Meanwhile, any scenario described above will require code from this or a similar library.

To get started with the Cloud Automation Toolkit, download it here:http://cdn.mikewasser.com/CloudAutomationToolkit-1.0.zip.  The package contains brief introductory documentation to help get started using it.

If you would like to help with the development of this project or have questions in regard to using it, please let me know!