Corti Standards - Corti API Documentation

Overview

Corti Standards are a curated, Corti-maintained library of clinical sections and templates — the new-API equivalent of the Documents Classic corti-* keys (e.g. corti-hpi, corti-soap). Where Classic sections were referenced by string keys on POST /interactions/{id}/documents, Standards are first-class section and template resources with stable UUIDs that you can reference, inherit from, and version against in the new /documents/sections and /documents/templates API.

Access model

Corti Standards are read-only for every API access token by default — no provisioning, no allowlisting.
They show up in your LIST /documents/sections and LIST /documents/templates responses alongside your own custom resources.
You cannot PATCH, DELETE, version, or publish Corti Standards. You can, however, inherit from them when authoring your own sections or templates via inheritFromId.

Identifying a Corti Standard

Corti Standards are tagged with source: corti on both Section and Template responses. Resources authored by an API client carry source: user — they belong to the project your API key is associated with in Corti Console. The source field is on the response object only — it is not currently a query-param filter on LIST /documents/sections or LIST /documents/templates. To narrow a list to only Corti Standards or only your own resources, filter on the response by source client-side, or use lang, region, specialty and label filters to narrow by the dimensions that matter for your use case.

Corti Standard sections

The Corti Standards section library covers the building blocks of clinical documentation. Each entry below is a stable key you can recognize, with the section title, output type and a short description of what it produces.

Each section is published as a separate resource per locale (and where applicable, per region or specialty), each with its own UUID. For example, corti-hpi is a different UUID in English than it is in German — but it shares the same key across locales. To find the UUID for the locale you need, use LIST /documents/sections with the appropriate lang (and optionally region, specialty) filter (see Discovery via the API below). Reference that UUID from your own templates, or pass it as inheritFromId when creating an inheriting section.

Corti Standard sections are offered in all the languages listed for document generation on the language availability page. Filter by the BCP-47 lang query parameter on LIST /documents/sections to see which sections are published in a given locale. Region-specific (e.g. BEL, USA) and specialty-specific (e.g. dermatology) variants are exposed via the region and specialty parameters respectively.

Browse the Corti Standard section library

Section `key`	Title	Output type	Description
`corti-actions`	Actions	array	Actions performed during the consultation, with one action per entry.
`corti-actions-and-plan`	Actions and Plan	array	Therapeutic and diagnostic actions and plans, with one concise clinical item per entry.
`corti-allergies`	Allergies	array	Open-ended set of allergy or intolerance entries, one per substance documented in the source material.
`corti-appointments`	Appointments	array	Follow-up appointments and referrals arranged at the visit, one entry per line.
`corti-assessment`	Assessment	string	Assessment section as a single paragraph of prose with no subheaders and no line breaks.
`corti-assessment-and-plan`	Assessment and Plan	object	Section containing an assessment paragraph followed by a plan list.
`corti-brief-clinical-note`	Brief Clinical Note	string	A very brief clinical note written as a single paragraph of prose with no line breaks.
`corti-cardiovascular-risk-factors`	Cardiovascular Risk Factors	array	Cardiovascular risk factor entries, one risk factor per key-value entry.
`corti-chief-complaint`	Chief Complaint	string	A concise one-line summary of the patient’s chief complaint and reason for referral.
`corti-diagnoses`	Diagnoses	array	Diagnoses explicitly stated in the source material, ordered with diagnoses related to the current visit first and less pertinent or pre-existing diagnoses after.
`corti-diagnostic-results`	Diagnostic Results	array	Open-ended set of diagnostic result entries, one per explicitly stated investigation result.
`corti-diagnostic-tests-ordered`	Diagnostic Tests Ordered	array	Diagnostic tests ordered at the current visit, one ordered test per entry.
`corti-discharge-summary`	Discharge Summary	object	Discharge summary organized into the required named sections.
`corti-emergency-situation-details`	Emergency Situation Details	object	Emergency situation details organized into five fixed key-value fields.
`corti-family-history`	Family History	array	Family history entries, one per item.
`corti-food-habits`	Food Habits	array	Food habits entries, one food-habits domain per key-value entry.
`corti-hpi`	History of Present Illness	string	History of present illness as a single paragraph of prose with no subheaders and no line breaks.
`corti-immunizations`	Immunizations	array	Open-ended set of immunization entries, one per documented administration or status.
`corti-interval-history`	Interval History	string	Interval history narrative written as a single paragraph with no line breaks and no subheaders.
`corti-lifestyle`	Lifestyle	array	Lifestyle entries, one lifestyle domain per key-value entry.
`corti-medical-decision-making`	Medical Decision Making	string	Detailed medical decision-making narrative written as a single paragraph with no line breaks.
`corti-medications`	Medications	array	Current active medications, one medication per entry.
`corti-mental-health-history`	Mental Health History	array	Psychiatric history entries, one item per line.
`corti-mental-status-exam`	Mental Status Exam	array	Mental status examination findings, one key-value entry per MSE domain.
`corti-objective`	Objective	array	Open-ended set of objective key-value entries, one per body-region finding group or diagnostic test result.
`corti-objectives-and-advice`	Objectives and Advice	array	Objectives and pieces of advice agreed or provided at the visit, one item per entry.
`corti-past-medical-history`	Past Medical History	array	Past medical and surgical history entries, one item per line.
`corti-past-obstetric-history`	Past Obstetric History	array	Past obstetric history entries, one item per line. The first entry is typically the G/P summary when documented, followed by one entry per pregnancy.
`corti-past-surgical-history`	Past Surgical History	array	Past surgical and invasive procedure entries, one item per line.
`corti-patient-summary`	Patient Summary	string	A cohesive patient-friendly summary written as a single paragraph of prose with no subheaders and no line breaks.
`corti-physical-exam-with-vitals`	Physical Exam (with vitals)	array	Open-ended set of examination, vital sign, or laboratory key-value entries, with one entry per header.
`corti-plan`	Plan	array	Plan items explicitly supported by the source material, with one clinical plan item per entry.
`corti-prescription`	Prescriptions	array	Prescriptions issued at the current visit, one prescription per entry.
`corti-referral`	Referral	array	Referral letter rendered as multiple prose blocks in order: salutation, history paragraph, findings paragraph, and final diagnosis-or-suspicion plus request paragraph.
`corti-review-of-systems`	Review of Systems	array	Open-ended set of review-of-systems domain entries, one per domain supported by the source material.
`corti-social-history`	Social History	string	Social history narrative written as a single paragraph with no line breaks.
`corti-subjective`	Subjective	string	Subjective history written as a single paragraph with no line breaks.
`corti-vital-signs`	Vital Signs	string	Vital signs rendered as a single line of compact prose with no line breaks.
`corti-well-child-care`	Well Child Care	object	Well-child developmental observations organized into five fixed key-value fields.

