METL now understands what your data is — not just what your file says it is. We also took our first step towards building an extractor template for you automatically. v1.17 also brought Transparency in Coverage data into the database and loaded our first network's TiC data.

New Features and Improvements​

Automatic template building​

Automatic template building takes its next big step with v1.17.

There are 2 capabilities to support this:

Data type analysis. The new dataType package reads the actual values in every column and classifies them into one of 30+ kinds — dates, NPIs, HCPCS and revenue codes, diagnosis codes, DRGs, NDCs, tax IDs, ZIPs, cities, first and last names, organization names, phone numbers, email addresses, addresses, and more. It doesn't rely on the column header, because trading partner headers are frequently wrong, cryptic, or missing entirely. It reads the data.

Name and city detection is backed by word lists we compiled and generate into the package — roughly 150,000 given names, 162,000 surnames, and 14,000 city words. That's what lets METL tell a LAST_NAME column from an ORG_NAME column when both contain nothing but text.

Column matching. Once every column has a type, METL scores each one against every field the wizard needs to fill and picks the best assignment. The matcher weighs the detected data type, the expected header words and patterns, and handles conflicts between columns when they appear to match the same input column. We've worked hard to ensure that a file with both a billing provider NPI and a rendering provider NPI won't get them backwards.

The result is a candidate list per field, with METL's pick pre-selected. In the next release you'll be able to use the UI to pick from the list of matches instead of building from scratch.

Supporting this, we added a header pattern type to the schema, so templates can describe how to find their headers with contains, whole, start, and end anchors rather than assuming row one.

User-definable value mapping​

Trading partners describe the same thing a dozen different ways. M/F, Male/Female, 1/2 — all gender. Previously, translating those into our enums meant a code change.

v1.17 adds a new package to support user-definable value mapping. Currently, we use custom SQL scripts in csvloader to do value mapping like this. Coming in the next release, we'll update csvloader to support custom value mapping from the UI. That will allow you to define, per load, how source values map to any of 15 target enum types, including claim type, gender/sex, relationship, coverage level, marital status, employment status, insurance line, benefit status, prior authorization, unit type, and more. The mappings are validated in the database, so a mapping that names a value the enum doesn't have is rejected at write time rather than at load time.

The design distinguishes a source value mapped to NULL from a source value that matched nothing at all, which matters when you're auditing why a field came out empty.

Transparency in Coverage — and our first carrier data load with it​

In v1.16 we shipped MRF table-of-contents parsing. In v1.17 we built the rest.

The database now has a full home for Transparency in Coverage data: transparency files, plans, in-network items, negotiated rates and prices, provider groups, provider references, and NPI sets, along with the supporting enum types for billing class, negotiation arrangement, negotiated type, plan market, plan ID type, and TIN type.

Alongside the schema, we added a new anthem downloader tool. It can download and load Anthem's published machine-readable files. These files run to tens of gigabytes, so the loader handles concurrent downloads, concurrent database loading, resumable attempts, progress reporting, and filtering down to just the plan sponsors you care about.

Extractor UI​

The Extractor UI kept moving fast this release:

• A new left navigation bar, which makes the wizard feel like a real application instead of a single-page form
• Data type analysis is now surfaced in the UI, so you can see what METL detected for each column
• Support for CSV column mapping objects, so the per-column optional and useFirstMatch settings we added in v1.14 are now editable from the UI instead of only from YAML
• inputs/get now returns all templates regardless of whether they match the uploaded file, so you can start from a similar partner's template rather than from nothing
• Fixes to the data type analysis request

PHI access auditing​

We extended the audit work from v1.16 to cover uploaded file contents. Every read of an uploaded file's data is now logged with the access type — Read for raw data, Analyze for data type inference — along with which columns were touched. Data type analysis reads real PHI to do its job, so it gets logged like any other access.

Exporter​

• Added the ability to add a file header and footer for exported files

Member matching​

Group ID is now displayed in the member matching UI, on both the canonical member and candidate member tables. We also fixed a StaleReactionError that could occur on the /matching route.

Testing and Deployment​

Automatic subrepo sync​

Subrepos now sync automatically instead of drifting until someone ran it manually.

Go lints are clean​

We fixed the last of our outstanding Go lint violations. This allowed us to remove betterer from the pipeline for Go lints. The Go side of the codebase now lints without any issues.

