exporting-to-fhir
Convert OpenMed NER output (entities from openmed.analyze_text) into FHIR R4 resources — Condition, MedicationStatement, Observation — using OpenMed's built-in FHIR R4 export helpers in openmed.clinical.exporters. Covers the verified CodeableConcept builder (coding, codeable_concept, system_uri), deterministic fullUrl references, and OperationOutcome reporting. Use after running OpenMed NER when the user wants standards-conformant FHIR JSON, mentions FHIR, Condition/Observation/MedicationStatement, CodeableConcept, RxNorm/LOINC/ICD-10/SNOMED coding, or interoperability with an EHR. Pairs after
npx skills add maziyarpanahi/openmed --skill exporting-to-fhir --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Exporting to FHIR OpenMed's NER (`openmed.analyze_text`) returns spans — text, label, offsets, confidence. To make those spans interoperable you wrap each clinically relevant span in a **FHIR R4 resource** (`Condition`, `MedicationStatement`, `Observation`, ...) carrying a coded `CodeableConcept`. OpenMed ships the **mechanical** R4 export helpers for this in `openmed.clinical.exporters`; you own the small amount of clinical mapping (which span becomes which resource). ## When to use Use this after NER, when the consumer is a FHIR system (an EHR, a registry, a data lake on FHIR). Reach for it when the user says "export to FHIR", "make a Condition/Observation", "build a CodeableConcept", or needs RxNorm/LOINC/ICD-10/ SNOMED-coded resources. For packaging many resources into one transaction Bundle, hand off to `assembling-fhir-bundles`. To check the result against US Core, hand off to `validating-us-core`. ## What OpenMed gives you (verified API) OpenMed deliberately ships the *purely mechanical* pieces and leaves clinical judgement to you. The verified entry points: ```python # CodeableConcept builder — openmed/clinical/exporters/codeable_concept_simple.py from openmed.clinical.ex
- When to use
- What OpenMed gives you (verified API)
- Quick start: entity → Condition
- Worked: the resulting Condition.code
- Workflow
- Resource cheat-sheet (where the CodeableConcept goes)
- MedicationStatement (drug span)
- Observation (lab/vital span)
- Hand-off to / from OpenMed
- Edge cases & gotchas
- Standards & references
What does the exporting-to-fhir skill do?
Convert OpenMed NER output (entities from openmed.analyze_text) into FHIR R4 resources — Condition, MedicationStatement, Observation — using OpenMed's built-in FHIR R4 export helpers in openmed.clinical.exporters. Covers the verified CodeableConcept builder (coding, codeable_concept, system_uri), deterministic fullUrl references, and OperationOutcome reporting. Use after running OpenMed NER when the user wants standards-conformant FHIR JSON, mentions FHIR, Condition/Observation/MedicationStatement, CodeableConcept, RxNorm/LOINC/ICD-10/SNOMED coding, or interoperability with an EHR. Pairs after
How do I install it?
Run `npx skills add maziyarpanahi/openmed --skill exporting-to-fhir --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From maziyarpanahi/openmed, a repository with 4,851 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.