Author: Ideon

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

Sabre ignited innovation and transparency throughout the travel industry. Decades later, a similar business model is transforming health insurance and employee benefits

At Vericred, we’re committed to simplifying the exchange of data between health insurance and employee benefits carriers and tech companies, fostering a new era of transparency, innovation and efficiency for stakeholders throughout the health and benefits ecosystem. Accomplishing this ambitious mission is transforming how consumers, businesses, employees and brokers quote, enroll in and manage health and benefits coverage.

A similar, previous monumental shift altered an equally complex ecosystem and created a blueprint for digital vanguards like Vericred: Sabre sparked consumerization, innovation and digital efficiency throughout the travel industry. But to fully comprehend why Sabre’s business model is adaptable beyond the travel industry, it’s vital to understand the company’s 60-year evolution from inventor of a game-changing, tangible product to leaders of a digital-first platform business.

Sabre: Powering the travel industry toward consumerization

During the inaugural phase of mass passenger air travel in the late-1950s, consumers and travel agents booked flights in person at airports, ticket offices and over the phone. This inefficient, labor-intensive process was both inconvenient for passengers and susceptible to human-induced booking errors. But where there’s a problem, there’s generally an innovative, tech-powered solution waiting around the corner.

Enter, Sabre. In 1964 the company launched its airline reservation terminal: the first fully operational, automated flight inventory and booking system. The Sabre Terminal fundamentally altered the booking experience for passengers and agents, enabling them to easily quote, compare and purchase flights, while improving operational efficiency and reservation accuracy for the airlines.

Fast forward to today, and Sabre has only strengthened its position within the airline, hotel and travel industries by shifting its business model from product-focused to platform-based. Once a producer of a physical product, the Sabre Terminal, Sabre now offers the underlying infrastructure serving online travel agencies, search engines, corporations and app developers around the world. Connecting and facilitating interactions throughout this intricate web of stakeholders enables what travelers now take for granted: their ability to easily reserve hotels, flights, cars, vacations, cruises and other travel, all via simple-to-use, secure platforms.

A blueprint for digital changemakers

Sabre’s success story as a transformative intermediary between travel entities and consumers offers other digital innovators a framework for transforming their own similarly complex industries.

The key to Sabre’s decades-long success was its transition to a platform business model. Platform businesses drive value to various groups of stakeholders by facilitating exchanges — of currency, information, data, etc.— between two or more participants.

Multi-sided, scalable platforms generate greater value for its users as more participants join the platform. Therefore as more airlines and hotels partnered with Sabre, its services proved more valuable to agents, app developers and booking platforms. Conversely, as more agents, developers and platforms leveraged Sabre’s services, airlines and hotels gained additional revenue opportunities and greater efficiency in how they distribute data to downstream end users. This skillful, deliberate value generation for all of its stakeholders is what enabled Sabre to become the undisputed king of a market category of its own creation: the leading travel industry data solutions provider, entrenched as a business necessity for airlines, hotels, agents and tech companies alike.

So what have other businesses, and industries, learned from Sabre’s blueprint?

In the finance and banking industry, global payments leader Visa recently acquired fintech startup Plaid for a whopping $5.3 billion. Often described as the digital “plumbing” linking the modern financial services sector, Plaid connects consumers, app developers and banking institutions through behind-the-scenes APIs.

Just as Plaid’s and Sabre’s digital infrastructure enables innovation in the financial and travel industries, Vericred is building from the ground up APIs and data solutions that are igniting a similar digital transformation throughout the health and benefits ecosystem. Like the aforementioned companies, Vericred’s multi-sided platform empowers tech companies to develop innovative digital products and services ushering in a new era of efficiency and transparency. Whereas Sabre connects travel-related stakeholders — airlines, hotels, agents, consumers, booking platforms, app developers, car rental firms, etc. — Vericred binds together essential constituents of the health insurance and employee benefits space: insurance carriers, brokers, online insurance marketplaces, Benefits Administration and HR Solutions, consumers, businesses and employees.

By linking these essential constituents, Vericred is knocking down data and connectivity walls, enabling digital innovation to reach all corners of the health and benefits landscape.

We believe the future of health insurance is digital, frictionless, transparent and user-friendly. Just as travel and banking rely on foundational APIs to connect their ecosystems, we envision a future in which the digital distribution of health insurance and benefits will materialize with Vericred paving the way.

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

