How People Translate Quickly | FHIR Questionnaire Translation: Localize Patient Questions Without Changing Answer Meaning

To translate an HL7 FHIR Questionnaire quickly and safely, identify each patient-visible question, instruction and answer display, attach reviewed language variants using a supported localization strategy, and preserve its linkId, item type, answer codes and conditional rules. Validate the target resource against the FHIR version and implementation guide in use, then test a completed form in the target language. A fluent translation is not enough if it changes what answer a patient gives or where that answer is stored.

A FHIR Questionnaire is a structured data-capture definition, not merely a webpage with labels. It can drive questions, grouping, answer choices, required constraints and conditional visibility. A QuestionnaireResponse records answers associated with the questionnaire structure. If translation changes the wording from “in the past week” to “today,” or relabels a coded option as a different clinical state, the digital form can remain technically valid while collecting a different fact. That makes context and clinical owner approval integral to localization QA.

This guide uses a fictional, nonclinical example of a bilingual school wellbeing intake to demonstrate the boundaries. It shows an illustrative FHIR R5 JSON resource using the HL7 translation extension on a primitive item.text field, then builds checks for forms, code lists, branching, screen rendering and records. It does not provide clinical translations for deployment or healthcare advice; real patient-facing wording needs qualified linguistic and clinical review, and implementations must follow their chosen FHIR release and national profiles.

Understand the Questionnaire as a form contract

Each Questionnaire item has a linkId that identifies the question within the form and a type that determines what sort of answer is expected. A question may have display text, help, coded concepts, nested children and rules about whether it is required or enabled. Translating the visible prompt does not alter these structural relationships. A response processor still needs to associate a submitted value with the intended question; changing a linkId during localization may make an answer appear missing or map it to the wrong analytic field.

The source form should therefore be copied into a versioned, read-only test fixture before translation begins. Record the Questionnaire URL and version when present, the FHIR release used by the sender and receiver, and the implementation guide constraints that apply. Build a list of patient-visible fields, including instructions rendered by the product rather than stored as item.text. The safest work begins with an exact inventory of what users see and what the receiving system interprets.

The translation extension and the JSON primitive boundary

HL7 publishes a translation extension whose canonical URL is http://hl7.org/fhir/StructureDefinition/translation. It contains a lang code and a translated content value for a string or markdown field. In the FHIR JSON representation, an extension on a primitive string property such as item.text is carried on the corresponding underscore companion property, item._text. The extension is not a replacement for the primary field; it adds information associated with that value.

Not every FHIR renderer automatically selects or displays the translation extension. A receiving application may ignore it, use a different localization package or require an implementation-guide-specific convention. Compatibility must be agreed with the consuming application. Translation work should be evaluated against the declared profile and the renderer rather than treating a structurally plausible JSON object as proof that a patient will see the intended language.

Preserve the distinction between words and answer values

Consider a question with coded answer options: the user sees labels such as “Yes” and “No,” while the system stores codes from a specified coding system. The labels can be localized if the implementation supports it; the codes and their systems must remain stable. A change from a code meaning “unknown” to a display reading “no” is not a harmless translation, even though both may be short words in the target language. The semantic binding belongs to the approved terminology, not to the convenience of a UI translator.

Likewise, a form might ask for a number of hours, a date, a quantity with units or a free-text explanation. These answer types have consequences for validation, interoperability and reporting. The translator should see the answer type, examples and expected use before approving the prompt. A small grammatical edit can alter whether the user enters an integer count, a decimal measurement or a narrative sentence. Good localization makes the expected answer easier to understand without changing its recorded type.

Use a clinically reviewed source-language ledger

For each translatable item, record linkId, source text, item type, question intent, approved target text, locale tag, developer contact, reviewer and the test screen where the question appears. Add whether the wording is informational, instructional, consent-related or an answer choice. High-risk forms need a clinical or domain reviewer who knows the operational meaning; a linguistic reviewer alone cannot decide whether a translation retains the intended time window, symptom intensity or decision consequence.

