Yvonne Wang, Senior Product Designer at Oscar

Over the past year, vibe coding has transitioned from hype to a staple of daily practice. At Oscar, we’ve been exploring how this shift redefines our design process.

Late in 2025, my product and engineering team integrated vibe coding into the early stage of a brand-new medical coding platform. By leveraging Figma Make as our primary tool for rapid concept validation, we were able to align with stakeholders faster and gather more grounded user feedback, ultimately compressing our discovery timeline from months of traditional scoping into just a few weeks.

This article reflects what we learned from that experience and why design craft matters even more in the era of vibe coding and AI. As our tools and processes continue to evolve, consider it a snapshot in time of how product design is changing at Oscar.

Why vibe coding?

Choosing a design approach usually comes down to the nature of the problem. For this particular project, we were designing from scratch, which required a level of clarity that static mocks simply couldn’t provide. We looked at four key factors:

First, the users.
Our users are expert medical coders who manage exceptionally nuanced data. We realized that asking them to “imagine” how a static screen might behave wasn’t sufficient. To get the most honest and valuable feedback, we needed to give them something they could actually feel and break.

Second, the stage of the product.
Because the product was in its infancy, the system wasn’t fully defined yet. In this highly ambiguous stage, we needed a medium that allowed us to “build to think,” making decisions in a living environment rather than on a static page.

Third, the scope and complexity.
The workflows were logic-heavy, spanning multiple roles and interconnected steps. It wasn’t enough to design isolated screens. We needed to understand how everything worked together end to end.

And finally, timeline and risk.
We had to move fast without skipping the de-risking process. By making the system tangible early, we could answer critical questions before we would typically surface in a traditional build.

With these factors in mind, vibe coding became our primary vehicle for moving from ambiguity to a validated production direction.

How we vibe coded in practice

Once we aligned on the vibe coding approach, we turned to Figma Make. We chose it because of its low barrier to entry and, more importantly, because it’s the most efficient way to share with cross functional teams and get immediate feedback.

However, once we got our hands dirty, we quickly realized that speed doesn’t guarantee quality. While vibe coding can generate prototypes in minutes, it still requires intentional shaping to get useful results. Through trial and error, a few principles ended up working well for us:

Start in Figma: structure before prompting.
It’s tempting to jump straight into prompting, but that often leads to layouts that are difficult to control. We found it much more effective to keep Figma as our “thinking space,” sketching rough wireframes and defining flows first. By feeding these structural skeletons into the AI, we gave it a foundation to follow, making the process far more predictable than starting from a blank slate.

Prompt the system, not just screens
Instead of focusing on how a single page looked, we focused our prompts on the logic. We described how users move across steps, how states change with user input, and how different roles interact. Focusing on the “connective tissue” helped the prototype feel like a cohesive, working system rather than a collection of isolated screens.

Precision naming as a scaling strategy.
In hindsight, we learned that naming every screen and feature clearly wasn’t a housekeeping task, it was a communication strategy with the AI. These names acted as “anchors”, making it easier for the tool to accurately update specific parts of the flow as it evolved.

The “Polished Trap”: why craft matters

While vibe coding is a superpower during early discovery, it can quickly become a liability when moving toward high-fidelity solutions. Because it’s so easy to generate something that feels “real”, it’s dangerously easy to commit too early.

Traditionally, the design process relies on a rigorous cycle of divergence and convergence, exploring a wide range of possibilities before narrowing down. But the sheer velocity of vibe coding can trick us into skipping those steps. When a prototype looks and feels functional, there’s a natural temptation to trust it immediately. We found ourselves falling into three specific traps:

• Settling for “good enough”: Committing to the first viable solution simply because it’s already interactive and functional.
• The death of exploration: Losing the patience for the wide-range exploration where the most creative, non-obvious ideas are usually found.
• Fixing instead of questioning: Optimizing the AI’s solution instead of questioning if we were even solving the right problem.

The turning point was realizing we had stopped asking the fundamental questions: Is this the right problem? What else could this be?

This is exactly where a designer’s craft stands out. In a vibe-coding world, craft is no longer defined by how well you can build a screen, but by the ability to maintain the discipline of the “messy middle.” It is the strategic judgment to know when to reframe the problem and the intuition to step back from a polished prototype to challenge the entire direction, and “What else could this be”?

As we continue to integrate these tools at Oscar, we’re learning that the value of a designer isn’t in the speed of the output, but in the depth of the inquiry. We use AI to move faster, but we use our craft to move in the right direction. Vibe coding can provide an answer, but designers still own the intent.

Getting the most value of vibe coding, without losing the craft was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Audrey Western, Product Designer
& Nicki Padar, Senior Product Designer

At Oscar, we’re on a mission to make healthcare so simple it feels invisible. But to get there, we often have to face some hard truths, including this one: for many members, the requirement to “create an account” is a often a roadblock, not an invitation.

To meet our members where they actually are — in their text messages and inboxes — we’ve doubled down on a powerful tool called applets. These are lightweight, login-free digital journeys that allow members to complete essential tasks such as viewing an ID card or paying a bill in seconds, without ever needing to remember a password.

In this blog post, we’ll be highlighting a few ways in which we’ve used applets to make things more convenient for our members.

Want to help us design the future of healthcare? Explore careers at Oscar.

Creating instant digital ID Cards

When we kicked off the applet development process, we prioritized four key pillars. First, we needed a tool that was flexible enough to span email, SMS, and QR codes, yet highly customizable so we could generate unique, personalized links for every member. What we created also had to be agile, allowing our marketing and operations teams to build and launch experiences using pre-built components without waiting on engineering.

Most importantly, we designed these to be purpose-built and efficient: a member should be able to complete their task in a matter of seconds, solving their problem in a single visit without ever needing to look back.

Our digital ID experience gave us a powerful way to apply these values. For many members, their ID card is the key to accessing care, but waiting a couple of weeks for a physical card can cause confusion, anxiety, and even delay care.

Now, as soon as a member enrolls in Oscar and provides an email or phone number, they receive a secure link to their digital ID card via text or email. To access it, members simply verify their identity with their last name, date of birth, and zip code, and can then save the card to their device.

In addition, we’ve also enabled member self-servicing options via our phone system and empowered our support staff to be able to send members their digital ID through internal tools as well. The results of this instant access speak for themselves: Today, 37% of ID cards sent by support staff are now digital.

Simplifying PCP selection

Confirming or updating an assigned Primary Care Provider (PCP) is the top reason our members call us.

Thanks to applets, this process is a lot faster and more seamless: Members calling in with this intent are now able to self-service via our phone system, and receive a text message or email link to the applet. This allows them to confirm or edit their PCP selection without needing to wait to speak to our support staff.

Since we launched this feature in August 2025, hundreds of members have already updated their PCP using the applet, freeing up our support team for more complex issues. We also integrated this applet into onboarding communications during Open Enrollment, making it easier for new members to set their PCP from day one.

Streamlining bill payment

Members are always looking for ways to make payments more quickly and with less friction. Knowing a policy is active and in good standing provides financial security and peace of mind, ensuring access to necessary care.

Our bill pay applet reduces that friction by providing an easy way to make a payment so members can remain in good standing. Additionally, the applet encourages members to turn on monthly autopay, which eliminates the mental load of remembering to pay each month.

Thanks to this addition, the monthly premium payment rate from our overdue billing reminders increased 13% MoM due to the inclusion of the bill pay applet. One of our campaigns saw a 49% MoM increase in payment rates

Creating a bridge to account creation