In our previous blog post we discussed why the Vericred engineering team decided to rewrite part of our API in Rust to solve some performance issues.

Setup and calling Rust code from Ruby

In order for one language to speak to another you have to use a foreign function interface (FFI). There exists an FFI gem that allows you to call dynamically-linked native libraries from Ruby code. If you’re going to be passing complex objects back and forth over the FFI boundry you’re likely better off using a library like Helix or Rutie which allow you to easily serialize and deserialize objects to pass between the two languages. Additionally, there is Rutie-Serde which combines Rutie with the power of the Serde framework to make the task even simpler. Some of the Ruby objects we had to deal with in our hotspot were nested objects that were several layers deep. We opted to use Rutie-Serde and leverage Serde’s derive macro. This allowed us to avoid manually writing any code to deserialize Ruby objects into their respective Rust structs, which saved a lot of time and likely a lot of errors.

For our tutorial we are going to create a simple Rust library that is going to take in a collection of objects from a Ruby app, perform some simple calculations in parallel outside of Ruby’s GVL, and then return a value back to Ruby. It’s going to consist of a Gemfile that just has the Rutie gem included and a main.rb file for our Ruby code.

Gemfile

gem 'rutie', '~> 0.0.3'

main.rb

The first thing we need to do is load the Rust library that we will create in a moment. If you are working with a Rails project that has a config/application.rb file you’d add this code there instead. The first parameter in the call to .new(), example_rust_lib, is the name of the Rust library we’re going to create and lib_path points to the location of the compiled library. In the call to .init() the first parameter is the c_init_method_name. This is the external entry point to your Rust library. The second parameter is the directory location of your Rust project, which in this case is just example_rust_lib. This initialization code will all make more sense as soon as we write our Rust library.

require 'rutie'
require 'securerandom'

module ExampleRubyApp
  Rutie
    .new(:example_rust_lib, lib_path: 'target/release')
    .init('Init_example_rust_lib', 'example_rust_lib')
end

Next is a class definition for the ParentRubyObjects that we’re going to pass to Rust. It consists of a number id, and an array of ChildRubyObjects which contains a string value that is set to a random string of hexidecimal digits when a new object is initialized. It’s worth noting that you don’t need to create special Ruby classes to pass to Rust. You can use existing classes, including ActiveRecord models, providing that you deserialize them properly on the Rust side.

class ParentRubyObject
  attr_reader :id, :children

  def initialize(id, children)
    @id = id
    @children = children
  end
end

class ChildRubyObject
  attr_reader :hex_value

  def initialize
    @hex_value = SecureRandom.hex
  end
end

We also have some code to generate data to send to Rust.

parent_objects = [].tap do |array|
  (1..1_000).map do |item_counter|
    id = item_counter
    children = Array.new(1000) { |_| ChildRubyObject.new }
    array << ParentRubyObject.new(id, children)
  end
end

We can now call our Rust library. You call the Rust library just as you would one written in Ruby. We pass in our array of ExampleRubyObjects and we are going to get back a number value.

calc_result = ExampleRustLib.calculate(parent_objects)
puts "The calculation result is #{calc_result}"

Let’s write some Rust…

You can place your Rust project anywhere you want in the file structure of your Ruby app. In our example we’re going to just place it in a folder called example_rust_lib off the root of our Ruby app. If you don’t have Rust installed follow the instructions here. We call cargo init to create a new Rust library.

cargo init example_rust_lib --lib

Your file structure should look something like this:

-example_ruby_app/
  -example_rust_lib/
    -Cargo.toml
    -src/
      -lib.rs
  -Gemfile
  -main.rb

Cargo.toml

The Cargo.toml file needs to be updated to include our dependencies and define two details about the library we are going to generate: its name and the crate-type which tells the compiler how to link crates. We want to create a dynamic library, so we use dylib.

[package]
name = "example_rust_lib"
version = "0.1.0"
authors = ["Edmund Kump <ekump@vericred.com>"]
edition = "2018"

[dependencies]
rayon = "1.2"
rutie = "0.5.5"
rutie-serde = "0.1.1"
serde = "1.0"
serde_derive = "1.0"

