Hasta Yolculuğu Veri Template'iniz

Oracle Health (Cerner)
Hasta Yolculuğu Veri Template'iniz

Hasta Yolculuğu Veri Template'iniz

Bu kapsamlı template, hasta yolculuklarını etkili bir şekilde analiz etmek ve optimize etmek için ihtiyacınız olan temel data'yı özetler. Toplanacak kritik niteliklerin, izlenecek temel aktivitelerin ve data çıkarımı konusunda pratik rehberliğin yapılandırılmış bir genel görünümünü sunar. Kesintisiz bir process mining deneyimi için event log'unuza hazırlamak üzere bu kaynağı kullanın.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • Veri Çekim Rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Hasta Yolculuğu Nitelikleri

Bunlar, sisteminizdeki hasta yolculuğunun kapsamlı bir analizi için event log'unuza dahil etmeniz önerilen data alanlarıdır.
5 Gerekli 9 Önerilen 6 İsteğe Bağlı
Ad Açıklama
Aktivite
ClinicalEventTag
Gerçekleştirilen klinik veya idari event'in adı veya açıklaması.
Açıklama

Bu attribute, hastanın bakımı sırasında gerçekleştirilen 'İlaç Uygulandı', 'Vital Bulgular Alındı' veya 'Hasta Taburcu Edildi' gibi belirli eylemi yakalar. Süreç adımı için insan tarafından okunabilir bir etiket sağlar.

Cerner'da bu genellikle CLINICAL_EVENT tablosundan elde edilir, özellikle EVENT_CD'yi (Olay Kodu) görüntü değerine eşleyerek veya EVENT_TAG'i kullanarak. Burada tutarlı adlandırma kuralları, okunabilir süreç haritaları için kritik öneme sahiptir.

Neden önemli

Süreç haritasındaki adımları tanımlayarak iş akışının görselleştirilmesini sağlar.

Nereden alınır

Tablo: CLINICAL_EVENT, Sütun: EVENT_TAG veya EVENT_CD için bağlı CODE_VALUE

Örnekler
Triyaj DeğerlendirmesiDiferansiyelli Tam Kan SayımıTaburculuk EmriHasta Transferi
Hasta Epizotu
EncounterId
Belirli hasta ziyareti veya bakım epizotu için benzersiz tanımlayıcı.
Açıklama

Bu attribute, hasta yolculuğu için merkezi case tanımlayıcısı olarak hizmet eder. Tek bir bakım dönemi içinde (örn. yatan hasta kalışı veya acil servis ziyareti) meydana gelen tüm klinik event'leri, siparişleri ve idari eylemleri gruplandırır. Process mining'de bu Kimlik, ayrık aktiviteleri birleşik bir süreç görünümüne dönüştürmek için esastır.

Teknik olarak bu, Cerner Millennium veri tabanındaki ENCOUNTER tablosundaki ENCNTR_ID'ye karşılık gelir. Hasta demografik bilgilerini, siparişleri ve klinik event'leri bağlamak için kullanılan birincil anahtardır.

Neden önemli

Hastanın kabulden taburculuğa kadar olan uçtan uca yolculuğunu yeniden yapılandırmak için gereken temel anahtardır.

Nereden alınır

Tablo: ENCOUNTER, Sütun: ENCNTR_ID

Örnekler
123456789876543211223344
Olay Zaman Damgası
EventEndDateTime
Aktivitenin gerçekleştiği veya tamamlandığı belirli tarih ve saat.
Açıklama

Bu attribute, bir event'in gerçekleştiği kesin anı kaydeder. Aktiviteleri sıralı olarak sıralamak ve süreç adımları arasındaki döngü sürelerini hesaplamak için kullanılır.

CLINICAL_EVENT tablosunda bu genellikle EVENT_END_DT_TM'ye karşılık gelir. Burada doğruluk, 'Hasta Kaydedildi' ile 'Triyaj Değerlendirmesi' arasındaki süre gibi bekleme sürelerini hesaplamak için hayati öneme sahiptir.

Neden önemli

Olayların sırasını belirlemek ve teslim süreleri gibi performans KPI'larını hesaplamak için temeldir.

