Meet Gabe, Oscar’s very own Data Analyst. He’s responsible for analyzing member demographics, marketing and sales data, as well as modeling growth to help forecast and stage future initiatives.

Prior to joining the Oscar team, Gabe worked as an investment associate intern at Bridgewater Associates, a researcher at the Technology and Entrepreneurship Center at Harvard, and as an intern at The Daily Show with Jon Stewart. He graduated magna cum laude from Harvard in 2013 with a degree in Philosophy and was editor-in-chief of the Harvard Review of Philosophy.

Gabe was very sick when he was younger, so he and his family learned firsthand how important health insurance is — and how confusing it can be. He believes in Oscar’s mission to make health insurance more helpful and easier to understand.

Evolution of Backend Data

In this post, we’ll be taking an exclusive look at the backend stack for data processing here at Oscar and how it continues to evolve. This is a lengthy discussion, so it will come in three parts over the next few weeks.

Building an engineering program at a new tech company is an exciting and often tricky business. There are so many amazing new technologies out there, so many battle-tested and reliable services, and so many tools that could be right for the job if you just make a choice and tweak it until it works for you. It’s fun to try new things and experiment, and it’s rewarding to build rock-solid services. At Oscar, we’re all about maintaining a high degree of curiosity and technical exploration, while relying on proven methods and technologies. Does that sound consistent to you? It’s not!

So, how do you reconcile conflicting engineering impulses while still having a good time? By making sure you’re addressing the stuff that matters first and foremost. Let’s establish some foundational premises from which arguments can proceed. Those premises will be the properties our systems must achieve by whatever means we come up with. We’ll get back to the conflict in a later post.

Data Acquisition
First, what are the properties we need? Remember, we’re talking about backend data processes alone here. Let’s start with one of the first things we had to do in engineering - connecting partner feeds. The insurance business is a complicated space, and we’re currently handling multiple data feeds from about ten different partner companies. As of this writing, we’re receiving about 60 individual data feeds and that number is likely to explode over time. Some of the feeds are trivial, requiring us to simply copy new data into our storage systems and leave it there, but that’s the exception. One of our feeds is an ASCII database transaction log representing hundreds of tables from a remote database written in Cobol. Many are fixed-width text files or CSV that must be parsed according to a schema of byte offsets and data types. For good measure, we also see EDI and HL7.

Whatever the format, the mission remains the same: to create a unified and up-to-date view of the data for users - both external and internal. And of course, don’t let a single bit get misplaced! This data really matters. It affects the lives of our customers and if we mishandle it, we can create inconvenience or even add significant stress at a time when focusing on medical treatment should be top priority. Basically, we shouldn’t ever screw up our data, and when it gets screwed up (yes, it will happen), we must be able to recover fast. Now we have our properties - whatever our choices, our feed systems must:

Respect order.
If you process things out of order, you risk corrupting your data.

Break on failure.
Never write bad data or otherwise continue in an abnormal state. Break vocally (trigger an alert) so engineers are notified immediately.

Be idempotent.
Mid-process or mid-transaction errors are to be expected, and if you can’t fix and resume from an arbitrary point easily without corrupting data, you’re going to spend a great deal of time recovering from one-off errors.

Be low-latency.
We’re not talking about response times for user requests, but rather the latency between the creation of a datum and its integration into our data stores.

Maintain privacy.
Our jobs are often handling user data, and they must handle such data with great care behind a privacy curtain.

That’s already a fair amount of properties. If we have several competing approaches, they all have to maintain the same general behavior and that’s more work. Also, the harder the properties are to implement, the slower is your development and the more error-prone is your code. Given that, let’s add a few more higher-order properties. Our systems should be: consistently implemented and consistently deployed.

So, how have we been going about that?

In the beginning…
We first had to get off the ground by constructing processors for each of the partner feeds. It started small with just a few vendors to connect, maybe 5 important feeds. 5 became 10, which then grew to 50. Formats became more varied, as did the properties of the feeds themselves. At that point, it was fairly obvious that we didn’t want to write separate handlers for each feed, so we came up with the following general architecture:

Each feed clearly needed it’s own reader, and processing each feed had to respect the schemas associated with each feed format. However, the generated data objects could be standard, as well as the framework for managing the data in a transactional and idempotent manner. Readers generated TransactionLogEntry objects that combine a standard set of metadata (transaction ID, date, record type, feed source, etc.) along with an attribute-value payload containing the transaction data. Different SchemaManager subclasses were created to support different schema types (CSV versus fixed width versus whatever) but they all did the same thing - generate bindings from TransactionLogEntry objects to persistent storage, and passing those bindings to the StateManager to be handled safely.

We started out as a python shop (we still are with a few exceptions) so we obviously had a lot of libraries and frameworks at our disposal that we could have used for this, particularly with regard to data modeling. Should we autogenerate SQLAlchemy object mappers or Thrift or Protocol Buffers? Honestly, we weren’t too particular at that point. Plain old data is easy to deal with and easy to convert to other formats down the line. Maintaining flexibility early on has allowed us to experiment more easily with systems that don’t speak SQLAlchemy, which we’ll discuss in a later post.

At that point, we had made it fairly easy to achieve some of our core properties - strict ordering, break on failure, and idempotence. Good start, but that’s all it was - a start. In our next post, we’ll explore the initial runtime framework we used to achieve the other properties we needed.

Meet Dan, senior sales executive here at Oscar. Dan manages Oscar’s relationships with our general agent partners and handles all sales that come through our brokers. Prior to joining the team, Dan earned his stripes in health insurance at a number of companies including Aetna, First Reliance Standard and The Business Council of New York State. He loves dogs, football, crossfit and his girlfriend (in no particular order). #WeAreOscar