The applet successes detailed above revealed a crucial opportunity: many members were using applets to complete high-value actions without ever creating a digital account. However, without an account, they miss out on the full power of Oscar’s platform, including personalized information, self-service tools, and our rewards program.

We asked: What if every authenticated applet interaction could become a seamless gateway to full account creation?

To answer that, we introduced a frictionless “create an account with 1 click” experience. After verifying their identity to access the applet (by entering their last name, date of birth, and zip code), members are prompted to enter their email at the end, which then emails them a secure login link.

This approach is fast, smart, and scalable where we are meeting members in a moment when they already have the intention and motivation to do something Oscar-related.

Applets as an engine for high-value actions

Applets succeed because they remove the cognitive load and wait time often associated with health insurance. By delivering these functionalities directly via text or email, we’re responding the member’s immediate intent and helping them solve problems in the fastest way possible.

What we’ve learned is that the most powerful form of engagement isn’t demanding attention, it’s proving value. By providing immediate utility through applets, we build trust as a health insurer that is working for our members.

We’re incredibly proud of how applets are simplifying moments of need and look forward to expanding these journeys, further cementing Oscar’s commitment to making healthcare simpler, faster, and more accessible.

Want to help us design the future of healthcare? Explore careers at Oscar.

Beyond the login: How applets are removing barriers to care was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reward programs are everywhere, from credit cards to coffee shops, but when it comes to health insurance, the idea can feel out of place.

At Oscar we understand that members aren’t looking for points; they’re looking for value, clarity, and care. So when our team set out to design Oscar Unlocks, our new rewards program, we saw it not as a marketing play, but as a design challenge: how could we make a rewards experience that genuinely helped members get more out of their coverage?

This question helped us to approach this problem with a design mindset. Here’s a look at what we learned along the way.

Want to help us design the future of healthcare? Explore careers at Oscar.

Research

Before committing to a program structure, we dove into discovery. Through desk research and conversations with our members, we set out to understand people’s feelings and expectations around rewards with regards to their health insurer.

What we learned:

• Well-designed rewards programs with perceived value, fairness, and personalization may increase loyalty, but this is not through rewards alone. Rewards programs create engagement, and engagement influences loyalty. (1, 2)
• Incentives distributed frequently (monthly rather than yearly) perform better in fostering engagement. (3)
• Rewards work best when they follow the action immediately, rather than being delayed. (3)

What surprised us though, was that many members were confused that we even asked what rewards they would want from their health insurer. Most participants simply wanted to feel like they were getting full value from their plan.

This insight fundamentally reframed our strategy. The opportunity, we realized, wasn’t just to add rewards on top of the insurance experience; rather it was to help members extract more value from what they already had.

Designing the Program

We learned a lot by conducting a landscape analysis. Through our research we learned that different industries take different approaches to rewards programs. Credit card companies, for example, use mostly a points-based reward system, whereas fitness rewards use gamification mechanics like badges and streaks. Educational programs included more interactive components like moving through a journey or collecting missions. We didn’t come across many health insurance rewards programs, turns out they’re not so common!

In our early design phase, we explored options inspired by all our competitors, but ultimately gravitated towards milestone-based badges. We envisioned each badge tier tying to digital tasks that served members while helping them get more value out of their plan. This is how Oscar Unlocks came to be, where earning badges unlocked meaningful rewards such as personalized experiences, giveaway entries, and VIP access to our support team.

Testing and Iteration

After aligning product, operations, and legal stakeholders on the feasibility of a rewards program, we felt confident in getting feedback from real members through low-fidelity prototype testing.

The results revealed a critical gap: Milestones earned later with tangible rewards (like product giveaways) tested exceptionally well. Whereas easier tiers felt like low-value add-ons that may not be worth the effort. Without something compelling in the early stages, we’d risk losing members’ motivation to keep going with this program.

This highlighted the importance of leaning into gamification mechanics like progress indicators, achievement previews, and tier foreshadowing. These elements created a sense of momentum and made the journey itself feel rewarding, not just the destination.

Health insurance is already inherently complex, so we wanted to avoid adding even more cognitive load as members worked toward unlocking badges. Our high-fidelity design phase became an exercise in strategic restraint: How could we make gamification feel rewarding without introducing friction?

• Staying out of the way: Members open their insurance app with a pressing need in mind, like checking a claim, finding a doctor, or reviewing coverage, not hunting for rewards. Because of this we designed the rewards program entrypoint as a subtle gold button in the top corner that sparked curiosity without demanding attention.
• Showing what matters: The rewards landing page answers three questions immediately: Where am I? What’s next? How close am I? Current badges, next milestone, and progress bar prominently above the fold so members wouldn’t waste time trying to understand where they are. Once earned, badges are moved into a “Completed” section below to keep focus on what’s most relevant.
• Getting the word out: Our member marketing campaigns support the full engagement funnel from raising awareness to encouraging participation throughout the program. To make the experience feel more interactive, we send celebratory notifications upon task or badge completion, with motivational reminders to guide members towards next actions.
• Making it feel earned: Badges require a deliberate swipe-to-unlock gesture to unlock, rather than an automatic reveal. This small bit of friction created a stronger emotional connection between member effort and achievement, making the reward more meaningful.

Looking Ahead

Learning how to design delightful experiences that respect the unique ways members engage with their health insurance is important. Members aren’t seeking entertainment or rewards points. They’re navigating a complicated system during moments of need, trying to maximize the value of coverage they already have.

We hope Oscar Unlocks helps bring a moment of delight in these stressful times while managing their health, and we’ll keep iterating on it, like using the foundation in place to add programs that incentivize healthy behaviors, to help our members see and access the value that Oscar already brings.

Want to help us design the future of healthcare? Explore careers at Oscar.

Footnotes

Yi, Y., Jeon, H. Effects of loyalty programs on value perception, program loyalty, and brand loyalty. JAMS 31, 229–240 (2003). https://doi.org/10.1177/0092070303031003002

Chen, Y., Mandler, T., & Meyer-Waarden, L. (2021). Three decades of research on loyalty programs: A literature review and future research agenda. Journal of Business Research, 124, 179–197. https://doi.org/10.1016/j.jbusres.2020.11.057

Danaher, P.J., Sajtos, L., Danaher, T.S., (2020).Tactical use of rewards to enhance loyalty program effectiveness. International Journal of Research in Marketing, 37(3), 505–520. https://doi.org/10.1016/j.ijresmar.2020.02.005.

Turning rewards into real value: How we designed Oscar Unlocks was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Sydney Choi, Senior Product Designer, Virtual Care

At Oscar, we use AI to help make our patients’ experience faster, simpler, and more personalized. At the same time, privacy remains our first priority, and we protect our patients’ data with strong safeguards and security practices.

Ask any provider, and they’ll tell you: clinical documentation is one of the most time-consuming aspects of their job. Every patient encounter must be thoroughly documented to ensure safety, continuity of care, and clear communication among care teams.

But this essential task comes at a cost: hours spent typing notes, updating charts, and retracing conversations, often long after the patient’s visit. The result? Providers often feel tethered to their screens instead of their patients, and feel a growing sense of burnout from administrative work.

A study conducted by Athena Health found that 69% of physicians reported spending too much time after hours on clinical documentation in electronic health records, and 62% identified excessive documentation requirements as their leading cause of burnout.

Some clinicians turn to scribes — professionals who shadow visits and handle note-taking — to lighten the load. But what if AI could step into this role, offering the same support, instantly and at scale?

Bringing AI-drafted documentation to synchronous visits