The ledger should also track source revisions. If a form owner changes “Have you ever experienced this?” to “During the last 30 days, have you experienced this?”, the previous translation must be reviewed again even if the same linkId is reused. Do not use an unchanged key as proof that the meaning was unchanged. Differential comparison of source wording, answer values and branch conditions is a practical way to trigger targeted retranslation without rereading every unaffected question.

Review the experience, not only the JSON

A multilingual form can parse correctly and still fail at the screen level. Longer text may overlap answer controls, instructions may be moved below the field they qualify, and a visual layout may make a conditional question appear mandatory. Test with screen readers, mobile sizes and realistic line lengths. Check whether the control’s accessible name matches the displayed question and whether the user receives feedback in the selected language when validation rejects an answer.

At least one test should include a deliberately invalid response, one skipped branch and one valid completed form. Capture the raw QuestionnaireResponse and compare its linkId and answer value structure with the expected baseline. A successful form submission that stores a changed concept or loses a branch is not localization success. The review must demonstrate both comprehension at the point of answering and stability at the point of data capture.

Tested example: a minimal safe contract

This illustrative FHIR R5 example adds one French translation to the primitive text of an integer question. It keeps the linkId and item type unchanged; the language choice in a real application depends on the receiver and its implementation guide. The scenario is a nonclinical exercise and has not been validated against a live FHIR server.

{
  "resourceType": "Questionnaire",
  "url": "https://example.org/fhir/Questionnaire/study-log",
  "status": "draft",
  "language": "en",
  "item": [
    {
      "linkId": "study-hours-yesterday",
      "type": "integer",
      "text": "How many hours did you study yesterday?",
      "_text": {
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/translation",
            "extension": [
              {"url": "lang", "valueCode": "fr"},
              {"url": "content", "valueString": "Combien d'heures avez-vous étudié hier ?"}
            ]
          }
        ]
      }
    }
  ]
}

The JSON syntax is valid and the primitive companion structure follows the documented FHIR JSON pattern, but syntax alone does not establish profile conformance or linguistic suitability. An implementer should run a version-matched FHIR validator, inspect the translation extension in the resource, and confirm that the chosen form renderer actually uses it. A careful translator should also ask whether “hours” means whole hours as the example integer type suggests, and whether the underlying educational question needs a different numeric design.

Lock answer identity and interpretation

These checks protect the contract between a question that someone sees and the data that downstream systems receive. The most dangerous defects can be invisible in a translated screenshot.

Build a minimal Questionnaire with two items: a first question asking for a whole-number response and a second conditional follow-up. Keep a printed inventory containing each linkId, type, any answerOption codes, and the relationship between the conditional expression and its source field. Translate the visible text and help strings, then compare that inventory before and after reserialization. The exact prompt may change from English into French, but the programmatic linkId of the integer question must remain identical. If the translator changes it to a target-language phrase, the patient may still see a plausible form while the downstream renderer, mapping or response consumer fails to match the answer. The valuable negative fixture is not a spelling error: it is a perfectly fluent translation that breaks the machine binding. An explicit structural diff catches it without pretending to judge clinical accuracy.

1. A translated `linkId` breaks downstream answer mapping

A translator changes the question identifier from study-hours-yesterday to a French phrase because it looks like another English string. The form still renders, but an analytics pipeline cannot associate the stored response with its expected field.

The linkId is a structural handle, not a patient-facing caption. QuestionnaireResponse items use it to identify the source question; localizing it can break mappings, data extraction and comparison across completed forms.

Diff every linkId before and after language work and block changes unless the form owner deliberately versions the contract. Repair by restoring the original handle and re-run a completed-response round trip.

2. A question type switched to match translated grammar

An editor rewrites a number-of-days prompt as a conversational paragraph and changes the item type from integer to string. The form now accepts free text that its old validation and reporting code cannot process.

Natural wording and answer datatype are independent concerns. A translation should clarify an integer question without changing its data type, range or business meaning; a genuine data model change needs separate product approval.

Compare item types and cardinality against the frozen source, then have the form owner approve a language-appropriate prompt. Test that invalid text is rejected and valid integers produce the same response structure.