[lib]
name = "example_rust_lib"
crate-type = ["dylib"]

lib.rs

In our lib.rs file We need to include the dependencies we added to our Cargo.toml file. We include both Rutie and Rutie-Serde in our project. As you’ll see Rutie-Serde takes care of the deserialization of the Ruby objects, but we also need to deal with some Rutie objects, like Thread in our library.

#[macro_use]
extern crate rutie_serde;

use rayon::prelude::*;
use rutie::{class, Object, Thread};

use rutie_serde::rutie_serde_methods;
use serde_derive::Deserialize;

We also need to define the structs that Rutie-Serde will deserialize our Ruby objects into. The structs in our example are straightforward. Serde provides several attributes to handle more complex deserialization cases, such as renaming fields, setting default values, and making fields optional.

#[derive(Debug, Deserialize)]
pub struct ParentRubyObject {
    pub id: u64,
    pub children: Vec<ChildRubyObject>
}

#[derive(Debug, Deserialize)]
pub struct ChildRubyObject {
    pub hex_value: String
}

Next we need to call two macros. The call to the class! macro will generate structs so that we can use our Ruby class in Rust. We then call the rutie_serde_methods! macro with four parameters: The Ruby class, _itself, the Exception ruby class that will be used to instantiate any exceptions that get generated in our Rust code, and our Rust function that will be called when the methods we defined in our Init_example_rust_lib function called.

class!(ExampleRustLib);

rutie_serde_methods!(
    ExampleRustLib,
    _itself,
    ruby_class!(Exception),
    fn pub_calculate(parent_objects: Vec<ParentRubyObject>) -> u32 {
        parent_objects
            .iter()
            .flat_map(|parent| &parent.children)
            .map(|child| {
                child
                    .hex_value
                    .chars()
                    .map(|c| c.to_digit(10).unwrap_or_else(|| 0))
                    .sum::<u32>()
            })
        .sum()
    }
);

The calculation being performed in pub_calculate() is fairly simple and is just for illustrative purposes. We aren’t going to dive into how to write Rust code, but we’ll quickly highlight what’s going on here. The “calculation” being performed is to sum the value of all characters in the hex_value field that are valid base-10 numbers. For example, the sum of 2ef8c would be 10 because there are two numbers in that string: 2 and 8. We then sum this calculation for all ChildRubyObjects contained in all ParentRubyObjects. We accomplish this using provided methods for the Iterator trait like flat_map() and sum(). These methods are similar to those found in Ruby’s Enumerable mixin.

Finally, we are going to write the function that will serve as the entry point for the Ruby app to call. We need to provide the #[no_mangle] attribute on this function to tell the Rust compiler to not mangle the symbol name for the function that’s being exported so that we can actually call it from outside Rust as Init_example_rust_lib. extern “C” makes this function adhere to the C calling convention.

The name of this function needs to match the c_init_method name provided in the call to Rutie.init() in our Ruby app earlier. In the body, we define a new Rutie class called ExampleRustLib and map the calculate method that will be called in Ruby to the Rust function we defined in our rutie_serde_methods! macro above.

#[no_mangle]
pub extern "C" fn Init_example_rust_lib() {
    rutie::Class::new("ExampleRustLib", None).define(|itself| {
        itself.def_self("calculate", pub_calculate);
    });
}

Compile the library by running cargo build --release from the example_rust_lib directory and run your ruby app. You should see it print out a number. And that’s all you have to do to add Rust to your Ruby application!

If you are interested in benchmarking an analogous Ruby implementation add this to your Ruby code and see how much slower it is:

ruby_calc_result = parent_objects
                   .flat_map(&:children)
                   .sum do |child|
                     child.hex_value.split('').sum { |c| c.to_i(base=10) }
                   end

But wait there’s more…

There are two things you can do that can make your Rust code even faster. As mentioned earlier, the Ruby GVL may be contributing to performance issues. Even though we wrote our library in Rust, it’s still beholden to the Ruby GVL because a Ruby process has called it. Luckily, Rutie provides a way to execute our Rust code outside of the GVL with the Thread::call_without_gvl() function. Any code executed within the closure passed into call_without_gvl() will be executed free of interference from the GVL. As noted in the Rutie documentation, it’s important that you don’t interact with any Ruby objects while the GVL is released. Otherwise, you may encounter unknown behavior.

