Licensing the datasets

The /v3/datasets bundle — conditions, medications, products, nicotine options, spelling corrections — is a standalone-licensable product. You can license the bundle independently from the underwriting engine and case store.

Use the dataset for non-underwriting workflows: EHR autocomplete, intake forms, pharmacy directories, formulary tooling, or any reference-data application.

This page is the integrator-facing positioning. Commercial terms, royalty schedule, and field-of-use scope live in the order form. For sales context, see the regulatory and patent posture notes (internal).

Why each row stands alone

Every row in v3 is self-contained. A condition row carries its medications inline as treated_with[] with prescription_count integers. A medication row carries its conditions inline as used_for[] with the same. No row depends on a response-root join, a frequency-graphs map, or a re-derived key:

{
  "id":   "cond_01KSR2WVAGC05ZGR6FA4QYEA8X",
  "name": "HIGH BLOOD PRESSURE",
  "treated_with": [
    { "id": "med_01KSR2WVAGC05ZGR6FA4QYEB12", "name": "LISINOPRIL", "prescription_count": 4120 },
    { "id": "med_01KSR2WVAGC05ZGR6FA4QYEB7K", "name": "AMLODIPINE", "prescription_count": 3088 }
  ]
}

A licensee storing this row needs nothing else: no second table, no foreign-key join, no mapping file. This is the licensee-friendly contract — the wire shape matches the stored shape.

What v3 fixed for licensees

v2's bundle relied on response-root maps (medications_by_condition, frequency_graphs.use_map) keyed by raw display strings. A licensee loading v2 into their own store had to:

1. Decode the response-root joins back into row-keyed relationships.
2. Implement a make_key normalizer matching the server's.
3. Track which response-root map the next version moved a field into.

Even if you only needed conditions[], you still had to load the maps to render frequencies. The data shape forced you to bundle everything.

v3 removes response-root maps entirely. The row is the source of truth. Take the rows you need; leave the rest.

License scopes for the datasets

License the dataset independently. Two common scopes:

A Catalog license powers autocomplete, autocorrect, and canonical-id matching in your own app. The engine is a separate license.

Patent and copyright

The datasets are protected under U.S. patents and copyrights. A dataset license covers the artifact; patent rights are conveyed separately when your use case implicates a claimed method (see the order form).

Every license requires patent marking on derivative surfaces you distribute. The marking text comes with your order form.

Refresh cadence

The version field bumps when any dataset changes. If you cache the bundle offline, revalidate with If-None-Match: 304 Not Modified keeps the cache; 200 swaps it.

Refresh frequency is a license parameter. Common cadences:

• Live — the licensee's app calls GET /v3/datasets on session start and after each prescription_count SLA window.
• Daily snapshot — the licensee's ETL ingests the bundle daily.
• Quarterly snapshot — a frozen snapshot is delivered out-of-band.

Talking to sales

For a dataset-only license, email [email protected]. Include:

• The categories you need (conditions, medications, spelling_corrections, …).
• The application surface (web, native, embedded, server-only).
• The refresh cadence.
• The territory and field of use.

Turnaround on a draft order form is one business day.

See also

• Reference catalog — the wire shape.
• Match, Autocomplete, Autocorrect — the SDK accessors that operate on the licensed rows.