Skip to main content

​
Overview

Beta Template Sections provide the structure of the clinical notes to generate, what content should be documented and how that content should be written, e.g. the writing style, what text formatting, certain standard phrases or fixed headings. New to templates? Read the intro to Templates. This guide expands on how to assemble sections into custom templates and covers how to tailor sections to cover more custom template needs, or even empower end users to adjust the document (e.g. clinical note) generated by Corti’s LLM to their bespoke preferences.
See the full API specification here for dynamic templates with overrides, or jump below to a request example.
This feature requires human oversight of its outputs

​
Scenarios and workflows

The ability to assemble templates from existing sections and customize their behaviour further, unlocks various scenarios and workflows. Let’s look at some of them.

​
Offer custom templates to customers

In this scenario, you want to provide the service your customers to tailor templates to your customer feedback and needs.
1

Define template needs

Based on your insights and customer feedback, make an overview of what the template’s structure should look like, for each section the desired output requirements in terms of its name, content, writing style and formatting rules. Say the customer already tested the corti-soap default template but wants a separate allergies section, the subjective content should be under the section name “Anamnesis” instead, and the Plan in running text instead of list items.
2

Map Corti default sections

Get an overview of Corti’s default sections via GET /templateSections and the languages they are available in.
3

Assemble and customize

In this case, you decide to use the corti-subjective, corti-allergies, corti-objective, corti-assessment and corti-plan sections. For corti-subjective you apply a nameOverrideand instruct via contentOverride to exclude allergies, and for corti-plan you apply a formatRuleOverride instructing to use one paragraph of running text.
4

Template provisioning and management

At this point, you will need to save your request as a bespoke template on your end. As you reference Corti’s default sections, you will automatically inherit any more underlying improvements Corti might apply to those. Any structural changes that might influence the output of a section will be thoroughly tested and included in our upcoming breaking changes if such a change is necessary.
The current Q1 2026 roadmap will bring the creation and management of templates via API, along with even further customization options. Stay updated on out our public roadmap

​
Enable end users to customize templates

1

Decide your approach

You will want to decide whether your product should offer fixed templates with customization options, or the building blocks of templates (sections) with customization options to your end users. You can check out Corti Assistant’s implementation that enables end users to assemble templates from default sections, then further customize those.
2

Display the templates or sections

Depending your approach, you will want to fetch and display the templates you offer or the section building blocks. Either way, since the customization is enabled via section-specific overrides, it is important that you decompose a template into its sections when offering customizing templates.
Learn more about your options to list default or custom templates and default sections in our guide or the API specifications here.
Corti default sections come with what we consider the best-suited writing styles. Those are often specific to the type of section. When you fetch templates via the API, the response includes the name of the writing style, however not the full underlying prompts.
3

Enable end users to customize

You will want to decide what’s right for your product and end users: do you provide defaults in a nice UI to toggle or choose? Or do you want your end users to provide the customized prompts directly? Or a hybrid? Should customization options be limited or leverage every single override ability? Depending on your approach, design your product UI and ensure the relevant sections and overrides are part of your POST /documents request.
4

Template provisioning and management

At this point, you will need to save your request as a bespoke template on your end. As you reference Corti’s default sections, you will automatically inherit any more underlying improvements Corti might apply to those. Any structural changes that might influence the output of a section will be thoroughly tested and included in our upcoming breaking changes if such a change is necessary.
The current Q1 2026 roadmap will bring the creation and management of templates via API, along with even further customization options. Stay updated on out our public roadmap

​
Dynamic note generation based on EHR fields

1

Decide your approach

You will want to decide whether your product should offer fixed mapping you define what EHR fields should map to what section, or whether you want to let your customers or even end users define that mapping.
2

Map Corti default sections

Get an overview of Corti’s default sections via GET /templateSections and the languages they are available in.
3

Customize sections if needed

Depending your approach and needs, you might want to do further tailoring of default sections yourself or offer this to your customers or end users. If you customize a default section, you will need to save on your end the overrides that relate to a specific section - whether those are global, or on an individual user level.
The current Q1 2026 roadmap will bring the creation and management of templates via API, along with even further customization options. Stay updated on out our public roadmap
4

Generate (customized) sections at run-time