The second thing you can do to boost performance is to make your code multi-threaded. One of Rust’s many strongpoints is how well suited it is for concurrent and parallel programming. We’re going to use Rayon an easy to use, yet powerful parallelism library. To capture the maximum performance gains possible from running code in parallel you’ll want to do so outside of the GVL.

Let’s update our pub_calculate() function to run our calculation in parallel and outside of the GVL.

rutie_serde_methods!(
    ExampleRustLib,
    _itself,
    ruby_class!(Exception),
    fn pub_calculate(parent_objects: Vec<ParentRubyObject>) -> u32 {
        Thread::call_without_gvl(
            move || {
                parent_objects
                    .par_iter()
                    .flat_map(|parent| &parent.children)
                    .map(|child| {
                        child.hex_value
                            .chars()
                            .map(|c| c.to_digit(10).unwrap_or_else(|| 0))
                            .sum::<u32>()
                    })
                    .sum()
            },
            Some(|| {})
        )
    }
);

You’ll note that very little changed. Our original calculation code is now inside of a closure that’s passed to Thread::call_without_gvl() and parent_objects.iter() was changed to parent_object.par_iter(). Our example code won’t run much faster when executed in parallel outside the GVL. But given a more complex real-life scenario where your Ruby app is running on hardware under load inside a web server like Puma you would very likely see meaningful performance gains.

Hopefully this tutorial was helpful. In future blog posts we’re going to cover testing, error handling, and persisting to a database in Rust libraries that are being executed inside of Ruby apps.

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

A few months ago the engineering team here at Vericred noticed some severe performance issues in one of our API endpoints written in Ruby on Rails. We isolated the problem to a specific piece of code that we felt would be a good candidate to be rewritten in Rust and it worked out great! We were able to reduce execution time by over 98% with virtually zero regression bugs in the new code. Over the next few blog posts we’re going to share why we decided to use Rust, how to integrate Rust into an existing Ruby codebase, and how executing code outside of Ruby’s GVL can improve performance.

Introducing a New Language To Your Team

The topic of how to introduce a new language to an engineering organization successfully is a complex topic in and of itself. For more information on introducing Rust to an organization check out Ashley Williams’ talk on introducing Rust at NPM.

Why Rust?

Vericred’s API, as well as the majority of our internal tools, are built with Ruby on Rails. This fits our needs most of the time. Ruby is an easy language to work with and the ecosystem of tools like Rails, ActiveRecord, and RSpec allow our engineering team to quickly and reliably deliver new features to our customers. But, Ruby isn’t necessarily the best option when you’re dealing with large amounts of data, or when you need things to be fast. What we gain in engineer productivity we potentially lose with performance. This is usually an acceptable trade-off, but we needed something for when speed was the priority.

Rust stood out to us as an excellent complement to Ruby for several reasons:

1. It excels in areas where Ruby is lacking. Namely, performance, parallelization, and memory utilization.
2. It’s almost the opposite of Ruby: It’s type-safe, natively compiled, and doesn’t have a garbage collector. Adding Rust to our tech stack would truly diversify it.
3. Despite being so different from Ruby it doesn’t feel foreign to work with. While it isn’t as easy to ramp up as Ruby, Rust is a modern language that puts great emphasis on ergonomics. You also don’t have to trade away memory and concurrency safety to achieve performance gains.
4. It has excellent support for extending Ruby code via FFI.

Of course, knowing that Rust can be a good addition to your engineering team’s toolbox and knowing when it’s the right tool for the job are two different things.

When to Use Rust

It’s important to understand why your code isn’t performing well enough in order to determine if Rust can help solve your problems. For example, if the root of your problem is slow database queries, Rust isn’t going to be much help. What made Rust a compelling choice for our specific hotspot was that it was a task that should execute significantly faster in parallel. We needed to perform several hundred independent calculations and return a collection of objects that would persist to a database. Yet, when we tried to parallelize the work in Ruby we saw only miniscule improvements. We believe the primary culprit was Ruby’s Global VM Lock (sometimes referred to as Global Interpreter lock) and thread contention. We are going to discuss the GVL in greater detail in a future post but to put it simply, the GVL only allows one thread to execute at a time. To make matters even worse, our API runs in Puma, the concurrent web-server. So our code was not only in contention with itself, but threads serving other requests.

