Corti Standards

Corti-curated standard sections and templates available to every API client by default

Beta

Overview

Corti Standards are a curated, Corti-maintained library of clinical sections and templates. Standards are first-class section and template resources with stable UUIDs that you can reference, inherit from, and version against in the /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. Learn more.

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 can also be used as query-param filter on LIST /documents/sections or LIST /documents/templates.

In addition, Corti Standards use structured label, e.g. family: corti-soap or family: corti-brief-clinical-note which you can use to only filter for a specific type of section or template, plus optional lang, region, specialty

Corti Standard sections

The Corti Standards section library covers the building blocks of clinical documentation. Each entry below is a stable label with key family 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 family type label 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 family label	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
source	Set the source to corti to only return Corti Standards.
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	Filter by a key:value label, e.g. family:corti-medications to list all sections of that family across languages. Repeatable.
published	Almost always true when discovering Standards for use.

JavaScript

// 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,
});

using Corti;

var sections = await client.Documents.Sections.ListAsync(
    new GuidedSectionsListRequest
    {
        Lang = new[] { "en" },
        Region = new[] { "USA" },
        Specialty = new[] { "dermatology" },
        Label = new[] { "customer:acme" },
        Published = true,
    });

import requests

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

url = f"https://api.{ENVIRONMENT}.corti.app/v2/documents/sections"
headers = {
    "Authorization": f"Bearer {TOKEN}",
    "Tenant-Name": TENANT,
}

# `lang`, `region`, `specialty`, and `label` are repeatable; `label` uses "key:value".
params = [
    ("lang", "en"),
    ("region", "USA"),
    ("specialty", "dermatology"),
    ("label", "customer:acme"),
    ("published", "true"),
]
response = requests.get(url, headers=headers, params=params)
response.raise_for_status()
sections = response.json()

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

# `lang`, `region`, `specialty`, and `label` are repeatable; `label` uses "key:value".
curl "https://api.${ENVIRONMENT}.corti.app/v2/documents/sections?lang=en&region=USA&specialty=dermatology&label=customer:acme&published=true" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Tenant-Name: ${TENANT}"

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.

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.

Related

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.