3. The wording changes the recall period

An English form asks about events during the last seven days. The target phrase reads as though it asks whether the event has ever happened. Patients can now answer truthfully but report an entirely different time window.

A time qualifier is part of the measurement definition, not background decoration. Clinical meaning includes duration, frequency, severity and negation; fluency cannot compensate when a qualifier changes the population of possible answers.

Give the reviewer the original recall window and one example inside and outside it. Correct the target wording and test comprehension with scenario questions, not a word-for-word comparison alone.

4. A negative question is turned positive

A source question asks whether a medicine was not taken, but the translation omits the negation. A saved Yes answer now means the opposite of what the receiver expects.

Polarity is a data semantics issue. Some languages express negative interrogatives in ways that make bare Yes and No ambiguous, so the question and its answer choices need to be reviewed as a coherent unit.

Ask a bilingual domain reviewer to paraphrase what Yes means under the target sentence. If ambiguity remains, rewrite the source question into an unambiguous affirmative form through controlled change management rather than editing one locale alone.

Attach translations in the correct FHIR location

These cases focus on the representation of language alternatives and on whether the consuming renderer uses the intended value rather than silently ignoring it.

The translation extension is a practical example of why a JSON string is not always a self-contained value. In FHIR JSON, a primitive element’s value can be accompanied by a sibling underscore-prefixed member holding extensions. Place the English question in text and the translated variant in _text.extension, using the extension’s nested lang and content elements according to the applicable FHIR version. Then deliberately move the extension to an unrelated item and ask whether the target renderer still picks it up. The JSON parser may accept both forms, but only one attaches the translation to the intended question. A version-matched FHIR validator and a real rendering test answer different questions: structural conformance and user-visible selection. Record both results separately, and do not infer that a syntactically valid document is safe for patient-facing use.

5. The `_text` companion is misplaced

A developer puts translation extension directly beside the item object rather than under the primitive companion _text. The JSON parses, yet the extension no longer clearly belongs to the visible text field.

FHIR JSON treats metadata on primitive values using underscore companion properties. Placement determines which element is extended and whether a validator or receiver can interpret the structure according to the profile.

Validate the resource against the target FHIR release, inspect the serialized location of each translation extension, and move it to the supported primitive field. Re-open the exact renderer and confirm the French string appears.

6. An extension has no `lang` child

The target content exists but the extension omitted its language code. A multilingual UI cannot reliably decide when to show the phrase, and a standards-aware validator may reject the extension shape.

The HL7 translation extension defines required subextensions for language and content. A sentence is not a usable localized alternative without a language identity that the consumer can match to its current preference.

Check required extension children and the value datatype against the published definition. Restore a valid lang and content pair, run the profile validator and test an unrelated locale to ensure the phrase is not shown everywhere.

7. An unsupported locale is silently substituted

A French Canadian user receives European French text without a label that this is a fallback. A form includes regional vocabulary about insurance that may not be appropriate in the user's setting.

BCP 47 language and region distinctions can matter in healthcare procedures, legal meaning and patient expectations. A generic language match does not prove that a regional form has been authorized for use.

Inventory supported locales and get clinical approval for each fallback. Show a clear language choice, record the actual displayed variant in the test report, and do not claim regional validation merely because the base language is shared.

8. The renderer ignores translations it cannot read

A FHIR resource contains a valid translation extension, but a web form library uses only item.text. The browser displays English even after a successful multilingual JSON export.

The extension records language data; it does not mandate that every form renderer implement a language switch. Rendering support, application configuration and resource validity are different layers of a system.

Check the renderer's documented extension support and log the selected text source. Add a tested interpretation layer or supported localization mechanism, then verify what the browser actually displays rather than counting extension entries.

Keep coded and numeric answers meaningful

A translation that changes units, choices or answer categories can alter the collected evidence while the FHIR document remains parseable.