To solve our problem, we needed three things:

1. To be able to execute our calculations faster than our current Ruby code.
2. To be able to execute our code free of the Ruby GVL.
3. To be able to truly parallelize our code and leverage all the CPU cores available to our server.

We were pretty confident that Rust could accomplish this. In our next post we explore how to use Rust within your existing Ruby app.

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

New to Health Reimbursement Arrangements (HRA)? Check out our recent blog to better understand HRA basics and learn what’s changing in 2020.

In our ongoing VeriStat blog series on Health Reimbursement Arrangements (HRA), we’re examining how a new type of HRA — the Individual Coverage HRA (ICHRA) — could alter the health insurance options for businesses and employees in 2020. According to White House estimates, ICHRA regulations are expected to transition millions of employees from traditional, employer-managed group health insurance plans to individual market plans.

Thus far, we’ve analyzed how monthly premiums in the individual market compare with small group premiums and identified counties where employees — if shifted to the individual market — would have access to the plan types they may be accustomed to in the group market. This information can enable employers to make well-informed benefits decisions that best fit their and their employees’ needs.

Recognizable Group Carriers

Another factor that employers may want to consider is whether their employees will be able to purchase individual coverage from recognizable brands. The four largest U.S. insurance brands by market share — Aetna, Blue Cross Blue Shield Association member carriers, Cigna and UnitedHealthcare — likely have national name recognition with employees. The data science team at Vericred investigated where these brands actively sell plans on the individual market and found that at least one of the above four offers plans in 74 percent of U.S. counties, with Blue Cross Blue Shield carriers accounting for most of this participation.

CVS Aetna, among the most recognizable health insurance brands, offers plans in the employer market, but no longer actively participates in the individual market.

Blue Cross Blue Shield Association member carriers are the most active of four national carriers in the individual market offering individual plans across nearly every state. These Blue Cross Blue Shield carriers also offer small and large group plans.

Cigna offers individual plans in seven states, generally in a small number of counties in and around high-population metropolitan areas. In 2020, Cigna is expanding its individual market presence into metro areas in three additional states: Florida, Utah and Kansas.

UnitedHealthcare, like Aetna, no longer actively participates in the individual market, but the insurer has discussed the possibility of adding more individual plans targeted at the ICHRA audience.

“We’re supportive of the expansion of the HRA and the ways in which they’re used broadly,” UnitedHealthcare’s CEO, David Wichmann, said during the company’s Q3 2019 earnings call. “I suspect that there may be some migration towards more individual offerings. I wouldn’t suggest that that would be prevalent, but to the extent that there are, I think, our company is well-positioned to be able to offer affordable coverages for people in the commercial individual space.”

New Brands are Emerging

While employees may take comfort in coverages from the well-established brands noted above, new recognizable brands are emerging in the individual market.  Ambetter (Centene), Bright and Oscar are aggressively marketing themselves as a new generation of health insurance carrier. Younger employees in particular may be less loyal to the four national brands, embracing these new carriers.

Employers should consider how important name recognition is for their employees, as many of the carriers with the largest employer market share have minimal participation in the individual market.

ICHRAs present another employer-sponsored health insurance option, but in order for businesses to make the best decision for their employees, InsurTech and HR platforms must provide decision support tools that assist them through this complicated determination.  As the only data platform partnered with hundreds of health insurance carriers serving both the group and individual markets, Vericred is uniquely positioned to help tech companies, and their customers, capitalize on changes to HRA regulations. Contact sales@vericred.com to learn how Vericred can support digital ICHRA solutions.

Interested in building digital solutions for the ICHRA market? Vericred recently published a digital toolkit, in which you’ll find resources on how ICHRA works, in-depth industry analysis, and use cases for creating solutions utilizing Vericred’s HRA Development Kit. If you are interested in learning more about Vericred, please contact us.

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

New to Health Reimbursement Arrangements (HRA)? Check out our recent blog to better understand HRA basics and learn what’s changing in 2020.

In our ongoing VeriStat blog series on Health Reimbursement Arrangements (HRA), we’re examining how a new type of HRA — the Individual Coverage HRA (ICHRA) — could alter health insurance options for businesses and their employees in 2020. According to White House estimates, ICHRA regulations are expected to transition millions of employees from traditional, employer-managed group health insurance plans to individual market plans.