At Oscar, we’ve already made strides in reducing documentation burden with AI-generated notes for messaging-based visits. These asynchronous interactions are a natural fit for AI: the written conversation serves as both a transcript and a reference, and providers can review and edit notes at their own pace. Plus, messaging visits tend to be focused on a single issue, making it easier for AI to capture the relevant details.

Synchronous visits, such as those conducted over video or phone, introduce a new set of challenges. In these real-time conversations, AI must first transcribe live speech into text before it can even begin drafting documentation. While providers can review the AI-generated transcript, it’s not as reliable as a written messaging thread created directly by the provider and patient.

The AI also has to navigate the complexity of separating crucial clinical information from casual conversation. If something important is missed or misinterpreted, providers have no easy way to verify the details. The stakes are high: incomplete or inaccurate documentation can compromise patient care and force providers to rely on memory — a risky proposition after a full day of appointments. With that in mind, we knew we needed to launch something that providers could immediately trust.

Prototyping AI documentation with 0 Lines of code (and 1 wizard)

We had a lot of questions about how AI-generated documentation would actually work for video visits:

• Would it be more work for providers to review and edit an AI-generated note than to write it from scratch?
• How much of a delay would be acceptable between finishing the visit and receiving the AI-generated notes draft?
• What would help providers trust and find value in the AI-generated note draft?
• And how might their behavior change with AI support?

To increase our confidence in building the right workflow, we ran a Wizard of Oz study, which entailed simulating the AI experience without writing a single line of code. Providers conducted mock video visits with colleagues role-playing as patients, using real patient scenarios and test charts.

After each visit, we manually transcribed the conversation and fed it into AI to generate a draft note, which the provider then reviewed and edited. This approach allowed us to closely observe how providers interacted with AI-generated notes, what they found helpful, and where friction points emerged.

One key friction point we uncovered was the delay between completing a visit and receiving an AI-generated draft for review. For the purposes of our study, we conservatively built in a one-hour delay, which reflected the time required by current systems to record, transcribe, and draft documentation. By the time the draft was ready, providers had often moved on to other patients, making it difficult to recall details and efficiently review the note.

Many felt that editing a one hour-delayed, AI-generated note could actually increase their workload, especially if the draft felt unfamiliar or missed key clinical details. On the positive side, providers appreciated being able to focus more on the patient during the visit, knowing that AI would handle most of the documentation.

Ultimately, our zero-code prototyping provided invaluable insight: with our existing technology, a one-hour turnaround simply wasn’t fast enough. We evaluated built-in transcription options from our video platform, but found them both expensive and primarily designed for basic captioning, falling short of our quality and speed requirements.

This research study validated the need to invest in building our own custom streaming service for near real-time transcription — a significant but essential step for delivering a truly effective solution.

How it works: From conversation to clinical note

Our new AI scribing tool generates draft clinical notes for providers after each video visit. It transcribes conversations in real time and combines them with relevant patient data to create a comprehensive SOAP (Subjective, Objective, Assessment, and Plan) note draft, saving providers time and reducing administrative burden. Importantly, providers retain full responsibility for all clinical decision-making, including determining and entering diagnoses and orders. This ensures that AI serves strictly as a productivity tool, supporting providers without replacing their expertise.

Here’s how it works:

• Transcription begins as soon as at least two participants join the video call and continues until the provider clicks “Generate Note.”
• At that point, the AI uses the live transcript, patient chart and demographic data, reason for visit, and any provider-entered information to create a draft of the subjective, objective, and plan sections of the SOAP note. This takes about 20 seconds on average.
• Providers then review and edit the draft as needed, and with another click, can have AI generate patient instructions based on the finalized documentation.
• Once complete, the provider submits the note and is ready for their next patient.

To maximize the quality of the AI-generated notes, providers are encouraged to verbalize their clinical reasoning and thought process during the visit so it’s captured in the transcript. For any personal reminders or questions a provider may want to jot down during the visit, a separate clinical scratchpad is available.

Importantly, scratchpad notes are not shared with the AI. This decision was intentional: by keeping the scratchpad separate, providers can clearly evaluate the quality and reliability of the AI-generated documentation on its own, without their own notes influencing the draft. This helps build trust in the AI’s capabilities and ensures that any improvements in documentation quality are truly attributable to the AI itself.

On the patient side, we show a disclaimer before joining the visit, letting patients know that a virtual assistant may be taking notes. If a patient has trouble joining the video room, providers can use the in-video calling feature to add them via phone. And as a fallback or if the patient prefers not to be recorded, providers always have the option to document manually instead of using AI.

Building provider trust: Partnering for successful adoption

Introducing new technology into clinical workflows is never simple. Providers are understandably cautious, given the high stakes for patient care and their professional licenses.

For this reason we made providers true partners during the entire process. Through our Wizard of Oz study and additional research sessions, providers could act out scenarios, share feedback, and get a sense for how the tool would fit into their daily workflows. Early pilot participants became ambassadors, vouching for the tool’s value and building confidence among their peers. We also partnered closely with clinical leadership to ensure the AI-generated drafts met our standards for excellence, further strengthening buy-in across the practice.

Additionally we included in-app guidance, developed tailored training materials with our Product Operations team, and set up a dedicated Slack channel for feedback. This collaborative approach ensured providers felt heard and saw their concerns addressed, making them more open to adopting the new technology and evolving their workflows. We also knew that trust would deepen as providers experienced the quality of AI-generated drafts firsthand and discovered where AI helped reduce their documentation burden.

Results: “time work” and “mind work” savings

“It has cut my charting time in half! Can we incorporate this into the phone calls and Lab reviews too PLEASE!!!!!” — Oscar Primary Care Provider

“It has been professionally speaking, life altering. Charting is a large portion of our work as providers and this tool has reduced the administrative burden during visits. It has reduced stress levels as well which helps with balancing all the duties we are responsible for during our shifts.”- Oscar Primary Care Provider

“I love it… it’s great, it’s a game-changer. Not only saves time but allows us to focus on the patient more.” — Oscar Primary Care Provider

We began by piloting with a small group of power users for two weeks, allowing us to gather feedback and fine-tune the prompts. After a successful pilot, we rolled out the feature to our broader primary care practice in mid-April — and the response has been overwhelmingly positive.

• Over 8,400 primary care visits (97% of all primary care video visits) conducted using AI scribing
• 8 minute reduction, on average, for pre and post-appointment documentation time
• 91% of providers report an increased ability to focus on the patient during the visit, with 64% reporting a significant increase for new patients and 56% for established patients

While it’s tempting to measure success solely by the reduction in documentation time — a key factor in scaling care — there’s more to the story. Documentation isn’t just “time work” (the minutes spent generating note content, waiting for stuff to load, or coordinating with an MA); it’s also “mind work.” This includes forming diagnoses, crafting care plans, and selecting the right ICD10 codes. Often, what we track as time work is deeply intertwined with this cognitive effort.

Our goal is to minimize administrative time work, freeing up valuable mental bandwidth during each visit. While the overall visit length may remain the same, this shift allows providers to spend more of that time on meaningful patient interactions and deeper clinical thinking — the hallmarks of quality care.

What’s next

In the near term, we’re working on expanding support to phone visits and making it seamless to generate AI drafts even if the visit modality changes mid-appointment (for example, switching from messaging to video). We’re also continuously refining our AI prompts to improve note quality and provider experience.

Looking further ahead, we’ve already started to explore how we want this to evolve in the next few years. Some things we’re starting to think about include:

• Ability for AI to capture structured data from conversation — for example, automatically adding a follow-up reminder when a provider says, “Come back in two weeks.”
• A more integrated experience, with the video feed and the EMR in a single, unified view
• Smarter AI-driven pre-population of the note based on patient intake and prior visits

Our vision is to create a world where providers can deliver excellent care without sacrificing their well-being or personal time. By making documentation smarter and more seamless, we’re not just reducing administrative burden — we’re helping providers reclaim the joy of practicing medicine and putting the focus back where it belongs: on the patient.

Huge thank you to the team members who helped move this initiative forward: Alex Yu, Vadini Argarwal, Ingrid Fan, Becky Eom, Madi Shultz, Brian Lee, Caleb Bank, Tory Grimley, and Maddy Ngo

AI scribing for video visits: More time for patients, less time on notes was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Brian Lee, Senior Product Manager, Virtual Care

In 2024, Oscar’s Virtual Care team set out to solve a persistent challenge in virtual healthcare: how can we make messaging encounters more efficient — while continuing to uphold clinical quality and deepen patient trust?

The answer came in the form of Oscar’s first member-facing generative AI product: the AI Clinical Intake Bot. It’s designed to gather clinical context from patients before a provider ever joins the thread — helping providers focus on what they do best: diagnosing and treating patients.

Enabling virtual messaging at scale

When a member initiates a virtual urgent care (VUC) consult, providers often spend the first few messages collecting basic information as part of the intake process: where is the pain, how long has it lasted, how severe is it? These context-gathering steps account for a significant portion of the consulttime that could otherwise be spent on clinical decision-making.

This inefficiency becomes more pressing as we scale — especially in light of the Live Chat launch which increased VUC Messaging utilization by 2.5x.

We saw an opportunity: what if a bot could take on the basic intake work typically handled by a clinician at the start of a consult — freeing up provider time, enabling more efficient consults, and helping us meet increasing patient demand more cost effectively?

The analogy: Working top of license

In brick-and-mortar clinics, intake is often handled by medical assistants, nurses, or students before a treating clinician steps in. This allows clinicians to “work at the top of their license” — spending time on the complex, high-value decisions only they are trained to make.

Our goal was to bring that same model to Oscar’s virtual care. We envisioned the AI Intake Bot to serve as a digital medical assistant, collecting structured, clinically relevant information from the patient so the provider can jump straight to the diagnostic work.

Why AI? Why not just a survey?

Oscar already uses structured tools like Patient Check-In to gather patient-specific information — think medications, allergies, behavioral health screenings, etc.

These flows are ideal for confirming and updating known data, which can be neatly stored in structured fields and fed back into our EHR. But they fall short when it comes to encounter-specific information — details about a member’s current issue, like symptoms and severity. This kind of unstructured input is best captured in free text and varies significantly across patients and visit types.

That’s where AI shines.

Rather than forcing patients into rigid forms, GPT can have a natural, adaptive conversation. If a patient says “my leg hurts,” the bot follows up:“Could you be more specific about where on your leg? For example, is it on your thigh, calf, shin, or ankle?”

This type of contextual follow-up improves the quality of information collected and elevates the patient’s experience. It shifts the process from a monotonous form-filling task to a fluid, interactive conversation about their needs.

How it works

From a product perspective, we designed the bot to feel simple and seamless for the member — while quietly executing a highly orchestrated clinical workflow behind the scenes.

Here’s how it works:

1. A patient requests a VUC messaging consult via the app or web
2. The bot automatically assigns itself to the consultation, introduces itself as an AI assistant, and clearly sets expectations
3. It begins a back-and-forth conversation with the patient to collect information, using clinically validated Initial Assessment Questions
4. Once the intake is complete — or if the patient stops responding, requests a human, or shares symptoms that require escalation — the bot ends intake and unassigns itself
5. The conversation is then routed directly to the provider queue, where a clinician picks it up and continues the consult with full visibility into the patient’s responses

To ensure clinical safety, we grounded the bot in Initial Assessment Questions (IAQs) derived from standardized Nurse Triage Protocols. These are the same clinically validated guidelines used by our Virtual Care RNs. The bot is strictly scoped: it can only ask questions, clarify responses, and escalate to a human when needed or requested by the patient. It never makes diagnoses or gives medical advice.

Additionally, during the bot intake process, consults show up in a dedicated queue which providers can monitor. It also gives them the option to “commandeer” or take over the encounter from the bot.

Member research: How patients feel about AI

Before building, our user research team interviewed members to understand their perception of AI in this context and pressure test design direction.

• Most patients were comfortable interacting with the bot — especially once they understood its purpose was to help, and not replace, their provider
• Transparency matters. Members appreciated that the bot disclosed it was AI-enabled
• Boundaries matter even more. Patients were clear that they were fine answering questions — but didn’t want AI trying to interpret symptoms or offer advice

This research helped us shape the bot’s interaction model: be transparent, stay in scope, and act as a helpful intake assistant — not a clinical decision-maker.

Building the bot

Instead of hardcoding a rigid decision tree, we built a prompt-driven system using GPT to dynamically interpret and ask clinically relevant intake questions.

Our approach blended the flexibility of AI with the structure of traditional triage protocols — allowing the bot to operate like a virtual nurse conducting a detailed symptom assessment.

Each bot interaction is grounded in a carefully constructed prompt that provides:

• Clinically validated Initial Assessment Questions (IAQs), specific to the member’s identified Reason for Visit (RFV)
• Patient context, gathered through a free-text description field, age, and gender
• Interaction strategies, like how to follow up on vague responses and using patient friendly vocabulary
• Safety protocols, for identifying red flag symptoms and adhering to only information collection
• Escalation rules, including when to immediately escalate to a human

At the core of the prompt is a clearly defined role: the bot acts as a detail-oriented nurse, focused on understanding symptoms, not offering diagnosis or advice. Again, these boundaries are enforced through strict rules around tone, response format, and safety protocols.

For example, if a patient reports symptoms like chest pain or trouble breathing, the bot immediately escalates with an #urgent_escalate token — no further questioning.

In situations where patients provide a vague or partial answer, the bot is instructed to follow up:

Patient: “I feel dizzy.”
Bot: “Have you also experienced symptoms like blurred vision, fainting, or trouble standing?”

Each question is selected from a dynamic IAQ-driven set, mapped to the RFV. For instance, in the case of nausea, GPT receives structured clinical definitions for mild, moderate, and severe symptoms, and is instructed to collect this context in patient-friendly language.

This prompting strategy allowed us to scale across multiple RFVs, maintain clinical rigor, and create a member experience that felt natural — yet tightly governed.

Results: safety, time savings, and engagement

“It asked a lot of good questions and helped me make a diagnosis wayyyy quicker.”
 — Oscar VUC Provider

We first launched this feature as an A/B experiment only to 1% of VUC messaging consultation, for specific RFVs. Over the course of our 8 week experiment timeline, we slowly ramped up traffic to 50%. This allowed us to closely monitor conversations for safety, while expanding access to the feature and increasing data collection for experiment analysis. The results we found were:

Safety first:

• 2,400 bot intakes reviewed by providers: 0 clinical red flags, 0 incorrect escalations

Efficiency gains:

• 95% of providers reported time savings; with over 50% reporting saving >3 minutes per consult
• Directional reduction in provider messages for most common RFVs like sore throat and UTI
• Shorter consult durations in asynchronous messaging

Patient engagement:

• 11% increase in consult completion rate
• 66% of patients completed all questions

What’s next

The AI Intake Bot launched fully in December 2024, with continued auditing and a 5% control group to ensure long-term safety and performance monitoring.