When the end user has completed a consultation and you now want to generate the documentation for the relevant EHR fields, you derive what sections should be generated based on the applicable EHR fields. This could be based on your global map or the customer/end user map. Then you construct your API request to POST /documents referencing the relevant sections, plus the potential overrides.

​
Stich a document together from multiple document input-output combinations

1

Determine the building blocks

Let’s imagine the goal is to alleviate documentation burden for clinicians where the final document should represent the referral context, conversations with the patient, detailed test results and clinician diagnosis. Let’s say the input sources are:
  • a referral letter
  • a transcript/facts generated for the admission conversation facilitated via /stream
  • detailed test results
  • a dictated note interpreting test results to establish the diagnosis
  • a transcript/facts generated for the discharge conversation facilitated via /stream
2

Map Corti default sections and its input

Get an overview of Corti’s default sections via GET /templateSections and the languages they are available in. Determine what section best serves as baseline for each aspect of the final documentation, and what input will feed into it. For example, the corti-diagnosis section might serve well for the detailed test results.
3

Customize sections if needed

You might want to do further tailoring of default sections. For example, for the corti-diagnosis section you might want to provide additionalInstructionsOverride that clarify how the results should be summarrized and structured.
4

Generate multiple documents to stitch together

Currently, the API does not support combining different context.types such as facts with transcript or string.
Therefore, in our case we will do 4 or 5 separate requests, each with the relevant context.type and the relevant sections and overrides:
  • input source: referral letter -> we will use the context.type: string to pass in the referral letter, use the corti-hpi section and via additionalInstructionsOverride give the model some more instructions that the source is a referral letter and what to summarize.
  • input source: facts generated for the admission conversation facilitated via /stream -> we will use context.type: facts and utilize several sections and overrides for small tailoring
  • input source: detailed test results report -> we will use context.type: string and utilize the corti-diagnostic-results section and overrides for small tailoring
  • input source: facts generated for the discharge conversation facilitated via /stream -> we will use context.type: facts and utilize several sections and overrides for small tailoring
  • for the dictated note interpreting test results to establish the diagnosis, this could of course just be verbatim leveraging speech rec, but in the case of a non-native speaking clinician, we could leverage pseudo-dictation that helps turn grammatical issues, interrupted sentence structures into coherent, proper clinical note content. For this we could use the corti-diagnostic-results section and apply relevant prompt instructions via overrides.
    An alternative can be to first use async fact extraction on the referral letter and detailed test results report.

​
Customization overrides and instruction hierarchy

Overrides do what they indicate: if you apply an override, the LLM will only receive what you provide in the override. So if you override a Corti default writingStyle, then whatever you provide in the override is the prompt for the writing style.
The following customization options are available
LevelPropertyoverride propertyPurpose
templaten/a as assembling sectionsdescriptionpass some context about the assembled template to the LLM
templateadditionalInstructionsadditionalInstructionsOverrideinstructions or context that is passed to all sections, e.g. context is non-critical emergency visit
sectionnamenameOverrideto return a different section name (title), e.g. Subjective -> Anamnesis
sectiondefaultWritingStylewritingStyleOverrideto prompt how the writing style should be, e.g. telegraphic, laymen, etc
sectiondefaultFormatRuleformatRuleOverrideto prompt format, e.g. bullets, subheadings, etc
sectionadditionalInstructionsadditionalInstructionsOverrideto provide additional instructions or context
Known issue: Template-level additional instructions that instruct to output certain standard placeholder texts, e.g. “Signed off by Dr…”, are currently often triggering documentation guardrails and removed in the output. We advise to handle such placeholders in your application
The combination of using default sections and overrides can lead to scenarios where the LLM receives conflicting instructions. For example, using a corti-assessment section and only providing a formatRuleOverride instructing to use fixed subheadings might conflict with the underlying prompts of the defaultWritingStyle. In this case, you can also override the writingStyle, or utilize additionalInstructionsOverride. The latter sits higher in the instruction hierarchy.

Instruction Hierarchy

The following guides the LLM output instructions by priority:
  1. Section-level Instructions including contentOverride, additionalInstructionsOverride
  2. Template-level Instructions including description, additionalInstructionsOverride
  3. Default Writing Style and writingStyleOverride
  4. Default Format Rule and formatRuleOverride

​
Request and Response Example

