Klinik Veri Pipeline Mimarisi: HL7 FHIR, DICOM, OMOP CDM Köprüsü ve KVKK Uyumlu Akış

Klinik verinin kaos topografyası

Bir hastanenin bilgi sistem manzarası şöyle: HIS (Hospital Information System) hasta kayıtları ve faturalama, RIS (Radiology Information System) görüntüleme talepleri, PACS (Picture Archiving and Communication System) DICOM görüntüleri, LIS (Lab Information System) tahlil sonuçları, EMR (Electronic Medical Record) klinik notlar. Çoğu hastanede en az 5-10 farklı sistem var; bazıları aynı vendor'dan, çoğu farklı vendor'dan.

Bu sistemler arasında veri akar: doktor tetkik ister (HIS → RIS), radyolojide çekim yapılır (RIS → PACS), sonuç raporu yazılır (PACS/RIS → HIS), faturaya yansır (HIS → SUT bildirimi). Her geçiş bir entegrasyon noktasıdır.

Eğer araştırma veya yapay zeka için bu veriyi kullanmak istiyorsanız, bu kaos topografyasının üzerine bir pipeline kurmalısınız. Bu yazıda hangi standartlar var, hangisi ne zaman, KVKK uyumu nasıl korunur açıklıyorum.

Katman 1: HL7 v2, hala temel mesajlaşma

HL7 v2 (1989'dan beri) hastane sistemlerinde en yaygın mesaj formatı. Türkiye'de kamu ve özel hastanelerin yaklaşık %80'i HL7 v2.5 veya v2.6 ile çalışıyor. Pipe-delimited (|) format, hızlı, ama parsing'i hatalı kolay.

Tipik mesaj tipleri:

• ADT (Admission, Discharge, Transfer): Hasta hareket bilgisi
• ORM (Order Message): Tetkik / işlem talebi
• ORU (Observation Result): Lab veya görüntüleme sonucu
• MDM (Medical Document Management): Klinik döküman

Örnek bir ADT mesajı:

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

Parsing için Mirth Connect, HAPI HL7, NextGen Connect tipik araçlar. Mirth açık kaynak, Türkiye hastanelerinde sık tercih edilen entegrasyon motoru.

Tipik tuzaklar:

• Custom Z segment'ler (örnek: ZIN, ZRT): vendor'un kendi eklediği non-standard alanlar
• Karakter encoding karışıklığı (UTF-8 vs ISO-8859-9 Türkçe karakter)
• TC kimlik numarası alanına Pasaport veya geçici numara karışması

Katman 2: FHIR, yeni nesil standart

FHIR (Fast Healthcare Interoperability Resources, R5 güncel) HL7'nin modern REST API tabanlı versiyonu. JSON / XML formatı, web standartlarına uygun, mobile ve cloud-friendly.

FHIR'de her şey "Resource". Patient, Observation, Encounter, Medication, DiagnosticReport, ImagingStudy. Her resource'un standardize bir şeması var, ID üzerinden bağlanır.

Örnek 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"
}

Türkiye'de FHIR durumu:

• e-Nabız platformu FHIR R4 tabanlı
• Sağlık Bakanlığı USS (Ulusal Sağlık Sistemi) FHIR migration sürecinde
• Yeni hastane yazılımları (özellikle EPIC, Cerner Türkiye implementasyonları) FHIR endpoint sunuyor
• Eski sistemler HL7 v2 → FHIR proxy (örnek: HAPI FHIR HL7 v2 to FHIR converter) ile köprülenir

Pratik öneri: Yeşil alan (greenfield) projelerde doğrudan FHIR. Brownfield (mevcut hastane entegrasyonu) projelerde HL7 v2 alır, kendi pipeline'ınızda FHIR'a dönüştürürsünüz.

Katman 3: DICOM, görüntüleme dünyası

Tıbbi görüntü için DICOM (Digital Imaging and Communications in Medicine) tek standart. Her CT, MR, X-ray, ultrason, mammografi DICOM dosyası üretir.

DICOM iki bilgi taşır:

• Pixel data: Görüntü matrisi (CT'de Hounsfield Unit, MR'da signal intensity)
• Metadata: Hasta bilgisi, çekim parametreleri, cihaz bilgisi (3000+ DICOM tag)

PACS'tan DICOM çekme protokolleri:

• C-FIND: Query (hangi study'ler var)
• C-MOVE / C-GET: Retrieve (study indir)
• DICOMweb (WADO-RS, QIDO-RS, STOW-RS): REST API üzerinden, modern alternatif

Tipik kütüphaneler:

• pydicom: Python, DICOM parsing ve manipülasyon
• dcm4che: Java, full DICOM toolkit
• Orthanc: Open-source mini PACS, araştırma için pratik
• OHIF Viewer: Web tabanlı görüntüleyici, Cornerstone3D üzerine

PHI sorunu: DICOM metadata'da hasta bilgisi açık. Anonymization için DICOM PS3.15 Annex E standardı:

• PatientName, PatientID, PatientBirthDate vb. kaldırılır veya pseudonimleştirilir
• StudyInstanceUID, SeriesInstanceUID yeniden üretilir (bağlantı kaybolmasın diye mapping tablosu tutulur, ayrı saklanır)
• Burned-in annotation (görüntü piksellerinde yazılı hasta adı) için pixel-level redaction
• DICOM Toolkit Anonymizer veya GDCM AnonymizeFiles standart araçlar

Katman 4: OMOP CDM, araştırma için ortak model

HL7 v2, FHIR, DICOM hep iletim ve depolama standartları. Araştırma için ek bir katman gerekir: ortak veri modeli (Common Data Model). OMOP CDM (OHDSI birliği) bunun global standardıdır.

OMOP CDM neden gerekli:

• Aynı tanı farklı hastanede farklı kodla yazılır (ICD-10, ICD-11, SNOMED CT, lokal kodlar)
• Aynı lab farklı birim ve referans aralığıyla
• Aynı ilaç farklı isim ve doz ile

OMOP bu çeşitliliği standart concept ID'lere mapler. Vocabulary OMOP'un kalbi: Athena terminoloji portalı 1.2 milyon kavramı içerir.

Tipik OMOP tabloları:

• person: hasta (gender_concept_id, year_of_birth, race_concept_id)
• visit_occurrence: ziyaret (visit_concept_id: inpatient, outpatient, ER)
• condition_occurrence: tanı (condition_concept_id, SNOMED CT)
• procedure_occurrence: işlem (procedure_concept_id, CPT/ICD-PCS)
• drug_exposure: ilaç (drug_concept_id, RxNorm)
• measurement: lab/vital (measurement_concept_id, LOINC)
• observation: diğer kayıt (sigara öyküsü, alerji)

ETL süreci:

1. Source extraction (HIS, lab, görüntüleme)
2. Source vocabulary identification (hangi kod sistemi)
3. Mapping to OMOP concepts (USAGI tool veya manuel)
4. Load to OMOP tables
5. Data Quality Dashboard (Achilles, DQD)

Türkiye'de OMOP adaptasyonu:

• SUT kodları (Türkiye spesifik) OMOP'a mapping çalışması başladı (TÜBİTAK 1003 destek)
• Birkaç üniversite hastanesi (Hacettepe, Koç) pilot OMOP instance'ları kurdu
• İlaç için RxNorm yerine yerel ilaç kodu mapping problemi açık

OMOP'un yapay zeka için değeri: çok merkezli, ortak şemalı veri seti üretebilirsiniz. Federated query (DataBricks, Atlas, ARACHNE tool'ları) ile veri merkez dışına çıkmadan analiz yapılır.

Katman 5: Veri kalitesi ve eşleştirme

Pipeline'ın en az glamour'lı ama en kritik katmanı. Üç problem:

1. Patient matching (kişi eşleştirme): Aynı hasta farklı sistemlerde farklı ID ile (HIS'te 12345, lab sisteminde A7-12345, PACS'ta Patient_001). Master Patient Index (MPI) kurulumu gerekir. Deterministic matching (TC kimlik tam eşleşmesi) + probabilistic matching (isim + doğum tarihi + cinsiyet kombinasyonu) hibrit.

2. Terminology mapping (kod eşleştirme): ICD-10 G56.0 (HIS'te yazılı) → SNOMED CT 57406009 (OMOP'ta). Bu mapping manuel başlar, USAGI gibi araçla yarı otomatik genişler. Tipik bir hastane için 5-10 bin kod mapping gerekir.

3. Deduplication: Aynı tahlil iki kez kayıtlı (manuel + otomatik), aynı tanı tekrar girilmiş, aynı vizit iki kayıt. Bu temizlik query-time veya ETL-time yapılır.

Veri kalitesi metrikleri (DQD):

• Completeness: % null değer
• Conformance: format uyumu
• Plausibility: mantıksız değer (yaş = 250, boy = 50cm)

Tipik beklenen score: %90+ completeness, %95+ conformance, %98+ plausibility.

KVKK uyumlu mimari kararlar

KVKK'ya göre sağlık verisi özel nitelikli kişisel veri. Pipeline tasarımında üç temel karar:

1. Anonimleştirme mi pseudonimleştirme mi?