While the results are promising, we still have room for improvement. Looking ahead, we are planning:

• AI-powered summarization of intake, to reduce provider review time and ensure providers are not repeating questions during the consultation
• Spanish-language translation for intake, to help all members get care quicker
• Expansion to more RFVs, to streamline intake across additional consults

Final thoughts

By automating the low-complexity, high-volume work of intake, Oscar’s AI Clinical Intake Bot enables providers to work at the top of their license — delivering faster, more focused care at scale.

And by designing transparently and responsibly, we’ve built a member-facing AI that patients understand and are willing to engage with.

At Oscar, we’re pushing the boundaries of technology to make healthcare smarter and more efficient. Interested in joining us? Check out our open roles.

How we built Oscar’s first member-facing AI: the Clinical Intake Bot was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Brian Lee, Senior Product Manager, Virtual Care

When it comes to communicating with both loved ones and businesses, many surveys have suggested that people would much rather do so via text than phone calls.

Yet this preference may not be as universal as it seems. At Oscar, our data has shown that, for a significant portion of our members, a phone call, not messaging, is the preferred mode of communicating with providers. That’s because, for many of them, phone consultations feel both more immediate and more personal.

On the other hand, there are also clear unique advantages to messaging in virtual care. It allows patients to engage privately from any setting — whether at work or in a quiet coffee shop — while empowering providers to support patients more efficiently.

Additionally, messaging threads serve as both conversation and medical record. This structure lends itself to easier administrative automation through AI-driven tools, such as intake, documentation, and order generation. In particular, text-based consultations are well-suited to AI-driven intake, enabling automated agents to efficiently gather initial patient information such as symptoms and severity before a provider joins the conversation.

Given the relative benefits of phone calls and messaging, Oscar’s Virtual Care tech team wondered: Could we bridge the gap between asynchronous messaging and real-time responsiveness to transform the experience not just for members, but for providers as well?

How Live Chat Works

To that end, we launched Live Chat for our Virtual Urgent Care (VUC) service, a critical, no-cost resource for Oscar’s ~1.8 million members.

Live Chat is simple: When members go to request a VUC consultation through the Oscar mobile app or web portal, they’re given the option to select Live Chat through a dedicated entrypoint that is displayed alongside Phone and Asynchronous Messaging. When they select Live Chat, a structured “wait-in-line” experience displays their estimated wait time and place in line. Once a provider is ready, they are able to engage in a real-time conversation.

With this feature, our hypothesis was that real-time interactions would lead to quicker care, creating a streamlined experience with shorter resolution times. Over time, this would encourage more patients to choose messaging, aligning with their expectations for immediacy and responsiveness in virtual urgent care.

The immediacy of Live Chat also significantly improves the provider experience. Live Chat encourages members to respond quickly, enabling more efficient communication between members and providers. That level of focused case management reduces the need for handoffs, helping providers maintain continuity of care. Fewer interruptions and less context switching, in turn, increase providers’ efficiency, freeing capacity to serve more patients.

The results from our pilot were highly encouraging:

• Improved patient experience: Through our pilot we saw a staggering 175% increase in messaging adoption, with over half of members choosing Live Chat over other methods of communication. Through Live Chat, both consultation and response times decreased by 90%. Overall consultation completion rate increased by 20%. From our member feedback survey, patients described Live Chat as “fast,” “efficient,” and “convenient.”
• More efficient providers. With a 28% improvement in efficiency, measured by consultations completed per hour, Live Chat has also improved the experience for providers. This efficiency is largely attributed to the reduction in context switching and patient unresponsiveness, allowing providers to focus on real-time patient interactions.

Bringing Live Chat to more members and providers

Following our pilot, we have expanded Live Chat staffing with more providers across multiple states and extended operating hours. With patient experience metrics continuing to improve, we’ve set our sights on the next iteration: further supporting our providers and enabling creative configurations to expand Live Chat to more patients.

In addition, we also plan to further improve the provider experience by developing tooling such as multitasking notifications and automated workflows for managing unresponsive patients. Our goal is to also introduce advanced configurations that can support staffing by state, language, and capacity in non-continuous and discrete staffing blocks.

The success of the pilot confirms our hypothesis: Live Chat can serve as a transformative tool, establishing messaging as a viable and efficient alternative to phone consultations. This transformation not only enhances patient satisfaction but also optimizes the operational efficiency of healthcare services.

Our vision is to make Live Chat a core part of Virtual Urgent Care, giving patients the immediacy of live interaction and the flexibility and privacy of Messaging. With each iteration, we move closer to a future where urgent care is as seamless and accessible as any digital chat experience.

At Oscar, we’re pushing the boundaries of technology to make healthcare smarter and more efficient. Interested in joining us? Check out our open roles.

Live Chat: Introducing real-time virtual care for Oscar Members was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

The key to creating high-value experiences is to build with our members and deeply understand their needs, barriers, motivations, and pain points. It is our priority to honor and defend the needs of our end users whether that means members, providers, insurance brokers, etc. We constantly challenge ourselves to think of new ways to live out our “user obsession,” which led us to explore a new process called continuous user research.

“Continuous user research” is the ongoing collection of user feedback and an overall commitment to regularly talking to your customers. The premise of continuous research is intriguing and positioned to address two primary UX Research challenges:

1. We don’t always know what we don’t know.

We can identify lots of problems from quantitative data, analytics, or other signals that surface research questions. However, sometimes, we don’t know what we don’t know.

2. We don’t always have time (or the need) for a dedicated, point-in-time study.

Dedicated, cross-sectional research is critical in many cases, but sometimes, we don’t have time to set-up, recruit, and properly execute a large study. Some questions may also not require a large, point-in-time study to explore. These small to medium-sized questions (more evaluative in nature) are no less important to address, but may not be the right candidates for full blown, dedicated studies.

That’s where continuous research programs shine. At Oscar, we call our continuous research program “Tuesday Testers.” Every other Tuesday, we interview Oscar members, and we make the most of the time we have with them. These thirty-minute sessions include:

1. A pulse check on the member, their experience with Oscar, where we excel, and where we fall short. This helps us address UX research challenge #1. We create a space where problems can surface that might otherwise be left in the shadows.
2. Gathering member reactions to new concepts and early design work. This helps us address UX Research challenge #2. Every week as our designers develop and refine new concepts, they stumble into questions that member feedback helps answer. Our Tuesday Testers program has made space for these explorations and helps us quickly decide which early concepts are worth further exploring (and which we should reevaluate).

While continuous research might seem easy and breezy, this program was hard work to bring to life and to maintain. From idea to execution, we’ve captured three major lessons learned about continuous research programs:

1. When we launched this program, we initially designed it for Friday testing — the original name was “Friday Five.” We’ve since had to pivot to Tuesdays because, like us, members have “Friday brain” too. We had significantly lower interest in feedback sessions and many who booked sessions never showed up. Thus, “Tuesday Testers” was born. We haven’t had a problem with engagement or no shows since.
2. Continuous research infrastructure is meant for exploring very specific research questions. We have strict requirements for what we can explore with Tuesday Testers versus what deserves a dedicated, point-in-time study. Our product design team helps us inform the questions we want to explore and which of those are most pressing, which helps maintain the integrity of the program. This stringency has been critical to preserving research integrity and methodologically sound study design. Continuous research doesn’t replace traditional UX research studies! There’s a time and place for both.

Pro Tip! If your study aims to explore questions like “what is the right thing to build,” “who is our user,” “what do they need in a given context” — you probably need to use a more traditional UX research approach with a point-in-time study. If you’re more curious about the usability, comprehension, or utility of an early stage design concept, then a continuous research approach may be appropriate. Read more about choosing the right study for your research questions here.