This examples request does the following:
  1. uses facts as context.type input
  2. assembles a template from Corti default sections and gives the LLM a little extra context via template.description
  3. customizes some sections further:
    • corti-hpi default name is “History of Present Ilness”, the requests does nameOverride to “Anamnesis”
    • corti-hpi with additionalInstructionsOverride such as to refer to patient as “My case”
    • corti-assessment uses writingStyleOverride to change to telegraphic style, and formatRuleOverride to use fixed subheadings
    • corti-plan uses a formatRuleOverride to change the default bullet point style to instead output a paragraph of running text
Customize assembled sections
  curl --request POST \
  --url https://api.$environment.corti.app/v2/interactions/$id/documents \
  --header 'Authorization: Bearer <token>' \
  --header 'Tenant-Name: <tenant-name>' \
    --header 'Content-Type: application/json' \
    --data '{
  "context": [
      {
        "type": "facts",
        "data": [
          {
            "text": "32 year-old female",
            "group": "demographics",
          "source": "system"
          },
          {
            "text": "itchy rash, started last week",
            "group": "history-of-present-illness",
          "source": "core"
          },
          {
            "text": "allergic to birch pollen since childhood",
            "group": "allergies",
            "source": "core"
          },
          {
            "text": "typical eczema appearance",
            "group": "assessment",
            "source": "core"
          },
          {
            "text": "corticosteroid treatment for 2 weeks, taper-down 2 weeks",
            "group": "plan",
          "source": "core"
          },
          {
            "text": "follow-up in 6 weeks",
            "group": "plan",
          "source": "core"
          }           
        ]
      }
    ],
    "template": {
          "description": "Clinical dermatology note",
          "sections": [
            {
               "key": "corti-hpi",
               "nameOverride": "Anamnesis",
               "additionalInstructionsOverride": "- refer to patient as my case\n- do not include allergies"
              },
              {"key": "corti-allergies"},
              {
                "key": "corti-assessment",
                "formatRuleOverride": "use fixed subheadings: **Diagnosis**:[content]\n\n**Assessment**:[content]:",
                "writingStyleOverride": "telegraphic, clinical neutral"
              },
              {
                "key": "corti-plan",
                "formatRuleOverride": "Single paragraph in running text"
              }
          ] 
      },
    "outputLanguage": "en",
    "name": "test of override customizations"
}'
Response examples
Document from request
{
    "id": "de06e013-2a66-44b5-ac74-998f3ebd9436",
    "name": "test of override customizations",
    "templateRef": "",
    "isStream": false,
    "sections": [
        {
            "key": "corti-hpi",
            "name": "Anamnesis",
            "text": "My case is a 32-year-old female presenting with an itchy rash that began last week. The rash exhibits a typical eczema appearance.",
            "sort": 0,
            "createdAt": "2025-12-12T12:07:42.551424Z",
            "updatedAt": "2025-12-12T12:07:42.551424Z"
        },
        {
            "key": "corti-allergies",
            "name": "Allergies",
            "text": "Birch pollen: allergic reaction.",
            "sort": 1,
            "createdAt": "2025-12-12T12:07:42.551424Z",
            "updatedAt": "2025-12-12T12:07:42.551424Z"
        },
        {
            "key": "corti-assessment",
            "name": "Assessment",
            "text": "**Diagnosis**: Eczema.\n\n**Assessment**: The patient presents with an itchy rash consistent with eczema. History of birch pollen allergy noted.",
            "sort": 2,
            "createdAt": "2025-12-12T12:07:42.551424Z",
            "updatedAt": "2025-12-12T12:07:42.551424Z"
        },
        {
            "key": "corti-plan",
            "name": "Plan",
            "text": "Initiate corticosteroid treatment for two weeks, followed by a taper-down regimen for an additional two weeks. Schedule follow-up in six weeks.",
            "sort": 3,
            "createdAt": "2025-12-12T12:07:42.551424Z",
            "updatedAt": "2025-12-12T12:07:42.551424Z"
        }
    ],
    "createdAt": "2025-12-12T12:07:42.551424Z",
    "updatedAt": "2025-12-12T12:07:42.551424Z",
    "outputLanguage": "en",
    "usageInfo": {
        "creditsConsumed": 0.029016
    }
}