Centralizing our Doctor Data

How to build infrastructure with the end user in mind

At Oscar, we’re on a mission to make health care simpler, and in order to do so, we need to own the insurance stack — and our data. Provider data about our physicians, hospitals, and networks, and the infrastructure that supports it is especially central to our product. It’s needed to provide a rich provider directory, surface care options on Oscar’s apps, process claims, coordinate care, and build Oscar’s networks. All of these functions have a direct impact on a member’s or provider’s experience with Oscar and their larger health care experience.

As a product team, we’re constantly thinking about the user experience — whether we’re building our applications’ front-ends or our foundational infrastructure and systems. So when we set out to rethink our Provider data infrastructure, one of our primary goals was to build a thoughtful balance of data and systems that could enable better experiences for our members, providers and internal users.

Provider data wasn’t built for end users

Most insurers and health systems maintain different sets of data about their physicians, hospitals, and networks for their directories and for their claims systems. Despite containing similar information, these datasets rarely talk to each other. Historically, claims systems and databases were solely built to process and pay claims, with very little regard to what a patient or member might require to discover the most relevant doctors and care options for their medical needs. This is because, before Oscar, most insurers saw third-party administrators and benefits managers as their main clientele, as opposed to consumers.

This multi-pronged approach to provider data leads to disparities in information, no single source of truth, and inefficiencies in internal operations. For example, when a cardiologist informs an insurer that she is incorrectly being paid at the rate for an internal medicine doctor, this information might get updated in the claims system, but not the provider directory. As a result, an insurer’s members might continue to find that doctor under search results for internal medicine.

Many of the pain points that patients experience while navigating their care stem from infrastructural design driven by transactional processing requirements. In order to build the right infrastructure, we needed to take a user driven approach to better understand these pain points.

Provider data impacts almost every feature within Oscar.

Understanding the problem is the first step

We started out tackling the problem by building out a web of all the different touchpoints a member or provider has with Oscar that even remotely involve provider data. Unsurprisingly, we found that the dataset impacted nearly every feature. Included in our web was:

• Building our selective networks
• Helping our members find the right doctors
• Managing discharge planning for a patient
• Requesting a telemedicine visit
• Provider servicing
• Regulatory filings
• Authorizing treatment for Oscar members
• Paying claims

We then set out to learn more by:

1. Engaging with our providers and health system partners to learn more about their relationships with insurers and their patients
2. Sifting through hundreds of logs detailing calls with members and providers to identify pain points
3. Meeting with our Concierge and Provider relations teams to gather their feedback on interactions with providers and members
4. Conducting interviews and shadowing several internal operational teams like Provider Service, Claims Operations, Network Partnerships, Concierge, etc. to see how they’ve built processes and workarounds to support their operations
5. Meeting with different product and engineering teams to understand how they would benefit from richer data about our network to address user needs

At Oscar we have a centralized provider data product and engineering team, so we were able to aggregate inbound ideas from all other Oscar teams to inform our infrastructure design.

What did we learn?

It might seem obvious, but our findings confirmed that members, providers and internal users need to be able to trust that information about Oscar’s providers and networks are accurate. Additionally, internal operational teams at Oscar need to be able to access a rich set of data about our providers and networks to make better decisions and build better experiences for our users.

Here are some examples of how we can do that:

• With accurate information about our providers and contracts, we can improve our auto-adjudication rates for claims.
• Our Network team can maintain a real-time view of our provider networks and close gaps immediately to make sure our member have access to care.
• Our Concierge teams can better route care for our members with richer data about our providers and those providers’ relationships with other providers, hospitals and facilities.

Oscar came up with four principles for building provider data infrastructure

After all of our research, several whiteboard sessions, philosophical discussions debating “what is a provider?”, ideation, rinse, and repeat, we landed on the following product principles of how we built out our provider data infrastructure:

1. Create a single source of truth: This not only prevents redundancies in disparate systems, but — more importantly — allows us to maintain a shared infrastructure in which users can trust they are viewing the most accurate and up-to-date representation of our network. A single source of truth also allows us to build feedback loops in which members, Concierge teams, and claims data can update and better inform our source of truth.
2. Create a rich and flexible provider data model: We can’t possibly know everything that Oscar will build in the future. Our model needs to be flexible to not only support the intricacies of our providers and networks today, but to also support new ideas, future product iterations, or new lines of businesses. We also need to build out a data model that doesn’t just think about providers, facilities, hospitals and offices as disparate functions. We need a richer model that understood the relationships between all of these entities and the nature of these relationships.
3. Make this data accessible: In order to support a single source of truth, this data needs to be accessible to all the users of this information in real time. We need to build out services for other systems to fetch information about our network and also make sure to index changes without latency so that the single source of truth is reflected in our tools and to our users immediately.
4. Empower our users: As we continue to grow and scale, we need to build tools that allow our members, providers and internal users to access, suggest changes to, edit and configure information about our networks and provider data.

This investment in user-driven design has unlocked a rich roadmap of infrastructure updates, internal tools and member and provider facing features that we’ve been rolling out over the last year (and there’s more to come!). As we tackle building our own stack, we’re continuing to employ and refine this same approach and these principles as we build out member data, plans and benefits, payments and our in-house claims system.