Nereden alınır

Tablo: CLINICAL_EVENT, Sütun: EVENT_END_DT_TM

Örnekler
2023-10-15T08:30:00Z2023-10-15T09:15:45Z2023-10-16T14:20:00Z
Kaynak Sistem
SourceSystem
Verinin kaynaklandığı sistemin adı.
Açıklama

Veri kaydının kaynak uygulamasını tanımlar. Bu bağlamda, ağırlıklı olarak 'Oracle Health' veya 'Cerner Millennium' olacaktır. Bu, verilerin diğer ESK'lar veya departman sistemleriyle karıştırılabileceği çoklu sistem ortamlarında faydalıdır.

Birden fazla kaynak alınmışsa, analistlerin süreç analizini veri kökenine göre filtrelemesine veya segmentlere ayırmasına olanak tanır.

Neden önemli

Özellikle çoklu sistem Process Mining kurulumlarında veri soyunu ve izlenebilirliği sağlar.

Nereden alınır

Sabit kodlu dize veya Sistem Meta Verileri

Örnekler
Oracle HealthCerner Millennium
Son Veri Güncellemesi
LastDataUpdate
Kaydın depodan çıkarıldığı veya en son değiştirildiği timestamp.
Açıklama

Analizde kullanılan verinin güncelliğini gösterir. Bu zaman damgası, kullanıcıların gerçek zamanlı verilere mi yoksa önceki bir yüklemeden alınan bir anlık görüntüye mi baktıklarını anlamalarına yardımcı olur.

Genellikle bir klinik öznitelik olmaktan ziyade ETL (Ayıklama, Dönüştür, Yükle) süreci sırasında oluşturulur.

Neden önemli

Veri yönetimi ve analizin güncel bilgilerle yapılmasını sağlamak için kritik öneme sahiptir.

Nereden alınır

ETL Sistem Zaman Damgası

Örnekler
2023-11-01T00:00:00Z2023-11-02T12:00:00Z
Birincil Tanı
DiagnosisCode
Bakımın birincil nedenini temsil eden ICD-10 veya SNOMED kodu.
Açıklama

Epizota atanan standartlaştırılmış klinik kod (örn. Pnömoni için 'J18.9'). Bu, belirli hastalıklar için 'Tedavi Protokolü Sapması'nı analiz etmek üzere hastaları duruma göre gruplandırmaya olanak tanır.

ENCOUNTER'a bağlı DIAGNOSIS tablosunda bulunur.

Neden önemli

Belirli durumlar için hasta yollarının birebir karşılaştırılmasına olanak tanır.

Nereden alınır

Tablo: DIAGNOSIS, Sütun: DIAGNOSIS_CODE (nomenklatür aracılığıyla)

Örnekler
I10E11.9J18.9
Bölüm
NurseUnit
Event'in gerçekleştiği belirli servis, birim veya departman.
Açıklama

Olay anında hastadan sorumlu fiziksel konumu veya organizasyonel birimi tanımlar (örn. 'ICU', 'Genel Cerrahi', 'Acil Servis').

Bu, birimler arasındaki hareketi takip ederek 'Servisler Arası Transfer Verimliliği' dashboard'una yardımcı olur. Cerner'da bu, genellikle Encounter veya takip tablosundaki LOC_NURSE_UNIT_CD'dir.

Neden önemli

Belirli departmanlardaki darboğazları analiz etmek ve hasta akış coğrafyasını görselleştirmek için temeldir.

Nereden alınır

Tablo: ENCOUNTER veya CLINICAL_EVENT, Sütun: LOC_NURSE_UNIT_CD

Örnekler
Acil ServisKardiyoloji ServisiICURadyoloji
Dosya Tipi
EncounterType
Hasta ziyaretinin kategorizasyonu; örneğin Yatan Hasta, Ayakta Hasta veya Acil Durum.
Açıklama

Hasta episodunun niteliğini sınıflandırır. Bu, veriyi dilimlemek için birincil bir boyuttur, çünkü 'Acil' ziyaretinin süreç akışı 'Planlı Yatan Hasta' ziyaretinden önemli ölçüde farklıdır.