Housekeeping​

• A fix to pkg/schedule
• Fixed a group_load case inconsistency which caused plans in the plan_match file with lowercase characters to never match
• Updated Carbon Svelte packages and a large batch of npm and Go dependencies

METL DB Release on GitHub

METL-deploy on GitHub

Since the beginning, the ETL in METL has always been about extract, transform and load. With v1.16, we're making ETL much more accessible. The Extractor UI is now read-write and we added an audit trail so you can see exactly who accessed what.

New Features and Improvements​

The Extractor UI is now read-write​

We've been promising this for a couple of releases and it's finally here. You can now create a new input template directly from the Extractor UI instead of hand-editing YAML.

The new workflow is:

1. Upload a file (or pick one that was previously uploaded — the UI now remembers).
2. METL analyzes the file and figures out the format and delimiters.
3. You review a preview of real data rows from your file.
4. You map the columns and save a brand new input template.
5. Run the database load and check the results right from the UI.
6. If there are issues with the results, delete it and re-run until you've got it right.

File analysis is one of the pieces we're most excited about over time. Eventually, we believe we'll be able to automate much of the process of mapping files. METL will make its best guess at what each column contains and you correct it from there. Our goal is to take new trading partner onboarding from months down to a few minutes. For now, we analyze the file to determine whether it is a delimited file or fixed-width and show a preview of the file.

The wizard steps are where the bulk of the work in the Extractor UI gets done today. The user is guided through the process of assigning columns in the input file to the METL database. Steps are fully configurable. This allows us to refine the steps to fill out a template to make it the easiest for users as we learn. Steps include:

• Bucket step - a big bucket where lots of related fields go together. Claims files can have hundreds of columns, so bucket steps allow us to group similar sorts of fields together. For example, we have a bucket step for all provider-related fields. We use these in a similar way as humans use piles when they are sorting a deck of cards. If you're sorting cards, you might sort by number, by suit, etc. Once you've done that sort, you'll probably sort again. This is how we use buckets for the UI.
• Map Output - This is where we assign an input column in the source file to where it belongs in the database. You might end up dragging a column named "Member Last Name" into the "claim_member.member.name_last" column in the database. Similar fields can be grouped together into tables to make it easy to find what you're looking for.
• Question - Sometimes we need to ask a question in order to know what to simplify what we show to the user in the Wizard. Question steps allow us to alter the UI based on the answer supplied
• Input form - Some things just require a person to type something in or pick something form a list of options. That's where an input form is helpful.

The Extractor UI also added a new data loads view. This allows you to load the data file that you've configured and see its status without leaving the wizard. If the results don't look like what you expected, you can delete the data from the database make the necessary fixes and run it again.

Job audit trail​

With APIs comes the responsibility to track how the data is being used. We added a new job_data_access audit log that records one row per call to the data endpoint — who called it, when, and how many rows they received. A companion job_data_access_job table records exactly which jobs each call touched.

We also continued the jobs work started in v1.15:

• job_etl now tracks when a job was queued, not just when it started
• Reloads now prefer the succeeded job when there are multiple attempts, so a retried file no longer shows up as failed
• Extracted data is cleared when the extractor fails, so a partial extract can't be loaded by mistake

MRF parsing​

We added support for parsing machine-readable file (MRF) tables of contents. Payers are required to publish their negotiated rates as MRFs under the Transparency in Coverage rule, and those files can be enormous. Parsing the table of contents is the first step toward pulling in the in-network rate files we actually care about.

Member matching​

The member matching UI can now be filtered by solution, which makes it much easier to manage a queue of members.

Behind the scenes, patient matching got significantly faster and much lighter on memory. Large matching runs that previously pushed against memory limits now complete comfortably.

Exporter​

We updated several exporter queries and fixed a deadlock that could occur when multiple exports ran at the same time.

Backend changes​

• Snapshot sorting is dramatically faster
• We removed TRUNCATE TABLE statements that were forcing unnecessary table locks
• We switched to statement_timestamp() where transaction-level timestamps were giving misleading results
• Our test suite and build-dbs are both faster, thanks to better caching

View improvements​