Each section follows the same shape as any API-client–authored resource: a UUID, a published version, heading, instructions (contentPrompt, writingStylePrompt, miscPrompt) and a typed outputSchema. You can inspect a Standard’s published configuration via GET /documents/sections/{sectionID}/versions/{versionID}.

Discovery via the API

Because each Standard section has a separate UUID per locale (and optionally per region or specialty), the canonical way to obtain the right UUID for your use case is via LIST /documents/sections with the relevant filters:

Query param	Use for
`lang`	Locale of the Standard you want (BCP-47, e.g. `en`, `de`, `fr`). Repeatable.
`region`	Country-specific Standard variant (ISO 3166-1 alpha-3, e.g. `BEL`, `USA`). Repeatable.
`specialty`	Specialty-specific Standard variant (e.g. `dermatology`, `cardiology`). Repeatable.
`label`	Any custom `key:value` label Corti applies to the Standard. Repeatable.
`published`	Almost always `true` when discovering Standards for use.

// Filter by language, region, specialty, label, and/or publish status.
// All four filter params are repeatable arrays. `label` values use "key:value".
const sections = await client.documents.sections.list({
  lang: ["en"],
  region: ["USA"],
  specialty: ["dermatology"],
  label: ["customer:acme"],
  published: true,
});

Filter client-side on source: "corti" to scope a list response to Corti Standards only (vs. resources your project has authored). Inspect the resolved configuration of a specific Standard via GET /documents/sections/{sectionID}/versions/{versionID}:

# Replace these with your values
ENVIRONMENT="<eu-or-us>"
SECTION_ID="<your-section-id>"
TENANT="<your-tenant-name>"
TOKEN="<your-access-token>"
VERSION_ID="<your-version-id>"

curl "https://api.${ENVIRONMENT}.corti.app/v2/documents/sections/${SECTION_ID}/versions/${VERSION_ID}" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Tenant-Name: ${TENANT}"

Cache the (key, lang, region, specialty) → sectionId mapping in your service once your variant set is known — it removes a list call from every generation request.

Compose a template from Standards

Reference Standard section IDs directly in a POST /documents/templates request — exactly the same shape as referencing your own sections:

{
  "name": "Allergy follow-up note",
  "languages": ["en"],
  "generation": {
    "instructions": { "prompt": "Produce a focused follow-up note for an allergy consultation." },
    "sections": [
      { "sectionId": "<your-section-id>", "orderIndex": 0 },
      { "sectionId": "<your-section-id>", "orderIndex": 1 },
      { "sectionId": "<your-section-id>", "orderIndex": 2 }
    ]
  }
}

Inheriting from a Corti Standard

