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:

# 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
)