• member_eligibility_current_view — previously we took the single latest eligibility submission per trading partner. Several partners send multiple independent eligibility files (e.g. one per group ID), and taking only the newest file meant the other groups were silently dropped. The view now recognizes the file "version" in the filename and keeps the latest submission for each version.
• member_coverage_view — switched the plan sponsor joins from INNER JOIN to LEFT OUTER JOIN. Members without a plan sponsor match were being dropped from the view entirely.

Bug fixes​

• Fixed an 834 parse error
• Fixed a Svelte LSP crash that was slowing down frontend development

Testing and Deployment​

Atlas lints in Betterer​

Our Atlas database lints now run through Betterer alongside the rest of our linting. That means schema issues are caught and tracked the same way as everything else in the codebase. Betterer helps us to continually reduce the number of lint violations over time instead of letting them sit. Database lints include things like ensuring each table has a foreign key, every column and every table has a comment, etc.

Dependency updates​

We updated Carbon Components Svelte to the latest version.

METL DB Release on GitHub

METL-deploy on GitHub

Our June release turned into a much bigger release than we anticipated.

New Features and Improvements​

Exporter Service​

The Exporter Service is a new service that allows data export from the database in a variety of formats. The initial version of the Exporter Service supports exporting claims data in CSV format, but we have plans to expand the capabilities of the Exporter Service in future releases. The Exporter Service is designed to be flexible and extensible, so we can easily add new export formats and new data types in the future.

The Exporter service ships with a new scheduler which allows us to schedule exports on a daily, weekly, monthly, or various other time windows. If you've ever worked with a cron job on a 'nix system, you'll be very familiar with the scheduling flexibility.

The data that is exported is only limited by your SQL querying skills. If it can be queried in SQL, it can be exported. This is the natural bookend to the load wizard we've been working on and makes it just as easy to get data out as it is to get it into METL.

The UI for the Exporter will be coming in a future release.

Scheduler Service​

As a part of the launch of the Exporter Service, we've added a new scheduler service. This will allow us to schedule regular tasks. It's being used to schedule Exports, but we'll soon be switching our jobs such as database backups, file reload tasks and more to the scheduler service. This will allow us to build in more and more automation right into the METL platform. Previously, we were relying on cloud task automation to accomplish this, but now it'll be built directly into METL for greater flexibility to end users.

The UI for the Scheduler will be coming in a future release.

Extractor UI​

The Extractor UI got some more polish this release and more capability to prepare it for editing. This included improved and more consistent error handling, cleanup to make it look more polished, and moving all the UI capabilities in extractor UI into individual components for easier maintainability. We're excited to add editing capability to the July release.

AI additions​

This release marks our first steps into AI development. We added our project-level configuration, added several Claude Skills and dove head first into AI development. We found some efficiencies in the process and lots of drawbacks to the process. We had at least 2 weeks of delays this release as we worked to adjust the code to our style. In general, coding went marginally faster, but review went significantly slower than prior releases. We expect to see this continually improve as we adjust to the new paradigm of development.

Web UI updates​

We improved Patient matching API performance.

Jobs redesign​

One of the consistent pieces of feedback we've received is that the METL UI needs to make more information available about the status of data loads. If a file is dropped in that doesn't match a regex, nothing is ever shown in the UI. With v1.15 we've completely redesigned the way we log information. Everything does not have to be associated with a "release" record (and ultimately load to the database). This allows us to log every time something happens with extractor and csvloader, even if they fail in unexpected ways.

In a subsequent release, we will introduce updates to the jobs UI for 3 different use cases:

1. The lowest level view providing a list of all jobs of any type occurring in the database in an auto-updating stream. This includes ETL jobs like extractor and csvloader, but it also includes exporter jobs as well as HTTP and any future type of job we add support for. This will be the UI to use for seeing a running view of everything happening for up-to-the minute troubleshooting.
2. A medium-detail view of jobs grouped by ETL jobs. This is the current view in the jobs UI.
3. A higher level jobs dashboard. This will make it possible to see multiple instances of jobs grouped together in a clean dashboard showing the status of each group. For example, if there have been 100 loads run for "ABC TPA Claims", you'll see a single card with "ABC TPA Claims" that shows Green if all 100 jobs have been successful. If any file for "ABC TPA Claims" didn't succeed, the card would be red. If there are jobs waiting to complete for "ABC TPA Claims" it would be yellow. That way, at a glance you can see what's happening per load without having to drill-down. We expect it will make it much easier to quickly see what's happening across a large list of load, export, and other types of jobs.