Inheritance is the recommended path for specialty variants or organization-specific tweaks. Use a Standard’s UUID as inheritFromId on your new section or template, then override only the fields you want to diverge.

Override instructions (writing style, content, misc)

instructions overrides are per-field partial — any field you omit is inherited from the Standard.

Inherit from a Corti Standard section — instructions override

{
  "name": "HPI (Pediatric)",
  "languages": ["en"],
  "specialties": ["pediatrics"],
  "inheritFromId": "<your-section-id>",
  "generation": {
    "instructions": {
      "writingStylePrompt": "Use family-centred language; refer to the patient as 'the child'."
    }
  }
}

Override `outputSchema` (structured output from a Standard)

The Standard’s prompts may be perfect, but you want structured output for an EHR pipeline. Supply your own outputSchema on the inheriting section — heading, instructions.contentPrompt, writingStylePrompt, miscPrompt are inherited from the Standard, so you’re keeping the brain and swapping the shape.

Inherit from a Corti Standard section — schema override

{
  "name": "HPI (structured)",
  "languages": ["en"],
  "inheritFromId": "<your-section-id>",
  "generation": {
    "outputSchema": {
      "type": "object",
      "fieldFormat": "{key}\n{value}\n",
      "fields": [
        { "key": "Onset",    "description": "When and how the illness began.",           "value": { "type": "string" } },
        { "key": "Course",   "description": "Progression over time.",                    "value": { "type": "string" } },
        { "key": "Symptoms", "description": "Current symptoms and pertinent negatives.", "value": { "type": "string" } }
      ]
    }
  }
}

outputSchema overrides are wholesale, not merged. Whatever you submit fully replaces the inherited schema — partial schemas are not merged. This applies whether you use inheritFromId (above) or override at runtime on POST /documents (see Customization Cookbook — Recipe 2).Mismatch caveat. When the schema change is structural (e.g. string → object/array), the inherited writingStylePrompt may conflict with the new shape. Consider overriding writingStylePrompt too in the same request so the model receives coherent instructions. See Section Schemas for design patterns.

Need a one-off schema override instead of an inheriting section?

If the schema change only applies to a single generation call (e.g. an end-user UI option), skip the inheriting resource and apply the override at runtime on POST /documents (Path 2). The shape is identical — generation.outputSchema wholesale-replaces for that call only. See Guided Synthesis — Path 2. Inheritance resolves against the Standard’s published version at request time. Any field you do not override continues to track Corti’s improvements as new versions are published.

Scoping a list by source

LIST /documents/sections and LIST /documents/templates return both Corti Standards and resources your project’s API clients have authored, interleaved in one response. The source field on each item tells you which is which:

`source` value	Meaning
`corti`	Corti-curated Standard (read-only).
`user`	Authored by an API client in your project.

To present a “browse Corti Standards” surface in your product, filter the response client-side on source === "corti". For a “my project’s templates” surface, filter on source === "user". Combine with server-side lang, region, specialty and label filters to keep the response payload tight.

source is not currently a query parameter on the LIST endpoints — only a field on the response. Server-side filtering by source would be additive if your integration needs it; flag this to your Corti contact if so.

Limitations and guarantees

Read-only. No write, version, publish or delete on Corti Standards.
Stable IDs. A Standard’s id is stable across the lifetime of that resource. Versions may be added by Corti over time; the published-version pointer evolves.
Silent updates by default. Updates to Corti Standards are typically silent: small prompt refinements and quality improvements ship continuously, the same way many small API releases do, without per-change notes. Only clear schema-breaking changes or significant behavior changes are explicitly communicated (e.g. via the upcoming changes log).
Need to stay on a specific behavior? Inheritance (inheritFromId) cannot pin you to an upstream version. To decouple from the Standard entirely, re-create the section or template as your own resource by copying its configuration into a POST /documents/sections or POST /documents/templates request without inheritFromId. The new resource is yours to version; subsequent Corti updates will not reach it.

Create a Section

Author your own sections, optionally inheriting from a Corti Standard.

Create a Template

Compose Corti Standard sections and your own sections into a versioned template.

Documentation Index

​Overview

​Access model

​Identifying a Corti Standard

​Corti Standard sections

​Discovery via the API

​Compose a template from Standards

​Inheriting from a Corti Standard

​Override instructions (writing style, content, misc)

​Override outputSchema (structured output from a Standard)

​Need a one-off schema override instead of an inheriting section?

​Scoping a list by source

​Limitations and guarantees

​Related

Create a Section

Create a Template

Overview

Access model

Identifying a Corti Standard

Corti Standard sections

Discovery via the API

Compose a template from Standards

Inheriting from a Corti Standard

Override instructions (writing style, content, misc)

Override `outputSchema` (structured output from a Standard)

Need a one-off schema override instead of an inheriting section?

Scoping a list by source

Limitations and guarantees

Related