Hasta Yolculuğu Veri Template'iniz
Hasta Yolculuğu Veri Template'iniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Veri Çekim Rehberliği
Hasta Yolculuğu Nitelikleri
| 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
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
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.
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.
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
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,
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,
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
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
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.
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ı '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
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.
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.
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
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
|
|||
Hasta Yolculuğu Aktiviteleri
| 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
|
|||