DTR is described as the step where the payer's form gets filled in. That description is why it keeps getting under-scoped.
Documentation Templates and Rules is a rules engine. It executes logic you did not write, against clinical data you own, inside an authorisation session you have to establish, using artefacts that change without telling you. Of the three Da Vinci guides in the CMS-0057-F prior authorization chain, it is reliably the largest piece of work — and the gap between it and the other two is wider than most estimates allow for.
This is written for the consuming side — a provider-facing product implementing DTR, not a payer authoring the rules. If you are still deciding which side you are on, start with the scoping questions.
What happens inside a session
1. SMART launch
DTR typically runs as a SMART on FHIR app launched from within the EHR session, carrying its own authorisation context and its own scopes. If you are the EHR, you are the launcher, and you control this. If you are an app inside someone else's EHR, you inherit every quirk of their SMART implementation — and those quirks differ enough that a working DTR launch in one host tells you very little about the next.
2. Fetch the artefacts
The Questionnaire and its associated CQL library come from the payer. Both must be version-pinned at fetch time, because the response you produce has to be interpretable against the rules that generated it. A response validated against rule set v3 and adjudicated against v4 is a class of bug that is very hard to diagnose after the fact.
3. Gather the inputs
The CQL will reference clinical data by US Core profile. Your record does not store it that way. This step is a query against your own system, shaped to produce what the rules expect — and it is where the effort concentrates.
4. Execute the rules
CQL runs against the gathered data and decides three things: which items are shown, which are prefilled, and which are skipped entirely. You need a CQL execution environment for this. There are open-source engines available and they are usable, but "usable" is not "drop-in" — expect to spend real time on the integration between the engine and your data access layer.
5. The clinician fills the gaps
Only the items the rules could not answer. The quality of steps 3 and 4 determines how many items that is, and the number is the entire user-facing value of DTR. A DTR implementation that prefills nothing is a web form with extra infrastructure.
6. Emit the QuestionnaireResponse
The version-stamped artefact that PAS carries to the payer. Straightforward once extraction works; a steady source of validation failures until it does.
The extraction gap
This is the part to internalise. The CQL is written against US Core profiles. Your product is written against your product. Every DTR estimate lives or dies in the distance between those two things.
The mapping is bespoke to your data model, and the difficulty is rarely uniform across resources. Conditions and medications usually map reasonably. Labs bring code system gaps — the CQL wants LOINC, your results store may carry local codes with an incomplete crosswalk. Documents and attachments are frequently the worst, because the rules want a specific document type and your system has a blob store with human-entered titles.
Three consequences worth planning for:
- Missing data is not an error case; it is the normal case. Decide early whether a rule referencing an element you do not have fails loudly, fails open, or falls through to asking the clinician. All three are defensible; the wrong outcome is each part of the codebase choosing differently.
- The extraction layer is reusable and should be built as such. It is the same category of work as payer data normalisation, in the opposite direction, and the two should share a canonical model rather than each having their own.
- Coverage grows per payer. Each new payer's rule library references elements the previous ones did not. The curve flattens, but it does not flatten quickly.
Six failure modes worth designing against
Two of these deserve expanding.
Silent rule staleness
A cached rule set that has gone out of date does not raise an error. It runs perfectly and asks the wrong questions. Nobody notices until a payer starts rejecting submissions or, worse, accepting ones assembled against outdated requirements. Drift detection — a scheduled check of artefact versions against the payer, with an alert — is not a nice-to-have. It is the difference between a system you can trust and one you cannot.
Prefill that is subtly wrong
The most serious of the six, because it is worse than no prefill at all. If your extraction maps the wrong field, DTR presents a plausible answer, and a clinician signs off on an assertion your mapping invented. That is a clinical documentation problem wearing an integration costume. Every prefilled value should be traceable to its source element, and the ones derived through any transformation should be visually distinguished from the ones read directly.
How to sequence the build
Start with the CQL spike. Take one real payer's rule library, run it against your own data, and count how many elements it asks for that you cannot supply. Two weeks. This single exercise will move your estimate further than anything else you can do, and it is frequently the finding that changes the shape of the project — sometimes into "we should phase DTR into next year and ship CRD plus PAS first."
Then the extraction layer, because the spike told you exactly what it needs to cover. Longest phase, and the most reusable output.
Then the renderer. Build it against the full Questionnaire item surface, not the subset your first payer happens to use. The temptation to build only what payer one requires is strong and the rework is guaranteed.
Then versioning and operations. Rule refresh, drift detection, per-payer pinning and an alert path when a template changes. This is the phase that gets cut under pressure and the one that determines whether the system still works in eighteen months.
The build-versus-buy question, specifically for DTR
DTR is the component where the buy case is strongest, because the CQL engine and the questionnaire renderer are genuinely general-purpose and someone else has already absorbed the edge cases.
The part that is never general-purpose is the extraction layer. It maps a payer's expectations onto your data model, and nobody else has your data model. Whatever you buy, you will build that — so evaluate vendors on how cleanly they let you plug your own extraction in, rather than on whether they claim Da Vinci support. Everyone claims Da Vinci support.
Where Nirmitee.io fits
Healthcare-only, FHIR R4 native, with production EHR integrations delivered for 30+ healthtech companies and an open-source Headless EHR covering 28 clinical domains and 70+ FHIR R4 resources — which means the US Core surface the CQL expects is territory we work in daily.
The two-week CQL spike is the engagement we would recommend before anyone commits a quarter to DTR, including teams that end up doing the rest themselves. If you want a second read on what your extraction gap looks like, a 15-minute technical conversation is usually enough to size it.