A translator may accurately translate “Select one” while overlooking that the original item’s answer structure permits several selections or expects a numeric type. To test this, make a paired fixture with a single-choice item and a repeated multi-choice item. Provide two response samples, one with an authorized code and one with an unrecognized localized phrase entered as though it were the code. A correct localization retains the machine answer value while translating only its display text. It must also preserve whether more than one answer is allowed. Where the form collects health data, a misleading choice label can alter patient understanding and downstream clinical interpretation even if the JSON remains structurally intact. Ask a qualified domain reviewer to verify that urgency, severity, negation, units and time windows retain their original meaning.

9. A coded Yes option is given a No label

In an intake item, the option carrying a code meaning yes appears with a target-language word meaning no. The patient sees an easy choice, but the stored code asserts the opposite fact.

Terminology code identity and the visible description must remain semantically aligned. Translating a display string does not grant permission to reuse or swap code values, code systems or their clinical definitions.

For each coded choice, show a bilingual reviewer the code meaning and a response example. Keep system and code stable, repair the display text and verify the recorded Coding after selecting the translated option.

10. A ValueSet expansion changes during language QA

A form references a published ValueSet. A localization job replaces the value-set URL with a translated phrase, and the application can no longer expand its available choices.

A canonical terminology URL identifies a value set; it is not a label. Internationalized displays must be carried through supported terminology data or rendering policy while retaining the binding.

Compare value-set URLs, expansion versions and answer codes to the approved baseline. Restore the canonical reference, obtain reviewed target-language displays, and test both the expansion response and the user's selected code.

11. Units change from hours to minutes in prose

The number field expects hours, but a translation asks for minutes while leaving the data type and downstream unit assumption unchanged. The user enters a plausible number that will be interpreted at the wrong scale.

Units are part of answer semantics even when they are only named in an instruction. A valid integer is not evidence that the value represents the quantity expected by the receiver.

Have an owner review unit wording beside the actual value representation and any unit fields. Include a test entry such as two hours and inspect the stored meaning. Repair the prompt or formally version the entire measurement contract.

12. A translated date example changes the format assumption

A target instruction uses a day-month-year example while a web component still parses month-day-year text. Some ambiguous dates appear to work until a value such as 05/06 is entered.

Date presentation, input parsing and data interchange require separate specifications. Language does not automatically change a custom parser, and a displayed format promise must agree with what the control accepts.

Test unambiguous and ambiguous dates in the target locale and inspect the serialized FHIR value. Prefer an accessible date control with explicit locale rules, or make text format instructions and parser expectations consistent.

Protect conditional questions and repeated items

Branching forms need more than phrase equivalence. The decision to show or require the next question must still correspond to the same answer and the same data structure.

Branching questions create a dangerous invisible dependency. Imagine that a pain follow-up appears only when a previous answer has a particular coded value. The French version renders the first answer label naturally, but a spreadsheet import changes the code used in enableWhen to the translated text. The branch disappears for eligible patients, yet a screenshot of the first question looks correct. Create an explicit test path for every conditional branch, including a negative path where the follow-up must remain hidden. Compare evaluated codes and identifiers with the original model after reinsertion; never use visible translated answer labels as machine comparisons unless the specification and implementation explicitly define that behavior. Review the complete patient journey rather than accepting an isolated language-file diff as sufficient proof.

13. An `enableWhen` code is localized

A conditional follow-up should appear when a specific coded answer is selected. Someone replaces the rule's answer code with translated display text, so the branch never opens for real responses.

Conditional expressions and coded values evaluate machine state, not the words printed on screen. A translated label can be different from its stable code and must not rewrite the predicate that controls the question tree.

Review enableWhen references, answer values and question linkIds as nonlinguistic invariants. Select the visible target-language option and assert that the same follow-up appears and the same answer code is stored.

14. Required status is accidentally removed

A target-language copy makes a question appear optional, and a developer removes the required flag to avoid confusing validation messages. The result no longer satisfies the original intake completeness rule.

An editorial complaint about wording is not authorization to modify response requirements. The correct repair may be a clearer explanation of why the field is needed and how to answer it.

Freeze structural required flags during language QA. Test an empty submission and ensure the target-language error clearly identifies the required item without promising that skipping is allowed.

15. Repeating items acquire inconsistent labels