3. This approach requires dedicated days for user interviews that are always kept meeting-free. Our members deserve our undivided attention. It’s important to create a culture that supports that!

Our “Tuesday Testers” program has helped us keep our finger on the pulse of the Oscar member experience — along the way learning what’s worth further investment…and what’s not.

Quick Example:

Vetting Before Setting: As a part of the Oscar experience, members on certain plans are encouraged to “set” a PCP (Primary Care Provider). Most of our design flows prompt the user to set a PCP right after searching for one. However, as Tuesday Testers have pointed out, members don’t want to set a PCP until they’ve had a chance to “vet” the doctor with a visit. This has helped us reimagine where and when a user is prompted to formally set their PCP.

Oscar’s mission is to make a healthier life accessible and affordable for all. By maintaining this continuous feedback loop, we can effectively gather and respond to member needs, helping us fulfill our mission. Our calendars are marked for every other Tuesday: turning feedback into action!

At Oscar, we’re pushing the boundaries of technology to make healthcare smarter and more efficient. Interested in joining us? Check out our open roles.

Lessons Learned: Launching Continuous User Research at Oscar was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Oscar Health, we recognize the pivotal role that brokers play in the insurance ecosystem. Brokers are not just intermediaries; they are trusted advisors who help members navigate the complex world of health insurance. Historically, the relationship between brokers and carriers has tended to be transactional, with minimal touchpoints beyond commissions payments from carrier to broker. But at Oscar, we see the potential for much more. By forming genuine partnerships with our brokers and agencies, we can unlock significant value for everyone involved. For brokers and agencies, working closely with carriers means access to comprehensive training, timely support, and tools that enhance their ability to serve members. For instance, we recently introduced tools that led to a ~60% reduction in misaligned brokers to agencies, allowing agencies to focus more on training and supporting their brokers, who can then dedicate more time to assisting members (stay tuned for more details!). For carriers, these partnerships translate into higher member satisfaction, better retention rates, and a stronger acquisition pipeline.

We have a dedicated team at Oscar that’s focused on developing the technology that supports broker and carrier relationships. The broker technology team believes that by providing brokers with better tools and leveraging Oscar’s technological strengths, we can foster stronger relationships and enable brokers to achieve the best outcomes for Oscar members. This includes selecting the most suitable plans, ensuring continuous coverage, and helping members navigate the complex health system effectively. We offer brokers a user-centric book of business, a streamlined quoting and enrollment process, and the ability to easily pay bills on behalf of members. Our approach to working with brokers is collaborative, combining quantitative and qualitative user and market insights to enhance the broker experience. We’ve been able to build this partnership through several initiatives, including:

• Regular meetings with agencies and brokers to understand their biggest pain points
• Annual survey feedback for all of our brokers
• Ad-hoc user interviews for user testing new features
• A/B testing to determine the best user experience

Our consistent research efforts have surfaced shared goals between Oscar and our partners — ensuring a high-quality member experience, focus on retention, and providing access to the best plans. These goals align perfectly with Oscar Health’s mission to make health insurance simple, transparent, and human.

For example, through market and user research, we identified a significant pain point for agencies and brokers: the correct association (or alignment) of brokers with their respective agencies. Even when brokers were correctly aligned, agencies often struggled to determine which brokers were ready to sell Oscar plans. These issues led to wasted administrative overhead on reporting and re-aligning brokers — time that could be better spent assisting members. We validated these pain points with data from our system, which showed a high volume of requests for brokers to realign with agencies due to initial misalignments.

To address these issues, we developed tools to fill these gaps. Some of the features we released include readiness reporting, invitation links, and an improved agency alignment process. Readiness reporting allows agencies to view and report on which of their brokers are ready to sell and are correctly aligned with their agency. Invitation links and the revamped agency alignment process enable brokers to efficiently and accurately align with their agencies. From these launches we saw the aforementioned 60% reduction in misaligned brokers to agencies.

In another round of qualitative interviews with our brokers, we learned that one of the biggest gaps in the market is carrier tooling that helps brokers retain their members. From the perspective of broker technology, this represents the next major advancement in the carrier-broker relationship. To test our theory, we initiated early pilot programs where we automated emails to brokers, alerting them to members at risk of churning due to unpaid monthly premiums. Additionally, we sent communications to members on behalf of brokers, encouraging them to create accounts and enable autopay. Among the test cohorts, these pilots resulted in approximately a 3% increase in members with on-time bill payments and a 7% increase in autopay enablement. Given the success of these early pilots, we believe now is the opportune time to deepen our relationship with brokers and further invest in retention-focused features for them.

We are excited to offer a preview of upcoming features aimed at helping brokers and agencies improve member retention and engagement. Our new tools will provide brokers and agencies with deeper insights into their book of business, including identifying members at risk of not renewing and brokers who may need assistance in ensuring their members pay their bills on time. Additionally, brokers will have the ability to schedule emails to remind their members of important actions, such as enabling autopay, reviewing their upcoming plans, and paying their bills.

A strong broker-carrier relationship is essential for delivering exceptional service to members and Oscar is committed to fostering these collaborative partnerships. We invite brokers and agencies to engage with us and take part in our mission to transform health insurance with Oscar Magic.

Tech-Driven Partnerships: How Oscar Health Empowers Brokers and Agencies was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In part 1, we covered the problem space of a claims system, how there is a large amount of complex logic that needs to be implemented and our system design objectives for tackling this problem space and providing a unique value to our members and providers. In part 2, we are peeling back the curtains on the details of our architecture, implementation and roll-out.

System Architecture

Below is a diagram of the overall new claims system architecture comprising the different layers. The UIs are the user interfaces into the system, the storage layer shows the major databases and files storage, and the main logic and system components are in the services layer with associated key dependencies. Finally, none of it works without the infrastructure layer comprising the OSs, networks, containers, orchestration, compute, storage, etc. in the cloud. This is a very high level overview to highlight the major components and provide reference for the below details.

The system is designed as a flexible processing pipelined architecture. Given the requirement to support multiple product lines and use cases, the architecture must provide flexibility for the set of functions and configuration of those functions on a per claim basis in the form of an execution plan per claim. Furthermore, this pushes the system to be stateless. A stateless architecture allows a claim to be adjudicated or re-adjudicated at any time for any reason where updates are atomic.

A stateless architecture has many advantages, but there can be downside if the pipeline stages are asynchronous in exploding the number of error conditions. We therefore built a synchronous pipeline where every claim is processed across all configured stages and then updated atomically. If something breaks during execution, a claim can just be adjudicated again. This is a critical differentiator. We don’t have 15 asynchronous processes running at different intervals, which often conflict with each other and increase processing time. This gives our system flexibility to be extensible and to add more functions over time with the least amount of impact on other stages of the pipeline.

There is significant logical complexity to manage in a claims pipeline including: the complexity of the rules, changing rules, changing contracts and fees, providers going in- and out-of-network (which can happen for all sorts of reasons), complex benefit structures to support different limits on specific services, and so on. All of this logic could be implemented directly in the platform code, but given the number of constant changes and tweaks that need to be made, we would need a large team of expensive engineers to manage it all. We need something in the middle which is a Domain Specific Language (DSL) for configuring the pipeline with a great degree of flexibility without the overhead of engineering new software. We built this DSL and added the capability to update the logic at a stage level granularity along with supporting unit test capabilities.

