code

Code Condition

Convert natural language condition to ICD-10-CM codes.

Uses an AI agent with function calling to implement the proper ICD-10 coding workflow:

  1. Normalize input: Expand abbreviations (DM2 → diabetes mellitus type 2)
  2. Alphabetic index lookup: Find candidate codes
  3. Tabular verification: Verify codes and check instructional notes
  4. Combination code check: Look for single codes covering multiple conditions
  5. Structured response: Return codes with reasoning and confidence

Example request:

{
  "condition": "DM2 w/ CKD stage 3",
  "include_hcc": true
}

Example response:

{
  "success": true,
  "codes_mentioned": ["E11.22", "N18.3"],
  "reasoning": "Type 2 diabetes with chronic kidney disease...",
  "confidence": "high",
  "warnings": [],
  "tool_calls_made": [...],
  "tokens_used": 1234
}

Note: This endpoint requires Pro or Enterprise tier.

post/api/v1/code

Request

  • Base URL: https://api.accurecord.io (the document declares no server; this is the origin it was published from)
  • URL: https://api.accurecord.io/api/v1/code
  • Auth: none declared

Headers

x-api-keystring nullable

Request body

conditionstring required

Natural language condition description

yearinteger nullable

ICD-10-CM fiscal year

include_hccboolean

Include HCC risk adjustment information

prior_codesstring[] nullable

Codes already assigned earlier in this encounter. Triggers cross-condition excludes1 detection.

code_uncertain_diagnosesboolean

Code uncertain/probable/rule-out/differential diagnoses as if established (inpatient & discharge-summary coding, ICD-10-CM Guideline II.H). Each such code is labelled coded_as_uncertain in the per-concept output and flagged in warnings. Default false keeps the outpatient rule (Guideline IV.H): uncertain dx are not coded.

meat_profilestring nullable

Name of the MEAT profile to use for evidence extraction (e.g. 'radv_strict' or 'ma_lite'). Falls back to the org's default profile if unset, or omits MEAT entirely if no profile is configured.

coding_policystring nullable

Name of the per-project coding-policy profile (Layer 2 rules: code/don't-code by chart section, chronic recapture, etc.). Falls back to the org's default policy if unset; if neither exists, coding behavior is unchanged.

hcc_model_versionstring nullable

HCC model version for RAF computation: 'V28' (CY2026 default) or 'V24' (legacy). Falls back to the org's preferred_hcc_model_version, then to V28.

hcc_segmentstring nullable

Beneficiary segment for RAF lookup, e.g. 'community_nondual_aged' (default), 'institutional', 'community_full_dual_aged'.

payerstring nullable

Payer slug ('uhc', 'humana', 'aetna', 'anthem', 'kaiser', etc.). Surfaces payer-specific denial rules in the response's verification.findings under detail.payer.

chart_idstring nullable

Optional chart_review_jobs.id this coding belongs to. Passing it (or member_id below) opts the request into reviewer mode: each verified code is persisted as a Recommendation row reviewable via /api/v1/reviewer/* endpoints.

member_idstring nullable

Optional members.id this coding belongs to. Like chart_id, passing it opts the request into reviewer mode.

previously_submitted_codesstring[] nullable

Codes ALREADY SENT TO THE PAYER for this member, to be reviewed against what this chart documents. Returns a support_review block per code. ⚠ This is NOT prior_codes: that means codes assigned earlier in THIS encounter and exists so the Excludes1 engine can see them. This asks the opposite question — does the documentation still support a code someone already submitted? Requires the support_review_enabled deployment flag (explicit 400 when off).

include_hcc_decisionsboolean

Include hcc_decisions[] — one decision object per candidate diagnosis, saying which codes it produced, which chart spans licensed them, which findings applied and what it contributed to RAF. Modelled on include_hcc: opt-in, and never changes the codes. Requires an HCC-enabled key (403 otherwise) and the hcc_lane_enabled deployment flag (explicit 400 when off, never a silent omission).

Example request

{
  "condition": "DM2 with CKD stage 3"
}

Response

Coding result. data is OPEN — keys are added over time and a client must ignore ones it does not know rather than reject the response.

successboolean required

Example response

{
  "data": {
    "confidence": "high",
    "pipeline": "v2"
  }
}

Changes

No recorded changes to this operation across all 1 revision of this API.