A household form repeats a question for several family members. Only the first repeated instance uses the localized label; later ones revert to English because the renderer cached the wrong component state.

A repeating questionnaire item defines one question contract that can be rendered multiple times with different response instances. Localization should be applied at the item definition or supported rendering layer consistently.

Add a fixture with three repeated items and navigate forward and backward. Inspect every instance and its accessible label, then verify response repetition count and linkId associations remain correct.

16. Help text is detached from the right field

An instruction explaining how to estimate a response is translated correctly but appears below the following question on mobile. A respondent applies it to the wrong item and submits misleading information.

Question wording, help content and visual placement form a semantic unit. Even if the FHIR text has not changed, presentation defects can alter what people understand they are being asked.

Capture the question and its help at desktop and mobile widths, plus screen-reader order. Attach help to the correct control and retest an example where applying the instruction to the wrong field would visibly change the answer.

Test real patient or learner comprehension

Human comprehension and accessibility are part of correctness, especially where a user must decide what to disclose or how to recover from an invalid entry.

To verify a target language end to end, start with a controlled Questionnaire and an approved response fixture in the source language. Render the form in the requested locale, enter a sample response, serialize the resulting QuestionnaireResponse, and check that each linkId still resolves to the same intended question. Confirm that response values retain the prescribed types and coded identities; a translated label should not become a new answer code. Examine the form both before and after a save-and-resume cycle, because a localized display may be correct initially but lost when the application reloads stored data. Include a negative fixture with an absent translation to observe fallback behavior. Report the actual FHIR version, profiles and validator output used; a one-off generic JSON check is not evidence of clinical-system compatibility.

17. Long target wording hides a decisive qualifier

A small-screen form clips the phrase “without help from another person,” making the target question look like a different activity measure. The truncated version seems grammatical but omits the actual qualification.

Layout defects can be meaning defects when a qualifier changes how the user should answer. Translation length is not just a cosmetic metric in structured data capture.

Test full text with zoom and narrow widths; permit wrapping or redesign the layout rather than dropping meaning. Ask the reviewer to state the retained qualifier aloud before accepting a shortened version.

A translated visible question asks for sleep duration, but an accessible name left in English describes bedtime. Users of assistive technology receive a different instruction from sighted users.

Accessible names are part of the patient-facing form, not merely decorative metadata. Two conflicting prompts feeding the same response field make the data less comparable and undermine equal access.

Use accessibility tooling and manual screen-reader navigation for the whole branch. Keep visible and accessible names semantically synchronized, and inspect the raw response from each interaction path.

A form asks for consent to share information with a named team. A short translation drops the recipient and makes the choice sound like consent to use data internally only.

Consent-related wording has a distinct consequence and should not be paraphrased merely to fit a button. The intended recipients, scope and revocation route must remain transparent to the person deciding.

Escalate the target text for qualified legal and institutional review, validate each recipient and consequence, then test the consent action and the stored answer without allowing translation staff to alter the underlying consent policy.

20. Error message implies a medical conclusion

A validation error for a missing response is translated as if the patient has a particular condition. The application is only asking for a field; the text now asserts something unverified about the person.

A form validator detects format or completeness, not a clinical diagnosis. Turning a technical rule into an interpretive statement is unsafe and may distress users or contaminate reports.

Trace the triggering condition from the validator and write a neutral actionable message that accurately describes the missing or invalid answer. Have both the domain owner and accessibility reviewer examine the displayed error.

Control version, privacy and production release

The final checks keep changes attributable to the right source version and verify that no identifiable patient information leaks into localization review artifacts.

Transfer this method from a school reading-habits questionnaire to a public vaccination appointment form, where a careless translation can change a safety-relevant answer. A checkbox labeled “No known allergies” must not be expressed as “Allergies unknown,” and both must remain linked to the correct code and branch path. Construct a two-item fixture whose second question appears only after an affirmative coded response, then write expected behavior for English and another locale. An interpreter or clinician should review the meaning of affirmation and negation independently from the software test. Keep any illustrative data synthetic and distinguish training material from clinical advice. The generalizable lesson is that the patient’s words, the machine’s answer identities and the conditions that control the journey need separate, coordinated verification.

