Last Thursday, I started messing around with BloomAPI’s new data-import libraries to see what I could do in a short period of time.

I started to play with the AHRQ HCUP data. Specifically the State of Maryland’s 2011 State Impatient Database (SID). Took about two days to get it imported (writing some helper libraries as I went), and a few minutes to hook up a graphing package. I strongly believe I’ll be able to get this down from two days to an hour in the future for new data sources.

The result was a slick user interface + dashboard for the SID. Here’s a quick example query I ran with it. It shows the number of single-child births (ICD-9 v270) by age in the state of Maryland in 2011.

Still looking for the right problems to explore with the data, but it is cool to look at the tech side for now. Graphs such as this could be generated in 500ms or less, aggregating over 750,000 documents.

The other day, a physician friend mentioned he was working on a project related to Hep-C treatment. I whipped out my laptop and in seconds used this tooling to discover the top 10 procedures done on patients diagnosed with Hep-C vs the general population.

I would love to find similar problems to investigate with this tooling. Let me know if you have questions to ask of claims data – would love to find some real problems to solve with it. I’m sure I’ll have some more things to say on this in the future and some more data-specific insight. Stay tuned.

BloomAPI v0.2.0 is now out! Check it out at www.bloomapi.com or the source at https://github.com/untoldone/bloomapi.

Just a quick progress update on BloomAPI itself: The public facing website now sees millions of API queries a month! In addition, somewhere between 10 and 50 applications use the public API in production (and many others run their own).

This version was a complete rewrite of the existing code in Go. The major improvements in the rewrite include:

• Normalized Postgres database. If you wanted NPI information in a structured database (instead of a messy 320 columns), host your own BloomAPI server to get it!
• Now uses ElasticSearch. The result is that you can query on any field at all and not just the indexed ones. This includes things such as taxonomy codes. Want real-time autocomplete of physician information on your website? This is now really easy to implement!
• About 10x the API performance compared to the previous version. BloomAPI now responds to queries in an average of about 11ms.
• Easily extend the NPI api with your own data. Just add it to the database and make a few small updates and your ready to serve physician information augmented with your own data.
• Now datasource agnostic (while maintaining a few NPI specific features for reverse compatibility). Look for many other datasources hosted by BloomAPI in the near future or bring your own (let me know if you are interested in hosting your data on BloomAPI)! Taxonomy descriptions and classifications are on the short list of next features – expect them to be added in the next week or two.
• On the backend – the public API has newer, faster hardware … now with redundancy.

v0.2.0’s API maintains complete reverse compatibility with v0.1.6’s, so no rewrites of your applications needed for the new version.

The deployment and contribute documentation has been rewritten for the new code. Check it out if you’d like to run BloomAPI yourself. Let me know if you have any trouble with it.

Really excited to hear about any applications you may have built or you are actively building. If anyone is interested, I’d be willing to add your applications to a ‘Built with BloomAPI’ section of the page.

Really excited to see what gets built!

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.

Why?

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.