Clinical Data Pipeline: HL7 FHIR, DICOM, OMOP

The chaotic topography of clinical data

A hospital's information system landscape looks like this: HIS (Hospital Information System) for patient records and billing, RIS (Radiology Information System) for imaging orders, PACS (Picture Archiving and Communication System) for DICOM images, LIS (Lab Information System) for test results, EMR (Electronic Medical Record) for clinical notes. Most hospitals have at least 5-10 different systems; some from the same vendor, most from different vendors.

Data flows between these systems: a doctor orders a test (HIS to RIS), imaging is performed in radiology (RIS to PACS), a result report is written (PACS/RIS to HIS), and it is reflected on the bill (HIS to SUT notification). Each transition is an integration point.

If you want to use this data for research or artificial intelligence, you must build a pipeline on top of this chaotic topography. In this article I explain which standards exist, which one applies when, and how KVKK compliance is preserved.

Layer 1: HL7 v2, still the foundational messaging

HL7 v2 (since 1989) is the most widespread message format in hospital systems. In Turkey, roughly 80% of public and private hospitals run on HL7 v2.5 or v2.6. It is a pipe-delimited (|) format, fast, but easy to parse incorrectly.

Typical message types:

• ADT (Admission, Discharge, Transfer): Patient movement information
• ORM (Order Message): Test / procedure order
• ORU (Observation Result): Lab or imaging result
• MDM (Medical Document Management): Clinical document

An example ADT message:

MSH|^~\&|HIS|HOSPITAL|EMR|HOSPITAL|20260515103022||ADT^A01|MSG001|P|2.5
PID|1||12345678901^^^TC||SOYAD^AD||19850315|F
PV1|1|I|CARDIOLOGY^301^1|||ATTENDING_DR|||CARDIO||||1|||||V001

Typical tools for parsing include Mirth Connect, HAPI HL7, and NextGen Connect. Mirth is open source and a frequently preferred integration engine in Turkish hospitals.

Typical pitfalls:

• Custom Z segments (for example: ZIN, ZRT): non-standard fields added by the vendor itself
• Character encoding confusion (UTF-8 vs ISO-8859-9 for Turkish characters)
• A Passport or temporary number ending up in the TC identity number field

Layer 2: FHIR, the new-generation standard

FHIR (Fast Healthcare Interoperability Resources, R5 current) is HL7's modern REST API-based version. JSON / XML format, aligned with web standards, mobile and cloud-friendly.

In FHIR, everything is a "Resource". Patient, Observation, Encounter, Medication, DiagnosticReport, ImagingStudy. Each resource has a standardized schema and is linked via an ID.

Example Patient resource:

{
  "resourceType": "Patient",
  "id": "patient-001",
  "identifier": [{
    "system": "https://fhir.saglik.gov.tr/tckn",
    "value": "12345678901"
  }],
  "name": [{ "family": "Soyad", "given": ["Ad"] }],
  "gender": "female",
  "birthDate": "1985-03-15"
}

The state of FHIR in Turkey:

• The e-Nabiz platform is FHIR R4-based
• The Ministry of Health's USS (National Health System) is in the FHIR migration process
• New hospital software (particularly EPIC, Cerner Turkey implementations) offers FHIR endpoints
• Legacy systems are bridged with an HL7 v2 to FHIR proxy (for example, the HAPI FHIR HL7 v2 to FHIR converter)

Practical recommendation: In greenfield projects, go directly to FHIR. In brownfield projects (integrating an existing hospital), you take in HL7 v2 and convert it to FHIR within your own pipeline.

Layer 3: DICOM, the imaging world

For medical images, DICOM (Digital Imaging and Communications in Medicine) is the single standard. Every CT, MR, X-ray, ultrasound, and mammography produces a DICOM file.

DICOM carries two kinds of information:

• Pixel data: The image matrix (Hounsfield Units in CT, signal intensity in MR)
• Metadata: Patient information, acquisition parameters, device information (3000+ DICOM tags)

Protocols for retrieving DICOM from PACS:

• C-FIND: Query (which studies exist)
• C-MOVE / C-GET: Retrieve (download study)
• DICOMweb (WADO-RS, QIDO-RS, STOW-RS): Over a REST API, a modern alternative

Typical libraries:

• pydicom: Python, DICOM parsing and manipulation
• dcm4che: Java, full DICOM toolkit
• Orthanc: Open-source mini PACS, practical for research
• OHIF Viewer: Web-based viewer, built on Cornerstone3D

The PHI problem: Patient information is exposed in DICOM metadata. For anonymization, the DICOM PS3.15 Annex E standard:

• PatientName, PatientID, PatientBirthDate and similar are removed or pseudonymized
• StudyInstanceUID, SeriesInstanceUID are regenerated (a mapping table is kept and stored separately so the link is not lost)
• Pixel-level redaction for burned-in annotations (patient names written into the image pixels)
• DICOM Toolkit Anonymizer or GDCM AnonymizeFiles are standard tools

Layer 4: OMOP CDM, a common model for research

HL7 v2, FHIR, and DICOM are all transmission and storage standards. Research requires an additional layer: a Common Data Model. OMOP CDM (the OHDSI collaboration) is its global standard.

Why OMOP CDM is needed:

• The same diagnosis is written with a different code at different hospitals (ICD-10, ICD-11, SNOMED CT, local codes)
• The same lab test comes with different units and reference ranges
• The same drug comes with a different name and dose

OMOP maps this diversity to standard concept IDs. The vocabulary is the heart of OMOP: the Athena terminology portal contains 1.2 million concepts.

Typical OMOP tables:

• person: patient (gender_concept_id, year_of_birth, race_concept_id)
• visit_occurrence: visit (visit_concept_id: inpatient, outpatient, ER)
• condition_occurrence: diagnosis (condition_concept_id, SNOMED CT)
• procedure_occurrence: procedure (procedure_concept_id, CPT/ICD-PCS)
• drug_exposure: drug (drug_concept_id, RxNorm)
• measurement: lab/vital (measurement_concept_id, LOINC)
• observation: other records (smoking history, allergy)

The ETL process:

1. Source extraction (HIS, lab, imaging)
2. Source vocabulary identification (which code system)
3. Mapping to OMOP concepts (USAGI tool or manual)
4. Load to OMOP tables
5. Data Quality Dashboard (Achilles, DQD)

OMOP adaptation in Turkey:

• Work on mapping SUT codes (Turkey-specific) to OMOP has begun (with TUBITAK 1003 support)
• A few university hospitals (Hacettepe, Koc) have set up pilot OMOP instances
• For drugs, the problem of mapping local drug codes instead of RxNorm remains open

OMOP's value for artificial intelligence: you can produce a multi-center dataset with a common schema. With federated query (DataBricks, Atlas, ARACHNE tools), analysis is performed without the data leaving the center.

Layer 5: Data quality and matching

The pipeline's least glamorous but most critical layer. Three problems:

1. Patient matching: The same patient exists in different systems with different IDs (12345 in HIS, A7-12345 in the lab system, Patient_001 in PACS). A Master Patient Index (MPI) setup is required. A hybrid of deterministic matching (exact TC identity match) + probabilistic matching (a combination of name + birth date + gender).

2. Terminology mapping (code matching): ICD-10 G56.0 (written in HIS) to SNOMED CT 57406009 (in OMOP). This mapping starts out manual and expands semi-automatically with a tool like USAGI. For a typical hospital, mapping 5,000-10,000 codes is required.

3. Deduplication: The same test recorded twice (manual + automatic), the same diagnosis entered again, the same visit recorded twice. This cleanup is done at query-time or ETL-time.

Data quality metrics (DQD):

• Completeness: % null values
• Conformance: format compliance
• Plausibility: implausible values (age = 250, height = 50 cm)

Typical expected scores: 90%+ completeness, 95%+ conformance, 98%+ plausibility.

KVKK-compliant architectural decisions

Under KVKK, health data is a special category of personal data. Three fundamental decisions in pipeline design:

1. Anonymization or pseudonymization?