New data loads - adding prescription drugs!​

We added several new data loads this release, and also added our first data load for prescription drugs. We're excited to have full support for prescription drugs and expect to add many new loads in the future.

View improvements​

• line_item_reporting_view - added date_of_birth and medical_plan_name

Repricing improvements​

We continue to add new capabilities to our My Price Health repricing engine for our enterprise clients. New capabilities include:

• Better support for modifiers and provider types
• Inpatient CBSA fallbacks

METL DB Release on GitHub

METL-deploy on GitHub

Our April release is a big release and includes capabilities throughout the codebase. We've got brand new capabilities like our Provider System of Record, our new METL Domain Specific Language, our new Rx Data loading wizard and the Extractor Wizard UI, and big improvements to our Claims UI to make it generally available.

New Features and Improvements​

Claims UI is generally available​

We're excited to make the Claims UI generally available with METL 1.14. Improvements include a vastly faster API to fetch claims, a global search that allows you to find any claim in the database, and much more.

New capabilities include:

• Select which claim statuses to see in your queue
• Different edit capability for each status
• Global search in the top navbar (click the magnifying glass) to search for any claim in the database
• Fixes to the UI to support loading any claim
• Every claim now gets its own URL so it's possible to share links with co-workers
• Transparency data section now displays example data
• A dropdown allows you to view and select current or previous claim statuses
• Visual improvements to the display with insured/patient split, provider sections, and corrected sorting in the line items
• Improvements to the HIPAA view display to show the full name and address

Provider System of Record​

It's finally time to make the NPI Registry and PECOS data live in METL. We've had the ability to load these for a while, but documentation has been spotty. We've resolved the documentation gaps and retested the loads. It's now easy to spin up a local provider system of record.

Data sources:

• NPI Registry - All providers that practice medicine in the US must get a National Provider Identifier (NPI). The data in the NPI Registry is expansive, but not always up-to-date since providers aren't required to update it frequently.
• PECOS (Provider Enrollment, Chain, and Ownership). This is the database CMS uses to manage providers who receive Medicare patients. Provider must re-enroll in Medicare annually, so the data in PECOS is often more up-to-date than the data in the NPI Registry

New METL Domain-specific Language​

We're excited to announce a new METL DSL that can be used to define rules for provider contracts, accumulators, and much more. The DSL is designed so it can take advantage of any data in the claim as well as many additional pieces of data that can be joined to the claim. We built the METL DSL for contracts, but we'll also be putting it to work in other areas as well. The syntax of the METL DSL looks a lot like a subset of JavaScript so it'll look familiar to most technical people. But, it's designed to be used as a building block system to make it easy to be used by non-technical people as well.

METL DSL supports:

• Lambdas, e.g. (foo) => foo.
• Call expressions, e.g. foo(bar).
• Binary expressions like foo || bar or foo + bar.
• Parenthesized expressions, e.g. (foo + bar).
• Unary expressions, e.g. !foo, -foo, and +foo.
• Some builtins like true / false / null / undefined
• Equality expressions like foo == bar and foo != bar but not like === and !==.
• Numbers and strings, e.g. "foo" and 1.23 note that numbers only support integers and basic decimals, e.g. no exponents or hexadecimals.
• Builtin functions like:
  • between (takes 3 inputs, first is the value, second is the lower bound, third is the upper bound) and
  • if (takes 3 inputs, first is the condition, second is taken when true, third is taken when false), and
  • isNumber (checks if a string is a valid number).
• Properties on objects, e.g. foo.bar
• Methods on arrays, currently that is foo.map((item) => item * 2), foo.filter((item) => item > 5), and foo.sum().
• The global variable claims is the most important and matches an edi837.Claim.

By design, the METL DSL doesn't support local variables, multiline statements, flow control and plenty of other things. It is not designed to be a general purpose programming language. Instead, it is designed primarily to support rules, filtering and other similar types of use cases.

Patient matching improvements​

We added some capabilities to the patient matching UI to make it easier to identify the file and the TPA that the file came from.

Extractor UI​

The updated Extractor UI Wizard is live. This is a configuration-driven Wizard system which allows us to create and modify Wizards to match the types of data we load. For today, our focus is on Claims, Eligibility and Rx data. The purpose of the Wizard is to make it easy to take an extract from a trading partner and quickly get it loaded to the database.

