> ## Documentation Index > Fetch the complete documentation index at: https://docs.corti.ai/llms.txt > Use this file to discover all available pages before exploring further. # 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.](/textgen/inheritance) ### 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](#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](/about/languages#language-availability-per-endpoint). 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. | 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. | ```ts title="JavaScript" theme={null} // 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, }); ``` ```csharp title="C# .NET" theme={null} 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, }); ``` ```python title="Python" theme={null} import requests # Replace these with your values ENVIRONMENT = "" TENANT = "" 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() ``` ```bash title="cURL" theme={null} # Replace these with your values ENVIRONMENT="" TENANT="" TOKEN="" # `lang`, `region`, `specialty`, and `label` are repeatable; `label` uses "key:value". curl "https://api.${ENVIRONMENT}.corti.app/v2/documents/sections?lang=en®ion=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}`: ```bash theme={null} # Replace these with your values ENVIRONMENT="" SECTION_ID="" TENANT="" TOKEN="" 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: ```json theme={null} { "name": "Allergy follow-up note", "languages": ["en"], "generation": { "instructions": { "prompt": "Produce a focused follow-up note for an allergy consultation." }, "sections": [ { "sectionId": "", "orderIndex": 0 }, { "sectionId": "", "orderIndex": 1 }, { "sectionId": "", "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. ```json title="Inherit from a Corti Standard section — instructions override" theme={null} { "name": "HPI (Pediatric)", "languages": ["en"], "specialties": ["pediatrics"], "inheritFromId": "", "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. ```json title="Inherit from a Corti Standard section — schema override" theme={null} { "name": "HPI (structured)", "languages": ["en"], "inheritFromId": "", "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](/textgen/customization-cookbook/recipe-2-inherit-corti-standard)). **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](/textgen/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](/textgen/documents-guided-synthesis/path-2-templateref-overrides). 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](/release-notes/changelog-upcoming)). * **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 Author your own sections, optionally inheriting from a Corti Standard. Compose Corti Standard sections and your own sections into a versioned template.