Insights
Explainable data quality for healthcare and insurance data.
Claims, eligibility, enrollment, and provider files feed decisions that affect people and money. Data-quality controls in this setting must do more than catch errors; they must explain themselves to auditors, regulators, and the members and providers affected. This is the approach Ascendant Systems applies to healthcare and insurance data work.
rules as code
Rules written down, versioned, and reviewable
Every data-quality rule lives in a versioned rule set with an identifier, a plain-language description, the fields it reads, the condition it checks, and the action taken when it fails. A change to a rule is a reviewed change with a date and an author role. When a claim is held because of rule EL-014, anyone can read what EL-014 means and why it exists.
- Identifier prefixes by domain, for example EL for eligibility, CL for claims, PR for provider, EN for enrollment.
- A severity on every rule: block the record, hold it for review, or warn and continue, chosen by the data owner, not the engineer.
- An effective date and a retirement date, so a rule can be traced to the policy or contract change that introduced it.
- A test case per rule with a synthetic record that passes and one that fails, run on every change to the rule set.
layers
Three control layers
- Structure at the boundary: files from carriers, clearinghouses, and vendors are checked for headers, row width, and required fields before they enter the pipeline. This is the layer FileSpecGuard demonstrates.
- Validation at load: value rules for formats, code sets, date logic, and cross-field consistency, with failing records quarantined and tagged with the rule identifier.
- Reconciliation at reporting: totals and counts tied back to source files and to prior periods, so a drop in paid claims is noticed the day it happens.
no silent decisions
No silent decisions
Automation, including AI assistance, may classify, flag, and route. It may not silently determine eligibility, payment, or coverage. Every consequential outcome passes through a rule that a person can read or a review step that a person performs, and the record shows which one. This is a design constraint, not a feature, and it keeps the workflow defensible when questions arrive months later.
quarantine
Quarantine with a path back
Failed records are not dropped and not corrected in place. They go to a quarantine store with the rule identifier, the offending values, and the source file, and the data owner sees a queue with counts by rule. Fixes happen at the source or through a documented correction with its own audit row. Reprocessing is idempotent, so a corrected batch does not duplicate what already loaded.
phi boundary
Protected information stays behind a boundary
Design and testing use synthetic records. Production protected health information is handled only under an agreed security boundary with organization isolation, least-privilege access, private storage, retention rules, and audit events. External AI services are disabled on customer data by default. Ascendant Systems does not claim a compliance certification and does not accept production health data until that boundary is approved in writing.
engagement
How the work is scoped
A typical starting point is a scoped assessment of one feed: the rules in force today, the failures of the last quarter, and where decisions are made without a readable rule. From there, a fixed-scope implementation puts the three layers in place for that feed, with the rule set, the quarantine queue, and the reconciliation report as the acceptance criteria.
Next step
Bring the problem behind the article
If one of these situations looks like yours, describe the outcome you need and what is getting in the way. The first exchange decides whether a responsible scope can be defined.