Our first VeriStat analyzed how monthly premiums in the individual market compare with small group premiums, and identified states where employees could potentially benefit by switching to the individual market from their current small group coverage. This crucial information enables employers to make cost-effective benefits decisions that best suit their and their employees’ needs.

However, the individual market differs from the small and large group markets in more than just premiums. There are differences in plan design and networks that employers may wish to consider when evaluating whether an ICHRA is right for them and their employees. The majority of employer-sponsored coverage offered is PPO (preferred provider organization) or POS (point of service) plans, but these are less common in the individual market. PPO and POS plans offer some degree of out-of-network coverage, whereas HMO (health maintenance organization) and EPO (exclusive provider organization) plans generally do not.

Vericred’s data science team analyzed, at the county level, where an employee switching to the individual market would have available to them at least one PPO or POS plan.

The results show that individual market PPO or POS plans are available in only 40 percent of counties and are more commonly offered in certain states:

• 22 states have PPO/POS plans available in every county
• 20 states have PPO/POS plans available in some counties
• 9 states have no PPO/POS plans in any county

Employers considering switching to an ICHRA should evaluate what plan types are offered in the individual market in their geographic area and the importance of out-of-network benefits to their employees.

Our next article in this VeriStat series on ICHRAs examines, again at the county and state levels, where the largest health insurance carriers sell plans in the individual ACA market.

Interested in building digital solutions for the ICHRA market? Vericred recently published a digital toolkit, in which you’ll find resources on how ICHRA works, in-depth industry analysis, and use cases for creating solutions utilizing Vericred’s HRA Development Kit. If you are interested in learning more about Vericred, please contact us.

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

On Oct. 24, Vericred was recognized as an InsurTech100 company for the second consecutive year. The annual list, compiled by specialist research firm FinTech Global and a panel of industry experts, named Vericred among the world’s leading technology companies driving digital transformation, cost savings and greater efficiency in the insurance industry.

“Vericred’s inclusion in the InsurTech100 is a powerful testament to the value we deliver both to insurance carriers and tech companies — online insurance marketplaces, quoting systems and BenAdmin and HR platforms,” said Michael Levin, Vericred’s co-founder and CEO. “The digital revolution has reached all corners of the health insurance and employee benefits space. This accolade validates our central role as a facilitator of innovation throughout the industry’s ecosystem of carriers, brokers, InsurTech platforms, employers, and other stakeholders.”

This year’s InsurTech100 companies were analyzed on a range of criteria:

• Industry significance of the problem being solved
• Growth, in terms of capital raised, revenue, customer traction
• Innovation of technology solution
• Potential cost savings, efficiency improvement, impact on the value chain and/or revenue enhancements generated for clients
• The importance of insurance executives knowing about the company.

“It is imperative that established insurance companies become aware of the latest innovations in the industry in order to be able to compete today in a market that is heavily focused on digital distribution,” Richard Sachar, director of FinTech Global, said in a press release. “The InsurTech100 list helps them do just that and to identify new business models which will have lasting impact on the industry.”

Vericred is building digital infrastructure for the distribution and fulfillment of health insurance and employee benefits. The Vericred Platform serves as a data translation layer between insurance carriers and technology companies that are transforming the way health insurance and employee benefits are quoted, sold, enrolled and managed. Vericred offers robust solutions for technology companies focused on the employer market, as well as the under 65 individual, Medicaid and Medicare markets.

For more information about Vericred’s data solutions, please contact sales@vericred.com.

**Ideon is the company formerly known as Vericred. Vericred began operating as Ideon on May 18, 2022.**

Health Reimbursement Arrangements (HRAs), an employer-funded benefits option since the 1970s, will undergo an extensive transformation beginning in January 2020. In this blog, we’ll review how changes to the HRA environment could have significant implications for the group and individual health insurance markets and on employees’ health plan choices.

What is an HRA?

An HRA is a type of benefits arrangement in which employers reimburse employees for health insurance expenses like monthly premiums, deductibles, and out-of-pocket medical costs. Both sides of this agreement receive tax benefits, as businesses can claim a tax deduction for the reimbursements and employees are reimbursed for eligible expenses tax-free.

