Dynamic medical report template builder: a technical case study

In most EMR systems, clinical documentation templates are static. A physician sees the same fields in the same order every time they open a chart note. If a clinic wants to add a field or change the layout, they submit a support request to the EMR vendor and wait.

This creates several problems.

Specialty mismatch. A template designed for a general practitioner does not match the documentation requirements of a chiropractor or a personal injury physician. Fields are wrong. Sections are missing. Required clinical observations have no place to live.

Physician workarounds. When the template does not fit, physicians write free text in a notes field. Free text is not standardized, not searchable, and not useful for billing or quality reporting.

Slow adaptation. Clinical documentation requirements change. New billing codes require new documentation elements. A new specialty joins the clinic. With static templates, these changes require vendor involvement and wait times that can stretch into months.

A configurable template builder eliminates these problems. Clinic staff can create and modify templates themselves, in minutes, without technical support.

The core of the template builder is its element type system. Every element in a template is one of 21 types, each serving a specific clinical documentation need.

Text elements. Single-line text for short answers (patient weight, a specific measurement). Multi-line text for narrative responses (describing symptoms, free-form observations). Both types support label configuration, placeholder text, and required/optional designation.

Vitals block. A structured set of fields for vital signs: blood pressure (systolic and diastolic), pulse rate, respiratory rate, height, weight, temperature, and oxygen saturation. The vitals block renders all of these in a compact, organized layout rather than as individual text fields.

Range scale. A configurable numeric scale with a minimum value, maximum value, and step size. Used for pain scales (0-10), functional assessment scales, and outcome measurements. Displays as either a slider or a numeric input with limits.

Checkbox group. A list of selectable options where multiple selections are allowed. Used for documenting clinical findings, symptom checklists, and multi-item assessments. Options are stored in a reusable library so the same option set can be used across multiple templates.

Dropdown select. A list of options where only one selection is allowed. Used for categorical assessments, laterality (left/right/bilateral), and any field with mutually exclusive options.

Body chart annotation canvas. An HTML5 canvas with a body diagram background. Physicians draw directly on the canvas to mark injury locations, area of pain, or region of treatment. Supports pen and eraser tools, color selection, and brush size adjustment. Canvas state is serialized and stored as a base64 image in the report record.

Spine level selector. A vertebral column diagram showing all spinal levels from C1-C7 (cervical), T1-T12 (thoracic), and L1-L5 (lumbar). Physicians click individual vertebrae to mark affected levels. The selection is stored as a structured array of level identifiers.

Optical measurement fields. Structured fields for vision measurements: visual acuity (Snellen notation), sphere, cylinder, axis, add power, prism, and base direction. Used by optometrists and ophthalmologists.

Signature pad. A canvas-based digital signature capture. Physicians sign directly with their mouse or a touch device. The signature is stored as a base64 PNG in the report record.

Smart notes builder. A structured note composition tool where physicians add named fields with configurable types and then compose a narrative from those fields. The output is a prose paragraph rather than a list of values.

Table element. A configurable table with editable rows and columns. Used for medication lists, procedure history, multi-date treatment summaries.

Date field. A date picker for date-specific entries. Distinct from the appointment date managed by the scheduling module. Used for onset dates, prior treatment dates, procedure dates.

Image upload. Allows attaching images (photos of injuries, imaging prints, reference diagrams) directly within a report element.

Header and section divider. Organizational elements for structuring long templates visually. Headers create labeled sections. Dividers add horizontal spacing between sections.

Each element is configurable through a settings panel that appears when the element is selected. Configuration options vary by element type but typically include:

Label text. The question or field name shown to the physician during documentation.

Placeholder text. Hint text shown in empty input fields.

Layout width. Elements can span full width or half width, allowing two fields to appear side by side.

Required vs optional. Whether the field must be filled before the report can be submitted.

Option set (for checkbox and dropdown elements). The list of selectable options, either typed in manually or selected from the reusable option library.

Default value. Pre-populated values that the physician can accept or modify.

Character limit (for text fields). Maximum input length.

This configuration system means the same element type can serve completely different documentation purposes depending on how it is configured. A dropdown configured with "Normal, Abnormal, Not Assessed" works for a neurological screening. Configured with "Left, Right, Bilateral, Not Applicable" it works for laterality documentation.

One operational challenge in a configurable template system is that the same set of options gets recreated many times. Every specialty uses "Normal/Abnormal." Every orthopedic template uses joint names. Every PI template uses case status options.

The option library solves this by allowing clinic staff to save a set of checkbox or dropdown options as a named library entry. When configuring a new element, they can select from the library rather than typing options manually.

This has two benefits. It saves configuration time when building new templates. And it creates consistency across templates (the same option wording appears every time, rather than slightly different versions created by different staff members on different days).

The option library is managed at the clinic level. Each clinic has its own library, and super admins can create global library entries available to all clinics.

A template in the Medico system has two states: the master template (which the clinic defines) and a patient instance (which is created when a physician opens a report for a specific patient).

When a patient instance is created, it starts as a copy of the master template at that moment. Subsequent changes to the master template do not affect existing patient instances. This ensures that a patient's completed report reflects the template as it existed when the encounter was documented, not a later version that may have different fields.

This versioning approach is important for legal and billing purposes. A physician's report documents a specific encounter. If the underlying template changes after that encounter, the documentation of the encounter should not change.

The template builder's state management is complex because it handles:

• A list of elements with order
• Per-element configuration (varies by type)
• Selection state (which element is currently selected)
• Dirty state (have changes been made since the last save)
• Drag-drop reordering of elements

Redux Toolkit with entity adapters handles the element list as a normalized collection: each element has a unique ID, and the order is maintained as a separate array of IDs. This allows O(1) updates to individual elements without rebuilding the entire array.

The selected element ID is stored as a separate piece of state. When the user selects an element, the settings panel renders based on the selected element's type and configuration, reading from the normalized entity collection.

Dirty state tracking uses a baseline snapshot of the template state saved on initial load. Before saving, the current state is compared to the baseline. If they match, no API call is needed. If they differ, the API call includes only the changed elements.

After a physician completes a patient report using the template, the report needs to be exportable as a PDF for sharing with attorneys, insurance companies, and other providers.

PDF generation from a dynamic template is non-trivial because the template structure varies. The PDF cannot be a static layout. It needs to render the elements in the order they appear in the template, with the correct layout width for each element.

The Medico PDF generation approach: the API receives the completed report data (element IDs with their filled values) and the template structure (element order and configuration). It builds the PDF programmatically using a PDF generation library, rendering each element type in the appropriate layout.

The generated PDF is stored in AWS S3 as a patient document and a signed download URL is returned to the frontend.