HEALTHCARE DATA EXCHANGE STANDARDS PERTEMUAN-5 NOVIANDI PRODI MIK | FAKULTAS ILMU-ILMU KESEHATAN

Healthcare Data Exchange Standards Dalam bab ini kita akan mempelajari standar pertukaran data dari sudut pandang teknis, dengan fokus pada pendekatan kesesuaian yang di gunakan untuk setiap standar. Bab ini menyajikan contoh standar pertukaran data perawatan kesehatan yang paling umum digunakan dan umum dari berbagai kategori. Mulai dari Hl versi 2.x dan FHIR ( fast healthcare interoperability resources) yang di tentukan oleh HL7 international. Dalam bab ini juga ada EDIFACT sebagai tandre pertukaran data yang digunakan di eropa dalam perawatan kesehatan. EbXML adalah fondasi untuk THE(digunakan untuk mengintegrasikan kesehatan enterprise) dan ITI (Information Technology Infrastructure ) Beberapa standar pertukaran data kesehatan tambahan di sajikan antara lain: HL7 Version 3 HL7CDA (Arsitektur dokumen klinis) ASTM (american society for testing and materials) DICOM (Digital imaging ang communications in medicine dan keluarga Xdt)

HL 7 v 2.x Versi pertama HL7 v2.x dirilis lebih dari 20 tahun yang lalu. Sejak saat itu, sejumlah besar perangkat tambahan telah diterapkan pada v2.x, termasuk model komponen untuk tipe data, profil kesesuaian, kondisi spesifikasi, struktur pesan, pengelompokan segmen, dan penanganan panjang, untuk beberapa nama. Prinsipnya, HL7 v2.x belakangan ini sesuai  mengeluarkan yang berbeda mewakili dalam pengembangan standar. 

HL 7 v 2.x Namun, dalam beberapa kasus, masalah muncul terkait dengan pemrosesan pesan yang didasarkan pada persyaratan yang diartikan dalam versi sebelumnya. Salah satu masalah ini melibatkan berkurangnya elemen (unsur) data yang ada dalam versi baru, yang membutuhkan konten sebelumnya menampung elemen data dalam pesan HL7 untuk dipindahkan ke bidang lain (elemen data).

Model Informasi Keseluruhan model informasi 1 HL7 v2.x, yang diciptakan dengan teknik mengubah standar HL7 v2, Informasi ini mencakup semua komponen penting dan, dengan cara itu, mencakup komponen-komponen yang terkait dengan kesesuaian. Unsur-unsur yang terdapat dalam model ini bersangkutan untuk diskusi kesesuaian yang dijelaskan secara rinci pada subbagian.  

Struktur Pesan HL7 Version 2.x adalah standar pertukaran data yang berorientasi pesan, yaitu tujuan utamanya adalah pertukaran pesan. Gambar 4.3 berisi resmi mewakili HL7 v2.x. Jika kelas berorientasi pesan dihapus, menyederhanakannya dengan hanya menampilkan kelas yang sesuai yang mencakup pesan. Struktur pesan terdiri dari urutan bagian dan kelompok bagian. Setiap bagian terdiri dari sekumpulan bidang yang diurutkan secara berurutan, masing-masing memiliki tipe data yang menentukan komponen dan secara iteratif, subkomponen. HL7 v2.x menggunakan pilihan (penggunaan), panjang, pengulangan (kardinalitas), dan membuat tabel yang sesuai.

Optionallity HL7 v2x menggunakan konsep opsional (penggunaan) 1 untuk segmen (kelompok), bidang, komponen dan subkomponen. Elemen yang ditandai sebagai "R" (wajib) harus muncul dalam sebuah pesan dan harus memiliki kebenaran . Kehadiran elemen kondisional (C) dalam sebuah pesan tergantung pada kondisi tertentu yang dapat dievaluasi dengan menggunakan nilai-nilai yang ada pada elemen lain dalam pesan yang sama.

Pengkodean Pesan v2.x HL7 memanfaatkan seperangkat pembatas dan indikator penanganan khusus / karakter yang ditetapkan secara hirarki. Pesan harus dipisahkan menjadi bagian-bagian dengan menggunakan pembatas (dan karakter khusus) dalam urutan disajikan di bawah ini: Yang pertama lima konsep dalam daftar di atas adalah pembatas dan harus digunakan memisahkan bagian-bagian dari pesan. Konsep keenam adalah pembatas yang digunakan untuk menyatakan karakter yang memperkenalkan urutan khusus ketika karakter harus diwakili sehingga merupakan pembatas. Unsur terakhir dalam daftar di atas bukanlah pembatas melainkan karakter khusus.  Hal ini dapat digunakan pada akhir nilai untuk dapat menunjukkan bahwa nilainya terpotong baik ketika disimpan didalam data base pengirim saat membuat pesan.

Pembatasan Sisi kiri dari model informasi biasanya memuat gambar menunjukkan penggunaan pembatas yang penting untuk pengkodean yang benar. Seperti dapat dilihat, sebagian besar pembatas memungkinkan karakter variabel. Ini awalnya diperkenalkan untuk membantu sistem sebelumnya yang tidak dapat mendukung pembatas default; pembatas segmen adalah satu-satunya yang pasti yang terikat pada Carriage Return.

