Skip to main content
A note template is the set of instructions Sully uses to turn a transcript and patient context into a clinical note. It defines the sections and their order, what information belongs in each section, and how the note should be written. The template is broken up into two parts:
  • Global instructions apply across the note.
  • Section instructions provide specific rules and examples for each section.
This page provides our default outpatient SOAP template as a complete, ready-to-use starting point. Download or copy it as provided, customize its instructions and sections, or use the guidance below to build your own.

Template structure

The combined text in the template and clinical context may not exceed 100,000 characters. Unknown fields are rejected. See the request reference for the other request fields.
The sections array is flat. Define top-level titles and their order in this array. To create subsections, describe bold labels and their content in the parent section’s instructions; do not add child-section objects.

Write global instructions

Global instructions define behavior shared by every section. Use the authoring guidance to decide which rules your template needs, then see the worked example for sample template text and the note it is intended to produce. When writing template.instructions, specify:
  • Formatting: Choose bullets or paragraphs, subsection labels, and spacing.
  • Missing information: Decide how to represent a wholly unsupported section and whether to omit unsupported subsections.
  • Source handling: Specify how the note should distinguish current findings from prior records.
  • Shared style: Describe the writing style, including how to preserve uncertainty.
The service adds top-level ###### headings. In the SOAP example, use bold labels within section bodies. The section instructions determine which content belongs under each label.
Example value for template.instructions:
The template contains Objective and Allergies, in that order. Objective’s section instructions select examination findings and completed imaging results, using Physical Exam Findings and Imaging Results as bold labels. Allergies’ section instructions select stated allergens and reactions.Encounter input: Clinician: “Today there is mild epigastric tenderness. Last month’s abdominal ultrasound showed no gallstones.” No allergy information is supplied.Expected note:
Unsupported Objective subsections are omitted. Allergies uses the whole-section placeholder, and the imaging result is explicitly identified as prior information.

Write section instructions

Section instructions define the content and organization of one section. Use the authoring guidance to write those rules, then see the worked example for a Review of Systems section. Use the blocks that apply to each section in the order below. These are authoring conventions within an instruction string; they are not API fields or labels that automatically appear in the generated note. Omit blocks with no relevant rules. Shared missing-information behavior can remain in the global instructions.
Example section title (sections[].title): Review of Systems.Example value for that section’s instructions field:
Encounter input: Patient reports occasional cough and denies shortness of breath. Clinician states the lungs are clear and orders a chest X-ray.Expected section body:
The examination finding belongs in Objective; the test order belongs in Assessment and Plan. A separate Missing information block is unnecessary because the global rule already covers unsupported systems and whole sections.

Outpatient SOAP example

The default outpatient SOAP template has seven top-level sections. The subjective components are individual sections; Objective uses bold subsection labels within its body. You can change the titles, order, instructions, and number of sections. Use this template as provided or adapt it for your application. Include it in each request; it is not applied automatically. The file contains the template object itself; assign it to your request’s template field.
Each section prompt below contains its rules and illustrative input/output examples in one copyable block. Copy the entire block into that section’s instructions field; both the rules and examples are sent to the model. These blocks match the instruction strings in the downloadable JSON.
Section promptCopy this entire block, including the examples, into this section’s instructions field.
Section promptCopy this entire block, including the examples, into this section’s instructions field.
Section promptCopy this entire block, including the examples, into this section’s instructions field.
Section promptCopy this entire block, including the examples, into this section’s instructions field.
Section promptCopy this entire block, including the examples, into this section’s instructions field.
Section promptCopy this entire block, including the examples, into this section’s instructions field.
Section promptCopy this entire block, including the examples, into this section’s instructions field.

Customize your template

Maintain separate templates by specialty, encounter type, or clinician in your application. Select a template, combine any global or section-specific customizations, and send the final template object with the transcript. Put shared behavior in global instructions and local content or formatting rules in the relevant section. Keep customizations consistent with the base template; explicitly revise a conflicting rule instead of appending its opposite.
Surgical history, screening history, and other additional history sections can be added within an existing PFSH section or as standalone sections.Example instruction
“Within PFSH, include a bold Screening History label for screening dates and results discussed during the encounter.” If screening needs its own top-level section, add a separate entry to template.sections.
If an entire section has no supported content, use Not Provided. Omit unsupported subsections and optional details. Do not turn missing information into a negative finding.Example
No allergy information → Not Provided; no imaging results → omit the Imaging Results subsection from Objective.
  • Use - item bullet syntax for all lists. Plain text items on separate lines may collapse, depending on the renderer.
  • Headings (######) must be followed by a blank line before body content.
  • Use double newlines (\n\n) between content blocks.
  • Use Not Provided for an unsupported whole section and omit unsupported subsections.
  • Sub-element labels use bold text (**Label**), never heading-level Markdown in this SOAP example.
Example section body
Rules that specifically mention other sections. For example, a rule may reinforce that patient-reported history belongs in HPI, while examination findings belong in Objective and management decisions belong in Assessment and Plan.Example instruction
“A patient reporting abdominal pain belongs in HPI or ROS; clinician-observed tenderness belongs in Objective. Keep an ordered abdominal CT in Assessment and Plan.”
Any rules or instructions related to an organization’s requirements or preferences for note formatting or content.Example instruction
“In PFSH, place occupational exposures under a bold Employment label when discussed.”
Instructions relating to specific formatting, such as Markdown formatting, which helps distinguish sections, subsections, and important values. Consistent labels can help when mapping generated note text to custom fields later; labels do not create structured API fields by themselves.Example instruction
“Within Assessment and Plan, use a Medications label and include the medication action, name, and stated details in each bullet.” Specify the corresponding target fields separately in the extraction schema.
Rules defining writing preferences such as:
  • Using bullet points versus paragraphs.
  • Preferences regarding prose, such as avoiding repeated “Patient reports…” phrasing in HPI.
  • Using concise clinical language versus retaining the patient’s own wording when needed to preserve meaning.
Example instruction
“Use concise HPI bullets without repeating ‘Patient reports’ in every entry; retain uncertain wording such as ‘possibly’ when stated.”
Substitute variables in your application before sending the request. The API receives the resulting instruction strings; it does not resolve application variables.Use your own string assembly or render a Handlebars template in your application:
You can also supply patient information through clinical context when appropriate.

Assemble and send the template

Store long instructions in readable Markdown or plain-text files. File headings are authoring labels; the API receives strings and does not read local files or interpret file boundaries.
Save the downloadable template as templates/outpatient-soap.json. For example:
Send request as the JSON body of POST /v3/notes using the authenticated SDK or curl examples.

Test and refine

  • Use representative encounters to check content selection, missing-information behavior, and formatting.
  • Compare generated notes with the source transcript and supplied context to check for unsupported facts and incorrect placement.
  • Include illustrative input and expected output in your instructions; explicitly say that their clinical facts must not be copied.
  • Turn recurring unwanted behavior into a specific rule or example, then rerun the same encounters to check the change.
  • Review global and section rules together for conflicts, especially after adding clinician or organization preferences.

Map the note to custom fields

To populate EHR fields, send the generated note string as text to POST /v1/utils/text-to-json with a JSON Schema defining the desired fields. See Generate a note, then structure it for the two-request workflow. Consistent section headings and labels can help extraction identify content. For example, a Medications label in Assessment and Plan can help locate medication actions and stated details. Define the target fields separately in the extraction schema. Template instructions are not automatically passed to Text to JSON. Markdown labels organize the note; they do not create structured API fields.