# Assembling Fhir Bundles

Package multiple FHIR R4 resources produced from OpenMed output into a single valid...

- Repository: https://github.com/maziyarpanahi/openmed (5755 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add maziyarpanahi/openmed --skill assembling-fhir-bundles -g -a claude-code -y`
Codex: `npx skills add maziyarpanahi/openmed --skill assembling-fhir-bundles -g -a codex -y`
Cursor: `npx skills add maziyarpanahi/openmed --skill assembling-fhir-bundles -g -a cursor -y`
Gemini CLI: `npx skills add maziyarpanahi/openmed --skill assembling-fhir-bundles -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add maziyarpanahi/openmed`

## Description

Package multiple FHIR R4 resources produced from OpenMed output into a single valid transaction Bundle ready to POST to an EHR, using OpenMed's verified bundle assembler openmed.clinical.exporters.fhir.to_bundle. Covers deterministic urn:uuid fullUrls, automatic in-Bundle reference rewriting, request blocks (method/url) for transaction vs batch, and conditional create. Use after exporting-to-fhir when the user has several Condition/Observation/MedicationStatement resources and wants one transaction Bundle, mentions Bundle, transaction, references, or posting to a FHIR server. Builds on exporting-to-fhir; pairs after.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Assembling FHIR Bundles

A FHIR server ingests one **transaction Bundle**, not loose resources, and the
resources inside it must cross-reference each other (`Condition.subject` →
Patient, `Observation.encounter` → Encounter, `DiagnosticReport.result` →
Observation). OpenMed ships a **deterministic, mechanical** Bundle assembler, `openmed.clinical.exporters.fhir.to_bundle`, that wraps the resources you built
in `exporting-to-fhir` into a valid R4 Bundle and wires up the references.

## When to use

Use after you have a *list* of standalone resources from `exporting-to-fhir` and
the destination is a FHIR server. Reach for it when the user says "build a
Bundle", "transaction", "POST these resources", or needs internal references
resolved. To check the Bundle against US Core, hand off to `validating-us-core`.

## What OpenMed gives you (verified API)

```python
from openmed.clinical.exporters.fhir import to_bundle, deterministic_fullurl

bundle = to_bundle(
    resources,                       # Sequence[Mapping] each with a resourceType
    doc_id="note-2024-03-02-001",    # seeds stable urn:uuid fullUrls
    bundle_type="transaction",       # "transaction" | "batch" | "collection" | ...
)
```

`to_bundle` does exactly three things, and **never** synthesises or validates:

The rest: https://github.com/maziyarpanahi/openmed/blob/HEAD/skills/assembling-fhir-bundles/SKILL.md