Replacing Word-Based Clinical Templates with Dynamic Web Forms
How a US health IT vendor moved clinical documentation out of Microsoft Word into a browser-based forms engine that wrote discrete assessment data into the patient record.
500+
Provider organizations on the platform
0
Local Office or OS dependencies for form rendering
1
Source of truth for assessment data in the chart
Client Overview
Nalashaa worked with a health IT vendor whose EHR and practice management platform was used by more than 500 customer organizations across the United States. Clinical documentation on that platform ran on Microsoft Word templates. A clinician opened a Word form, completed the assessment, and saved it back against the patient.
That design was set when the platform launched; the customer base was small enough for the vendor to know what every site was running. By the time the platform reached 500-plus organizations across the country, that was no longer possible.
The vendor's engineering team brought in Nalashaa to replace the documentation layer.
Business Requirement
The brief was to replace Word with a documentation layer which the vendor, controlled end to end. Four requirements defined that layer.
-
Independence from the local operating system and Office version
Forms had to render identically regardless of what was installed on a clinician's workstation. Word templates reformatted themselves whenever a customer's operating system or Office version was updated, which left the vendor absorbing a support load for changes it had no visibility into and left clinicians unsure which version of a form they were looking at.
-
Consistent behavior across every supported browser
The documentation layer had to open cleanly in any browser the platform supported. The Word-based forms did not, and for a vendor selling to organizations that each standardized on a different browser, that made documentation a deployment question rather than a product feature.
-
Assessment content captured as discrete data
Form fields had to resolve to structured elements that could be merged into the relational patient record. Content captured through the Word templates did not, so the same assessment existed twice, once in a document and once in the chart, which left clinicians and reporting teams working from more than one version of the truth.
-
A verifiable link between a note and the template that produced it
Every completed note had to be traceable to a specific template version. Templates changed over time with no reliable way to establish which version generated a given note, and for a documentation system running across hundreds of provider organizations, that was a compliance exposure rather than a housekeeping problem.
Nalashaa's Solution
Nalashaa's team built a dynamic web forms engine and integrated it with the client's existing EHR rather than delivering a standalone forms product. Four components made up the build.
-
01 / Rendering
browser-native forms engine
The team built the forms engine in Java and rendered forms directly in the browser. Layout, field logic, and validation were all resolved by the engine at request time rather than by anything installed on the clinician's workstation.
-
02 / Data
discrete capture into the patient record
Each field on a form mapped to a data element in the EHR model. An assessment completed through the engine landed in the relational patient record as structured data rather than as a document filed against the encounter.
-
03 / Authoring
template library and custom builds
Most clinical templates shipped with the engine. Customers who needed something specific to a specialty or a workflow built it through the authoring interface, defining fields and their target data elements without writing code.
-
04 / Governance
versioning and audit trail
Every template carried a version number, and every submission recorded in the template version that produced it, the author, and the timestamp.
Implementation Approach
The work started with the template inventory rather than the engine. The team catalogued the Word templates in active use across the customer base and ranked them by usage volume and by how much structured clinical content each one carried. That ranking set the build order.
Engine development and EHR data mapping then ran together. Building the runtime first and mapping fields afterward would have been the conventional sequence, and it was also the one most likely to produce a forms engine nobody could connect to the chart. Running them in parallel forced every rendering decision to be made against a real target field.
Rollout was staged through a pilot group before the template library moved across in full, so mapping errors surfaced against a small customer set rather than the whole base.
-
01
Inventory
Catalogued active Word templates and ranked them by usage and clinical structure.
-
02
Build and map
Developed the forms engine while mapping fields to EHR data elements.
-
03
Pilot
Validated rendering, capture, and authoring with a limited customer cohort.
-
04
Migration
Converted the template library and moved customers onto the engine.
Solution Highlights
-
One template, one appearance, every site
Form behavior became a property of the engine rather than of the endpoint. The vendor changed the template once, and all 500-plus organizations saw the same thing.
-
Assessment content became reportable
Because fields resolved EHR data elements, information from an assessment could be searched, trended, and reported in the same way as any other structured clinical data in the chart.
-
Template changes left the release cycle
Authoring moved to the customer, so a specialty-specific form no longer had to wait for a product release to reach the clinicians who asked for it.
-
The audit trail was written, not reconstructed
Version and authorship were captured at the moment the note was created, so documentation history became a stored fact rather than something pieced together after a question was raised.
Benefits
| Benefit | What changed for the vendor | Impact |
|---|---|---|
| Support load detached from the endpoint | Operating system and Office updates at customer sites stopped generating formatting tickets. | Support effort removed from a variable the vendor could not control |
| Browser standards stopped blocking deployment | Documentation worked on every browser the platform supported, so a customer's browser policy stopped being an onboarding question. | One less prerequisite in customer implementation |
| Duplicate assessment records eliminated | The chart held the assessment itself instead of pointing at a document that held it. | One record per assessment |
| Template requests stopped consuming engineering time | Routine and specialty template work moved to the customer-facing authoring interface. | Development roadmap freed for product work |
| Compliance questions became answerable | Template versions and submissions were logged together and retrievable on request. | Documentation history traceable end to end |
The Takeaway
The clearest decision in this engagement was refusing to treat the problem as a formatting problem.
Word templates that broke after an OS update looked like a rendering issue, and rendering was genuinely broken. But fixing only that would have produced better-behaved forms sitting in the same place, outside the patient's record, still creating a second copy of every assessment.
The question worth asking of any documentation layer is not how it renders. It is whether what a clinician enters becomes part of the chart or becomes a file attached to it. For health IT vendors carrying document-based templates, the migration is worth doing for the browser support alone, and it is worth doing properly for the data.
See what your documentation templates are costing you.
Let's look at your form layer.
Talk to the experts