Category: Blog

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

By Michael Levin, Co-founder and CEO, Vericred

A lot runs through your mind when you complete a Series B round of funding totaling $22.7 million. 

Two obvious feelings, for sure: pride and humility. 

Pride, because the round, which was oversubscribed, took less than three months—half the time we expected—and included monetary votes of confidence from four new investors (Aquiline Technology Growth, Echo Health Ventures, MassMutual Ventures, and Guardian Strategic Ventures) as well as three existing ones (Riverside Acceleration Capital, First Health Capital Partners, and FCA Venture Partners). It’s the ideal mix of strategic and venture capital partners. If we’re to be judged by the company we keep, we like our chances.

Humility, because we learned a lot about business and our industry from the fundraising process, even from those investors who passed on this round. There’s nothing like having dozens of microscopes focused on you, each with its own lens through which to view your decisions and theories. Humility also because we now feel even more pressure to keep delivering on our accumulating successes and evolving promise. We’ll use this new capital to expand our operational teams in New York City and Omaha, and to beef up our marketing and sales functions throughout the country. We don’t take a dollar of revenue—existing or new—for granted. 

But, if I’m leveling with you, what I’m also feeling right now is optimism and impatience. 

Optimism, because the vision that’s driven us from the beginning continues to prove its merit, producing real accomplishments and genuine approbation from stakeholders that matter. 

We are, all of us at Vericred, unapologetic benefit geeks who love a good API. And we started our infrastructure-as-a-service platform because we knew that the health insurance and benefits industry was about to enter a new phase of digital transformation, an inevitable evolution driven by a need for the operational efficiencies that would be necessary to improve member experiences and product innovation. 

Today, thanks to our talented team, Vericred offers a full suite of APIs across medical, life, dental, vision and other lines of coverage that power quoting, enrollment, member management, and renewals on multi-carrier InsurTech and BenTech platforms.  Our goals were to simplify the complex process of exchanging data among multiple partners—and set a standard for the industry. That’s what we’ve done, and that’s what we’ll continue to do. 

One measure of Vericred’s impact on the industry is the more than 300 carriers and 100+ tech companies (and counting) that have joined our platform, a roster of heavyweights and forward thinkers that includes Cigna, Guardian, Humana, MetLife, Principal, Kaiser, Rippling, Gusto, Ease, and Namely. This momentum, along with the strategic investment participation by industry leading carriers, reflects the inevitability of what’s coming as much as it does the excellence of our execution.

But our determination to grow the community of partners on our platform is not driven solely by the desire to generate returns for investors or to bring order to a far-too-siloed business. We have always been a little (maybe a lot) obsessed with the benefits ecosystems because we believe our industry—and our industry’s ability to serve individuals and organizations—is enhanced when we are all connected, when we are speaking the same language directly to each other in the smoothest possible “dialogue.” 

When I talk about connecting I’m not just referring to the efficient transmission and translation of data that Vericred is helping to simplify. I’m referring to real-life connections between actual humans—data scientists, C-suite execs, tech mavens, operations leaders, marketing pros—across companies and sectors of the industry. 

That’s really why I’m also a little impatient after this just-completed raise. I want to make that happen, sooner than later. Which is why some of the funds will be used to launch a series of initiatives that we believe will go a long way toward building the kind of community that a healthy industry needs, one in which the transfer of knowledge is not only API to API or system to system but also person to person. 

I’ll expand on the details of Vericred’s “connectivity agenda” in the coming weeks and months, but for now I’ll just say that we believe the people in every precinct of our expanding and evolving ecosystem—carriers, technology companies, regulators, researchers—need a new way of communicating and exchanging ideas. Just as we’ve made good on the promises we’ve made so far about standardizing health insurance and benefits data, we’re equally committed to accountability when it comes to unifying our more-in-common-than-not communities.

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

Earlier this year we decided that we wanted to move our PostgreSQL database for the Vericred API from Heroku to AWS Amazon Aurora. Aurora offers higher performance, better scaling options, and more flexibility at a lower cost while still being fully managed. Aurora is also PostgreSQL compatible, so the change appeared seamless to our API and our engineers. With the help of Heroku’s Data Solution Architecture team we were able to accomplish the migration, and additionally upgrade from Postgres 9.6 to 11.6 with just a few minutes of cumulative downtime.

