Build a template library that pays you back

The architecture decision: one master template, or many specialised ones

This is the biggest design choice you'll make, and it's an easy one to drift into without realising. You'll build a template for a specific client, then another for a slightly different case, then another, and a year later you have 40 progress notes that each cover 90% of the same ground.

The better default: one master clinical note that handles every routine session, plus a small number of distinct templates for genuinely different work. The master template stays opinionated, same field order, same headings, same AI prompt at the end, so your team writes the same way no matter who's in the chair. Specialised templates earn their place by doing something the master can't: a structured risk assessment, an insurance-driven progress note format, a discharge summary with its own logic.

The trade-off is real. A tight master compounds: every smart-chip pattern you add, every AI prompt refinement, every custom field, they all flow through every note your team writes. Many tiny specialised templates fragment that compounding. You end up maintaining 12 copies of the same chief-complaint section, and when you want to change one thing you change it 12 times.

A rough rule for when to split: if the new template would share more than 70% of its fields with the master, don't split. Add a Section to the master for the extra fields instead. If it's a genuinely different document type, an intake questionnaire versus a session note versus a discharge letter, then yes, separate templates.

The practical end state for most practices: one master clinical note (SOAP or DAP-style depending on your discipline), one to three intake forms in your default Intake folder, an assessment or screening form per modality you actually use, and a discharge or referral template. Eight to twelve templates total. Not forty.

The forcing function: every new template you create is a future maintenance bill. Ask whether you can adapt an existing one before you click New template.

AI prompts inside templates, the underused lever

Most teams use AI prompts as a separate tool. They generate a transcript, then run a prompt to summarise it. That works, but it's leaving compounding on the table.

Build the prompt into the template itself. A SOAP note template with an AI instruction at the bottom, *(Use the transcript above to draft a discharge summary in the practitioner's voice, referencing the goals listed in the Plan section)*, turns into a two-document workflow every time you use it. A progress note with a prompt at the top, *(Summarise the client's main concerns from this session in two sentences)*, gives anyone reading the note the headline first.

Carepatron gives you three components to combine. Placeholders in square brackets describe what should appear there: [Patient Name], [Insert past medical history]. Instructions in round parentheses tell the AI how to handle the content: (Only include relevant past medical history if explicitly mentioned in the transcript.). Verbatim text in quotation marks stays unchanged every time the template runs, useful for clinician sign-offs, qualifications, contact details. You can mix all three in a single prompt.

The critical constraint: AI prompts only run when the note has a transcript. If you haven't recorded the session or run a dictation, the prompt sits there inert. Build that into your team's habit, the template assumes a transcript exists.

Where to place prompts strategically: at the top of a template for a short summary, at the end to generate a downstream document, between sections to draft one part of the note from the transcript while you write the rest manually. A well-designed master template often has two prompts: one near the top for a quick summary, and one at the bottom to generate the next deliverable. Template prompts only see the current session, so for questions about earlier sessions, use Ask in the note instead.

A note on plans: you can build and edit templates, prompts included, on every plan, Free included. AI prompts use AI tokens, and Free has a lifetime allowance of 1 million that doesn't reset. Plus and Advanced have no token cap.

Smart-chip patterns that pre-fill every form

Data chips are the pill-shaped tokens you drop into a template that pull profile fields into the rendered form. Used well, they mean your team never re-types name, DOB, contact, or any custom field you've defined.

The sequence matters: build your custom-fields schema first, then build templates that draw from it. If you reverse the order, design templates, then realise you need a field for referral source, you end up retrofitting chips into existing templates one at a time, and inevitably some get missed. Lesson 2.2 covers the schema work. Do that first.

Three patterns that pay back the work:

The referral source chip on every clinical note. If you track where clients come from, and you should, for marketing and clinical context, chip that field at the top of every progress note. Reading the note, you know in one glance whether you're treating a self-referral, a GP referral, or an insurance case, and you can adjust language accordingly.

The chief complaint or presenting problem chip at the top of every progress note. This is the single field your team rewrites most often, and it usually drifts session-to-session. Chip it from the client profile and it stays consistent, when the chief complaint genuinely changes, update the profile, not 14 notes.

The goals chip on every quarterly review. Goals live in a custom field that gets updated when treatment direction shifts. Quarterly reviews then pre-fill with the current goals, so your team reviews against what's actually current, not what was true six months ago.

The broader principle: any piece of information that should be the same across multiple documents belongs in the client profile, not in each template. Treat the profile as the source of truth and templates as views over it. When you add a new field type to your library, emergency contact, primary insurance, preferred pronouns, go back through your top three or four templates and chip it in. The work compounds: every future note inherits it for free.

Folder taxonomy that survives a growing team

Folders that work for one therapist break for a six-person clinic. The breakage is always the same: someone organises by clinician ('Sarah's templates', 'Mike's templates'), and now hiring is a documentation event because every new practitioner needs their own folder, their own copies, their own drift.