21. Patient information copied into translation screenshots

A reviewer exports screenshots with real names, dates and answers to an external language vendor. The phrases are easy to understand, but the review package now reveals sensitive respondent information.

Localization QA does not require access to identifiable patient data. Test fixtures should be synthetic, realistic enough to exercise the display and structurally faithful without exposing records from production.

Replace private data with fabricated fixtures and redact attached logs. Apply access controls and retention rules to review material, and confirm that support tickets contain no live patient data before sharing them.

22. R4 and R5 structures are mixed together

An implementation uses an R4 server but copies a modern R5 example without checking the receiving profile. A JSON file that looks plausible fails validation or maps to a different item structure.

FHIR releases and implementation guides define the versioned contract. An element or constraint valid in one release cannot automatically be assumed valid in another, even when its name is familiar.

Record the actual FHIR version and use a version-matched validator and profile. Review changes to Questionnaire fields and translation extension definitions before promoting the target resource.

23. A source question changes without a translation review

A form owner edits the English prompt to ask about the previous month, but the French extension still asks about the previous week. Both strings are attached to the same stable linkId.

Stable identifiers help continuity but do not guarantee semantic consistency after a source revision. A translation is approved against a particular source meaning and can become stale without any syntax error.

Store source-text hashes or revision identifiers in the translation ledger. Flag any changed source question for re-review and test that all target variants express the current recall window.

24. The final rendered form and stored response disagree

A multilingual intake passes static JSON checks but a submission from a target-language session writes the wrong coded option. The problem only appears after clicking Submit through the real application.

FHIR structure, application rendering and response serialization are separate components. A successful resource parse cannot prove that the controls, branching and submission mapping work end to end.

Complete a synthetic target-language form, save the QuestionnaireResponse, and compare each linkId, answer type and code to the expected baseline. Block release until both a linguist and implementer approve the full path.

Diagnose the entire delivery chain

The release test should include a version-matched validator, a synthetic response fixture and a human walkthrough. Start with a known question and one coded answer option. Confirm the resource reports the intended FHIR release, the translation extension sits on the correct primitive, and the renderer selects the expected language. Enter a valid answer and inspect the QuestionnaireResponse without relying on screen labels alone. Repeat with a branch that should remain closed, a missing required field and an intentionally invalid value.

Keep evidence proportional to risk. A school wellbeing form can use ordinary teacher and language-review approval for nonclinical instructional questions. A clinical intake form may need a clinician, patient-facing language specialist, accessibility reviewer, privacy officer and implementation owner. Do not copy real patient data into localization packets to make examples feel realistic. The exact route depends on the jurisdiction, the implementation guide and the institution; this editorial method cannot replace that governance.

Changed-context transfer exercise

A community health intake form asks “During the last seven days, did you miss any prescribed doses?” with coded Yes, No and Prefer not to answer options. A translator changes the French prompt to ask about the last month, renames the linkId, and translates the three answer codes as if they were labels. The web page still displays attractive French text. Explain what must be restored, what needs clinical review, and the minimum synthetic tests needed before a French-language release.

Worked answer to the transfer exercise

Restore the canonical linkId and code identities, preserving the code system and actual values; localization belongs on supported display text and the question prompt, not the machine handles. Have a qualified reviewer align the French recall period with the original seven-day meaning and verify the polarity of missed doses alongside the Yes/No semantics. Validate the resource under the actual FHIR release and profile, then test three synthetic selections, the relevant enableWhen branches if any, required-field failure, screen-reader labels and the final QuestionnaireResponse. A pretty screenshot is not sufficient evidence that stored clinical meaning survived.

Practical release review checklist

The gate below is intended for a form maintainer and language reviewer to use together. It is not a substitute for a clinical safety or privacy review where one is required.

