Agent skill

Exporting To Fhir

by maziyarpanahi in maziyarpanahi/openmed

Convert OpenMed NER output (entities from openmed.analyzetext) into FHIR R4 resources — Condition, MedicationStatement, Observation — using OpenMed's built-in FHIR R4 export helpers in…

Apache-2.0Auto-check passedResearch & Science

Install Exporting To Fhir

skills CLI
$ npx skills add maziyarpanahi/openmed --skill exporting-to-fhir -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install maziyarpanahi/openmed exporting-to-fhir --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/maziyarpanahi/openmed.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/exporting-to-fhir .claude/skills/exporting-to-fhir && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
exporting-to-fhir
GitHub stars
5.5k
Token cost
~2.6k tokens
SKILL.md length
647 words
Files
1
Skills in repo
74
Repo updated
First seen
Licence
Apache-2.0

At a glance

Convert OpenMed NER output (entities from openmed.analyzetext) into FHIR R4 resources — Condition, MedicationStatement, Observation — using OpenMed's built-in FHIR R4 export helpers in…

  • Works in 7 steps: NER — openmed.analyze_text(note,… → Classify each span: a disease label →… → Ground the surface text to a code out of… → …
  • Wants standards-conformant FHIR JSON
  • SKILL.md covers When to use, What OpenMed gives you…, Quick start: entity → Condition and Worked: the resulting…, plus 4 more sections
  • Reaches hl7.org and terminology.hl7.org

What it does

Exporting To Fhir is an agent skill from maziyarpanahi/openmed. Convert OpenMed NER output (entities from openmed.analyzetext) 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, codeableconcept, systemuri), 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…

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Research & Science, covering Clinical and healthcare research. The repository describes itself as: Local-first healthcare AI: clinical NER and HIPAA PII de-identification on hardware you control. 2,200+ medical models, 35 model-backed PII languages, and Python, MLX, Android… The licence is Apache-2.0.

When your agent uses it

  • Wants standards-conformant FHIR JSON
  • Condition/Observation/MedicationStatement
  • CodeableConcept
  • RxNorm/LOINC/ICD-10/SNOMED coding

Example prompts

  • “/exporting-to-fhir”