What’s the relationship between traditional group plans and HRAs?

Traditionally, most businesses that offer health benefits select one or several insurance plans in which employees may enroll. However, for those companies that want to sponsor health coverage for their employees without managing and administering the benefit themselves, HRAs represent an appealing alternative. Instead of employers shopping for plans, enrolling members and handling other health insurance-related tasks, most of these responsibilities would fall upon individual employees. HRAs permit each employee to make the best health insurance decisions for their specific requirements, while businesses simply provide reimbursements for qualified expenses. Most employers choose to offer either a group health plan or an HRA option– but not both.

Different Types of HRAs and what’s changing in 2020

Qualified Small Employer Health Reimbursement Arrangement (QSEHRA): Since 2017, small businesses — those with less than 50 employees — can offer HRAs that reimburse their employees for premiums and eligible healthcare expenses. These HRAs have contribution limits — $5,000 for an individual and $10,000 for a family — must offer all employee classes the same terms and cannot be used for ancillary benefits like dental, vision, etc.

Individual Coverage Health Reimbursement Arrangement (ICHRA): In June 2019, the Trump administration finalized new HRA rules that will create two new types of HRAs for 2020. ICHRA, like QSEHRA, will enable businesses to reimburse employees for premiums and other qualified expenses, but there are key differences between the two. ICHRA regulations include the following core features:

• businesses of any size will be eligible to offer ICHRAs.
• no restrictions on the annual amount employers may reimburse employees.
• businesses may offer varying terms, and reimbursement allotments, to different employee classes (such as full-time, part-time, seasonal, non-salaried, etc.).
• ICHRAs enable large employers to fulfill the Affordable Care Act’s employer mandate, which requires them to offer affordable, minimum essential health coverage to at least 95 percent of their full-time employees.
• ICHRA terms must remain uniform among employees of the same class, except that businesses may alter allotments based on the employee’s age or the number of dependents. ICHRA contributions, in order to satisfy the employer mandate, must provide employees an opportunity to purchase “affordable” individual market plans. According to the IRS, an ICHRA is considered affordable if “the remaining amount an employee has to pay for a self-only silver plan on the exchange is less than 9.86% of the employee’s household income.”
• ICHRA beneficiaries must maintain individual health coverage, through purchasing on-exchange or off-exchange insurance plans.

Excepted Benefit Health Reimbursement Arrangement (EBHRA): Also coming to the 2020 HRA environment are EBHRAs, another component of the recent Trump administration directive. EBHRAs allow employers to contribute up to $1,800 per year toward their employees’ expenses that are not covered by their group plan. These types of HRAs can be used to reimburse employees for expenses such as short-term insurance and dental, vision and home care, among other certified costs. Under EBHRA regulations, these employers must also offer a group health plan.

How will the new HRA landscape — particularly the arrival of ICHRA — impact employers and employees? What about HR platforms and InsurTech companies?

It’s expected that the new HRA rules, especially the availability of ICHRAs, will transform the employer-sponsored health insurance market by transitioning employees from group plans to the individual market. For employers, this lessens their administrative burden. For employees, this means more personal choice and greater control of their insurance options.

With more businesses eligible to offer HRAs, it’s likely the individual market will grow substantially over the next few years. And, millions of employees will experience shopping for and enrolling in on-exchange and off-exchange individual plans for the first time.

According to a U.S. Departments of Health and Human Services, Labor, and the Treasury estimate, it will take employers around five years to fully adjust to the updated rule, at which time roughly 800,000 businesses will offer ICHRAs. This, the departments’ modeling suggests, will cover about 11 million employees and family members.

The White House calculates that, as an effect of the new directive, the size of the individual market could increase by as much as 50%.

For HR and InsurTech platforms that currently support the group market, the individual market, or both, they must not only be prepared for this transition, but position themselves to thrive in this new environment. By supporting solutions for both plan types, InsurTechs can seamlessly migrate users from group plans to individual plans, therefore retaining customers who would otherwise be forced to shop elsewhere.

Interested in building digital solutions for the ICHRA market? Vericred recently published a digital toolkit, in which you’ll find resources on how ICHRA works, in-depth industry analysis, and use cases for creating solutions utilizing Vericred’s HRA Development Kit. If you are interested in learning more about Vericred, please contact us.