• Anonymization: the individual cannot be re-identified (k-anonymity, l-diversity), and it is not considered "personal data" under KVKK
• Pseudonymization: the individual's identity is concealed but a mapping table exists, so it is still considered personal data

For research, pseudonymization is generally sufficient, with ethics committee approval + a DPA. In clinical decision support (DSS), real identified data is used with strict access control.

2. Data in place or centralized? Federated learning (data does not move, the model travels) is KVKK-friendly. For a single-center centralized (data lake) model, a DPA, ISO 27001, and a KVKK inventory are mandatory.

3. Transmission and storage encryption

• In-transit: TLS 1.3, mTLS between hospital and cloud
• At-rest: AES-256, key management (KMS) as a separate system
• Database column-level encryption for sensitive fields (TCKN)

Cross-border transfer: KVKK Article 9: explicit consent or KVK Board approval is required for transfer abroad. Even EU-internal regions such as AWS Frankfurt and Azure West Europe count as "abroad" under KVKK. The solution: a Turkey location (the AWS Istanbul region arrived in 2026, Azure Turkey is limited). Or keep the entire pipeline on-premise.

Sketch of a practical pipeline

A typical hospital to research pipeline:

HIS, LIS, RIS, PACS
    ↓ (HL7 v2 / DICOMweb)
Mirth Connect / DICOMweb proxy
    ↓ (FHIR R5)
FHIR persistent store (HAPI FHIR + PostgreSQL)
    ↓ (anonymization + ETL)
OMOP CDM (PostgreSQL + Athena vocabulary)
    ↓ (curated extract)
Research data mart (Parquet + DuckDB / Spark)
    ↓
AI training pipeline / Statistical analysis / Cohort discovery

The typical setup time for this architecture is 3-6 months, at a cost of 20,000-100,000 USD (depending on scope and data volume). After setup, an operations team of 1-2 people.

Practical core checklist

To set up a clinical data pipeline soundly:

• Source system inventory and version information
• HL7 v2 message samples and Z-segment documentation
• DICOMweb endpoint test
• FHIR R4/R5 server selection (HAPI, Microsoft FHIR, Aidbox)
• Master Patient Index strategy
• Terminology mapping plan (USAGI, manual review)
• OMOP CDM schema deployment
• Data Quality Dashboard (Achilles + DQD)
• Has a KVKK-compliant DPA been signed
• Has the anonymization protocol been approved (ethics committee)
• Encryption in-transit and at-rest active
• Audit log (who accessed which data)
• DR (disaster recovery) plan

Three common mistakes

Mistake 1: The "let's take all the data and figure it out later" approach. First the use case, then the pipeline. Building a 5-10 million row data lake and never querying it is a waste of money and energy.

Mistake 2: Leaving anonymization to the last moment. Bringing raw PHI-containing data into central storage and then anonymizing it is both KVKK-risky and technically difficult. Do source-side anonymization as much as possible.

Mistake 3: Vendor lock-in. The hospital information system vendor's offer of "use our extract API, we'll give you CSV" looks appealing. But when the vendor changes, your pipeline is reset to zero. Working through standard formats (FHIR, OMOP) is a long-term investment.

Serteser Danismanlik support for clinical data pipelines

For hospitals and companies, clinical data engineering is a long-range investment. Serteser Danismanlik provides support in the following areas:

• Existing system inventory and integration architecture planning
• HL7 v2 / FHIR mapping and Mirth Connect channels
• DICOMweb pipeline setup, anonymization protocol
• OMOP CDM ETL, vocabulary mapping
• Data Quality Dashboard and continuous quality metrics
• KVKK-compliant DPA, anonymization, and access control architecture
• Curated extracts for research (cohort discovery, AI training sets)
• Data flow diagrams for ethics committee applications

With international peer-reviewed clinical research experience published in an international peer-reviewed journal and active management of PROSPERO-registered systematic reviews, backed by a research infrastructure that combines the two disciplines of data engineering + clinical methodology, we provide end-to-end support in clinical data pipeline projects.

For support with your research data infrastructure, you can review our academic consulting services.