Organise by phase of care instead. A four-folder taxonomy that holds up:

• Intake: the folder Carepatron creates for you, marked Default. Forms in here are what the Send intake workflow sends when new clients are added.
• Active treatment: your master clinical note, plus any modality-specific assessments.
• Review: progress reviews, treatment plan updates, supervision documentation.
• Discharge: discharge summaries, referral letters, closing documentation.

This structure means a new hire reads four labels and knows where everything lives. It also means templates evolve as your client moves through care, which mirrors how clinicians actually think.

A few practical rules. Keep the Intake folder short: every form in it goes to every new client when Send intake is on, so three to five forms is plenty. Move the rest to a separate specialised-intake folder for manual sending. You can drag templates between folders, or hover over a template and click Move to folder.

One folder pattern to avoid: 'Archived' or 'Old' folders. They're a graveyard. If a template is dead, delete it. If you're not sure, set a 30-day review reminder. Half-archived templates accumulate and confuse new team members about which version is current.

The community library: when to consume, when to contribute

Community is the entire collection of templates published by other Carepatron workspaces. It's a starting point for the kind of templates you'd otherwise build from scratch, and a published surface for the work you've already refined.

The key distinction in the Community section of the Templates page: Use template versus Copy to workspace. Use template starts a note with it but doesn't save it to your team templates: it's a one-off. Copying it brings it into your library where you can edit, chip, prompt, and version it for your practice.

The right default: copy to workspace, then customise. A community template is rarely production-ready for your specific discipline, locale, or terminology. Treat it as a draft. Pull it in, run it through three to five real clients, and only then consider it a working part of your library.

When to publish back. The temptation is to publish as soon as the template feels finished, but the version you publish on day one is full of your practice's specific assumptions, referrer names, internal acronyms, location-specific language. Wait until you've used the template long enough that you've stripped your own assumptions out of it. A good gate: would a clinician at a different practice, in a different country, with different software conventions, recognise this as a useful starting point? If yes, publish.

The publish flow asks for a Collection and a Description. Pick the collection carefully and write a description that says who the template is for: 'Adult anxiety intake for CBT practices' is easier for the right people to find than 'Form'.

Open the overflow menu on any of your templates and choose Publish to community. The template stays in your library, you're not giving it away, you're sharing a copy.

Sharing, permissions, and what your team can edit

Templates live in your team templates by default. Anyone on the team can use them, and that's the right default: you want consistent documentation across your team. The question is who changes them.

Carepatron doesn't have a separate permission for editing templates: anyone on your team can edit a team template. So the control is agreement, not settings. A pattern that works for a growing practice:

• Owner and clinical lead: own the master template and its AI prompts. Changes go through them.
• Senior practitioners: duplicate a template for a specific use case rather than editing the master.
• Everyone else: use, chip, fill and send templates, and suggest changes rather than making them.

This prevents the most common failure mode in a multi-clinician practice: well-meaning edits that drift the master template out of clinical consistency. Documentation that diverges across practitioners is a quality and compliance risk before it's a productivity problem.

One plan note: you can build and edit templates on every plan, Free included, so you can design the library before you choose a paid plan. The 14-day free trial runs on Advanced, but SMS, your own workflows, electronic claims and eligibility checks stay off until you subscribe.

The maintenance rhythm that keeps your library useful

It's easy to build the template library once and then never come back to it. Six months later, half the templates are unused, two of them produce notes that nobody can quite remember the purpose of, and the master template has a section about a billing code that changed last quarter.

The fix is rhythm, not effort. Three loops:

Monthly: usage check. Ask your team which templates they actually use. Carepatron doesn't report template usage, so this is a quick conversation, not a dashboard. Flag any template nobody has reached for in a month. Templates exist to remove friction, if nobody reaches for one, it's adding friction (longer scrolling, more choice paralysis, more onboarding overhead for new hires) without earning its place.

Quarterly: retirement pass. Anything flagged in the monthly check for two consecutive months gets retired. Not archived, deleted, or copied to a personal workspace if a single clinician genuinely uses it. The quarterly pass also catches the inverse problem: templates that get used heavily but were never properly designed. Those get promoted, pulled into the master template's logic or formalised as their own polished version.

Annually: schema review. Walk through your custom fields and ask which ones still earn their place. The fields you defined two years ago might not match the data you actually need to capture now. Fields that nobody chips into templates can be deprecated; fields that get manually re-typed across multiple notes should be added to the schema and chipped in everywhere they appear.

The rule that holds the whole system together: new templates only when an existing one cannot be adapted. Every time someone on the team wants 'a new form for X', the first question is whether the master template plus a new section or an AI prompt can do the job. Usually it can. The tenth time, you get a deliberate new template, built, used, reviewed, and either kept or killed.