Given we now have a DSL, managing the system changes with minimal risk is a challenge. To address this challenge, we added the ability to shadow test any new DSL change against production claims or any test claims we specify and compare to the existing code or configuration. This ensures we don’t break something as we are making changes to the system. Additionally, the new code can be gated by date, so any changes take effect on a specific date to ensure only the right set of claims are impacted starting at a given point in time. All of this can be done a lot more efficiently, ie. less effort, with a tech savvy insurance operations team which would tend to be less expensive than a software engineering team. This allows us to test production claims against hypothetical configuration changes and see the outcome before actually applying it. This is hugely beneficial in determining the overall impact on any kind of changes, e.g. contract / pricing, new benefits, edits, etc.

As part of the architecture, tracking changes to the raw claim becomes important to explain why certain decisions were made on a claim, so we designed the data structure to store the raw claim and then all changes created by the system separately as they occurred in order to be able to identify and explain what was changed. This allows changes to be backed out and a raw claim can be adjudicated again if there were issues. Furthermore, each stage creates a trace of what changes were made and the trace is attached to the claim in the data model to reference.

In choosing a language to build the system, we considered several factors including performance, tool chains and libraries, developer familiarity, etc. and went with golang. It provides higher performance than python with the same convenience of memory management and better multithreading support. This allows the system to be more scalable and performant as we extend it over time. In addition, this is a cloud-native platform built on AWS and leveraging EKS as the container orchestrator. This provides the ability to control cost and scalability of the system in-line with the specific business needs. The system can scale up under load and then scale down when not needed. New instances can be created at the push of a button. This is a huge value if we need more environments for testing or even externalizing the system for other payers.

While we aspire to 100% auto-adjudicate, there are simply cases where we need to hold claims and review, edit, troubleshoot either for manual review or fixing issues in configuration and re-adjudicating claims. This requires a UI to support manual review and taking action on claims. We worked closely with our claims operations team and developed a best in class UI for managing and working holds. In addition, we also need UIs for controlling the configuration and testing of the system, managing and reviewing payments, and configuring provider contracts and pricing into the system. These UIs provide the lens into our overall system.

These are all the key system architecture considerations that went into building this system. Of course there are other logical complexities in adjacent functions including configuring and managing benefits for each of the product offerings and managing accumulators when considering any 3rd party delegates for specific types of claims / services, e.g. pharmacy. We had to include all of these additional dependencies to make it all work.

Implementation and Release Considerations

The methods to implement and release are quite complex. The architecture must support incremental steps to roll out new functionality and ensure that the overall integrity of claims processing is maintained. In order to address this goal, we had to build what I call a “Frankenstein” system. We had to connect our new system to the current system and shift functionality incrementally to the new system over time.

Since we rebuilt our data model with the new system, it is important to be able to synchronize the data from the current system to the new system to maintain a consistent state of a claim across the two systems. This created challenges due to the asynchronous nature of tying these 2 systems together to perform separate operations on claims, but we had to do it to control the risk. So one by one, we moved stages over to the new system and then disabled the functionality in the current system. Before moving a stage, parallel testing between the new and current system had to be performed to ensure the accuracy of the payments of the claims aligns since the configuration complexity is high.

As we went through this process, we constantly discovered new things, workflows, etc. that were built around the current system. We had many scripts running on top of the current system in order to increase auto-adjudication, but those scripts were not well documented and in some cases very brittle; hence, part of the reason to migrate to the new system. The functionality of the scripts were built into the new platform natively, so no longer a side asynchronous job running to fix some obscure corner case. Those corner cases are covered making it easier to maintain the overall reliability of the system.

In addition, deficiencies in capabilities in the current system needed to be improved, leading to an increased scope for the new system when migrating provider payment functionality. In order to reduce the risk in making these changes, we shifted the payments functionality out of the current system prior to cutting over the whole system. This added time and effort, but reduced the risk on the overall implementation and ensured higher quality.

The final set of stages are benefits determination and cost share, plus accumulators, which have the highest risk. If they are wrong, it can have a material impact on members and our business. Parallel testing was executed and monitored for a year. During that year, we also added the logic for fully managing member accumulators and the ability to perform a canary cutover market by market.

Once everything was ready, we started cutting over starting with our smallest market with the most diversity in claims. The intent was to get decent coverage in logic, payments, and documents, but have low enough volume that we could manually check every single claim before it was completed. This helped uncover configuration errors and bugs that we missed in testing. We continued this process until all markets were cut over. Overall this ensured a smooth, risk controlled cutover.

Results

We now have a world class claims processing system achieving industry-leading auto-adjudication rates around 98%. We are seeing our interest costs and adjustment rate improve steadily. The system is so flexible and fast that we can now recover from almost any issue in a very short period of time. In the wake of the Change Healthcare outage earlier this year, we were able to recover quickly and pay our providers in a timely manner. This would have been a very difficult disruption to overcome with a legacy system.

Our efforts will enable Oscar to truly deliver on our mission to deliver accessible and affordable healthcare and introduce innovative offerings that serve the varied needs of our members.

Tackling the challenge of a new claims system, Part 2 was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Oscar, we took the bold step of developing an in-house claims system with a modern architecture and a tech stack wrapped around it that provides a completely new health insurance experience for our providers and members. Very few others have had the fortitude to do this, as it is a complex undertaking with far-reaching operational implications. Perhaps this is why so many payors are still using on-prem software to process claims. Oscar’s early claims vendor implemented their system in COBOL.

So why invest in our own claims system? Years ago after exploring third party solutions, evaluating our business processes, and assessing our internal software development capabilities, we decided that building our own system was the only way to achieve a truly frictionless experience and high degree of operational flexibility/efficiency. Oscar Health is a high-tech healthcare company, not an insurance company with a tech team. We are working to disrupt U.S. healthcare for the benefit of our members and providers–and this starts with the system at the core of our operations. As our CEO Mark Bertolini puts it: “Paying claims is the jugular of the business.”

We wanted our new system to:

• Cover a wide range of logical complexity across benefit structures as well as different types of members and providers in one system,
• Unlock flexibility in how premiums (what members owe their insurance company) are paid,
• Scale to tens of millions of members with the push of a button with minimal to no administrative cost increase, and auto-adjudication rates north of 98% (industry standard is in the low 80s)…all while tightly managing our risk.
• Drive down adjustment rate / increase payment accuracy by being able to easily identify, root cause and solve problems,
• Have the capability to support real-time payment processes for future business innovations

With a system like this, we could build highly personalized plans and eventually eliminate the latency that plagues the healthcare system, which leads to costly delays for providers and stress and uncertainty for members.

For the first time, we’re pulling back the curtain on one of Oscar’s most complex development efforts, one that spanned years and touched nearly every part of our tech stack. This is a two-part article where we’ll highlight some of the more innovative things we built and share some learnings we believe are relevant for any other tech team embarking on complex and long-running initiatives, especially in healthcare. Part 1 will cover the problem space and design considerations. Part 2 will cover the architecture, implementation and roll-out.

The Constraints

The complexity of a software project is as much about the constraints as it is about the novelty of the features you’re building. In switching to a new claims system, while running a large and growing health insurance business:

• Our tolerance for errors is essentially zero — in other words, it’s critical to monitor how changes are rolled out.
• Financial controls, including any relevant data and reporting, must be preserved.
• Claims cannot cease to be processed for really any amount of time.
• Business outcomes in the new system have to be at least equivalent to (though in our case, we made many improvements on) the prior system.

The Goals

While we had many goals in this work, our simplest aspiration has been the ability to auto-adjudicate 100% of our claims. Other objectives guiding our work on this project:

• High technical performance–scalable, flexible, accurate, available.
• Modern tech stack to leverage state-of-the-art software development methods and processes for system extensibility and evolution, with the ability to plug in new technologies seamlessly.
• One system to support any insurance product type–Individual & Family Plans, including EPO, HMO, and PPO, products funded through ICHRAs (a new funding mechanism that allows businesses to cover the cost of insurance for employees who bought coverage under the Affordable Care Act), Medicare Advantage, and more.
• Near-total automation to minimize and eliminate any manual work related to claims processing, which leads to lower admin cost to process claims.
• Robust monitoring of system performance.
• Guardrails and controls to minimize risk in processing claims or making changes to the system.
• Ability to eventually externalize the system for other payers and risk-bearing entities
• Develop the system with an eye toward detecting and preventing Fraud, Waste, and Abuse.

Claims Processing Overview

There are many systems that are part of an insurance company’s “Core Administration,” but for the purposes of this article, we are going to focus on claims processing and payments.

Claims processing involves a series of steps that ultimately boil down to interpreting what services were provided at the doctor’s office based on a submitted claim, determining what a payor owes to a provider for those services, and what portion of the cost, if any, the member is responsible for:

Below is a heavily simplified run-down of the stages in claims processing:

• EDI 837: An ANSI standard specified file format that is used to submit a claim electronically; the system must receive and ingest these files for processing.
• Member Match: This process involves verifying if the claim’s member information corresponds to an eligible member. Challenges include incomplete or incorrect data; efforts are made to match the correct person to ensure provider-friendliness.
• Provider Match: This stage checks if the provider is in our system or needs to be added. Once identified, an internal provider identifier is attached as metadata to the claim for downstream processing.
• Dupe Detection: If we receive a duplicate claim, we must deny; otherwise, this can result in provider overpayments, i.e. we don’t want to pay the same claim twice.
• Network Status: Providers can be In-Network (INN), meaning we have an active contract within the dates of service of the claim, or they can be Out-of-Network (OON). Determining network status involves identifying the correct business entity and associated contract to use for payment as a Provider may have multiple contracts tied to different entities.
• Edits: Edits involve modifying claims according to specific rules to ensure compliance with industry regulations and service dates. Non-compliant claims may be denied. An example can include maximum frequency per day restrictions on a given service.
• Pricing: This stage is complex due to the large number and types of fees for services and additional terms like pricing escalators. Pricing a claim involves determining the fees based on the individual services provided and the amounts within the contract that is applicable for a given date of service.
• Prior Authorization (PA) Match: PAs are controls insurance companies implement for expensive treatments/procedures in order to protect from fraud, waste, and abuse. Oscar’s clinical staff reviews all of the details and provides a PA before the treatment or procedure occurs. When claims are processed for these cases, a PA must be matched before the claim is paid.
• Benefits determiner: The benefit determiner looks up the member’s benefits and compares against the procedure/service codes on the claim and determines if they are covered and to what extent.
• Cost Share: This stage calculates the member cost share based on their benefits and the amounts they have already paid towards their deductible and out-of-pocket maximum (OOPM). The amount of the cost share is then added into their deductible and OOPM to count towards the next claim.
• Finalize claim: Ensures all stages have been executed and the claim is in the correct state before handing-off to the payments stages.
• Interest determination: Interest penalties, which vary based on contractual and market rules, are calculated if payment deadlines are missed and added to the payment to cover the interest.
• Overpayments: Overpayments are a common industry problem and can happen for a number of reasons including incorrect system configuration or claim information. This stage detects claim adjustments, determines overpayment amounts, and recovers them by offsetting outgoing payments or requesting a check and notifying the provider.
• Payments/Doc Gen: Documents are generated either electronically as an EDI 835 or paper as an EOP (explanation of payment) which also includes the amount to collect from the member and sent to the provider along with their payment of choice whether it be ACH, paper check, or virtual credit cards. Members are also sent an EOB (explanation of benefits) that provides the details of the claims and associated payments to the provider along with any amount they owe the provider.

Again, this is a cursory “happy path” overview of a general workflow to pay a claim, but provides an idea of the complexity involved. Many other conditions are required to be covered including capitation payments for specific types of business models with providers, along with interest-only payments, as examples of a few special cases.

System Design Considerations and Objectives

This new system is a more sprawling story than simply replacing our current system. It also includes the redesign of our underlying data models and systems, related services, data flows, and fundamental operating models. An array of specific, differentiating technical design and implementation aspects either directly or indirectly enable a set of capabilities that provide Oscar feature and capability advantages over the rest of the market.

Key differentiating technical aspects:

• From-scratch implementation built by our engineers, with modern languages, libraries, etc, architected from the start for SOA (service-oriented architecture) and cloud deployment
• Modular architecture, where core services can be directly leveraged by all processes and not just for claims processing
• Central data models for providers and members that directly support Search, Ops and Members views, pipeline ingestion, *and* claims processing, with clean mapping to analytics views for Risk, ML and reporting
• New Domain-Specific Language (DSL) for expressing pricing, eligibility rules, plan details, etc that provides expressive power to non-programmers, and a human-friendly view into execution results such as exactly how a given claim was priced
• Temporal stores for both core data and DSL
• High-performance stream-based claims processing pipeline, designed to enable what-if and “prospective” processing of claims
• Designed-in pipeline hooks and checkpoints enabling us to “plug in” arbitrary claims-checking logic and models
• Integrated incremental and batch claims-processing test capabilities
• Leading-edge matching technology enabling automated processing of information that is typically brittle and error-prone, driving considerable manual intervention

We see each of these aspects as differentiating within the industry, and each provides specific advantages and capabilities for Oscar going forward. The above design criteria are chosen specifically to support the following classes of capabilities, which exceed the current industry state of the art:

Enable real-time claims operations

Examples:

• Dynamic claims processing for point of sale integrations
• Counterfactual adjudication to test contracts and benefits on a broad scale against a golden set of claims
• React immediately to fraud, waste, and abuse signals
• Supported by: Modular architecture, Temporal stores, High-performance, matching technology, DSL, pipeline hooks

Provide enhanced visibility into claims and benefits processing

Examples:

• Produce accurate cost estimates based on actual member plans and provider contracts
• Detailed adjudication tracing in order to precisely analyze the conditions that caused a claim or benefit to adjudicate or pay out the way it did
• Benefit explication for explaining what is covered and under what conditions and enabling members and service reps to make more educated decisions about benefit changes
• Supported by: DSL, Modular architecture, Temporal stores, High-performance, test capabilities

Provide a unified analytics store

Examples:

• Production and analytics data kept in sync reliably, consistently, and with low latency. Actuarial analyses and production claims processing are consistent
• Time machine analytics for historic queries and report generation
• Supported by: Central data models, Modular architecture, Temporal stores

Ancillary benefits to having rewritten the stack ourselves

Examples:

• No “black box” areas of code that no one in-house understands (as you see at the larger health insurers with legacy systems)
• Modularized code has been designed for our operating environment and can be leveraged directly for services other than straight claims processing
• Code is cleaner, well-tested, and designed for extensibility
• Supported by: Modular architecture, Temporal stores, High-performance, matching technology

Part 1 Summary

In part 1, we covered the problem space of a claims system, how there is a large amount of complex logic that needs to be implemented and our system design objectives for tackling this problem space and providing a unique value to our members and providers. In part 2, we’ll cover the details of how we implemented this system and rolled it out.

Tackling the challenge of a new claims system, Part 1 was originally published in Oscar Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.