Symcat Blog

I just read the article Half of Healthcare Providers Are Looking to Buy Business Intelligence and it compelled me to post some of my recent reflections on the topic.

There is a growing excitement about the vast stores of data coming from EMR adoption. Policymakers, executives, and entrepreneurs alike are alluding to the great potential for this newly-discovered source of data to transform health care through what is often called “Business Intelligence.”

Really, “Business Intelligence” means many things to many people, but I tend to focus on health care’s unique spin on it: clinical data. By that I mean the type of data that is typically dictated or typed in narrative form by physicians into their EMRs: symptoms, past medical history, family diseases, social circumstances, and diagnoses.  This data is the foundation of medicine and health that must be linked with the volume and payment statistics to which Business Intelligence typically refers in order to be useful for predictive analytics. Unfortunately, clinical data has remained unstructured and therefore largely inaccessible because physicians do not have the tools to structure this data without disrupting their workflow. And in the prevailing fee-for-service model, disrupting workflow means taking a paycut. Meaningful use requirements/payments are attempting to change this piecemeal, but it will be an arduous process as incentives must be reevaluated to ensure they’re promoting the physician behaviors for which they’re designed (ie not just cutting corners).

There is hope in the form of various natural language processing (NLP) attempts including IBM’s Watson and to some extent, Isabel. I’ve heard of more than a few applications coming out that will automate diagnostic coding using NLP, but these are still just a fraction of what they need to be.

Personally, I am more optimistic about the potential to share various sources of structured data across the health care system in order to perform Business Intelligence. This means, breaking down the model of large EMR vendors that do everything so-so, into a series of software solutions that each do one thing really well, but can interoperate. HL7 (interoperability standards) and UMLS (controlled vocabularies) can help get us there. 

That’s why Symcat is what it is (or will be): a way of transforming the previously inefficient process of collecting clinical data from patients that are sick and allowing them to quickly and easily communicate that to their doctors. No repetition, no being cut off mid-sentence, and, most relevant to this post, no unstructured information. More on that later.

Craig

Check us out in the Health section of the Atlantic. 

We’ve been working hard in preparation for our demo day, but expect some new posts coming soon.

Thanks for your support!

Craig

We’ve just put together an infographic explaining some of the motivation behind Symcat! See the full version at http://symcat.com/infographics/cyberchondria.png.

Summary: Cyberchondria refers to the tendency to be concerned about symptoms as a result of searching them online. 4 out of 5 people search online for health information, many of them for common symptoms such as headache and chest pain. Unfortunately, web search tends to rank highly more concerning conditions, even though they’re far less likely. This often causes unnecessary concern among web searchers and even influences their decision to seek medical care. Symcat can help solve that by letting people know what they’re likely to have and what they should do about it by asking others what worked for them. It’s crowd-sourcing at it’s best. Try it out at symcat.com.

Medgadget just published an article about Symcat. In it Craig talks about the conception of Symcat and the direction it’s going. Check it out.

Pingpong tournament at Blueprint Health. W. Danford def T. Soo in the 3rd game 21-19

Symcat meets HHS CTO Todd Park and Senior Advisor Aman Bhandari at Blueprint Health office. Thanks for coming by guys!

Craig just wrote an article for popular health blog iMedicalApps. Reposted below.

You’ve got this great idea for a medical app that will transform health care (or at least a chunk of it).

Now what?

There is no one path to executing your idea. Particularly for those of us in medicine where the course is clearly delineated (pre-med, med school, residency, etc), acknowledging this fact can be disorienting. My goal here is to suggest one path that has helped me personally get beyond the ideation phase.

1. Find a friend

In the future, this person will be called your co-founder. For now, it is a buddy with whom you like to work and share common interests. In truth, you can probably complete all the following steps without this, but, like a tough workout routine, it is much easier to get through the hard parts when you have someone that shares your goal and can help take some of the weight off of your shoulders.

Recognize that great ideas die the moment the vision is lost. It is like a fire that needs constant fanning. I consider myself highly motivated and still, on a regular basis, I want to quit either because “someone has already done it” or “it is impossible.” The same is true for my co-founder, David. Fortunately, and I can only theorize why it works out this way, David and I find ourselves perfectly out of phase, fanning the fire constantly.

2. Learn to code

If you already know how to code, great. If you don’t, you should learn. Just enough to get you by. There are a bunch of reasons why this is a good idea.