Bu, ENCOUNTER tablosundaki ENCNTR_TYPE_CD'den türetilmiştir ve bir kod seti değerini (örn. 'Yatan Hasta', 'Acil') referans alır.

Neden önemli

Farklı bakım ortamlarındaki yolların ve verimin karşılaştırmalı analizine olanak tanır.

Nereden alınır

Tablo: ENCOUNTER, Sütun: ENCNTR_TYPE_CD (CODE_VALUE aracılığıyla çözümlendi)

Örnekler
Yatan HastaAcilAyaktan HastaGünübirlik Cerrahi
Hasta Kimliği
PersonId
Birden fazla encounter'da hasta için benzersiz tanımlayıcı.
Açıklama

Vaka ID'sinden farklı olarak, Hasta ID'si (veya Kişi ID'si) bir hastanın hastaneye yaptığı tüm ziyaretlerde sabit kalır. Bu öznitelik, tekrar yatış oranlarını analiz etmek ve hastanın uzun vadeli geçmişini anlamak için çok önemlidir.

Cerner'da bu, PERSON tablosundaki PERSON_ID'dir. Birden fazla ENCNTR_ID kaydını birbirine bağlar.

Neden önemli

Ayrı episodları aynı bireye bağlayarak 'Hasta Tekrar Yatış Oranı' KPI'ını mümkün kılar.

Nereden alınır

Tablo: PERSON, Sütun: PERSON_ID

Örnekler
P10001P55992P99221
Kalış Süresi
LengthOfStay
Hasta epizotunun gün veya saat cinsinden toplam süresi.
Açıklama

Bu, kabul timestamp'i ile taburculuk timestamp'i arasındaki zaman farkını temsil eden hesaplanmış bir attribute'tür. 'Genel Hasta Kalış Süresi Analizi' dashboard'ı için birincil verimlilik metriğidir.

Bu, process mining aracı içinde hesaplanabilse de, case düzeyinde önceden hesaplanmış statik bir attribute olarak içe aktarmak genellikle performans açısından verimlidir.

Neden önemli

Hastane yönetimi için en önemli tek verimlilik KPI'ıdır.

Nereden alınır

ENCOUNTER.REG_DT_TM ve DISCH_DT_TM'den türetilmiştir

Örnekler
4.5 gün2 saat12 gün
Kullanıcı
PerformingPrsnlId
Aktiviteyi gerçekleştiren klinisyenin kimliği veya adı.
Açıklama

İlacı uygulayan hemşire veya taburculuğu imzalayan doktor gibi süreç adımını kimin gerçekleştirdiğini yakalar. Bu, kaynak kullanım analizine olanak tanır.

Cerner'da bu, tabloya (Siparişler vs Klinik Olaylar) bağlı olarak genellikle PERFORMED_PRSNL_ID veya UPDT_ID'dir. Bunun genel bir 'Kullanıcı' özniteliğine eşlenmesi, Görev Ayrılığı analizini kolaylaştırır.

Neden önemli

Kaynak analizini destekler ve potansiyel eğitim ihtiyaçlarını veya iş yükü dengesizliklerini belirler.

Nereden alınır

Tablo: CLINICAL_EVENT, Sütun: PERFORMED_PRSNL_ID

Örnekler
Dr. SmithHemşire JonesSysAdmin
Sipariş Kalemi
OrderMnemonic
Laboratuvar testi veya ilaç gibi verilen belirli siparişin adı.
Açıklama

Bir sipariş olayının içeriğini tanımlar (örn. 'Tam Kan Sayımı', 'Aspirin 81mg'). Bu öznitelik, 'Tanı Siparişi Verildi' ve 'İlaç Uygulandı' aktiviteleri için gerekli bağlamı sağlar.

Genellikle ORDERS tablosundaki ORDER_MNEMONIC altında bulunur. Süreç boyunca akan 'Ürün' olarak işlev görür.

Neden önemli

Tanısal ve tedavi yolaklarının ayrıntılı analizi için gereklidir.

Nereden alınır

Tablo: ORDERS, Sütun: ORDER_MNEMONIC

Örnekler
Akciğer GrafisiTemel Metabolik PanelAsetaminofenBeyin MRG
Taburculuk Durumu
DischargeDisposition
Taburculuk sonrası hastanın varış noktası veya durumu.
Açıklama

Epizot bittikten sonra hastanın nereye gittiğini (örn. 'Eve', 'Nitelikli Bakım Tesisi', 'Vefat Etti') belirtir. Bu, 'Taburculuk Planlaması' analizi ve başarısız sonuçların belirlenmesi için kritik öneme sahiptir.

ENCOUNTER tablosunda DISCH_DISPOSITION_CD olarak bulunur.

Neden önemli

Temel sonuç metriği; hasta yolculuğunun 'son durumunu' tanımlar.

Nereden alınır

Tablo: ENCOUNTER, Sütun: DISCH_DISPOSITION_CD (CODE_VALUE aracılığıyla çözümlendi)

Örnekler
Eve Taburcu EdildiRehabilitasyona Transfer EdildiTıbbi Tavsiyeye Karşı AyrıldıSüresi Doldu
Yeniden Yatış Var mı
IsReadmission
Bu episodun önceki bir taburculuktan sonraki 30 gün içinde gerçekleşip gerçekleşmediğini gösteren bayrak.
Açıklama

Bir tekrar yatışı temsil eden vakaları tanımlamak için kullanılan bir boolean bayrağıdır. Bu, mevcut episodun kabul tarihinin, aynı PersonId için önceki episodun taburcu tarihiyle karşılaştırılmasıyla hesaplanır.

'Hasta Tekrar Yatış Trendleri' dashboard'u için temeldir.

Neden önemli

'Hasta Tekrar Yatış Oranı' KPI'ını doğrudan destekler, bu da önemli bir bakım kalitesi metriğidir.

Nereden alınır

ENCOUNTER kayıtlarını karşılaştıran SQL Mantığı aracılığıyla türetilmiştir

Örnekler
truefalse
İlaç Durumu
MedAdminStatus
İlaç siparişinin durumu (örn. Verildi, Reddedildi, Verilmedi).
Açıklama

Bir ilaç uygulama görevinin sonucunu gösterir. 'İlaç Uygulama Uyumluluğu' dashboard'u için, gerçekten uygulanan ilaçlar ile planlanmış ancak kaçırılan veya reddedilenler arasında ayrım yapmak hayati öneme sahiptir.

Muhtemelen CLINICAL_EVENT veya belirli İlaç Uygulama Kaydı (MAR) tablolarında bulunur.

Neden önemli

Tedavi protokollerindeki uyum boşluklarını belirler.

Nereden alınır

Oracle Health (Cerner) dokümantasyonuna başvurun

Örnekler
UygulandıReddedildiBekletildi
Kabul Kanalı
AdmissionSource
Hasta kabulünün kaynağı.
Açıklama

Hastanın hastane sistemine nasıl girdiğini açıklar; örneğin 'Doktor Yönlendirmesi', 'Acil Servis' veya 'Başka Hastaneden Sevk'.

Bu, hastane sürecinin 'ön kapısını' analiz etmeye yardımcı olur. ENCOUNTER tablosundaki ADMIT_SRC_CD'ye eşlenir.

Neden önemli

'İlk Değerlendirme Bekleme Süresi'ni giriş noktasına göre bağlamlandırır.

Nereden alınır

Tablo: ENCOUNTER, Sütun: ADMIT_SRC_CD

Örnekler
Acil ServisDoktor SevkHastaneden Transfer
Ödeyen Tipi
FinancialClass
Hastanın birincil sigorta kapsamı veya finansal sınıflandırması.
Açıklama

Hastayı ödeme kaynağına göre (örn. Medicare, Özel Sigorta, Kendi Ödemesi) kategorize eder. Bu öznitelik, süreç akışlarının veya kalış sürelerinin sigorta türüne göre değişip değişmediğini analiz etmek için kullanılır.

ENCOUNTER tablosundaki FINANCIAL_CLASS_CD'den türetilmiştir.

Neden önemli

Ödeme yapan türe göre bakım sunumundaki veya idari süreçlerdeki farklılıkları belirlemeye yardımcı olur.

Nereden alınır

Tablo: ENCOUNTER, Sütun: FINANCIAL_CLASS_CD (CODE_VALUE aracılığıyla çözümlendi)

Örnekler
MedicareBlue CrossKendi ÖdemeliMedicaid
Sipariş Numarası
OrderId
Belirli bir sipariş (Laboratuvar, İlaç, Konsültasyon) için benzersiz tanımlayıcı.
Açıklama

Bir sipariş için sistem tarafından oluşturulan kimlik. Vaka Kimliği olmasa da, bu önemli bir ikincil anahtardır. 'Tanısal Sipariş Verildi' event'ini 'Tanısal Sonuç Doğrulandı' event'ine bağlar.

Bu olmadan, bir hastanın birden fazla eş zamanlı siparişi varsa belirli testler için kesin dönüş süresini hesaplamak zordur.

Neden önemli

Eşleştirilmiş aktiviteleri (Sipariş -> Sonuç) doğru bir şekilde bağlamak için temeldir.

Nereden alınır

Tablo: ORDERS, Sütun: ORDER_ID

Örnekler
88291028829103
Sonuç Durumu
ResultStatus
Tanısal bir sonucun durumu (örn. Auth (Doğrulandı), Düzeltildi, Ön).
Açıklama

Bir tanı testi sonucunun yaşam döngüsü aşamasını gösterir. Bu, bir sonucun klinik karar verme için ne zaman resmi olarak kullanılabilir olduğunu belirlemek amacıyla 'Tanı Sonucu Teslim Süresi' analizinde kullanılır.

Genellikle belirli durum kodlarıyla CLINICAL_EVENT'te bulunur.

Neden önemli

Ön ve nihai sonuçlar arasında ayrım yapar, bu da sonraki aktivitelerin ne zaman başlayacağını etkiler.

Nereden alınır

Tablo: CLINICAL_EVENT, Sütun: RESULT_STATUS_CD

Örnekler
Yetkilendirme (Doğrulandı)HatadaDeğiştirildi
Triyaj Önceliği
TriageAcuity
Triyaj değerlendirmesi sırasında atanan aciliyet seviyesi.
Açıklama

Hastanın durumunun ciddiyetini gösteren sayısal veya kategorik bir değerdir (örn. 1-Acil'den 5-Acil Değil'e kadar). Yüksek öncelikli hastaların daha kısa bekleme sürelerine sahip olması gerektiğinden, bekleme sürelerini analiz etmek için hayati bir segmentasyon özniteliğidir.

Genellikle Triage olayı sırasında klinik formlarda veya belirli gözlem kodlarında yakalanır.

Neden önemli

Sürecin hastaları klinik aciliyete göre doğru bir şekilde önceliklendirip önceliklendirmediğini doğrulamak için kritik öneme sahiptir.

Nereden alınır

Oracle Health (Cerner) dokümantasyonuna başvurun

Örnekler
12345
Gerekli Önerilen İsteğe Bağlı

Hasta Yolculuğu Aktiviteleri

Bunlar, doğru Process Discovery ve darboğaz tespiti için event log'unuza dahil etmeniz gereken temel süreç adımları ve kilometre taşlarıdır.
8 Önerilen 6 İsteğe Bağlı
Aktivite Açıklama
Departman Transferi Gerçekleşti
Hastanın bir yerden (örn. acil servis) başka bir yere (örn. yoğun bakım) fiziksel olarak taşındığını gösterir. Bu, konum geçmişi üzerinden takip edilir.
Neden önemli

'Servisler Arası Transfer Verimliliği' analizine olanak tanır ve hastaların hastane içindeki akışını görselleştirmeye yardımcı olur.

Nereden alınır

ENCNTR_LOC_HIST (Encounter Konum Geçmişi) tablosu, LOC_NURSE_UNIT_CD'deki değişiklikleri yakalar.

Yakala

Durum alanını öncesi/sonrası ile karşılaştır

Event tipi inferred
Hasta Kaydedildi
Hastanın sisteme girdiği ve kayıt edildiği anda hasta epizotunun başlangıcını işaretler. Cerner Millennium'da bu, encounter kaydı oluşturulduğunda veya kayıt timestamp'i ayarlandığında yakalanır.
Neden önemli

Kalış Süresi (LOS) hesaplamaları ve ilk bekleme süresi analizi için başlangıç zamanını belirler.

Nereden alınır

ENCOUNTER tablosu, özellikle REG_DT_TM (Kayıt Tarihi/Saati) sütunu.

Yakala

İşlem yeni ENCOUNTER satırı oluşturduğunda kaydedildi

Event tipi explicit
Hasta Taburcu Edildi
Hastanın kalışını sonlandıran nihai idari event. Bu timestamp, toplam Kalış Süresini hesaplamak için kullanılır.
Neden önemli

Sürecin birincil bitiş event'i. Kalış Süresi ve yeniden yatış hesaplamaları için esastır.

Nereden alınır

ENCOUNTER tablosu, özellikle DISCH_DT_TM (Taburculuk Tarihi/Saati).

Yakala

Encounter durumu DISCHARGED olarak değiştiğinde kaydedildi

Event tipi explicit
Taburculuk Emri İmzalandı
Doktorun hastayı taburcu etme emrini verdiği event. Bu, taburculuk planlama saatini başlatır.
Neden önemli

'Taburculuk Planlama Döngü Süresi' için başlangıç noktası. Bununla gerçek taburculuk arasındaki boşluk, operasyonel gecikmeleri gösterir.

Nereden alınır

Katalog tipi Taburculuk gösterdiğinde ORDERS tablosu.

Yakala

Taburculuk emri durumu ORDERED olarak ayarlandığında kaydedildi

Event tipi explicit
Tanı Belgelendi
Hastanın encounter kaydına resmi bir tanı eklendiğinde gerçekleşir. Bu, bir test sonucundan farklıdır ve klinisyenin durumu onaylamasını temsil eder.
Neden önemli

'Tanı Doğrulandı' dönüm noktası ve kesin tanıya kadar geçen süreyi analiz etmek için temeldir.

Nereden alınır

DIAGNOSIS tablosu, ENCOUNTER_ID'ye bağlı DIAGNOSIS_DT_TM kullanılarak.

Yakala

PowerChart'ta tanı eklendiğinde/güncellendiğinde kaydedildi

Event tipi explicit
Tanı Siparişi Verildi
Bir klinisyen laboratuvar testi veya görüntüleme çalışması için bir sipariş girdiğinde gerçekleşir. Bu timestamp, tanısal dönüş süresi hesaplamasını başlatır.
Neden önemli

'Tanısal Sonuç Teslim Süresi' KPI'ı için başlangıç noktası; sipariş verme ile uygulama arasındaki gecikmeleri belirlemeye yardımcı olur.

Nereden alınır

Katalog tipi Laboratuvar veya Radyoloji olduğunda ORIG_ORDER_DT_TM kullanılarak ORDERS tablosu.

Yakala

Sipariş durumu ORDERED olarak ayarlandığında kaydedildi

Event tipi explicit
Tanı Sonucu Doğrulandı
Bir laboratuvar veya görüntüleme sonucunun kesinleştiği ve klinisyene sunulduğu an. Bu, tanısal dönüş süresi aralığını sonlandırır.
Neden önemli

'Tanı Sonucu Teslim Süresi' döngüsünü tamamlar ve sonraki tedavi kararlarını tetikler.

Nereden alınır

CLINICAL_EVENT tablosu (laboratuvarlar için) veya ORDERS durumunun COMPLETED olarak değişmesi.

Yakala

Sonuç durumu AUTH (Doğrulandı) olarak değiştiğinde kaydedildi

Event tipi explicit
Triyaj Değerlendirmesi Tamamlandı
Acil servis veya kabul bağlamında ilk hemşire değerlendirmesinin veya triyaj formunun tamamlanmasını temsil eder. Bu genellikle sistem içinde belgelenmiş belirli bir form veya klinik event'tir.
Neden önemli

'İlk Değerlendirme Bekleme Süresi' KPI'ını hesaplamak ve ön kapıdaki darboğazları belirlemek için kritik öneme sahiptir.

Nereden alınır

CLINICAL_EVENT tablosu, Triage veya İlk Değerlendirme formlarıyla ilişkili olay kodlarına göre filtrelenmiştir.

Yakala

Klinik belge/form imzalandığında/doğrulandığında kaydedildi

Event tipi explicit
Bakım Planı Aktive Edildi
Cerner'da bir PowerPlan'ın veya bakım yolağının başlatılmasını temsil eder. Bu, standartlaştırılmış bir tedavi protokolünün seçildiğini işaret eder.
Neden önemli

'Tedavi Protokolü Sapma Analizi' için gerçek bakımı planlanan yol ile karşılaştırmak açısından çok önemlidir.

Nereden alınır

ACT_PW_CAT (Eylem Yolu Kataloğu) veya DCP_FORMS_REF, yolu Encounter'a bağlar.

Yakala

PowerPlan başlatıldığında kaydedildi

Event tipi explicit
İlaç Uygulandı
İlaç Uygulama Kaydı (MAR) belgelendiği üzere, hastaya ilacın fiili uygulamasını kaydeder.
Neden önemli

İlaçların zamanında verilip verilmediğini doğrulayarak 'İlaç Uygulama Uyumluluğu' dashboard'ını destekler.

Nereden alınır

CLINICAL_EVENT tablosu, ilaç uygulama olayları için filtrelenmiştir (Görev Durumu = Tamamlandı).

Yakala

Barkod taraması veya manuel MAR girişi üzerine kaydedildi

Event tipi explicit
Konsültasyon Tamamlandı
Uzman konsültasyonunun tamamlandığını işaretler, genellikle imzalı bir konsültasyon notu veya belgesi ile kanıtlanır.
Neden önemli

Uzman görüşünün ne zaman alındığını belirler; bu durum karmaşık bakım yollarında bir darboğaz olabilir.

Nereden alınır

CLINICAL_EVENT tablosu, Konsültasyonlar olarak sınıflandırılan belge türleri için filtrelenmiştir.

Yakala

Konsültasyon notu imzalandığında kaydedildi

Event tipi explicit
Prosedür Planlandı
Belirli bir zaman için bir cerrahi vaka veya büyük bir prosedürün rezerve edildiğini gösterir. Bu, kaynak tahsisini ve prosedür öncesi bekleme sürelerini anlamaya yardımcı olur.
Neden önemli

Ameliyathane veya işlem odası kullanımındaki planlama verimliliğini ve potansiyel darboğazları vurgular.

Nereden alınır

Encounter'a bağlı SURGICAL_CASE tablosu veya SCH_APPT tablosu.

Yakala

Planlama işlemi onaylandığında kaydedildi

Event tipi explicit
Prosedür Yapıldı
Bir ameliyatın veya büyük bir prosedürün ne zaman gerçekleştiğini gösteren timestamp. Bu genellikle perioperatif dokümantasyonda yakalanır.
Neden önemli

Klinik yolaklar ve kaynak kullanımı analizi için önemli bir dönüm noktasıdır.

Nereden alınır

SURGICAL_CASE tablosu (Vaka Başlangıç/Bitiş zamanları) veya yatak başı prosedürler için CLINICAL_EVENT.

Yakala

SurgiNet veya prosedür dokümantasyonu aracılığıyla kaydedildi

Event tipi explicit
Takip Randevusu Planlandı
Hastaya aynı epizot veya bakım planına bağlı gelecek bir randevu ayarlandığında gerçekleşir.
Neden önemli

'Takip Planlama Zamanlaması' dashboard'ını destekler. Bakım sürekliliği verimliliğini ölçer.

Nereden alınır

PERSON_ID'ye bağlı SCH_APPT (Randevu Planla) tablosu.

Yakala

Randevu planlama modülünde oluşturulduğunda kaydedildi

Event tipi explicit
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi Oracle Health (Cerner)'dan nasıl alırsınız