We decided to perform the upgrade from Postgres 9.6 to 11.6 before migrating to Aurora. We wanted to keep the number of things changing at once to a minimum and figured a major version upgrade a couple of weeks before the migration would give us ample time to iron out any issues, of which there were none. The process for upgrading the major version of PostgreSQL in Heroku was straight-forward: we brought up a follower database, waited for it to catch up to the primary database, upgraded the follower, put Vericred API into read-only mode, promoted the follower database to be the primary, and exited read-only mode. We performed the migration overnight when there was minimal activity on the API. The API was unavailable for less than five minutes while the follower was promoted to the primary database and the Heroku dynos were recycled.

On a high level, the process for migrating from Heroku to AWS Amazon Aurora was similar to upgrading major versions within Heroku: Create a new database to follow the one you want to migrate, put your API into read-only mode so the follower catches up with any new commits, promote the follower, exit read-only mode, go about your day. But there were a couple of issues that complicated matters. Heroku uses AWS hardware, but their AWS account owns the database instance, not Vericred’s. And Heroku couldn’t just give us carte blanche access to the instance. The other issue was you can’t configure an Aurora instance to follow a non-Aurora instance, you have to use something like logical replication or AWS Data Migration Service to get the data into Aurora.

To solve the first problem, that we didn’t have full control over the source database in AWS, we needed the help of Heroku’s Data Solution Architecture team. They setup a secure S3 bucket with a recent backup of our database and up-to-date WAL files. In our AWS account we setup an EC2 instance and installed PostgreSQL and a tool called Wal-E. Wal-E is a program that allows you to setup continuous archiving via a base backup and WAL files. The Wal-E documentation was great and setting up continuous archiving was fairly simple. It took several hours for Wal-E to catch up to the primary database, but when that was done, we had a read-only follower in AWS of our primary database in Heroku. Like with the major version upgrade, we put our API into read-only mode, made the follower our primary database, and recycled our application dynos. Total downtime was less than a minute.

Once the primary database was hosted in our AWS account, we had to get the data into Amazon Aurora. To do this we used AWS Data Migration Service. With DMS you define source and target databases and then define one or several tasks to move tables and rows to the target database. DMS can also validate the data is the same between the source and target after it has been migrated. We needed to migrate approximately 120 tables and they fell into one of four categories each with their own DMS task. The first criteria was whether or not the tables needed to be continuously replicated after migration, which DMS supports. About 90% of our tables get updated due to our API interacting with internal applications at Vericred. We had the luxury of temporarily turning off any services in our API that updated these tables during the migration without impacting our customers. The second consideration was whether or not a table contained a LOB column. LOB columns are types with large binary objects and can include text, JSON, JSONB and BYTEA. DMS can successfully handle LOB columns with large amounts of data using “FULL LOB MODE” but running a task in this mode severely impacts migration performance, so it’s important to segregate tables that require full LOB mode into a separate task. Migrating all the tables took about four hours. The migration of tables with LOB columns consisting of JSONB that could be several megabytes in size took up the majority of that time.

DMS migrates the tables and the data inside them, but it doesn’t migrate indices, primary keys, foreign keys, triggers, or user defined types and functions. After the data migration was complete, we had to reapply all of these by running SQL scripts we prepared ahead of time on the Aurora instance. Running all these scripts took another two and a half hours. After that was complete, we were ready to cutover to Aurora as our primary database. Again, we put the API in read-only mode, turned off continuously replication in DMS, pointed the API at the new database, and recycled the application dynos. This took less than a minute and we were back up and running.

The migration took a fair amount of planning, coordination, and testing by the engineering team, as well as some help from the experts at Heroku. But, all in all it turned out to be less painful than expected to migrate our 1TB database not only from one cloud provider to another, but from one database engine to another with almost no noticeable downtime to our customers.

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

In the first two blog posts of this series we discussed the why and the how of using Rust to speed up Ruby apps. In part three we took a look at error handling between Ruby and Rust code. Now let’s take a look at testing.

Testing Ruby Code That Calls Rust

There isn’t that much that needs to be said specifically about testing Rust code that is accessed via a Ruby app, especially unit tests. You can unit test your Rust library just like any other Rust application. You can also unit test your Ruby code as you normally would, mocking out the calls to your Rust library.

