Data normalization

[healthbjk]

Navigating the healthcare landscape often means dealing with data that's inconsistent, fragmented, or in disparate formats. Even though the APIs Flexpa uses are all required to be FHIR, the implementations of the various payers differ in terms of where specific data elements are encoded, whether optional data is included, and what code systems are used.

In 2023 Q4, we are migrating to a new architecture that caches data such that we can more comprehensively understand how each payer structures their FHIR payloads, including field population, code systems in use, and other needs. Our aim is to eat the pain for customers so that you can look in one place consistently for fields with consistent code systems.

We are hoping to learn which fields are most important to normalize for customers. We are also interested in whether this should be included/wrapped into the base Flexpa API or a separate API (separating receiving the raw data from normalized data).

[rhymiz]

"Group ID", "Member ID" and "Relationship to Policy Holder" are most important to us at the moment.
It would make integration a breeze if the identifier name and location were available in the same location for every payer.

Currently we have to create custom parsers for every payer we'd like to pull this data from.

I think a caching + mapping layer works, but may potentially be a little brittle, no?
If a payer changes the identifier name, that puts a lot of pressure on your engineering team to manage those mappings -- just a thought. I'm not against it, to be clear.

Just thinking that it may be beneficial for payers to adhere to some type of naming convention - you could potentially push the responsibility of mapping payer -> flexpa to them, since they are the source of truth for the data.

[guillaume-miara]

Great to see that this is on your mind!
As far as we are concerned, in an ideal world we would only be looking at the normalized data and only have access to the raw data in case something seems inconsistent.

In terms of use cases: Something that is important to us at the moment is the Explanation of Benefits fields.
An example of inconsistencies we're seeing is the Adjudication totals
You can see that Humana example you provide does not follow the Carin value set.
If it implements an older standard, having a normalization to the new standard would be really helpful.