We've been using the backend features of the wizard for over a year now, so it's been battle-tested and we're excited to bring the UI to production too. For now, the Extractor UI is read-only, but we'll be enabling read-write capability over the next couple of releases.

RX wizard & schema updates​

We've now added support for prescription drug data! This includes the database updates, template updates, and a new wizard to support prescription drugs. We anticipate that the 1.15 release will include prescription drug data loading for the first time.

Enterprise tenant deploy capability​

Our enterprise clients need the ability to deploy multiple client environments in one database. We added that capability in this release.

Extractor templates​

We added some additional features to our extractor input templates. One is that we made it possible to have a CSV column as either a string or an object with additional configuration options. Second, we added a new userFirstMatch option. This is useful for poorly designed data files where the data file repeats the same data in the file more than once.

Before:

optional: [claim_member.member_identification_code]
useFirstMatch: [claim_member.member_identification_code]
csvColumns:
    claim_member.member_identification_code: Subscriber_ID

After:

csvColumns:
    claim_member.member_identification_code:
        name: Subscriber_ID
        useFirstMatch: true
        optional: true
    output1.column2: Value 2 # still works

View improvements​

• line_item_reporting_view - added receive_time
• line_item_everything_view - restored the columns that got incorrectly removed in the v1.9 release

Repricing improvements​

We continue to add new capabilities to our My Price Health repricing engine for our enterprise clients. New capabilities include:

• ZIP3 fallback
• Rate sheet quantity
• Resolve negative Medicare issue
• Invalid SNF claim error message
• Improve ASC provider check

Testing and Deployment​

CI deploy fixes​

In v1.13, we added Atlas tests to verify views are all working. Some views run crosstab to translate rows into columns, so they only fail at runtime. But, the lints don't catch any errors if there is no data. So, with this release, we now run Atlas tests during our test and prod deploys to make sure that all of our views work.

Extract/load race condition​

We solved a timing issue where extracted data would not load because the new release record hadn't yet been created when csvloader attempted to load.

Testing improvements​

We made several internal testing improvements to better validate the code that we release. Most notably is that we're now running unit tests for the web UI as a part of CI.

New openjdk image​

The openjdk image we were previously using is no longer available on Docker Hub so we switched to a newer and more supported Docker image.

Our January release is primarily filled with new capability preparation. We're building out the ability to load Rx data to the database. We're also working on our Extractor UI to dramatically reduce the time it takes to translated data files into the METL schema. And, we're building the METL domain specific language (DSL) to make it easier to handle contract repricing, accumulators, payment integrity, and more.

New features and improvements​

Preparation for new Rx data loading​

We've done a lot of work to prepare for loading prescription drug data to the database.

• Extractor templates moving to the database
• Rx Schema
  • rename Go struct fields
  • update DB schema

Jobs UI​

The Jobs UI has turned out to be an very helpful tool to easily view and troubleshoot load issues. We continue expanding and improving it with:

• Enable searching for only failed jobs
• Fix paging

Claims repricing workflow improvements​

Enable adding new claim status through API

Working on METL Domain Specific Language​

METL DSL MVP. This will unlock capabilities for contracts, accumulators, payment integrity and much more.

Enterprise tenant deployment​

We've enabled the METL web UI for our enterprise tenants.

Other various enhancements​

• Switch to govalues/decimal. We now use this for all decimals instead of the previous decimal package we used which took much more memory.
• Add member_canonical_id_chosen to views so we can take advantage of patient matching data
• More line item categories for grouping for better reporting
• Rename columns with "_id" that aren't key columns for clearer usage
• Make patient matching more deterministic for better comparison and consistency
• Use claim_number as the standard claim number instead of payer_claim_number for better clarity and consistency.

Testing and Deployment​

• Automated Python package publishing via GitHub Actions
• Fixes to make it easier to release Python package

Our December release is a little bit light as we shaved a week off the development schedule in order to get us closer to our monthly release cadence timeframe. Our plan for 2026 is to release the first Wednesday of every month.

UI​

Job status dashboard​

Fixed the proxy to pass query parameters so that the jobs search and pagination works correctly now.

extractor wizard​

Database schema is included in this release. More progress towards full read/write capability for new extractor templates.

System updates and improvements​

We made several fixes to our user authentication and role management system for our tenants. We now have the ability to configure roles per tenant instance.

