The headline features in version 1.9 are member matching and X12 EDI 837 claims loading. Other improvements include a provider system of record (in preparation for future provider matching), address parsing and normalization (in support of member and provider matching), improved telemetry (to help us better solve performance issues), reporting lookup data improvements, extractor improvements, and the first step towards deploying the METL website publicly.
Member matching
Humans are complicated. We move from one place to another. We change our last and first names. We change gender markers. Not only that, but trading partners routinely make errors entering member information. So, we even see changes in date of birth, member IDs, and Social Security Numbers. Because of this, member matching requires a considerable amount of fuzzy matching. While humans are really good at fuzzy matching, computers, in general, are not. v1.9 introduces automated and human-assisted member matching that seeks to identify a human being, even across multiple trading partners. Member matching will track me across all of these sorts of scenarios, and many more:
- I change employers and my new employer happens to use the same TPA as my old employer. I'll get a new member identification code on my insurance card, but the records will be merged into a single canonical member.
- I have insurance from my employer and also through my spouse's insurance at the same time. Even though I have two insurance plans at the same time, both will show as the same canonical member ID.
- I change my name and address, but have the same SSN.
Automated matching is a rules-based algorithm that matches members together when there is a high degree of confidence that they are the same. In our testing, we can automatically handle about 97% of cases, and humans need to review the remaining 3%. This is a critical capability to enable a bunch of use cases we have plans for in the future including member-level reporting and risk analysis, member-specific data access (in a future member UI) and much more.
X12 EDI 837 claims data loading and repricing
We're excited to be able to bring X12 EDI 837 claims data loading and repricing to METL. This is an alpha release and is being tested internally, but will launch publicly later this year. The X12 EDI specification makes it possible for us to load data from multiple trading partners without managing a whole host of data import scripts for each TPA. And, since the X12 format is the HIPAA standard, it's the most ubiquitous format for healthcare claims data. v1.9 brings the capability to load this to the database and adds the data tables necessary to store all the repricing benchmark data that My Price Health supplies to customers in their API. In a future release, licensed X12 customers will be able to load X12 data directly to the database. For customers that want their data repriced to a contract or using some other methodology, METL will call the My Price Health API to reprice the data automatically on load.
This is our first METL plug-in that brings enhanced functionality to the platform for licensed users. Licensed users will not need to send their data off through SFTP to have this work performed for them, but METL will orchestrate the work directly in the METL platform. We're excited to use this same model for other METL plugins in the future. We believe this can greatly speed up claims processing and payment.
Supporting improvements
Provider System of Record
We are continuing our work to enable provider matching. This is a similar problem as the aforementioned member matching problem, but for healthcare providers. To begin with, we're building a system of record of healthcare providers. We're merging together multiple data sources to create a single master record for providers. We expect to continue to add additional data sources to this over time, but this release brings us new or updated data from these sources:
- NPI registry
- PECOS enrollment
- Doctors & Clinicians National Downloadable File
Address parsing and normalization
One of the challenges of fuzzy matching for providers and members is that addresses are messy. For example, all of these are the same address:
- 1234 West Main Street Apartment 6B
- 1234 W Main Apt #6B
- 1234 W Main St Apt 6B
We've tried out a handful of address matching tools over the years. We then wrote our own when none of the tools we found were perfect. The focus of our address parsing and normalization tool was to be fast and simple. It first attempts to parse an address, and then it attempts to normalize it. If all goes well, all the above address variations above (and more) end up in the database as a single canonical address.
Reporting data lookup tables
We're adding additional data to support reporting and analysis including:
- Procedure code lookup improvements
- Procedure code group fallback
- HCUP diagnosis chronic condition indicators
Improved telemetry
We ran into several performance issues with member matching once we ran it on a large database. To sort the issues out, we added telemetry in AWS and in the database to make it easier to track down the issues.
We made a few improvements to extractor and csvloader to support optional loads. This is important since not all columns are always present, and not all files are present to load either. This gives us the flexibility we need for input files that change over time.
