Skip to content
Contact

Interoperability

Healthcare data exchange with an explicit contract

SEYON implements FHIR, HL7 v2, C-CDA, and DICOM patterns as technology services. These are capabilities, not official HL7, DICOM, or other certifications.

Standards

Standards overview

  • FHIR

    HL7 FHIR resources exposed through REST APIs, commonly as JSON or XML, including FHIR R4. Profiles and extensions capture local constraints. Terminology maps keep codes comparable.

  • HL7 v2

    ADT, ORU, and ORM messages carried over MLLP or another agreed transport. Parsing, validation, routing, and transformation keep the feed operable.

  • C-CDA

    XML clinical documents used for summaries and exchange. Work focuses on document structure, section extraction, and transformation into a reviewed model.

  • DICOM

    Medical imaging data and metadata, including how imaging studies relate to the clinical record and to PACS workflows.

Exchange

How the channels fit together

Healthcare data exchange

Source clinical systems
Integration services
  • FHIR R4 APIs
  • HL7 v2 messages
  • C-CDA documents
  • DICOM metadata

Downstream applications and analytics consume the channel that matches the workflow. The diagram is a pattern, not a claim about a specific customer network.

Active channel: FHIR R4 APIs

FHIR API integration

A practical FHIR R4 API starts with the resources a consumer needs. Patient, Observation, Encounter, Practitioner, Organization, DiagnosticReport, and DocumentReference cover many first releases. Authentication and authorization are designed with the identity platform already in place. OAuth 2.0 and SMART on FHIR are common patterns, selected per deployment rather than assumed.

FHIR R4 Patient resourceSynthetic sample
{
  "resourceType": "Patient",
  "id": "example-001",
  "meta": {
    "tag": [
      {
        "system": "https://example.org/tags",
        "code": "synthetic",
        "display": "Synthetic example"
      }
    ]
  },
  "identifier": [
    {
      "system": "https://example.org/mrn",
      "value": "E00000001"
    }
  ],
  "name": [
    {
      "use": "official",
      "family": "Example",
      "given": ["Sample"]
    }
  ],
  "gender": "unknown",
  "birthDate": "1980-01-01"
}

Synthetic example for illustration. Do not send real patient information through demonstration APIs.

HL7 v2 workflow

An ADT message signals an admission, discharge, or transfer. An ORU message carries results. An ORM message carries an order. The MSH segment identifies the message. PID and PV1 carry the patient and visit context the receiver must validate. MLLP is a common way to carry the message. Parsing respects separators, validation checks required fields, and routing applies the transformation for that destination.

Synthetic ADT A01 messageSynthetic sample
MSH|^~\&|SAMPLE_SENDER|SAMPLE_CLINIC|SAMPLE_RECEIVER|SAMPLE_HOSPITAL|20260315103045||ADT^A01|MSG00001001|P|2.5.1
EVN|A01|20260315103045
PID|1||E00000001^^^SAMPLE^MR||EXAMPLE^PATIENT||19800101|U
PV1|1|O|CLINIC^ROOM1^BED1

A fictional ADT^A01 message. Identifiers and names are placeholders, not a patient record.

C-CDA to FHIR

An example conversion flow

A Continuity of Care Document arrives as XML. Structured sections are mapped into a FHIR R4 document Bundle, and the original document stays attached. This is an illustrative pattern, not a complete specification or a certification.

Worked example

C-CDA to FHIR transformation

Synthetic sample
  1. 1

    Input: C-CDA

    A clinical document arrives as XML, such as a discharge summary or a patient summary.

    C-CDA

    <ClinicalDocument>
  <recordTarget>
    ...
  </recordTarget>
</ClinicalDocument>
  2. 2

    Parse and validate

    The XML is checked, then the header and the sections the receiver will use are extracted.

    • Schema checks
    • Section extraction
    • Required header fields
  3. 3

    Transform to FHIR

    Structured entries are mapped to FHIR R4 resources. The mapping cites the source field.

    Mapping

    Codes, identifiers, and sections

    • Patient
    • Encounter
    • Observation
    • MedicationRequest
    • CarePlan
  4. 4

    Validate FHIR

    The Bundle is checked against the FHIR R4 shape and the profile agreed for that interface.

    Profile and reference checks

    • FHIR R4 structure
    • Agreed profile
    • References between resources
  5. 5

    Output: FHIR

    The result is a FHIR R4 document Bundle the receiving API can read, with the original C-CDA still attached.

    • Patient
    • Encounter
    • Observation
    • MedicationRequest
    • CarePlan

Running step 1: Input: C-CDA

  1. C-CDA
  2. Parse and validate
  3. Transform
  4. Validate
  5. FHIR

A structured section becomes the FHIR resource that preserves its meaning. Narrative without a code stays on the Composition for review.

Section mapping

  • C-CDA

    Document header

    Patient, author, custodian, and encounter

    FHIR R4

    Patient, Practitioner, Organization, Encounter

    Identity and visit context

    Document header maps to Patient, Practitioner, Organization, Encounter.

  • C-CDA

    Problems

    Problem observation entries

    FHIR R4

    Condition

    Code, clinical status, and onset when present

    Problems maps to Condition.

  • C-CDA

    Medications

    Medication activity entries

    FHIR R4

    MedicationRequest

    Medication, intent, and dosage when present

    Medications maps to MedicationRequest.

  • C-CDA

    Allergies

    Allergy and intolerance concerns

    FHIR R4

    AllergyIntolerance

    Substance, reaction, and criticality when present

    Allergies maps to AllergyIntolerance.

  • C-CDA

    Results

    Result organizer and observations

    FHIR R4

    DiagnosticReport and Observation

    Value, unit, and the report that groups them

    Results maps to DiagnosticReport and Observation.

  • C-CDA

    The document

    Source XML kept intact

    FHIR R4

    Composition and DocumentReference

    A link back to the original C-CDA

    The document maps to Composition and DocumentReference.

Narrative without a code

A social-history paragraph with no coded entry stays attached to the Composition and is queued for review. The conversion keeps the text and leaves the code for a person to supply.

Illustrative Bundle contents

  1. Composition
  2. Patient
  3. Encounter
  4. Condition
  5. MedicationRequest
  6. AllergyIntolerance
  7. DiagnosticReport
  8. Observation
  9. CarePlan
  10. DocumentReference

This list is the shape of the output. Identifiers in a shared demo stay synthetic.

C-CDA documents

C-CDA clinical documents are XML. A patient summary has a header and sections such as problems, medications, allergies, and results. Extraction should target the sections the receiving system will use and keep a link back to the source document. Narrative that was never structured stays visible as an exception instead of being forced into a code.

DICOM and imaging

DICOM describes medical imaging data and the communication patterns around it. Integration work may cover imaging metadata, references from the clinical record to a study, and the workflow between a modality, a PACS, and downstream systems. SEYON does not present this as a certified imaging product. Sample designs use illustrative study descriptions, never real images of patients.

  1. 1Modality produces a study
  2. 2PACS stores images and metadata
  3. 3Metadata is mapped for downstream use
  4. 4The EHR or application keeps a reference

Delivery

Interoperability challenges and solutions

Build your healthcare integration strategy

Bring the systems, the message types, and the consumers. SEYON will help define a contract that can be tested with synthetic data.

Build Your Healthcare Integration Strategy