Hapus Permintaan Versi HL7 2.x hanya mencakup tiga "jenis data“ : data yang ada data yang tidak ada data yang akan dihapus Dua tipe pertama relatif mudah dipahami: nilai untuk elemen dikirim saat tersedia, jika tidak, elemen tersebut tetap tidak dinilai. Jika informasi tersebut dihapus, kutipan ganda ("") adalah urutan karakter khusus yang ditunjuk untuk mengaktifkan perilaku ini. Fitur ini menempatkan beberapa beban pada aplikasi pengirim, karena penerapan perilaku ini mengharuskan aplikasi mengenali data yang dikomunikasikan sebelumnya telah dihapus. Sebagian besar aplikasi tidak melacak sejarah data spesifik untuk suatu item, sehingga antarmuka tidak dapat mendeteksi bahwa item ini sebelumnya berisi beberapa data yang sudah tidak berlaku lagi. Biasanya, "tidak ada informasi" ditransfer, meninggalkan sistem target dengan informasi lama sampai nilai baru dikirim.

Null-Flavors Versi HL7 2.x tidak mendukung gagasan tentang pembatalan, yang merupakan konsep yang digunakan untuk menunjukkan alasan data tidak ada dalam elemen (misal, tidak diketahui). Metode kerja di sekitar dimana nilai kode digunakan untuk mewakili rasa null telah digunakan sejak versi awal standar diterbitkan. Sayangnya, solusinya telah diterapkan secara teratur dan tidak konsisten. Proposal untuk mendukung rasa tidak sehat telah diajukan, namun kekhawatiran kompatibilitas telah mencegah adopsinya.

Tipe Data Tipe data memberlakukan struktur konten pesan tambahan dalam hirarki pesan. Tipe data mendefinisikan pembagian bidang menjadi komponen dan pembagian komponen ke dalam sub-komponen. Versi pertama dari v2.x hanya memiliki satu tipe data gabungan (tipe data CM). Seiring berjalannya lebih dari 90 jenis data telah tersedia. Tidak seperti bahasa pemrograman biasa, tipe data HL7 v2.x didefinisikan berdasarkan konten yang dimaksudkan untuk mewakili.  Contohnya meliputi: • Nama Orang • Alamat • Rentang Waktu

Events Beberapa pesan bisa diurai dengan mudah karena mereka dalam struktur internal, dan struktur pesan yang berbeda ada yang menggunakan kode event yang sama. Dalam Versi 2.5, profil konteks pesan diperkenalkan bersama dengan profil pesan yang diidentifikasi untuk menunjukkan komposisi pesan bila digunakan dengan benar.

Perilaku Dinamis Perilaku dinamis yang menentukan bagaimana dua aplikasi dapat berkenaan dengan satu pesan. Ketika aplikasi memulai mengirimkan pesan, aplikasi ini perlu mendapatkan indikasi apakah penerima akan menerima pesan atau tidak. Untuk alasan ini, aplikasi penerima akan merespon dengan tanda terima. Hal ini dapat diberikan pada dua tingkat yang berbeda, seperti: • transportasi dan • aplikasi

Protokol Transmisi Seperti yang telah disebutkan sebelumnya, ASTM digunakan sebagai dasar untuk menentukan protocol transmisi HL 7 versi 2.x. namun perbaikan telah diperkenalkan, sebagai contoh, untuk nama segmen terbatas pada tiga huruf. Beberapa short-comings masih tetap seperti HL7 V.1, namun sepertinya kurang penyertaan akhir pesan. Pengawasan ini mengarah pada masalah dengan protocol trasmisi tertentu, khususnya komunikasi berbasis soket. Untuk file pengiriman berbasis trasmisi, pesan hanya ditulis sekuensial kedalam sebuah file. Ketika mentransfer file, pengaman tambahan (file yang bertindak sebagai semaphores, penguncian, penggantian nama), diperlukan untuk memastikan kelengkapan pesan. Untuk framing tambahan harus digunakan sehingga gangguan transmisi dapat terdeteksi.

Protokol Transmisi Seperti yang telah disebutkan sebelumnya, ASTM digunakan sebagai dasar untuk menentukan protocol transmisi HL 7 versi 2.x. namun perbaikan telah diperkenalkan, sebagai contoh, untuk nama segmen terbatas pada tiga huruf. Beberapa short-comings masih tetap seperti HL7 V.1, namun sepertinya kurang penyertaan akhir pesan. Pengawasan ini mengarah pada masalah dengan protocol trasmisi tertentu, khususnya komunikasi berbasis soket. Untuk file pengiriman berbasis trasmisi, pesan hanya ditulis sekuensial kedalam sebuah file. Ketika mentransfer file, pengaman tambahan (file yang bertindak sebagai semaphores, penguncian, penggantian nama), diperlukan untuk memastikan kelengkapan pesan. Untuk framing tambahan harus digunakan sehingga gangguan transmisi dapat terdeteksi.

Tabel dan Nilai HL7 v2.x mendukung gagasan tentang data yang dikodekan, yang dilakukan dengan mendefinisikan tabel nilai dan kemudian mengikat tabel tersebut ke elemen pesan tertentu. Dengan rilis terbaru HL7 V2.X, lebih dari 500 tabel telah didefinisikan, beberapa diantaranya juga menyediakan daftar nilai. Kode untuk nilai yang tercantum dalam tabel harus digunakan jika konsep spesifik yang diperlukan diwakili oleh salah satu kode tersebut, namun memperpanjang tabel dengan nilai kode tambahan yang diperlukan untuk pemrosesan lokal diperbolehkan.

Metodologi Kesesuaian Dengan Hl7 v2.x.5, profil diperkenalkan sebagai bagian dari standar resmi. Profil terdiri dari metodologi kendala yang diterapkan pada konformitas yang ada, dan mereka memberikan representasi formal yang memungkinkan untuk mengekspresikan hambatan diperkenalkan secara tepat.

Terima Kasih