Meadowlark · Provider

Meadowlark Provider

A provider record, entered once.

Four applications that carry a health plan's provider data from intake to payment, so a record entered once is resolved, priced and published without being re-keyed.

Documentation Open Provider

Behind a sign-in; write in for a token.

Status

State: Live
Address: meadowlarkprovider.com
Measured: 726 Go and 123 TypeScript tests, counted on 21 September 2026

What it is

A clinician joins a practice. Her name goes into the credentialing system on Monday, the contract system on Tuesday, the directory on Wednesday. By Friday the three copies already disagree. Nobody did anything wrong; this is just what happens when provider data is re-keyed.

Meadowlark Provider exists so the record is entered once. Four applications each own a single job and share one written data contract: the system of record resolves the provider, the pricing engine prices against it, the directory publishes it, and Provider 360 analyzes the network, reading the system of record when pointed at it and its own seeded copy by default. None of them ever asks anyone to type it again.

What it sits on top of

Wherever a plan's provider identifiers and contracts originate today, and whatever adjudicates its claims. Provider sits between them: it is the system of record for the provider, the pricer for a claim line, and the publisher of the directory. It is not a claims system and does not replace one.

What's inside

Front door: One sign-in for the four applications, one server-side session behind all of them, and revocable tokens rather than accounts.
Provider MDM: The system of record (master data management): identity, identifiers, affiliations, locations, participation and credential history, with identity resolution and a triage queue for uncertain matches. The only place a provider is created or changed.
Pricing Engine: Fee schedules, contracts and rules. Rate-file import with validation and correction, governed promotion, claim-line pricing with a full trace, evidence bundles for audit.
Provider Directory: The published, network-scoped directory: search, attestation and correction, network-adequacy checks, and exports in FHIR Plan-Net (the HL7 standard for health-plan provider directories) and the machine-readable QHP provider file Marketplace plans publish.
Provider 360: The read-side network view: signals, the full provider profile, organizations, geography, CSV export.

What it refuses to do

It does not adjudicate claims. The pricing engine prices one claim line at a time and hands back the trace.
It has no user accounts, passwords or roles. A token is a door key, not an identity.
It never reads a social security number back. The one column that holds one is encrypted so that identity resolution can match on it without the value ever being stored or queried in the clear.
No application reads another's tables. Each owns its own database, and data moves between them only over the documented interfaces.
It holds no real provider, member or claim. Every environment runs on generated data.

How it shows its work

Every priced claim line carries its trace: which contract and rate sheet applied, which candidates were rejected and why, which modifiers applied, what each step produced. For an auditor, an evidence bundle packages the imports, corrections, versions, approvals and traces behind a priced claim in one download. It records each step, not who took it.

Built and secured

Built

The boundary between the four applications is written down once, in a contract shipped with the source, and enforced in code.
Standards at the edge: FHIR Plan-Net and the QHP machine-readable file out of the directory. Plain REST and JSON everywhere else.
Go services, plus a TypeScript service for Provider 360, with TypeScript front ends. Four applications behind one door, five services in all, each deployable on its own.
726 Go tests and 123 TypeScript tests, counted on 21 September 2026. Provider 360 typechecks, tests and builds in CI on every push to main that changes it, and its build fails if an internal name leaks into a public document; the rest of Provider runs its suites locally.

Secured

Writes that matter take an explicit, logged second step: an identity merge is confirmed before it runs, a promoted rate file waits for an approval, and a directory correction is a governed write-back. Without identities there is no separate checker: the token that submitted a rate file can also approve it.
The front door records which token signed in. Behind it, the applications log their writes but not who made them.
The social security number column is under AES-SIV (RFC 5297), keyed from the environment. It is deterministic so identity resolution can match on it; the cost is that equal numbers encrypt alike.
One door across all four applications: revocable tokens, server-side sessions, rate-limited sign-in, a Content Security Policy, origin checks on every state-changing request.

The stack is deliberately plain. The interesting engineering is in the contract between the applications and in the things the system refuses to do, not in the framework list.