Meet Dan, senior sales executive here at Oscar. Dan manages Oscar’s relationships with our general agent partners and handles all sales that come through our brokers. Prior to joining the team, Dan earned his stripes in health insurance at a number of companies including Aetna, First Reliance Standard and The Business Council of New York State. He loves dogs, football, crossfit and his girlfriend (in no particular order). #WeAreOscar

Doing Well + Doing Good

When my mom and dad were kids, most jobs were relatively simple and straightforward. Titles were succinct, and generally self-explanatory. Companies fit into clearly defined industry niches. People seemed to be content with their work and had company loyalty. There was always the kid from the neighborhood who moved away for school and then to the big city, but most went to college locally and then settled down somewhere near home.

A job was something you did for 35-40 years as you raised a family, paid off your mortgage, and saved for retirement. If you happened to get a really good job, your parents had some bragging rights and you enjoyed a more comfortable life but for the most part people were satisfied with “an honest day’s work” and general financial stability.

Times have changed. Today, we would never settle for “just a job.” Why would we? We grew up hearing we were special and talented, right? Look at the ubiquity of the middle school honor student bumper stickers if you need more evidence. Research tell us that most Americans believe they are above average… so why would anyone settle for an average job?

Scroll through the social media feed of a typical 20 or 30-something and you will see inspirational articles on professional and personal success, images of vibrant social life with travel and fine food, and promotion of their favorite charitable causes and social concerns. The pursuit of success, fun, and meaning seems to be a common formula for the good life these days.

Like the single New Yorker who aspires to meet an Ivy-educated, attractive, former college athlete who makes a good living, enjoys theatre and live jazz, cooks like Rachael Ray, tutors underprivileged kids on weekends, and raises money for wells in Sub-Saharan Africa, I’ve been on a search for a company (or an idea for a company I can start) where I can fulfill my career aspirations, enjoy my work, and do something that really matters. A fairytale trifecta? Maybe.

Within the majority of professional options, potential for “success” and a chance to have a sense of meaning and purpose seem to be opposing elements. In recent years, I’ve been observing the growing popularity of two phrases — “social entrepreneurship” and “success and significance” — with great interest as more and more people wrestle with the desire to find more meaning in their professional lives.

What is social entrepreneurship? It varies depending on who you ask. I define it as creating economically sustainable solutions to social problems. The phrase “social entrepreneurship” has become a bit of a buzzword in recent years, especially on university campuses and in socially-minded communities. It is still in a place where there aren’t too many success stories but it is inspiring to see so many investing time and effort into the creation of organizations that seek to bring self-sustaining solutions to important causes.

The “success to significance” movement predates social entrepreneurship but it hasn’t evolved much from a relatively broken prototype. Case studies usually feature entrepreneurs and corporate titans who amassed fortunes, came to a realization that “success” didn’t fulfill them as hoped, followed by using the second half of their careers in search of significance (usually through philanthropy of some sort). There is nothing wrong with this game plan but it isn’t a very interesting story. There is a more epic story available; a story grandkids tell with pride.

At Oscar, I have found something uncommon. Our company is a wealth generator and job creator. Our product (health insurance + slick tech + top service) is massively scalable and nearly universal in potential social impact as everyone needs health care. Through the Health Insurance Marketplace and the Affordable Care Act, we provide health insurance to many families who now have health insurance for the first time.

Selfishly, I love that I get to work on this effort with a team that has one of the most interesting cross-sections of thought leadership I’ve encountered. We have top talent from some of our nation’s most coveted employers spanning the worlds of healthcare, insurance, technology, finance, consulting, media, logistics, design, and advertising. Plus, we get to spend our days in an enviable open loft space in a historic building in Soho.

We are making insurance simple, intuitive, and human. It is an innovative approach to help make health care less broken and more accessible to the masses. We partner in the wellbeing of our customers, contribute to the local economy, provide our team with rewarding work and opportunities for professional growth, and create value for our shareholders and stakeholders. It is an incredible mix.

The snarky New Yorker in me snubs his nose just a bit at some old friends from an economics class I took during the first year of my MBA program at Wharton. There was an animated discussion between me and a few others who insisted that business could not represent shareholder interests and perform a social good. At Oscar, we are proving them wrong.

In these still tenuous economic times, a job still is a job, and those of us with gainful employment should give thanks. But, if you are fortunate enough to find work that enables you to do well while doing good, know that it is a rare find.

by Rodney Gibson


Meet Rodney, a Senior Manager here at Oscar. He assists our senior leadership with special projects and management cadence. Prior to Oscar, Rodney worked at a variety of tech companies including Go2Net, InfoSpace and Yahoo!.

Rodney has also done some cool things like launching a solar powered lighting company for underdeveloped regions of the world and moonlighting as the pole vault coach at Stanford and Penn. Rodney is passionate about crossfit and social justice.


Meet Vin & TK, Oscar’s finance team.

Vin is our VP of Finance. He has extensive experience in financial reporting and treasury operations. Prior to starting with Oscar, Vin worked at a variety of big name corporations - including Fidelis Care, Exxon, and PricewaterhouseCoopers among others. Vin is a CPA and holds a BS in Accounting, as well as an MBA in Finance.

Takuma, or TK as we all know him, is our Accounting and Reporting Manager. TK has a mix of a public accounting and corporate finance experience. He worked on public accounting at Deloitte and Ernst & Young. TK is originally from Japan and grew up in San Francisco. A self-admitted sneakerhead, TK downsized his impressive collection of 90-something pairs when he moved to NYC.

Here at Oscar, TK is responsible for the proper transactional record keeping along with reporting financial results to the government and investors. Vin has an overall responsibility for financial reporting and operations accounting. He chose to join the Oscar team because it was an opportunity to be part of an innovative option in an industry that has been historically unimaginative.