Integration tests are always a good idea, but even more so when a dynamically typed language is passing objects to a statically typed language via FFI. There are no restrictions on what type an attribute can be on a Ruby object that gets passed into a Rust library. In Rust you will need to know how to handle all the possible types your Ruby code might throw at you. Integration tests should help you catch potential type impedance issues before you start seeing panics in your production logs.

We use RSpec at Vericred as our Ruby testing framework. The only thing that made our Ruby integration tests slightly tricky was the fact that our Rust library inserts rows into our PostgreSQL database. We use the DatabaseCleaner gem to reset our database between tests. By default we use the transaction strategy which encapsulates database inserts as part of a test in a transaction that gets rolled back after the test. This doesn’t play nice when things outside of the ActiveRecord database connection insert data in the database (like a Rust library). The solution for this is straightforward, use the truncation strategy for just the tests that test the integration with our Rust library. This will ensure that data inserted by the Rust library will be present long enough for you to test it in RSpec. Just make sure the database is cleaned after the test. The maintainers of DatabaseCleaner provide a thorough example here.

Writing Tests in Rust

The documentation team at Rust can do a much better job of teaching you how to write tests in Rust than us, but we’ll quickly highlight the basics. A test function is more or less the same as any other function in Rust except the function signature doesn’t define any arguments or return types. A test function will have a #[test] annotation above it and will only be compiled and executed when you run the cargo test command. The assert and assert_eq macros are similar to expectations in RSpec in that they let you assert the code you’re testing returns correct results. Here is a basic example:

fn double_it(x: isize) -> isize {
  isize * 2
}

#[test]
fn double_it_test() {
    let result = double_it(1024);

    assert_eq!(2048, result);
}

Simple enough, right? It may not print output to the screen as pretty as RSpec, but it certainly gets the job done.

Mocking in Rust

Now let’s say our double_it function calls another function that we’d like to mock. Implementing a mocking library in a statically typed language like Rust is more complicated than a dynamic language like Ruby. Nevertheless, there are a few crates out there that can help us do the job. We currently use Mocktopus at Vericred. At the time we started implementing our Rust library it was the best option available. Mockall is a newer library that offers more features than Mocktopus and appears to be more actively developed. Be sure to check out both libraries and pick the one best suited for your needs. We’re going to take a look at an example with Mocktopus.

#![cfg_attr(test, feature(proc_macro_hygiene))]

#[cfg(test)]
use mocktopus::macros::*;

fn double_it(x: isize) -> isize {
    doubler(x)
}

#[cfg_attr(test, mockable)]
fn doubler(x: isize) -> isize {
    x * 2
}

#[cfg(test)]
use mocktopus::mocking::*;

#[test]
fn double_it_test() {
    doubler.mock_safe(|_x| {
        MockResult::Return(2048)
    });

    let result = double_it(1024);

    assert_eq!(2048, result);
}

In addition to including mocktopus you also have to enable the proc_macro_hygiene feature, which is nightly-only. While Mocktopus requires that you execute your tests using Rust nightly, your actual non-test code can still use stable. In order to mark a function (or entire module, or impl definition) mockable you conditionally set the mockable attribute using cfg_attr. Also, make sure you include mocktopus as a dev-dependency. Taking these steps will ensure that mocks will not be compiled into release builds, which would likely cause performance issues.

Using Mocktopus Across Multiple Targets

It’s not uncommon for a Rust project to include multiple targets. An example of this would be a binary target (or multiple binaries) and a lib target that creates a library imported by the binaries. What if you wanted to mock a call to a function in the library made from the binary? Unfortunately, #[cfg(test)] is not enabled for dependencies, so the above example will not work. But, we can make some simple modifications to achieve the desired effect.

First we need to make Mocktopus an optional dependency on [dependencies] instead of a plain old dependency under [dev-dependencies]. And then we’re going to add a mockable feature. Your Cargo.toml file should change from this:

[dev-dependencies]
mocktopus = "*"

to this:

[dependencies]
mocktopus = { version = "*", optional = true }

[features]
mockable = ["mocktopus"]

Next we replace the test flag passed to cfg attributes with our mockable feature like this:

#[cfg(any(feature = "mockable", mockable))]
use mocktopus::macros::*;

fn double_it(x: isize) -> isize {
    doubler(x)
}

#[cfg_attr(feature = "mockable", mockable)]
fn doubler(x: isize) -> isize {
    x * 2
}

We can enable the mocking feature with a command line flag: cargo +nightly test --features "mockable".