Exact Questionnaire source version and receiving profile documented
All linkId, item types, answer codings and canonical URLs preserved
Target text and language tags reviewed against the source question intent
FHIR primitive extensions and child lang/content shapes validated
Time windows, units, negation and choice meaning checked by a domain owner
Branching, required rules and repeats tested in each supported target language
Rendered text and accessible names agree
Synthetic QuestionnaireResponse checked field by field after submission
No identifiable patient data enters translation screenshots or reports
Versioned approval covers clinical, linguistic and technical ownership

Where this method stops working

The example is a teaching fixture, not a verified deployment configuration or clinical instrument. Different FHIR releases, implementation guides and renderers may support different multilingual mechanisms. The published translation extension is not automatically honored by every consumer. Follow the actual receiver’s contract and use appropriate validators and patient-language testing.

Language equivalence cannot be established by JSON parsing, BCP 47 format checks or a bilingual phrase table alone. Clinical contexts can require validated instruments, consent wording, regulated terminology or a formal change process. Nothing in this article authorizes changing patient records, replacing diagnostic guidance, or using unreviewed machine translation as patient-facing medical instructions.

Summary: keep the human wording and machine contract aligned

A safe multilingual Questionnaire keeps its question and answer structure stable while making the visible words understandable to the intended patient or learner. The key discipline is to trace every phrase to its linkId, type, coded choices and response mapping, then test a real form journey using synthetic data. Translation quality and data integrity have to pass together; neither a fluent sentence nor a valid JSON file is sufficient on its own.

Frequently asked questions

1. May I translate a Questionnaire `linkId`?

Normally no. It is an identifier used to correlate question definitions and answers. Changing it is a contract change, not merely a language change, and must be handled with explicit form versioning and downstream coordination.

2. Where does a translation extension go for `item.text` in FHIR JSON?

For a primitive string value, the associated extension is placed in the underscore companion property, typically item._text, with the extension structure expected by the chosen FHIR release and profile.

3. Does every FHIR Questionnaire renderer display the HL7 translation extension?

No. The extension can carry language alternatives, but each renderer must implement a strategy to select and display them. Test your actual consuming software rather than assuming universal support.

4. Can the display for a coded option be translated?

Yes, using a supported mechanism and clinical terminology review. The code and code system retain their identity. A target label must continue to describe the same choice as the stored code.

5. Why is changing a question’s time window dangerous?

The recall period defines which experiences count toward the answer. A different period can produce different data even when the respondent understands and answers the translated question accurately.

6. Does a valid FHIR JSON file guarantee a safe translation?

No. Validation checks structural conformance and some coded constraints. It does not prove that the target phrase is medically equivalent, culturally appropriate, or correctly rendered at the point of answering.

7. How should the QA team handle real patient screenshots?

Use fabricated, synthetic data in a controlled test system. Remove identifiers from review artifacts and follow applicable privacy and institutional rules for any incident investigation requiring production data.

8. What should be compared after a test submission?

Inspect the QuestionnaireResponse item linkIds, answer datatypes and codes, repeated item structure, expected branching and the reference to the intended questionnaire version where applicable.

9. Can we release one target language while another is unfinished?

Sometimes, if the organization has an approved coverage and fallback policy and the application does not misrepresent unfinished phrases as complete. High-risk forms may require all visible strings for a locale to pass review.

10. Who signs off a multilingual clinical questionnaire?

The required team depends on use and jurisdiction. Typically a domain or clinical owner, a qualified target-language reviewer, a technical implementer and the institution’s privacy or safety governance may each have relevant responsibilities.

Authoritative current sources

HL7 FHIR Release 5 Questionnaire resource — formal definition of items, linkIds, response expectations and constraints
HL7 FHIR Extensions Pack 5.3.0 Translation extension (May 2026) — official canonical extension URL and required language/content subextensions
HL7 FHIR R5 JSON representation — primitive elements, underscore companion properties and extension representation
HL7 FHIR R5 QuestionnaireResponse resource — the answer structure against which to test multilingual submission

Human SEO metadata (offline editorial only)

SEO title: FHIR Questionnaire Translation QA | Safe Multilingual Forms

Meta description: Translate FHIR Questionnaire prompts, instructions and answers while preserving linkId, types, answer codes and clinical meaning. Includes validation and review examples.