Provider docs

How Loa publishes and reviews provider data

Loa keeps provider-facing software small. Public pages, APIs, and MCP tools all read from the same source-labeled runtime layer, and provider changes become public only after review.

Source data

Hospital prices start from published machine-readable files. Provider profile data starts from stable public identity records and approved Loa updates when available.

Loa does not silently overwrite source-file prices with submitted values. Reviewed provider prices are stored as overlays with their own provenance.

Review flow

Submit corrections through the provider form, email, API, or MCP. Each channel creates the same review request and audit trail.

Approved requests can publish verified price overlays or allowlisted profile field overrides. Rejected or follow-up requests stay visible in request status.

Price labels

Published MRF Price

A price selected from hospital machine-readable files or other cleaned source-file data. Loa shows the source label and keeps enough metadata to trace the value back to the indexed row.

Loa Verified Provider Price

A provider-submitted price that Loa reviewed before publication. It appears ahead of the source-file baseline and keeps review provenance.

Comparable MRF price

When a reviewed provider price links to a matching current MRF row, Loa can show the provider value and the comparable source-file value together.

API retrieval

Provider and hospital API responses include a request id, provenance, confidence, pagination for list endpoints, and named errors. Public read routes can be used locally without an API key; metered clients can use a provider API key.

GET /api/v1/entities/search
GET /api/v1/entities/{slug}
GET /api/v1/entities/{slug}/prices
GET /api/v1/prices/compare
POST /api/v1/entity-updates
GET /api/v1/openapi.json

MCP agent retrieval

Compatible agents can search Loa entities, fetch profiles and prices, explain price sources, and submit linked-provider correction requests through the existing MCP server. Mutating update requests require a stable idempotency key and linked entity access.

search_entities
get_entity_profile
get_entity_prices
explain_price_sources
submit_entity_update_request
MCP docs

Need to correct data?

Send the smallest verifiable change you can. Include CPT codes, prices in cents or dollars, payer or plan details if relevant, and any source context reviewers should use.