The METL UI is finally here for all users! This brings a claims UI, a job status dashboard, manual member matching, and the extractor wizard.

UI rollout​

Claims UI​

View HCFA and UB-04 claims in the claims UI to see all the claims in the database. Views include a PDF view of both HCFA and UB-04 claims as well as an HTML view with additional features such as repricing information.

Job status dashboard​

View the status of all data loads. You can see the times, statuses, and logs of both the extractor and csvloader steps.

Manual member matching​

Choose what to do with eligibility members and claim patients which have not been able to be automatically matched to a canonical member.

extractor wizard​

View the mapping between all the columns in a data file and the fields in the database.

System updates and improvements​

In addition to the exciting features in the UI, this release also includes a gateway / proxy server for backend API calls on AWS and other environments, as well as fixes for authentication and user roles.

This release also ended up being a great time for us to migrate from Svelte 4 to Svelte 5 to take advantage of the new capabilities.

X12 EDI 837 loading and repricing​

X12 EDI 837 Data loading is now ready for production. We've loaded EDI files from many different TPA's as well as repricing data for each. EDI data is now the easiest way to get claims data into the METL database.

Member matching improvements​

We continued the performance improvements of the v1.10 release. This release now does member matching more efficiently than before.

The top new feature in v1.10 is the extractor wizard. This brings forward our vision for making it easy to import common data (currently claims and eligibility data) in different formats into METL. Other exciting improvements include the beta version of our X12 837 EDI data loading, other data loading, and some important improvements to prepare for our fully open source future.

extractor Wizard​

With v1.10, we enable read-only access to all extractor claims and eligibility templates. This allows you to drop a file onto the web UI and view the extractor field mapping. You can't update the configuration at this time. The wizard is expected to allow for editable configuration in the v1.12 release, enabling rapid iteration to load data. The vision of the wizard is that teams will be able to get new data from a trading partner and configure and load it the same day.

Member matching performance fixes​

While member matching performance was great in our testing, it didn't fare so well on the larger databases of our customers. This release adds some fixes to improve performance including:

• Query fixes: this is the biggest performance fix. The query change was HUGE. It went from 8 1/2 hours to 4 seconds. Bizarrely, there was no change to the functionality of the query. We had an OR condition in the query to get both scenarios. That OR condition caused it to go 8 1/2 hours. We switched it to two separate updates without an OR condition and it became 4 seconds.
• Vacuum and analyze as needed: Early on, we added a vacuum and analyze to extractor after tables were updated. This fixed massive performance issues by ensuring that statistics were always up to date. Unfortunately, this came at the cost of running these operations after every load. This improvement changed this operation to only run after the number of rows in a table changed by enough to need a re-analyze. This shaves a few seconds off every load.

X12 EDI 837 data loading beta​

Improvements to 837 EDI loading. We've now extracted and loaded nearly 2000 different EDI files in our testing. Loads are working well, and we expect the prod release to be v1.11.

Other system improvements​

As we continue marching toward our full Open Source release, we're improving our systems to comprehend the capabilities we need to balance rapid iteration and a tighter feedback loop from our customers. Improvements this release include:

• Python client CI and testing.
• Database deploy CI fixes
• JOSH (just one single history). This is the tool we've been needing to allow us to open source METL and be able to receive pull requests from the public repository and also push code from the internal repository. This gets us much closer to being able to fully Open Source METL.
• METL archives with hashes. Rather than using dates, we're now using hashes. This ensures that we don't save the same exact file over and over to S3
• Removed dependency on Microsoft Office email client which was causing the Web server for the Claims UI to not start

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.

extractor improvements​

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.

We're excited to announce version 1.8 of METL!

The main public user-facing features of 1.8 are data fixes for a number of data loads that were released previously and the metl.dev website (this documentation)! We have enabled documentation by dynamically reading the latest Atlas .HCL files, so it should be simple to keep the documentation up to date each release.

While not yet public, this release also adds a UI to METL! It's being tested and should land in the 1.9 version of METL for general usage. The UI includes 2 different views of claims data (PDF view and HTML view), a demo of the upcoming extractor wizard, a demo of the manual patient matching functionality and more. In addition to claims data, the UI also includes Transparency in Coverage (TiC) data for each claim to provide a sense of contract rates for different carriers and TPA's.