• To evaluate other developers
• To run early experiments (see step #4)
• To understand what technical challenges your idea faces
• To be taken seriously

Fortunately, there are only two things you need in order to learn how to code.

• A partner (for the reasons in step #1)
• A (series of) project(s)

The second point requires some explanation. The best way to learn to code is to do it and the only way to make learning tolerable is to have a project you want to see completed. I suggest you (with a friend):

1. Read How I Failed, Failed, and Finally Succeeded at Learning How to Code
2. Do a few (short) projects on ProjectEuler or Codecademy
3. Take David Malan’s free (Harvard) course Building Dynamic Websites
4. Do a simple project that you are interested in (our first one was a facebook app that transferred friends’ birthdays to your google calendar). This may be your app.

It is more important that you learn how to build something then that you learn a particular language. That said, I would suggest learning Ruby on Rails.

3. Do your research

If you are serious about your idea, you need to make sure that it has not already been created. Chances are good that there is something out there that at least resembles what you are doing. You should do a web search and search the app stores. Google Scholar may also be relevant. It is worth going past the first few results and trying anything that seems even remotely useful. Doing so may reveal clues as to what challenges you may have (eg distribution, keeping people engaged, technical issues).

Moreover, people will ask (either in person or as a user) how you are different or where your competition is. Here is where you get your ammunition to answer those questions.

4. Validate your idea

Entrepreneurship is a series of experiments. You want to perform the cheapest experiments possible early on and scale them up as you make progress. This is part of “Lean Startup Methodology” and is the philosophical offspring of the Toyota Production System.

Sometimes this means you have to build a version of your app and sometimes not. For example, you may be able to build a landing page that describes only what your app does using a LaunchRock or similar service in order to collect emails. This may be the easiest way to test if people are interested in using your app, which would be helpful to know before you actually start to build anything.

Related to this, I suggest you get comfortable sharing your idea with others. It is often feared that sharing your idea makes it easy for others to steal. I suppose there is that risk. However, far outweighing that is the fact that sharing it widely allows you to get valuable feedback.

5. Secure your resources (time and money)

You can probably do some early experiments while you still have a day job. Ultimately, though, you have to take the plunge and commit some real time to it. Jumping off at “The Right Time” is a leap of faith. It is also a very personal decision highly sensitive to individual circumstance. For David and I, taking time off between the third and fourth year of medical school made a lot of sense because we do not have additional obligations to patients or dependents.

The decision to take some time can be made much easier, though, if you are promised funding. There are a number of ways to obtain funding and this is the subject for my next blog post.

[Stay tuned for part two of this series!] 

We’re excited to learn that Symcat has been accepted from over 50 entries to be among 5 semi-finalists for the Robert Wood Johnson Foundation’s Aligning Forces Challenge. The objective was to use their provider quality data to help patients decide how to find care. The top three finalists will receive $100,000, $25,000, and $5,000, respectively.

You can read more of the details from Health 2.0.

Congratulations to the other semi-finalists!

A few days ago, we posted Symcat, our next-gen symptom checker, to Hacker News to get some early feedback on the tool and evaluate some basic user behavior. We were only on the first page of HN for a short time, but nonetheless, about 4000 users tried out Symcat and gave us some great feedback. As a thank you, we thought we would share with the HN community a little aggregate info about what people were searching. Below are the top 10 symptoms searched during our HN post.

Those top 10 symptoms comprised about 50% of the searches performed. A fair number of the searches were just people playing around with the site, but interestingly the observed proportions corresponded pretty closely with the symptoms seen in our dataset of outpatient and emergency room visits. We compared the number of people experiencing symptoms on HN with symptoms from the general population for the 10 most common symptoms nationally (chart below). For example, the first bar suggests, in words, that “someone from Hacker News is over 3x more likely to suffer from headache than the general population.”

It’s hard to know for certain how many people were just playing with the site and how many were truly experiencing the symptoms they searched for, but it’s interesting to note that the top 3 increased risk symptoms are all symptoms of the flu. As Google flu trends indicates, we are squarely in flu season, so this is what we would expect if people were entering their true symptoms. Moreover, the reduced risk of more serious symptoms “shortness of breath, vomiting, chest pain” would be exactly what we expect to find in a population of relatively healthy Internet users (as compared to their sicker counterparts in doctors’ offices). So, Symcat may be a promising way to measure the epidemiology of symptoms in real-time.

In any case, we hope you found this interesting and that you continue to help us improve Symcat with your feedback. Get well soon, Hacker News!

For additional symptom-related info, check out our dynamic infographics on headache, cough, and sore throat.

“Humana wants to become a consumer-driven business.” Thanks to Shankar Ram and Andrew Dunn of Humana for stopping by the Blueprint Health office in New York to hang out with the teams.