Requirements

  • Python 3

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. NER — openmed.analyze_text(note, model_name=...) → result.entities.
  2. Classify each span: a disease label → Condition; a drug → MedicationStatement;
  3. Ground the surface text to a code out of process (terminology server or
  4. Build the CodeableConcept with coding(...) + codeable_concept(...).
  5. Wrap it in the resource shell (set clinicalStatus/status, subject,
  6. Reference the Patient/Encounter via {"reference": "Patient/"}.
  7. Pass the list to to_bundle(...) (assembling-fhir-bundles) and validate

What it can do on your machine

Read from SKILL.md and the folder at commit 34d7b8c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are python and json).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • hl7.org
    • terminology.hl7.org
    • snomed.info
    • unitsofmeasure.org

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Exporting To Fhir loads about 2.6k tokens when it runs. Until then it costs about 176 tokens; SKILL.md has 647 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~176
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from maziyarpanahi/openmed at commit 34d7b8c, republished under its Apache-2.0 licence (© maziyarpanahi). 647 words, ~2,603 tokens.

Download SKILL.mdSave it as .claude/skills/exporting-to-fhir/SKILL.md (or your agent's skills folder).
name
exporting-to-fhir
description
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 extracting-clinical-entities; feeds assembling-fhir-bundles and validating-us-core.
license
Apache-2.0
metadata.project
OpenMed
metadata.category
fhir-interop
metadata.pairs
after
metadata.version
1.0

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.exporters.codeable_concept_simple import (
    system_uri,        # vocab id -> canonical HL7 system URI
    coding,            # (system, code, display) -> Coding dict
    codeable_concept,  # [Coding, ...] -> CodeableConcept dict (deterministic order)
)

# Bundle + reference + OperationOutcome — openmed/clinical/exporters/fhir/
from openmed.clinical.exporters.fhir import (
    to_bundle,                 # [resource, ...] -> R4 transaction Bundle
    deterministic_fullurl,     # (doc_id, index) -> stable urn:uuid
    OperationOutcomeIssue,     # issue dataclass
    to_operation_outcome,      # [issue, ...] -> OperationOutcome
    from_validation_result,    # validator result -> OperationOutcome
)

system_uri knows these vocabularies out of the box: rxnorm, icd-10-cm, loinc, snomed, hpo, mesh (and passes through any http(s):// URI unchanged). It is the single source of truth for vocab-id → system-URI mapping.

There is no to_condition() / to_observation() magic function. You build the resource shell (a small dict) and drop a codeable_concept(...) into its coded slot. That is by design: the resource type and clinical status are decisions OpenMed will not make for you.

Quick start: entity → Condition

python
import openmed
from openmed.clinical.exporters.codeable_concept_simple import coding, codeable_concept

# 1) NER (synthetic note — no real PHI)
result = openmed.analyze_text(
    "Assessment: type 2 diabetes mellitus, stable.",
    model_name="disease_detection_superclinical",
)
# result.entities -> EntityPrediction(text, label, confidence, start, end)
span = result.entities[0]            # e.g. text="type 2 diabetes mellitus"

# 2) Ground to a code OUT OF PROCESS (your terminology server / mapping table).
#    OpenMed bundles no restricted vocab — see querying-terminology-service.
icd_code, snomed_code = "E11.9", "44054006"

# 3) Build the CodeableConcept with OpenMed's builder
cc = codeable_concept(
    [
        coding("snomed", snomed_code, "Diabetes mellitus type 2"),
        coding("icd-10-cm", icd_code, "Type 2 diabetes mellitus without complications"),
    ],
    text=span.text,
)

# 4) Assemble the resource shell yourself
condition = {
    "resourceType": "Condition",
    "id": "cond-1",
    "clinicalStatus": {
        "coding": [{
            "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
            "code": "active",
        }]
    },
    "verificationStatus": {
        "coding": [{
            "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
            "code": "confirmed",
        }]
    },
    "category": [{
        "coding": [{
            "system": "http://terminology.hl7.org/CodeSystem/condition-category",
            "code": "encounter-diagnosis",
        }]
    }],
    "code": cc,                                  # OpenMed-built CodeableConcept
    "subject": {"reference": "Patient/patient-1"},
    "recordedDate": "2024-03-02",
}

codeable_concept sorts codings deterministically (SNOMED, LOINC, RxNorm, ICD-10-CM, HPO, MeSH first; everything else alphabetical), so the JSON is byte-stable across runs — important for diffable pipelines and golden tests.

Worked: the resulting Condition.code

json
{
  "code": {
    "coding": [
      { "system": "http://snomed.info/sct", "code": "44054006",
        "display": "Diabetes mellitus type 2" },
      { "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "E11.9",
        "display": "Type 2 diabetes mellitus without complications" }
    ],
    "text": "type 2 diabetes mellitus"
  }
}

Workflow

  1. NER — openmed.analyze_text(note, model_name=...) → result.entities.
  2. Classify each span: a disease label → Condition; a drug → MedicationStatement; a lab/vital/measurement → Observation.
  3. Ground the surface text to a code out of process (terminology server or your own map). Never invent codes; if you cannot ground a span, emit a CodeableConcept with only text and no coding.
  4. Build the CodeableConcept with coding(...) + codeable_concept(...).
  5. Wrap it in the resource shell (set clinicalStatus/status, subject, dates). Use the cheat-sheet below.
  6. Reference the Patient/Encounter via {"reference": "Patient/<id>"}.
  7. Pass the list to to_bundle(...) (assembling-fhir-bundles) and validate (validating-us-core).
Resource cheat-sheet (where the CodeableConcept goes)
OpenMed entity kindFHIR resourceCoded slotRequired status field
Disease / diagnosisConditioncodeclinicalStatus, verificationStatus
Drug / medicationMedicationStatementmedicationCodeableConceptstatus (e.g. active)
Lab / vital / findingObservationcode (+ valueQuantity/valueCodeableConcept)status (e.g. final)
ProcedureProcedurecodestatus
AllergyAllergyIntolerancecodeclinicalStatus
Show full SKILL.md (249 more words)Show less
MedicationStatement (drug span)
python
med = {
    "resourceType": "MedicationStatement",
    "id": "med-1",
    "status": "active",
    "medicationCodeableConcept": codeable_concept(
        [coding("rxnorm", "860975", "metformin hydrochloride 500 MG Oral Tablet")],
        text="metformin 500 mg",
    ),
    "subject": {"reference": "Patient/patient-1"},
}
Observation (lab/vital span)
python
obs = {
    "resourceType": "Observation",
    "id": "obs-1",
    "status": "final",
    "category": [{"coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/observation-category",
        "code": "laboratory",
    }]}],
    "code": codeable_concept(
        [coding("loinc", "4548-4", "Hemoglobin A1c/Hemoglobin.total in Blood")],
        text="HbA1c",
    ),
    "valueQuantity": {
        "value": 7.4, "unit": "%",
        "system": "http://unitsofmeasure.org", "code": "%",
    },
    "subject": {"reference": "Patient/patient-1"},
}

Hand-off to / from OpenMed

  • From OpenMed: result.entities (EntityPrediction.text/.label/.confidence /.start/.end) is the input. Keep confidence and the offsets in an extension or a side log so the resource is auditable back to the source span.
  • To OpenMed: before exporting a note that still contains PHI, run openmed.deidentify(...); or de-identify a built resource/Bundle with openmed.interop.fhir_operations.de_identify_resource / de_identify_bundle (see that module — it walks free-text + narrative and never touches codes, references, systems, or temporal values).
  • OperationOutcome: report any spans you could not map as OperationOutcomeIssue(severity="warning", code="incomplete", diagnostics=..., expression="Condition.code") → to_operation_outcome([...]). Keep diagnostics PHI-free (offsets/labels, never raw identifiers).

Edge cases & gotchas

  • No code? Still valid. A CodeableConcept with only text and no coding is legal R4. Emit it rather than inventing a code, and flag it via OperationOutcome. US Core may still require a code — see validating-us-core.
  • system_uri raises on an unknown short id that is not a URL. Pass a known short id (rxnorm/loinc/snomed/icd-10-cm/hpo/mesh) or a full http(s):// system URI.
  • Negation / temporality. OpenMed NER finds the mention, not its assertion. A negated ("no diabetes") or historical span should change verificationStatus/clinicalStatus or be dropped. Resolve assertion first (resolving-clinical-context, openmed.clinical).
  • Stable ids. Give each resource a unique id; to_bundle rejects duplicate ResourceType/id pairs because they corrupt cross-references.
  • Local-first. Grounding to RxNorm/LOINC/SNOMED is out-of-process with the user's own credentials. OpenMed bundles no restricted terminology.

Standards & references

© maziyarpanahi, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/exporting-to-fhir of maziyarpanahi/openmed.

Open the folder on GitHubat commit 34d7b8c

Compare with similar skills

Exporting To Fhir next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Exporting To Fhir compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Exporting To Fhir this skillmaziyarpanahi/openmed5.5k—~2.6kAutomated safety check: PassApache-2.0
Clinical Trials Databasegoogle-deepmind/science-skills3.2k2 repos~3.2kAutomated safety check: PassApache-2.0
CHARLS Paper Reproduction Guidexjtulyc/MedgeClaw6171 repos~1.8kAutomated safety check: PassNone
Biomedical Analysis Dispatchxjtulyc/MedgeClaw6171 repos~2kAutomated safety check: PassNone
Research Paperluwill/research-skills862—~1.9kAutomated safety check: PassNone
Research Proposalluwill/research-skills862—~4.5kAutomated safety check: NotesNone

Similar skills

  • Clinical Trials Database

    google-deepmind/science-skills

    Query ClinicalTrials.gov via APIv2. An agent skill from google-deepmind/science-skills.

    3.2k GitHub starsUsed in 2 repos~3.2k tokens
    Research & ScienceAuto-check passed
  • Guides an agent through reproducing papers built on the CHARLS health and retirement survey, from variable mapping to cognition, depression and isolation scores.

    617 GitHub starsUsed in 1 repo~1.8k tokens
    Research & ScienceAuto-check passed
  • Routes bioinformatics, drug discovery, clinical and multi-omics tasks from a chat interface to Claude Code sessions running K-Dense scientific skills, with a live dashboard per task.

    617 GitHub starsUsed in 1 repo~2k tokens
    Research & ScienceAuto-check passed
  • Research Paper

    luwill/research-skills

    A skill your agent uses when the user asks to write or draft an ORIGINAL RESEARCH ARTICLE — IMRaD paper, conference paper, short/workshop paper, 研究论文/期刊论文/会议论文 — reporting their own completed…

    862 GitHub stars~1.9k tokensUpdated yesterday
    Research & ScienceAuto-check passed
  • Research Proposal

    luwill/research-skills

    A skill your agent uses when the user asks to write or draft a PhD / doctoral research proposal, research plan, 研究计划书, or 开题报告 — a forward-looking plan of background, gap, research questions…

    862 GitHub stars~4.5k tokensUpdated yesterday
    Research & ScienceAuto-check: notes
  • Medical Imaging Review

    LeonChaoX/qinyan-academic-skills

    Write comprehensive literature reviews for medical imaging AI research.

    944 GitHub starsUsed in 3 repos~1.1k tokens
    Research & ScienceAuto-check: notes

More from maziyarpanahi/openmed

All 74 skills in this repo
  • Checks OpenMed de-identified clinical text against the 18 HIPAA Safe Harbor identifier categories and reports gaps and residual re-identification risk.

    5.5k GitHub stars~1.7k tokensUpdated today
    Auto-check passed
  • OpenMed Model Card Writer

    maziyarpanahi/openmed

    Fills in a model card for an OpenMed clinical NER or de-identification model from its evaluation reports: intended use, metrics, subgroups and limitations.

    5.5k GitHub stars~1.8k tokensUpdated today
    Auto-check passed
  • Walks a data pipeline against the HIPAA Privacy and Security Rule checklist and produces a gap report before it processes patient data.

    5.5k GitHub stars~2k tokensUpdated today
    Auto-check passed
  • ICD-10 Coding Assistant

    maziyarpanahi/openmed

    Suggests candidate ICD-10-CM diagnosis and ICD-10-PCS procedure codes for clinical text extracted by OpenMed, with rationale for a certified coder to review.

    5.5k GitHub stars~2k tokensUpdated today
    Auto-check passed
  • OpenMed ETL to OMOP CDM

    maziyarpanahi/openmed

    Maps OpenMed-extracted, terminology-coded conditions, drugs and measurements into OMOP CDM v5.4 tables for OHDSI and ATLAS analytics.

    5.5k GitHub stars~1.9k tokensUpdated today
    Auto-check passed
  • Extracting SDOH and Z-Codes

    maziyarpanahi/openmed

    Finds social risks such as housing instability or food insecurity in clinical notes and proposes matching ICD-10-CM Z-codes for a coder to confirm.

    5.5k GitHub stars~1.9k tokensUpdated today
    Auto-check passed

Questions about Exporting To Fhir

What does Exporting To Fhir do?

Convert OpenMed NER output (entities from openmed.analyzetext) into FHIR R4 resources — Condition, MedicationStatement, Observation — using OpenMed's built-in FHIR R4 export helpers in…. Exporting To Fhir is an agent skill from maziyarpanahi/openmed.exporters.

When should I use Exporting To Fhir?

Exporting To Fhir fits situations like: wants standards-conformant FHIR JSON; condition/Observation/MedicationStatement; codeableConcept; rxNorm/LOINC/ICD-10/SNOMED coding.

How do I install Exporting To Fhir in Claude Code?

Run `npx skills add maziyarpanahi/openmed --skill exporting-to-fhir -a claude-code`. Or copy the skill folder (skills/exporting-to-fhir in maziyarpanahi/openmed) into .claude/skills/exporting-to-fhir in your project. Claude Code loads it when a task matches its description.

How do I install Exporting To Fhir in Codex?

Run `npx skills add maziyarpanahi/openmed --skill exporting-to-fhir -a codex`. Or copy the skill folder (skills/exporting-to-fhir in maziyarpanahi/openmed) into .agents/skills/exporting-to-fhir in your project. Codex loads it when a task matches its description.

Can I use Exporting To Fhir in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add maziyarpanahi/openmed --skill exporting-to-fhir -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/exporting-to-fhir, .gemini/skills/exporting-to-fhir, .github/skills/exporting-to-fhir and .opencode/skills/exporting-to-fhir in your project.

What does Exporting To Fhir need to run?

SKILL.md names no scripts, command-line tools or credentials: Exporting To Fhir is instructions for the agent only. Our summary lists: Python 3.

Does Exporting To Fhir access the network?

SKILL.md names 4 domains. In commands or code: hl7.org, terminology.hl7.org, snomed.info and unitsofmeasure.org; the agent is likely to contact these when it follows the instructions. This is read from the text; nothing was executed.

Is Exporting To Fhir safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Exporting To Fhir use?

Exporting To Fhir is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Exporting To Fhir use?

About 2.6k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Exporting To Fhir?

Skills that share tags, products or a category with Exporting To Fhir: Clinical Trials Database (google-deepmind/science-skills, 3.2k stars), CHARLS Paper Reproduction Guide (xjtulyc/MedgeClaw, 617 stars), Biomedical Analysis Dispatch (xjtulyc/MedgeClaw, 617 stars) and Research Paper (luwill/research-skills, 862 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Exporting To Fhir?

maziyarpanahi (a GitHub user) maintains it in maziyarpanahi/openmed, which has 5,506 GitHub stars. The repository holds 74 skills in this directory. The repository was last updated on October 11, 2026.

Source: maziyarpanahi/openmed on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.