FHIR XML Resource Generation Prompt Template

This prompt is designed for healthcare integration engineers who need to generate HL7 FHIR resources in XML format from structured or semi-structured clinical data. The primary job-to-be-done is converting a payload of clinical facts—such as patient demographics, observations, or medication orders—into a valid FHIR XML document that can be ingested by a downstream FHIR server, EHR, or HIE gateway. The ideal user is a developer or integration specialist building a production data pipeline, not a clinician interacting with a chat interface. You should use this prompt when the target FHIR resource type is known in advance (e.g., Patient, Observation, MedicationRequest), the input data contains the required clinical fields, and the output must pass automated XML schema validation against a specific FHIR version (R4, R4B, or R5).

Do not use this prompt when the target resource type is unknown at generation time, when the output format must be FHIR JSON instead of XML, or when the input data is too sparse to populate required FHIR elements. This prompt is also unsuitable for generating non-FHIR XML documents such as CDA, CCDA, or custom schemas. Before invoking this prompt in a pipeline, ensure you have resolved the FHIR version, the resource type, and any required profile or extension URLs. The prompt template expects placeholders like [RESOURCE_TYPE], [FHIR_VERSION], and [PROFILE_URLS] to be populated by the application layer, not inferred by the model. In high-stakes clinical contexts, always pair this prompt with a post-generation validation step that checks conformance against the official FHIR structure definition and any implementation guide profiles before the XML reaches a production system.

After reviewing this section, confirm that your use case fits the production boundary described here. If you are generating FHIR JSON, handling unknown resource types, or working with non-FHIR XML formats, select a different prompt from the XML and Markup Document Structure playbook. If your use case matches, proceed to the prompt template section to copy the ready-to-adapt template and begin wiring it into your pipeline.

This section provides the core prompt template for generating HL7 FHIR resources in XML format. The template is designed to be copied directly into your AI harness, with square-bracket placeholders that you replace with concrete values before execution. It instructs the model to produce only the XML document, with no surrounding explanation or markdown fences, ensuring the output can be piped directly into a validation step or downstream system.

textCopy
Generate a valid HL7 FHIR [FHIR_VERSION] [RESOURCE_TYPE] resource in XML format from the following clinical data:

[INPUT_DATA]

Constraints:
- The output must validate against the [RESOURCE_TYPE] structure definition and the following profiles: [PROFILES].
- Include the required FHIR namespace declaration on the root element.
- Use the narrative text element to include a human-readable summary of the resource.
- If the input contains references to other resources, use contained resources where appropriate, otherwise use logical references.
- [ADDITIONAL_CONSTRAINTS]

Return only the XML document with no surrounding explanation or markdown fences.

Adapt this template by replacing each placeholder with concrete values for your integration. [FHIR_VERSION] should be a release like R4 or R5. [RESOURCE_TYPE] is the target resource, such as Patient, Observation, or MedicationRequest. [INPUT_DATA] is the clinical data payload—this can be a JSON object, a narrative description, or a structured record from an EHR system. [PROFILES] should list any conformance profiles (e.g., http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient) that the output must satisfy. Use [ADDITIONAL_CONSTRAINTS] to inject domain-specific rules, such as required extensions, identifier systems, or terminology bindings.

Before deploying this prompt into a production pipeline, wire the output into an XML schema validator and a FHIR validator (such as the HL7 FHIR Validator or a profile-specific implementation guide checker). If the validator rejects the output, use a repair prompt from the Output Repair and Validation Prompts pillar to correct structural errors. For high-stakes clinical workflows, always require human review of generated resources before they are persisted to a FHIR server or exchanged with downstream systems.

Integrating the FHIR XML Resource Generation Prompt into a production system requires more than a single API call. The prompt is designed to be one step in a structured generation pipeline that includes input sanitization, schema validation, retry logic, and human-in-the-loop review for high-risk resources. The harness must treat the LLM as an unreliable component that occasionally produces malformed XML, invents codes, or misplaces required elements—and must catch these failures before the output reaches a downstream EHR, FHIR server, or clinical data repository.

Begin by constructing the prompt request with strict tool-use or structured output mode if your model provider supports it. For OpenAI, use response_format with a JSON Schema that wraps the XML string to prevent markdown wrapping; for Anthropic, use the XML-generation system prompt with explicit stop sequences after the closing root element. Validate the raw output immediately: parse the XML string with a strict parser (e.g., lxml with schema validation enabled), check for well-formedness, and then validate against the target FHIR structure definition using a library like fhir.resources (Python) or the HL7 FHIR Validator. If validation fails, classify the error: schema violations (missing required elements, wrong types) should trigger a retry with the error message injected into the [CONSTRAINTS] placeholder; code system errors (invented or mismatched terminology) should trigger a terminology lookup step that replaces invalid codes with valid ones from a terminology server before retrying; contained resource errors should trigger a decomposition step that generates contained resources separately and reassembles them.

Implement a retry budget of 2–3 attempts with escalating interventions. On the first failure, append the validator error to the prompt and retry. On the second failure, switch to a more capable model or add explicit few-shot examples of the failing element. If all retries fail, escalate to a human review queue with the original input, the failed outputs, and the validator error log. For high-risk resources like MedicationRequest, AllergyIntolerance, or Procedure, require human approval even on successful validation by routing the output to a review interface that displays the generated XML alongside the source clinical context. Log every generation attempt with the prompt version, model, input hash, output, validation result, and reviewer decision for audit trails and prompt regression testing. Never allow unvalidated FHIR XML to flow into a production FHIR server or clinical workflow.