Hopefully, by leveraging Rust’s type system, ownership model and robust testing capabilities, you’ll be able to improve performance and stability of your Ruby apps without introducing a litany of new bugs.

As a platform business operating at the intersection of health insurance and technology, our data services support two distinct constituencies: insurance carriers and tech platforms. With COVID-19 disrupting business operations around the world, we’ve decided to check-in on how both groups of stakeholders are responding to these dynamic market conditions. Earlier this month, with an assist from AHIP, we began tracking how U.S. health insurance carriers are confronting the current national health emergency. Likewise, tech platforms in the InsurTech and employee benefits space are combating COVID-19, albeit in their own ways, leveraging their respective platforms to mitigate the outbreak’s impact on their customers.

With initiatives ranging from offering businesses free payroll and expanding telemedicine services, to helping brokers navigate unprecedented new challenges, our partners are developing an ongoing series of innovative solutions.

Here is a list of ways these tech platforms are addressing the challenges brought forth by COVID-19. If you have more information to add, or would like to be included on our list, please contact us.

HealthJoy, a benefits experience platform, announced QuickLaunch in response to the COVID-19 pandemic. The initiative allows companies to deploy telemedicine and concierge support to employees within two business days.

HR and benefits platform Zenefits is offering businesses 12 months of free payroll with an annual subscription to any of the firm’s HR software packages. Zenefits has also published several resources designed to help small and medium sized businesses navigate COVID-19, built a calculator to help employers apply for Payroll Protection Program loans, and added a feature to help employees submit COVID-related leave requests.

San Francisco-based Rippling, an employee management platform, has published a range of content for businesses, with advice on hiring and onboarding remote employees, and uncovering hidden security risks of remote work. Additionally, Rippling offered a free webinar with recommendations on how to onboard employees in the age of COVID-19.

Ease, a digital benefits administration platform serving 1,500+ agencies and 70,000+ employers, is helping brokers digitize their operations and workflows. In response to heightened demand for its BenAdmin and HR solutions, Ease is doubling both training and support to make it easier for brokers to onboard clients remotely.

With an influx of volume related to COVID-19, Teladoc, a virtual care and telehealth platform, has responded by developing FAQ documents to assist confirmed and potential coronavirus patients to receive care remotely.

Small business-focused HR and benefits platform Gusto has created an extensive COVID-19 resources page. In addition to original content, the guide includes financial and relief resources, broken down by federal program and at the state level. Gusto also reduced pricing for new customers and has partnered with lenders to help small businesses apply for the Paycheck Protection Program.

GoCo, an HR, benefits and payroll platform, created a COVID-19 section on its website that offers advice and insights for businesses and HR professionals. The company also launched a new feature to help businesses track leave requests in compliance with the Families First Coronavirus Response Act.

Take Command Health, which provides HRA solutions to employers, launched a roadmap to guide small business owners through a range of Coronavirus-related resources, legislation and relief programs.

Stride Health, an online insurance marketplace for health, dental, vision and life insurance, launched its “Independent Worker’s Guide to COVID-19,” which includes advice and support on tackling health, taxes and financial problems during the Coronavirus crisis. With several states having created Special Enrollment Periods for the uninsured, Stride Health enables users to search for affordable health plans by zip code.

National provider of employee benefits, payroll and HR services, BenefitMall, is offering two separate resources pages: one for its payroll clients and one for brokers. BenefitMall also launched a multi-part webinar series on staying safe and prepared during COVID-19.

AmWINS, an insurance brokerage with products across property, casualty and group benefits, is offering insights on how COVID-19 is transforming the insurance industry, and advice for brokers on how to assist clients during this unprecedented period.

Decisely, a benefits brokerage and HR platform for small businesses, produced for its customers a document on The Families First Coronavirus Response Act, which provides financial aid and other benefits to combat COVID-19 in the U.S.

Applied Systems, provider of cloud-based software for the insurance industry, has built a resources page that includes business continuity guides, technology support and business management recommendations.

Zywave, a technology solutions provider operating across multiple lines of insurance, is offering a COVID-19 resources center to help brokers and their clients confront the COVID-19 pandemic. Zywave’s in-house content team organized the resources into three categories: compliance, HR, and information for employees.

Mercer has created an information hub to help employers and HR professionals mitigate the many challenges emerging from COVID-19.

If you have more information to add, or would like to be included on our list, please contact us.