For Embedded Assistant customers who want to use the Template Assembler without sacrificing automated routing into their EHR or internal systems, a dynamic mapping strategy is the most robust option.
This approach requires customer-side implementation.
What “Dynamic Mapping” Means in Practice
The Template Assembler increases flexibility in document generation by allowing users, amongst other capabilities, to assemble documents from a shared section library.
With the template assembler, users can generate documents using any section in the section library
While an integrator could map all possible sections in advance, Corti can and will expand our library of sections at any point.
A dynamic mapping strategy allows your platform to:
Detect new or unknown section keys
Decide how they should map to existing EHR sections
Persist that mapping for future use
Once mapped, content generated by Corti Assistant can continue flowing into the correct downstream fields automatically.
What Customers Need to Build
At a high level, customers would need to implement three core capabilities in their embedded platform.
1. Section Key Detection
Your system should be able to:
Identify section keys coming from the Template Assembler output
Compare them against a list of already-known or mapped section keys
When an unknown section key appears, it should be flagged for handling.
This can be done:
At note generation time
At template creation or update time
Or during ingestion into your system
2. Mapping Logic (Decision Layer)
Once a new section key is detected, your platform needs a way to decide where it should map.
Common approaches include:
Manual Mapping
An admin or configuration user is prompted to map the new section key
Example:
assessment_new_name→Assessment(EHR field)
Rule-Based Mapping
Simple heuristics based on:
Section name
Section type
Keywords (e.g., “Plan”, “Assessment”, “Medications”)
Default / Fallback Mapping
Unknown sections are routed to:
A generic “Clinical Notes” field
A free-text or overflow section
This prevents data loss while mapping is finalized
3. Persistent Mapping Storage
Once a mapping decision is made, it should be stored and reused.
Your platform should persist:
Section key → EHR field mapping
At the organization, customer, or user level.
This ensures:
Consistent behavior across notes
No repeated prompts for the same section
Stable downstream automation
Example High-Level Flow
Corti expands the library of sections, and a new section key is generated
Your embedded platform detects an unknown section key
The platform:
Applies an existing rule, or
Routes to a default field, or
Prompts an admin to define a mapping
The mapping is saved and reused for future notes
When This Option Makes Sense
Dynamic mapping is best suited for customers who:
Have flexible or configurable EHR integrations
Want to preserve automation while allowing template customization
Expect frequent iteration on templates over time
It is not recommended for:
Organizations with strict documentation requirements where users should not be customizing templates
Highly rigid integrations with fixed schemas
Environments where unmapped content is unacceptable
Important Considerations
This functionality is not provided out of the box and must be implemented by the embedded customer.
Customers should plan for:
Operational ownership (who manages mappings)
UI or configuration workflows (if applicable)
Support processes for edge cases
Have a question for our team?
Click Support in the bottom-left corner of the console to submit a ticket or reach out via email at [email protected] and we'll be happy to assist you.s.