• Anonimleştirme: kişi geri tanımlanamaz (k-anonymity, l-diversity), KVKK kapsamında "kişisel veri" sayılmaz
• Pseudonimleştirme: kişi kimlik gizlendi ama mapping tablosu var, hala kişisel veri sayılır

Araştırma için genelde pseudonimleştirme yeterlidir, etik kurul izni + DPA ile. Klinik karar destekte (DSS) gerçek kişi tanımlı veri, sıkı erişim kontrolü ile kullanılır.

2. Veri yerinde mi merkezi mi? Federated learning (veri taşınmıyor, model gidiyor) KVKK-dostudur. Tek merkez merkezi (data lake) modeli için DPA, ISO 27001, KVKK envanteri zorunlu.

3. Aktarım ve depolama şifreleme

• In-transit: TLS 1.3, mTLS hastane-cloud arası
• At-rest: AES-256, key management (KMS) ayrı sistem
• Database column-level encryption hassas alanlar için (TCKN)

Cross-border transfer: KVKK 9. madde: yurtdışı aktarım için açık rıza veya KVK Kurulu izni. AWS Frankfurt, Azure West Europe gibi AB içi bölgeler bile KVKK kapsamında "yurtdışı". Çözüm: Türkiye lokasyonu (AWS İstanbul region geldi 2026, Azure Türkiye sınırlı). Veya tüm pipeline on-premise.

Pratik bir pipeline çizimi

Tipik bir hastane → araştırma 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)
Araştırma data mart (Parquet + DuckDB / Spark)
    ↓
AI training pipeline / İstatistiksel analiz / Cohort discovery

Bu mimarinin tipik setup süresi 3-6 ay, maliyet 20-100 bin USD (kapsam ve veri hacmi bağımlı). Kurulum sonrası operasyon ekibi 1-2 kişi.

Pratik çekirdek kontrol listesi

Bir klinik veri pipeline'ı sağlıklı kurmak için:

• Kaynak sistem envanteri ve versiyon bilgisi
• HL7 v2 mesaj örnekleri ve Z-segment dokümantasyonu
• DICOMweb endpoint testi
• FHIR R4/R5 server seçimi (HAPI, Microsoft FHIR, Aidbox)
• Master Patient Index stratejisi
• Terminology mapping plan (USAGI, manuel review)
• OMOP CDM schema deployment
• Data Quality Dashboard (Achilles + DQD)
• KVKK uyumlu DPA imzalandı mı
• Anonymization protokolü onaylandı mı (etik kurul)
• Encryption in-transit ve at-rest aktif
• Audit log (kim hangi veriye eriştiği)
• DR (disaster recovery) plan

Sık yapılan üç hata

Hata 1: "Tüm veriyi alalım sonra düşünürüz" yaklaşımı. Önce kullanım senaryosu (use case), sonra pipeline. 5-10 milyon satır data lake kurup hiç sorgulamamak para ve enerji kaybı.

Hata 2: Anonymization'ı son ana bırakmak. PHI içeren ham veriyi merkezi depoya alıp sonra anonymize etmek hem KVKK riskli hem teknik olarak zor. Mümkün olduğunca source-side anonymization.

Hata 3: Vendor lock-in. Hospital information system vendor'ın "extract API'mizi kullan, biz size CSV veriyoruz" teklifi cazip görünür. Ama vendor değişince pipeline'ınız sıfırlanır. Standart formatlar (FHIR, OMOP) üzerinden çalışmak uzun vadeli yatırımdır.

Klinik veri pipeline için Serteser Danışmanlık desteği

Hastane ve şirketler için klinik veri mühendisliği uzun erimli bir yatırım. Serteser Danışmanlık şu alanlarda destek sunar:

• Mevcut sistem envanteri ve entegrasyon mimarisi planlama
• HL7 v2 / FHIR mapping ve Mirth Connect kanalları
• DICOMweb pipeline kurulumu, anonymization protokolü
• OMOP CDM ETL, vocabulary mapping
• Data Quality Dashboard ve sürekli kalite metriği
• KVKK uyumlu DPA, anonymization, erişim kontrolü mimarisi
• Araştırma için curated extract (cohort discovery, AI training set)
• Etik kurul başvurusu için veri akış şeması

The Orthopaedic Journal of Sports Medicine'de yayınlanmış uluslararası hakemli klinik araştırma deneyimi ve PROSPERO kayıtlı aktif sistematik derleme yönetimi ile veri mühendisliği + klinik metodoloji iki disiplini birlikte kuran araştırma altyapısıyla, klinik veri pipeline projelerinde uçtan uca destek sağlıyoruz.